Re: [MPlayer-users] Trouble with Mp3 audio in MP4 containers

[The Wanderer <inverseparadox@xxxxxxxxxxx>]

On 12/19/2005 04:48 AM, WireSpot wrote:

> I'm having a problem described once before by someone on the list:
> http://archives.free.net.ph/message/20051106.140616.760437b4.en.html
>
> Problem: with certain MP4 containers, with track 1 = X264 video and
> track 2 = MP3 audio, I get audio artefacts (all kinds of blips, snaps
> and "water splashes") and sequences repeat themselves over and over
> several times before moving on. The sync is generally good, but
> riddled with these problems.

The internal MPlayer demuxer for MP4 files has some holes in its
understanding of what constitutes an audio stream. Use '-demuxer 35' to
tell MPlayer to use the libavformat demuxer, and the audio should play
back fine.

The only MP4 files I have for which I need to use that option also have
a somewhat unusual internal label for the audio stream, such that
libavformat will not detect it as MP3; for those files, I have to also
specify '-ac +ffmp3'.

The libavformat demuxer also appears to have a mistaken idea of what
frame rate the files I have should be played back at; it plays them at
30000/1001, which is much too fast. Specifying '-fps 24000/1001' fixes
the problem, without introducing any new ones.

The things you describe as resulting from your experiments with the
files seem to match up with my own experiences (the -dumpaudio bit in
particular), although I haven't encountered repeating sequences - just
the audio artifacts. It's likely that you're encountering the same
problem. (For that matter, you're most likely also working with the
exact same source files.)

> I also tried muxing with mencoder with "-oac copy -ovc copy
> -audiofile" from the video and audio track, but the resulting AVI has
> bad A/V sync and crashes MPlayer.

If you specify the three above options before the input filename, then
instead of crashing, the output file will be truncated to about 35MB (I
think) when MEncoder halts with "too many audio packets in the buffer".
If you replace '-oac copy' with '-oac mp3lame -lameopts vbr:br=128' the
resulting file should be just fine; when I've done that in my fiddling
around, I have been unable to hear the slight reduction in audio
quality.

> I can always transcode the video into some other codec, but that kind
> of defies the whole purpose of X264, not to mention it would take
> lots of time and possibly look worse.

The video isn't even the problem; the problem is partly in the demuxers
available to MPlayer and partly in the nonstandard audio ID of the
files.

--
      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.

_______________________________________________
MPlayer-users mailing list
MPlayer-users@xxxxxxxxxxxx
http://mplayerhq.hu/mailman/listinfo/mplayer-users