GNOME Bugzilla – Bug 768897
urisourcebin: Disable use-buffering for adaptivedemux
Last modified: 2017-01-09 13:38:07 UTC
When playbin3 is used for DASH playback, start-up buffering takes longer time than playbin2. Do we need additional queue2 element right after adaptivedemux for buffering?
Created attachment 331641 [details] [review] urisourcebin-Disable-use-buffering-for-adaptivedemux.patch
Actually, do we even need queue2 in adaptivedemux use-cases ? adaptivedemux already uses a queue2 internally iirc.
(In reply to Edward Hervey from comment #2) > Actually, do we even need queue2 in adaptivedemux use-cases ? adaptivedemux > already uses a queue2 internally iirc. I don't know why urisourcebin configures queue2 element for adaptivedemux case, as you said adaptivedemux already has it inside. I also thought that it's batter to remove queue2 element from urisourcebin in adaptivedemux use-case.
Buffering for adaptivedemux should happen after the demuxer(s) following adaptivedemux (i.e. in multiqueue), or if there is no demuxer after the parser. The queue2 buffering before adaptivedemux and inside adaptivedemux is irrelevant here.
(In reply to Sebastian Dröge (slomo) from comment #4) > Buffering for adaptivedemux should happen after the demuxer(s) following > adaptivedemux (i.e. in multiqueue), or if there is no demuxer after the > parser. Multiqueue should never be used for "buffering" in decodebin3. It's sole purpose is to cope with interleave and ensure unlinked streams don't go too far ahead (for fast stream switching). > > The queue2 buffering before adaptivedemux and inside adaptivedemux is > irrelevant here. The one inside adaptivedemux is just to ensure that we get "accurate" download speed/time (i.e. the fragment being currently requested and downloaded is not impacted by downstream blocking). We could even just use a queue for that purpose. Therefore in the playbin3 use-case we *DO* want to have the buffering done in urisourcebin, with queue2 just before each source pad. And that buffering should be handled in TIME.
(In reply to Edward Hervey from comment #5) > (In reply to Sebastian Dröge (slomo) from comment #4) > Therefore in the playbin3 use-case we *DO* want to have the buffering done > in urisourcebin, with queue2 just before each source pad. And that buffering > should be handled in TIME. In case that adaptivedemux with playbin3 were used (especially multi-period case), I think that multiqueue seems to be better element for buffering than queue2 in urisourcebin, from seamless period switching point of view. Let's assume the period advanced moment. A newly srcpad (to be exposed due to new period) is empty state at that time, and it needs buffering. However, multiqueue never empty, since the existing parsebin will be reused with multiqueueslot.
I forgot that slot (queue2) in urisourcebin is reused also, sorry :) Then, buffering by the queue2 element should be work fine. I think we can reject this issue.