[Bug 757376] playbin: have-context and need-context messages are lost

[GStreamer (GNOME Bugzilla)]

https://bugzilla.gnome.org/show_bug.cgi?id=757376

--- Comment #8 from Matthew Waters <ystreet00 at gmail.com> ---
(In reply to Nicolas Dufresne (stormer) from comment #7)
> The application context shall be preferred. Because the decodebin pipelines
> are constructed src to sink, unlike the static pipeline where the state
> change is sink to src, both ways need to be supported. So one or the other
> should make little difference, if anything "special is needed" with the
> context, the application will provide one.

If a bin already has a context set, the element to add will receive its
context.  Thus the requirement that the application context is preferred holds.

> It's unfortunate though, since it would seem that the way we plug the
> decoders these days introduce side effect. A question, is the decoder added
> to the pipeline when it's state is changed to READY ? I'm a bit out of date
> maybe, but the mechanism in place for context sharing would only work if it
> was. Other then that, there is active work to implement the query proxying
> in playbin, maybe that work will help a little. It will let an unlinked
> decoder query the sink context I believe.

Decodebin adds the decoder to the decodebin, sets the target pad (so the
context query is forwarded with autplug-query) and sets the decoder to PAUSED
(from NULL).

Despite this, an element has always needed to deal with context replacements in
GstElement::set_context.

As mentioned by the commit message in
http://cgit.freedesktop.org/gstreamer/gstreamer/commit/?id=d5ded1588920c4471eefe055d09095d9e5e989b5
if you want the context to be propagated between the context query and the
context messages, you have to manually call gst_element_set_context upon
successfully performing a context query.

-- 
You are receiving this mail because:
You are the QA Contact for the bug.
You are the assignee for the bug.