[vlc-devel] Re: Multicast udp streaming from playlist - problems

[Gildas Bazin]

On Wednesday 01 September 2004 12:35, Dermot McGahon wrote:
> 
> >> The two main problems are:
> >>
> >> (1)  Crashes after a period of time. This can vary from between
> >>      forty minutes to four or five hours. The logs files with
> >>      "crash" in the filename should hopefully shed some light on
> >>      what happens just before the crash.
> >>
> >
> > Could you try with a svn version ? (I'm afraid you'll be compeled to
> > compile it yourself, no linux nightely builds).
> 
> I will try with svn.
> 

The MPEG TS/PS demuxers have been entirely re-written so you really should.

> 
> Any explanation of these errors which helps me avoid having to read all
> of the code would be appreciated :)
> 
> I realise that once things get out of whack that follow-on errors might 
not
> mean much.
> 
> 
> * libdvbpsi error (PSI decoder): TS discontinuity (received 10, expected 
0)
> 
>    Received 10 of what? This is probably the PAT. It's saying that it
>    can't read the PAT?
> 

It's an allusion to the discontinuity counters in TS packets. If the demux 
receives 2 consecutive packets with non-consecutive discontinuity counters, 
then a packet was likely lost.

> 
> * [00000229] main audio output warning: buffer is 204733 in advance,  
> triggering downsampling
> 
>    What is the 204733 measured in? Microseconds?
Yes.
>    What does the downsampling achieve? A/V sync?
Yes.

> 
> * [00000223] mpeg_system input warning: packet lost by TS demux for PID  
> 2317: current 7,
>    packet 0
>    [00000223] mpeg_system input warning: packet corrupted, PES sizes do 
not  
> match
>    [00000226] mpeg_audio decoder debug: emulated startcode (no startcode 
on  
> following frame)
>    [00000223] mpeg_system input warning: packet lost by TS demux for PID  
> 257: current 10,
>    packet 13
> 
> 
>     What does current 7 refer to?
Again, I think it refers to the discontinuity counter.

>     Should the PES packets all be the same size?
Not necessarily but the size of the PES packet is coded in the PES header so 
we can detect a mismatch between the expected size and the real size.

>     The stream seems altogether wrong at this point, to state the
>     obvious.
It does look like it.

...
>    [00000229] main audio output warning: computed PTS is out of range  
> (97213), clearing out
>    [00000229] main audio output warning: PTS is out of range (76676),  
> dropping buffer
>    [00000229] main audio output warning: output PTS is out of range  
> (110630), clearing out
>    [00000229] main audio output warning: PTS is out of range (19266),  
> dropping buffer
>    [00000229] main audio output warning: PTS is out of range (-4692),  
> dropping buffer
>    [00000229] main audio output warning: PTS is out of range (-28648),  
> dropping buffer
>    [00000229] main audio output debug: audio output is starving (29236),  
> playing silence
> 
> 
>     What are the output and input PTS?
> 

It's something to do with the A/V sync, ie. mismatch between expected 
playing time and current playing time.
This type of errors will be frequent if a stream is corrupted or if the 
player doesn't receive the data in time for displaying.
This last problem can usually be solved by increasing the caching on the 
client side (--udp-caching=value_in_miliseconds).

> 
> *  [00000229] main audio output warning: PTS is out of range (33146699),  
> dropping buffer
>     [00000223] mpeg_system input warning: packet lost by TS demux for PID  
> 257: current 14,
>     packet 0
>     libdvbpsi error (PSI decoder): TS discontinuity (received 0, expected  
> 15)
>     [00000223] mpeg_system input warning: packet lost by TS demux for PID  
> 2315: current 3,
>     packet 8
>     [00000223] mpeg_system input warning: packet lost by TS demux for PID  
> 2317: current 8,
>     packet 11
>     Killed
>     Mon Aug 30 17:38:27 IST 2004
>     [dermot at epia dermot]$
> 
>     What could cause it to be killed?
> 

Likely some corrupted data fed to the decoders.
Decoders are not supposed to crash on bad streams though, but it seems that 
some of them are not error resilient enough.

--
Gildas

-- 
This is the vlc-devel mailing-list, see http://www.videolan.org/vlc/
To unsubscribe, please read http://developers.videolan.org/lists.html