[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 #15 from Edward Hervey <bilboed at bilboed.com> ---
(In reply to HoonHee Lee from comment #14)
> 1) If we have a stream that contains 1-video and 2-audios and 1st audio
> stream is not available(not supported decoder or in blacklist).
> How about changing automatically from 1st audio to 2nd audio when initial
> pre-rolling? I think that changing automatically is more better instead of
> mute sound.

  For this use-case, the way I see it happening should be:
  * The 1st audio stream is initially selected automatically
  * When that 1st audio stream arrives downstream of multiqueue, decodebin3
fires the 'stream-handling' signal (or whatever we'll call it) with no
available decoder factories
  * playbin3 can't handle it, returns that it does not want to have it exposed
  * decodebin3 marks it blacklisted for now, and re-triggers the initial
selection (update_requested_selection) which would avoid using that stream (in
the same way that we sort by SELECT/UNSELECT streams) => The 2nd audio stream
ends up being selected instead.
  * decodebin3 triggers the stream switch update (it sees the current stream it
wanted to expose isn't selected, and switches)

  That would solve the issue of exposing a stream that can't be handled

  It leaves the issue of:
  * What to do if the app decide to select that stream. How do we notify the
user/app ? Do we still expose it if it was requested ?

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