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

[Tomas Härdin]

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


> PS: The most efficient way to make the code be structured the way
> people
> like it is to work together on it and contribute. Iam mentioning this
> because
> IRC gives off some hostile vibes ATM, and this reminds me of the
> distant past
> Working together -> makes everyone happy.
> Fighting other peoples work -> results in fragmenting the community

I would suggest not completely ignoring people like me who a) have
domain knowledge and b) are opposed to this on feature creep or other
grounds

/Tomas