[FFmpeg-devel] [PATCH v6 0/1] avformat: add Software Defined Radio support

[Michael Niedermayer]

On Sat, Jul 01, 2023 at 06:28:03PM +0300, Rémi Denis-Courmont wrote:
> Hi,
> 
> Le 30 juin 2023 21:02:36 GMT+03:00, Michael Niedermayer <michael at niedermayer.cc> a écrit :
> >On Fri, Jun 30, 2023 at 07:40:53PM +0200, Michael Niedermayer wrote:
> >> On Fri, Jun 30, 2023 at 04:38:46PM +0200, Jean-Baptiste Kempf wrote:
> >> > On Fri, 30 Jun 2023, at 16:08, Michael Niedermayer wrote:
> >> > > Also as said previously, If there is at least a 2nd developer working
> >> > > on this then we could & should move this to a seperate libraray (libavradio)
> >> > 
> >> > Why wait for a 2nd dev?
> >> 
> >> It is significant work
> >
> >And if we could put it in git master then people could work together to
> >build the libavradio out of it as we all want.
> 
> You can also achieve that by creating a separate git repo for libavradio on git.ffmpeg.org. Admittedly some people could object to hosting this code by FFmpeg; the point is that I don't see what good putting this inside the FFmpeg master git branch achieves.
> 
> >Such collaboration is kind of one of the reasons of having a "git master"
> 
> You're better off collaborating with people interested in this, than with the entirety of FFmpeg-devel, me thinks.
> 
> That's if this turns into a "Boring Serious Open-Source" project to paraphrase a certain somebody else. If it remains just your hobby project, you're probably better off doing it in your own git repository where you can dictate everything. There you won't have to deal with the FFmpeg TC nor pesky minders of other people's source code such as I.

These are wise words.
The thing that i have difficulty getting into my head is how all these
fringe formats and codecs that most of us are not even able to find a
sample for. Let alone have ever used or ever will.
Do fit into FFmpeg while code to support the 2 most widespread analog
radio systems are off limits.

One can define that as transport and exclude it but that feels very contrived.
Explain that to a child, FFmpeg supports all multimedia, that is audio and video
BUT not that audio you listen here to in the car radio UNLESS you plug that
usb stick in (with an mp3 on it), then we support it.

If FFmpeg is intending to support all of multimedia it should support
AM & FM audio by some means.

i can put the input device and demuxer in libavradio with the same API as
currently and put that in a seperate directory or repository.
It seems a technically not thought through decission though. It simply
adds extra work to maintain it.

the reason why iam pushy is that i belive the FFmpeg users would want this
feature. If i give in and dump it into my github repo, chances are 99% of
users will not have access to this feature as it likely wont get included
in most distributions

theres nothing i gain from this feature going into git master. I just
think radio support _does_ belong into FFmpeg.

thx

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

He who knows, does not speak. He who speaks, does not know. -- Lao Tsu
-------------- 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/20230701/f3b33187/attachment.sig>