After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 704933 - uridecodebin: allow progressive buffering with more media types
uridecodebin: allow progressive buffering with more media types
Status: RESOLVED FIXED
Product: GStreamer
Classification: Platform
Component: gst-plugins-base
git master
Other Linux
: Low enhancement
: 1.3.1
Assigned To: GStreamer Maintainers
GStreamer Maintainers
playback
: 642277 (view as bug list)
Depends on: 704927 704929 704930 722934 722935
Blocks:
 
 
Reported: 2013-07-26 14:03 UTC by Sjoerd Simons
Modified: 2014-01-24 21:42 UTC
See Also:
GNOME target: ---
GNOME version: ---


Attachments
proposed patch (3.56 KB, patch)
2013-07-26 14:03 UTC, Sjoerd Simons
accepted-commit_now Details | Review

Description Sjoerd Simons 2013-07-26 14:03:58 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 1 Sebastian Dröge (slomo) 2013-07-26 15:05:48 UTC
Comment on attachment 250204 [details] [review]
proposed patch

Obviously correct assuming all demuxers are fixed first
Comment 2 Sjoerd Simons 2013-07-29 14:35:03 UTC
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.
Comment 3 Sebastian Dröge (slomo) 2013-07-30 08:47:40 UTC
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.
Comment 4 Sebastian Dröge (slomo) 2013-08-16 11:00:02 UTC
*** Bug 642277 has been marked as a duplicate of this bug. ***
Comment 5 Sebastian Dröge (slomo) 2014-01-06 09:28:19 UTC
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.
Comment 6 Sjoerd Simons 2014-01-06 09:50:28 UTC
(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
Comment 7 Sebastian Dröge (slomo) 2014-01-06 09:52:24 UTC
(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 :)
Comment 8 Sjoerd Simons 2014-01-24 21:37:05 UTC
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