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

u-9iep at aetey.se u-9iep at aetey.se
Wed Feb 15 13:01:55 EET 2017

Hi Ronald,

On Tue, Feb 14, 2017 at 09:46:55AM -0500, Ronald S. Bultje wrote:
> > The huge difference in the amount of the data to be processed; in other
> > words the very essence of the vector quantization technology where frame
> > data is represented by a codebook, by design meant to be much smaller.
> We acknowledge that. We understand this. Nobody disputes this.

Just several lines below you assume (why?) that using this specific advantage
in Cinepak would create any ground for a "corresponding change" in h264.
As far as I know h264 does not use vector quantization on the final
output data, or what do you mean by the following:

> But we still don't think breaking the modularization is the right way
> forward. I'm sorry. We're thinking about this in terms of maintainability
> as well as speed. The problem is that once we allow this, people will ask
> for 16bit output in h264 for all native bitdepths, or even packed formats
> (Kieran already asked).

Unfortunately I do not see this as having any real relevance.
If there indeed is a gain to be collected for h264, it should be weighed
against the cost to be caused by a change _there_.

As a matter of fact, I do not suggest "breaking modularity in ffmpeg".

Modularity, a very useful concept, like any other concept has its area
of usefulness. An approach very reasonable in most situations should
not be mistaken for "the best one in all cases".

Here we have a case where enforced application of this generally useful
concept is remarkably far from optimal.

> We know it's faster. We also know it's unreasonable from a maintenance

You do not know the latter.
Your guess possibly reflects the feeling of a fundamental concept
being neglected, but this in not a case of neglection/ignorance.

> perspective. We have to draw a line somewhere. It's an imperfect line but
> there's a reason for it. I'm sorry. That's life.

You do not have to be sorry, just be substantial.

I have checked the changes done to Cinepak decoder during the 4 years
since it began to decode correctly.

If the change being discussed now would have been applied back then,
one of the later commits would have had about 15 extra lines to change
(btw, in a very regular fashion: "frame." => "frame->" nothing else).

Another commit would have to change 5 lines instead of 1.

The latter indicated indeed an unnecessary duplication in variable
declarations, sorry for that. I now change the patch to avoid this.

That's all. Tell me if I missed something.

The decoder is used rarely but it is indispensable when maximal speed
is needed. There is no substitute.

Is a 3-fold improvement in the decoding speed worth 15 extra lines
to change once in 4 years?


More information about the ffmpeg-devel mailing list