[MPlayer-dev-eng] MPEG-TS demux problem?

[Nico Sabbi]

Zoltan Hidvegi wrote:

>mwp at overclockers.com.au wrote:
>  
>
>>False alarm :(
>>The older version of mplayer does it also.
>>Seems there is somthing bad about this particular video im trying to encode.
>>    
>>
>
>OK, but still there may be a bug, probably in the MPEG-TS demuxer,
>check out ftp://ftp.mplayerhq.hu/MPlayer/incoming/badac3.ts a 16MB
>sample.
>
>Play it with
>
>mplayer badac3.ts -tsprog 2
>
>-tsprog 0 is a weather radar channel, and it works fine. -tsprog 2 is
>HDTV 1080i, and it gives tons of "a52: error at resampling" messages.
>Also the audio PTS is jumping forward at high speed.  It may be a
>badly muxed stream, but the problem is once mplayer gets into this
>state, it never recovers.  This stream does have a working part if you
>start at the right place:
>
>mplayer badac3.ts -tsprog 2 -sb 3350000
>
>This produces meaningful audio, but the first second is still a bit
>distorted.
>
>This is from OTA ATSC HDTV broadcast, may contain reception errors, but
>more likely suffers from crappy muxing at the TV station.
>
>Zoli
>
>  
>

the problem is not with muxing and timestamps (playing the ts file with 
-demuxer 35
exhibits the same problem), but either in ad_liba52 or in the audio 
bitstream itself:
mplayer can't play  the dumped audio with -demuxer 35 or with -rawaudio 
on:format=0x2000,
while vlc can (maybe it has a better ac3 demuxer?) .
I suspect ad_liba52.c has some well hidden bug in the detection code.

When rewriting the frame parser code for muxer_mpeg I stumbled a couple 
of times on a
situation that I thought impossible to happen: false positive syncword 
detection.
I found a 0x0b77 syncword that identified a valid/correct ac3 frame, but 
with wrong length and sample_rate!!

(As a side note the same thing happens much more often for mp1/2/3).

Tonight I'l give a deeper look at the code.

    Nico