[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