[MPlayer-advusers] mp3 decoding problem

[The Wanderer]

The Wanderer wrote:

> The Wanderer wrote:
> 
>> compn wrote:
>>
>>> decoding this file causes audio glitches in mplayer
>>> -demuxer 35, -ac ffmp3, -dumpaudio, nothing helps
>>> user reports it playing fine in xine.

Having now tested the original video: it does not play in xine for me
(aborts immediately with "error, NO frame"), and while vlc does play it
with perfectly fine audio, it also gives me severely hashed video (to
the point that the subtitles are quite thoroughly illegible).

(These are stock xine and vlc from current Debian unstable.)

>>> http://home.twmi.rr.com/compn/mp3audioproblem.mp4
>>> 2.1mb
>> 
>> I have the what is almost certainly the same file (~233MB in
>> total), and have experienced a number of different problems with it
> 
> I'll note that there are now two of these files that I know of, from
> the same source, both exhibiting very similar problems (although,
> from my limited examination, the second less so than the first). For
> the time being, there are also working XviD/AVI versions being
> released in parallel to the problematic x264/MP4 versions, but that
> will not be the case for much longer.

They're up to four files now. There has been a fair amount of discussion
of these problems (or what I think are the same ones) on the forums
associated with the source of the files, and some people there may be
willing to help; if being able to ask questions of the people
responsible for creating the files would be useful, then I can see if
they would be willing to cooperate.

As noted above, vlc can play the audio of any of these source files just
fine. However, if I extract the audio with -dumpaudio and play that with
anything - MPlayer, ffplay, mpg321, vlc - it exhibits the same popping
and scratchiness that are present when playing the source file with
MPlayer. Since the audio itself is not damaged (else vlc would not be
able to play it correctly), and -dumpaudio is (according to my
understanding) supposed to be a byte-for-byte copy of the audio stream,
the fact that the dumped audio *is* damaged presumably means that
MPlayer is misunderstanding what exactly constitutes the audio stream;
that in turn would mean that the problem lies in the demuxer.

If no one else is interested in trying to figure out what the problem
here is, I'm quite willing to do the work myself - if someone can clue
me in on how to go about figuring out what part of the relevant code
might be responsible. I know how to track down the cause of a crash (in
general, anyway), and I have some experience with tracking down
non-crashing bugs in code I know in detail from having written it myself
- but I have next to *no* understanding of the MPlayer code, and so no
idea of where to get started. (I've never even been able to follow the
flow of execution from program start, which is the only place I can
think of to start trying to *gain* such an understanding.) The only
thing I could really do to try to fix things, without some help, would
be to essentially rewrite random parts of demux_mov.c and see what
happens; that would probably fix the problem eventually, through the
mechanics of any evolutionary process, but it would probably have fried
my brain well before that point.

I'd also like to note, for the record, that if this post - like my last
two on the subject - gets no attention at all, I shall begin to get
somewhat angry.

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