[vls-devel] [RFC] VideoLAN Server Architecture For the Future

[Jean-Paul Saman]

VIDEOLAN SERVER
===============
The VideoLAN Server as it currently is lacks some features to become a 
complete VOD solution or streaming solution. It's input capabilities is 
way behind the VideoLAN client. Developing all input capabilities for 
both VideoLAN server and client in duplication is waste of everybody 
time. It should be possible to combine both solutions in one way or 
another. Here is the way I think this could be done. Please comment on it.

Features
=======
For starters it should provide:
- streaming from devices: DVD, file, VCD, satelite (WinTV, DVB-S, 
DVB-T), camera
- streaming formats MPEG PS/TS 1/2/3/4, DivX
- streaming control through protocols like: H26L, RTSP, HTTP
- multicast session announcements: SDP
- streaming unicast/multicast
- transcoding needed for WLAN 11Mbps (802.11b), 10MB networks, internet
- streaming support for DVB-IPI (RTCP)
- server controlled trickplay
- streaming secure content using OpenSSL or something similar
- launch events (for starting scripts, scheduled start of streams or 
hookup to databases for adminstration/acounting)

The technical side:
===================
I'd like to see that VLS is less dependend on streaming TS packets, so 
that it can stream any audio/video format that is streamable, eg: MPEG4, 
mp3, etc over TS or RTP or ....


1) libvlc ------------->packetiser -> filter* -> FIFO -> streamer -> net

2) transoder ---------->packetiser -> filter* -> FIFO -> streamer -> net
    (perhaps ffmpeg)

3) Mpeg2-TS -> convertor/packetiser-> filter* -> FIFO -> streamer -> net
    (File/DVB cards)

1,2 and 3 would be running as separate processes and consist of a stream 
layer and a stream control. See next picture. The filter makes it 
possible to implement trickplay and other stream manipulation functionality.
In the current VLS we need to separate input and readers from 
convertor/packetiser and introduce a fixed module stream interface and a 
control interface to make this possible. It will make the modules more 
modular and interchangeable.

   Module stream interface (possible):
   -----------------------------------
   connect( C_String capability, C_Packet *packet);
   get_capability( C_String capability );

   Module Control interface (possible):
   ------------------------------------
   start();
   stop();
   forward(int speed);
   rewind(int speed);
   pause/suspend();
   resume();
   get_capability();

Capabilities will be strings like "rtp", "mpeg2-ts", "trickplay 
default", etc.

All processes store on disk what they stream in a predefined format. For 
instance a file in /var/videolan/server/broadcast. Then the stream 
manager (RTSP, HTTP, telnet, ...) can see control all streams regardless 
of which process is streaming and who it started. I mean a stream 
started in a Telnet interface should be stoppable from the HTTP control 
(or RTSP).

Architecture:
-------------
A general server architecture would then be:

      stream layer (see 1,2,3)
             ^
             |
      stream control
             |
             O native interface
             ^
             |
      stream manager
    (RTSP, HTTP, telnet)

The stream manager will run as a separate process and dispatch/spawn 
servers (stream layer/stream control) when needed. Like a webserver 
does. This will add to stability of the server solution.

Summary:
========
The input of VLS is it weakpoint. The intertweening of input, reader, 
convertor and packetizer is very bad. It does not allow a clean design 
and is very restrictive. This explains why there is a lack of formats it 
can stream.

The strong point of VLS is that it uses so little CPU time, especially 
with DVB and Mpeg2-TS streams.

It streaming out algorithme is allright, but uses extrapolation. However 
in practise this has not been an issue up till now. I wonder when it 
will be. It really should use intrapolation otherwise it can never 
reconstruct the original stream timing (DVB input and Mpeg2-TS files).

A possible scenario for transistion
===================================
When VLC streaming is working alright, then the streaming capabilities 
for Mpeg1-PS and Mpeg2-PS (file/DVD) should be discontinued. VLS should 
then only be used for DVB streaming from WinTV-Nova cards and Mpeg2-TS 
files. The vls-stream-manager should be extracted from the current VLS 
code and a native interface should be used to communicate with either 
the VLC streamer or 'original' VLS code.

This will allow for a more stable streaming server and keep a working 
solution. For me keep it working as total at all times is a must (mainly 
from current users perspective).

Greetings,
Jean-Paul Saman.

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