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?
Probably this (https://github.com/mean00/avidemux2/blob/master/avidemux/common/ADM_editor/src/ADM_segment.cpp#L684), 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.
The situation should be better now (https://github.com/mean00/avidemux2/commit/0135dc7d40416d50dad4fd183c2c55942f05d1e4), the other part of the equation, aimed at preserving the video stream timebase is in the works.
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...
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).