(Go: >> BACK << -|- >> HOME <<)
Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

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

Open
pjotrek-b opened this issue Mar 6, 2024 · 6 comments
Open

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

pjotrek-b opened this issue Mar 6, 2024 · 6 comments
Labels
os:linux

Comments

@pjotrek-b
Copy link

Important Information

Provide following Information:

  • mpv version: v0.37.0-484-g665a472098 (built Debian-package with libsmbclient support manually enabled)
  • Linux Distribution and Version: Xubuntu 20.04.6 (64bit)
  • Source of the mpv binary: mpv-build (github)
  • If known which version of mpv introduced the problem: already in v0.32.0-1ubuntu1
  • Window Manager and version: X11

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
Copy link
Author

I think I found the reason:
The cache settings matter. 🥳
(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. 😞

@pjotrek-b
Copy link
Author

Sorry: forgot the logfile!
smb_frameseek_stuck.log

@pjotrek-b
Copy link
Author

We've found the pattern! 😄
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
Copy link
Author

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
Copy link
KaFu74 commented Mar 19, 2024

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

@pjotrek-b
Copy link
Author

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

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
os:linux
Projects
None yet
Milestone
No milestone
Development

No branches or pull requests
2 participants
@pjotrek-b @KaFu74