[vls-devel] Re: Occasional crazy problem with vls

[Andrew de Quincey]

On Monday 19 January 2004 13:34, Jean-Paul Saman wrote:
> Andrew de Quincey wrote:
> > Has anyone else seen something like this:
> >
> > VLS is playing a looped MPEG2 program stream file, multicasting it as a
> > UDP MPEG2 transport stream.
> >
> > This works fine.. normally.
> >
> > However, sometimes _BUT NOT ALWAYS_, when the load on the server is high
> > (e.g. copying a large mpeg file onto it), VLS goes crazy. It starts
> > sending the stream out really fast... say 20x the speed it should. This
> > continues until it hits the end of the file, at which point it starts
> > playing normally again.
> >
> > Note that the problems doesn't always occur... usually videolan behaves
> > correctly with high loads, but as I said, occasionally this problem
> > occurs. I'm guessing this is some timestamping problem caused by the high
> > load, as the file plays perfectly in videolan at all other times.
> >
> > I'm asking this because (for various reasons) I'm not using the most
> > recent version of videolan, although I'm not that far behind. Has anyone
> > fixed anything like this recently (before I start looking)?
>
> I don't think it is a problem as such of VideoLAN. What happens in this
> scenario is that the copy of the new mpeg file is messing up the
> harddisk cache. In fact all VLS request for data from the same disk
> start starving and this will result in sending out *late* packets like a
> mad man ;-).
>
> What I am interested in is knowing if your video clients expierence a
> temporarly lack in video (like a big hole)? This would support my theory
> above.

If you use VLC as a test client, you can see the video suddenly speeds up.

You can duplicate the problem partly by running VLS in the foreground. If you 
ctrl-z it and leave it for 10 seconds, then 'fg' it again, the video in VLC 
will speed up for a bit until it catches up with where VLS "thinks" it should 
be. (I can't replicate the problem I originally reported in this way, but it 
looks related).

I don't think this the correct behaviour. VLS should either just skip the 
video, or realise its been delayed for a bit, and compensate its timings. I 
don't think suddenly sending a massive burst is right. My normal video 
clients (which are STBs with hardware decoders) don't really like the burst 
very much.

What do people think? I can easly implement a fix if people agree this is a 
problem...

> If you run one of the newer kernels 2.4.23 (2.4.24) or 2.6.x then you
> should mount your drive with the anticipatory scheduler. The effect you
> have should then be gone. (As long as you don't try to push more data
> then the HD or PCI bus can swallow down its throat ;-)).

I can certainly try that out, yeah.

-- 
This is the vls-devel mailing-list, see http://www.videolan.org/streaming/
To unsubscribe, please read http://developers.videolan.org/lists.html
If you are in trouble, please contact <postmaster at videolan.org>