[streaming] Re: VOD implementation suggestions

[Marc Manthey]

On 26.08.2004, at 11:49, 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.

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

thats very interesting  because i tryed to use 
http://www.iwitnesstv.com/
a programm called MacTV from Joe Huber ,is designed to work primarily 
with Cisco's IP/TV servers or with MBONE programs. Although you can try 
it out via the Internet, you'll get the best results using it on a LAN 
with a local IP/TV server. MacTV is an independent product and is not 
sold, endorsed nor supported by Cisco Systems.

It works with builtin SAP/SDP Listener but i could  not  find  
information about  this
on the  web.

i had contact  with henning schulzrinne 
(http://www.cs.columbia.edu/~hgs/)
he  is  involved  in the sip protokoll discription and  rtsp as well 
and  he told  me
that you have " to track rtsp packets " to make  this "live" list 
possible
then i asked  about  if you could use ( 
http://developer.apple.com/darwin/projects/opendirectory/) open 
directory and  he  said  that its not  been supported.
So there were a solution because i used cuseeme for  years and  there  
where
a "live" list you see all connected  users and  you can get access thru 
an
authentification with username and  password. When you are  logged in
you see yourself  in the  list. SO you dont  have to worry  about
"announcing";)





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

yes


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

we had  the  idea  like 
http://homepage.mac.com/rossetantoine/osirix/Index2.html

that you can stream a desktop or  a window too!!



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

yeah!!!!


> 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 
> elementarystreams. That can be done with VLM as well, with the help of 
> a specialstream output module. Basically, before VLM registers an 
> input item withthe "VOD server", it could start playing the input with 
> a special streamoutput 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.

cool
 >Dermot.


greetings  from germany  marc


--
"It doesn't matter who you are, it's what you do that  takes you far"
  —Madonna.

          Marc Manthey
          Hildeboldplatz 1a
          D – 50672 KÖLN
          web:http://www.let.de
          mail:marc at let.de
          aim:addbuddy?screenname=macfreak2004
          sip:+49221355338066
          Mobile:+49(0)177-3415481
--

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