in24 Little Endian PCM audio (pcm_s24le) in mov decoded incorrectly as Big Endian (pcm_s24be)

[Ignasi Rius]

I have a MOV file with 2 audio tracks using the in24 codecID and the pcm_s24le format. (So audio is Little Endian).
However, ffmpeg interprets the tracks as Big Endian, so audio is not decoded properly. If I tell ffmpeg to decode it as pcm_s24le everything works fine. QT, vlc, Windows Media Player and any other player I tried decodes it just right, so I'm sure the file its OK.

How to reproduce:

% ffmpeg -i IN24_LittleEndian.mov -vn -acodec copy BAD_DecodedAudioOutput.MOV

However, everything works fine if I force the input audio codec with:

% ffmpeg -acodec pcm_s24le -i IN24_LittleEndian.mov -vn -acodec copy OK_DecodedAudioOutput.MOV

FFmpeg version is:

ffmpeg version N-46146-g11d695d
built on Oct 29 2012 18:06:25 with gcc 4.7.2 (GCC) (32-bit static Windows build from Zeranoe'n)

To give a little bit more info, if I run ffprobe, you can see that ffmpeg thinks the audio is Big Endian:

%ffprobe IN24_LittleEndian.mov
ffprobe version N-46146-g11d695d Copyright (c) 2007-2012 the FFmpeg developers
  built on Oct 29 2012 18:06:25 with gcc 4.7.2 (GCC)
  configuration: --enable-gpl --enable-version3 --disable-pthreads --enable-runtime-cpudetect --enable-avisynth --enable-bzlib --enable-frei0r --enable-libass -
-enable-libopencore-amrnb --enable-libopencore-amrwb --enable-libfreetype --enable-libgsm --enable-libmp3lame --enable-libnut --enable-libopenjpeg --enable-libo
pus --enable-librtmp --enable-libschroedinger --enable-libspeex --enable-libtheora --enable-libutvideo --enable-libvo-aacenc --enable-libvo-amrwbenc --enable-li
bvorbis --enable-libvpx --enable-libx264 --enable-libxavs --enable-libxvid --enable-zlib
  libavutil      52.  1.100 / 52.  1.100
  libavcodec     54. 69.100 / 54. 69.100
  libavformat    54. 35.100 / 54. 35.100
  libavdevice    54.  3.100 / 54.  3.100
  libavfilter     3. 20.109 /  3. 20.109
  libswscale      2.  1.101 /  2.  1.101
  libswresample   0. 16.100 /  0. 16.100
  libpostproc    52.  1.100 / 52.  1.100
Input #0, mov,mp4,m4a,3gp,3g2,mj2, from 'IN24_LittleEndian.mov':
  Metadata:
    major_brand     : JUNK
    minor_version   : 537199360
    compatible_brands: qt  JUNK
    creation_time   : 2012-08-31 14:30:11
    encoder         : Matrox ISO Writer mvdClipISO.dll
    encoder-eng     : Matrox ISO Writer mvdClipISO.dll
  Duration: 00:00:32.16, start: 0.000000, bitrate: 31111 kb/s
    Stream #0:0(eng): Video: dvvideo (dvcp / 0x70637664), yuv420p, 720x576 [SAR 16:15 DAR 4:3], 28800 kb/s, SAR 59:54 DAR 295:216, 25 fps, 25 tbr, 25 tbn, 25 tb
c
    Metadata:
      creation_time   : 2012-08-31 14:30:11
      handler_name    : ?Matrox Alias Data Handler
    Stream #0:1(eng): Audio: pcm_s24be (in24 / 0x34326E69), 48000 Hz, 1 channels, s32, 1152 kb/s
    Metadata:
      creation_time   : 2012-08-31 14:30:11
      handler_name    : ?Matrox Alias Data Handler
    Stream #0:2(eng): Audio: pcm_s24be (in24 / 0x34326E69), 48000 Hz, 1 channels, s32, 1152 kb/s
    Metadata:
      creation_time   : 2012-08-31 14:30:11
      handler_name    : ?Matrox Alias Data Handler

I could provide the example MOV file but it's 100 Mbytes. I'll try to produce a much smaller example to reproduce the problem easily and attach it later.

[Carl Eugen Hoyos]

Please provide a sample, there is no hard file size limit for incoming.

[Ignasi Rius]

Replying to cehoyos:

Please provide a sample, there is no hard file size limit for incoming.

I tried, however I'm afraid it is a limit, since I got this error message: "Maximum attachment size: 2621440 bytes"

I will upload a much smaller example today. Thanks.

[Carl Eugen Hoyos]

"incoming" is explained here: ​http://ffmpeg.org/bugreports.html (no enforced size limit)
An alternative is ​http://www.datafilehost.com/

[Ignasi Rius]

Thanks for your help cehoyos. I've just uploaded IN24_LittleEndian.mov and a short .txt file in relation to this ticket to FFMpeg's FTP server.

[Carl Eugen Hoyos]

Do you think this is a regression?
(This would make the ticket important.)

[Ignasi Rius]

I don't know if it's a regression. All I can tell is that it happens also in version N-39267-g4082198 (~25 March 2012), and it's the same issue going on when using FFmpeg's C API as well.
I have more sample video files if needed (produced by a Matrox XMIO capture board). Just ask.

[Ignasi Rius]

I've been investigating a little bit further how the endianess should be specified in the 'in24' codec.

By default, 'in24' samples are Big Endian, unless there is the 'enda' atom present in the "Sample description atom (stsd)" which according to Apple's QTRef_AtomsResources.pdf, "Determines the endian status of the sound component that interprets data contained in an audio atom list."

Then, I checked if the file I provided has the 'enda' atom, and apparently it does.

I attached a screenshot of dumpster.exe where you can see an unknown data field with the hex-value "0x656e6461" ('enda' in ASCII).

So, I guess that for some reason ffmpeg does not parse this atom correctly.

[Ignasi Rius]

Dumpster Screenshot showin the presence of the 'enda' atom

[Carl Eugen Hoyos]

Two patches are currently discussed that fix the issue, I am just waiting for a developers decision which is better:
​http://thread.gmane.org/gmane.comp.video.ffmpeg.devel/153616/focus=153658
​http://thread.gmane.org/gmane.comp.video.ffmpeg.devel/153616/focus=153629

[Carl Eugen Hoyos]

Replying to irius:

I attached a screenshot of dumpster.exe where you can see an unknown data field with the hex-value "0x656e6461" ('enda' in ASCII).

The relevant information is in the following 16 bit ("0001"), but don't you agree it is interesting that Dumpster also fails to recognize the file as QuickTime-compatible (which it isn't, it fails at least with QuickTime 7.7.2)?

[Ignasi Rius]

Replying to cehoyos:

Replying to irius:

I attached a screenshot of dumpster.exe where you can see an unknown data field with the hex-value "0x656e6461" ('enda' in ASCII).

The relevant information is in the following 16 bit ("0001"), but don't you agree it is interesting that Dumpster also fails to recognize the file as QuickTime-compatible (which it isn't, it fails at least with QuickTime 7.7.2)?

Thanks!. I believed that the reason Dumpster didn't recognize this atom was that it is outdated, and Apple introduced this atom quite "recently", so it doesn't know how to decode newer structs.

Making it clear that I am a total newbie in "MOV" and QuickTime, what do you mean by "QuickTime compatible"? I can play the file on my Quicktime 7.7.2 (1680.56) (Windows 7). I reviewed the patches, and as far as I can understand (which is not too far indeed) it has to do with Matrox branding the file as "JUNK" which causes ffmpeg to not treat it as a regular QT mov file, and as a side effect the "enda" atom is not processed. Is it so?

Anyway, it's quite impressive that in a couple of days there are already 2 possible fixes to this.

[Carl Eugen Hoyos]

Replying to irius:

Replying to cehoyos:

Replying to irius:

I attached a screenshot of dumpster.exe where you can see an unknown data field with the hex-value "0x656e6461" ('enda' in ASCII).

The relevant information is in the following 16 bit ("0001"), but don't you agree it is interesting that Dumpster also fails to recognize the file as QuickTime-compatible (which it isn't, it fails at least with QuickTime 7.7.2)?

Thanks!. I believed that the reason Dumpster didn't recognize this atom was that it is outdated, and Apple introduced this atom quite "recently", so it doesn't know how to decode newer structs.

The page I used for debugging was from 2006 and I suspect the atom was there significantly longer.

Making it clear that I am a total newbie in "MOV" and QuickTime, what do you mean by "QuickTime compatible"? I can play the file on my Quicktime 7.7.2 (1680.56) (Windows 7).

It fails here on vanilla Windows QuickTime.
(Perhaps you have installed some part of the Matrox software that includes support for it?)

I reviewed the patches, and as far as I can understand (which is not too far indeed) it has to do with Matrox branding the file as "JUNK" which causes ffmpeg to not treat it as a regular QT mov file, and as a side effect the "enda" atom is not processed. Is it so?

Apart from the question if mov is "regular" or isom/mp4: Yes (but it is not the enda atom - that would be always processed - but the "QuickTime version 1" audio fields before the enda atom that should not be present in non-QuickTime files and that Dumpster also fails to recognize.)

Anyway, it's quite impressive that in a couple of days there are already 2 possible fixes to this.

The patches were there in less than a day;-)

[Carl Eugen Hoyos]

Should be fixed in current git head, thank you for the sample!