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

wm4 nfxjfg at googlemail.com
Fri Feb 3 12:14:28 EET 2017


On Fri, 3 Feb 2017 10:46:12 +0100
u-9iep at 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-9iep at 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.


More information about the ffmpeg-devel mailing list