[FFmpeg-devel] Realmedia patch

Luca Abeni lucabe72
Tue Sep 9 08:42:20 CEST 2008

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

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

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

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


More information about the ffmpeg-devel mailing list