Re: [FFmpeg-devel] STF RaptorQ

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

On Fri, May 23, 2025 at 4:00 PM Kieran Kunhya <kieran618@googlemail.com> wrote:
>
> 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

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).

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".