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. > > I agree with Kieran that this seems to largely be outside the STF > > objectives (i.e. sustainability for open source projects). > > A new implementation of RIST, SRT, Raptor and so on may fall outside > but redesigning the protocol layer in FFmpeg would perfectly fit inside > "sustainability for open source projects" > When you want A and B and both are connected, you ask for the funding > to be for the side that fits inside the guidelines > So this STF project could be changed to center on maintaince of the > protocol layer instead of a RaptorQ/SRT/RIST implementation i think. I'm certainly not suggesting anybody implement a new version of RIST or SRT (and on a personal note I give Kieran an enormous amount of credit for building his own SRT implementation). But yeah, I think most people who have looked closely at the ffmpeg protocol layer acknowledge it could be improved, and that seems like the thing that someone could easily convince STF of. Devin -- Devin Heitmueller, Senior Software Engineer LTN Global Communications o: +1 (301) 363-1001 w: https://ltnglobal.com e: devin.heitmuel...@ltnglobal.com _______________________________________________ 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".
