Re: [FFmpeg-devel] [PATCH] avformat/rtpproto: add support for RTP/UDP socket reuse - Rémi Denis-Courmont

From: "Rémi Denis-Courmont" <remi@remlab.net>
To: FFmpeg development discussions and patches <ffmpeg-devel@ffmpeg.org>
Subject: Re: [FFmpeg-devel] [PATCH] avformat/rtpproto: add support for RTP/UDP socket reuse
Date: Sun, 25 Dec 2022 11:00:14 +0100
Message-ID: <161CB574-83C0-43B8-A1C7-11D90456DFD2@remlab.net> (raw)
In-Reply-To: <79439d3675acb30d0688eed9c718e975c8f063b0.camel@voila.events>

Le 24 décembre 2022 14:07:26 GMT+01:00, Camille Oudot <camille+ffmpeg-devel@voila.events> a écrit :
>Hello,
>
>On Sat, 2022-12-24 at 13:36 +0200, Rémi Denis-Courmont wrote:
>> I don't see why you need an option for this. In parsing the SDP, it
>> should be self-evident if a given socket needs to be reused for RTCP-
>> mux or for SDP BUNDLE.
>
>I indeed disregarded the "receiving RTP streams" part, my bad. I should
>clarify that this patch is only useful for _sending_ bundled RTP
>streams and muxed RTCP sender reports. I am currently using this patch
>successfully in a simulcast streaming WebRTC infrastructure, that could
>not work without it.
>
>Only the AV_OPT_FLAG_ENCODING_PARAM should be set in the option's
>flags, as this is the only case that makes sense and properly works.
>
>Analyzing the corresponding SDP options and opening only one socket and
>demuxing in userspace should be the way to go for reading such streams
>as you pointed it. Again I must clarify that this use case is not
>covered, and will set the option's flags accordingly.
>
>Thanks for your feedback.
>
>-- 
>Camille
>
>
>_______________________________________________
>ffmpeg-devel mailing list
>ffmpeg-devel@ffmpeg.org
>https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
>
>To unsubscribe, visit link above, or email
>ffmpeg-devel-request@ffmpeg.org with subject "unsubscribe".

That is not how REUSEADDR works in general. It's originally meant to allow, well, literally reusing the same address/port pair immediately after it's been released.

It's not meant to share the same address/port concurrently. That part varies by OS, and causes obvious security issues on multi-user systems. Again, there is also REUSEPORT, which is what you'd want on Linux in this case, but behaves differently on BSD and doesn't exist at all on Windows (IIRC).

So even for sending, I don't think this patch really works.
_______________________________________________
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

To unsubscribe, visit link above, or email
ffmpeg-devel-request@ffmpeg.org with subject "unsubscribe".