[Bug 778163] parsebin: Don't expose endpad if corresponding decoder is not supported

GStreamer (GNOME Bugzilla) bugzilla at gnome.org
Tue Feb 14 10:54:52 UTC 2017


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

--- Comment #11 from HoonHee Lee <hoonh83.lee at gmail.com> ---

(In reply to Edward Hervey from comment #10)
> (In reply to Olivier CrĂȘte from comment #6)
> > Something like: ((IS_FACTORY (x) && (gst_element_factory_list_is_type(x,
> > .._DECODER) || gst_element_factory_list_is_type(x, .._SINK))) ||
> > (IS_ELEMENT(x) && GST_ELEMENT_IS_SINK(x)))
> 
>   You would need to instantiate the sink (potentially with the correct
> device id) to know exactly what the sink supports in terms of caps.
> 
> (In reply to HoonHee Lee from comment #9)
> > I have one more question.
> > In latest version, parsebin emits "autoplug-factories" to decodebin3 in
> > analyze_new_pad () but, decodebin3 does not add callback function likes
> > "g_signal_connect (parsebin, "autoplug-factories"...)".
> > Thus, decodebin3 can not response the "autoplug-factories" signal and then
> > can not emit "autoplug-factories" signal to playbin3.
> >  
> > Is there any intention not to implement "autoplug-factories" signal between
> > decodebin3 and playbin3? or just missed to implement?
> 
>   The reason this was removed or deactivated is because we want to use a
> more correct/streamlined signal for this (as mentionned in the review
> signals bug).
> 
>   One idea could be the following:
>   1) parsebin always exposes everything (regardless of decoder being present
> or not)
>   2) streams go through multiqueue
>   3) When deciding whether to use a decoder or not (downstream of
> multiqueue), fire the new signal.
> 
>   This signal would provide:
>     * The GstStream object
>     * The list of decoders (if any) that decodebin3 will try to link
> 
>   The callback can return:
>     * The re-sorted list of decoders (potentially with new elements in it)
>     * Whether the stream should:
>       1) Be exposed as-is (without any decoder)
>       2) Be discarded (never exposed, i.e. blacklisted, until the stream
> changed)
>       3) Try to plug in the decoders in the provided order.
> 
>   This is the same thing as what was done previously. But just with one
> signal instead of 4.
> 
>   This should solve your problem as far as I understand.

Hello Edward Hervey
Thanks for your detailed guide.
I understood most of things that you suggested.

For 2), You want to maintain the GstStream which is not exposed in current
collection? Or Removing the GstStream in current collection and posting it?
I think it is important to show either all tracks or supported tracks to player
side.

Please feedback about my question.
Thanks.

Thanks.

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


More information about the gstreamer-bugs mailing list