[Live-devel] Patch to RTSPClient to support Kasenna RTSP

[Dermot McGahon]

On Wed, 20 Oct 2004 02:13:39 -0700, Ross Finlayson <finlayson at live.com>  
wrote:


> I don't think so, because (b) precludes the possibility of ever using a  
> single "RTSPClient" object to do more than one "DESCRIBE": one using  
> normal RTSP; the other using Kasenna.

True.

> Actually, I don't particularly like either (a) or (b).  Is it not  
> possible to instead avoid adding extra 'Kasenna' flags to  
> "describe...()" and "setup...()", but instead to figure out  
> automatically - from the response to the initial "DESCRIBE" (or perhaps  
> "OPTIONS") - whether or not the stream needs special 'Kasenna' hack  
> handling for the subsequent "SETUP" and "PLAY"?  This is what I'd prefer  
> to do, if it's possible, because it would avoid the caller having to  
> know - in advance - whether or not a "rtsp://" URL is for a regular  
> stream or a 'Kasenna' stream.
>
> I realize that this would probably require permanently adding
>          application/x-rtsp-mh,
> to the "DESCRIBE" "Accept:" line, but this is something that I'd be  
> willing to live with if it meant that we could detect 'Kasenna' streams  
> at run time.

We talked about this and this approach has its own problems.

The OPTIONS response does not contain any identifying information. The
DESCRIBE response does.

The problems are:

(a) The application/x-rtsp-mh would have to be permanently added and
     DJ is fairly certain that this will break some VOD servers. I don't
     have a range to test with, so can't tell you just now which ones
     will be affected. Trying with application/x-rtsp-mh and falling back
     to application/sdp doesn't seem quite right either.

(b) The variant behaviour is only required for MPEG-2 content. Kasenna
     hosted MPEG-4 is standard RTSP/application/sdp. The format of the
     content is either (i) discovered by checking the metadata returned
     from the http links (example below), or (ii) by knowing in advance
     that all content is MPEG-2 and specifying on the command line.

I'm not sure I'm explaining this properly. All my content is MPEG-2 and
the #define hacked LIVE.COM was sufficient. A vlc --rtsp-kasenna is also
sufficient for my application. Figuring it out automatically from the
DESCRIBE response would also be ok for my application, as I only need
to play MPEG-2 content. So, I have options :)

For vlc the situation is not quite so simple. They would like to be able
to play MPEG-1/2/4 and MP3 from the VOD server. To do that they fetch
the http:// variant of the rtsp:// link and parse the sgimb metadata. If
it's MPEG-4 LIVE.COM needs to do the normal exchange, if it's MPEG-2 the
DESCRIBE and SETUP are different.

So, modifying createNew will not help vlc. Both vlc (general use) and
my application can work with the flag passed to describeURL and
setupMediaSubsession. With auto detect on the DESCRIBE, some VOD servers
might choke on the SETUP and MPEG-4 content won't work correctly with
vlc in general use .. although again a flag could be passed in :)

I'm not doing a great sales job on this patch. I basically agree with
you that it's all not perfect. The older #define patch worked fine for
me. This newer one will also work fine for me. I'm willing to do the
autodetect which will also work fine for me, but I don't think it will
be good enough for vlc. It risks breaking some standard compliant VOD
servers and precludes MPEG-4 content.

Actually I don't have any MPEG-4 content installed to test with. If it
responded well to Accept: application/x-rtsp-mh, application/sdp, maybe
the sdp would tell us that it is MPEG-4? Either that or just receiving
an sdp would mean that it is MPEG-4.

I'm wide open to suggestions. Probably we need to do some MPEG-4 testing
and get back to you.



Dermot.
--




Snippet of RTSP exchange between vlc/LIVE.COM and Kasenna:
----------------------------------------------------------

Received OPTIONS response: RTSP/1.0 200 OK
CSeq: 1
Message: OPTIONS Successful
Public: OPTIONS, DESCRIBE, SETUP, PLAY, PAUSE, SET_PARAMETER,  
GET_PARAMETER, SET_PLAYMODE, TEARDOWN
Date: Wed, 20 Oct 2004 16:39:03 GMT

Sending request: DESCRIBE rtsp://omnibase/sync_test RTSP/1.0
CSeq: 2
User-Agent: VLC Media Player (LIVE.COM Streaming Media v2004.10.18)

Received DESCRIBE response: RTSP/1.0 200 OK
CSeq: 2
Date: Wed, 20 Oct 2004 16:39:03 GMT
Server: Kasenna MediaBase version 7.0.1
Content-type: application/x-rtsp-mh
Content-Length: 416



Metadata returned from the http links:
--------------------------------------

* This specifies the content format and hence the required
   rtsp dialect.

sgiNameServerHost=videoserver.nob.nl
Stream="xdma://omnibase/demo/blah"
sgiMovieName=/demo/blah
sgiAuxState=2
sgiFormatName=MPEG-2
sgiWidth=704
sgiHeight=576
sgiBitrate=4999839
sgiDuration=599058880
sgiApplicationName=MediaBaseURL
sgiElapsedTime=0
sgiServerVersion=6.1.2
sgiRtspPort=554
AutoStart=True
sgiUserAccount=pid=7703&time=1098200252&displayText=You%20are%20logged%20as%20guest&
sgiUserPassword=