GNOME Bugzilla – Bug 315312
Gstreamer Xv uses RGB instead of YUV.
Last modified: 2006-05-26 09:58:19 UTC
Distribution/Version: X.org 7.0.0 RC0 Gstreamer would fail when set Video output is set to Xv. The test output in the capplet would crash. Thaytan on IRC helped me get to the source of the problem. The X server is X.org 7.0.0 RC0, with the radeon driver. Thaytan looked at debug output: thaytan pat__: so for some reason we try and output RGB into what seems to be a YUV buffer thaytan pat__: does gst-launch-0.8 videotestsrc ! video/x-raw-yuv,format='(fourcc)I420' ! xvimagesink work? pat__ thaytan: that does, indeed, work. pat__ x-raw-rgb does not. thaytan pat__: so our problem is that with your Xv driver, it thinks it can do RGB output and then messes up
Created attachment 51841 [details] Debug level 5 output.
Created attachment 51842 [details] Output from xvinfo.
After some investigation, it appears that XvShmCreateImage returns an xvimage structure with a data_size set to half what it should be for the 32bit format that was negotiated. It is unclear why this happens, but it seems to be an Xserver bug. Attaching patch that at least catches this error and prevents us from crashing when the Xserver hands us this garbage.
Created attachment 51843 [details] [review] Patch to prevent crashing on bad allocation from the Xserver
Using this patch, ** (process:27280): WARNING **: gst_xvimagesink_xvimage_new failed to create image of suitable size (Wanted 307200, got 153600) With an image size of 320x240, that means that 4 bytes per pixel (32bpp) we requested, but we only got 16bpp. An alternative explanation is that, looking through the radeon_video.c code, we have the width passed to a function being multiplied and divided by two.
Committed thaythan's patch. It fixes the segfault! Have you reported your issues to the x.org bugzilla ? any news ?
Created attachment 52837 [details] Photo of bad Xv output. I have opened the bug at freedesktop: https://bugs.freedesktop.org/show_bug.cgi?id=4640 The image shows how the (broken) output looks.
Pat, I notice noone ever commented on the fdo bug. Could you please test if this is still ongoing or if it got silently fixed?
The error still exists in gstreamer-0.8, with Xorg 7.0.0.
Further attempts reveal that it does not work with 0.10 either. There is no surprise here, since it appears to be a bug in X.org.
We need to ping the upstream bug then, and find out what's happening with it.
this is a plugins issue
Making some progress upstream, but this bug's not ready to be closed yet.
I just committed some fixes to xvimagesink in 0.10 that make it so a) It should be handling RGB Xv overlays correctly b) It always prefers YUV over RGB formats c) It gracefully errors out when the X server hands back a broken video buffer. Closing, I believe the remaining problems are all on the X Server side now.