[FFmpeg-devel] Realmedia patch

[Ronald S. Bultje]

Hi Luca,

On Mon, Aug 25, 2008 at 2:59 AM, Luca Abeni <lucabe72 at email.it> wrote:
> 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...
[..]
> 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).


OK, I'll try to separate the two. I would still like to use the
RTPDynamicProtocolHandler and some other RTP-like structures, but
those are mostly called from rtsp.c so I think that should be OK. I
guess I could rename Handler:parse_header to Handler:parse_packet and
use that (so that no explicit reference to RDT is needed).

For the generalizing of the RDT handling in rtsp.c, do you know if RDT
is always TCP? If so, I could make it a separate RTSPProtocol, like
TCP, UDP and UDP_MULTICAST, and could rotate over them in
make_setup_request() (although I'd need some code to handle it during
OPTIONS / DESCRIBE, but anyway...). Alternatively, I'd add a new
variable to the rtsp context that distinguishes between RTP and RDT.

Ronald

Ronald