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

Dmitry Volyntsev xeioexception at gmail.com
Tue Jan 17 09:02:18 CET 2012


2012/1/17 Luca Abeni <lucabe72 at email.it>:
> 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
> _______________________________________________
> ffmpeg-devel mailing list
> ffmpeg-devel at ffmpeg.org
> http://ffmpeg.org/mailman/listinfo/ffmpeg-devel


> when the second ffmpeg instance tries to use port
 5000 for the RTP port, ffurl_open() should fail. And so port 5002 is tried
It is true, but only if the seconds instance starts while first
instance still active. But the issue little-bit differs.

If fact, the second instance starts when first instance already
stopped (killed or something), so it closes opened udp ports. But (it
is important for the issue), remote side still sends data to rtp/rtcp
ports. Also important things for the issue , the remote side should
lost (some how) notification about first instance closing.

> 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).
Yes, you are right. I'm going consider this requirement in the next patch.

Thanks you, for comments

-- 
Be happy,
Best regards,
Dmitry Volyntsev


More information about the ffmpeg-devel mailing list