You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
What I've managed to do is use the contents of _DurationNum and _DurationDen frame properties to make the FFmpeg AviSynth demuxer VFR-aware. But as I note in the patch's commit message, it's fragile (particularly the assumptions to try and make the start timing line up better with the original file), and seeking is broken when vfr-awareness is turned on. The VFR MKV file used as a test sample, on the other hand, can seek perfectly fine in FFplay or mpv.
Is this something where it's probably just a matter of not using the FFmpeg-side functionality to its fullest, or like I note¹ in the commit message, will it require something more robust on our end?
¹
It occurs to me that comparing the seek behavior with mkv (or any other container capable of variable frame durations) is potentially like comparing apples and oranges because those containers have additional structures (e.g. an index) that handles some of the load of making sure seeking can be done accurately by their corresponding demuxers. This would mean that such an index would need to be present for the script to actually get functional seeking in vfr mode: whether by it being in the frame properties or - at worst - exposed by the AviSynth+ core itself through an api function or entirely new structure, in which case vfr-mode seeking would have to be shelved until those things appear.
reacted with thumbs up emoji reacted with thumbs down emoji reacted with laugh emoji reacted with hooray emoji reacted with confused emoji reacted with heart emoji reacted with rocket emoji reacted with eyes emoji
-
@pinterf @Asd-g
For reference,
https://github.com/qyot27/FFmpeg/commits/avs_vfrtest/
https://forum.doom9.org/showpost.php?p=2007820&postcount=2871
What I've managed to do is use the contents of _DurationNum and _DurationDen frame properties to make the FFmpeg AviSynth demuxer VFR-aware. But as I note in the patch's commit message, it's fragile (particularly the assumptions to try and make the start timing line up better with the original file), and seeking is broken when vfr-awareness is turned on. The VFR MKV file used as a test sample, on the other hand, can seek perfectly fine in FFplay or mpv.
Is this something where it's probably just a matter of not using the FFmpeg-side functionality to its fullest, or like I note¹ in the commit message, will it require something more robust on our end?
¹
Beta Was this translation helpful? Give feedback.
All reactions