Cinepak

From MultimediaWiki
Jump to navigation Jump to search

The Cinepak coding method is a vector quantization scheme with interframe update optimization. It is known to operate most commonly using a modified YUV 4:2:0 colorspace but also supports 256-grayscale and palettized mode. A modified variant of this format is used for full motion video on many Sega Saturn games (in Sega FILM files often bearing the .cpk extension). It is not known if this format has anything in common with the Cinepak For Sega format used in many Sega CD games.

According to https://en.wikipedia.org/wiki/Cinepak (as of 2013-07-27) Cinepak was released in 1991. There is also a patent which seems to approximately describe the codec: http://www.patentstorm.us/patents/5467413/fulltext.html "Patent 5467413 Issued on November 14, 1995. Estimated Expiration Date: May 20, 2013", submitted 05/20/1993.

The old technology is still being used. As of 2012: "Cinepak Codec for 64 bit is now available" http://beyonddesign.typepad.com/posts/2012/09/service-pack-2-now-available-for-autodesk-navisworks-2013.html

The codec has a very low decoding complexity. With Motorola 68k CPUs at 25 to 33MHz it is known to be well playable as 320x240 2175kbits/sec at 15fps. For a better visual quality with those CPUs 24fps, 320x240, 1800kbps could be recommended (according to http://www.synack.net/~bbraun/68kvideo.html written Jan. 23 2010).

There are several versions of a binary proprietary encoder/decoder as a windows dll, among others ftp://ftp.probo.com/pub/cinepak/cvid32.zip, these dlls can be used on other platforms via "mencoder -ovc vfw -xvfwopts codec=iccvid.dll".

ffmpeg includes both a decoder and an encoder for Cinepak (the encoder draft was written by Tomas Härdin in 2011, made operational and submitted to ffmpeg in January 2014 by Rl @ Aetey). The encoder is simple and quite straightforward, not optimized for speed. It is much slower than its proprietary counterpart but has better quality/bitrate (a double blind test would be welcome).


Technical notes:

x1, x2 and y1, y2 strip coordinates are absolute, unless y1==0 and the strip is not the first one on the frame - then y1 is assumed to coincide with y2 from the previous strip and the read y2 contains the strip height, i.e. if(read_y1==0){ y1 = previous_y2; y2 = previous_y2 + read_y2; }

Vintage players on both Windows and MacOS work only if the number of strips per frame does not exceed 3.

MacOS player needs codebook definitions always to be present even for empty codebooks, in strict order (v4, then v1).

The technical description does not indicate it, but the conversion matrix from conversion to YUV and RGB color space seems to be as follows:

   | y |   | 0 |   |  0.2857  0.5714  0.1429 | | r |
   | u | = |128| + | -0.1429 -0.2857  0.4286 | | g |
   | v |   |128|   |  0.3571 -0.2857 -0.0714 | | b |

The same is true for the inverse matrix:

   | r |   | 1.0  0.0  2.0 | |   y     |
   | g | = | 1.0 -0.5 -1.0 | | u - 128 |
   | b |   | 1.0  2.0  0.0 | | v - 128 |