Video cut and then saved in copy mode has framerate issue

[Cormy1]

Not sure if you'll be able to see anything just from this, I can upload the source file as well.
But I just made some cuts to a video, not all on keyframes, and saved in copy mode without re-encoding.
When I play it back in my media player, the framerate stutters throughout.
https://we.tl/t-NFAXFEXVzW

[eumagga0x2a]

We have a massive amount of duplicate timestamps (MKV supports only PTS, that's it) in the file. You can rescue it by saving in copy mode as AVI (acknowledge the freaky warning), then loading the resulting AVI in Avidemux, restoring correct PTS and saving it in copy mode to e.g. MP4 or MKV.

[eumagga0x2a]

Does the topic header imply that the source of the sample didn't exhibit the issue with duplicated timestamps and they were introduced by saving in copy mode with Avidemux? In this case it would be indeed indispensable to get hold of the source video file (I strongly suspect that it was originally a MPEG-TS).

[Cormy1]

Yes, the source did not have this issue.
Saving in copy-mode did introduce it.
https://we.tl/t-e2BsD3ucJV

[eumagga0x2a]

The file you provided as the source exhibits exactly the same issue, i.e. a massive amount of duplicated / colliding timestamps when loaded in Avidemux. Avidemux detects frame rate as a standard 24000/1001 fps one (as also specified by the codec in agreement with MKVToolNix) and attempts to align all timestamps in the file to a multiple of this timebase. At this stage something goes wrong.

I'll try to have a look later, thank you for the sample.

[eumagga0x2a]

Should be fixed by [demuxers/Matroska] Fix calculation of CFR timestamps for given timebase when the first frame PTS significantly deviates from a multiple of the timebase, thank you for raising the topic and for providing the sample.

However, when we end up with duplicated PTS somewhere or when a file originally contains duplicated PTS, we currently don't have a working strategy how to deal with such a situation. This fix doesn't address this problem, it just reduces the chances to break a good file.

[Cormy1]

Was it just a result of being loaded into Avidemux that created the duplicate and colliding timestamps?
Or just the way Avidemux handled those duplicates and colliding timestamps?
I don't notice the playback issue when playing the source in my media player (MPC-BE)

[eumagga0x2a]

Was it just a result of being loaded into Avidemux that created the duplicate and colliding timestamps?

In the first, small sample produced from the source video in copy mode, the duplicate timestamps were an artifact of loading the source video in Avidemux and subsequently processing it. The original problem, now fixed, was created by the Matroska demuxer in Avidemux.

When loading the small sample in Avidemux, the only way to rescue it is to invalidate all video timestamps – this is what saving as AVI is for. Without this step, the processed video will remain broken.

Discarding all timestamps right in the demuxer when duplicated PTS are found, means that the success depends entirely on the demuxer getting the timebase of the video right (and the entire video stream throughout matching this timebase pretty perfectly) – either a total hit or a total miss.

Contrary to MP4 (and AVI), Matroska files usually store timestamps not as multiple of a rational numerator/denominator (such rational is called timebase) but at a fixed 1 ms resolution. This means that US standard frame rates such as 24000/1001, 30000/1001 and 60000/1001 cannot be represented in Matroska timestamps without errors. FFmpeg is perfectly happy with that – a 24000/1001 fps constant frame rate video will turn into a variable frame rate with timestamps being a multiple of a millisecond.

Avidemux tries to reconstruct the original, fraction-based perfect timing. The reason for failure was that Avidemux tried to force the first frame PTS to be a multiple of the timebase before calculating the multiples for all other frames' timings. In the source video the first frame PTS was pretty exacly 1/2 of the timebase and all subsequent frames were very well aligned at multiples of timebase relative to the original first frame PTS (but not to the zero point). Once it was replaced with a multiple of timebase, we got a lot of rounding erros, i.e. duplicated multiples.

I assume that such scenario when all timestamps are shifted, while being regular relative to each other, may be pretty common.

don't notice the playback issue when playing the source in my media player (MPC-BE)

The source is fine, the file saved by Avidemux without the fix for the Matroska demuxer is broken. If MPC-BE nevertheless is able to play that processed video smoothly, it can be achieved by detecting and discarding broken timing, relying on some timestamps being correct and assigning sane timestamps based on the order the decoder outputs decoded pictures. But I don't know MPC-BE codebase, so it is just speculation.

[Cormy1]

Other issue with that source is that when I'm trying to skip through it on keyframes, I often get a message that Avidemux can't go to the next keyframe and I need to seek/play past it.

EDIT: Actually I think the latest changes fixed that as well.

Quick off-topic question, does Avidemux fully support FFV1 encoding?
I noticed this Wikipedia article said support was removed:
https://en.wikipedia.org/wiki/FFV1#Applications_supporting_FFV1

[szlldm]

I noticed this Wikipedia article said support was removed:

Now it is back