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

[Ross Finlayson]

>>I'm noticing you implemented this slightly different than I had
>>anticipated. In my understanding it is possible to set an option on the
>>RTSPClient object when you create it. This eliminates the need for
>>changing the DescribeURL method etc, which would keep the API unchanged.
>
>There isn't really a way to keep the API completely unchanged. The
>information has to be passed one way or another.
>
>The options, as I see it, are:
>
>  (a) Pass a flag to describeURL, setupMediaSubsession. The flag has a
>      default value of false, so it is fully backwards compatible.
>
>  (b) Pass a flag to createNew. Store it as a private variable. Use it
>      in exactly the same way as option (a). Perhaps this is a better
>      way to do this.

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.

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.


	Ross Finlayson
	LIVE.COM
	<http://www.live.com/>