GNOME Bugzilla – Bug 796000
adaptivedemux: Re-use pads (streams-aware)
Last modified: 2018-05-11 06:26:40 UTC
slot's caps comparison with pending pad's caps cannot guarantee that they are fully compatible ones. For example, in case of hls streaming, caps for both video/audio streams can be "video/mpegts". So, newly exposed pads by adaptivedemux can be inappropriately linked with an existing slot. (e.g., link video stream's pad to audio stream's slot)
Moved from Bug #775132. See also Bug #776672
In Bug #775132, I proposed mapping new/old streams using Caps/Tag/StreamType/StreamFlags. But it seems to insufficient approach and there might be still ambiguity. I thing new API for mapping two streams' continuity can be useful for that. maybe gst_stream_set_peer_stream_id(const gchar* stream_id) ? When we add expose-all mode in decodebin3, potentially the same ambiguity could be made.
Created attachment 371897 [details] [review] urisourcebin: Link pending pad to slot by using GstStream API
This stream has two audio track and current urisourcebin impl. can cause invalid stream mapping. http://bitdash-a.akamaihd.net/content/sintel/hls/playlist.m3u8 Almost always, video is disappeared with bit rate switching by hlsdemux.
Why can't adaptive demuxers do that themselves ? (i.e. figure out which pad to re-use)
(In reply to Edward Hervey from comment #5) > Why can't adaptive demuxers do that themselves ? (i.e. figure out which pad > to re-use) That idea looks great (same approach with Bug 684790), and I guess that will bring very big change in adaptivedemux though.
It might not be *that* much change in adaptivedemux. In general I think it should really be up to "stream providers" (demuxer, adaptive demuxers,...) to figure out which stream/pad can be re-used. They have the most information and can make the most informed decision. Trying to handle this from the outside is a "best effort that won't always work". Shall we close this bug or rename it to add this feature in adaptivedemux ?
(In reply to Edward Hervey from comment #7) > It might not be *that* much change in adaptivedemux. > > In general I think it should really be up to "stream providers" (demuxer, > adaptive demuxers,...) to figure out which stream/pad can be re-used. They > have the most information and can make the most informed decision. Trying to > handle this from the outside is a "best effort that won't always work". > > Shall we close this bug or rename it to add this feature in adaptivedemux ? OK. let's drop this urisourcebin patch :) I prefer to rename btw.
Renamed title. Of course this would only be in streams-aware context (so we don't break legacy usage)
oh... I already proposed this reusing approach at Bug #777213. This bug seems to duplication of it. Can I follow up this discussion at Bug #777213 ? (and close this bug)
Well spotted :) Should the title of Bug #777213 be renamed (to be more generic) ? Also this bug depends on Bug #775132, should #777213 also depend on that ? *** This bug has been marked as a duplicate of bug 777213 ***
Bug #775132 is also block of #Bug #777213. I changed the name to be more generic.