[FFmpeg-devel] FFmpeg release 6.1 (SDR Plans)

Paul B Mahol onemda at gmail.com
Thu Sep 21 22:44:37 EEST 2023


On Thu, Sep 21, 2023 at 9:37 PM Nicolas George <george at nsup.org> wrote:

> Vittorio Giovara (12023-09-21):
> > So this is an example of accusatory tone - discrediting the previous
> author
> > in order to make your arguments have more weight. It's a bad move and
> > easily spottable, you should argue with better elements at your disposal,
> > not by claiming that I don't package software or don't contribute to
> > libavfilter.
>
> You are misunderstanding my point completely, I am not accusing you of
> anything, I am merely using you as an example to show how your argument
> is flawed.
>
> I can take myself as an example instead, if you like it better:
>
> How much did *I* contribute to hardware acceleration? Zero!
>
> How much did *I* contribute to assembly optimization? Zero!
>
> How much do *I* intend to contribute to hardware acceleration? Zero!
>
> But now, however much I would like to, especially in libavfilter, I
> refrain from objecting to new features of hardware acceleration.
>
> Because I can make the difference between the things that benefit me and
> the things that are useful to many users and therefore good for the
> project.
>
> FFmpeg is made a of a lot of parts that are often very independent. That
> is on purpose: that way, if somebody is not interested in a part, they
> can just ignore it and let others work on it.
>
> And that is exactly what I am asking you to do:
>
> Just ignore SDR and let Michael work on it.
>
> SDR costs NOTHING except Michael's time, and Michael's time is his own
> to spend. For the rest of us, the grounds for objecting are the same
> NOTHING.
>

SDR API is not trivial and inclusion of it with all its features and
components is not trivial inside FFmpeg libraries.


>
> > opinion on this release still stands: either a release with everything
> or a
> > release without the contentious piece of code, but not both. It's
> confusing
> > to the end users, and shows lack of direction of the project.
>
> On this we agree, making a second release without the feature just some
> people object to it would be a waste of Michael's time.
>
> --
>   Nicolas George
> _______________________________________________
> 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".
>


More information about the ffmpeg-devel mailing list