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

[Michael Niedermayer]

On Mon, Jul 24, 2023 at 10:19:13PM +0200, Tomas Härdin wrote:
> sön 2023-07-23 klockan 16:01 -0300 skrev James Almer:
> > 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? 
> 
> Such libraries already exist. Libraries that need talented developers
> working on them. Something that I have already suggested, but it
> appears to be falling on deaf ears. Which is a shame.

You suggested this for many things, including MXF
For MXF your suggestion has no support AFAIK. And it would cause
problems with MXF support in FFmpeg (but thats off topic here)

For avradio, maybe i need to communicate more with the other developers
but I am not ignoring your suggestion. I also dont do what you suggest
litterally (which is maybe why you think iam ignoring it)

But since a while my plan for DAB support is to using an external
library.
For FM and AM, using an external libraray is just a mistake, same as
it is for something like *av_asprintf(). The external libraray would
just be more pain than doing it internally

About the need for talented developers in SDR projects. I understand
every project needs more talented developers. But what my goal after
having some fun with SDR is, is to

serve the end user. And here iam
trying to make it possible that "FFmpeg based" players and tools
can use SDR.
If i join gnu radio and use pipes very few end users of FFmpeg based
tools would be served by that

I dont understand why you keep telling me to join a absolutely huge
python project (which has no need for any further development in SDR code)
(and has no easy path to be used by a FFmpeg based tool end user)

For FFmpeg using a C or C++ libraray for some parts of SDR like DAB
is something that makes sense and i plan to go that route. But beyond
that I simply do not understand how your suggestions would server
end users
Its not my goal to create a "player" for myself. I have a radio from my
grand aunt that works still fine. Again my goal was to have fun with
the math&dsp code and serve the end users of this project.
gnu radio needs no further math & dsp from me and it wont serve end
users of libav* / FFmpeg tools. The repeated suggestion for gnu radio
baffles me. Maybe iam missing something, of course, but i dont see
how this could work. Maybe if iam all wrong here, why dont you send
a patch, that gives ffmpeg & libav* based tool end users AM/FM/DAB/DVB
support through gnu radio ? With same features and convenience
avradio does today.

thx

[...]

-- 
Michael     GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

Avoid a single point of failure, be that a person or equipment.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 195 bytes
Desc: not available
URL: <https://ffmpeg.org/pipermail/ffmpeg-devel/attachments/20230726/d2439a2f/attachment.sig>