{"id":3601,"date":"2011-10-19T23:13:36","date_gmt":"2011-10-20T06:13:36","guid":{"rendered":"http:\/\/multimedia.cx\/eggs\/?p=3601"},"modified":"2011-10-19T23:13:36","modified_gmt":"2011-10-20T06:13:36","slug":"more-cinepak-madness","status":"publish","type":"post","link":"https:\/\/multimedia.cx\/eggs\/more-cinepak-madness\/","title":{"rendered":"More Cinepak Madness"},"content":{"rendered":"<p>Fellow digital archaeologist <a href=\"http:\/\/clone2727.blogspot.com\/\">Clone2727<\/a> found a <em>possible<\/em> fifth variant of the <a href=\"http:\/\/wiki.multimedia.cx\/index.php?title=Cinepak\">Cinepak video codec<\/a>. He asked me if I cared to investigate the sample. I assured him I wouldn&#8217;t be able to die a happy multimedia nerd unless I have cataloged all possible Cinepak variants known to exist in the wild. I&#8217;m sure there are chemistry nerds out there who are ecstatic when another element is added to the periodic table. Well, that&#8217;s me, except with weird multimedia formats.<\/p>\n<p><strong>Background<\/strong><br \/>\nCinepak is a video codec that saw widespread use in the early days of digital multimedia. To date, we have cataloged 4 variants of Cinepak in the wild. This distinction is useful when trying to write and maintain an all-in-one decoder. The variants are:<\/p>\n<ol>\n<li>The standard type: Most Cinepak data falls into this category. It decodes to a modified\/simplified YUV 4:2:0 planar colorspace and is often seen in AVI and QuickTime\/MOV files.<\/li>\n<li>8-bit greyscale: Essentially the same as the standard type but with only a Y plane. This has only been identified in AVI files and is distinguished by the file header&#8217;s video bits\/pixel field being set to 8 instead of 24.<\/li>\n<li>8-bit paletted: Again, this is identified by the video header specifying 8 bits\/pixel for a Cinepak stream. There is essentially only a Y plane in the data, however, each 8-bit value is a palette index. The palette is transported along with the video header. To date, only one known sample of this format has even been spotted in the wild, and it&#8217;s classified as NSFW. It is also a QuickTime\/MOV file.<\/li>\n<li><a href=\"http:\/\/wiki.multimedia.cx\/index.php?title=Sega_FILM\">Sega\/FILM CPK<\/a> data: Sega Saturn games often used CPK files which stored a variant of Cinepak that, while very close the standard Cinepak, couldn&#8217;t be decoded with standard decoder components.<\/li>\n<\/ol>\n<p>So, a flexible Cinepak decoder has to identify if the file&#8217;s video header specified 8 bits\/pixel. How does it distinguish between greyscale and paletted? If a file is paletted, a custom palette should have been included with the video header. Thus, if video bits\/pixel is 8 and a palette is present, use paletted; else, use greyscale. Beyond that, the Cinepak decoder has a heuristic to determine how to handle the standard type of data, which might deviate slightly if it comes from a Sega CPK file.<\/p>\n<p><strong>The Fifth Variant?<\/strong><br \/>\nNow, regarding this fifth variant&#8211; the reason this issue came up is because of that aforementioned heuristic. Basically, a Cinepak chunk is supposed to store the length of the entire chunk in its header. The data from a Sega CPK file plays fast and loose with this chunk size and the discrepancy makes it easy to determine if the data requires special handling. However, a handful of files discovered on a Macintosh game called <a href=\"http:\/\/www.mobygames.com\/game\/macintosh\/journeyman-project-pegasus-prime\">&#8220;The Journeyman Project: Pegasus Prime&#8221;<\/a> have chunk lengths which are sometimes in disagreement with the lengths reported in the containing QuickTime file&#8217;s stsz atom. This trips the heuristic and tries to apply the CPK rules against Cinepak data which, aside from the weird chunk length, is perfectly compliant.<\/p>\n<p>Here are the first few chunk sizes, as reported by the file header (stsz atom) and the chunk:<\/p>\n<pre>\r\nsize from stsz = 7880 (0x1EC8); from header = 3940 (0xF64)\r\nsize from stsz = 3940 (0xF64); from header = 3940 (0xF64)\r\nsize from stsz = 15792 (0x3DB0); from header = 3948 (0xF6C)\r\nsize from stsz = 11844 (0x2E44); from header = 3948 (0xF6C)\r\n\r\n<\/pre>\n<p>Hey, there&#8217;s a pattern here. If they don&#8217;t match, then the stsz size is an even multiple of the chunk size (2x, 3x, or 4x in my observation). I suppose I could revise the heuristic to state that if the stsz size is 2x, 3x, 4x, or equal to the chunk header, qualify it as compliant Cinepak data.<\/p>\n<p>Of course it feels impure, but software engineering is rarely about programmatic purity. A decade of special cases in the <a href=\"http:\/\/ffmpeg.org\/\">FFmpeg<\/a> \/ <a href=\"http:\/\/libav.org\/\">Libav<\/a> codebases are a testament to that.<\/p>\n<p><strong>What&#8217;s A Variant?<\/strong><br \/>\nSuddenly, I find myself contemplating what truly constitutes a variant. Maybe this was just a broken encoder program making these files? And for that, I assign it the designation of distinct variation, like some sort of special, unique showflake?<\/p>\n<p>Then again, I documented <a href=\"http:\/\/wiki.multimedia.cx\/index.php?title=Flic_Video#Magic_Carpet\">Magic Carpet FLIC<\/a> as being a distinct variant of the broader FLIC format (which has <a href=\"http:\/\/www.compuphase.com\/flic.htm\">an enormous number of variants<\/a> as well).<\/p>\n","protected":false},"excerpt":{"rendered":"<p>Cataloging different types of Cinepak video codec data<\/p>\n","protected":false},"author":1,"featured_media":0,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[14],"tags":[],"class_list":["post-3601","post","type-post","status-publish","format-standard","hentry","category-codec-technology"],"aioseo_notices":[],"_links":{"self":[{"href":"https:\/\/multimedia.cx\/eggs\/wp-json\/wp\/v2\/posts\/3601","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/multimedia.cx\/eggs\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/multimedia.cx\/eggs\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/multimedia.cx\/eggs\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/multimedia.cx\/eggs\/wp-json\/wp\/v2\/comments?post=3601"}],"version-history":[{"count":4,"href":"https:\/\/multimedia.cx\/eggs\/wp-json\/wp\/v2\/posts\/3601\/revisions"}],"predecessor-version":[{"id":3605,"href":"https:\/\/multimedia.cx\/eggs\/wp-json\/wp\/v2\/posts\/3601\/revisions\/3605"}],"wp:attachment":[{"href":"https:\/\/multimedia.cx\/eggs\/wp-json\/wp\/v2\/media?parent=3601"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/multimedia.cx\/eggs\/wp-json\/wp\/v2\/categories?post=3601"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/multimedia.cx\/eggs\/wp-json\/wp\/v2\/tags?post=3601"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}