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

[Dermot McGahon]

On Wed, 20 Oct 2004 06:47:36 -0700, Ross Finlayson <finlayson at live.com>  
wrote:

>
>> 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
>
> I think you mean "DESCRIBE", right (because that's what contains the  
> "Accept:" line)?

I meant DESCRIBE.


>>  and MPEG-4 content won't work correctly with
>> vlc in general use .. although again a flag could be passed in :)
>
> I'm not sure I follow this.  For MPEG-4 content, even from a Kasenna  
> server, the "Content-Type:" returned in a "DESCRIBE" response will  
> presumably be the proper "application/sdp", which the RTSPClient code  
> can recognize as meaning: Do the normal RTSP protocol from here on.

I'm trying to get some mp4 content to ingest and test with. No luck
so far.

I just tested without an Accept line and it returns x-rtsp-mh for
an mpeg2.

I tested again with "Accept: application/sdp, application/x-rtsp-mh"
and it doesn't accept it for mpeg2:

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

Received DESCRIBE response: RTSP/1.0 415 Unsupported Media Type
CSeq: 2
Message: Date: Thu, 21 Oct 2004 00:15:36 GMT


> I think we all agree that modifying createNew() is off the table.  The  
> only question now, in my mind is: Will doing auto-detect based on the  
> "DESCRIBE" response work?  I.e., if the "Content-Type:" in the response  
> is "application/sdp", do normal RTSP processing; if the "Content-Type:"  
> in the response is "application/x-rtsp-mh", do the Kasenna bullshit  
> processing.  If this can work, then this is what we should do, because  
> it will make all RTSP clients (not just VLC, but also things like  
> "openRTSP") work transparently, without the need for special parameters  
> telling the code, in advance, that the stream is 'Kasenna bullshit'.

I agree that modifying createNew is not a good solution.

I will test again once I have mp4 content, but it's not looking good
for this approach so far i.e it won't even work for mpeg2.



> The show-stopper issue here is:
>
>> (a) The application/x-rtsp-mh would have to be permanently added and
>>     DJ is fairly certain that this will break some VOD servers.
>
> Let's find out if this is really the case.  I.e., if the "Accept:"  
> header in a "DESCRIBE" request is
>          "Accept: application/sdp, application/x-rtsp-mh\r\n"
> (Note the order: "application/sdp" appearing before  
> "application/x-rtsp-mh"), then
>          1/ Does this break any known RTSP server (that does proper  
> RTSP)?, and

It breaks the first one I tried, the Kasenna :)

The opposite order works.


>          2/ Do Kasenna servers handle this properly, returning - in  
> their response - an "Content-Type:" header that contains  
> "application/x-rtsp-mh" for their hacked MPEG-2 streams, and  
> "application/sdp" for everything else?

Still unknown.


> If the answer to 1/ is No, and the answer to 2/ is Yes, then we should  
> be able to do the hacked Kasenna processing based on the "Content-Type:"  
> header returned in a "DESCRIBE" response.

And if the answer to 1/ is yes?

We have two options then, I think:

(1) Use the patch I have submitted. It works! For standard RTSP servers
     and Kasenna. The only objection seems to be that it passes an extra
     parameter (which has a default value).

(2) Another possibility is to always try "Accept: application/sdp" and
     if the response is "415 Unsupported Media Type", try again with
     "Accept: application/x-rtsp-mh".



Dermot.
--