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

[GStreamer (GNOME Bugzilla)]

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

--- Comment #10 from Edward Hervey <bilboed at bilboed.com> ---
(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.

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