From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from ffbox0-bg.mplayerhq.hu (ffbox0-bg.ffmpeg.org [79.124.17.100]) by master.gitmailbox.com (Postfix) with ESMTP id 0B1184508A for ; Tue, 3 Jan 2023 19:13:23 +0000 (UTC) Received: from [127.0.1.1] (localhost [127.0.0.1]) by ffbox0-bg.mplayerhq.hu (Postfix) with ESMTP id 6F5DF68BD94; Tue, 3 Jan 2023 21:13:21 +0200 (EET) Received: from mail-wm1-f42.google.com (mail-wm1-f42.google.com [209.85.128.42]) by ffbox0-bg.mplayerhq.hu (Postfix) with ESMTPS id 4EDE968B6F0 for ; Tue, 3 Jan 2023 21:13:14 +0200 (EET) Received: by mail-wm1-f42.google.com with SMTP id ay40so23631781wmb.2 for ; Tue, 03 Jan 2023 11:13:14 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=voila.events; s=google; h=content-transfer-encoding:mime-version:user-agent:references :in-reply-to:date:to:from:subject:message-id:from:to:cc:subject:date :message-id:reply-to; bh=Dtyvh6ke71Kd4Wg8QpBYMKTUS9jw/JRDao/ZKSAti+k=; b=eNq8BnDFOgLnDfpRFQQSnUhl1EQiHVtrNN/1XF3sv5lKsFq85Ru2pSwUE5QrYnpAwt HbNwylMTUUAKP1utyfCLf2MQ4iwlerL4YxITLywq+k+2Ef3TuNzb7apfgzCty07YRSwO +B29G/fdq6eZsx7jHKGPxDVVZt3tzzCeaHgfE= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=content-transfer-encoding:mime-version:user-agent:references :in-reply-to:date:to:from:subject:message-id:x-gm-message-state:from :to:cc:subject:date:message-id:reply-to; bh=Dtyvh6ke71Kd4Wg8QpBYMKTUS9jw/JRDao/ZKSAti+k=; b=pZI79x0IzufspWQj9CUNa9RjI7azXjofBswvxK0rIi75yTIm0Nz9gZZfuxF63IWn5I 1q85wWXwnT+yMEkEYiQJB3k6/vonDY1XTi6olc0+jke4FHn2ria4dH8Yg1NUJKCqJRCJ F26W+UtE8uX6NzqZfMesVrHJcPeUm+I9l1M0iQPzBpcg60jy4kOSDYD/T1tHkoTbl7sU EiGTJPCUKKqe23idj39OH5rF8Nth3OKzcuHdsxLTm12MNxl8tHSdpu2EWi+LFCLC7VPC hN4CZVSwUlndGILTNH6fcBkORR4cT8OPWpt9ZphPZQIObK5BOc/YiggZqYKa9cUUoxPu rOZg== X-Gm-Message-State: AFqh2kpmYXZa6L2i2rWyMs4UOk5rcJdhSJF6DR9D1tdwUCAq81ZQFza9 0XiToqf1vBucud8ykdTG0W43B8nIJY9lvxUlIws= X-Google-Smtp-Source: AMrXdXtu0ZvU8CWJL7NVXzu2C6UxqOSbHFZFKtdCwSeKCfqI90nZauIItIm/Prod5ONP3UYAqmzlYA== X-Received: by 2002:a05:600c:601b:b0:3d3:56ce:5693 with SMTP id az27-20020a05600c601b00b003d356ce5693mr31397758wmb.17.1672773193393; Tue, 03 Jan 2023 11:13:13 -0800 (PST) Received: from colap3.home (lfbn-ren-1-691-195.w81-53.abo.wanadoo.fr. [81.53.29.195]) by smtp.gmail.com with ESMTPSA id m1-20020a7bca41000000b003d1de805de5sm42532910wml.16.2023.01.03.11.13.12 for (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Tue, 03 Jan 2023 11:13:12 -0800 (PST) Message-ID: From: Camille Oudot To: ffmpeg-devel@ffmpeg.org Date: Tue, 03 Jan 2023 20:13:12 +0100 In-Reply-To: <3621898.0Uz0849ZAC@basile.remlab.net> References: <12120876.O9o76ZdvQC@basile.remlab.net> <61a2d014dae2970ffa0a68097b26eec8cac9a399.camel@voila.events> <3621898.0Uz0849ZAC@basile.remlab.net> User-Agent: Evolution 3.38.3-1+deb11u1 MIME-Version: 1.0 Subject: Re: [FFmpeg-devel] [PATCH] avformat/rtpproto: add support for RTP/UDP socket reuse X-BeenThere: ffmpeg-devel@ffmpeg.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: FFmpeg development discussions and patches List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Reply-To: FFmpeg development discussions and patches Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Errors-To: ffmpeg-devel-bounces@ffmpeg.org Sender: "ffmpeg-devel" Archived-At: List-Archive: List-Post: Why does the "reuse" option exists on the "udp" protocol in the first place? Why would it not apply to "rtp" also? Here is the original patch proposal on udp: http://ffmpeg.org/pipermail/ffmpeg-devel/2006-October/thread.html#18946 > Sure. But then that does not solve the problem of RTCP mux and SDP > bundle, which normally would use the exact same IP address and port > number on the local end (and also on the far end, if set). I confirm the requirement is to send several RTP streams with FFmpeg with identical proto/src_ip/src_port/dst_ip/dst_port. > > > It's not that simple. The semantics of REUSEPORT varies between Linux > and BSD. IIRC, REUSEPORT was originally meant by BSD to allow > multiple processes to listen on the same multicast group, but then > Linux redefined it with radically different semantics, for receive > load-balancing purpose. They added SO_REUSEPORT_LB in BSD to mimic the Linux behavior. > > Repeating myself, but I don't see how that solves the problem. You > don't need REUSEADDR for two sockets to send to the same remote > IP/port, and you cannot rely on it to send from the same local > IP/port. It *does* work, at least on Linux: I can send several RTP streams from the exact same local IP/port (and _to_ the same IP/port too but that's not a problem in general as you point it) with either REUSEADDR or REUSEPORT options set. Here are ffmpeg strace traces for local RTCP port == local RTP port. The command sends a video stream to the following RTP URL (RTP and are sent from the same local source port): rtp://127.0.0.1:40000?localaddr=127.0.0.1&localport=22300&localrtcpport =22300&rtcpport=40000 without SO_REUSEPORT ==================== ... socket(AF_INET, SOCK_DGRAM|SOCK_CLOEXEC, IPPROTO_IP) = 4 bind(4, {sa_family=AF_INET, sin_port=htons(22300), sin_addr=inet_addr("127.0.0.1")}, 16) = 0 getsockname(4, {sa_family=AF_INET, sin_port=htons(22300), in_addr=inet_addr("127.0.0.1")}, [128->16]) = 0 setsockopt(4, SOL_SOCKET, SO_SNDBUF, [32768], 4) = 0 socket(AF_INET, SOCK_DGRAM|SOCK_CLOEXEC, IPPROTO_IP) = 5 bind(5, {sa_family=AF_INET, sin_port=htons(22300), in_addr=inet_addr("127.0.0.1")}, 16) = -1 EADDRINUSE (Address already in use) with SO_REUSEPORT ================= ... socket(AF_INET, SOCK_DGRAM|SOCK_CLOEXEC, IPPROTO_IP) = 4 setsockopt(4, SOL_SOCKET, SO_REUSEPORT, [1], 4) = 0 bind(4, {sa_family=AF_INET, sin_port=htons(22300), sin_addr=inet_addr("127.0.0.1")}, 16) = 0 getsockname(4, {sa_family=AF_INET, sin_port=htons(22300), sin_addr=inet_addr("127.0.0.1")}, [128->16]) = 0 setsockopt(4, SOL_SOCKET, SO_SNDBUF, [32768], 4) = 0 socket(AF_INET, SOCK_DGRAM|SOCK_CLOEXEC, IPPROTO_IP) = 5 setsockopt(5, SOL_SOCKET, SO_REUSEPORT, [1], 4) = 0 bind(5, {sa_family=AF_INET, sin_port=htons(22300), sin_addr=inet_addr("127.0.0.1")}, 16) = 0 Regards -- 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".