[FFmpeg-devel] [PATCH v6 0/1] avformat: add Software Defined Radio support

[Lynne]

Jul 2, 2023, 21:52 by george at nsup.org:

> Lynne (12023-07-02):
>
>> git master is not a playground, but it is certainly a place for developers
>> to experiment with ideas they're *seriously* exploring.
>>
>> Sonic and Snow were experiments. They didn't work out, but nevertheless,
>> they made their mark on the status quo of compression research at the time.
>>
>> FFV1 was an experiment. It worked out, being an IETF standard.
>> The native mpeg encoders were experiments. They worked out, and their
>> rate control system largely inspired x264's rate control systems.
>> The DNN filtering stuff was an experiment. It didn't work out.The native Opus encoder was an experiment, and it holds up well against
>> libopus, if a bit slow and misguided.
>> The AAC encoder was always an experiment. Did it work out? Let's
>> find out after the third rewrite :)
>>
>
> Thanks for the history. This is what I called a playground for hackers;
> a rose by any other name.
>
>> As for libavsdr? Time will tell. But it's certainly got a niche to fill,
>> as currently, you have to setup large and complex gnuradio filterchains.
>> But, I would prefer for it to be in a separate repository.
>>
>
> I have a hard time understanding this preference, for both avradio and
> avstream.
>
> Moving to a separate repository requires you to maintain a separate
> build system, separate tests, etc. It also means only enthusiast users
> will download and install the library, thus greatly reducing both its
> usefulness and its changes of getting off the ground.
>

Not really, if ffmpeg has a new dependency, distributions are generally
eager to use it if it's well packaged and doesn't depend itself on hundreds
of other libraries.
Moreso if it's an official library.
A simple makefile is a few dozen lines, it doesn't have to be automatically
generated. And test-wise, FATE wouldn't really be able to cover it.