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

[Hendrik Leppkes]

On Tue, Feb 7, 2017 at 3:57 PM,  <u-9iep at aetey.se> wrote:
> On Mon, Feb 06, 2017 at 11:05:06PM +0100, Clément Bœsch wrote:
>> On Mon, Feb 06, 2017 at 10:05:10AM +0100, u-9iep at aetey.se wrote:
>> [...]
>> > > No, code quality is not outside the scope of your patch.
>> >
>> > Code quality is a subjective matter.
>> >
>>
>> I'm not going to fight with you
>
> Appreciated.
>
>> several developers consider your patch
>> does not pass the quality requirements of the project. It's arbitrary,
>> [... skipped ...], but that's the current policy of the project.
>
> Well said.
>
>> Changing that policy is outside the scope of this patch.
>
> :)
>
>> [...]
>> > > The use of the environment variable is not tolerable, this is a blocker.
>> >
>> > It is explicitly specified that it is _not_ being used,
>>
>> Then please drop the dead code.
>
> Ok, why not.
>
> 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
look rather questionable, and on top of that some built-in yuv
conversion is not really appropriate. Packing into different RGB
formats is one thing, but actually converting to another color format
entirely is quite something else. Whats next, handling all sorts of
various yuv colorspaces and subsampling factors?

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.

- Hendrik