From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from ffbox0-bg.ffmpeg.org (ffbox0-bg.ffmpeg.org [79.124.17.100]) by master.gitmailbox.com (Postfix) with ESMTPS id 6EE914C2C8 for ; Fri, 23 May 2025 20:35:50 +0000 (UTC) Received: from [127.0.1.1] (localhost [127.0.0.1]) by ffbox0-bg.ffmpeg.org (Postfix) with ESMTP id 9C34D68DF90; Fri, 23 May 2025 23:35:47 +0300 (EEST) Received: from relay9-d.mail.gandi.net (relay9-d.mail.gandi.net [217.70.183.199]) by ffbox0-bg.ffmpeg.org (Postfix) with ESMTPS id C36B968DEDF for ; Fri, 23 May 2025 23:35:45 +0300 (EEST) Received: by mail.gandi.net (Postfix) with ESMTPSA id E2DC54430D for ; Fri, 23 May 2025 20:35:44 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=niedermayer.cc; s=gm1; t=1748032545; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=CwgUchEdhypMOIDybqpZ0GBpkV882MhtbttJu2aEwhs=; b=h29wJCt0/SOjE+OjrnG6fmg41zU+/eQBW09SwGMdfSM6cimGVXAQgdtP/aswIT+gf8P5Tk hbuIo1cbTADkgXOgHqxYsFvvPEv7zyc1PnkPNdk5FbPo20akJ3yRPkZXBe3kicBGfAI5GM aalwhYLEbsJhjL3sqeJnVvRZ2RrDCSZLu8BOJLayHNbw+nxUJG9gXbL2cL2swC8rf/3ckb 0TlkL/9TYNsIN6EgTHMlfsrbpBEbsYt2vaQv8yMYkxZXgarRNl+cW5BHnCm4X0gEvtpwcg wUR/bAxAD51LgP/x2nwmLPElqXSafinUZRzMEsjL/7vRgFk4jVTxqCQYuX/kgQ== Date: Fri, 23 May 2025 22:35:43 +0200 From: Michael Niedermayer To: FFmpeg development discussions and patches Message-ID: <20250523203543.GH29660@pb2> References: <20250523094514.GW29660@pb2> MIME-Version: 1.0 In-Reply-To: X-GND-State: clean X-GND-Score: -85 X-GND-Cause: gggruggvucftvghtrhhoucdtuddrgeeffedrtddtgdelkedvucdltddurdegfedvrddttddmucetufdoteggodetrfdotffvucfrrhhofhhilhgvmecuifetpfffkfdpucggtfgfnhhsuhgsshgtrhhisggvnecuuegrihhlohhuthemuceftddunecusecvtfgvtghiphhivghnthhsucdlqddutddtmdenfghrlhcuvffnffculdduhedmnecujfgurhepfffhvffukfhfgggtuggjsehgtderredttdejnecuhfhrohhmpefoihgthhgrvghlucfpihgvuggvrhhmrgihvghruceomhhitghhrggvlhesnhhivgguvghrmhgrhigvrhdrtggtqeenucggtffrrghtthgvrhhnpeelkeeggfffiedufeejueffjeduhedttdduledtheevveevtdeiueelhfdtuedtkeenucfkphepgedurdeiiedrieejrdduudefnecuvehluhhsthgvrhfuihiivgeptdenucfrrghrrghmpehinhgvthepgedurdeiiedrieejrdduudefpdhhvghloheplhhotggrlhhhohhsthdpmhgrihhlfhhrohhmpehmihgthhgrvghlsehnihgvuggvrhhmrgihvghrrdgttgdpnhgspghrtghpthhtohepuddprhgtphhtthhopehffhhmphgvghdquggvvhgvlhesfhhfmhhpvghgrdhorhhg X-GND-Sasl: michael@niedermayer.cc Subject: Re: [FFmpeg-devel] STF RaptorQ 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: multipart/mixed; boundary="===============4723822128579441951==" Errors-To: ffmpeg-devel-bounces@ffmpeg.org Sender: "ffmpeg-devel" Archived-At: List-Archive: List-Post: --===============4723822128579441951== Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="aMpzU8GE10cZrvW6" Content-Disposition: inline --aMpzU8GE10cZrvW6 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Hi Kieran On Fri, May 23, 2025 at 04:45:53PM +0100, Kieran Kunhya via ffmpeg-devel wr= ote: > On Fri, May 23, 2025 at 4:00=E2=80=AFPM Kieran Kunhya wrote: > > > > On Fri, May 23, 2025 at 3:50=E2=80=AFPM Devin Heitmueller > > wrote: > > > > > > Hello Michael, > > > > > > On Fri, May 23, 2025 at 5:45=E2=80=AFAM Michael Niedermayer > > > wrote: > > > > On Thu, May 22, 2025 at 07:55:40PM -0400, Devin Heitmueller wrote: > > > > > On Thu, May 22, 2025 at 7:42=E2=80=AFPM Kieran Kunhya via ffmpeg-= devel > > > > > wrote: > > > > > > I wanted to put on the record that adding RaptorQ to FFmpeg isn= 't > > > > > > maintenance of FFmpeg. > > > > > > > > i agree adding RaptorQ itself is probably not maintenance > > > > > > Ok, so that much everybody seems to agree on. Great. > > > > > > > > > It's adding an obscure FEC protocol to FFmpeg, > > > > > > > > tornado and raptor codes are not obscure. > > > > and FFmpeg supports hundreads of much more obscure things > > > > > > Sure, no disagreement there. While I've personally never used any of > > > the codecs that support video games from the 1990's, I don't really > > > have any problem with them being in ffmpeg. That said, in my opinion, > > > I doubt STF would really think it's a good use of their funds to add > > > support for new codecs for such games. > > > > > > > > I'm not sure I've seen any commercial gear that does RaptorQ for = FEC, > > > > > so it's not clear what the use cases are if the goal is > > > > > interoperability. > > > > > > > > its IMHO for communication between tools that on both sides > > > > use our software > > > > > > > > If no commercial gear uses a reliable FEC system all teh better > > > > for us > > > > > > Wow, that's quite a leap to suggest that because there aren't open > > > standards using RaptorQ that there isn't commercial video transmission > > > gear out there that doesn't do a good job with FEC. > > > > > > > > If somebody really wants to be paid to work on > > > > > reliable transport protocols, the time would be better spent impr= oving > > > > > the RIST or SRT integration, which is where most of the industry = is > > > > > putting their energy. > > > > > > > > FEC is supperior to ARQ > > > > for ARQ, each receiver needs to request the lost packet > > > > while for FEC the sender just needs to know or guess how many packe= ts > > > > where lost. > > > > 1. FEC is lower latency >=20 > This isn't true. You need a large FEC matrix to handle burst packet > loss and you have to buffer for the duration of this matrix. > At low bitrates this duration can be really long. (100 packets at > 1mbit/s is already roughly a second). Even with this constructed example, FEC is lower latency than no FEC lets take your 1mbit/sec and your 100packets a second, that makes 10kbit pe= r packet with retransmission we will request a retransmission once we reasonably kno= w a packet is lost, but we will not be sure because sometimes a packet is just late or= out of order so we at the very least will have to wait for the next packet to come in bu= t in reality maybe we wait an extra one to conserve bandwidth and not request a reatransmit of= every out of order packet. We will also end up asking for packets that we actually do receive later, these will waste bandwidth with FEC lets say we have 1 extra parity packet every 20 packets, but you c= an pick other numbers now we do the same, we ask for a retransmission at the same time as before. BUT and thats the crucial difference we dont need to ask for a specific pac= ket we just ask for how many we are currently missing Lets pick actual random numbers: Packets 1, 3, 2, 4, 5, 8, 6, 9, 10 ARQ: R2 R6R7 (you can make this burst arbitrary long) FEC: R1 R2 Now the differnce are multiple First the parity packet send for R1 will not just include packets up to 3 b= ut instead up to the point the sender has them at the time it sends the parity packet so this pa= cket may include packet 6 or 7. Similarly when the receiver requests 2 parity packets seeing 8 without 6 an= d 7 by the time the receiver receives the first parity packet it will have received packet = 6 and not need to wait for the 2nd one again there is a CLEAR advantage over ARQ in lower latency and we have NOT even used the 1/20 parity we get by default you can make teh burst as long as you want, theres an advanatge for FEC * If a packet is received after its retransmission is requested * If any transmitted by default parity packets cover the range * If any previous requested parity happens to cover any part of the burst Now i dont expect that iam the first to suggest this system above, but maybe i am. Also above is just what i came up with in 15min, i expect if some mathematicans think about this they will find more ways to reduce latency with FEC. Giving one an extra optional tool cant make the optimal solution worse, it can make it better though. thx [...] --=20 Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB Its not that you shouldnt use gotos but rather that you should write readable code and code with gotos often but not always is less readable --aMpzU8GE10cZrvW6 Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iF0EABEKAB0WIQSf8hKLFH72cwut8TNhHseHBAsPqwUCaDDcHAAKCRBhHseHBAsP q82pAJ4ghn7bKtqlYe4FFqcfannZFW0hpwCeLeybsXuvQs2e86oTJbcyP6afjlc= =0fyj -----END PGP SIGNATURE----- --aMpzU8GE10cZrvW6-- --===============4723822128579441951== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ 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". --===============4723822128579441951==--