[FFmpeg-devel] Realmedia patch

Luca Abeni lucabe72
Mon Aug 25 08:59:07 CEST 2008

Hi Ronald,

Ronald S. Bultje wrote:
>> Just one quick question: why are you using the RTP demuxer for receiving
>> RDT (which seems to be a different thing)? Has this been requested during
>> a previous review? If yes, then I suspect your patch is ok (but I think
>> this makes the RTP code even more convoluted).
>> If no, then I suspect the best thing to do would be to add a new
>> "RTSP_PROTOCOL_RDT" protocol to RTSPProtocol, and to use it for calling
>> an "rdt_parse_packet()" instead of rtp_parse_packet().
>> Also, I think there are no RTCP-like packets with RDT, so
>> rtp_check_and_send_back_rr() should not be called, and the RTCP input
>> port should not be opened...
> I guess the answer to all of this is "because it seemed like the
> easiest way to get it to work".


> My impression so far is that RDT is
> some sort of a modified RTSP, but it's largely the same (I think you
> agree here, right?).

Well, the point is (I am mainly writing this for other people that follow
this thread, so that they can get a better idea of the situation):
1) There are two different protocols that are used at the same time:
	- a "control" protocol providing "VCR-like" functionalities like
	  "start", "stop", "pause", "seek", etc... This is RTSP
	- a second protocol used to actually transmit the audio/video
	  data. This protocol is generally RTP (together with RTCP), but
	  different transport protocols can be used. For example, someone
	  uses raw UDP, and real uses its RDT protocol
2) Real seems to use a lightly modified RTSP, so I agree that RTSP code
    should be reused (adapting it) for supporting real streams
3) As a transport protocol, real does not use RTP, but its own protocol
    (RDT), which does not seem to share much with RTP.
    For example, RTP needs RTCP (if the client does not receive RTCP SR
    packets from the server, it cannot synchronise the audio and video
    streams). And I do not think RDT has anything similar... So, the RTP
    protocol in libavformat will open two UDP ports (one for RTP packets
    and one for RTCP packets), while RDT seems to only need one port.
4) The real problem that needs to be addressed here is that the code in
    libavformat/rtsp.c assumes that RTP can be the only protocol used for
    transporting audio and video data. So, it automatically associates
    RTSP ===> RTP.
    This is the thing that (in my opinion) needs to be fixed. As far as
    I can see, your patch works around this problem by modifying the RTP
    code, but I believe that the problem should be properly addressed
    by removing the wrong assumption from the RTSP code.

> As for RDT vs. RTP, yeah, there's great
> differences, but the infrastructure largely pointed at RTSP -> RTP so
> I just followed that and modified as accordingly.

Yes, as discussed above the current infrastructure is incorrect in
assuming "RTSP ===> RTP". But I believe that you addressed the problem
starting from the wrong point :)
(it is the RTSP code that is wrong and should be modified, not the RTP

> I could separate,
> but there'd be large similarities between RDT and RTP (then again, the
> boilerplate code between ASF and AVI demuxers is also the same, so
> maybe this is a mood point).

Maybe I am wrong, but from a quick look at the code I do not see too
many similarities between the two protocols.

> If you wish, I can do it all separately but I'm not sure if that'd
> make stuff easier. Basically the if(real){..}else{..} would just be in
> different functions, so to say.

At least the code would be more correct from the theoretical point
of view (see the discussion above). And we would avoid opening an UDP
port for non-existing RTCP packets ;-). And I guess the RDT code
could be simplified (no need to have two separate functions to parse
the header and the payload).


More information about the ffmpeg-devel mailing list