On Thu, Apr 12, 2018 at 01:57:34PM +0100, Rostislav Pehlivanov wrote:
> On 12 April 2018 at 11:31, Paul B Mahol <one...@gmail.com> wrote:
>
> > Signed-off-by: Paul B Mahol <one...@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 dono, 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. > conversion inside decoders. Output it as YCoCg by writing directly to the > data planes. We support it. It doesn't matter if it's perfectly mappable to > RGB, if you allow for 2 more bits of precision. Thanks [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB The misfortune of the wise is better than the prosperity of the fool. -- Epicurus
signature.asc
Description: PGP signature
_______________________________________________ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
