[FFmpeg-devel] [PATCH] RTP local udp port issue fix (ticket 916)

Luca Abeni lucabe72 at email.it
Tue Jan 17 08:32:57 CET 2012


Hi all,

On 01/16/2012 07:51 PM, Michael Niedermayer wrote:
> On Mon, Jan 16, 2012 at 08:55:18PM +0400, Dmitry Volyntsev wrote:
>> Abstract: Ffmpeg doen't check that udp port which it selects for
>> incoming rtp already receives packets
>>
>> Detailed description, steps to reproduce and ffmpeg logs and wireshark
>> logs of the issue: https://ffmpeg.org/trac/ffmpeg/ticket/916
>>
>> Description: RTSP session brakes some times and rstp server doesn't
>> receive any notification about it and still sends packet in rtp
>> session. new ffmpeg instance request the same port for incoming
>> streams and doesn't detect it, it receives two stream simultaneously
>> but tries constantly re-synchronize with two interleaved streams.
>>
>> I've checked what other implementation of RTP/RTSP do in this case.
>> 1) LIVE555 library (inside vlc media player)
>> 2) gstreamer framework
>> Both of them just request no udp port from special range, but use port
>> which an OS provides.
>> It this case local udp ports grow sequentially and issue case doesn't
>> occur. The remote side after some period of time stops sending packets
>> to old ports.
>
> from your description and my limited knowledge of RTSP the patch looks
> good. I dont understan though why the code didnt do this originally
>
> maybe luca can comment ?

I have currently no time to look at all the details... But there is something
wrong in what's happening: when the second ffmpeg instance tries to use port
5000 for the RTP port, ffurl_open() should fail. And so port 5002 is tried
(thanks to the "while (j <= RTSP_RTP_PORT_MAX) {" loop) and so on...
Hence, there should be no collision.

Maybe libavformat ends up using SO_REUSEADDR for some reason? I'd check that...

I think the proposed patch might be wrong, because it might end up in using odd
numbers for the RTP port (I think RTP ports should be even numbers, and RTCP
ports should be odd).


				Luca


More information about the ffmpeg-devel mailing list