[vlc] Slightly OT - Late audio and video problems playing back stream from DSS

[Cian Cullinan]

I have a problem with playing back high bitrate streams using the VLC
mozilla plugin with Firefox from Darwin Streaming Server. Playback is
jerky, and occasionally causes freezes, requiring a restart of
Firefox.
These pieces are encoded with mpeg4 video and AAC audio, and vary
between 5 and 10Mbit/s.
The server is running DSS 5.6.0 on CentOS-4.3, with 4x15,000RPM SCSI
disks in RAID10.
Streaming 13 of these puts the server CPU usage up at about 20-30%, so
no problem there, and the RAID set should have no problem keeping up
with the I/O.
Client machines use Firefox  1.0.8 + VLC  0.8.5 mozilla plugin to play
back streams from the server, and CPU usage is about 20% during
playback.
The whole system is on a GigE network.
Running VLC from the command line with -v, gives errors like the
following during jerky playback:

[00000274] main audio output warning: PTS is out of range (13323695),
dropping buffer
[00000274] main audio output warning: buffer is 53612 in advance,
triggering downsampling
[00000271] main video output warning: late picture skipped (13698728)
[00000271] main video output warning: late picture skipped (13651963)
[00000274] main audio output warning: resampling stopped after
10516651 usec (drift: -849)
[00000271] main video output warning: late picture skipped (2851)
[00000274] main audio output warning: output date isn't PTS date,
requesting resampling (51444)
[00000274] main audio output warning: buffer is 52510 late, triggering
upsampling
[00000271] main video output warning: late picture skipped (1515)
[00000274] main audio output warning: resampling stopped after
10345359 usec (drift: 154)
[00000271] main video output warning: late picture skipped (6500)
signal 2 received, terminating vlc - do it again in case it gets stuck
[00000271] main video output warning: late picture skipped (415)

I haven't been able to get debugging output from a freeze yet.

It was suggested to me on the IRC channel this can happen with high
bitrate streams that cause more TCP resend requests, but I am not
using rtsp-tcp, just regular rtsp with udp transport.

It *seems* to me that playback is better for the lower bitrate
streams, and also improves if they are cached by the server in RAM,
but that is subjective.
So I have really have three questions:
1) Can anyone think of a reason for the messages I'm getting? Given
the low server and client CPU loads, and the capacity of the network,
I'm inclined to think it's an issue with the server hard disks. But
they are more than fast enough to access the files to stream them. I
have even turned off all streams except for one and I see the same
thing. Maybe there is something more complicated like read-ahead
values I need to look at, I just don't know at this stage.
2) What can I do to help vlc cope with late data so that playback does
not become jerky? I have experimented a bit with rtsp-caching and
udp-caching with no obvious effect. I also see the option rtp-late. Is
this relevant, any suggested values for it?
3) While the jerky playback is a big problem, the *worst* thing is the
way vlc will occasionally freeze. Is there something I can do to
prevent this?

I know the answer to some of these questions is "experiment and see",
and I intend to, but unfortunately for me the system is not always the
easiest to get access to to test, so I would like to have a better
idea of where to focus my attention when I do get access.


Cian

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