On Fri, May 23, 2025 at 3:50 PM Devin Heitmueller <devin.heitmuel...@ltnglobal.com> wrote: > > Hello Michael, > > On Fri, May 23, 2025 at 5:45 AM Michael Niedermayer > <mich...@niedermayer.cc> wrote: > > On Thu, May 22, 2025 at 07:55:40PM -0400, Devin Heitmueller wrote: > > > On Thu, May 22, 2025 at 7:42 PM Kieran Kunhya via ffmpeg-devel > > > <ffmpeg-devel@ffmpeg.org> 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 improving > > > 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 packets > > where lost. > > 1. FEC is lower latency > > 2. FEC does not suffer from "oops the retrasmit was lost too" > > 3. if you have 3 receivers one lost packet 5 one packet 8 and one packet 0 > > with ARQ you need to send 3 individual packets with FEC you CAN broadcast > > the same 1 packet to all 3 receivers to recover them. > > This is largely an academic discussion that I could argue either side > of, depending on the intended use case. There are tradeoffs to both > approaches, and which one is most appropriate depends on how it's > being used. > > > Also FEC is VERY widely used, just not where you are looking. > > from compact disks, to phone networks to inter planetary communication > > since over 50 years its the standard, voyager in 1970 used FEC already. > > Please tell me that you're not seriously trying to explain to me that > FEC is widely used and has been around for decades to solve lots of > real-world problems. It would be difficult for me to not read that > with a very condescending tone.
Michael doesn't understand the difference between block FEC and packet FEC so he's not being condescending. Kieran _______________________________________________ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
