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 _______________________________________________ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
