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 96FA7450BD for ; Thu, 5 Jan 2023 12:17:03 +0000 (UTC) Received: from [127.0.1.1] (localhost [127.0.0.1]) by ffbox0-bg.mplayerhq.hu (Postfix) with ESMTP id 3AEA168BD3B; Thu, 5 Jan 2023 14:16:59 +0200 (EET) Received: from nef.ens.fr (nef2.ens.fr [129.199.96.40]) by ffbox0-bg.mplayerhq.hu (Postfix) with ESMTPS id 869F968BCB0 for ; Thu, 5 Jan 2023 14:16:53 +0200 (EET) X-ENS-nef-client: 129.199.129.80 ( name = phare.normalesup.org ) Received: from phare.normalesup.org (phare.normalesup.org [129.199.129.80]) by nef.ens.fr (8.14.4/1.01.28121999) with ESMTP id 305CGqJQ021900 for ; Thu, 5 Jan 2023 13:16:53 +0100 Received: by phare.normalesup.org (Postfix, from userid 1001) id B2298EB5B7; Thu, 5 Jan 2023 13:16:52 +0100 (CET) Date: Thu, 5 Jan 2023 13:16:52 +0100 From: Nicolas George To: FFmpeg development discussions and patches Message-ID: References: <12120876.O9o76ZdvQC@basile.remlab.net> <61a2d014dae2970ffa0a68097b26eec8cac9a399.camel@voila.events> <3621898.0Uz0849ZAC@basile.remlab.net> <7f17349fa6a3ff1564e4211fcbe4aa72fa1b7b6d.camel@voila.events> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: <7f17349fa6a3ff1564e4211fcbe4aa72fa1b7b6d.camel@voila.events> X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.4.3 (nef.ens.fr [129.199.96.32]); Thu, 05 Jan 2023 13:16:53 +0100 (CET) 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: Camille Oudot (12023-01-04): > So does it still makes sense to have a patch to pass through a RTP > "reuseaddr" option to the underlying UDP URL "reuse" option? Yes, totally. But let us make it the right way: not just add this option and forward code, but correctly set up the objects so that all options are forwarded as necessary. See libavfilter/framesync.h for an example of code that does this. > Documenting the good use cases of course (although I'd start using it > for the wrong use case ;-)). If yes I'll resubmit the patch. Having several instances of ffmpeg / ffplay / whatever receive the same stream seems like a valid use case. > I'm still planning to have a look on a proper (e.g using only one > shared socket) implementation of rtcp-mux (easy one, I already have a > PoC working) and RTP Bundle (tougher one). Please. I suspect cheating with SO_REUSEADDR would not have been more straightforward anyway: the demuxer for each individual stream would have received the packets for all streams and would have to be taught to distinguish. Regards, -- Nicolas George _______________________________________________ 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".