[FFmpeg-devel] [RFC] Release 6.1

James Almer jamrial at gmail.com
Tue Sep 26 20:25:54 EEST 2023


On 9/26/2023 2:16 PM, Michael Niedermayer wrote:
> On Tue, Sep 26, 2023 at 05:30:19PM +0200, Anton Khirnov wrote:
>> Quoting Michael Niedermayer (2023-09-26 17:09:47)
>>> On Tue, Sep 26, 2023 at 11:13:40AM +0200, Anton Khirnov wrote:
>>>> Quoting Michael Niedermayer (2023-09-22 11:27:54)
>>>>> The idea was really just, that i said ill include SDR and i want to
>>>>> keep this word
>>>>
>>>> Well, you should not have spoken for the entire project without
>>>> consulting the rest of the community first. Nobody here is entitled to
>>>
>>> This statement is a little misleading, i think
>>>
>>> Iam part of the community, i would think and for 99% of the tweets made
>>> on the official twitter account i have never been asked or even had a
>>> chance to comment before they where made. So what you suggest here is
>>> "the correct way", has never been applied.
>>
>> This is disingenuous sophistry, and honestly I find it insulting that
>> you expect people to swallow it.
>>
>> You made the tweet in question long after it was clear that the feature
>> is controversial. Then you tried to use it as an argument in favor of
>> pushing SDR to master. In other words, you used the fact that you have
>> Twitter posting rights to promote your opinion over that of other
>> developers. If that is not abuse of power then I don't know what is.
> 
> ok
> I wrote a SDR input device for free, wanted to give it to the users
> as i believed it was a cool and usefull feature
> 
> i tried to argue for it, i tried to promote it.
> And as the person doing all releases of FFmpeg since a very long time
> i thought yeah we will be able to resolve the disagreements and get it
> in 6.1 with everyone geing happy.
> I was wrong, i announced this before i actually got people to agree yes
> I still belive if people where not so "excited" on this whole and if it
> was just a technical question we could get SDR in 6.1 with everyone
> agreeing.
> But now heres a man to be burned at the stake, and thats more important.
> 
> abuse of power ?
> If its abuse of power to risk my position in FFmpeg to try to get users a feature
> i belive in they would like and find cool then yes i abused my power.

No, it was not abuse of power per se. That was a bit strong from Anton's 
part. But tweeting it was jumping the gun about something that was 
controversial and still in the discussion phase of things, and then 
using it as argument to upstream the code bothered some people.

> 
> Should i ask the counter-question ?
> are the developers who have less than 10 commits since 2017 abusing something
> by organizing and rallying the people against SDR, against the domain owner
> and against me ?
> 
> Without that, i do belive we could have gotten SDR with everyone being happy
> in 6.1
> 
> Anyway, i appologize for announcing SDR in 6.1. I was too much in love with
> SDR and how cool it would be ...
> 
> I guess there will be votes to remove me from everything.
> But dont fear, i will not abuse anything, i will resign from everything that
> a correct vote asks me to resign from.

We don't want you to resign anything. We want a proper discussion in how 
to handle SDR, if at all. Pushing it in a form that everyone agrees is 
not ready for upstream is not a good idea. Best case scenario we end up 
with a period of having to change things around as they were made public 
in a release and thus part of the API, which is harder to maintain and 
migrate from, and worst case scenario we end up with something that 
doesn't get more development because it was limited from the get go.

SDR is big, so its API needs to be designed carefully and in an 
extensible way.
libavradio must absolutely not be libavdevice redux, and it must have 
its own, versatile and extensible API that a lavd device can then work 
with, even if not using its full potential, because libavradio can have 
other users that will not be constrained to what lavf/lavd can do.


More information about the ffmpeg-devel mailing list