[streaming] Re: VOD implementation suggestions

[Gildas Bazin]

On Thursday 26 August 2004 11:49, Dermot McGahon wrote:
> On Wed, 25 Aug 2004 21:59:43 +0200, Gildas Bazin <gbazin at altern.org> 
wrote:

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

Well, this is already dealt with by the input layer of VLC.
VLC will always re-map the input PTS's to its own internal version of PTS's 
which are continuous (no clock gap, etc...) (remember, VLC was originally 
designed as a player ;).

You can also already do things like apply an offset correction to the audio 
PTS's compared to the video ones etc...

Which means that the streams produced by VLC should already play nicely 
(from a timestamps point of view) with most players out there.

As for storing sync points for the input stream, this does fit the 
pre-parsing very well (pre-parsing will just have to be a complete parsing 
if this feature is desired). However this will need more work because we 
will need a common facility that the demuxers could use to build a sync 
points table when playing an input for the first time (again, this info 
could be stored in the shared input_item_t structure).
This work would also benefit the "player" part of VLC by allowing 
better/faster seeking once the sync points table is available.

However, considering the work involved here, I would say that this is more 
like a long term plan.

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

Sure, you can always use (or create) other access output modules.
This should be easy to do considering the flexibility of the stream output 
architecture.

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

Care to elaborate ? :)

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

Sure, if you have specific questions/suggestions, I'll do my best to help.

--
Gildas

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