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

[Michael Niedermayer <michael@niedermayer.cc>]

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

On Sun, Jul 23, 2023 at 04:01:16PM -0300, James Almer wrote:
> On 7/23/2023 3:49 PM, Tomas Härdin wrote:
> > sön 2023-07-23 klockan 17:23 +0200 skrev Michael Niedermayer:
> > > On Sat, Jul 22, 2023 at 11:39:11PM +0200, Lynne wrote:
> > > > Jul 22, 2023, 21:30 by michael@niedermayer.cc:
> > > > 
> > > > > This avoids keeping diffs to fftools in the libavradio repository
> > 
> > No to this entire patchset.
> > 
> > > > > ---
> > > > >   fftools/ffmpeg.c     |  7 +++++
> > > > >   fftools/ffplay.c     |  6 ++++
> > > > >   fftools/ffprobe.c    |  6 ++++
> > > > >   fftools/opt_common.c | 66
> > > > > ++++++++++++++++++++++++++++++++++++++++----
> > > > >   fftools/opt_common.h | 27 ++++++++++++++++++
> > > > >   5 files changed, 107 insertions(+), 5 deletions(-)
> > > > > 
> > > > 
> > > > Do you think we should keep this out of the 6.1 branch?
> > > > I don't expect packagers to start packaging libavradio immediately,
> > > > so I don't feel that strongly about it, but maybe we should let
> > > > users test it first in git master for a bit?
> > 
> > Users can test libavradio's master if they wish. Do not assume merging
> > this fork will happen, especially not without TC approval, nor that
> > trying to sneak it in won't be noticed and opposed.
> > 
> > This patchset makes an even stronger case why this fork should have its
> > own mailing list and not pretend it's part of the main project.
> > 
> > 
> > > about packagers and libavradio. The (more vocal members of the)
> > > community
> > > wanted sdr in a seperate library and not libavdevice, its likely that
> > > distributions will eventually package it, wherever it is.
> > 
> > Why would they package it when there already are mature programs like
> > gqrx, dablin etc? Programs that feature separation of concerns. See for
> > example hacktv which uses ffmpeg, libhackrf and libsoapysdr without
> > insisting on being part of either
> > 
> > Another problem is that this would almost certainly cause headaches for
> > packagers. I know this because it's going to cause headaches for this
> > project to care about maintaining compatibility with a fork that
> > doesn't want to pretend it's a fork.
> 
> What bothers me is that even though it's added outside of lavd, it's being
> added as a brand new lavd, with all the drawbacks this implies, including it
> being tied to lavf in an awful way. And all for a single "device"
> AVInputFormat. It's completely overkill.

Its outside because people asked for it to be outside.
I thought its bad but its fine really if you look a bit forward


> 
> Why is this libavradio not designed as a standalone library, with its own,
> carefully designed API for general radio usage, that can be then glued to
> lavd as an AVInputFormat relying on said external library? Doing that would
> also make it usable in other projects that don't want to use the lavf/lavd
> API.

Because 2 things matter.
1. the final result
2. how to get there efficiently

The first step is a demuxer/input device. Whereever it is. (thats what we have now)
DAB & DVB can be added too or could be added later

No new API is here, so no API can be misdesigned and no API can require
to be replaced. Theres also no API we will need to deprecate
If we do API first we will have to redo and deprecate it 100% certainly.
We have had to frequently redo APIs and that was with things
we understood much better. So if we do an SDR API now, probably we would have to
redo it more than once, more so if some of the community boycotts
the design or implementation process

The second step is users, improvments, bugfixes, figure out what people use/want/need

AFTER this. We are in a position to design the API without being certain that
we have to redo it immedeatly

And here comes the 3rd step, connect libavfilter to libavradio, move the components
into libavfilter. Do demodulation and probing in filters.
filters will not need to deal with mpeg-ts or AAC because they would be
used by libavradio and return mpeg-ts / AAC to its "caller"

And then the 4th step (which can be switched with teh 3rd)
Make all the parts available though a new API. At that time we will have a
much better understanding of what there is inside libavradio (because its
actually implemented) and also what developers want from a libavradio API
Here we are in a much better position to actually design a good API.
Also at this point many parts can be already used through libavfilter,
you need a stereo FM demodulator? there would be a avfilter for that probably.

There are other pathes forward but thats the current plan _IF_ this isnt killed off
by the community and _IF_ others join and enjoy working on this. Also nothing is
cast in stone, this plan is intended to be adapted as needed on the way.

I originally just intended to do AM&FM demodulation, and this has become a
much bigger project. We already have RDS & metadata support for example
But fact is, libavradio exists now. Now the question is will people join
and make more out of it or kill it off. Ultimately I cannot do this alone
especially not if 90% of replies tell me to fuck off. Theres a point where
i will move on and switch the bulk of my time to "not FFmpeg" and just do
payed work here.

Again, i understand that radio needs an API beyond libavdevices, and i agree
but IMO this comes after we have feedback from users what they need&want.
And that requires users which requires it to be in a release.

thx


> A standalone library can link to lavu for any utils it may need. A lavd
> device using it wouldn't be the first module using an external library that
> generates a circular dependency with other lav* libraries.


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

Take away the freedom of one citizen and you will be jailed, take away
the freedom of all citizens and you will be congratulated by your peers
in Parliament.

[-- Attachment #1.2: signature.asc --]
[-- Type: application/pgp-signature, Size: 195 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".