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 679708 - playbin: read ahead files, better support for network shares and other slow inputs
playbin: read ahead files, better support for network shares and other slow i...
Status: RESOLVED OBSOLETE
Product: GStreamer
Classification: Platform
Component: gst-plugins-base
unspecified
Other Linux
: Normal enhancement
: git master
Assigned To: GStreamer Maintainers
GStreamer Maintainers
: 657115 686598 (view as bug list)
Depends on:
Blocks:
 
 
Reported: 2012-07-10 20:32 UTC by Andrea Corbellini
Modified: 2018-11-03 11:21 UTC
See Also:
GNOME target: ---
GNOME version: ---


Attachments
filesrc: add BANDWIDTH_LIMITED flag to scheduling query if file is on a remote filesystem (5.41 KB, patch)
2013-07-22 22:42 UTC, Tim-Philipp Müller
needs-work Details | Review

Description Andrea Corbellini 2012-07-10 20:32:24 UTC
Playing files and devices located in not-so-low-latency locations with Totem currently is not always optimal. Examples of such locations include slow DVDs, SSH shares and NBD devices.

When playing a movie from those locations I can observe the following:

* the first N minutes of the movie is played perfectly well;
* after those N minutes, the movie stops for a while;
* the movie continues again for N minutes;
* the movie re-stops and so on...

It seems to me (though I might be wrong) that Totem fetches only when its read buffer is exhausted. To play files reliably, Totem should instead continuously fill the buffer, trying to always keep it at a reasonable size.
Comment 1 Bastien Nocera 2012-07-11 23:57:49 UTC
This isn't Totem's job though, this is GStreamer's job, as it is the ones that actually reads from those devices or files. Reassigning there.
Comment 2 Tim-Philipp Müller 2012-07-12 08:58:03 UTC
> It seems to me (though I might be wrong) that Totem fetches only when its read
> buffer is exhausted. To play files reliably, Totem should instead continuously
> fill the buffer, trying to always keep it at a reasonable size.

One would need to investigate a specific case here, but that's not really how it should be working. There should also be some buffering in the lower layers. I can confirm that the behaviour with network shares in pull mode is not ideal though, I think it's just a case of not enough buffering then.
Comment 3 Tim-Philipp Müller 2012-09-28 09:53:15 UTC
*** Bug 657115 has been marked as a duplicate of this bug. ***
Comment 4 Tim-Philipp Müller 2013-06-12 22:18:57 UTC
*** Bug 686598 has been marked as a duplicate of this bug. ***
Comment 5 Edward Hervey 2013-06-13 06:04:13 UTC
Just to point out that queue2 is most likely *not* used for the various cases mentionned above and in duplicated bugs (assuming all those are mounted locally) since it's only activated in uridecodebin (and therefore playbin) for some "remote" URI.

Maybe we should activate it for all sources ?
Comment 6 Sebastian Dröge (slomo) 2013-06-13 06:31:49 UTC
At least for all non-live sources, yes, sounds like a plan. Probably with different settings depending on the type of source.
Comment 7 Edward Hervey 2013-06-13 07:02:33 UTC
We also want to make sure it works efficiently in src-pull/sink-pull mode with those sources, but then it could do some read-ahead.

I also wonder how efficient it would be with downstream elements that do pull_range with a pre-allocated (and configured) GstBuffer (like qtdemux) ?
 We'd end up doing double-copies... unless we use a mmap allocator (but then there's no guarantee the underlying data would be available quickly ?)
Comment 8 Tim-Philipp Müller 2013-07-22 22:42:09 UTC
Created attachment 249848 [details] [review]
filesrc: add BANDWIDTH_LIMITED flag to scheduling query if file is on a remote filesystem

Not sure we really want to force demuxers and parsers in
playbin/uridecodebin to operate in push mode in this case.
Maybe we need yet another flag. Shuoldn't do this before
making sure push mode works flawlessy for all major types
of files (at least mkv has some issues, might be bad timestamping
or so)
Comment 9 Sebastian Dröge (slomo) 2013-07-23 07:31:16 UTC
Review of attachment 249848 [details] [review]:

::: plugins/elements/gstfilesrc.c
@@ +508,3 @@
+#else
+  {
+    GST_FIXME_OBJECT (src, "Don't know how to check for remote filesystem");

On Windows you could probably check for the path starting with \\
Comment 10 Sebastian Dröge (slomo) 2013-07-23 07:39:03 UTC
(In reply to comment #8)
> Created an attachment (id=249848) [details] [review]
> filesrc: add BANDWIDTH_LIMITED flag to scheduling query if file is on a remote
> filesystem
> 
> Not sure we really want to force demuxers and parsers in
> playbin/uridecodebin to operate in push mode in this case.
> Maybe we need yet another flag.

What exactly should they do? And BANDWIDTH_LIMITED is not about pull-mode, it's just enabling the buffering in queue2 (which makes demuxers run in pull mode of course).
Comment 11 Tim-Philipp Müller 2013-07-23 09:22:56 UTC
I'm not sure if demuxers + parsers should use a suboptimal access pattern in this case. Network filesystems are usually on a local network and reasonably fast. It might be better to add some buffering when operating in pull mode, either in general or in some cases.
Comment 12 Bastien Nocera 2013-07-25 09:04:53 UTC
(In reply to comment #11)
> I'm not sure if demuxers + parsers should use a suboptimal access pattern in
> this case. Network filesystems are usually on a local network and reasonably
> fast.

The problem is when the data rate of the stream nearly matches that of the network. For testing, you could set up a webdav client, and use the rate limiting feature of Apache:
https://git.gnome.org/browse/totem/tree/browser-plugin/tests/launch-web-server.sh#n109

Seeks might also be much more expensive than reads. It's possible that the original problem is fixed now that gvfs and gvfs-smb don't crash when giosrc is used, and that I've reverted the Totem code that forced it to use the local file source instead of giosrc (only in master right now, but I'll make sure it's in 3.10 as well if we end up not shipping the new UI).
Comment 13 GStreamer system administrator 2018-11-03 11:21:48 UTC
-- GitLab Migration Automatic Message --

This bug has been migrated to freedesktop.org's GitLab instance and has been closed from further activity.

You can subscribe and participate further through the new bug through this link to our GitLab instance: https://gitlab.freedesktop.org/gstreamer/gst-plugins-base/issues/69.