[RFC] New architecture for a video server

[Arnaud de Bossoreille de Ribou]

On Fri, Aug 02, 2002, Christophe Massiot wrote:
> The basic idea is to demultiplex, process each ES separately, 
> remultiplex, and send.
> 
> +------+    +-------+    +---------------+    +-----+   +--------+
> | read | -> | demux | -> | ES processing | -> | mux |-> | output |
> +------+    +-------+    +---------------+    +-----+   +--------+
> 
> Since there is a lot of work to do, we should reuse code from 
> existing projects, as much as possible. Libvlc's input module 
> understands many more formats than VLS's, so I propose that we plug 
> the new server after the input thread of VLC, and take advantage of 
> the recent --codec switch (a multiplexer then being a special codec 
> type). In addition, having it inside libvlc allows us to use it from 
> other applications, in particular I'm thinking of an Apache module. 
> The multiplexing and output part can probably be based on VLS's 
> codebase.
> 
> This approach has one drawback : when reading a TS file, the TS 
> stream that is sent only vaguely resembles to the packets given. That 
> is, everything is demultiplexed and remultiplexed, so all existing 
> SIs are lost. For such stream, VLS or VLMS still have an advantage.
> 
> 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.
> 
> The following chapters describes how the new server architecture 
> would be integrated into libvlc. Note that this document doesn't give 
> any hook for "scheduling" streams, that is start and stop streams at 
> some precise time. IMHO, it is the job of an external program to 
> start and stop servers, and is thus out of the scope of this document.

Hi,

I haven't read all the details but my first comment is that if the
application we want to write is based on a well designed module
architecure, I mean the interfaces between them are generic enough to
link them arbitrarily we will ba able to have chains like this:

read -> output (eg TS without any modification)
read -> TS-TSCBR -> output
...

And when VLC's input will be able to mux and demux TS streams (you just
have to get the code of VLS and convert it to C </self-satisfaction> ;-)
we will ba able to do as VLS does for DVB streams. Note: the TS mux of
VLS is able to mux one _or_more_ programs by calling just one method.
The only thing that avoids this in VLS is the way programs are handled
by the application itself. So, at the end it would be nice to have

read -> TS demux -> TS mux (n > 1 programs) -> ...
                 -> TS mux -> ...
                 -> TS mux -> ...
                 -> TS mux -> ...

That's why I insist on well designed module interfaces.

<boring stuff>
I've been very busy for the last 4 months and that's why I was unable to
deal with VideoLAN stuff. Actually I can't deal with all the real life
(the one with pizzas) stuff. So just forget me (if you've not yet
forgotten me) at the moment. I'll try to deal with all the libdvbpsi
pending tasks until I'm back to France and probably after. Then I will
see if I can still contribute to smaller parts of the project.
</boring stuff>

bye,

-- 
Arnaud

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