Kieran Kunhya (12023-07-28): > FFmpeg doesn't implement TCP in userspace, it doesn't implement the > WiFi protocol etc etc. Different layers are delegated to different > programs.
Hi. You seem to be discussing this in more good faith than I previously imagined, so I will try to tone done the irritation in my mails. I am also changing the subject of the mail, so that more people will have a look at it. I have already posted about my conception of what FFmpeg is and should be in the previous mail: http://ffmpeg.org/pipermail/ffmpeg-devel/2023-July/312735.html There are at least two necessary conditions for something to go into FFmpeg: that it is useful to users, at least a few of them, and that somebody bothered to write the code. FFmpeg is designed to run under an operating system, where a network stack is usually available whenever network hardware exists, so there is absolutely no need for that in FFmpeg. But if people started to routinely use FFmpeg on some kind of bare-metal microcontroller where network hardware exists but the official network stack is too big to share the space with FFmpeg, and if somebody were to propose a limited network stack based on lavu's cryptographic primitives, then it would totally make sense to accept it. Yes, this example is far-fetched, because you chose a case where only a far-fetched example works. You insist on having different layers, and I agree it is somewhat relevant. But remember: the Internet is not built on the nice theoretical layers of the OSI model. The protocols of Internet are much more messy, because they insist more on pragmatism than aesthetics, and that is what made their success. If there are well-defined layers, then probably the others layers are already implemented, the “different programs” exist, are very satisfactory and very widely available. Then FFmpeg does not need to have them natively. But if these “different programs” for different layers do not exist, or are not satisfactory, or are not widely available, then we have to develop them. And if that happens, it would be idiot to force them to be separate projects. Maybe later, when they have become stable, and other programs use them, it will make sense to split them into their own separate project. But in the beginning, it is a waste of effort. > Is FFmpeg going to implement HTTP3 (QUIC) in full? QUIC is a layered protocol. I do not know. I have followed things from afar, does HTTP3 brings benefits from users, apart from more efficient tracking and faster delivery of ads? Anyway, your sentence brigs a point that is very important: *** IT DOES NOT HAVE TO BE COMPLETE TO BE USEFUL. *** See below for more about it. > All of your examples are small and self-contained. SDR is definitely > not small and self-contained. It's a field bigger than multimedia and > there are many layers of framing inside. Michael's code seems pretty self-contained to me. And once again: *** IT DOES NOT HAVE TO BE COMPLETE TO BE USEFUL. *** As far as I understand it, if I bought the hardware tomorrow, the code that Michael already wrote, and that is a tiny little bit of the whole field of SDR, would already bring me features that are not available in any other piece of Libre Software, or possibly at the cost of fragile plumbing. This is enough of an argument to warrant inclusion. And it does not make sense to insist that one of our most talented developers waste his time with the trouble of maintaining a separate project just to satisfy aesthetic considerations of “proper layering”. I have another example of “it does not have to be complete to be useful”: XML. The whole XML standard is quite complex, it involves DVD and schema validation, loading external entities, etc. But the use of XML in multimedia is much more limited, it only involves parsing “<foo bar="qux">”-style text. Now, “proper layering” dictates using a real XML library. But real XML libraries are designed to support most of the standard, and that affects their design as a whole. That means every time we use a real XML library to parse “<foo bar="qux">”, we pay the price for the complexity of the whole language, in terms of efficiency, reliability, security exposure. If we had our own parser for “<foo bar="qux">”, we would have to pay a price only once. “Proper layering” has benefits, but it also has costs. Therefore it is a bad idea to adhere to it dogmatically. FFmpeg has been successful because it relied on pragmatism rather than dogmatic adherence to principles. Let us continue that way. Regards, -- Nicolas George
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".
