Open porg opened 1 year ago
Can you try git master? I believe https://github.com/mpv-player/mpv/commit/296d40dc6f38401085d005bb4627f8afff46b041 fixed what you are describing; well at least the subtitle part of that.
https://mpv.io/installation/#:~:text=macOS
Sorry I do not own a mac. You will have to compile it from source yourself or maybe use homebrew to fetch git head if it's possible.
I will wait for the next stable build and give you feedback on it then.
I managed to build mpv 0.35.0-531-gcf0373e15b
(from master as of now) myself with these instructions (were for M1 chip, but procedure was the same on my IntelMac).
I must have misunderstood what you're experiencing then. Maybe it has something to do with #10176 (separate thing).
$duration
and $percent-pos
should be repainted too.Okay thanks I understand this better I think. It's definitely specific to VFR and the other stuff was just vaguely similar but not actually related.
Great that the problem is now better understood.
What's your estimate? Is this principally do-able? Or are there some big obstacles in that regard in the architecture of mpv?
I'm not really sure honestly. This is a bit out of my wheelhouse.
Who in the mpv team could estimate the feasibility of this?
The subtitle "issue" is completely unrelated to VFR, and the behavior should not be changed (it may not even be possible for mpv to make this change, I suspect this concept would be too deeply integrated in libass).
ASS subtitles (which all text subs get converted to internally) are expected to start and end in sync with video frames.
The format uses 2 decimal precision for timestamps, which is not enough to precisely point to the very start/end of a frame.
Video sync is very important so that subtitles do not bleed across scene changes, and allows for transform (\t) tags to animate in sync with the video. Therefore subtitles should appear and disappear in sync with video frames.
Making any change to how subtitles start and end will break millions of files.
A better solution would for you to not hold a frame for 10 seconds through timestamps, but keep the video CFR and insert "null" frames. Since you're re-encoding anyway, skip your decimation filter and allow a higher i-frame interval.
It is annoying that osd updates have the same limitation, as they're also subtitles.
How uosc deals with it is by telling users to use video-sync=display-resample
. That may fix your issue.
As I understand it, it allows scripts to force a repaint of their own subtitle overlay mid-frame. I don't know how osd status messages are handled internally, it's possible that they only update each frame.
did video-sync=display-resample
work around this problem? to me this sounds like a general problem how we render and update.
a test video file would be nice too.
I had already started with a meaningful test video plus test subtitle file, but not finished this back then.
Will post it here as soon as I get time, possibly will get to it over the new year holidays.
@porg any progress on the test file?
Great to read your re-inquiry. Motivates me to deliver the test material.
End of march is the next realistic chance that I will get to this. I put a reminder into my calendar.
Reproduction
ON SCREEN DISPLAY (OSD): Playback-time stuck during still frame
In my
~/.config/mpv/mpv.conf
I customized my OSD to display also frame numbers and FPS.osd-status-msg=${playback-time/full} / ${duration} (${percent-pos}%)\nFrame: ${estimated-frame-number} / ${estimated-frame-count} — FPS: ${estimated-vf-fps} / ${container-fps}\n
$estimated-frame-number
remains still during the still frame. That's correct obviously.$duration
and$percent-pos
remain stuck.SUBTITLES which start or end during still frame are not accounted for
My Source Material & Use Case
ffmpeg
video filter-vf mpdecimate
to create variable frame rate videos from this.ffmpeg -i screen-recording.mov -movflags faststart -c:a copy -c:v libx264 -preset veryslow -vf mpdecimate -vsync vfr -crf 18 screen-recording.mp4
Environment