Scratchy audio and too-fast playback in some MP4 files

[inverseparadox@…]

The MP4 files available via ​http://www.kaizoku-fansubs.com/torrent/index.php are
not played back correctly by MPlayer. Some people have reported that xine can
play them correctly (although it does not play them at all for me), and others
have said the same about VLC (which produces severely hashed video for me, but
is otherwise fine).

The basic problems take two forms.

First, and less severe: the audio at least, and perhaps the video, is played
back too fast (as compared against the versions of the content available via the
same site in AVI form). The reported framerate is 23.976, which is what one
would expect - but at one point, when attempting to fix the various problems by
remuxing and/or transcoding, I noted that the ratio of seconds to frames in the
in-progress output was approximately 22.5; when I specified that framerate
explicitly to MPlayer, the MP4 file played back at the correct expected speed.
It has been observed that this part of the problem is not exhibited by MPlayer
1.0pre7; I have hypothesized that it may be related to a change, which I
remember being discussed but have not been able to track down, from using the
codec framerate rather than the container framerate (in cases where they are
different) to the reverse.

Second, the audio is played full of scratches and popping sounds, roughly
similar to what one might expect from a poor-condition vinyl record. Although
there are numerous errors printed to the console when this happens, I think that
the problem is neither in the file itself nor in the audio codec. The reason I
think the problem is not in the file is that when I play the same file in VLC,
the audio is flawless. The reason I think that the problem is not in the audio
codec is that when I dump the audio, using 'mplayer -dumpstream', and play the
resulting file using any player - including VLC - the broken sound is still
present. Since -dumpstream is, IIRC, supposed to be a byte-exact copy of the
audio stream, and since the audio in the source file has ben demonstrated to not
be damaged, then since the audio in the dumped file *is* damaged the only
possibly obvious conclusion seems to be that MPlayer is not understanding
correctly what constitutes the audio stream - i.e., it is passing incorrect
and/or incomplete data both to the audio codec and to the audio dumper.

As a side note, not directly related to this bug report: some parts of FFmpeg,
and possibly (according to my memory although I've been unable to reproduce it)
of MPlayer, appear to think that the audio in this file is AAC. Instead, it is
actually MP3.

I can provide any logs and conduct any experiments which are desired; I haven't
given any here because not only does there not appear to be an obvious place to
put them, I'm not 100% certain exactly what would be useful (it's not exactly
obvious, unlike with - say - a crash bug).

[compn]

workaround for audio : mplayer 163.mp4 -demuxer 35 -ac +ffmp3

[compn]

upon futher research , this bug appears to be 2 or 3 bugs total...

bug #1 is libavformat
libavformat seems to be using the aac codec for all 'mp4a' fourcc files.

bug #2 is mplayer's mp4 demuxer is not behaving like libavformat's mp4 demuxer.
libavformat can demux the file properly

bug #3 is that mplayer and/or libavformat are having problems finding the
correct fps.

[compn]

added sample url.

[inverseparadox@…]

An extension to the workaround: -fps 24000/1001. Without that, MPlayer will use
30000/1001, which for these files at least is incorrect.

How permanent is that sample URL? For that matter, how big is the sample file
(full ~233MB, or just a small clip)? If it's small enough, it would probably be
a good idea to post it here as an attachment.

Possibly unrelated, and (if so) deserving of bugs of their own, a couple of
other points.

One, seeking in the latest such file with -ss brings the audio to the correct
point but leaves the video far behind; attempting to compensate with
ridiculously huge values (i.e., more than a third of the total -ss value in one
test) for the -delay option did bring the two into sync, but did not seek to the
requested time. This is probably either a bug in libavformat's MP4 demuxer or a
bug in the codec handling the (H.264) video.

Two, remuxing the file with all of the 'workaround' options and '-oac copy -ovc
copy' not only requires '-fafmttag' to change the audio ID value from 0x6134706d
to 0x55 but also aborts after writing about 30-60 MB with "Too many audio
packets in the buffer: (4096 in 1572864 bytes)." and a workaround recommendation
which doesn't apply, since the source is not an AVI file. Attempting to play the
truncated output file works, albeit with an error message about "switching to
-ni mode", but produces no audio. Transcoding the audio with -oac mp3lame does
not produce any similar behaviour.

[compn]

anime-destiny seems to be having the same problems, altho the sync is ok, the
audio still needs -demuxer 35 (for both aac and mp3 audio) and -ac +ffmp3 for mp
3

[A-Destiny]_Konjiki_no_Gash_Bell_-_65_[71EE362C].mp4

is one of the problem files, torrents are availible at:

​http://anime-destiny.org

[aph@…]

Using either marriat or locally-compiled mplayer 1.0pre8, I still experience
problems with certain files, e.g. [K-F]_One_Piece_162_[1AB178EF9].mp4 or
[K-F]_One_Piece_164_[8EFAD2F0].mp4:

• scratchy/blippy audio
• loss of a/v sync

However, [K-F]_One_Piece_163_[1918D318].mp4 plays fine with no arguments.

162 has a audio rate of 48000, 163 uses 44100.

As a workaround, files 162 and 164 can be played with these arguments:

-ac +ffmp3 -demuxer lavf

as described above. However, if you seek, you'll lose A/V sync.

In previous entries, they talk about having to set -fps manually -- I did not
find it to be the case that mplayer got the FPS wrong, either without arguments
or with the lavf demuxer.

Files 164-168 seem to have the problem, but 169 and 170 do not. That's all I
checked. This problem feels like a bug in the K-F encoding -- maybe this is
something mplayer should be tolerant of, maybe not. The only positive
suggestion I can make is that someone who knows about the nuts and bolts of the
MP4 container might check the files....

[reimar]

Uploading the sample files to our ftp server with a desriptive text file (as
described in bugreports.txt) might give this at least a chance to be fixed. At
least I can't download any torrents (even if the urls would work).

[compn]

op165-mp3audio-miscproblems.mp4
op165-mp3audio-miscproblems.txt
op174 - bad pts vs. time base numerator.mp4
op174 - bad pts vs. time base numerator.txt

in /incoming are the sample files which this bug is based on.
please move to samples :)

[compn]

the misdetection of mp3 with -demuxer lavf should be fixed.

[compn]

* Bug 810 has been marked as a duplicate of this bug. *

[compn]

all the files seem to play correctly now that lavf demuxer is default for mp4/mov

please reopen this bug if you find a problem.