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

[Andrew de Quincey]

> >>>>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 ;-).
> >
> > I'm not sure if the IO explanation is quite the reason... see that was
> > just how I managed to duplicate it. This occurs at random on video
> > servers which we know are not having large files or any load of that sort
> > occurring to them. The only load is from streaming video either from
> > disk, or from DVB-T/DVB-S cards directly to the network interface.
>
> The two years our VLS server is streaming to multiple clients while
> recording another stream I never saw this behaviour. Unless the disk was
> overloaded.

At the moment, we're not really using this feature, so we're only streaming 
one single file. On my test server, this is ALL that I am doing.

> But did your clients expirience a still frame or black frame for some
> time when copying the large file ? you haven't answered this question.

No. On VLC, the first thing I see wrong is the speeded up play. No stills or 
black frames.

On our STBs, which are (unfortunately) far less tolerant to problems, all 
kinds of crap happens... jitter, mpeg blocking, black frames...




In the meantime, I've found what causes this bad reaction to load in VLS:

inline void C_TsStreamer::WaitSendDate(C_TsPacket* pPacket)

I added the following debug code to this function:
  if (iWait < -20000) {
     printf("Weird iWait %lli\n", iWait);
  }

Now, whenever the problem occurs, I see loads of prints saying "Weird iWait". 
VLC immediately starts showing the accelerated video frames, until the file 
loop occurs.

If I change this code to:
  if (iWait < -20000) {
     InitClock(pPacket);
  }
(modifiying WaitSendDate() to take the current pPacket, and the call to it to 
pass it)

So: if it sees one of the out of range iWait values, it knows there has been a 
delay, and re-initialises the stream clock. The STB and VLC both seem to work 
perfectly normally with this in place.

What do you think? This at least means the runaway problem no longer occurs, 
and I'll make it log as you suggest so that people know when their systems 
are overloaded.

-- 
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>