Hello all, I've got some experience in this particular area, so figured it might be helpful to offer another voice.
Kieran makes a number of excellent points, and I largely agree with his discussion of the problem space. It's an intrinsically difficult problem. The data arrives on multiple sockets, leading to all sorts of opportunities for timing behavior and reordering issues. And, in my experience, I certainly agree with Kieran's assertion that the quality of implementations vary wildly across both open source and commercial products (e.g. hardware encoders and transcoders) that attempt to implement the standard. Not to mention the interoperability issues when receiving streams from all these different products. Building an implementation where you are confident that it does it "right" generally means having a large corpus of test vectors that exercise edge cases both in delivery timing and packet loss, assessing the result to determine which packets should have been recoverable versus what was actually recovered. This is considerably beyond the sorts of tests ffmpeg typically does in their FATE suite (which AFAIK doesn't attempt to validate libavformat protocols at all). That said, I don't necessarily think we should let "perfect be the enemy of good" and outright reject a proposed implementation that has been reported to work in many use cases. The ffmpeg project has no shortage of code that doesn't handle every possible edge case and that I wouldn't trust for 24x7 usage, but that doesn't mean it shouldn't exist. It's a good starting point and can be improved over time. I would encourage Romain to look at upipe's implementation, as it's always good to look at a mature and well-exercised stack if such a thing already exists and is publically available. Marking it as experimental seems like a reasonable ask, given that it's brand new code. That would both allow it to be evaluated/tested by those who care about it, and there's a base onto which to submit fixes/improvements. And, like with anything else, if it's determined that the implementation works very poorly and/or it gets abandoned, it can always be dropped from the tree. Yes, I agree with Kieran that Prompeg FEC is annoying and it would be great if everybody would just move to newer/better protocols. But there are still cases out there where FEC is useful and there is a ton of legacy equipment out there that does FEC but not those newer protocols. For the most part this isn't really about designing new workflows but rather interoperating with existing workflows/equipment. Devin On Fri, Jan 17, 2025 at 12:08 PM Michael Niedermayer <mich...@niedermayer.cc> wrote: > > Hi Kieran > > On Fri, Jan 17, 2025 at 04:05:09PM +0000, Kieran Kunhya via ffmpeg-devel > wrote: > > On Fri, Jan 17, 2025 at 2:48 PM James Almer <jamr...@gmail.com> wrote: > > > > > > On 1/17/2025 11:42 AM, Nicolas George wrote: > > > > James Almer (12025-01-17): > > > >> Don't assume he will not extend the implementation. Ask him instead > > > >> what he > > > >> plans to do in the long term. > > > >> And this could also be marked as experimental, in which case if > > > >> abandoned or > > > >> proven unstable for several real world cases, it can be removed or > > > >> disabled. > > > > > > > > You were asking for proof that corporate-style mindset harms the > > > > project, you have one right here: “we do not want this new feature > > > > because it could mean bad PR” is one of the leitmotivs that have pushed > > > > the project towards stagnation since the GA has had influence. > > > > > > I don't see how the GA has anything to do with this when we're talking > > > about one person, but you're not wrong in that rejecting a feature for > > > being incomplete is not ideal. > > > The codebase is not lacking in partially implemented features and > > > protocols, and as long as it's stable, is not invasive, and gracefully > > > rejects unsupported scenarios, IMO it should be ok. But Kieran's > > > requests should be addressed. And like i said, marking it as > > > experimental is an option. > > > > Just to add here what I wrote on IRC. FEC *by definition* is meant to > > be used on lossy and otherwise problematic networks. > > Therefore it cannot crash, infinite loop etc. Nor can it be "elegant". > > The reality is it has heuristics to deal with the real world like any > > loss tolerant protocol. This is in addition to the other issues this > > implementation has. > > If there are issues in a patch, the best is to point the patch author > to these issues with sufficient detail so he can correct them. > > thx > > [...] > -- > Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB > > Freedom in capitalist society always remains about the same as it was in > ancient Greek republics: Freedom for slave owners. -- Vladimir Lenin > _______________________________________________ > 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". -- 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".
