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

[James Almer]

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:
>> [...]
>>>>>> Can't we just remove this codec? It has no use other than causing
>>>>>> potential security issues and maintenance.    
>>>>>
>>>>> I agree about removing the encoder, but the decoder is needed for
>>>>> existing streams. Unless everyone just argues it has no real world
>>>>> samples for being an avcodec-only toy codec.
>>>>>
>>>>> If you send a patch removing the encoder without also trying to remove
>>>>> all the things that currently depend on it (One or two filters i think)
>>>>> then I'll +1 it. ffv1 and mpeg4 encoders are enough for any kind of
>>>>> testing, fate or otherwise, that might require a native encoder.    
>>>>
>>>> I find it a bit offensive that people suggest to remove the encoder i
>>>> maintain.  
>>>
>>> Can I add my own unused fringe codec with no users, as long as I
>>> maintain it?  
>>
>> Is there any reason to be so obsessed with snow? There are plenty of other
>> "fringe" codecs in the codebase that only one person in the world cared
>> about 10 years ago. Snow is one of the rare wavelet codecs, and as a
>> result is much more valuable than many random basic game flavored codecs.
>> And somehow, no one ever mention those.
> 
> Those game codecs have actually some use. There are files in the wild
> that are available to many, and that aren't just demo/test files. But
> it's true that all these game codecs bloat the codebase, cause
> maintenance and security issues, and have little use. They barely have
> a justification to exist too.

Don't be one of those that go "h264/aac/mov is all ffmpeg should care
about".

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

> 
> If you feel like what I'm doing is harassment, I can end my involvement
> with michael to avoid this - but only if you stop him from doing bad
> things.

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.
Even when you were proven wrong (the runtime cpu flag stuff) you answer
was "Then go and rewrite the entire dsp initialization infrastructure".
What made you think that was a good reply? If anything, that's what
whoever is trying to introduce the faulty behavior should do, not him
that reported why it's faulty.

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.

> 
>> Please people, chill out. I understand the frustration when someone
>> doesn't understand something that feel obvious to "everyone" and keep
>> insisting on it, but that doesn't mean you should enter in some form of
>> obsession and vengeance about anything he did/does/will do.
>>
>> ...aaand here I am, back in the "Insane people defending Michael all the
>> time" category.
> 
> We don't really need more of that category.
> _______________________________________________
> ffmpeg-devel mailing list
> ffmpeg-devel at ffmpeg.org
> http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
>