Expected behavior of the wanted feature
As a heavy user of demuxer-max-back-bytes and demuxer-max-bytes to cache content for slow network drive, how cache current works is e.g.:
-
At middle position of the video, video is paused and cache fills up from this position of the video onward up to the limit defined.
-
When seeking to beginning of video where there isn't cache, cache starts building from there but you can see the cache is taken starting from middle position onward until cache is full is a FIFO manner. This means that now there will always be a gap from your current position which isn't cached yet until older cache near end of video becomes newer cache at the beginning of video (you may often end up caching the same portion of the video again).
It's a somewhat naive implementation IMO because caching should assume user wants to always seek from current seek position onward, even if they seek to beginning of video where it's not cached yet. Even though cache is oldest at the middle position of the video, it would often make sense to prioritize it over newer cache if it is closer to current seek position, i.e. remove cache starting from end of video where it is "farthest" from current seek position as cache fills up at beginning of video where current seek position is.
Alternative behavior of the wanted feature
Instead, offer the option to prefer keeping the cache starting from your current seek position and not simply FIFO manner. Prioritize the attempt to fill all of the cache as fast as possible from from current seek position in a continuous fashion.
Log File
No response
Sample Files
No response
Expected behavior of the wanted feature
As a heavy user of
demuxer-max-back-bytesanddemuxer-max-bytesto cache content for slow network drive, how cache current works is e.g.:At middle position of the video, video is paused and cache fills up from this position of the video onward up to the limit defined.
When seeking to beginning of video where there isn't cache, cache starts building from there but you can see the cache is taken starting from middle position onward until cache is full is a FIFO manner. This means that now there will always be a gap from your current position which isn't cached yet until older cache near end of video becomes newer cache at the beginning of video (you may often end up caching the same portion of the video again).
It's a somewhat naive implementation IMO because caching should assume user wants to always seek from current seek position onward, even if they seek to beginning of video where it's not cached yet. Even though cache is oldest at the middle position of the video, it would often make sense to prioritize it over newer cache if it is closer to current seek position, i.e. remove cache starting from end of video where it is "farthest" from current seek position as cache fills up at beginning of video where current seek position is.
Alternative behavior of the wanted feature
Instead, offer the option to prefer keeping the cache starting from your current seek position and not simply FIFO manner. Prioritize the attempt to fill all of the cache as fast as possible from from current seek position in a continuous fashion.
Log File
No response
Sample Files
No response