On Fri, 23 May 2025, 21:35 Michael Niedermayer, <mich...@niedermayer.cc> wrote:
> 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 > Your diagram makes no sense and in protocols such as RaptorQ and other FEC like XOR it's a unidirectional channel. You don't request FEC packets in any of these protocols. There is a (potentially dynamic) percentage of FEC packets sent for the actual data.. Let's use your toy example of one parity packet after 20 data packets. The receiver has to wait 20 packets to be sure an FEC packet has been transmitted, adding latency. If the content is VBR it's even worse as you need out of band signalling to signal the worst case latency to avoid bursting. If the RTT is low then it might be quicker to just retransmit and it saves bandwidth as you don't have overhead. For long RTT links like London to Sydney unidirectional FEC might be a better tradeoff. 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".
