GNOME Bugzilla – Bug 704933
uridecodebin: allow progressive buffering with more media types
Last modified: 2014-01-24 21:42:50 UTC
Created attachment 250204 [details] [review] proposed patch uridecodebin has a whitelist of media types it will allow for use with download buffering, which means that progressive download strategies aren't available for other media types, which is somewhat restrictive (e.g. ogg and matroska video aren't allowed). Discussion on IRC showed that the main reason for this list is that some demuxer can potentially cause a huge amount of seeks. However this shouldn't be necessary given that sources can indicate that seeks should be avoided if possible, so as long as demuxer properly respect the _SEQUENTIAL gst scheduling flag this whitelist should be unnecessary.
Comment on attachment 250204 [details] [review] proposed patch Obviously correct assuming all demuxers are fixed first
For relevant demuxers that weren't whitelisted before (in base & good): ogg: fixed (bug #704929) mkv: Seems to behave correct enough already (bug #704930) for ffmpeg: avdemux: Depends on ffmpeg, i have no idea how they behave or if there is api here to tweak the behaviour? For bad, the only one where it matters seems to be mxfdemux, but i don't know that enough to decide what should happen. (Specifically some seeks around at the starts are fine, which it does, i'm not sure how it scales though). In all cases the "regression" if any here would be that demuxers trigger a seek storm at startup (especially if it jumps through the file!). Which probably annoys the server, but shouldn't break things.
Maybe we can just prevent avdemux from doing pull mode if upstream is SEQUENTIAL. That should prevent any potential problems. I would assume that avdemux will assume fast random access in pull mode. For mxfdemux, it does try to keep the interleave of the different streams at <0.5s all the time in pull mode. So could potentially seek every 0.5s for every stream inside it. Same as for avdemux, just prevent pull mode if SEQUENTIAL for now. The regression is not just a lot of seeks in the beginning, but also suboptimal behaviour during playback where they would before do something more sensible because they were running in push mode. Something more sensible could for example be to prevent seeking at all, which is still better behaviour for the user than his stream just breaking.
*** Bug 642277 has been marked as a duplicate of this bug. ***
Sjoerd, want to provide patches for the other two and then we can consider applying the uridecodebin patch? Also see bug #719615, seems to be caused by your Ogg change.
(In reply to comment #5) > Sjoerd, want to provide patches for the other two and then we can consider > applying the uridecodebin patch? Want to sure, when i'll get round to it i can't really say unfortunately. . Also note that for MXF i already mentioned that i don't know the format well enough to work out the right approach there and for avdemux I'm not so sure about the ffmpeg APIs involved. Help (or at least hints) for either would be most appreciated ;) > Also see bug #719615, seems to be caused by your Ogg change. Saw that one, havne't had the time to dig into it yet.. New year, new chances though :).. A local file really shouldn't be going into sequential mode, so the first step would be figuring out if my changes to oggdemux actually are buggy or whether it's a new symptom of an existing bug
(In reply to comment #6) > (In reply to comment #5) > > Sjoerd, want to provide patches for the other two and then we can consider > > applying the uridecodebin patch? > > Want to sure, when i'll get round to it i can't really say unfortunately. . > Also note that for MXF i already mentioned that i don't know the format well > enough to work out the right approach there and for avdemux I'm not so sure > about the ffmpeg APIs involved. Help (or at least hints) for either would be > most appreciated ;) See above :) Just disable pull mode for both if SEQUENTIAL > > Also see bug #719615, seems to be caused by your Ogg change. > > Saw that one, havne't had the time to dig into it yet.. New year, new chances > though :).. A local file really shouldn't be going into sequential mode, so > the first step would be figuring out if my changes to oggdemux actually are > buggy or whether it's a new symptom of an existing bug ack, let's track that in the other bug. Just thought you might have an idea already :)
commit 43237ad0e25ffa4adb949cbde397cd00aa9c180d Author: Sjoerd Simons <sjoerd.simons@collabora.co.uk> Date: Fri Jul 26 15:44:28 2013 +0200 uridecodebin: Drop hardcoded list of media suitable for download buffering Discussion on IRC indicated that the main reason for this list was to prevent demuxers that can trigger a lot of seeking from using progressive buffering using queue2 (which due to being seekable triggers that behaviour). However given that upstream can indicate seeks are possible but should be avoided via a scheduling query, this extra whitelisting shouldn't be necessary for well-behaved demuxers. https://bugzilla.gnome.org/show_bug.cgi?id=704933