PCM Audio, little/big endian, and saving to .mov

[Urik]

I remember seeing a thread here a while back about a similar topic. Couldn't find it but it said that Avidemux automatically saves as .mov if trying to save uncompressed PCM (wave) audio.
That is indeed how it works for certain files, like clips from a Sony camera I have (I'm talking about h264 obviously, I'm not putting anything like Prores in Avidemux)
However, I've noticed that I could not save/remux other .mov videos with PCM audio which I've assembled with FFMPEG.
After some cross-checking, I found the (apparent) culprit. The Sony files audio has "Big Endian" byte order

MediaInfo

Code Select Expand


Format                      : PCM
Format settings             : Big / Signed
Codec ID                    : twos


The audio that would cause Avidemux to pop an error instead of saving as .mov is "little endian" type

Code Select Expand


Format                      : PCM
Format settings             : Little / Signed
Codec ID                    : sowt


I confirmed it by extracting, converting to little-endian and remuxing audio back into the Sony clips, and then Avidemux wouldn't save them anymore.
I could still make edits and workaround this by saving audio separately then saving video with AAC audio and then muxing them to .mov via FFmpeg.

I assume it must've been an oversight since little endian isn't unusual (more like, common)?

By the way, why doesn't Avidemux doesn't have an actual selectable MOV Muxer? Just curious.

edit: it seems something about chrome was causing the spam checker *** Forbidden. Please enable JavaScript. *** error when making a post. Tried Edge and it went through.

[eumagga0x2a]

I can be easily wrong, but AFAIK LPCM in MOV is always big-endian. It is definitely a shortcoming of the PCM encoder in Avidemux that it doesn't allow to byte-swap the output.

By the way, why doesn't Avidemux doesn't have an actual selectable MOV Muxer? Just curious.

Just not done, I guess? Apart from that, the design doesn't allow multiple filename extensions per muxer, so it would be 99.9% identical code for the ability to save DNxHD (and LPCM with correct extension).

Didn't look into addition of ProRes yet. A decoder is available in libavcodec but not built in Avidemux.

[Urik]

Ok, thanks for response. I thought since wav is little endian, it's supposed to be the same in mov and Sony is just weird with their audio being big endian.

[Urik]

Kinda funny how these days when googling for something I end up stumbling onto my own posts, but it seems Avidemux now has the mov muxer and is able to save pcm audio with it.
However, when tested, I had some issue with such output files where the video player (mpc-hc) would take long time to start playing the audio when seeking through the file, and Adobe Premiere would not play audio at all.  I'm using 201219 VC+ build, testing merging h264 stream with wav (pcm 16 bit little-endian) audio.

Similar outputs from other tools such as ffmpeg (.mov & pcm) and mp4box (.mp4 & pcm) don't have this issue. Movflags/faststart was on in all cases (including avidemux).
Actually, mp4box-produced file seems to be most fluent in playback/seeking presumably due to its default 500ms a/v interleaving.

I can't really tell much more, metadata wise I didn't see any clues. Perhaps it has something to do with how stream data is written. And be/le byte order makes no difference.

[eumagga0x2a]

Difficult to tell what is amiss as all players on Linux handle MOV (H.264 + PCM) files created by Avidemux just fine, at least short ones with stereo audio, didn't try multichannel yet. Nevertheless, I've changed some stuff to better align our behaviour with FFmpeg, please try a future nightly.

Actually, mp4box-produced file seems to be most fluent in playback/seeking presumably due to its default 500ms a/v interleaving.

Isn't it a horribly bad interleaving? How can such a huge interleaving window be beneficial for seeking? Avidemux uses just the frame increment.

[Urik]

Isn't it a horribly bad interleaving? How can such a huge interleaving window be beneficial for seeking? Avidemux uses just the frame increment.

I dunno, it's new to me so it was a quick theory. I never knew before what it is so I thought mp4box is unique for that. If I'm reading their documentation right, ffmpeg defaults to 10sec interleaving. After some more testing, I don't think it matters anymore for playback and the first test must've been just circumstantial.
I still don't know what exactly causes Avidemux-exported mov files with pcm audio have no audio in Adobe Premiere (audio gets recognized but won't play), as there's no apparent differences that mediainfo/mp4info/etc can tell me. It's not really a crucial usage scenario but I was curious as usual.

[eumagga0x2a]

I still don't know what exactly causes Avidemux-exported mov files with pcm audio have no audio in Adobe Premiere (audio gets recognized but won't play)

Does this depend on duration of the video? I could upload a short sample created by Avidemux built off the latest git master. If it works while a mov file created in copy mode by an earlier version doesn't, this would indicate that the issue has been resolved.

[Urik]

Does this depend on duration of the video?

No, I've tested on files as short as 2 sec so far. Can test.

I've just noticed when using select track > add audio track it rejects any pcm audio files ("Cannot use that file as audio track") regardless of selected format or audio output setting. Maybe it was always this way and I just didn't notice.

I do remember that at some point in (some 2019 build, I think), it would automatically switch to mov when trying to save mp4 with pcm audio. I see it no longer does that.

I know a lot of this stuff is unconventional, but specifically mp4+pcm is a viable scenario because many cameras (Sony and others) record files this way, despite being against official mp4 spec.

[eumagga0x2a]

I've just noticed when using select track > add audio track it rejects any pcm audio files ("Cannot use that file as audio track") regardless of selected format or audio output setting. Maybe it was always this way and I just didn't notice.

But it playes mov files with little-endian PCM audio track created by ffmpeg, doesn't it?

I do remember that at some point in (some 2019 build, I think), it would automatically switch to mov when trying to save mp4 with pcm audio. I see it no longer does that.

The muxer switched silently to MOV mode and saved the output as a QuickTime file but with extension "mp4" before both were cleanly separated.

I know a lot of this stuff is unconventional, but specifically mp4+pcm is a viable scenario because many cameras (Sony and others) record files this way, despite being against official mp4 spec.

Avidemux doesn't try to mux PCM into mp4. It couldn't even if it wanted. libavformat doesn't allow this.

[eumagga0x2a]

I've uploaded a short H.264 (a static 1280x720 solid red image) + 6 channel low-endian 16-bit PCM sample to https://we.tl/t-g54muex69L

SHA256: e4297e4be9df24f6ba83c602a43eb9cdb21d6f8300710cda7e8f2021cffe9f74
MD5: a0a7c4679cefb08e30a72c2775fc7920

[Urik]

Yes, this one works fine. Video/audio plays. Channels recognized as they should (by in-program file info and gain meters).

Obviously if I try to re-wrap this very file in 20201229 it breaks it again. By the way, one symptom I didn't mention is that with those broken files there is sometimes a sound pop at beginning, and audio meters peak once and go down or stay at 0db peak.

But it playes mov files with little-endian PCM audio track created by ffmpeg, doesn't it?

Yes it (Avidemux) plays all, big endian, little endian, also mp4 files from Sony cameras and mp4box. So, regardless of byte order.

Avidemux doesn't try to mux PCM into mp4. It couldn't even if it wanted. libavformat doesn't allow this.

Yes I do realize that. ffmpeg devs themselves stated before they want to stick to the paper spec and won't allow that.

[eumagga0x2a]

Yes, this one works fine. Video/audio plays. Channels recognized as they should (by in-program file info and gain meters).

Just to be sure: I speak about Adobe Premiere. Does it play there?

[Urik]

Yes, this one works fine. Video/audio plays. Channels recognized as they should (by in-program file info and gain meters).

Just to be sure: I speak about Adobe Premiere. Does it play there?

Yes, Adobe Premiere. Your test file plays fine.
(The other responses I made earlier but forgot to send so I attached them to same message)

[eumagga0x2a]

Great, thanks. This means the fix works :-))

We didn't set channel_layout in AVCodecParameters, which resulted in the optional 'chan' atom being not written. Additionally, the block_align field in AVCodecParameters was not set while the PCM encoder didn't set blockalign in WAVHeader.

These three issues are fixed now.

[Urik]

Well, it makes sense, I've had experiences before where Premiere was picky about audio for weird reasons. Like it wouldn't recognize a second track in ffmpeg-produced quicktime if some certain metadata flag or tag wasn't the way it wanted.