Is avidemux a frame accurate and lossless video cutter/splitter on Linux?

[adidasos]

Is avidemux a frame accurate and lossless video cutter/splitter on Linux? Thanks!

[sark]

Whether Windows, or Linux, the answer is no.

No program is truly able to be frame accurate and lossless. Even the often recommended Lossless Cut is not lossless and frame accurate by default, and its lossless frame accurate mode is described by its developers as experimental.

Simply put. You cannot discard frames that are referenced by remaining frames without issues, unless you reencode.

[adidasos]

I'll try to add some things, and perhaps explain better. But I am not a video expert, so I might not do the best job. As I understand it there are key-frames. I think this is what you are referencing. And these key-frames show up every so often throughout the video. When I cut/split a video I want it to cut in that exact spot that I choose. Why? Because if it doesn't, the cut doesn't come out looking very good, and I'm not happy with it. (frame accurate) I realize if you cut away from these key-frames that it has to make new ones or go to the nearest one by adding/subtracting frames from your cut.

I really don't care if a video splitter has to re-encode a file as long as it sounds and looks as good as the original. (lossless) Because I keep all the videos that I cut to watch and enjoy so I don't want their quality reduced. I often cut music videos to take out seizure warnings, or credits, or long boring intros with no music, for example. And if it ruins the quality of the music or the video then I don't want it.

So can this program at least cut without adding or taking away frames from my cut spot that will change the way it looks from what I choose? Perhaps by making a new key-frame if needed instead. And is it able to not reduce the quality of the outputted video/audio in any noticeable way? Also, I would like if the cut video can accurately keep track of the total length of the video and where you are at time wise when being played. This was occasionally a problem with other videos cut in past programs I used. Thanks!

[sark]

It is possible to cut with precise frame accuracy without loss of quality, but you must reencode using a lossless format.

H264 can do this within Avidemux (there are also other options). However, unlike cutting in copy mode on keyframes, lossless encoding produces VERY large files. This may be fine for archiving, or later editing, but may be impractical for general viewing of output.

Try the following:

Open a file in Avidemux. Select about 10 seconds to save.
Choose Mpeg4 AVC (x264) as your encoder.
Under Configure/General set the quality slider setting to 0 (zero = lossless).
Save the file and check its output size.
Bare in mind this is just 10 seconds.

[sark]

So can this program at least cut without adding or taking away frames from my cut spot that will change the way it looks from what I choose?

And is it able to not reduce the quality of the outputted video/audio in any noticeable way?

Lossless cutting, without reencoding, is often desirable because it is fast. It is not necessarily a quality issue.
It is quite possible to cut with frame accuracy using lossy encoding and produce a percieved quality that matches the original. The average viewer will not notice any difference. Not technically lossless, but quality wise, it can appear the same. Maybe this is what you are requesting.

Avidemux can certainly produce high quality output that is similar to the original, if you're happy to encode.

After trying the previous test, repeat it with a quality setting of about 15 to 18. Settings depend very much on the original content. Compare with the original and decide for yourself if this is satisfactory.

[adidasos]

Thank you everyone for your input. I tried both the lossless and the copy original. The test file was already x264 to begin with. The lossless x264 does make much bigger files. I don't see much difference between the two, but the 0 lossless does look a little better. I think I will be happy with using avidemux going forward. I just switched to linux because I have always hated windows. So now I do believe I should be able to have a video cutter/splitter that will work for me in a Linux environment. Both tests did produce files that keep the quality similar or the same, and kept the timing info intact, and appeared to match my cuts as I selected them. Yay!

[sark]

Just to clarify a few points.

Lossless cutting is a term generally used to describe frame accurate cutting without reencoding. IMHO, Rife with issues.

Lossless formats are basically any format that can reencode without loss of quality. Unfortunately, this produces very large files.

If frame accuracy is important you will usually need to reencode. If it is not critical, you can cut on keyframes without reencoding. Also, because most (not all) referencing is in a backwards direction, you must start on a keyframe, but you can often end on an intermediate frame. If the keyframes are quite close together, you can cut very close to your dedired frames.

Finally, reencoding does not have to be detrimental to quality. It is often the encoding times that discourage this option.

[Elstar`]

In case of H264/AVC in mp4 container it indeed produces unmodified stream in copy mode. You must cut on keyframes, though (actually you can cut after a P-frame in most cases, but next segment must always begin on keyframe).

In case of lossless repack from mp4 to mkv container, there could be some weird results, for example, variable frame rate becomes constant as reported by mediainfo.

[butterw]

Is avidemux a frame accurate and lossless video cutter/splitter on Linux? Thanks!

Yes, with the caveat that compressed video files must be keyframe-only and most video files aren't.

In case of lossless repack from mp4 to mkv container, there could be some weird results, for example, variable frame rate becomes constant as reported by mediainfo.

Remuxing can sometimes fix things.

[eumagga0x2a]

In case of lossless repack from mp4 to mkv container, there could be some weird results, for example, variable frame rate becomes constant as reported by mediainfo.

Matroska uses by default (practically, always) a timestamp accuracy of 1 millisecond. This means that widely used standard time bases like 1001/24000 or 1001/30000 cannot be expressed in Matroska timing and are replaced by an approximation, making them technically variable frame rate. FFmpeg stubbornly sticks with this approximation, thus a roundtrip MP4 -> MKV -> MP4 done with ffmpeg results in a variable frame rate MP4 when fps in a constant frame rate source MP4 file is not something like 25 or 50 fps. Avidemux tries to guess the original frame rate and to complete a MP4 -> MKV -> MP4 roundtrip losslessly.

[Andrew-R]

Hello, all!

I was looking into this problem (minimal reencode of streams with non-all-I videocodecs)

and  today I found patent
https://patents.google.com/patent/US9392279
"Method and system for generating an instantaneous decoding refresh (IDR) picture slice in an H.264/AVC compliant video data stream "

Does it sounds like step in the right direction for smart-copy of h264 files?

[sark]

Hello, all!

I was looking into this problem (minimal reencode of streams with non-all-I videocodecs)

and  today I found patent
https://patents.google.com/patent/US9392279
"Method and system for generating an instantaneous decoding refresh (IDR) picture slice in an H.264/AVC compliant video data stream "

Does it sounds like step in the right direction for smart-copy of h264 files?

That patent was applied for ten years ago. Doubt there is anything new there.

The bottom line is that you cannot reference frames that do not exist. Without major encoder changes, I cannot see how you can get around this.

The current crop of lossless cutting apps work by reencoding the first and last GOP, and concatenating back. The problem is matching the encoded GOP sections parameters to the original unencoded section.

I guess the ability to better read, and match those parameters is the way forward. Currently though, I would not trust lossless cutting output that uses this method, even when it appears to work.