[streaming] Re: VOD implementation suggestions

[Dermot McGahon]

On Wed, 25 Aug 2004 21:59:43 +0200, Gildas Bazin <gbazin at altern.org> wrote:

> Hi people,
>
> Since there has been some interest in implementing VOD support for VLC, I
> decided to gather some information (special thanks to fenrir :) and write
> up a small proposal about how to implement this.
> Bear in mind that I don't really know much about RTSP so you'll have to  
> take all this with a pinch of salt.

RTSP is a very basic setup and teardown protocol. The commands are:

  SETUP     - tell the vod server to ready a stream, reserve bandwidth etc..
  PLAY      - tell the vod server to stream
  PAUSE     - tell the vod server to pause
  TEARDOWN  - tell the vod server you are finished with the stream

SDP is a little more complicated but is basically a textual description
of a stream.

I'm delighted that there is interest in implementing this. I would ask
though, that we try and keep vod clients in mind as well as vod server
capability. In other words, it is currently possible to receive raw
udp multicast streams using vlc, but I don't think it is possible to
receive rtsp unicast streams from a kasenna server. Derk-Jan and myself
have been talking about this over the last few months; have made some
progress; but haven't really cracked it fully yet.



> First it has to be noted that the "streaming output" architecture of VLC
> combined with the VLM (videolan manager which is part of VLC) should make
> implementing RTSP support relatively straightforward. Which means it will
> need a fair amount of code but should integrate well in the current
> architecture.
>
> So what needs to be done ?
>
> 1 - "VOD server" plugin:
> ---------------------------
> Most of the work needed will be to create a new "VOD server" plugin. In  
> our case the "VOD server" plugin will implement an RTSP protocol stack 
> but we can imagine having other "VOD server" plugins implementing other  
> protocols (or alternative implementations of the same protocol).

In order of importance:

(1) RTSP/RTP/UDP
(2) RTSP/UDP/MPEG-2
(3) RTSP-Kasenna/UDP
(4) Other?

The LIVE.COM code is already a good RTSP protocol stack. I have implemented
Kasenna RTSP support for it, but these patches are not folded back to the
LIVE.COM project for a couple of reasons:

(1) The Kasenna RTSP is slightly non-standard. So there is understandably
     some resistance to polluting the currently standards based  
implementation.

(2) My implementation is poor. It implements Kasenna RTSP but breaks
     standard RTSP. The implementation could fairly easily be fixed to
     support both RTSP variants in parallel and Derk-Jan and I have
     discussed ways to do that.


> This "VOD server" plugin will only act as a middle man between clients  
> and the VLM. So it will basically receive commands from clients and send  
> orders to VLM (play/pause/stop input or such). When clients request a  
> streamfor instance, the "VOD server" will send a start command to VLM  
> with the
> appropriate stream output options (to select the right elementary stream
> and stream them with the requested output method).

Sounds like a good design.


> I want to emphasis the fact that the "VOD server" wouldn't stream the  
> input data itself. This part of the task would be delegated to the  
> "streaming
> output" layer of VLC. The "VOD server" is just there for the interaction
> between the client and VLC.

Interaction between a couple of different types of clients and vlc ..



> 2 - VLM (videolan manager):
> --------------------------------
> The VLM is already there but it will need to be extended to work with  
> "VOD server" plugins.
>
> VLM is used to add/register new input items with the "VOD server".
> For instance: "new foo vod input file://bar.avi loop" adds a new input  
> item to the videolan manager and "setup foo enabled" will later on  
> registerit with the "VOD server" (so clients can see/access it).

Ok. Again, sounds good.

Ideally, the clients would have a way to build a playlist of vod
items available. This could be done using SAP/SDP.

Even more ideal again would be a mixture of SAP/SDP announcements,
letting the client know that there are, for example, five unicast
mpeg-2 or 4 streams available, and there are ten multicast tv
stations being broadcast from a dvb card. The multicast streams
don't need RTSP for setup, but I don't see any difference between
unicast and multicast as regards SAP/SDP announcements.


> In the case of an "RTSP server", to generate the SDP for an input, we  
> will need to pre-parse it to gather information about its elementary 
> streams. That can be done with VLM as well, with the help of a special 
> stream output module. Basically, before VLM registers an input item with 
> the "VOD server", it could start playing the input with a special stream 
> output module which would gather all ES information and store it in a  
> shared
> location (like the input_item_t structure that defines the basic  
> properties of an input). Once this information is gathered, the special  
> stream output module will stop the input and VLM will register the input  
> to the "VOD
> server" and pass along the ES info.

This is clever. This is essentially registration of the content. The
commercial vod servers do this anyway. They also perform processing on
the mpeg streams while "importing" them, normalising PTSs, adding sync
points at various places. I'm not up on all the details but could probably
find out more.


> So VLM needs to be modified to:
> - Start the "VOD server"
> - Initiate the pre-parsing of the input to gather the ES info
> - Register/Unregister an input item with the "VOD server"

- SAP/SDP announcements?
- Allow registration of multicast inputs

Different vod servers implement trickplay differently. If we want
vlc to act as a vod client, we need to be aware of these differences.

For example, the Kasenna implements pause/resume like this:

(a) client sends an RTSP PAUSE
(b) server pauses the stream
(c) client needs to display last frame, vlc seems to do this
(d) client sends an RTSP PLAY with the last PTS. Note: the vod
     server does *not* keep track of the current position in
     the stream. The client has to do that instead. Stream is
     resumed at the point the client requests. It generally would
     only make sense to resume at the same point that the stream
     was paused at.


> 3 - Pre-parsing stream output module:
> -------------------------------------------
> As stated above we need a simple stream output module whose only job is  
> to register the elementary stream information of an input and store them  
> in
> the input_item_t structure for later use by VLM. Gathering this info  
> would be easy as the module will just have to wait until a certain  
> amount of time worth of data has reached the stream output fifos. When  
> this amount of time has been read from the input, we can assume all the  
> ES are there.
> Pre-parsing could of course also be extended to full parsing if need be.
> Once the module has the ES info, it could signal the input to stop.

It might be worth thinking at this stage about broken streams from
various outputs .. i.e dvb cards, cameras, frame-grabbers. It would be
good if there was some "robustness" code is this stream output module
which would, for example, check that both video and audio elementary
streams both contained sane PTS's. Decisions could be made at that
point to apply corrections to either the audio or the video PTS's.



> 4 - The RTP (access output) plugin:
> ----------------------------------------
> We already have an RTP access output plugin (part of the streaming output
> architecture) so I'm not sure we need much work there.

No, but we need a way to be able to use RTSP (possibly more than
one variant) without being forced to also use RTP.


> Well, I think that's about it.
> I don't see that as a very difficult job and furthermore there are  
> several separated tasks here so it could be done cooperatively....
> So all we need now are people motivated enough to start the work :)

Some of it is already done :)

There is far too much for one person to do though.

How about a little more design discussion? There are a lot of different
requirements out there.



Dermot.
--

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