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

[James Almer <jamrial@gmail.com>]

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.

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

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