The decision was based on incorrect assumption that this option
"only opens a connection to the next file, and the cache of the next
video starts empty", a prequisite of the assumption that this option
has no major drawbacks, including incurring unwanted network traffic.
The assumption can be proven incorrect by testing with networked files
in playlist. With log level set to debug, the following lines are shown
after the next file is prefetched, while monitoring of network traffic
shows constant network traffic after the currect file cache reading
reaches EOF, which triggers prefetching:
[cplayer] Opening done: <url to prefetched file>
[lavf] select track 0
[lavf] select track 1
[lavf] EOF reached.
[ffmpeg] AVIOContext: Statistics: 37139315 bytes read, 0 seeks
It is clear that saying "there is nothing to prefetch after the first
frame" is a complete lie: in fact, it fetches the whole file to the
demuxer cache, according to the demuxer cache settings. And when the next
file plays, it also starts with full cache rather than "an empty cache".
In fact, what this option really does is written in
556e204a11: --prefetch-playlist calls
demux_start_prefetch() which does the same thing as the
--demuxer-cache-wait option:
"Before starting playback, read data until either the end of the file was
reached, or the demuxer cache has reached maximum capacity."
This is exactly what is happening with the testing. This option will indeed
cause large amount of unwanted network traffic - a concern raised in the
discussion concerning this option.
Revert this commit since it's based on incorrect assumption, and subsequent
incorrect conclusions derived from it in the subsequent discussions.
This reverts commit 978b219889.
nanahi
c301667515