search

mpv-player / mpv

🎥 Command line video player
https://mpv.io
Other
28.2k stars 2.89k forks source link

frame-back-step stops working after a few frames (when opening smb:// url) #13649

Open pjotrek-b opened 7 months ago

pjotrek-b commented 7 months ago

Important Information

Provide following Information:

Reproduction steps

Open a videofile from a Samba (CIFS) share, using the "smb://" URL prefix: $ mpv --no-config smb://guest@hostname/share/folder

  1. Seek to a position far enough, so you could frame-seek backwards for at least a minute or so.

  2. Now use "," to seek backwards 1 frame: Hold "," until the video stops rewinding

  3. Now neither "," nor "." has any effect anymore. The player seems "stuck".

  4. However, pressing left/right arrow keys, or seeking manually (clicking) to any other position works.

  5. 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

pjotrek-b commented 7 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:

pjotrek-b commented 7 months ago

Sorry: forgot the logfile! smb_frameseek_stuck.log

pjotrek-b commented 7 months ago

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.

pjotrek-b commented 7 months ago

No cache before playback position: frame-back-step will get stuck: mpv-frameseekback_stuck-no_precache

Some cache left before the playback position: Works fine! mpv-frameseekback_stuck-precache

KaFu74 commented 7 months ago

Maybe this setting will help? --demuxer-max-back-bytes= https://mpv.io/manual/stable/#options-demuxer-max-back-bytes

pjotrek-b commented 7 months ago

@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".

MarjaE2 commented 3 months ago

The same bug occurs with local files, though.