[FFmpeg-devel] Realmedia patch

[Derk-Jan Hartman]

On 9 sep 2008, at 08:42, Luca Abeni wrote:
> Hi Ronald,
>
> Ronald S. Bultje wrote:
> [...]
>>> AFAIK, the only not-fully-standard feature provided by qt is in "RTP
>>> over TCP" handling: qt does not use the standard RTP over RTSP, but
>>> seems to use RTP over HTTP. I've been told that having it working
>>> should be fairly easy, but I suspect that some additional work might
>>> be needed to correctly integrate "RTP over HTTP" in libavformat in a
>>> clean way.
>>
>> I can confirm that setup is easy (as you said, just add payloads) and
>> that RTP over RTSP looks very weird, i.e. I don't understand how to
>> parse the data.
>
> You mean RTP over HTTP, right? (because RTP over RTSP is already
> supported ;-). I've been told that even if it is a non-standard
> combination, there is some document that describes it in details.
> So, knowing how to parse the data should not be a problem (but this
> is just what I've been told: I never searched for such a document).

http://developer.apple.com/documentation/QuickTime/QTSS/Concepts/chapter_2_section_14.html

>
>> UDP doesn't work, I never receive any data, I'll try
>> some different URIs, maybe my test is broken [1]...
>
> I just tried it. It looks like the problem is that this URL provides
> "X-QDM" audio and "X-SorensonVideo", whatever they are...
> Obviously, libavformat does not support them (AFAIK, nothing similar
> to this is described in any RFC, so I do not know how to handle
> these payloads).
>
> Anyway, I know for sure that ffmpeg can receive "regular" mov or mp4
> files (containing mp2, mp3, AAC, mpeg4 video or h.264 video) streamed
> by qt.

This has also been my experience. I'm not sure if ffmpeg supports the  
X-QT RTP format, but that could be supported, implementations of this  
exist around the web. (live555 has it for sure). I have been unable to  
find any hints on X-SorensonVideo and X-QDM packetization.

>> I tried a second stream, quicktime served by a realmedia server, and
>> this breaks horribly. Makes me think that maybe this separation  
>> within
>> RTPDynamicPayloadHandler and RTSP_SERVER_* wasn't the best of ideas.
>> We should separate into multiple layers, where SDP parsing is a
>> server-dependent thing, whereas data parsing _alone_ is
>> payload-type-dependent.
>
> The right thing is the following one:
> 1) the "OPTION" command is used to detect the server type

OPTIONS
>
> 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 )

> 3) the payload type is determined by the "rtpmap" attributes in the
>    SDP lines describing the various media.
> So, transpor-protocol (rtp, rdt, etc...) parsing is not payload
> dependent, and does not depend on the SDP. Payload parsing is
> SDP-dependent.
>
> Your code assumes real==rdt, so if a real server does not want to  
> stream
> over rdt the setup fails. Which, in a first approximation, is fine (I
> asked you to first extend the rtsp code making it more generic, and to
> add live/rdt support later, but you decided this was more complex).
> Anyway, this is easily fixable by falling back to standard RTSP if a
> "real SETUP" command fails (if a real server refuses to work with the
> real protocol, then I think it is ok to handle it as a standard rtsp
> server).
> So, this really is easily fixable.
>
>> Maybe I should rewrite the RTSP/RTP demuxers after all. :-).
>
> As I said some time ago, I believe the RTSP/RTP demuxer is not in a
> good shape, and I think it needs to be heavily modified (if not  
> rewritten).
> But this is not easy, and requires a good design to start with...
> Moreover, I am not the RTSP maintainer (and right now, I have no time
> to maintain it)...

The problem is there are too many RTSP variations, 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. Having dealt with these issues a lot I  
really do hope a clean implementation can be made in ffmpeg. I'm not  
totally happy with live555 + separate real RTSP module at the moment  
in VLC. Let alone the lack of support of IPv6 in live555.

DJ