https://wiki.multimedia.cx/api.php?action=feedcontributions&user=DrV&feedformat=atom
MultimediaWiki - User contributions [en]
2024-03-19T11:31:34Z
User contributions
MediaWiki 1.39.5
https://wiki.multimedia.cx/index.php?title=Small_FFmpeg_Tasks&diff=12555
Small FFmpeg Tasks
2010-04-20T03:38:27Z
<p>DrV: Remove GIF LZW encoder task: already done</p>
<hr />
<div>This page contains ideas for small, relatively simple tasks for the [[FFmpeg]] project. People who might be interested in trying one of these tasks:<br />
* Someone who wants to contribute to FFmpeg and needs to find a well-defined task to start with<br />
* Someone who wishes to qualify for one of FFmpeg's coveted [[FFmpeg Summer Of Code|Summer of Code]] project slots<br />
* An existing FFmpeg developer who has been away from the project for a while and needs a smaller task as motivation for re-learning the codebase<br />
<br />
For other tasks of varying difficulty, see the [[Interesting Patches]] page.<br />
<br />
'''If you would like to work on one of these tasks''', please take these steps:<br />
* Subscribe to the [https://lists.mplayerhq.hu/mailman/listinfo/ffmpeg-devel FFmpeg development mailing list] and indicate your interest<br />
* Ask [[User:Multimedia Mike|Multimedia Mike]] for a Wiki account so you can claim your task on this Wiki<br />
<br />
'''If you would like to add to this list''', please be prepared to explain some useful details about the task. Excessively vague tasks with no supporting details will be ruthlessly deleted.<br />
<br />
<br />
=== Finish up a previous incomplete SoC project ===<br />
<br />
Several SoC projects from previous years have not yet made it into FFmpeg. Taking any of them and finishing them up to the point that they can be included should make for a good qualification task. Check out the [[FFmpeg Summer Of Code]] overview page and look for the unfinished projects, like AMR-NB, Dirac, TS muxer, JPEG 2000.<br />
<br />
=== Generic Colorspace system ===<br />
This task involves adding support more than 8 bits per component (Y on 10 bits, U on 10 bits, V on 10 bits for example)<br />
and generic simple conversion to other colorspaces.<br />
<br />
''Does this have to do with revising FFmpeg's infrastructure? If so, then it doesn't feel like a qualification task. If it's something simpler, then the vague description does not convey that simplicity. Please expound.'' --[[User:Multimedia Mike|Multimedia Mike]] 12:56, 25 February 2008 (EST)<br />
<br />
''I don't think so, extending PixFmt to extended structure with finegrained description like depth, range values, colorspace, sample period, and write generic simple conversion from all formats to all others, like suggested by Michael on the mailing list. Conversion routine can be a good qualification task for video encoders/decoders. What do you think ?<br />
--[[User:Bcoudurier|Baptiste Coudurier]] 00:30, 29 February 2008 (EST)<br />
<br />
''* Adding the [[YCoCg]] colorspace (with different sized planes) for RGB sourced pictures would be nice too. [[User:Elte|Elte]] 07:15, 16 March 2009 (EDT)<br />
<br />
=== Make the SoC dts encoder multichannel capable ===<br />
Here is a skeleton for a dts encoder http://svn.mplayerhq.hu/soc/dcaenc/, currently it can only encode stereo streams.<br />
The task is to extend it to support 5.1 channels also.<br />
<br />
Specs and info can be found here:<br />
http://wiki.multimedia.cx/index.php?title=DTS<br />
<br />
=== Extend GIF Encoder and Decoder to support Animated GIFs ===<br />
<br />
=== Implement a Vivo demuxer for FFmpeg ===<br />
Implement an FFmpeg demuxer for the [[Vivo]] file format. The best reference for understanding the format would be MPlayer's [http://svn.mplayerhq.hu/mplayer/trunk/libmpdemux/demux_viv.c?view=markup existing .viv demuxer].<br />
<br />
This task corresponds to issue 99: http://roundup.ffmpeg.org/roundup/ffmpeg/issue99<br />
<br />
''I am ready to help out with understanding MPlayer's demuxer, esp. MPlayer API stuff if necessary.<br />
--[[User:Reimar|Reimar]] 15:46, 1 March 2008 (EST)<br />
<br />
=== Port missing demuxers from MPlayer to FFmpeg ===<br />
MPlayer supports a few container formats in libmpdemux that are not yet present in libavformat. Porting them over and gettting them relicensed as LGPL or reimplementing them from scratch should make reasonable small tasks.<br />
<br />
# TiVo -- ''Jai Menon is working on this''<br />
# VIVO -- ''Daniel Verkamp has a patch for this''<br />
# SL support for MPEG-TS (anyone got samples?)<br />
# MNG<br />
<br />
=== Optimal Huffman tables for (M)JPEG ===<br />
This task is outlined at http://guru.multimedia.cx/small-tasks-for-ffmpeg/ and is tracked in the issue tracker: http://roundup.ffmpeg.org/roundup/ffmpeg/issue267<br />
<br />
=== M95 Playback System ===<br />
This task is to implement an FFmpeg playback subsystem for [[M95]] files. This will entail writing a new file demuxer and video decoder (the audio is already uncompressed), both of which are trivial by FFmpeg standards. [[M95|The M95 page]] contains the specs necessary to complete this task and points to downloadable samples.<br />
<br />
=== BRP Playback System ===<br />
This task is to implement an FFmpeg playback subsystem for [[BRP]] files. This will entail writing a new file demuxer as well as a video decoder that can handle at least 2 variations of format data. Further, write an audio decoder for the custom DPCM format in the file. All of these tasks are considered trivial by FFmpeg standards. [[BRP|The BRP page]] contains the specs necessary to complete this task and points to downloadable samples for both known variations.<br />
<br />
=== 16-bit Interplay Video Decoder ===<br />
FFmpeg already supports [[Interplay MVE]] files with [[Interplay Video|8-bit video data]] inside. This task involves supporting 16-bit video data. The video encoding format is mostly the same but the pixel size is twice as large. Engage the ffmpeg-devel list to discuss how best to approach this task.<br />
<br />
=== 16-bit VQA Video Decoder ===<br />
FFmpeg already supports Westwood [[VQA]] files. However, there are 3 variations of its custom video codec. The first 2 are supported in FFmpeg. This task involves implementing support for the 3rd variation. Visit the VQA samples repository: http://samples.mplayerhq.hu/game-formats/vqa/ -- The files in the directories Tiberian Sun VQAs/, bladerunner/, and dune2000/ use the 3rd variation of this codec. The [[VQA|VQA page]] should link to all the details you need to support this format.<br />
<br />
Discussion/patch: ([http://lists.mplayerhq.hu/pipermail/ffmpeg-devel/2009-March/065348.html reference])<br />
<br />
=== HNM4 Playback System ===<br />
This task is to implement an FFmpeg playback subsystem for [[HNM4]] variant of the [[HNM]] format. This will entail writing a new file demuxer and video decoder, both of which are trivial by FFmpeg standards. [[HNM4|The HNM4 page]] contains the specs necessary to complete this task and links to downloadable samples.<br />
<br />
=== Apple RPZA encoder ===<br />
A patch was once sent to the ffmpeg-devel mailing list to include an encoder for the [[Apple RPZA]] video codec. That code can be found on the "[[Interesting Patches]]" page. This qualification task involves applying that patch so that it can compile with current FFmpeg SVN code and then cleaning it up per the standards of the project. Engage the mailing list to learn more about what to do.<br />
:''Claimed by Jai Menon''<br />
<br />
=== QuickTime Edit List Support ===<br />
Implement edit list support in FFmpeg's QuickTime demuxer (libavformat/mov.c). This involves parsing the 'elst' atom in a QuickTime file. For a demonstration of how this is a problem, download the file menace00.mov from http://samples.mplayerhq.hu/mov/editlist/ and play it with ffplay or transcode it with ffmpeg. Notice that the audio and video are ever so slightly out of sync. Proper edit list support will solve that. Other samples in that directory also presumably exhibit edit list-related bugs. The [http://xine.cvs.sourceforge.net/xine/xine-lib/src/demuxers/demux_qt.c?view=markup Xine demuxer] has support for this, it might be useful for hints.<br />
<br />
(patch was submitted to ffmpeg-devel , around 14 March 2009) <br />
<br />
=== Implement the Flash Screen Video codec version 2 ===<br />
FFmpeg is missing both a decoder and an encoder. Would be nice to have that.<br />
<br />
:''Daniel Verkamp is working on this''<br />
<br />
=== Add wma fixed point decoder back into libavcodec ===<br />
http://svn.rockbox.org/viewvc.cgi/trunk/apps/codecs/libwma/<br />
Rockbox's fixed-point WMA decoder was adapted from the decoder in libavcodec.<br />
<br />
=== RealAudio 14.4 encoder ===<br />
FFmpeg contains a decoder for [[RealAudio 14.4]], a farily simple integer CELP codec. Write an encoder. This would be a good qualification task for anyone interested in working on AMR, Speex, or sipr.<br />
<br />
=== VC1 timestamps in m2ts ===<br />
<br />
Codec copy of VC1 from m2ts currently doesn't work. Either extend the VC1 parser to output/fix timestamps, or fix the timestamps from m2ts demuxing.<br />
<br />
=== FLIC work ===<br />
<br />
Revise the [[Flic Video]] decoder at libavcodec/flicvideo.c to support video transported in AVI or MOV files while making sure that data coming from the usual FLI files still works. 'AFLC' and 'flic' FourCC samples are linked from the [[Flic Video]] page.<br />
<br />
=== CJPG format ===<br />
<br />
Extend FFmpeg's MJPEG decoder to handle the different frames/packing of CJPG. Samples at: http://roundup.ffmpeg.org/roundup/ffmpeg/issue777<br />
<br />
=== flip flag for upside-down codecs ===<br />
<br />
<pre>about the flip, a patch that decodes images fliped when<br />
codec_tag == ff_get_fourcc("GEOX") is welcome.<br />
its a metter of 2lines manipulating data/linesize of imgages after<br />
get_buffer() or something similar<br />
[...]<br />
-- <br />
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB<br />
</pre><br />
more info:<br />
http://roundup.ffmpeg.org/roundup/ffmpeg/issue741<br />
<br />
=== lavf-based concatenation tool ===<br />
<br />
Unless we have multiple files input in FFmpeg, it would be nice to have some libavformat-based tool that would extract frames from multiple files (possible different containers as well) and put them into single one.<br />
<br />
=== cljr and vcr1 encoders ===<br />
According to this: http://lists.mplayerhq.hu/pipermail/ffmpeg-devel/2009-February/063647.html both of the encoders are disabled, and won't compile if enabled. Michael would prefer to keep them around, and have someone grow them into full encoders.<br />
<br />
=== implement some colorspace fourcc/codecs ===<br />
some colorspace formats were uploaded to http://samples.mplayerhq.hu/V-codecs/<br />
including:<br />
CYUV.AVI is 8 Bit Interleaved 4:2:2<br />
a12v.avi is 4:2:2:4 10 Bit Interleaved<br />
auv2.avi is 4:2:2:4 8 Bit Interleaved<br />
and V-codecs/yuv8/MAILTEST.AVI .<br />
<br />
it might decode with current pixfmts, for that all you will need is:<br />
cd ffmpeg<br />
svn di -r20378:20379<br />
<br />
step by step tutorial for adding new input formats to swscale:<br />
cd mplayer/libswscale/<br />
svn di -r20426:20427<br />
the hunks 3 and 5 you dont need, they are optional special converters<br />
also the change to isSupportedOut() you dont need<br />
above will add a new input format<br />
<br />
another example for adding an input format<br />
cd mplayer/libswscale/<br />
svn di -r20604:20605<br />
<br />
=== Implement Phantom Cine demuxer and Bayer format support for swscale ===<br />
The format is described here:<br />
http://wiki.multimedia.cx/index.php?title=Phantom_Cine<br />
It will need support for Bayer -> RGB conversion in swscale to make the demuxer useful though.<br />
<br />
=== Make the rtp demuxer support rtcp BYE packets ===<br />
rtcp BYE (203) packets are sent from the sender to the receiver to notify that a stream has ended.<br />
FFmpeg currently ignores them.<br />
<br />
Sample url rtsp://media.lscube.org/tests/tc.mov<br />
<br />
=== support for [[YCoCg]]/RGB colorspace in FFV1 ===<br />
Add support for [[YCoCg]] and [[RGB]] encoded sources for the [[FFV1]] codec<br />
<br />
This would add a free lossless intra-frame RGB codec for all by FFmpeg supported platforms (most important MacOS + Windows) which is often asked for video editing in video forums (e.g. slashcam.de)<br />
<br />
=== Metal Gear Solid Video format demuxer ===<br />
Write a demuxer to play video files harvested from the game Metal Gear Solid: The Twin Snakes. The format is described on the wiki page [[Metal Gear Solid VP3]] (which also contains links to samples). This page is based on observations and conjecture, so remember to engage the ffmpeg-devel mailing list with questions.<br />
<br />
=== [[IFF#ANIM|IFF ANIM]] decoder ===<br />
Modify libavformat/iff.c to handle this chunk and write a decoder for the format. The wiki page at [[IFF#ANIM|IFF ANIM]] has links to more information and source code. Samples can be found at http://www-user.tu-chemnitz.de/~womar/projects/iffanim/iffanim_samplepack.zip .<br />
<br />
=== [[CDXL]] decoder ===<br />
http://roundup.ffmpeg.org/roundup/ffmpeg/issue1012<br />
<br />
Write a decoder for this format using the information in the [[CDXL]] wiki page<br />
Discussed for the 2009 SoC <br />
<br />
=== port missing decoders/demuxers from other open source projects. ===<br />
<br />
http://www.mega-nerd.com/libsndfile/#Features<br />
Paris Audio File PAF<br />
IRCAM SF<br />
GNU Octave 2.0 MAT4<br />
GNU Octave 2.1 MAT5<br />
Portable Voice Format PVFSound<br />
Designer II SD2<br />
samples are here: http://www.mega-nerd.com/tmp/SoundFileCollection-20050711-0902.tgz<br />
<br />
http://www.hawksoft.com/hawkvoice/<br />
HVDI_VOICE_DATA- packet<br />
[[GSM]]<br />
LPC<br />
CELP<br />
LPC10<br />
<br />
http://sourceforge.net/projects/vgmstream<br />
150+ formats: http://vgmstream.svn.sourceforge.net/viewvc/vgmstream/readme.txt<br />
<br />
http://www.imagemagick.org<br />
http://www.graphicsmagick.org/formats.html<br />
many image formats not in ffmpeg yet.<br />
<br />
http://gpac.sourceforge.net/<br />
[[MPEG-4 BIFS]]<br />
3GPP DIMS<br />
[[LASeR]]<br />
SAF<br />
SVG<br />
[[Synchronized Multimedia Integration Language|SMIL]]<br />
VRML<br />
X3D<br />
XMT<br />
<br />
http://adplug.sourceforge.net/<br />
http://adplug.sourceforge.net/library/<br />
many OPL2/OPL3 audio formats not in ffmpeg yet.<br />
<br />
http://mikmod.raphnet.net/<br />
http://mikmod.raphnet.net/#features<br />
many music pattern formats not in ffmpeg yet.<br />
<br />
http://www.fly.net/~ant/libs/audio.html#Game_Music_Emu<br />
AY<br />
GBS<br />
GYM<br />
HES<br />
KSS<br />
NSF, NSFE<br />
SAP<br />
[[SNES-SPC700 Sound Format]]<br />
VGM, VGZ<br />
<br />
=== port [[Ut Video]] decoder/encoder ===<br />
gpl v2 decoder/encoder at wiki page<br />
<br />
Claimed by shankhs ch as a GSoC 2010 qualification project.<br />
<br />
=== Sony psp demuxer ===<br />
create/port a demuxer for the sony playstation portable format PMP.<br />
*Samples: http://samples.mplayerhq.hu/playstation/psp/<br />
*mplayer demuxer: http://mplayer-ww.svn.sourceforge.net/viewvc/mplayer-ww/trunk/mplayer/libmpdemux/demux_pmp.c<br />
<br />
=== libswscale PAL8 output ===<br />
<br />
See the thread: "[RFC] libswscale palette output implementation":<br />
http://thread.gmane.org/gmane.comp.video.ffmpeg.devel/101397<br />
<br />
<br />
=== vloopback output support ===<br />
<br />
vloopback is a linux kernel device which allows to create a virtual video device where<br />
programs can write, and can be accessed as a normal video device:<br />
http://www.lavrsen.dk/twiki/bin/view/Motion/VideoFourLinuxLoopbackDevice<br />
<br />
This would allow to write the ffmpeg output to a vloopdevice and be displayed by some a<br />
program reading from such device (e.g. skype, a voip client etc.).<br />
<br />
An example of a program which uses vloopback:<br />
http://www.ws4gl.org/<br />
<br />
<br />
=== Port video filters from MPlayer/VLC/Mjpegtools/Effectv/etc etc to libavfilter ===<br />
<br />
There are plenty programs providing their own filters, many of them may be easily ported to the <br />
superior ;-) framework of libavfilter. Also may be possible to create wrappers around other libraries<br />
(e.g. opencv, libgimp, libshowphoto, libaa).<br />
<br />
=== Add weighted motion compensation for B-frames in RV3/4 ===<br />
<br />
RealVideo 3 and 4 uses weighted motion compensation for B-frames (like H.264) but current code<br />
always uses simple averaging. Reverse-engineer weighted MC functions for B-frames and make<br />
RV3/4 decoder use them.<br />
<br />
[[Category:FFmpeg]]</div>
DrV
https://wiki.multimedia.cx/index.php?title=Kega_Video&diff=12233
Kega Video
2010-02-03T15:47:31Z
<p>DrV: </p>
<hr />
<div>* FourCC: KGV1<br />
* Sample: http://samples.mplayerhq.hu/V-codecs/kgv1.avi<br />
<br />
Codec used for capturing videos in some Sega emulator called Kega.<br />
<br />
It produces output in RGB555 and coding is LZ-like.<br />
<br />
Frame starts with two bytes which code real dimensions as multiple of 8 minus 1 block (i.e. <code>width = (src[0] + 1) * 8;</code>, same for height), the rest is coded data.<br />
<br />
Coded data consists of 16-bit LSB control words with possible extensions:<br />
<br />
# <code>111x xxyy yyyy yyyy</code> - copy <code>(y+3)</code> pixels from positive offset <code>offsets[x]</code> in the previous frame. If <code>offsets[x]</code> is not yet defined for this frame, read 24-bit LSB word after this code word. Naturally, this is possible only in interframes. The offset may wrap around the frame, depending on the current output position.<br />
# <code>110y yyyy yyyy yyyy</code> - read run length value minus four from next byte (i.e. <code>run = get_byte() + 4</code>) and copy pixels from negative offset <code>y+1</code> (e.g. offset 0 means RLE, offset 1 means repeating last two pixels, etc.)<br />
# <code>101y yyyy yyyy yyyy</code> - same as above but always copy 3 pixels from given offset<br />
# <code>100y yyyy yyyy yyyy</code> - same as above but always copy 2 pixels from given offset<br />
# <code>0ppp pppp pppp pppp</code> - <code>p</code> is pixel value, simply output it.<br />
<br />
Implementing decoder is left as an exercise for reader.<br />
<br />
[[Category:Video Codecs]]</div>
DrV
https://wiki.multimedia.cx/index.php?title=Kega_Video&diff=12232
Kega Video
2010-02-03T15:39:33Z
<p>DrV: </p>
<hr />
<div>* FourCC: KGV1<br />
* Sample: http://samples.mplayerhq.hu/V-codecs/kgv1.avi<br />
<br />
Codec used for capturing videos in some Sega emulator called Kega.<br />
<br />
It produces output in RGB565 and coding is LZ-like.<br />
<br />
Frame starts with two bytes which code real dimensions as multiple of 8 minus 1 block (i.e. <code>width = (src[0] + 1) * 8;</code>, same for height), the rest is coded data.<br />
<br />
Coded data consists of 16-bit LSB control words with possible extensions:<br />
<br />
# <code>111x xxyy yyyy yyyy</code> - copy <code>(y+3)</code> pixels from positive offset <code>offsets[x]</code> in the previous frame. If <code>offsets[x]</code> is not yet defined for this frame, read 24-bit LSB word after this code word. Naturally, this is possible only in interframes. The offset may wrap around the frame, depending on the current offset position.<br />
# <code>110y yyyy yyyy yyyy</code> - read run length value minus four from next byte (i.e. <code>run = get_byte() + 4</code>) and copy pixels from negative offset <code>y+1</code> (e.g. offset 0 means RLE, offset 1 means repeating last two pixels, etc.)<br />
# <code>101y yyyy yyyy yyyy</code> - same as above but always copy 3 pixels from given offset<br />
# <code>100y yyyy yyyy yyyy</code> - same as above but always copy 2 pixels from given offset<br />
# <code>0ppp pppp pppp pppp</code> - <code>p</code> is pixel value, simply output it.<br />
<br />
Implementing decoder is left as an exercise for reader.<br />
<br />
[[Category:Video Codecs]]</div>
DrV
https://wiki.multimedia.cx/index.php?title=Apple&diff=12065
Apple
2009-12-02T00:51:49Z
<p>DrV: add CAF to Apple formats</p>
<hr />
<div>Website: [http://www.apple.com http://www.apple.com]<br />
<br />
Apple is the company behind the [[Apple QuickTime Player|QuickTime]] multimedia player.<br />
<br />
Apple Formats:<br />
* [[QuickTime container]] (MOV)<br />
* [[CAF|Core Audio Format]] (CAF)<br />
* [[iTunes Library]]<br />
* [[FairPlay]]<br />
<br />
[[Category:Multimedia-related Companies]]</div>
DrV
https://wiki.multimedia.cx/index.php?title=Lagarith&diff=11912
Lagarith
2009-08-26T05:14:38Z
<p>DrV: spelling</p>
<hr />
<div>* FourCC: LAGS<br />
* Website: http://lags.leetcode.net/codec.html<br />
* Samples: http://samples.mplayerhq.hu/V-codecs/lagarith/<br />
<br />
Lagarith is a lossless video codec intended for video editing and archiving. It is also suitable for video capture on high-end systems. It is capable of handling RGB24, RGB32, RGBA, YUY2, and YV12 input video. To facilitate editing, Lagarith only supports keyframes, and optional null frames. Other features that make it suitable for video editing include a simple configuration interface, a good compression to speed ratio, full backwards compatibility with earlier versions of the codec, and a reduced resolution mode that is useful for 'bait-and-switch' editing.<br />
<br />
== Features ==<br />
<br />
=== Compression ===<br />
If the image is RGB(A), the red and blue channels are converted to their difference from the green channel (YUY2 and YV12 cannot be similarly converted). The image then has median prediction applied to it to make it more compressible (similar to Huffyuv's median prediction). Next, each channel is compressed independently. The channels will have a modified run-length coding scheme applied to runs of 0 if it reduces the length of the byte sequence. Runs may be triggered by 1, 2 or 3 sequential 0 values depending on which (if any) reduces the length the most. Run-length coding typically improves both compression and speed. If the modified run-length coding does not reduce the sequence length, the sequence is passed through unchanged. Next, the frequency for the different values in the byte sequence is tabulated and stored using Fibonacci coding. Finally, the byte sequence is compressed using a range coder and the frequency table.<br />
<br />
Additionally, in special cases where a frame is a solid color, the frame may be stored as just one uncompressed pixel.<br />
<br />
=== Multithreading ===<br />
The codec allows the user to specify if multiple threads should be used; this can be used on dual-core systems to significantly improve speed. The threading takes advantage of the fact that the channels are compressed independently & uses a separate thread for each channel. The output data is the same regardless of whether or not multithreading is enabled.<br />
<br />
=== 64-Bit Support ===<br />
A beta version of the codec is available for Windows 64. All features except reduced resolution mode are supported by the 64-bit version, and the 64-bit version is significantly faster than the 32-bit version on a 64-bit AMD processor. The output data is identical for the 32- and 64-bit versions.<br />
<br />
== Data Format ==<br />
Lagarith data is typically transported in [[AVI]] files. If the frame is 0 bytes long then the frame is a NULL frame. Presumably, the frame is unchanged from the previous frame.<br />
<br />
Byte 0 is the 'frame type' of an encoded chunk, and indicates the type of coding used to decode the remainder of the chunk. The supported types are:<br />
* 1: Uncompressed<br />
* 2: Unaligned RGB24<br />
* 3: Arithmetic coded YUY2<br />
* 4: Arithmetic coded RGB24<br />
* 5: Solid greyscale color frame<br />
* 6: Solid non-greyscale color frame<br />
* 7: Obsolete arithmetic coded RGB keyframe (Maintained for backwards compatibility)<br />
* 8: Arithmetic coded RGBA<br />
* 9: Solid RGBA color frame<br />
* 10: Arithmetic coded YV12<br />
* 11: Reduced resolution frame<br />
Any other value is considered to be an error.<br />
<br />
=== Arithmetic Coded Frames === <br />
This is the general layout for frame types 2, 3, 4, 7, 8, 10, and 11.<br />
Following the type byte, the next 8-12 bytes in the chunk represent 2 or 3 32bit integers that tell the offset to compresed channel data. The first compressed color channel data begins immediately after the offset data. For YUV and RGB formats, there are 2 offset values (2 integers, 8 bytes), with the offsets pointing to G/U and B/V; the R/Y channel starts at byte 9. For RGBA, 3 offsets are stored, pointing to G,B, and A respectively; with the R channel starting at byte 13. <br />
<br />
Each plane is packed with range coding with (fixed?) probabilities given in the beginning. Probabilities are coded with Fibonacci codes prefix for length and if code == 1 then the next Fibonacci code with zero probabilities count follow.<br />
<br />
Fibonacci codes are constructed from the Fibonacci series 1,2,3,5,8,13,21,34 where each bits signals whether to add next value or not (i.e. first bit - add 1, second bit - add 2, fourth bit - add 5, etc) and '11' signal end of code:<br />
<br />
1 - 11<br />
2 - 011<br />
3 - 0011<br />
4 - 1011<br />
5 - 00011<br />
6 - 10011<br />
7 - 01011<br />
8 - 000011<br />
...<br />
16 - 0010011<br />
32 - 00101011<br />
etc.<br />
<br />
<br />
After plane decoding zero [[RLE]] may be applied. This RLE scheme takes escape length as argument - number of zeroes before run starts (1-3 zeroes only). So is escape length = 2 and two zeroes in sequence are met, read run length and output so much zeroes.<br />
<br />
(TODO: describe compressed data layout; image prediction methods)<br />
<br />
=== Uncompressed ===<br />
Data encoding 1 is uncompressed data. The entire buffer after the type byte is copied into the output. This frame type is intended more for debugging than actual use.<br />
<br />
=== Obsolete RGB ===<br />
Decoding support only. The method for storing the compression header information and calculating the probability tables was changed in version 1.1.0.<br />
<br />
=== Unaligned RGB24 ===<br />
Used for RGB24 frames with a width that is not a multiple of 4. This is used to distinguish between frames coded with pre-1.2.0 versions that did not correctly remove padding.<br />
<br />
=== Solid Color Frames ===<br />
When the value of byte 0 is 5, 6, or 9, this indicates that the frame is a solid RGB color. The value 5 indicates a solid greyscale color, and the entire frame should be set to the value of byte 1. A value of 6 indicates a solid RGB color, with bytes 1,2, and 3 representing the R, G, and B values that all pixels in the frame should be set to. A value of 9 indicates an solid RGBA color, and is handled the same as a solid RGB frame, except that byte 4 holds the alpha value that each pixel should be set to.<br />
<br />
=== Reduced resolution frame ===<br />
Identical to a YV12 frame except that the resolution must be upscaled by 2.<br />
<br />
[[Category:Video Codecs]]<br />
[[Category:Lossless Video Codecs]]<br />
[[Category:Formats missing in FFmpeg]]</div>
DrV
https://wiki.multimedia.cx/index.php?title=VGM_Video&diff=11911
VGM Video
2009-08-25T21:05:56Z
<p>DrV: add sample and player</p>
<hr />
<div>* Company: [[XVD|XVD Corporation (DigitalStream-USA)]]<br />
* FourCC: VGMV<br />
* Sample: http://www.ila-ila.com/xvd-hist/sites/lab1454/eng/products/cruise48.vgm<br />
<br />
Java player: http://www.ila-ila.com/xvd-hist/sites/lab1454/eng/products/jpl_dm2.htm<br />
<br />
VGM Video (aka VT2k aka BigBits) is video codec for realtime encoding.<br />
<br />
[[Category:Video Codecs]] <br />
[[Category:Undiscovered Video Codecs]]</div>
DrV
https://wiki.multimedia.cx/index.php?title=Sony_Wave64&diff=11882
Sony Wave64
2009-08-15T19:18:03Z
<p>DrV: no longer missing in FFmpeg</p>
<hr />
<div>*Extension: w64<br />
*Company: Sony<br />
*Specification: http://www.vcs.de/fileadmin/user_upload/MBS/PDF/Whitepaper/Informations_about_Sony_Wave64.pdf<br />
<br />
<br />
[[libsndfile]] has LGPL muxer/demuxer.<br />
<br />
[[Category:Container Formats]]</div>
DrV
https://wiki.multimedia.cx/index.php?title=8088_Corruption_DAT&diff=11881
8088 Corruption DAT
2009-08-15T19:17:23Z
<p>DrV: no longer missing in FFmpeg</p>
<hr />
<div>* Extension: dat<br />
* Website: http://www.oldskool.org/pc/8088_Corruption<br />
<br />
8088 Corruption is the name of a somewhat academic project by one Jim Leonard, a.k.a. Trixter. The goal of the project was to play full screen, [[FMV|full motion video]] on an original IBM PC. The specs of the "original IBM PC" included:<br />
<br />
* Intel 8088 CPU running at 4.77 MHz<br />
* CGA video<br />
* original Sound Blaster audio<br />
<br />
The result of the project was an FMV data file (8088_COR.DAT) encoded in a particular format as well as a playback program that runs on the original IBM PC. However, by understanding the format of the data, it is possible to create decoders for other platforms.<br />
<br />
== DAT File Format ==<br />
The 8088_COR.DAT data file is a sequence of data frames without any header. All playback parameters are implicit to the format. Each data frame is 2735 bytes long. The first 2000 bytes of the frame represent the video data and the last 735 bytes are the audio data. The total size of the data file ought to be divisible by 2735.<br />
<br />
== Video Format ==<br />
The video format operates in a CGA text mode using the CGA's hardwired palette and 8x8 BIOS font. Frames are presented at a rate of 30 per second. The video coding necessarily acts as a [[Vector Quantization|vector quantizer]] with the 8x8 BIOS font acting as a vector codebook. Each frame is comprised of 40x25=1000 text cells, or vectors. Each vector is represented by a pair of bytes. The first byte is an codebook index, a.k.a. an index into the 8x8 font table. The second byte of the pair represents the attributes. The upper 4 bits (7-4) of the attribute represent the background color and the lower 4 bits (3-0) represent the foreground color.<br />
<br />
=== Data Resources ===<br />
<br />
* http://en.wikipedia.org/wiki/Color_Graphics_Adapter#The_CGA_color_palette<br />
* http://multimedia.cx/CGA_FONT.8X8<br />
<br />
== Audio Format ==<br />
The audio format used in 8088 Corruption is simply unsigned, 8-bit [[PCM]] played at 22050 Hz. Each frame contains 735 PCM bytes which happens to be the quotient of 22050/30.<br />
<br />
[[Category:Video Codecs]]</div>
DrV
https://wiki.multimedia.cx/index.php?title=Quotes&diff=11765
Quotes
2009-07-15T18:29:49Z
<p>DrV: /* #ffmpeg */</p>
<hr />
<div>Here are some memorable quotes gathered from various MPlayer and FFmpeg related discussions. Beware of what you say, because it will be recorded, taken out of context and ridiculed!<br />
<br />
==IRC Channels==<br />
<br />
===#mplayerdev===<br />
<br />
<pre><br />
<ods15> btw, gcc took 900mb of ram and then segfaulted for me when i tried to compile a 30mb C file :P<br />
<ods15> that took about 20 minutes until it evantually gave out of mem error<br />
<ods15> i should probably just write my own compiler than can do it in 0.05s and no ram...<br />
<ShadowJK> can tcc compile it :)<br />
<ods15> ShadowJK, heh i should've tried that<br />
* ods15 just makes a sample file and tries now<br />
<ods15> ahem, it did it in like 3 seconds and no ram :P<br />
</pre><br />
<br />
<pre><br />
<poirierg> great new ppl! I'm likely to get laid before linuxtag!<br />
<poirierg> woops<br />
<ods15> ...<br />
<poirierg> great new ppl! I'm likely to get laid out before linuxtag!<br />
<dalias> lol poirierg<br />
<poirierg> budget cuts and stuff like that....<br />
<dalias> poirierg, oh<br />
<dalias> i read that as 'get laid'<br />
<dalias> and i was like wtf tmi<br />
<ods15> ja<br />
<dalias> the word is 'laid off' btw, not 'laid out'<br />
<delewis> haha.<br />
<ods15> so, wait, great?<br />
<poirierg> okay, I'm getting laid off<br />
</pre><br />
<br />
<pre><br />
<ods15> british is american with a sloppy accent, and much stupider curse words<br />
</pre><br />
<br />
<pre><br />
<poirierg> cartman, you don't see smart girls if you only watch pr0n<br />
</pre><br />
<br />
<pre><br />
<superdump> Welcome to ye Olde #mplayerdev Tavern. If yaoi 'n' free cola is what ye be lookin' far, we's got 'em! Yarr...<br />
</pre><br />
<br />
<pre><br />
<dalias> because you can't use x264<br />
<superdump> why not?<br />
<dalias> because the decoder is slower than gabu trying to get a girlfriend<br />
</pre><br />
<br />
<pre><br />
<dalias> h264 is like matroska<br />
<dalias> yes mmatroska is better than avi but it sucks still<br />
<dalias> hes h264 compresses better than mpeg4 but it sucks still<br />
<dalias> and the question is: is 15% compression gain worth 500% performance drop?<br />
</pre><br />
<br />
<pre><br />
<poirierg> do you know the difference between God and dalias ? ;)<br />
<dalias> god only tells you what's bad to do when you inhale from a burning bush<br />
<dalias> dalias tells you what's bad all the time<br />
</pre><br />
<br />
<pre><br />
<reynaldo> i was once atacked by one of those beast<br />
<reynaldo> i was 4 years old iirc<br />
<reynaldo> those birds have almost 4 meters measured from the extremes of their wings<br />
<reynaldo> i have some stories you wouldnt believe :P<br />
<reynaldo> i dont remember meeting any chilean atacked by a condor besides me<br />
<reynaldo> :P<br />
<reynaldo> i was once biten by a black widow too :P extremely hard to find spider<br />
<reynaldo> nature has been trying to kill me since the day i born!<br />
<reynaldo> :P<br />
<iive> i though condors doesn't attack humans.<br />
<reynaldo> they dont<br />
<reynaldo> thats the weirdest part<br />
<reynaldo> :P<br />
<iive> well, then there is only one explanetion. you are not human.<br />
* iive runs<br />
<reynaldo> :P<br />
<reynaldo> who knows<br />
<reynaldo> maybe the karaoke filter is just the begining of my world domination plan<br />
</pre><br />
<br />
<pre><br />
<reynaldo> why dont you work with me improving the filter then ?<br />
<poirierg> reynaldo, because I don't want to steel the paternity of your little toy<br />
<reynaldo> thats not my boy<br />
<reynaldo> everyone an his girlfriend facing the same problem solved it the same wahy<br />
<reynaldo> we can make something neater<br />
<reynaldo> :)<br />
<poirierg> your are calling me to become the girlfriend of you audio filter?<br />
</pre><br />
<br />
<pre><br />
<ods15> i'm waiting for someone to send me brains tommorrow, not much to do until then<br />
</pre><br />
<br />
<pre><br />
<snacky> h264-in-mpeg is standardized since 2003. if hd-dvd does it differently it's because they're stupid ;)<br />
<iive> they do. thay are<br />
</pre><br />
<br />
<pre><br />
<KotH> Rathann: some nice quotes you have there :)<br />
<Rathann> I know! ^_^<br />
<Rathann> I've been collecting them for months<br />
<KotH> and some i dont even remember typing ^^'<br />
<Rathann> ^_^v<br />
<Rathann> hehe<br />
<Rathann> it's good to have logs<br />
</pre><br />
<br />
<pre><br />
<phcoder> compiling svn:<br />
<phcoder> allcodecs.c: In function 'avcodec_register_all':<br />
<phcoder> allcodecs.c:67: error: 'ENABLE_DCA_DECODER' undeclared (first use in this function)<br />
<phcoder> allcodecs.c:67: error: (Each undeclared identifier is reported only once<br />
<phcoder> allcodecs.c:67: error: for each function it appears in.)<br />
<phcoder> allcodecs.c:253: error: 'ENABLE_DCA_PARSER' undeclared (first use in this function)<br />
<phcoder> Sorry forgot to configure<br />
<KotH> dont forget make distclean<br />
<Rathann> don't forget to use your brain<br />
</pre><br />
<br />
<pre><br />
<DonDiego> geez<br />
<DonDiego> how many mistakes can you make in a single line of shell ..<br />
<KotH> one per character<br />
<DonDiego> i'm quite close ;)<br />
<DonDiego> sundays after parties are not the best days for programming ;)<br />
</pre><br />
<br />
<pre><br />
<cartman> <poirierg> cartman, you don't see smart girls if you only watch pr0n<br />
<dalias> :)<br />
<cartman> this is all I get for reporting quality pr0n bugs<br />
<dalias> cartman, it's what you get for making statements about girls being stupid<br />
<cartman> dalias: girls are stupid anyway<br />
</pre><br />
<br />
<pre><br />
<ShadowJK> "I have to agree with Rich's supposed opinion here. It is beyond mad."<br />
<ShadowJK> dalias, you've become quite efficient at flamewars, when you don't even need <br />
to participate anymore, people just assume what you were going to say :)<br />
</pre><br />
<br />
<pre><br />
<iive> btw does somebody know a way to get the xvid bitstream syntax number<br />
<iive> the number that xvid put to identify what bugs they had when encoding it.<br />
<Rathann> rtfs?<br />
<iive> i ask if somebody knows<br />
<iive> this is if nobody knows<br />
<iive> fucker<br />
<rxt> hehe, nothing changed on mplayer while I was away :)<br />
</pre><br />
<br />
<pre><br />
<snacky> ugh... you guys should see how polite superdump is being to lusers on #ffmpeg . it's really disgusting<br />
<superdump> :)<br />
<snacky> what is it with polite people?! don't you realize you are making the rest of us look bad?<br />
</pre><br />
<br />
<pre><br />
<KotH> i talked with an ubuntu guy here<br />
<KotH> and the biggest problem they have is that upstream is uncooperative<br />
<Rathann> is it?<br />
<KotH> from their perspective yes<br />
<Rathann> I haven't seen any patches from anyone @ubuntu<br />
<Rathann> nor bugreports, for that matter<br />
<KotH> well, replace upstream by downstream and you get the same in green<br />
</pre><br />
<br />
<pre><br />
<KotH> the biggest outcome of a 2h+ discussion was that both sites want to work with each other, but think it's impossible<br />
<Rathann> why do they think we're uncooperative?<br />
<Rathann> (obviously we aren't)<br />
<KotH> well... have a look at our history<br />
<ShadowJK> Obviously uncooperative. Refusing to integrate with gstreamer, copying libraries <br />
randomly into source tree, breaking compilation with gcc2.96 on purpose, stuff doesn't compile with PIC, etc etc ;)<br />
<KotH> yeah.. these points come into play too<br />
<KotH> but that's a longer story<br />
...<br />
<ShadowJK> You know, I don't think those MPlayer developers even go to church of Xiph every <br />
week to worship a speedy emergence of Tarkin and ogm as the world dominating system<br />
</pre><br />
<br />
<pre><br />
<KotH> anyone here who has an understanding of x11?<br />
<ods15> it shows graphics :P<br />
<KotH> yeah, right<br />
</pre><br />
<br />
<pre><br />
<uau> i was already a better coder than most existing developers when i got involved with mplayer<br />
</pre><br />
<br />
<pre><br />
<snacky> you guys and your secrets<br />
<KotH> there are more secrets around mplayer than you could possibly imagine<br />
<KotH> like, is there really a michael niedermayer? and if he exists, is he a single entity? is he alien?<br />
<snacky> I wonder if he/they/it has/have any spies in here.<br />
* KotH whistels<br />
* Rathann checks if his tinfoil hat is in place<br />
</pre><br />
<br />
<pre><br />
<xiphmont_> Vorbis still stands up nicely. Theora, OTOH, is a a bit embarrassing.<br />
* dalias tries to be polite about theora..<br />
<xiphmont_> rather, it's a bit embarrassing until you look at the code, then it's alot embarrassing.<br />
<xiphmont_> and that's 70% 'really fucking stupid encoder, really On2, be ashamed' and 40% 'format<br />
design flaws'. It's so bad it adds up to 110%.<br />
<xiphmont_> I plan to help Theora limp along not too embarrassingly until it can be replaced for<br />
real-- possibly 2-4 years.<br />
<xiphmont_> Theora is actually fixable tho. The amount of low-hanging fruit is staggering.<br />
<xiphmont_> I mean, an entropy backend that results in *more* bits being written than went in? It's<br />
just... wow.<br />
</pre><br />
<br />
<pre><br />
<|Bio|> but i need fix fo win<br />
<iive> how much do you need it?<br />
<|Bio|> very much.<br />
<iive> as i said, it is not really mplayer problem, mingw is the support library, it should take the ucs2 convert it to utf8 then do the opposite.<br />
<iive> and, very much is not enough.<br />
</pre><br />
<br />
<pre><br />
<@beastd> hallo iive<br />
<@iive> hi beastd<br />
<@beastd> and what's up with you these times, ivan?<br />
<@iive> nothing much, flaming diego mostly<br />
</pre><br />
<br />
<pre><br />
<KotH> video player development is anime driven anyways...<br />
</pre><br />
<br />
<pre><br />
<KotH> damn... now i know again, why i keep that much stone age scsi hardware around<br />
<KotH> if everything else fails...scsi will always boot<br />
<iive> :O<br />
<KotH> i dont think i had that much problems booting a pc since i got that toshiba laptop with non-standard floppy working<br />
</pre><br />
<br />
<Compn> changelog needs to be super updated for release<br />
<KotH> Compn: what are you waiting for? ;)<br />
* Compn hates release time<br />
* KotH hates time<br />
* timebomb hates you too<br />
<br />
===#mplayer===<br />
<br />
<pre><br />
* KotH wants a point and click solution... w/o the click<br />
</pre><br />
<br />
<pre><br />
<Micksa> I'm reading about motion compensation<br />
<Micksa> some of this is serious voodoo<br />
<Micksa> I love it :)<br />
</pre><br />
<br />
<pre><br />
<dtm> you're a free software pimp, Commn<br />
</pre><br />
<br />
<pre><br />
<Jan_> mplayer has a number of command line options that is large enough to overflow a 32-bit variable.<br />
</pre><br />
<br />
<pre><br />
<iive> Commn: yeh.. usa people usually have problem with foregin languages like british, australian or canadian. :)<br />
</pre><br />
<br />
<pre><br />
<CarlFK> how many gig is an hour of raw DV ?<br />
<DogBoy> like from a porno?<br />
<CarlFK> right<br />
<DogBoy> just how raw are we talking<br />
<CarlFK> right from the cam corder's firewire<br />
</pre><br />
<br />
<pre><br />
<dtm> Commn: i read all of your wiki page and you forgot the final entry for "and seek professional <br />
help immediately for the mental illness that either<br />
1) made you want to follow all these steps for lazy, codependent fools on irc or<br />
2) that you WILL HAVE after faithfully trying to implement all these steps for a week"<br />
<dtm> http://mfrost.typepad.com/photos/uncategorized/gaaallllgh.jpg that big dog is the cumulative laziness of a lot<br />
of irc users the medium sized cat is Commn and the one watching, frozen in horror, is me<br />
<dtm> now is that a normal response for a cat who has a self preservation instinct? i think not.<br />
<dtm> HE LIKES IT!<br />
<Commn> dtm : haha how long did it take to find that picture?<br />
<dtm> Commn: somebody gave it to me and i kept it in a firefox tab all week coz it's so awesome coz<br />
I KNEW IT WOULD HAVE A GREAT PURPOSE<br />
<dtm> Commn: since you asked for feedback, i'll say that you're extraordinarily diligent and conscientious, and<br />
the minority of that content is directly relevant to mplayer, and the majority is relevant to a "how to ask<br />
questions the smart way" type of document if not being totally redundant thereof<br />
<dtm> you are a gentleman and a scholar, and true patriot<br />
<sacarasc> dtm is cute when he is adoring someone<br />
<Commn> dtm : yes, its a modified 'how to ask questions' docu<br />
<Commn> its lame tho<br />
<Commn> i might delete it <br />
<Rathann> dtm is such a clear case of user-support-induced insanity that I wonder why I am still sane sometimes...<br />
</pre><br />
<br />
<pre><br />
<pianoboy3333> how long does mplayer take to compile?<br />
<dtm> how long til the Point of Know Return?<br />
<pianoboy3333> ...<br />
<dtm> i'm sorry, was that question not as dumb as yours? oh well i tried!<br />
<dtm> <3<br />
<iive> dtm: you are starting to sound like me.<br />
<dtm> Hmmmm.<br />
* dtm commits honorable ninja suicide<br />
</pre><br />
<br />
<pre><br />
<Erb> Does anyone know how to launch the GUI MPlayer in Linux via PHP (in Firefox)? I can run MPlayer scripts<br />
in the background fine. I only need to do this for local videos for an application I'm building.<br />
* dtm throws his brain into a blender in an attempt to comprehend Erb's question but fails sadly<br />
</pre><br />
<br />
<pre><br />
<dtm> tell me what i want to know, and nobody gets hurst.<br />
<dtm> hurt.<br />
<Rathann> o_O<br />
<dtm> i'm feeling like the giant cactus wants to be plastered in ascii screenshots<br />
<dtm> I MUST COMPLY<br />
<dtm> HELP ME DO THIS, Rathann<br />
</pre><br />
<br />
<pre><br />
<DazBrum> what is the channel for developers<br />
<-- DazBrum has quit ()<br />
<dtm> lols<br />
<dtm> i think i'll spare them from that<br />
</pre><br />
<br />
<pre><br />
<netstat> how come mplayer eating memory<br />
<netstat> it uses up to 90% cpu<br />
<dtm> must be a good movie<br />
</pre><br />
<br />
<pre><br />
<cappicard> o/~ Ich versteh euch nicht! o/~<br />
<dtm> i'm sorry cappicard i dont speak satanic<br />
<cappicard> LOL<br />
<cappicard> it's just German<br />
<dtm> yeah but not when they're singing it.<br />
<cappicard> heh :)<br />
<iive> cappicard: isn't it the same<br />
</pre><br />
<br />
<pre><br />
<gioele> How come that I get a 35 minutes MP3 from a 5 minutes FLV video with -dumpaudio?<br />
<Compn> aliens beaming audio into your mp3<br />
<spuck00> ^^<br />
<gioele> Compn: time to call SETI?<br />
<Compn> yep<br />
<Compn> if the aliens are peaceful, say hello<br />
<Compn> if they are aggressive, look out!<br />
</pre><br />
<br />
<pre><br />
* richard___ wonders why so many people join this channel for no apparent purpose<br />
<rsk> they share the love of mplayer ;-(<br />
<sacarasc> i have a purpose<br />
<richard___> I wasn't implying that there's anything wrong with it :)<br />
</pre><br />
<br />
<pre><br />
<rms> please tell me how to use dd_rescue<br />
<KotH> RTFM<br />
<rms> and what special will it do, except regular copy?<br />
<KotH> RTFM<br />
<rms> RTFM?<br />
<KotH> the manual says everything oyu need to know<br />
<KotH> read the fucking manual<br />
<rms> oh ok<br />
</pre><br />
<br />
<pre><br />
<iive> -dumpvideo<br />
<LinuxCart> umm, that's a good idea. i'll try that.<br />
<LinuxCart> thank you iive<br />
<KotH> LinuxCart: if in doubt, it's iive's fault ;)<br />
</pre><br />
<br />
<pre><br />
<LinuxCart> how could this be explained?<br />
<iive> it just another of dv misteries<br />
<iive> it's KotH fault.<br />
</pre><br />
<br />
<pre><br />
<LinuxMafia> how can i turn on language and sub<br />
<KotH> RTFM<br />
<LinuxMafia> KotH, using debian or freebsd?<br />
<KotH> LinuxCart: doesnt matter, the FM is OS idenpedent<br />
<LinuxCart> KotH: is RTFM some dialect to say it's iive fault :P<br />
</pre><br />
<br />
<pre><br />
<ChaosR> MPlayer 1.0rc1-4.1.2-DFSG-free <- my version<br />
<ChaosR> is it out of date<br />
<mjunx> of course<br />
<mjunx> if it wasn't built like within an hour ago at any given time, it's usually out of date<br />
</pre><br />
<br />
<pre><br />
<Fatsobob> trying to get mplayer to play win32 on ubuntu makes me want to shoot myself<br />
<Fatsobob> mostly because ubuntu is all "totem this" and "totem that"<br />
</pre><br />
<br />
<pre><br />
<Quintin> Is there any reason to use opengl vo device?<br />
<sacarasc> nope<br />
<Quintin> what's it there for?<br />
<sacarasc> because you might want to use it...<br />
...<br />
<reimar> sacarasc: is there any reason why I should think what you just said makes sense? ;-)<br />
<sacarasc> reason and what people want are not always the same<br />
</pre><br />
<br />
<pre><br />
<Commn> iive : dont call mplayer users dumb<br />
<Commn> not to their faces anyhow<br />
</pre><br />
<br />
<pre><br />
<Agiofws> has anyone tried cinerella ?<br />
<Agiofws> i think it great <br />
<Kunalagon> I tried , and I thin 80 % does not work<br />
<MisT_> never get compiled here<br />
<Kunalagon> it has more bugs than my shelter<br />
</pre><br />
<br />
<pre><br />
<voltagex> ArneB: at one stage I was able to do the maths to crack CSS on paper :P<br />
...<br />
<ArneB> voltagex: Obviously your mind and paper are illegal.<br />
<ArneB> Better hand them over to the MPAA.<br />
<voltagex> I think you could sneeze and accidentally crack CSS<br />
<voltagex> yep<br />
<voltagex> no more pencils<br />
</pre><br />
<br />
<pre><br />
<danny500> how do I convert a ogm file into an mpeg file using mencoder?<br />
<danny500> anyone><br />
<danny500> hello?<br />
<danny500> ?<br />
<danny500> help<br />
<BenrA> mencoder -of mpeg -oac lavc -ovc lavc -lavcopts vcodec=mpeg2video -o foo.mpg foo.ogm<br />
<danny500> ?<br />
<BenrA> If you want quality and/or DVD compatibility or anything, consult the docs. ;)<br />
<danny500> ok that was confusing<br />
<danny500> file equals = file:///home/danny500/Trigun/Trigun%20-%201%20-%20The%20%24%2460%20Billion%20Man <br />
<danny500> now, rewrite that code so that It'll work<br />
<danny500> well then?<br />
<BenrA> What is your problem?<br />
<housetier> I'd try replacing "foo.ogm" with /home/danny500/Trigun/Trigun%20-%201%20-%20The%20%24%2460%20Billion%20Man <br />
(if that is the real file name), and see how far it goes<br />
<danny500> fine then, don't help me, I'll go to a room where I'll actually get help. Fucking assholes<br />
</pre><br />
<br />
<pre><br />
<crackedboy> hi, can I ask something about kmplayer?<br />
<md`> no<br />
<crackedboy> ok, sorry<br />
<md`> you're forgiven<br />
</pre><br />
<br />
<pre><br />
<CHodapp> I have a program that's basically just generating RGB data for a framebuffer. <br />
<CHodapp> I'm having major issues figuring out how to get this data to an encoded video.<br />
<CHodapp> ffmpeg seems to only want some particular kind of YUV<br />
<CHodapp> can I make mencoder handle raw RGB or raw YUV or anything like that?<br />
<Commn> its easier to get it working with mplayer, to see what options you need<br />
<Commn> mplayer file -demuxer rawvideo -vc rawbgr16<br />
<Commn> etc<br />
<Commn> then you can do mencoder with those opts<br />
<Commn> or maybe even mplayer -vo yuv4mpeg , which ffmpeg probably accepts <br />
<Commn> maybe even use a named pipe... mkfifo stream.yuv && ffmpeg -i stream.yuv -options ...<br />
<CHodapp> ugh, documentation is so sparse on stuff like this<br />
<CHodapp> ugh, why is this such a pain in the ass, with everything<br />
<CHodapp> hrm, maybe rawrgb24 is what I need<br />
<Commn> what part is sparse?<br />
<Commn> if you tell us, we can improve mplayer docs<br />
<CHodapp> well, not so much in mplayer as everything else I've tried... I was mostly searching on <br />
the web to get some clue of how I'd convert what kind of raw input to encoded output<br />
<Commn> mplayer -vc help|grep raw<br />
<Commn> will show what raw codecs mplayer has<br />
<CHodapp> Yeah, I just now found that<br />
<CHodapp> blah . . . Cannot find codec matching selected -vo and .video format 0x30323449.<br />
<Commn> CHodapp : try -vc +rawrgb32 or whatnot<br />
<Commn> just add + in front of it <br />
<CHodapp> then it says the selected video_out device is incompatible with this codec<br />
<CHodapp> tried sdl and x11<br />
<Commn> if you can make a small sample of your file<br />
<Commn> dd if=input of=output count=3 bs=1024k<br />
<Commn> i can try to get it working in mplayer<br />
<CHodapp> you might as well just take 640*480*3*100 bytes of data from /dev/urandom and try <br />
that... it will be functionally equivalent<br />
<CHodapp> I'm using this right now: mplayer -rawvideo w=640:h=480 -demuxer rawvideo -vc +rawrgb24 -vo sdl temp.rgb<br />
<Commn> whats random got to do with it ?<br />
<CHodapp> it's just a bunch of bytes, completely unorganized, and mplayer needs to know the resolution<br />
<CHodapp> it doesn't care about the contents<br />
<CHodapp> something else is wrong, otherwise I'd be getting something on the screen<br />
<Commn> if you give me some file i can help<br />
<Commn> otherwise its hard to debug from here ;p<br />
<CHodapp> www.uc.edu/~hodappcm/temp2.rgb<br />
<CHodapp> not the most coherent video, but you won't find that out unless you get something on the screen<br />
<CHodapp> it's 320x240, 10 frames worth<br />
<Commn> what program generates it ?<br />
<CHodapp> just something I'm writing. it's all procedural.<br />
<Commn> i'm trying to remember why it defaults to i420<br />
<CHodapp> i420? like yuv?<br />
<Commn> ya<br />
<CHodapp> definitely shouldn't be yuv...<br />
<Commn> i know, mplayer -rawvideo is defaulting to that<br />
<CHodapp> hmm<br />
<CHodapp> still no output?<br />
<Commn> CHodapp : something like this didnt work ? ffmpeg -f rawvideo -pix_fmt rgb24<br />
<CHodapp> couldn't find codec parameters...<br />
<CHodapp> wait, I forgot the size<br />
<Commn> haha more static<br />
<CHodapp> what commandline did you use?<br />
<Commn> ffplay -f rawvideo -pix_fmt rgb24 -s 320x240 temp2.rgb<br />
<CHodapp> wonder if my endianness is wrong...<br />
<Commn> is it black frames ?<br />
<Commn> ffplay -f rawvideo -pix_fmt bgr32 -s 320x240 temp2.rgb<br />
<Commn> CHodapp : http://64.233.167.104/search?q=cache:0o70XuNe5QkJ:www.kingcot.eclipse.co.uk/unichrome/tvoutTest.html+mplayer+rawvideo+rgb&hl=en&ct=clnk&cd=50&gl=us&client=opera<br />
<Commn> CHodapp : there is an app on that page which generates rgb data<br />
<CHodapp> yeah...<br />
<CHodapp> by the way, I just sent you data from /dev/urandom<br />
</pre><br />
<br />
<pre><br />
<Jan-> Just so you know, you do realise, the reason we're after using mplayer is because it's f@&^@ng brilliant.<br />
<Jan-> It plays, as they say, *.<br />
<Jan-> It'd play a bucket of cornflour if you painted the word "MOVIE" on it.<br />
</pre><br />
<br />
<pre><br />
<nyersa> do I need to also specify the aspect ratio?<br />
<Rathann> that's too vague a question<br />
<Rathann> so my answer is: maybe<br />
</pre><br />
<br />
<pre><br />
<judaz> i hear music, but not de voices<br />
<judaz> the *<br />
<Rathann> well, it's good that you don't hear voices<br />
<Rathann> hearing voices is usually a sign of insanity<br />
</pre><br />
<br />
<pre><br />
<sacarasc> i want mplayer 1.0 final so i can laugh and hell freezes over and people stop being idiots<br />
</pre><br />
<br />
<pre><br />
<ma3x> what do you need mplayer for?<br />
<ma3x> full of bugs<br />
<ma3x> get windows media centre<br />
<rsk> yea<br />
<rsk> get a brain<br />
</pre><br />
<br />
<pre><br />
<individ> using mplayer revision 26668 fixed my obscure problem, thanks for the tough love :]<br />
</pre><br />
<br />
<pre><br />
<^^MAg^^> Arwen: I'm not blind, it's using ffh264<br />
<Arwen> ^^MAg^^, and where do you read "x264" in that?<br />
</pre><br />
<br />
<pre><br />
<ProN00b> Kovensky, i like it better without ass<br />
</pre><br />
<br />
<pre><br />
<Kovensky> ProN00b: you're weird<br />
<anon32> Kovensky, why? Because he likes his text without ZOMGPONIES?<br />
<ProN00b> no, but there are no ponies anyways, just smaller text<br />
</pre><br />
<br />
<pre><br />
<Compn> the topic is getting a bit large <br />
<Zider> compress it with H.264<br />
</pre><br />
<br />
<pre><br />
<roo_> Cheaterman: actually I believe the real help comes from above, so I sat down and prayed for you<br />
<roo_> seems like it worked like a charm ...... again!<br />
</pre><br />
<br />
<pre><br />
<roo_> papo: and I honestly dunno whats worse, the child abuse thingie, or the windows movie maker :p<br />
</pre><br />
<br />
=== #ffmpeg ===<br />
<pre><br />
<tomyu> can i use ffmpeg to split a movie or i will loose quaility<br />
<merbzt> tomyu: use -vcodec copy<br />
<tomyu> iam on ubuntu<br />
</pre><br />
<br />
<pre><br />
<grepper> you don't have -pix_fmt ?<br />
<aum> '-pix_fmt list' worked - it just isn't advertised on the manpage<br />
* aum pays due respect, and acknowledges that the *real* manpages are those files ending in .c, .h, .cxx etc<br />
<grepper> it sure IS in my manpage<br />
<grepper> maybe debian makes it from ffmpeg -h<br />
</pre><br />
<br />
<pre><br />
<jaredthane> Now I'll just shoot myself in the head for being so stupid!<br />
<andoma> do you want help with that as well? :-)<br />
</pre><br />
<br />
<pre><br />
<benoit-> zinfandel: read the code<br />
<benoit-> and come back when you know what you're talking about<br />
<zinfandel> thats the 15 minutes i dont have now, but ok you win<br />
</pre><br />
<br />
<pre><br />
<kshishkov|work> well, strictness of laws here is compensated by inability to enforce them often<br />
</pre><br />
<br />
<pre><br />
<encompass> so what does FFMpeg actually stand for?<br />
<Kuukunen> fast forward moving picture experts group<br />
</pre><br />
<br />
<pre><br />
<peleg> oh, awful!!!<br />
<peleg> these terrible sounds ripped my ears...<br />
<iive> aac have been committed to ffmpeg?<br />
</pre><br />
<br />
<pre><br />
<bigbear2> ok r 15190 is fine too<br />
<zap0> is that 'stable' version now?<br />
<Rathann> zap0: define 'stable' ;)<br />
<zap0> somewhere you keep horses<br />
<Rathann> oh, the horses have run already<br />
<zap0> wild horses... damn you horses!<br />
</pre><br />
<br />
<pre><br />
<Hfuy> TroyMcClure?<br />
<TroyMcClure> yep<br />
<Hfuy> the TroyMcClure we remember from such video-conversion instructional films as "MPEG-4 - Suitable for Porn?"<br />
</pre><br />
<br />
<pre><br />
<Hfuy> In order to make FCP* display this stuff without insisting on a render, all the stars will have to be in alignment, if you see what I mean.<br />
<br />
* Final Cut Pro<br />
</pre><br />
<br />
<pre><br />
<Dark_Shikari> Most NLEs are utterly trashy pieces of software<br />
<Dark_Shikari> with video support that makes most late-90s apps look good<br />
<Hfuy> Couldn't agree more.<br />
<Dark_Shikari> despite being supposedly "professional" video editors they don't actually support any "professional" formats<br />
<Hfuy> However, they are utterly trashy pieces of software I am bound to support.<br />
</pre><br />
<br />
<pre><br />
<Hfuy> Uh-oh. Looks like it needs to me MXF-wrapped.<br />
<Dark_Shikari> does FCP take DirectShow input?<br />
<Dark_Shikari> I know Premiere does.<br />
<Hfuy> Final Cut is available only on the Mac.<br />
<Hfuy> This makes my life... interesting.<br />
<Hfuy> Premiere also knows how to import EDLs with timecode and so forth, which FCP doesn't; absolutely the only way to get anything into FCP is using Quicktime embeds.<br />
[...]<br />
<Dark_Shikari> you're intentionally torturing yourself ;)<br />
</pre><br />
<br />
<pre><br />
<Hfuy> You are aware I assume of what an egregious train wreck of a format MXF is.<br />
<Dark_Shikari> so there's no mxf muxer I'd assume<br />
<Dark_Shikari> I don't pay attention to awful container formats :><br />
<Dark_Shikari> that's the great part of working on a pure encoder app, you can let the ffmpeg devs torture themselves over awfully designed container formats instead ;)<br />
<Hfuy> MXF is extremely awful. One cannot help but raise an eyebrow when a container format touts itself as solving all interchange problems, overnight and for ever.<br />
<Dark_Shikari> lol<br />
<Hfuy> What it actually does is take the interchange problem, wrap it up in a pretty box with a ribbon on it marked "MXF", and pretend that helps.<br />
<Dark_Shikari> I think there's some inverse relationship between marketing claims and actual substance<br />
<Hfuy> If it's any consolation, I'm having enormous grief trying to create timecoded Quicktimes on a Windows PC.<br />
</pre><br />
<br />
<pre><br />
<Hfuy> ...yes, AVCI is MXF-wrapped. Curses.<br />
<Hfuy> Oh, good grief, it's split-file A/V.<br />
<Dark_Shikari> oh god<br />
<Dark_Shikari> its not even interleaved?!<br />
<Hfuy> With external XML metadata.<br />
<Hfuy> I believe MXF can be. But in the case of AVC-Intra, it's not.<br />
<Dark_Shikari> :><br />
* Hfuy allows his head to fall forward onto the desk<br />
<Hfuy> What in God's name is --wrong-- with these people?!<br />
<Dark_Shikari> lol<br />
<Hfuy> Allow me to quote from the AVC-Intra whitepaper.<br />
<Dark_Shikari> ugh, whitepapers<br />
<Hfuy> Basic concept of AVC-Intra <br />
<Hfuy> Guarantee interoperability Adoption of International video coding standard and MXF fle format<br />
<Hfuy> Words fail me.<br />
</pre><br />
<br />
<pre><br />
<Hfuy> So, how much money do I have to give you to have you implement MXF wrapping to SMPTE 381M?<br />
* Hfuy ducks<br />
<Dark_Shikari> I'm not going to touch it with a 10 foot pole :><br />
<Hfuy> So let me get this straight, for a moment. We can have ffmpeg create the highly advanced compressed video data, but we can't make FCP read it, because it isn't wearing a nice enough suit?<br />
<Dark_Shikari> lol<br />
<Hfuy> Don't mock the afflicted.<br />
<Hfuy> Doesn't this imply that FCP's importer is rather lacking in the generality department?<br />
<Dark_Shikari> what, you're surprised?<br />
</pre><br />
<br />
<pre><br />
<pasteeater> I get error "Unknown option 'gop'". [...]<br />
<derwin> you compiled --without-republicans<br />
</pre><br />
<br />
=== #ffmpeg-devel ===<br />
<br />
<pre><br />
<superdump> well, i've been hailed as a guru and i'm owed a pint (see #ffmpeg)<br />
<superdump> hehe<br />
<andoma> i want a pint too!<br />
<superdump> it's loud and annoying<br />
<kshishkov|work> so what, I've got one marriage proposal (from female) there once<br />
<superdump> o rly?<br />
<andoma> that ranks higher indeed ..<br />
<andoma> kshishkov > superdump<br />
</pre><br />
<br />
<pre><br />
<caldo_de_cana> ok, I need a little CS help... my callback function for vfwcap<br />
locks a mutex to add packets to a list. lavf's read_packet function also locks<br />
the same mutex to read packets from the list. If there are no packets on the<br />
list and read_packet has to wait, I could make it wait for a semaphore that is<br />
set from inside the callback, right?<br />
<iive> lavf (ffmpeg in general) using mutex is news for me.<br />
<caldo_de_cana> iive: windows stuff... I had to make up for vfw's misdesign<br />
<caldo_de_cana> actually it's lavd... most files there have huge hacks<br />
* iive runs and hides<br />
* mru makes up for windows misdesign by not using it<br />
</pre><br />
<br />
<pre><br />
* KotH threatens to not bring any chocolate to next LT<br />
<mru> noooo<br />
<mru> KotH: what are your demands?<br />
<KotH> uhm... that you do something... or dont do it... dont know<br />
<mru> well, I'm doing something, and I'm also not doing some things<br />
</pre><br />
<br />
<pre><br />
<KotH> chocolate is serious business!<br />
</pre><br />
<br />
<pre><br />
< patrakov> yes, I have already solved one organizational issue (invalid XML from clueless partners)<br />
<@mru> all xml is invalid<br />
<@mru> or should be<br />
</pre><br />
<br />
<pre><br />
<mru> when it locks up, it only responds to external reset<br />
...<br />
<mru> it's almost impossible to intentionally trigger the bug<br />
<mru> so far, the most reliable way has been to run ffmpeg for a few minutes<br />
<mru> FFmpeg, killer of compilers and CPUs alike<br />
</pre><br />
<br />
<pre><br />
<Dark_Shikari> (Reminds me, a bit ago when I sent in a patch to implement<br />
a feature for H.264 decoding, Michael messaged me giving me a really clever<br />
way to do it, saying we should commit the better way in a few months after<br />
waiting for all competitors to do it the inefficient way.)<br />
<Rathann> did he, really?<br />
<Dark_Shikari> yes<br />
<Dark_Shikari> He's just that awesome<br />
</pre><br />
<br />
<pre><br />
<mru> the only "valid" reason I can think of for using theora is because it works in ogg<br />
<mru> and the only "valid" reason I can think of for using ogg is that theora works there<br />
</pre><br />
<br />
<pre><br />
And lo, a lonely patch sat... awaiting feedback.<br />
<br />
It yearned for an "OK";<br />
<br />
It hoped for a "looks good, but change the warning to...".<br />
<br />
And when it was alone, when no one else was around, and when it felt<br />
truly safe to dream; It dreamed of a "my god, this is the best patch<br />
ever -- far better than removing GPL source code from libswcale, and<br />
likely to win the Nobel prize for programming"<br />
<br />
But frankly, it'd settle for "rejected" just so I can stop monitoring it :)<br />
<br />
- Art<br />
</pre><br />
<br />
<pre><br />
I just assume that for people who subscribe to this list,<br />
FFmpeg is the most important thing in their lives :)<br />
-- Mike<br />
</pre><br />
<br />
<pre><br />
* bcoudurier has joined #ffmpeg-devel<br />
<bcoudurier> hi guys<br />
<iive> yo bcoudurier<br />
<bcoudurier> hey<br />
<iive> what's up on ffmpeg front?<br />
<mru> fflames of course<br />
</pre><br />
<br />
<pre><br />
<Compn> google "theora porn" returns nothing worthy<br />
</pre><br />
<br />
==Mailing lists==<br />
<br />
===[http://lists.mplayerhq.hu/mailman/listinfo/mencoder-users mencoder-users]===<br />
<br />
<pre><br />
> But trust me: Both Core Duo and Core 2 Duo support 64bit extensions,<br />
> almost identically.<br />
<br />
Don't trust me! I'm wrong! I'm ashamed! There do exist Core Duos<br />
without AMD64/EM64T/Intel 64 extensions.<br />
-- Moritz Barsnick, correcting himself<br />
</pre><br />
<br />
===[http://lists.mplayerhq.hu/mailman/listinfo/mplayer-cvslog mplayer-cvslog]===<br />
<br />
<pre><br />
> btw, anyone has a copy of the ISO-english spec? ;)<br />
<br />
Ok. :)<br />
<br />
1. There isn't a spec, since the language hasn't been standardized. All<br />
we have are numerous competing drafts written by independent,<br />
non-authoritative organizations.<br />
<br />
2. A large amount of existing English code, such as Shakespeare, is<br />
unparseable by modern English speakers.<br />
<br />
3. If an element of the language has been frequently misused over a long<br />
enough period of time, such misuse often becomes acceptable.<br />
<br />
4. An English speaker can be considered reasonably feature-complete even<br />
if such speaker only recognizes a small subset of the language.<br />
<br />
5. Certain keywords tend to cause internal compiler errors. Such<br />
keywords are known as "profanity", and existing English speakers weakly<br />
attempt to prevent recently-written speakers from being aware of them.<br />
<br />
6. English is a highly context dependent. Many keywords, when used in<br />
their own particular context, take on an entirely illogical meaning.<br />
These "idioms" cause compilation errors, especially when an old speaker<br />
is attempting to communicate with a new one.<br />
<br />
7. ....<br />
<br />
I could go on, but that's enough fun for now. :)<br />
-- Michael Niedermayer and Corey Hickey in mplayer-cvslog at mplayerhq.hu<br />
</pre><br />
<br />
<pre><br />
On Sat, Dec 01, 2007 at 02:35:25PM +0100, reimar wrote:<br />
> Author: reimar<br />
> Date: Sat Dec 1 14:35:25 2007<br />
> New Revision: 25225<br />
> <br />
> Log:<br />
> Fox typos<br />
<br />
well ...<br />
<br />
[...]<br />
-- <br />
Michael <br />
</pre><br />
<br />
<pre><br />
Author: michael<br />
Date: Thu Sep 4 21:49:13 2008<br />
New Revision: 27519<br />
<br />
Log:<br />
Fix 4 of the unscaled rgb15/16 converters, each of these contained<br />
2-3 bugs each of which made it fail completely, this code clearly<br />
has never been tested and been written by somone who knows the<br />
difference between a potato and a computer is that the first is round.<br />
</pre><br />
<br />
===[http://lists.mplayerhq.hu/mailman/listinfo/mplayer-dev-eng mplayer-dev-eng]===<br />
<br />
<pre><br />
Without a frontend, mplayer is useless.<br />
-- Jean-Philippe Guillemin in mplayer-dev-eng at mplayerhq.hu<br />
</pre><br />
<br />
<pre><br />
[about alsa resampler]<br />
Now why on earth would anyone want to use this crap?? It's only<br />
configurable between two extremes of sucking: very bad quality, or<br />
very bad performance.<br />
-- Rich Felker in mplayer-dev-eng at mplayerhq.hu<br />
</pre><br />
<br />
<pre><br />
Reinventing the wheel certainly is annoying, but as long as all other<br />
wheels are square...<br />
<br />
Reimar Döffinger<br />
</pre><br />
<br />
<pre><br />
On Thu, Aug 24, 2006 at 01:10:18PM -0400, Dave Dodge wrote:<br />
> IA64 compilation is an ongoing research project.<br />
<br />
Which is what leaves me always wondering where on earth (or actually far<br />
away from earth) Intel engineers left their brains when designing<br />
IA64...<br />
Technology for the next century. As in we will get it to work properly<br />
somewhen in the next century...<br />
<br />
Reimar Döffinger<br />
</pre><br />
<br />
<pre><br />
> > My patches include:<br />
> <br />
> Are these patches visible somewhere? Some comments below based on what<br />
> your descriptions tell.<br />
<br />
No, I wanted to hear your comments before I post them.<br />
-- Dan Oscarsson and Uoti Urpala on Mon, Apr 06, 2009<br />
</pre><br />
<br />
===[http://lists.mplayerhq.hu/mailman/listinfo/mplayer-users mplayer-users]===<br />
<br />
<pre><br />
> > yes, video decoding is not perfect either so even if u decode the bitstream u <br />
> > loose quality (idct inaccuracies and such) so u should really use a hexeditor <br />
> > instead of mplayer to view ur movies<br />
><br />
> Perhaps we could rewrite xmatrix so it takes its input from AVI<br />
> files...<br />
<br />
"Do you always look at it encoded?"<br />
<br />
"Well ya have to. The video codecs work FOR the construct program. But<br />
there's way too much information to decode this DIVX. You get used to<br />
it -- I don't even see the code. All I see is blonde, brunette,<br />
redhead..."<br />
-- Michael Niedermayer, Moritz Bunkus and D Richard Felker III in mplayer-users at mplayerhq.hu<br />
</pre><br />
<br />
<pre><br />
>>> Is there any possibility to convert a Ream Media video stream to<br />
>>> ogg/theora video?<br />
>><br />
>> no, ogg is banned for good from the list of possible outputs for<br />
>> manifest insanity<br />
><br />
> Thank you for your answer, but can you be more specific?<br />
<br />
ogg is by far the most insane mux format ever conceived,<br />
thus no conscious coder wants to permit to give birth to an abomination<br />
like that<br />
-- Marek Mahut and Nico Sabbi in mplayer users at mplayerhq.hu<br />
</pre><br />
<br />
<pre><br />
> > > 1. ok, true, I wanted to say mad TAG right ? How can I get this<br />
> > > to MP3 tag ?<br />
> ><br />
> > There is no such thing as a MAD tag. MAD only plays MP1/MP2/MP3. <br />
> > Your file has to have one of those as the audio track for MAD to be<br />
> > able to play it at all. You also didn't read the rest of my post.<br />
><br />
> MAD audio codec then ?<br />
<br />
...<br />
<br />
I'd love to help, but I have to go bang my head against that wall over<br />
there...<br />
-- wim delvaux and RC in mplayer-users at mplayerhq.hu<br />
</pre><br />
<br />
<pre><br />
Tobias Damisch wrote:<br />
> Guillaume Poirier wrote:<br />
> > MPlayer still lacks "fairies" support to invent the pixels in between,<br />
> > needed to get a truly HD picture.<br />
><br />
> Just get latest SVN and recompile with:<br />
><br />
> --enable-fairies<br />
><br />
> Then try adding -vf fscale=1600:1200 (or any other resolution you<br />
> might desire) to your command line.<br />
<br />
Gentoo's latest mplayer ebuild is apparently an SVN snapshot from<br />
08/10/2006 and doesn't seem to include a fairies USE flag for<br />
compilation. Was fairies support added after that date, or is the<br />
ebuild missing a USE flag?<br />
<br />
Grant<br />
</pre><br />
<br />
===[http://lists.mplayerhq.hu/mailman/listinfo/ffmpeg-cvslog ffmpeg-cvslog]===<br />
<br />
<pre><br />
>> I'm sure Michael knows how to capitalize and punctuate at<br />
>> least a little bit.<br />
> thats defamation, ive never capitalized and punktuated correctly<br />
> besides that i dont like pure capitalism ;)<br />
I NEVER ASKED YOU TO WRITE LIKE THIS.<br />
-- Måns Rullgård and Michael Niedermayer in ffmpeg-cvslog at mplayerhq.hu<br />
</pre><br />
<br />
<pre><br />
Michael Niedermayer CVS <michael@mplayerhq.hu><br />
<br />
Modified Files:<br />
ffmpeg-doc.texi<br />
Log Message:<br />
split string to avoid buffer overflow in native english speaking persons (fix suggested by The Wanderer)<br />
</pre><br />
<br />
<pre><br />
On Mon, Dec 26, 2005 at 09:57:36PM +0100, Alexander Strasser wrote:<br />
> Oh, I just saw it was in the original mail. I must have<br />
> accidently deleted it while writing the answer. Sorry for<br />
> the trouble.<br />
<br />
no problem at all, better to ask then to miss some typos by the CIA/KGB guys<br />
who edit all my outgoing and incoming mails<br />
<br />
Michael<br />
</pre><br />
<br />
<pre><br />
>>>Log:<br />
>>>use pr -n -t instead of non-standard cat -n<br />
>>><br />
>>Is this purely to be standard compliant or did you manage to find a <br />
>>system that doesn't accept cat -n?<br />
><br />
>Rich has one, apparently.<br />
<br />
That's funny...<br />
I admire FFmpeg's standard compliance. It gets to the point where you<br />
create systems to justify such changes.<br />
-- Måns Rullgård and Ramiro Polla<br />
</pre><br />
<br />
<pre><br />
Besides, people with non-compliant systems need to be taught a lesson.<br />
-- Måns Rullgård<br />
</pre><br />
<br />
===[http://lists.mplayerhq.hu/mailman/listinfo/ffmpeg-devel ffmpeg-devel]===<br />
<br />
<pre><br />
On Mon, Jan 02, 2006 at 05:14:20AM +0100, Michael Niedermayer wrote:<br />
> Hi<br />
><br />
> On Fri, Dec 16, 2005 at 03:45:37PM -1000, Steve Lhomme wrote:<br />
> > This code moves the AR detection in the codec part so that it works when<br />
> > the DV stream is in AVI (or else) too. Plus the interlacing detection<br />
> > now works.<br />
><br />
> roman, please choose<br />
> [ ] patch ok<br />
> [ ] patch not ok<br />
> [ ] dv maintainer lazy<br />
> [ ] dv maintainer busy<br />
> [ ] dv maintainer dead<br />
<br />
Michael you've forgotten a very important option for somebody who decided<br />
to celebrate New Year in Russia:<br />
<br />
[X] dv maintainer drunk<br />
</pre><br />
<br />
<pre><br />
> All right, new screening process for prospective FFmpeg contributors:<br />
> "Are you now, or have you ever been, a Microsoft Visual C++ user?"<br />
> There's going to be scandal when the oversight committee investigates my<br />
> employment history.<br />
If you used msvc on your day job it doesn't count, as long as you really hated it.<br />
-- Mike Melanson and Måns Rullgård in ffmpeg-devel at mplayerhq.hu<br />
</pre><br />
<br />
<pre><br />
>>>I never understood the point of those supposedly "cool" aliases some<br />
>>>people use.<br />
>><br />
>> What about the supposedly "cool" circle you put over the 'a's in <br />
>> your name? :)<br />
> <br />
> <br />
> It's Swedish and turns the 'a' into something that sounds like an 'o' as<br />
> in 'hot'...<br />
<br />
Ah, so that's the difference. It's not "cool", it's 'hot'.<br />
-- Måns Rullgård, Mike Melanson, and Diego Biurrun in ffmpeg-devel at mplayerhq.hu<br />
</pre><br />
<br />
<pre><br />
> patching file configure<br />
> Hunk #1 FAILED at 914.<br />
> 1 out of 1 hunk FAILED -- saving rejects to file configure.rej<br />
Ah, yes, the swift evolution of ffmpeg made the patch obsolete in 24h.<br />
-- MÃ¥ns RullgÃ¥rd and VÃctor Paesa in ffmpeg-devel at mplayerhq.hu<br />
</pre><br />
<br />
<pre><br />
[about the lack of "chained ogg" support]<br />
I'm aware of this problem, and I've been trying to think of a<br />
solution. The more I think about it, the more it appears as an<br />
abomination. Just like everything Ogg related. No surprises there.<br />
-- Måns Rullgård in ffmpeg-devel at mplayerhq.hu<br />
</pre><br />
<br />
<pre><br />
not everything from OO is necessarily bad, like not everything from M$<br />
is necessarily bad, if later where the case M$ would gone bankrupt long<br />
ago ...<br />
but thats geting deeply off topic, lets rather concentrate on flames and<br />
insults ...<br />
-- Michael Niedermayer in ffmpeg-devel at mplayerhq.hu<br />
</pre><br />
<br />
<pre><br />
[Marco Gerards submits a THP demuxer]<br />
Coooool. I have hundreds of THP files. I will find some that have sound<br />
and get them posted soon. In the meantime, Niedermayer will be along<br />
shortly to tear apart your patch. Good luck! :)<br />
-- Mike Melanson in ffmpeg-devel at mplayerhq.hu<br />
</pre><br />
<br />
<pre><br />
[about SwScaler rewrite]<br />
> > And then we can call an architecture dependent init function that can<br />
> > overide the C behavior much like is done for the dsputils.<br />
> I was thinking about that too<br />
thinking is good patch is better ...<br />
-- Marc Hoffman, Luca Barbato and Michael Niedermayer in ffmpeg-devel at mplayerhq.hu<br />
</pre><br />
<br />
<pre><br />
On Sun, Jan 15, 2006 at 06:27:55PM +0100, Reimar Döffinger wrote:<br />
><br />
> Oh, and the image of my RE drawing is up as well :-) :<br />
> http://www.stud.uni-karlsruhe.de/~uvhe/LZODraw_bw.png<br />
<br />
Thank goodness your coding skills are better than your handwriting ;)<br />
<br />
Diego<br />
</pre><br />
<br />
<pre><br />
On Thu, Sep 22, 2005 at 10:51:05AM +0200, oandrieu@gmail.com wrote:<br />
> Michael Niedermayer [Wednesday 21 September 2005] :<br />
> > cosmetics<br />
><br />
> Yes. And ?<br />
<br />
sorry, i should have been more verbose, maybe i should be restarted with -v<br />
can someone of the admin(s) do that?<br />
<br />
Michael<br />
</pre><br />
<br />
<pre><br />
as far as i can see this AVI file has _many_ video frames in each chunk, sick<br />
how can a person be capable of using a text editor (and writing software) and<br />
at the same time be such a complete idiot writing a program generating so<br />
broken avi files ...<br />
<br />
Michael<br />
</pre><br />
<br />
<pre><br />
michaels law: "if gcc can mess up, it does mess up" ;)<br />
</pre><br />
<br />
<pre><br />
> >> + "psllw $1, %%mm1 \n\t" <br />
> >> + "psllw $1, %%mm2 \n\t" <br />
> > <br />
> > paddw<br />
> <br />
> Is that always faster?<br />
<br />
no, you can design a cpu where its not<br />
<br />
Michael<br />
</pre><br />
<br />
<pre><br />
if you think that this patch will be accepted due to you whining how much<br />
time you spend on it already then you live in some strange fantasy world<br />
-- Michael Niedermayer in ffmpeg-devel at mplayerhq.hu<br />
</pre><br />
<br />
<pre><br />
Rich, I always knew you were a little out of the ordinary, but<br />
pirating gay porn wasn't quite what I was expecting even from you.<br />
-- Måns Rullgård in ffmpeg-devel at mplayerhq.hu<br />
</pre><br />
<br />
<pre><br />
[after a discussion of a patch with a new audio decoder evolved into <br />
runtime generation of tables vs. hardcoding them in the object file debate]<br />
<br />
what is the name of this bikeshed?<br />
-- compn<br />
</pre><br />
<br />
<pre><br />
On Thu, Oct 18, 2007 at 11:04:23AM +0200, Jean-Michel Pouré wrote:<br />
> Some days ago, Christian Marillat reported that it was impossible to<br />
> compile ffmpeg/libavcodec packages under Debian. Any idea where the<br />
> problem comes from? Was it fixed lately?<br />
<br />
Sure. My crystal ball tells me that fiendish aliens have been using<br />
force fields to obstruct the flow of cosmic energies in Christian's<br />
machine. The fact that the aliens have decided to sabotage FFmpeg first<br />
should give us all pause. It is a rare compliment to receive but it<br />
carries along a great responsibility.<br />
<br />
Now everybody remember that the survival of the human race rests on our<br />
shoulders. If we are to remain victorious in this epic conflict we must<br />
not succumb to darkness. The pureness of our hearts is our most potent<br />
defense. We must preserve it at any cost.<br />
<br />
Diego<br />
</pre><br />
<br />
<pre><br />
On Tue, Oct 30, 2007 at 12:15:28AM -0400, Ronald S. Bultje wrote:<br />
[...]<br />
> I'm not "they" anymore, I left Fluendo +/- 2 1/2 years ago and GStreamer +/-<br />
> 2 years ago.<br />
<br />
i see, ill get the kgb chief liquidated for providing me with outdated<br />
information<br />
<br />
Michael<br />
</pre><br />
<br />
<pre><br />
On Fri, Dec 14, 2007 at 08:01:51PM +0100, Diego Biurrun wrote:<br />
[...]<br />
> > + * @file rectanlge.h<br />
><br />
> rectANgle.h<br />
<br />
diego: /dev/brain: Permission denied ;)<br />
<br />
Michael<br />
</pre><br />
<br />
<pre><br />
The only officially correct spelling of snow is in the form of a frozen<br />
snowflake placed on 5000 year old papyrus and illuminated by the light of<br />
a population III star.<br />
<br />
Now please diego fix it to the official spelling!<br />
<br />
<br />
Michael<br />
</pre><br />
<br />
<pre><br />
O, mercyfull Diego, hast thou not given the dear needed access?<br />
Wherefore did thou create ye, if not to commit?<br />
<br />
<br />
Michael<br />
</pre><br />
<br />
<pre><br />
FFmpeg preys on weak, unmaintained or closed-source codecs. If your<br />
library does not meet those requirements, ffmpeg won't consume it (and<br />
will use a wrapper if it is good one).<br />
<br />
Kostya<br />
</pre><br />
<br />
<pre><br />
> <br />
> Just curios, is it possible to add hardware DVD, h.264 and VC-1 decoding to ffmpeg?<br />
<br />
Yes, through ./configure --dont-hijack-threads --see-ffmpeg-users<br />
<br />
Benjamin Zores<br />
</pre><br />
<br />
<pre><br />
Thats like giving a painting from Leonardo da Vinci to a wild boar so it can<br />
correct the fine details.<br />
<br />
Michael<br />
</pre><br />
<br />
<pre><br />
But the only correct usage of autotools is as argument to rm<br />
<br />
Michael<br />
</pre><br />
<br />
<pre><br />
Diego Biurrun wrote:<br />
> I came across this excellent paper from 15 years ago:<br />
> <br />
> #ifdef Considered Harmful, or Portability Experience With C News <br />
><br />
> It's a nice short read and emphasizes the experiences we have had around<br />
> here. It also comes to very similar conclusions, which is quite<br />
> gratifying.<br />
<br />
In the other news water is considered harmful yet useful...<br />
<br />
lu<br />
</pre><br />
<br />
<pre><br />
> > > > Considering 'lag' versus 'delay', I think I have consistently used <br />
> > > > 'lag' in my AMR code I think, mainly because it's shorter. :) <br />
> > > <br />
> > > Repent ye bloody sinner! Thy code showest the innermost part of thy <br />
> > > heart, lagging as it is behind the times! Now delay ye no longer with <br />
> > > updating it as thy Lord commands ye! <br />
> > <br />
> > I didnt know robert was worshiping the spirit who denies everything always. <br />
> <br />
> He has taken to worshipping all manner of devilishly spirits, as <br />
> islander folks are known to do ... <br />
> <br />
> > And reconsidering the whole, if they are equivalent, the shorter has <br />
> > some undenyable advantage. <br />
> > Dont ye agree? <br />
> <br />
> Nay, ye mind is clouded by the charms of the islander's charms. Pray <br />
> that the daemon's have mercy upon ye and lift those spells from thou... <br />
<br />
If you ever write a fantasy novel id want a copy ...<br />
<br />
Robert Swain, Diego and Michael<br />
</pre><br />
<br />
<pre><br />
> My spare time is taken up 20% MythTV, 10% SCST, 85% drinking heavily.<br />
<br />
And the remainder you spend on maths studies, right?<br />
<br />
Some man and MÃ¥ns<br />
</pre><br />
<br />
<pre><br />
[some weird problem on MacOSX 10.5]<br />
> The regular not-postfixed symbols are there, however. It's just that the<br />
> compiler ignores that it's compiling for an older version whenever it<br />
> encounters the _XOPEN_SOURCE flag.<br />
<br />
Our code conforms to widely accepted standards. Your compiler decides<br />
to replace a few symbols with non-standard names, which the linker<br />
then cannot find. Around here, that's called Your Problem.<br />
<br />
> To fix compiling on OSX for older versions, all _XOPEN_SOURCE<br />
> definitions should check for __APPLE__ first.<br />
><br />
> #if !defined(_XOPEN_SOURCE) && !defined(__DARWIN__) && !defined(__APPLE__)<br />
> # define _XOPEN_SOURCE 500<br />
> #endif<br />
<br />
In my part of the world, when there's a hole in the road, they don't<br />
require people to mount wings on their cars; they fix the hole. You<br />
should do the same. Or stay home.<br />
-- Adrian Stutz and MÃ¥ns<br />
</pre><br />
<br />
<pre><br />
>> In file included from /usr/include/math.h:26,<br />
>> from ./libavutil/mathematics.h:25,<br />
>> from ./libavutil/avutil.h:57,<br />
>> from liba52/parse.c:40:<br />
>> /usr/include/architecture/ppc/math.h:179: error: parse error before<br />
>> '__attribute__'<br />
><br />
> Well, wtf is in math.h that it stumbles over?<br />
<br />
This is getting better and better. First macosx can't link with its<br />
own libs, and now it can't even compile its own headers. If this<br />
keeps up, it won't be long before it stops booting at all, and we'll<br />
finally see an end to these problems.<br />
-- Guillaume, Reimar and MÃ¥ns<br />
</pre><br />
<br />
<pre><br />
> Oh, one more thing: In my world it is common to top-reply (and I am<br />
<br />
Then we don't like your world. Please go back there, and don't come<br />
here again.<br />
<br />
> doing this for almost 29 years). But now I know that the FFmpeg<br />
<br />
I see you're attempting a proof by doing-it-for-a-long-time approach.<br />
That doesn't work in this world.<br />
-- Frans de Boer and MÃ¥ns<br />
</pre><br />
<br />
<pre><br />
> balatoni denes tried to get a half optimized idct in and i nicely told<br />
> him that it has to include all tricks and optimizations we could think of.<br />
> We ended up with something that was clearly quite a bit faster than<br />
> what he submitted first, that is between all the complaints about how<br />
> little time he had and how evil we were for not just acceptiing it as<br />
> is.<br />
<br />
The Legend of the Warrior - now I am officially part of the ffmpeg<br />
mythology :)<br />
-- Michael Niedermayer and Balatoni Denes<br />
</pre><br />
<br />
<pre><br />
> Do you intend to actually implement a .ass demuxer?<br />
<br />
As you ask so nicely, Ill see what i can do. Iam starting to think that<br />
it might take less time to just implement everything related to ASS than<br />
continue this discussion.<br />
-- Uoti Urpala and Michael Niedermayer<br />
</pre><br />
<br />
<pre><br />
[about withdrawing Snow development prize/donation]<br />
>>> I'll be sorry to do this but it seems snow will die before beeing born.<br />
>> <br />
>> Well it seems that as 2008 comes to a close, Loren's prediction has<br />
>> finally been proven wrong ;)<br />
>> <br />
>> (from ~2005)<br />
>> <OpenSourced> where do you think x264 will be in 3 years<br />
>> <pengvado> replaced by snow :)<br />
>> <br />
> Darn, I thought you x264 devels were expert at various types of<br />
> prediction...<br />
<br />
That was only the first pass.<br />
-- Lars Täuber, Jason Garrett-Glaser, Andreas Öman and Måns Rullgård<br />
<br />
</pre><br />
<br />
<pre><br />
[...]<br />
split, improved, benchmarked, shaken, stirred and applied<br />
<br />
-- Michael Niedermayer in response to Jason Garrett-Glaser's patch<br />
</pre><br />
<br />
<pre><br />
2009/2/17 Michael Niedermayer:<br />
> 2009/2/17 Diego Biurrun wrote:<br />
<br />
[...]<br />
<br />
>> Have you ever tried to make a web design work in cross-browser fashion?<br />
><br />
> i never had a problem with plain html being displayed wrongly in any browser<br />
> and i never felt the need to add mandatory CSS/JS/JAVA/flash/SVG/VRML/ ...<br />
> there is extreemly little content that needs these technologies to be<br />
> represented.<br />
> truth is <p>, <h?>, <a>, <img> is enough for 98% of the content, for math<br />
> stuff sub/sup is usefull, also some bold or italic is sometimes usefull and<br />
> surely lists and tables on occasion but beyond that i have difficulty seeing<br />
> the point.<br />
> books still print black text on white, people dont seem to need the text<br />
> changing when they move their finger over it ...<br />
</pre><br />
<br />
<pre><br />
> Hi,<br />
><br />
> I have a friend with access to a 64-way Sparc machine with 32 GB of RAM. <br />
> He wants to see if it can set a new speed record with FFmpeg. So, have <br />
> it, you speed freaks: What would be the best way to stress FFmpeg, <br />
> preferably in multi-threaded mode? I suspect it would have to do with <br />
> encoding somehow, and this person has access to plenty of raw video footage.<br />
><br />
> Thanks...<br />
<br />
This may sound off-topic, but the prospect of using a supercomputer for<br />
mundane purposes sounds extremely delicious.<br />
-- Mike and Eric<br />
</pre><br />
<br />
===[http://lists.mplayerhq.hu/mailman/listinfo/ffmpeg-soc ffmpeg-soc]===<br />
<br />
<pre><br />
Alexander Strange wrote:<br />
> <br />
> On Apr 23, 2008, at 2:24 PM, vitor wrote:<br />
> <br />
>> Author: vitor<br />
>> Date: Wed Apr 23 20:24:46 2008<br />
>> New Revision: 2152<br />
>><br />
>> Log:<br />
>> Replace if(acroread appli_Goethe.pdf &){B}else{C} by if(a){C}else{B}<br />
> <br />
> Too much tab completion?<br />
<br />
Is there a price for the most nonsense commit log? ;-)<br />
<br />
-Vitor<br />
</pre><br />
<br />
===[http://lists.mplayerhq.hu/mailman/listinfo/nut-devel NUT-devel]===<br />
<br />
<pre><br />
We should have some nut samples.<br />
Someone, (not me, I am lazy), should mux some free video and <br />
audio into NUT (or just grab a camera and film something funny <br />
like what happens with an egg in the microwave or something <br />
else where A-V sync can be seen).<br />
<br />
Michael<br />
</pre><br />
<br />
<pre><br />
A "spec" as readable as a sendmail configuration file doesn't make<br />
matters better...<br />
<br />
Måns Rullgård<br />
</pre><br />
<br />
===other===<br />
<br />
<pre><br />
i've remembered i have root access at new mphq, but probably<br />
it was just a dream :)))<br />
-- A'rpi<br />
</pre><br />
<br />
<pre><br />
FFmpeg works like a human being: something nice comes in, crap comes out.<br />
-- superdump on an S-Bahn train in Berlin<br />
(written from memory, please fix)<br />
</pre><br />
<br />
<pre><br />
Michael Niedermayer <michaelni@gmx.at> added the comment:<br />
<br />
this is for bugreports not guess reports<br />
</pre><br />
<br />
<pre><br />
Sun Nov 11 10:32:18 CET 2007 <br />
Previous message: [Ffmpeg-user] Anyone? <br />
>Anyone?<br />
<br />
someone?<br />
<br />
>I still can't make it work.<br />
<br />
have you tried cialis?<br />
<br />
of course maybe you're referring to an audiovisual problem, <br />
and maybe it even pertains to ffmpeg...<br />
really hard to tell!<br />
<br />
tripp<br />
</pre><br />
<br />
<pre><br />
Breaking DRM is a little like attempting to break through a door even<br />
though the window is wide open and the only thing in the house is a bunch<br />
of things you dont want and which you would get tomorrow for free anyway<br />
-- Michael Niedermayer<br />
</pre><br />
<br />
<pre><br />
Hello,<br />
<br />
I have downloaded the latest version of vhook modules from<br />
"svn://svn.mplayerhq.hu/ffmpeg/trunk"<br />
but they are a bunch of .c and .h files.<br />
Please tell me how to generate a .dll file from them.<br />
I am using Windows XP.<br />
Thank you.<br />
<br />
-- An ordinary Windows user on ffmpeg-user (long lines broken manually<br />
and Yahoo signature removed to keep the wiki clean)<br />
</pre></div>
DrV
https://wiki.multimedia.cx/index.php?title=SoX_native_intermediate_format&diff=11669
SoX native intermediate format
2009-05-30T22:23:10Z
<p>DrV: no longer missing in ffmpeg</p>
<hr />
<div>* Extension: sox<br />
<br />
Uncompressed PCM format used in [[SoX]].<br />
<br />
[[SoX]] has LGPL muxer and demuxer.<br />
<br />
== File format ==<br />
<br />
Depending on the magic number, all fields are written in big or little endian, including the double-precision floating-point sample rate. Audio is always stored in 32-bit linear PCM, with endianness also determined by the file's magic number.<br />
<br />
Bytes Type Description<br />
<br />
0- 3 string Magic number (".SoX" for LE, "XoS." for BE)<br />
4- 7 int32 Size of headers in bytes<br />
8-15 int64 Number of samples<br />
16-23 double Sample rate<br />
24-27 int32 Number of channels<br />
28-31 int32 Size of comment in bytes<br />
32-.. string Comment<br />
..-.. Padding<br />
..-end int32 Audio samples<br />
<br />
Number of channels must be between 1 and 65535, inclusive.<br />
<br />
Total header size (including the magic number) must be a multiple of 8 bytes.<br />
<br />
The coded header size field equals size of the fixed header (without the magic number, i.e. 28 bytes) plus size of comment plus size of padding (which is reserved for possible future use).<br />
<br />
[[Category:Container Formats]]</div>
DrV
https://wiki.multimedia.cx/index.php?title=SoX_native_intermediate_format&diff=11665
SoX native intermediate format
2009-05-28T16:56:43Z
<p>DrV: clarify header size padding requirement</p>
<hr />
<div>* Extension: sox<br />
<br />
Uncompressed PCM format used in [[SoX]].<br />
<br />
[[SoX]] has LGPL muxer and demuxer.<br />
<br />
== File format ==<br />
<br />
Depending on the magic number, all fields are written in big or little endian, including the double-precision floating-point sample rate. Audio is always stored in 32-bit linear PCM, with endianness also determined by the file's magic number.<br />
<br />
Bytes Type Description<br />
<br />
0- 3 string Magic number (".SoX" for LE, "XoS." for BE)<br />
4- 7 int32 Size of headers in bytes<br />
8-15 int64 Number of samples<br />
16-23 double Sample rate<br />
24-27 int32 Number of channels<br />
28-31 int32 Size of comment in bytes<br />
32-.. string Comment<br />
..-.. Padding<br />
..-end int32 Audio samples<br />
<br />
Number of channels must be between 1 and 65535, inclusive.<br />
<br />
Total header size (including the magic number) must be a multiple of 8 bytes.<br />
<br />
The coded header size field equals size of the fixed header (without the magic number, i.e. 28 bytes) plus size of comment plus size of padding (which is reserved for possible future use).<br />
<br />
[[Category:Container Formats]]<br />
[[Category:Formats missing in FFmpeg]]</div>
DrV
https://wiki.multimedia.cx/index.php?title=SoX_native_intermediate_format&diff=11659
SoX native intermediate format
2009-05-27T23:53:50Z
<p>DrV: </p>
<hr />
<div>* Extension: sox<br />
<br />
Uncompressed PCM format used in [[SoX]].<br />
<br />
[[SoX]] has LGPL muxer and demuxer.<br />
<br />
== File format ==<br />
<br />
Depending on the magic number, all fields are written in big or little endian, including the double-precision floating-point sample rate. Audio is always stored in 32-bit linear PCM, with endianness also determined by the file's magic number.<br />
<br />
Bytes Type Description<br />
<br />
0- 3 string Magic number (".SoX" for LE, "XoS." for BE)<br />
4- 7 int32 Size of headers in bytes<br />
8-15 int64 Number of samples<br />
16-23 double Sample rate<br />
24-27 int32 Number of channels<br />
28-31 int32 Size of comment in bytes<br />
32-.. string Comment<br />
..-.. Padding<br />
..-end int32 Audio samples<br />
<br />
Number of channels must be between 1 and 65535, inclusive.<br />
<br />
Total header size must be a multiple of 8 bytes; it equals size of the fixed header (without the magic number - 28 bytes) plus size of comment plus size of padding (which is reserved for possible future use).<br />
<br />
[[Category:Container Formats]]<br />
[[Category:Formats missing in FFmpeg]]</div>
DrV
https://wiki.multimedia.cx/index.php?title=SoX_native_intermediate_format&diff=11658
SoX native intermediate format
2009-05-27T20:41:26Z
<p>DrV: file format</p>
<hr />
<div>* Extension: sox<br />
<br />
Uncompressed PCM format used in [[SoX]].<br />
<br />
[[SoX]] has LGPL muxer and demuxer.<br />
<br />
== File format ==<br />
<br />
Depending on the magic number, all fields are written in big or little endian, including the double-precision floating-point sample rate. Audio is always stored in 32-bit linear PCM, with endianness also determined by the file's magic number.<br />
<br />
Bytes Type Description<br />
<br />
0- 3 string Magic number (".SoX" for LE, "XoS." for BE)<br />
4- 7 int32 Size of headers in bytes<br />
8-15 int64 Number of samples<br />
16-23 double Sample rate<br />
24-27 int32 Number of channels<br />
28-31 int32 Size of comment in bytes<br />
32-.. string Comment<br />
..-.. Padding<br />
..-end int32 Audio samples<br />
<br />
Number of channels may be between 1 and 65535, inclusive.<br />
<br />
Total header size must be a multiple of 8 bytes; it equals size of the fixed header (without the magic number - 28 bytes) plus size of comment plus size of padding (which is reserved for possible future use).<br />
<br />
[[Category:Container Formats]]<br />
[[Category:Formats missing in FFmpeg]]</div>
DrV
https://wiki.multimedia.cx/index.php?title=Bink_Video&diff=11562
Bink Video
2009-05-04T23:43:15Z
<p>DrV: /* 1 */</p>
<hr />
<div>* FourCC: BINK (note that some FourCC lists assert that BINK is a FourCC for general-purpose multimedia containers; however, Bink data is always known to be encapsulated in a custom container format)<br />
* Company: [[RAD Game Tools]]<br />
* Samples: [http://samples.mplayerhq.hu/game-formats/bink/ http://samples.mplayerhq.hu/game-formats/bink/], countless video games<br />
<br />
Bink is a video codec that purports to use every video coding technique ([[DCT]], [[FFT]], [[Wavelet Coding]], [[Vector Quantization]], [[Motion Compensation]]) under the sun and used in a large number of computer and console games. The video is packaged in custom [[Bink Container|Bink]] files.<br />
<br />
Each plane is coded separately. The Y plane is always coded first in each frame.<br />
<br />
== Block types ==<br />
<br />
'''NOTE: This section is incomplete'''<br />
<br />
=== 0 ===<br />
<br />
Copy 8x8 block from previous frame to current frame<br />
<br />
=== 1 ===<br />
<br />
Read secondary block code<br />
<br />
(TODO)<br />
<br />
==== 1 - 3 ====<br />
<br />
Fill 16x16 block with coded byte<br />
<br />
=== 6 ===<br />
<br />
Fill 8x8 block with coded byte<br />
<br />
[[Category:Undiscovered Video Codecs]]<br />
[[Category:Video Codecs]]<br />
[[Category:Undiscovered Game Formats]]<br />
[[Category:Game Formats]]</div>
DrV
https://wiki.multimedia.cx/index.php?title=Bink_Video&diff=11561
Bink Video
2009-05-04T23:36:32Z
<p>DrV: start documenting block types (very incomplete)</p>
<hr />
<div>* FourCC: BINK (note that some FourCC lists assert that BINK is a FourCC for general-purpose multimedia containers; however, Bink data is always known to be encapsulated in a custom container format)<br />
* Company: [[RAD Game Tools]]<br />
* Samples: [http://samples.mplayerhq.hu/game-formats/bink/ http://samples.mplayerhq.hu/game-formats/bink/], countless video games<br />
<br />
Bink is a video codec that purports to use every video coding technique ([[DCT]], [[FFT]], [[Wavelet Coding]], [[Vector Quantization]], [[Motion Compensation]]) under the sun and used in a large number of computer and console games. The video is packaged in custom [[Bink Container|Bink]] files.<br />
<br />
Each plane is coded separately. The Y plane is always coded first in each frame.<br />
<br />
== Block types ==<br />
<br />
'''NOTE: This section is incomplete'''<br />
<br />
=== 0 ===<br />
<br />
Copy 8x8 block from previous frame to current frame<br />
<br />
=== 1 ===<br />
<br />
Read secondary block code<br />
<br />
(TODO)<br />
<br />
=== 6 ===<br />
<br />
Fill 8x8 block with coded byte<br />
<br />
[[Category:Undiscovered Video Codecs]]<br />
[[Category:Video Codecs]]<br />
[[Category:Undiscovered Game Formats]]<br />
[[Category:Game Formats]]</div>
DrV
https://wiki.multimedia.cx/index.php?title=CDXL&diff=11059
CDXL
2009-02-08T22:01:49Z
<p>DrV: initial CDXL documentation based on referenced articles</p>
<hr />
<div>* Company: [[Commodore]]<br />
* Patents: US 5,293,606, "Apparatus and method for transferring interleaved data objects in mass storage devices into separate destinations in memory"<br />
* See also: [http://en.wikipedia.org/wiki/CDXL Wikipedia CDXL article], [http://web.archive.org/web/20030108081402/http://home.t-online.de/home/K_Andreas/CDXL.HTM German article with technical details] (archive.org)<br />
<br />
CDXL is an uncompressed video format created by Commodore for playback from CD-ROM on Amiga computers.<br />
<br />
== File format ==<br />
<br />
CDXL files have no identifying markers or file headers; the file contains a number of frames, each prefixed by a frame header.<br />
<br />
Frame header | Palette | Video | Audio<br />
<br />
All multi-byte integers are big endian.<br />
<br />
== Frame header ==<br />
<br />
byte 0 File type<br />
byte 1 Info byte<br />
bits 0-2 Video encoding<br />
bit 3 Stereo flag<br />
bits 5-7 Plane arrangement<br />
bytes 2-5 Current chunk size<br />
bytes 6-9 Previous chunk size<br />
bytes 10-11 Reserved<br />
bytes 12-13 Current frame number (1 for first frame)<br />
bytes 14-15 Video width<br />
bytes 16-17 Video height<br />
bytes 18-19 Number of bit planes<br />
bytes 20-21 Palette size in bytes<br />
bytes 22-23 Sound size in bytes<br />
bytes 24-31 Reserved<br />
<br />
File type values (it is unknown what these mean):<br />
<br />
0 Custom CDXL<br />
1 Standard CDXL<br />
2 Special CDXL<br />
<br />
Video encoding values:<br />
<br />
0 RGB<br />
1 HAM<br />
2 YUV<br />
3 AVM & DCTV<br />
<br />
Plane arrangement values:<br />
0 Bit planar<br />
1 Byte planar<br />
2 Chunky<br />
4 Bit line<br />
6 Byte line<br />
<br />
== Palette ==<br />
<br />
The palette is encoded as 12-bit RGB values (4 bits each of R, G, and B) stored in 16-bit words with the upper 4 bits unused and set to 0. The palette size field in the header is the number of bytes in the palette, i.e. double the number of entries in the palette.<br />
<br />
== Audio ==<br />
<br />
Audio is encoded in standard uncompressed signed 8-bit PCM. The CDXL file itself does not seem to contain any sampling rate information, although related documents suggest 11025 Hz is standard.<br />
<br />
== Video ==<br />
<br />
Video is encoded differently based on the info byte in the header.<br />
<br />
RGB is encoded as an index into the palette for the current frame.<br />
<br />
HAM (Hold-And-Modify), an Amiga-specific video mode, is encoded as described on [http://en.wikipedia.org/wiki/Hold-And-Modify Wikipedia].<br />
<br />
[[Category:Container formats]]<br />
[[Category:Video Codecs]]<br />
[[Category:Incomplete Video Codecs]]</div>
DrV
https://wiki.multimedia.cx/index.php?title=Bink_Container&diff=10848
Bink Container
2009-01-14T04:12:09Z
<p>DrV: low bit of frame index table is keyframe flag</p>
<hr />
<div>''This page is based on the document 'Description of the Bink File Format' by Mike Melanson at [http://multimedia.cx/bink-format.txt http://multimedia.cx/bink-format.txt].''<br />
<br />
* Extenstions: bik<br />
* Company: [[RAD Game Tools]]<br />
* Samples: [http://samples.mplayerhq.hu/game-formats/bink/ http://samples.mplayerhq.hu/game-formats/bink/], countless video games<br />
<br />
Bink files are multimedia files used in a variety of video games, both on personal computers platforms and video game consoles. The files act as containers for data compressed with the proprietary [[Bink Video|Bink video]] and [[Bink Audio|audio]] codecs. Bink multimedia files are known to bear the .bik extension.<br />
<br />
== File Format ==<br />
<br />
'''This description is known to be incomplete.'''<br />
<br />
All multi-byte numbers are stored in little endian format.<br />
<br />
Bink files commence with a 44-byte header which is laid out as follows. Audio information follows the main header. If there are zero audio tracks, then the headers are omitted.<br />
<br />
bytes 0-2 file signature ('BIK')<br />
byte 3 Bink Video codec revision (0x62, 0x66, 0x67, 0x68, 0x69; b,f,g,h,i respectively)<br />
bytes 4-7 file size not including the first 8 bytes<br />
bytes 8-11 number of frames<br />
bytes 12-15 largest frame size in bytes<br />
bytes 16-19 number of frames again?<br />
bytes 20-23 video width (less than or equal to 32767)<br />
bytes 24-27 video height (less than or equal to 32767)<br />
bytes 28-31 video frames per second dividend<br />
bytes 32-35 video frames per second divider<br />
bytes 36-39 video flags<br />
bits 28-31: width and height scaling<br />
1 = 2x height doubled<br />
2 = 2x height interlaced<br />
3 = 2x width doubled<br />
4 = 2x width and height-doubled<br />
5 = 2x width and height-interlaced<br />
bit 20: has alpha plane<br />
bit 17: grayscale<br />
bytes 40-43 number of audio tracks (less than or equal to 256)<br />
<br />
for each audio track<br />
two bytes unknown<br />
two bytes audio channels (1 or 2). Not authoritative, see flags below.<br />
<br />
for each audio track<br />
two bytes audio sample rate (Hz)<br />
two bytes flags<br />
bit 15: unknown (observed in some samples)<br />
bit 14: unknown (observed in some samples)<br />
bit 13: stereo flag<br />
bit 12: Bink Audio algorithm<br />
1 = use Bink Audio DCT <br />
0 = use Bink Audio FFT<br />
<br />
for each audio track<br />
four bytes unknown<br />
<br />
Revisions f and g contain video planes in YVU order, while the planes are ordered YUV in other (later) revisions. Revision b is found in Heroes of Might and Magic 3, but is not supported by any of the tools published by RAD Game Tools.<br />
<br />
The audio track flags are similar to those defined for the [[Smacker]] ''AudioRate'' flags.<br />
<br />
Following the header is a frame index table. The number of entries in the table is equal to the number of frames specified in the header. Each entry consists of a 32-bit absolute offset for that frame. There is no length information provided in the table, so the length of a sample is implicitly the difference between frame offsets, and the size of the file (for the very last frame). If bit 0 of an entry is set, that frame is a keyframe; this bit should be masked off to find the actual offset of the frame data in the file.<br />
<br />
Each frame contains (optional) audio and video data. Bytes 12-15 (largest frame size) probably exist to provide the playback application with the largest single buffer it will have to allocate. The layout of each frame is as follows:<br />
<br />
for each audio track<br />
four bytes length of audio packet (bytes) plus four bytes. <br />
A value of zero indicates no audio is present for this track.<br />
four bytes number of samples in packet<br />
variable length [[Bink Audio]] packet<br />
<br />
variable length [[Bink Video]] packet<br />
<br />
== Exe files ==<br />
Bink data can be contained in exe files. To find where to start decoding search in the file for one of 4 id's:<br />
'fKIB'<br />
'gKIB'<br />
'hKIB'<br />
'iKIB'<br />
<br />
Note that this is BIK value is in machine order (therefore appears backwards for x86 binaries).<br />
<br />
== External Links ==<br />
* [http://www.radgametools.com/down/Bink/BinkLinuxPlayer.zip The Bink Video command line Player for x86 GNU/Linux from RAD Game Tools]<br />
<br />
[[Category:Container Formats]]<br />
[[Category:Game Formats]]</div>
DrV
https://wiki.multimedia.cx/index.php?title=Interesting_Patches&diff=10818
Interesting Patches
2009-01-11T22:22:30Z
<p>DrV: /* Bink Audio decoder by Peter Ross */</p>
<hr />
<div>This page tries to collect some useful patches for FFmpeg that didn't make into SVN for some reason or another.<br />
<br />
== native [[Zlib]] decoder by Mans Rullgard ==<br />
http://lists.mplayerhq.hu/pipermail/ffmpeg-devel/2007-July/032820.html<br />
<br />
In the same thread, there are patches to use the native decoder in several FFmpeg decoders.<br />
<br />
== [[WMV3]] encoder by Denis Fortin ==<br />
http://lists.mplayerhq.hu/pipermail/ffmpeg-devel/2007-June/031699.html<br />
<br />
== [[H.263]] rtp patch ==<br />
http://www.voxgratia.org/bin/ffmpeg-0.4.7.patch.zip, originally at http://www.salyens.com/downloads/index.html#ffmpeg-0.4.7, now removed.<br />
<br />
== [[Apple RPZA]] encoder by Todd Kirby ==<br />
http://lists.mplayerhq.hu/pipermail/ffmpeg-devel/2005-June/001673.html<br />
<br />
== Test Pattern Generator Demuxer by Nicholas George ==<br />
http://lists.mplayerhq.hu/pipermail/ffmpeg-devel/2007-October/036838.html<br />
<br />
== Test Pattern Generator Demuxer by [[User:Angustia|Ramiro Ribeiro Polla]] ==<br />
http://lists.mplayerhq.hu/pipermail/ffmpeg-devel/2007-April/028226.html<br />
Or <br />
http://thread.gmane.org/gmane.comp.video.ffmpeg.devel/49447<br />
<br />
== PES packetizer by Xiaohui Sun ==<br />
http://lists.mplayerhq.hu/pipermail/ffmpeg-devel/2007-September/034849.html<br />
<br />
Part of the work of [[FFmpeg Summer Of Code#TS Muxer|Summer Of Code TS Muxer]]<br />
<br />
== Imlib2script: a scriptable vhook by [[User:Wzrlpy|VÃctor Paesa]] ==<br />
http://thread.gmane.org/gmane.comp.video.ffmpeg.devel/52341<br />
<br />
== vf_imlib2: a libavfilter filter by [[User:Wzrlpy|VÃctor Paesa]] ==<br />
http://lists.mplayerhq.hu/pipermail/ffmpeg-soc/2007-December/002162.html<br />
<br />
== File concatenation by Wolfram Gloger ==<br />
http://lists.mplayerhq.hu/pipermail/ffmpeg-devel/2007-July/032131.html<br />
<br />
== "mem" file protocol by Lagrange Multiplier ==<br />
The "mem" protocol simply uses RAM as a source for input multimedia data, akin to how the "file" and "pipe" protocols use filesystem files and pipes as sources.<br />
<br />
http://lists.mplayerhq.hu/pipermail/ffmpeg-devel/2007-May/028489.html<br />
<br />
== Presets/profiles for usual targets by Panagiotis Issaris ==<br />
Allow to keep in a text file groups of command options, and apply them at once by specifying the target name.<br />
<br />
Handy for iPod, PSP, or any other picky multimedia player that otherwise requires lengthy command lines.<br />
<br />
http://article.gmane.org/gmane.comp.video.ffmpeg.devel/37244<br />
<br />
== PiP (Picture in Picture): a vhook filter by Mihail Stoyanov ==<br />
http://article.gmane.org/gmane.comp.video.ffmpeg.devel/38896<br />
<br />
== [[AMV]] encoder ==<br />
http://code.google.com/p/amv-codec-tools/<br />
<br />
See this post [http://lists.mplayerhq.hu/pipermail/ffmpeg-devel/2007-October/037356.html] to see what is missing to get it into SVN.<br />
<br />
== [[Electronic Arts Formats]] demuxer/decoder by [[User:Suxen drol|Peter Ross]]==<br />
http://lists.mplayerhq.hu/pipermail/ffmpeg-devel/2007-October/036938.html<br />
The format demuxer modifications and the EA video codecs have not yet been applied to FFmpeg.<br />
<br />
== Experimental MSVC port by Ole André Vadla Ravnås ==<br />
Code in the [http://bazaar-vcs.org bazaar] branch at http://people.collabora.co.uk/~oleavr/OABuild/bzr/ffmpeg/<br />
<br />
Patch at http://lists.mplayerhq.hu/pipermail/ffmpeg-devel/2008-March/044463.html<br />
<br />
== H264 encoder by Jori Liesenborgs & Panagiotis Issaris ==<br />
http://research.edm.uhasselt.be/~h264/<br />
<br />
== DTS/AC3 in wav autodetection ==<br />
http://thread.gmane.org/gmane.comp.video.ffmpeg.devel/49812/focus=49909<br />
Clean up this patch and also add detection of AC3 in wav, it is similar. Samples for both can be found here: http://www.sr.se/cgi-bin/mall/artikel.asp?ProgramID=2445&Artikel=739973<br />
<br />
== [[Bink Audio]] decoder by [[User:Suxen drol|Peter Ross]] ==<br />
http://lists.mplayerhq.hu/pipermail/ffmpeg-devel/2008-April/045346.html<br />
<br />
Note: An updated patch is under development by [[User:DrV]] based on an updated patch by the original [[User:Suxen drol|author]].<br />
<br />
== G722 decoder by Chas Williams ==<br />
http://lists.mplayerhq.hu/pipermail/ffmpeg-devel/2008-June/048457.html<br />
<br />
It is basically an adaptation to FFmpeg of the [http://www.soft-switch.org/ SirenDSP] decoder.<br />
<br />
== [[Chinese AVS]] video encoder by [[User:StefanG|Stefan Gehrer]] ==<br />
http://lists.mplayerhq.hu/pipermail/ffmpeg-devel/2007-July/033286.html<br />
<br />
== Lossless msmpeg4v3 to mpeg4 transcoder ==<br />
http://thread.gmane.org/gmane.comp.video.ffmpeg.devel/17074<br />
<br />
== Fixed point cook decoder ==<br />
http://thread.gmane.org/gmane.comp.video.ffmpeg.devel/46024<br />
http://thread.gmane.org/gmane.comp.video.ffmpeg.devel/54008<br />
http://thread.gmane.org/gmane.comp.video.ffmpeg.devel/54553<br />
[[Category:FFmpeg]]<br />
<br />
== GDI screen grabbing for Win32 ==<br />
http://thread.gmane.org/gmane.comp.video.ffmpeg.devel/43589<br />
<br />
There are two implementations in the thread above.<br />
<br />
== [[RealAudio sipr|RealAudio SIPR]] @16k decoder and demuxer by [[User:Voroshil|Vladimir Voroshilov]] ==<br />
<br />
http://lists.mplayerhq.hu/pipermail/ffmpeg-devel/2008-September/052961.html<br />
<br />
Expected to work with FFmpeg r15192<br />
<br />
== [[QCELP]] reference decoder wrapper by Moriyoshi Koizumi ==<br />
<br />
http://lists.mplayerhq.hu/pipermail/ffmpeg-devel/2006-December/020223.html</div>
DrV
https://wiki.multimedia.cx/index.php?title=Bink_Container&diff=10796
Bink Container
2009-01-10T03:51:14Z
<p>DrV: revisions f and g: plane ordering</p>
<hr />
<div>''This page is based on the document 'Description of the Bink File Format' by Mike Melanson at [http://multimedia.cx/bink-format.txt http://multimedia.cx/bink-format.txt].''<br />
<br />
* Extenstions: bik<br />
* Company: [[RAD Game Tools]]<br />
* Samples: [http://samples.mplayerhq.hu/game-formats/bink/ http://samples.mplayerhq.hu/game-formats/bink/], countless video games<br />
<br />
Bink files are multimedia files used in a variety of video games, both on personal computers platforms and video game consoles. The files act as containers for data compressed with the proprietary [[Bink Video|Bink video]] and [[Bink Audio|audio]] codecs. Bink multimedia files are known to bear the .bik extension.<br />
<br />
== File Format ==<br />
<br />
'''This description is known to be incomplete.'''<br />
<br />
All multi-byte numbers are stored in little endian format.<br />
<br />
Bink files commence with a 44-byte header which is laid out as follows. Audio information follows the main header. If there are zero audio tracks, then the headers are omitted.<br />
<br />
bytes 0-2 file signature ('BIK')<br />
byte 3 Bink Video codec revision (0x62, 0x66, 0x67, 0x68, 0x69; b,f,g,h,i respectively)<br />
bytes 4-7 file size not including the first 8 bytes<br />
bytes 8-11 number of frames<br />
bytes 12-15 largest frame size in bytes<br />
bytes 16-19 number of frames again?<br />
bytes 20-23 video width (less than or equal to 32767)<br />
bytes 24-27 video height (less than or equal to 32767)<br />
bytes 28-31 video frames per second dividend<br />
bytes 32-35 video frames per second divider<br />
bytes 36-39 video flags<br />
bits 28-31: width and height scaling<br />
1 = 2x height doubled<br />
2 = 2x height interlaced<br />
3 = 2x width doubled<br />
4 = 2x width and height-doubled<br />
5 = 2x width and height-interlaced<br />
bit 20: has alpha plane<br />
bit 17: grayscale<br />
bytes 40-43 number of audio tracks (less than or equal to 256)<br />
<br />
for each audio track<br />
two bytes unknown<br />
two bytes audio channels (1 or 2). Not authoritative, see flags below.<br />
<br />
for each audio track<br />
two bytes audio sample rate (Hz)<br />
two bytes flags<br />
bit 15: unknown (observed in some samples)<br />
bit 14: unknown (observed in some samples)<br />
bit 13: stereo flag<br />
bit 12: Bink Audio algorithm<br />
1 = use Bink Audio DCT <br />
0 = use Bink Audio FFT<br />
<br />
for each audio track<br />
four bytes unknown<br />
<br />
Revisions f and g contain video planes in YVU order, while the planes are ordered YUV in other (later) revisions. Revision b is found in Heroes of Might and Magic 3, but is not supported by any of the tools published by RAD Game Tools.<br />
<br />
The audio track flags are similar to those defined for the [[Smacker]] ''AudioRate'' flags.<br />
<br />
Following the header is a frame index table. The number of entries in the table is equal to the number of frames specified in the header. Each entry consists of a 32-bit absolute offset for that frame. There is no length information provided in the table, so the length of a sample is implicitly the difference between frame offsets, and the size of the file (for the very last frame). The absolute offset for the first entry in the table is often, but not always, offset by -1. Data for the first frame always begins immediately after the table, so the first entry in the table can be considered redundant.<br />
<br />
Each frame contains (optional) audio and video data. Bytes 12-15 (largest frame size) probably exist to provide the playback application with the largest single buffer it will have to allocate. The layout of each frame is as follows:<br />
<br />
for each audio track<br />
four bytes length of audio packet (bytes) plus four bytes. <br />
A value of zero indicates no audio is present for this track.<br />
four bytes number of samples in packet<br />
variable length [[Bink Audio]] packet<br />
<br />
variable length [[Bink Video]] packet<br />
<br />
== Exe files ==<br />
Bink data can be contained in exe files. To find where to start decoding search in the file for one of 4 id's:<br />
'fKIB'<br />
'gKIB'<br />
'hKIB'<br />
'iKIB'<br />
<br />
Note that this is BIK value is in machine order (therefore appears backwards for x86 binaries).<br />
<br />
== External Links ==<br />
* [http://www.radgametools.com/down/Bink/BinkLinuxPlayer.zip The Bink Video command line Player for x86 GNU/Linux from RAD Game Tools]<br />
<br />
[[Category:Container Formats]]<br />
[[Category:Game Formats]]</div>
DrV
https://wiki.multimedia.cx/index.php?title=User:DrV&diff=10795
User:DrV
2009-01-10T03:46:22Z
<p>DrV: </p>
<hr />
<div>Some random hacker.<br />
<br />
[http://www.drv.nu/ Home page]</div>
DrV
https://wiki.multimedia.cx/index.php?title=Bink_Container&diff=10735
Bink Container
2009-01-03T00:51:42Z
<p>DrV: /* File Format */ video flags: alpha plane</p>
<hr />
<div>''This page is based on the document 'Description of the Bink File Format' by Mike Melanson at [http://multimedia.cx/bink-format.txt http://multimedia.cx/bink-format.txt].''<br />
<br />
* Extenstions: bik<br />
* Company: [[RAD Game Tools]]<br />
* Samples: [http://samples.mplayerhq.hu/game-formats/bink/ http://samples.mplayerhq.hu/game-formats/bink/], countless video games<br />
<br />
Bink files are multimedia files used in a variety of video games, both on personal computers platforms and video game consoles. The files act as containers for data compressed with the proprietary [[Bink Video|Bink video]] and [[Bink Audio|audio]] codecs. Bink multimedia files are known to bear the .bik extension.<br />
<br />
== File Format ==<br />
<br />
'''This description is known to be incomplete.'''<br />
<br />
All multi-byte numbers are stored in little endian format.<br />
<br />
Bink files commence with a 44-byte header which is laid out as follows. Audio information follows the main header. If there are zero audio tracks, then the headers are omitted.<br />
<br />
bytes 0-2 file signature ('BIK')<br />
byte 3 Bink Video codec revision (0x62, 0x66, 0x67, 0x68, 0x69; b,f,g,h,i respectively)<br />
bytes 4-7 file size not including the first 8 bytes<br />
bytes 8-11 number of frames<br />
bytes 12-15 largest frame size in bytes<br />
bytes 16-19 number of frames again?<br />
bytes 20-23 video width (less than or equal to 32767)<br />
bytes 24-27 video height (less than or equal to 32767)<br />
bytes 28-31 video frames per second dividend<br />
bytes 32-35 video frames per second divider<br />
bytes 36-39 video flags<br />
bits 28-31: width and height scaling<br />
1 = 2x height doubled<br />
2 = 2x height interlaced<br />
3 = 2x width doubled<br />
4 = 2x width and height-doubled<br />
5 = 2x width and height-interlaced<br />
bit 20: has alpha plane<br />
bit 17: grayscale<br />
bytes 40-43 number of audio tracks (less than or equal to 256)<br />
<br />
for each audio track<br />
two bytes unknown<br />
two bytes audio channels (1 or 2). Not authoritative, see flags below.<br />
<br />
for each audio track<br />
two bytes audio sample rate (Hz)<br />
two bytes flags<br />
bit 15: unknown (observed in some samples)<br />
bit 14: unknown (observed in some samples)<br />
bit 13: stereo flag<br />
bit 12: Bink Audio algorithm<br />
1 = use Bink Audio DCT <br />
0 = use Bink Audio FFT<br />
<br />
for each audio track<br />
four bytes unknown<br />
<br />
The audio track flags are similar to those defined for the [[Smacker]] ''AudioRate'' flags.<br />
<br />
Following the header is a frame index table. The number of entries in the table is equal to the number of frames specified in the header. Each entry consists of a 32-bit absolute offset for that frame. There is no length information provided in the table, so the length of a sample is implicitly the difference between frame offsets, and the size of the file (for the very last frame). The absolute offset for the first entry in the table is often, but not always, offset by -1. Data for the first frame always begins immediately after the table, so the first entry in the table can be considered redundant.<br />
<br />
Each frame contains (optional) audio and video data. Bytes 12-15 (largest frame size) probably exist to provide the playback application with the largest single buffer it will have to allocate. The layout of each frame is as follows:<br />
<br />
for each audio track<br />
four bytes length of audio packet (bytes) plus four bytes. <br />
A value of zero indicates no audio is present for this track.<br />
four bytes number of samples in packet<br />
variable length [[Bink Audio]] packet<br />
<br />
variable length [[Bink Video]] packet<br />
<br />
== Exe files ==<br />
Bink data can be contained in exe files. To find where to start decoding search in the file for one of 4 id's:<br />
'fKIB'<br />
'gKIB'<br />
'hKIB'<br />
'iKIB'<br />
<br />
Note that this is BIK value is in machine order (therefore appears backwards for x86 binaries).<br />
<br />
Revision b is found in Heroes of Might and Magic 3, but is not supported by any of the tools published by RAD Game Tools.<br />
<br />
== External Links ==<br />
* [http://www.radgametools.com/down/Bink/BinkLinuxPlayer.zip The Bink Video command line Player for x86 GNU/Linux from RAD Game Tools]<br />
<br />
[[Category:Container Formats]]<br />
[[Category:Game Formats]]</div>
DrV
https://wiki.multimedia.cx/index.php?title=Bink_Container&diff=10734
Bink Container
2009-01-03T00:35:19Z
<p>DrV: /* File Format */ grayscale bit</p>
<hr />
<div>''This page is based on the document 'Description of the Bink File Format' by Mike Melanson at [http://multimedia.cx/bink-format.txt http://multimedia.cx/bink-format.txt].''<br />
<br />
* Extenstions: bik<br />
* Company: [[RAD Game Tools]]<br />
* Samples: [http://samples.mplayerhq.hu/game-formats/bink/ http://samples.mplayerhq.hu/game-formats/bink/], countless video games<br />
<br />
Bink files are multimedia files used in a variety of video games, both on personal computers platforms and video game consoles. The files act as containers for data compressed with the proprietary [[Bink Video|Bink video]] and [[Bink Audio|audio]] codecs. Bink multimedia files are known to bear the .bik extension.<br />
<br />
== File Format ==<br />
<br />
'''This description is known to be incomplete.'''<br />
<br />
All multi-byte numbers are stored in little endian format.<br />
<br />
Bink files commence with a 44-byte header which is laid out as follows. Audio information follows the main header. If there are zero audio tracks, then the headers are omitted.<br />
<br />
bytes 0-2 file signature ('BIK')<br />
byte 3 Bink Video codec revision (0x62, 0x66, 0x67, 0x68, 0x69; b,f,g,h,i respectively)<br />
bytes 4-7 file size not including the first 8 bytes<br />
bytes 8-11 number of frames<br />
bytes 12-15 largest frame size in bytes<br />
bytes 16-19 number of frames again?<br />
bytes 20-23 video width (less than or equal to 32767)<br />
bytes 24-27 video height (less than or equal to 32767)<br />
bytes 28-31 video frames per second dividend<br />
bytes 32-35 video frames per second divider<br />
bytes 36-39 video flags<br />
bits 28-31: width and height scaling<br />
1 = 2x height doubled<br />
2 = 2x height interlaced<br />
3 = 2x width doubled<br />
4 = 2x width and height-doubled<br />
5 = 2x width and height-interlaced<br />
bit 17: grayscale<br />
bytes 40-43 number of audio tracks (less than or equal to 256)<br />
<br />
for each audio track<br />
two bytes unknown<br />
two bytes audio channels (1 or 2). Not authoritative, see flags below.<br />
<br />
for each audio track<br />
two bytes audio sample rate (Hz)<br />
two bytes flags<br />
bit 15: unknown (observed in some samples)<br />
bit 14: unknown (observed in some samples)<br />
bit 13: stereo flag<br />
bit 12: Bink Audio algorithm<br />
1 = use Bink Audio DCT <br />
0 = use Bink Audio FFT<br />
<br />
for each audio track<br />
four bytes unknown<br />
<br />
The audio track flags are similar to those defined for the [[Smacker]] ''AudioRate'' flags.<br />
<br />
Following the header is a frame index table. The number of entries in the table is equal to the number of frames specified in the header. Each entry consists of a 32-bit absolute offset for that frame. There is no length information provided in the table, so the length of a sample is implicitly the difference between frame offsets, and the size of the file (for the very last frame). The absolute offset for the first entry in the table is often, but not always, offset by -1. Data for the first frame always begins immediately after the table, so the first entry in the table can be considered redundant.<br />
<br />
Each frame contains (optional) audio and video data. Bytes 12-15 (largest frame size) probably exist to provide the playback application with the largest single buffer it will have to allocate. The layout of each frame is as follows:<br />
<br />
for each audio track<br />
four bytes length of audio packet (bytes) plus four bytes. <br />
A value of zero indicates no audio is present for this track.<br />
four bytes number of samples in packet<br />
variable length [[Bink Audio]] packet<br />
<br />
variable length [[Bink Video]] packet<br />
<br />
== Exe files ==<br />
Bink data can be contained in exe files. To find where to start decoding search in the file for one of 4 id's:<br />
'fKIB'<br />
'gKIB'<br />
'hKIB'<br />
'iKIB'<br />
<br />
Note that this is BIK value is in machine order (therefore appears backwards for x86 binaries).<br />
<br />
Revision b is found in Heroes of Might and Magic 3, but is not supported by any of the tools published by RAD Game Tools.<br />
<br />
== External Links ==<br />
* [http://www.radgametools.com/down/Bink/BinkLinuxPlayer.zip The Bink Video command line Player for x86 GNU/Linux from RAD Game Tools]<br />
<br />
[[Category:Container Formats]]<br />
[[Category:Game Formats]]</div>
DrV
https://wiki.multimedia.cx/index.php?title=Bink_Container&diff=10733
Bink Container
2009-01-03T00:34:35Z
<p>DrV: /* File Format */ limits</p>
<hr />
<div>''This page is based on the document 'Description of the Bink File Format' by Mike Melanson at [http://multimedia.cx/bink-format.txt http://multimedia.cx/bink-format.txt].''<br />
<br />
* Extenstions: bik<br />
* Company: [[RAD Game Tools]]<br />
* Samples: [http://samples.mplayerhq.hu/game-formats/bink/ http://samples.mplayerhq.hu/game-formats/bink/], countless video games<br />
<br />
Bink files are multimedia files used in a variety of video games, both on personal computers platforms and video game consoles. The files act as containers for data compressed with the proprietary [[Bink Video|Bink video]] and [[Bink Audio|audio]] codecs. Bink multimedia files are known to bear the .bik extension.<br />
<br />
== File Format ==<br />
<br />
'''This description is known to be incomplete.'''<br />
<br />
All multi-byte numbers are stored in little endian format.<br />
<br />
Bink files commence with a 44-byte header which is laid out as follows. Audio information follows the main header. If there are zero audio tracks, then the headers are omitted.<br />
<br />
bytes 0-2 file signature ('BIK')<br />
byte 3 Bink Video codec revision (0x62, 0x66, 0x67, 0x68, 0x69; b,f,g,h,i respectively)<br />
bytes 4-7 file size not including the first 8 bytes<br />
bytes 8-11 number of frames<br />
bytes 12-15 largest frame size in bytes<br />
bytes 16-19 number of frames again?<br />
bytes 20-23 video width (less than or equal to 32767)<br />
bytes 24-27 video height (less than or equal to 32767)<br />
bytes 28-31 video frames per second dividend<br />
bytes 32-35 video frames per second divider<br />
bytes 36-39 video flags<br />
bits 28-31: width and height scaling<br />
1 = 2x height doubled<br />
2 = 2x height interlaced<br />
3 = 2x width doubled<br />
4 = 2x width and height-doubled<br />
5 = 2x width and height-interlaced<br />
bytes 40-43 number of audio tracks (less than or equal to 256)<br />
<br />
for each audio track<br />
two bytes unknown<br />
two bytes audio channels (1 or 2). Not authoritative, see flags below.<br />
<br />
for each audio track<br />
two bytes audio sample rate (Hz)<br />
two bytes flags<br />
bit 15: unknown (observed in some samples)<br />
bit 14: unknown (observed in some samples)<br />
bit 13: stereo flag<br />
bit 12: Bink Audio algorithm<br />
1 = use Bink Audio DCT <br />
0 = use Bink Audio FFT<br />
<br />
for each audio track<br />
four bytes unknown<br />
<br />
The audio track flags are similar to those defined for the [[Smacker]] ''AudioRate'' flags.<br />
<br />
Following the header is a frame index table. The number of entries in the table is equal to the number of frames specified in the header. Each entry consists of a 32-bit absolute offset for that frame. There is no length information provided in the table, so the length of a sample is implicitly the difference between frame offsets, and the size of the file (for the very last frame). The absolute offset for the first entry in the table is often, but not always, offset by -1. Data for the first frame always begins immediately after the table, so the first entry in the table can be considered redundant.<br />
<br />
Each frame contains (optional) audio and video data. Bytes 12-15 (largest frame size) probably exist to provide the playback application with the largest single buffer it will have to allocate. The layout of each frame is as follows:<br />
<br />
for each audio track<br />
four bytes length of audio packet (bytes) plus four bytes. <br />
A value of zero indicates no audio is present for this track.<br />
four bytes number of samples in packet<br />
variable length [[Bink Audio]] packet<br />
<br />
variable length [[Bink Video]] packet<br />
<br />
== Exe files ==<br />
Bink data can be contained in exe files. To find where to start decoding search in the file for one of 4 id's:<br />
'fKIB'<br />
'gKIB'<br />
'hKIB'<br />
'iKIB'<br />
<br />
Note that this is BIK value is in machine order (therefore appears backwards for x86 binaries).<br />
<br />
Revision b is found in Heroes of Might and Magic 3, but is not supported by any of the tools published by RAD Game Tools.<br />
<br />
== External Links ==<br />
* [http://www.radgametools.com/down/Bink/BinkLinuxPlayer.zip The Bink Video command line Player for x86 GNU/Linux from RAD Game Tools]<br />
<br />
[[Category:Container Formats]]<br />
[[Category:Game Formats]]</div>
DrV
https://wiki.multimedia.cx/index.php?title=Bink_Container&diff=10732
Bink Container
2009-01-03T00:17:41Z
<p>DrV: /* File Format */ fix formatting</p>
<hr />
<div>''This page is based on the document 'Description of the Bink File Format' by Mike Melanson at [http://multimedia.cx/bink-format.txt http://multimedia.cx/bink-format.txt].''<br />
<br />
* Extenstions: bik<br />
* Company: [[RAD Game Tools]]<br />
* Samples: [http://samples.mplayerhq.hu/game-formats/bink/ http://samples.mplayerhq.hu/game-formats/bink/], countless video games<br />
<br />
Bink files are multimedia files used in a variety of video games, both on personal computers platforms and video game consoles. The files act as containers for data compressed with the proprietary [[Bink Video|Bink video]] and [[Bink Audio|audio]] codecs. Bink multimedia files are known to bear the .bik extension.<br />
<br />
== File Format ==<br />
<br />
'''This description is known to be incomplete.'''<br />
<br />
All multi-byte numbers are stored in little endian format.<br />
<br />
Bink files commence with a 44-byte header which is laid out as follows. Audio information follows the main header. If there are zero audio tracks, then the headers are omitted.<br />
<br />
bytes 0-2 file signature ('BIK')<br />
byte 3 Bink Video codec revision (0x62, 0x66, 0x67, 0x68, 0x69; b,f,g,h,i respectively)<br />
bytes 4-7 file size not including the first 8 bytes<br />
bytes 8-11 number of frames<br />
bytes 12-15 largest frame size in bytes<br />
bytes 16-19 number of frames again?<br />
bytes 20-23 video width<br />
bytes 24-27 video height<br />
bytes 28-31 video frames per second dividend<br />
bytes 32-35 video frames per second divider<br />
bytes 36-39 video flags<br />
bits 28-31: width and height scaling<br />
1 = 2x height doubled<br />
2 = 2x height interlaced<br />
3 = 2x width doubled<br />
4 = 2x width and height-doubled<br />
5 = 2x width and height-interlaced<br />
bytes 40-43 number of audio tracks<br />
<br />
for each audio track<br />
two bytes unknown<br />
two bytes audio channels (1 or 2). Not authoritative, see flags below.<br />
<br />
for each audio track<br />
two bytes audio sample rate (Hz)<br />
two bytes flags<br />
bit 15: unknown (observed in some samples)<br />
bit 14: unknown (observed in some samples)<br />
bit 13: stereo flag<br />
bit 12: Bink Audio algorithm<br />
1 = use Bink Audio DCT <br />
0 = use Bink Audio FFT<br />
<br />
for each audio track<br />
four bytes unknown<br />
<br />
The audio track flags are similar to those defined for the [[Smacker]] ''AudioRate'' flags.<br />
<br />
Following the header is a frame index table. The number of entries in the table is equal to the number of frames specified in the header. Each entry consists of a 32-bit absolute offset for that frame. There is no length information provided in the table, so the length of a sample is implicitly the difference between frame offsets, and the size of the file (for the very last frame). The absolute offset for the first entry in the table is often, but not always, offset by -1. Data for the first frame always begins immediately after the table, so the first entry in the table can be considered redundant.<br />
<br />
Each frame contains (optional) audio and video data. Bytes 12-15 (largest frame size) probably exist to provide the playback application with the largest single buffer it will have to allocate. The layout of each frame is as follows:<br />
<br />
for each audio track<br />
four bytes length of audio packet (bytes) plus four bytes. <br />
A value of zero indicates no audio is present for this track.<br />
four bytes number of samples in packet<br />
variable length [[Bink Audio]] packet<br />
<br />
variable length [[Bink Video]] packet<br />
<br />
== Exe files ==<br />
Bink data can be contained in exe files. To find where to start decoding search in the file for one of 4 id's:<br />
'fKIB'<br />
'gKIB'<br />
'hKIB'<br />
'iKIB'<br />
<br />
Note that this is BIK value is in machine order (therefore appears backwards for x86 binaries).<br />
<br />
Revision b is found in Heroes of Might and Magic 3, but is not supported by any of the tools published by RAD Game Tools.<br />
<br />
== External Links ==<br />
* [http://www.radgametools.com/down/Bink/BinkLinuxPlayer.zip The Bink Video command line Player for x86 GNU/Linux from RAD Game Tools]<br />
<br />
[[Category:Container Formats]]<br />
[[Category:Game Formats]]</div>
DrV
https://wiki.multimedia.cx/index.php?title=Bink_Container&diff=10731
Bink Container
2009-01-03T00:17:25Z
<p>DrV: /* File Format */ video flags in header: scaling</p>
<hr />
<div>''This page is based on the document 'Description of the Bink File Format' by Mike Melanson at [http://multimedia.cx/bink-format.txt http://multimedia.cx/bink-format.txt].''<br />
<br />
* Extenstions: bik<br />
* Company: [[RAD Game Tools]]<br />
* Samples: [http://samples.mplayerhq.hu/game-formats/bink/ http://samples.mplayerhq.hu/game-formats/bink/], countless video games<br />
<br />
Bink files are multimedia files used in a variety of video games, both on personal computers platforms and video game consoles. The files act as containers for data compressed with the proprietary [[Bink Video|Bink video]] and [[Bink Audio|audio]] codecs. Bink multimedia files are known to bear the .bik extension.<br />
<br />
== File Format ==<br />
<br />
'''This description is known to be incomplete.'''<br />
<br />
All multi-byte numbers are stored in little endian format.<br />
<br />
Bink files commence with a 44-byte header which is laid out as follows. Audio information follows the main header. If there are zero audio tracks, then the headers are omitted.<br />
<br />
bytes 0-2 file signature ('BIK')<br />
byte 3 Bink Video codec revision (0x62, 0x66, 0x67, 0x68, 0x69; b,f,g,h,i respectively)<br />
bytes 4-7 file size not including the first 8 bytes<br />
bytes 8-11 number of frames<br />
bytes 12-15 largest frame size in bytes<br />
bytes 16-19 number of frames again?<br />
bytes 20-23 video width<br />
bytes 24-27 video height<br />
bytes 28-31 video frames per second dividend<br />
bytes 32-35 video frames per second divider<br />
bytes 36-39 video flags<br />
bits 28-31: width and height scaling<br />
1 = 2x height doubled<br />
2 = 2x height interlaced<br />
3 = 2x width doubled<br />
4 = 2x width and height-doubled<br />
5 = 2x width and height-interlaced<br />
<br />
bytes 40-43 number of audio tracks<br />
<br />
for each audio track<br />
two bytes unknown<br />
two bytes audio channels (1 or 2). Not authoritative, see flags below.<br />
<br />
for each audio track<br />
two bytes audio sample rate (Hz)<br />
two bytes flags<br />
bit 15: unknown (observed in some samples)<br />
bit 14: unknown (observed in some samples)<br />
bit 13: stereo flag<br />
bit 12: Bink Audio algorithm<br />
1 = use Bink Audio DCT <br />
0 = use Bink Audio FFT<br />
<br />
for each audio track<br />
four bytes unknown<br />
<br />
The audio track flags are similar to those defined for the [[Smacker]] ''AudioRate'' flags.<br />
<br />
Following the header is a frame index table. The number of entries in the table is equal to the number of frames specified in the header. Each entry consists of a 32-bit absolute offset for that frame. There is no length information provided in the table, so the length of a sample is implicitly the difference between frame offsets, and the size of the file (for the very last frame). The absolute offset for the first entry in the table is often, but not always, offset by -1. Data for the first frame always begins immediately after the table, so the first entry in the table can be considered redundant.<br />
<br />
Each frame contains (optional) audio and video data. Bytes 12-15 (largest frame size) probably exist to provide the playback application with the largest single buffer it will have to allocate. The layout of each frame is as follows:<br />
<br />
for each audio track<br />
four bytes length of audio packet (bytes) plus four bytes. <br />
A value of zero indicates no audio is present for this track.<br />
four bytes number of samples in packet<br />
variable length [[Bink Audio]] packet<br />
<br />
variable length [[Bink Video]] packet<br />
<br />
== Exe files ==<br />
Bink data can be contained in exe files. To find where to start decoding search in the file for one of 4 id's:<br />
'fKIB'<br />
'gKIB'<br />
'hKIB'<br />
'iKIB'<br />
<br />
Note that this is BIK value is in machine order (therefore appears backwards for x86 binaries).<br />
<br />
Revision b is found in Heroes of Might and Magic 3, but is not supported by any of the tools published by RAD Game Tools.<br />
<br />
== External Links ==<br />
* [http://www.radgametools.com/down/Bink/BinkLinuxPlayer.zip The Bink Video command line Player for x86 GNU/Linux from RAD Game Tools]<br />
<br />
[[Category:Container Formats]]<br />
[[Category:Game Formats]]</div>
DrV
https://wiki.multimedia.cx/index.php?title=YouTube&diff=10651
YouTube
2008-12-15T10:03:31Z
<p>DrV: </p>
<hr />
<div>* Website: http://www.youtube.com/<br />
<br />
YouTube is a website that allows users to upload video that can then be viewed by other users. Some of YouTube's wild popularity hinges on its accessibility-- it is able to accept multimedia files encoded in an enormous array of formats. Some suspect that YouTube's backend conversion software leverages [[FFmpeg]]. FFmpeg supports a wide range of multimedia formats as documented in this [[Main Page|Multimedia Wiki]]. This Wiki page is an effort to determine which multimedia formats can be converted by YouTube's software.<br />
<br />
Note that this is an ongoing project and is not exactly an authoritative list of all the formats that YouTube accepts.<br />
<br />
== Formats That YouTube Accepts ==<br />
<br />
{| border="1" cellpadding="4"<br />
! container || video codec || audio codec || status || YouTube link || sample file name || sample location || date tested<br />
|-<br />
| [[AVI]]<br />
| [[FMP4]]<br />
| [[PCM]]<br />
| bgcolor="#00FF00" | works<br />
| [http://youtube.com/watch?v=ekkk8sVajqE converted video]<br />
| n/a<br />
| n/a<br />
| January 4, 2007<br />
|-<br />
| [[RoQ]]<br />
| [[RoQ|RoQ Video]]<br />
| [[Id RoQ DPCM]]<br />
| bgcolor="yellow" | some visual bugs<br />
| [http://youtube.com/watch?v=9KaOfvKCSH0 converted video]<br />
| jk02.roq<br />
| [http://samples.mplayerhq.hu/game-formats/idroq/ location]<br />
| January 4, 2007<br />
|-<br />
| [[Sega FILM]]<br />
| [[Cinepak]]<br />
| [[PCM]]<br />
| bgcolor="#00FF00" | mostly works<br />
| [http://youtube.com/watch?v=hxxG_pnNJDM converted video]<br />[http://youtube.com/watch?v=eXaj9povG_w converted video]<br />[http://youtube.com/watch?v=JWHzfypvHMg converted video]<br />[http://youtube.com/watch?v=tXZbK9Vt8LI converted video]<br />[http://youtube.com/watch?v=XLT0Qsp_oP8 converted video]<br />
| worldseriesbaseball.cpk<br />hiddensouls-gun-butterfly.cpk<br />intro.film<br />corelogo-stereo.cpk<br />R01.CAK<br /><br />
| [http://samples.mplayerhq.hu/game-formats/film-cpk/ location]<br />
| January 4, 2007<br />
|-<br />
| [[4xm Format]]<br />
| [[4xm Video]]<br />
| [[4X IMA ADPCM]]<br />
| bgcolor="yellow" | somewhat works<br />
| [http://youtube.com/watch?v=QF8tRFFyOUQ converted video]<br />
| aitd-29.4xm<br />
| [http://samples.mplayerhq.hu/game-formats/4xm/ location]<br />
| January 4, 2007<br />
|-<br />
| [[Flic Video]]<br />
| [[Flic Video]]<br />
| n/a<br />
| bgcolor="#00FF00" | works<br />
| [http://www.youtube.com/watch?v=ZPIYoaBe6uk converted video]<br />[http://www.youtube.com/watch?v=zfABghyPtDw converted video]<br />
| a.fli<br />fli-engines.fli<br />
| [http://samples.mplayerhq.hu/fli-flc/ location]<br />
| January 4, 2007<br />
|-<br />
| [[AVI]]<br />
| [[DUCK]], 16-bit variant<br />
| [[Duck DK4 IMA ADPCM]]<br />
| bgcolor="#00FF00" | works<br />
| [http://www.youtube.com/watch?v=fYn3A05DGqM converted video]<br />[http://www.youtube.com/watch?v=-TnaRNdIDDE converted video]<br />
| vc2_intro.avi<br />salsa.avi<br />
| [http://samples.mplayerhq.hu/game-formats/DUCK/ location]<br />
| January 4, 2007<br />
|-<br />
| [[AVI]]<br />
| [[DUCK]], 24-bit variant<br />
| [[Duck DK3 IMA ADPCM]]<br />
| bgcolor="yellow" | visual bugs<br />
| [http://www.youtube.com/watch?v=vP16mAgrDV8 converted video]<br />
| sonic3dblast_intro.avi<br />
| [http://samples.mplayerhq.hu/game-formats/DUCK/ location]<br />
| January 4, 2007<br />
|-<br />
| [[MOV]]<br />
| [[8BPS]]<br />
| ??<br />
| bgcolor="#00FF00" | works<br />
| [http://www.youtube.com/watch?v=iz19C4js9Sc converted video]<br />
| full9ironswing.mov<br />
| [http://samples.mplayerhq.hu/V-codecs/8BPS-PlanarRGB/ location]<br />
| January 4, 2007<br />
|-<br />
| [[AVI]]<br />
| [[AASC]]<br />
| ??<br />
| bgcolor="#00FF00" | works<br />
| [http://www.youtube.com/watch?v=s-o588WTHgY converted video]<br />
| AASC.AVI<br />
| [http://samples.mplayerhq.hu/V-codecs/AASC/ location]<br />
| January 4, 2007<br />
|-<br />
| [[AVI]]<br />
| [[AP41]]<br />
| ??<br />
| bgcolor="#00FF00" | works<br />
| [http://www.youtube.com/watch?v=-ZJZ3tPWGVE converted video]<br />
| AP2_teaser.avi<br />
| [http://samples.mplayerhq.hu/V-codecs/AP41/ location]<br />
| January 4, 2007<br />
|-<br />
| [[AVI]]<br />
| [[ASV1]]<br />
| ??<br />
| bgcolor="#00FF00" | works<br />
| [http://www.youtube.com/watch?v=JxtLKdOWZrM converted video]<br />
| ASV1.avi<br />
| [http://samples.mplayerhq.hu/V-codecs/ASV1/ location]<br />
| January 4, 2007<br />
|-<br />
| [[AVI]]<br />
| [[ASV2]]<br />
| ??<br />
| bgcolor="#00FF00" | works<br />
| [http://www.youtube.com/watch?v=KluKo1oVmIc converted video]<br />
| asv2_320x240_3.avi<br />
| [http://samples.mplayerhq.hu/V-codecs/ASV2/ location]<br />
| January 4, 2007<br />
|-<br />
| [[AVI]]<br />
| [[CJPG]]<br />
| ??<br />
| bgcolor="#00FF00" | works<br />
| [http://www.youtube.com/watch?v=NEmTg5H04jk converted video]<br />
| video013_paulera.avi<br />
| [http://samples.mplayerhq.hu/V-codecs/CJPG/ location]<br />
| January 4, 2007<br />
|-<br />
| [[AVI]]<br />
| [[CLJR]]<br />
| ??<br />
| bgcolor="#00FF00" | works<br />
| [http://www.youtube.com/watch?v=ujfEkLBhdPM converted video]<br />
| testcljr.avi<br />
| [http://samples.mplayerhq.hu/V-codecs/CLJR/ location]<br />
| January 4, 2007<br />
|-<br />
| [[AVI]]<br />
| [[CRAM]], 8-bit variant<br />
| [[Microsoft ADPCM]]<br />
| bgcolor="#00FF00" | works<br />
| [http://www.youtube.com/watch?v=AWNwMzdO3EE converted video]<br />
| dance.avi<br />
| [http://samples.mplayerhq.hu/V-codecs/CRAM/ location]<br />
| January 4, 2007<br />
|-<br />
| [[AVI]]<br />
| [[CRAM]], 16-bit variant<br />
| ??<br />
| bgcolor="#00FF00" | works<br />
| [http://www.youtube.com/watch?v=9ULLRKLHA78 converted video]<br />
| clock-cram16.avi<br />
| [http://samples.mplayerhq.hu/V-codecs/CRAM/ location]<br />
| January 4, 2007<br />
|-<br />
| [[MOV]]<br />
| [[Cinepak]], 8-bit palettized<br />
| ??<br />
| bgcolor="#00FF00" | works<br />
| [http://www.youtube.com/watch?v=7_EftBXPVtg converted video]<br />(private)<br />
| catfight%20Tag%20team%20DT.mov<br />
| [http://samples.mplayerhq.hu/V-codecs/CVID/palette/ location]<br />
| January 4, 2007<br />
|-<br />
| [[AVI]]<br />
| [[CYUV]]<br />
| n/a<br />
| bgcolor="#00FF00" | works<br />
| [http://www.youtube.com/watch?v=JNqAoPlz5MM converted video]<br />
| cyuv.avi<br />
| [http://samples.mplayerhq.hu/V-codecs/CYUV/ location]<br />
| January 4, 2007<br />
|-<br />
| [[AVI]]<br />
| [[DXGM]]<br />
| ??<br />
| bgcolor="#00FF00" | works<br />
| [http://www.youtube.com/watch?v=rS49fvSYfP8 converted video]<br />
| 0x4D475844-wow.avi<br />
| [http://samples.mplayerhq.hu/V-codecs/DXGM/ location]<br />
| January 4, 2007<br />
|-<br />
| [[AVI]]<br />
| [[I263]]<br />
| ??<br />
| bgcolor="#00FF00" | works<br />
| [http://www.youtube.com/watch?v=UB6hTOSI-cE converted video]<br />
| i263.avi<br />
| [http://samples.mplayerhq.hu/V-codecs/I263/ location]<br />
| January 4, 2007<br />
|-<br />
| [[AVI]]<br />
| [[IV32]]<br />
| ??<br />
| bgcolor="#00FF00" | works<br />
| [http://www.youtube.com/watch?v=agiz8CzE14A converted video]<br />
| levis.avi<br />
| [http://samples.mplayerhq.hu/V-codecs/IV32/ location]<br />
| January 4, 2007<br />
|-<br />
| [[AVI]]<br />
| [[IV41]]<br />
| ??<br />
| bgcolor="#00FF00" | works<br />
| [http://www.youtube.com/watch?v=ASjTE5-O7ek converted video]<br />
| indeo41.avi<br />
| [http://samples.mplayerhq.hu/V-codecs/IV41/ location]<br />
| January 4, 2007<br />
|-<br />
| [[AVI]]<br />
| [[IV50]]<br />
| ??<br />
| bgcolor="#00FF00" | works<br />
| [http://www.youtube.com/watch?v=qas7jnznkpE converted video]<br />
| Educ_Movie_DeadlyForce.avi<br />
| [http://samples.mplayerhq.hu/V-codecs/IV50/ location]<br />
| January 4, 2007<br />
|-<br />
| [[MOV]]<br />
| [[ZyGo]]<br />
| ??<br />
| bgcolor="yellow" | somewhat works<br />
| [http://www.youtube.com/watch?v=z9E22FAaDio converted video]<br />
| Film_200_zygo_pro.mov<br />
| [http://samples.mplayerhq.hu/V-codecs/ZyGo/ location]<br />
| January 4, 2007<br />
|-<br />
| [[AVI]]<br />
| [[WV1F]]<br />
| ??<br />
| bgcolor="#00FF00" | works<br />
| [http://www.youtube.com/watch?v=SHerEq2WTtM converted video]<br />
| title2.avi<br />
| [http://samples.mplayerhq.hu/V-codecs/WV1F/AVI/ location]<br />
| January 4, 2007<br />
|-<br />
| [[AVI]]<br />
| [[QPEG]]<br />
| ??<br />
| bgcolor="#00FF00" | works<br />
| [http://www.youtube.com/watch?v=XlXoLVVz94w converted video]<br />
| Clock.avi<br />
| [http://samples.mplayerhq.hu/V-codecs/QPEG/ location]<br />
| January 4, 2007<br />
|-<br />
| [[AVI]]<br />
| [[RT21]]<br />
| ??<br />
| bgcolor="#00FF00" | works<br />
| [http://www.youtube.com/watch?v=-3jpd7GHZ80 converted video]<br />
| VPAR0019.AVI<br />
| [http://samples.mplayerhq.hu/V-codecs/RT21/ location]<br />
| January 4, 2007<br />
|-<br />
| [[MOV]]<br />
| [[RPZA]]<br />
| n/a<br />
| bgcolor="#00FF00" | works<br />
| [http://www.youtube.com/watch?v=QE_BUd4aX48 converted video]<br />
| rpza2.mov<br />
| [http://samples.mplayerhq.hu/V-codecs/RPZA/ location]<br />
| January 4, 2007<br />
|-<br />
| [[MOV]]<br />
| [[SMC]]<br />
| n/a<br />
| bgcolor="#00FF00" | works<br />
| [http://www.youtube.com/watch?v=4jbipvw_098 converted video]<br />
| cass_schi.qt<br />
| [http://samples.mplayerhq.hu/V-codecs/SMC/ location]<br />
| January 4, 2007<br />
|-<br />
| [[AVI]]<br />
| [[TM20]]<br />
| ??<br />
| bgcolor="#00FF00" | works<br />
| [http://www.youtube.com/watch?v=u3Sq5mMOj-M converted video]<br />
| sqlogo.avi<br />
| [http://samples.mplayerhq.hu/V-codecs/TM20/ location]<br />
| January 4, 2007<br />
|-<br />
| [[AVI]]<br />
| [[YVU9]]<br />
| n/a<br />
| bgcolor="#00FF00" | works<br />
| [http://www.youtube.com/watch?v=xU1iuk9Bin8 converted video]<br />
| indeoraw1.2.avi<br />
| [http://samples.mplayerhq.hu/V-codecs/YVU9/ location]<br />
| January 4, 2007<br />
|-<br />
| [[NuppelVideo]]<br />
| [[NuppelVideo RTJPEG]]<br />
| ??<br />
| bgcolor="#00FF00" | works<br />
| [http://www.youtube.com/watch?v=ZGMOED1kkwg converted video]<br />
| Today.nuv<br />
| [http://samples.mplayerhq.hu/nuv/ location]<br />
| January 4, 2007<br />
|-<br />
| [[PVA]]<br />
| MPEG-2<br />
| MPEG layer 2<br />
| bgcolor="#00FF00" | works<br />
| [http://youtube.com/watch?v=Nn8vdNIhL3k converted video]<br />
| PVA_DeejayTV_Coldplay.pva<br />
| [http://samples.mplayerhq.hu/PVA/ location]<br />
| January 4, 2007<br />
|-<br />
| [[RealMedia]]<br />
| [[RV10]]<br />
| ??<br />
| bgcolor="#00FF00" | works<br />
| [http://www.youtube.com/watch?v=cF9FIS0QZk8 converted video]<br />
| jade-56.rm <br />
| [http://samples.mplayerhq.hu/real/VC-RV10/ location]<br />
| January 4, 2007<br />
|-<br />
| [[RealMedia]]<br />
| [[RV20]]<br />
| ??<br />
| bgcolor="#00FF00" | works<br />
| [http://www.youtube.com/watch?v=tK1wc0Qfzfs converted video]<br />
| Legend-of-the-Rangers_I.rm<br />
| [http://samples.mplayerhq.hu/real/VC-RV20/ location]<br />
| January 4, 2007<br />
|-<br />
| [[RealMedia]]<br />
| [[RV30]]<br />
| ??<br />
| bgcolor="#00FF00" | works<br />
| [http://www.youtube.com/watch?v=hY74r57WqLI converted video]<br />
| eiqu-56k.rm<br />
| [http://samples.mplayerhq.hu/real/VC-RV30/ location]<br />
| January 4, 2007<br />
|-<br />
| [[FLV]]<br />
| [[Sorenson Spark]]<br />
| ??<br />
| bgcolor="#00FF00" | works<br />
| [http://youtube.com/watch?v=Rsb6eejikQU converted video]<br />
| zelda.flv<br />
| [http://samples.mplayerhq.hu/FLV/ location]<br />
| January 4, 2007<br />
|-<br />
| [[AVI]]<br />
| [[FFV1]]<br />
| n/a<br />
| bgcolor="#00FF00" | works<br />
| [http://www.youtube.com/watch?v=2mBR9bqBzIw converted video]<br />
| custom command line <ref name="avi-ffv1-command-line">'mencoder /dev/urandom -demuxer rawvideo -rawvideo w=320:h=240:fps=24 -frames 120 -ovc lavc -lavcopts vcodec=ffv1 -o test.avi'</ref><br />
| n/a<br />
| January 4, 2007<br />
|-<br />
| [[YUV4MPEG2]]<br />
| Raw [[YCbCr 4:2:0]]<br />
| n/a<br />
| bgcolor="#00FF00" | works<br />
| [http://www.youtube.com/watch?v=qGWWOjo_yM8 converted video]<br />
| custom command line<ref name="yuv4mpeg2-command-line">'ffmpeg -i inputfile.ext outputfile.y4m'</ref><br />
| n/a<br />
| January 5, 2007<br />
|-<br />
| [[AVI]]<br />
| [[Microsoft RLE]]<br />
| [[Microsoft ADPCM]]<br />
| bgcolor="#00FF00" | works<br />
| [http://youtube.com/watch?v=b4qb_L2JoeA converted video]<br />
| <br />
| <br />
| January 14, 2007<br />
|-<br />
| [[MOV]]<br />
| [[SVQ1]]<br />
| [[QDM2]]<br />
| bgcolor="#00FF00" | works<br />
| [http://youtube.com/watch?v=5Ow0Zvrma0s converted video]<br />
| <br />
| <br />
| January 20, 2007<br />
|-<br />
| [[Smacker|Rad Game Tools Smacker]]<br />
| [[Smacker|Smacker Video]]<br />
| [[Smacker|Smacker Audio]]<br />
| bgcolor="yellow" | somewhat works<br />
| [http://www.youtube.com/watch?v=uois4Rc-kYY converted video]<br />
| Streets of Sim City intro.smk<br />
|<br />
| December 15, 2008<br />
<!--<br />
|-<br />
| <br />
| <br />
| <br />
| bgcolor="#00FF00" |<br />
| [ converted video]<br />
| <br />
| [ location]<br />
| January 4, 2007<br />
--><br />
|}<br />
<br />
== Formats That YouTube Fails To Convert ==<br />
The reason that this list tests so many obscure formats is that YouTube is known to handle an impressive number of obscure formats just fine.<br />
<br />
Note that items marked rejected because they were too long are probably results of software malfunction; the samples should not exceed the 10-minute time length ''(I'm making this assumption based on their relatively small sizes --[[User:Multimedia Mike|Multimedia Mike]])''.<br />
<br />
{| border="1" cellpadding="4"<br />
! container || video codec || audio codec || status || YouTube error || sample file name || sample location || date tested<br />
|-<br />
| [[Wing Commander III MVE]]<br />
| [[Wing Commander III MVE Video Codec]]<br />
| [[PCM]]<br />
| bgcolor="#FF0000" | fails<br />
| Failed (unable to convert video file)<br />
| wc3-chewed-out.mve<br />
| [http://samples.mplayerhq.hu/game-formats/wc3-mve/ location]<br />
| January 4, 2007<br />
|-<br />
| [[CIN|Quake II CIN]]<br />
| [[CIN|Quake II CIN Video]]<br />
| [[PCM]]<br />
| bgcolor="#FF0000" | fails<br />
| Failed (unable to convert video file)<br />
| idlog.cin<br />
| [http://samples.mplayerhq.hu/game-formats/idcin/ location]<br />
| January 4, 2007<br />
|-<br />
| [[Smacker|Rad Game Tools Smacker]]<br />
| [[Smacker|Smacker Video]]<br />
| [[Smacker|Smacker Audio]]<br />
| bgcolor="#FF0000" | fails<br />
| Failed (invalid file format)<br />
| <br />
| [http://samples.mplayerhq.hu/game-formats/smacker/ location]<br />
| January 4, 2007<br />
|-<br />
| [[Interplay MVE]]<br />
| [[Interplay Video]]<br />
| [[Interplay DPCM]]<br />
| bgcolor="#FF0000" | fails<br />
| Failed (unable to convert video file)<br />
| baldursgate-logo.mve<br />
| [http://samples.mplayerhq.hu/game-formats/interplay-mve/ location]<br />
| January 4, 2007<br />
|-<br />
| [[VQA|Westwood VQA]]<br />
| [[VQA|Westwood VQA]]<br />
| [[Westwood ADPCM Audio]]<br />
| bgcolor="#FF0000" | fails<br />
| Failed (invalid file format)<br />
| cc-demo1.vqa<br />
| [http://samples.mplayerhq.hu/game-formats/vqa/ location]<br />
| January 4, 2007<br />
|-<br />
| [[AVS|Creature Shock AVS]]<br />
| [[AVS|AVS video]]<br />
| [[PCM]]<br />
| bgcolor="#FF0000" | fails<br />
| Failed (invalid file format)<br />
| OUTATIME.AVS<br />
| [http://samples.mplayerhq.hu/game-formats/avs/ location]<br />
| January 4, 2007<br />
|-<br />
| [[AVI]]<br />
| [[COL1]]<br />
| ??<br />
| bgcolor="#FF0000" | fails<br />
| Rejected (length of video is too long)<br />
| sample.vid<br />
| [http://samples.mplayerhq.hu/V-codecs/COL1/ location]<br />
| January 4, 2007<br />
|-<br />
| [[AVI]]<br />
| [[CSCD]]<br />
| ??<br />
| bgcolor="#FF0000" | fails<br />
| Failed (unable to convert video file)<br />
| sample_video.avi<br />
| [http://samples.mplayerhq.hu/V-codecs/CSCD/ location]<br />
| January 4, 2007<br />
|-<br />
| [[MOV]]<br />
| [[IV41]]<br />
| ??<br />
| bgcolor="#FF0000" | fails<br />
| Failed ''(no additional information)''<br />
| indeo41.avi<br />
| [http://samples.mplayerhq.hu/V-codecs/IV41/ location]<br />
| January 4, 2007<br />
|-<br />
| [[AVI]]<br />
| [[KMVC]]<br />
| ??<br />
| bgcolor="#FF0000" | fails<br />
| Failed (unable to convert video file)<br />
| LOGO1.AVI<br />
| [http://samples.mplayerhq.hu/V-codecs/KMVC/ location]<br />
| January 4, 2007<br />
|-<br />
| [[MOV]]<br />
| [[PGVV]]<br />
| ??<br />
| bgcolor="#FF0000" | fails<br />
| Failed (unable to convert video file)<br />
| airfone.mov<br />
| [http://samples.mplayerhq.hu/V-codecs/PGVV-RadiusStudio/ location]<br />
| January 4, 2007<br />
|-<br />
| [[Vivo]]<br />
| [[Vivo H.263]]<br />
| [[Vivo Siren]]<br />
| bgcolor="#FF0000" | fails<br />
| Rejected (length of video is too long)<br />
| Sav...lian_version%2529.viv<br />
| [http://samples.mplayerhq.hu/vivo/ location]<br />
| January 4, 2007<br />
|-<br />
| [[MOV]]<br />
| [[3IV2]]<br />
| ??<br />
| bgcolor="#FF0000" | fails<br />
| Rejected (length of video is too long)<br />
| Aqua_...partial.mov<br />
| [http://samples.mplayerhq.hu/V-codecs/3iv2/ location]<br />
| January 4, 2007<br />
|-<br />
| [[Flic Video|Magic Carpet Modified FLIC]]<br />
| [[Flic Video|Modified FLIC]]<br />
| n/a<br />
| bgcolor="#FF0000" | fails<br />
| Failed (invalid file format)<br />
| logo.dat<br />
| [http://samples.mplayerhq.hu/game-formats/magiccarpet-fli/ location]<br />
| January 4, 2007<br />
|-<br />
| [[VMD]]<br />
| [[VMD|VMD video]]<br />
| [[VMD|VMD audio]]<br />
| bgcolor="#FF0000" | fails<br />
| Rejected (length of video is too long)<br />Failed (unable to convert video file)<br />
| phantas-intro-R-rated.vmd<br />swat_3157.vmd<br />
| [http://samples.mplayerhq.hu/game-formats/sierra-vmd/ location]<br />
| January 4, 2007<br />
|-<br />
| [[AVI]]<br />
| [[ZMBV]]<br />
| ??<br />
| bgcolor="#FF0000" | fails<br />
| Failed (unable to convert video file)<br />
| td3_000.avi<br />
| [http://samples.mplayerhq.hu/V-codecs/ZMBV/ location]<br />
| January 4, 2007<br />
|-<br />
| [[American Laser Games MM]]<br />
| [[American Laser Games MM|MM Video]]<br />
| [[PCM]]<br />
| bgcolor="#FF0000" | fails<br />
| Failed (invalid file format)<br />
| scene6.mm<br />
| [http://samples.mplayerhq.hu/game-formats/alg-mm/ location]<br />
| January 4, 2007<br />
|-<br />
| [[FLV]]<br />
| [[On2 VP6]]<br />
| ??<br />
| bgcolor="#FF0000" | fails<br />
| Failed (invalid file format)<br />
| clip1024.flv<br />
| [http://samples.mplayerhq.hu/FLV/flash8/ location]<br />
| January 4, 2007<br />
|-<br />
| [[FLV]]<br />
| [[Flash screen video]]<br />
| ??<br />
| bgcolor="#FF0000" | fails<br />
| Failed (invalid file format)<br />
| screen.flv<br />
| [http://samples.mplayerhq.hu/FLV/flash_screen/ location]<br />
| January 4, 2007<br />
|-<br />
| [[AVI]]<br />
| [[Snow]]<br />
| n/a<br />
| bgcolor="#FF0000" | fails<br />
| Failed (unable to convert video file)<br />
| custom command line <ref name="avi-snow-command-line">'mencoder /dev/urandom -demuxer rawvideo -rawvideo w=320:h=240:fps=24 -frames 120 -ovc lavc -lavcopts vcodec=snow -o test.avi'</ref><br />
| n/a<br />
| January 4, 2007<br />
|-<br />
| [[RealMedia]]<br />
| [[RV40]]<br />
| ??<br />
| bgcolor="#FF0000" | fails<br />
| Rejected (length of video is too long)<br />
| spygames-2MB.rmvb<br />
| [http://samples.mplayerhq.hu/real/VC-RV40/ location]<br />
| January 4, 2007<br />
|-<br />
| [[Bink Container]]<br />
| [[Bink Video]]<br />
| [[Bink Audio]]<br />
| bgcolor="#FF0000" |<br />
| Failed (invalid file format)<br />
| logo_legal.bik<br />
| [http://samples.mplayerhq.hu/game-formats/bink/ location]<br />
| February 9, 2007<br />
<!--<br />
|-<br />
| <br />
| <br />
| <br />
| bgcolor="#FF0000" |<br />
| <br />
| <br />
| [ location]<br />
| January 4, 2007<br />
--><br />
|}<br />
<br />
<references/><br />
<br />
[[Category:Multimedia-related Companies]]</div>
DrV
https://wiki.multimedia.cx/index.php?title=FFmpeg_demuxer_HOWTO&diff=10650
FFmpeg demuxer HOWTO
2008-12-15T05:01:05Z
<p>DrV: libavformat/allformats.h no longer exists; macros in libavformat/allformats.c take care of the externs now</p>
<hr />
<div>: ''please make this page more complete if you can, thanks''<br />
<br />
== registering the demuxer ==<br />
<br />
=== libavformat/allformats.c ===<br />
<br />
Add for a demuxer:<br />
REGISTER_DEMUXER(DEMUXERNAME, demuxername)<br />
<br />
For a muxer:<br />
REGISTER_MUXER(MUXERNAME, muxername)<br />
<br />
The macro will add the _demuxer or whatever is appropriate. '''Run configure in the top level directory and make clean, as config.h will be automatically modified'''.<br />
<br />
make dist-clean<br />
./configure<br />
make<br />
<br />
<br />
=== libavformat/Makefile ===<br />
<br />
Add <br />
OBJS-$(CONFIG_DEMUXERNAME_DEMUXER) += filename.o<br />
<br />
== demuxer code ==<br />
<br />
This section is merely an overview; please look at an actual demuxer to see how to do it.<br />
<br />
=== demuxername_probe ===<br />
<br />
The probe will be called by the framework; this is where you can detect if the file is your format. There should be no dependence on filename, in fact you probably can't even access it. Most video containers start with some constant sequence of bytes. If there are 4 bytes and they are always the same, and unique, then return AVPROBE_SCORE_MAX. Otherwise, return 0. If the format is mis-designed and doesn't have this, divide AVPROBE_SCORE_MAX by something (e.g. 2) to designate limited confidence that the file corresponds to your demuxer.<br />
<br />
=== demuxername_read_header ===<br />
<br />
Here you should get any header information, e.g. the frame width if it is video, the sample rate if it is audio, etc. You should also setup your streams (looking at examples usually explains most things, except perhaps [[presentation timestamp|timestamp]] information); set codec_type, codec_id, and possibly width, height, pix_fmt for video, and channels, sample_rate, bits_per_sample, and bit_rate for audio. return 0.<br />
<br />
=== demuxername_read_packet ===<br />
<br />
Most formats are split into blocks of audio and video. The read_packet function should set up pkt. This involves initializing the packet with av_new_packet, or, preferably, av_get_packet (which also takes the file stream as an argument). After you initialize the packet, you should set (in any order) pos and data (if you used av_new_packet), stream_index (to set which decoder, usually audio or video, to send the packet to, which corresponds to the order you initialized them in), and pts, the presentation timestamp.<br />
<br />
== see also ==<br />
<br />
* [[FFmpeg codec howto]]<br />
* [[FFmpeg programming conventions]]<br />
<br />
[[Category:FFmpeg Tutorials]]<br />
[[Category:Tutorials]]</div>
DrV
https://wiki.multimedia.cx/index.php?title=ART&diff=10311
ART
2008-07-31T04:09:42Z
<p>DrV: width and height</p>
<hr />
<div>* Extension: art<br />
* Company: AOL<br />
* Samples: http://samples.mplayerhq.hu/image-samples/ART/<br />
* Wikipedia page: http://en.wikipedia.org/wiki/ART_image_file_format (has some interesting links)<br />
<br />
ART is an image format used on the America OnLine (AOL) service. The file format originated with a company named Johnson-Grace and was later acquired by AOL. Allegedly, the format is able to employ a number of different compression techniques depending on the characteristics of the image data.<br />
<br />
== File Format ==<br />
<br />
Integers seem to be in little-endian format.<br />
<br />
0x00 ( +2) ASCII characters "JG", likely for Johnson-Grace<br />
...<br />
0x0D ( +2) width<br />
0x0F ( +2) height<br />
<br />
[[Category:Image Formats]]<br />
[[Category:Undiscovered Image Formats]]</div>
DrV
https://wiki.multimedia.cx/index.php?title=FFmpeg_codec_HOWTO&diff=9629
FFmpeg codec HOWTO
2008-03-12T03:50:08Z
<p>DrV: /* libavformat/rm.c */ fix rm demuxer link</p>
<hr />
<div>This page is meant as an introduction to the internal codec API in [[FFmpeg]].<br />
It will also show how the codecs are connected with the demuxers. This is by<br />
no means a complete guide but enough to understand how to add a codec to FFmpeg.<br />
[[RealAudio cook|Cook]] is used as an example throughout.<br />
<br />
== registering the codec ==<br />
<br />
=== libavcodec/avcodec.h ===<br />
The first thing to look at is the AVCodec struct.<br />
<br />
typedef struct AVCodec {<br />
const char *name;<br />
enum CodecType type;<br />
enum CodecID id;<br />
int priv_data_size;<br />
int (*init)(AVCodecContext *);<br />
int (*encode)(AVCodecContext *, uint8_t *buf, int buf_size, void *data);<br />
int (*close)(AVCodecContext *);<br />
int (*decode)(AVCodecContext *, void *outdata, int *outdata_size,<br />
uint8_t *buf, int buf_size);<br />
int capabilities;<br />
struct AVCodec *next;<br />
void (*flush)(AVCodecContext *);<br />
const AVRational *supported_framerates; ///array of supported framerates, or NULL if any, array is terminated by {0,0}<br />
const enum PixelFormat *pix_fmts; ///array of supported pixel formats, or NULL if unknown, array is terminanted by -1<br />
} AVCodec;<br />
<br />
Here we can see that we have some elements to name the codec, what type it is (audio/video), the supported pixel formats and some function<br />
pointers for init/encode/decode and close. Now lets see how it is used.<br />
<br />
=== libavcodec/cook.c ===<br />
If we look in this file at the bottom we can see this code:<br />
<br />
AVCodec cook_decoder =<br />
{<br />
.name = "cook",<br />
.type = CODEC_TYPE_AUDIO,<br />
.id = CODEC_ID_COOK,<br />
.priv_data_size = sizeof(COOKContext),<br />
.init = cook_decode_init,<br />
.close = cook_decode_close,<br />
.decode = cook_decode_frame,<br />
};<br />
<br />
First we get an AVCodec struct named cook_decoder. And then we set the variables of cook_decoder. Note that we only set the variables that are needed. Currently there is no encoder so we don't set any. If we now look at the id variable we can see that CODEC_ID_COOK isn't defined in libavcodec/cook.c. It is declared in avcodec.h.<br />
<br />
=== libavcodec/avcodec.h ===<br />
<br />
Here we will find the CodecID enumeration.<br />
<br />
enum CodecID {<br />
...<br />
CODEC_ID_GSM,<br />
CODEC_ID_QDM2,<br />
CODEC_ID_COOK,<br />
CODEC_ID_TRUESPEECH,<br />
CODEC_ID_TTA,<br />
...<br />
};<br />
<br />
CODEC_ID_COOK is there in the list. This is the list of all supported codecs in FFmpeg, the list is fixed and used internally to id every codec. Changing the order would break binary compatibility.<br />
<br />
This is all enough to declare a codec. Now we must register them for internal use also. This is done at runtime.<br />
<br />
=== libavcodec/allcodecs.c ===<br />
In this file we have the avcodec_register_all() function, it has entries like this for all codecs.<br />
<br />
...<br />
REGISTER_DECODER(COOK, cook);<br />
...<br />
<br />
This macro expands to a register_avcodec() call which registers a codec for internal use.<br />
Note that register_avcodec() will only be called when CONFIG_COOK_DECODER is defined.<br />
This allows to not compile the decoder code for a specific codec.<br />
But where is it defined? This is extracted by configure with this command line:<br />
<br />
sed -n 's/^[^#]*DEC.*, *\(.*\)).*/\1_decoder/p' libavcodec/allcodecs.c<br />
<br />
So adding a REGISTER_DECODER(NEW, new) entry in allcodecs.c and reconfigure is enough to add the needed define. Now we have everything to hookup a codec.<br />
<br />
== FFmpeg demuxer connection ==<br />
<br />
: ''[[FFmpeg demuxer howto]]''<br />
<br />
=== libavformat/rm.c ===<br />
<br />
If we think of an imaginary rm file that ffmpeg is about to process, the first thing that happens is that it is identified<br />
as a rm file. It is passed on to the rm demuxer ([http://svn.mplayerhq.hu/ffmpeg/trunk/libavformat/rmdec.c?view=markup rmdec.c]). The rm demuxer looks through the file and finds out that it is a<br />
cook file.<br />
<br />
...<br />
} else if (!strcmp(buf, "cook")) {<br />
st->codec->codec_id = CODEC_ID_COOK;<br />
...<br />
<br />
Now ffmpeg knows what codec to init and where to send the payload from the container. So back to cook.c and the initialization process.<br />
<br />
== codec code ==<br />
<br />
=== libavcodec/cook.c Init ===<br />
After ffmpeg knows what codec to use, it calls the declared initialization function pointer declared in the codecs AVCodec struct. In<br />
cook.c it is called cook_decode_init. Here we setup as much as we can before we start decoding. The following things should be handled in the init, vlc table initialization, table generation, memory allocation and extradata parsing.<br />
<br />
=== libavcodec/cook.c Close ===<br />
The cook_decode_close function is the codec clean-up call. All memory, vlc tables, etc. should be freed here.<br />
<br />
=== libavcodec/cook.c Decode ===<br />
In cook.c the name of the decode call is cook_decode_frame.<br />
<br />
static int cook_decode_frame(AVCodecContext *avctx,<br />
void *data, int *data_size,<br />
uint8_t *buf, int buf_size) {<br />
...<br />
<br />
The function has 5 arguments:<br />
* avctx is a pointer to an AVCodecContext<br />
* data is the pointer to the output buffer<br />
* data_size is a variable that should be set to the output buffer size in bytes (this is usually the number of samples decoded * the number of channels * the byte size of a sample)<br />
* buf is the pointer to the input buffer<br />
* buf_size is the byte size of the input buffer<br />
<br />
The decode function shall return the number of bytes consumed from the input buffer or -1 in case of an error. If there is no error during decoding, the return value is usually buf_size as buf should only contain one 'frame' of data. Bitstream parsers to split the bitstream into 'frames' used to be part of the codec so a call to the decode function could have consumed less than buf_size bytes from buf. It is now encouraged that bitstream parsers be separate.<br />
<br />
<br />
That's how it works without too much detail.<br />
<br />
=== The Glue codec template ===<br />
The imaginary Glue audio codec will serve as a base to exhibit bitstream reading, vlc decoding and other things.<br />
The code is purely fictional and is sometimes written purely for the sake of example. No attempt is made to prevent invalid<br />
data manipulation.<br />
<br />
The Glue codec follows.<br />
<br />
[http://wiki.multimedia.cx/index.php?title=FFmpeg_codec_howto&oldid=7347 non-colored version]<br />
<br />
<span style="font-style: italic;color: #808080;">/* The following includes have the bitstream reader, various dsp functions and the various defaults */</span><br />
<span style="color: #008000;">#define ALT_BITSTREAM_READER</span><br />
<span style="color: #008000;">#include "avcodec.h"</span><br />
<span style="color: #008000;">#include "bitstream.h"</span><br />
<span style="color: #008000;">#include "dsputil.h"</span><br />
<br />
<span style="font-style: italic;color: #808080;">/* This includes the tables needed for the Glue codec template */</span><br />
<span style="color: #008000;">#include "gluedata.h"</span><br />
<br />
<br />
<span style="font-style: italic;color: #808080;">/* Here we declare the struct used for the codec private data */</span><br />
<span style="font-weight: bold;color: #000000;">typedef</span><span style="color: #000000;"> </span><span style="font-weight: bold;color: #000000;">struct</span><span style="color: #000000;"> {</span><br />
<span style="color: #000000;"> GetBitContext gb;</span><br />
<span style="color: #000000;"> FFTContext fft_ctx;</span><br />
<span style="color: #000000;"> VLC vlc_table;</span><br />
<span style="color: #000000;"> MDCTContext mdct_ctx;</span><br />
<span style="color: #000000;"> </span><span style="color: #800000;">float</span><span style="color: #000000;">* sample_buffer;</span><br />
<span style="color: #000000;">} GLUEContext;</span><br />
<br />
<br />
<span style="font-style: italic;color: #808080;">/* The init function */</span><br />
<span style="color: #800000;">static</span><span style="color: #000000;"> </span><span style="color: #800000;">int</span><span style="color: #000000;"> glue_decode_init(AVCodecContext *avctx)</span><br />
<span style="color: #000000;">{</span><br />
<span style="color: #000000;"> GLUEContext *q = avctx-&gt;priv_data;</span><br />
<br />
<span style="color: #000000;"> </span><span style="font-style: italic;color: #808080;">/* This imaginary codec uses one fft, one mdct and one vlc table. */</span><br />
<span style="color: #000000;"> ff_mdct_init(&amp;q-&gt;mdct_ctx, </span><span style="color: #0000ff;">10</span><span style="color: #000000;">, </span><span style="color: #0000ff;">1</span><span style="color: #000000;">); </span><span style="font-style: italic;color: #808080;">// 2^10 == size of mdct, 1 == inverse mdct</span><br />
<span style="color: #000000;"> ff_fft_init(&amp;q-&gt;fft_ctx, </span><span style="color: #0000ff;">9</span><span style="color: #000000;">, </span><span style="color: #0000ff;">1</span><span style="color: #000000;">); </span><span style="font-style: italic;color: #808080;">// 2^9 == size of fft, 0 == inverse fft</span><br />
<span style="color: #000000;"> init_vlc (&amp;q-&gt;vlc_table, </span><span style="color: #0000ff;">9</span><span style="color: #000000;">, </span><span style="color: #0000ff;">24</span><span style="color: #000000;">,</span><br />
<span style="color: #000000;"> vlctable_huffbits, </span><span style="color: #0000ff;">1</span><span style="color: #000000;">, </span><span style="color: #0000ff;">1</span><span style="color: #000000;">,</span><br />
<span style="color: #000000;"> vlctable_huffcodes, </span><span style="color: #0000ff;">2</span><span style="color: #000000;">, </span><span style="color: #0000ff;">2</span><span style="color: #000000;">, </span><span style="color: #0000ff;">0</span><span style="color: #000000;">); </span><span style="font-style: italic;color: #808080;">// look in bitstream.h for the meaning of the arguments</span><br />
<br />
<span style="color: #000000;"> </span><span style="font-style: italic;color: #808080;">/* We also need to allocate a sample buffer */</span><br />
<span style="color: #000000;"> q-&gt;sample_buffer = av_mallocz(</span><span style="font-weight: bold;color: #000000;">sizeof</span><span style="color: #000000;">(</span><span style="color: #800000;">float</span><span style="color: #000000;">)*</span><span style="color: #0000ff;">1024</span><span style="color: #000000;">); </span><span style="font-style: italic;color: #808080;">// here we used av_mallocz instead of av_malloc</span><br />
<span style="color: #000000;"> </span><span style="font-style: italic;color: #808080;">// av_mallocz memsets the whole buffer to 0</span><br />
<br />
<span style="color: #000000;"> </span><span style="font-style: italic;color: #808080;">/* Check if the allocation was successful */</span><br />
<span style="color: #000000;"> </span><span style="font-weight: bold;color: #000000;">if</span><span style="color: #000000;">(q-&gt;sample_buffer == NULL)</span><br />
<span style="color: #000000;"> </span><span style="font-weight: bold;color: #000000;">return</span><span style="color: #000000;"> -</span><span style="color: #0000ff;">1</span><span style="color: #000000;">;</span><br />
<br />
<span style="color: #000000;"> </span><span style="font-style: italic;color: #808080;">/* return 0 for a successful init, -1 for failure */</span><br />
<span style="color: #000000;"> </span><span style="font-weight: bold;color: #000000;">return</span><span style="color: #000000;"> </span><span style="color: #0000ff;">0</span><span style="color: #000000;">;</span><br />
<span style="color: #000000;">}</span><br />
<br />
<br />
<span style="font-style: italic;color: #808080;">/* This is the main decode function */</span><br />
<span style="color: #800000;">static</span><span style="color: #000000;"> </span><span style="color: #800000;">int</span><span style="color: #000000;"> glue_decode_frame(AVCodecContext *avctx,</span><br />
<span style="color: #000000;"> </span><span style="color: #800000;">void</span><span style="color: #000000;"> *data, </span><span style="color: #800000;">int</span><span style="color: #000000;"> *data_size,</span><br />
<span style="color: #000000;"> uint8_t *buf, </span><span style="color: #800000;">int</span><span style="color: #000000;"> buf_size)</span><br />
<span style="color: #000000;">{</span><br />
<span style="color: #000000;"> GLUEContext *q = avctx-&gt;priv_data;</span><br />
<span style="color: #000000;"> int16_t *outbuffer = data;</span><br />
<br />
<span style="color: #000000;"> </span><span style="font-style: italic;color: #808080;">/* We know what the arguments for this function are from above</span><br />
<span style="font-style: italic;color: #808080;"> now we just have to decode this imaginary codec, the made up</span><br />
<span style="font-style: italic;color: #808080;"> bitstream format is as follows:</span><br />
<span style="font-style: italic;color: #808080;"> 12 bits representing the amount of samples</span><br />
<span style="font-style: italic;color: #808080;"> 1 bit fft or mdct coded coeffs, 0 for fft/1 for mdct</span><br />
<span style="font-style: italic;color: #808080;"> read 13 bits representing the amount of vlc coded fft data coeffs</span><br />
<span style="font-style: italic;color: #808080;"> read 10 bits representing the amount of vlc coded mdct data coeffs</span><br />
<span style="font-style: italic;color: #808080;"> (...bits representing the coeffs...)</span><br />
<span style="font-style: italic;color: #808080;"> 5 bits of dummy data that should be ignored</span><br />
<span style="font-style: italic;color: #808080;"> 32 bits the hex value 0x12345678, used for integrity check</span><br />
<span style="font-style: italic;color: #808080;"> */</span><br />
<br />
<span style="color: #000000;"> </span><span style="font-style: italic;color: #808080;">/* Declare the needed variables */</span><br />
<span style="color: #000000;"> </span><span style="color: #800000;">int</span><span style="color: #000000;"> samples, coeffs, i, fft;</span><br />
<span style="color: #000000;"> </span><span style="color: #800000;">float</span><span style="color: #000000;"> mdct_tmp[</span><span style="color: #0000ff;">1024</span><span style="color: #000000;">];</span><br />
<br />
<span style="color: #000000;"> </span><span style="font-style: italic;color: #808080;">/* Now we init the bitstream reader, we start at the beginning of the inbuffer */</span><br />
<span style="color: #000000;"> init_get_bits(&amp;q-&gt;gb, buf, buf_size*</span><span style="color: #0000ff;">8</span><span style="color: #000000;">); </span><span style="font-style: italic;color: #808080;">//the buf_size is in bytes but we need bits</span><br />
<br />
<span style="color: #000000;"> </span><span style="font-style: italic;color: #808080;">/* Now we take 12 bits to get the amount of samples the current frame has */</span><br />
<span style="color: #000000;"> samples = get_bits(&amp;q-&gt;gb, </span><span style="color: #0000ff;">12</span><span style="color: #000000;">);</span><br />
<span style="color: #000000;"> </span><br />
<span style="color: #000000;"> </span><span style="font-style: italic;color: #808080;">/* Now we check if we have fft or mdct coeffs */</span><br />
<span style="color: #000000;"> fft = get_bits1(&amp;q-&gt;gb);</span><br />
<span style="color: #000000;"> </span><span style="font-weight: bold;color: #000000;">if</span><span style="color: #000000;"> (fft) {</span><br />
<span style="color: #000000;"> </span><span style="font-style: italic;color: #808080;">//fft coeffs, get how many</span><br />
<span style="color: #000000;"> coeffs = get_bits(&amp;q-&gt;gb, </span><span style="color: #0000ff;">13</span><span style="color: #000000;">);</span><br />
<span style="color: #000000;"> } </span><span style="font-weight: bold;color: #000000;">else</span><span style="color: #000000;"> {</span><br />
<span style="color: #000000;"> </span><span style="font-style: italic;color: #808080;">//mdct coeffs, get how many</span><br />
<span style="color: #000000;"> coeffs = get_bits(&amp;q-&gt;gb, </span><span style="color: #0000ff;">10</span><span style="color: #000000;">);</span><br />
<span style="color: #000000;"> }</span><br />
<br />
<span style="color: #000000;"> </span><span style="font-style: italic;color: #808080;">/* Now decode the vlc coded coeffs to the sample_buffer */</span><br />
<span style="color: #000000;"> </span><span style="font-weight: bold;color: #000000;">for</span><span style="color: #000000;"> (i=</span><span style="color: #0000ff;">0</span><span style="color: #000000;"> ; i&lt;coeffs ; i++)</span><br />
<span style="color: #000000;"> q-&gt;sample_buffer[i] = get_vlc2(&amp;q-&gt;gb, q-&gt;vlc_table.table, vlc_table.bits, </span><span style="color: #0000ff;">3</span><span style="color: #000000;">); </span><span style="font-style: italic;color: #808080;">//read about the arguments in bitstream.h</span><br />
<br />
<span style="color: #000000;"> </span><span style="font-style: italic;color: #808080;">/* Now we need to transform the coeffs to samples */</span><br />
<span style="color: #000000;"> </span><span style="font-weight: bold;color: #000000;">if</span><span style="color: #000000;"> (fft) {</span><br />
<span style="color: #000000;"> </span><span style="font-style: italic;color: #808080;">//The fft is done inplace</span><br />
<span style="color: #000000;"> ff_fft_permute(&amp;q-&gt;fft_ctx, (FFTComplex *) q-&gt;sample_buffer);</span><br />
<span style="color: #000000;"> ff_fft_calc(&amp;q-&gt;fft_ctx, (FFTComplex *) q-&gt;sample_buffer);</span><br />
<span style="color: #000000;"> } </span><span style="font-weight: bold;color: #000000;">else</span><span style="color: #000000;"> {</span><br />
<span style="color: #000000;"> </span><span style="font-style: italic;color: #808080;">//And we pretend that the mdct is also inplace</span><br />
<span style="color: #000000;"> ff_imdct_calc(&amp;q-&gt;mdct_ctx, q-&gt;sample_buffer, q-&gt;sample_buffer, mdct_tmp);</span><br />
<span style="color: #000000;"> }</span><br />
<br />
<span style="color: #000000;"> </span><span style="font-style: italic;color: #808080;">/* To make it easy the stream can only be 16 bits mono, so let's convert it to that */</span><br />
<span style="color: #000000;"> </span><span style="font-weight: bold;color: #000000;">for</span><span style="color: #000000;"> (i=</span><span style="color: #0000ff;">0</span><span style="color: #000000;"> ; i&lt;samples ; i++)</span><br />
<span style="color: #000000;"> outbuffer[i] = (int16_t)q-&gt;sample_buffer[i];</span><br />
<br />
<span style="color: #000000;"> </span><span style="font-style: italic;color: #808080;">/* Report how many samples we got */</span><br />
<span style="color: #000000;"> *data_size = samples;</span><br />
<br />
<span style="color: #000000;"> </span><span style="font-style: italic;color: #808080;">/* Skip the dummy data bits */</span><br />
<span style="color: #000000;"> skip_bits(&amp;q-&gt;gb, </span><span style="color: #0000ff;">5</span><span style="color: #000000;">);</span><br />
<br />
<span style="color: #000000;"> </span><span style="font-style: italic;color: #808080;">/* Check if the buffer was consumed ok */</span><br />
<span style="color: #000000;"> </span><span style="font-weight: bold;color: #000000;">if</span><span style="color: #000000;"> (get_bits(&amp;q-&gt;gb,</span><span style="color: #0000ff;">32</span><span style="color: #000000;">) != </span><span style="color: #008080;">0x12345678</span><span style="color: #000000;">) {</span><br />
<span style="color: #000000;"> av_log(avctx,AV_LOG_ERROR,</span><span style="color: #dd0000;">"Stream error, integrity check failed!</span><span style="color: #ff00ff;">\n</span><span style="color: #dd0000;">"</span><span style="color: #000000;">);</span><br />
<span style="color: #000000;"> </span><span style="font-weight: bold;color: #000000;">return</span><span style="color: #000000;"> -</span><span style="color: #0000ff;">1</span><span style="color: #000000;">;</span><br />
<span style="color: #000000;"> }</span><br />
<br />
<span style="color: #000000;"> </span><span style="font-style: italic;color: #808080;">/* Return the amount of bytes consumed if everything was ok */</span><br />
<span style="color: #000000;"> </span><span style="font-weight: bold;color: #000000;">return</span><span style="color: #000000;"> *data_size*</span><span style="font-weight: bold;color: #000000;">sizeof</span><span style="color: #000000;">(int16_t);</span><br />
<span style="color: #000000;">}</span><br />
<br />
<br />
<span style="font-style: italic;color: #808080;">/* the uninit function, here we just do the inverse of the init */</span><span style="color: #000000;"> </span><br />
<span style="color: #800000;">static</span><span style="color: #000000;"> </span><span style="color: #800000;">int</span><span style="color: #000000;"> glue_decode_close(AVCodecContext *avctx)</span><br />
<span style="color: #000000;">{</span><br />
<span style="color: #000000;"> GLUEContext *q = avctx-&gt;priv_data;</span><br />
<br />
<span style="color: #000000;"> </span><span style="font-style: italic;color: #808080;">/* Free allocated memory buffer */</span><br />
<span style="color: #000000;"> av_free(q-&gt;sample_buffer);</span><br />
<br />
<span style="color: #000000;"> </span><span style="font-style: italic;color: #808080;">/* Free the fft transform */</span><br />
<span style="color: #000000;"> ff_fft_end(&amp;q-&gt;fft_ctx);</span><br />
<br />
<span style="color: #000000;"> </span><span style="font-style: italic;color: #808080;">/* Free the mdct transform */</span><br />
<span style="color: #000000;"> ff_mdct_end(&amp;q-&gt;mdct_ctx);</span><br />
<br />
<span style="color: #000000;"> </span><span style="font-style: italic;color: #808080;">/* Free the vlc table */</span><br />
<span style="color: #000000;"> free_vlc(&amp;q-&gt;vlc_table);</span><br />
<br />
<span style="color: #000000;"> </span><span style="font-style: italic;color: #808080;">/* Return 0 if everything is ok, -1 if not */</span><br />
<span style="color: #000000;"> </span><span style="font-weight: bold;color: #000000;">return</span><span style="color: #000000;"> </span><span style="color: #0000ff;">0</span><span style="color: #000000;">;</span><br />
<span style="color: #000000;">}</span><br />
<br />
<br />
<span style="color: #000000;">AVCodec glue_decoder =</span><br />
<span style="color: #000000;">{</span><br />
<span style="color: #000000;"> .name = </span><span style="color: #dd0000;">"glue"</span><span style="color: #000000;">,</span><br />
<span style="color: #000000;"> .type = CODEC_TYPE_AUDIO,</span><br />
<span style="color: #000000;"> .id = CODEC_ID_GLUE,</span><br />
<span style="color: #000000;"> .priv_data_size = </span><span style="font-weight: bold;color: #000000;">sizeof</span><span style="color: #000000;">(GLUEContext),</span><br />
<span style="color: #000000;"> .init = glue_decode_init,</span><br />
<span style="color: #000000;"> .close = glue_decode_close,</span><br />
<span style="color: #000000;"> .decode = glue_decode_frame,</span><br />
<span style="color: #000000;">};</span><br />
<br />
== see also ==<br />
<br />
* [[FFmpeg demuxer howto]]<br />
* [[FFmpeg programming conventions]]<br />
<br />
[[Category:FFmpeg Tutorials]]<br />
[[Category:Tutorials]]</div>
DrV
https://wiki.multimedia.cx/index.php?title=Psygnosis_YOP&diff=9578
Psygnosis YOP
2008-03-04T06:50:49Z
<p>DrV: /* File Format */ spelling</p>
<hr />
<div>* Extension: yop<br />
* Company: [[Psygnosis]]<br />
* Samples: http://samples.mplayerhq.hu/game-formats/yop/<br />
<br />
YOP is an [[FMV]] video format used in the computer game [http://www.mobygames.com/game/city-of-lost-children The City of the Lost Children] by Psygnosis. The format uses very primitive pattern-based video compression and stock [[IMA ADPCM]] sound encoding.<br />
<br />
== File Format ==<br />
<br />
A YOP file begins with the following 2048-bytes header:<br />
<br />
+ 0 word Signature -- "YO"<br />
+ 2 byte Unknown_2 -- unused, but set to 1. Perhaps format version<br />
+ 3 byte Unknown_3 -- unused, can be either 0 or 1. Format version minor?<br />
+ 4 word NumFrames -- number of frames<br />
+ 6 byte Unknown_6 -- framerate?<br />
+ 7 byte FrameSize -- size of the single frame chunk in sectors (2048 bytes per sector)<br />
+ 8 word Width -- frame width<br />
+ A word Height -- frame height<br />
+ C byte PalColors -- number of colors in palette per frame '''see notes'''<br />
+ D byte FirstColor1 -- first color to update for odd frames (counting from 1)<br />
+ E byte FirstColor2 -- first color to update for even frames (counting from 1)<br />
+ F byte Unknown_C[3] -- unused/zero<br />
+ 12 word SoundLen -- size of the audio block for frame<br />
+ 14 byte Unknown_14[] -- unknown/unused/padding to the next sector's boundary<br />
+800 FRAME Frames[NumFrames] -- video frames<br />
<br />
For each frame:<br />
+ 0 dword Unknown_0 -- unused/ignored, some length?<br />
+ 4 RGB Palette[PalColors] -- palette part for this frame, 6 bits per component<br />
+xxx byte Sound[SoundLen] -- ADPCM-encoded sound data, mono, 22050Hz, 1840 samples per frame<br />
+yyy byte Video[...] -- encoded video data, variable length<br />
+zzz byte Padding[...] -- unused/padding<br />
---- total frame size is FrameSize * 2048<br />
<br />
===Notes===<br />
<br />
* All multi-byte numbers are little-endian.<br />
* Both file header and each frame chunk are aligned/padded to 2048-byte boundaries.<br />
* Frame chunks have a fixed size (FrameSize * 2048), even if the actual payload size is much smaller.<br />
* Each frame comes with its own palette part, updating PalColors entries starting from FirstColor1 for odd and FirstColor2 for even frames respectively.<br />
* The IMA ADPCM audio decoding context (predictor and step index) is initialized to zero at the beginning of the playback and maintained across successive frames.<br />
<br />
== Video Compression ==<br />
A video frame is broken into 2x2 macroblocks and each macroblock is decoded using the following algorithm:<br />
<br />
tag = next nibble<br />
tag is:<br />
0 : abcd<br />
1 : abca<br />
2 : abcb<br />
3 : abcc<br />
4 : abac<br />
5 : abaa<br />
6 : abab<br />
7 : abbc<br />
8 : aabc<br />
9 : aaba<br />
A : abba<br />
B : aabb<br />
C : aaab<br />
D : aaaa<br />
E : abbb<br />
F : read next tag and copy previously drawn block located at the following coordinates (in pixels) relative to the current block:<br />
tag is:<br />
0 : -4:-4<br />
1 : -2:-4<br />
2 : 0:-4<br />
3 : 2:-4<br />
4 : -4:-2<br />
5 : -4: 0<br />
6 : -3:-3<br />
7 : -1:-3<br />
8 : 1:-3<br />
9 : 3:-3<br />
A : -3:-1<br />
B : -2:-2<br />
C : 0:-2<br />
D : 2:-2<br />
E : 4:-2<br />
F : -2: 0<br />
<br />
* abcc means "read byte a and use it to paint pixel 1 (top left), read byte b and paint pixel 2 (top right), read byte c and paint pixel 3 (bottom left) ''and'' pixel 4 (bottom right)".<br />
* Tags are 4-bit nibbles, processed starting from the high one (bits 4..7), then lower (bits 0..3). However, complete bytes are consumed from the bytesteam, thus pixel bytes do not overlap with the tags.<br />
<br />
[[Category:Game Formats]]<br />
[[Category:Video Codecs]]<br />
[[Category:Formats missing in FFmpeg]]</div>
DrV
https://wiki.multimedia.cx/index.php?title=Talk:Bink_Container&diff=6743
Talk:Bink Container
2007-01-09T19:56:27Z
<p>DrV: </p>
<hr />
<div>Original:<br />
bytes 28-31 video frames per second<br />
bytes 32-35 image format<br />
<br />
Suggested:<br />
bytes 28-35 video frames per second in a/b format (real number)<br />
bytes 28-31 a<br />
bytes 32-35 b<br />
<br />
<br />
I noticed numbers like:<br />
6025/201<br />
2997/100<br />
Both are very close to 30 (a usual framerate for videos)<br />
<br />
<br />
There is another error in the optional audio header:<br />
Original:<br />
bytes 44-45 audio channels (1 or 2)<br />
bytes 46-47 unknown<br />
<br />
Suggested:<br />
bytes 44-45 unknown (but somehow related to samplerate)<br />
bytes 46-47 audio channels (1 or 2)<br />
<br />
* The framerate correction is indeed right. --[[User:VAG|VAG]] 19:23, 25 December 2006 (EST)<br />
<br />
I'm not sure the audio sample rate is quite correct. I get slightly strange values like 44000 (logo_lucas.bik) and 22500 (AnivisionLogo.bik) on some of the samples provided, although I get sensible ones like 44100 (original.bik) on others... I'm not an audio expert by any means, but it seems strange that these values are so close to multiples of common audio sample rates and yet not equal to them. --[[User:DrV|DrV]] 00:25, 6 January 2007 (EST)<br />
<br />
Isn't it 22050? That would be half of 44100 :) And probably because it is mono. I could be mistaken...<br />
<br />
* Yes, 22050 and 44100 would be the ones I'd expect to see, but some of the files contain ones close to those but not equal. --[[User:DrV|DrV]]</div>
DrV
https://wiki.multimedia.cx/index.php?title=Talk:Bink_Container&diff=6722
Talk:Bink Container
2007-01-06T05:25:17Z
<p>DrV: </p>
<hr />
<div>Original:<br />
bytes 28-31 video frames per second<br />
bytes 32-35 image format<br />
<br />
Suggested:<br />
bytes 28-35 video frames per second in a/b format (real number)<br />
bytes 28-31 a<br />
bytes 32-35 b<br />
<br />
<br />
I noticed numbers like:<br />
6025/201<br />
2997/100<br />
Both are very close to 30 (a usual framerate for videos)<br />
<br />
<br />
There is another error in the optional audio header:<br />
Original:<br />
bytes 44-45 audio channels (1 or 2)<br />
bytes 46-47 unknown<br />
<br />
Suggested:<br />
bytes 44-45 unknown (but somehow related to samplerate)<br />
bytes 46-47 audio channels (1 or 2)<br />
<br />
* The framerate correction is indeed right. --[[User:VAG|VAG]] 19:23, 25 December 2006 (EST)<br />
<br />
I'm not sure the audio sample rate is quite correct. I get slightly strange values like 44000 (logo_lucas.bik) and 22500 (AnivisionLogo.bik) on some of the samples provided, although I get sensible ones like 44100 (original.bik) on others... I'm not an audio expert by any means, but it seems strange that these values are so close to multiples of common audio sample rates and yet not equal to them. --[[User:DrV|DrV]] 00:25, 6 January 2007 (EST)</div>
DrV
https://wiki.multimedia.cx/index.php?title=Bink_Container&diff=6668
Bink Container
2007-01-03T18:39:23Z
<p>DrV: fix offset of 'audio channels' field in header</p>
<hr />
<div>''This page is based on the document 'Description of the Bink File Format' by Mike Melanson at [http://multimedia.cx/bink-format.txt http://multimedia.cx/bink-format.txt].''<br />
<br />
* Extenstions: bik<br />
* Company: [[RAD Game Tools]]<br />
* Samples: [http://samples.mplayerhq.hu/game-formats/bink/ http://samples.mplayerhq.hu/game-formats/bink/], countless video games<br />
<br />
Bink files are multimedia files used in a variety of video games, both on personal computers platforms and video game consoles. The files act as containers for data compressed with the proprietary [[Bink Video|Bink video]] and [[Bink Audio|audio]] codecs. Bink multimedia files are known to bear the .bik extension.<br />
<br />
== File Format ==<br />
<br />
'''This description is known to be incomplete.'''<br />
<br />
All multi-byte numbers are stored in little endian format.<br />
<br />
Bink files appear to start with a 56-byte header which is laid out as follows:<br />
<br />
bytes 0-2 file signature ('BIK')<br />
byte 3 possibly a file version number (e.g., 0x68, 0x69)<br />
bytes 4-7 file size not including the first 8 bytes<br />
bytes 8-11 number of frames<br />
bytes 12-15 largest frame size in bytes<br />
bytes 16-19 number of frames again?<br />
bytes 20-23 video width<br />
bytes 24-27 video height<br />
bytes 28-31 video frames per second<br />
bytes 32-35 image format<br />
bytes 36-39 unknown<br />
bytes 40-43 audio flag: if 0, header ends; if 1, header continues;<br />
bytes 44-45 unknown<br />
bytes 46-47 audio channels (1 or 2)<br />
bytes 48-49 audio sample rate<br />
bytes 50-55 unknown<br />
<br />
Following the header is a sample offset table. The number of entries in the table is equal to the number of samples specified in the header. Each entry consists of a 32-bit absolute offset for that sample. There is no length information, so the length of a sample is implicitly the difference between sample offsets. One frame contains both audio and video data (if both are present it the file). Bytes 12-15 (largest frame size) probably exist to provide the playback application with the largest single buffer it will have to allocate.<br />
<br />
[[Category:Container Formats]]<br />
[[Category:Game Formats]]</div>
DrV