[FFmpeg-devel] What is FFmpeg and what should it be

[Nicolas George <george@nsup.org>]

[-- Attachment #1.1: Type: text/plain, Size: 4734 bytes --]

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

[-- Attachment #1.2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

[-- Attachment #2: Type: text/plain, Size: 251 bytes --]

_______________________________________________
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

To unsubscribe, visit link above, or email
ffmpeg-devel-request@ffmpeg.org with subject "unsubscribe".