Re: [FFmpeg-devel] STF RaptorQ

[Kieran Kunhya via ffmpeg-devel <ffmpeg-devel@ffmpeg.org>]

On Fri, May 23, 2025 at 3:50 PM Devin Heitmueller
<devin.heitmueller@ltnglobal.com> wrote:
>
> Hello Michael,
>
> On Fri, May 23, 2025 at 5:45 AM Michael Niedermayer
> <michael@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-request@ffmpeg.org with subject "unsubscribe".