GNOME Bugzilla – Bug 364737
Totem gets red and blue channel swapped when playing a file
Last modified: 2006-10-26 07:48:53 UTC
When playing an avi with the Xv gstreamer backend in totem it seems the red and blue channels have been swapped. However, when i play the same file in mplayer (with Xv output) the colors are right. Totem is 2.16.1 and gstreamer 0.10.9. The X server is ATI fglrx 8.29.6 with Xorg 7.1.1. Here is the mplayer output playing the file: $ mplayer Battlestar\ Galactica\ -\ 2x01\ -\ Scattered.avi MPlayer 1.0pre8-rpm.livna.org-4.1.1 (C) 2000-2006 MPlayer Team CPU: Genuine Intel(R) CPU T2500 @ 2.00GHz (Family: 6, Model: 14, Stepping: 8) CPUflags: MMX: 1 MMX2: 1 3DNow: 0 3DNow2: 0 SSE: 1 SSE2: 1 Compiled with runtime CPU detection. Linux RTC init error in ioctl (rtc_irqp_set 1024): Permission denied Try adding "echo 1024 > /proc/sys/dev/rtc/max-user-freq" to your system startup scripts. Setting up LIRC support... mplayer: could not connect to socket mplayer: No such file or directory Failed to open LIRC support. You will not be able to use your remote control. Playing Battlestar Galactica - 2x01 - Scattered.avi. AVI file format detected. VIDEO: [XVID] 640x352 12bpp 23.976 fps 991.6 kbps (121.0 kbyte/s) Clip info: Software: Nandub v1.0rc2 ========================================================================== Opening audio decoder: [mp3lib] MPEG layer-2, layer-3 AUDIO: 48000 Hz, 2 ch, s16le, 128.0 kbit/8.33% (ratio: 16000->192000) Selected audio codec: [mp3] afm: mp3lib (mp3lib MPEG layer-2, layer-3) ========================================================================== ========================================================================== Opening video decoder: [ffmpeg] FFmpeg's libavcodec codec family Selected video codec: [ffodivx] vfm: ffmpeg (FFmpeg MPEG-4) ========================================================================== alsa-init: using device default alsa: 48000 Hz/2 channels/4 bpf/65536 bytes buffer/Signed 16 bit Little Endian AO: [alsa] 48000Hz 2ch s16le (2 bytes per sample) Starting playback... VDec: vo config request - 640 x 352 (preferred colorspace: Planar YV12) VDec: using Planar YV12 as output csp (no 0) Movie-Aspect is 1.82:1 - prescaling to correct movie aspect. VO: [xv] 640x352 => 640x352 Planar YV12 A: 3.7 V: 3.7 A-V: 0.013 ct: -0.002 89/ 89 6% 0% 0.9% 0 0
I have gotten this when switching from Nvidia(closed) to Nv(open) on Ubuntu systems.
Tim, how can we check which type of XvImage was used by the GStreamer backend?
I guess this is the same issue as in bug #357741, most likely a driver bug. Could you try this: 1) gst-launch-0.10 videotestsrc ! video/x-raw-yuv,format=\(fourcc\)I420 ! xvimagesink 2) gst-launch-0.10 videotestsrc ! video/x-raw-yuv,format=\(fourcc\)YV12 ! xvimagesink (or 'videotestsrc ! ximagesink' for a reference picture) 3) gst-launch-0.10 -v playbin uri=file:///path/to/foo.avi should output a line with the caps used by xvimagesink
1) red/blue swapped 2) right colors 3) red/blue swapped, output attached
Created attachment 75424 [details] playbin output
Thanks, so it really is the same as #357741 then. I guess we might be able to hack around it somehow if we can detect the driver in xvimagesink, but at the end of the day it's a driver bug and it needs to be fixed there (YV12 is exactly the same format as I420 only that the two chroma planes are swapped). *** This bug has been marked as a duplicate of 357741 ***