[vlc] Re: More elegant handling of large VLM playlists

[Warren Young]

Derk-Jan Hartman wrote:
> 
>> Why does it: a) open the RTSP port before it's ready to answer  
>> requests; and b) bother to demux all files in the first place?
> 
> a: I guess no one ever tested with this many files

Fair enough.  Fixing this should be trivial.

> This is a sync failure, and CAN  occur multiple times within a file.
> It is an error and should be reported whenever it occurs if you ask me.

I agree that the error should be reported.  I just question how useful 
it is to report it thousands of times.

Yes, thousands of times.  I ran the ProjectX demuxer on one of these 
problem streams (thanks for the tip, by the way) and it reported 47719 
warnings and errors.  If I remux the file, the error/warning count drops 
into the single digits.

>> 3. The problem I referred to above seems to be an oversensitivity  in 
>> the PS demuxer as to what it considers "garbage".
> 
> I think the problem here is that because of the loading of all the  
> files in the VLM, the synchronization code becomes overloaded,  causing 
> data to be late and requiring the server to resync the  stream. If the 
> load on the server is low, you should not run into  this if you don't 
> run into it during normal VLC playback i think.

I'm don't understand how VLM could be overloaded in this case.  The 
initialization process is serial: it generates the SDP for each file, 
one at a time, in the order given in the VLM configuration file.  Then 
to test the RTSP streaming, we're only asking it to send one ~1-4 Mbit/s 
MPEG-1 or MPEG-2 stream at a time.  In production, this can be higher, 
but that's irrelevant for the problems I've discussed here.

> Is all your MPEG data in true PS?

They are all muxed system streams of some sort or another, yes.  No 
elementary streams, and no transport streams.

> You might consider streaming in muxed form, with VLM instead of in  
> seperate tracks. 

We are.  Here's a typical VLM directive:

	new 101 vod enabled
	setup 101 input "/video/101.mpg"

101.mpg here is an MPEG-1 system stream.  It could just as well be an 
MPEG-2 program stream.

> The fact that most  players don't care about this as much as VLC has
> also resulted in the  fact that there are so many of those files out
> there. 

Yes, the world would be a better place if all MPEG encoders output 
perfect streams, but that doesn't mean it's not a good idea to do a 
best-effort attempt to decode broken streams.

Keep in mind, VLC as a standalone player does play these files 
correctly.  And, it's relatively simple to fix them so that VLM will 
stream them without errors.  These files aren't irrecoverably broken. 
Something in the remux process fixes these problems.  The correct data 
is available.

> pre-demux on load might be something that could be cached in one way  or 
> another. 

That sounds quite reasonable.  It could be optional, perhaps turned on 
by a verb in VLM's configuration language.  It could go in a *.sdp file 
named after the associated MPEG file.  As long as this stream property 
file remains newer than the MPEG, assume that the data in the stream 
property file remains valid.

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