[FFmpeg-devel] [PATCH] avcodec/snowdec: Check intra block dc differences.

[Michael Niedermayer]

On Wed, Sep 06, 2017 at 11:55:41AM +0200, wm4 wrote:
> On Tue, 5 Sep 2017 22:14:39 -0300
> James Almer <jamrial at gmail.com> wrote:
> 
> > On 9/5/2017 5:38 AM, wm4 wrote:
> > > On Tue, 5 Sep 2017 10:03:11 +0200
> > > Clément Bœsch <u at pkh.me> wrote:
> > >   
> > >> On Mon, Sep 04, 2017 at 08:35:17PM +0200, wm4 wrote:
[...]
> > > 
> > > The only argument for snow is that it's a nice ideas. It might serve as
> > > some proof of concept. As a real codec, it appears to be unusable.
> > >   
> > >> I don't personally care about game codecs or snow myself (probably nobody
> > >> does), but I don't support this snow/swscale/whatever-michael-did killing
> > >> circle jerk. This really feels like some form of constant harassment (I'm
> > >> not even talking about IRC), and that's not acceptable.  
> > > 
> > > Well, michael could just cut back on trying to force insane stuff. His
> > > obstinate attitude to force ridiculous patches and defending them like
> > > they're the only choice doesn't help. Even when we try to remove some
> > > of his sins, he'll defend it to death, no matter how crazy and stupid
> > > the code was (side data merging comes to mind).  
> > 
> > Seeing that stuff is effectively deprecated, i don't think he defended
> > it to death. Everyone argued it was a pointless feature, and he
> > ultimately conceded.
> 
> He only "conceded" after I put all of my energy into it, and even then

> he was letting us know that he thought side data merging was great.

This is a false statement about me
Its my oppinion that
side data merging gave FFmpeg a strategic advantage over Libav at
the time it was added.
Without a competition at the time i would not have supported adding
it most likely.


[...]

Iam refraining from commenting on some of the snipped aggression
above


> Getting back to this bit:
> 
> > You're very critical of all his patches. In many cases you give a
> > detailed technical explanation of why you disagree, but most times you
> > just make a snarky comment or are otherwise kinda rude.
> 
> In general, Michael often tends to post new patches with exactly the
> same bad issues as past patches, even though there was lengthy
> discussion about them, how they were bad, and how Michael shouldn't do
> that. So excuse me if I don't repeat myself every time.
> 
> We had this discussion about fine grained error messages for fuzzed
> samples before too. Several times. Michael doesn't learn, or most
> likely, doesn't want to learn. It's rude to ignore our comments. Why are
> you complaining about me again?

I think you misunderstand or at least we have a different understanding
of the situation

In FFmpeg each piece of code has a maintainer. In fact
thats true everywhere, theres always someone or more who does the work.

And in general, not specific to FFmpeg
The people doing the work most of the time have the
authority about how to do it or they tend to be paid.

In FFmpeg, the person doing the work has the final decission on how the
code is written. Within the rules of our development policy.
For snow, a few others and defacto jpeg2000 thats me

jpeg 2000 is btw a terrible codec, i would be more than happy to give
the maintainer hat to someone else.

git shortlog -sn libavcodec/jpeg2000*
   317  Michael Niedermayer
    14  Luca Barbato
     9  Carl Eugen Hoyos
     9  Hendrik Leppkes
     7  Nicolas Bertrand
     6  Vittorio Giovara
     4  James Almer
     4  Janne Grunau
     3  Diego Biurrun
     3  Ganesh Ajjanagadde
     3  Paul B Mahol
     2  Anton Khirnov
     2  Clément Bœsch
     1  Derek Buitenhuis
     1  Lou Logan
     1  Lukasz Marek
     1  Martin Storsjö
     1  Reimar Döffinger

If the mainatiner of some code has a preferrance that differs from
your preferrance thats nothing to be upset about.

And i stated repeatedly that iam happy to follow the community
preferrance.
But instead of an attempt to poll the community for everyones
preferrance. there are 3 or 4 people who keep telling me
with increased aggression to do what they say. That is with mails
worded as if there was alot of authority behind them.
I find these mails quite rude honestly. Rude toward the community and
toward me.

Thus you have the current situation where patches i write for code
maintained by people who stated they want "no error messages" to have
no such messages. (unless i forget)

And patches writen for code maintained by me and others who didnt
state anything often contain error messages. (unless i forget)

Thats not ignoring people, i try to respect everyones preferrance in
code they maintain. And i would wish they would respect mine in code
i maintain, but some dont do that.

If somone explicitly objects to a patch i have always refrained from
pushing it.

And it seems people very easily get upset if I propose changes to code
i maintain that they previously told me they dont like.
"Why" really is beyond my comperhension. Iam the one maintaining this
code, and even have only proposed the changes in a posted patch.


> 
> > I tried to find a common ground regarding the error messages in this
> > thread an the other and almost got it. But then i fucked up by agreeing
> > with you about removing snowenc which started this stupid branch of the
> > discussion. So please, like Clement said, chill out. We gain nothing
> > with all this and lose plenty.
> 
> What could we possibly lose at this point.

a lot
anger and hostility rarely leads to good things



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

If you drop bombs on a foreign country and kill a hundred thousand
innocent people, expect your government to call the consequence
"unprovoked inhuman terrorist attacks" and use it to justify dropping
more bombs and killing more people. The technology changed, the idea is old.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 181 bytes
Desc: Digital signature
URL: <http://ffmpeg.org/pipermail/ffmpeg-devel/attachments/20170907/1bce1c3b/attachment.sig>