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 ESMTPS id 9B877477C3 for ; Mon, 20 Jan 2025 06:05:31 +0000 (UTC) Received: from [127.0.1.1] (localhost [127.0.0.1]) by ffbox0-bg.mplayerhq.hu (Postfix) with ESMTP id E83B868AA1B; Mon, 20 Jan 2025 08:05:27 +0200 (EET) Received: from mail-yb1-f177.google.com (mail-yb1-f177.google.com [209.85.219.177]) by ffbox0-bg.mplayerhq.hu (Postfix) with ESMTPS id D1F9E68A718 for ; Mon, 20 Jan 2025 08:05:21 +0200 (EET) Received: by mail-yb1-f177.google.com with SMTP id 3f1490d57ef6-e3a26de697fso6347655276.3 for ; Sun, 19 Jan 2025 22:05:21 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1737353120; x=1737957920; h=to:subject:message-id:date:from:in-reply-to:references:mime-version :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=fwLrRQ2aCwlT5mA+qeZx1oAk+bPmK38PX/LMRVGLZlU=; b=drZrDovZ0OJO2mYgkPdYVRb4uyyMEeipAVEUD9Op4D2Oi/h78ApLCsdJejMOFpRSXt VnJaaQ5h94rL8/6eSuo8uf7z3KKjI1MRv5SVjvtxiUaQY9r6H8tf6dvZvQhrgyxQaKwa vbIy6l4nQT4Gq1H0f/7Cx8rdwBsHSIePi+yeAMzLcihWKF72zZttR5SY3NaIGPwKnaN8 iwnJTLNrNF7XTgea0bYaTxqCTwZS4ePkThkC8Ua9auAqmF1y0TUhkjWeKPyq/2flxJCE cHLdxTQ0EhL9lLI+aSluIgN2SXUfh3+R8otfsGfg95hXGfr2TLzcR6KeWMcdZNA2OqfY U1Aw== X-Gm-Message-State: AOJu0Yz0Rgbdg+pLwk4RXaaDL+sKWWsjDe1aG81vyssxaUe7jmql4yaU bQdXn1MLfkA6yAWm5Kbe72DbkHPj5VMTfeV0TOagR//cu7ixJiIoQUV+6B03I/ridQiVK4+FAX3 pNyoKG/fY3SkqNtWRSZ0hmbrK5TmOKA== X-Gm-Gg: ASbGnctDIrARC+UwZgPuSSs7xCHvEr6rCk6aquCj5I1lNMNvPkEG4lYlJRyC/tq+bUJ ePLc0Ls9Dz1+oGwFJ82HlSV8MGOH+9BygMmyc4LkQJznoB2L5lT4= X-Google-Smtp-Source: AGHT+IFkxcAWa8aVulQFRw4PzYS35ILF4f+7rgieRn4AxOKB1UFQrm7xheQwMtOuTd4pkIep0SDI4lUx7ZO9b/wBklk= X-Received: by 2002:a05:6902:1288:b0:e57:4254:a765 with SMTP id 3f1490d57ef6-e57b1099b1amr8337417276.29.1737353120107; Sun, 19 Jan 2025 22:05:20 -0800 (PST) MIME-Version: 1.0 References: <082f12b8-2319-47d2-8854-f361d2039748@gmail.com> <20250117170823.GM4991@pb2> <20250119222239.GU4991@pb2> In-Reply-To: <20250119222239.GU4991@pb2> Date: Mon, 20 Jan 2025 06:05:11 +0000 X-Gm-Features: AbW1kvYHvHn9uMdxMHl3BZvt6Z4ohK1qHqFinxX43VBtpIO0MZ9e7mwO3H5m-Tc Message-ID: To: FFmpeg development discussions and patches X-Content-Filtered-By: Mailman/MimeDel 2.1.29 Subject: Re: [FFmpeg-devel] [PATCH v0] Implement promeg decoder. 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: , From: Kieran Kunhya via ffmpeg-devel Reply-To: FFmpeg development discussions and patches Cc: Kieran Kunhya 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: On Sun, 19 Jan 2025, 22:22 Michael Niedermayer, wrote: > The part i do not agree with and iam not convinced about is that this > cannot be done in a clean and fully working and heuristics free > way in the real world. > Protocols are not the same as codecs. Just because you have a hammer, everything isn't a nail. Have you ever written a protocol for a lossy network transport before? Protocols are exceptionally difficult to unit test (and this one is relatively non complex as it's unidirectional). Let's pick a simple problem. How do you detect a source encoder restart, considering this spec forces you to set SSRC=0? (why I don't know, but some devices do require it). You are forced to use heuristics. I picked a sequence number gap of 200 packets as this is twice as big as the maximum allowed matrix. This will false positive roughly 0.3% of the time but if you've lost 200 packets you probably will be in a resync condition anyway. You could also use RTP timestamps in the heuristics (but some RTP stream payloads have constant timestamps per frame or timestamps are set incorrectly), you could try packet arrival times, but there are stream splicers out there that splice two RTP streams without packet timing gaps. Note that this simple issue already exists and has existed for years in the RTP demux, a protocol that is much more important than legacy FEC. The only way to solve this is to use heuristics. Rinse and repeat for another hundred or so edge cases, and make sure they don't interact. Like I said, it's hard to unit test, so remember, you'll have to test all of these by hand. Protocols are not easy. There's a reason Zoom is so good and all the alternatives (OSS included) suck. Regards, Kieran Kunhya > _______________________________________________ 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".