Avidemux Forum

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"?

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.

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/

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.

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.

Remember, you

Quote from: test32421 on October 02, 2024, 09:28:24 PMHowever, 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.

Remember, all your video fragments (in copy mode) must start on I-frame and end on P-frame, else avidemux will cut at wrong points.

You sure about that? Most posts suggest to both start and end on I-frames, and in fact this (possibly older, but still) avidemux documentation seems to suggest just the same: https://avidemux.sourceforge.net/doc/en/cutting.xml.html

Quote from: test32421 on October 09, 2024, 02:45:46 AMYou sure about that? Most posts suggest to both start and end on I-frames

Yes, you can end it on I-frame too, just not on B-frame. Also beware of IDR warning, not all I-frames are suitable for cutting (in this case you must cut on some other I-frame). This could happen with non-live youtube videos, for example.

And for avidemux cutting interface: the "B" marker position is not included in selection. So I mean, your "ending" frame is the frame that is actually included in that selection, the previous one. And that frame could be either I or P, just not B. You can test it yourself.

By the way, did eventually update to 2.8.2 Nightly. One nitpick that I have is, for anamorphic content, it should be able to display what aspect ratio the input file is forcing and give an option to always keep that. Right now, it seems output always defaults to 1:1 PAR until something else is set. In practice, that means an extra step of opening the input file in VLC or something to check.

Quote from: test32421 on October 09, 2024, 02:45:46 AMMost posts suggest to both start and end on I-frames

Avidemux contributes to confusion by using inaccurate terminology. A video segment must start with a keyframe. It often doesn't really matter what type of frame is at the end. Avidemux will automatically stop at the last frame in the stream order fitting into the range specified by the B marker (as Elstar` correctly noticed, the end of selection doesn't belong to the selection). Setting it to a B-frame means that no frame with decode timestamp (DTS) greater than or equal to the DTS of the B-frame and presentation timestamp (PTS) greater than or equal the PTS of the B-frame will be included into the output. This results e.g. in one P-frame the B-frame depends on being dropped as it is displayed after the B-frame. At the same time, it precedes the B-frame in the stream order, thus the portion of the stream we have to drop is longer when the B marker has been set to a B-frame.

Quote from: test32421 on October 09, 2024, 09:05:49 PMOne nitpick that I have is, for anamorphic content, it should be able to display what aspect ratio the input file is forcing and give an option to always keep that.

Avidemux completely ignores aspect ratio specified at the container level. Only VUI from the codec is evaluated and can be inspected in the "Properties" dialog.

What is the reasoning for not including the frame marked with B in the selection? That seems extremely counterintuitive, and indeed I was assuming it's included. In fact, it means that if you do what is mentioned everywhere, which is to place both A and B at I-frames, you are guaranteed to get frames cut off at the end.

It is counter intuitive, but there is a logic behind it.

Imagine you have a video that runs at one frame per second (1fps). Presentation Time Stamps (PTS) represent the time a frame first appears, therefore the first frame would appear at 0secs, the second frame at 1secs. If we set the A marker to frame one (0secs), and the B marker to frame two (1secs),  the total time range equals just one second (0 to 1). Now, if we save both frames we would save a clip that was two seconds long. This is contrary to the time range we selected.

It doesn't matter where along the timeline we do this, 3sec to 4sec, or 8sec to 9sec. The markers display two different frames, but the duration of the range is equal to just one second (the duration of a single frame). Hence the B marker frame is not included in the selection.

The image below shows how only a single frames duration (1sec) falls between the A and B markers.

You cannot view this attachment.

Quote from: test32421 on October 10, 2024, 01:27:08 AMWhat is the reasoning for not including the frame marked with B in the selection?

This is a basic mathematical convention.

Frankly, I felt the same a long while ago as I started to contribute to Avidemux, but this created way more problems than it solved so I changed my mind and restored the sanity.

Quote from: sark on October 10, 2024, 12:25:23 PMNow, if we save both frames we would save a clip that was two seconds long.

No, it would be one second long, with the second frame having zero duration.

Quote from: eumagga0x2a on October 10, 2024, 08:03:16 PM

Quote from: sark on October 10, 2024, 12:25:23 PMNow, if we save both frames we would save a clip that was two seconds long.

No, it would be one second long, with the second frame having zero duration.

Are you suggesting my example would save both frames, but display only the first for its full duration. That would turn all logic I have applied to this convention on its head.

Your comment also seems to contradict all previous statements that the B frame is not saved, which my experience contradicts.

Can you clarify that statement.

Personally I do not need single frame accuracy, but the more I understand about this convention, the less I understand.

Quote from: sark on October 10, 2024, 09:30:45 PMYour comment also seems to contradict all previous statements that the B frame is not saved, which my experience contradicts.

Your example picture is correct, the frame starting at the B marker is not saved (if reencoded).