Closed riaqn closed 3 years ago
Dudemanguy
commented
3 years ago The script in question worked fine for me. I paused a video, hit some buttons and it always did stuff. All the vf stuff updates on runtime so it should work. I'm on wayland but that really shouldn't matter in this case.
riaqn
commented
3 years ago @Dudemanguy thank you for taking a look at this - I have attached my mpv log if that helps
Dudemanguy
commented
3 years ago I'm not sure exactly what keybindings you are pressing in that log but it appears that all you're doing is changing the pitch? That certainly worked for me (tried it on i3 for good measure). No clue what's going on at your end.
riaqn
commented
3 years ago Yes I only changed pitch. I tried i3 and the issue is the same. Have you tried to change v360 filter when the video is NOT paused? Can you notice some difference in the latency?
Dudemanguy
commented
3 years ago Can you notice some difference in the latency?
Not really. It appears to change nearly instantly for me paused or unpaused.
riaqn
commented
3 years ago So I actually noticed something interesting.
y and h. I notice that the latency is much higher when I set the resolution high(2160p), while unnoticeable when the resolution is low (108p, not 1080p). My theory is that when the video is paused, a filter change requires reload the video from the last keyframe all the way to the current frame (because the current frame of the source video is lost). Does that make sense? And is there some workaround?
Dudemanguy
commented
3 years ago It takes more work to apply a video filter on a higher resolution image than a lower resolution one, so yes it will take longer by default. That's not surprising.
Okay but looking into the code I can see why it would take longer for the video to update while paused in certain cases. If the video is unpaused, then the vf change will just appear on the next frame. However in the paused case, mpv needs to refresh the video (to apply the new filters). This is done using an exact seek to the same frame. Exact seeks can definitely be slow depending on a lot of factors (the codec, etc.). So what you are seeing is just slow exact seeks.
And is there some workaround?
Not really. Not without sacrificing precision somehow anyway. If you don't mind that, you could probably just unpause, apply the filter, and then pause it again. You'd end up on the next frame at least but it should be much faster.
riaqn
commented
3 years ago Yes that confirms my guess. And now you mentioned it, I realize why my previous workaround does not work. Previously I first change the filter, then call the frame-step command to load the next frame with new filter. Maybe I should call frame-step BEFORE changing the filter. I will try and let you know. I'm doing all this in a key callback invoked by libmpv
EDIT: ugh I still can't get it to work.
Dudemanguy
commented
3 years ago frame-step just unpauses for one frame and then pauses again. That wouldn't work. For this workaround, you would have to issue a sequence of mpv commands that set unpause, vf, and finally pause again in that order.
riaqn
commented
3 years ago Thanks! It works flawlessly now. (except the video will play for a few frames, of course). I really hope this issue could be solved sometime, tho.
Dudemanguy
commented
3 years ago The only way this could be solved is to somehow redesign the video filter chain so an exact seek is never required. Dunno the feasibility of that.
Important Information
Provide following Information:
Reproduction steps
VR-reversalkeybindings). This would cause changes to thev360ffmpeg video filter.This problem is NOT limited to the
VR-reversalscript - I wrote a python program withpython-mpvthat useslibmpvbindings to play VR videos usingv360video filter and suffer from the same issue.Expected behavior
The picture should change according to the
v360filter change instantly.Actual behavior
The picture does not change, or change only after a long delay (1 sec, for example)
Log file