MKV variable to constant and timestamp errors

[coolgit]

OK i have lots of mkv files and and each need trimming once. Trimming is start to 44ish minutes.

Each MKV file are vfr and each has vfr timestamps. I then proceeded to cut each file and copy both audio and video to new mkv file. No encoding whatsoever. Some files worked and has vfr but some were converted to cfr without my say so. I want all files to be vfr as this is important.

Secondly, when converting the original timestamps is:

# timecode format v2
0.00
42.00
83.00
125.00
167.00
209.00
250.00
292.00
334.00
375.00 and so on.

After new mkv file was created the timestamps changed to:

# timecode format v2
111.00
153.00
194.00
236.00
278.00
320.00
361.00
403.00
445.00
486.00 and so on.

The above timestamp is wrong. It should be the same as the original.

For example if i were to trim a video from 0 to 60,000 frames out of 65,000 frames then the new timestamps would be 60,000 frames not 65,000 from the original. If i did this myself i would open timestamp into notepad++ and delete lines 60,002 to 65,001. I do not need to change anything else.

When i cut a video from 0 to 45:00.364, frames 0 of 65069, the original timestamp shown, using spreadsheet, arrived correctly at 45:00.323. The avidemux timestamp arrived incorrectly at 45:00.434. I do not know what methods you are using but would it be easier just export original timestamp, delete lines no longer needed, then import new timestamp, the same way as i did it by hand above.

So why does avidemux starts with 111.00, it causes audio/video sync to be off around 100 to 120 ms.

Edit:additional info.

I originally used the last official release and got 0 of 65064, 65064 frames, 5 frames short, video length 45:00.114. Not a big deal as they were black frames. I updated using the latest nightly built and got 0 of 65069, 65069 frames, video length 45:00.323, which is correct and perfectly cut. Obviously there has been some fixes so any chance of an official build so users can cut at the correct frame/time and get the right amount of frames.

[eumagga0x2a]

Avidemux tries to restore original timestamps in specific cases when variable frame rate in MKV is an artifact of timestamps being not precisely representable with 1 millisecond resolution in MKV: remuxing a MP4 with a CFR video track at 30000/1001 fps (time base 1001/30000) to a MKV and back to MP4 using Avidemux results in a CFR video like the original. Performing this roundtrip with ffmpeg creates a VFR MP4, the CFR property is lost.

In some rare circumstances, guessing the original timing may go wrong. Please provide a sample MKV then, thank you.

Official releases which are older than a couple of weeks are only useful to verify that an issue found in a nightly build is not a recent regression.

[coolgit]

What MP4 got to do with my post? The file is MKV. It is Star Trek series where it was filmed in 23.976 and the cgi part in 29.970. The timestamp correctly uses both so the audio is in sync. As my first post avidemux created a weird timestamp that was not compatible with the mkv file.

Seriously why can't avidemux just use the original mkv timestamp and not change it.

[eumagga0x2a]

MP4 expresses timing in units of a rational time base with arbitrary non-zero numerator and denominator within range supported by data type (uint32_t). This means that, when remuxed as MKV, such timestamp often fundamentally cannot be represented in MKV which in most cases uses 1/1000 of a second as the default time unit (it can be an arbitrary non-zero number of nanoseconds, but, firstly, this is hardly ever used and, secondly, even nanoseconds don't allow mathematically precise representation of timestamps). Thus we get an approximation, effectively making a CFR video (slightly) VFR one.

Avidemux tries to recognize cases when strictly speaking a VFR MKV is actually a CFR one with deviations resulting from rounding errors. Usually this detection is very reliable, but if you have stumbled upon a video where it fails when using the latest nightly, please provide a sample.

Except for rare edge cases, restoring the original CFR when loading a MKV video is a true advantage, IMHO. Not going to throw it away.