Difference between revisions of "Cinepak"

From MultimediaWiki
Jump to navigation Jump to search
(refreshed info, added a technical note)
(added some complexity/performance figures)
Line 6: Line 6:
  
 
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.
 
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.
 +
 +
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
 
There are several versions of a binary proprietary encoder/decoder as a windows dll, among others ftp://ftp.probo.com/pub/cinepak/cvid32.zip
Line 12: Line 14:
 
http://titan.codemill.se/~tomhar/cinepakenc.patch
 
http://titan.codemill.se/~tomhar/cinepakenc.patch
  
The encoder mentioned above was adapted for the current (December 2012) ffmpeg, bugfixed and improved for better rate/distortion performance by Rl. The compression speed is barely optimized (it is slow), a choice made for keeping simplicity and r/d. A snapshot 2013-02-18 is at
+
The encoder mentioned above was adapted for the current (December 2012) ffmpeg, bugfixed and improved for better rate/distortion performance by Rl. The compression speed is barely optimized (it is slow), a choice made for keeping simplicity and r/d. The encoder seems to outperform the proprietary one but does not yet produce streams fully playable by the legacy decoders (the stream format is simple but the constraints of its interpretation by those decoders remain undocumented). The decoder in ffmpeg is of course happy with the streams. A snapshot 2013-02-18 is at
 
http://www.aetey.se/dl/cinepak-encoder-ffmpeg.patch
 
http://www.aetey.se/dl/cinepak-encoder-ffmpeg.patch
  
ffmpeg used to contain an almost compliant decoder (using YUV420 instead of the Cinepak colorspace, which distorts colors), a colorspace fix has been submitted (as of 2013-02-18) by Rl, also improving decoding speed with 15-60% and stream format compliance.This patch is also available at
+
ffmpeg's decoder used to be partially compliant (substituting Cinepak colorspace with YUV420, which distorted colors). A colorspace fix has been submitted (as of 2013-02-18) by Rl, also improving decoding speed with 15-60% and stream format compliance. Since then the new decoder is part of ffmpeg.
http://www.aetey.se/dl/cinepak-decoder-colorspace.patch
 
  
The encoder was never submitted for inclusion in ffmpeg, feel free to push it upstream.
+
The encoder was never submitted for inclusion in ffmpeg, feel free to complete its compliance and push it upstream.
  
 
----
 
----

Revision as of 02:07, 27 July 2013

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.

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

There is also a simple and straightforward open source encoder as a ffmpeg patch, written in 2011 by Tomas Härdin and available at http://titan.codemill.se/~tomhar/cinepakenc.patch

The encoder mentioned above was adapted for the current (December 2012) ffmpeg, bugfixed and improved for better rate/distortion performance by Rl. The compression speed is barely optimized (it is slow), a choice made for keeping simplicity and r/d. The encoder seems to outperform the proprietary one but does not yet produce streams fully playable by the legacy decoders (the stream format is simple but the constraints of its interpretation by those decoders remain undocumented). The decoder in ffmpeg is of course happy with the streams. A snapshot 2013-02-18 is at http://www.aetey.se/dl/cinepak-encoder-ffmpeg.patch

ffmpeg's decoder used to be partially compliant (substituting Cinepak colorspace with YUV420, which distorted colors). A colorspace fix has been submitted (as of 2013-02-18) by Rl, also improving decoding speed with 15-60% and stream format compliance. Since then the new decoder is part of ffmpeg.

The encoder was never submitted for inclusion in ffmpeg, feel free to complete its compliance and push it upstream.


A technical note: 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; }