[2.8.1] Copy mode buggy?

[Misha]

When I remux a TS file to MP4 using copy mode, the video bitrate looks have something lost vs another software called Lossless Cut. The file size is hugely different from others too.
And the audio bitrate mode was changed too.

So, why?
Is there no way to remux to mp4 if I want to keep everything? (e.g. no A/V align to lost frames)

[eumagga0x2a]

In a MPEG-TS stream, Avidemux drops all packets belonging to stream types it doesn't support (i.e. anything except of the first video track and audio tracks). Within H.264 or HEVC video track, Avidemux drops filler NAL units, used by encoders to keep video bitrate beyond specified minimum when the actual video data is not enough for that. Keeping bitrate artificially up, sometimes necessary for video broadcasts over channels with fixed bandwidth, is pointless in containers not suitable for streaming like MP4.

Audio bitrate of AAC streams remuxed from MPEG-TS into MP4 will drop a little bit because Avidemux extracts AAC frames from the LATM envelope, necessary for MPEG-TS, which means that AAC extradata is not repeated over and over again. Absolutely no changes are made to the actual compressed frames.

[Misha]

In a MPEG-TS stream, Avidemux drops all packets belonging to stream types it doesn't support (i.e. anything except of the first video track and audio tracks). Within H.264 or HEVC video track, Avidemux drops filler NAL units, used by encoders to keep video bitrate beyond specified minimum when the actual video data is not enough for that. Keeping bitrate artificially up, sometimes necessary for video broadcasts over channels with fixed bandwidth, is pointless in containers not suitable for streaming like MP4.

Audio bitrate of AAC streams remuxed from MPEG-TS into MP4 will drop a little bit because Avidemux extracts AAC frames from the LATM envelope, necessary for MPEG-TS, which means that AAC extradata is not repeated over and over again. Absolutely no changes are made to the actual compressed frames.

Does this mean that when using copy mode, there is absolutely no loss of quality or content in both video and audio?

[eumagga0x2a]

No loss of quality: absolutely.
No loss of content: it depends.

[Misha]

Here's another similar question. When I save an audio track from a video file separately, it changes the audio format, at least on the file label. Does this affect how it plays, or even the sound quality?

I don't have this problem with audio files extracted by other software, and repackaging the audio file with Avidemux seems to work fine.

The audio format profile of my source file is HE-AAC / LC, but after extracting it with Avidemux, it becomes Main. The sampling rate is now only 24.0 kHz.

[eumagga0x2a]

HE-AAC is AAC with half the sampling rate and with spectral band replication (SBR). In some cases SBR is not signaled in the codec extradata and can be determined only by decoding at least one AAC frame (implicit SBR):

Code Select Expand

Format settings, SBR                     : Yes (Implicit)
(from mediainfo output you had attached). What exact problem do you experience with Avidemux-exported HE-AAC audio track? Does Avidemux fail to import its own export correctly?

[Misha]

What exact problem do you experience with Avidemux-exported HE-AAC audio track? Does Avidemux fail to import its own export correctly?

The audio format profile of my source file is HE-AAC / LC, but after extracting it with Avidemux, it becomes Main. The sampling rate is now only 24.0 kHz.

You cannot view this attachment.
This is what I got from analyzing the exported aac files under another software. The one on the left is from Avidemux and the one on the right is exported by that software.

I'm worried that it will end up playing with a loss of sound quality due to the loss of HE and SBR information and the halving of the sample rate.
Will the player or decoder recognize the SBR signal properly without the correct information?

I'd like the export to keep all the information contained in the source file as intact as possible to avoid potential issues.

[eumagga0x2a]

Do I need to repeat what I wrote in my last reply?

[Misha]

Do I need to repeat what I wrote in my last reply?

I know what you mean. But I don't understand why other software can export HE extradata properly but Avidemux can't? Why can't it retain this relevant information for easy viewing of its properties? It makes it looks not lossless. Is it said to minimize the file size?

[eumagga0x2a]

I'll look into specifics of export of HE-AAC audio tracks regarding extradata provided by the track and being actually written, thanks.

[eumagga0x2a]

So, the format Avidemux uses to export AAC audio tracks – Audio Data Transport Stream (ADTS) – is simply incapable to accomodate audio object type (AOT) codes beyond AAC LTP (Long Term Prediction) as well as explicitly specified sampling frequencies. I've modified the AAC writer in Avidemux in the sense that it will now fake AAC Low Complexity (AAC LC) if AOT is incompatible instead of ending up with something worse supported like AAC Main.

However, in many cases an AAC decoder identifies the correct type from bitstream (from compressed audio frames) alone, like pretty much everything FFmpeg-based plays HE-AAC and HE-AAC v2 (AAC SBR and AAC SBR PS) streams exported this way to file just fine. Again, this is a limitation of the ADTS envelope, ffmpeg does mainly the same.

To preserve the entire extradata from the original stream, Avidemux would need to be able to export AAC using LATM envelope. Will keep this topic on my radar.

[eumagga0x2a]

In my local Avidemux code tree, I've added a wrapper for the LATM muxer from libavformat and have played with it as well as with the output of the same muxer in FFmpeg

Code Select Expand

ffmpeg -i source.mp4 -map 0:1 -c:a copy -f latm output.aac
and I have to say that I don't think that going this path would benefit users. The compatibility of raw LATM streams with players seems to be pretty poor, neither the Microsoft's successor app for Windows Media Player nor GStreamer-based apps like Totem on Linux can handle it. FFmpeg-based players are fine, but I doubt that this is sufficient. The situation where some .aac files created by Avidemux are different and cannot be played by many popular players would be worse than the current one (e.g. WMP plays HE-AAC inside ADTS which doesn't indicate SBR just fine, but rejects HE-AAC inside LATM with the proper complete extradata).

Last but not least, Avidemux itself cannot handle such files at the moment (but implementing support should be possible).

That said, unless Avidemux gains an ability to handle audio-only MP4 containers or MPEG-TS streams without a video track, which would allow to switch from exporting raw audio stream to exporting audio stored inside a well-supported container, the current state of affairs is IMHO the lesser evil.