State of lossless cutting in avidemux 2.8.1

[test32421]

Hello,

when looking up the subject of lossless cutting in avidemux, I found a lot of older threads that all suggest the same: in avidemux, lossless cutting is possible, but only if the start and end frames are I-frames (keyframes). If at least one of the two is not an I-frame, a warning is supposed to appear during exporting, and when exporting, it will reencode the resulting video. Reencoding is supposed to be quality controllable via a slider.

However, this behavior does not match what I'm seeing in the latest version. There is no encoding quality option, for one. I'm also able to cut on any frame I want, and it will export the video all the same, witout any warnings. Comparing with the source, I can't spot any differences, but VLC will always show a framerate that is off by a fraction, compared to the source.

Can anybody clarify if lossless cutting is still possible in 2.8.1, or is it always reencoding the video now, presumably with highest quality? And another minor question - I noticed that a headphone downmix option is enabled by default. I'm assuming this is just for playback and doesn't need to be changed when both audio and video are shown as "copy"?

[szlldm]

Lossless cutting must start on I-frame, this is due to physical/mathematical/information-theoretical principles. The end frame rule depends on the frame structure of the source material.

Copy mode or reencode is fully controlled by the user. If Copy mode selected, there is no reencode happens.
The headphone downmix option only affect the playback in Avidemux.

[sark]

To reencode you must choose an encoder option in the Video Output drop down list. Copy is selected by default. Once an encoder option is selected the Configure button becomes active and you can apply quality settings.

Because most (not all) I-frame referencing is done in a backwards direction, you must always start on an I frame, but you can often end on an intermediate frame. It is therefore possible to get very accurate results without reencoding, but there is no guarantee.

Version 2.8.1 is now very old. The latest nightlies can be found below:

https://www.avidemux.org/nightly/win64/

[test32421]

OK, thanks for the answers. I tested it again and it seems in copy mode it will just silently cut the output file to keyframes instead of giving a warning. So it kind of works like the record feature in VLC, but definitely gives more solid results than that, and is much faster of course.

However, I still don't understand why the resulting frame rate is off by about 0.002 frames or so. When doing +10 seconds seeking in VLC, comparing with the source, it indeed doesn't always land on the same frame. This suggest to me that even when cutting by keyframes, there might be a duplicate or missing frame somewhere in the video.

[eumagga0x2a]

1. Please use a recent (the latest) 2.8.2 nightly. Running 2.8.1 now is akin to inflicting self-harm.

2. If the source video is encoded in Open-GOP-mode like almost all DVB-T/C/S streams, it may contain so-called early B-frames (B-frames preceding a keyframe in the display order, but following the keyframe in the stream order) referencing pictures from the previous GOP. Avidemux must drop such B-frames at the start of the video as they cannot be fully decoded.

Resulting gaps in the stream skew average frame rate as displayed by many tools including Avidemux.