options: default to --prefetch-playlist=yes #15378
Conversation
|
Can we reword the description somehow to make it easier to understand? Particularly that it merely opens a demuxer thread for the next file and doesn't actually prefill cache for the next file. If even contributors like @na-na-hi don't understand what the option actually does, regular users have no hope of understanding the text. |
|
It was much more confusing before and I didn't understand it either, see d4bf179. I explicitly wrote "This does not prefill the cache with the video data of the next URL." at the beginning, so how would you specify it further? |
|
Perhaps explaining the use case when you want to use it would help? "This is most useful when reading small files where a significant portion of the load time is spent creating a new demuxer thread" or something to that effect. |
DOCS/man/options.rst
Outdated
| file played. | ||
| If ``--demuxer`` and related probing options are changed in the time window | ||
| between the start of prefetching and the playback of the next file, the old | ||
| values are used. |
There was a problem hiding this comment.
So it breaks all format specific options and profiles? Kind of defeats the purpose of extension profiles, no?
There was a problem hiding this comment.
Well that's not purpose of extension profiles, they were what was used before implementing conditional profiles and then were deprecated. In conditional profiles this already doesn't work because they are evaluted too late, it seems to work for the first file only if you match by path, and this still works with --prefetch-playlist which doesn't affect the first file.
But yes, setting demuxer options in extension profiles is a reason for not enabling it by default globally. I think it is worth the trade-off for images because you navigate between then much more, and yes the next file could be a video, defaults can't be perfect, but navigating between images faster should be preferable for the majority of users. A note about it can be added in the image profile.
There was a problem hiding this comment.
Also I will look into discarding prefetched data if demuxer options changed, it already does it stream-open-filename changed, so it should be possible.
There is no known issue with --prefetch-playlist and file-local-options. It works just fine with them, and people have been using it since 2017 and haven't reported related issues. So ease the warnings to not scare users away from using a useful option. Also when --prefetch-playlist was implemented it also prefetched the stream cache until 559a400 removed it - see mpv-player#6753. So if such issues ever existed, they were fixed by not making it prefill the stream cache. Now it doesn't do much, it only opens a connection to the next file, and the cache of the next video starts empty.
guidocella
changed the title
guidocella
force-pushed
the
prefetch-docs
branch
from
ef26379 to
50f22d3
Compare
|
Repurposed the PR to change the default to |
|
Download the artifacts for this pull request: |
--prefetch-playlist improves performance by starting to read the next file in the last second or playback or while viewing an image. This is obviously noticeable with playlists of direct media URLs, but can also make a difference on local slow hardware, mainly large (in bytes) images on HDDs. You can easily see the difference with 10+ MB images. Since e7a2536 and 24db17d fixed niche issues, and it's known not to cause other issues by users using since 2017 who haven't reported issues, enable it by default to improve performance. The only flaw is that it doesn't support ytdl-hook URLs, so in Youtube playlist, it does a web request with ffmpeg that is doomed to fail since the last second of playback, though this doesn't cause practical disadvantages.
guidocella
force-pushed
the
prefetch-docs
branch
from
50f22d3 to
f88faee
Compare
There is no known issue with --prefetch-playlist and file-local-options. It works just fine with them, and people have been using it since 2017 and haven't reported related issues. So ease the warnings to not scare users away from using a useful option.
Also when --prefetch-playlist was implemented it also prefetched the stream cache until 559a400 removed it - see #6753. So if such issues ever existed, they were fixed by not making it prefill the stream cache. Now it doesn't do much, it only opens a connection to the next file, and the cache of the next video starts empty.