[vlc-devel] Re: Multicast udp streaming from playlist - problems
Dermot McGahon
dermot at dspsrv.com
Wed Sep 1 12:35:33 CEST 2004
On Tue, 31 Aug 2004 18:06:14 +0200, Benjamin PRACHT
<bigben+spam at videolan.org> wrote:
> On Tue, Aug 31, 2004, Dermot McGahon wrote :
>> Resending without attachments. Log files at:
>>
>> http://www.bqbsoftware.ie/crashes_vlc/
>> http://www.bqbsoftware.ie/channel_change/
>> http://www.bqbsoftware.ie/live_vlc/
>> ------------------------------------------------
[-]
>> 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.
> Morfeover, could you check if VLC behaving anormaly befor being killed ?
> (memory consumption for instance)
I can keep an eye on memory, yes.
There wasn't anything obvious in the logs?
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?
* [00000229] main audio output warning: buffer is 204733 in advance,
triggering downsampling
What is the 204733 measured in? Microseconds?
What does the downsampling achieve? A/V sync?
* [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?
Should the PES packets all be the same size?
The stream seems altogether wrong at this point, to state the
obvious.
* [00000229] main audio output warning: resampling stopped after 1555891
usec
[00000229] main audio output warning: buffer is 101965 in advance,
triggering downsampling
[00000229] main audio output warning: output PTS is out of range (1396),
clearing out
[00000229] main audio output warning: input PTS is out of range (16762),
trashing
[00000229] main audio output warning: resampling stopped after 1716344
usec
[00000229] main audio output warning: computed PTS is out of range
(42978), clearing out
[00000229] main audio output warning: PTS is out of range (24023),
dropping buffer
[00000229] main audio output warning: output PTS is out of range
(48914), clearing out
[00000229] main audio output warning: PTS is out of range (106),
dropping buffer
[00000229] main audio output warning: PTS is out of range (-23810),
dropping buffer
[00000223] mpeg_system input warning: packet lost by TS demux for PID
2315: current 0,
packet 9
[00000223] mpeg_system input warning: packet lost by TS demux for PID
2317: current 1,
packet 12
[00000223] mpeg_system input warning: packet corrupted, PES sizes do not
match
[00000223] mpeg_system input warning: packet lost by TS demux for PID
257: current 4,
packet 7
libdvbpsi error (PSI decoder): TS discontinuity (received 7, expected 5)
[00000226] mpeg_audio decoder debug: emulated startcode (no startcode on
following frame)
[00000229] main audio output warning: computed PTS is out of range
(37436), clearing out
[00000229] main audio output warning: PTS is out of range (29042),
dropping buffer
[00000229] main audio output warning: output PTS is out of range
(45566), clearing out
[00000229] main audio output warning: PTS is out of range (-39086),
dropping buffer
[00000229] main audio output debug: audio output is starving (36514),
playing silence
[00000223] mpeg_system input warning: packet lost by TS demux for PID
2317: current 0,
packet 11
[00000223] mpeg_system input warning: packet lost by TS demux for PID
2315: current 13,
packet 15
[00000223] mpeg_system input warning: Oversized PES packet for PID 2317:
expected 6158,
actual 6164
[00000223] mpeg_system input warning: packet corrupted, PES sizes do not
match
[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?
* [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?
>> (2) Using any method to change stream (n & p from the keyboard;
>> console interface next and previous; web interface next and
>> previous): there are *some* channels which cause jumpiness
>> on channel change. Changing either to or away from these
>> channels will cause a three or four second settling period.
>> I will dump some of this content to disk and try and see what
>> is unusual about it, but I am hoping that the log files
>> might show up what is unusual.
>>
>
> Could you check if this is not related to some network latency ? Joining
> a multicast group can take several seconds if the streamer in not on the
> same subnet than the client...
Definitely not network latency. When this is working well, it works very
well! Channel change times are about 1.5 seconds, including joining the
multicast group, buffering, decoding, video output ..
The content is UK channels from Astra 28E, streamed using dvbstream.
This morning for example, none of the channels show the blinking/resizing
problem. All channel changes are smooth and fast. The next time I see
content making vlc jump around I will dump to file and send a link to it.
Dermot.
--
--
This is the vlc-devel mailing-list, see http://www.videolan.org/vlc/
To unsubscribe, please read http://developers.videolan.org/lists.html
More information about the vlc-devel
mailing list