On Fri, 3 Feb 2017 10:46:12 +0100 u-9...@aetey.se wrote: > On Thu, Feb 02, 2017 at 05:52:29PM +0100, wm4 wrote: > > On Thu, 2 Feb 2017 16:59:51 +0100 > > u-9...@aetey.se wrote:
> > The heavy code duplication has other downsides. What if someone fixes > > a bug, but only in the rgb32 version and ignores the rgb565 version? > > There is no guarantee that this is the same bug or that the same fix > would apply, because the functions are subtly different. Yes, duplicated code with subtle changes is harder to maintain. > > > Have you got a suggestion how to do avoid this in this case, > > > without sacrificing the speed? > > > > Is there any value in this at all? It's a very old codec, that was > > apparently used by some video games. What modern application of it > > would there possibly be? And that in addition would require special > > optimizations done by no other codec? > > Cinepak is not a "game codec" but a solid video codec and has been used > very widely, for a long time, for a large range of applications. > > For some niche applications it still provides the best result, being > a single and far away leader in decoding speed. > > On a 16-bit-per-pixel output with a CPU-based decoder you will > not find _any_ over 25% of Cinepak speed. Raw video can not compete > either when indata delivery bandwidth si limited. > > It has also an unused improvement margin in the encoder, still keeping > legacy decoders compatibility. The current encoder is already performing > a _way_ better than the proprietary one, so why leave this nice tool > unused where it can help? I can't take this seriously, but I won't go and try finding a better codec just to make a point. > > > Any suggestion which can replace this approach? > > > > get_format would be more appropriate. > > get_format() does not belong to the decoder, nor is it up to the task, > which I explained in a recent message. I don't know what you're thinking, but that's just wrong. _______________________________________________ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
