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

[Derk-Jan Hartman]

On 20 okt 2004, at 11:13, Ross Finlayson wrote:
>>> 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.

i don't see why this would be desirable for anyone. at least not 
anymore then ease of VLC use or RTSP compliance.
And i consider (a) a bit of a messy solution..

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

I once built a version of the old Kasenna with the KASENNA define to 
True. that included the double Content-Type. It broke several streams 
then. I consider it a dangerous option.

And the first time Kasenna announces itself as a Kasenna server is 
after the DESCRIBE.
And if you don't send the proper DESCRIBE, VLC might return with a SDP 
for an MPEG2 stream which is completely bogus (tested this). And on 
MPEG4, you NEED to send sdp contentype request, yet you cannot know if 
it's MPEG4 or MPEG2 here unless you tell the RTSP client this.

I though that something like :
         psz_options = p_sys->rtsp->sendOptionsCmd( psz_url );
         if( psz_options )
             delete [] psz_options;

would be the nicest solution but this is not up to me of course.

DJ
---
Universiteit Twente
Derk-Jan Hartman (d.hartman at student.utwente dot nl)
http://home.student.utwente.nl/d.hartman