[MPlayer-dev-eng] Re: Chasing audio bugs with a52/ac3

[Norman Ramsey]

 > I'm trying to play an ATSC stream from my newly installed AirStar
 > HD5000 card in mplayer, and am experienceing some problems, I
 > believe with a52/ac3.  For a minute or so, video and audio play
 > well, but I experience tons of errors:

I can confirm similar problems, primarily with MPEG-2 transport
streams that are recorded from broadcasts of Fox stations.  I have
these observations:

  1. The problem occurs with the latest CVS mplayer (within the last
     24 hours).

  2. The patch that Scott W. Larson just posted to mplayer-dev-eng
     helps some, in that it reduces the number of CRC failures, but I
     still get a great many errors of the form

       a52: error at resampling

     and eventually mplayer fails with these error messages:

        Too many video packets in the buffer: (340 in 8395636 bytes).
        Maybe you are playing a non-interleaved stream/file or the codec failed?
        For AVI files, try to force non-interleaved mode with the -ni option.
        alsa-space: xrun of at least 0.242 msecs. resetting stream3% 15.5% 310 0 22%    
        A:20546.1 V:20560.3 A-V:-14.221 ct:  0.103 2481/2481 17% 15%  5.5% 310 0 0%     
        Too many audio packets in the buffer: (4096 in 747728 bytes).
        Maybe you are playing a non-interleaved stream/file or the codec failed?
        For AVI files, try to force non-interleaved mode with the -ni option.

  3. In an attempt to diagnose the problem, I tried

        mplayer -vo null -dumpaudio -dumpfile offending.ac3 offending.ts

     I then attempted to play 'offending.ac3' using the standalone
     'a52dec' program, which is available as a Debian package.  This
     standalone program uses liba52, but possibly not the same version
     that mplayer uses.  In any case, although there was some noise
     and some 'skips', the 'a52dec' program successfully gets through
     a full 30 minutes without failing and without garbling the audio.
     By contrast, mplayer fails within 5 minutes.

  4. On many similar files, mplayer gets so confused that it is not
     possible to resync by using the seek keys. (uparrow/downarrow and
     friends).  N.B. I don't know if this is still true with Scott's
     patch. 

I don't know the code base, but I'm willing to hypothesize that at
least one of the following things is going wrong:

  A. Perhaps mplayer is demuxing the transport stream incorrectly and
     so is feeding trash to the audio codec.  (The success of
     -dumpaudio may indicate that such a failure is unlikely; I don't
     know the code well enough to tell.)

  B. Perhaps mplayer is using a less robust version of liba52 than the
     one in the 'a52dec' program.  Web searches suggest that liba52 is
     a dead project, and I don't know how to find the 'best' master
     version.

  C. Perhaps mplayer's codec is using the same liba52 as 'a52dec', but
     in less paranoid ways.  In other words, perhaps the AC-3 stream
     contains errors to which 'a52dec' is resilient but which cause
     mplayer to fail.  If this is the case, then porting some of
     a52dec's logic into mplayer might be enough to fix the problem.
     I would be happy to make an attempt a month or so hence.

I would be grateful if somebody who knows the code base could suggest
how best to narrow down the possibilities.  There seem to be a
significant group of people at pchdtv.com who are also being hurt by
similar problems, and I would be happy to contribute to a solution.


Norman