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

[Paul B Mahol]

On Sat, Jul 1, 2023 at 8:56 PM Michael Niedermayer <michael at niedermayer.cc>
wrote:

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

If you are not able to find sample or reference for some format or codec
that
does not mean there is no samples or people using that samples or reference
for some codec.

It just shows your huge lack of understanding of multimedia ecosystem.


>
> 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
> _______________________________________________
> ffmpeg-devel mailing list
> ffmpeg-devel at ffmpeg.org
> https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
>
> To unsubscribe, visit link above, or email
> ffmpeg-devel-request at ffmpeg.org with subject "unsubscribe".
>