[FFmpeg-devel] [PATCH] Cinepak: speed up decoding several-fold, depending on the scenario, by supporting multiple output pixel formats.
h.leppkes at gmail.com
Tue Feb 7 20:21:39 EET 2017
On Tue, Feb 7, 2017 at 6:48 PM, <u-9iep at aetey.se> wrote:
> 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.
If you don't understand why this is bad, then trying to explain it
again is just wasted time.
I'll give you a hint: What if every codec would do this? Surely that
would be faster, but noone in their right mind would ever want to work
on such an abonimation.
>> 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?
If you want effieciency above everything else, maybe you should write
a very specific application tailored for your one specific use-case,
and not use a generic multimedia frame work like ffmpeg.
Anyway, you don't seem to be understanding our points at all, so the
chances of this ever being commited are reaching zero.
More information about the ffmpeg-devel