GNOME Bugzilla – Bug 679708
playbin: read ahead files, better support for network shares and other slow inputs
Last modified: 2018-11-03 11:21:48 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.
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.
> 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.
*** Bug 657115 has been marked as a duplicate of this bug. ***
*** Bug 686598 has been marked as a duplicate of this bug. ***
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 ?
At least for all non-live sources, yes, sounds like a plan. Probably with different settings depending on the type of source.
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 ?)
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)
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 \\
(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).
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.
(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).
-- 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.