[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
Tue Feb 14 13:14:04 EET 2017


On Tue, Feb 14, 2017 at 10:03:41AM +0100, Paul B Mahol wrote:
> Correct way in solving this is outputing in cinepak decoder actual
> native format that it
> uses and not do any conversions of colorspace which is currently done.
> Implement correct colorspace conversions of cinepak format to others
> in libswscale.

Would you comment on what is the difference between now and the situation

 https://ffmpeg.org/pipermail/ffmpeg-devel/2013-February/138811.html

when you (?) wrote on the same topic

-----------
> i think hes asking if it should be a new colorspace in swscale, or
> added into the cinepak decoder/encoder common code.
>
> by your answer i think it has to be a new swscale colorspace?

Please leave libswscale alone.
-----------

That position was IMHO reasonable.

Commenting on your current suggestion:

What would be the advantage of moving the Cinepak-specific conversions
into the general purpose library? Either this would mean as many
variations of the conversion code as there are in the decoder now or
the conversion would be done through some intermediate format, which is
a loss per se. The code still only would be used by Cinepak.

Besides this, for a purely technical reason the conversions done in
Cinepak are not suitable for delayed delegation to swscaler.

The reason has been already pointed out in the thread:

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.

(BTW mathematically DCT to the contrary is equivalent to referencing an
extremely large codebook. This codebook does not have to be transmitted
or stored, neither of which would be practical. Instead its entries are
generated on-demand, for each frame data block. This is the situation
where swscale is an efficient tool.)

Hope this helps.

Regards,
Rune



More information about the ffmpeg-devel mailing list