[FFmpeg-devel] [PATCH] Cinepak: speed up decoding several-fold, depending on the scenario, by supporting multiple output pixel formats.

[u-9iep at aetey.se]

On Tue, Feb 07, 2017 at 04:17:30PM +0100, Hendrik Leppkes wrote:
> On Tue, Feb 7, 2017 at 3:57 PM,  <u-9iep at aetey.se> wrote:
> > Still, given the disapproval of the "code quality" without a tangible
> > criteria to follow, I can hardly take any accomodating steps, barring
> > the omission of the unused code - would this step be enough?
> 
> The code duplication is still enormous and makes the entire approach

Do you mean the about dozen lines which by the bitstream design are
doing exactly the same but are repeated almost literally in every of
the 10 finctions? This is the duplication I see, do you mean this or
something else?

> look rather questionable, and on top of that some built-in yuv
> conversion is not really appropriate. Packing into different RGB

Why not appropriate if it is useful?
Any other way to do equally fast decoding to YUV?

> formats is one thing, but actually converting to another color format
> entirely is quite something else. Whats next, handling all sorts of

You talk past me! What makes you accept the one but not the other? :)

> various yuv colorspaces and subsampling factors?

Why not, if there will be a data consumer with this hypothetical format
and we will need speed? Why not? This _is_ efficient at the decoder,
it is just many of the developers ignored this fact until now.

> So at the very least the YUV part should be dropped at this point, its
> not a decoders job to convert from RGB to YUV.

What is the criteria to choose where the job is to be done?
My point is efficiency. What is yours?

Regards,
Rune