MultimediaWiki - User contributions [en]

SIFF

2007-10-15T18:44:26Z

Roberto: Link to samples

* Extentions: vb, son
* Samples: http://samples.mplayerhq.hu/game-formats/SIFF/

Certain PC games developed by [[Beam Software]] use a multimedia format with the file signature 'SIFF'. The format can transport audio and video (which are .vb files) or just audio (which are .son files).

== File Format ==

The general fourcc chunk format is as follows:

bytes 0-3 chunk type
bytes 4-7 chunk size (not including 8-byte chunk preamble and usually in MSB format)
bytes 8.. chunk payload

It is important to note that in the fourcc chunk preamble, the size field is big-endian. However, all other multi-byte numbers in the file are little-endian.

A VB file begins with a 'SIFF' file signature, followed by the total length of the file, minus 8 bytes. Bytes 8-11 contain the version fourcc, e.g. 'VBV1'. Then comes the header, which is laid out as follows:

bytes 0-3 header fourcc ('VBHD')
bytes 4-7 header length (should be 32 == 0x20)
bytes 8-9 unknown, but might be header version
bytes 10-11 video width
bytes 12-13 video height
bytes 14-17 zeroes
bytes 18-19 number of frames
bytes 20-21 bits per audio sample?
bytes 22-23 audio sample rate
bytes 24-39 zeroes

All data is stored in 'BODY' chunk in blocks. Block format:

bytes 0-3 block size (with header)
bytes 4-5 flags
bytes 6.. block payload

Flags meaning:

bit 0 - frame has global motion vector
bit 2 - block contains audio
bit 3 - block contains video
bit 4 - palette change
bit 5 - block has frame duration

Global motion vector is stored as two signed words.

Palette change data:

byte 0 - start index
byte 1 - number of entries to change
bytes 2.. - RGB entry, 3 bytes per entry

=== Video Frame Format ===

Frame is divided into 4x4 blocks. Block type is stored in two bits, which are grouped into one byte for four consequent blocks.

Block types:
* 0 - skip block
* 1 - motion compensated block, next byte contains motion vector (with values -8..7). If motion vector is zero then block is uncompressed and its data is contained in the next 16 bytes.
* 2 - block is filled with color stored in the next byte
* 3 - pattern fill, pattern method and value is stored in the next byte.

Pattern type (for block type 3) is stores in high two bits, pattern index is stored in 6 low bits. Pattern type meanings:
* 0 - read 2 bytes and paint block with them
* 1 - read one bytes and paint only pixels where pattern bit is zero
* 2 - read one bytes and paint only pixels where pattern bit is one
* 3 - invalid value

Motion compensation may wrap, i.e. pixels from the previous or next line may be read.

There are 64 possible patterns:

0x0660, 0xFF00, 0xCCCC, 0xF000, 0x8888, 0x000F, 0x1111, 0xFEC8,
0x8CEF, 0x137F, 0xF731, 0xC800, 0x008C, 0x0013, 0x3100, 0xCC00,
0x00CC, 0x0033, 0x3300, 0x0FF0, 0x6666, 0x00F0, 0x0F00, 0x2222,
0x4444, 0xF600, 0x8CC8, 0x006F, 0x1331, 0x318C, 0xC813, 0x33CC,
0x6600, 0x0CC0, 0x0066, 0x0330, 0xF900, 0xC88C, 0x009F, 0x3113,
0x6000, 0x0880, 0x0006, 0x0110, 0xCC88, 0xFC00, 0x00CF, 0x88CC,
0x003F, 0x1133, 0x3311, 0xF300, 0x6FF6, 0x0603, 0x08C6, 0x8C63,
0xC631, 0x6310, 0xC060, 0x0136, 0x136C, 0x36C8, 0x6C80, 0x324C

== Games That Use The SIFF Format ==

* [http://www.mobygames.com/game/windows/kknd2-krossfire KKND2: Krossfire]
* [http://www.mobygames.com/game/dos/norse-by-norse-west-the-return-of-the-lost-vikings The Lost Vikings II] (a.k.a. Norse By Norse West: The Return of the Lost Vikings)
[[Category:Game Formats]]

Quotes

2007-09-30T22:16:30Z

Roberto: /* #mplayerdev */

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!

==IRC Channels==

===#mplayerdev===

<pre>
<ods15> btw, gcc took 900mb of ram and then segfaulted for me when i tried to compile a 30mb C file :P
<ods15> that took about 20 minutes until it evantually gave out of mem error
<ods15> i should probably just write my own compiler than can do it in 0.05s and no ram...
<ShadowJK> can tcc compile it :)
<ods15> ShadowJK, heh i should've tried that
* ods15 just makes a sample file and tries now
<ods15> ahem, it did it in like 3 seconds and no ram :P
</pre>

<pre>
<poirierg> great new ppl! I'm likely to get laid before linuxtag!
<poirierg> woops
<ods15> ...
<poirierg> great new ppl! I'm likely to get laid out before linuxtag!
<dalias> lol poirierg
<poirierg> budget cuts and stuff like that....
<dalias> poirierg, oh
<dalias> i read that as 'get laid'
<dalias> and i was like wtf tmi
<ods15> ja
<dalias> the word is 'laid off' btw, not 'laid out'
<delewis> haha.
<ods15> so, wait, great?
<poirierg> okay, I'm getting laid off
</pre>

<pre>
<ods15> british is american with a sloppy accent, and much stupider curse words
</pre>

<pre>
<poirierg> cartman, you don't see smart girls if you only watch pr0n
</pre>

<pre>
<superdump> Welcome to ye Olde #mplayerdev Tavern. If yaoi 'n' free cola is what ye be lookin' far, we's got 'em! Yarr...
</pre>

<pre>
<dalias> because you can't use x264
<superdump> why not?
<dalias> because the decoder is slower than gabu trying to get a girlfriend
</pre>

<pre>
<dalias> h264 is like matroska
<dalias> yes mmatroska is better than avi but it sucks still
<dalias> hes h264 compresses better than mpeg4 but it sucks still
<dalias> and the question is: is 15% compression gain worth 500% performance drop?
</pre>

<pre>
<poirierg> do you know the difference between God and dalias ? ;)
<dalias> god only tells you what's bad to do when you inhale from a burning bush
<dalias> dalias tells you what's bad all the time
</pre>

<pre>
<reynaldo> i was once atacked by one of those beast
<reynaldo> i was 4 years old iirc
<reynaldo> those birds have almost 4 meters measured from the extremes of their wings
<reynaldo> i have some stories you wouldnt believe :P
<reynaldo> i dont remember meeting any chilean atacked by a condor besides me
<reynaldo> :P
<reynaldo> i was once biten by a black widow too :P extremely hard to find spider
<reynaldo> nature has been trying to kill me since the day i born!
<reynaldo> :P
<iive> i though condors doesn't attack humans.
<reynaldo> they dont
<reynaldo> thats the weirdest part
<reynaldo> :P
<iive> well, then there is only one explanetion. you are not human.
* iive runs
<reynaldo> :P
<reynaldo> who knows
<reynaldo> maybe the karaoke filter is just the begining of my world domination plan
</pre>

<pre>
<reynaldo> why dont you work with me improving the filter then ?
<poirierg> reynaldo, because I don't want to steel the paternity of your little toy
<reynaldo> thats not my boy
<reynaldo> everyone an his girlfriend facing the same problem solved it the same wahy
<reynaldo> we can make something neater
<reynaldo> :)
<poirierg> your are calling me to become the girlfriend of you audio filter?
</pre>

<pre>
<ods15> i'm waiting for someone to send me brains tommorrow, not much to do until then
</pre>

<pre>
<snacky> h264-in-mpeg is standardized since 2003. if hd-dvd does it differently it's because they're stupid ;)
<iive> they do. thay are
</pre>

<pre>
<KotH> Rathann: some nice quotes you have there :)
<Rathann> I know! ^_^
<Rathann> I've been collecting them for months
<KotH> and some i dont even remember typing ^^'
<Rathann> ^_^v
<Rathann> hehe
<Rathann> it's good to have logs
</pre>

<pre>
<phcoder> compiling svn:
<phcoder> allcodecs.c: In function 'avcodec_register_all':
<phcoder> allcodecs.c:67: error: 'ENABLE_DCA_DECODER' undeclared (first use in this function)
<phcoder> allcodecs.c:67: error: (Each undeclared identifier is reported only once
<phcoder> allcodecs.c:67: error: for each function it appears in.)
<phcoder> allcodecs.c:253: error: 'ENABLE_DCA_PARSER' undeclared (first use in this function)
<phcoder> Sorry forgot to configure
<KotH> dont forget make distclean
<Rathann> don't forget to use your brain
</pre>

<pre>
<DonDiego> geez
<DonDiego> how many mistakes can you make in a single line of shell ..
<KotH> one per character
<DonDiego> i'm quite close ;)
<DonDiego> sundays after parties are not the best days for programming ;)
</pre>

<pre>
<cartman> <poirierg> cartman, you don't see smart girls if you only watch pr0n
<dalias> :)
<cartman> this is all I get for reporting quality pr0n bugs
<dalias> cartman, it's what you get for making statements about girls being stupid
<cartman> dalias: girls are stupid anyway
</pre>

<pre>
<ShadowJK> "I have to agree with Rich's supposed opinion here. It is beyond mad."
<ShadowJK> dalias, you've become quite efficient at flamewars, when you don't even need
to participate anymore, people just assume what you were going to say :)
</pre>

<pre>
<iive> btw does somebody know a way to get the xvid bitstream syntax number
<iive> the number that xvid put to identify what bugs they had when encoding it.
<Rathann> rtfs?
<iive> i ask if somebody knows
<iive> this is if nobody knows
<iive> fucker
<rxt> hehe, nothing changed on mplayer while I was away :)
</pre>

<pre>
<snacky> ugh... you guys should see how polite superdump is being to lusers on #ffmpeg . it's really disgusting
<superdump> :)
<snacky> what is it with polite people?! don't you realize you are making the rest of us look bad?
</pre>

<pre>
<KotH> i talked with an ubuntu guy here
<KotH> and the biggest problem they have is that upstream is uncooperative
<Rathann> is it?
<KotH> from their perspective yes
<Rathann> I haven't seen any patches from anyone @ubuntu
<Rathann> nor bugreports, for that matter
<KotH> well, replace upstream by downstream and you get the same in green
</pre>

<pre>
<KotH> the biggest outcome of a 2h+ discussion was that both sites want to work with each other, but think it's impossible
<Rathann> why do they think we're uncooperative?
<Rathann> (obviously we aren't)
<KotH> well... have a look at our history
<ShadowJK> Obviously uncooperative. Refusing to integrate with gstreamer, copying libraries
randomly into source tree, breaking compilation with gcc2.96 on purpose, stuff doesn't compile with PIC, etc etc ;)
<KotH> yeah.. these points come into play too
<KotH> but that's a longer story
...
<ShadowJK> You know, I don't think those MPlayer developers even go to church of Xiph every
week to worship a speedy emergence of Tarkin and ogm as the world dominating system
</pre>

<pre>
<KotH> anyone here who has an understanding of x11?
<ods15> it shows graphics :P
<KotH> yeah, right
</pre>

<pre>
<uau> i was already a better coder than most existing developers when i got involved with mplayer
</pre>

===#mplayer===

<pre>
* KotH wants a point and click solution... w/o the click
</pre>

<pre>
<Micksa> I'm reading about motion compensation
<Micksa> some of this is serious voodoo
<Micksa> I love it :)
</pre>

<pre>
<dtm> you're a free software pimp, Commn
</pre>

<pre>
<Jan_> mplayer has a number of command line options that is large enough to overflow a 32-bit variable.
</pre>

<pre>
<iive> Commn: yeh.. usa people usually have problem with foregin languages like british, australian or canadian. :)
</pre>

<pre>
<CarlFK> how many gig is an hour of raw DV ?
<DogBoy> like from a porno?
<CarlFK> right
<DogBoy> just how raw are we talking
<CarlFK> right from the cam corder's firewire
</pre>

<pre>
<dtm> Commn: i read all of your wiki page and you forgot the final entry for "and seek professional
help immediately for the mental illness that either
1) made you want to follow all these steps for lazy, codependent fools on irc or
2) that you WILL HAVE after faithfully trying to implement all these steps for a week"
<dtm> http://mfrost.typepad.com/photos/uncategorized/gaaallllgh.jpg that big dog is the cumulative laziness of a lot
of irc users the medium sized cat is Commn and the one watching, frozen in horror, is me
<dtm> now is that a normal response for a cat who has a self preservation instinct? i think not.
<dtm> HE LIKES IT!
<Commn> dtm : haha how long did it take to find that picture?
<dtm> Commn: somebody gave it to me and i kept it in a firefox tab all week coz it's so awesome coz
I KNEW IT WOULD HAVE A GREAT PURPOSE
<dtm> Commn: since you asked for feedback, i'll say that you're extraordinarily diligent and conscientious, and
the minority of that content is directly relevant to mplayer, and the majority is relevant to a "how to ask
questions the smart way" type of document if not being totally redundant thereof
<dtm> you are a gentleman and a scholar, and true patriot
<sacarasc> dtm is cute when he is adoring someone
<Commn> dtm : yes, its a modified 'how to ask questions' docu
<Commn> its lame tho
<Commn> i might delete it
<Rathann> dtm is such a clear case of user-support-induced insanity that I wonder why I am still sane sometimes...
</pre>

<pre>
<pianoboy3333> how long does mplayer take to compile?
<dtm> how long til the Point of Know Return?
<pianoboy3333> ...
<dtm> i'm sorry, was that question not as dumb as yours? oh well i tried!
<dtm> <3
<iive> dtm: you are starting to sound like me.
<dtm> Hmmmm.
* dtm commits honorable ninja suicide
</pre>

<pre>
<Erb> Does anyone know how to launch the GUI MPlayer in Linux via PHP (in Firefox)? I can run MPlayer scripts
in the background fine. I only need to do this for local videos for an application I'm building.
* dtm throws his brain into a blender in an attempt to comprehend Erb's question but fails sadly
</pre>

<pre>
<dtm> tell me what i want to know, and nobody gets hurst.
<dtm> hurt.
<Rathann> o_O
<dtm> i'm feeling like the giant cactus wants to be plastered in ascii screenshots
<dtm> I MUST COMPLY
<dtm> HELP ME DO THIS, Rathann
</pre>

<pre>
<DazBrum> what is the channel for developers
<-- DazBrum has quit ()
<dtm> lols
<dtm> i think i'll spare them from that
</pre>

<pre>
<netstat> how come mplayer eating memory
<netstat> it uses up to 90% cpu
<dtm> must be a good movie
</pre>

<pre>
<cappicard> o/~ Ich versteh euch nicht! o/~
<dtm> i'm sorry cappicard i dont speak satanic
<cappicard> LOL
<cappicard> it's just German
<dtm> yeah but not when they're singing it.
<cappicard> heh :)
<iive> cappicard: isn't it the same
</pre>

<pre>
<gioele> How come that I get a 35 minutes MP3 from a 5 minutes FLV video with -dumpaudio?
<Compn> aliens beaming audio into your mp3
<spuck00> ^^
<gioele> Compn: time to call SETI?
<Compn> yep
<Compn> if the aliens are peaceful, say hello
<Compn> if they are aggressive, look out!
</pre>

<pre>
* richard___ wonders why so many people join this channel for no apparent purpose
<rsk> they share the love of mplayer ;-(
<sacarasc> i have a purpose
<richard___> I wasn't implying that there's anything wrong with it :)
</pre>

<pre>
<rms> please tell me how to use dd_rescue
<KotH> RTFM
<rms> and what special will it do, except regular copy?
<KotH> RTFM
<rms> RTFM?
<KotH> the manual says everything oyu need to know
<KotH> read the fucking manual
<rms> oh ok
</pre>

<pre>
<iive> -dumpvideo
<LinuxCart> umm, that's a good idea. i'll try that.
<LinuxCart> thank you iive
<KotH> LinuxCart: if in doubt, it's iive's fault ;)
</pre>

<pre>
<LinuxCart> how could this be explained?
<iive> it just another of dv misteries
<iive> it's KotH fault.
</pre>

<pre>
<LinuxMafia> how can i turn on language and sub
<KotH> RTFM
<LinuxMafia> KotH, using debian or freebsd?
<KotH> LinuxCart: doesnt matter, the FM is OS idenpedent
<LinuxCart> KotH: is RTFM some dialect to say it's iive fault :P
</pre>

<pre>
<ChaosR> MPlayer 1.0rc1-4.1.2-DFSG-free <- my version
<ChaosR> is it out of date
<mjunx> of course
<mjunx> if it wasn't built like within an hour ago at any given time, it's usually out of date
</pre>

<pre>
<Fatsobob> trying to get mplayer to play win32 on ubuntu makes me want to shoot myself
<Fatsobob> mostly because ubuntu is all "totem this" and "totem that"
</pre>

<pre>
<Quintin> Is there any reason to use opengl vo device?
<sacarasc> nope
<Quintin> what's it there for?
<sacarasc> because you might want to use it...
...
<reimar> sacarasc: is there any reason why I should think what you just said makes sense? ;-)
<sacarasc> reason and what people want are not always the same
</pre>

<pre>
<Commn> iive : dont call mplayer users dumb
<Commn> not to their faces anyhow
</pre>

<pre>
<Agiofws> has anyone tried cinerella ?
<Agiofws> i think it great
<Kunalagon> I tried , and I thin 80 % does not work
<MisT_> never get compiled here
<Kunalagon> it has more bugs than my shelter
</pre>

<pre>
<voltagex> ArneB: at one stage I was able to do the maths to crack CSS on paper :P
...
<ArneB> voltagex: Obviously your mind and paper are illegal.
<ArneB> Better hand them over to the MPAA.
<voltagex> I think you could sneeze and accidentally crack CSS
<voltagex> yep
<voltagex> no more pencils
</pre>

<pre>
<danny500> how do I convert a ogm file into an mpeg file using mencoder?
<danny500> anyone>
<danny500> hello?
<danny500> ?
<danny500> help
<BenrA> mencoder -of mpeg -oac lavc -ovc lavc -lavcopts vcodec=mpeg2video -o foo.mpg foo.ogm
<danny500> ?
<BenrA> If you want quality and/or DVD compatibility or anything, consult the docs. ;)
<danny500> ok that was confusing
<danny500> file equals = file:///home/danny500/Trigun/Trigun%20-%201%20-%20The%20%24%2460%20Billion%20Man
<danny500> now, rewrite that code so that It'll work
<danny500> well then?
<BenrA> What is your problem?
<housetier> I'd try replacing "foo.ogm" with /home/danny500/Trigun/Trigun%20-%201%20-%20The%20%24%2460%20Billion%20Man
(if that is the real file name), and see how far it goes
<danny500> fine then, don't help me, I'll go to a room where I'll actually get help. Fucking assholes
</pre>

<pre>
<crackedboy> hi, can I ask something about kmplayer?
<md`> no
<crackedboy> ok, sorry
<md`> you're forgiven
</pre>

<pre>
<CHodapp> I have a program that's basically just generating RGB data for a framebuffer.
<CHodapp> I'm having major issues figuring out how to get this data to an encoded video.
<CHodapp> ffmpeg seems to only want some particular kind of YUV
<CHodapp> can I make mencoder handle raw RGB or raw YUV or anything like that?
<Commn> its easier to get it working with mplayer, to see what options you need
<Commn> mplayer file -demuxer rawvideo -vc rawbgr16
<Commn> etc
<Commn> then you can do mencoder with those opts
<Commn> or maybe even mplayer -vo yuv4mpeg , which ffmpeg probably accepts
<Commn> maybe even use a named pipe... mkfifo stream.yuv && ffmpeg -i stream.yuv -options ...
<CHodapp> ugh, documentation is so sparse on stuff like this
<CHodapp> ugh, why is this such a pain in the ass, with everything
<CHodapp> hrm, maybe rawrgb24 is what I need
<Commn> what part is sparse?
<Commn> if you tell us, we can improve mplayer docs
<CHodapp> well, not so much in mplayer as everything else I've tried... I was mostly searching on
the web to get some clue of how I'd convert what kind of raw input to encoded output
<Commn> mplayer -vc help|grep raw
<Commn> will show what raw codecs mplayer has
<CHodapp> Yeah, I just now found that
<CHodapp> blah . . . Cannot find codec matching selected -vo and .video format 0x30323449.
<Commn> CHodapp : try -vc +rawrgb32 or whatnot
<Commn> just add + in front of it
<CHodapp> then it says the selected video_out device is incompatible with this codec
<CHodapp> tried sdl and x11
<Commn> if you can make a small sample of your file
<Commn> dd if=input of=output count=3 bs=1024k
<Commn> i can try to get it working in mplayer
<CHodapp> you might as well just take 640*480*3*100 bytes of data from /dev/urandom and try
that... it will be functionally equivalent
<CHodapp> I'm using this right now: mplayer -rawvideo w=640:h=480 -demuxer rawvideo -vc +rawrgb24 -vo sdl temp.rgb
<Commn> whats random got to do with it ?
<CHodapp> it's just a bunch of bytes, completely unorganized, and mplayer needs to know the resolution
<CHodapp> it doesn't care about the contents
<CHodapp> something else is wrong, otherwise I'd be getting something on the screen
<Commn> if you give me some file i can help
<Commn> otherwise its hard to debug from here ;p
<CHodapp> www.uc.edu/~hodappcm/temp2.rgb
<CHodapp> not the most coherent video, but you won't find that out unless you get something on the screen
<CHodapp> it's 320x240, 10 frames worth
<Commn> what program generates it ?
<CHodapp> just something I'm writing. it's all procedural.
<Commn> i'm trying to remember why it defaults to i420
<CHodapp> i420? like yuv?
<Commn> ya
<CHodapp> definitely shouldn't be yuv...
<Commn> i know, mplayer -rawvideo is defaulting to that
<CHodapp> hmm
<CHodapp> still no output?
<Commn> CHodapp : something like this didnt work ? ffmpeg -f rawvideo -pix_fmt rgb24
<CHodapp> couldn't find codec parameters...
<CHodapp> wait, I forgot the size
<Commn> haha more static
<CHodapp> what commandline did you use?
<Commn> ffplay -f rawvideo -pix_fmt rgb24 -s 320x240 temp2.rgb
<CHodapp> wonder if my endianness is wrong...
<Commn> is it black frames ?
<Commn> ffplay -f rawvideo -pix_fmt bgr32 -s 320x240 temp2.rgb
<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
<Commn> CHodapp : there is an app on that page which generates rgb data
<CHodapp> yeah...
<CHodapp> by the way, I just sent you data from /dev/urandom
</pre>

<pre>
<Jan-> Just so you know, you do realise, the reason we're after using mplayer is because it's f@&^@ng brilliant.
<Jan-> It plays, as they say, *.
<Jan-> It'd play a bucket of cornflour if you painted the word "MOVIE" on it.
</pre>

==Mailing lists==

===[http://lists.mplayerhq.hu/mailman/listinfo/mplayer-cvslog mplayer-cvslog]===

<pre>
> btw, anyone has a copy of the ISO-english spec? ;)

Ok. :)

1. There isn't a spec, since the language hasn't been standardized. All
we have are numerous competing drafts written by independent,
non-authoritative organizations.

2. A large amount of existing English code, such as Shakespeare, is
unparseable by modern English speakers.

3. If an element of the language has been frequently misused over a long
enough period of time, such misuse often becomes acceptable.

4. An English speaker can be considered reasonably feature-complete even
if such speaker only recognizes a small subset of the language.

5. Certain keywords tend to cause internal compiler errors. Such
keywords are known as "profanity", and existing English speakers weakly
attempt to prevent recently-written speakers from being aware of them.

6. English is a highly context dependent. Many keywords, when used in
their own particular context, take on an entirely illogical meaning.
These "idioms" cause compilation errors, especially when an old speaker
is attempting to communicate with a new one.

7. ....

I could go on, but that's enough fun for now. :)
-- Michael Niedermayer and Corey Hickey in mplayer-cvslog at mplayerhq.hu
</pre>

===[http://lists.mplayerhq.hu/mailman/listinfo/mplayer-dev-eng mplayer-dev-eng]===

<pre>
Without a frontend, mplayer is useless.
-- Jean-Philippe Guillemin in mplayer-dev-eng at mplayerhq.hu
</pre>

<pre>
[about alsa resampler]
Now why on earth would anyone want to use this crap?? It's only
configurable between two extremes of sucking: very bad quality, or
very bad performance.
-- Rich Felker in mplayer-dev-eng at mplayerhq.hu
</pre>

<pre>
Reinventing the wheel certainly is annoying, but as long as all other
wheels are square...

Reimar Döffinger
</pre>

<pre>
On Thu, Aug 24, 2006 at 01:10:18PM -0400, Dave Dodge wrote:
> IA64 compilation is an ongoing research project.

Which is what leaves me always wondering where on earth (or actually far
away from earth) Intel engineers left their brains when designing
IA64...
Technology for the next century. As in we will get it to work properly
somewhen in the next century...

Reimar Döffinger
</pre>

===[http://lists.mplayerhq.hu/mailman/listinfo/mplayer-users mplayer-users]===

<pre>
> > yes, video decoding is not perfect either so even if u decode the bitstream u
> > loose quality (idct inaccuracies and such) so u should really use a hexeditor
> > instead of mplayer to view ur movies
>
> Perhaps we could rewrite xmatrix so it takes its input from AVI
> files...

"Do you always look at it encoded?"

"Well ya have to. The video codecs work FOR the construct program. But
there's way too much information to decode this DIVX. You get used to
it -- I don't even see the code. All I see is blonde, brunette,
redhead..."
-- Michael Niedermayer, Moritz Bunkus and D Richard Felker III in mplayer-users at mplayerhq.hu
</pre>

<pre>
>>> Is there any possibility to convert a Ream Media video stream to
>>> ogg/theora video?
>>
>> no, ogg is banned for good from the list of possible outputs for
>> manifest insanity
>
> Thank you for your answer, but can you be more specific?

ogg is by far the most insane mux format ever conceived,
thus no conscious coder wants to permit to give birth to an abomination
like that
-- Marek Mahut and Nico Sabbi in mplayer users at mplayerhq.hu
</pre>

<pre>
> > > 1. ok, true, I wanted to say mad TAG right ? How can I get this
> > > to MP3 tag ?
> >
> > There is no such thing as a MAD tag. MAD only plays MP1/MP2/MP3.
> > Your file has to have one of those as the audio track for MAD to be
> > able to play it at all. You also didn't read the rest of my post.
>
> MAD audio codec then ?

...

I'd love to help, but I have to go bang my head against that wall over
there...
-- wim delvaux and RC in mplayer-users at mplayerhq.hu
</pre>

<pre>
Tobias Damisch wrote:
> Guillaume Poirier wrote:
> > MPlayer still lacks "fairies" support to invent the pixels in between,
> > needed to get a truly HD picture.
>
> Just get latest SVN and recompile with:
>
> --enable-fairies
>
> Then try adding -vf fscale=1600:1200 (or any other resolution you
> might desire) to your command line.

Gentoo's latest mplayer ebuild is apparently an SVN snapshot from
08/10/2006 and doesn't seem to include a fairies USE flag for
compilation. Was fairies support added after that date, or is the
ebuild missing a USE flag?

Grant
</pre>

===[http://lists.mplayerhq.hu/mailman/listinfo/ffmpeg-cvslog ffmpeg-cvslog]===

<pre>
>> I'm sure Michael knows how to capitalize and punctuate at
>> least a little bit.
> thats defamation, ive never capitalized and punktuated correctly
> besides that i dont like pure capitalism ;)
I NEVER ASKED YOU TO WRITE LIKE THIS.
-- Måns Rullgård and Michael Niedermayer in ffmpeg-cvslog at mplayerhq.hu
</pre>

<pre>
Michael Niedermayer CVS <michael@mplayerhq.hu>

Modified Files:
ffmpeg-doc.texi
Log Message:
split string to avoid buffer overflow in native english speaking persons (fix suggested by The Wanderer)
</pre>

<pre>
On Mon, Dec 26, 2005 at 09:57:36PM +0100, Alexander Strasser wrote:
> Oh, I just saw it was in the original mail. I must have
> accidently deleted it while writing the answer. Sorry for
> the trouble.

no problem at all, better to ask then to miss some typos by the CIA/KGB guys
who edit all my outgoing and incoming mails

Michael
</pre>

===[http://lists.mplayerhq.hu/mailman/listinfo/ffmpeg-devel ffmpeg-devel]===

<pre>
> All right, new screening process for prospective FFmpeg contributors:
> "Are you now, or have you ever been, a Microsoft Visual C++ user?"
> There's going to be scandal when the oversight committee investigates my
> employment history.
If you used msvc on your day job it doesn't count, as long as you really hated it.
-- Mike Melanson and Måns Rullgård in ffmpeg-devel at mplayerhq.hu
</pre>

<pre>
> patching file configure
> Hunk #1 FAILED at 914.
> 1 out of 1 hunk FAILED -- saving rejects to file configure.rej
Ah, yes, the swift evolution of ffmpeg made the patch obsolete in 24h.
-- Måns Rullgård and Víctor Paesa in ffmpeg-devel at mplayerhq.hu
</pre>

<pre>
[about the lack of "chained ogg" support]
I'm aware of this problem, and I've been trying to think of a
solution. The more I think about it, the more it appears as an
abomination. Just like everything Ogg related. No surprises there.
-- Måns Rullgård in ffmpeg-devel at mplayerhq.hu
</pre>

<pre>
not everything from OO is necessarily bad, like not everything from M$
is necessarily bad, if later where the case M$ would gone bankrupt long
ago ...
but thats geting deeply off topic, lets rather concentrate on flames and
insults ...
-- Michael Niedermayer in ffmpeg-devel at mplayerhq.hu
</pre>

<pre>
[Marco Gerards submits a THP demuxer]
Coooool. I have hundreds of THP files. I will find some that have sound
and get them posted soon. In the meantime, Niedermayer will be along
shortly to tear apart your patch. Good luck! :)
-- Mike Melanson in ffmpeg-devel at mplayerhq.hu
</pre>

<pre>
[about SwScaler rewrite]
> > And then we can call an architecture dependent init function that can
> > overide the C behavior much like is done for the dsputils.
> I was thinking about that too
thinking is good patch is better ...
-- Marc Hoffman, Luca Barbato and Michael Niedermayer in ffmpeg-devel at mplayerhq.hu
</pre>

<pre>
On Sun, Jan 15, 2006 at 06:27:55PM +0100, Reimar Döffinger wrote:
>
> Oh, and the image of my RE drawing is up as well :-) :
> http://www.stud.uni-karlsruhe.de/~uvhe/LZODraw_bw.png

Thank goodness your coding skills are better than your handwriting ;)

Diego
</pre>

<pre>
On Thu, Sep 22, 2005 at 10:51:05AM +0200, oandrieu@gmail.com wrote:
> Michael Niedermayer [Wednesday 21 September 2005] :
> > cosmetics
>
> Yes. And ?

sorry, i should have been more verbose, maybe i should be restarted with -v
can someone of the admin(s) do that?

Michael
</pre>

<pre>
as far as i can see this AVI file has _many_ video frames in each chunk, sick
how can a person be capable of using a text editor (and writing software) and
at the same time be such a complete idiot writing a program generating so
broken avi files ...

Michael
</pre>

<pre>
michaels law: "if gcc can mess up, it does mess up" ;)
</pre>

<pre>
> >> + "psllw $1, %%mm1 \n\t"
> >> + "psllw $1, %%mm2 \n\t"
> >
> > paddw
>
> Is that always faster?

no, you can design a cpu where its not

Michael
</pre>

<pre>
if you think that this patch will be accepted due to you whining how much
time you spend on it already then you live in some strange fantasy world
-- Michael Niedermayer in ffmpeg-devel at mplayerhq.hu
</pre>

<pre>
Rich, I always knew you were a little out of the ordinary, but
pirating gay porn wasn't quite what I was expecting even from you.
-- Måns Rullgård in ffmpeg-devel at mplayerhq.hu
</pre>

<pre>
[after a discussion of a patch with a new audio decoder evolved into
runtime generation of tables vs. hardcoding them in the object file debate]

what is the name of this bikeshed?
-- compn
</pre>

===[http://lists.mplayerhq.hu/mailman/listinfo/nut-devel NUT-devel]===

<pre>
We should have some nut samples.
Someone, (not me, I am lazy), should mux some free video and
audio into NUT (or just grab a camera and film something funny
like what happens with an egg in the microwave or something
else where A-V sync can be seen).

Michael
</pre>

<pre>
A "spec" as readable as a sendmail configuration file doesn't make
matters better...

Måns Rullgård
</pre>

===other===

<pre>
i've remembered i have root access at new mphq, but probably
it was just a dream :)))
-- A'rpi
</pre>

<pre>
FFmpeg works like a human being: something nice comes in, crap comes out.
-- superdump on an S-Bahn train in Berlin
(written from memory, please fix)
</pre>

RealMedia

2006-12-25T22:10:49Z

Roberto: audio/x-ralf-mpeg4 mimetype

* Extensions: rm, ra, rmvb
* Company: [[Real]]
* Specifications: https://common.helixcommunity.org/nonav/2003/HCS_SDK_r5/htmfiles/rmff.htm

Multimedia container format developed by [[Real]] and used almost exclusively for codecs developed by [[Real]].

The old .ra files are just for audio. The newer RealMedia (.rm) files are for audio and video.

== RA Format ==

This is the old audio-only RealAudio file format.
A very similar structure is also used to describe audio streams in RM files.

The audio data part is just a stream of bytes with no structure.
There is no index in .ra files, but seeking is possible because the codecs are CBR.

=== RealAudio 1.0 file (.ra version 3) ===

This is from the very first version of RealAudio (1995). These files can only contain [[RealAudio 14.4|8kbps VSELP]] audio data. A [[FourCC]] (lpcJ) may be present, but it is ignored. Byte order is big-endian.

byte[4] Header signature ('.', 'r', 'a', 0xfd)
word Version (always 3)
word Header size, not including first 8 bytes
byte[10] Unknown
dword Data size
byte Title string length
byte[] Title string
byte Author string length
byte[] Author string
byte Copyright string length
byte[] Copyright string
byte Comment string length
byte[] Comment string
byte Unknown *
byte Fourcc string length (always 4) *
byte[] Fourcc string (always "lpcJ") *
Audio data

Notes:
* Fields marked with * may be missing. Based on the only known sample with no [[FourCC]], it's assumed that all these fields are either present or missing. To determine if they are missing, check the header size (bytes 6-7).
* The informative fields (title, author, copyright and comment) can have zero length.

=== RealAudio 2.0 file (.ra version 4) ===

This is second version of the RealAudio file format. It is distinguished from the above by the value in byte 5 (=0x04). This type of file must contain a valid [[FourCC]] to identify the audio codec.

Possible [[FourCC]] values are [[RealAudio 28.8|28_8]], [[RealAudio_dnet|dnet]] and [[RealAudio_sipr|sipr]].

byte[4] Header signature ('.', 'r', 'a', 0xfd)
word Version (always 4)
word Unused (always 0)
byte[4] ra4 signature (always ".ra4")
dword Data size - 0x27
word Version2 (always equal to version)
dword Header size - 16
word Codec flavor
dword Coded frame size
byte[12] Unknown
word Sub packet h
word Frame size
word Subpacket size
word Unknown
word Samplerate
word Unknown
word Sample size
word Channels
byte Interleaver ID string length (always 4)
byte[] Interleaver ID string
byte [[FourCC]] string length (always 4)
byte[] [[FourCC]] string
byte[3] Unknown
byte Title string length
byte[] Title string
byte Author string length
byte[] Author string
byte Copyright string length
byte[] Copyright string
byte Comment string length
byte[] Comment string
Audio Data

Notes:
* The 0x27 in data size is the size of the fixed-length part of the header (up to channels).
* The informative fields (title, author, copyright and comment) can have zero length.

=== .ra version 5 ===

While the .ra header can contain version 5, there are no known RealAudio files with this format, and it's not known if they really exist.

== RealMedia Format ==

This is the newer format which stores both audio and video. All multi-byte numbers are stored in big-endian format.

A RealMedia file consists of a series of chunks. Each chunk has the following format:

dword chunk type ([[FOURCC]])
dword chunk size, including 8-byte preamble
word chunk version
byte[] chunk payload

Real chunk types:
* .RMF: RealMedia file header (only one per file, must be the first chunk)
* PROP: File properties (only one per file)
* MDPR: Stream properties (one for each stream)
* CONT: Content description/metadata (typically one per file)
* DATA: File data
* INDX: File index (typically one per stream)

=== RealMedia file header (.RMF) ===

This must be the first chunk in a RealMedia file. Only one .RMF can be present in a file. The only useful information carried by .RMF is the number of headers.

A .RMF chunk has the following format

dword chunk type ('.RMF')
dword chunk size (typically 0x12)
word chunk version (always 0, for every known file)
dword file version
dword number of headers

Notes:
* All known sample files have version equal to 0.
* There is a sample with chunk size = 0x10, in that case file version is a word. Note that the sample has chunk version = 0 like all other files.

=== File properties header (PROP) ===

This chunk contains some information about the general properties of a RealMedia file. Only one PROP chunk can be present in a file.

A PROP chunk has the following format

dword Chunk type ('PROP')
dword Chunk size (typically 0x32)
word Chunk version (always 0, for every known file)
dword Maximum bit rate
dword Average bit rate
dword Size of largest data packet
dword Average size of data packet
dword Number of data packets in the file
dword File duration in ms
dword Suggested number of ms to buffer before starting playback
dword Offset of the first INDX chunk form the start of the file
dword Offset of the first DATA chunk form the start of the file
word Number of streams in the file
word Flags (bitfield, see below)

Flags:
* bit 0: file can be saved on disk
* bit 1: PerfectPlay can be used (extra buffering)
* bit 2: the file is a live broadcast

=== Media properties header (MDPR) ===

This chunk contains information about the properties of a RealMedia stream. This header defines the type of a stream and the codec used. All codec-related data is in the type specific part of this header.

Many fields share the same meanings as the ones in PROP chunk, but in this case they are specific for one stream.

There is one MDPR chunk for every stream in the file.

A MDPR chunk has the following format

dword Chunk type ('MDPR')
dword Chunk size
word Chunk version (always 0, for every known file)
word Stream number
dword Maximum bit rate
dword Average bit rate
dword Size of largest data packet
dword Average size of data packet
dword Stream start offset in ms
dword Preroll in ms (to be subtracted from timestamps?)
dword Stream duration in ms
byte Size of stream description string
byte[] Stream description string
byte Size of stream mime type string
byte[] Mime type string
dword Size of type specific part of the header
byte[] Type specific data, meaning and format depends on mime type

==== Audio (audio/) ====

===== audio/x-pn-realaudio and audio/x-pn-multirate-realaudio =====
These mimetypes are used to specify streams with RealAudio codecs. There are 3 known versions of this datablock: ra3, ra4, ra5. ra3 is used only with the old 14_4 codec, ra4 and ra5 can be used with all the other codecs.

The audio block has this format

byte[4] Header signature ('.', 'r', 'a', 0xfd)
word Version (3, 4 or 5)
#if version == 3
word Header size, not including first 8 bytes
byte[10] Unknown
dword Data size
byte Title string length
byte[] Title string
byte Author string length
byte[] Author string
byte Copyright string length
byte[] Copyright string
byte Comment string length
byte[] Comment string
byte Unknown *
byte Fourcc string length (always 4) *
byte[] Fourcc string (always "lpcJ") *
#elseif version == 4 or version == 5
word Unused (always 0)
byte[4] ra signature (".ra4" or ".ra5", depending on version)
dword Unknown (maybe data size)
word Version2 (always equal to version)
dword Header size
word Codec flavor
dword Coded frame size
byte[12] Unknown
word Sub packet h
word Frame size
word Subpacket size
word Unknown
#if version == 5
byte[6] Unknown
#endif
word Samplerate
word Unknown
word Sample size
word Channels
#if version == 4
byte Interleaver ID string length (always 4)
byte[] Interleaver ID string
byte [[FourCC]] string length (always 4)
byte[] [[FourCC]] string
#endif
#if version == 5
dword Interleaver ID
dword [[FourCC]]
#endif
byte[3] Unknown
#if version == 5
byte Unknown
#endif
dword Codec extradata length
byte[] Codec extradata
#endif

===== audio/X-MP3-draft-00 =====
This is used to store MP3 audio in rm container.
When this mimetype is used the type-specific part of the MDPR header is not used, and its length is set to 0.

The MP3 frames are stored in ADU format (see RFC 3119 for details) with no interleaving (at least this is true in the only known sample).

===== audio/x-ralf-mpeg4 =====
This is used to store [[Real Lossless Codec|ralf]] lossless audio. This is the only known RealAudio codec that does not use the x-pn-realaudio mimetype.

The format of this type-specific data is not known.

=== Content description header (CONT) ===

This chunk contains some text information (like title, author, ...) about the content of the file. This header has an informative purpose only and it's not needed to demux the file.

A CONT chunk has the following format

dword Chunk type ('CONT')
dword Chunk size
word Chunk version (always 0, for every known file)
word Title string length
byte[] Title string
word Author string length
byte[] Author string
word Copyright string length
byte[] Copyright string
word Comment string length
byte[] Comment string

=== Data header (DATA) ===

This chunk contains a group of data packets. Packets from each stream are interleaved, except for multirate files.

A DATA chunk has the following format

dword Chunk type ('DATA')
dword Chunk size
word Chunk version (always 0, for every known file)
dword Number of data packets in this chunk
dword Offset of the next DATA chunk (form the start of the file)
byte[] Data packets

Each data packet has this format

word Packet version (0 or 1 in available samples)
word Packet size
word Stream number
dword Timestamp (in ms)
byte Unknown
byte Flags (bitfield, see below)
#if version == 1
byte Unknown
#endif
byte[] Stream-specific data

Flags:
* bit 0: reliable packet (refers to network transmission method)
* bit 1: keyframe

Note:
The previous description of the data packet comes from working demuxer code, the description in official [[Real]] docs (somewhere on [[Helix]] site) is a bit different:

word Packet version
word Packet size
word Stream number
dword Timestamp
#if version == 0
byte Packet group
byte Flags
#endif
#if version == 1
word ASM rule
byte ASM flags
#endif
byte[] Stream-specific data

where packet group is "The packet group to which the packet belongs. If packet grouping is not used, set this field to 0 (zero)", asm rule is "The ASM rule assigned to this packet" and asm flags "Contains HX_ flags that dictate stream switching points".

=== Index header (INDX) ===

This chunk contains index entries. It comes after all the DATA chunks.
An index chunk contains data for a single stream, A file can have more than one INDX chunk.

A INDX chunk has the following format

dword Chunk type ('INDX')
dword Chunk size
word Chunk version (always 0, for every known file)
dword Number of entries in this chunk
word Stream number
dword Offset of the next INDX chunk (form the start of the file)
byte[] Index entries

Each index entry has this format

word Entry version (always 0, for every known file)
dword Timestamp (in ms)
dword Packet offset in file (form the start of the file)
dword Packet number

== Codecs ==

Codecs in RealMedia are identified by the following four character codes:

===== Audio =====

* [[RealAudio 14.4|lpcJ]] - RealAudio 1.0 (VSELP)
* [[RealAudio 28.8|28_8]] - RealAudio 2.0 (LD-CELP)
* [[RealAudio_dnet|dnet]] - AC3
* [[RealAudio_sipr|sipr]] - Sipro
* [[RealAudio_cook|cook]] - Cook
* [[RealAudio_atrc|atrc]] - ATRAC
* [[Real Lossless Codec|ralf]] - RealAudio Lossless Format
* [[RealAudio_raac|raac]] - LC-AAC
* [[RealAudio_racp|racp]] - HE-AAC

===== Video =====

* [[RealVideo|RV10]] - H.263
* [[RealVideo|RV13]] - H.263
* [[RealVideo G2|RV20]] - H.263+
* [[RealVideo 3|RV30]] - Unknown format
* [[RealVideo 4|RV40]] - Unknown format

[[Category: Container Formats]]

RealMedia

2006-12-25T21:51:40Z

Roberto: audio/X-MP3-draft-00 mimetype

* Extensions: rm, ra, rmvb
* Company: [[Real]]
* Specifications: https://common.helixcommunity.org/nonav/2003/HCS_SDK_r5/htmfiles/rmff.htm

Multimedia container format developed by [[Real]] and used almost exclusively for codecs developed by [[Real]].

The old .ra files are just for audio. The newer RealMedia (.rm) files are for audio and video.

== RA Format ==

This is the old audio-only RealAudio file format.
A very similar structure is also used to describe audio streams in RM files.

The audio data part is just a stream of bytes with no structure.
There is no index in .ra files, but seeking is possible because the codecs are CBR.

=== RealAudio 1.0 file (.ra version 3) ===

This is from the very first version of RealAudio (1995). These files can only contain [[RealAudio 14.4|8kbps VSELP]] audio data. A [[FourCC]] (lpcJ) may be present, but it is ignored. Byte order is big-endian.

byte[4] Header signature ('.', 'r', 'a', 0xfd)
word Version (always 3)
word Header size, not including first 8 bytes
byte[10] Unknown
dword Data size
byte Title string length
byte[] Title string
byte Author string length
byte[] Author string
byte Copyright string length
byte[] Copyright string
byte Comment string length
byte[] Comment string
byte Unknown *
byte Fourcc string length (always 4) *
byte[] Fourcc string (always "lpcJ") *
Audio data

Notes:
* Fields marked with * may be missing. Based on the only known sample with no [[FourCC]], it's assumed that all these fields are either present or missing. To determine if they are missing, check the header size (bytes 6-7).
* The informative fields (title, author, copyright and comment) can have zero length.

=== RealAudio 2.0 file (.ra version 4) ===

This is second version of the RealAudio file format. It is distinguished from the above by the value in byte 5 (=0x04). This type of file must contain a valid [[FourCC]] to identify the audio codec.

Possible [[FourCC]] values are [[RealAudio 28.8|28_8]], [[RealAudio_dnet|dnet]] and [[RealAudio_sipr|sipr]].

byte[4] Header signature ('.', 'r', 'a', 0xfd)
word Version (always 4)
word Unused (always 0)
byte[4] ra4 signature (always ".ra4")
dword Data size - 0x27
word Version2 (always equal to version)
dword Header size - 16
word Codec flavor
dword Coded frame size
byte[12] Unknown
word Sub packet h
word Frame size
word Subpacket size
word Unknown
word Samplerate
word Unknown
word Sample size
word Channels
byte Interleaver ID string length (always 4)
byte[] Interleaver ID string
byte [[FourCC]] string length (always 4)
byte[] [[FourCC]] string
byte[3] Unknown
byte Title string length
byte[] Title string
byte Author string length
byte[] Author string
byte Copyright string length
byte[] Copyright string
byte Comment string length
byte[] Comment string
Audio Data

Notes:
* The 0x27 in data size is the size of the fixed-length part of the header (up to channels).
* The informative fields (title, author, copyright and comment) can have zero length.

=== .ra version 5 ===

While the .ra header can contain version 5, there are no known RealAudio files with this format, and it's not known if they really exist.

== RealMedia Format ==

This is the newer format which stores both audio and video. All multi-byte numbers are stored in big-endian format.

A RealMedia file consists of a series of chunks. Each chunk has the following format:

dword chunk type ([[FOURCC]])
dword chunk size, including 8-byte preamble
word chunk version
byte[] chunk payload

Real chunk types:
* .RMF: RealMedia file header (only one per file, must be the first chunk)
* PROP: File properties (only one per file)
* MDPR: Stream properties (one for each stream)
* CONT: Content description/metadata (typically one per file)
* DATA: File data
* INDX: File index (typically one per stream)

=== RealMedia file header (.RMF) ===

This must be the first chunk in a RealMedia file. Only one .RMF can be present in a file. The only useful information carried by .RMF is the number of headers.

A .RMF chunk has the following format

dword chunk type ('.RMF')
dword chunk size (typically 0x12)
word chunk version (always 0, for every known file)
dword file version
dword number of headers

Notes:
* All known sample files have version equal to 0.
* There is a sample with chunk size = 0x10, in that case file version is a word. Note that the sample has chunk version = 0 like all other files.

=== File properties header (PROP) ===

This chunk contains some information about the general properties of a RealMedia file. Only one PROP chunk can be present in a file.

A PROP chunk has the following format

dword Chunk type ('PROP')
dword Chunk size (typically 0x32)
word Chunk version (always 0, for every known file)
dword Maximum bit rate
dword Average bit rate
dword Size of largest data packet
dword Average size of data packet
dword Number of data packets in the file
dword File duration in ms
dword Suggested number of ms to buffer before starting playback
dword Offset of the first INDX chunk form the start of the file
dword Offset of the first DATA chunk form the start of the file
word Number of streams in the file
word Flags (bitfield, see below)

Flags:
* bit 0: file can be saved on disk
* bit 1: PerfectPlay can be used (extra buffering)
* bit 2: the file is a live broadcast

=== Media properties header (MDPR) ===

This chunk contains information about the properties of a RealMedia stream. This header defines the type of a stream and the codec used. All codec-related data is in the type specific part of this header.

Many fields share the same meanings as the ones in PROP chunk, but in this case they are specific for one stream.

There is one MDPR chunk for every stream in the file.

A MDPR chunk has the following format

dword Chunk type ('MDPR')
dword Chunk size
word Chunk version (always 0, for every known file)
word Stream number
dword Maximum bit rate
dword Average bit rate
dword Size of largest data packet
dword Average size of data packet
dword Stream start offset in ms
dword Preroll in ms (to be subtracted from timestamps?)
dword Stream duration in ms
byte Size of stream description string
byte[] Stream description string
byte Size of stream mime type string
byte[] Mime type string
dword Size of type specific part of the header
byte[] Type specific data, meaning and format depends on mime type

==== Audio (audio/) ====

===== audio/x-pn-realaudio and audio/x-pn-multirate-realaudio =====
These mimetypes are used to specify streams with RealAudio codecs. There are 3 known versions of this datablock: ra3, ra4, ra5. ra3 is used only with the old 14_4 codec, ra4 and ra5 can be used with all the other codecs.

The audio block has this format

byte[4] Header signature ('.', 'r', 'a', 0xfd)
word Version (3, 4 or 5)
#if version == 3
word Header size, not including first 8 bytes
byte[10] Unknown
dword Data size
byte Title string length
byte[] Title string
byte Author string length
byte[] Author string
byte Copyright string length
byte[] Copyright string
byte Comment string length
byte[] Comment string
byte Unknown *
byte Fourcc string length (always 4) *
byte[] Fourcc string (always "lpcJ") *
#elseif version == 4 or version == 5
word Unused (always 0)
byte[4] ra signature (".ra4" or ".ra5", depending on version)
dword Unknown (maybe data size)
word Version2 (always equal to version)
dword Header size
word Codec flavor
dword Coded frame size
byte[12] Unknown
word Sub packet h
word Frame size
word Subpacket size
word Unknown
#if version == 5
byte[6] Unknown
#endif
word Samplerate
word Unknown
word Sample size
word Channels
#if version == 4
byte Interleaver ID string length (always 4)
byte[] Interleaver ID string
byte [[FourCC]] string length (always 4)
byte[] [[FourCC]] string
#endif
#if version == 5
dword Interleaver ID
dword [[FourCC]]
#endif
byte[3] Unknown
#if version == 5
byte Unknown
#endif
dword Codec extradata length
byte[] Codec extradata
#endif

===== audio/X-MP3-draft-00 =====
This is used to store MP3 audio in rm container.
When this mimetype is used the type-specific part of the MDPR header is not used, and its length is set to 0.

The MP3 frames are stored in ADU format (see RFC 3119 for details) with no interleaving (at least this is true in the only known sample).

=== Content description header (CONT) ===

This chunk contains some text information (like title, author, ...) about the content of the file. This header has an informative purpose only and it's not needed to demux the file.

A CONT chunk has the following format

dword Chunk type ('CONT')
dword Chunk size
word Chunk version (always 0, for every known file)
word Title string length
byte[] Title string
word Author string length
byte[] Author string
word Copyright string length
byte[] Copyright string
word Comment string length
byte[] Comment string

=== Data header (DATA) ===

This chunk contains a group of data packets. Packets from each stream are interleaved, except for multirate files.

A DATA chunk has the following format

dword Chunk type ('DATA')
dword Chunk size
word Chunk version (always 0, for every known file)
dword Number of data packets in this chunk
dword Offset of the next DATA chunk (form the start of the file)
byte[] Data packets

Each data packet has this format

word Packet version (0 or 1 in available samples)
word Packet size
word Stream number
dword Timestamp (in ms)
byte Unknown
byte Flags (bitfield, see below)
#if version == 1
byte Unknown
#endif
byte[] Stream-specific data

Flags:
* bit 0: reliable packet (refers to network transmission method)
* bit 1: keyframe

Note:
The previous description of the data packet comes from working demuxer code, the description in official [[Real]] docs (somewhere on [[Helix]] site) is a bit different:

word Packet version
word Packet size
word Stream number
dword Timestamp
#if version == 0
byte Packet group
byte Flags
#endif
#if version == 1
word ASM rule
byte ASM flags
#endif
byte[] Stream-specific data

where packet group is "The packet group to which the packet belongs. If packet grouping is not used, set this field to 0 (zero)", asm rule is "The ASM rule assigned to this packet" and asm flags "Contains HX_ flags that dictate stream switching points".

=== Index header (INDX) ===

This chunk contains index entries. It comes after all the DATA chunks.
An index chunk contains data for a single stream, A file can have more than one INDX chunk.

A INDX chunk has the following format

dword Chunk type ('INDX')
dword Chunk size
word Chunk version (always 0, for every known file)
dword Number of entries in this chunk
word Stream number
dword Offset of the next INDX chunk (form the start of the file)
byte[] Index entries

Each index entry has this format

word Entry version (always 0, for every known file)
dword Timestamp (in ms)
dword Packet offset in file (form the start of the file)
dword Packet number

== Codecs ==

Codecs in RealMedia are identified by the following four character codes:

===== Audio =====

* [[RealAudio 14.4|lpcJ]] - RealAudio 1.0 (VSELP)
* [[RealAudio 28.8|28_8]] - RealAudio 2.0 (LD-CELP)
* [[RealAudio_dnet|dnet]] - AC3
* [[RealAudio_sipr|sipr]] - Sipro
* [[RealAudio_cook|cook]] - Cook
* [[RealAudio_atrc|atrc]] - ATRAC
* [[Real Lossless Codec|ralf]] - RealAudio Lossless Format
* [[RealAudio_raac|raac]] - LC-AAC
* [[RealAudio_racp|racp]] - HE-AAC

===== Video =====

* [[RealVideo|RV10]] - H.263
* [[RealVideo|RV13]] - H.263
* [[RealVideo G2|RV20]] - H.263+
* [[RealVideo 3|RV30]] - Unknown format
* [[RealVideo 4|RV40]] - Unknown format

[[Category: Container Formats]]

RealMedia

2006-12-25T21:26:10Z

Roberto: audio/x-pn-realaudio and audio/x-pn-multirate-realaudio mimetypes

* Extensions: rm, ra, rmvb
* Company: [[Real]]
* Specifications: https://common.helixcommunity.org/nonav/2003/HCS_SDK_r5/htmfiles/rmff.htm

Multimedia container format developed by [[Real]] and used almost exclusively for codecs developed by [[Real]].

The old .ra files are just for audio. The newer RealMedia (.rm) files are for audio and video.

== RA Format ==

This is the old audio-only RealAudio file format.
A very similar structure is also used to describe audio streams in RM files.

The audio data part is just a stream of bytes with no structure.
There is no index in .ra files, but seeking is possible because the codecs are CBR.

=== RealAudio 1.0 file (.ra version 3) ===

This is from the very first version of RealAudio (1995). These files can only contain [[RealAudio 14.4|8kbps VSELP]] audio data. A [[FourCC]] (lpcJ) may be present, but it is ignored. Byte order is big-endian.

byte[4] Header signature ('.', 'r', 'a', 0xfd)
word Version (always 3)
word Header size, not including first 8 bytes
byte[10] Unknown
dword Data size
byte Title string length
byte[] Title string
byte Author string length
byte[] Author string
byte Copyright string length
byte[] Copyright string
byte Comment string length
byte[] Comment string
byte Unknown *
byte Fourcc string length (always 4) *
byte[] Fourcc string (always "lpcJ") *
Audio data

Notes:
* Fields marked with * may be missing. Based on the only known sample with no [[FourCC]], it's assumed that all these fields are either present or missing. To determine if they are missing, check the header size (bytes 6-7).
* The informative fields (title, author, copyright and comment) can have zero length.

=== RealAudio 2.0 file (.ra version 4) ===

This is second version of the RealAudio file format. It is distinguished from the above by the value in byte 5 (=0x04). This type of file must contain a valid [[FourCC]] to identify the audio codec.

Possible [[FourCC]] values are [[RealAudio 28.8|28_8]], [[RealAudio_dnet|dnet]] and [[RealAudio_sipr|sipr]].

byte[4] Header signature ('.', 'r', 'a', 0xfd)
word Version (always 4)
word Unused (always 0)
byte[4] ra4 signature (always ".ra4")
dword Data size - 0x27
word Version2 (always equal to version)
dword Header size - 16
word Codec flavor
dword Coded frame size
byte[12] Unknown
word Sub packet h
word Frame size
word Subpacket size
word Unknown
word Samplerate
word Unknown
word Sample size
word Channels
byte Interleaver ID string length (always 4)
byte[] Interleaver ID string
byte [[FourCC]] string length (always 4)
byte[] [[FourCC]] string
byte[3] Unknown
byte Title string length
byte[] Title string
byte Author string length
byte[] Author string
byte Copyright string length
byte[] Copyright string
byte Comment string length
byte[] Comment string
Audio Data

Notes:
* The 0x27 in data size is the size of the fixed-length part of the header (up to channels).
* The informative fields (title, author, copyright and comment) can have zero length.

=== .ra version 5 ===

While the .ra header can contain version 5, there are no known RealAudio files with this format, and it's not known if they really exist.

== RealMedia Format ==

This is the newer format which stores both audio and video. All multi-byte numbers are stored in big-endian format.

A RealMedia file consists of a series of chunks. Each chunk has the following format:

dword chunk type ([[FOURCC]])
dword chunk size, including 8-byte preamble
word chunk version
byte[] chunk payload

Real chunk types:
* .RMF: RealMedia file header (only one per file, must be the first chunk)
* PROP: File properties (only one per file)
* MDPR: Stream properties (one for each stream)
* CONT: Content description/metadata (typically one per file)
* DATA: File data
* INDX: File index (typically one per stream)

=== RealMedia file header (.RMF) ===

This must be the first chunk in a RealMedia file. Only one .RMF can be present in a file. The only useful information carried by .RMF is the number of headers.

A .RMF chunk has the following format

dword chunk type ('.RMF')
dword chunk size (typically 0x12)
word chunk version (always 0, for every known file)
dword file version
dword number of headers

Notes:
* All known sample files have version equal to 0.
* There is a sample with chunk size = 0x10, in that case file version is a word. Note that the sample has chunk version = 0 like all other files.

=== File properties header (PROP) ===

This chunk contains some information about the general properties of a RealMedia file. Only one PROP chunk can be present in a file.

A PROP chunk has the following format

dword Chunk type ('PROP')
dword Chunk size (typically 0x32)
word Chunk version (always 0, for every known file)
dword Maximum bit rate
dword Average bit rate
dword Size of largest data packet
dword Average size of data packet
dword Number of data packets in the file
dword File duration in ms
dword Suggested number of ms to buffer before starting playback
dword Offset of the first INDX chunk form the start of the file
dword Offset of the first DATA chunk form the start of the file
word Number of streams in the file
word Flags (bitfield, see below)

Flags:
* bit 0: file can be saved on disk
* bit 1: PerfectPlay can be used (extra buffering)
* bit 2: the file is a live broadcast

=== Media properties header (MDPR) ===

This chunk contains information about the properties of a RealMedia stream. This header defines the type of a stream and the codec used. All codec-related data is in the type specific part of this header.

Many fields share the same meanings as the ones in PROP chunk, but in this case they are specific for one stream.

There is one MDPR chunk for every stream in the file.

A MDPR chunk has the following format

dword Chunk type ('MDPR')
dword Chunk size
word Chunk version (always 0, for every known file)
word Stream number
dword Maximum bit rate
dword Average bit rate
dword Size of largest data packet
dword Average size of data packet
dword Stream start offset in ms
dword Preroll in ms (to be subtracted from timestamps?)
dword Stream duration in ms
byte Size of stream description string
byte[] Stream description string
byte Size of stream mime type string
byte[] Mime type string
dword Size of type specific part of the header
byte[] Type specific data, meaning and format depends on mime type

==== Audio (audio/) ====

===== audio/x-pn-realaudio and audio/x-pn-multirate-realaudio =====
These mimetypes are used to specify streams with RealAudio codecs. There are 3 known versions of this datablock: ra3, ra4, ra5. ra3 is used only with the old 14_4 codec, ra4 and ra5 can be used with all the other codecs.

The audio block has this format

byte[4] Header signature ('.', 'r', 'a', 0xfd)
word Version (3, 4 or 5)
#if version == 3
word Header size, not including first 8 bytes
byte[10] Unknown
dword Data size
byte Title string length
byte[] Title string
byte Author string length
byte[] Author string
byte Copyright string length
byte[] Copyright string
byte Comment string length
byte[] Comment string
byte Unknown *
byte Fourcc string length (always 4) *
byte[] Fourcc string (always "lpcJ") *
#elseif version == 4 or version == 5
word Unused (always 0)
byte[4] ra signature (".ra4" or ".ra5", depending on version)
dword Unknown (maybe data size)
word Version2 (always equal to version)
dword Header size
word Codec flavor
dword Coded frame size
byte[12] Unknown
word Sub packet h
word Frame size
word Subpacket size
word Unknown
#if version == 5
byte[6] Unknown
#endif
word Samplerate
word Unknown
word Sample size
word Channels
#if version == 4
byte Interleaver ID string length (always 4)
byte[] Interleaver ID string
byte [[FourCC]] string length (always 4)
byte[] [[FourCC]] string
#endif
#if version == 5
dword Interleaver ID
dword [[FourCC]]
#endif
byte[3] Unknown
#if version == 5
byte Unknown
#endif
dword Codec extradata length
byte[] Codec extradata
#endif

=== Content description header (CONT) ===

This chunk contains some text information (like title, author, ...) about the content of the file. This header has an informative purpose only and it's not needed to demux the file.

A CONT chunk has the following format

dword Chunk type ('CONT')
dword Chunk size
word Chunk version (always 0, for every known file)
word Title string length
byte[] Title string
word Author string length
byte[] Author string
word Copyright string length
byte[] Copyright string
word Comment string length
byte[] Comment string

=== Data header (DATA) ===

This chunk contains a group of data packets. Packets from each stream are interleaved, except for multirate files.

A DATA chunk has the following format

dword Chunk type ('DATA')
dword Chunk size
word Chunk version (always 0, for every known file)
dword Number of data packets in this chunk
dword Offset of the next DATA chunk (form the start of the file)
byte[] Data packets

Each data packet has this format

word Packet version (0 or 1 in available samples)
word Packet size
word Stream number
dword Timestamp (in ms)
byte Unknown
byte Flags (bitfield, see below)
#if version == 1
byte Unknown
#endif
byte[] Stream-specific data

Flags:
* bit 0: reliable packet (refers to network transmission method)
* bit 1: keyframe

Note:
The previous description of the data packet comes from working demuxer code, the description in official [[Real]] docs (somewhere on [[Helix]] site) is a bit different:

word Packet version
word Packet size
word Stream number
dword Timestamp
#if version == 0
byte Packet group
byte Flags
#endif
#if version == 1
word ASM rule
byte ASM flags
#endif
byte[] Stream-specific data

where packet group is "The packet group to which the packet belongs. If packet grouping is not used, set this field to 0 (zero)", asm rule is "The ASM rule assigned to this packet" and asm flags "Contains HX_ flags that dictate stream switching points".

=== Index header (INDX) ===

This chunk contains index entries. It comes after all the DATA chunks.
An index chunk contains data for a single stream, A file can have more than one INDX chunk.

A INDX chunk has the following format

dword Chunk type ('INDX')
dword Chunk size
word Chunk version (always 0, for every known file)
dword Number of entries in this chunk
word Stream number
dword Offset of the next INDX chunk (form the start of the file)
byte[] Index entries

Each index entry has this format

word Entry version (always 0, for every known file)
dword Timestamp (in ms)
dword Packet offset in file (form the start of the file)
dword Packet number

== Codecs ==

Codecs in RealMedia are identified by the following four character codes:

===== Audio =====

* [[RealAudio 14.4|lpcJ]] - RealAudio 1.0 (VSELP)
* [[RealAudio 28.8|28_8]] - RealAudio 2.0 (LD-CELP)
* [[RealAudio_dnet|dnet]] - AC3
* [[RealAudio_sipr|sipr]] - Sipro
* [[RealAudio_cook|cook]] - Cook
* [[RealAudio_atrc|atrc]] - ATRAC
* [[Real Lossless Codec|ralf]] - RealAudio Lossless Format
* [[RealAudio_raac|raac]] - LC-AAC
* [[RealAudio_racp|racp]] - HE-AAC

===== Video =====

* [[RealVideo|RV10]] - H.263
* [[RealVideo|RV13]] - H.263
* [[RealVideo G2|RV20]] - H.263+
* [[RealVideo 3|RV30]] - Unknown format
* [[RealVideo 4|RV40]] - Unknown format

[[Category: Container Formats]]

RealMedia

2006-12-19T23:05:44Z

Roberto: Cosmetics: fix indentation

* Extensions: rm, ra, rmvb
* Company: [[Real]]

Multimedia container format developed by [[Real]] and used almost exclusively for codecs developed by [[Real]].

The old .ra files are just for audio. The newer RealMedia (.rm) files are for audio and video.

== RA Format ==

This is the old audio-only RealAudio file format.
A very similar structure is also used to describe audio streams in RM files.

The audio data part is just a stream of bytes with no structure.
There is no index in .ra files, but seeking is possible because the codecs are CBR.

=== RealAudio 1.0 file (.ra version 3) ===

This is from the very first version of RealAudio (1995). These files can only contain [[RealAudio 14.4|8kbps VSELP]] audio data. A [[FourCC]] (lpcJ) may be present, but it is ignored. Byte order is big-endian.

byte[4] Header signature ('.', 'r', 'a', 0xfd)
word Version (always 3)
word Header size, not including first 8 bytes
byte[10] Unknown
dword Data size
byte Title string length
byte[] Title string
byte Author string length
byte[] Author string
byte Copyright string length
byte[] Copyright string
byte Comment string length
byte[] Comment string
byte Unknown *
byte Fourcc string length (always 4) *
byte[] Fourcc string (always "lpcJ") *
Audio data

Notes:
* Fields marked with * may be missing. Based on the only known sample with no [[FourCC]], it's assumed that all these fields are either present or missing. To determine if they are missing, check the header size (bytes 6-7).
* The informative fields (title, author, copyright and comment) can have zero length.

=== RealAudio 2.0 file (.ra version 4) ===

This is second version of the RealAudio file format. It is distinguished from the above by the value in byte 5 (=0x04). This type of file must contain a valid [[FourCC]] to identify the audio codec.

Possible [[FourCC]] values are [[RealAudio 28.8|28_8]], [[RealAudio_dnet|dnet]] and [[RealAudio_sipr|sipr]].

byte[4] Header signature ('.', 'r', 'a', 0xfd)
word Version (always 4)
word Unused (always 0)
byte[4] ra4 signature (always ".ra4")
dword Data size - 0x27
word Version2 (always equal to version)
dword Header size - 16
word Codec flavor
dword Coded frame size
byte[12] Unknown
word Sub packet h
word Frame size
word Subpacket size
word Unknown
word Samplerate
word Unknown
word Sample size
word Channels
byte Interleaver ID string length (always 4)
byte[] Interleaver ID string
byte [[FourCC]] string length (always 4)
byte[] [[FourCC]] string
byte[3] Unknown
byte Title string length
byte[] Title string
byte Author string length
byte[] Author string
byte Copyright string length
byte[] Copyright string
byte Comment string length
byte[] Comment string
Audio Data

Notes:
* The 0x27 in data size is the size of the fixed-length part of the header (up to channels).
* The informative fields (title, author, copyright and comment) can have zero length.

=== .ra version 5 ===

While the .ra header can contain version 5, there are no known RealAudio files with this format, and it's not known if they really exist.

== RealMedia Format ==

This is the newer format which stores both audio and video. All multi-byte numbers are stored in big-endian format.

A RealMedia file consists of a series of chunks. Each chunk has the following format:

dword chunk type ([[FOURCC]])
dword chunk size, including 8-byte preamble
word chunk version
byte[] chunk payload

Real chunk types:
* .RMF: RealMedia file header (only one per file, must be the first chunk)
* PROP: File properties (only one per file)
* MDPR: Stream properties (one for each stream)
* CONT: Content description/metadata (typically one per file)
* DATA: File data
* INDX: File index (typically one per stream)

=== RealMedia file header (.RMF) ===

This must be the first chunk in a RealMedia file. Only one .RMF can be present in a file. The only useful information carried by .RMF is the number of headers.

A .RMF chunk has the following format

dword chunk type ('.RMF')
dword chunk size (typically 0x12)
word chunk version (always 0, for every known file)
dword file version
dword number of headers

Notes:
* All known sample files have version equal to 0.
* There is a sample with chunk size = 0x10, in that case file version is a word. Note that the sample has chunk version = 0 like all other files.

=== File properties header (PROP) ===

This chunk contains some information about the general properties of a RealMedia file. Only one PROP chunk can be present in a file.

A PROP chunk has the following format

dword Chunk type ('PROP')
dword Chunk size (typically 0x32)
word Chunk version (always 0, for every known file)
dword Maximum bit rate
dword Average bit rate
dword Size of largest data packet
dword Average size of data packet
dword Number of data packets in the file
dword File duration in ms
dword Suggested number of ms to buffer before starting playback
dword Offset of the first INDX chunk form the start of the file
dword Offset of the first DATA chunk form the start of the file
word Number of streams in the file
word Flags (bitfield, see below)

Flags:
* bit 0: file can be saved on disk
* bit 1: PerfectPlay can be used (extra buffering)
* bit 2: the file is a live broadcast

=== Media properties header (MDPR) ===

This chunk contains information about the properties of a RealMedia stream. This header defines the type of a stream and the codec used. All codec-related data is in the type specific part of this header.

Many fields share the same meanings as the ones in PROP chunk, but in this case they are specific for one stream.

There is one MDPR chunk for every stream in the file.

A MDPR chunk has the following format

dword Chunk type ('MDPR')
dword Chunk size
word Chunk version (always 0, for every known file)
word Stream number
dword Maximum bit rate
dword Average bit rate
dword Size of largest data packet
dword Average size of data packet
dword Stream start offset in ms
dword Preroll in ms (to be subtracted from timestamps?)
dword Stream duration in ms
byte Size of stream description string
byte[] Stream description string
byte Size of stream mime type string
byte[] Mime type string
dword Size of type specific part of the header
byte[] Type specific data, meaning and format depends on mime type

=== Content description header (CONT) ===

This chunk contains some text information (like title, author, ...) about the content of the file. This header has an informative purpose only and it's not needed to demux the file.

A CONT chunk has the following format

dword Chunk type ('CONT')
dword Chunk size
word Chunk version (always 0, for every known file)
word Title string length
byte[] Title string
word Author string length
byte[] Author string
word Copyright string length
byte[] Copyright string
word Comment string length
byte[] Comment string

=== Data header (DATA) ===

This chunk contains a group of data packets. Packets from each stream are interleaved, except for multirate files.

A DATA chunk has the following format

dword Chunk type ('DATA')
dword Chunk size
word Chunk version (always 0, for every known file)
dword Number of data packets in this chunk
dword Offset of the next DATA chunk (form the start of the file)
byte[] Data packets

Each data packet has this format

word Packet version (0 or 1 in available samples)
word Packet size
word Stream number
dword Timestamp (in ms)
byte Unknown
byte Flags (bitfield, see below)
#if version == 1
byte Unknown
#endif
byte[] Stream-specific data

Flags:
* bit 0: reliable packet (refers to network transmission method)
* bit 1: keyframe

Note:
The previous description of the data packet comes from working demuxer code, the description in official [[Real]] docs (somewhere on [[Helix]] site) is a bit different:

word Packet version
word Packet size
word Stream number
dword Timestamp
#if version == 0
byte Packet group
byte Flags
#endif
#if version == 1
word ASM rule
byte ASM flags
#endif
byte[] Stream-specific data

where packet group is "The packet group to which the packet belongs. If packet grouping is not used, set this field to 0 (zero)", asm rule is "The ASM rule assigned to this packet" and asm flags "Contains HX_ flags that dictate stream switching points".

=== Index header (INDX) ===

This chunk contains index entries. It comes after all the DATA chunks.
An index chunk contains data for a single stream, A file can have more than one INDX chunk.

A INDX chunk has the following format

dword Chunk type ('INDX')
dword Chunk size
word Chunk version (always 0, for every known file)
dword Number of entries in this chunk
word Stream number
dword Offset of the next INDX chunk (form the start of the file)
byte[] Index entries

Each index entry has this format

word Entry version (always 0, for every known file)
dword Timestamp (in ms)
dword Packet offset in file (form the start of the file)
dword Packet number

== Codecs ==

Codecs in RealMedia are identified by the following four character codes:

===== Audio =====

* [[RealAudio 14.4|lpcJ]] - RealAudio 1.0 (VSELP)
* [[RealAudio 28.8|28_8]] - RealAudio 2.0 (LD-CELP)
* [[RealAudio_dnet|dnet]] - AC3
* [[RealAudio_sipr|sipr]] - Sipro
* [[RealAudio_cook|cook]] - Cook
* [[RealAudio_atrc|atrc]] - ATRAC
* [[Real Lossless Codec|ralf]] - RealAudio Lossless Format
* [[RealAudio_raac|raac]] - LC-AAC
* [[RealAudio_racp|racp]] - HE-AAC

===== Video =====

* [[RealVideo|RV10]] - H.263
* [[RealVideo|RV13]] - H.263
* [[RealVideo G2|RV20]] - H.263+
* [[RealVideo 3|RV30]] - Unknown format
* [[RealVideo 4|RV40]] - Unknown format

[[Category: Container Formats]]

RealMedia

2006-12-19T23:04:49Z

Roberto: Wikify some keywords

RealMedia

2006-12-19T22:48:18Z

Roberto: Remove redundant comment in "official" Real data packet format

* Extensions: rm, ra, rmvb
* Company: [[Real]]

Multimedia container format developed by [[Real]] and used almost exclusively for codecs developed by Real.

The old .ra files are just for audio. The newer RealMedia (.rm) files are for audio and video.

== RA Format ==

This is the old audio-only RealAudio file format.
A very similar structure is also used to describe audio streams in RM files.

The audio data part is just a stream of bytes with no structure.
There is no index in .ra files, but seeking is possible because the codecs are CBR.

=== RealAudio 1.0 file (.ra version 3) ===

This is from the very first version of RealAudio (1995). These files can only contain [[RealAudio 14.4|8kbps VSELP]] audio data. A FourCC (lpcJ) may be present, but it is ignored. Byte order is big-endian.

byte[4] Header signature ('.', 'r', 'a', 0xfd)
word Version (always 3)
word Header size, not including first 8 bytes
byte[10] Unknown
dword Data size
byte Title string length
byte[] Title string
byte Author string length
byte[] Author string
byte Copyright string length
byte[] Copyright string
byte Comment string length
byte[] Comment string
byte Unknown *
byte Fourcc string length (always 4) *
byte[] Fourcc string (always "lpcJ") *
Audio data

Notes:
* Fields marked with * may be missing. Based on the only known sample with no FourCC, it's assumed that all these fields are either present or missing. To determine if they are missing, check the header size (bytes 6-7).
* The informative fields (title, author, copyright and comment) can have zero length.

=== RealAudio 2.0 file (.ra version 4) ===

This is second version of the RealAudio file format. It is distinguished from the above by the value in byte 5 (=0x04). This type of file must contain a valid FourCC to identify the audio codec.

Possible fourCC values are [[RealAudio 28.8|28_8]], [[RealAudio_dnet|dnet]] and [[RealAudio_sipr|sipr]].

byte[4] Header signature ('.', 'r', 'a', 0xfd)
word Version (always 4)
word Unused (always 0)
byte[4] ra4 signature (always ".ra4")
dword Data size - 0x27
word Version2 (always equal to version)
dword Header size - 16
word Codec flavor
dword Coded frame size
byte[12] Unknown
word Sub packet h
word Frame size
word Subpacket size
word Unknown
word Samplerate
word Unknown
word Sample size
word Channels
byte Interleaver ID string length (always 4)
byte[] Interleaver ID string
byte FourCC string length (always 4)
byte[] FourCC string
byte[3] Unknown
byte Title string length
byte[] Title string
byte Author string length
byte[] Author string
byte Copyright string length
byte[] Copyright string
byte Comment string length
byte[] Comment string
Audio Data

Notes:
* The 0x27 in data size is the size of the fixed-length part of the header (up to channels).
* The informative fields (title, author, copyright and comment) can have zero length.

=== .ra version 5 ===

While the .ra header can contain version 5, there are no known RealAudio files with this format, and it's not known if they really exist.

== RealMedia Format ==

This is the newer format which stores both audio and video. All multi-byte numbers are stored in big-endian format.

A RealMedia file consists of a series of chunks. Each chunk has the following format:

dword chunk type ([[FOURCC]])
dword chunk size, including 8-byte preamble
word chunk version
byte[] chunk payload

Real chunk types:
* .RMF: RealMedia file header (only one per file, must be the first chunk)
* PROP: File properties (only one per file)
* MDPR: Stream properties (one for each stream)
* CONT: Content description/metadata (typically one per file)
* DATA: File data
* INDX: File index (typically one per stream)

=== RealMedia file header (.RMF) ===

This must be the first chunk in a RealMedia file. Only one .RMF can be present in a file. The only useful information carried by .RMF is the number of headers.

A .RMF chunk has the following format

dword chunk type ('.RMF')
dword chunk size (typically 0x12)
word chunk version (always 0, for every known file)
dword file version
dword number of headers

Notes:
* All known sample files have version equal to 0.
* There is a sample with chunk size = 0x10, in that case file version is a word. Note that the sample has chunk version = 0 like all other files.

=== File properties header (PROP) ===

This chunk contains some information about the general properties of a RealMedia file. Only one PROP chunk can be present in a file.

A PROP chunk has the following format

dword Chunk type ('PROP')
dword Chunk size (typically 0x32)
word Chunk version (always 0, for every known file)
dword Maximum bit rate
dword Average bit rate
dword Size of largest data packet
dword Average size of data packet
dword Number of data packets in the file
dword File duration in ms
dword Suggested number of ms to buffer before starting playback
dword Offset of the first INDX chunk form the start of the file
dword Offset of the first DATA chunk form the start of the file
word Number of streams in the file
word Flags (bitfield, see below)

Flags:
* bit 0: file can be saved on disk
* bit 1: PerfectPlay can be used (extra buffering)
* bit 2: the file is a live broadcast

=== Media properties header (MDPR) ===

This chunk contains information about the properties of a RealMedia stream. This header defines the type of a stream and the codec used. All codec-related data is in the type specific part of this header.

Many fields share the same meanings as the ones in PROP chunk, but in this case they are specific for one stream.

There is one MDPR chunk for every stream in the file.

A MDPR chunk has the following format

dword Chunk type ('MDPR')
dword Chunk size
word Chunk version (always 0, for every known file)
word Stream number
dword Maximum bit rate
dword Average bit rate
dword Size of largest data packet
dword Average size of data packet
dword Stream start offset in ms
dword Preroll in ms (to be subtracted from timestamps?)
dword Stream duration in ms
byte Size of stream description string
byte[] Stream description string
byte Size of stream mime type string
byte[] Mime type string
dword Size of type specific part of the header
byte[] Type specific data, meaning and format depends on mime type

=== Content description header (CONT) ===

This chunk contains some text information (like title, author, ...) about the content of the file. This header has an informative purpose only and it's not needed to demux the file.

A CONT chunk has the following format

dword Chunk type ('CONT')
dword Chunk size
word Chunk version (always 0, for every known file)
word Title string length
byte[] Title string
word Author string length
byte[] Author string
word Copyright string length
byte[] Copyright string
word Comment string length
byte[] Comment string

=== Data header (DATA) ===

This chunk contains a group of data packets. Packets from each stream are interleaved, except for multirate files.

A DATA chunk has the following format

dword Chunk type ('DATA')
dword Chunk size
word Chunk version (always 0, for every known file)
dword Number of data packets in this chunk
dword Offset of the next DATA chunk (form the start of the file)
byte[] Data packets

Each data packet has this format

word Packet version (0 or 1 in available samples)
word Packet size
word Stream number
dword Timestamp (in ms)
byte Unknown
byte Flags (bitfield, see below)
#if version == 1
byte Unknown
#endif
byte[] Stream-specific data

Flags:
* bit 0: reliable packet (refers to network transmission method)
* bit 1: keyframe

Note:
The previous description of the data packet comes from working demuxer code, the description in official Real docs (somewhere on Helix site) is a bit different:

word Packet version
word Packet size
word Stream number
dword Timestamp
#if version == 0
byte Packet group
byte Flags
#endif
#if version == 1
word ASM rule
byte ASM flags
#endif
byte[] Stream-specific data

where packet group is "The packet group to which the packet belongs. If packet grouping is not used, set this field to 0 (zero)", asm rule is "The ASM rule assigned to this packet" and asm flags "Contains HX_ flags that dictate stream switching points".

=== Index header (INDX) ===

This chunk contains index entries. It comes after all the DATA chunks.
An index chunk contains data for a single stream, A file can have more than one INDX chunk.

A INDX chunk has the following format

dword Chunk type ('INDX')
dword Chunk size
word Chunk version (always 0, for every known file)
dword Number of entries in this chunk
word Stream number
dword Offset of the next INDX chunk (form the start of the file)
byte[] Index entries

Each index entry has this format

word Entry version (always 0, for every known file)
dword Timestamp (in ms)
dword Packet offset in file (form the start of the file)
dword Packet number

== Codecs ==

Codecs in RealMedia are identified by the following four character codes:

===== Audio =====

* [[RealAudio 14.4|lpcJ]] - RealAudio 1.0 (VSELP)
* [[RealAudio 28.8|28_8]] - RealAudio 2.0 (LD-CELP)
* [[RealAudio_dnet|dnet]] - AC3
* [[RealAudio_sipr|sipr]] - Sipro
* [[RealAudio_cook|cook]] - Cook
* [[RealAudio_atrc|atrc]] - ATRAC
* [[Real Lossless Codec|ralf]] - RealAudio Lossless Format
* [[RealAudio_raac|raac]] - LC-AAC
* [[RealAudio_racp|racp]] - HE-AAC

===== Video =====

* [[RealVideo|RV10]] - H.263
* [[RealVideo|RV13]] - H.263
* [[RealVideo G2|RV20]] - H.263+
* [[RealVideo 3|RV30]] - Unknown format
* [[RealVideo 4|RV40]] - Unknown format

[[Category: Container Formats]]

RealMedia

2006-12-19T22:47:16Z

Roberto: Add time unit to data packet timestamp

* Extensions: rm, ra, rmvb
* Company: [[Real]]

Multimedia container format developed by [[Real]] and used almost exclusively for codecs developed by Real.

The old .ra files are just for audio. The newer RealMedia (.rm) files are for audio and video.

== RA Format ==

This is the old audio-only RealAudio file format.
A very similar structure is also used to describe audio streams in RM files.

The audio data part is just a stream of bytes with no structure.
There is no index in .ra files, but seeking is possible because the codecs are CBR.

=== RealAudio 1.0 file (.ra version 3) ===

This is from the very first version of RealAudio (1995). These files can only contain [[RealAudio 14.4|8kbps VSELP]] audio data. A FourCC (lpcJ) may be present, but it is ignored. Byte order is big-endian.

byte[4] Header signature ('.', 'r', 'a', 0xfd)
word Version (always 3)
word Header size, not including first 8 bytes
byte[10] Unknown
dword Data size
byte Title string length
byte[] Title string
byte Author string length
byte[] Author string
byte Copyright string length
byte[] Copyright string
byte Comment string length
byte[] Comment string
byte Unknown *
byte Fourcc string length (always 4) *
byte[] Fourcc string (always "lpcJ") *
Audio data

Notes:
* Fields marked with * may be missing. Based on the only known sample with no FourCC, it's assumed that all these fields are either present or missing. To determine if they are missing, check the header size (bytes 6-7).
* The informative fields (title, author, copyright and comment) can have zero length.

=== RealAudio 2.0 file (.ra version 4) ===

This is second version of the RealAudio file format. It is distinguished from the above by the value in byte 5 (=0x04). This type of file must contain a valid FourCC to identify the audio codec.

Possible fourCC values are [[RealAudio 28.8|28_8]], [[RealAudio_dnet|dnet]] and [[RealAudio_sipr|sipr]].

byte[4] Header signature ('.', 'r', 'a', 0xfd)
word Version (always 4)
word Unused (always 0)
byte[4] ra4 signature (always ".ra4")
dword Data size - 0x27
word Version2 (always equal to version)
dword Header size - 16
word Codec flavor
dword Coded frame size
byte[12] Unknown
word Sub packet h
word Frame size
word Subpacket size
word Unknown
word Samplerate
word Unknown
word Sample size
word Channels
byte Interleaver ID string length (always 4)
byte[] Interleaver ID string
byte FourCC string length (always 4)
byte[] FourCC string
byte[3] Unknown
byte Title string length
byte[] Title string
byte Author string length
byte[] Author string
byte Copyright string length
byte[] Copyright string
byte Comment string length
byte[] Comment string
Audio Data

Notes:
* The 0x27 in data size is the size of the fixed-length part of the header (up to channels).
* The informative fields (title, author, copyright and comment) can have zero length.

=== .ra version 5 ===

While the .ra header can contain version 5, there are no known RealAudio files with this format, and it's not known if they really exist.

== RealMedia Format ==

This is the newer format which stores both audio and video. All multi-byte numbers are stored in big-endian format.

A RealMedia file consists of a series of chunks. Each chunk has the following format:

dword chunk type ([[FOURCC]])
dword chunk size, including 8-byte preamble
word chunk version
byte[] chunk payload

Real chunk types:
* .RMF: RealMedia file header (only one per file, must be the first chunk)
* PROP: File properties (only one per file)
* MDPR: Stream properties (one for each stream)
* CONT: Content description/metadata (typically one per file)
* DATA: File data
* INDX: File index (typically one per stream)

=== RealMedia file header (.RMF) ===

This must be the first chunk in a RealMedia file. Only one .RMF can be present in a file. The only useful information carried by .RMF is the number of headers.

A .RMF chunk has the following format

dword chunk type ('.RMF')
dword chunk size (typically 0x12)
word chunk version (always 0, for every known file)
dword file version
dword number of headers

Notes:
* All known sample files have version equal to 0.
* There is a sample with chunk size = 0x10, in that case file version is a word. Note that the sample has chunk version = 0 like all other files.

=== File properties header (PROP) ===

This chunk contains some information about the general properties of a RealMedia file. Only one PROP chunk can be present in a file.

A PROP chunk has the following format

dword Chunk type ('PROP')
dword Chunk size (typically 0x32)
word Chunk version (always 0, for every known file)
dword Maximum bit rate
dword Average bit rate
dword Size of largest data packet
dword Average size of data packet
dword Number of data packets in the file
dword File duration in ms
dword Suggested number of ms to buffer before starting playback
dword Offset of the first INDX chunk form the start of the file
dword Offset of the first DATA chunk form the start of the file
word Number of streams in the file
word Flags (bitfield, see below)

Flags:
* bit 0: file can be saved on disk
* bit 1: PerfectPlay can be used (extra buffering)
* bit 2: the file is a live broadcast

=== Media properties header (MDPR) ===

This chunk contains information about the properties of a RealMedia stream. This header defines the type of a stream and the codec used. All codec-related data is in the type specific part of this header.

Many fields share the same meanings as the ones in PROP chunk, but in this case they are specific for one stream.

There is one MDPR chunk for every stream in the file.

A MDPR chunk has the following format

dword Chunk type ('MDPR')
dword Chunk size
word Chunk version (always 0, for every known file)
word Stream number
dword Maximum bit rate
dword Average bit rate
dword Size of largest data packet
dword Average size of data packet
dword Stream start offset in ms
dword Preroll in ms (to be subtracted from timestamps?)
dword Stream duration in ms
byte Size of stream description string
byte[] Stream description string
byte Size of stream mime type string
byte[] Mime type string
dword Size of type specific part of the header
byte[] Type specific data, meaning and format depends on mime type

=== Content description header (CONT) ===

This chunk contains some text information (like title, author, ...) about the content of the file. This header has an informative purpose only and it's not needed to demux the file.

A CONT chunk has the following format

dword Chunk type ('CONT')
dword Chunk size
word Chunk version (always 0, for every known file)
word Title string length
byte[] Title string
word Author string length
byte[] Author string
word Copyright string length
byte[] Copyright string
word Comment string length
byte[] Comment string

=== Data header (DATA) ===

This chunk contains a group of data packets. Packets from each stream are interleaved, except for multirate files.

A DATA chunk has the following format

dword Chunk type ('DATA')
dword Chunk size
word Chunk version (always 0, for every known file)
dword Number of data packets in this chunk
dword Offset of the next DATA chunk (form the start of the file)
byte[] Data packets

Each data packet has this format

word Packet version (0 or 1 in available samples)
word Packet size
word Stream number
dword Timestamp (in ms)
byte Unknown
byte Flags (bitfield, see below)
#if version == 1
byte Unknown
#endif
byte[] Stream-specific data

Flags:
* bit 0: reliable packet (refers to network transmission method)
* bit 1: keyframe

Note:
The previous description of the data packet comes from working demuxer code, the description in official Real docs (somewhere on Helix site) is a bit different:

word Packet version
word Packet size
word Stream number
dword Timestamp
#if version == 0
byte Packet group
byte Flags (bitfield, see below)
#endif
#if version == 1
word ASM rule
byte ASM flags
#endif
byte[] Stream-specific data

where packet group is "The packet group to which the packet belongs. If packet grouping is not used, set this field to 0 (zero)", asm rule is "The ASM rule assigned to this packet" and asm flags "Contains HX_ flags that dictate stream switching points".

=== Index header (INDX) ===

This chunk contains index entries. It comes after all the DATA chunks.
An index chunk contains data for a single stream, A file can have more than one INDX chunk.

A INDX chunk has the following format

dword Chunk type ('INDX')
dword Chunk size
word Chunk version (always 0, for every known file)
dword Number of entries in this chunk
word Stream number
dword Offset of the next INDX chunk (form the start of the file)
byte[] Index entries

Each index entry has this format

word Entry version (always 0, for every known file)
dword Timestamp (in ms)
dword Packet offset in file (form the start of the file)
dword Packet number

== Codecs ==

Codecs in RealMedia are identified by the following four character codes:

===== Audio =====

* [[RealAudio 14.4|lpcJ]] - RealAudio 1.0 (VSELP)
* [[RealAudio 28.8|28_8]] - RealAudio 2.0 (LD-CELP)
* [[RealAudio_dnet|dnet]] - AC3
* [[RealAudio_sipr|sipr]] - Sipro
* [[RealAudio_cook|cook]] - Cook
* [[RealAudio_atrc|atrc]] - ATRAC
* [[Real Lossless Codec|ralf]] - RealAudio Lossless Format
* [[RealAudio_raac|raac]] - LC-AAC
* [[RealAudio_racp|racp]] - HE-AAC

===== Video =====

* [[RealVideo|RV10]] - H.263
* [[RealVideo|RV13]] - H.263
* [[RealVideo G2|RV20]] - H.263+
* [[RealVideo 3|RV30]] - Unknown format
* [[RealVideo 4|RV40]] - Unknown format

[[Category: Container Formats]]

RealMedia

2006-12-19T22:46:23Z

Roberto: INDX chunk and index entries

* Extensions: rm, ra, rmvb
* Company: [[Real]]

Multimedia container format developed by [[Real]] and used almost exclusively for codecs developed by Real.

The old .ra files are just for audio. The newer RealMedia (.rm) files are for audio and video.

== RA Format ==

This is the old audio-only RealAudio file format.
A very similar structure is also used to describe audio streams in RM files.

The audio data part is just a stream of bytes with no structure.
There is no index in .ra files, but seeking is possible because the codecs are CBR.

=== RealAudio 1.0 file (.ra version 3) ===

This is from the very first version of RealAudio (1995). These files can only contain [[RealAudio 14.4|8kbps VSELP]] audio data. A FourCC (lpcJ) may be present, but it is ignored. Byte order is big-endian.

byte[4] Header signature ('.', 'r', 'a', 0xfd)
word Version (always 3)
word Header size, not including first 8 bytes
byte[10] Unknown
dword Data size
byte Title string length
byte[] Title string
byte Author string length
byte[] Author string
byte Copyright string length
byte[] Copyright string
byte Comment string length
byte[] Comment string
byte Unknown *
byte Fourcc string length (always 4) *
byte[] Fourcc string (always "lpcJ") *
Audio data

Notes:
* Fields marked with * may be missing. Based on the only known sample with no FourCC, it's assumed that all these fields are either present or missing. To determine if they are missing, check the header size (bytes 6-7).
* The informative fields (title, author, copyright and comment) can have zero length.

=== RealAudio 2.0 file (.ra version 4) ===

This is second version of the RealAudio file format. It is distinguished from the above by the value in byte 5 (=0x04). This type of file must contain a valid FourCC to identify the audio codec.

Possible fourCC values are [[RealAudio 28.8|28_8]], [[RealAudio_dnet|dnet]] and [[RealAudio_sipr|sipr]].

byte[4] Header signature ('.', 'r', 'a', 0xfd)
word Version (always 4)
word Unused (always 0)
byte[4] ra4 signature (always ".ra4")
dword Data size - 0x27
word Version2 (always equal to version)
dword Header size - 16
word Codec flavor
dword Coded frame size
byte[12] Unknown
word Sub packet h
word Frame size
word Subpacket size
word Unknown
word Samplerate
word Unknown
word Sample size
word Channels
byte Interleaver ID string length (always 4)
byte[] Interleaver ID string
byte FourCC string length (always 4)
byte[] FourCC string
byte[3] Unknown
byte Title string length
byte[] Title string
byte Author string length
byte[] Author string
byte Copyright string length
byte[] Copyright string
byte Comment string length
byte[] Comment string
Audio Data

Notes:
* The 0x27 in data size is the size of the fixed-length part of the header (up to channels).
* The informative fields (title, author, copyright and comment) can have zero length.

=== .ra version 5 ===

While the .ra header can contain version 5, there are no known RealAudio files with this format, and it's not known if they really exist.

== RealMedia Format ==

This is the newer format which stores both audio and video. All multi-byte numbers are stored in big-endian format.

A RealMedia file consists of a series of chunks. Each chunk has the following format:

dword chunk type ([[FOURCC]])
dword chunk size, including 8-byte preamble
word chunk version
byte[] chunk payload

Real chunk types:
* .RMF: RealMedia file header (only one per file, must be the first chunk)
* PROP: File properties (only one per file)
* MDPR: Stream properties (one for each stream)
* CONT: Content description/metadata (typically one per file)
* DATA: File data
* INDX: File index (typically one per stream)

=== RealMedia file header (.RMF) ===

This must be the first chunk in a RealMedia file. Only one .RMF can be present in a file. The only useful information carried by .RMF is the number of headers.

A .RMF chunk has the following format

dword chunk type ('.RMF')
dword chunk size (typically 0x12)
word chunk version (always 0, for every known file)
dword file version
dword number of headers

Notes:
* All known sample files have version equal to 0.
* There is a sample with chunk size = 0x10, in that case file version is a word. Note that the sample has chunk version = 0 like all other files.

=== File properties header (PROP) ===

This chunk contains some information about the general properties of a RealMedia file. Only one PROP chunk can be present in a file.

A PROP chunk has the following format

dword Chunk type ('PROP')
dword Chunk size (typically 0x32)
word Chunk version (always 0, for every known file)
dword Maximum bit rate
dword Average bit rate
dword Size of largest data packet
dword Average size of data packet
dword Number of data packets in the file
dword File duration in ms
dword Suggested number of ms to buffer before starting playback
dword Offset of the first INDX chunk form the start of the file
dword Offset of the first DATA chunk form the start of the file
word Number of streams in the file
word Flags (bitfield, see below)

Flags:
* bit 0: file can be saved on disk
* bit 1: PerfectPlay can be used (extra buffering)
* bit 2: the file is a live broadcast

=== Media properties header (MDPR) ===

This chunk contains information about the properties of a RealMedia stream. This header defines the type of a stream and the codec used. All codec-related data is in the type specific part of this header.

Many fields share the same meanings as the ones in PROP chunk, but in this case they are specific for one stream.

There is one MDPR chunk for every stream in the file.

A MDPR chunk has the following format

dword Chunk type ('MDPR')
dword Chunk size
word Chunk version (always 0, for every known file)
word Stream number
dword Maximum bit rate
dword Average bit rate
dword Size of largest data packet
dword Average size of data packet
dword Stream start offset in ms
dword Preroll in ms (to be subtracted from timestamps?)
dword Stream duration in ms
byte Size of stream description string
byte[] Stream description string
byte Size of stream mime type string
byte[] Mime type string
dword Size of type specific part of the header
byte[] Type specific data, meaning and format depends on mime type

=== Content description header (CONT) ===

This chunk contains some text information (like title, author, ...) about the content of the file. This header has an informative purpose only and it's not needed to demux the file.

A CONT chunk has the following format

dword Chunk type ('CONT')
dword Chunk size
word Chunk version (always 0, for every known file)
word Title string length
byte[] Title string
word Author string length
byte[] Author string
word Copyright string length
byte[] Copyright string
word Comment string length
byte[] Comment string

=== Data header (DATA) ===

This chunk contains a group of data packets. Packets from each stream are interleaved, except for multirate files.

A DATA chunk has the following format

dword Chunk type ('DATA')
dword Chunk size
word Chunk version (always 0, for every known file)
dword Number of data packets in this chunk
dword Offset of the next DATA chunk (form the start of the file)
byte[] Data packets

Each data packet has this format

word Packet version (0 or 1 in available samples)
word Packet size
word Stream number
dword Timestamp
byte Unknown
byte Flags (bitfield, see below)
#if version == 1
byte Unknown
#endif
byte[] Stream-specific data

Flags:
* bit 0: reliable packet (refers to network transmission method)
* bit 1: keyframe

Note:
The previous description of the data packet comes from working demuxer code, the description in official Real docs (somewhere on Helix site) is a bit different:

word Packet version
word Packet size
word Stream number
dword Timestamp
#if version == 0
byte Packet group
byte Flags (bitfield, see below)
#endif
#if version == 1
word ASM rule
byte ASM flags
#endif
byte[] Stream-specific data

where packet group is "The packet group to which the packet belongs. If packet grouping is not used, set this field to 0 (zero)", asm rule is "The ASM rule assigned to this packet" and asm flags "Contains HX_ flags that dictate stream switching points".

=== Index header (INDX) ===

This chunk contains index entries. It comes after all the DATA chunks.
An index chunk contains data for a single stream, A file can have more than one INDX chunk.

A INDX chunk has the following format

dword Chunk type ('INDX')
dword Chunk size
word Chunk version (always 0, for every known file)
dword Number of entries in this chunk
word Stream number
dword Offset of the next INDX chunk (form the start of the file)
byte[] Index entries

Each index entry has this format

word Entry version (always 0, for every known file)
dword Timestamp (in ms)
dword Packet offset in file (form the start of the file)
dword Packet number

== Codecs ==

Codecs in RealMedia are identified by the following four character codes:

===== Audio =====

* [[RealAudio 14.4|lpcJ]] - RealAudio 1.0 (VSELP)
* [[RealAudio 28.8|28_8]] - RealAudio 2.0 (LD-CELP)
* [[RealAudio_dnet|dnet]] - AC3
* [[RealAudio_sipr|sipr]] - Sipro
* [[RealAudio_cook|cook]] - Cook
* [[RealAudio_atrc|atrc]] - ATRAC
* [[Real Lossless Codec|ralf]] - RealAudio Lossless Format
* [[RealAudio_raac|raac]] - LC-AAC
* [[RealAudio_racp|racp]] - HE-AAC

===== Video =====

* [[RealVideo|RV10]] - H.263
* [[RealVideo|RV13]] - H.263
* [[RealVideo G2|RV20]] - H.263+
* [[RealVideo 3|RV30]] - Unknown format
* [[RealVideo 4|RV40]] - Unknown format

[[Category: Container Formats]]

RealMedia

2006-12-19T22:11:43Z

Roberto: DATA header and data packets

* Extensions: rm, ra, rmvb
* Company: [[Real]]

Multimedia container format developed by [[Real]] and used almost exclusively for codecs developed by Real.

The old .ra files are just for audio. The newer RealMedia (.rm) files are for audio and video.

== RA Format ==

This is the old audio-only RealAudio file format.
A very similar structure is also used to describe audio streams in RM files.

The audio data part is just a stream of bytes with no structure.
There is no index in .ra files, but seeking is possible because the codecs are CBR.

=== RealAudio 1.0 file (.ra version 3) ===

This is from the very first version of RealAudio (1995). These files can only contain [[RealAudio 14.4|8kbps VSELP]] audio data. A FourCC (lpcJ) may be present, but it is ignored. Byte order is big-endian.

byte[4] Header signature ('.', 'r', 'a', 0xfd)
word Version (always 3)
word Header size, not including first 8 bytes
byte[10] Unknown
dword Data size
byte Title string length
byte[] Title string
byte Author string length
byte[] Author string
byte Copyright string length
byte[] Copyright string
byte Comment string length
byte[] Comment string
byte Unknown *
byte Fourcc string length (always 4) *
byte[] Fourcc string (always "lpcJ") *
Audio data

Notes:
* Fields marked with * may be missing. Based on the only known sample with no FourCC, it's assumed that all these fields are either present or missing. To determine if they are missing, check the header size (bytes 6-7).
* The informative fields (title, author, copyright and comment) can have zero length.

=== RealAudio 2.0 file (.ra version 4) ===

This is second version of the RealAudio file format. It is distinguished from the above by the value in byte 5 (=0x04). This type of file must contain a valid FourCC to identify the audio codec.

Possible fourCC values are [[RealAudio 28.8|28_8]], [[RealAudio_dnet|dnet]] and [[RealAudio_sipr|sipr]].

byte[4] Header signature ('.', 'r', 'a', 0xfd)
word Version (always 4)
word Unused (always 0)
byte[4] ra4 signature (always ".ra4")
dword Data size - 0x27
word Version2 (always equal to version)
dword Header size - 16
word Codec flavor
dword Coded frame size
byte[12] Unknown
word Sub packet h
word Frame size
word Subpacket size
word Unknown
word Samplerate
word Unknown
word Sample size
word Channels
byte Interleaver ID string length (always 4)
byte[] Interleaver ID string
byte FourCC string length (always 4)
byte[] FourCC string
byte[3] Unknown
byte Title string length
byte[] Title string
byte Author string length
byte[] Author string
byte Copyright string length
byte[] Copyright string
byte Comment string length
byte[] Comment string
Audio Data

Notes:
* The 0x27 in data size is the size of the fixed-length part of the header (up to channels).
* The informative fields (title, author, copyright and comment) can have zero length.

=== .ra version 5 ===

While the .ra header can contain version 5, there are no known RealAudio files with this format, and it's not known if they really exist.

== RealMedia Format ==

This is the newer format which stores both audio and video. All multi-byte numbers are stored in big-endian format.

A RealMedia file consists of a series of chunks. Each chunk has the following format:

dword chunk type ([[FOURCC]])
dword chunk size, including 8-byte preamble
word chunk version
byte[] chunk payload

Real chunk types:
* .RMF: RealMedia file header (only one per file, must be the first chunk)
* PROP: File properties (only one per file)
* MDPR: Stream properties (one for each stream)
* CONT: Content description/metadata (typically one per file)
* DATA: File data
* INDX: File index (typically one per stream)

=== RealMedia file header (.RMF) ===

This must be the first chunk in a RealMedia file. Only one .RMF can be present in a file. The only useful information carried by .RMF is the number of headers.

A .RMF chunk has the following format

dword chunk type ('.RMF')
dword chunk size (typically 0x12)
word chunk version (always 0, for every known file)
dword file version
dword number of headers

Notes:
* All known sample files have version equal to 0.
* There is a sample with chunk size = 0x10, in that case file version is a word. Note that the sample has chunk version = 0 like all other files.

=== File properties header (PROP) ===

This chunk contains some information about the general properties of a RealMedia file. Only one PROP chunk can be present in a file.

A PROP chunk has the following format

dword Chunk type ('PROP')
dword Chunk size (typically 0x32)
word Chunk version (always 0, for every known file)
dword Maximum bit rate
dword Average bit rate
dword Size of largest data packet
dword Average size of data packet
dword Number of data packets in the file
dword File duration in ms
dword Suggested number of ms to buffer before starting playback
dword Offset of the first INDX chunk form the start of the file
dword Offset of the first DATA chunk form the start of the file
word Number of streams in the file
word Flags (bitfield, see below)

Flags:
* bit 0: file can be saved on disk
* bit 1: PerfectPlay can be used (extra buffering)
* bit 2: the file is a live broadcast

=== Media properties header (MDPR) ===

This chunk contains information about the properties of a RealMedia stream. This header defines the type of a stream and the codec used. All codec-related data is in the type specific part of this header.

Many fields share the same meanings as the ones in PROP chunk, but in this case they are specific for one stream.

There is one MDPR chunk for every stream in the file.

A MDPR chunk has the following format

dword Chunk type ('MDPR')
dword Chunk size
word Chunk version (always 0, for every known file)
word Stream number
dword Maximum bit rate
dword Average bit rate
dword Size of largest data packet
dword Average size of data packet
dword Stream start offset in ms
dword Preroll in ms (to be subtracted from timestamps?)
dword Stream duration in ms
byte Size of stream description string
byte[] Stream description string
byte Size of stream mime type string
byte[] Mime type string
dword Size of type specific part of the header
byte[] Type specific data, meaning and format depends on mime type

=== Content description header (CONT) ===

This chunk contains some text information (like title, author, ...) about the content of the file. This header has an informative purpose only and it's not needed to demux the file.

A CONT chunk has the following format

dword Chunk type ('CONT')
dword Chunk size
word Chunk version (always 0, for every known file)
word Title string length
byte[] Title string
word Author string length
byte[] Author string
word Copyright string length
byte[] Copyright string
word Comment string length
byte[] Comment string

=== Data header (DATA) ===

This chunk contains a group of data packets. Packets from each stream are interleaved, except for multirate files.

A DATA chunk has the following format

dword Chunk type ('DATA')
dword Chunk size
word Chunk version (always 0, for every known file)
dword Number of data packets in this chunk
dword Offset of the next DATA chunk (form the start of the file)
byte[] Data packets

Each data packet has this format

word Packet version (0 or 1 in available samples)
word Packet size
word Stream number
dword Timestamp
byte Unknown
byte Flags (bitfield, see below)
#if version == 1
byte Unknown
#endif
byte[] Stream-specific data

Flags:
* bit 0: reliable packet (refers to network transmission method)
* bit 1: keyframe

Note:
The previous description of the data packet comes from working demuxer code, the description in official Real docs (somewhere on Helix site) is a bit different:

word Packet version
word Packet size
word Stream number
dword Timestamp
#if version == 0
byte Packet group
byte Flags (bitfield, see below)
#endif
#if version == 1
word ASM rule
byte ASM flags
#endif
byte[] Stream-specific data

where packet group is "The packet group to which the packet belongs. If packet grouping is not used, set this field to 0 (zero)", asm rule is "The ASM rule assigned to this packet" and asm flags "Contains HX_ flags that dictate stream switching points".

== Codecs ==

Codecs in RealMedia are identified by the following four character codes:

===== Audio =====

* [[RealAudio 14.4|lpcJ]] - RealAudio 1.0 (VSELP)
* [[RealAudio 28.8|28_8]] - RealAudio 2.0 (LD-CELP)
* [[RealAudio_dnet|dnet]] - AC3
* [[RealAudio_sipr|sipr]] - Sipro
* [[RealAudio_cook|cook]] - Cook
* [[RealAudio_atrc|atrc]] - ATRAC
* [[Real Lossless Codec|ralf]] - RealAudio Lossless Format
* [[RealAudio_raac|raac]] - LC-AAC
* [[RealAudio_racp|racp]] - HE-AAC

===== Video =====

* [[RealVideo|RV10]] - H.263
* [[RealVideo|RV13]] - H.263
* [[RealVideo G2|RV20]] - H.263+
* [[RealVideo 3|RV30]] - Unknown format
* [[RealVideo 4|RV40]] - Unknown format

[[Category: Container Formats]]

Intel Music Coder

2006-10-30T21:21:32Z

Roberto: no longer incomplete

* Format: 0x401
* Company: [[Intel]]
* Samples: http://samples.mplayerhq.hu/A-codecs/IMC/

Perceptual audio codec developed by Intel. It features a 256-point MDCT transform and constant bitrate (all known samples are mono and have 512-bit frames). These coefficients are grouped into 32 bands, the first bands hold 3-4 coefficients and the last bands contain 12 coefficients per band. Bit allocation for each coefficient is done adaptively for each frame. The window for MDCT overlap is a simple sine window normalized with sqrt(2).

== Frame Structure ==
All bits are packed into 16-bit little-endian words, MSB first.

9 bits - should always be 0x21
3 bits - frame type
1 bit - flag (used in bit allocation)
<band coefficients>
<band flags>
<coefficient flags>
<coefficients>

=== Band Coefficients ===
Each band should have one coefficient. If the frame type has bit 0x4 set then the first band coefficient should be read explicitly otherwise it should be read using one of 16 Huffman trees depending on frame type and band number (frame type specifies one of 4 sets which contain four static Huffman trees and an array pointing to one of those trees for each band number). If the returned Huffman code is 17 then read 4 additional bits and add their value to the result.

=== Band Flags ===
Each band except bands with coefficient == 16 should have its own flag.

=== Coefficient Flags ===
Coefficient flags are stored either as bits or may be coded as pairs:

0 -> 1, 1
11 -> 0, 1
100 -> 1, 0
101 -> 0, 0

=== Coefficients ===
Coefficients are stored in 1-6 bits with length calculated depending on bits left and bits per band.

[[Category:Audio Codecs]]

Talk:Siren

2006-10-15T11:47:18Z

Roberto:

Do you know if this codec has any relation vith the Vivo Siren audio codec (fourcc 0x112) ?
Vivo siren should be based on G723

--[[User:Roberto|rxt]] 07:47, 15 October 2006 (EDT)

WavPack

2006-10-07T23:31:42Z

Roberto: Add unofficial fourcc

* Extension: wv
* Website: http://www.wavpack.com/
* Samples: http://samples.mplayerhq.hu/A-codecs/lossless/ (luckynight.wv)
* FOURCC (unofficial): WVPK

WavPack is an open source lossless audio coding algorithm with floating point data support and optional lossy audio compression.

== WavPack v.4 ==
=== File Format ===
General details of WavPack format can be found in file 'format.txt' in wavpack sources archive.
WavPack file consists of blocks each beginning with 'wvpk'. Every block contains all information about sound data - sampling rate, channels, bits per sample, etc.
and so-called metadata. Metadata may contain different coefficients using for restoring samples, correction bitstream and actual compressed samples.

=== Block structure ===
Each block contains compressed data

Block header (all data is stored in little-endian words)
4 bytes - 'wvpk'
32 bits - block size
16 bits - version
8 bits - track number
8 bits - track sub index
32 bits - total samples in file (may be 0xFFFFFFFF)
32 bits - offset in samples for current block (i.e. how much samples should be decoded by now)
32 bits - samples in this block
32 bits - flags
32 bits - CRC

Flags meaning:
bits 0- 1 - bytes per sample minus one
bit 2 - sound is monaural
bit 3 - hybrid profile (lossy compression)
bit 4 - joint stereo coding scheme
bit 5 - cross-decorrelation scheme is used
bit 6 - shaping for hybrid profile is present
bit 7 - floating point data present
bit 8 - int32 mode
bits 9-10 - hybrid profile flags
bits 11-12 - multi-channel start and end blocks
bits 13-17 - shift parameter?
bits 18-22 - scaling parameter?
bits 23-26 - sampling rate index

=== Metadata ===
Metadata can be divided into three parts: ID, length and data. Every metadata block has even length and data size is stored in words in either one or three bytes depending on ID flag

Flags for ID:
0x20 - decoder may ignore data contained here
0x40 - data size is odd
0x80 - data size is large

IDs:
* 0x01 - encoder info
* 0x02 - decorrelation terms
* 0x03 - decorrelation weights
* 0x04 - decorrelation samples
* 0x05 - entropy info
* 0x0A - packed samples

=== Decorrelation terms ===
Decorrelation terms are stored in one byte, lower 5 bits indicate predictor type, high 3 bits contain delta value.

Possible predictor values:
0-5 - predictors for stereo, only predictors 2-4 are implemented
6-12 - predictor uses 1-7 samples for prediction
13-16 - reserved
17-18 - predictor does prediction by two samples

=== Decorrelation weights ===
Each decorrelation term should have one or two weights depending on channels.
Each weight is packed into one byte and can be restored in this way:

n = getchar() << 3;
if(n > 0) n += (n + 64) >> 7;

=== Decorrelation samples ===
Each decorrelation term may have up to 16 samples depending on its value. Each sample is 32-bit but stored in 16 bits, lower 8 bits are mantiss and high 8 bits are exponent-9, i.e if exponent < 9 shift mantiss right, otherwise left

=== Entropy info ===
This section contains one or two sets of medians for samples decoding. Each median is log-packed into 16 bits as described above.

=== Samples coding ===
Samples are stored in metadata block with ID=0x0A and are packed with modified Golomb codes. Decoding process is specified below where get_unary() is the function which returns length of '1'-bits string (i.e. 111110b = 5, 10b = 1).
Codeset is adaptively divided into four sets and every code has unary prefix (possibly escaped) defining interval of this code and mantis part like in Golomb code.

if(last_zero){
n = 0;
last_zero = 0;
}else{
n = get_unary();
if(n == 16){
n2 = get_unary();
if(n2 < 2) n += n2;
else n += (1 << (n2-1)) | getbits(n2-1);
}
last_one = n & 1;
if(last_one)
n = (n>>1) + 1;
else
n = n >> 1;
last_zero = !last_one;
}
if(n == 0){
base = 0;
add = median[0] - 1;
decrease median[0];
} else if(n == 1){
base = median[0];
add = median[1] - 1;
increase median[0];
decrease median[1];
} else {
base = median[0] + median[1] + median[2] * (n - 2);
add = median[2] - 1;
increase median[0];
increase median[1];
if(n == 2) derease median[2];
else increase median[2];
}
k = log2(add);
ex = (1 << k) - add - 1;
t2 = getbits(k - 1);
if(t2 >= ex)
t2 = t2 * 2 - ex + getbit();
sign = getbit();
if(sign==0) result = base + t2;
else result = ~(base + t2);

[[Category:Container Formats]]
[[Category:Audio Codecs]]
[[Category:Lossless Audio Codecs]]

True Audio

2006-10-07T23:30:39Z

Roberto: Add unofficial fourcc

* Extension: tta
* Website: http://www.true-audio.com/
* Theory/Whitepaper: http://www.true-audio.com/codec.theory
* Samples: http://samples.mplayerhq.hu/A-codecs/lossless/ (luckynight.tta)
* FOURCC (unofficial): TTA1

True Audio (TTA) is an open source lossless audio coding algorithm.

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

FFmpeg Wishlist

2006-06-04T17:31:02Z

Roberto: aac in rm is no longer a wish

A temporary FFmpeg wish/todo list:

* implement seeking in flv files
* improve flv demuxer, print name of missing codec support
* improved documentation (web,manpage)
* improve ac3 encoder (implement block switching)
* implement radix-4 fft routines
* implement iff demuxer (with anim and sound decoding)
* clean up alac decoder
* implement dts in wav support
* implement raw dts support
* implement Bethsoft VID demuxer/decoder
* implement proper piping
* clean up the building process so muxers and demuxers can individually be disabled
* clean up this patch enough to commit it [http://thread.gmane.org/gmane.comp.video.ffmpeg.devel/28596/focus=28599]
* implement flv v1.1 metadata muxing, look at [http://inlet-media.de/flvtool2 http://inlet-media.de/flvtool2] for more info
* implement grabbing from video devices under windows
* implement a Monkey's Audio decoder, look at the c++ sdk sources
* implement a JPEG2000 decoder
* integrate speex, glue code or native implementation
* write a ffmpeg man page

== [[Snow]] ==
* multiple reference frames improvements
** decide which frames to keep (e.g. long-term refs)
** some changes to the mv prediction code
* non translational motion compensation
** estimate non translational parameters per block by using surrounding motion vectors
** add a ac coded bit per block to switch between translational and non-translational MC
** borrow the non translational MC code from libmpcodecs/vf_perspective.c
** some changes to the encoder to decide between translational and non t.
* Trellis quantization (select quantized coefficient so as to minimize the rate distrortion
* 4x4 sized block support (we have 16x16 and 8x8 currently)
* 1/8 pel motion compensation / estimation support (pretty much just encoder changes needed which in case of the iterative me should be trivial)
* improve the intra color decision

RealAudio sipr

2006-04-01T13:44:24Z

Roberto: Add flavors

* FOURCC: sipr
* Company: [[Real|RealNetworks]]

Audio codec found in [[RealMedia]] files, not as common as [[RealAudio_cook|cook]].

Allegedly the same codec as [[ACELP.net]]. May be partly based on G.729, however RealAudio predates the finalization of the G.729 specifications for the 6.5 kbit/s and 11.8 kbit/s variants. [http://www.itu.int/rec/recommendation.asp?type=folders&lang=e&parent=T-REC-G.729 ITU-T G.729 page]

Codec library with debugging symbols: [http://wwwa2.kph.uni-mainz.de/ftp/pub/machines/linux/multimedia/v50b3_linux20elf.tar.gz v50b3_linux20elf.tar.gz]

Sipr flavors
0 6.5 Kbps Voice
1 8.5 Kbps Voice
2 5 Kbps Voice
3 16 Kbps Voice

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

ATRAC3

2006-04-01T13:35:35Z

Roberto: Add flavors

FOURCC: atrc

Found in some old [[RealMedia]] files. Suspected to be similar to, or the same as, [[Sony ATRAC]].

Atrc flavors
0 66 Kbps Stereo Music - RA 8
1 94 Kbps Stereo Music - RA 8
2 105 Kbps Stereo Music - RA 8
3 132 Kbps Stereo Music - RA 8
4 146 Kbps Stereo Music - RA 8
5 176 Kbps Stereo Music - RA 8
6 264 Kbps Stereo Music - RA 8
7 352 Kbps Stereo Music - RA 8

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

RealAudio cook

2006-04-01T13:22:50Z

Roberto: Added flavors

* FourCC: cook
* Company: [[Real]]
* Samples: http://www.mplayerhq.hu/MPlayer/samples/real/AC-cook/

RealAudio cook (a.k.a. Cooker a.k.a. gecko) is an audio codec created by [[Real]]. It features different coding modes, of which cook 5.1 is not yet supported by the decoder in [[FFmpeg]].

Cook Flavors
00 8 Kbps Music - RealAudio
01 11 Kbps Music - RealAudio
02 16 Kbps Music - RealAudio
03 20 Kbps Music - RealAudio
04 32 Kbps Music - RealAudio
05 44 Kbps Music - RealAudio
06 64 Kbps Music - RealAudio
07 32 Kbps - RealAudio
08 6 Kbps Music - RealAudio
09 20 Kbps Stereo Music
10 32 Kbps Stereo Music
11 44 Kbps Stereo Music
12 64 Kbps Stereo Music
13 96 Kbps Stereo Music
14 64 Kbps - RealAudio
15 20 Kbps Music High Response - RealAudio
16 32 Kbps Music High Response - RealAudio
17 16 Kbps Stereo Music - RealAudio
18 20 Kbps Stereo Music - RealAudio
19 20 Kbps Stereo Music High Response - RealAudio
20 32 Kbps Stereo Music - RealAudio
21 32 Kbps Stereo Music High Response - RealAudio
22 44 Kbps Stereo Music - RealAudio
23 44 Kbps Stereo Music High Response - RealAudio
24 64 Kbps Stereo Music - RealAudio
25 96 Kbps Stereo Music - RealAudio
26 12 Kbps Stereo Music - RealAudio
27 64 kbps Stereo Surround - RealAudio
28 96 kbps Stereo Surround - RealAudio
29 44 kbps Stereo Surround - RealAudio
30 96 Kbps 5.1 Multichannel - RealAudio 10
31 132 Kbps 5.1 Multichannel - RealAudio 10
32 184 Kbps 5.1 Multichannel - RealAudio 10
33 268 Kbps 5.1 Multichannel - RealAudio 10

[[Category:Audio Codecs]]
[[Category:Incomplete Audio Codecs]]

RealVideo 4

2006-03-27T19:25:49Z

Roberto: Clarify RealVideo 9/10

* FourCC: rv40
* Company: [[Real]]
* Samples: http://www.mplayerhq.hu/MPlayer/samples/real/VC-RV40/

RealVideo 4 is available in [[RealPlayer]] starting with version 9. RealVideo 10 (introduced with RealPlayer 10) uses the same RV40 video format, and can be played by RealPlayer 9 decoder. All Realvideo 10 enhancements are in the encoder.

RV40 is suspected to be based on [[H.264]].

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

RealMedia

2006-03-04T15:24:53Z

Roberto: Rename "Genre" as interleaver ID ("genr" is just the name of the generic interleaver)

* Extensions: rm, ra, rmvb
* Company: [[Real]]

Multimedia container format developed by [[Real]] and used almost exclusively for codecs developed by Real.

The old .ra files are just for audio. The newer RealMedia (.rm) files are for audio and video.

== RA Format ==

This is the old audio-only RealAudio file format.
A very similar structure is also used to describe audio streams in RM files.

The audio data part is just a stream of bytes with no structure.
There is no index in .ra files, but seeking is possible because the codecs are CBR.

=== RealAudio 1.0 file (.ra version 3) ===

This is from the very first version of RealAudio (1995). These files can only contain [[RealAudio 14.4|8kbps VSELP]] audio data. A FourCC (lpcJ) may be present, but it is ignored. Byte order is big-endian.

byte[4] Header signature ('.', 'r', 'a', 0xfd)
word Version (always 3)
word Header size - 7
byte[10] Unknown
dword Data size
byte Title string length
byte[] Title string
byte Author string length
byte[] Author string
byte Copyright string length
byte[] Copyright string
byte Comment string length
byte[] Comment string
byte Unknown *
byte Fourcc string length (always 4) *
byte[] Fourcc string (always "lpcJ") *
Audio data

Notes:
* Fields marked with * may be missing. Based on the only known sample with no FourCC, it's assumed that all these fields are either present or missing. To determine if they are missing, check the header size (bytes 6-7).
* The informative fields (title, author, copyright and comment) can have zero length.

=== RealAudio 2.0 file (.ra version 4) ===

This is second version of the RealAudio file format. It is distinguished from the above by the value in byte 5 (=0x04). This type of file must contain a valid FourCC to identify the audio codec.

Possible fourCC values are [[RealAudio 28.8|28_8]], [[RealAudio_dnet|dnet]] and [[RealAudio_sipr|sipr]].

byte[4] Header signature ('.', 'r', 'a', 0xfd)
word Version (always 4)
word Unused (always 0)
byte[4] ra4 signature (always ".ra4")
dword Data size - 0x27
word Version2 (always equal to version)
dword Header size - 16
word Codec flavor
dword Coded frame size
byte[12] Unknown
word Sub packet h
word Frame size
word Subpacket size
word Unknown
word Samplerate
word Unknown
word Sample size
word Channels
byte Interleaver ID string length (always 4)
byte[] Interleaver ID string
byte FourCC string length (always 4)
byte[] FourCC string
byte[3] Unknown
byte Title string length
byte[] Title string
byte Author string length
byte[] Author string
byte Copyright string length
byte[] Copyright string
byte Comment string length
byte[] Comment string
Audio Data

Notes:
* The 0x27 in data size is the size of the fixed-length part of the header (up to channels).
* The informative fields (title, author, copyright and comment) can have zero length.

=== .ra version 5 ===

While the .ra header can contain version 5, there are no known RealAudio files with this format, and it's not known if they really exist.

== RealMedia Format ==

This is the newer format which stores both audio and video. All multi-byte numbers are stored in big-endian format.

A RealMedia file consists of a series of chunks. Each chunk has the following format:

dword chunk type ([[FOURCC]])
dword chunk size, including 8-byte preamble
word chunk version
byte[] chunk payload

Real chunk types:
* .RMF: RealMedia file header (only one per file, must be the first chunk)
* PROP: File properties (only one per file)
* MDPR: Stream properties (one for each stream)
* CONT: Content description/metadata (typically one per file)
* DATA: File data
* INDX: File index (typically one per stream)

=== RealMedia file header (.RMF) ===

This must be the first chunk in a RealMedia file. Only one .RMF can be present in a file. The only useful information carried by .RMF is the number of headers.

A .RMF chunk has the following format

dword chunk type ('.RMF')
dword chunk size (typically 0x12)
word chunk version (always 0, for every known file)
dword file version
dword number of headers

Notes:
* All known sample files have version equal to 0.
* There is a sample with chunk size = 0x10, in that case file version is a word. Note that the sample has chunk version = 0 like all other files.

=== File properties header (PROP) ===

This chunk contains some information about the general properties of a RealMedia file. Only one PROP chunk can be present in a file.

A PROP chunk has the following format

dword Chunk type ('PROP')
dword Chunk size (typically 0x32)
word Chunk version (always 0, for every known file)
dword Maximum bit rate
dword Average bit rate
dword Size of largest data packet
dword Average size of data packet
dword Number of data packets in the file
dword File duration in ms
dword Suggested number of ms to buffer before starting playback
dword Offset of the first INDX chunk form the start of the file
dword Offset of the first DATA chunk form the start of the file
word Number of streams in the file
word Flags (bitfield, see below)

Flags:
* bit 0: file can be saved on disk
* bit 1: PerfectPlay can be used (extra buffering)
* bit 2: the file is a live broadcast

=== Media properties header (MDPR) ===

This chunk contains information about the properties of a RealMedia stream. This header defines the type of a stream and the codec used. All codec-related data is in the type specific part of this header.

Many fields share the same meanings as the ones in PROP chunk, but in this case they are specific for one stream.

There is one MDPR chunk for every stream in the file.

A MDPR chunk has the following format

dword Chunk type ('MDPR')
dword Chunk size
word Chunk version (always 0, for every known file)
word Stream number
dword Maximum bit rate
dword Average bit rate
dword Size of largest data packet
dword Average size of data packet
dword Stream start offset in ms
dword Preroll in ms (to be subtracted from timestamps?)
dword Stream duration in ms
byte Size of stream description string
byte[] Stream description string
byte Size of stream mime type string
byte[] Mime type string
dword Size of type specific part of the header
byte[] Type specific data, meaning and format depends on mime type

== Codecs ==

Codecs in RealMedia are identified by the following four character codes:

===== Audio =====

* [[RealAudio 14.4|lpcJ]] - RealAudio 1.0 (VSELP)
* [[RealAudio 28.8|28_8]] - RealAudio 2.0 (LD-CELP)
* [[RealAudio_dnet|dnet]] - AC3
* [[RealAudio_sipr|sipr]] - Sipro
* [[RealAudio_cook|cook]] - Cook
* [[RealAudio_atrc|atrc]] - ATRAC
* [[Real Lossless Codec|ralf]] - RealAudio Lossless Format
* [[RealAudio_raac|raac]] - LC-AAC
* [[RealAudio_racp|racp]] - HE-AAC

===== Video =====

* [[RealVideo|rv10]] - H.263
* [[RealVideo|rv13]] - H.263
* [[RealVideo|rv20]] - H.263+
* [[RealVideo|rv30]] - Unknown format
* [[RealVideo|rv40]] - Unknown format

[[Category: Container Formats]]

RealMedia

2006-03-02T22:34:26Z

Roberto: Start adding MDPR

* Extensions: rm, ra, rmvb
* Company: [[Real]]

Multimedia container format developed by [[Real]] and used almost exclusively for codecs developed by Real.

The old .ra files are just for audio. The newer RealMedia (.rm) files are for audio and video.

== RA Format ==

This is the old audio-only RealAudio file format.
A very similar structure is also used to describe audio streams in RM files.

The audio data part is just a stream of bytes with no structure.
There is no index in .ra files, but seeking is possible because the codecs are CBR.

=== RealAudio 1.0 file (.ra version 3) ===

This is from the very first version of RealAudio (1995). These files can only contain [[RealAudio 14.4|8kbps VSELP]] audio data. A FourCC (lpcJ) may be present, but it is ignored. Byte order is big-endian.

byte[4] Header signature ('.', 'r', 'a', 0xfd)
word Version (always 3)
word Header size - 7
byte[10] Unknown
dword Data size
byte Title string length
byte[] Title string
byte Author string length
byte[] Author string
byte Copyright string length
byte[] Copyright string
byte Comment string length
byte[] Comment string
byte Unknown *
byte Fourcc string length (always 4) *
byte[] Fourcc string (always "lpcJ") *
Audio data

Notes:
* Fields marked with * may be missing. Based on the only known sample with no FourCC, it's assumed that all these fields are either present or missing. To determine if they are missing, check the header size (bytes 6-7).
* The informative fields (title, author, copyright and comment) can have zero length.

=== RealAudio 2.0 file (.ra version 4) ===

This is second version of the RealAudio file format. It is distinguished from the above by the value in byte 5 (=0x04). This type of file must contain a valid FourCC to identify the audio codec.

Possible fourCC values are [[RealAudio 28.8|28_8]], [[RealAudio_dnet|dnet]] and [[RealAudio_sipr|sipr]].

byte[4] Header signature ('.', 'r', 'a', 0xfd)
word Version (always 4)
word Unused (always 0)
byte[4] ra4 signature (always ".ra4")
dword Data size - 0x27
word Version2 (always equal to version)
dword Header size - 16
word Codec flavor
dword Coded frame size
byte[12] Unknown
word Sub packet h
word Frame size
word Subpacket size
word Unknown
word Samplerate
word Unknown
word Sample size
word Channels
byte Genre string length (always 4)
byte[] Genre string
byte FourCC string length (always 4)
byte[] FourCC string
byte[3] Unknown
byte Title string length
byte[] Title string
byte Author string length
byte[] Author string
byte Copyright string length
byte[] Copyright string
byte Comment string length
byte[] Comment string
Audio Data

Notes:
* The 0x27 in data size is the size of the fixed-length part of the header (up to channels).
* The informative fields (title, author, copyright and comment) can have zero length.

=== .ra version 5 ===

While the .ra header can contain version 5, there are no known RealAudio files with this format, and it's not known if they really exist.

== RealMedia Format ==

This is the newer format which stores both audio and video. All multi-byte numbers are stored in big-endian format.

A RealMedia file consists of a series of chunks. Each chunk has the following format:

dword chunk type ([[FOURCC]])
dword chunk size, including 8-byte preamble
word chunk version
byte[] chunk payload

Real chunk types:
* .RMF: RealMedia file header (only one per file, must be the first chunk)
* PROP: File properties (only one per file)
* MDPR: Stream properties (one for each stream)
* CONT: Content description/metadata (typically one per file)
* DATA: File data
* INDX: File index (typically one per stream)

=== RealMedia file header (.RMF) ===

This must be the first chunk in a RealMedia file. Only one .RMF can be present in a file. The only useful information carried by .RMF is the number of headers.

A .RMF chunk has the following format

dword chunk type ('.RMF')
dword chunk size (typically 0x12)
word chunk version (always 0, for every known file)
dword file version
dword number of headers

Notes:
* All known sample files have version equal to 0.
* There is a sample with chunk size = 0x10, in that case file version is a word. Note that the sample has chunk version = 0 like all other files.

=== File properties header (PROP) ===

This chunk contains some information about the general properties of a RealMedia file. Only one PROP chunk can be present in a file.

A PROP chunk has the following format

dword Chunk type ('PROP')
dword Chunk size (typically 0x32)
word Chunk version (always 0, for every known file)
dword Maximum bit rate
dword Average bit rate
dword Size of largest data packet
dword Average size of data packet
dword Number of data packets in the file
dword File duration in ms
dword Suggested number of ms to buffer before starting playback
dword Offset of the first INDX chunk form the start of the file
dword Offset of the first DATA chunk form the start of the file
word Number of streams in the file
word Flags (bitfield, see below)

Flags:
* bit 0: file can be saved on disk
* bit 1: PerfectPlay can be used (extra buffering)
* bit 2: the file is a live broadcast

=== Media properties header (MDPR) ===

This chunk contains information about the properties of a RealMedia stream. This header defines the type of a stream and the codec used. All codec-related data is in the type specific part of this header.

Many fields share the same meanings as the ones in PROP chunk, but in this case they are specific for one stream.

There is one MDPR chunk for every stream in the file.

A MDPR chunk has the following format

dword Chunk type ('MDPR')
dword Chunk size
word Chunk version (always 0, for every known file)
word Stream number
dword Maximum bit rate
dword Average bit rate
dword Size of largest data packet
dword Average size of data packet
dword Stream start offset in ms
dword Preroll in ms (to be subtracted from timestamps?)
dword Stream duration in ms
byte Size of stream description string
byte[] Stream description string
byte Size of stream mime type string
byte[] Mime type string
dword Size of type specific part of the header
byte[] Type specific data, meaning and format depends on mime type

== Codecs ==

Codecs in RealMedia are identified by the following four character codes:

===== Audio =====

* [[RealAudio 14.4|lpcJ]] - RealAudio 1.0 (VSELP)
* [[RealAudio 28.8|28_8]] - RealAudio 2.0 (LD-CELP)
* [[RealAudio_dnet|dnet]] - AC3
* [[RealAudio_sipr|sipr]] - Sipro
* [[RealAudio_cook|cook]] - Cook
* [[RealAudio_atrc|atrc]] - ATRAC
* [[Real Lossless Codec|ralf]] - RealAudio Lossless Format
* [[RealAudio_raac|raac]] - LC-AAC
* [[RealAudio_racp|racp]] - HE-AAC

===== Video =====

* [[RealVideo|rv10]] - H.263
* [[RealVideo|rv13]] - H.263
* [[RealVideo|rv20]] - H.263+
* [[RealVideo|rv30]] - Unknown format
* [[RealVideo|rv40]] - Unknown format

[[Category: Container Formats]]

RealMedia

2006-03-01T21:50:47Z

Roberto: PROP header

RealMedia

2006-02-26T23:46:22Z

Roberto: .RMF

RealMedia

2006-02-26T22:52:10Z

Roberto: Add version, chunk frequency; remove vido and .ar (they are substructures of MDPR)

RealMedia

2006-02-26T21:20:12Z

Roberto: Explain audio data part

RealMedia

2006-02-25T14:50:39Z

Roberto: Add rmvb extension

Talk:RealMedia

2006-02-25T13:31:31Z

Roberto: add signature

Part of the .ra headers can be used in RM files for audio codec description (some new codecs like ralf, or even mp3 in rm, uses their own mimetype != realaudio so they have no .ra header).

I'll extract the common part or .ra when i'll rite thr RM audio part, and then i'll also version 5 details (mostly are unknown ignored bytes)
--[[User:Roberto|rxt]] 08:31, 25 February 2006 (EST)

Talk:RealMedia

2006-02-25T00:15:38Z

Roberto: random notes for myself, let's check how discussion tab works :)

RealMedia

2006-02-25T00:09:23Z

Roberto: Extended and clarified

* Extensions: rm, ra
* Company: [[Real]]

Multimedia container format developed by [[Real]] and used almost exclusively for codecs developed by Real.

The old .ra files are just for audio. The newer RealMedia (.rm) files are for audio and video.

== RA Format ==

This is the old audio-only RealAudio file format.
A very similar structure is also used to descibe audio streams in RM files.

=== RealAudio 1.0 file (.ra version 3) ===

This is from the very first version of RealAudio (1994). These files can only contain [[RealAudio 14.4|8kbps VSELP]] audio data. A FourCC (lpcJ) may be present, but it is ignored.

byte[4] Header signature ('.', 'r', 'a', 0xfd)
word Version (always 3)
word Header size - 7
byte[10] Unknown
dword Data size
byte Title string length
byte[] Title string
byte Author string length
byte[] Author string
byte Copyright string length
byte[] Copyright string
byte Comment string length
byte[] Comment string
byte Unknown *
byte Fourcc string length (always 4) *
byte[] Fourcc string (always "lpcJ") *
Audio data

Notes:
*fields marked with * may be missing. Based on the only known sample with no fourcc, it's assumed that all these fields are either present or missing.
* the informative fields (title, author, copyright and comment) can have zero length.

=== RealAudio 2.0 file (.ra version 4) ===

This is second version of the RealAudio file format. It is distinguished from the above by the value in byte 5 (=0x04). This type of file must contain a valid FourCC to identify the audio codec.

Possible fourcc values are [[RealAudio 28.8|28_8]], [[RealAudio_dnet|dnet]] and [[RealAudio_sipr|sipr]].

byte[4] Header signature ('.', 'r', 'a', 0xfd)
word Version (always 4)
word Unused (always 0)
byte[4] ra4 signature (always ".ra4")
dword Data size - 0x27
word Version2 (always equal to version)
dword Header size - 16
word Codec flavor
dword Coded Frame Size
byte[12] Unknown
word Sub packet h
word Frame Size
word Sub Packet Size
word Unknown
word Sample rate
word Unknown
word Sample size
word Channels
byte genr string length (always 4)
byte[] genr string
byte Fourcc string length (always 4)
byte[] Fourcc string
byte[3] Unknown
byte Title string length
byte[] Title string
byte Author string length
byte[] Author string
byte Copyright string length
byte[] Copyright string
byte Comment string length
byte[] Comment string
Audio Data

Notes:
* the 0x27 in data size is the size of the fixed-length part of the header (up to channels).
* the informative fields (title, author, copyright and comment) can have zero length.

=== .ra version 5 ===

While .ra header can have version 5, there are no known RealAudio files with this format, and it's not known if they really exist.

== RealMedia Format ==

This is the newer format which stores both audio and video. All multi-byte numbers are stored in big endian format.

A RealMedia file consists of a series of chunks. Each chunk has the following format:

bytes 0-3 chunk type ([[FOURCC]])
bytes 4-7 chunk size, including 8-byte preamble
bytes n.. chunk payload

Real chunk types:
* .RMF: RealMedia file header
* PROP: File properties
* MDPR: Stream properties
* CONT: Content description/metadata
* DATA: File data
* INDX: File index
* '.','r','a',0xFD: Legacy RealAudio encapsulation
* VIDO

== Codecs ==

Codecs in RealMedia are identified by the following four character codes:

===== Audio =====

* [[RealAudio 14.4|lpcJ]] - RealAudio 1.0 (VSELP)
* [[RealAudio 28.8|28_8]] - RealAudio 2.0 (LD-CELP)
* [[RealAudio_dnet|dnet]] - AC3
* [[RealAudio_sipr|sipr]] - Sipro
* [[RealAudio_cook|cook]] - Cook
* [[RealAudio_atrc|atrc]] - ATRAC
* [[Real Lossless Codec|ralf]] - RealAudio Lossless Format
* [[RealAudio_raac|raac]] - LC-AAC
* [[RealAudio_racp|racp]] - HE-AAC

===== Video =====

* rv10 - H.263
* rv13 - H.263
* rv20 - H.263+
* rv30 - Unknown format
* rv40 - Unknown format

[[Category: Container Formats]]

Flic Video

2006-02-24T20:13:32Z

Roberto: Video only note

This is the original format used by [[Autodesk]] Animator.

You can find a complete description of the fli/flc format (both container and video codec) here [http://www.compuphase.com/flic.htm http://www.compuphase.com/flic.htm].

==Video Codec==
* FOURCC (unofficial): FLIC
* Frame type: IP (conditional replenishment)
* Company: [[Autodesk]]

The codec uses RGB colorspace: paletted RGB8, RGB15, RGB16, RGB24.<br>RGB8 is tightly coupled with the VGA mode 0x13.

Compression methods are RLE-based.

==Container==
There are many variations of flic container, the most common are the original FLI from Autodesk Animator and the extended FLC from Autodesk Animator Pro.

Flic files are video-only.

The file format is chunk-based.

[[Category:Video Codecs]]
[[Category:Container Formats]]

Flic Video

2006-02-24T20:12:26Z

Roberto: typo

This is the original format used by [[Autodesk]] Animator.

You can find a complete description of the fli/flc format (both container and video codec) here [http://www.compuphase.com/flic.htm http://www.compuphase.com/flic.htm].

==Video Codec==
* FOURCC (unofficial): FLIC
* Frame type: IP (conditional replenishment)
* Company: [[Autodesk]]

The codec uses RGB colorspace: paletted RGB8, RGB15, RGB16, RGB24.<br>RGB8 is tightly coupled with the VGA mode 0x13.

Compression methods are RLE-based.

==Container==
There are many variations of flic container, the most common are the original FLI from Autodesk Animator and the extended FLC from Autodesk Animator Pro.

The file format is chunk-based.

[[Category:Video Codecs]]
[[Category:Container Formats]]

Pegasus Lossless JPEG

2006-02-19T13:19:04Z

Roberto: remove from Undiscovered Video Codecs, playable by lavc

* FOURCCs: JPGL

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

CorePNG

2006-02-17T23:52:10Z

Roberto: Add page with a short description

* FOURCCs: PNG1
* Name: CorePNG
* Frame type: IP

This lossless codec is based on the PNG image format.
Each frame can be encoded as-is (I frame), or can represent a delta from the previous frame (P frame). In both cases the data is compressed with in standard PNG format.

The codec was originally developed to compress subtitles.

The codec supports RGB[A] and YUV colorspaces: in RGB mode every frame is compresses as a PNG image; in YUV mode a frame is stored as 3 PNG images with order Y, U, V,

Here you can find the [http://corecodec.org/projects/corepng CorePNG codec website]

Lossless Codec Libraries

2006-02-05T18:03:27Z

Roberto: remove from "incomplete video codecs" category: codec is ok, doc only is incomplete

''This page is based on the document 'Description of the LCL codecs (MSZH and ZLIB)' by Roberto Togni found at [http://multimedia.cx/lcl.txt http://multimedia.cx/lcl.txt].''

* FOURCCs: MSZH and ZLIB
* Frame type: intra only

These two codecs, used in [[Microsoft Audio/Video Interleaved|AVI]] files, were created by Kenji Oshima to compress digital animation. MSZH is based on a simple proprietary compressor while ZLIB uses deflate method found in the [http://www.zlib.org zlib library] to compress frames.

This description is based on LCL Ver 2.23 dated 2000.09.20.

== Basic Description ==

The codec converts original RGB24 image data to a target colorspace and compresses it with a selected algorithm. The codec can also remove unchanged frames and replace them with null frames, and can filter image data before compression. The only difference between avimszh and avizlib is in the stream compressor. PNG filtering is available only in avizlib. Except for null frames, there is no temporal compression, and all frames can be decoded independently from the others. Each AVI chunk contains one frame. In case of multithreaded mode the two sections are stored into the same chunk.

== File Header ==

Codec information is stored at the end of [[BITMAPINFOHEADER]] structure into AVI header. This structure is 8 bytes longer than the standard structure.

struct {
standard BITMAPINFOHEADER fields

unsigned char unknown[4];
unsigned char imagetype;
unsigned char compression;
unsigned char flags;
unsigned char codec;
} BITMAPINFOHEADER_extended

* unknown:
always [4, 0, 0, 0]

* codec:
1 mszh
3 zlib

* imagetype:
0 [[YUV 1:1:1]]
1 [[YUV 4:2:2]]
2 [[RGB24]]
3 [[YUV 4:1:1]]
4 [[YUV 2:1:1]]
5 [[YUV 4:2:0]]

* compression:
0 mszh: compression
1 mszh: no compression, zlib: hispeed compression
9 zlib: high compression
-1 zlib: normal compression (zlib standard level)

* flags:
bit 0: multithread used
bit 1: nullframe insertion used
bit 3: png fileter used (zlib only)

== Image Types ==

'''(TODO: These should probably be moved to their own pages)'''

=== RGB24 ===

This colorspace is laid out as standard Blue-Green-Red order color data, totaling 3 bytes per pixel.

=== YUV ===

YUV formats can be converted to RGB using the following equations:
R = Y + 1.403V'
G = Y - 0.344U' - 0.714V'
B = Y + 1.770U'
or, in a programmer-friendly form (integer math)
b = ((y << 20) + u * 1858076 + 0x80000) >> 20;
g = ((y << 20) - u * 360857 - v * 748830 + 0x80000) >> 20;
r = ((y << 20) + v * 1470103 + 0x80000) >> 20;
Values are then clamped to 0-255 range.

Please note that these equations don't have the 128 offset value into U and V components.

YUV structure: packed format with various subsampling factors
'''(TODO: add byte order and description for every YUV format)'''

Please note that byte order is different from standard YUV formats with the same name!

== Compression ==

As the codec name suggests, all compressors are lossless.

=== Zlib compression ===

This mode uses the standard zlib deflate method. For algorithm description refer to the zlib docs. The compressor state is reset every frame (decode every frame independently). Compression codes (1, 9, -1) have the same meaning as zlib compression flags. Zlib does not require compression level at decompressor so the value is there only for informational purposes.

=== Mszh ===

No compression: Just does what it says, image is not compressed at all.

Mszh compression: Works by copying blocks from already decoded data.
'''(TODO: add mszh decompression algorithm)'''

== Flags ==

=== Multithreaded ===

The encoded image is split in two independent blocks. The decoder must decode them separately and concatenate the resulting images.
'''(TODO: add length and offset fields)'''

=== Nullframe ===

If one frame is unchanged from the previous frame, the coder replaces the new frame with a null frame.

=== PNG Filter (zlib only) ===

It is unclear why this is called a PNG filter since it has nothing to do with filters used in pnglib. All filters share the same structure, but the implementation depends on the colorspace. PNG filters are line-based, first pixel is stored unchanged, then other values are stored as difference from the previous ones. The filter (if any) is applied between decompression and colorspace conversion.

'''(TODO: add structure for each pngfilter)'''

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

HuffYUV

2006-02-05T18:01:17Z

Roberto: typo

''This page is based on the document 'Description of the HuffYUV (HFYU) Codec' by Roberto Togni found at [http://multimedia.cx/huffyuv.txt http://multimedia.cx/huffyuv.txt].''

* FOURCC: HFYU
* Website: [http://neuron2.net/www.math.berkeley.edu/benrg/huffyuv.html http://neuron2.net/www.math.berkeley.edu/benrg/huffyuv.html]

HuffYUV is a lossless video compressor for [[Microsoft Audio/Video Interleaved|AVI]] files written by Ben Rudiak-Gould. Source code is available and distributed (mostly) under the GNU General Public License. This codec was created to temporarily store video data coming from a capture card for later editing, so its main features are:
* speed: uses simple predictors and original version is heavily optimized.
* quality: lossless, so image is not degraded if read/written many times.
* editable: every frame is intracoded (a.k.a., a keyframe) so there are no interframe dependencies and each frame can be seeked to independently and decoded on its own.

== Tech Notes From Author's Page (referring to v 2.1.1) ==

HuffYUV's algorithm is roughly the same as lossless JPEG: it predicts each sample and Huffman-encodes the error. The predictor functions are:
* "left" (predicts the previous sample from the same channel)
* "gradient" (predicts Left+Above-AboveLeft)
* "median" (predicts the median of Left, Above, and the gradient predictor). Channels are compressed separately, but in RGB mode the channels used are actually R-G, G, and B-G. This yields much better compression than R, G, B.

The error signal in each channel is encoded with its own Huffman table. On compression HuffYUV picks appropriate tables from its built-in collection. These tables are then stored in the output file and used when decompressing. This way future versions of HuffYUV can decompress old files without my having to explicitly support old tables. A Huffyuv-savvy application can also specify the Huffman tables to be used for compression instead of accepting the defaults.

== File Header ==

All information about the image format and predictor are stored into the [[BITMAPINFOHEADER]] structure of the AVI file header.

=== BITMAPINFOHEADER Layout ===

Only the interesting fields are shown here:

HUFFYUV_BITMAPINFOHEADER {
int biSize
[...]
short biBitCount
int biCompression
[...]
Extradata {
BYTE method
BYTE bpp_override
BYTE unused[2]
}
BYTE Compressed_Huffmantables[]
}

Extradata and Compressed_Huffmantables fields are not always there.

biCompression contains "HFYU" FOURCC.

biSize is the size of the whole structure and it is used to find out if extra fields are there, since size of standard BITMAPINFOHEADER is known.

To find out image format you need to get true bit count: it is stored in bpp_override if biSize > sizeof(BITMAPINFOHEADER), else (or if bpp_override is 0) it is stored in biBitCount. Then you can retrieve the image format with this table

+-----+-------+
| bit | image |
+-----+-------+
| 16 | YUY2 |
| 24 | RGB |
| 32 | RGBA |
+-----+-------+

In the rest of this description YUV will indicate image of type [[YUY2]], and RGB will be used for both RGB and RGBA.

To find out the prediction method you have to mask the 3 least significant bits of biBitCount (biBitCount & 0x07) and use them to index into this table:

+-----+-------------+
| bit | method |
+-----+-------------+
| 000 | see below |
| 001 | left |
| 010 | left decorr |
| 011 | gradient * |
| 100 | median |
+-----+-------------+

If the gradient method is selected (011) and the colorspace is RGB, the method is actually gradient with decorrelation.

If (biBitCount & 0x07) is 0, method is stored in extradata if biSize > sizeof(BITMAPINFOHEADER), else method is predict_old (the method used in version 1.x, it's the same as predict left). To find out method from extradata method byte use this table

+------+-----------------+
| byte | method |
+------+-----------------+
| -2 | old |
| 0 | left |
| 1 | gradient |
| 2 | median |
| 64 | left decorr |
| 65 | gradient decorr |
+------+-----------------+

Huffman tables may be stored in the file (v2.x) or not (v1.x). If biSize = sizeof(BITMAPINFOHEADER) tables are not stored into file, and to decode data the decoder must know classic tables, choosing
RGB or YUV as appropriate. Otherwise, tables are stored in file: if (biBitCount & 0x07) = 0 tables start at the end of BITMAPINFOHEADER, else they start after Extradata.

== Huffman Tables ==

Huffman tables are stored in file compressed with a run-length algorithm. This is what Ben Rudiak-Gould says about it in source code (tables.cpp)

// The Huffman tables are run-length encoded. (I could have Huffman-
// encoded them, but the madness has to end somewhere.) The
// decompression algorithm is as follows: Read a byte. The lower five
// bits are the value to repeat. If the upper three bits are zero, the
// repeat count is in the next byte; otherwise, the upper three bits are
// the repeat count. The tables are zero-terminated so that I can use
// string functions on them (a zero byte can never appear in the RLE
// data).

// Each array actually contains three Huffman tables, one for each sample
// type (e.g. Y,U,V, or R-G,G,B-G). Each table expands to 256 bytes, and
// each byte is a code length. The codes themselves are determined at
// run time and are not stored here--except for the "classic" tables,
// which don't fit the code-choosing algorithm.

When the 3 tables are available (either extracted and decompressed, or known because the file was compressed with v1.x of the codec) the decoder can extract data from the encoded byte stream.

Tables are stored in file in this order:
* YUV: Y_table, U_table, V_table
* RGB: B_table, G_table, R_table
* RGB with decorrelation: B-G_table, G_table, R-G_table

== Frame decompression ==

=== General info ===

One frame is stored per AVI chunk. All frames in file are marked as keyframes. You only need data from current chunk and file header to decompress a frame (no knowledge of previous frames or frame position in file is needed).

=== Operating Algorithm ===

The HuffYUV codec compresses an image by predicting the value of a pixel from its neighbors, and computes an error value (delta) by subtracting it from the effective pixel value. The result of this operation is then compressed with a Huffman algorithm, using a different table for each channel. To decompress a frame the decoder needs to reverse this process: extract the error value from the compressed Huffman stream, then reconstruct the pixel value by computing the predictor value and adding it to the error value. To make this process possible you need a start value (the first pixel in a frame) and a predictor that uses only values from past pixels (already decompressed). Obviously, all predictors used in HuffYUV satisfy this requirement.

All pixel component values must be treated as unsigned bytes. In all computations overflow or underflow causes a wrap-around (i.e., no saturation).

If decorrelation is used (RGB only), then instead of compressing R, G, B components the codec compresses R-G, G, B-G usually resulting in better compression. To reconstruct B and R values you have to add them the value of G taken from the same pixel.

=== Bitstream ===

The components of the image are compressed with different Huffman tables and then the bitstreams are interleaved.

As an example suppose there are 3 components (the values represent the difference between the pixel value and the predictor output). The byte sequence [ABC][DEF][GHI][LMN] is compressed in this way:
* Compress each byte of the first triplet [ABC] using the Huffan table associated with its component. The decoder will output 3 variable length codes. Suppose you get aaaa by compression of A, bbbbbbb from B and ccc from C. The output bitstream will be aaaabbbbbbccc.
* Repeat the process for every triplet, adding the new bits at the end of the stream. If compression of [DEF] will give dddd eee fffff, the output stream after second pixel will be aaaabbbbbbcccddddeeefffff.

To decompress this sequence, keep extracting bits from the stream until you get a valid code (the table contains all valid codes), and then you decode it using the table associated with that component. In the example above you will get the 4 bit aaaa and decode them to A. After decoding the current component you need to remove decoded bits from the stream (the bitstream now contains bbbbbbcccddddeeefffff), and start decoding the next component. When the first triplet [ABC] is decoded the stream will be ddddeeefffff, and the decoder is ready to start again with the first component of the next pixel.

=== Data order ===

This is how data is stored in then encoded stream. The meaning of the stream format line is:
* a capital letter is used to indicate an uncompressed value 1 byte long
* small letters represent Huffman-coded values
The length in bits of Huffman-coded values depend on the size of the code word (after decompression all delta values are 1byte long).

==== YUV Data ====
Image data is encoded and decoded left to right, top to bottom. Each pixel pair is represented by 4 bytes using YUY2 format. Frame width is always even.
Stream format: Y U Y V y u y v y u y v ....
where YUYV are the first two pixels, and y, u, v are the error values. y is decompressed with Y_table, u with U_table and v with V_table.

==== RGB Data ====
Image is stored left to right, bottom to top. Each pixel is represented by 3 bytes, using BGR24 format.
Stream format: X B G R b g r b g r ....
where X is unused, BGR is the first pixel, and b, g, r are the error values. b is decompressed with B_table, g with G_table and r with R_table.

==== RGB Data With Decorrelation ====
Image is stored left to right, bottom to top. Each pixel is represented by 3 bytes, using BGR24 format.
Stream format: X B G R g bg rg g bg rg ....
where X is unused, BGR is the first pixel, and g, bg, rg are the error values. g is decompressed with G_table, bg with B-G_table and rg with R-G_table.

==== RGBA Data ====
Image is stored left to right, bottom to top. Each pixel is represented by 4 bytes, using BGR24 format plus alpha channel.
Stream format: B G R A b g r a b g r a ....
where BGRA is the first pixel, and b, g, r, a are the error values. b is decompressed with B_table, g with G_table, r with R_table and a with R_table.

==== RGBA Data With Decorrelation ====
Image is stored left to right, bottom to top. Each pixel is represented by 4 bytes, using BGR24 format plus alpha channel.
Stream format: B G R A g bg rg a g bg rg a ....
where BGRA is the first pixel, and g, bg, rg, a are the error values. g is decompressed with G_table, bg with B-G_table, br with R-G_table and a with R-G_table.

== Predictors ==

Predictors are used to guess the value of the next pixel so that the codec needs to store only the error between the real pixel value and the prediction. If the prediction model is good the error will be small, and will compress better than full pixel values.

Valid predictors are:
* YUV: old, left, gradient, median.
* RGB: old, left, left with decorrelation, gradient with decorrelation.

Other combinations (e.g. RGB gradient without decorrelation), while technically feasible, are not used.

While describing predictors, the following symbols are used:
* [A B C]: components of a pixel
* Ayz: component A of pixel at row y and column z
* a, b, c: indices used for columns
* n, m: indices used for rows
* x: index used to indicate the last column of a frame

=== Predict Left, Predict Left With Decorrelation, And Predict Old ===

Predict old is the same as predict left (without decorrelation for RGB case).

The predictor for a pixel component is the same component from previous pixel (previous pair for U, V in YUV case).

Some examples:
* random pixel inside a row, RGB
...... [Ban Gan Ran] [Bam Gam Ram] ......
The predictor for Gam is Gan

* random pixel inside a row, YUV
.......[Y1an Uan Y2an Van] [Y1am Uam Y2am Vam] .......
The predictor for Uam is Uan, for Y1am is Y2an, for Y2am is Y1am

*first pixel in a row (not for first row), RGB
[Ba1 Ga1 Ra1] ........ [Bax Gax Rax]
[Bb1 Gb1 Rb1] ......
The predictor for Rb1 is Rax

*first pixel in a row (not for first row), YUV
[Y1a1 Ua1 Y2a1 Va1] ........ [Y1ax Uax Y2ax Vax]
[Y1b1 Ub1 Y2b1 Vb1] ......
The predictor for Ub1 is Uax, for Y2b1 is Y1b1, for Y1b1 is Y2ax

The first pixel of the picture is stored uncompressed, the rest of the frame is compressed with the predict left algorithm.

=== Predict gradient and predict gradient with decorrelation ===

The predictor for a pixel is given by the sum of the previous pixel (like predict left) and the above pixel (the pixel from the row above at the same column), minus the above left pixel (the pixel from the row above at the previous column).

Some examples:
* random pixel inside a row, RGB
...... [Ban Gan Ran] [Bam Gam Ram] ......
.......[Bbn Gbn Rbn] [Bbm Gbm Rbm]
The predictor for Gbm is (Gbn + Gam - Gan)

* random pixel inside a row, YUV
.......[Y1an Uan Y2an Van] [Y1am Uam Y2am Vam] .......
.......[Y1bn Ubn Y2bn Vbn] [Y1bm Ubm Y2bm Vbm] .......
** The predictor for Ubm is (Ubn + Uam - Uan)
** The predictor for Y1bm is (Y2bn + Y1am - Y2an)
** The predictor for Y2bm is (Y1bm + Y2am - Y1am)

* first pixel in a row (not for first row), RGB
[Ba1 Ga1 R11] ........ [Bax Gax Rax]
[Bb1 Gb1 Rb1] ........ [Bbx Gbx Rbx]
[Bc1 Gc1 Rc1] ......
** The predictor for Rc1 is (Rbx + Rb1 - Rax)

* first pixel in a row (not for first row), YUV
[Y1a1 Ua1 Y2a1 Va1] ........ [Y1ax Uax Y2ax Vax]
[Y1b1 Ub1 Y2b1 Vb1] ........ [Y1bx Ubx Y2bx Vbx]
[Y1c1 Uc1 Y2c1 Vc1] ......
** The predictor for Uc1 is (Ubx + Ub1 - Uax)
** The predictor for Y2c1 is (Y1c1 + Y2b1 - Y1b1)
** The predictor for Y1c1 is (Y2bx + Y1b1 - Y2ax)

The first pixel of the picture is stored uncompressed, and the remainder of the first row is compressed with the predict left algorithm. Other rows are compressed with predict gradient. The above left value for the first pixel of the second row is 0.

Maybe other pixels of the second row should ignore above left values, but I'm not sure about it.

=== Predict Median (YUV only) ===

The predictor for a pixel is given by the median value among the left pixel, the pixel above and the gradient predictor (sum of the previous pixel and the above pixel, minus the above left pixel). The median is obtained by sorting the three values and taking the one in the middle, and have nothing to do
with the mean value of the three numbers. For example, if the left pixel is 0x12, the above pixel is 0x4e and the gradient predictor is 0xaf, the median is 0x4e.

As Ben Rudiak-Gould says on his page, there is no technical reason for this method to be YUV only, he simply didn't implement it for RGB case.

Some examples:
* random pixel inside a row, YUV
.......[Y1an Uan Y2an Van] [Y1am Uam Y2am Vam] .......
.......[Y1bn Ubn Y2bn Vbn] [Y1bm Ubm Y2bm Vbm] .......
** The predictor for Ubm is the median value of Ubn, Uam and (Ubn + Uam - Uan)
** The predictor for Y1bm is the median value of Y2bn, Y1am and (Y2bn + Y1am - Y2an)
** The predictor for Y2bm is the median value of Y1bm, Y2am and (Y1bm + Y2am - Y1am)

* first pixel in a row (not for first row), YUV
[Y1a1 Ua1 Y2a1 Va1] ........ [Y1ax Uax Y2ax Vax]
[Y1b1 Ub1 Y2b1 Vb1] ........ [Y1bx Ubx Y2bx Vbx]
[Y1c1 Uc1 Y2c1 Vc1] ......
** The predictor for Uc1 is the median value of Ubx, Ub1 and (Ubx + Ub1 - Uax)
** The predictor for Y2c1 is the median value of Y1c1, Y2b1 and (Y1c1 + Y2b1 - Y1b1)
** The predictor for Y1c1 is the median value of Y2bx, Y1b1 and (Y2bx + Y1b1 - Y2ax)

The first pixel of the picture is stored uncompressed. The remaining of the first row, and the first 4 pixel (2 pairs, 8 bytes) of the second row are compressed with the predict left algorithm. The rest of the second row and other rows are compressed with predict median.

Technically the second pixel of the second row could be compressed using median predictor; it's compressed with left predictor because original code uses MMX instructions and can handle 8 bytes a time.

== Interlaced images ==

If image height is greater than 288 pixel, the image is treated as interlaced. The decoder must build an image with double width and half height, obtained by placing the two fields side by side, with the odd field on the left. The frame size reported in the file header is unchanged, the only way to find out interlacing is by comparing the image height with 288.

As an example, suppose your original frame is

1111111111111111
2222222222222222
3333333333333333
4444444444444444
5555555555555555
6666666666666666
7777777777777777
8888888888888888

then the frame to be compressed will be

11111111111111112222222222222222
33333333333333334444444444444444
55555555555555556666666666666666
77777777777777778888888888888888

In this way every line on a field gets the values for the predictors from the previous line of the same field, instead of using the previous line of the frame.

Please note that it makes a difference only for prediction methods that use values from the previous line (median and gradient algorithms): if a method refers only to the value of the previous pixel (left algorithms) interlacing can be ignored.

== Final notes ==

The frame width must be divisible by 4 (at least for the original codec).

It is likely that the header parsing logic can be simplified a lot since not every combination of options is valid. This is what I was able to create using dll v2.1.1 and 1.2.3/1.3.1 and VirtualDub under Windows:
* Old format (v1.x only) is only used with classical tables (not stored in file)
* Other methods (v2.1.1) always store tables in file, and uses extradata to store method.

The first two(?) pixels (or 4 bytes) of the second row in predict gradient could be stored in a different way, using only left and above pixel as predictor. None of my samples require this.

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

Helix

2006-01-19T22:12:23Z