Misdetection of MP3 as AAC in MP4 files

[inverseparadox@…]

I have a growing set of MP4 files which exhibit audio problems in MPlayer. In an
attempt to work around those problems, I've attempted to transmux or transcode
them to another format using FFmpeg - and run into some unexpected hiccups.

These are the same files for which I have reported a bug, apparently involving
the demuxer, in MPlayer - but some at least of the problems I list below appear
to be specific to FFmpeg.

Note that the initial component assignment for this bug is just a guess; the
actual error (or the initial one, at least) appears to be in the codec-detection
code, which for all I know might not be in either libavcodec or libavformat. It
might be a good idea to add other possible components to the list - at least
libavutil, now that that exists.

==
wanderer@pegasus:/tmp$ ffmpeg -i /home/pub/video/One\ Piece/One\ Piece\ -\
165.mp4 -acodec copy -vcodec copy op165-v1.avi
ffmpeg version CVS, build 3277056, Copyright (c) 2000-2004 Fabrice Bellard

configuration: --enable-mp3lame --enable-vorbis --enable-faad --enable-a52

--enable-pp --enable-shared-pp --enable-faadbin --enable-pthreads --enable-gpl
--enable-libogg --enable-theora --enable-x264 --enable-xvid

built on Nov 8 2005 00:42:40, gcc: 3.3.5 (Debian 1:3.3.5-12)

Seems that stream 0 comes from film source: 2997.00 (2997/1) -> 24.00 (24/1)
Input #0, mov,mp4,m4a,3gp,3g2, from '/home/pub/video/One Piece/One Piece - 165.mp4':

Duration: 00:23:05.3, start: 0.000000, bitrate: 1389 kb/s
Stream #0.0, 24.00 fps: Video: h264, yuv420p, 640x480
Stream #0.1: Audio: aac, 48000 Hz, stereo

Output #0, avi, to 'op165-v1.avi':

Stream #0.0, nan fps: Video: h264, 640x480, q=2-31
Stream #0.1: Audio: mp4a / 0x6134706D, 48000 Hz, stereo

Stream mapping:

Stream #0.0 -> #0.0
Stream #0.1 -> #0.1

Press [q] to stop encoding
frame=33215 q=-10267561.3 Lsize= 333202kB time=1385.3 bitrate=1970.4kbits/s
video:215583kB audio:18935kB global headers:0kB muxing overhead 42.079480%
==

The first problem with this is that the audio contained in these MP4 files -
according to all of 'mplayer -identify', the source which created them, and the
fact that if I '-dumpaudio' I can play the resulting file with mpg321 - is MP3,
not AAC. FFmpeg identifies it incorrectly. This is probably the cause of some,
perhaps even all, of the other problems. I've tried specifying the audio codec
explicitly, via 'ffmpeg -acodec mp3 -i inputfile -acodec copy outputfile' or the
like, and it has made absolutely no difference. This is definitely a bug of some
flavor.

The second problem is that despite having been told '-acodec copy -vcodec copy',
FFmpeg is going from '24.00 fps h264' to 'nan fps h264' and from misidentified
'aac' to 'mp4a' (which may or may not be the same thing, I've encountered
conflicting answers).

MPlayer cannot play the resulting file; it floods the terminal with

==
FAAD: Failed to decode frame: Maximum number of scalefactor bands exceeded
FAAD: error: Maximum number of scalefactor bands exceeded, trying to resync!
==

(repeat the latter line 9 more times) over and over and over until I quit. The
player window does open, but - at least for as long as I've waited - displays
only a black screen.

ffplay cannot play it either; it exits immediately with a simple "could not open
codecs" error. As a side note, ffplay *can* play the original file, but not well

• for one thing, probably due to the misidentified audio, although the video is

reasonable (it takes too long to begin and hangs after a while, but that could
easily be bottlenecked on the other problem) it is accompanied by only silence;
for another thing, probably based on the same misidentification, it floods the
terminal with "[aac @ 0x8410e70]faac: frame decoding failed: Channel coupling
not yet implemented" (and bogs the system down heavily in the process) until
exit, which is usually achieved only with kill -9.

If I explicitly specify '-acodec mp3' for the input file, the only visible
changes are that MPlayer a) prints the contents of
MSGTR_MPDEMUX_AVIHDR_EmptyList and MSGTR_CouldntDetFNo, and b) thinks that the
video is 'avc1' instead of H.264. (There are other ways to generate this
particular mixup from these files; I don't remember any of them offhand, but I
remember other people having described it.)

If I remux to FFmpeg's idea of MP4 rather than to AVI, the result is only
slightly less ugly. MPlayer cannot play the file at all; it just floods the
terminal with occasional "Unknown NAL code" errors and huge numbers of "Error
while decoding frame!" errors, and the video window never opens. ffplay fails in
much the same way as it does on the original file, except perhaps slightly
worse; although the video window did open, it never got to the point of playing
video at all.

If I replace the '-acodec copy' with '-acodec mp3', things don't even get as far
as producing an output file. FFmpeg spews out floods of the same AAC-related
"Channel coupling not implemented" errors as I got from ffplay, and transcoding
never gets anywhere. (Except for the replacement of the output file's 'Stream
#0.1" line with one giving the default values for MP3 encoding, the rest of the
terminal output is the same.)

...I think there was another situation I was going to describe, but I don't
remember what it might have been. (I don't *think* that transcoding the video
but leaving the audio alone did anything else strange...) In any case, hopefully
the above should be enough for the time being.

[diego@…]

Is this still a problem with the updated libfaad etc? Could you provide a
sample file?

[inverseparadox@…]

Not sure exactly which parts of the problem to provide updates on, here. With
current CVS trees:

FFmpeg no longer produces visibly incorrect console output when remuxing. (It
identifies the audio as MP2, rather than MP3, but it's possible that that may in
fact be correct.)

ffplay plays the original file without problems, though it fails with a "SDL
Parachute Deployed" segfault (and a 'glibc detected' etc. abort) on the remuxed
file.

MPlayer, rather than doing the ugly things it used to do with the audio, now
produces no sound at all on either the original file or the remuxed file;
specifying '-demuxer 35' just produces a spew of FAAD decoding errors on the
console.

MPlayer *can* play the file with no apparent errors if I transcode the audio to
MP3 rather than just remuxing - but since it's supposed to be MP3 or at least
MP2 to begin with, this is less than perfect.

MPlayer produces no sound, and video with varyingly incorrect colors, on a
version of the file remuxed to FFmpeg's idea of MP4.

The file I made the above observations with is now being uploaded to incoming/,
filename op165-mp3audio-miscproblems.mp4. I'm not entirely sure what the current
state of all of the problems I've observed with these files is, and it took
enough time and experimentation to write it all out the first time that I'm not
much interested in doing it again if there's no need to; therefore the
accompanying text file is merely a pointer to this bug (which has the advantage
that updated status reports can be provided if they develop).

[Dominik 'Rathann' Mierzejewski]

MPlayer-060518 plays audio as mp3, but there're lots of stutters and
high-pitched glitches. Both mp3lib and ffmp3 codecs exhibit the problem. I
haven't tested with libmad. -demuxer lavf fails in the same way you described.

[inverseparadox@…]

Er, yes; IIRC, MPlayer always correctly detected the audio as being MP3 - it was
FFmpeg which misidentified it as AAC. The MPlayer bug is in the demuxer, such
that it drops part of each chunk of the audio stream and produces the pops and
skips you mentioned; it also, for presumably related reasons, plays the file too
fast (playback at approximately the correct subjective speed can, for at least
some of my sample files, be achieved with -fps 22.5).

(Unless you're just noting that the 'MPlayer produces no sound' bit is not
currently true for the original file, in which case I confirm that; it is,
however, true for the remuxed-to-AVI version. This is with the default demuxer,
I haven't retested with -demuxer lavf.)

I'm a little curious as to why an FFmpeg bug report is seeing only
MPlayer-related discussion... there is, after all, a separate bug report (bug
403) for the MPlayer side of the problem.

[mans@…]

The sample file plays fine with current SVN.

[inverseparadox@…]

Depends what you mean by "works". It plays, yes (using ffplay), and the two
specific described problems - misdetecting MP3 audio as AAC and going from 24.00
fps H.264 to nan fps H.264 - no longer occur (although the audio is still listed
as "mp2", which is inconsistent with every other check I've tried - not that
I've tried many)... but. The primary purpose of FFmpeg is transcoding/remuxing -
and there, problems still remain. The only way to produce a playable file from
the sample using FFmpeg appears to be to transcode the audio; any operation
which involves copying it is not playable (correctly, or in some cases at all)
by either ffplay or MPlayer.

Remuxing the file to AVI, with the most basic possible command line (ffmpeg -i
infile.mp4 -vcodec copy -acodec copy outfile.avi), produces a file which:

Cannot be played by ffplay; it exits immediately upon opening the playback
window, with a SDL-parachute segfault.

Is misdetected by MPlayer as containing AAC audio, and played as a result with
no sound (albeit, now, at the correct frame rate). Appending '+mp3' or '+ffmp3'
to the MPlayer command line results in MPlayer playing less than half a second
of audio and then hanging - no CPU usage, no disk usage, but no response even to
'q'; it has to be killed (Ctrl-C works). Using '-demuxer 35', MPlayer segfaults

• badly; the program hung immediately after printing the "this shouldn't happen"

message, and it took me two Ctrl-Cs and eventually a kill -9 to take it all of
the way down.

Remuxing the file to FFmpeg's idea of MP4, with a similar command line, produces
a file which:

Cannot be played by ffplay - it exits less than a second after opening the
playback window, having played no video and no audio, with a SDL-parachute segfault.

Is played by MPlayer with severely damaged video (black background displayed as
gray, for instance), and no sound by default; adding '-ac +ffmp3' produces
equally severely garbled audio. With '-demuxer 35', MPlayer again segfaults,
albeit not as badly as with the AVI.

As far as I can tell, the only two ways in which this can be said to "work" are
that the misdetection itself no longer occurs (as reported in the console
output) and that ffplay is capable of playing back the file. It does not appear
to be possible to use FFmpeg to produce a playable version of the file without
transcoding the audio; even after transcoding the audio, ffplay still displays
the video as blank (although MPlayer can play the version just fine).

Whether or not this specific bug has been resolved (and I'm leaving it marked
that way because I'm not entirely certain that the remaining problems are
related to the original report), there is still a bug remaining somewhere - the
most likely candidates for where, to me, seem to be either the streamcopy code
somewhere or both the AVI *and* MP4 muxers (and possibly others, I haven't
tested). Either that or the apparent misdetection as 'mp2' is related somehow...

[mans@…]

You're right, there are some issues with this file. I'm reopeing the bug
so I won't forget it, even though the title is somewhat misleading.

[diego@…]

Can this be closed or moved to the new FFmpeg bugtracker, please?

[compn]

seems to work in svn for me. if there is still a problem, please use ffmpegs tracker to report it.

[cami:~/greenscreen] compn% ffmpeg -i /Volumes/D\$/mplayer-testclips/\[A-Destiny]_Konjiki_no_Gash_Bell_-_65_\[71EE362C].mp4 -vcodec copy -acodec copy outfile.avi
FFmpeg version SVN-r10476, Copyright (c) 2000-2007 Fabrice Bellard, et al.

configuration: --extra-cflags=-I/usr/local/include/SDL --extra-ldflags=-L/usr/local/lib
libavutil version: 49.5.0
libavcodec version: 51.43.0
libavformat version: 51.12.3
built on Sep 12 2007 00:16:17, gcc: 3.3 20030304 (Apple Computer, Inc. build 1809)

Input #0, mov,mp4,m4a,3gp,3g2,mj2, from '/Volumes/D$/mplayer-testclips/[A-Destiny]_Konjiki_no_Gash_Bell_-_65_[71EE362C].mp4':

Duration: 00:22:49.9, start: 0.000000, bitrate: 6 kb/s
Stream #0.0(und): Video: h264, yuv420p, 640x480, 23.98 fps(r)
Stream #0.1(jpn): Audio: mp3, 48000 Hz, stereo, 128 kb/s

Output #0, avi, to 'outfile.avi':

Stream #0.0(und): Video: avc1 / 0x31637661, yuv420p, 640x480, q=2-31, 23.98 fps(c)
Stream #0.1(jpn): Audio: 0x0000, 48000 Hz, stereo, 128 kb/s

Stream mapping:

Stream #0.0 -> #0.0
Stream #0.1 -> #0.1

Press [q] to stop encoding
[mov,mp4,m4a,3gp,3g2,mj2 @ 0x3968d4]stream 0, offset 0x10096d: partial file
frame= 102 fps=102 q=838.7 Lsize= 656kB time=4.3 bitrate=1263.7kbits/s
video:572kB audio:68kB global headers:0kB muxing overhead 2.563813%

[cami:~/greenscreen] compn% mplayer outfile.avi
MPlayer dev-SVN-r24201-3.3 (C) 2000-2007 MPlayer Team
AltiVec found
CPU: PowerPC

Playing outfile.avi.
Cache fill: 10.94% (671994 bytes)
AVI file format detected.
[aviheader] Video stream found, -vid 0
[aviheader] Audio stream found, -aid 1
VIDEO: [avc1] 640x480 24bpp 23.976 fps 1101.4 kbps (134.4 kbyte/s)
Clip info:

Software: Lavf51.12.3

Opening video filter: [eq]
==========================================================================
Opening video decoder: [ffmpeg] FFmpeg's libavcodec codec family
Selected video codec: [ffh264] vfm: ffmpeg (FFmpeg H.264)
==========================================================================
==========================================================================
Opening audio decoder: [mp3lib] MPEG layer-2, layer-3
AUDIO: 48000 Hz, 2 ch, s16be, 128.0 kbit/8.33% (ratio: 16000->192000)
Selected audio codec: [mp3] afm: mp3lib (mp3lib MPEG layer-2, layer-3)
==========================================================================
AO: [macosx] 48000Hz 2ch s16be (2 bytes per sample)
Starting playback...
VDec: vo config request - 640 x 480 (preferred colorspace: Planar YV12)
VDec: using Planar YV12 as output csp (no 0)
Movie-Aspect is undefined - no prescaling applied.
VO: [quartz] 640x480 => 640x480 Planar YV12 [fs]

Exiting... (End of file)

[inverseparadox@…]

What if the problem doesn't seem to be confined to FFmpeg?

Admittedly, there is almost certainly a bug in the FFmpeg MP44 muxer. However, I believe that there is also still a bug in the MPlayer MP4 demuxer - and possibly other bugs elsewhere which would be related to this.

The file you tested with is not the same as the one I originally reported the problem on, which I uploaded to incoming at one point - the filename is in an earlier post. (I'm not sure why you tested this with a different file, which does not even appear to come from the same source.) Retesting with that file, I get:

The original file plays fine with ffplay and with 'mplayer -demuxer lavf'. With the native MPlayer demuxer, there are still the crackling/popping sounds in the audio which are the core of the other bug I mentioned in the original bug report.

After remuxing to AVI with FFmpeg, the result plays fine both with ffplay and with MPlayer.

After remuxing to MP4 with FFmpeg, however, there are major problems. ffplay segfaults on the resulting file. 'mplayer -demuxer lavf' does as well. Plain 'mplayer' plays slightly-damaged video and no audio, because it still detects the audio as AAC. 'mplayer -ac +mp3' plays similarly damaged video and what sounds like ridiculously fast audio. 'mplayer -ac +mp3 -demuxer lavf' plays perfectly.

Obviously there is a bug in the FFmpeg MP4 muxer and/or in ffplay. However, that does not eliminate the fact that there still appears to be a bug in MPlayer, in that although FFmpeg claims to have muxed MP3 into the MP4 container exactly as it did into the AVI container, MPlayer detects it as AAC.

I strongly suspect that the bug on the MPlayer side is the same one which leads to skips and pops in the audio when playing from MP4 files without '-demuxer lavf'.