GNOME Bugzilla – Bug 578500
v4l2src caps
Last modified: 2009-04-15 15:03:23 UTC
The pipeline v4l2 --> ffmpeg --> filter rgb --> xsink triggers "could not negotiate" at v4l2 level. If xsink is defined as ximagesink rather than xvimagesink, the test works. a third test with an additionnal filter forcing yuv in v4l2 is nok. 3 tests are reported below using gst-launch, the same is observed building the pipelines in Python. Note: v4l2src publishes caps x-raw-rgb while my webcam is only able to generate x-raw-yuv or MPEG. This may be linked to the problem. - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - ProblemA/test1 - works as expected - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - $ gst-launch-0.10 v4l2src ! ffmpegcolorspace ! video/x-raw-rgb ! ximagesink - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - ProblemA/test2 - ximagesink is replaced by xvimagesink (has more caps) - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - $ gst-launch-0.10 v4l2src ! ffmpegcolorspace ! video/x-raw-rgb ! xvimagesink ERROR: Pipeline doesn't want to pause. ERROR: from element /GstPipeline:pipeline0/GstV4l2Src:v4l2src0: Could not negotiate format Additional debug info: gstbasesrc.c(2426): gst_base_src_start (): /GstPipeline:pipeline0/GstV4l2Src:v4l2src0: ... - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - ProblemA/test3 - force YUV in v4l2src - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - $ gst-launch-0.10 v4l2src ! video/x-raw-yuv,width=320,height=240 ! ffmpegcolorspace ! video/x-raw-rgb,width=320,height=240 ! xvimagesink ERROR: Pipeline doesn't want to pause. ERROR: from element /GstPipeline:pipeline0/GstV4l2Src:v4l2src0: Could not negotiate format Additional debug info: gstbasesrc.c(2426): gst_base_src_start (): /GstPipeline:pipeline0/GstV4l2Src:v4l2src0:
Created attachment 132411 [details] commands and logs with debug messages
Very verbose ... Couple of general comments: - v4l2src 0.10.10!? The current version is 0.10.14. It's usually a good idea to try something more recent before filing bugs. - just because gst-inspect-0.10 xvimagesink shows RGB caps in the pad template does not mean that xvimagesink will actually accept/support RGB caps in your particular case. It may just accept YUV caps. What it supports is queried at runtime (after the elements are linked). > gst-launch-0.10 v4l2src ! capsfilter,width=320 ! ffmpegcolorspace ! ximagesink > display a video in 1600x1200 - this syntax is not valid. You're lucky it's parsed at all. feel free to file a bug against the parser so we can throw an error here. > gst-launch-0.10 --gst-debug=v4l2src:3 v4l2src ! ffmpegcolorspace ! video/x-raw-rgb,width=320,height=240,framerate=5 ! xvimagesink > WARNING: erroneous pipeline: could not link ffmpegcsp0 to xvimagesink0 - specified like this, framerate will end up being of (int) type, which is incompatible with the (fraction) type in the xvimagesink pad template caps. Try framerate=5/1 Hope this helps.
Following the above recommendation I reformulate the report as follows: 1) the bug appears on version 0.10.21 2) The following pipeline failed in negociating caps while it exists compatible caps on each element pairs. $ gst-launch-0.10 v4l2src ! ffmpegcolorspace ! video/x-raw-rgb ! xvimagesink ... ERROR: from element /GstPipeline:pipeline0/GstV4l2Src:v4l2src0: Could not negotiate format Additional debug info: gstbasesrc.c(2426): gst_base_src_start (): /GstPipeline:pipeline0/GstV4l2Src:v4l2src0: Check your filtered caps, if any 3) Hint: the same pipeline ending with element ximagesink or fakesink in place of xvimagesink succeeds. The same is true if we force fully defined caps between ffmpeg & ximagesink as follows: $ gst-launch-0.10 --gst-debug=v4l2src:3 v4l2src ! ffmpegcolorspace ! video/x-raw-rgb,width=320,height=240,bpp=32,depth=24,endianness=4321,red_mask=65280,green_mask=16711680,blue_mask=-16777216 ! xvimagesink
*** Bug 578934 has been marked as a duplicate of this bug. ***
> Following the above recommendation I reformulate the report as follows: > ... > 2) The following pipeline failed in negociating caps while it exists compatible > caps on each element pairs. > $ gst-launch-0.10 v4l2src ! ffmpegcolorspace ! video/x-raw-rgb ! xvimagesink > ... > ERROR: from element /GstPipeline:pipeline0/GstV4l2Src:v4l2src0: Could not > negotiate format This is not a bug. It is a perfectly normal/expected failure. See my second comment above. > 3) Hint: the same pipeline ending with element ximagesink or fakesink in place > of xvimagesink succeeds. This is also as expected (ximagesink supports only RGB, and fakesink will accept anything) and does not indicate a bug in the above pipeline. > The same is true if we force fully defined caps between ffmpeg & ximagesink as > follows: > $ gst-launch-0.10 --gst-debug=v4l2src:3 v4l2src ! ffmpegcolorspace ! > video/x-raw-rgb,width=320,height=240,bpp=32,depth=24,endianness=4321,red_mask=65280,green_mask=16711680,blue_mask=-16777216 > ! xvimagesink Are you saying this pipeline with *xvimagesink* succeeds? (note that you write 'ffmpeg & ximagesink' but the pipeline actually contains an xvimagesink).
Does gst-launch videotestsrc ! video/x-raw-rgb ! xvimagesink succeed, or fail? I agree with Tim, the most likely cause is that the Xv adapter on your video card does not support RGB.
1) Jan's question: the last test succeeds with ximagesink and failed with xvimagesink 2) The failure occurs between v4l2src and ffmpegcolorspace. The same test using python and dumping bus messages shows that the other links succeed, capability v4l2src<-->ffmpefcolorspace being the last step of negociations. 3) your assumption that xvimagesink does not support rgb is improbable as in this case the failure would have occured at the link filter<-->xvimagesink 4) the last test forces a fully specified capability, the same with ximage and xvimage so that what happens upstream should not depend on the sink.
(In reply to comment #7) > 1) Jan's question: the last test succeeds with ximagesink and failed with > xvimagesink This indicates xvimagesink does not support RGB in your case. > 2) The failure occurs between v4l2src and ffmpegcolorspace. You don't know where it occurs in case of a not-negotiated error at run-time. The flow return will be passed upstream to the element driving the pipeline (here: v4l2src) and that element will post an error message. The error may have occured somewhere further down though. > The same test using python and dumping bus messages shows that the other links > succeed, capability v4l2src<-->ffmpefcolorspace being the last step of > negociations. Linking happens in NULL state based on the *theoretically possible* caps. Negotiation will happen later based on the *actually supported* caps, and will lead to a not-negotiated run-time error in case elements are linked that don't work together using the actually supported caps. > 3) your assumption that xvimagesink does not support rgb is improbable as in > this case the failure would have occured at the link filter<-->xvimagesink See comments above: linking is done based on theoretically supported caps, before xvimagesink has even had a chance to query the actually supported caps from the Xv adaptor. > 4) the last test forces a fully specified capability, the same with ximage and > xvimage so that what happens upstream should not depend on the sink. That is correct in terms of what happens upstream should not depend on the sink - but what do you think that means/implies? Please do the following: $ GST_DEBUG=xvimagesink:5 gst-launch-0.10 videotestsrc num-buffers=1 ! xvimagesink 2>dbg.log and attach dbg.log to this bug report, thanks!
Created attachment 132691 [details] run of testsrc Please find the output of the requested test
Created attachment 132700 [details] Message read from the gstbus The same pipeline built in python yields the attached messages. They show: All elements successfully reach state READY 1) filter reaches the state PAUSED (or is reaching) 2) ffmpegcolorspace, trying to go on PAUSED state yields the error: "The stream is in the wrong format"
gst_xvimagesink_get_xv_support: Generated the following caps: video/x-raw-yuv, format=(fourcc)YUY2, width=(int)[ 1, 4096 ], height=(int)[ 1, 4096 ], framerate=(fraction)[ 0/1, 2147483647/1 ]; video/x-raw-yuv, format=(fourcc)YV12, width=(int)[ 1, 4096 ], height=(int)[ 1, 4096 ], framerate=(fraction)[ 0/1, 2147483647/1 ]; video/x-raw-yuv, format=(fourcc)I420, width=(int)[ 1, 4096 ], height=(int)[ 1, 4096 ], framerate=(fraction)[ 0/1, 2147483647/1 ]; video/x-raw-yuv, format=(fourcc)UYVY, width=(int)[ 1, 4096 ], height=(int)[ 1, 4096 ], framerate=(fraction)[ 0/1, 2147483647/1 ] => no RGB support in xvimagesink in your case. (In reply to comment #10) > The same pipeline built in python yields the attached messages. > They show: > All elements successfully reach state READY Yes. > 1) filter reaches the state PAUSED (or is reaching) Yes, it reaches PAUSED state (this doesn't mean anything, this happens before data flow has started yet). > 2) ffmpegcolorspace, trying to go on PAUSED state yields the error: "The stream is in the wrong format" No. ffmpegcolorspace is already in PAUSED state at that point. And it is the source that posts this error message because it can't figure out compatible caps (because you force the ffmpegcolorspace-xvimagesink link to a format that is not actually supported). I'm going to close this as NOTABUG now. Please post to the mailing list or stop by our IRC channel on freenode if you have further questions related to this. You might also have a look at the design docs in gstreamer/docs/design, linked to from our homepage.
OK - thanks for your detailed analysis and explanations. Note that caps negotiation is really tricky and not sufficiently explained in the Application Development Manual nor in reference manual.