[streaming] Re: VOD implementation suggestions

[Dermot McGahon]

On Thu, 26 Aug 2004 13:34:03 +0200, Derk-Jan Hartman  
<hartman at videolan.org> wrote:

>> Dermot McGahon wrote:

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

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

Yes, you're right. VLC can receive RTSP unicast RTP TS streams just
fine. Thanks to your good work. What it can't do is receive RTSP
unicast UDP TS streams from a Kasenna VOD server. But it wouldn't
take much to make that happen.

The Kasenna VOD server was developed before the RTP spec was even
conceived, never mind written. Fine, they should really go back and
make it standards compliant but they haven't done that for some
reason. I've ranted at Kasenna and never received an answer to why
MPEG-1 & 2 are handled using SGIMB (SGI Mediabase meta information,
an predating alternative to SDP) but MPEG-4 is exclusively MPEG-4.
But it has to be because their MPEG-4 support was developed later
and they didn't retrofit their MPEG-1 and 2 support to match. I don't
know much about their MP3 support but I know that you have looked
into that. It also may be configurable, on a per-server basis, whether
SDP or SGIMB is used, but if so, I've never found out where!


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

That's a pity. We don't have a broad enough net connection to give
you access to our Kasenna server, but I'll test and patches you need
tested.


>>  (1) RTSP/RTP/UDP
> that doesn't exist :)

Well. The RTP still needs to be carried over either UDP or TCP.

My terminology might be a little off but I think you know what
I mean. RTSP/RTP/MPEG-2 over either UDP or TCP.


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

Most commercial systems use this. The Kasenna server streams using
RTSP/UDP/UDP .. which is basically just RTSP/UDP/MPEG-2.


>> (3) RTSP-Kasenna/UDP
>> (4) Other?
> (Real, Windows?)

Yes. At least some effort should be made to support these variants,
but they are not something I'm especially interested in, or know
much about.


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

Well yes, blatant deviations from the spec. Easily handled though.


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

I can make liveMedia variant switchable, but it will be ugly.

I'm still a little confused about how to detect for sure which vod
server you are connecting to. Maybe issuing a DESCRIBE RTSP command
before SETUP is the way to go? An alternative is to request sgimb
instead of sdp in the SETUP, but this is completely Kasenna specific,
and a waste of time for any other vod server.


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

I don't know the architecture well enough to comment on this. But, as long
as there is support for a couple of different clients to be able to  
connect,
it might not be such a bad restriction to force all clients to be following
one standard i.e a vlc/vlm can be configured as a vod server which is  
either
RTSP/RTP compliant or RTSP-Kasenna/RTP compliant or (the one you don't  
like),
RTSP/UDP compliant.


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

I should read more of the docs, but I haven't found where to enable
listening for SAP announcements?


> That might be a long term thing.. However not unwanted, if you consider  
> the enourmous amount of faulty files in the world.

Sure. This can easily be long-term.


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

Right.

The Kasenna uses this for fast-forward and rewind, but not for pause
and resume. They only support one speed (+ x 12) and (- x 12).


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

I'm not sure that trick-play is actually specified anywhere. Is it?

Yes, this autodetection may not be so trivial. But in most cases it should
be possible. DESCRIBE is a good start.



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

Sure. There is a substantial amount to be done. This can definitely
wait.


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

Maybe I'm missing something here, but if multicast/udp/ts works, then I
don't see why unicast/udp/ts would not work. In fact, it does work. It's
working here. And for every IPtv rollout so far (mostly Japan and Korea,
with one or two in Scandinavia, London, Germany and New York). Unicast
UDP is perfectly fine in a controlled LAN environment or using TCP/IP
over ATM. But I'm not that up-to-date on RTP and should do some reading.


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>