Re: [RFC] New architecture for a video server

The new architecture that you propose (the one that demultiplex, process
each ES separately, reemultiplex, and send) is badly needed for PS
processing. It has been implemented in a very basic way as part of the
PS2TS converter but oviously needs to be extended and made much more
generic.

Instead of completely replacing the current vls architecture with this
one, I'd rather integrate this new generic ES engine as a new vls input:
* This would make the demux/mux phase optional. The associated overhead
and complexity would be eliminated in case of a TS or DVB input stream
that just needs to be relayed to the output.
* This would be compatible with the existing codebase. One of my biggest
concern is that this new architecture will require a lot of work and
there aren't that many active VLS developers. Creating a new generic
input and then migrating the existing PS inputs would minimize the
amount of work by preserving the over inputs.
* The efficiency of final phase (scheduling and sending over the packets
to the recipients) would be preserved. This is not just a cool feature,
this is essential to keep the latency low and therefore to be able to
respect the bitrate of the stream (whether this is VBR or CBR).

RTP, HTTP and raw UDP are just transport layer. It is possible to create
new outputs to pack the TS packets into any protocol you want. The
current VLS only offers a raw UDP output, but I think tooney as recently
created a RTP output. It shouldn't be a problem to also add an http
output.

I don't know whether this would support MPEG4. If the MPEG4 transport
stream is compatible with the MPEG2 one, then there is no problem. Any
insight ?

Benoit

-- 
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 <[email protected]>