Direct Copy output converts constant video frame rates to variable frame rate.

[tomfank]

I've just become aware of a glitch when loading an mp4 file with a constant video frame rate and doing a direct copy (video) output after trimming the file.  The output file shows a variable video frame rate (as measured by MediaInfo utility) with a significant span between the slowest and fastest frame (e.g. as much as ~50 fps with the native clip having a 60 fps constant frame rate).  The overall average variable frame rate is very close to the original constant frame rate, however (e.g. like 59.570 fps vs a 60 fps native video frame rate).

This happens with the two Mp4 variant muxers, but NOT with the .MKV output file format.  If the native file requires re-encoding when output after editing, the mp4 muxers correctly retain the original video's constant frame rate. This has been in prior WIndows versions for some time, but I just became aware of it.

Is this a bug that can be fixed?

[eumagga0x2a]

Probably this, so you might get a single frame or a couple of frames with half the duration depending on editing steps. Basically completely harmless as long as the frame rate denominator doesn't get too high (and <= 120 should be okay with most hardware decoders and absolutely fine with any software player), but still worth being fixed.

Unfortunately, a proper fix would require a transition from timestamps in µs into timestamps in a timescale (as a rational num/den) as well as big changes to the strategy of stream copy. This means a lot of work.

[eumagga0x2a]

The situation should be better now, the other part of the equation, aimed at preserving the video stream timebase is in the works.

[hiro]

Not only I also noticed that, I've been "FPS resampling" from e.g. 29.97 to 29.97 (for "ages") after observing, though I may be wrong*, a CFR (report) afterwards, instead of VFR otherwise. So this post sounds like good news (will have to check).

* Sometimes wondering about "MediaInfo" reliability, on its framerate mode analysis...

[eumagga0x2a]

The main part of the task is done, with some demuxers and muxers still requiring more work. The currently latest available nightlies from 2019-12-23 don't include the recent fixes to the flv demuxer yet, but apart from that, they should do a better job at preserving original frame rate in most cases.

Please be aware that they won't turn a variable frame rate video into a constant frame rate one (with one very limited exception of mp4 files with timestamp jitter clearly originating from our rounding errors, meanwhile fixed).