GNOME Bugzilla – Bug 589232
the red/green/blue masks in ximagesink don't match the ones in videotestsrc/ffmpegcolorspace
Last modified: 2010-01-14 19:52:38 UTC
Please describe the problem: I use the following pipeline : videotestsrc ! ximagesink I've tried using videotestsrc ! ffmpegcolorspace ! videoscale ! ximagesink too I understood from the GST_DEBUG=5 log file that the red/green/blue masks in ximagesink don't match the ones in videotestsrc/ffmpegcolorspace ffmpegcolorspace and videotestsrc need to start supporting other caps it likely works on the desktop because I have different hardware here and/or a different screen depth is used Steps to reproduce: 1. maybe configure your x server to use a different depth or somesuch? 2. 3. Actual results: DISPLAY=:0 GST_DEBUG=5 gst-launch videotestsrc ! ximagesin k --gst-debug-no-color 2>&1 | tee mylog.log (returns errors) Expected results: DISPLAY=:0 gst-launch videotestsrc ! fakesink (no errors) Does this happen every time? yes Other information: I run it on ARM Platform (at91sam9261ek) my rootfs is built by OE (angstrom disribution) x11-image + gstremaer + gst-plugins
Created attachment 138895 [details] GST_DEBUG=5 log file .tar.bz2 save as file like tar.biz2
What exactly is the difference between the r/g/b masks? The masks are received from the X server in any case so it looks like your X server uses a mask/endianness combination that is not supported by GStreamer (or more specific ffmpegcolorspace) (yet).
You could also try videotestsrc ! videoscale ! ffmpegcolorspace ! ximagesink btw.
Unless it's a bug in the driver and these masks are considered broken, standard elements like ffmpegcolorspace and videotestsrc/videoscale should handle these masks as well IMO.
Closing this bug report as no further information has been provided. Please feel free to reopen this bug if you can provide the information asked for. Thanks!