Red Hat Bugzilla – Bug 80535
Matrox G200 crash when trying to use XVideo extension for DVD playback
Last modified: 2007-04-18 12:49:20 EDT
From Bugzilla Helper: User-Agent: Mozilla/5.0 Galeon/1.2.6 (X11; Linux i686; U;) Gecko/20020916 Description of problem: Machine: Celeron 333A, Matrox G200 (8Mb), 192Mb RAM. When using mplayer to play AVIs of a particular size, or DVDs (same thing happens using OGLE to play DVDs - see output later), the XVideo extension seems to fail on startup. mplayer works fine when playing other AVIs using XVideo. It just seems to be screens of size 720x576 that cause a problem. It can result in a locked mouse pointer - but otherwise the machine seems to function normally after the error. mplayer - http://www.mplayerhq.hu/homepage/ ogle - http://www.dtek.chalmers.se/groups/dvd/ Version-Release number of selected component (if applicable): How reproducible: Always Steps to Reproduce: 1. mplayer -vo xv dvd:// or ogle 2. 3. Actual Results: program fails, and can possibly lock the mouse pointer. Using "mplayer -vo dga dvd://" or "mplayer -vo x11 dvd://" works. Expected Results: The DVD should have played. Additional info: Example output from mplayer when attempting to play a DVD: libmpeg2: Using MMX for IDCT transform libmpeg2: Using MMX for motion compensation VDec: vo config request - 720 x 576 (preferred csp: Planar YV12) VDec: using Planar YV12 as output csp (no 0) Movie-Aspect is 1.78:1 - prescaling to correct movie aspect. VO: [xv] 720x576 => 1024x576 Planar YV12 Selected video codec: [mpeg12] vfm:libmpeg2 (MPEG 1 or 2) ========================================================================== AO: [oss] 48000Hz 2ch Signed 16-bit (Little-Endian) Building audio filter chain for 48000Hz/2ch/16bit -> 48000Hz/2ch/16bit... Start playing... X11 error: BadAlloc (insufficient resources for operation) 0.0% 0 0 0% MPlayer interrupted by signal 6 in module: flip_page ************* Example output when using OGLE to play a DVD: Note[ogle_vout]: Found Xv extension 2.2, checking for suitable adaptors Note[ogle_vout]: Xv adaptor "Matrox G-Series Backend Scaler" port 67 image format 842094169 Debug[ogle_vout]: resize: 1024, 576 WARNING[ogle_vout]: check_for_EWMH: property has wrong type Debug[ogle_vout]: resize: 1024, 576 X Error of failed request: BadAlloc (insufficient resources for operation) Major opcode of failed request: 142 (XVideo) Minor opcode of failed request: 19 () Serial number of failed request: 99 Current serial number in output stream: 99 **************** Output from the xvinfo command: $ xvinfo X-Video Extension version 2.2 screen #0 Adaptor #0: "Matrox G-Series Backend Scaler" number of ports: 1 port base: 67 operations supported: PutImage supported visuals: depth 16, visualID 0x23 depth 16, visualID 0x24 depth 16, visualID 0x25 depth 16, visualID 0x26 depth 16, visualID 0x27 depth 16, visualID 0x28 depth 16, visualID 0x29 depth 16, visualID 0x2a depth 16, visualID 0x2b depth 16, visualID 0x2c depth 16, visualID 0x2d depth 16, visualID 0x2e depth 16, visualID 0x2f depth 16, visualID 0x30 depth 16, visualID 0x31 depth 16, visualID 0x32 number of attributes: 1 "XV_COLORKEY" (range 0 to 16777215) client settable attribute client gettable attribute (current value is 2110) maximum XvImage size: 1024 x 1024 Number of image formats: 3 id: 0x32595559 (YUY2) guid: 59555932-0000-0010-8000-00aa00389b71 bits per pixel: 16 number of planes: 1 type: YUV (packed) id: 0x32315659 (YV12) guid: 59563132-0000-0010-8000-00aa00389b71 bits per pixel: 12 number of planes: 3 type: YUV (planar) id: 0x30323449 (I420) guid: 49343230-0000-0010-8000-00aa00389b71 bits per pixel: 12 number of planes: 3 type: YUV (planar)
Please attach the XFree86 log file and config file that you were using for the above with bugzilla's file attachment feature below. If you lower the resolution you are using, does that make it work at all?
Created attachment 88986 [details] XFree86 config file
Created attachment 88987 [details] XFree log file Lowering the resolution or changing the colour depth makes no difference.
Ugh, you set the config file to octet-stream...
Ok, I fixed that.. I don't see anything immediate in the log or config currently.
Not relevant I suppose, but I set the bugzilla form to auto-detect the type of the first attachment and, for some reason, it chose octet stream :) I set the second one manually to text/plain.
*** This bug has been marked as a duplicate of 126307 ***
Changed to 'CLOSED' state since 'RESOLVED' has been deprecated.