Re: [FFmpeg-devel] What is FFmpeg and what should it be

[Paul B Mahol <onemda@gmail.com>]

On Tue, Aug 8, 2023 at 5:23 PM Michael Niedermayer <michael@niedermayer.cc>
wrote:

> Hi
>
> On Mon, Aug 07, 2023 at 06:39:10PM +0300, Rémi Denis-Courmont wrote:
> > Le sunnuntaina 6. elokuuta 2023, 22.53.23 EEST Michael Niedermayer a
> écrit :
> > > > > > Did you ask people to do that?
> > > > >
> > > > > yes, multiple times.
> > > > > Also normally patch objections come with a path forward, that was
> not
> > > > > the case here.
> > > >
> > > > Not necessarily, sometimes preventing a bad idea from happening is a
> > > > positive thing in itself, and no path forward is needed.
> > >
> > > That is missing that people suggest a path forward but
> > > with too few details to easily walk that path.
> >
> > Uh, I hate to state the patently obvious, but if "no path forward is
> needed",
> > then there should logically be _no_ "details to walk [a] path".
> Conversely, if
> > avradio does not belong in FFmpeg, as Kieran, Tomas and others have been
> > arguing, then there is no path forward to be given on FFmpeg-devel.
> >
> >
> > And besides I don't think it's even fair to state that "too few details"
> were
> > given. People did suggest making this a new separate project properly
> isolated
> > from FFmpeg internals, and/or joining efforts with existing OSS SDR
> projects
> > rather than FFmpeg. Some specific projects have even been cited.
> >
> > As far as FFmpeg(-devel) is concerned, I can't think how it could/should
> > reasonably get any more specific than that.
>
> The saying goes, one cannot win an Argument on the Internet.
> So, iam not trying to, but
>
> IIRC, a while ago you said iam obliged to work on FFmpeg. Thats
> simply not the case.
>
> Its not an obligation but rather my choice that i like to work on
> something the end user will enjoy. And the end user, in fact
> more than 500 end users liked SDR in FFmpeg.
> My original plan was to spend 1-2 weeks working on SDR, now
> probably about 2 months passed with me spending a bit working on
> SDR here and there.
>
> I also am not obliged to do what other developers want me to do. But i have
> been in this community for a very long time and have my highest respect
> from the Developers in this community, even if at times we disagreed
> they are all great people, and some are my friends.
> And working toward a consensus everyone is happy with is
> something i want whenever there is a disagreement.
> On IRC what people said, and what JB said here, is that people are ok
> with a SDR module in FFmpeg under some conditions.
> It is these conditions that i do not fully understand, and that i
> tried to understand better.
>
> You and vittorio here seem to suggest that instead there are no
> possible conditions and no path forward. Thus a fork would have to happen.
> Now iam quite confident, that, thats not what people ask for.
> We had a fork and i dont think we want to have a new one.
>
> Again, i want a consensus everyone is happy with so I keep asking
> what people suggest exactly.
>

For start, and good will, I'm willing to accept a signal of good will from
you to remove sdr files from FATE.
There is no point in discussing anything further with you until that is
done.


> Thanks
>
> [...]
> --
> Michael     GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB
>
> He who knows, does not speak. He who speaks, does not know. -- Lao Tsu
> _______________________________________________
> 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".