MultimediaWiki - User contributions [en]

FFmpeg Summer of Code 2013

2013-03-22T09:47:50Z

Alex:

Google Summer of Code is a program that offers students stipends to write code for open source projects. FFmpeg participated to several past editions, and this page is about the [http://www.google-melange.com/gsoc/homepage/google/gsoc2013 Google Summer of Code 2013 edition].
In particular, see [http://www.google-melange.com/gsoc/events/google/gsoc2013 timeline].

Application period starts on March 18, and March 29 at 19:00 UTC is the application deadline for interested organizations.
Please finish up this page before then.

= Proposing Ideas =

If you have a project idea please contact a developer first at the #ffmpeg-devel IRC channel on Freenode or via the [http://ffmpeg.org/contact.html ffmpeg-devel mailing list]. A good source of ideas is the [https://ffmpeg.org/trac/ffmpeg/ FFmpeg bug tracker] and [[FFmpeg_Summer_of_Code_2012|FFmpeg Summer of Code 2012 Ideas List]].

When adding an idea follow this template for consistency:

<pre>
== Task Title ==

'''Description:''' A few sentences or a short paragraph describing the task.

'''Expected results:''' Bulleted list or paragraph describing what the student is expected to achieve.

'''Prerequisites:''' Skills or knowledge required by student.

'''Qualification Task:''' Small task student should perform to demonstrate understanding.

'''Mentor:''' List mentor and backup mentor if there is one and contact info such as IRC name or email address.
</pre>

'''Note:''' This section will be removed upon our organization application.

= Mentored tasks =

== H.264 Multiview Video Coding (MVC) ==

<div class="floatright">[[Image:Mmspg-epfl-ch-double-camera.jpg]]</div>

'''Description:''' MVC samples exist and the codec is used on Bluray media, but FFmpeg is missing a decoder. Since this task also consists of some changes in the current architecture, it is especially important that this task is discussed on the [http://ffmpeg.org/mailman/listinfo/ffmpeg-devel ffmpeg-devel mailing list].

'''Expected results:''' Create MVC decoder and add a test for the FFmpeg Automated Testing Environment (FATE).

'''Prerequisites:''' C coding skills, familiarity with git/source code control systems.

'''Qualification Task:''' Perform work that demonstrates understanding of MVC and that is a subpart of the whole MVC implementation.

'''Mentor:''' Michael Niedermayer (''michaelni'' on IRC)

== Animated Portable Network Graphics (APNG) ==

'''Description:''' FFmpeg currently does not support Animated PNGs.

'''Specification:''' https://wiki.mozilla.org/APNG_Specification

<div class="floatright">[[Image:Animated PNG example bouncing beach ball.png]]</div>

'''Expected results:'''
* APNG demuxer
** implement robust probing:
*** PNG images are not misdetected as APNG animations
*** APNG animations are not misdetected as PNG images
** splits stream into sensible packets (so they can be easily reused in APNG muxer)
** survives fuzzing (zzuf)
** add FATE coverage, coverage should be at least 70%
** test code under valgrind so no invalid reads/writes happen

* APNG decoder
** use existing PNG decoder code (write decoder in same file)
** implement parsing of all APNG chunks (acTL, fcTL, fdAT)
** error handling
** survives fuzzing (zzuf)
** add test for FATE, coverage should be at least 75%
** CRC checksum validation
** test code under valgrind so no invalid reads/writes happen

* APNG muxer && APNG encoder
** use existing PNG encoder code (write encoder in same file)
** write compliant files, make sure they play correctly in major web browsers that support APNG
** add test for FATE

'''Prerequisites:''' C coding skills, familiarity with git/source code control systems.

'''Qualification Task:''' Implement format autodetection for imagepipe & image demuxer

'''Mentor:''' [[User:Pbm|Paul B Mahol]] (''durandal_1707'' on IRC)

== Misc Libavfilter extension ==

<div class="floatright">[[Image:Lavfi-gsoc-filter-vintage-illustration.jpg]]</div>

'''Description:''' Libavfilter is the FFmpeg filtering library. It currently supports audio and video filtering and generation support. This work may focus on porting, fixing, extending, or writing new audio and video filters from scratch.

Candidate filters for porting may be the remaining MPlayer filters currently supported through the mp wrapper, libaf MPlayer filters, and filters from other frameworks (e.g. mjpegtools, transcode, avisynth, virtualdub, etc.). In case of mp ports, the student should verify that the new filter produces the same output and is not slower.

Some ideas for more filters:
* a frequency filtering domain filter relying on the FFT utils in libavcodec
* a controller filter which allows to send commands to other filters (e.g. to adjust volume, contrast, etc.), e.g. like the sendcmd filter but through an interactive GUI
* a lua scripting filter, which allows to implement filtering custom logic in lua

For more ideas check:
[https://ffmpeg.org/trac/ffmpeg/query?status=new&status=open&status=reopened&component=avfilter&col=id&col=summary&col=status&col=type&col=priority&col=component&col=version&order=priority trac libavfilter tickets].

'''Expected results:''' Write or port audio and video filters and possibly fix/extend libavfilter API and design when required.

'''Prerequisites:''' C coding skills, familiarity with git/source code control systems. Some background on DSP and image/sound processing techniques would be a bonus but is not strictly required.

'''Qualification task:''' write or port one or more filters

'''Mentor:''' [[User:Stefanosa|Stefano Sabatini]]

'''Backup mentor:''' Clément Bœsch (''ubitux'' on IRC)

== Subtitles ==

'''Description:''' FFmpeg has been working on improving its subtitles support recently, notably by adding the support for various text subtitles and various hardsubbing (burning the subtitles onto the video) facilities. While the theme may sound relatively simple compared to audio/video signal processing, the project carry an historical burden not easy to deal with, and introduces various issues very specific to its sparse form.

<center>[[Image:Subtitles-sensei.jpg]]</center>

'''Expected results:'''
* Add support for new subtitles formats. Example: a demuxer for .SUP files, just like VobSub but for Blu-Ray, or a VobSub muxer.
* Improve text subtitles decoders. Typically, this can be supporting advanced markup features in SAMI or WebVTT.
* Update the API to get rid of the clumsy internal text representation of styles
* Proper integration of subtitles into libavfilter. This is the ultimate goal, as it will notably allow a complete subtitles rendering for applications such as ffplay.
* BONUS: if everything goes well, the student will be allowed to add basic support for teletext

'''Prerequisites:''' C coding skills, familiarity with git/source code control systems. Some background in fansubbing area (notably ASS experience) would be a bonus but is not strictly required.

'''Qualification task:''' write one subtitles demuxer and decoder (for example support for Spruce subtitles format). This is in order to make sure the subtitles chain is understood.

'''Mentor:''' Clément Bœsch (''ubitux'' on IRC)

'''Backup Mentor:''' Nicolas George

== Postproc optimizations ==

<div class="floatright">[[Image:PostProc.jpg]]</div>

'''Description:''' FFmpeg contains libpostproc, which is used to postprocess 8x8 DCT-MC based video and images (jpeg, mpeg-1/2/4, H.263 among others). The code though has been written a long time ago and its SIMD optimizations need to be updated to what modern CPUs support (AVX2 and SSE2+).

'''Expected results:'''
* Convert all gcc inline asm in libpostproc to YASM.
* Restructure the code so that it works with block sizes compatible with modern SIMD.
* Add Integer SSE2 and AVX2 optimizations for each existing MMX/MMX2/3dnow optimization in libpostproc.

'''Prerequisites:''' C coding skills, good x86 assembly coding skills, familiarity with git/source code control systems.

'''Qualification task:''' convert 1 or 2 MMX2 functions to SSE2 and AVX2.

'''Mentor:''' Michael Niedermayer (''michaelni'' on IRC)

<br clear="all">

== Bayer RGB colorspaces ==

<div class="floatright">[[Image:350px-Bayer_pattern_on_sensor.svg.png ]]</div>

'''Description:''' Several image and video format store pixels using Bayer-pattern colorspaces. Supporting these format would broaden FFmepg's applicability to RAW still and video photography processing. Tasks:

'''Expected Results:'''
* Rebase existing patches
* Implement bayer transformations in libswscale (plain C)
* Add bayer formats to the libavutil pixfmt enumeration routines
* SIMD optimizations of the libswscale transformations
* Complete PhotoCINE demuxer to support Bayer format; (or another format of your choosing)

Optional goodies:
* Extend TIFF decoder to support DNG-Bayer format
* Support a popular proprietary camera format (many to choose from; see dcraw project)

'''Qualification task''': TBD

'''Mentor''': Peter Ross

'''Backup Mentor''': Michael Niedermayer (''michaelni'' on IRC)

<br clear="all">

== MPEG-4 ALS encoder ==

<div class="floatright">http://upload.wikimedia.org/wikipedia/commons/e/e9/ATunes.png</div>
<div class="floatright">[http://commons.wikimedia.org/wiki/File%3AATunes.png]</div>

'''Description:'''
A MPEG-4 ALS decoder was implemented several years ago but an encoder is still missing in the official codebase. A rudimentary encoder has already been written and is available on [https://github.com/justinruggles/FFmpeg-alsenc.git github]. For this task, that encoder is first to be updated to fit into the current codebase of FFmpeg and to be tested for conformance using the [http://www.nue.tu-berlin.de/menue/forschung/projekte/beendete_projekte/mpeg-4_audio_lossless_coding_als/parameter/en/#230252 reference codec and specifications]. Second, the encoder is to be brought through the usual reviewing process to hit the codebase at the end of the project.

'''Expected results:'''

* Update the existing encoder to fit into the current codebase.
* Ensure conformance of the encoder by verifying using the reference codec and generate a test case for FATE.
* Ensure the FFmpeg decoder processes all generated files without warnings.
* Enhance the rudimentary feature set of the encoder.

'''Prerequisites:''' C coding skills, familiarity with git/source code control systems. A certain interest in audio coding and/or knowledge about the FFmpeg codebase could be beneficial.

'''Qualification task:''' Add floating point support to MPEG-4 ALS decoder

'''Mentor:''' [[User:Pbm|Paul B Mahol]] (''durandal_1707'' on IRC)

<br clear="all">

= Unmentored tasks =

== glplay ==

<div class="floatleft">[[Image:Opengl_logo.jpg]]</div>

'''Description:''' The SDL library that is used by FFplay has some deficiencies, adding OpenGL output to FFplay should allow for better performance (and less bugs at least for some hardware / driver combinations). This could be a new application (glplay), but it is probably simpler to extend ffplay to use OpenGL. You can use code from MPlayer's OpenGL vo module which may be relicensed under the LGPL.

'''Mentor:''' TBD Backup: Reimar Döffinger

<br clear="all">

== AAC ==

'''Description:''' FFmpeg contains an AAC encoder and decoder, both of them can be improved in various ways. This is enough work for more than one GSoC project, so one part of your submission would be to define on which task exactly you want to work.
* AAC LD decoder
* AAC BSAC decoder: This has already been started, but the existing decoder still fails on many samples
* AAC SSR decoder
* AAC 960/120 MDCT window
* AAC multi-channel encoding
See also the FFmpeg bug tracker for AAC issues, fixing one of them or rebasing the existing incomplete BSAC decoder for current git head fixing one or more existing bugs are possible qualification tasks.

== DTS / DCA ==

'''Description:''' FFmpeg contains a DTS decoder.
* DTS-HD decoder improvements: A possible qualification task is to implement ticket [https://ffmpeg.org/trac/ffmpeg/ticket/1920 #1920]
** Add support for X96 extension (96khz)
** Add support for XLL extension (lossless)
** Add support for pure DTS-HD streams that do not contain a DTS core
** Add support for multiple assets
** Add support for LBR extension

== TrueHD encoder ==

'''Description:''' FFmpeg currently does not support encoding to one of the lossless audio formats used on Bluray discs. This task consists of implementing a TrueHD encoder that allows to losslessly encode audio to play it on hardware devices capable of TrueHD decoding.

== Opus decoder ==

<div class="floatright">[[Image:Opus.png]]</div>

'''Description:''' Opus decoding is currently supported through the external libopus library
* Write a native decoder, continue working on the existing unfinished implementation
A possible qualification task is to port the existing incomplete decoder to current git head and improve it to show that you are capable of working on this task.

== VC-1 interlaced ==

'''Description:''' The FFmpeg VC-1 decoder has improved over the years, but many samples are still not decoded bit-exact and real-world interlaced streams typically show artefacts.
* Implement missing interlace features
* Make more reference samples bit-exact
As a qualification task, you should try to find a bug in the current decoder implementation and fix it.

== JPEG 2000 ==

<div class="floatleft">[[Image:Jpeg2000.jpg]]</div>

'''Description:''' FFmpeg contains an experimental native JPEG 2000 encoder and decoder. Both are missing many features, see also the FFmpeg bug tracker for some unsupported samples.
Work on an issue (for example from the bug tracker) as a qualification task to show that you are capable of improving the codec implementation.

<br clear="all">

== VP7 ==

'''Description:''' Not many [http://samples.mplayerhq.hu/V-codecs/VP7/ VP7 samples] are in the wild, but no open-source decoder exists although a [http://multimedia.cx/mirror/VP7_Data_Format_and_Decoder_Overview.pdf specification] exists. Write a decoder that reuses as much as possible of existing FFmpeg code: it is likely that functions of the existing decoders for On2-based formats will be useful.

== VP8L ==

'''Description:''' [[VP8L]] is a lossless format used in WebP. There is no support for this in FFmpeg.

[[Category:FFmpeg]]

GoToMeeting Codec

2012-11-04T14:29:58Z

Alex:

* FourCC: G2M2, G2M3, G2M4
* Company: [http://www.gotomeeting.com GoToMeeting (Citrix)]
* Samples:
** G2M2: http://samples.mplayerhq.hu/V-codecs/G2M2/
** G2M3: http://samples.mplayerhq.hu/V-codecs/G2M3/
** G2M4: http://samples.mplayerhq.hu/V-codecs/G2M4/

This is a codec used to save recordings in GoToMeeting. The codec also calls itself GoToWebinar (see [http://www.gotowebinar.com/ http://www.gotowebinar.com/]).

Win32 binary decoder available here: [http://www.gotomeeting.com/codec http://www.gotomeeting.com/codec]

According to samples, all G2M2 video frames begin with the characters 'G2M2', followed by a series of chunks. Each chunk has the following layout:

bytes 0-3 length of chunk payload, not including this length field
byte 4 type of chunk
bytes 5.. remainder of payload, format unknown

Supported chunk types are 0xC8-0xCD.

It appears that the minimum size for a G2M2 frame (possibly a no-change frame) is 14 bytes. This includes the 4 signature bytes, a 4-byte length indicating a chunk length of 6, and a 6-byte payload of type 0xCA followed by 5 more bytes.

G2M3 bears much similarity to G2M2 at the surface level. Naturally, each frame has a signature of 'G2M3'.

=== Chunk C8 ===

This seems to contain display information.

Chunk contents (all values are big-endian):

4 bytes image width
4 bytes image height
4 bytes compression mode (should be 2 or 3)
4 bytes tile width
4 bytes tile height
1 byte colour depth (4, 8, 16, 24 or 32)
for 4/8bpp there is a palette in standard RGBTUPLE format
for 16-32bpp there are four bitmasks for each field

=== Chunk C9 ===

Should be image update.

1 byte tile position in row?
1 byte tile position in column?
... compressed data

'''REing compressed data format is left as an exercise to the reader, an example is provided below

==== Compression 2 ====

ELS-coded data size
ELS-coded data for transparency pixel
ELS-coded data for whole image
JPEG data

ELS-coded data size:

0xxxxxxx
10xxxxxx xxxxxxxx
110xxxxx xxxxxxxx xxxxxxxx
111xxxxx xxxxxxxx xxxxxxxx xxxxxxxx

===== ELS data =====

ELS-coded data seems to consist of coded flags and differences for RGB triplets.

Vanilla augmented ELS coder is used ([http://ieeexplore.ieee.org/xpls/abs_all.jsp?arnumber=582144 The ELS-coder: a rapid entropy coder]).
.

Unsigned values are coded as a number with all bits set to one and an addition to it:

mask = 1;
val = 0;

while (decode_bit()) {
val += mask;
mask <<= 1;
}
while (mask > 1) {
mask >>= 1;
if (decode_bit())
val += mask;
}

E.g. number 5 will be coded as <code>11 0 10</code> (i.e. 3 + stop bit + 2).

Signed values use last bit for sign:

if (val & 1)
val = - ((val + 1) >> 1);
else
val = val >> 1;

Image data is composed this way:

single pixel value that is used for transparency colour
full tile image

Pixels in image can be coded as the one of 10 already decoded neighbours depending on which of them equal to which (a bit like JBIG compression), as some cached value or as the difference to the predicted one from left+top+topleft neighbours.

===== JPEG data =====
JPEG data seems to be scan data with escapes but no headers (default Huffman tables and quantisation matrices are used).

=== Chunk CA ===

Probably mouse cursor position.

2 bytes cursor position X
2 bytes cursor position Y
1 byte seems to be always 1

=== Chunk CB ===

This one seems to define mouse cursor shape:

4 bytes data size
1 byte width
1 byte height
1 byte hotspot x
1 byte hotspot y
... cursor bitmask and its inverse (in M$ format 98% sure)

=== Chunk CC ===

Maybe some resync chunk, it's supposed to contain only 4-byte value equal to 2000.

=== Chunk CD ===

One dword, something to do with time.

[[Category:Video Codecs]]
[[Category:Undiscovered Video Codecs]]
[[Category:Formats missing in FFmpeg]]
[[Category:Screen Capture Video Codecs]]

VP8L

2012-10-29T01:51:26Z

Alex:

* Company: [[Google]]
* Specification: https://developers.google.com/speed/webp/docs/webp_lossless_bitstream_specification
* Sample implementation: https://code.google.com/p/webm/source/browse/src/dec/vp8l.c?repo=libwebp&r=2fc130157767e529fedd42fad0c70c13804058ab

From Google's [[WebP]] page: "Lossless WebP compression uses already seen image fragments in order to exactly reconstruct new pixels. It can also use a local palette if no interesting match is found. This palette is continuously updated to re-use recent colors. This compression mode is named "VP8L" and shares some common features with the so-called LZ77 compression algorithm."

[[Category:Video Codecs]]

WebP

2012-10-29T01:51:06Z

Alex:

* Extension: webp
* Specification: https://developers.google.com/speed/webp/docs/riff_container
* Samples: http://samples.mplayerhq.hu/image-samples/webp/

'''WebP''' is an image format developed developed by [[Google]]. It uses a [[RIFF]] based container format and employs [[VP8]] for lossy and [[VP8L]] for lossless image compression.

== References ==
* [http://code.google.com/speed/webp/index.html Official website]

[[Category:Image Formats]]
[[Category:Formats missing in FFmpeg]]

WebP

2012-10-29T01:50:27Z

Alex:

* Extension: webm
* Samples: http://samples.mplayerhq.hu/image-samples/webp/

'''WebP''' is an image format developed developed by [[Google]]. It uses a [[RIFF]] based container format and employs [[VP8]] for lossy and [[VP8L]] for lossless image compression.

== References ==
* [http://code.google.com/speed/webp/index.html Official website]

[[Category:Image Formats]]
[[Category:Formats missing in FFmpeg]]

VP8L

2012-10-29T01:49:49Z

Alex:

* Company: [[Google]]
* Sample implementation: https://code.google.com/p/webm/source/browse/src/dec/vp8l.c?repo=libwebp&r=2fc130157767e529fedd42fad0c70c13804058ab

From Google's [[WebP]] page: "Lossless WebP compression uses already seen image fragments in order to exactly reconstruct new pixels. It can also use a local palette if no interesting match is found. This palette is continuously updated to re-use recent colors. This compression mode is named "VP8L" and shares some common features with the so-called LZ77 compression algorithm."

[[Category:Video Codecs]]

WebM

2012-10-29T01:48:59Z

Alex:

* Company: [[Google]]
* Website: http://www.webmproject.org/

Taken from the web page: "The WebM project is dedicated to developing a high-quality, open video format for the web that is freely available to everyone."

Core technologies include:

* video codec: [[On2 VP8]] and [[VP8L]]
* audio codec: [[Vorbis]]
* container: [[Matroska]]

WebP

2012-10-29T01:48:46Z

Alex:

* Extension: webm
* Samples: http://samples.mplayerhq.hu/image-samples/webp/

'''WebP''' is an image format developed developed by [[Google]]. It uses the [[WebM]] container format and employs [[VP8]] for lossy and [[VP8L]] for lossless image compression.

== References ==
* [http://code.google.com/speed/webp/index.html Official website]

[[Category:Image Formats]]
[[Category:Formats missing in FFmpeg]]

MUSICompress

2012-10-29T01:16:27Z

Alex:

* Extensions: mcp
* Company: Soundspace Audio
* Homepage: [http://members.aol.com/sndspace Soundspace]
* [https://groups.google.com/forum/?fromgroups=#!topic/comp.music.research/uCu3xAi2k7o Introductory letter from author]
* Publication: A. Wegener, “MUSICompress: Lossless, lowMIPS audio compression in software and hardware”, in Proc. Int. Conf. Signal Processing Applications and Technology, San Diego, CA, USA, 1997 September 14-17.

Implementation also called WaveZip.

[[Category:Audio Codecs]]
[[Category:Undiscovered Audio Codecs]]
[[Category:Formats missing in FFmpeg]]

Dakx Wav

2012-10-29T01:08:23Z

Alex:

* Description: [http://www.rjamorim.com/rrw/daxwav.html Dakx Wav]
* Website: http://www.dakx.com/
* Patent: [http://www.google.com/patents?vid=USPAT5825830 USPAT 5,825,830]
* Simple decoder/encoder: http://www.dakx.com/software/simdaxg.c

[[Category: Audio Codecs]]
[[Category: Lossless Audio Codecs]]
[[Category: Undiscovered Audio Codecs]]

Sonarc

2012-10-29T01:06:11Z

Alex:

* Description: [http://www.speech.cs.cmu.edu/comp.speech/Section3/Software/sonarc.html Sonarc]

[[Category: Audio Codecs]]
[[Category: Lossless Audio Codecs]]
[[Category: Undiscovered Audio Codecs]]

WavArc

2012-10-29T01:04:38Z

Alex:

* Description: [http://www.firstpr.com.au/audiocomp/lossless/wavarc/ WavArc]

[[Category: Audio Codecs]]
[[Category: Lossless Audio Codecs]]
[[Category: Undiscovered Audio Codecs]]

AudioZip

2012-10-29T01:02:28Z

Alex:

* Description: [http://www.rjamorim.com/rrw/audiozip.html AudioZip] [http://web.tiscali.it/mupuxeddu/software/old/audiozip.html AudioZip #2]

[[Category: Audio Codecs]]
[[Category: Lossless Audio Codecs]]
[[Category: Undiscovered Audio Codecs]]

UEMCLIP

2011-01-30T00:12:28Z

Alex:

* Website: http://uemclip.com/English/index_e.htm
* Company: [[NTT]]
* Description: http://uemclip.com/doc/HighLevelDescription.pdf
* Sample: http://uemclip.com/data/UEMCLIP.wav (decoded UEMCLIP to pcm)
* RTP payload format: https://tools.ietf.org/html/draft-ietf-avt-rtp-uemclip

UEMCLIP (mU-law EMbedded Coder for Low-delay IP communication) is [[μ-law]]-based voice codec. This codec is base of [[G.711.1]] [https://www.ntt-review.jp/archive/ntttechnical.php?contents=ntr200808le1.html].

The RTP payload format document describes the data packets and chapter 4 explains the transcoding possibility between G.711 and UEMCLIP. It is mentioned here that sub layer index 0 is standard G.711 data, but this sub layer block might or might not follow immediately the headers (so the sub layer headers must be parsed).

[[Category:Audio Codecs]]
[[Category:Vocoders]]
[[Category:Undiscovered Audio Codecs]]
[[Category:MDCT Audio Codecs]]

UEMCLIP

2011-01-30T00:12:00Z

Alex:

* Website: http://uemclip.com/English/index_e.htm
* Company: [[NTT]]
* Description: http://uemclip.com/doc/HighLevelDescription.pdf
* Sample: http://uemclip.com/data/UEMCLIP.wav (decoded UEMCLIP to pcm)
* RTP payload format: https://tools.ietf.org/html/draft-ietf-avt-rtp-uemclip

UEMCLIP (mU-law EMbedded Coder for Low-delay IP communication) is [[μ-law]]-based voice codec. This codec is base of [[G.711.1]] [https://www.ntt-review.jp/archive/ntttechnical.php?contents=ntr200808le1.html].

The RTP payload format document describes the data packets and chapter 4 explains the transcoding possibility between G.711 and UEMCLIP. It is mentioned here that sub layer index 0 is standard G.711 data, but this sub layer block might or might not follow the headers.

[[Category:Audio Codecs]]
[[Category:Vocoders]]
[[Category:Undiscovered Audio Codecs]]
[[Category:MDCT Audio Codecs]]

On2 VP6

2009-12-22T21:09:30Z

Alex:

* FOURCCs: VP60, VP61, VP62
* Company: [[On2]]
* Whitepaper: http://www.on2.com/cms-data/pdf/1125607149174329.pdf ([[Mirrored Files|mirrored]])
* Samples: [http://samples.mplayerhq.hu/V-codecs/VP6/ http://samples.mplayerhq.hu/V-codecs/VP6/]
* Nice article form author of the codec (Paul Wilkins): http://www.dspdesignline.com/211100053?printableArticle=true

== Implementations ==

An early open source implementation could be found at http://libvp62.sourceforge.net/, but
was driven underground by On2 on copyright infringement claims.

This specification is said to be incomplete with regard to the On2 VP6 specification.

A decoder implementation may be found in the FFMPEG source file [http://svn.mplayerhq.hu/ffmpeg/trunk/libavcodec/vp6.c?view=markup vp6.c]

== Format ==

The aim here is to open this standard with a full description of the bitstream format and decoding process. Contributors from On2 especially encouraged here, but it is anticipated that this section will be completed through reverse engineering and by people who saw libvp62 source code before it was censored.

Please do not submit any copyrighted text or code here.

=== Introduction ===

VP6 uses unidirectional ("P-frame") and intra-frame (within the current frame) prediction. Entropy coding is performed using arithmetic (range?) coding and an 8x8 iDCT is used. The format supports dynamic adjustment of encoded video resolution. There are three variants of the VP6 codec, VP60 (Simple Profile), VP62 (Advanced Profile) and VP62 (Heightened Sharpness Profile).

=== Macroblocks ===

Each video frame is composed of an array of 16x16 macroblocks, just like [[MPEG-2]], [[MPEG-4]] parts 2 and 10. Each [[MB]] (macroblock) takes one of the following modes ("[[MV]]" means "motion vector"):

* Intra MB
* Inter MB, null MV, previous frame reference
* Inter MB, differential MV, previous frame reference
* Inter MB, four MVs, previous frame reference
* Inter MB, MV 1, previous frame reference
* Inter MB, MV 2, previous frame reference
* Inter MB, null MV, bookmarked frame reference
* Inter MB, differential MV, bookmarked frame reference
* Inter MB, MV 1, bookmarked frame reference
* Inter MB, MV 2, bookmarked frame reference

=== Frame Header ===

The frame header commences with a section that is encoded using conventional big-endian bit packing.

{| border="1"
! Syntax !! Number of bits !! Type !! Semantics
|-
| frame_mode || 1 || Enum || 0x0 signifies an intra frame
|-
| qp || 6 || Unsigned || Quantization parameter valid range 0..63
|-
| marker || 1 || Constant || 0=VP61/62, 1=VP60
|-
| if (frame_mode == 0) { || || ||0 equals to INTRA_FRAME
|-
| version || 5 || Constant || 6=VP60/61, 7=VP60(Electronic Arts), 8=VP62
|-
| version2 || 2 || Constant || 0=VP60, 3=VP61/62
|-
| interlace || 1 || Boolean || true (1) means interlace will be used
|-
| if (marker==1 or version2==0) {
|-
| offset || 16 || Unsigned || secondary buffer offset (bytes releative to start of buffer)
|-
| }
|-
| dim_y || 8 || Unsigned || Macroblock height of video
|-
| dim_x || 8 || Unsigned || Macroblock width of video
|-
| render_y || 8 || Unsigned || Display height of video
|-
| render_x || 8 || Unsigned || Display width of video
|-
| }else{
|-
| if (marker==1 or version2==0) {
|-
| offset || 16 || Unsigned || secondary buffer offset (bytes releative to start of buffer)
|-
| }
|-
| }
|}

If dim_x or dim_y have values different from the previous intra frame, then the resolution of the encoded image has changed.

Arithmetic coding commences at the next bit (which should be on a byte boundary):

{| border="1"
! Syntax !! Type !! Semantics
|-
| if (frame_mode == 0) {
|-
| marker1 || Equiprobable 2-bit || Ignored
|-
| } else {
|-
| bookmark || Equiprobable 1-bit || bookmark == 0x1 means this frame will be the next bookmark frame
|-
| filter1 || Equiprobable 1-bit ||
|-
| if (filter1 == 0x1) {
|-
| filter2 || Equiprobable 1-bit ||
|-
| }
|-
| filter_info || Equiprobable 1-bit ||
|-
| }
|-
| if (frame_mode == 0 <nowiki>||</nowiki> filter_info == 0x1) {
|-
| filter_mode1 || Equiprobable 1-bit ||
|-
| if (filter_mode1 == 0x1) {
|-
| filter_threshold1 || Equiprobable 5-bit ||
|-
| filter_motion_param || Equiprobable 3-bit ||
|-
| } else {
|-
| filter_mode2 || Equiprobable 1-bit ||
|-
| }
|-
| filter_mode3 || Equiprobable 4-bit ||
|-
| }
|-
| marker2 || Equiprobable 1-bit || Secondary buffer encoding algorithm. 0=Range coding, 1=Huffman coding.
|}

If the secondary buffer is present, coeffient symbols are read from the secondary buffer using the algorithm indicated by marker2. VP60 has "the ability to switch to a faster entropy encoding strategy to ensure smooth playback" and "the ability to decode different parts of the bitstream on different sub-processors (for instance the vlx and the core), to ensure better overall system utilization" [http://www.on2.com/cms-data/pdf/1125607149174329.pdf].

=== Entropy Coding ===

Described here is the decoding process for the arithmetically-coded (AC) parts of the bitstream. VP6 uses a 16-bit [http://en.wikipedia.org/wiki/Range_encoding range coding] scheme to code binary symbols.

The AC decoder maintains three state variables: ''code'', ''mask'' and ''high''.

====Initialization====

At initialization, the first two bytes of the AC bitstream are shifted into ''code''. The variable ''high'' is set to 0xff00. The variable ''mask'' is set to 0xffff.

====Decoding a Binary Value====

Each binary symbol has an associated probability ''p'' in the range 0 to 0xff.

A threshold, ''t'', is computed thus:

: ''t'' = 0x100 + ( 0xff00 & ( ( (''high''-0x100) * ''p'' ) >> 8 ) )

Equiprobable binary symbols are treated somewhat differently:

: ''t'' = 0xff00 & ( (''high''+0x100) >> 1 )

The binary value may then be decoded by comparing ''code'' and ''t''. If ''code'' is less than ''t'', the binary value is decoded as 0. If ''code'' is equal to or greater than ''t'', the binary value is decoded as 1.

If a 1 was decoded, then

: ''high'' = ''high'' - ''t''
: ''code'' = ''code'' - ''t''

If a 0 was decoded, then

: ''high'' = ''t''

The following renormalization is now repeated while (''high'' & 0x8000) is non-zero.

: ''high'' = 2 * ''high''
: ''code'' = 2 * ''code''
: ''mask'' = 2 * ''mask''
: if ((''mask'' & 0xff) == 0x00) {
:: ''code'' = ''code'' | <i>next byte from bitstream</i>
:: ''mask'' = ''mask'' | 0xff
:}

====Decoding an Equiprobable n-bit Integer Value====

Integer values are coded as a big-endian sequence of equiprobable binary values. To decode an n-bit equiprobable integer value, n equiprobable binary values should be decoded using the sequence above and left-shifted into an integral result variable.

=== Inverse DCT ===

Inverse DCT is performed on 8x8 blocks of pixels. The algorithm used is the same (or a small variation) of the one used for the [[On2 VP3|VP3]] decoder in [[FFmpeg]] [http://www1.mplayerhq.hu/cgi-bin/cvsweb.cgi/ffmpeg/libavcodec/vp3dsp.c?rev=1.9&content-type=text/x-cvsweb-markup&cvsroot=FFMpeg], the original vp3 iDCT code is here [http://svn.xiph.org/trunk/vp32/CoreLibs/CDXV/Vp31/dx/generic/IDctPart.c].

[[Category:Video Codecs]]
[[Category:Incomplete Video Codecs]]

Audible Audio

2009-08-20T22:55:12Z

Alex:

* Company: Audible.com
* Samples: http://samples.mplayerhq.hu/audible/

Proprietary container format from audible.com. There is no published specification. It may contain one of five different encodings which are numbered 1 thru 5. 1-3 are rumored to be [[ACELP.net]] at varying bitrates. #4 is [[MP3]]. #5 is some unknown Sony format.

* [http://www.digitalpreservation.gov/formats/fdd/fdd000103.shtml Description of the format from the US Library of Congress]
* [http://en.wikipedia.org/wiki/Audible.com Wikipedia entry]

To find files, use Google "filetype:aa audible".

Apparently this project knows everything below this: [http://code.google.com/p/pyaudibletags/source/browse/trunk/pyaudibletags.py PyAudibleTags]

=== File format ===

The file is built up of 5 parts:
* general header
* text based metadata
* some codec related header
* offset table
* data

==== General header ====

First 4 bytes is the file size including these four bytes.

==== Text based metadata ====

number_of_entires (32)
skip (8)

key_length (32)
value_length (32)
key (key_length)
value (value_length+1)

==== Offset table ====
number_of_entries (32)

type (32) [0 - meta?, 1 - meta?, 2 - audio packets, 3 - meta?, 4 - meta?]
offset (32) [must be relative, as the first entry in the list is always 0]

==== Parsing the file ====

This following Ruby code works for parsing the known parts:

video = File.new(ARGV[0])
puts "File size: #{video.read(4).unpack('N')[0].to_i}"
video.read(0xb4) # skip header
sizes = video.read(4).unpack('N')
puts "Number of entires: #{sizes[0].to_i}"
video.read(1) # skip
(1..sizes[0].to_i).each { |x|
sizes = video.read(8).unpack('NN')
key = video.read(sizes[0].to_i)
value = video.read(sizes[0].to_i+1)
puts "#{x} key(#{sizes[0].to_i})=#{key} value(#{sizes[0].to_i)=#{value}"
}
video.read(0x6f) # skip
sizes = video.read(4).unpack('N')
puts "Number of packet table entries: #{sizes[0].to_i}"
(1..sizes[0].to_i).each {
sizes = video.read(8).unpack('NN')
puts "type=#{sizes[0].to_i} offset=#{sizes[1].to_i}"
}

Sample output (stripped):

File size: 5762745
Number of entries: 19
...
13 key(5)=codec value(7)=acelp85
16 key(10)=HeaderSeed value(10)=1158166611
18 key(9)=HeaderKey value(43)=3759801365 1641076194 2988088058 4282540117
19 key(15)=EncryptedBlocks value(5)=39333
...
Number of packet table entries: 5461
type=0 offset=0
type=0 offset=1045
...

[[Category: Container Formats]]

YLC

2009-08-20T01:14:15Z

Alex:

* Website: http://spring-fragrance.mints.ne.jp/aviutl/ (Japanese)
* FourCC: YLC0

The website names it as "YUY2 Lossless Codec".

[[Category:Video Codecs]]
[[Category:Lossless Video Codecs]]
[[Category:Undiscovered Video Codecs]]

Audible Audio

2009-08-20T00:16:16Z

Alex:

* Company: Audible.com
* Samples: http://samples.mplayerhq.hu/audible/

Proprietary container format from audible.com. There is no published specification. It may contain one of five different encodings which are numbered 1 thru 5. 1-3 are rumored to be [[ACELP.net]] at varying bitrates. #4 is [[MP3]]. #5 is some unknown Sony format.

* [http://www.digitalpreservation.gov/formats/fdd/fdd000103.shtml Description of the format from the US Library of Congress]
* [http://en.wikipedia.org/wiki/Audible.com Wikipedia entry]

To find files, use Google "filetype:aa audible".

=== File format ===

The file is built up of 5 parts:
* general header
* text based metadata
* some codec related header
* offset table
* data

==== General header ====

First 4 bytes is the file size including these four bytes.

==== Text based metadata ====

number_of_entires (32)
skip (8)

key_length (32)
value_length (32)
key (key_length)
value (value_length+1)

==== Offset table ====
number_of_entries (32)

type (32) [0 - meta?, 1 - meta?, 2 - audio packets, 3 - meta?, 4 - meta?]
offset (32) [must be relative, as the first entry in the list is always 0]

==== Parsing the file ====

This following Ruby code works for parsing the known parts:

video = File.new(ARGV[0])
puts "File size: #{video.read(4).unpack('N')[0].to_i}"
video.read(0xb4) # skip header
sizes = video.read(4).unpack('N')
puts "Number of entires: #{sizes[0].to_i}"
video.read(1) # skip
(1..sizes[0].to_i).each { |x|
sizes = video.read(8).unpack('NN')
key = video.read(sizes[0].to_i)
value = video.read(sizes[0].to_i+1)
puts "#{x} key(#{sizes[0].to_i})=#{key} value(#{sizes[0].to_i)=#{value}"
}
video.read(0x6f) # skip
sizes = video.read(4).unpack('N')
puts "Number of packet table entries: #{sizes[0].to_i}"
(1..sizes[0].to_i).each {
sizes = video.read(8).unpack('NN')
puts "type=#{sizes[0].to_i} offset=#{sizes[1].to_i}"
}

Sample output (stripped):

File size: 5762745
Number of entries: 19
...
13 key(5)=codec value(7)=acelp85
16 key(10)=HeaderSeed value(10)=1158166611
18 key(9)=HeaderKey value(43)=3759801365 1641076194 2988088058 4282540117
19 key(15)=EncryptedBlocks value(5)=39333
...
Number of packet table entries: 5461
type=0 offset=0
type=0 offset=1045
...

[[Category: Container Formats]]

Audible Audio

2009-08-20T00:07:32Z

Alex:

* Company: Audible.com
* Samples: http://samples.mplayerhq.hu/audible/

Proprietary container format from audible.com. There is no published specification. It may contain one of five different encodings which are numbered 1 thru 5. 1-3 are rumored to be [[ACELP.net]] at varying bitrates. #4 is [[MP3]]. #5 is some unknown Sony format.

* [http://www.audible.com/formats Audible.com FAQ]
* [http://www.digitalpreservation.gov/formats/fdd/fdd000103.shtml Description of the format from the US Library of Congress]
* [http://en.wikipedia.org/wiki/Audible.com Wikipedia entry]

=== File format ===

The file is built up of 5 parts:
* general header
* text based metadata
* some codec related header
* offset table
* data

==== General header ====

First 4 bytes is the file size including these four bytes.

==== Text based metadata ====

number_of_entires (32)
skip (8)

key_length (32)
value_length (32)
key (key_length)
value (value_length+1)

==== Offset table ====
number_of_entries (32)

type (32) [0 - meta?, 1 - meta?, 2 - audio packets, 3 - meta?, 4 - meta?]
offset (32) [must be relative, as the first entry in the list is always 0]

==== Parsing the file ====

This following Ruby code works for parsing the known parts:

video = File.new(ARGV[0])
puts "File size: #{video.read(4).unpack('N')[0].to_i}"
video.read(0xb4) # skip header
sizes = video.read(4).unpack('N')
puts "Number of entires: #{sizes[0].to_i}"
video.read(1) # skip
(1..sizes[0].to_i).each { |x|
sizes = video.read(8).unpack('NN')
key = video.read(sizes[0].to_i)
value = video.read(sizes[0].to_i+1)
puts "#{x} key(#{sizes[0].to_i})=#{key} value(#{sizes[0].to_i)=#{value}"
}
video.read(0x6f) # skip
sizes = video.read(4).unpack('N')
puts "Number of packet table entries: #{sizes[0].to_i}"
(1..sizes[0].to_i).each {
sizes = video.read(8).unpack('NN')
puts "type=#{sizes[0].to_i} offset=#{sizes[1].to_i}"
}

Sample output (stripped):

File size: 5762745
Number of entries: 19
...
13 key(5)=codec value(7)=acelp85
16 key(10)=HeaderSeed value(10)=1158166611
18 key(9)=HeaderKey value(43)=3759801365 1641076194 2988088058 4282540117
19 key(15)=EncryptedBlocks value(5)=39333
...
Number of packet table entries: 5461
type=0 offset=0
type=0 offset=1045
...

[[Category: Container Formats]]

Audible Audio

2009-08-20T00:06:23Z

Alex:

* Company: Audible.com
* Samples: http://samples.mplayerhq.hu/audible/

Proprietary container format from audible.com. There is no published specification. It may contain one of five different encodings which are numbered 1 thru 5. 1-3 are rumored to be [[ACELP.net]] at varying bitrates. #4 is [[MP3]]. #5 is some unknown Sony format.

* [http://www.audible.com/formats Audible.com FAQ]
* [http://www.digitalpreservation.gov/formats/fdd/fdd000103.shtml Description of the format from the US Library of Congress]
* [http://en.wikipedia.org/wiki/Audible.com Wikipedia entry]

=== File format ===

The file is built up of 5 parts:
* general header
* text based metadata
* some codec related header
* offset table
* data

==== General header ====

First 4 bytes is the file size including these four bytes.

==== Text based metadata ====

number_of_entires (32)
skip (8)

key_length (32)
value_length (32)
key (key_length)
value (value_length+1)

==== Offset table ====
number_of_entries (32)

type (32) [0 - meta?, 1 - meta?, 2 - audio packets, 3 - meta?, 4 - meta?]
offset (32) [must be relative, as the first entry in the list is always 0]

==== Parsing the file ====

This following Ruby code works for parsing the known parts:

video = File.new(ARGV[0])
puts "File size: #{video.read(4).unpack('N')[0].ti_i}"
video.read(0xb4) # skip header
sizes = video.read(4).unpack('N')
puts "Number of entires: #{sizes[0].to_i}"
video.read(1) # skip
(1..sizes[0].to_i).each { |x|
sizes = video.read(8).unpack('NN')
key = video.read(sizes[0].to_i)
value = video.read(sizes[0].to_i+1)
puts "#{x} key(#{sizes[0].to_i})=#{key} value(#{sizes[0].to_i)=#{value}"
}
video.read(0x6f) # skip
sizes = video.read(4).unpack('N')
puts "Number of packet table entries: #{sizes[0].to_i}"
(1..sizes[0].to_i).each {
sizes = video.read(8).unpack('NN')
puts "type=#{sizes[0].to_i} offset=#{sizes[1].to_i}"
}

Sample output (stripped):

13 key(5)=codec value(7)=acelp85
16 key(10)=HeaderSeed value(10)=1158166611
18 key(9)=HeaderKey value(43)=3759801365 1641076194 2988088058 4282540117
19 key(15)=EncryptedBlocks value(5)=39333

Probably a seek table starts at 0x5f8:

[[Category: Container Formats]]

Audible Audio

2009-08-19T23:38:54Z

Alex:

Audible Audio

2009-08-19T23:37:56Z

Alex:

Audible Audio

2009-08-19T23:26:57Z

Alex:

Audible Audio

2009-08-19T23:08:40Z

Alex:

Audible Audio

2009-08-19T23:07:04Z

Alex:

Proprietary container format from audible.com. There is no published specification. It may contain one of five different encodings which are numbered 1 thru 5. 1-3 are rumored to be [[ACELP.net]] at varying bitrates. #4 is [[MP3]]. #5 is some unknown Sony format.

* [http://www.audible.com/formats Audible.com FAQ]
* [http://www.digitalpreservation.gov/formats/fdd/fdd000103.shtml Description of the format from the US Library of Congress]
* [http://en.wikipedia.org/wiki/Audible.com Wikipedia entry]

==== Parsing metadata ====

This following Ruby code works for parsing the metadata on the only sample available:

video = File.new(ARGV[0])
video.read(189) # skip header
(1..19).each { |x|
sizes = video.read(8).unpack('NN')
key = video.read(sizes[0].to_i)
value = video.read(sizes[0].to_i+1)
puts "#{x} key(#{sizes[0].to_i})=#{key} value(#{sizes[0].to_i)=#{value}"
}

Sample output (stripped):

13 key(5)=codec value(7)=acelp85
16 key(10)=HeaderSeed value(10)=1158166611
18 key(9)=HeaderKey value(43)=3759801365 1641076194 2988088058 4282540117
19 key(15)=EncryptedBlocks value(5)=39333

[[Category: Container Formats]]

VGM Video

2009-01-24T21:28:41Z

Alex:

* Company: [[XVD|XVD Corporation (DigitalStream-USA)]]
* FourCC: VGMV

VGM Video (aka VT2k aka BigBits) is video codec for realtime encoding.

[[Category:Video Codecs]]
[[Category:Undiscovered Video Codecs]]

Muzip

2009-01-24T18:07:49Z

Alex:

* Extensions: mzp, dat, tlp
* Company: [[XVD|Alaris (XVD Corporation)]]
* Sample: http://www.ila-ila.com/xvd-hist/sites/lab1454/eng/products/NCitySng12.mzp

This format is similar to wav but not same.

Decoder is here: http://www.ila-ila.com/xvd-hist/sites/lab1454/eng/products/muzip1.jar

==Header==
0..3 "RIFF"
4..7 unknown (file size? seems not)
8..11 "WAVE"
12..15 "fmt\0" (note: not space, it's null)
16..19 unknown (fmt\0 size? seems not)
20..21 unknown (format id? "0301". seems not)
22 number of channels
23 unknown (rest of number of channels?)
24..27 sampling rate
28..31 (byte per sec?)
32..33 (block size?)
34..35 (bit per sample?)
36..(\0) codec name ("CTP03", "CTP04", "CTP05", "CTP06")
42..43 unknown (rest of codec name or not?)
44 coefficients(compression ratio) (8-13 -> [8,12,15,16,24,10])
45 key frame
46 variable bitrate
47 reserved
48..51 unknown
52..55 "data"
56..59 total size

[[Category:Audio Codecs]]
[[Category:Undiscovered Audio Codecs]]
[[Category:Formats missing in FFmpeg]]

Alaris VideoGramPiX

2009-01-24T18:06:08Z

Alex:

* FourCCs: VGPX, VTLP
* Company: [[Alaris]]
* Samples:
** VTLP: http://samples.mplayerhq.hu/V-codecs/VTLP-VGPX/

Sample Java player available here: http://www.ila-ila.com/xvd-hist/sites/vgram/index.htm

[[Category:Video Codecs]]
[[Category:Undiscovered Video Codecs]]

Alaris

2009-01-24T18:05:38Z

Alex:

#REDIRECT [[XVD]]

XVD

2009-01-24T18:05:31Z

Alex:

[http://www.ila-ila.com/xvd-hist/ Unofficial history of XVD] including a [http://www.ila-ila.com/xvd-hist/timeline.html timeline] and saved pages of the companies.

XVD is connected to Alaris, Rightbits and Videogram. Alaris' most known codec is [[VGPX|VideoGram]]

== XVD Video Codecs ==

* [[VGM Video]]

== XVD Audio Codecs ==

* [[VGM Audio]]

[[Category:Multimedia-related Companies]]

XVD

2009-01-24T18:04:05Z

Alex:

[http://www.ila-ila.com/xvd-hist/ Unofficial history of XVD] including a [http://www.ila-ila.com/xvd-hist/timeline.html timeline] and saved pages of the companies.

XVD is connected to Alaris, Rightbits and Videogram.

== XVD Video Codecs ==

* [[VGM Video]]

== XVD Audio Codecs ==

* [[VGM Audio]]

[[Category:Multimedia-related Companies]]

Alaris VideoGramPiX

2009-01-24T18:03:15Z

Alex:

* FourCCs: VGPX, VTLP
* Company: [[Alaris]]
* Samples:
** VTLP: http://samples.mplayerhq.hu/V-codecs/VTLP-VGPX/

[[Category:Video Codecs]]
[[Category:Undiscovered Video Codecs]]

Alaris VideoGramPiX

2009-01-24T18:02:52Z

Alex:

* FourCCs: VGPX, VTLP
* Company: [Alaris]
* Samples:
** VTLP: http://samples.mplayerhq.hu/V-codecs/VTLP-VGPX/

[[Category:Video Codecs]]
[[Category:Undiscovered Video Codecs]]

VGM Video

2009-01-24T17:50:15Z

Alex: VT2k = BigBits

* Company: XVD Corporation (DigitalStream-USA)
* FourCC: VGMV

VGM Video (aka VT2k aka BigBits) is video codec for realtime encoding.

[[Category:Video Codecs]]
[[Category:Undiscovered Video Codecs]]

Metal Gear Solid VP3

2009-01-24T17:37:50Z

Alex:

* Extension: ''none (extracted from a game resource file)''
* Company: Silicon Knights
* Samples: http://samples.mplayerhq.hu/game-formats/mgs1-vp3/

The GameCube version of Konami's [http://www.mobygames.com/game/gamecube/metal-gear-solid-the-twin-snakes Metal Gear Solid: The Twin Snakes], developed by Silicon Knights, uses files that are suspected to contain [[VP3]] video data. Be advised that the file format described here explains files as extracted by [http://sourceforge.net/projects/extractor-gtk Extractor-GTK].

== File Format ==
All multi-byte numbers are big-endian.

The files are comprised of a series of chunks. Each chunk has the following layout:

bytes 0-3 0x0000000E
bytes 4-7 total length of the chunk
bytes 8-11 unknown; might be reserved and set to 0
bytes 12-15 length of the payload
bytes 16.. payload

Note that the chunks are 0-padded to 16-byte boundaries. Thus, the length of the payload + 16 does not necessarily equal the total length of the chunk.

The first chunk contains header information which has the following format:

bytes 0-3 close to the total size of the file, but not exact and should not be used
bytes 4-19 unknown
bytes 20-23 video width in pixels
bytes 24-27 video height in pixels
bytes 28-35 unknown
bytes 36-39 possibly the frame rate (18 fps?)
bytes 40-43 video codec FourCC ('13PV', VP31 spelled backwards)
bytes 44-63 unknown

The remainder of the chunks apparently contain raw VP31 data.

[[Category:Game Formats]]
[[Category:Formats missing in FFmpeg]]
[[Category:Undiscovered Game Formats]]

ACT

2007-11-20T02:43:57Z

Alex: G729A wikipedia link

* Samples: http://samples.mplayerhq.hu/A-codecs/act/
* Working decoder: http://www.netac.com/Download/C635/C635%20Driver&Tools.zip

ACT files are created by [http://en.wikipedia.org/wiki/Chinese_MP4/MTV_Player '''Chinese-made portable MP3 players'''] when recording from the internal microphone.

ACT files uses the [http://en.wikipedia.org/wiki/G.729a G729A] speech compression codec. There are 3 different ways to record to this format from a player.

*Fine Rec
*Long Rec
*Long Vox, in this mode the player will record when voice activated.

==ACT File Format==

=== Bitstream ===

These 3 modes map to 2 bitstream formats, the Fine and Long bitstream formats.

{| border="1" cellpadding="5" style="border-collapse: collapse; border-style: dashed; border-color: #2f6fab;"
|- bgcolor="#f0f0f0" |
! Name!! Sample rate!! Frame size!! Frames per chunk !! Chunk size !! Padding bytes
|-
|Fine||8000||10||51||510||2
|-
|Long||4400||22||23||506||6
|}

Files are always aligned to 512 bytes boundary and contains 512 byte header and chunks of the same size. Each chunk consists of fixed number of frames and padding bytes.

=== Header ===
{| border="1" cellpadding="5" style="border-collapse: collapse; border-style: dashed; border-color: #2f6fab;"
|- bgcolor="#f0f0f0" |
! Name !! Offset !! Bytes !! Description
|-
|riff tag||0||4||'RIFF'
|-
|riff size||4||4||data_size + 36
|-
|wave tag||8||4||'WAVE'
|-
|fmt tag||12||4||'fmt '
|-
|wave header size||16||4||Always 0x10
|-
|wave format||20||2||PCM's 0x01<ref name="pcm">This collides with the values for regular 16bits PCM</ref>
|-
|channels||22||2||0x01(mono)
|-
|sample rate||24||4||8000 or 4400
|-
|bit rate||28||4||16000 or ?
|-
|block align||32||2||Always 0x02
|-
|bits per sample||34||2||Always 16
|-
|data_tag||36||4||'data'
|-
|data_size||40||4||chunks_count * 8 * chunk_size<ref name="chunk_size"> chunk_size is determined from the bitstream table.</ref>
|-
|reserved||44||212||filled by zero
|-
|act tag||256||1||Always 0x84
|-
|millisec||257||2||milliseconds part of duration value
|-
|seconds||259||1||seconds part of duration value
|-
|minutes||260||4||minutes part of duration value
|-
|reserved||264||248||filled by zero
|}

<references/>

=== Frame format ===

First half of ACT frame contains odd bytes, while the second contains even bytes of encoded G.729 frame.

for(i=0 ; i<frame_size/2; i++)
{
g729_data[2*i]=act_data[i]
g729_data[2*i+1]=act_data[frame_size/2+i]
}

=== G.729A Codec parameters ===

Table of transmitted parameters indices. For each parameter, the Most Significant Bit (MSB) is transmitted first.

{| border="1" cellpadding="5" style="border-collapse: collapse; border-style: dashed; border-color: #2f6fab;"
|- bgcolor="#f0f0f0" |
! Symbol !! Description !! Bits (Fine) !! Bits (Long)
|-
| L0 || Switched MA predictor of LSP quantizer || 1 || 1
|-
| L1 || First stage vector of quantizer || 7 || 7
|-
| L2 || Second stage lower vector of LSP quantizer || 5 || 5
|-
| L3 || Second stage higher vector of LSP quantizer || 5 || 5
|-
| P1 || Pitch delay first subframe || 8 || 8
|-
| P0 || Parity bit for Pitch delay || 1 || 1
|-
| C1 || Fixed codebook first subframe || 13 || 12
|-
| S1 || Signs of fixed-codebook pulses 1st subframe || 4 || 9
|-
| GA1 || Gain codebook (stage 1) 1st subframe || 3 || 3
|-
| GB1 || Gain codebook (stage 1) 1st subframe || 4 || 4
|-
| P2 || Pitch delay second subframe || 5 || 5
|-
| C2 || Fixed codebook 2nd subframe || 13 || 12
|-
| S2 || Signs of fixed-codebook pulses 2nd subframe || 4 || 9
|-
| GA2 || Gain codebook (stage 1) 2nd subframe || 3 || 3
|-
| GB2 || Gain codebook (stage 1) 2nd subframe || 4 || 4
|-
! !! Total !! 80 !! 88
|}

In Long mode 2 ACT frames form a G.729 frame.

[[Category:Audio Codecs]]
[[Category:Undiscovered Audio Codecs]]

Talk:ClearVideo

2007-11-20T02:40:50Z

Alex:

Which RealVideo codecs are based on this?

Also based on some of their patents, it looks like they switched to wavelets for UCOD, while their original image compression (called FIF files) were "fractal based".

Vividas VIV

2007-11-19T03:45:48Z

Alex:

* Extension: viv
* MIME type: video/vividas
* Company: [http://www.vividas.com/ Vividas Pty Ltd]
* Samples: [http://video.vividas.com/sales/Honda_CRV_TVC_sales_048i.viv TBD]

VIV is a proprietary web audio/video streaming format used by the Vividas Player. The player, available for Win32, Mac OSX and Sun platforms, is distributed as native binary and installed on-demand via Java or ActiveX.

Developer blog: "Vividas is the company behind 'Vividas Player' (Suprise!) which is a video streaming platform (powered by VP6/VP7) which is very much like (to dumb things down) quicktime or Windows Media Player for streaming content, only with a twist. Its ultra fast, compact, installation-requiremente-requireded-no and very bandwidth efficient... The decoder - written in C/C++ with a healthy mix of ASM - is around 250-300Kb. Most of the internals is hush hush so I cant reveal much, but what is interesting is the uptake of broadband across the globe and the future prospects of HD-Quality video streaming and where this technology is headed" [http://blogs.developerfusion.co.uk/blogs/thushan/archive/2005/08/11/821.aspx]

Actually the decoder is a 800kb DLL.

The player has support for Speex, Vorbis and VP6.

Layout of the file:
{| border="1" cellpadding="5" style="border-collapse: collapse; border-style: dashed; border-color: #2f6fab;"
|- bgcolor="#f0f0f0" |
! Size !! Meaning !! Default value
|-
|9 bytes || Magic || "vividas03"
|-
|1 byte || Unknown || 84 or 85 in most files
|-
|1 byte || Unknown || 20, 62, 65 in most files
|-
|1 byte || Unknown || Always 1 ?
|-
|1 byte || Length of name field
|-
|x bytes || Name field
|-
| || Encrypted data here
|}

Altought data is encrypted, an index table is recognizable just after the header.

===External Resources===
Extended company and product description is available on [http://en.wikipedia.org/wiki/Vividas Wikipedia].

[http://www.on2.com/company/news-room/press-releases/?id=254 "Vividas Licenses TrueMotion VP7 for Mass Distribution of High Quality Video"] January 13th, 2005

[http://www.vividas.com/footer/opensource.html Vividas - Open Source Acknowledgement]
[[Category:Container Formats]]

Flash screen video

2007-11-19T03:38:34Z

Alex: Add into Screen Capture category

* FOURCC: FSV1
* Company: [[Adobe]]

This is a simple screen capture codec. The screen is divided into x*16 * y*16 pixel blocks.
Then only the "changed since last frame" blocks are transmitted zlib-compressed. The video is contained in [[Flash Video]] files.

[[Category:Video Codecs]]
[[Category:Lossless Video Codecs]]
[[Category:Screen Capture Video Codecs]]

Vividas VIV

2007-11-19T02:21:36Z

Alex: Initial format description

* Extension: viv
* MIME type: video/vividas
* Company: [http://www.vividas.com/ Vividas Pty Ltd]
* Samples: [http://video.vividas.com/sales/Honda_CRV_TVC_sales_048i.viv TBD]

VIV is a proprietary web audio/video streaming format used by the Vividas Player. The player, available for Win32, Mac OSX and Sun platforms, is distributed as native binary and installed on-demand via Java or ActiveX.

Developer blog: "Vividas is the company behind 'Vividas Player' (Suprise!) which is a video streaming platform (powered by VP6/VP7) which is very much like (to dumb things down) quicktime or Windows Media Player for streaming content, only with a twist. Its ultra fast, compact, installation-requiremente-requireded-no and very bandwidth efficient... The decoder - written in C/C++ with a healthy mix of ASM - is around 250-300Kb. Most of the internals is hush hush so I cant reveal much, but what is interesting is the uptake of broadband across the globe and the future prospects of HD-Quality video streaming and where this technology is headed" [http://blogs.developerfusion.co.uk/blogs/thushan/archive/2005/08/11/821.aspx]

Actually the decoder is a 800kb DLL.

The player has support for Speex and Vorbis.

Layout of the file:
{| border="1" cellpadding="5" style="border-collapse: collapse; border-style: dashed; border-color: #2f6fab;"
|- bgcolor="#f0f0f0" |
! Size !! Meaning !! Default value
|-
|9 bytes || Magic || "vividas03"
|-
|3 bytes || Unknown
|-
|1 byte || Length of name field
|-
|x bytes || Name field
|-
| || Data here
|}

===External Resources===
Extended company and product description is available on [http://en.wikipedia.org/wiki/Vividas Wikipedia].

[http://www.on2.com/company/news-room/press-releases/?id=254 "Vividas Licenses TrueMotion VP7 for Mass Distribution of High Quality Video"] January 13th, 2005

[http://www.vividas.com/footer/opensource.html Vividas - Open Source Acknowledgement]
[[Category:Container Formats]]

Vividas VIV

2007-11-19T01:48:01Z

Alex: Speex/Vorbis

* Extension: viv
* MIME type: video/vividas
* Company: [http://www.vividas.com/ Vividas Pty Ltd]
* Samples: [http://video.vividas.com/sales/Honda_CRV_TVC_sales_048i.viv TBD]

VIV is a proprietary web audio/video streaming format used by the Vividas Player. The player, available for Win32, Mac OSX and Sun platforms, is distributed as native binary and installed on-demand via Java or ActiveX.

Developer blog: "Vividas is the company behind 'Vividas Player' (Suprise!) which is a video streaming platform (powered by VP6/VP7) which is very much like (to dumb things down) quicktime or Windows Media Player for streaming content, only with a twist. Its ultra fast, compact, installation-requiremente-requireded-no and very bandwidth efficient... The decoder - written in C/C++ with a healthy mix of ASM - is around 250-300Kb. Most of the internals is hush hush so I cant reveal much, but what is interesting is the uptake of broadband across the globe and the future prospects of HD-Quality video streaming and where this technology is headed" [http://blogs.developerfusion.co.uk/blogs/thushan/archive/2005/08/11/821.aspx]

Actually the decoder is a 800kb DLL.

The player has support for Speex and Vorbis.

===External Resources===
Extended company and product description is available on [http://en.wikipedia.org/wiki/Vividas Wikipedia].

[http://www.on2.com/company/news-room/press-releases/?id=254 "Vividas Licenses TrueMotion VP7 for Mass Distribution of High Quality Video"] January 13th, 2005

[http://www.vividas.com/footer/opensource.html Vividas - Open Source Acknowledgement]
[[Category:Container Formats]]

NCT Soft ALF2CD ACM

2007-11-19T01:07:46Z

Alex:

* Codec ID: 0x1FC4
* Website: http://www.nctsoft.com/
* Author: Lev Bannov / leksei Myasnikov

Almost nothing is known about this audio codec.

[[Category:Audio Codecs]]
[[Category:Undiscovered Audio Codecs]]

Dakx Wav

2007-11-19T00:31:24Z

Alex: Add website, patent, simple source

* Description: [http://www.rjamorim.com/rrw/daxwav.html Dakx Wav]
* Website: http://www.dakx.com/
* Patent: [[http://www.google.com/patents?vid=USPAT5825830 USPAT 5,825,830]
* Simple decoder/encoder: http://www.dakx.com/software/simdaxg.c

[[Category: Audio Codecs]]
[[Category: Lossless Audio Codecs]]
[[Category: Undiscovered Audio Codecs]]

SBC

2007-11-18T20:45:26Z

Alex: Add category listing.

The name SBC is used among more speech codecs.

Known codecs named SBC:
* The oldest codec probably is the Lernout & Hauspie SBC family, which is shipped with standard Windows versions.
* The Bluetooth group standardised a speech codec named [[Bluetooth SBC|SBC]].
* [[Octel SBC]] was created at Lucent and is used at Vodafone for Voicemail services.

[[Category:Audio Codecs]]
[[Category:Vocoders]]

SBC

2007-11-18T20:43:34Z

Alex: General SBC article, linking to the three known ones.

Octel SBC

2007-11-18T16:53:42Z

Alex: Samples URL changed to Octel-SBC

* mime-type: audio/vnd.octel.sbc
* samples: http://samples.mplayerhq.hu/A-codecs/Octel-SBC/

According to the [http://www.iana.org/assignments/media-types/audio/vnd.octel.sbc IANA vnc.octel.sbc] submission: "The data is a binary format with no header or trailer. The compression algorithm is a proprietary speech compression algorithm developed by the Octel Messaging Division of Lucent Technologies."

[[Category:Audio Codecs]]
[[Category:Vocoders]]
[[Category:Formats missing in FFmpeg]]

Talk:Bluetooth SBC

2007-11-18T16:35:08Z

Alex:

The name of the page should be Bluetooth_SBC. Any administrators there?

Bluetooth SBC

2007-11-18T16:31:38Z

Alex: vnd.octel.sbc and the samples are not the Bluetooth SBC

* LGPL SBC library: http://www.holtmann.org/linux/bluetooth/sbc.html

The Bluetooth low-complexity, subband codec (SBC) is described in the specification of the Advanced Audio Distribution Profile (A2DP) in appendix B (page 50). SBC is an audio coding system specially designed for Bluetooth audio and video applications to obtain high quality audio at medium bitrates, and having a low computational complexity. It uses 4 or 8 subbands, an adaptive bit allocation algorithm and simple adaptive block PCM quantizers. The SBC audio coding system is based on an earlier system: F. de Bont, M. Groenewegen and W. Oomen, "A High Quality Audio-Coding System at 128 kb/s",
98th AES Convention, Febr. 25-28, 1995.

The A2DP test specification contains a reference encoder and decoder for the SBC codec. These programs are only available for Windows and only in binary form.

[[Category:Audio Codecs]]
[[Category:Vocoders]]
[[Category:Formats missing in FFmpeg]]

Octel SBC

2007-11-18T16:31:22Z

Alex: Forget to place category listing

* mime-type: audio/vnd.octel.sbc
* samples: http://samples.mplayerhq.hu/A-codecs/SBC/

According to the [http://www.iana.org/assignments/media-types/audio/vnd.octel.sbc IANA vnc.octel.sbc] submission: "The data is a binary format with no header or trailer. The compression algorithm is a proprietary speech compression algorithm developed by the Octel Messaging Division of Lucent Technologies."

[[Category:Audio Codecs]]
[[Category:Vocoders]]
[[Category:Formats missing in FFmpeg]]