Hi, On Wed, Feb 8, 2017 at 2:45 AM, <u-9...@aetey.se> wrote:
> This unfortunately can not come near an identical performance because > it would have to work on several times more data (frame vs codebook). [..] > I value layered design as much as you do, but it introduces limitations. [..] > In certain aspects, by the original design, it is still superior to > virtualy anything else at hand. With the proposed optimization we get the > best out of its virtues. It would be a waste to ignore the possibility. 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 just don't think it belongs in upstream FFmpeg. (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 interesting that we chose rgb24 as output format, I'm guessing it's because YCgCo support in FFmpeg is non-existent.) Ronald _______________________________________________ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
