[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
code)
> 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).
Luca
More information about the ffmpeg-devel
mailing list