Hi Kieran On Fri, May 23, 2025 at 04:45:53PM +0100, Kieran Kunhya via ffmpeg-devel wrote: > On Fri, May 23, 2025 at 4:00 PM Kieran Kunhya <kieran...@googlemail.com> > wrote: > > > > 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 > > 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 per packet with retransmission we will request a retransmission once we reasonably know 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 but 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 can 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 packet 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 but instead up to the point the sender has them at the time it sends the parity packet so this packet may include packet 6 or 7. Similarly when the receiver requests 2 parity packets seeing 8 without 6 and 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 [...] -- 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
signature.asc
Description: PGP signature
_______________________________________________ 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".
