[streaming] Re: VOD implementation suggestions

[Derk-Jan Hartman]

Dermot McGahon 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!


I and my previous employer as well as my university met similar responses.


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

If you could...
I might get the access back in the future, but it will require me to go 
trough some bureaucratic procedures. They had to close down the 'public' 
feeds because their was a lot of trouble over the rights of the Olympic 
Games, which made these public streams more public than they used to be.

Now every user that wants to receive this in the interessent of the 
experiment needs to be specifically firewalled after signing a contract 
etc etc etc.
I just haven't gotten around to diving into that :)

>>>  (1) RTSP/RTP/UDP
>>
>> that doesn't exist :)
> 
> 
> Well. The RTP still needs to be carried over either UDP or TCP.

RTP is UDP with some special contents. sometimes the whole lot is in 
turn carried in tcp, which makes it even stranger :)

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

Well now that i know of. I have seen UDP/TS a lot, but RTSP/UDP/TS not 
so much. Only Kasenna seems to use it.
It think i saw that IP/TV now also doe it, but that is a fairly recent 
development (past 356 days).
The problem with these streams is that unlike normal RTSP streams, they 
don't use RTCP. that is what makes them so different.
I also suspect this is the reason I couldn't get this working last time 
i tried accepting these RTSP/UDP streams.

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

The DESCRIBE is just necesarry i think. We just need to know the server 
platform. Also, the SDP in the SETUP that kasenna returns is not always 
valid/correct. We need to be aware of this as well.

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

In windows you go to "Settings->Add Interface->SAP playlist", and 
they'll just show up in your playlist, if you can access any.


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

A distinction needs to be made here.
The 'trick-play' technology, which is basically a way to play an MPEG2 
at a speed other than normal.

Two basic techniques exist for this as far as I know. Just doubling the 
datarate (VLC can do this), or skipping everyother frame and sending at 
the same rate as before (effectivly doubling the playback speed as well) 
I'm not sure VLC can do the latter (serverside, clientside is not a 
problem) since VLC doesn't know frames. (and various other techniques to 
achieve reverse and slomo. VLC cannot reverse atm, it can only jump 
position serverside)

For pause there is the rate=0 and the rate=1 but picture stays the same 
technique. There has been a MPEG draft about these techniques i think, 
but i'm not sure. Meuuh should know.

Then there is the extensions in use to control this behaviour trough 
RTSP. This is basically STB Vendor specific.

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

The main problem is what if Describe is Kasenna, and stream is mpeg4 ???
Then you need to switch back to "non-kasenna mode'.
> 

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

the difference here is what we are talking about exactly
a lexicon to work with :) before diggin in.

RTSP
A wrapper specification for the combination of RTCP/RTP/SDP standards.

RTCP
A HTTP TCP based control and stream setup method in use by RTSP

RTSP-r
Real extensions to mostly the the RTCP area of the spec allowing 
authentication and other advanced control methods of streams. As well as 
allowing for an alternate transport method called RDP

RTSP-k
Kasenna's version of RTSP mostly based on the earliest ideas of RTSP. 
outdated

RTSP-w
M$ version of RTSP basically introduces a new payload format to stream 
ASF streams.

UDP
a unreliable video transportation method that allows uni and multicasting

RTP
an extension to UDP packets that adds time and 'payload format' headers 
to UDP. It's basically a MUX for Video ES, much like TS or PS or ASF.

RDP
an alternative to RTP that also garentuees delivery of the packets.

SDP
a file format that describes a stream. This is also returned upon a 
DESCRIBE RTCP call and will specify the RTP streams to the client.

Then there are TCP bridging capabilities, but for the purpose of clarity 
we will not take this into account.

so what are the possiblities?

UDP/TS/multi&uni
supported by most STBs and one of the first streaming methods.
supported by VLC server and client side

RTP/multi&uni
in use by some webradio's
VLC supports this client side (no longer serverside)

RTSP/SDP/RTP/multi&uni
this is the big thing. it's what everyone should be using in most cases.
VLC supports it client side and serverside for most types of video/audio
QuickTime supports it server&client
Real supports it client(server? not 100% sure it does)
new VBricks and new IP/TV solutions support it too as far as I can tell.

RTSP-k/UDP/multi
this is basically just UDP/TS/multi VLC supports is client side, because 
we rip the multicast ip from the sgimb file and just ignore the RTSP-k part.
I see no reason to support this serverside in VLC. both the RTCP and the 
use of UDP are not spec compliant and i don't see a good reason in 
helping it survive. As an input for a Kasenna server you can feed it 
normal UDP/multi and MPEG4. Kasenna can relay that for you (Trax knows 
all about this).

RTSP-k/UDP/uni
for VoD for clients with an unknown IP, you need to setup such a stream 
on the fly. therefore Kasenna uses RTSP. However the way it uses this is 
different depending on type of video and the version of the Kasenna 
server. It's also no real RTSP at all, because it doesn't use RTCP.
sometimes it provides a SDP, but it often isn't correct. Other times it 
uses sgimb files.
It would be very nice to get this supported clientside, however again 
i'm not sure this should be supported serverside of VLC for the same 
reasons..

RTSP/SDP/UDP/multi&uni
In use by newer VBricks and IP/TV i think. mostly spec compliant, but 
doesn't use RTP. (as long as the source is TS this is not so much a 
problem techinically though).
VLC supports it client side (with livedotcom tweaks where needed).
serverside support is possible, but I think these devices just as well 
like a plain udp/ts/multi as input, so i don't see a reason to 
re-engineer our rtsp plugin to use udp when it's not even spec compliant 
to do so.

then there is SAP, which is a way to broadcast/announce SDPs. Support 
varies very much, but VLC supports most of it.

DJ

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