[FFmpeg-devel] [PATCH] Efficiently support several output pixel formats in Cinepak decoder

[u-9iep at aetey.se]

On Wed, Feb 08, 2017 at 09:02:44AM -0500, Ronald S. Bultje wrote:
> I encourage you to fork the code and publish the faster decoder so others
> with use cases like yours can use it. It's free software, you're allowed
> and encouraged to do that.

I considered this possibility. My scope of contribution is though "a
useful modification". Leading/maintaining a multimedia-tool-project is
a very different thing and not something I am interested in.

> I just don't think it belongs in upstream FFmpeg.

This depends of course on the idea of what FFmpeg is.
I am not qualified to make such a definition, given my limited
engagement here.

My expectation was "the Swiss Army Knife of multimedia" and "the most
efficient tool in its class". If either of those is not or no longer
relevant, not my thing to decide, then the patch is indeed wrongly
addressed.

> (Going back to the native format discussion, I looked at decode_codebook
> and it appears the native format is actually 8-bit/component YCgCo; it's

Not exactly, it is similar but Cinepak-specific, it is also optimized for
conversion to rgb.

> interesting that we chose rgb24 as output format, I'm guessing it's because

It is the natural target format of Cinepak's design.

> YCgCo support in FFmpeg is non-existent.)

Kind of.
(https://ffmpeg.org/pipermail/ffmpeg-devel/2013-February/138811.html)

This was fortunate, allowing to notice the gain associated with filling
the codebook with the converted data, compared to doing the conversion
on the resulting frame.

>From the commit message Mon Feb 18 18:00:33 2013 +0100
"
    old decoder + conversion to rgb:         fps = 2618
    old decoder, without converting to rgb:  fps = 4012
    
    new decoder, producing rgb:              fps = 4502
"

Regards,
Rune