Open pjotrek-b opened 8 months ago
I think I found the reason: The cache settings matter. :partying_face: (but they don't fix it)
Because my original issue was with an SD VHS recording as FFV1/PCM/MKV (720x576@25i, gopsize=1), but the synthetic ffmpeg-testsrc
sample worked flawlessly - and displayed more seconds in cache (!).
It seems that the player runs out of cache (drops to 0/0
, shown in the terminal) and shows the following line - but without any action - in the logs (for each keypress):
[cplayer] Run command: frame-back-step, flags=73, args=[]
So I tried setting my cache values higher in /etc/mpv/mpv.conf
, copy-pasting the suggestion from man mpv
:
[big-cache]
cache=yes
demuxer-max-bytes=512MiB
demuxer-readahead-secs=20
Higher demuxer cache values don't completely fix the freeze, but it seems that when waiting for the cache to have pre-loaded, frame-back-step works "longer".
But: With all cache options, sooner or later it gets stuck on frame-back-step
. :disappointed:
Sorry: forgot the logfile! smb_frameseek_stuck.log
We've found the pattern! :smile: My colleague saw that the line displaying the cache in relationship to the playback position was an indicator:
If there is no cache before the playback position: freeze problem. If there is cache before the playback position: works!
I've consulted man mpv
and for the time being setting "demuxer-seekable-cache=no" seems to work for us.
Is there any option to "force" starting to cache data before the playback position?
As far as I understood the docs, "demuxer-max-back-bytes" only keeps existing cache before the playback position - but cannot be used to pre-read it when jumping directly to a certain offset.
No cache before playback position: frame-back-step will get stuck:
Some cache left before the playback position: Works fine!
Maybe this setting will help?
--demuxer-max-back-bytes=
@KaFu74 : Was hoping the same, but unfortunately not.
Quote from man mpv
:
"This controls how much past data the demuxer is allowed to preserve."
Since demuxer-max-back-bytes only allows to keep bytes cached - but does not initialize loading the cache "starting before the current playback position".
The same bug occurs with local files, though.
Important Information
Provide following Information:
libsmbclient
support manually enabled)Reproduction steps
Open a videofile from a Samba (CIFS) share, using the "smb://" URL prefix:
$ mpv --no-config smb://guest@hostname/share/folder
Seek to a position far enough, so you could frame-seek backwards for at least a minute or so.
Now use "," to seek backwards 1 frame: Hold "," until the video stops rewinding
Now neither "," nor "." has any effect anymore. The player seems "stuck".
However, pressing left/right arrow keys, or seeking manually (clicking) to any other position works.
After this "re-seeking", frame-seeking (,.) works again.
Until seeking back again (=repeat step 2).
Expected behavior
The same as opening the same video file directly from the local filesystem: Use frame-seeking back-and-forth without the player getting stuck.
Actual behavior
The player gets stuck, so that frame-seeking seems disabled/broken - until re-setting the player's playback position in any other way (keyboard or GUI).
Sample files
I've generated one (i-frames only to avoid GOP causing the issue), using
ffmpeg
: ffmpeg -f lavfi -i testsrc=size=1920x1080 -t 300 -r 25 -pix_fmt yuv422p10le -c:v ffv1 -level 3 -an test.mkv