Hi all, Le lun. 20 janv. 2025 à 10:23, Marth64 <mart...@proxyid.net> a écrit : > > James Almer: > > > I'd really like if we can stop with the "Everything's fucked, nothing > > can be done" mails every other week and instead make use of the > > framework we came up with, or if needed, change it and improve it. > > +1 > or we will never move forward with anything
Thank you for the robust discussion y'all. First and foremost, I'm sorry to see that no one seems to have actually tested my changes. Here are some testing feedback: * I had to fix a couple of glitches from the v0, I'll post an updated patch after sending this email. * It has only been tested end-to-end with FFmpeg implementation. We are scheduled to test with the client's actual encoder some time this month. * I have done the following: 1. From a AWS remote server, launch this process: ffmpeg -re -i <New Orleans WWOZ URL> -f rtp_mpegts -fec prompeg=l=4:d=4 rtp://<my ISP IP>:3498 2. Set up port forwarding to my laptop inside my local LAN wifi. (If you know US IPs and if you know New Orleans, I have to add that my internet link is particularly bad too) 3. Launch on my laptop: ffmpeg -i "rtp://127.0.0.1:8000?fec=prompeg=l=4:d=4" -c copy -y /tmp/decoded.aac I then used macos's Network Link Conditioner with different packet loss ratio to simulate packet losses. After about 30 min of each case, I reported the following recovery ratio: 1% packet loss: 100% recovery ratio 5% packet loss: 98% recovery ratio 10% packet loss: 95% recovery ratio 20% packet loss: 82% recovery ratio Frankly, these numbers seem good enough to me to merge as is, this is already providing a pretty robust solution for users who are concerned only about using ffmpeg end-to-end. As for the rest of the conversation, here are some quick notes: --> Do I intend to maintain and expand the implementation? I would love to. In fact, I would love to be involved more with the development process here. It's just been really difficult to get some attention on the changes that I have proposed. Typically, I have another patch that I sent earlier about ogg that has had zero review so far. But, yeah, I have a track record of maintaining several projects over the years and I'd like to consider this one as well. --> Feedback and expert knowledge In the discussion, I see a lot of knowledge being expressed that comes from years of working on these technologies. Though I have some under my belt as well, I'm eager to learn more, if this can be done in a constructive way. Here are some feedback based on what I've been able to read in the threads: --> Heuristics vs. algorithmic In my opinion, heuristics should be avoided as much as possible and, if used, should be abstracted away in their own modular architectural design. The reason being that each particular heuristic introduces side effects that are often hard to anticipate, complicate code proofread and testing. When a specific situations arises, like a specific router behavior, instead of immediately adding a quick conditional branch, it can be more beneficial to ask ourselves what are the consequences of this specific behavior to the system in general and wether or not this can be caught through some of the more generic mechanisms already in place (or via a new one). However, heuristics can also be hard learned lessons from battling in the field (see expert knowledge above) so I'm not against them, just generally very conservative. --> Practical engineering I have grown to like engineering based on tests and experiments like the ones I did above. At the end of the day, I have no specific attachment to my implementation in particular as long as there is one that is maintainable and that can provide the functionality that is desired. (though I will admit it's always nice to get your work recognized and validated). To address some specific concerns about the proposed implementation: --> Infinite loop Being a "simple" implementation with no heuristics, the expected steps upon receiving a new packet are always finite. Thus, there cannot be any infinite loop in this implementation. --> Encoder restart This seems to be out wildly of the scope for those changes. The RTP demuxer does not yet support encoder restart. Also, to support this, you would also have to deal with PTS/DTS discontinuities that would be akin to supporting dynamic content switch, another thing that is not obvious to do in ffmpeg at the moment. In the future, I would love to contribute more on this. Based on the conversation'd feedback regarding implementation specific details, this seems like a hard problem, in particular because SSRC is not usable for that. In this specific case, it seems to me that, instead of building heuristics that are a little bit of a shot in the dark, this particular problem could warrant breaking the separation of concern and using the content layer. In a lot of cases, that the content layer would make it extremely clear when a new stream is coming into the demuxer by looking at some specifics of its bitstream. And, yes, if this is impossible, for instance with raw PCM, then use heuristics as last resort, if this makes sense. --> Next steps? I still have to test the implementation with my client's hardware encoders. However, I believe that the v1 of the changes that I'm about to send should be ready for a solid review/consideration based on my own testing. Meanwhile, I will be at FOSDEM the first weekend of October and would love to continue the conversation in person. In fact, I am planning to give a talk about dynamic content switching using ffmpeg so some of the talk could be an interesting starting point for a larger conversation. Thanks, -- Romain _______________________________________________ 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".
