Opened 5 years ago

Closed 5 years ago

#1881 closed defect (fixed)

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

Reported by: irius Owned by:
Priority: normal Component: avformat
Version: git-master Keywords: mov in24 pcm
Cc: Blocked By:
Blocking: Reproduced by developer: yes
Analyzed by developer: no

Description

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.

Attachments (1)

enda_atom_present.PNG (60.0 KB) - added by irius 5 years ago.
Dumpster Screenshot showin the presence of the 'enda' atom

Download all attachments as: .zip

Change History (14)

comment:1 follow-up: Changed 5 years ago by cehoyos

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

comment:2 in reply to: ↑ 1 Changed 5 years ago by irius

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.

comment:3 Changed 5 years ago by cehoyos

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

comment:4 Changed 5 years ago by irius

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.

comment:5 Changed 5 years ago by cehoyos

  • Component changed from undetermined to avformat
  • Reproduced by developer set
  • Version changed from unspecified to git-master

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

comment:6 Changed 5 years ago by irius

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.

comment:7 Changed 5 years ago by cehoyos

  • Priority changed from important to normal
  • Status changed from new to open

comment:8 follow-up: Changed 5 years ago by irius

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.

Changed 5 years ago by irius

Dumpster Screenshot showin the presence of the 'enda' atom

comment:9 Changed 5 years ago by cehoyos

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

comment:10 in reply to: ↑ 8 ; follow-up: Changed 5 years ago by 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)?

comment:11 in reply to: ↑ 10 ; follow-up: Changed 5 years ago by 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.

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.

comment:12 in reply to: ↑ 11 Changed 5 years ago by cehoyos

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;-)

comment:13 Changed 5 years ago by cehoyos

  • Resolution set to fixed
  • Status changed from open to closed

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

Note: See TracTickets for help on using tickets.