GNOME Bugzilla – Bug 387073
gst-launch videotestsrc ! ffmpegcolorspace ! ximagesink doesnot work on sunray
Last modified: 2006-12-22 11:10:59 UTC
Please describe the problem: gst-launch videotestsrc ! ximagesink works on sunray, but gst-launch videotestsrc ! ffmpegcolorspace ! ximagesink does not work it tells me that Setting pipeline to PAUSED ... ERROR: Pipeline doesn't want to pause. ERROR: from element /pipeline0/videotestsrc0: Could not negotiate format Additional debug info: gstbasesrc.c(1837): gst_base_src_start (): /pipeline0/videotestsrc0: Check your filtered caps, if any Setting pipeline to NULL ... FREEING pipeline ... Steps to reproduce: 1. 2. 3. Actual results: Expected results: Does this happen every time? yes Other information:
Created attachment 78543 [details] xdpyinfo for sunray
Created attachment 78545 [details] debug info GST_DEBUG=*:5 gst-launch videotestsrc ! ffmpegcolorspace ! ximagesink >/tmp/dtu.log 2>&1
This situtation is a little hard to debug, because the SunStudio C compiler doesn't have the GCC printf format extensions that we use for printing caps details in the debug output. As a result, the debug output just lists some pointer values, and we don't know what's inside them. The only thing I notice in the xdpyinfo is that the server seems to have opposite endianness to the X server on my (little endian) machine and the one on the Sparc SunBlade1000 here. Jerry also mentioned on IRC that the sunray doesn't have XShm support, which shouldn't cause a problem - ximagesink works fine over ssh which is the same situation.
when I run gst-launch -v videotestsrc ! ximagesink on sunray client and server. I find that diff -/pipeline0/videotestsrc0.src: caps = video/x-raw-rgb, bpp=(int)32, endianness=(int)4321, depth=(int)24, red_mask=(int)16711680, green_mask=(int)65280, blue_mask=(int)255, width=(int)320, height=(int)240, framerate=(fraction)30/1, pixel-aspect-ratio=(fraction)1/1 -/pipeline0/ximagesink0.sink: caps = video/x-raw-rgb, bpp=(int)32, endianness=(int)4321, depth=(int)24, red_mask=(int)16711680, green_mask=(int)65280, blue_mask=(int)255, width=(int)320, height=(int)240, framerate=(fraction)30/1, pixel-aspect-ratio=(fraction)1/1 +/pipeline0/videotestsrc0.src: caps = video/x-raw-rgb, bpp=(int)32, endianness=(int)4321, depth=(int)24, red_mask=(int)255, green_mask=(int)65280, blue_mask=(int)16711680, width=(int)320, height=(int)240, framerate=(fraction)30/1, pixel-aspect-ratio=(fraction)1/1 +/pipeline0/ximagesink0.sink: caps = video/x-raw-rgb, bpp=(int)32, endianness=(int)4321, depth=(int)24, red_mask=(int)255, green_mask=(int)65280, blue_mask=(int)16711680, width=(int)320, height=(int)240, framerate=(fraction)30/1, pixel-aspect-ratio=(fraction)1/1 New clock: GstSystemClock so I guess that ffmpegcolorspace can not handle this special color mask caused this problem?
Created attachment 78743 [details] [review] patch, attempt 1 This patch adds 2 new 24-bit in 32-bits arrangements into ffmpegcolorspace (the same as the existing 2, but with the 'unused' byte at the other end of the word. This should fix the problem.
thanks, I verified it on sparc and x86, the patch works.
Thanks for testing. fixed in CVS: * gst/ffmpegcolorspace/avcodec.h: * gst/ffmpegcolorspace/gstffmpegcodecmap.c: (gst_ffmpeg_pixfmt_to_caps), (gst_ffmpeg_caps_to_pixfmt), (gst_ffmpegcsp_avpicture_fill): * gst/ffmpegcolorspace/imgconvert.c: (img_convert), (img_get_alpha_info): Add 2 new caps arrangements, for 24-bit RGB and BGR in 32-bits, but at the other end of the word. Fixes: #387073. Add some inconsequential branch hints in a couple of places.