Re: [FFmpeg-devel] [PATCH 5/6] fftools: avradio support

[Nicolas George <george@nsup.org>]

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

Kieran Kunhya (12023-07-25):
> You can have satisified users without having to implement SDR in a
> multimedia library, nor xml parsing, nor a web server, nor anything
> else that sits at a higher or lower level than FFmpeg.

Satisfied users is not a yes/no thing. There was a branch of the fork
with more features and more satisfied users, and a branch of the fork
with less features and less satisfied users. The second one died, and
good riddance.

We are on the branch of the fork that wants more features even if it
means a few hacks. Accept it or work on the other branch.

> It's not just multimedia that goes over radio, it's not just
> multimedia that goes over TCP,  it's not just multimedia that needs
> XML, that's why there are separate libraries for these kind of things.

It is not just multimedia that can be encrypted, yet FFmpeg has
cryptographic primitives.

It is not just multimedia that can go over HTTP, yet FFmpeg has support
for HTTP — limited to its needs.

It is not just multimedia that requires Fourier transforms and similar
mathematical operations, yet FFmpeg has them too.

> FFmpeg is not the kitchen sink of miscellaneous wheel reinvention.

I reject the disparaging “kitchen sink”, but apart from it, YES, FFmpeg
is exactly that, or at least it was some time before the fork.

Then some people pushed for more seriousness, more stability, which
meant less creativity. And seeing their efforts to make the project more
serious, more stable and more sterile were not succeeding enough, they
tried to take over, that resulted in a fork that almost killed the
project.

And we, on the FFmpeg side, made the mistake to try to entice them back.
We changed for that, we made the project more serious, more stable, more
sterile, to try and convince them to come back. We should not have done
so. Instead, we should have reaffirmed what makes FFmpeg not libav, and
demanded THEY change to be welcomed back.

And so the trend towards more seriousness, more stability, more
sterility, continued. Amplified by people who started business to
exploit FFmpeg, and have a personal interest in the project being more
serious, more stable, and don't care it's more sterile.

But before that evolution, what FFmpeg success in the first place, was
precisely that it was a welcoming place for development in the
multimedia field. Not just a narrow version of “the scope”, but anything
related to multimedia, or useful for it. Not just things that do not
exist elsewhere but also projects to invent new and creative ways of
doing it. And since that ambiance attracted very talented hackers
(including you personally, as far as I could see), it frequently gave
impressive results.

So yes, being able to use SDR devices to record AM/FM on the fly from
ffmpeg or any FFmpeg-based application is worth a few hacks here and
there.

And yes, being able to read network streams defined by XML manifests
without linking to the big stinking pile of shite that is libxml2 is
worth having our own XML parser, limited to exactly what we need instead
of supporting the whole complex format.

And so on and so on.

FFmpeg is a place for creativity. If you do not agree, try to remember
why you came here in the first place.

-- 
  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".