[RFC] New architecture for a video server

[Jean-Paul Saman]

Christophe Massiot wrote:
> At 20:45 +0200 4/08/2002, Jean-Paul Saman wrote :
> 
>>> Similarly, VLC is currently unable to decode several programs within 
>>> the same input. That is we couldn't stream more than one program from 
>>> a satellite input. Again, VLS will still be useful for that kind of 
>>> situations, until VLC's input is extended to support decoding 
>>> multiple programs.
>>>
>> For most VOD uses that is no real problem. Usually one channel of a 
>> satelitte is used.
> 
> 
> Yeah but it's a problem for IPTV.
> 
Did not think of that.

>> In order to really leverage this great idea it would be great if it 
>> were possible to bypass going to the ES level for satelitte and SPTS 
>> streaming. Is there really no way of doing that in the current libvlc?
> 
> 
> Of course there is a way. We would need to add a semantic to 
> data_packet_t and pes_packet_t coming from the input, so that we'd be 
> sure they're actual TS and PES packets.
> 
> However, I'm almost convinced that we do not want to that way. Recently 
> I have spent a few hours debugging one of our users. It turned out that 
> the stream he used (coming from a local VOD dealer) only had ONE PAT/PMT 
> at the beginning. So bad for random access...
> 
> And I'm not even talking about streams which have funky PCRs, or 
> whatever. We spend really a lot of time debugging problems which in turn 
> are related to bad/unexpected TS streams, so that I think it's a damn 
> good idea to demux/remux the stream, just in case.

In these cases, but when retransmitting a stored satelitte channel it 
should be possible to just retransmit without demuxing, remuxing first. 
At least make it configurable is my suggestion.
In this way you can always tell someone with a bad behaving file to pass 
it completely through libvlc to see if the problem persist.

> 
>>> A drawback of this architecture : we have a lot of threads. 1 thread 
>>> for the input, 1 thread for the interface, 1 thread per ES, and 
>>> optionally one thread for the stream output. However, on current 
>>> machines VLS and VLMS only take up a margin of the CPU power, so that 
>>> we can afford a little more CPU time.
>>>
>> What is a little more? a few percents or 30-50 percent
> 
> I can't assess that, because I do not know the current overhead of VLS 
> and VLMS. However, considering how VLC's input (which already features a 
> lot of computation) performs on today's machine, it will probably be 
> marginal. And anyway, the bottleneck of such a system will still be I/O.
> 
Think of vls overhead about 1-2% CPU! If this increases to 30-50 percent 
for demuxing/remuxing of the same stream I can not see any benefit for 
this approach. In case of transcoding/changing stream formats it should 
be alright.

>>> Finally, if the user requested the stream to be constant bitrate 
>>> (CBR), the TS multiplexor will add TS packets for stuffing. The 
>>> resulting TS packets are placed in a FIFO, in the right order, with 
>>> emission dates.
>>>
>> Will the VBR case also be handled? Or are you intending to only stick 
>> to CBR?
> 
> 
> VBR is the same as CBR but without padding, so it will be way more 
> simple to implement.
> 
Of course ;-)

-- 
Kind greetings,

Jean-Paul Saman

Software Architect

e-mail (work): saman at natlab.research.philips.com
phone  (work): 040 27 42909
------------------------------------------------------------
Ordina TA,
Science Park Eindhoven 5602, Postbus 293, 5600 AG Eindhoven
e-mail : jean-paul.saman at ordina.nl
phone  : 040 2601200
fax    : 040 2601199


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