[FFmpeg-devel] [PATCH] avcodec/dxv: add support for "high" quality mode

[wm4]

On Thu, 12 Apr 2018 15:49:30 +0200
Michael Niedermayer <michael at niedermayer.cc> wrote:

> On Thu, Apr 12, 2018 at 01:57:34PM +0100, Rostislav Pehlivanov wrote:
> > On 12 April 2018 at 11:31, Paul B Mahol <onemda at gmail.com> wrote:
> >   
> > > Signed-off-by: Paul B Mahol <onemda at gmail.com>
> > > ---
> > >  libavcodec/dxv.c | 1006 ++++++++++++++++++++++++++++++
> > > ++++++++++++++++++++++--
> > >  1 file changed, 978 insertions(+), 28 deletions(-)
> > >
> > >
> > > +
> > > +static av_always_inline uint32_t yacocg2rgba(int yo, int co, int cg, int
> > > a)
> > > +{
> > > +    int r, g, b;
> > > +
> > > +    co = co - 127;
> > > +    cg = cg - 127;
> > > +
> > > +    r = av_clip_uint8(yo + co - cg);
> > > +    g = av_clip_uint8(yo + cg);
> > > +    b = av_clip_uint8(yo - co - cg);
> > > +
> > > +    return (a << 24) | (b << 16) | (g << 8) | (r);
> > > +}  
> > 
> > 
> > Cinepak all over again? We're not doing and are never going to do  
> 
> no, its different.
> The cinepak case was a volunteer who wanted to maintain the cinepak code, had
> a patch that made the decoder several fold faster (in his practical use) and 
> possibly closer in output to the binary reference. That by doing colorspace
> convertion to the vector quantizer data tables IIRC
> 
> He was attacked
> cinepak in ffmpeg is unmaintained since then and there has been no further
> contribution from him since then either.
> 
> This case here is very different, noone depends on this IIUC.
> So i have no strong oppinion on this.
> 
> The mention of cinepak as a "good" example is what makes me a bit upset.
> I do not think we should be proud of how that cinepak case was handled.

No, he posted a patch that was unacceptable for several reasons. These
were pointed out. He then made a drama out of it, implying something
about how FFmpeg will fade into irrelevance because Cinepak support is
not the "best". And now you drag out this drama, for whatever reason.

He also failed to provide explanations why this was supposed to be
necessary. Keep in mind that he wanted to decode directly to obscure
packed RGB formats and such.

Also Cinepak is an obscure garbage codec, so it's not a big loss that
it's a bit slower. Nobody complained about Cinepak support ever, except
that one guy.