[MPlayer-advusers] mp3 decoding problem (also libavformat issues)

[The Wanderer]

compn wrote:

> On Tue, 22 Nov 2005 22:56:01 -0500 The Wanderer
> <inverseparadox at comcast.net> wrote:
> 
>> compn wrote:

>>> this is incorrect, i found if you combine such commandlines, you
>>> can play the audio correctly in mplayer, i figured this out by
>>> studying how vlc would do it
>>> 
>>> mplayer 163.mp4 -demuxer 35 -ac +ffmp3
>>> 
>>> but i'm told that the video speeds up/plays incorrectly
>> 
>> It does; if you also specify '-fps 24000/1001' it will play back
>> perfectly. I've seen this discussed on the forums of the people who
>> released the files, and hadn't reached the point of thinking to
>> post it here.
>> 
>>> at least this gives you correct audio. altho i'm at a loss at why
>>> ffmp3 is not handling mp3 audio when demuxed with lavf... old
>>> codecs.conf or missing entry?
>> 
>> For one thing, the audio in the file is misdetected by FFmpeg - it
>> thinks that it's AAC for some reason. (Probably to do with the fact
>> that
> 
> i think i've narrowed down the bugs, maybe they are correct, maybe
> i'm 100% wrong :)
> 
> bug #1 in mp3 in mp4 with -demuxer 35 is libavformat using fourcc
> instead of the mpeg4 elementary stream descriptor atom to pick which
> audio codec to use.
> 
> does mplayer use the elementary stream descriptor atom? i think yes?
> does ffmpeg need to use this instead of fourcc?
> 
> AAC:
> MOV track #0: 105 chunks, 948 samples
> Audio bits: 16  chans: 2  rate: 44100
> MOV: Found MPEG4 audio Elementary Stream Descriptor atom (51)!
> Fourcc: mp4a
> 
> MP3:
> MOV track #1: 2886 chunks, 0 samples
> Audio bits: 16  chans: 2  rate: 48000
> MOV: Found MPEG4 audio Elementary Stream Descriptor atom (35)!
> Fourcc: mp4a
> 
> 
> bug #2 is mplayer's mp4 demuxer is not demuxing the mp3 audio like 
> libavformat.

If by "like" you mean "in the same way that libavformat does", then yes.
By some means MPlayer appears to be using an incorrect idea of what data
is and is not part of the audio stream, so it passes either too little
data (chopping off in the middle of a frame, or something) or too much
data (appending unrelated data after the end of the correct data) to the
audio codec.

> bug #3 is libavformat demuxing the framerate improperly

It may not just be libavformat, actually. The file plays back too fast
(albeit not as much so) in MPlayer as well, when not specifying -demuxer
35. I've gotten it to play back at what appears, subjectively, to be the
correct rate by specifying '-fps 22.5' (I got the number from dividing
the number of frames by the number of seconds in one of my early
transcoding-with-MEncoder test runs, although I haven't been able to
reproduce that since), but the default framerate even without
libavformat's demuxer appears to have some hiccups in it. (More likely,
given that the default framerate with MPlayer's demuxer is 24000/1001,
this is another effect of the bug you've labeled as #2.)

(I wasn't entirely certain of the above, so I went back and tested just
now, and it appears to be the case - judging by the fact that the audio
and video do not get out of sync, and the audio is definitely playing
too fast. I'll note that although the audio plays at the correct speed
with -fps 22.5, it *does* then get out of sync with the video.)

> can someone verify this using ffplay on the same sample?

Unfortunately no, because currently if I pass one of the MP4 files as
input to either the ffmpeg or ffplay binary I get system-overloading
floods of "[aac @ 0x8410e70]faac: frame decoding failed: Channel
coupling not yet implemented" errors (I think it's literally hundreds if
not thousands per second). In the case of ffplay, the display window
does open, but I get neither video nor audio output. This is a result of
the same bug you've labeled as #1, above. If I could figure out how to
force ffplay to use a given audio codec - in the same way that you can
in MPlayer with the plus sign in '-ac +ffmp3' - then I'd be able to test
it, but from everything I've seen there doesn't appear to be a way to do
that.

I have, in the past, been able to get *some* output from ffplay on what
I seem to remember were the same files (it's a little blurry in my
memory, because I've done so many tests with remuxed/transcoded
versions), but current CVS behaves as I've described above.

-- 
       The Wanderer

Warning: Simply because I argue an issue does not mean I agree with any
side of it.

Secrecy is the beginning of tyranny.