On Wed, Aug 02, 2023 at 02:59:11PM +0200, Jean-Baptiste Kempf wrote:
> On Wed, 2 Aug 2023, at 14:55, Michael Niedermayer wrote:
> > the code already is in a seperate repository. And is basically isolated
> > in a single demuxer and single input device.
> 
> But it's not a library in that repository, like swscale, swresample or similar libraries.
> 
> If it was, with an API, it would be trivial to add support to this optional library as an FFmpeg module, and noone who complain.

There are multiple problems but the real problem is that
How many people discuss an SDR API ? (0)
How many people propose an SDR API ? (0)
How many people say what they want an SDR API to be able to do ? (0)
    This is not a simple question ?
    enumerate devices, set options, open, read frames, close ? That does not differ from the
    existing input device / demuxer API.
    If one cannot state a single difference in the API requirements from the existing
    input device API, how can one design that API ?
    If the existing input device API suposedly is not good
    Is it bad just because it is the existing API ? And it would be perfectly
    fine if it just had different function names ?
In other areas the community collaborates to create APIs
here all energy is spend to block patches (the latest set blocked are pure bugfixes)

Also swresample and swscale are simpler in what they need to provide API wise.

My very first patch i sent btw was blocked with the claim that it used
an external library and did not do the processing nativly.
Thats exactly what you suggest now

IMHO, People who want to use this API, or want to implement this API
should help with the API design and implementation

And if there are 0 people wanting to use the API then why should i design
that API ? who for ?
SDR in FFmpeg has 500+ users who want it, the API iam not sure has a user

People who have no intend to use the API or SDR or implement either
should not represent 99% of whom approv / reject the code
This is a problem, because it leads to bad code.
The people telling me what to do dont care about the results
one day its "not external lib", then its "external lib" then its
"libavfilter" then its "not libavfilter"

Again we had 0 that is ZERO discussions about an SDR API.
where does it start ? a hw enumerate, a soapy device, a void *
representing a SDR data stream from something like soapy

soapy is full of bugs, for the code to work we need to know
where the data came from and we need to interact with the hw
should we provide a layer over all of libsoapy ?
should we support only libsoapy and take a device from libsoapy
as input
should we have a generic input support that libsoapy is one of several
options ?

I cannot design this API with this. because 3 out of 4
choices will get attacked and blocked if not all 4, if someone just
implements it.
because people are unwilling to think about anything they just think
they know how it must be done and they dont discuss anything they just
demand and attack and wait how the next patchset looks. Eventually
everyone then looses interrest and a patchset goes through but thats
not good design.
So again, IMHO people should help design and implement this API
if they want an API.
If i have to design an API by trial and error until it gets no
unspecific objections by people not interrested in using it
thats not going to be an API that anyone will want to use.

thx

[...]
-- 
Michael     GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

The day soldiers stop bringing you their problems is the day you have stopped 
leading them. They have either lost confidence that you can help or concluded 
you do not care. Either case is a failure of leadership. - Colin Powell