https://wiki.multimedia.cx/api.php?action=feedcontributions&user=Multimedia+Mike&feedformat=atomMultimediaWiki - User contributions [en]2024-03-28T09:08:09ZUser contributionsMediaWiki 1.39.5https://wiki.multimedia.cx/index.php?title=Hachoir&diff=15760Hachoir2024-02-07T16:16:48Z<p>Multimedia Mike: update external links</p>
<hr />
<div>Hachoir is a file parser framework written in Python, features:<br />
* '''Autofix''': On error, Hachoir can automatically fix errors on buggy file or parser<br />
* '''Lazy''': Field value, size, description, absolute address, (...) are computed on demand<br />
* '''No arbitrary limit''': Hachoir don't have arbitrary limit: addresses can be bigger than 4 Go, an integer can be 64 bits or more, there is no field number limit, etc.<br />
* '''Types''': Hachoir have many predefined field types: integer, string, boolean, byte array, etc.<br />
* '''Bit granularity''': Size and address are in bits, so it's easy to mix fields with size in bytes or in bits<br />
* '''Unicode''': String value are stored in Unicode (if string charset is specified)<br />
* '''Endian''': You don't have to care about endian: you just need to set it once for the whole parser<br />
* '''No dependency''': Hachoir just needs Python 2.4 (but some frontends need more libraries)<br />
* '''API''': Data are represented as a tree of fields where each field is a Python object<br />
* '''Parser''': 30 parsers are included: JPEG picture, ZIP archive, MP3 audio, etc.<br />
* '''Guess parser''': An algorithm automatically chooses the right parser using file extension, given MIME type or using validate() function of each parser ;<br />
<br />
The tool used to be found at hachoir.org, though that has been taken over by domain squatters. The new homes are:<br />
* https://hachoir.readthedocs.io/en/latest/<br />
* https://github.com/vstinner/hachoir<br />
<br />
[[Category:RE Tools]]</div>Multimedia Mikehttps://wiki.multimedia.cx/index.php?title=Motion_Pixels&diff=15730Motion Pixels2023-10-06T05:11:16Z<p>Multimedia Mike: found another game that uses Motion Pixels</p>
<hr />
<div>* FOURCCs: MVI1, MVI2<br />
* Company: [[Sirius Publishing]]<br />
* Samples:<br />
** MVI1: [http://samples.mplayerhq.hu/game-formats/mvi1-avi/ http://samples.mplayerhq.hu/game-formats/mvi1-avi/]<br />
** MVI2: [http://samples.mplayerhq.hu/V-codecs/MVI2/ http://samples.mplayerhq.hu/V-codecs/MVI2/]<br />
** Movie CD: [http://samples.mplayerhq.hu/drivers32/motionpixelsmoviecd/ http://samples.mplayerhq.hu/drivers32/motionpixelsmoviecd/]<br />
** Movie CD Win32 Codecs: [http://samples.mplayerhq.hu/drivers32/motionpixels/ http://samples.mplayerhq.hu/drivers32/motionpixels/]<br />
<br />
== Introduction ==<br />
<br />
Motion Pixels version 1 (MVI1) was used in a few video games while version 2 (MVI2) was used in a number of Movie CDs. All of these items were published by Sirius Publishing and the Motion Pixels codec is believed to still be owned by the company's CEO, Richard Gnant.<br />
<br />
MVI belongs to the "old-school" family of video codecs and relies on interframe differences and adaptive delta-coding for horizontal lines of the picture. Delta coefficients are additionally [[Huffman|Huffman-packed]]. For better compression at the cost of picture quality additional colorspace downsampling may be used. MVI2 adds smoother delta-coding and the ability to dynamically change downsampling for each frame.<br />
<br />
Compressed MVI1 video may be carried in the custom [[MVI Container]] format.<br />
<br />
== Documentation Notes ==<br />
<br />
As MVI2 version is merely an addition to MVI1, both formats will be documented together, where MVI2-specific features will be marked with '''V2''' symbol.<br />
<br />
== MVI Codec ==<br />
<br />
=== Compression Flags ===<br />
<br />
When video is packaged inside [[AVI]] files, all vital codec's parameters carried in [[BITMAPINFOHEADER]]'s '''biCompression''' field of the video stream. These flag bits are:<br />
<br />
* 0..3 (0x000F) - Colorspace Format (see below)<br />
* '''V2''' 9 (0x0200) - ...<br />
* '''V2''' 10 (0x0400) - ...<br />
* 11 - (0x0800) ...<br />
* 12 - (0x1000) Still-Frame mode<br />
* 13 - (0x2000) Frames are upside-down<br />
* 14 - (0x4000) Video was encoded using trial version of the codec (this flag tells original decoder to put watermark to the frame)<br />
* 15 - (0x8000) Image is interlaced (single-field, in MP's terminology), only odd lines carried<br />
<br />
=== Colorspace Formats ===<br />
<br />
Output always RGB, but as an extra compression feature, source image may be initially converted to one of listed formats:<br />
<br />
* 0 - RGB<br />
* 1 - YUV 4:2:2<br />
* 2 - YUV 4:1:1<br />
* 3 - YUV 8:1:1<br />
* 4 - YUV 16:1:1<br />
<br />
<br />
=== Normal mode VS Still-Frame mode ===<br />
<br />
When videos with small amount of changes encoded (ex, 'talking heads' or some static scenery) special trick may be performed. Very first frame contains all the scenery, while all successive frames take this first frame as a base and add neccessary changes to it. The tricky part is, that first frame contains such a 'change-frame' as well, so you have two logical frames in one physical. Offset to the base frame is located at ('''biSizeImage''' - 4) in the encoded data buffer. Change-frame located at it's start.<br />
<br />
=== Bit Reader ===<br />
<br />
Compressed data stored using binary stream. Bitreader operates with internal 32-bits queue and pops bits starting from the highest. '''TODO''' : Add sample<br />
<br />
=== Decompression ===<br />
<br />
==== General Frame Structure ====<br />
<br />
* Frame Flags<br />
* Mask Block<br />
* Motion Block<br />
* Fill Block<br />
* '''V2''' Extra Block<br />
* Deltas Bundle<br />
** Initial Position<br />
** Color Deltas<br />
** Huffman Tree<br />
** Packed Deltas Indicies<br />
<br />
==== Frame Flags ====<br />
Each frame begins with sequence of local flag bits. These bits are:<br />
{| border="1" cellpadding="5" style="border-collapse: collapse; border-style: dashed; border-color: #2f6fab;"<br />
|- bgcolor="#f0f0f0" |<br />
! # of bits !! Present if !! Name !! Description<br />
|-<br />
| 1 || always || KeyframeFlag || Non-zero if this frame is a key frame (for Still-Frame mode this DOES NOT mean base frame change!)<br />
|-<br />
| '''V2''' 3 || flags bit 9 || ColorSpace || Colorspace Format for this frame<br />
|-<br />
| '''V2''' 1 || flags bit 9 || ... || ...<br />
|-<br />
| '''V2''' 1 || flags bit 9 || SmoothDeltas || Use smooth delta-coding<br />
|-<br />
|'''V2''' 1 || flags bit 9 || HaveSerial || (see next field)<br />
|-<br />
| '''V2''' 20 || flags bit 9 + HaveSerial || SerialNumber || Encoder's serial number<br />
|-<br />
| '''V2''' 1 || flags bit 9 || ... || ...<br />
|-<br />
| '''V2''' 8 || flags bit 10 || ... || ...<br />
|-<br />
| '''V2''' 8 || flags bit 10 || ... || ...<br />
|}<br />
<br />
==== Mask Block ====<br />
Mask block contains changes since the last frame. There are two types of masks - general masks, which tell what rectangular area has changed since last frame, and fill masks, which also specify colour value to fill that rectangle.<br />
If bit (buf[1]&2) is set then general masks are present along with fill mask, otherwise only fill masks are present.<br />
<br />
Masks bistream:<br />
<br />
12 bits count of masks with dimensions <= 256x256<br />
12 bits count of masks with dimensions <= 16x16<br />
masks<br />
<br />
Mask data is stored as <offset, width, height, [color]>. Offset size = ceil(log2(frame width * frame height)), width and height take 4 or 8 bits depending on mask max dimension, color value is present only for fill masks and takes 15 bits.<br />
<br />
==== Motion Block ====<br />
==== Fill Block ====<br />
==== Extra Block ====<br />
==== Color Deltas Bundle ====<br />
==== Assembling the Frame ====<br />
<br />
== Games Using Motion Pixels ==<br />
* [https://www.mobygames.com/game/windows/treasure-quest Treasure Quest]<br />
* [https://www.mobygames.com/game/25426/apollo-18-the-moon-missions/ Apollo 18: The Moon Missions]<br />
<br />
[[Category:Video Codecs]]<br />
[[Category:Undiscovered Video Codecs]]<br />
[[Category:Undiscovered Game Formats]]<br />
[[Category:Game Formats]]<br />
[[Category:Formats missing in MPlayer]]</div>Multimedia Mikehttps://wiki.multimedia.cx/index.php?title=Duck_IVF&diff=15696Duck IVF2022-12-28T01:01:47Z<p>Multimedia Mike: fix incorrect offset</p>
<hr />
<div>* Extension: ivf<br />
* Samples: The test-vectors-* archives available here: https://chromium.googlesource.com/webm/vp8-test-vectors<br />
<br />
IVF is a simple file format that transports raw VP8 data.<br />
<br />
Multi-byte numbers of little-endian. An IVF file begins with a 32-byte header:<br />
<br />
bytes 0-3 signature: 'DKIF'<br />
bytes 4-5 version (should be 0)<br />
bytes 6-7 length of header in bytes<br />
bytes 8-11 codec FourCC (e.g., 'VP80')<br />
bytes 12-13 width in pixels<br />
bytes 14-15 height in pixels<br />
bytes 16-19 time base denominator<br />
bytes 20-23 time base numerator<br />
bytes 24-27 number of frames in file<br />
bytes 28-31 unused<br />
<br />
The header is followed by a series of frames. Each frame consists of a 12-byte header followed by data:<br />
<br />
bytes 0-3 size of frame in bytes (not including the 12-byte header)<br />
bytes 4-11 64-bit presentation timestamp<br />
bytes 12.. frame data<br />
<br />
== PC games using IVF files ==<br />
<br />
* [https://www.mobygames.com/game/rogue-trooper-redux Rogue Trooper Redux]<br />
* [https://www.mobygames.com/game/shantae-and-the-seven-sirens Shantae and the Seven Sirens]<br />
<br />
[[Category:Container Formats]]</div>Multimedia Mikehttps://wiki.multimedia.cx/index.php?title=SFD&diff=15627SFD2022-04-14T03:42:32Z<p>Multimedia Mike: Redirected page to Sofdec</p>
<hr />
<div>#redirect: [[Sofdec]]</div>Multimedia Mikehttps://wiki.multimedia.cx/index.php?title=MXF&diff=15626MXF2022-04-11T05:47:39Z<p>Multimedia Mike: link to mirrored file</p>
<hr />
<div>* Official portal for the SMPTE MXF Implementers Group (SMPTE W25.10): http://www.smpte-mxf.org/<br />
* Samples:<br />
** http://www.freemxf.org/samples/index.html <br />
** http://www.irt.de/IRT/mxf/files/index.php<br />
** http://samples.mplayerhq.hu/MXF/<br />
<br />
MXF is a container used by the broadcasting industry.<br />
<br />
MXF is also the official container for Digital Cinema Material.<br />
http://www.dcimovies.com/DCI_Digital_Cinema_System_Spec_v1.pdf ([[Mirrored Files|Mirrored]])<br />
<br />
Open source implementation can be found here: [http://www.freemxf.org/ www.freemxf.org]<br />
<br />
FFmpeg implementation: [http://svn.mplayerhq.hu/*checkout*/ffmpeg/trunk/libavformat/mxf.c?content-type=text%2Fplain mxf.c]<br />
<br />
More info can be found at http://trac.videolan.org/vlc/ticket/152 and http://www.digitalpreservation.gov/formats/fdd/fdd000013.shtml#specs.<br />
<br />
=== File structure ===<br />
The file may start with up to 64k "garbage".<br />
Then follows a partition pack, given by the following byte sequence:<br />
byte 0-10 0x06, 0x0E, 0x2B, 0x34, 0x02, 0x05, 0x01, 0x01, 0x0D, 0x01, 0x02 (may not appear in the "garbage")<br />
byte 11 version (currently 0x01)<br />
byte 12 structure type (here 0x01 for partition)<br />
byte 13-15 depends on structure type<br />
<br />
[[Category:Container Formats]]</div>Multimedia Mikehttps://wiki.multimedia.cx/index.php?title=Mirrored_Files&diff=15625Mirrored Files2022-04-11T05:46:52Z<p>Multimedia Mike: mirror for MXF spec</p>
<hr />
<div>This is a list of official technical documents that are mirrored at multimedia.cx for convenience or archival: http://multimedia.cx/mirror/<br />
<br />
Contact [[User:Multimedia Mike|Multimedia Mike]] in order to add documents to the mirror.<br />
<br />
* [[A52]]:<br />
** 2018 Revision:<br />
*** mirror: https://multimedia.cx/mirror/A52-2018.pdf<br />
*** original: https://www.atsc.org/wp-content/uploads/2015/03/A52-2018.pdf<br />
** Revision B:<br />
*** mirror: https://multimedia.cx/mirror/a_52b.pdf<br />
*** original: [offline]<br />
<br />
* [[Apple Core Audio Format]] specification, dated 2006-03-08:<br />
** mirror: https://multimedia.cx/mirror/CAFSpec-2006-03-08.pdf<br />
** original: http://developer.apple.com/documentation/MusicAudio/Reference/CAFSpec/index.html<br />
<br />
* Apple [[QuickTime container]] specification, dated 2007-09-04:<br />
** mirror: https://multimedia.cx/mirror/qtff-2007-09-04.pdf<br />
** original: http://developer.apple.com/mac/library/documentation/QuickTime/QTFF<br />
<br />
* [[Audio Interchange File Format]]:<br />
** mirror: https://multimedia.cx/mirror/AudioIFF1_2_1.htm<br />
<br />
* [[Cinepak]]:<br />
** mirror: https://multimedia.cx/mirror/cinepak.txt<br />
** original: http://www.csse.monash.edu.au/%7etimf/videocodec/cinepak.txt<br />
<br />
* [[CYUV]]:<br />
** mirror: https://multimedia.cx/mirror/cyuv.txt<br />
** original: http://www.csse.monash.edu.au/~timf/videocodec/cyuv.txt<br />
<br />
* [[Dialogic IMA ADPCM]]:<br />
** mirror: https://multimedia.cx/mirror/dialogic-adpcm.pdf<br />
<br />
* [[DTS]]:<br />
** mirror (whitepaper): https://multimedia.cx/mirror/dts-whitepaper.pdf<br />
** mirror (document 1): https://multimedia.cx/mirror/dts1.pdf<br />
** mirror (document 2): https://multimedia.cx/mirror/dts2.pdf<br />
** mirror (DTS patent application, scans, 550 pages, 54 MB PDF): https://multimedia.cx/mirror/EP864146-53.pdf<br />
** mirror (DCA transform): https://multimedia.cx/mirror/dca-transform.pdf<br />
** Specification v1.4.1, 2012-09: https://multimedia.cx/mirror/ts_102114v010401p.pdf<br />
<br />
* [[H264]] draft specification, marked 2002 (E):<br />
** mirror: https://multimedia.cx/mirror/JVT-G050.pdf<br />
<br />
* [[IBM UltiMotion]] specification:<br />
** mirror: https://multimedia.cx/mirror/UMSPEC.ZIP<br />
<br />
* Id [[CIN]]:<br />
** mirror: https://multimedia.cx/mirror/idcin.html<br />
** original: http://www.csse.monash.edu.au/~timf/videocodec/idcin.html<br />
<br />
* Id [[RoQ]]:<br />
** mirror: https://multimedia.cx/mirror/idroq.txt<br />
** original: http://www.csse.monash.edu.au/~timf/videocodec/idroq.txt<br />
** sample decoder source code: https://multimedia.cx/mirror/idroq.tar.gz<br />
<br />
* [[Indeo 3]]:<br />
** mirror (partial specification): https://multimedia.cx/mirror/5386232.pdf<br />
** mirror (header explanation): https://multimedia.cx/mirror/indeo3.txt<br />
** original (header explanation): http://www.csse.monash.edu.au/~timf/videocodec/indeo3.txt<br />
<br />
* [[JPEG-LS]]<br />
** mirror: https://multimedia.cx/mirror/fcd14495p.pdf<br />
<br />
* [[Meridian Lossless Packing]] whitepaper:<br />
** mirror: https://multimedia.cx/mirror/mlp_jap_new.PDF<br />
** original: http://www.meridian-audio.com/w_paper/mlp_jap_new.PDF<br />
<br />
* [[Motion JPEG]] Documentation by Microsoft (1993):<br />
** mirror: https://multimedia.cx/mirror/msmjpg.txt<br />
<br />
* [[MXF]]/Digital Cinema System Specification:<br />
** mirror: https://multimedia.cx/mirror/DCI_Digital_Cinema_System_Spec_v1.pdf<br />
<br />
* [[Nokia MVC]]:<br />
** documentation:<br />
*** original: http://ftp3.itu.ch/av-arch/video-site/0005_Osa/q15j19.doc<br />
*** mirror: https://multimedia.cx/mirror/q15j19.doc<br />
** reference codec:<br />
*** original: http://ftp3.itu.ch/av-arch/video-site/0005_Osa/q15j20.zip<br />
*** mirror: https://multimedia.cx/mirror/q15j20.zip<br />
<br />
* [[Nullsoft Video]]:<br />
** documentation:<br />
*** mirror: https://multimedia.cx/mirror/NSVFormat.rtf<br />
<br />
* [[On2 VP3]]:<br />
** Binary Downloads<br />
*** [https://multimedia.cx/mirror/vpvision/On2VP3VideoForWindows.exe On2 VP3 Video for Windows installer (1.2MB)]<br />
*** [https://multimedia.cx/mirror/vpvision/VpV05install.exe VPVision installer (4.6MB)]<br />
*** [https://multimedia.cx/mirror/vpvision/readme.txt readme.txt]<br />
*** [https://multimedia.cx/mirror/vpvision/readmefirst.txt readmefirst.txt]<br />
** Source Code Downloads<br />
*** [https://multimedia.cx/mirror/vpvision/source/vp32.tar.gz VP3.2 Codec source code (compressed TAR format, 1.1MB)]<br />
*** [https://multimedia.cx/mirror/vpvision/source/vpvision0.5_source.zip VPVision source code (ZIP archive, 5.2MB)]<br />
*** [https://multimedia.cx/mirror/vpvision/source/vorbis_nodebug_tc40_vp0.5rc.zip Vorbis (ZIP archive, 12.7MB)]<br />
*** [https://multimedia.cx/mirror/vpvision/source/readme.txt readme.txt]<br />
*** [https://multimedia.cx/mirror/vpvision/source/readmefirst.txt readmefirst.txt]<br />
<br />
* [[On2 VP6]]:<br />
** VP6 Bitstream & Decoding Specification<br />
*** mirror: https://multimedia.cx/mirror/vp6_format.pdf<br />
** whitepaper:<br />
*** mirror: https://multimedia.cx/mirror/vp6-white-paper.pdf<br />
*** original: http://www.on2.com/cms-data/pdf/1125607149174329.pdf<br />
<br />
* [[On2 VP7]]:<br />
** VP7 Data Format and Decoder<br />
*** mirror: https://multimedia.cx/mirror/VP7_Data_Format_and_Decoder_Overview.pdf<br />
** whitepaper:<br />
*** mirror: https://multimedia.cx/mirror/vp7-white-paper.pdf<br />
*** original: http://www.on2.com/cms-data/pdf/1123531744838491.pdf<br />
<br />
* [[PVA]] specification:<br />
** mirror: https://multimedia.cx/mirror/av_format_v1.pdf<br />
<br />
* [[RealAudio 14.4]]:<br />
** mirror: https://multimedia.cx/mirror/spra136.pdf<br />
** original: http://focus.ti.com/lit/an/spra136/spra136.pdf<br />
<br />
* [[RealVideo]] document assortment ([https://multimedia.cx/eggs/official-realvideo-specifications/ described in this blog post]):<br />
** mirror: https://multimedia.cx/mirror/realvideo/<br />
** original: https://rarvcode-video.helixcommunity.org/files/Docs/<br />
<br />
* [[Sonarc]] lossless audio v2.1i software<br />
** mirror: https://multimedia.cx/mirror/snrc21i.zip<br />
** original: ftp://ftp.elf.stuba.sk/pub/pc/pack/snrc21i.zip<br />
<br />
* [[VC-1]] (a.k.a. VC-9) draft specification:<br />
** mirror: draft dated 2006-02-24: https://multimedia.cx/mirror/VC-1_Compressed_Video_Bitstream_Format_and_Decoding_Process.pdf<br />
** mirror: draft dated 2005-08-23: https://multimedia.cx/mirror/s421m.pdf<br />
** mirror: draft dated 2005-08-23: https://multimedia.cx/mirror/rp227.pdf<br />
** mirror: draft dated 2004-03-31: https://multimedia.cx/mirror/C24.008-VC9-Spec-CD1.pdf<br />
** reference source code mirror: https://multimedia.cx/mirror/VC1_reference_decoder_release6.zip</div>Multimedia Mikehttps://wiki.multimedia.cx/index.php?title=Mirrored_Files&diff=15624Mirrored Files2022-04-11T05:33:38Z<p>Multimedia Mike: upgrade all multimedia.cx links to https</p>
<hr />
<div>This is a list of official technical documents that are mirrored at multimedia.cx for convenience or archival: http://multimedia.cx/mirror/<br />
<br />
Contact [[User:Multimedia Mike|Multimedia Mike]] in order to add documents to the mirror.<br />
<br />
* [[A52]]:<br />
** 2018 Revision:<br />
*** mirror: https://multimedia.cx/mirror/A52-2018.pdf<br />
*** original: https://www.atsc.org/wp-content/uploads/2015/03/A52-2018.pdf<br />
** Revision B:<br />
*** mirror: https://multimedia.cx/mirror/a_52b.pdf<br />
*** original: [offline]<br />
<br />
* [[Apple Core Audio Format]] specification, dated 2006-03-08:<br />
** mirror: https://multimedia.cx/mirror/CAFSpec-2006-03-08.pdf<br />
** original: http://developer.apple.com/documentation/MusicAudio/Reference/CAFSpec/index.html<br />
<br />
* Apple [[QuickTime container]] specification, dated 2007-09-04:<br />
** mirror: https://multimedia.cx/mirror/qtff-2007-09-04.pdf<br />
** original: http://developer.apple.com/mac/library/documentation/QuickTime/QTFF<br />
<br />
* [[Audio Interchange File Format]]:<br />
** mirror: https://multimedia.cx/mirror/AudioIFF1_2_1.htm<br />
<br />
* [[Cinepak]]:<br />
** mirror: https://multimedia.cx/mirror/cinepak.txt<br />
** original: http://www.csse.monash.edu.au/%7etimf/videocodec/cinepak.txt<br />
<br />
* [[CYUV]]:<br />
** mirror: https://multimedia.cx/mirror/cyuv.txt<br />
** original: http://www.csse.monash.edu.au/~timf/videocodec/cyuv.txt<br />
<br />
* [[Dialogic IMA ADPCM]]:<br />
** mirror: https://multimedia.cx/mirror/dialogic-adpcm.pdf<br />
<br />
* [[DTS]]:<br />
** mirror (whitepaper): https://multimedia.cx/mirror/dts-whitepaper.pdf<br />
** mirror (document 1): https://multimedia.cx/mirror/dts1.pdf<br />
** mirror (document 2): https://multimedia.cx/mirror/dts2.pdf<br />
** mirror (DTS patent application, scans, 550 pages, 54 MB PDF): https://multimedia.cx/mirror/EP864146-53.pdf<br />
** mirror (DCA transform): https://multimedia.cx/mirror/dca-transform.pdf<br />
** Specification v1.4.1, 2012-09: https://multimedia.cx/mirror/ts_102114v010401p.pdf<br />
<br />
* [[H264]] draft specification, marked 2002 (E):<br />
** mirror: https://multimedia.cx/mirror/JVT-G050.pdf<br />
<br />
* [[IBM UltiMotion]] specification:<br />
** mirror: https://multimedia.cx/mirror/UMSPEC.ZIP<br />
<br />
* Id [[CIN]]:<br />
** mirror: https://multimedia.cx/mirror/idcin.html<br />
** original: http://www.csse.monash.edu.au/~timf/videocodec/idcin.html<br />
<br />
* Id [[RoQ]]:<br />
** mirror: https://multimedia.cx/mirror/idroq.txt<br />
** original: http://www.csse.monash.edu.au/~timf/videocodec/idroq.txt<br />
** sample decoder source code: https://multimedia.cx/mirror/idroq.tar.gz<br />
<br />
* [[Indeo 3]]:<br />
** mirror (partial specification): https://multimedia.cx/mirror/5386232.pdf<br />
** mirror (header explanation): https://multimedia.cx/mirror/indeo3.txt<br />
** original (header explanation): http://www.csse.monash.edu.au/~timf/videocodec/indeo3.txt<br />
<br />
* [[JPEG-LS]]<br />
** mirror: https://multimedia.cx/mirror/fcd14495p.pdf<br />
<br />
* [[Meridian Lossless Packing]] whitepaper:<br />
** mirror: https://multimedia.cx/mirror/mlp_jap_new.PDF<br />
** original: http://www.meridian-audio.com/w_paper/mlp_jap_new.PDF<br />
<br />
* [[Motion JPEG]] Documentation by Microsoft (1993):<br />
** mirror: https://multimedia.cx/mirror/msmjpg.txt<br />
<br />
* [[Nokia MVC]]:<br />
** documentation:<br />
*** original: http://ftp3.itu.ch/av-arch/video-site/0005_Osa/q15j19.doc<br />
*** mirror: https://multimedia.cx/mirror/q15j19.doc<br />
** reference codec:<br />
*** original: http://ftp3.itu.ch/av-arch/video-site/0005_Osa/q15j20.zip<br />
*** mirror: https://multimedia.cx/mirror/q15j20.zip<br />
<br />
* [[Nullsoft Video]]:<br />
** documentation:<br />
*** mirror: https://multimedia.cx/mirror/NSVFormat.rtf<br />
<br />
* [[On2 VP3]]:<br />
** Binary Downloads<br />
*** [https://multimedia.cx/mirror/vpvision/On2VP3VideoForWindows.exe On2 VP3 Video for Windows installer (1.2MB)]<br />
*** [https://multimedia.cx/mirror/vpvision/VpV05install.exe VPVision installer (4.6MB)]<br />
*** [https://multimedia.cx/mirror/vpvision/readme.txt readme.txt]<br />
*** [https://multimedia.cx/mirror/vpvision/readmefirst.txt readmefirst.txt]<br />
** Source Code Downloads<br />
*** [https://multimedia.cx/mirror/vpvision/source/vp32.tar.gz VP3.2 Codec source code (compressed TAR format, 1.1MB)]<br />
*** [https://multimedia.cx/mirror/vpvision/source/vpvision0.5_source.zip VPVision source code (ZIP archive, 5.2MB)]<br />
*** [https://multimedia.cx/mirror/vpvision/source/vorbis_nodebug_tc40_vp0.5rc.zip Vorbis (ZIP archive, 12.7MB)]<br />
*** [https://multimedia.cx/mirror/vpvision/source/readme.txt readme.txt]<br />
*** [https://multimedia.cx/mirror/vpvision/source/readmefirst.txt readmefirst.txt]<br />
<br />
* [[On2 VP6]]:<br />
** VP6 Bitstream & Decoding Specification<br />
*** mirror: https://multimedia.cx/mirror/vp6_format.pdf<br />
** whitepaper:<br />
*** mirror: https://multimedia.cx/mirror/vp6-white-paper.pdf<br />
*** original: http://www.on2.com/cms-data/pdf/1125607149174329.pdf<br />
<br />
* [[On2 VP7]]:<br />
** VP7 Data Format and Decoder<br />
*** mirror: https://multimedia.cx/mirror/VP7_Data_Format_and_Decoder_Overview.pdf<br />
** whitepaper:<br />
*** mirror: https://multimedia.cx/mirror/vp7-white-paper.pdf<br />
*** original: http://www.on2.com/cms-data/pdf/1123531744838491.pdf<br />
<br />
* [[PVA]] specification:<br />
** mirror: https://multimedia.cx/mirror/av_format_v1.pdf<br />
<br />
* [[RealAudio 14.4]]:<br />
** mirror: https://multimedia.cx/mirror/spra136.pdf<br />
** original: http://focus.ti.com/lit/an/spra136/spra136.pdf<br />
<br />
* [[RealVideo]] document assortment ([https://multimedia.cx/eggs/official-realvideo-specifications/ described in this blog post]):<br />
** mirror: https://multimedia.cx/mirror/realvideo/<br />
** original: https://rarvcode-video.helixcommunity.org/files/Docs/<br />
<br />
* [[Sonarc]] lossless audio v2.1i software<br />
** mirror: https://multimedia.cx/mirror/snrc21i.zip<br />
** original: ftp://ftp.elf.stuba.sk/pub/pc/pack/snrc21i.zip<br />
<br />
* [[VC-1]] (a.k.a. VC-9) draft specification:<br />
** mirror: draft dated 2006-02-24: https://multimedia.cx/mirror/VC-1_Compressed_Video_Bitstream_Format_and_Decoding_Process.pdf<br />
** mirror: draft dated 2005-08-23: https://multimedia.cx/mirror/s421m.pdf<br />
** mirror: draft dated 2005-08-23: https://multimedia.cx/mirror/rp227.pdf<br />
** mirror: draft dated 2004-03-31: https://multimedia.cx/mirror/C24.008-VC9-Spec-CD1.pdf<br />
** reference source code mirror: https://multimedia.cx/mirror/VC1_reference_decoder_release6.zip</div>Multimedia Mikehttps://wiki.multimedia.cx/index.php?title=LOCO&diff=15623LOCO2022-04-11T05:27:45Z<p>Multimedia Mike: link to mirrored file</p>
<hr />
<div>''This page is originally based on a description written by [[User:Kostya]].''<br />
<br />
* FourCC: LOCO<br />
* Samples: [http://samples.mplayerhq.hu/V-codecs/LOCO/ http://samples.mplayerhq.hu/V-codecs/LOCO/]<br />
<br />
LOCO codec written by Mohammad Rezaei and based on the [[JPEG-LS]] lossy/lossless compression scheme, originally known as LOCO-I.<br />
<br />
More information on LOCO-I can be found on: <br />
* [http://www.jpeg.org/public/fcd14495p.pdf FCD14495] ([[Mirrored Files|Mirrored]]) (JPEG-LS final comittee draft)<br />
* [http://www.hpl.hp.com/loco/ http://www.hpl.hp.com/loco/] (LOCO-I description)<br />
<br />
== Decoding Process ==<br />
# get predictor<br />
# decode residue<br />
# output predictor minus residue as new pixel<br />
<br />
== Prediction ==<br />
<br />
A pixel (X) can predict from up to 3 surrounding pixels: up (A), left (B), and up-left (C):<br />
<br />
+---+---+<br />
| C | A |<br />
+---+---+<br />
| B | X |<br />
+---+---+<br />
<br />
The prediction logic works as follows:<br />
* A,B,C are unavailable (X is top left pixel) - use 128 as prediction value<br />
* A and C are unavailable (X is in the top line) - use B as predictor<br />
* B and C are unavailable (X is in the first column) - use A as predictor<br />
* A,B,C are available (this one is the JPEG-LS prediction scheme):<br />
** if C >= max(A,B) then use min(A,B) as predictor<br />
** if C <= min(A,B) then use max(A,B) as predictor<br />
** else use (A+B-C) as predictor<br />
<br />
== Residue Decoding ==<br />
<br />
Residue decoding is based on Rice codes. There are some differences though:<br />
* Numbers are stored as their absolute value in Rice code and one trailing bit shows their sign - 0 for positive, 1 for negative integers<br />
* Rice parameter is not static but updates every time<br />
If there is lossy compression mode, then add loss value:<br />
if(val > 0)val += loss<br />
if(val < 0)val -= loss<br />
<br />
== Rice Code Decoding ==<br />
<br />
* Get standard Rice code with given parameter<br />
* It new code is zero<br />
** If we have some saved bits:<br />
*** Get Rice(2) code meaning run length of zeroes<br />
*** If run length is more than one then add (run_length + 1) bits to saved bit, else substract 3 from saved bits<br />
** Else increment decode_run_length<br />
* If new code is non-zero:<br />
** If decode_run_length > 2 then add it to saved bits, else substract 3 from saved bits<br />
** Set decode_run_length to zero<br />
* Return new code<br />
<br />
== Rice Code Parameter Updating ==<br />
<br />
Rice decoder choses its parameter based on two things - sum of absolute values of decoded residues and their number. To avoid overflow if count went up to sixteen then halve both count and sum.<br />
<br />
Rice parameter is log2(sum/number) clamped to interval [0..9]<br />
<br />
[[Category:Video Codecs]]<br />
[[Category:Video FourCCs]]</div>Multimedia Mikehttps://wiki.multimedia.cx/index.php?title=Mirrored_Files&diff=15622Mirrored Files2022-04-11T05:25:52Z<p>Multimedia Mike: mirror JPEG-LS PDF</p>
<hr />
<div>This is a list of official technical documents that are mirrored at multimedia.cx for convenience or archival: http://multimedia.cx/mirror/<br />
<br />
Contact [[User:Multimedia Mike|Multimedia Mike]] in order to add documents to the mirror.<br />
<br />
* [[A52]]:<br />
** 2018 Revision:<br />
*** mirror: https://multimedia.cx/mirror/A52-2018.pdf<br />
*** original: https://www.atsc.org/wp-content/uploads/2015/03/A52-2018.pdf<br />
** Revision B:<br />
*** mirror: http://multimedia.cx/mirror/a_52b.pdf<br />
*** original: [offline]<br />
<br />
* [[Apple Core Audio Format]] specification, dated 2006-03-08:<br />
** mirror: http://multimedia.cx/mirror/CAFSpec-2006-03-08.pdf<br />
** original: http://developer.apple.com/documentation/MusicAudio/Reference/CAFSpec/index.html<br />
<br />
* Apple [[QuickTime container]] specification, dated 2007-09-04:<br />
** mirror: http://multimedia.cx/mirror/qtff-2007-09-04.pdf<br />
** original: http://developer.apple.com/mac/library/documentation/QuickTime/QTFF<br />
<br />
* [[Audio Interchange File Format]]:<br />
** mirror: http://multimedia.cx/mirror/AudioIFF1_2_1.htm<br />
<br />
* [[Cinepak]]:<br />
** mirror: http://multimedia.cx/mirror/cinepak.txt<br />
** original: http://www.csse.monash.edu.au/%7etimf/videocodec/cinepak.txt<br />
<br />
* [[CYUV]]:<br />
** mirror: http://multimedia.cx/mirror/cyuv.txt<br />
** original: http://www.csse.monash.edu.au/~timf/videocodec/cyuv.txt<br />
<br />
* [[Dialogic IMA ADPCM]]:<br />
** mirror: http://multimedia.cx/mirror/dialogic-adpcm.pdf<br />
<br />
* [[DTS]]:<br />
** mirror (whitepaper): http://multimedia.cx/mirror/dts-whitepaper.pdf<br />
** mirror (document 1): http://multimedia.cx/mirror/dts1.pdf<br />
** mirror (document 2): http://multimedia.cx/mirror/dts2.pdf<br />
** mirror (DTS patent application, scans, 550 pages, 54 MB PDF): http://multimedia.cx/mirror/EP864146-53.pdf<br />
** mirror (DCA transform): http://multimedia.cx/mirror/dca-transform.pdf<br />
** Specification v1.4.1, 2012-09: http://multimedia.cx/mirror/ts_102114v010401p.pdf<br />
<br />
* [[H264]] draft specification, marked 2002 (E):<br />
** mirror: http://multimedia.cx/mirror/JVT-G050.pdf<br />
<br />
* [[IBM UltiMotion]] specification:<br />
** mirror: http://multimedia.cx/mirror/UMSPEC.ZIP<br />
<br />
* Id [[CIN]]:<br />
** mirror: http://multimedia.cx/mirror/idcin.html<br />
** original: http://www.csse.monash.edu.au/~timf/videocodec/idcin.html<br />
<br />
* Id [[RoQ]]:<br />
** mirror: http://multimedia.cx/mirror/idroq.txt<br />
** original: http://www.csse.monash.edu.au/~timf/videocodec/idroq.txt<br />
** sample decoder source code: http://multimedia.cx/mirror/idroq.tar.gz<br />
<br />
* [[Indeo 3]]:<br />
** mirror (partial specification): http://multimedia.cx/mirror/5386232.pdf<br />
** mirror (header explanation): http://multimedia.cx/mirror/indeo3.txt<br />
** original (header explanation): http://www.csse.monash.edu.au/~timf/videocodec/indeo3.txt<br />
<br />
* [[JPEG-LS]]<br />
** mirror: https://multimedia.cx/mirror/fcd14495p.pdf<br />
<br />
* [[Meridian Lossless Packing]] whitepaper:<br />
** mirror: http://multimedia.cx/mirror/mlp_jap_new.PDF<br />
** original: http://www.meridian-audio.com/w_paper/mlp_jap_new.PDF<br />
<br />
* [[Motion JPEG]] Documentation by Microsoft (1993):<br />
** mirror: https://multimedia.cx/mirror/msmjpg.txt<br />
<br />
* [[Nokia MVC]]:<br />
** documentation:<br />
*** original: http://ftp3.itu.ch/av-arch/video-site/0005_Osa/q15j19.doc<br />
*** mirror: http://multimedia.cx/mirror/q15j19.doc<br />
** reference codec:<br />
*** original: http://ftp3.itu.ch/av-arch/video-site/0005_Osa/q15j20.zip<br />
*** mirror: http://multimedia.cx/mirror/q15j20.zip<br />
<br />
* [[Nullsoft Video]]:<br />
** documentation:<br />
*** mirror: http://multimedia.cx/mirror/NSVFormat.rtf<br />
<br />
* [[On2 VP3]]:<br />
** Binary Downloads<br />
*** [http://multimedia.cx/mirror/vpvision/On2VP3VideoForWindows.exe On2 VP3 Video for Windows installer (1.2MB)]<br />
*** [http://multimedia.cx/mirror/vpvision/VpV05install.exe VPVision installer (4.6MB)]<br />
*** [http://multimedia.cx/mirror/vpvision/readme.txt readme.txt]<br />
*** [http://multimedia.cx/mirror/vpvision/readmefirst.txt readmefirst.txt]<br />
** Source Code Downloads<br />
*** [http://multimedia.cx/mirror/vpvision/source/vp32.tar.gz VP3.2 Codec source code (compressed TAR format, 1.1MB)]<br />
*** [http://multimedia.cx/mirror/vpvision/source/vpvision0.5_source.zip VPVision source code (ZIP archive, 5.2MB)]<br />
*** [http://multimedia.cx/mirror/vpvision/source/vorbis_nodebug_tc40_vp0.5rc.zip Vorbis (ZIP archive, 12.7MB)]<br />
*** [http://multimedia.cx/mirror/vpvision/source/readme.txt readme.txt]<br />
*** [http://multimedia.cx/mirror/vpvision/source/readmefirst.txt readmefirst.txt]<br />
<br />
* [[On2 VP6]]:<br />
** VP6 Bitstream & Decoding Specification<br />
*** mirror: http://multimedia.cx/mirror/vp6_format.pdf<br />
** whitepaper:<br />
*** mirror: http://multimedia.cx/mirror/vp6-white-paper.pdf<br />
*** original: http://www.on2.com/cms-data/pdf/1125607149174329.pdf<br />
<br />
* [[On2 VP7]]:<br />
** VP7 Data Format and Decoder<br />
*** mirror: http://multimedia.cx/mirror/VP7_Data_Format_and_Decoder_Overview.pdf<br />
** whitepaper:<br />
*** mirror: http://multimedia.cx/mirror/vp7-white-paper.pdf<br />
*** original: http://www.on2.com/cms-data/pdf/1123531744838491.pdf<br />
<br />
* [[PVA]] specification:<br />
** mirror: http://multimedia.cx/mirror/av_format_v1.pdf<br />
<br />
* [[RealAudio 14.4]]:<br />
** mirror: http://multimedia.cx/mirror/spra136.pdf<br />
** original: http://focus.ti.com/lit/an/spra136/spra136.pdf<br />
<br />
* [[RealVideo]] document assortment ([http://multimedia.cx/eggs/official-realvideo-specifications/ described in this blog post]):<br />
** mirror: http://multimedia.cx/mirror/realvideo/<br />
** original: https://rarvcode-video.helixcommunity.org/files/Docs/<br />
<br />
* [[Sonarc]] lossless audio v2.1i software<br />
** mirror: http://multimedia.cx/mirror/snrc21i.zip<br />
** original: ftp://ftp.elf.stuba.sk/pub/pc/pack/snrc21i.zip<br />
<br />
* [[VC-1]] (a.k.a. VC-9) draft specification:<br />
** mirror: draft dated 2006-02-24: http://multimedia.cx/mirror/VC-1_Compressed_Video_Bitstream_Format_and_Decoding_Process.pdf<br />
** mirror: draft dated 2005-08-23: http://multimedia.cx/mirror/s421m.pdf<br />
** mirror: draft dated 2005-08-23: http://multimedia.cx/mirror/rp227.pdf<br />
** mirror: draft dated 2004-03-31: http://multimedia.cx/mirror/C24.008-VC9-Spec-CD1.pdf<br />
** reference source code mirror: http://multimedia.cx/mirror/VC1_reference_decoder_release6.zip</div>Multimedia Mikehttps://wiki.multimedia.cx/index.php?title=VC-1&diff=15621VC-12022-04-11T05:17:25Z<p>Multimedia Mike: /* Official Information */ fix mirror link</p>
<hr />
<div>* FourCCs: WMV3, WMV9, WMVA, WVC1, WMVP, WVP2, WMVR<br />
* Company: [[Microsoft]]<br />
* Samples: <br />
** WMV9: http://samples.mplayerhq.hu/V-codecs/WMV9/<br />
** WMVA: http://samples.mplayerhq.hu/V-codecs/WMVA/<br />
** WMVP: http://samples.mplayerhq.hu/V-codecs/WMVP/<br />
** WVP2: http://samples.mplayerhq.hu/V-codecs/WVP2/<br />
** WVC1: http://samples.mplayerhq.hu/V-codecs/WVC1/<br />
** WMVB:<br />
** WMVR:<br />
* General Overview: http://www.microsoft.com/windows/windowsmedia/forpros/events/NAB2005/VC-1.aspx<br />
* Draft specification: http://multimedia.cx/mirror/C24.008-VC9-Spec-CD1.pdf<br />
<br />
VC-1 is a video coding standard developed by Microsoft. It began as Windows Media Video 9. It is prevalent in [[ASF]] files downloaded from the internet. It is also supposed to be used on [[HD-DVD]]s.<br />
<br />
'''See [[Understanding VC-1]] for more information about the technical details of the format.'''<br />
<br />
== Encapsulation ==<br />
Most commonly, VC-1 data is found inside of Microsoft [[ASF]] files and identified with the FourCC 'WMV3' for VC-1 simple and main profile and FourCC 'WVC1' for advanced profile. Note that the FourCC 'WMV9' may not actually exist in the wild but the acronym gained prominence anyway due to the fact that this video codec was introduced as part of the Windows Media 9 tool suite. VC-1 video will probably be encapsulated in other types of containers and stream formats such as [[MPEG]] for [[HD-DVD]] transport.<br />
<br />
== Profiles And Levels ==<br />
''This table is cribbed wholesale from http://www.microsoft.com/windows/windowsmedia/forpros/events/NAB2005/VC-1.aspx''<br />
<br />
VC-1 has 3 profiles: simple, main, and advanced. Each has various levels. The combinations of profiles and levels represent trade-offs between encoding/decoding complexity, compression quality, and compressed image size.<br />
<br />
{| class="wikitable" border="1" align="center" cellpadding="6" cellspacing="3" <br />
|- style="background:silver; color=black"<br />
! Profile !! Level !! Maximum Bit Rate !! Representative Resolutions by Frame Rate (Format)<br />
|-<br />
|Simple<br />
|Low<br />
|96 kilobits per second (Kbps)<br />
|176 x 144 @ 15 Hz ([[QCIF]])<br />
|-<br />
|<br />
|Medium<br />
|384 Kbps<br />
|240 x 176 @ 30 Hz<br>352 x 288 @ 15 Hz ([[CIF]])<br />
|-<br />
|Main<br />
|Low<br />
|2 megabits per second (Mbps)<br />
|320 x 240 @ 24 Hz ([[QVGA]])<br />
|-<br />
|<br />
|Medium<br />
|10 Mbps<br />
|720 x 480 @ 30 Hz (480p)<br>720 x 576 @ 25 Hz (576p)<br />
|-<br />
|<br />
|High<br />
|20 Mbps<br />
|1920 x 1080 @ 30 Hz (1080p)<br />
|-<br />
|Advanced<br />
|L0<br />
|2 Mbps<br />
|352 x 288 @ 30 Hz (CIF)<br />
|-<br />
|<br />
|L1<br />
|10 Mbps<br />
|720 x 480 @ 30 Hz (NTSC-SD)<br>720 x 576 @ 25 Hz (PAL-SD)<br />
|-<br />
|<br />
|L2<br />
|20 Mbps<br />
|720 x 480 @ 60 Hz (480p)<br>1280 x 720 @ 30 Hz (720p)<br />
|-<br />
|<br />
|L3<br />
|45 Mbps<br />
|1920 x 1080 @ 24 Hz (1080p)<br>1920 x 1080 @ 30 Hz (1080i)<br>1280 x 720 @ 60 Hz (720p)<br />
|-<br />
|<br />
|L4<br />
|135 Mbps<br />
|1920 x 1080 @ 60 Hz (1080p)<br>2048 x 1536 @ 24 Hz<br />
|}<br />
<br />
== Coding Concepts ==<br />
<br />
=== Colorspace ===<br />
VC-1 codes a sequence of images in the [[YUV 4:2:0]] colorspace.<br />
<br />
=== Macroblocks, Blocks, and Sub-blocks ===<br />
When VC-1 codes an image, it divides the image into [[Macroblock|macroblocks]]. Each 16x16 macroblock is comprised of 6 8x8 sample blocks (4 Y blocks, 1 U block, and 1 V block). Further, the coding method may divide an individual 8x8 block into 2 8x4 blocks, 2 4x8 blocks, or 4 4x4 blocks.<br />
<br />
=== Transform Coding ===<br />
VC-1 uses a variation of the [[Discrete Cosine Transform]] to convert blocks of samples into a transform domain to facilitate more efficient coding. The transform may operate on the full 8x8 block or any of the 3 supported sub-block sizes (8x4, 4x8, or 4x4). Unlike many codec standards preceding VC-1, the specification defines a bit-accurate transform method that all implementations are expected to conform to so as to minimize transform error.<br />
<br />
=== Zigzag ===<br />
After tranforming sample data into the transform domain, VC-1 reorders the transformed data in a [[Zigzag Reordering|zigzag]] pattern which makes certain successive coding techniques more effective. VC-1 has 13 different zigzag patterns depending on various parameters (block size, interlacing, prediction mode and intra/inter).<br />
<br />
=== Quantization ===<br />
[[Quantization]] is the compression step that potentially loses the most information in a lossy compression scheme such as VC-1. This codec (unlike many others) defines a direct way to scale DC/AC coefficients using quantization parameter instead of specifying quantization matrixes.<br />
<br />
Quantizer may differ between macroblocks in several ways - all macroblocks may have different quantizers, edge macroblocks only, two adjacent edges macroblocks,<br />
macroblocks from one edge or all macroblocks may have the same quantizer. For cases 2-4 there is second quantizer for selected edge macroblocks, for the first case difference value between main and real quantizer is stored.<br />
<br />
=== Bitplane Coding ===<br />
VC-1 uses a number of bitplanes which are simply maps of ones and zeros that specify properties for the macroblocks in an image. For example, a particular bitplane codes information about which macroblocks are not coded in a frame. These bitplanes are coded into the final bitstream using a number of methods:<br />
* raw (data from bitplane is actually stored in macroblock header)<br />
* rowskip/colskip (each row or column are either zero - '0' bit is sent or coded - '1' bit and raw data bits are sent)<br />
* tiling (bitplane is split into 2x3 or 3x2 blocks, each block is coded with own codeword, remainder is coded with rowskip and colskip method)<br />
Bitplane may be coded in inverted mode which is signalled by additional bit before bitplane data.<br />
<br />
=== Motion Compensation ===<br />
VC-1 uses half-pel and quarter-pel interframe [[Motion Compensation|motion compensation]] with either bilinear (like in [[H.264|H.264]]) or bicubic (extended version of motion compensation employed in [[WMV2|Windows Media 2]]) interpolation.<br />
<br />
=== Huffman Coding ===<br />
All essential data in frames (like motion vectors, block coefficients) is stored using static Huffman codes. Usually there are several sets of codes for each data type (motion vectors, block coefficients) and one set is used throughout whole frame. The set index is usually defined in frame header or derived from some parameters (like quantization or is frame intra/inter). Many of those codesets are inherited from MS [[MPEG-4|MPEG-4]] variants.<br />
<br />
=== Intensity Compensation ===<br />
Intensity Compensation is special mode when reference frame luma and chroma data are scaled before using it in motion compensation.<br />
<br />
=== Range Reduction ===<br />
This is special mode when both luma and chroma data range (0..255) is scaled down twice to 64..192 (with center = 128), so it needs to be expanded back before displaying (and using for prediction in simple and main profiles).<br />
<br />
=== Overlap Transform ===<br />
For blocks with big quantization value overlap transform may be performed. This is done by smoothing borders of adjacent blocks.<br />
<br />
== Bitstream Packing ==<br />
VC-1 bitstreams are packed as bits into bytes in left -> right order:<br />
<br />
byte 0 byte 1 byte 2 byte 3 byte 4 ....<br />
<br />
byte 0 byte 1<br />
abcdefgh ijklmnop<br />
<br />
Given the preceding bytestream/bitstream, a get_bit() operation to retrieve the next bit in the stream would return bit a. A get_bits(5) operation to request the next 5 bits would return 'bcdef'. The next get_bits(4) operation would return 'ghij'.<br />
<br />
== Setup Data / Sequence Layer ==<br />
When VC-1 data is encapsulated inside of an [[ASF]] file it will be accompanied with setup data attached as the extradata of a [[BITMAPINFOHEADER]] data structure. In VC-1 parlance, this data is called the sequence layer. The format of this data is as follows:<br />
<br />
* 2 bits: profile (0 - simple, 1 - main, 2 - complex, 3 - advanced). Complex profile is not covered by VC-1 standard and may occur in old WMV3 files where it was called "advanced profile".<br />
* if profile is simple or main (0 or 1, respectively)<br />
** 2 bits: reserved, should be 0<br />
* if profile is advanced (3)<br />
** 3 bits: level of advanced profile (values 5-7 are invalid)<br />
** 2 bits: chroma format (note that only format 1, [[YUV 4:2:0]] is defined; other values are invalid)<br />
* 3 bits: Q frame rate for post processing; unused<br />
* 5 bits: Q bit rate for post proc; unused<br />
* if profile is simple or main<br />
** 1 bit: loop filter flag<br />
** 1 bit: reserved, should be 0 (looks like special coding mode known as J-frames in WMV2)<br />
** 1 bit: multiresolution coding flag<br />
** 1 bit: reserved, should be 1<br />
** 1 bit: fast U/V motion compensation (note: must be 1 in simple profile) - hints if decoder should round chroma motion values to halves<br />
** 1 bit: extended motion vectors (note: must be 0 in simple profile)<br />
** 2 bits: macroblock dequantization mode<br />
** 1 bit: variable sized transform (i.e. allow 8x4, 4x8 and 4x4 blocks)<br />
** 1 bit: reserved, should be 0 (possibly means if codeset for decoding AC coefficient is specified explicitly)<br />
** 1 bit: overlapped transform flag<br />
** 1 bit: sync marker flag<br />
** 1 bit: range reduction flag<br />
** 3 bits: maximum number of consecutive B frames<br />
** 2 bits: quantizer mode<br />
** 1 bit: 'finterp' flag in present in frame header<br />
** 1 bit: 'release-to-manufacturer' flag - if set to 0 means old WMV3 encoding with different bitstream format for P/B frames (yet unfigured)<br />
* if profile is advanced<br />
** 1 bit: post processing flag<br />
** 12 bits: max coded width (actual width = (width + 1) * 2)<br />
** 12 bits: max coded height (actual height = (height + 1) * 2)<br />
** 1 bit: pulldown flag<br />
** 1 bit: interlaced<br />
** 1 bit: frame counter flag<br />
* 1 bit: frame interpolation flag<br />
* if profile is advanced<br />
** '''(UNFINISHED: lots more stuff to be filled in when advanced profile is needed)'''<br />
* if profile is simple or main<br />
** 1 bit: reserved, should be 1<br />
<br />
In the case of simple or main profile data encapsulated in a general container format, the max coded width and height parameters will come from the container format rather than being encoded in the sequence layer. Observe that the total number of bits that comprise the sequence layer for simple or main profile data is 32 which, incidentally, ought to be the size of the extradata transmitted from the ASF container to a VC-1 decoder.<br />
<br />
== High Level Decoding Algorithm ==<br />
For each encoded frame:<br />
* unpack the frame information such as quantization parameters, bitplanes, and tables<br />
* for each field<br />
** unpack each macroblock<br />
** for each macroblock<br />
*** perform motion compensation if needed<br />
*** determine blocks coding mode (which block is intra and is coded or not)<br />
*** for each block<br />
**** if block is intra or coded then decode it else proceed to the next block<br />
**** do inverse transform and in some case add 128 to every sample value<br />
**** do overlapping if needed<br />
**** do postprocessing if requested<br />
<br />
=== Decoding Motion Vector ===<br />
Each motion vector is stored in form F*36+LY*6+LX where F - flag which signalizes that macroblock is coded, LX and LY are coded sign and lengths of dX and dY values.<br />
<br />
=== Decoding Intra Block ===<br />
Overall decoding process:<br />
* predict DC value<br />
* read and apply delta value<br />
* if block has AC coeffs<br />
** select dezigzag matrix<br />
** while it is not the last coefficient<br />
*** decode AC coefficient information<br />
*** put AC coefficient into designated place in block<br />
* if specified do AC prediction basing on predicted DC direction<br />
* unquantize all coefficients<br />
<br />
=== Decoding Inter Block ===<br />
Inter block is composed from AC coefficients starting from top left corner. The only catch that it could be divided into subblocks which need to be decoded separately.<br />
<br />
=== Decoding AC Coefficient ===<br />
AC coefficient is coded by special value which decomposes into number of zeroes before coefficient, coefficient value and if this is the last non-zero coefficient. All information needed to decode them is contained in special tables.<br />
<br />
=== AC Prediction ===<br />
AC prediction is simply adding seven AC coefficient values from first row of block above or first column of block left of the current one to the corresponding coefficients of the destination block. Source block is the same which DC value was used for prediction.<br />
This process is performed only when the special bit is set.<br />
<br />
== Official Information ==<br />
This Wiki aims to provide a complete, independent, and understandable description of the VC-1 format. Until such time, here are some external references on the format.<br />
* Old specs can be found here: http://jovian.com/files/C24.008-VC9-Spec-CD1.pdf<br />
* VC-1 Compressed Video Bitstream Format and Decoding Process http://www.smpte.org/smpte_store/standards/pdf/s421m.pdf ([[Mirrored Files]])<br />
* VC-1 Bitstream Transport Encodings (specs for placing VC-1 in MPEG-2 Program and Transport streams) http://www.smpte.org/smpte_store/standards/pdf/rp227.pdf ([[Mirrored Files]])<br />
* VC-1 Decoder and Bitstream Conformance [http://www.smpte.org/smpte_store/standards/pdf/rp228.pdf http://www.smpte.org/smpte_store/standards/pdf/rp228.pdf]<br />
* Googling for VC1_reference_decoder_release6.zip might turn up sources for the reference decoder.<br />
<br />
== WMVP differences from WMV3 ==<br />
<br />
WMVP is essentially a slide show containing source material and transform information.<br />
<br />
Source material is stored like sprite which is transformed and cropped afterwards (sprite dimensions are usually bigger than output).<br />
Sprite properties are stored in sequence header instead of <code>RES_RTM</code> flag:<br />
<br />
sprite width - 11 bits<br />
sprite height - 11 bits<br />
frame rate - 5 bits<br />
X8 presence - 1 bit<br />
skip DC/AC tables - 1 bit<br />
slice code - 3 bits<br />
<br />
Frames are preceded by two bits with undiscovered meaning.<br />
I-frames contain sprites and transform coefficients in 15.15 fixed point format, P-frames contain only transform coefficients.<br />
<br />
[[Category:Video Codecs]]</div>Multimedia Mikehttps://wiki.multimedia.cx/index.php?title=VC-1&diff=15620VC-12022-04-11T05:15:58Z<p>Multimedia Mike: /* Official Information */ link to mirrored documents</p>
<hr />
<div>* FourCCs: WMV3, WMV9, WMVA, WVC1, WMVP, WVP2, WMVR<br />
* Company: [[Microsoft]]<br />
* Samples: <br />
** WMV9: http://samples.mplayerhq.hu/V-codecs/WMV9/<br />
** WMVA: http://samples.mplayerhq.hu/V-codecs/WMVA/<br />
** WMVP: http://samples.mplayerhq.hu/V-codecs/WMVP/<br />
** WVP2: http://samples.mplayerhq.hu/V-codecs/WVP2/<br />
** WVC1: http://samples.mplayerhq.hu/V-codecs/WVC1/<br />
** WMVB:<br />
** WMVR:<br />
* General Overview: http://www.microsoft.com/windows/windowsmedia/forpros/events/NAB2005/VC-1.aspx<br />
* Draft specification: http://multimedia.cx/mirror/C24.008-VC9-Spec-CD1.pdf<br />
<br />
VC-1 is a video coding standard developed by Microsoft. It began as Windows Media Video 9. It is prevalent in [[ASF]] files downloaded from the internet. It is also supposed to be used on [[HD-DVD]]s.<br />
<br />
'''See [[Understanding VC-1]] for more information about the technical details of the format.'''<br />
<br />
== Encapsulation ==<br />
Most commonly, VC-1 data is found inside of Microsoft [[ASF]] files and identified with the FourCC 'WMV3' for VC-1 simple and main profile and FourCC 'WVC1' for advanced profile. Note that the FourCC 'WMV9' may not actually exist in the wild but the acronym gained prominence anyway due to the fact that this video codec was introduced as part of the Windows Media 9 tool suite. VC-1 video will probably be encapsulated in other types of containers and stream formats such as [[MPEG]] for [[HD-DVD]] transport.<br />
<br />
== Profiles And Levels ==<br />
''This table is cribbed wholesale from http://www.microsoft.com/windows/windowsmedia/forpros/events/NAB2005/VC-1.aspx''<br />
<br />
VC-1 has 3 profiles: simple, main, and advanced. Each has various levels. The combinations of profiles and levels represent trade-offs between encoding/decoding complexity, compression quality, and compressed image size.<br />
<br />
{| class="wikitable" border="1" align="center" cellpadding="6" cellspacing="3" <br />
|- style="background:silver; color=black"<br />
! Profile !! Level !! Maximum Bit Rate !! Representative Resolutions by Frame Rate (Format)<br />
|-<br />
|Simple<br />
|Low<br />
|96 kilobits per second (Kbps)<br />
|176 x 144 @ 15 Hz ([[QCIF]])<br />
|-<br />
|<br />
|Medium<br />
|384 Kbps<br />
|240 x 176 @ 30 Hz<br>352 x 288 @ 15 Hz ([[CIF]])<br />
|-<br />
|Main<br />
|Low<br />
|2 megabits per second (Mbps)<br />
|320 x 240 @ 24 Hz ([[QVGA]])<br />
|-<br />
|<br />
|Medium<br />
|10 Mbps<br />
|720 x 480 @ 30 Hz (480p)<br>720 x 576 @ 25 Hz (576p)<br />
|-<br />
|<br />
|High<br />
|20 Mbps<br />
|1920 x 1080 @ 30 Hz (1080p)<br />
|-<br />
|Advanced<br />
|L0<br />
|2 Mbps<br />
|352 x 288 @ 30 Hz (CIF)<br />
|-<br />
|<br />
|L1<br />
|10 Mbps<br />
|720 x 480 @ 30 Hz (NTSC-SD)<br>720 x 576 @ 25 Hz (PAL-SD)<br />
|-<br />
|<br />
|L2<br />
|20 Mbps<br />
|720 x 480 @ 60 Hz (480p)<br>1280 x 720 @ 30 Hz (720p)<br />
|-<br />
|<br />
|L3<br />
|45 Mbps<br />
|1920 x 1080 @ 24 Hz (1080p)<br>1920 x 1080 @ 30 Hz (1080i)<br>1280 x 720 @ 60 Hz (720p)<br />
|-<br />
|<br />
|L4<br />
|135 Mbps<br />
|1920 x 1080 @ 60 Hz (1080p)<br>2048 x 1536 @ 24 Hz<br />
|}<br />
<br />
== Coding Concepts ==<br />
<br />
=== Colorspace ===<br />
VC-1 codes a sequence of images in the [[YUV 4:2:0]] colorspace.<br />
<br />
=== Macroblocks, Blocks, and Sub-blocks ===<br />
When VC-1 codes an image, it divides the image into [[Macroblock|macroblocks]]. Each 16x16 macroblock is comprised of 6 8x8 sample blocks (4 Y blocks, 1 U block, and 1 V block). Further, the coding method may divide an individual 8x8 block into 2 8x4 blocks, 2 4x8 blocks, or 4 4x4 blocks.<br />
<br />
=== Transform Coding ===<br />
VC-1 uses a variation of the [[Discrete Cosine Transform]] to convert blocks of samples into a transform domain to facilitate more efficient coding. The transform may operate on the full 8x8 block or any of the 3 supported sub-block sizes (8x4, 4x8, or 4x4). Unlike many codec standards preceding VC-1, the specification defines a bit-accurate transform method that all implementations are expected to conform to so as to minimize transform error.<br />
<br />
=== Zigzag ===<br />
After tranforming sample data into the transform domain, VC-1 reorders the transformed data in a [[Zigzag Reordering|zigzag]] pattern which makes certain successive coding techniques more effective. VC-1 has 13 different zigzag patterns depending on various parameters (block size, interlacing, prediction mode and intra/inter).<br />
<br />
=== Quantization ===<br />
[[Quantization]] is the compression step that potentially loses the most information in a lossy compression scheme such as VC-1. This codec (unlike many others) defines a direct way to scale DC/AC coefficients using quantization parameter instead of specifying quantization matrixes.<br />
<br />
Quantizer may differ between macroblocks in several ways - all macroblocks may have different quantizers, edge macroblocks only, two adjacent edges macroblocks,<br />
macroblocks from one edge or all macroblocks may have the same quantizer. For cases 2-4 there is second quantizer for selected edge macroblocks, for the first case difference value between main and real quantizer is stored.<br />
<br />
=== Bitplane Coding ===<br />
VC-1 uses a number of bitplanes which are simply maps of ones and zeros that specify properties for the macroblocks in an image. For example, a particular bitplane codes information about which macroblocks are not coded in a frame. These bitplanes are coded into the final bitstream using a number of methods:<br />
* raw (data from bitplane is actually stored in macroblock header)<br />
* rowskip/colskip (each row or column are either zero - '0' bit is sent or coded - '1' bit and raw data bits are sent)<br />
* tiling (bitplane is split into 2x3 or 3x2 blocks, each block is coded with own codeword, remainder is coded with rowskip and colskip method)<br />
Bitplane may be coded in inverted mode which is signalled by additional bit before bitplane data.<br />
<br />
=== Motion Compensation ===<br />
VC-1 uses half-pel and quarter-pel interframe [[Motion Compensation|motion compensation]] with either bilinear (like in [[H.264|H.264]]) or bicubic (extended version of motion compensation employed in [[WMV2|Windows Media 2]]) interpolation.<br />
<br />
=== Huffman Coding ===<br />
All essential data in frames (like motion vectors, block coefficients) is stored using static Huffman codes. Usually there are several sets of codes for each data type (motion vectors, block coefficients) and one set is used throughout whole frame. The set index is usually defined in frame header or derived from some parameters (like quantization or is frame intra/inter). Many of those codesets are inherited from MS [[MPEG-4|MPEG-4]] variants.<br />
<br />
=== Intensity Compensation ===<br />
Intensity Compensation is special mode when reference frame luma and chroma data are scaled before using it in motion compensation.<br />
<br />
=== Range Reduction ===<br />
This is special mode when both luma and chroma data range (0..255) is scaled down twice to 64..192 (with center = 128), so it needs to be expanded back before displaying (and using for prediction in simple and main profiles).<br />
<br />
=== Overlap Transform ===<br />
For blocks with big quantization value overlap transform may be performed. This is done by smoothing borders of adjacent blocks.<br />
<br />
== Bitstream Packing ==<br />
VC-1 bitstreams are packed as bits into bytes in left -> right order:<br />
<br />
byte 0 byte 1 byte 2 byte 3 byte 4 ....<br />
<br />
byte 0 byte 1<br />
abcdefgh ijklmnop<br />
<br />
Given the preceding bytestream/bitstream, a get_bit() operation to retrieve the next bit in the stream would return bit a. A get_bits(5) operation to request the next 5 bits would return 'bcdef'. The next get_bits(4) operation would return 'ghij'.<br />
<br />
== Setup Data / Sequence Layer ==<br />
When VC-1 data is encapsulated inside of an [[ASF]] file it will be accompanied with setup data attached as the extradata of a [[BITMAPINFOHEADER]] data structure. In VC-1 parlance, this data is called the sequence layer. The format of this data is as follows:<br />
<br />
* 2 bits: profile (0 - simple, 1 - main, 2 - complex, 3 - advanced). Complex profile is not covered by VC-1 standard and may occur in old WMV3 files where it was called "advanced profile".<br />
* if profile is simple or main (0 or 1, respectively)<br />
** 2 bits: reserved, should be 0<br />
* if profile is advanced (3)<br />
** 3 bits: level of advanced profile (values 5-7 are invalid)<br />
** 2 bits: chroma format (note that only format 1, [[YUV 4:2:0]] is defined; other values are invalid)<br />
* 3 bits: Q frame rate for post processing; unused<br />
* 5 bits: Q bit rate for post proc; unused<br />
* if profile is simple or main<br />
** 1 bit: loop filter flag<br />
** 1 bit: reserved, should be 0 (looks like special coding mode known as J-frames in WMV2)<br />
** 1 bit: multiresolution coding flag<br />
** 1 bit: reserved, should be 1<br />
** 1 bit: fast U/V motion compensation (note: must be 1 in simple profile) - hints if decoder should round chroma motion values to halves<br />
** 1 bit: extended motion vectors (note: must be 0 in simple profile)<br />
** 2 bits: macroblock dequantization mode<br />
** 1 bit: variable sized transform (i.e. allow 8x4, 4x8 and 4x4 blocks)<br />
** 1 bit: reserved, should be 0 (possibly means if codeset for decoding AC coefficient is specified explicitly)<br />
** 1 bit: overlapped transform flag<br />
** 1 bit: sync marker flag<br />
** 1 bit: range reduction flag<br />
** 3 bits: maximum number of consecutive B frames<br />
** 2 bits: quantizer mode<br />
** 1 bit: 'finterp' flag in present in frame header<br />
** 1 bit: 'release-to-manufacturer' flag - if set to 0 means old WMV3 encoding with different bitstream format for P/B frames (yet unfigured)<br />
* if profile is advanced<br />
** 1 bit: post processing flag<br />
** 12 bits: max coded width (actual width = (width + 1) * 2)<br />
** 12 bits: max coded height (actual height = (height + 1) * 2)<br />
** 1 bit: pulldown flag<br />
** 1 bit: interlaced<br />
** 1 bit: frame counter flag<br />
* 1 bit: frame interpolation flag<br />
* if profile is advanced<br />
** '''(UNFINISHED: lots more stuff to be filled in when advanced profile is needed)'''<br />
* if profile is simple or main<br />
** 1 bit: reserved, should be 1<br />
<br />
In the case of simple or main profile data encapsulated in a general container format, the max coded width and height parameters will come from the container format rather than being encoded in the sequence layer. Observe that the total number of bits that comprise the sequence layer for simple or main profile data is 32 which, incidentally, ought to be the size of the extradata transmitted from the ASF container to a VC-1 decoder.<br />
<br />
== High Level Decoding Algorithm ==<br />
For each encoded frame:<br />
* unpack the frame information such as quantization parameters, bitplanes, and tables<br />
* for each field<br />
** unpack each macroblock<br />
** for each macroblock<br />
*** perform motion compensation if needed<br />
*** determine blocks coding mode (which block is intra and is coded or not)<br />
*** for each block<br />
**** if block is intra or coded then decode it else proceed to the next block<br />
**** do inverse transform and in some case add 128 to every sample value<br />
**** do overlapping if needed<br />
**** do postprocessing if requested<br />
<br />
=== Decoding Motion Vector ===<br />
Each motion vector is stored in form F*36+LY*6+LX where F - flag which signalizes that macroblock is coded, LX and LY are coded sign and lengths of dX and dY values.<br />
<br />
=== Decoding Intra Block ===<br />
Overall decoding process:<br />
* predict DC value<br />
* read and apply delta value<br />
* if block has AC coeffs<br />
** select dezigzag matrix<br />
** while it is not the last coefficient<br />
*** decode AC coefficient information<br />
*** put AC coefficient into designated place in block<br />
* if specified do AC prediction basing on predicted DC direction<br />
* unquantize all coefficients<br />
<br />
=== Decoding Inter Block ===<br />
Inter block is composed from AC coefficients starting from top left corner. The only catch that it could be divided into subblocks which need to be decoded separately.<br />
<br />
=== Decoding AC Coefficient ===<br />
AC coefficient is coded by special value which decomposes into number of zeroes before coefficient, coefficient value and if this is the last non-zero coefficient. All information needed to decode them is contained in special tables.<br />
<br />
=== AC Prediction ===<br />
AC prediction is simply adding seven AC coefficient values from first row of block above or first column of block left of the current one to the corresponding coefficients of the destination block. Source block is the same which DC value was used for prediction.<br />
This process is performed only when the special bit is set.<br />
<br />
== Official Information ==<br />
This Wiki aims to provide a complete, independent, and understandable description of the VC-1 format. Until such time, here are some external references on the format.<br />
* Old specs can be found here: http://jovian.com/files/C24.008-VC9-Spec-CD1.pdf<br />
* VC-1 Compressed Video Bitstream Format and Decoding Process http://www.smpte.org/smpte_store/standards/pdf/s421m.pdf ([[Mirrored]])<br />
* VC-1 Bitstream Transport Encodings (specs for placing VC-1 in MPEG-2 Program and Transport streams) http://www.smpte.org/smpte_store/standards/pdf/rp227.pdf ([[Mirrored]])<br />
* VC-1 Decoder and Bitstream Conformance [http://www.smpte.org/smpte_store/standards/pdf/rp228.pdf http://www.smpte.org/smpte_store/standards/pdf/rp228.pdf]<br />
* Googling for VC1_reference_decoder_release6.zip might turn up sources for the reference decoder.<br />
<br />
== WMVP differences from WMV3 ==<br />
<br />
WMVP is essentially a slide show containing source material and transform information.<br />
<br />
Source material is stored like sprite which is transformed and cropped afterwards (sprite dimensions are usually bigger than output).<br />
Sprite properties are stored in sequence header instead of <code>RES_RTM</code> flag:<br />
<br />
sprite width - 11 bits<br />
sprite height - 11 bits<br />
frame rate - 5 bits<br />
X8 presence - 1 bit<br />
skip DC/AC tables - 1 bit<br />
slice code - 3 bits<br />
<br />
Frames are preceded by two bits with undiscovered meaning.<br />
I-frames contain sprites and transform coefficients in 15.15 fixed point format, P-frames contain only transform coefficients.<br />
<br />
[[Category:Video Codecs]]</div>Multimedia Mikehttps://wiki.multimedia.cx/index.php?title=Mirrored_Files&diff=15619Mirrored Files2022-04-11T05:15:42Z<p>Multimedia Mike: mirror rp227.pdf</p>
<hr />
<div>This is a list of official technical documents that are mirrored at multimedia.cx for convenience or archival: http://multimedia.cx/mirror/<br />
<br />
Contact [[User:Multimedia Mike|Multimedia Mike]] in order to add documents to the mirror.<br />
<br />
* [[A52]]:<br />
** 2018 Revision:<br />
*** mirror: https://multimedia.cx/mirror/A52-2018.pdf<br />
*** original: https://www.atsc.org/wp-content/uploads/2015/03/A52-2018.pdf<br />
** Revision B:<br />
*** mirror: http://multimedia.cx/mirror/a_52b.pdf<br />
*** original: [offline]<br />
<br />
* [[Apple Core Audio Format]] specification, dated 2006-03-08:<br />
** mirror: http://multimedia.cx/mirror/CAFSpec-2006-03-08.pdf<br />
** original: http://developer.apple.com/documentation/MusicAudio/Reference/CAFSpec/index.html<br />
<br />
* Apple [[QuickTime container]] specification, dated 2007-09-04:<br />
** mirror: http://multimedia.cx/mirror/qtff-2007-09-04.pdf<br />
** original: http://developer.apple.com/mac/library/documentation/QuickTime/QTFF<br />
<br />
* [[Audio Interchange File Format]]:<br />
** mirror: http://multimedia.cx/mirror/AudioIFF1_2_1.htm<br />
<br />
* [[Cinepak]]:<br />
** mirror: http://multimedia.cx/mirror/cinepak.txt<br />
** original: http://www.csse.monash.edu.au/%7etimf/videocodec/cinepak.txt<br />
<br />
* [[CYUV]]:<br />
** mirror: http://multimedia.cx/mirror/cyuv.txt<br />
** original: http://www.csse.monash.edu.au/~timf/videocodec/cyuv.txt<br />
<br />
* [[Dialogic IMA ADPCM]]:<br />
** mirror: http://multimedia.cx/mirror/dialogic-adpcm.pdf<br />
<br />
* [[DTS]]:<br />
** mirror (whitepaper): http://multimedia.cx/mirror/dts-whitepaper.pdf<br />
** mirror (document 1): http://multimedia.cx/mirror/dts1.pdf<br />
** mirror (document 2): http://multimedia.cx/mirror/dts2.pdf<br />
** mirror (DTS patent application, scans, 550 pages, 54 MB PDF): http://multimedia.cx/mirror/EP864146-53.pdf<br />
** mirror (DCA transform): http://multimedia.cx/mirror/dca-transform.pdf<br />
** Specification v1.4.1, 2012-09: http://multimedia.cx/mirror/ts_102114v010401p.pdf<br />
<br />
* [[H264]] draft specification, marked 2002 (E):<br />
** mirror: http://multimedia.cx/mirror/JVT-G050.pdf<br />
<br />
* [[IBM UltiMotion]] specification:<br />
** mirror: http://multimedia.cx/mirror/UMSPEC.ZIP<br />
<br />
* Id [[CIN]]:<br />
** mirror: http://multimedia.cx/mirror/idcin.html<br />
** original: http://www.csse.monash.edu.au/~timf/videocodec/idcin.html<br />
<br />
* Id [[RoQ]]:<br />
** mirror: http://multimedia.cx/mirror/idroq.txt<br />
** original: http://www.csse.monash.edu.au/~timf/videocodec/idroq.txt<br />
** sample decoder source code: http://multimedia.cx/mirror/idroq.tar.gz<br />
<br />
* [[Indeo 3]]:<br />
** mirror (partial specification): http://multimedia.cx/mirror/5386232.pdf<br />
** mirror (header explanation): http://multimedia.cx/mirror/indeo3.txt<br />
** original (header explanation): http://www.csse.monash.edu.au/~timf/videocodec/indeo3.txt<br />
<br />
* [[Meridian Lossless Packing]] whitepaper:<br />
** mirror: http://multimedia.cx/mirror/mlp_jap_new.PDF<br />
** original: http://www.meridian-audio.com/w_paper/mlp_jap_new.PDF<br />
<br />
* [[Motion JPEG]] Documentation by Microsoft (1993):<br />
** mirror: https://multimedia.cx/mirror/msmjpg.txt<br />
<br />
* [[Nokia MVC]]:<br />
** documentation:<br />
*** original: http://ftp3.itu.ch/av-arch/video-site/0005_Osa/q15j19.doc<br />
*** mirror: http://multimedia.cx/mirror/q15j19.doc<br />
** reference codec:<br />
*** original: http://ftp3.itu.ch/av-arch/video-site/0005_Osa/q15j20.zip<br />
*** mirror: http://multimedia.cx/mirror/q15j20.zip<br />
<br />
* [[Nullsoft Video]]:<br />
** documentation:<br />
*** mirror: http://multimedia.cx/mirror/NSVFormat.rtf<br />
<br />
* [[On2 VP3]]:<br />
** Binary Downloads<br />
*** [http://multimedia.cx/mirror/vpvision/On2VP3VideoForWindows.exe On2 VP3 Video for Windows installer (1.2MB)]<br />
*** [http://multimedia.cx/mirror/vpvision/VpV05install.exe VPVision installer (4.6MB)]<br />
*** [http://multimedia.cx/mirror/vpvision/readme.txt readme.txt]<br />
*** [http://multimedia.cx/mirror/vpvision/readmefirst.txt readmefirst.txt]<br />
** Source Code Downloads<br />
*** [http://multimedia.cx/mirror/vpvision/source/vp32.tar.gz VP3.2 Codec source code (compressed TAR format, 1.1MB)]<br />
*** [http://multimedia.cx/mirror/vpvision/source/vpvision0.5_source.zip VPVision source code (ZIP archive, 5.2MB)]<br />
*** [http://multimedia.cx/mirror/vpvision/source/vorbis_nodebug_tc40_vp0.5rc.zip Vorbis (ZIP archive, 12.7MB)]<br />
*** [http://multimedia.cx/mirror/vpvision/source/readme.txt readme.txt]<br />
*** [http://multimedia.cx/mirror/vpvision/source/readmefirst.txt readmefirst.txt]<br />
<br />
* [[On2 VP6]]:<br />
** VP6 Bitstream & Decoding Specification<br />
*** mirror: http://multimedia.cx/mirror/vp6_format.pdf<br />
** whitepaper:<br />
*** mirror: http://multimedia.cx/mirror/vp6-white-paper.pdf<br />
*** original: http://www.on2.com/cms-data/pdf/1125607149174329.pdf<br />
<br />
* [[On2 VP7]]:<br />
** VP7 Data Format and Decoder<br />
*** mirror: http://multimedia.cx/mirror/VP7_Data_Format_and_Decoder_Overview.pdf<br />
** whitepaper:<br />
*** mirror: http://multimedia.cx/mirror/vp7-white-paper.pdf<br />
*** original: http://www.on2.com/cms-data/pdf/1123531744838491.pdf<br />
<br />
* [[PVA]] specification:<br />
** mirror: http://multimedia.cx/mirror/av_format_v1.pdf<br />
<br />
* [[RealAudio 14.4]]:<br />
** mirror: http://multimedia.cx/mirror/spra136.pdf<br />
** original: http://focus.ti.com/lit/an/spra136/spra136.pdf<br />
<br />
* [[RealVideo]] document assortment ([http://multimedia.cx/eggs/official-realvideo-specifications/ described in this blog post]):<br />
** mirror: http://multimedia.cx/mirror/realvideo/<br />
** original: https://rarvcode-video.helixcommunity.org/files/Docs/<br />
<br />
* [[Sonarc]] lossless audio v2.1i software<br />
** mirror: http://multimedia.cx/mirror/snrc21i.zip<br />
** original: ftp://ftp.elf.stuba.sk/pub/pc/pack/snrc21i.zip<br />
<br />
* [[VC-1]] (a.k.a. VC-9) draft specification:<br />
** mirror: draft dated 2006-02-24: http://multimedia.cx/mirror/VC-1_Compressed_Video_Bitstream_Format_and_Decoding_Process.pdf<br />
** mirror: draft dated 2005-08-23: http://multimedia.cx/mirror/s421m.pdf<br />
** mirror: draft dated 2005-08-23: http://multimedia.cx/mirror/rp227.pdf<br />
** mirror: draft dated 2004-03-31: http://multimedia.cx/mirror/C24.008-VC9-Spec-CD1.pdf<br />
** reference source code mirror: http://multimedia.cx/mirror/VC1_reference_decoder_release6.zip</div>Multimedia Mikehttps://wiki.multimedia.cx/index.php?title=Talk:Microsoft_IMA_ADPCM&diff=15617Talk:Microsoft IMA ADPCM2022-03-21T03:24:50Z<p>Multimedia Mike: clarification</p>
<hr />
<div>Maybe I am wrong, but according to the Microsoft WAVE AVI Codec registry on the IETF, the Audio ID here should be 0x0002 and not 0x0011, where 0x0011 seems to point to Intel's DVI ADPCM instead. Please check [https://www.iana.org/assignments/wave-avi-codec-registry/wave-avi-codec-registry.xml] for more information. Furthermore, the Quicktime ID should be MS$0011.<br />
<br />
: Yes, this is confusing. But 0x0011 is the 16-bit identifier for the IMA variant of ADPCM, which 0x0002 is the ID for [https://wiki.multimedia.cx/index.php/Microsoft_ADPCM Microsoft's own ADPCM variant], which is distinct from the IMA flavor. QuickTime ID for this is 'ms\x0\x11'. [[User:Multimedia Mike|Multimedia Mike]] ([[User talk:Multimedia Mike|talk]]) 20:24, 20 March 2022 (PDT)</div>Multimedia Mikehttps://wiki.multimedia.cx/index.php?title=Mirrored_Files&diff=15616Mirrored Files2022-03-21T03:12:36Z<p>Multimedia Mike: Microsoft Motion JPEG documentation</p>
<hr />
<div>This is a list of official technical documents that are mirrored at multimedia.cx for convenience or archival: http://multimedia.cx/mirror/<br />
<br />
Contact [[User:Multimedia Mike|Multimedia Mike]] in order to add documents to the mirror.<br />
<br />
* [[A52]]:<br />
** 2018 Revision:<br />
*** mirror: https://multimedia.cx/mirror/A52-2018.pdf<br />
*** original: https://www.atsc.org/wp-content/uploads/2015/03/A52-2018.pdf<br />
** Revision B:<br />
*** mirror: http://multimedia.cx/mirror/a_52b.pdf<br />
*** original: [offline]<br />
<br />
* [[Apple Core Audio Format]] specification, dated 2006-03-08:<br />
** mirror: http://multimedia.cx/mirror/CAFSpec-2006-03-08.pdf<br />
** original: http://developer.apple.com/documentation/MusicAudio/Reference/CAFSpec/index.html<br />
<br />
* Apple [[QuickTime container]] specification, dated 2007-09-04:<br />
** mirror: http://multimedia.cx/mirror/qtff-2007-09-04.pdf<br />
** original: http://developer.apple.com/mac/library/documentation/QuickTime/QTFF<br />
<br />
* [[Audio Interchange File Format]]:<br />
** mirror: http://multimedia.cx/mirror/AudioIFF1_2_1.htm<br />
<br />
* [[Cinepak]]:<br />
** mirror: http://multimedia.cx/mirror/cinepak.txt<br />
** original: http://www.csse.monash.edu.au/%7etimf/videocodec/cinepak.txt<br />
<br />
* [[CYUV]]:<br />
** mirror: http://multimedia.cx/mirror/cyuv.txt<br />
** original: http://www.csse.monash.edu.au/~timf/videocodec/cyuv.txt<br />
<br />
* [[Dialogic IMA ADPCM]]:<br />
** mirror: http://multimedia.cx/mirror/dialogic-adpcm.pdf<br />
<br />
* [[DTS]]:<br />
** mirror (whitepaper): http://multimedia.cx/mirror/dts-whitepaper.pdf<br />
** mirror (document 1): http://multimedia.cx/mirror/dts1.pdf<br />
** mirror (document 2): http://multimedia.cx/mirror/dts2.pdf<br />
** mirror (DTS patent application, scans, 550 pages, 54 MB PDF): http://multimedia.cx/mirror/EP864146-53.pdf<br />
** mirror (DCA transform): http://multimedia.cx/mirror/dca-transform.pdf<br />
** Specification v1.4.1, 2012-09: http://multimedia.cx/mirror/ts_102114v010401p.pdf<br />
<br />
* [[H264]] draft specification, marked 2002 (E):<br />
** mirror: http://multimedia.cx/mirror/JVT-G050.pdf<br />
<br />
* [[IBM UltiMotion]] specification:<br />
** mirror: http://multimedia.cx/mirror/UMSPEC.ZIP<br />
<br />
* Id [[CIN]]:<br />
** mirror: http://multimedia.cx/mirror/idcin.html<br />
** original: http://www.csse.monash.edu.au/~timf/videocodec/idcin.html<br />
<br />
* Id [[RoQ]]:<br />
** mirror: http://multimedia.cx/mirror/idroq.txt<br />
** original: http://www.csse.monash.edu.au/~timf/videocodec/idroq.txt<br />
** sample decoder source code: http://multimedia.cx/mirror/idroq.tar.gz<br />
<br />
* [[Indeo 3]]:<br />
** mirror (partial specification): http://multimedia.cx/mirror/5386232.pdf<br />
** mirror (header explanation): http://multimedia.cx/mirror/indeo3.txt<br />
** original (header explanation): http://www.csse.monash.edu.au/~timf/videocodec/indeo3.txt<br />
<br />
* [[Meridian Lossless Packing]] whitepaper:<br />
** mirror: http://multimedia.cx/mirror/mlp_jap_new.PDF<br />
** original: http://www.meridian-audio.com/w_paper/mlp_jap_new.PDF<br />
<br />
* [[Motion JPEG]] Documentation by Microsoft (1993):<br />
** mirror: https://multimedia.cx/mirror/msmjpg.txt<br />
<br />
* [[Nokia MVC]]:<br />
** documentation:<br />
*** original: http://ftp3.itu.ch/av-arch/video-site/0005_Osa/q15j19.doc<br />
*** mirror: http://multimedia.cx/mirror/q15j19.doc<br />
** reference codec:<br />
*** original: http://ftp3.itu.ch/av-arch/video-site/0005_Osa/q15j20.zip<br />
*** mirror: http://multimedia.cx/mirror/q15j20.zip<br />
<br />
* [[Nullsoft Video]]:<br />
** documentation:<br />
*** mirror: http://multimedia.cx/mirror/NSVFormat.rtf<br />
<br />
* [[On2 VP3]]:<br />
** Binary Downloads<br />
*** [http://multimedia.cx/mirror/vpvision/On2VP3VideoForWindows.exe On2 VP3 Video for Windows installer (1.2MB)]<br />
*** [http://multimedia.cx/mirror/vpvision/VpV05install.exe VPVision installer (4.6MB)]<br />
*** [http://multimedia.cx/mirror/vpvision/readme.txt readme.txt]<br />
*** [http://multimedia.cx/mirror/vpvision/readmefirst.txt readmefirst.txt]<br />
** Source Code Downloads<br />
*** [http://multimedia.cx/mirror/vpvision/source/vp32.tar.gz VP3.2 Codec source code (compressed TAR format, 1.1MB)]<br />
*** [http://multimedia.cx/mirror/vpvision/source/vpvision0.5_source.zip VPVision source code (ZIP archive, 5.2MB)]<br />
*** [http://multimedia.cx/mirror/vpvision/source/vorbis_nodebug_tc40_vp0.5rc.zip Vorbis (ZIP archive, 12.7MB)]<br />
*** [http://multimedia.cx/mirror/vpvision/source/readme.txt readme.txt]<br />
*** [http://multimedia.cx/mirror/vpvision/source/readmefirst.txt readmefirst.txt]<br />
<br />
* [[On2 VP6]]:<br />
** VP6 Bitstream & Decoding Specification<br />
*** mirror: http://multimedia.cx/mirror/vp6_format.pdf<br />
** whitepaper:<br />
*** mirror: http://multimedia.cx/mirror/vp6-white-paper.pdf<br />
*** original: http://www.on2.com/cms-data/pdf/1125607149174329.pdf<br />
<br />
* [[On2 VP7]]:<br />
** VP7 Data Format and Decoder<br />
*** mirror: http://multimedia.cx/mirror/VP7_Data_Format_and_Decoder_Overview.pdf<br />
** whitepaper:<br />
*** mirror: http://multimedia.cx/mirror/vp7-white-paper.pdf<br />
*** original: http://www.on2.com/cms-data/pdf/1123531744838491.pdf<br />
<br />
* [[PVA]] specification:<br />
** mirror: http://multimedia.cx/mirror/av_format_v1.pdf<br />
<br />
* [[RealAudio 14.4]]:<br />
** mirror: http://multimedia.cx/mirror/spra136.pdf<br />
** original: http://focus.ti.com/lit/an/spra136/spra136.pdf<br />
<br />
* [[RealVideo]] document assortment ([http://multimedia.cx/eggs/official-realvideo-specifications/ described in this blog post]):<br />
** mirror: http://multimedia.cx/mirror/realvideo/<br />
** original: https://rarvcode-video.helixcommunity.org/files/Docs/<br />
<br />
* [[Sonarc]] lossless audio v2.1i software<br />
** mirror: http://multimedia.cx/mirror/snrc21i.zip<br />
** original: ftp://ftp.elf.stuba.sk/pub/pc/pack/snrc21i.zip<br />
<br />
* [[VC-1]] (a.k.a. VC-9) draft specification:<br />
** mirror: draft dated 2006-02-24: http://multimedia.cx/mirror/VC-1_Compressed_Video_Bitstream_Format_and_Decoding_Process.pdf<br />
** mirror: draft dated 2005-08-23: http://multimedia.cx/mirror/s421m.pdf<br />
** mirror: draft dated 2004-03-31: http://multimedia.cx/mirror/C24.008-VC9-Spec-CD1.pdf<br />
** reference source code mirror: http://multimedia.cx/mirror/VC1_reference_decoder_release6.zip</div>Multimedia Mikehttps://wiki.multimedia.cx/index.php?title=Macromedia&diff=15603Macromedia2021-12-27T20:04:56Z<p>Multimedia Mike: update language to reflect longer history</p>
<hr />
<div>Website: [http://www.macromedia.com/ http://www.macromedia.com/]<br />
<br />
Macromedia was the company behind [[Flash]] and [[SWF | ShockWave]]. In 2005, Macromedia was acquired by [[Adobe]].<br />
<br />
[[Category:Multimedia-related Companies]]</div>Multimedia Mikehttps://wiki.multimedia.cx/index.php?title=Portable_Sound_Format&diff=15591Portable Sound Format2021-10-07T05:18:28Z<p>Multimedia Mike: fill in some broader details</p>
<hr />
<div>* Extensions: PSF, PSF2, USF, GSF, 2SF, DSF, QSF, SSF<br />
<br />
Portable Sound Format (PSF) is a game audio music format. The different extensions correspond to music programs extracted from different types of game systems:<br />
<br />
* PSF: Sony PlayStation<br />
* PSF: Sony PlayStation 2<br />
* USF: Nintendo 64<br />
* GSF: Nintendo Game Boy Advance<br />
* 2SF: Nintendo DS<br />
* DSF: Sega Dreamcast<br />
* QSF: Q-sound<br />
* SSF: Sega Saturn<br />
<br />
A set of PSF files usually represents all of the music from a particular games. A set of music features 1 of 2 topologies:<br />
<br />
Individual files: Each file stands on its own.<br />
* song1.psf<br />
* song2.psf<br />
* ...<br />
* songN.psf<br />
<br />
Shared library: There is 1 or more shared libraries and a sequence of smaller files which reference the shared libraries.<br />
* gamemusic.psflib<br />
* song1.psf<br />
* ...<br />
* songN.psf<br />
<br />
[[Category:Game Audio Formats]]</div>Multimedia Mikehttps://wiki.multimedia.cx/index.php?title=NSF&diff=15590NSF2021-10-07T04:33:29Z<p>Multimedia Mike: </p>
<hr />
<div>* Extension NSF, NSFe<br />
<br />
NSF stands for NES Sound Format. The format encapsulates sequences of instructions extracted from 8-bit Nintendo Entertainment System (NES) games. The instructions activate NES sound hardware in order to play music.<br />
<br />
Some NSF files have the extension .nsfe to indicate extended metadata.<br />
<br />
[[Category:Game Audio Formats]]</div>Multimedia Mikehttps://wiki.multimedia.cx/index.php?title=Ip20&diff=15588Ip202021-10-04T17:35:43Z<p>Multimedia Mike: FourCC redirector</p>
<hr />
<div>#redirect [[Imagination Pilots Matte Animation]]<br />
<br />
[[Category:Video FourCCs]]</div>Multimedia Mikehttps://wiki.multimedia.cx/index.php?title=Ipma&diff=15587Ipma2021-10-04T17:35:06Z<p>Multimedia Mike: FourCC redirectory</p>
<hr />
<div>#redirect [[Imagination Pilots Matte Animation]]<br />
<br />
[[Category:Video FourCCs]]</div>Multimedia Mikehttps://wiki.multimedia.cx/index.php?title=Apple_SMC&diff=15576Apple SMC2021-08-11T05:35:39Z<p>Multimedia Mike: confirmed this bit of trivia</p>
<hr />
<div>''This page is based on the document 'Description of the Apple Graphics (SMC) Codec' by Mike Melanson found at [http://multimedia.cx/smc.txt http://multimedia.cx/smc.txt]''.<br />
<br />
* FOURCCs: 'smc ' (note space character, ASCII 0x20, needed for FOURCC)<br />
* Company: [[Apple]]<br />
* Samples: [http://samples.mplayerhq.hu/V-codecs/SMC/ http://samples.mplayerhq.hu/V-codecs/SMC/]<br />
<br />
The Apple SMC codec is also known as the Apple Graphics codec. It is a vector quantizer video codec that operates on 4x4 blocks of 8-bit paletted pixel values. The codec is named after its developer, Sean M. Callahan.<br />
<br />
== Basics of SMC Data and Decoding ==<br />
<br />
All multi-byte values (there is actually only 1) are stored in big-endian format.<br />
<br />
An SMC decoder renders 4x4 pixel blocks from left to right, top to bottom. The source data are 8-bit paletted values. The palette for an SMC-encoded Quicktime file is transported within the stsd atom of the video header.<br />
<br />
An SMC decoder maintains 3 circular caches consisting of 256 elements each. Each element contains 2, 4 or 8 colors which are used in decoding 2-, 4-, and 8-color blocks:<br />
<br />
* color pair cache for 2-color encoded blocks:<br />
<br />
+---------+---------+<br />
pair 0 | color 0 | color 1 |<br />
+---------+---------+<br />
pair 1 | color 0 | color 1 |<br />
+---------+---------+<br />
/ .. .. /<br />
+---------+---------+<br />
pair 255 | color 0 | color 1 |<br />
+---------+---------+<br />
<br />
* color quad cache for 4-color encoded blocks:<br />
<br />
+---------+---------+---------+---------+<br />
quad 0 | color 0 | color 1 | color 2 | color 3 |<br />
+---------+---------+---------+---------+<br />
quad 1 | color 0 | color 1 | color 2 | color 3 |<br />
+---------+---------+---------+---------+<br />
/ .. .. .. .. /<br />
+---------+---------+---------+---------+<br />
quad 255 | color 0 | color 1 | color 2 | color 3 |<br />
+---------+---------+---------+---------+<br />
<br />
* color octet cache for 8-color encoded blocks:<br />
<br />
+---------+---------+---------+---------+<br />
octet 0 | color 0 | color 1 / .. / color 7 |<br />
+---------+---------+---------+---------+<br />
octet 1 | color 0 | color 1 / .. / color 7 |<br />
+---------+---------+---------+---------+<br />
/ .. .. .. .. /<br />
+---------+---------+---------+---------+<br />
octet 255 | color 0 | color 1 | .. | color 7 |<br />
+---------+---------+---------+---------+<br />
<br />
The caches operate as circular arrays: If a cache exceeds 256 elements, new elements are stored starting from the beginning of the cache. All 3 caches are reset before decoding a new frame.<br />
<br />
The first byte of a chunk is probably a flags byte. XAnim's comments seem to imply that this byte is always 0xe1. I've also observed a 0x80 byte in this byte. In either case, the meaning of the byte is unknown.<br />
<br />
Bytes 2-4 are the length of the chunk. This value should match the value transported in the Quicktime file's video chunk length atom. Then, the bytestream in the chunk is traversed. The decoder renders blocks based on the upper nibble of command opcodes.<br />
<br />
== SMC Opcodes ==<br />
<br />
After the first 4 bytes, an SMC chunk is a stream of opcodes and associated data. The opcode is the upper nibble of the next byte in the stream. The meaning of each opcode is detailed next.<br />
<br />
== 0x00 or 0x10: Skip Blocks ==<br />
<br />
These 2 opcodes instruct the decoder to skip blocks in the output frame. If there are 4x4 pixel blocks in the previous frame that are the same as in the current frame, there's no point in rendering them again, so these opcodes allow the decoder to skip blocks.<br />
<br />
These opcodes skip n blocks, where n is 1 plus the lower nibble of the opcode byte if the opcode is 0x00, or 1 plus the next byte in the stream if the opcode is 0x10.<br />
<br />
== 0x20 or 0x30: Repeat Last Block ==<br />
<br />
These 2 opcodes instruct the decoder to repeat the last block over the next n blocks, where n is 1 plus the lower nibble of the opcode byte if the opcode is 0x20, or 1 plus the next byte in the stream if the opcode is 0x30. If the first block to be rendered is the first block on a line, repeat the last block from the previous line.<br />
<br />
== 0x40 or 0x50: Repeat Previous 2 Blocks ==<br />
<br />
These 2 opcodes instruct the decoder to repeat the last pair blocks over the next n pairs of blocks, where n is 1 plus the lower nibble of the opcode byte if the opcode is 0x40, or 1 plus the next byte in the stream if the opcode is 0x50. If the first block to be rendered is the first block on a lines, repeat the last 2 blocks from the previous line. Similarly, if the first block to be rendered is the second block on a line, the first repeated block will be the last block from the previous line, while the second repeated block will be the first block from the current line.<br />
<br />
== 0x60 or 0x70: 1-Color Encoding ==<br />
<br />
These 2 opcodes instruct the decoder to paint the next n blocks the same color. The number of blocks is 1 plus the lower nibble of the opcode byte if the opcode is 0x60, or 1 plus the next byte in the stream if the opcode<br />
is 0x70. The color to paint the block is the palette entry indexed by the next byte in the stream.<br />
<br />
== 0x80 or 0x90: 2-Color Encoding ==<br />
<br />
These 2 codes both specify a pair of colors with which to paint the next n blocks. The number of blocks to paint is equal to 1 plus the lower nibble of the opcode.<br />
<br />
The color pair to be used to paint the blocks depends on the opcode. If the opcode is 0x80, the next 2 bytes in the stream specify the palette indices to be used. The 2 colors are stored in the next available entry in the color pair cache. If the opcode is 0x90, then the next byte in the stream specifies an index into the color pair cache containing the color pair to be used.<br />
<br />
For each block to be rendered, there are 2 bytes (called a and b in this example) in the stream that are arrays of flags which specify which of the 2 colors in the selected pair will paint which pixels in the block. The flags are arranged as follows:<br />
<br />
a7 a6 a5 a4<br />
a3 a2 a1 a0<br />
b7 b6 b5 b4<br />
b3 b2 b1 b0<br />
<br />
For example, it bit 3 of byte b is 1, then the pixel in the lower left corner of the block is set to color 1 from the selected pair, otherwise it is set to color 0.<br />
<br />
== 0xA0 or 0xB0: 4-Color Encoding ==<br />
<br />
These 2 codes both specify a quad of colors with which to paint the next n blocks. The number of blocks to paint is equal to 1 plus the lower nibble of the opcode.<br />
<br />
The color quad to be used to paint the blocks depends on the opcode. If the opcode is 0xA0, the next 4 bytes in the stream specify the palette indices to be used. The 4 colors are stored in the next available entry in the color quad cache. If the opcode is 0xB0, then the next byte in the stream specifies an index into the color quad cache containing the color quad to be used.<br />
<br />
For each block to be rendered, there are 4 bytes (called a, b, c and d in this example) in the stream that are arrays of flags which specify which of the 4 colors in the selected pair will paint which pixels in the<br />
block. The flags are arranged as follows:<br />
<br />
a76 a54 a32 a10<br />
b76 b54 b32 b10<br />
c76 c54 c32 c10<br />
d76 d54 d32 d10<br />
<br />
For example, if the lower 2 bits of byte a are 11 (3 decimal), then color 3 of the selected color quad is placed in the upper right corner of the block.<br />
<br />
== 0xC0 or 0xD0: 8-Color Encoding ==<br />
<br />
These 2 codes both specify an octet of colors with which to paint the next n blocks. The number of blocks to paint is equal to 1 plus the lower nibble of the opcode.<br />
<br />
The color octet to be used to paint the blocks depends on the opcode. If the opcode is 0xC0, the next 8 bytes in the stream specify the palette indices to be used. The 8 colors are stored in the next available entry in the color octet cache. If the opcode is 0xD0, then the next byte in the stream specifies an index into the color octet cache containing the color octet to be used.<br />
<br />
For each block to be rendered, there are 6 bytes in the stream that will comprise arrays of flags that specify which of the 8 colors in the selected pair will paint which pixels in the block. It's best to assemble the next 6 bytes into 2 24-bit numbers stored in 2 32-bit variables (a and b in this example). The next 6 bytes in the stream are rearranged in the most unusual manner. For 6 bytes:<br />
<br />
[01 23 45 67 89 AB]<br />
<br />
broken down into a vector of 12 nibbles:<br />
<br />
[n0n1 n2n3 n4n5 n6n7 n8n9 nAnB]<br />
<br />
this is the arrangement of color flags:<br />
<br />
flags_a = n0n1 n2n4 n5n6<br />
flags_b = n8n9 nAn3 n7nB<br />
<br />
The flags are arranged as follows:<br />
<br />
a23-21 a20-18 a17-15 a14-12<br />
a11-9 a8-6 a5-3 a2-0<br />
b23-21 b20-18 b17-15 b14-12<br />
b11-9 b8-6 b5-3 b2-0<br />
<br />
For example, bits 23-21 of a32 will yield the index into the selected color octet to specify the color of the first pixel of the block. If bits 23-21 of a32 are 101 (5 decimal), color 5 from the selected octet is placed in the first pixel of the block.<br />
<br />
== 0xE0: 16-Color Encoding ==<br />
<br />
For n blocks, where n is 1 plus the lower nibble of the command opcode (no exception here), copy the blocks directly into the output image. Each block is comprised of 16 bytes and each byte is a palette entry. For bytes [0, 1, .., 15] in the bytestream, the block is laid out as<br />
<br />
0 1 2 3<br />
4 5 6 7<br />
8 9 10 11<br />
12 13 14 15<br />
<br />
== 0xF0: Unknown Opcode ==<br />
<br />
The XAnim source code does not necessarily list this as an invalid opcode, just an unknown one.<br />
<br />
== References ==<br />
<br />
* [[XAnim]]<br />
<br />
[[Category:Video Codecs]]</div>Multimedia Mikehttps://wiki.multimedia.cx/index.php?title=H4M&diff=15572H4M2021-07-22T05:54:49Z<p>Multimedia Mike: reference patent</p>
<hr />
<div>* Extension: h4m<br />
* Company: [[Hudson]] / University of Tsukuba<br />
* Website: http://www.chaos.cs.tsukuba.ac.jp/research/index.html (Japanese)<br />
* Patent: [https://patents.google.com/patent/US6714687B2/en?oq=6714687 US#6714687]<br />
<br />
H4M is game format that uses AOT (Adaptive Orthogonalized Transform) based vector quantization image compression.<br />
<br />
* HVQM3 is used on [[N64]] Mario Party series games<br />
* HVQM4 is used on some [[Nintendo GameCube]] Biohazard/Resident Evil series games<br />
<br />
H4M files begin with the ASCII characters "HVQM" followed by versioning information. Most of the format is unknown.<br />
<br />
== Games Using H4M ==<br />
<br />
These games use H4M files. Observed format versions are noted where known.<br />
<br />
* [https://www.mobygames.com/game/gamecube/resident-evil-0 Resident Evil 0 (GameCube)], v1.5<br />
* [https://www.mobygames.com/game/gamecube/resident-evil- Resident Evil (GameCube)], v1.3<br />
<br />
[[Category:Game Formats]]<br />
[[Category:Undiscovered Game Formats]]</div>Multimedia Mikehttps://wiki.multimedia.cx/index.php?title=H4M&diff=15571H4M2021-07-21T23:43:58Z<p>Multimedia Mike: typo</p>
<hr />
<div>* Extension: h4m<br />
* Company: [[Hudson]] / University of Tsukuba<br />
* Website: http://www.chaos.cs.tsukuba.ac.jp/research/index.html (Japanese)<br />
<br />
H4M is game format that uses AOT (Adaptive Orthogonalized Transform) based vector quantization image compression.<br />
<br />
* HVQM3 is used on [[N64]] Mario Party series games<br />
* HVQM4 is used on some [[Nintendo GameCube]] Biohazard/Resident Evil series games<br />
<br />
H4M files begin with the ASCII characters "HVQM" followed by versioning information. Most of the format is unknown.<br />
<br />
== Games Using H4M ==<br />
<br />
These games use H4M files. Observed format versions are noted where known.<br />
<br />
* [https://www.mobygames.com/game/gamecube/resident-evil-0 Resident Evil 0 (GameCube)], v1.5<br />
* [https://www.mobygames.com/game/gamecube/resident-evil- Resident Evil (GameCube)], v1.3<br />
<br />
[[Category:Game Formats]]<br />
[[Category:Undiscovered Game Formats]]</div>Multimedia Mikehttps://wiki.multimedia.cx/index.php?title=H4M&diff=15570H4M2021-07-21T23:20:42Z<p>Multimedia Mike: document games that use this format, along with version numbers</p>
<hr />
<div>* Extension: h4m<br />
* Company: [[Hudson]] / University of Tsukuba<br />
* Website: http://www.chaos.cs.tsukuba.ac.jp/research/index.html (Japanese)<br />
<br />
H4M is game format that uses AOT (Adaptive Orthogonalized Transform) based vector quantization image compression.<br />
<br />
* HVQM3 is used on [[N64]] Mario Party series games<br />
* HVQM4 is used on some [[Nintendo GameCube]] Biohazard/Resident Evil series games<br />
<br />
H4M files begin with the ASCII characters "HVQM" followed by versioning information. Most of he format is unknown.<br />
<br />
== Games Using H4M ==<br />
<br />
These games use H4M files. Observed format versions are noted where known.<br />
<br />
* [https://www.mobygames.com/game/gamecube/resident-evil-0 Resident Evil 0 (GameCube)], v1.5<br />
* [https://www.mobygames.com/game/gamecube/resident-evil- Resident Evil (GameCube)], v1.3<br />
<br />
[[Category:Game Formats]]<br />
[[Category:Undiscovered Game Formats]]</div>Multimedia Mikehttps://wiki.multimedia.cx/index.php?title=Duck_IVF&diff=15488Duck IVF2020-06-02T01:05:29Z<p>Multimedia Mike: typo</p>
<hr />
<div>* Extension: ivf<br />
* Samples: The test-vectors-* archives available here: https://chromium.googlesource.com/webm/vp8-test-vectors<br />
<br />
IVF is a simple file format that transports raw VP8 data.<br />
<br />
Multi-byte numbers of little-endian. An IVF file begins with a 32-byte header:<br />
<br />
bytes 0-3 signature: 'DKIF'<br />
bytes 4-5 version (should be 0)<br />
bytes 6-7 length of header in bytes<br />
bytes 8-11 codec FourCC (e.g., 'VP80')<br />
bytes 12-13 width in pixels<br />
bytes 14-15 height in pixels<br />
bytes 16-23 time base denominator<br />
bytes 20-23 time base numerator<br />
bytes 24-27 number of frames in file<br />
bytes 28-31 unused<br />
<br />
The header is followed by a series of frames. Each frame consists of a 12-byte header followed by data:<br />
<br />
bytes 0-3 size of frame in bytes (not including the 12-byte header)<br />
bytes 4-11 64-bit presentation timestamp<br />
bytes 12.. frame data<br />
<br />
== PC games using IVF files ==<br />
<br />
* [https://www.mobygames.com/game/rogue-trooper-redux Rogue Trooper Redux]<br />
* [https://www.mobygames.com/game/shantae-and-the-seven-sirens Shantae and the Seven Sirens]<br />
<br />
[[Category:Container Formats]]</div>Multimedia Mikehttps://wiki.multimedia.cx/index.php?title=Duck_IVF&diff=15487Duck IVF2020-06-02T01:03:47Z<p>Multimedia Mike: found a Shantae game that uses this format</p>
<hr />
<div>* Extension: ivf<br />
* Samples: The test-vectors-* archives available here: https://chromium.googlesource.com/webm/vp8-test-vectors<br />
<br />
IVF is a simple file format that transports raw VP8 data.<br />
<br />
Multi-byte numbers of little-endian. An IVF file begins with a 32-byte header:<br />
<br />
bytes 0-3 signature: 'DKIF'<br />
bytes 4-5 version (should be 0)<br />
bytes 6-7 length of header in bytes<br />
bytes 8-11 codec FourCC (e.g., 'VP80')<br />
bytes 12-13 width in pixels<br />
bytes 14-15 height in pixels<br />
bytes 16-23 time base denominator<br />
bytes 20-23 time base numerator<br />
bytes 24-27 number of frames in file<br />
bytes 28-31 unused<br />
<br />
The header is followed by a series of frames. Each frame consists of a 12-byte header followed by data:<br />
<br />
bytes 0-3 size of frame in bytes (not including the 12-byte header)<br />
bytes 4-11 64-bit presentation timestamp<br />
bytes 12.. frame data<br />
<br />
== PC games using IFV files ==<br />
<br />
* [https://www.mobygames.com/game/rogue-trooper-redux Rogue Trooper Redux]<br />
* [https://www.mobygames.com/game/shantae-and-the-seven-sirens Shantae and the Seven Sirens]<br />
<br />
[[Category:Container Formats]]</div>Multimedia Mikehttps://wiki.multimedia.cx/index.php?title=Origin_Flic_Codec&diff=15486Origin Flic Codec2020-05-01T00:55:02Z<p>Multimedia Mike: proper samples link</p>
<hr />
<div>* FourCC: JYV1, JYA1, RRV1, RRV2<br />
* Company: Origin Systems <br />
* Samples: http://samples.mplayerhq.hu/game-formats/crusader-no-remorse/<br />
<br />
''Please rename this codec name to something more original''<br />
<br />
Origin Flic Codec is a relatively simple palettized video codec used in PC version of Crusader: No Remorse game. Data is packaged inside standard [[AVI]] container and employs relatively simple [[RLE]] compression. Audio stored in uncompressed [[PCM]] form. It is rumored that codec's FourCCs are actually based on game developer's names (not confirmed.)<br />
<br />
== Video Codec ==<br />
A video movie uses fixed palette, stored in corresponding AVI Stream Format chunk.<br />
<br />
Video frame is encoded in a series of slices, where each slice encodes a number of horizontal lines of picture. Number of slices depends on FourCC and is:<br />
* JYV1, RRV1 - 5 slices<br />
* RRV2 - 15 slices<br />
Therefore, each slice contains VideoHeight/slices raster lines.<br />
<br />
Frame chunk consist of the following parts:<br />
<br />
u32 slicetable[num_slices]<br />
-- for each slice --<br />
u32 codes_size;<br />
u8 codes[codes_size]<br />
u8 raster[]<br />
--------------------<br />
where each entry of slicetable points to corresponding codes/raster block (offsets are relative to beginning of the chunk.)<br />
<br />
Video decompression is performed as follows (for each slice):<br />
<br />
flipflop = flip<br />
while slice is not complete<br />
idx = GetBits(4);<br />
blocksize = BaseLength[idx];<br />
if idx != 0 and idx != 8<br />
blocksize += GetBits(FineLengthBits[idx]);<br />
if flipflop == flip<br />
leave blocksize pixels unchanged<br />
else<br />
draw blocksize pixels from raster[]<br />
flip flop<br />
<br />
BaseLength[] = {0, 1<<7, 1<<3, 0, 1<<1, 0, 1<<5, 0,<br />
1, 1<<8, 1<<4, 0, 1<<2, 0, 1<<6, 0};<br />
FineLengthBits[] = {0, 7, 3, 0, 1, 16, 5, 0,<br />
1, 8, 4, 0, 2, 24, 6, 0};<br />
<br />
GetBits() reads variable number of bits from codes[], highest bits of lowest byte first.<br />
For RRV* FourCCs 'leave' and 'draw' command skips/doubles each pixel when decoding a keyframe (i.e. a keyframe should be upscaled horizontally.)<br />
<br />
[[Category:Game Formats]]<br />
[[Category:Video Codecs]]<br />
[[Category:Formats missing in FFmpeg]]</div>Multimedia Mikehttps://wiki.multimedia.cx/index.php?title=Robot_Animation&diff=15474Robot Animation2020-02-14T06:23:05Z<p>Multimedia Mike: /* Audio Format */ correct the audio format</p>
<hr />
<div>* Extension: RBT<br />
* Company: [[Sierra Entertainment]]<br />
<br />
Robot files are animation files used in various Sierra computer games. It is a container format that encapsulates video and possibly audio.<br />
<br />
The details on this page were gleaned from [http://scummvm.org/ ScummVM] source code, which only covers version 5 of the format.<br />
<br />
== Container Format ==<br />
All multi-byte numbers are little-endian.<br />
<br />
The general organization of a Robot file is as follows:<br />
<br />
<header><br />
<unknown block><br />
<palette><br />
<video frame size table><br />
<frame size table><br />
<unknown tables><br />
<padding><br />
<frame 1><br />
<frame 2><br />
...<br />
<frame n><br />
<br />
A Robot file begins with the following variable-length header.<br />
<br />
bytes 0-5 signature and probably a version (16 00 53 4f 4c 00; bytes 2-4 are 'SOL')<br />
bytes 6-7 version<br />
bytes 8-9 audio chunk size<br />
bytes 10-11 silence chunk size<br />
bytes 12-13 unknown<br />
bytes 14-15 frame count<br />
bytes 16-17 palette data size<br />
bytes 18-19 unknown chunk data size<br />
bytes 20-21 X resolution<br />
bytes 22-23 Y resolution<br />
byte 24 has palette<br />
byte 25 has sound<br />
bytes 26-27 unknown<br />
bytes 28-29 framerate<br />
bytes 30-31 is HiRes<br />
bytes 32-33 max skippable packets<br />
bytes 34-35 max cels per frame<br />
bytes 36-39 the maximum possible size, in bytes, of the first fixed cel<br />
bytes 40-43 the maximum possible size, in bytes, of the second fixed cel<br />
bytes 44-47 the maximum possible size, in bytes, of the third fixed cel<br />
bytes 48-51 the maximum possible size, in bytes, of the fourth fixed cel<br />
bytes 52-59 unknown<br />
bytes 60.. unknown data chunk, size defined by bytes 18-19<br />
<br />
After the header is a palette chunk. The size of the palette chunk is defined it bytes 16-17 of the header. The first 37 or 38 bytes have the following format:<br />
<br />
bytes 0-24 unknown<br />
byte 25 first palette index to replace<br />
bytes 29-30 palette count<br />
byte 32 palette format (0 = variable, 1 = constant)<br />
bytes 33-[36,37] unknown<br />
byte [37,38].. palette components<br />
<br />
The palette is 256 total entries, though the palette encoded in this chunk is only likely to encode a partial palette since the other colors are reserved for other parts of the game's user interface.<br />
<br />
Replace (palette count) entries in the palette starting with the index specified by byte 25. The palette components are ordered red - green - blue - red - green - blue - etc. The palette components begin at index 37 for constant palettes and 38 for variable palettes.<br />
<br />
Each palette component is 8 bits.<br />
<br />
Following the palette chunk is 2 size tables: the first is the video frame size table and the second is the size table. Each table contains one 16-bit size value for each frame in the file (the frame count is defined in bytes 14-15 of the header).<br />
<br />
Following the 2 size tables is more undefined data that has a constant size of 1536 bytes. Reverse engineering efforts indicate that this is a 1024-byte table followed by a 512-byte table.<br />
<br />
Finally, there is padding before the frames. The first frame is aligned on a 2048-byte boundary (perhaps a CD sector boundary). Thus, after reading the previous unknown data, advance the file (0x800 - (current_offset(rbt_file) & 0x7ff)) bytes.<br />
<br />
Then there the sequence of frames, the count of which is defined in the header. Each frame contains video and also audio, if the header indicates that the file contains sound. The size of the entire frame corresponds to the frame's entry in the frame size table. The video comes first and the size of the video portion corresponds to the frame's entry is the video frame size table. The remainder of the frame is the audio, and the value should match the audio chunk size specified in the header.<br />
<br />
== Video Format ==<br />
A frame begins with a video frame and is possibly followed by audio. An individual video frame is completely intracoded (i.e., it does not depend on any other frames being decoded first). Each frame specifies its own width and height as well as an origin (x, y) coordinate that signals to the game engine where the frame should be placed on a scene.<br />
<br />
A video frame begins with the following 24-byte header:<br />
<br />
bytes 0-2 unknown<br />
byte 3 frame scaling factor<br />
bytes 4-5 frame width<br />
bytes 6-7 frame height<br />
bytes 8-11 unknown, often 0<br />
bytes 12-13 frame X coordinate<br />
bytes 14-15 frame Y coordinate<br />
bytes 16-17 size of compressed data in bytes<br />
bytes 18-19 number of frame fragments<br />
bytes 20-23 unknown<br />
<br />
The frame scaling factor is often 100, indicating 100% scaling (i.e., no scaling up or down). A scale factor of, e.g., 80 indicates that the decoded frame should be scaled to 80% of its full size.<br />
<br />
After the header is a series of compressed fragments, the count of which is specified in the frame header. Many frames have a single fragment but some have more. Each fragment begins with the following 10-byte header:<br />
<br />
bytes 0-3 fragment compressed size<br />
bytes 4-7 fragment decompressed size<br />
bytes 8-9 compression type<br />
<br />
Only 2 types of compression are known:<br />
* type 0: [https://en.wikipedia.org/wiki/Lempel%E2%80%93Ziv%E2%80%93Stac standard Lempel-Ziv-Stac (LZS) compression]<br />
* type 2: raw, uncompressed image<br />
<br />
== Audio Format ==<br />
The remainder of the frame contains audio. The audio portion begins with the following 8-byte header:<br />
<br />
bytes 0-3 unknown<br />
bytes 4-7 length of audio payload<br />
<br />
The audio data is compressed with [[Sierra DPCM]].<br />
<br />
== Versions and Games ==<br />
These are the known Robot format versions known to be associated with particular games and SCI engine revisions:<br />
<br />
* Version 4: [http://www.mobygames.com/game/daryl-f-gates-police-quest-swat Police Quest: SWAT] (demo)<br />
* Version 5: SCI 2.1 and SCI 3, including [http://www.mobygames.com/game/roberta-williams-phantasmagoria Phantasmagoria] and [http://www.mobygames.com/game/rama Rama]<br />
* Version 6: SCI 3<br />
<br />
[[Category:Game Formats]]</div>Multimedia Mikehttps://wiki.multimedia.cx/index.php?title=Sierra_DPCM&diff=15473Sierra DPCM2020-02-14T06:22:03Z<p>Multimedia Mike: one more format that can contain this audio type</p>
<hr />
<div>* Company: [[Sierra Entertainment]]<br />
<br />
This is a set of DPCM codecs used in [[Sierra Audio]], [[VMD]], and [[RBT]] files.<br />
<br />
=== Old DPCM ===<br />
Decoding of DPCM is very simple: read nibble, get corresponding delta value from table and update current sample value.<br />
<br />
Delta table:<br />
<br />
{ 0, 1, 2, 3, 6, 10, 15, 21,<br />
-21,-15,-10, -6, -3, -2, -1, -0}<br />
<br />
=== New DPCM ===<br />
New scheme differs from old one by delta table (note the order of its second part): <br />
<br />
{ 0, 1, 2, 3, 6, 10, 15, 21,<br />
-0, -1, -2, -3, -6, -10, -15, -21}<br />
<br />
=== 16-bit DPCM ===<br />
TODO<br />
<br />
[[Category:Audio Codecs]]<br />
[[Category:DPCM Audio Codecs]]<br />
[[Category:Game Formats]]</div>Multimedia Mikehttps://wiki.multimedia.cx/index.php?title=Robot_Animation&diff=15472Robot Animation2020-02-14T06:20:26Z<p>Multimedia Mike: /* Container Format */ clarify the fixed cel sizes based on the ScummVM source code</p>
<hr />
<div>* Extension: RBT<br />
* Company: [[Sierra Entertainment]]<br />
<br />
Robot files are animation files used in various Sierra computer games. It is a container format that encapsulates video and possibly audio.<br />
<br />
The details on this page were gleaned from [http://scummvm.org/ ScummVM] source code, which only covers version 5 of the format.<br />
<br />
== Container Format ==<br />
All multi-byte numbers are little-endian.<br />
<br />
The general organization of a Robot file is as follows:<br />
<br />
<header><br />
<unknown block><br />
<palette><br />
<video frame size table><br />
<frame size table><br />
<unknown tables><br />
<padding><br />
<frame 1><br />
<frame 2><br />
...<br />
<frame n><br />
<br />
A Robot file begins with the following variable-length header.<br />
<br />
bytes 0-5 signature and probably a version (16 00 53 4f 4c 00; bytes 2-4 are 'SOL')<br />
bytes 6-7 version<br />
bytes 8-9 audio chunk size<br />
bytes 10-11 silence chunk size<br />
bytes 12-13 unknown<br />
bytes 14-15 frame count<br />
bytes 16-17 palette data size<br />
bytes 18-19 unknown chunk data size<br />
bytes 20-21 X resolution<br />
bytes 22-23 Y resolution<br />
byte 24 has palette<br />
byte 25 has sound<br />
bytes 26-27 unknown<br />
bytes 28-29 framerate<br />
bytes 30-31 is HiRes<br />
bytes 32-33 max skippable packets<br />
bytes 34-35 max cels per frame<br />
bytes 36-39 the maximum possible size, in bytes, of the first fixed cel<br />
bytes 40-43 the maximum possible size, in bytes, of the second fixed cel<br />
bytes 44-47 the maximum possible size, in bytes, of the third fixed cel<br />
bytes 48-51 the maximum possible size, in bytes, of the fourth fixed cel<br />
bytes 52-59 unknown<br />
bytes 60.. unknown data chunk, size defined by bytes 18-19<br />
<br />
After the header is a palette chunk. The size of the palette chunk is defined it bytes 16-17 of the header. The first 37 or 38 bytes have the following format:<br />
<br />
bytes 0-24 unknown<br />
byte 25 first palette index to replace<br />
bytes 29-30 palette count<br />
byte 32 palette format (0 = variable, 1 = constant)<br />
bytes 33-[36,37] unknown<br />
byte [37,38].. palette components<br />
<br />
The palette is 256 total entries, though the palette encoded in this chunk is only likely to encode a partial palette since the other colors are reserved for other parts of the game's user interface.<br />
<br />
Replace (palette count) entries in the palette starting with the index specified by byte 25. The palette components are ordered red - green - blue - red - green - blue - etc. The palette components begin at index 37 for constant palettes and 38 for variable palettes.<br />
<br />
Each palette component is 8 bits.<br />
<br />
Following the palette chunk is 2 size tables: the first is the video frame size table and the second is the size table. Each table contains one 16-bit size value for each frame in the file (the frame count is defined in bytes 14-15 of the header).<br />
<br />
Following the 2 size tables is more undefined data that has a constant size of 1536 bytes. Reverse engineering efforts indicate that this is a 1024-byte table followed by a 512-byte table.<br />
<br />
Finally, there is padding before the frames. The first frame is aligned on a 2048-byte boundary (perhaps a CD sector boundary). Thus, after reading the previous unknown data, advance the file (0x800 - (current_offset(rbt_file) & 0x7ff)) bytes.<br />
<br />
Then there the sequence of frames, the count of which is defined in the header. Each frame contains video and also audio, if the header indicates that the file contains sound. The size of the entire frame corresponds to the frame's entry in the frame size table. The video comes first and the size of the video portion corresponds to the frame's entry is the video frame size table. The remainder of the frame is the audio, and the value should match the audio chunk size specified in the header.<br />
<br />
== Video Format ==<br />
A frame begins with a video frame and is possibly followed by audio. An individual video frame is completely intracoded (i.e., it does not depend on any other frames being decoded first). Each frame specifies its own width and height as well as an origin (x, y) coordinate that signals to the game engine where the frame should be placed on a scene.<br />
<br />
A video frame begins with the following 24-byte header:<br />
<br />
bytes 0-2 unknown<br />
byte 3 frame scaling factor<br />
bytes 4-5 frame width<br />
bytes 6-7 frame height<br />
bytes 8-11 unknown, often 0<br />
bytes 12-13 frame X coordinate<br />
bytes 14-15 frame Y coordinate<br />
bytes 16-17 size of compressed data in bytes<br />
bytes 18-19 number of frame fragments<br />
bytes 20-23 unknown<br />
<br />
The frame scaling factor is often 100, indicating 100% scaling (i.e., no scaling up or down). A scale factor of, e.g., 80 indicates that the decoded frame should be scaled to 80% of its full size.<br />
<br />
After the header is a series of compressed fragments, the count of which is specified in the frame header. Many frames have a single fragment but some have more. Each fragment begins with the following 10-byte header:<br />
<br />
bytes 0-3 fragment compressed size<br />
bytes 4-7 fragment decompressed size<br />
bytes 8-9 compression type<br />
<br />
Only 2 types of compression are known:<br />
* type 0: [https://en.wikipedia.org/wiki/Lempel%E2%80%93Ziv%E2%80%93Stac standard Lempel-Ziv-Stac (LZS) compression]<br />
* type 2: raw, uncompressed image<br />
<br />
== Audio Format ==<br />
The remainder of the frame contains audio. The audio portion begins with the following 8-byte header:<br />
<br />
bytes 0-3 unknown<br />
bytes 4-7 length of audio payload<br />
<br />
The audio data is uncompressed PCM.<br />
<br />
== Versions and Games ==<br />
These are the known Robot format versions known to be associated with particular games and SCI engine revisions:<br />
<br />
* Version 4: [http://www.mobygames.com/game/daryl-f-gates-police-quest-swat Police Quest: SWAT] (demo)<br />
* Version 5: SCI 2.1 and SCI 3, including [http://www.mobygames.com/game/roberta-williams-phantasmagoria Phantasmagoria] and [http://www.mobygames.com/game/rama Rama]<br />
* Version 6: SCI 3<br />
<br />
[[Category:Game Formats]]</div>Multimedia Mikehttps://wiki.multimedia.cx/index.php?title=Robot_Animation&diff=15471Robot Animation2020-02-14T05:18:20Z<p>Multimedia Mike: /* Audio Format */ describe audio header format</p>
<hr />
<div>* Extension: RBT<br />
* Company: [[Sierra Entertainment]]<br />
<br />
Robot files are animation files used in various Sierra computer games. It is a container format that encapsulates video and possibly audio.<br />
<br />
The details on this page were gleaned from [http://scummvm.org/ ScummVM] source code, which only covers version 5 of the format.<br />
<br />
== Container Format ==<br />
All multi-byte numbers are little-endian.<br />
<br />
The general organization of a Robot file is as follows:<br />
<br />
<header><br />
<unknown block><br />
<palette><br />
<video frame size table><br />
<frame size table><br />
<unknown tables><br />
<padding><br />
<frame 1><br />
<frame 2><br />
...<br />
<frame n><br />
<br />
A Robot file begins with the following variable-length header.<br />
<br />
bytes 0-5 signature and probably a version (16 00 53 4f 4c 00; bytes 2-4 are 'SOL')<br />
bytes 6-7 version<br />
bytes 8-9 audio chunk size<br />
bytes 10-11 silence chunk size<br />
bytes 12-13 unknown<br />
bytes 14-15 frame count<br />
bytes 16-17 palette data size<br />
bytes 18-19 unknown chunk data size<br />
bytes 20-21 X resolution<br />
bytes 22-23 Y resolution<br />
byte 24 has palette<br />
byte 25 has sound<br />
bytes 26-27 unknown<br />
bytes 28-29 framerate<br />
bytes 30-31 is HiRes<br />
bytes 32-33 max skippable packets<br />
bytes 34-35 max cels per frame<br />
bytes 36-39 pre-allocation of memory for fixed cels<br />
bytes 40-43 pre-allocation of memory for fixed cels<br />
bytes 44-47 pre-allocation of memory for fixed cels<br />
bytes 48-51 pre-allocation of memory for fixed cels<br />
bytes 52-59 unknown<br />
bytes 60.. unknown data chunk, size defined by bytes 18-19<br />
<br />
After the header is a palette chunk. The size of the palette chunk is defined it bytes 16-17 of the header. The first 37 or 38 bytes have the following format:<br />
<br />
bytes 0-24 unknown<br />
byte 25 first palette index to replace<br />
bytes 29-30 palette count<br />
byte 32 palette format (0 = variable, 1 = constant)<br />
bytes 33-[36,37] unknown<br />
byte [37,38].. palette components<br />
<br />
The palette is 256 total entries, though the palette encoded in this chunk is only likely to encode a partial palette since the other colors are reserved for other parts of the game's user interface.<br />
<br />
Replace (palette count) entries in the palette starting with the index specified by byte 25. The palette components are ordered red - green - blue - red - green - blue - etc. The palette components begin at index 37 for constant palettes and 38 for variable palettes.<br />
<br />
Each palette component is 8 bits.<br />
<br />
Following the palette chunk is 2 size tables: the first is the video frame size table and the second is the size table. Each table contains one 16-bit size value for each frame in the file (the frame count is defined in bytes 14-15 of the header).<br />
<br />
Following the 2 size tables is more undefined data that has a constant size of 1536 bytes. Reverse engineering efforts indicate that this is a 1024-byte table followed by a 512-byte table.<br />
<br />
Finally, there is padding before the frames. The first frame is aligned on a 2048-byte boundary (perhaps a CD sector boundary). Thus, after reading the previous unknown data, advance the file (0x800 - (current_offset(rbt_file) & 0x7ff)) bytes.<br />
<br />
Then there the sequence of frames, the count of which is defined in the header. Each frame contains video and also audio, if the header indicates that the file contains sound. The size of the entire frame corresponds to the frame's entry in the frame size table. The video comes first and the size of the video portion corresponds to the frame's entry is the video frame size table. The remainder of the frame is the audio, and the value should match the audio chunk size specified in the header.<br />
<br />
== Video Format ==<br />
A frame begins with a video frame and is possibly followed by audio. An individual video frame is completely intracoded (i.e., it does not depend on any other frames being decoded first). Each frame specifies its own width and height as well as an origin (x, y) coordinate that signals to the game engine where the frame should be placed on a scene.<br />
<br />
A video frame begins with the following 24-byte header:<br />
<br />
bytes 0-2 unknown<br />
byte 3 frame scaling factor<br />
bytes 4-5 frame width<br />
bytes 6-7 frame height<br />
bytes 8-11 unknown, often 0<br />
bytes 12-13 frame X coordinate<br />
bytes 14-15 frame Y coordinate<br />
bytes 16-17 size of compressed data in bytes<br />
bytes 18-19 number of frame fragments<br />
bytes 20-23 unknown<br />
<br />
The frame scaling factor is often 100, indicating 100% scaling (i.e., no scaling up or down). A scale factor of, e.g., 80 indicates that the decoded frame should be scaled to 80% of its full size.<br />
<br />
After the header is a series of compressed fragments, the count of which is specified in the frame header. Many frames have a single fragment but some have more. Each fragment begins with the following 10-byte header:<br />
<br />
bytes 0-3 fragment compressed size<br />
bytes 4-7 fragment decompressed size<br />
bytes 8-9 compression type<br />
<br />
Only 2 types of compression are known:<br />
* type 0: [https://en.wikipedia.org/wiki/Lempel%E2%80%93Ziv%E2%80%93Stac standard Lempel-Ziv-Stac (LZS) compression]<br />
* type 2: raw, uncompressed image<br />
<br />
== Audio Format ==<br />
The remainder of the frame contains audio. The audio portion begins with the following 8-byte header:<br />
<br />
bytes 0-3 unknown<br />
bytes 4-7 length of audio payload<br />
<br />
The audio data is uncompressed PCM.<br />
<br />
== Versions and Games ==<br />
These are the known Robot format versions known to be associated with particular games and SCI engine revisions:<br />
<br />
* Version 4: [http://www.mobygames.com/game/daryl-f-gates-police-quest-swat Police Quest: SWAT] (demo)<br />
* Version 5: SCI 2.1 and SCI 3, including [http://www.mobygames.com/game/roberta-williams-phantasmagoria Phantasmagoria] and [http://www.mobygames.com/game/rama Rama]<br />
* Version 6: SCI 3<br />
<br />
[[Category:Game Formats]]</div>Multimedia Mikehttps://wiki.multimedia.cx/index.php?title=Robot_Animation&diff=15470Robot Animation2020-02-14T00:51:54Z<p>Multimedia Mike: more details determined, thanks to ScummVM</p>
<hr />
<div>* Extension: RBT<br />
* Company: [[Sierra Entertainment]]<br />
<br />
Robot files are animation files used in various Sierra computer games. It is a container format that encapsulates video and possibly audio.<br />
<br />
The details on this page were gleaned from [http://scummvm.org/ ScummVM] source code, which only covers version 5 of the format.<br />
<br />
== Container Format ==<br />
All multi-byte numbers are little-endian.<br />
<br />
The general organization of a Robot file is as follows:<br />
<br />
<header><br />
<unknown block><br />
<palette><br />
<video frame size table><br />
<frame size table><br />
<unknown tables><br />
<padding><br />
<frame 1><br />
<frame 2><br />
...<br />
<frame n><br />
<br />
A Robot file begins with the following variable-length header.<br />
<br />
bytes 0-5 signature and probably a version (16 00 53 4f 4c 00; bytes 2-4 are 'SOL')<br />
bytes 6-7 version<br />
bytes 8-9 audio chunk size<br />
bytes 10-11 silence chunk size<br />
bytes 12-13 unknown<br />
bytes 14-15 frame count<br />
bytes 16-17 palette data size<br />
bytes 18-19 unknown chunk data size<br />
bytes 20-21 X resolution<br />
bytes 22-23 Y resolution<br />
byte 24 has palette<br />
byte 25 has sound<br />
bytes 26-27 unknown<br />
bytes 28-29 framerate<br />
bytes 30-31 is HiRes<br />
bytes 32-33 max skippable packets<br />
bytes 34-35 max cels per frame<br />
bytes 36-39 pre-allocation of memory for fixed cels<br />
bytes 40-43 pre-allocation of memory for fixed cels<br />
bytes 44-47 pre-allocation of memory for fixed cels<br />
bytes 48-51 pre-allocation of memory for fixed cels<br />
bytes 52-59 unknown<br />
bytes 60.. unknown data chunk, size defined by bytes 18-19<br />
<br />
After the header is a palette chunk. The size of the palette chunk is defined it bytes 16-17 of the header. The first 37 or 38 bytes have the following format:<br />
<br />
bytes 0-24 unknown<br />
byte 25 first palette index to replace<br />
bytes 29-30 palette count<br />
byte 32 palette format (0 = variable, 1 = constant)<br />
bytes 33-[36,37] unknown<br />
byte [37,38].. palette components<br />
<br />
The palette is 256 total entries, though the palette encoded in this chunk is only likely to encode a partial palette since the other colors are reserved for other parts of the game's user interface.<br />
<br />
Replace (palette count) entries in the palette starting with the index specified by byte 25. The palette components are ordered red - green - blue - red - green - blue - etc. The palette components begin at index 37 for constant palettes and 38 for variable palettes.<br />
<br />
Each palette component is 8 bits.<br />
<br />
Following the palette chunk is 2 size tables: the first is the video frame size table and the second is the size table. Each table contains one 16-bit size value for each frame in the file (the frame count is defined in bytes 14-15 of the header).<br />
<br />
Following the 2 size tables is more undefined data that has a constant size of 1536 bytes. Reverse engineering efforts indicate that this is a 1024-byte table followed by a 512-byte table.<br />
<br />
Finally, there is padding before the frames. The first frame is aligned on a 2048-byte boundary (perhaps a CD sector boundary). Thus, after reading the previous unknown data, advance the file (0x800 - (current_offset(rbt_file) & 0x7ff)) bytes.<br />
<br />
Then there the sequence of frames, the count of which is defined in the header. Each frame contains video and also audio, if the header indicates that the file contains sound. The size of the entire frame corresponds to the frame's entry in the frame size table. The video comes first and the size of the video portion corresponds to the frame's entry is the video frame size table. The remainder of the frame is the audio, and the value should match the audio chunk size specified in the header.<br />
<br />
== Video Format ==<br />
A frame begins with a video frame and is possibly followed by audio. An individual video frame is completely intracoded (i.e., it does not depend on any other frames being decoded first). Each frame specifies its own width and height as well as an origin (x, y) coordinate that signals to the game engine where the frame should be placed on a scene.<br />
<br />
A video frame begins with the following 24-byte header:<br />
<br />
bytes 0-2 unknown<br />
byte 3 frame scaling factor<br />
bytes 4-5 frame width<br />
bytes 6-7 frame height<br />
bytes 8-11 unknown, often 0<br />
bytes 12-13 frame X coordinate<br />
bytes 14-15 frame Y coordinate<br />
bytes 16-17 size of compressed data in bytes<br />
bytes 18-19 number of frame fragments<br />
bytes 20-23 unknown<br />
<br />
The frame scaling factor is often 100, indicating 100% scaling (i.e., no scaling up or down). A scale factor of, e.g., 80 indicates that the decoded frame should be scaled to 80% of its full size.<br />
<br />
After the header is a series of compressed fragments, the count of which is specified in the frame header. Many frames have a single fragment but some have more. Each fragment begins with the following 10-byte header:<br />
<br />
bytes 0-3 fragment compressed size<br />
bytes 4-7 fragment decompressed size<br />
bytes 8-9 compression type<br />
<br />
Only 2 types of compression are known:<br />
* type 0: [https://en.wikipedia.org/wiki/Lempel%E2%80%93Ziv%E2%80%93Stac standard Lempel-Ziv-Stac (LZS) compression]<br />
* type 2: raw, uncompressed image<br />
<br />
== Audio Format ==<br />
The remainder of the frame contains audio. The audio portion begins with an 8-byte header of an unknown format. The audio data is uncompressed PCM.<br />
<br />
== Versions and Games ==<br />
These are the known Robot format versions known to be associated with particular games and SCI engine revisions:<br />
<br />
* Version 4: [http://www.mobygames.com/game/daryl-f-gates-police-quest-swat Police Quest: SWAT] (demo)<br />
* Version 5: SCI 2.1 and SCI 3, including [http://www.mobygames.com/game/roberta-williams-phantasmagoria Phantasmagoria] and [http://www.mobygames.com/game/rama Rama]<br />
* Version 6: SCI 3<br />
<br />
[[Category:Game Formats]]</div>Multimedia Mikehttps://wiki.multimedia.cx/index.php?title=Mirrored_Files&diff=15453Mirrored Files2019-09-28T03:47:45Z<p>Multimedia Mike: mirror the latest A-52 spec</p>
<hr />
<div>This is a list of official technical documents that are mirrored at multimedia.cx for convenience or archival: http://multimedia.cx/mirror/<br />
<br />
Contact [[User:Multimedia Mike|Multimedia Mike]] in order to add documents to the mirror.<br />
<br />
* [[A52]]:<br />
** 2018 Revision:<br />
*** mirror: https://multimedia.cx/mirror/A52-2018.pdf<br />
*** original: https://www.atsc.org/wp-content/uploads/2015/03/A52-2018.pdf<br />
** Revision B:<br />
*** mirror: http://multimedia.cx/mirror/a_52b.pdf<br />
*** original: [offline]<br />
<br />
* [[Apple Core Audio Format]] specification, dated 2006-03-08:<br />
** mirror: http://multimedia.cx/mirror/CAFSpec-2006-03-08.pdf<br />
** original: http://developer.apple.com/documentation/MusicAudio/Reference/CAFSpec/index.html<br />
<br />
* Apple [[QuickTime container]] specification, dated 2007-09-04:<br />
** mirror: http://multimedia.cx/mirror/qtff-2007-09-04.pdf<br />
** original: http://developer.apple.com/mac/library/documentation/QuickTime/QTFF<br />
<br />
* [[Audio Interchange File Format]]:<br />
** mirror: http://multimedia.cx/mirror/AudioIFF1_2_1.htm<br />
<br />
* [[Cinepak]]:<br />
** mirror: http://multimedia.cx/mirror/cinepak.txt<br />
** original: http://www.csse.monash.edu.au/%7etimf/videocodec/cinepak.txt<br />
<br />
* [[CYUV]]:<br />
** mirror: http://multimedia.cx/mirror/cyuv.txt<br />
** original: http://www.csse.monash.edu.au/~timf/videocodec/cyuv.txt<br />
<br />
* [[Dialogic IMA ADPCM]]:<br />
** mirror: http://multimedia.cx/mirror/dialogic-adpcm.pdf<br />
<br />
* [[DTS]]:<br />
** mirror (whitepaper): http://multimedia.cx/mirror/dts-whitepaper.pdf<br />
** mirror (document 1): http://multimedia.cx/mirror/dts1.pdf<br />
** mirror (document 2): http://multimedia.cx/mirror/dts2.pdf<br />
** mirror (DTS patent application, scans, 550 pages, 54 MB PDF): http://multimedia.cx/mirror/EP864146-53.pdf<br />
** mirror (DCA transform): http://multimedia.cx/mirror/dca-transform.pdf<br />
** Specification v1.4.1, 2012-09: http://multimedia.cx/mirror/ts_102114v010401p.pdf<br />
<br />
* [[H264]] draft specification, marked 2002 (E):<br />
** mirror: http://multimedia.cx/mirror/JVT-G050.pdf<br />
<br />
* [[IBM UltiMotion]] specification:<br />
** mirror: http://multimedia.cx/mirror/UMSPEC.ZIP<br />
<br />
* Id [[CIN]]:<br />
** mirror: http://multimedia.cx/mirror/idcin.html<br />
** original: http://www.csse.monash.edu.au/~timf/videocodec/idcin.html<br />
<br />
* Id [[RoQ]]:<br />
** mirror: http://multimedia.cx/mirror/idroq.txt<br />
** original: http://www.csse.monash.edu.au/~timf/videocodec/idroq.txt<br />
** sample decoder source code: http://multimedia.cx/mirror/idroq.tar.gz<br />
<br />
* [[Indeo 3]]:<br />
** mirror (partial specification): http://multimedia.cx/mirror/5386232.pdf<br />
** mirror (header explanation): http://multimedia.cx/mirror/indeo3.txt<br />
** original (header explanation): http://www.csse.monash.edu.au/~timf/videocodec/indeo3.txt<br />
<br />
* [[Meridian Lossless Packing]] whitepaper:<br />
** mirror: http://multimedia.cx/mirror/mlp_jap_new.PDF<br />
** original: http://www.meridian-audio.com/w_paper/mlp_jap_new.PDF<br />
<br />
* [[Nokia MVC]]:<br />
** documentation:<br />
*** original: http://ftp3.itu.ch/av-arch/video-site/0005_Osa/q15j19.doc<br />
*** mirror: http://multimedia.cx/mirror/q15j19.doc<br />
** reference codec:<br />
*** original: http://ftp3.itu.ch/av-arch/video-site/0005_Osa/q15j20.zip<br />
*** mirror: http://multimedia.cx/mirror/q15j20.zip<br />
<br />
* [[Nullsoft Video]]:<br />
** documentation:<br />
*** mirror: http://multimedia.cx/mirror/NSVFormat.rtf<br />
<br />
* [[On2 VP3]]:<br />
** Binary Downloads<br />
*** [http://multimedia.cx/mirror/vpvision/On2VP3VideoForWindows.exe On2 VP3 Video for Windows installer (1.2MB)]<br />
*** [http://multimedia.cx/mirror/vpvision/VpV05install.exe VPVision installer (4.6MB)]<br />
*** [http://multimedia.cx/mirror/vpvision/readme.txt readme.txt]<br />
*** [http://multimedia.cx/mirror/vpvision/readmefirst.txt readmefirst.txt]<br />
** Source Code Downloads<br />
*** [http://multimedia.cx/mirror/vpvision/source/vp32.tar.gz VP3.2 Codec source code (compressed TAR format, 1.1MB)]<br />
*** [http://multimedia.cx/mirror/vpvision/source/vpvision0.5_source.zip VPVision source code (ZIP archive, 5.2MB)]<br />
*** [http://multimedia.cx/mirror/vpvision/source/vorbis_nodebug_tc40_vp0.5rc.zip Vorbis (ZIP archive, 12.7MB)]<br />
*** [http://multimedia.cx/mirror/vpvision/source/readme.txt readme.txt]<br />
*** [http://multimedia.cx/mirror/vpvision/source/readmefirst.txt readmefirst.txt]<br />
<br />
* [[On2 VP6]]:<br />
** VP6 Bitstream & Decoding Specification<br />
*** mirror: http://multimedia.cx/mirror/vp6_format.pdf<br />
** whitepaper:<br />
*** mirror: http://multimedia.cx/mirror/vp6-white-paper.pdf<br />
*** original: http://www.on2.com/cms-data/pdf/1125607149174329.pdf<br />
<br />
* [[On2 VP7]]:<br />
** VP7 Data Format and Decoder<br />
*** mirror: http://multimedia.cx/mirror/VP7_Data_Format_and_Decoder_Overview.pdf<br />
** whitepaper:<br />
*** mirror: http://multimedia.cx/mirror/vp7-white-paper.pdf<br />
*** original: http://www.on2.com/cms-data/pdf/1123531744838491.pdf<br />
<br />
* [[PVA]] specification:<br />
** mirror: http://multimedia.cx/mirror/av_format_v1.pdf<br />
<br />
* [[RealAudio 14.4]]:<br />
** mirror: http://multimedia.cx/mirror/spra136.pdf<br />
** original: http://focus.ti.com/lit/an/spra136/spra136.pdf<br />
<br />
* [[RealVideo]] document assortment ([http://multimedia.cx/eggs/official-realvideo-specifications/ described in this blog post]):<br />
** mirror: http://multimedia.cx/mirror/realvideo/<br />
** original: https://rarvcode-video.helixcommunity.org/files/Docs/<br />
<br />
* [[Sonarc]] lossless audio v2.1i software<br />
** mirror: http://multimedia.cx/mirror/snrc21i.zip<br />
** original: ftp://ftp.elf.stuba.sk/pub/pc/pack/snrc21i.zip<br />
<br />
* [[VC-1]] (a.k.a. VC-9) draft specification:<br />
** mirror: draft dated 2006-02-24: http://multimedia.cx/mirror/VC-1_Compressed_Video_Bitstream_Format_and_Decoding_Process.pdf<br />
** mirror: draft dated 2005-08-23: http://multimedia.cx/mirror/s421m.pdf<br />
** mirror: draft dated 2004-03-31: http://multimedia.cx/mirror/C24.008-VC9-Spec-CD1.pdf<br />
** reference source code mirror: http://multimedia.cx/mirror/VC1_reference_decoder_release6.zip</div>Multimedia Mikehttps://wiki.multimedia.cx/index.php?title=A52&diff=15452A522019-09-28T03:45:47Z<p>Multimedia Mike: more recent spec</p>
<hr />
<div>* Codec ID: 0x2000<br />
* Specification for A/52 (2018): https://www.atsc.org/wp-content/uploads/2015/03/A52-2018.pdf ([[Mirrored Files|mirrored]])<br />
* Encoding / decoding Guidelines: http://www.dolby.com/assets/pdf/tech_library/46_DDEncodingGuidelines.pdf<br />
* Short description: http://focus.ti.com/lit/an/spra724/spra724.pdf<br />
<br />
==AC3==<br />
ATSC A/52a is a standard for lossy encoding of audio in digital television broadcasting in the United States. It is the same as Dolby Digital AC3.<br />
<br />
==EAC3==<br />
ATSC A/52b is an extension to A/52a and was approved for the [[Blu-ray]] and [[HD DVD]] standard. It is the same as Enhanced AC3 or EAC3 for short. EAC3 is also supposed to be backwards compatible with AC3. But that is not the case, you have to transcode somewhere in the middle of the decode process.<br />
<br />
[[Category: Audio Codecs]]<br />
[[Category: MDCT Audio Codecs]]<br />
[[Category: Multichannel Audio Codecs]]</div>Multimedia Mikehttps://wiki.multimedia.cx/index.php?title=ZECO&diff=15437ZECO2019-04-29T05:20:03Z<p>Multimedia Mike: new FourCC for the catalog</p>
<hr />
<div>#redirect [[ZeroCodec]]<br />
<br />
[[Category:Video FourCCs]]</div>Multimedia Mikehttps://wiki.multimedia.cx/index.php?title=LCKK&diff=15434LCKK2019-04-29T04:56:20Z<p>Multimedia Mike: new FourCC for the catalog</p>
<hr />
<div>#redirect [[Toponoky]]<br />
<br />
[[Category:Video FourCCs]]</div>Multimedia Mikehttps://wiki.multimedia.cx/index.php?title=Duck_TrueMotion_1&diff=15376Duck TrueMotion 12018-09-06T03:21:24Z<p>Multimedia Mike: /* Games Using Duck TrueMotion 1 */ update known game list</p>
<hr />
<div>* FOURCCs: DUCK,PVEZ<br />
* Company: [[On2|On2 (formerly Duck)]]<br />
* Patents: US #6,181,822, "Data compression apparatus and method"<br />
* Samples: http://samples.mplayerhq.hu/V-codecs/DUCK/<br />
<br />
Duck TrueMotion 1 (TM1) is the first video codec developed by The Duck Corporation. It uses [[Differential Coding|differential pulse code modulation]] and interframe differencing. The primary application for which Duck TrueMotion 1 was developed is gaming software, typically on PC or Sega Saturn titles.<br />
<br />
== Underlying Concepts ==<br />
<br />
TM1 operates on bidirectional delta quantization. The mathematical premise of delta coding is simple addition. For example, take the following sequence of numbers:<br />
<br />
82 84 81 80 86 88 85<br />
<br />
All of the numbers are reasonably large (on a scale of 0..255 in this example). However, they are quite similar to each other. Using delta coding, only the differences between successive numbers are stored:<br />
<br />
82 +2 -3 -1 +6 +2 -3<br />
<br />
The first number is still large but since the remaining numbers are clustered close to each other, the deltas are relatively small. Thus, the deltas require less information to encode. <br />
<br />
TM1 takes this concept and extends it to 2 dimensions. A particular pixel is assumed to have a pixel directly above it and a pixel directly to the left (if neither of these pixels exist in the frame, e.g., for the top-left corner pixel, 0 is used in place of the non-existant pixels). The current pixel is decoded as the sum of the up and left pixels, plus a delta from the encoded video bitstream.<br />
<br />
encoded video bitstream: ...D5 D6 D7 D8...<br />
<br />
decoded video frame:<br />
A B C D<br />
E F G H<br />
<br />
In this example, the encoded video bitstream is sitting at delta D5 when it is time to decode pixel E. A is the pixel above E. There is no pixel to the left of E, so 0 is used as the left value. Thus:<br />
<br />
E = A + 0 + D5<br />
<br />
In the case of pixel F, both the up and left pixel values (called the vertical and horizontal predictors, respectively) are available:<br />
<br />
F = B + E + D6<br />
<br />
That is the general idea behind decoding TM1 data. The actual decoding algorithm is more involved. The TM1 bytestream actually contains a series of indices that point into tables with the delta values to be<br />
applied to the vertical and horizontal predictor pixels. These tables only specify small deltas to be added to pixel predictors. When a larger delta is needed because the delta between 2 numbers is too large, then a special bytestream code indicates that the next delta is to be multiplied by 5 before it is applied.<br />
<br />
TM1 operates on 4x4 macroblocks of pixels. Each block in a frame can be broken into 4 2x2 blocks, 2 halves (either 4x2 or 2x4), or encoded as a 4x4 block. The block type is encoded in the frame header.<br />
<br />
While the TM1 algorithm operates on RGB colorspace data at the input and output level, it borrows some ideas from YUV colorspaces. For more information of RGB and YUV colorspaces, see the References section.<br />
<br />
TM1 uses a modified colorspace that embodies luminance (Y) and chrominance (C) information encoded as RGB deltas. Since Y information is more important to the human eye than C information, the Y data must be updated more frequently than the C data (i.e., more Y predictors than C predictors are applied to the image). For a every pixel within a given block in a macroblock, a Y predictor must be applied. However, only one C predictor is applied for each block in the macroblock.<br />
<br />
== TrueMotion v1 Frame Format and Header ==<br />
<br />
All multi-byte numbers are stored in little endian format.<br />
<br />
An encoded intraframe (keyframe) of TM1 data is laid out as:<br />
<br />
header | predictor indices<br />
<br />
An encoded interframe is laid out as:<br />
<br />
header | block change bits | predictor indices<br />
<br />
The difference between the 2 types of frames is that an interframe has a section of bits that specify which blocks in the frame are unchanged from the previous frame.<br />
<br />
A TM1 header is quasi-encrypted with a logical XOR operation. This is probably done to provide some obfuscation of the header and thwart casual inspection of the data format.<br />
<br />
An encoded TM1 frame begins with the one byte that indicates the length of the decrypted header, only with a dummy high bit and rotated left by 5. To obtain the actual length from byte B:<br />
<br />
L = ((B >> 5) | (B << 3)) & 0x7F<br />
<br />
Then, decrypt the header by starting with byte 1 in the encoded frame (indexing from 0) and XORing each byte with its successive byte. Assuming the header is of length L bytes as computed above, and that the encoded header starts at buffer[1] (buffer[0] had the rotated length), the decode process is:<br />
<br />
for (i = 1; i < L; i++)<br />
decoded_header[i - 1] = buffer[i] ^ buffer[i + 1];<br />
<br />
The decoded header data structure is laid out as follows:<br />
<br />
byte 0 compression method<br />
byte 1 delta set<br />
byte 2 vector set<br />
bytes 3-4 frame height<br />
bytes 5-6 frame width<br />
bytes 7-8 checksum<br />
byte 9 version<br />
byte 10 header type<br />
byte 11 flags<br />
byte 12 control<br />
bytes 13-14 x offset<br />
bytes 15-16 y offset<br />
bytes 17-18 width<br />
bytes 19-20 height<br />
<br />
The compression method field indicates the type of compression used to encode this frame. There are 2 general types: 16-bit and 24-bit. Further, each has 4 block sizes to select from. The valid compression types are<br />
<br />
0, 9, 11, 13, 15: NOP frames; frame is unchanged from previous frame<br />
1: 16-bit 4x4 (V)<br />
2: 16-bit 4x4 (H)<br />
3: 16-bit 4x2 (V)<br />
4: 16-bit 4x2 (H)<br />
5: 16-bit 2x4 (V)<br />
6: 16-bit 2x4 (H)<br />
7: 16-bit 2x2 (V)<br />
8: 16-bit 2x2 (H)<br />
10: 24-bit 4x4 (H)<br />
12: 24-bit 4x2 (H)<br />
14: 24-bit 2x4 (H)<br />
16: 24-bit 2x2 (H)<br />
>16: invalid compression type<br />
<br />
The (H) and (V) designations come from the original Duck source code. It is unclear what they mean, except for the common horizontal and vertical designations common in video terminology.<br />
<br />
The delta set and vector set fields are used to generate the set of predictor tables that will be used to decode this frame.<br />
<br />
The height and width fields should be the same as those specified in the AVI file that contains the data.<br />
<br />
The checksum field appears to contain the frame's sequence number modulo 512. The first frame is 0x0000 and the next frame is 0x0001. Frame #511 has a checksum of 0x01FF while frame #512 wraps around to 0x0000.<br />
<br />
If the version field is less than 2, then the frame is intracoded (this may indicate that early versions of the coding method was purely intracoded). If the version field is greater than or equal to 2, then if the header type field is 2 or 3, the flags field has bit 4 set (flags & 0x10) to indicate an intraframe; else if the header type field is greater than 3, then the header is invalid; else the frame is intracoded.<br />
<br />
The purpose of the control field is unclear.<br />
<br />
The x & y offset, width, and height fields apparently pertain to a sprite mode that is not covered in this document.<br />
<br />
== 16-bit Data ==<br />
<br />
Decoding a 16-bit frame requires 2 tables. The tables can change from one frame to the next and must be rebuilt if the header specified a new table. One table contains the C predictors while the other contains the Y predictors.<br />
<br />
Each table consists of 1024 32-bit entries. Each group of 4 entries corresponds to a byte index from 0..255. Each entry contains a double pixel predictor shifted left by one. If the very last bit (bit 0) in the 32-bit entry is 0, then there is another predictor for that index. If the last bit is 1, then this predictor is the last one for this list.<br />
<br />
For example...<br />
<br />
A B C D ...<br />
E F G H ...<br />
I J K L ...<br />
M N O P ...<br />
<br />
'''(UNFINISHED)'''<br />
<br />
== 24-bit Data ==<br />
<br />
The process of decoding a 24-bit frame is similar to that of decoding a 16-bit frame. However, the frame is decoded into 2 separate planes, a Y plane and a C plane, and recombined into a final RGB map at render time.<br />
<br />
'''(UNFINISHED)'''<br />
<br />
== Duck TrueMotion v1 Tables ==<br />
<br />
[http://svn.mplayerhq.hu/ffmpeg/trunk/libavcodec/truemotion1data.h?view=markup&rev=4679 http://svn.mplayerhq.hu/ffmpeg/trunk/libavcodec/truemotion1data.h?view=markup&rev=4679]<br />
<br />
== Games Using Duck TrueMotion 1 ==<br />
These software titles are known to use the Duck TrueMotion 1 video codec to encode full motion video:<br />
<br />
* [https://www.mobygames.com/game/bubble-bobble-also-featuring-rainbow-islandsBubble Bobble special CD release with Rainbow Island (DOS)]<br />
* [https://www.mobygames.com/game/saturn/blazing-dragons Blazing Dragons (Sega Saturn)]<br />
* [https://www.mobygames.com/game/sega-saturn/congo-the-movie-the-lost-city-of-zinj Congo: The Movie - The Lost City of Zinj (Sega Saturn)]<br />
* [https://www.mobygames.com/game/dos/d D (DOS version only)]<br />
* [https://www.mobygames.com/game/saturn/horde The Horde (Sega Saturn)]<br />
* [https://www.mobygames.com/game/saturn/nhl-all-star-hockey NHL All-Star Hockey (Sega Saturn)]<br />
* [https://www.mobygames.com/game/phantasmagoria-a-puzzle-of-flesh Phantasmagoria: A Puzzle of Flesh (DOS & Windows)]<br />
* [https://www.mobygames.com/game/santa-fe-mysteries-the-elk-moon-murder Santa Fe Mysteries: The Elk Moon Murder (DOS & Windows)]<br />
* [https://www.mobygames.com/game/saturn/solar-eclipse Solar Eclipse (Sega Saturn)]<br />
* [https://www.mobygames.com/game/saturn/sonic-3d-blast Sonic 3D Blast (Sega Saturn)]<br />
* [https://www.mobygames.com/game/spycraft-the-great-game Spycraft: The Great Game (DOS & Windows)]<br />
* [https://www.mobygames.com/game/saturn/theme-park Theme Park (Sega Saturn)]<br />
* [https://www.mobygames.com/game/saturn/virtua-cop-2 Virtua Cop 2 (Sega Saturn)]<br />
* [https://www.mobygames.com/game/saturn/virtua-fighter-2 Virtua Fighter 2 (Sega Saturn)]<br />
* [https://www.mobygames.com/game/windows/zork-grand-inquisitor Zork: Grand Inquisitor (Windows)]<br />
* [https://www.mobygames.com/game/windows/zork-nemesis-the-forbidden-lands Zork Nemesis: The Forbidden Lands (Windows)]<br />
<br />
[[Category:Video Codecs]]<br />
[[Category:Incomplete Video Codecs]]<br />
[[Category:Game Formats]]</div>Multimedia Mikehttps://wiki.multimedia.cx/index.php?title=User:Multimedia_Mike&diff=15373User:Multimedia Mike2018-07-18T02:58:06Z<p>Multimedia Mike: Undo revision 15372 by Multimedia Mike (talk)</p>
<hr />
<div>Mike Melanson is the administrator and maintainer of the MultimediaWiki. He doesn't do much general multimedia hacking these days, but is still committed to ensuring that the multimedia knowledge collected by numerous talented contributors remains open and accessible.<br />
<br />
His email address is < mike at multimedia.cx >.<br />
<br />
== TODO ==<br />
I still need to document these items based on source code I have:<br />
* [[Packed Animation File]]<br />
* [[Escape 130]]<br />
* [[Gremlin Digital Video]]<br />
<br />
== Notes To Myself ==<br />
* With current version of MediaWiki (v1.6), access [[MediaWiki:Sidebar]] in order to edit navigation bar.</div>Multimedia Mikehttps://wiki.multimedia.cx/index.php?title=User:Multimedia_Mike&diff=15372User:Multimedia Mike2018-07-18T02:57:38Z<p>Multimedia Mike: </p>
<hr />
<div>Mike Melanson is the administrator and maintainer of the MultimediaWiki. He doesn't do much general multimedia hacking these days, but is still committed to ensuring that the multimedia knowledge collected by numerous talented contributors remains open and accessible.<br />
<br />
His email address is < mike at multimedia.cx >.<br />
<br />
== TODO ==<br />
I still need to document these items based on source code I have:<br />
* [[Packed Animation File]]<br />
* [[Escape 130]]<br />
* [[Gremlin Digital Video]]<br />
<br />
== Notes To Myself ==<br />
* With current version of MediaWiki (v1.6), access [[MediaWiki:Sidebar]] in order to edit navigation bar.<br />
<br />
making an edit after 1.31 upgrade...</div>Multimedia Mikehttps://wiki.multimedia.cx/index.php?title=FFmpeg_Metadata&diff=15352FFmpeg Metadata2018-02-06T05:20:17Z<p>Multimedia Mike: /* MP3 */ update the MP3 metadata information</p>
<hr />
<div>This page documents all of the metadata keys that [[FFmpeg]] honors, depending on the format being encoded. <br />
<br />
== Basic Usage ==<br />
FFmpeg has a free-form command line option that allows the user to specify key/value pairs for encoding metadata. The option is <code>-metadata</code> and is used as such:<br />
<br />
ffmpeg -i inputfile -metadata title="Movie Title" -metadata year="2010" outputfile<br />
<br />
Whether the metadata key/value pairs are actually encoded into the output file is dependent upon the file format being muxed. Many formats only support a handful of metadata keys. This page documents which keys FFmpeg will encode into which formats.<br />
<br />
== QuickTime/MOV/MP4/M4A/et al. ==<br />
The following table shows the metadata keys that FFmpeg honors when muxing a QuickTime file. The low-level identifier column lists the atom name that the format uses to encode the data on disc, which is not interesting to most readers. For the interested but uninitiated, the notation, e.g., '\251nam' indicates a 4-byte code consisting of the byte A9 in hexadecimal (or 251 in octal) followed by the ASCII characters 'n', 'a', and 'm'.<br />
<br />
<table border="1" cellpadding="5"><br />
<tr><br />
<th>Key</th><br />
<th>iTunes field</th><br />
<th>Low-level identifier</th><br />
</tr><br />
<br />
<tr><br />
<td>"title"</td><br />
<td>Name</td><br />
<td>'\251nam'</td><br />
</tr><br />
<br />
<tr><br />
<td>"author"</td><br />
<td>Artist</td><br />
<td>'\251ART'</td><br />
</tr><br />
<br />
<tr><br />
<td>"album_artist"</td><br />
<td>Album Artist</td><br />
<td>'aART'</td><br />
</tr><br />
<br />
<tr><br />
<td>"album"</td><br />
<td>Album</td><br />
<td>'\251alb'</td><br />
</tr><br />
<br />
<tr><br />
<td>"grouping"</td><br />
<td>Grouping</td><br />
<td>'\251grp'</td><br />
</tr><br />
<br />
<tr><br />
<td>"composer"</td><br />
<td>Composer</td><br />
<td>'\251wrt'</td><br />
</tr><br />
<br />
<tr><br />
<td>"year"</td><br />
<td>Year</td><br />
<td>'\251day'</td><br />
</tr><br />
<br />
<tr><br />
<td>"track"</td><br />
<td>Track Number</td><br />
<td>'trkn'</td><br />
</tr><br />
<br />
<tr><br />
<td>"comment"</td><br />
<td>Comments</td><br />
<td>'\251cmt'</td><br />
</tr><br />
<br />
<tr><br />
<td>"genre"</td><br />
<td>Genre</td><br />
<td>'\251gen'</td><br />
</tr><br />
<br />
<tr><br />
<td>"copyright"</td><br />
<td>??</td><br />
<td>'\251cpy'</td><br />
</tr><br />
<br />
<tr><br />
<td>"description"</td><br />
<td>Description</td><br />
<td>'desc'</td><br />
</tr><br />
<br />
<tr><br />
<td>"synopsis"</td><br />
<td>Information dialog when selecting "Show Description" in context menu</td><br />
<td>'ldes'</td><br />
</tr><br />
<br />
<tr><br />
<td>"show"</td><br />
<td>Show</td><br />
<td>'tvsh'</td><br />
</tr><br />
<br />
<tr><br />
<td>"episode_id"</td><br />
<td>Episode ID</td><br />
<td>'tven'</td><br />
</tr><br />
<br />
<tr><br />
<td>"network"</td><br />
<td>??</td><br />
<td>'tvnn'</td><br />
</tr><br />
<br />
<tr><br />
<td>"lyrics"</td><br />
<td>Lyrics</td><br />
<td>'\251lyr'</td><br />
</tr><br />
<br />
</table><br />
<br />
Further, the MOV muxer encodes libavformat version string into the '\251too' field. FFmpeg does not allow this key to be overridden from the command line.<br />
<br />
== ASF/WMV/WMA ==<br />
FFmpeg’s ASF muxer honors the following metadata keys:<br />
<br />
* “title”<br />
* “author”<br />
* “copyright”<br />
* “comment”<br />
* "rating"<br />
<br />
Beyond these keys, the ASF muxer accepts free-form key/value metadata keys to be encoded into the header. Further, libavformat encodes its version using the key "WM/EncodingSettings".<br />
<br />
== AVI ==<br />
FFmpeg’s AVI muxer honors the following metadata keys, writing them into FourCC chunks in the file header:<br />
<br />
* "IARL"<br />
* "IART", "artist"<br />
* "ICMS"<br />
* "ICMT", "comment"<br />
* "ICOP", "copyright"<br />
* "ICRD", "date"<br />
* "ICRP"<br />
* "IDIM"<br />
* "IDPI"<br />
* "IENG"<br />
* "IGNR", "genre"<br />
* "IKEY"<br />
* "ILGT"<br />
* "ILNG", "language"<br />
* "IMED"<br />
* "INAM", "title"<br />
* "IPLT"<br />
* "IPRD", "album"<br />
* "IPRT", "track"<br />
* "ISBJ"<br />
* "ISFT", "encoder" - note that this is automatically filled in by libavformat<br />
* "ISHP"<br />
* "ISRC"<br />
* "ISRF"<br />
* "ITCH", "encoded_by"<br />
<br />
== FLV ==<br />
FFmpeg's FLV muxer generates an onMetaData tag when creating a FLV file. This tag may contain free-form metadata key/value pairs. These key/value pairs are presented to the [[Adobe Flash Player]] through the onMetaData event when loading the FLV.<br />
<br />
In addition to user-specified key/value metadata pairs, FFmpeg's FLV muxer also encodes the following metadata fields:<br />
<br />
* 'duration'<br />
* 'filesize'<br />
* 'encoder'<br />
* if video is present in FLV:<br />
** 'width'<br />
** 'height'<br />
** 'videodatarate'<br />
** 'framerate'<br />
** 'videocodecid'<br />
* if audio is present in FLV:<br />
** 'audiodatarate'<br />
** 'audiosamplerate'<br />
** 'audiosamplesize'<br />
** 'stereo'<br />
** 'audiocodecid'<br />
<br />
== Matroska ==<br />
FFmpeg's Matroska muxer honors the following metadata keys:<br />
<br />
* “title”<br />
* “description”<br />
* “language”<br />
<br />
Beyond these keys, the Matroska muxer also accepts free-form key/value metadata pairs.<br />
<br />
== MP3 ==<br />
FFmpeg's MP3 muxer creates an [https://en.wikipedia.org/wiki/ID3 ID3v2 tag] compatible with either v2.3 or v2.4. The muxer honors the following metadata keys:<br />
<br />
{| class="wikitable"<br />
!FFmpeg metadata tag<br />
!ID3v2 tag<br />
|-<br />
|"album"<br />
|TALB<br />
|-<br />
|"composer"<br />
|TCOM<br />
|-<br />
|"genre"<br />
|TCON<br />
|-<br />
|"copyright"<br />
|TCOP<br />
|-<br />
|"encoded_by"<br />
|TENC<br />
|-<br />
|"title"<br />
|TIT2<br />
|-<br />
|"language"<br />
|TLAN<br />
|-<br />
|"artist"<br />
|TPE1<br />
|-<br />
|"album_artist"<br />
|TPE2<br />
|-<br />
|"performer"<br />
|TPE3<br />
|-<br />
|"disc"<br />
|TPOS<br />
|-<br />
|"publisher"<br />
|TPUB<br />
|-<br />
|"track"<br />
|TRCK<br />
|-<br />
|"encoder"<br />
|TSSE<br />
|-<br />
|"lyrics"<br />
|TSLT<br />
|}<br />
<br />
If any additional metadata tags are specified that are not in the preceding table, the FFmpeg MP3 muxer encodes a TXXX user-defined information frame containing both the key and the value.<br />
<br />
== MPEG Transport Streams ==<br />
FFmpeg's transport stream muxer honors the following metadata keys:<br />
<br />
* "title"<br />
* "language"<br />
<br />
== NUT ==<br />
FFmpeg’s NUT muxer honors the following metadata keys:<br />
<br />
* “title”<br />
* “author”<br />
* “copyright”<br />
<br />
== Realmedia ==<br />
FFmpeg’s Realmedia muxer encodes a “CONT” chunk by concatenating certain metadata values specified on the command line. These are the recognized metadata keys:<br />
<br />
* “title”<br />
* “author”<br />
* “copyright”<br />
* “comment”<br />
<br />
Example:<br />
<br />
ffmpeg -i track05.wav \<br />
-metadata title="This is the title" \<br />
-metadata author="Made by Me" \<br />
-metadata copyright="Copyright 2009 Me"<br />
-metadata comment="An exercise in Realmedia metadata" \<br />
-y track05.rm<br />
<br />
This is what the start of the file looks like in a hex editor:<br />
<br />
0040 00 01 00 03 43 4F 4E 54 00 00 00 5F 00 00 00 11 ....CONT..._....<br />
0050 54 68 69 73 20 69 73 20 74 68 65 20 74 69 74 6C This is the titl<br />
0060 65 00 0A 4D 61 64 65 20 62 79 20 4D 65 00 11 43 e..Made by Me..C<br />
0070 6F 70 79 72 69 67 68 74 20 32 30 30 39 20 4D 65 opyright 2009 Me<br />
0080 00 21 41 6E 20 65 78 65 72 63 69 73 65 20 69 6E .!An exercise in<br />
0090 20 52 65 61 6C 6D 65 64 69 61 20 6D 65 74 61 64 Realmedia metad<br />
00A0 61 74 61 4D 44 50 52 00 00 00 9B 00 00 00 00 00 ataMDPR.........<br />
<br />
== SDP ==<br />
The SDP muxer honors the “title” metadata key.<br />
<br />
== SoX ==<br />
The SoX native format muxer honors the “comment” metadata key.</div>Multimedia Mikehttps://wiki.multimedia.cx/index.php?title=Escape_130&diff=15348Escape 1302018-01-26T03:20:29Z<p>Multimedia Mike: update to link to mirrored document</p>
<hr />
<div>* [[Eidos Technologies]]<br />
* Samples: http://samples.mplayerhq.hu/game-formats/rpl/<br />
* Technical Description: https://multimedia.cx/mirror/dec130-spec.txt (Mirrored from this now-defunct link: http://pirsoft-dsl-dropzone.de/dec130-spec.txt ) Note that this document was used as a reference for a lot of the description on this page, but the Pb/Pr adjustment table described in the original document had errors. The tables on this wiki page are correct.<br />
<br />
Surprisingly, unlike previous [[ESCAPE]] codecs, Escape 130 was completely redesigned. Now it operates in mixed [[YUV]]/[[RGB]] colorpace and employs simple differential coding. In short, the source RGB image broken into 2x2 blocks. The average value of each pixel quad is interpolated, converted to YUV colorspace and stored together with quantized neighboring pixel differences. The decoder, operating in reverse, unpacks interpolated pixel values, convert them to RGB colorspace, then requantizes 4 pixels using supplied or pre-defined coefficient set. Compression works well for full-motion video, but static images experience visible blocking.<br />
<br />
The following is a spec for the Escape 130 codec; this is accurate as far as I know, but it is possible there are errors.<br />
<br />
==Container==<br />
<br />
All known video clips using the Escape 130 video codec are contained in the [[ARMovie]]/RPL container format. [[ARMovie]] is a general video/sound container; the only feature worth mentioning here is that the video and audio are contained in pairs of opaque chunks of arbitrary size. All known Escape 130 clips have only one video frame per chunk, though, which means the demuxer doesn't have to parse the video frame headers.<br />
<br />
Note that functionally, this format is mostly unrelated to the [[Escape 122]] and [[Escape 124]] codecs; the only real similarity is the skip code, block code organization of the blocks.<br />
<br />
The audio alongside Escape 130 samples is either 16-bit signed linear [[PCM]], or an [[IMA ADPCM]] variant.<br />
<br />
See the [[ARMovie]] page for a list of games using this codec.<br />
<br />
==Bit order==<br />
<br />
All numbers in this format are little-endian; this format is bit-oriented,<br />
and the bitstream is parsed in little-endian order. Multi-bit quantities<br />
are stored smallest bit first.<br />
<br />
==Header==<br />
<br />
The header is 16 bytes long; decoding doesn't require any information from this header.<br />
<br />
The first two bytes are always 0x0130. The second two bytes are 0x0001 for most frames and 0x8001 for keyframes (i.e. frames not dependent on the previous frame). The only way that a keyframe is different from a normal frame is that the only legal skip code in a keyframe is the code with the value zero. Most clips are not seekable anyway due to the audio using an ADPCM format without any keyframes (XXX is it really unseekable?). The next 4 bytes contain the size of the video frame, which is the same as the chunk size in the index of the container. The next 8 bytes are always zero.<br />
<br />
==Colorspace and Organization==<br />
<br />
Each frame is conceptually a series of 2x2 blocks of pixels, encoded from left to right, top to bottom. The colors are encoded in the file using a [[YCbCr]] colorspace. Y samples use 6 bits, Cb and Cr samples use 5 bits. There is always one Cb and one Cr sample per 2x2 block of pixels. There is always one base Y sample for any given block, plus there can be a adjustment pattern on top of the base sample, which provides more resolution.<br />
<br />
XXXFIXME: The information I have indicates that for blocks without an adjustment pattern, there is a special pattern applied after conversion to 8-bit RGB: (top left) green+6, (top right) red+6 blue+6, (bottom left) red+4 blue+4 green+2, (bottom right) red+2 blue+2 green+4. However, I have no idea what the purpose is; possibly to reduce blockiness? That said, I think this adjustment is too small to be visible.<br />
<br />
XXXFIXME: Is there more than one potential colorspace? Some information I have indicates that there is a flag in bit 17 of the header that allows selecting an alternate colorspace, but I don't know of any samples.<br />
<br />
==Encoding==<br />
<br />
Each frame is enocoded as a series of skip codes and block codes. A frame consists of a skip code, then a block code, then a skip code, etc. A frame ends when every block in the frame has been either explicitly encoded or skipped.<br />
<br />
A skip code is a number, encoded with a variable length encoding. It indicates some number of blocks to copy over from the previous frame. The blocks are "skipped" from left to right, top to bottom, starting with the block after the last block explicitly encoded (starting with the block in the top left for the first skip code).<br />
<br />
A block code explicitly encodes the color of a block. Most blocks are dependent in some way on the previous block; the "previous block" is the block in the current frame processed immediately before the current block. Visually, the previous block is the block to the immediate right of the current block. Note that the previous block may have been copied from the previous frame by a skip code. (XXXWhat about the block in the top left?)<br />
<br />
A block code consists of two parts: the first part encodes the Y value(s), and the second part encodes the Cb and Cr values.<br />
<br />
There are four formats for the Y value(s): one encodes a base value for the block plus an intensity pattern for the individual pixels, one just encodes a base value, one encodes a difference from the previous block's base value, and one is just an indicator to use the previous block's base value.<br />
<br />
There are three formats for the Cb and Cr values: one encodes the values for the block, one encodes an adjustment from the previous block's values, and one is just an indicator to use the previous block's values.<br />
<br />
==Encoding details==<br />
<br />
====Skip codes====<br />
{| border="1"<br />
|-<br />
!Binary<br />
!Value<br />
|-<br />
| 000000000000XXXXXXXXXXXXXXX<br/>(12 zero bits followed by 15 data bits)<br />
| X + 262<br />
|-<br />
| 0000XXXXXXXX<br/>(4 zero bits followed by 8 data bits)<br />
| X + 7<br />
|-<br />
| 0XXX<br/>(1 zero bit followed by 3 data bits)<br />
| X<br />
|-<br />
| 1<br/>(1 one bit)<br />
| 0<br />
|}<br />
<br />
====Block code, Y part====<br />
1SSSSSSDDBBBBB<br/><br />
B is half of the base value, D is the code for the strength of the pattern, and S is the code for the pattern.<br />
<br />
011BBBBBB<br/><br />
B is the base value<br />
<br />
010AAA<br/><br />
A is the code for the adjustment from the previous block's values<br />
<br />
00<br/><br />
Indicator to use the values from the previous block<br />
<br />
====Block code, Cb/Cr part====<br />
11BBBBBRRRRR<br/><br />
B is the Cb value, R is the Cr value<br />
<br />
10AAA<br/><br />
A is the code for the adjustment from the previous block's values<br />
<br />
0<br/><br />
Indicator to use the values from the previous block<br />
<br />
====Table for Y adjustment codes====<br />
{| border="1"<br />
|-<br />
! Code<br />
! Adjustment<br/>(relative to 6-bit sample)<br />
|-<br />
| 000<br />
| -4<br />
|-<br />
| 001<br />
| -3<br />
|-<br />
| 010<br />
| -2<br />
|-<br />
| 011<br />
| -1<br />
|-<br />
| 100<br />
| 1<br />
|-<br />
| 101<br />
| 2<br />
|-<br />
| 110<br />
| 3<br />
|-<br />
| 111<br />
| 4<br />
|-<br />
|}<br />
<br />
====Table for Cb/Cr adjustment codes====<br />
{| border="1"<br />
|-<br />
! Code<br />
! Cb Adjustment<br/>(relative to 5-bit sample)<br />
! Cr Adjustment<br/>(relative to 5-bit sample)<br />
|-<br />
| 000<br />
| 1<br />
| 0<br />
|-<br />
| 001<br />
| 1<br />
| 1<br />
|-<br />
| 010<br />
| 0<br />
| 1<br />
|-<br />
| 011<br />
| -1<br />
| 1<br />
|-<br />
| 100<br />
| -1<br />
| 0<br />
|-<br />
| 101<br />
| -1<br />
| -1<br />
|-<br />
| 110<br />
| 0<br />
| -1<br />
|-<br />
| 111<br />
| 1<br />
| -1<br />
|}<br />
<br />
====Tables for intensity-pattern encoding====<br />
<br />
The formula for the luma of each pixel is BaseValue + PatternStrength * PatternValue, where PatternStrength and PatternValue are from the following two tables.<br />
<br />
======Pattern strength codes (adjustments strengths relative to 6-bit sample):======<br />
{| border="1"<br />
|-<br />
! Code<br />
! Strength<br />
|-<br />
| 00<br />
| 2<br />
|-<br />
| 01<br />
| 4<br />
|-<br />
| 10<br />
| 10<br />
|-<br />
| 11<br />
| 20<br />
|}<br />
<br />
======Pattern codes======<br />
<br />
This table can be dynamically generated; the way this table is generated is just using a pattern of 0, 1, then -1, for the pixels from the top left to the bottom right, with the restrictions that any code with the bottom 4 bits zero is zero, and any potential row without both a 1 and a -1 is skipped. This algorithm will leave the bottom ten cells untouched.<br />
<br />
{| border="1"<br />
|-<br />
! Code<br />
! Top left<br />
! Top right<br />
! Bottom left<br />
! Bottom right<br />
|-<br />
| 000000<br />
| 0<br />
| 0<br />
| 0<br />
| 0<br />
|-<br />
| 000001<br />
| -1<br />
| 1<br />
| 0<br />
| 0<br />
|-<br />
| 000010<br />
| 1<br />
| -1<br />
| 0<br />
| 0<br />
|-<br />
| 000011<br />
| -1<br />
| 0<br />
| 1<br />
| 0<br />
|-<br />
| 000100<br />
| -1<br />
| 1<br />
| 1<br />
| 0<br />
|-<br />
| 000101<br />
| 0<br />
| -1<br />
| 1<br />
| 0<br />
|-<br />
| 000110<br />
| 1<br />
| -1<br />
| 1<br />
| 0<br />
|-<br />
| 000111<br />
| -1<br />
| -1<br />
| 1<br />
| 0<br />
|-<br />
| 001000<br />
| 1<br />
| 0<br />
| -1<br />
| 0<br />
|-<br />
| 001001<br />
| 0<br />
| 1<br />
| -1<br />
| 0<br />
|-<br />
| 001010<br />
| 1<br />
| 1<br />
| -1<br />
| 0<br />
|-<br />
| 001011<br />
| -1<br />
| 1<br />
| -1<br />
| 0<br />
|-<br />
| 001100<br />
| 1<br />
| -1<br />
| -1<br />
| 0<br />
|-<br />
| 001101<br />
| -1<br />
| 0<br />
| 0<br />
| 1<br />
|-<br />
| 001110<br />
| -1<br />
| 1<br />
| 0<br />
| 1<br />
|-<br />
| 001111<br />
| 0<br />
| -1<br />
| 0<br />
| 1<br />
|-<br />
| 010000<br />
| 0<br />
| 0<br />
| 0<br />
| 0<br />
|-<br />
| 010001<br />
| 1<br />
| -1<br />
| 0<br />
| 1<br />
|-<br />
| 010010<br />
| -1<br />
| -1<br />
| 0<br />
| 1<br />
|-<br />
| 010011<br />
| -1<br />
| 0<br />
| 1<br />
| 1<br />
|-<br />
| 010100<br />
| -1<br />
| 1<br />
| 1<br />
| 1<br />
|-<br />
| 010101<br />
| 0<br />
| -1<br />
| 1<br />
| 1<br />
|-<br />
| 010110<br />
| 1<br />
| -1<br />
| 1<br />
| 1<br />
|-<br />
| 010111<br />
| -1<br />
| -1<br />
| 1<br />
| 1<br />
|-<br />
| 011000<br />
| 0<br />
| 0<br />
| -1<br />
| 1<br />
|-<br />
| 011001<br />
| 1<br />
| 0<br />
| -1<br />
| 1<br />
|-<br />
| 011010<br />
| -1<br />
| 0<br />
| -1<br />
| 1<br />
|-<br />
| 011011<br />
| 0<br />
| 1<br />
| -1<br />
| 1<br />
|-<br />
| 011100<br />
| 1<br />
| 1<br />
| -1<br />
| 1<br />
|-<br />
| 011101<br />
| -1<br />
| 1<br />
| -1<br />
| 1<br />
|-<br />
| 011110<br />
| 0<br />
| -1<br />
| -1<br />
| 1<br />
|-<br />
| 011111<br />
| 1<br />
| -1<br />
| -1<br />
| 1<br />
|-<br />
| 100000<br />
| 0<br />
| 0<br />
| 0<br />
| 0<br />
|-<br />
| 100001<br />
| -1<br />
| -1<br />
| -1<br />
| 1<br />
|-<br />
| 100010<br />
| 1<br />
| 0<br />
| 0<br />
| -1<br />
|-<br />
| 100011<br />
| 0<br />
| 1<br />
| 0<br />
| -1<br />
|-<br />
| 100100<br />
| 1<br />
| 1<br />
| 0<br />
| -1<br />
|-<br />
| 100101<br />
| -1<br />
| 1<br />
| 0<br />
| -1<br />
|-<br />
| 100110<br />
| 1<br />
| -1<br />
| 0<br />
| -1<br />
|-<br />
| 100111<br />
| 0<br />
| 0<br />
| 1<br />
| -1<br />
|-<br />
| 101000<br />
| 1<br />
| 0<br />
| 1<br />
| -1<br />
|-<br />
| 101001<br />
| -1<br />
| 0<br />
| 1<br />
| -1<br />
|-<br />
| 101010<br />
| 0<br />
| 1<br />
| 1<br />
| -1<br />
|-<br />
| 101011<br />
| 1<br />
| 1<br />
| 1<br />
| -1<br />
|-<br />
| 101100<br />
| -1<br />
| 1<br />
| 1<br />
| -1<br />
|-<br />
| 101101<br />
| 0<br />
| -1<br />
| 1<br />
| -1<br />
|-<br />
| 101110<br />
| 1<br />
| -1<br />
| 1<br />
| -1<br />
|-<br />
| 101111<br />
| -1<br />
| -1<br />
| 1<br />
| -1<br />
|-<br />
| 110000<br />
| 0<br />
| 0<br />
| 0<br />
| 0<br />
|-<br />
| 110001<br />
| 1<br />
| 0<br />
| -1<br />
| -1<br />
|-<br />
| 110010<br />
| 0<br />
| 1<br />
| -1<br />
| -1<br />
|-<br />
| 110011<br />
| 1<br />
| 1<br />
| -1<br />
| -1<br />
|-<br />
| 110100<br />
| -1<br />
| 1<br />
| -1<br />
| -1<br />
|-<br />
| 110101<br />
| 1<br />
| -1<br />
| -1<br />
| -1<br />
|-<br />
| 110110<br />
| 0<br />
| 0<br />
| 0<br />
| 0<br />
|-<br />
| 110111<br />
| 0<br />
| 0<br />
| 0<br />
| 0<br />
|-<br />
| 111000<br />
| 0<br />
| 0<br />
| 0<br />
| 0<br />
|-<br />
| 111001<br />
| 0<br />
| 0<br />
| 0<br />
| 0<br />
|-<br />
| 111010<br />
| 0<br />
| 0<br />
| 0<br />
| 0<br />
|-<br />
| 111011<br />
| 0<br />
| 0<br />
| 0<br />
| 0<br />
|-<br />
| 111100<br />
| 0<br />
| 0<br />
| 0<br />
| 0<br />
|-<br />
| 111101<br />
| 0<br />
| 0<br />
| 0<br />
| 0<br />
|-<br />
| 111110<br />
| 0<br />
| 0<br />
| 0<br />
| 0<br />
|-<br />
| 111111<br />
| 0<br />
| 0<br />
| 0<br />
| 0<br />
|}<br />
<br />
<br />
[[Category:Video Codecs]]<br />
[[Category:Game Formats]]</div>Multimedia Mikehttps://wiki.multimedia.cx/index.php?title=SID&diff=15347SID2018-01-26T03:08:58Z<p>Multimedia Mike: reassign category</p>
<hr />
<div>* Extension: SID<br />
Sound Interface Device (SID) file format.<br />
[[Category:Game Audio Formats]]</div>Multimedia Mikehttps://wiki.multimedia.cx/index.php?title=Portable_Sound_Format&diff=15346Portable Sound Format2018-01-26T03:02:49Z<p>Multimedia Mike: basic info</p>
<hr />
<div>* Extensions: PSF, USF, GSF, 2SF, DSF, QSF, SSF<br />
<br />
Portable Sound Format is a game audio music format.<br />
<br />
[[Category:Game Audio Formats]]</div>Multimedia Mikehttps://wiki.multimedia.cx/index.php?title=SAP&diff=15345SAP2018-01-25T05:17:05Z<p>Multimedia Mike: disambiguation page</p>
<hr />
<div>In the context of multimedia technology, SAP can refer to either:<br />
<br />
* [[Atari SAP]], a chiptune format<br />
* [[Session Announcement Protocol]], a multimedia network protocol</div>Multimedia Mikehttps://wiki.multimedia.cx/index.php?title=Atari_SAP&diff=15344Atari SAP2018-01-25T05:14:47Z<p>Multimedia Mike: basic info</p>
<hr />
<div>* Extension: SAP<br />
<br />
Chiptune format.<br />
<br />
[[Category:Game Audio Formats]]</div>Multimedia Mikehttps://wiki.multimedia.cx/index.php?title=Session_Announcement_Protocol&diff=15343Session Announcement Protocol2018-01-25T05:13:36Z<p>Multimedia Mike: Multimedia Mike moved page SAP to Session Announcement Protocol without leaving a redirect: Collision with another SAP acronym</p>
<hr />
<div>SAP stands for '''Session Announcement Protocol'''. It's defined in [http://www.ietf.org/rfc/rfc2974.txt RFC2974].<br />
It's a distributed directory of announcements of streams and uses multicast to efficiently distribute these announces on the Local Area Network or on the MBONE. It uses [[SDP]]'s to describe streams so that you can open the stream via [[RTSP]].<br />
<br />
This technique will allow you to have a lot of server-generated streams (often multicasted) that announce themselves on the network. The clients on the network can then listen for these announcements. A client can receive a listing of all these streams and can simply 'tune' into an individual stream.<br />
<br />
It can also work for Internet telephony ([[SIP]]) for instance.<br />
<br />
Example of what is announced via SAP on the MBONE:<br />
http://www.uninett.no/multimedia/streamingguide/alle.html<br />
<br />
[[Category:Networking Protocols]]</div>Multimedia Mikehttps://wiki.multimedia.cx/index.php?title=AY&diff=15342AY2018-01-25T03:08:16Z<p>Multimedia Mike: basic info</p>
<hr />
<div>Extension: AY<br />
<br />
AY files are music files extracted from software written for the ZX Spectrum and Amstrad CPC computers. Both of these computers used the [https://en.wikipedia.org/wiki/General_Instrument_AY-3-8910 General Instruments AY-3-8910 chip], which is how this format derives its name.<br />
<br />
[[Category: Game Audio Formats]]</div>Multimedia Mikehttps://wiki.multimedia.cx/index.php?title=SC68&diff=15341SC682018-01-25T02:38:07Z<p>Multimedia Mike: expanding</p>
<hr />
<div>Extension: sc68<br />
<br />
sc68 is a chiptune format for the Atari ST. It also apparently features some crossover with the Amiga.<br />
<br />
All known files can be downloaded in a single package here: http://sc68.atari.org/musics_all.html<br />
<br />
[[Category:Game Audio Formats]]</div>Multimedia Mikehttps://wiki.multimedia.cx/index.php?title=SC68&diff=15340SC682018-01-25T00:58:25Z<p>Multimedia Mike: basic info</p>
<hr />
<div>Extension: sc68<br />
<br />
Chiptune format.<br />
<br />
[[Category:Game Audio Formats]]</div>Multimedia Mikehttps://wiki.multimedia.cx/index.php?title=GBS&diff=15339GBS2018-01-23T04:44:28Z<p>Multimedia Mike: basic page</p>
<hr />
<div>* Extension: GBS<br />
<br />
GBS is an audio format that encapsulates sequences of music playback instructions extracted from Game Boy games.<br />
<br />
[[Category:Game Audio Formats]]</div>Multimedia Mikehttps://wiki.multimedia.cx/index.php?title=RSN&diff=15338RSN2018-01-21T23:40:01Z<p>Multimedia Mike: basic page</p>
<hr />
<div>* Extension: RSN<br />
<br />
RSN files are RAR archives that contain series of [[SPC]] files.<br />
<br />
[[Category:Game Audio Formats]]</div>Multimedia Mike