[FFmpeg-devel] Realmedia patch

Luca Abeni lucabe72
Tue Sep 9 16:32:44 CEST 2008


Hi,

Derk-Jan Hartman wrote:
[...]
>> The right thing is the following one:
>> 1) the "OPTION" command is used to detect the server type
> 
> OPTIONS

of course ;-)

>> 2) according to the server type, you can select a different protocol
>>    (RTP, RDT, etc...) in the "SETUP" command. This is done through the
>>    "Transport:" tag.
>>    The usage of RTP or RDT parsing functions depend on the answer you
>>    receive to "SETUP"
> 
> Yes, but if you have to check for all 5 or so types of protocols, that  
> could become a bit messy of course.
> 
> RTSP RAW/RAW/UDP (+ different Settop box implementations..... )
> RTSP AVP/UDP
> RTSP AVP/TCP
> RTSP RTP/HTTP/TCP
> RTSP RDT
> RTSP windows media server (has it's own nice exceptions :D )

I do not think we have to check for all the protocol. Based on the
information collected through "OPTIONS" (and maybe from the SDP), we
can guess the protocol to request. For example, it is useless to
request RDT, M$ RTSP, RAW/RAW/UDP, or RTP/HTTP/TCP to a standard
RSTP server. If, instead, the server is real, we will first ask for
RDT (but according to the last emails from Ronald it seems that we
can guess if the server wants to send RDT by looking at the SDP).

Anyway, my idea is that we need a flexible mechanism that allows
to send requests and select the protocol based on the server type.

[...]
> The problem is there are too many RTSP variations

I completely agree ;-)
And the big problem seems to be that some of those variations
violate the standard :(

> and that the RTSP  
> spec itself allows for too much freedom (how the hell are you supposed  
> to know if Scale: is supported? ). It will be difficult to implement  
> everything in a compatible way.

Oh, well... I was not thinking about supporting everything immediately...
I was just trying to think about the functionalities for basic playback.

> Having dealt with these issues a lot I  
> really do hope a clean implementation can be made in ffmpeg.

I hope that too... But we are still a little bit far from it ;-)


				Luca




More information about the ffmpeg-devel mailing list