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

["Tomas Härdin" <git@haerdin.se>]

mån 2023-07-24 klockan 00:56 +0200 skrev Michael Niedermayer:
> And here comes the 3rd step, connect libavfilter to libavradio, move
> the components
> into libavfilter. Do demodulation and probing in filters.

Paul already said no to this

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

This describes gnuradio, or more accurately the gnuradio we have at
home. It would require a widening of scope of lavfi. And a new API or
even multiple new APIs. Which is strange because so far we've been led
to believe that the effects on the rest of the project would be minor.
That's not even taking users into account, who I fear will also be
compelled to do extra work to accommodate all this. Untold months if
not years of work. Why?

The more I think about this the more baffling it becomes. Instead of
the current architecture where we mostly have demuxer -> decoder ->
lavfi -> encoder -> muxer, or bytes -> packets -> essence -> packets ->
bytes, instead data of various types need to be woven in and out of
lavfi, interacting with lavf and lavc in arcane ways. With gnuradio
this isn't much of a problem because the project has been built around
it from day one. The way a typical GRC graph looks, and the fact that
each radio service needs an entirely different graph, with entirely
different combinations of data types in and out of each box, reflects
this.

Another thing that baffles me is this argument around time. Because
surely it would take less time to just use what already exists, making
use of the miracle of the UNIX pipe where necessary. Programs that do
one thing and do it well and all that. Division of labour.

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

Like an extent that is slowly growing. Creeping, if you will.

> Theres a point where
> i will move on and switch the bulk of my time to "not FFmpeg" and
> just do
> payed work here.

I am honestly at a loss for words with this. When I first saw this I
debated whether to even reply to it. It speaks for itself really.

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