[gstreamer-bugs] [Bug 578500] v4l2src caps

[GStreamer (bugzilla.gnome.org)]

If you have any questions why you received this email, please see the text at
the end of this email. Replies to this email are NOT read, please see the text
at the end of this email. You can add comments to this bug at:
  http://bugzilla.gnome.org/show_bug.cgi?id=578500

  GStreamer | gst-plugins-good | Ver: 0.10.21

Tim-Philipp Müller changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|UNCONFIRMED                 |NEEDINFO




------- Comment #8 from Tim-Philipp Müller  2009-04-15 12:52 UTC -------
(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!


-- 
See http://bugzilla.gnome.org/page.cgi?id=email.html for more info about why you received
this email, why you can't respond via email, how to stop receiving
emails (or reduce the number you receive), and how to contact someone
if you are having problems with the system.

You can add comments to this bug at http://bugzilla.gnome.org/show_bug.cgi?id=578500.