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 704930 - Prevent matroskademux from potentially seeking a lot when the SEQUENTIAL scheduling flag is set
Prevent matroskademux from potentially seeking a lot when the SEQUENTIAL sche...
Status: RESOLVED INVALID
Product: GStreamer
Classification: Platform
Component: gst-plugins-good
git master
Other Linux
: Normal normal
: git master
Assigned To: GStreamer Maintainers
GStreamer Maintainers
Depends on:
Blocks: 704933
 
 
Reported: 2013-07-26 13:41 UTC by Sjoerd Simons
Modified: 2013-07-29 13:18 UTC
See Also:
GNOME target: ---
GNOME version: ---


Attachments
proposed patch (1.32 KB, patch)
2013-07-26 13:41 UTC, Sjoerd Simons
needs-work Details | Review

Description Sjoerd Simons 2013-07-26 13:41:32 UTC
Created attachment 250200 [details] [review]
proposed patch

Attached patch makes matroska go into push mode when upstream had the SEQUENTIAL scheduling flag set to prevent overly enthousiastic seeking.. 

This is a pretty heavy hammer though, as matroska doesn't necessarily need a lot of seeking if an index is present. But as i'm not very familiar with matroska this is simplest solution for now ;)
Comment 1 Sjoerd Simons 2013-07-26 15:09:08 UTC
Some testing shows that this is probably a too heavy hammer for now.. Seeking in webm files isn't as smooth as it was before anymore, I guess becuase it doesn't download the index anymore ? (But i haven' t looked in detail).
Comment 2 Sebastian Dröge (slomo) 2013-07-26 15:21:47 UTC
Comment on attachment 250200 [details] [review]
proposed patch

I think it's better to just run in pull mode and disable the one or two places where it jumps in the bisection search mode.
Comment 3 Sjoerd Simons 2013-07-29 13:05:12 UTC
Looking through the code, it seems to me that it will only fall back to bisection search if it can't find an index. So we have two options:
0) Keep the current code, if the user is streaming a file not really suitable for it then a lot of seeks will happen if the user 
     wants to seek..
1) Fail the seek and/or flag the file as not seekable when there is no index and we've got SEQUENTIAL scheduling mode.


I'm not sure what's better here, i'm leaning towards 0.. Streaming files that are bad for streaming will result in a bad experience, news at 11 ?
Comment 4 Tim-Philipp Müller 2013-07-29 13:13:07 UTC
I don't think we should disable seeking just because it's going to be slow. People will file bugs for that, and rightly so IMHO.
Comment 5 Sjoerd Simons 2013-07-29 13:18:10 UTC
In that case, imho this bug is invalid.. As the behaviour from matroskademux looks correct (it don't do more seeks then necessary, although it can be a lot iff they're necessary)