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

[Brendan McCarthy]

Sorry if this info is irrelevant, but  I get this problem with DVB-T  
signals with AC3 audio (Brisbane, Australia). MP2 audio is unaffected.

The video plays fine for a couple of seconds then starts spitting out  
a52 errors (sorry, don't have the output handy)

If I capture the stream with dvbstream -o  mplayer exhibits the  
problem on the captured file. However, remuxing the stream with  
ProjectX results in a file that plays fine.

I can try and put some samples up if you are interested, but it might  
take me a couple of days to get access to the material again.

cheers,
Brendan

On 21/07/2005, at 5:00 PM, Nico Sabbi wrote:

> 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
>
>
> _______________________________________________
> MPlayer-dev-eng mailing list
> MPlayer-dev-eng at mplayerhq.hu
> http://mplayerhq.hu/mailman/listinfo/mplayer-dev-eng
>
>