GNOME Bugzilla – Bug 532307
filesrc: laptop mode for playback, optimise file access with posix_fadvise()
Last modified: 2018-11-03 11:14:10 UTC
totem/gstreamer could improve laptop battery time by reading ahead the movie into memory and allowing the operating system to shut down the disk/dvd drive. This is not the same as prebuffering because there is no reasom not to start playing the movie immediately. Furthermore, totem could detect if the laptop is on battery or a/c power, and do this only in battery mode.
Are you planning to work on this? We don't normally keep enhancement bugs open unless someone is actively planning to work on a project. Otherwise, we get a huge list of enhancement requests that nobody cares about that makes it more difficult to see real bugs in the bug list.
Also, doesn't/shouldn't the OS do this kind of read-ahead caching automatically really?
David, I'm reporting this from the user's perspective. I don't have the expertise in C, Gnome nor GStreamer to do any work on this myself. What would be the better place to post this? If somebody wants to trade work on this with some work in Java, let me know :-) Tim, from my observations, the OS doesn't do this. Should it? The application can have some idea what it is going to do with resources (files) it opens, but I don't know how an OS could generally make a good guess for all possible applications and usage patterns.
Created attachment 110668 [details] [review] queue_load_burst.diff I think you can do this with something like this. with a load-burst mode on a queue: * block the sink_pad when the queue is full. * unblock the sinkpad when the queue is empty. but of course the application (totem) needs to set the border parameters to some good values to make any use of it.
Created attachment 110669 [details] [review] queue_load_burst.diff update, remove some useless comments.
Something like bursting data out of queues seems like a good idea but for playbin2 it needs to go into multiqueue or something. There is a tradeoff here because you would now end up buffering more data in memory instead of streaming it from disk.
I believe we should leave that to the OS. But we might be able to do more on filesrc. Currently if one would use mmap and sequential=TRUE we would do madvise (mmapregion, size, MADV_SEQUENTIAL) In the same way we would do posix_fadvise () for the non-mmap case.
Created attachment 182100 [details] [review] use posix_fadvice in non mmap case Its hard to meassure the effect of this, but al least it seems to work.
It think this is related to bug #634687. E.g. just setting POSIX_FADV_NOREUSE unconditionaly is not the right thing to do. For a videoeditor it might be beneficial if the filecontent stays in memory. For one-shot playback we can immediately forget it though.
Yes, if this is ever implemented it should be controlled with something like the operation hints.
What should we do about the queue/queue2/multiqueue bursty modes?
Arguably the posix_fadvise() stuff should be coming from the element that does the data access. qtdemux will have a different pattern of data access than streaming formats. Demuxers know they're currently scanning (throw-away data) or in streaming mode. So really what we need is a way for demuxers to signal this to upstream elements such as filesrc. For simple things it could be done with a pull_range() full with additional flags. This could also be interesting for a souphttpsrc ! downloadbuffer ! demuxer style scenario, the demuxer could advertise ranges it will need in advance. Making good use of that is a different matter of course.
-- 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/13.