Using variable frame timings externally

[qyot27]

@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?

¹

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.

[Asd-g]

FFplay / mpv probably don't have issues because they have to demux/decode the mkv file and thus they take the timestamps directly.
With avisynth the situation is different because the frames are already there and usually these applications (also avspmod, virtualdbu2) does use fps to display the frames but instead in the case of vfr they have to use _DurationNum \ _DurationDen for frame displaying.