[streaming] Re: VOD implementation suggestions

[Derk-Jan Hartman]

Dermot McGahon wrote:
> 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.

well not entirely true. VLC can receive RTSP Unicast RTP TS streams just 
fine as I understand it. The problem is that the kasenna is a piece of 
shit that was one of the first systems to do this kind of stuff and 
therefore still uses a lot of the unclearaties and deprecated ideas of 
the most early version of the standard.

For VLC the problem is a large part in live.com. the rest should be 
relativly easy..
unfortunately i have lost my testbed environment for this because of 
issues with broadcasting rights.

>> 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
that doesn't exist :)

> (2) RTSP/UDP/MPEG-2
This indeed is required, but i'm not sure if such server solutions 
actually exist... perhaps VBrick or IP/TV systems do this, but I don't 
have these as resources..

> (3) RTSP-Kasenna/UDP
> (4) Other?
(Real, Windows?)
> 
> 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.

(slightly ???, i'd call them blatent deviations of the spec)

> (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 indeed is possible, the best way to do this is by having VLC detect 
this is coming from kasenna (the input used the sgimb demux), and then 
tell liveMedia by use of a switch to go into kasenna mode.
> 
>> 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 ..

Ah yes, this is in interesting point!!!
I think we forgot this. for instance for unicast, for each time the VoD 
server is contacted by a new client, a new streamoutput (VLM) item will 
need to be created i fear....
This poses interesting problems....

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

SAP is a basic element of a VLC announce these days. it would be a 
trivial extension on the above implementation.

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

Again trivial, for multicast you can already do this in VLC. an unicast 
RTSP system would be setup similary.

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

That might be a long term thing.. However not unwanted, if you consider 
the enourmous amount of faulty files in the world.
> 
>> 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
done :)
> 
> 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.

another method is sending RTSP PLAY commands with different rate 
settings. 0 being pause, 1 being normal, 2 being fast forward, -1 
reverse, -2 rewind.

And this is where we run into REAL problems....
This is exactly the reason why using a specification and then NOT using 
it correctly becomes a big problem. It is extremely difficult to detect 
all these settings, in fact I believe even impossible or maybe unwanted.
Perhaps we can simply make settings of this that you then need to set 
depending on the method you use. It's just a huge task to autodetect all 
this requiring a parsing overhead on every system, even the spec 
compliant ones.

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

Future task that is of later concern. One step at a time approach 
definetly applies in this case.

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

I don't agree. I see no reason in POSING as a broken server platform 
like Kasenna. accepting it is not so much a problem for me, but serving 
more broken streams is. it's either multicast/udp/ts with SAP or 
rtsp/rtp/sap in my eyes. RTPS/UDP is a broken format which I think is a 
bad idea to provide.

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

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