Avidemux cutting video not exactly at designated end marker.

[hebeguess]

Let's start with a mainstream format video and set it to trim exactly the same range using multiple versions of avidemux.

Custom metadata readout on sample video.

General
Filename.......: SAMPLE.mkv
Container......: Matroska
Size...........: 39.7 MiB
Duration.......: 57 s 836 ms

Video
Format.........: AVC
Profile........: High@L4 8 bits
Resolution.....: 1920x1080 (16:9)
Frame rate.....: 23.976 FPS
Duration.......: 57 s 850 ms

Audio
Format.........: E-AC-3 JOC
Channels.......: 6 channels
Delay..........: 12 ms
Frame rate.....: 31.250 FPS
Duration.......: 57 s 836 ms

Avidemux 2.7.5
Baseline

General
Filename.......: 275.mkv
Size...........: 3.44 MiB
Duration.......: 5 s 589 ms

Video
Delay..........: 84 ms
Frame rate.....: 23.976 FPS
Duration.......: 5 s 505 ms

Audio
Delay..........: 8 ms
Frame rate.....: 31.250 FPS
Duration.......: 5 s 504 ms

Avidemux 2.7.6
Side notes: Noting that the audio duration grow by 2 audio frames, probably related to the reworking on timing logic then.
I mentioned it in the forums nearly 2 years ago while I was trying to figure out/solving audio/video stuttering issue after concatenation back then.
The extra frames make it worse [in the view of appending operations], so I was avoiding newer version since.
The behavior isn't universal, some video (even in similar format) isn't affected and I still don't know why.

General
Filename.......: 278 0015 0020 770.mkv
Size...........: 3.45 MiB
Duration.......: 5 s 589 ms

Video
Delay..........: 84 ms
Frame rate.....: 23.976 FPS
Duration.......: 5 s 505 ms

Audio
Delay..........: 8 ms
Frame rate.....: 31.250 FPS
Duration.......: 5 s 568 ms

Avidemux 2.8.0 (or nightly-220618)
The main issue for the thread:
The markers were placed at exact same locations as before, check the video duration: it decreased by considerale amount of time.
This was caused by the program silently revert to the penultimate (P/I frame) safe cutting point,
even though the end marker was already located at a safe cutting P-frame already.
This can be verified either visually or by frame counting on the video.

As for the audio the duration of it seems to be matching where you actually put the end marker.
Let's say in the case of placing end marker at a B frame, the output video will properly revert to the last P/I frame prior the end marker location [on B-frame], however audio will still be chopped off at where the end marker was placed.

General
Filename.......: 280.mkv
Size...........: 3.32 MiB
Duration.......: 5 s 576 ms

Video
Delay..........: 84 ms
Frame rate.....: 23.976 FPS
Duration.......: 4 s 880 ms

Audio
Delay..........: 8 ms
Frame rate.....: 31.250 FPS
Duration.......: 5 s 568 ms

===


Next up, try it on a video without P frames (safe to end on any frames).

General
Filename.......: SAMPLE-B-frames-only-video.mkv
Container......: Matroska
Size...........: 208 MiB
Duration.......: 59 s 392 ms

Video
Format.........: HEVC
Profile........: Main 10@L5@High 10 bits
Resolution.....: 3840x1920 (2.000)
Frame rate.....: 23.976 FPS
Duration.......: 59 s 393 ms

Audio
Format.........: E-AC-3 JOC
Channels.......: 6 channels
Language.......: English
Delay..........: 17 ms
Frame rate.....: 31.250 FPS
Duration.......: 59 s 392 mss

Avidemux 2.7.5
Baseline

General
Filename.......: 275.mkv
Size...........: 13.1 MiB
Duration.......: 3 s 295 ms

Video
Delay..........: 42 ms
Frame rate.....: 23.976 FPS
Duration.......: 3 s 253 ms

Audio
Delay..........: 7 ms
Frame rate.....: 31.250 FPS
Duration.......: 3 s 264 ms

Avidemux 2.7.8
Side notes: audio duration actually matched up to Avidemux 2.7.5 in this case.

General
Filename.......: 278.mkv
Size...........: 13.1 MiB
Duration.......: 3 s 295 ms

Video
Delay..........: 42 ms
Frame rate.....: 23.976 FPS
Duration.......: 3 s 253 ms

Audio
Delay..........: 7 ms
Frame rate.....: 31.250 FPS
Duration.......: 3 s 264 ms

Avidemux 2.8.0 (or nightly-220618)
The video ended at 2 video frames earlier than where the end marker sat.

General
Filename.......: 280.mkv
Size...........: 12.7 MiB
Duration.......: 3 s 271 ms

Video
Delay..........: 42 ms
Frame rate.....: 23.976 FPS
Duration.......: 3 s 170 ms

Audio
Delay..........: 7 ms
Frame rate.....: 31.250 FPS
Duration.......: 3 s 264 ms

====


Here is another problem seems to be on nightly-220618 only.
Avidemux 2.8.0 is fine.

General
Filename.......: SAMPLE.mkv
Container......: Matroska
Size...........: 39.7 MiB
Duration.......: 57 s 836 ms

Video
Format.........: AVC
Profile........: High@L4 8 bits
Resolution.....: 1920x1080 (16:9)
Frame rate.....: 23.976 FPS
Duration.......: 57 s 808 ms

Audio
Format.........: E-AC-3 JOC
Channels.......: 6 channels
Delay..........: 12 ms
Frame rate.....: 31.250 FPS
Duration.......: 57 s 836 ms

What I do is drag & drop a video and press save.
For the first round, Avidemux will shift the starting time of video & audio due to its internal logic like always.

General
Filename.......: SAMPLE_edit.mkv
Size...........: 39.7 MiB
Duration.......: 57 s 920 ms

Video
Delay..........: 84 ms
Frame rate.....: 23.976 FPS
Duration.......: 57 s 808 ms

Audio
Delay..........: 128 ms (other version was around 96ms; 84 ms avidemux + 12 ms original stat)
Frame rate.....: 31.250 FPS
Duration.......: 57 s 792 ms

Do it recursively.
What's wrong here on nightly is it keep on adding delay start time onto audio track while trimmed down its total
duration.

General
Filename.......: SAMPLE_edit_edit.mkv
Size...........: 39.7 MiB
Duration.......: 57 s 920 ms

Video
Delay..........: 84 ms
Frame rate.....: 23.976 FPS
Duration.......: 57 s 808 ms

Audio
Delay..........: 160 ms
Frame rate.....: 31.250 FPS
Duration.......: 57 s 760 ms

General
Filename.......: SAMPLE_edit_edit_edit.mkv
Size...........: 39.7 MiB
Duration.......: 57 s 920 ms

Video
Frame rate.....: 23.976 FPS
Duration.......: 57 s 808 ms

Audio
Delay..........: 192 ms
Frame rate.....: 31.250 FPS
Duration.......: 57 s 728 ms

[butterw]

I think the behavior was changed as to whether the Marker B frame is included in the output video.
in v2.7.7 and v2.7.9-dev (210611): included
in v2.8.1-dev (20june2022): not included.

A good way to see what is going on is to reencode the source clip with a frame number/pts overlay (filter "Miscellaneous > PrintInfo").

[eumagga0x2a]

The behavior change regarding the B marker was even mentioned in the release changelog for 2.8.0.

Generally, in copy mode, it up to the internal structure (especially to timestamps) of the video stream to determine when Avidemux has to cut off the output and switch to the next segment (if it exists). For a reliable result, the source may not contain B-frames.

I'll look into recursive operation.