[RFC] New architecture for a video server

[Christophe Massiot]

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.

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

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

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

-- 
Christophe Massiot.

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