Matroska File Format(under construction!)Alexander Noéalex@Last change:January11,2009Contents1Introduction42EBML-basics62.1Unsigned Integer Values of Variable Length(”vint“) (6)2.2EBML elements (7)2.3Signed Integer Values of Variable Length(svint) (7)2.4Data Types (8)3M ATROSKAfiles-Top-Level elements93.1EBML (9)3.2Segment (9)4EBML-The EBMLfile header105Level1-Elements inside Segments125.1Overview (12)5.2SegmentInfo (13)5.3SeekHead (16)5.4Tracks (18)5.5Cluster (27)5.6Cues (29)5.7Chapters-Editions and ChapterAtoms (31)5.8Attachments (35)5.9Tags (36)16M ATROSKA block Layout and Lacing396.1Basic layout of a Block (39)6.2Lacing (40)7Overhead of M ATROSKAfiles417.1Overhead of B LOCK G ROUPS (41)7.2Overhead of C LUSTER s (46)7.3Overhead caused by Cues (47)8Links48 List of Tables1EBML (10)2Segment (12)3SegmentInfo (14)4SeekHead (16)5Seek (16)6Tracks (18)7TrackEntry (18)8Video (21)9Audio (22)10ContentEncodings (23)11ContentEncoding (23)12ContentCompression (24)16Cluster (27)17BlockGroup (28)18Cues (29)19CuePoint (30)20CueTrackPositions (30)21Chapters (31)22EditionEntry (31)23ChapterAtom (32)224ChapterTracks (34)25ChapterDisplay (34)26Attachments (35)27AttachedFile (35)28Tags (36)29Tag (37)30Targets (37)31SimpleTag (38)31IntroductionThis document is intended to be used by developers who want to implement sup-port for the M ATROSKAfile format in their applications,but who want to build this support from scratch rather than using existing implementations,or people who just want to understand the M ATROSKAfile format in detail.Thus,thefile format itself is described,the usage of existing libraries isn’t.This document does not replace the official documentation1.It is less condensed, but not necessarily complete.Especially,in the case that M ATROSKA supports Dig-ital Restrictions Management one day,I will expressively not document that part. Also,typos in element IDs are never impossible.When speaking about element occurence,elements can be mandatory or not,ele-ments may be present several times inside a parent element or not etc.Occurence restrictions will be indicated using expressions like=1or≥1etc.Those re-strictions will exclude cases which do not technically render afile unusable or ambigous,but which are unreasonable,like afile with no S EGMENT UID,see sec-tion5.2.The same way it would be weird(but not make afile unusable)to have a C HAPTERS element(which is supposed to describes chapters)which is empty.An element that must occur at least once is a reasonablefile is called“mandatory”. When an element is really mandatory,i.e thefile or a part of it is useless when it’s missing,it will be labeled as≥1(!)or=1(!).An example would be the codec ID of a track,without which a track cannot be decoded at all.The official Matroska specification pages use the following interpretation of“manda-tory”and“default”:When an element has a default value that is used if the ele-ment itself is not present,the value cannot be missing,thus the element is inher-ently mandatory.This interpretation of“mandatory”being weird,this document considers an element mandatory when it must be physically present in thefile. Also,default values can only be valid values.Consequently,a mandatory element cannot have a default value because if it had one,it couldn’t be mandatory any-more.In this document,element names are always printed like T HIS,element values are printed like$T HIS,as in“if$T HIS F LAG=1,...”.If you have any questions concerning this document,if you have comments,addi-tions,if you have found an error,or if you want to contact me for whatever reason, 1/technical/specs/index.html4please send me an e-mail(include’matroska’in the topic!).You can contact me in german,english or french,whatever you prefer.Just don’t ask me if you can ask something or if I could document some Digital Restrictions Management.This document is powered by LaTeX,so changing the order of certain tables or the style of those tables etc.is,with certain limits,possible within a few seconds. Screenshots of real lifefile structures are used to illustrate thefile structure.All of them have been made using the EBML Tree Viewer in AVI-Mux GUI.52EBML-basicsEBMLfiles use integers of variable size.This way,thefile format doesn’t waste space with storing32or even64bit integers in placed where they might sometimes occur.The way the size is coded is inspired by the UTF-8encoding format.2.1Unsigned Integer Values of Variable Length(”vint“)The length of an integer is equivalent to length=1+[number_of_leading_zero_bits]. All integers use big endian.You could use more than7leading zeros,then thefirst byte would be0x00,however,this would only be needed if integers longer than56bits are required.This is forbidden in M ATROSKAfiles.Example:3A41FE:Thefirst byte3A(00111010)has2leading zeros,resulting in a total length of3 bytes.Thefirst‘1’in the byte(00111010)is just needed tofinish the sequence of leading zeros and can’t be used to store the value either.Thus,it is reset to obtain the value this byte sequence represents.The result is then0X1A41FE.As you can see,you lose one bit per byte to know how long a number is,and you can use7 bits per byte to store the integer’s value itself.Of course,the value0x1A41FE could also be written as101A41FE or08001A41FE(do the decoding on a piece of paper if it’s not clear),however,when writing EBMLfiles,the shortest possible encoding should be used to avoid wasting space, which is the very point of this coding scheme.Unknown LengthAll bits after the leading zeros being set to one,such as FF or7F FF,indicates an unknown length.Muxers shall avoid writing unknown length values whenever possible.The only exception is the last Level0element of afile.If encoding a number as described above results in such a sequence,it must be encoded again with a greater destination length.Example:When encoding16383as described above,the result is7F FF.In7F FF,all bits after the leading zero are set,which would indicate an unknown length.That means,the length is increased to3,and the number is encoded again to203F FF.NoteIt is possible to use a lookup table to determine the total length from thefirst byte.6The Matroskafile format does not allow integer lengths greater than8,meaning that the number of leading zeros is not higher than7and that the total length can always be retrieved from thefirst byte.2.2EBML elementsOne piece of information is stored the following way:typedef struct{vint ID//EBML-IDvint size//size of elementchar[size]data//data}EBML_ELEMENT;The length of ID shall be called s_ID,the length of size shall be called s_size. Elements that contain other EBML Elements are called EBML Master elements. Generally,the order of EBML elements inside a parent element is notfixed.In some cases,a certain order is recommended,but it is never mandatory.Especially, no element order should be assumed inside small parent elements.2.3Signed Integer Values of Variable Length(svint)Signed integers have the following value:Read the integer as Unsigned Integer and then subtractvsint_subtr[length-1]where__int64vsint_subtr[]={0x3F,0x1FFF,0x0FFFFF,0x07FFFFFF,0x03FFFFFFFF,0x01FFFFFFFFFF,0x00FFFFFFFFFFFF,0x007FFFFFFFFFFFFF};72.4Data TypesWhereas vint s are used in the header section of EBML elements,the data types describes in this section occur in the data section.2.4.1Signed and Unsigned Integers(int and uint)Integers,signed as well as unsigned,are stored in big endian byte order,with leading0x00(in case of positive values)and0xFF(in case of negative values) being cut off(example for int:-257is0xFE0xFF).An int/uint may not be larger than8bytes.2.4.2FloatA Float value is a32or64bit real number,as defined in IEEE.80Bit values have been in the specification,but have been removed and should not be used.The bytes are stored in big endian order.2.4.3Types of StringsString refers to an ASCII string.UTF-8refers to a string that is encoded as UTF-883M ATROSKAfiles-Top-Level elementsM ATROSKAfiles only have two different top level elements:3.1EBMLThis header describes the contents of an EBMLfile.There should be only one EBML header in onefile.Any further EBML headers do not render afile invalid, but shall be ignored by any application reading thefile.Files with more than one EBML header could be created for instance if two or morefiles are appended by using the copy/b command.3.2SegmentA S EGMENT contains multimedia data,as well as any header data necessary for re-play.There can be several S EGMENT s in one M ATROSKAfile,but this is not encour-aged to be done,as not many tools are able to handle multisegment M ATROSKA files correctly.If you want to replay multisegment M ATROSKAfiles on Windows, please use Haali Media splitter22http://haali.cs.msu.ru/mkv/94EBML-The EBMLfile headerThe EBML top level element contains a description of thefile type,such as EBML version,file type name,file type versionetc.Obviously,this header being missing makes it necessary to guess thefile type.Table1:The EBML element(Top-Level)Element Descriptionuint,#≤1 EBMLV ERSION ID:4286 def:1indicates the version of the EBML Writer that has been used to create afileuint,#≤1 EBMLR EAD V ERSION ID:42F7def:1indicates the minimum version an EBML parser needs to be compliant with to be able to read thefileuint,#≤1EBMLM AX IDL ENGTH ID:42F2def:4indicates the length of the longest EBML-ID thefile contains. In case of matroska,this value is4.Any EBML-ID which is longer than the value of this element shall be considered invalid.uint,#≤1EBMLM AX S IZE L ENGTH ID:42F3def:8indicates the maximum s_size value thefile contains.Any EBML element having an s_size value greater than EBML-MaxSizeLength shouldl be considered invalid.EBML continued on next page10Element Descriptionstring,#≤1 D OC T YPE ID:4282 def:matroska describes the contents of thefile.In the case of a M ATROSKA file,its value is'matroska'uint,#≤1D OC T YPE V ERSION ID:4287def:1indicates the version of the$D OC T YPE writer used to create thefileuint,#≤1D OC T YPE R EAD V ERSION ID:4285def:1indicates the minimum version number a$D OC T YPE parser must be compliant with to read thefile.Index→page2end of EBML As you can see,in the case of Matroskafiles all child elements of the EBML el-ement have a default value.Thus,an empty EBML element would technically introduce a Matroskafile(withfile type version1,maximum ID length4,max-imum size length8etc.)correctly.However,I don’t recommend to push the specifications like this.It is not recommended to use either IDs or size values greater than8bytes.While it’s clear that8bytes are enough to represent any size of anything on any hard disc,one might think about using IDs larger than8bytes.However,since the ID is considered an integer,treating IDs larger than8bytes is difficult on current CPUs, which are limited to64bit for simple integer operations.115Level1-Elements inside Segments 5.1OverviewTable2:The S EGMENT element(Top-Level) Element DescriptionMaster,#=1S EGMENT I NFO(→3) ID:1549A966S EGMENT I NFO contains general information about a seg-ment,like an UID,a title etc.This information is not really required for playback,but should be there(→section5.2).Master,#≥0S EEK H EAD(→4) ID:114D9B74A S EEK H EAD is an index of elements that are children of S EGMENT.It can point to other S EEK H EAD s,but not to itself. If all non-C LUSTER precede all C LUSTER s(→section5.5), a S EEK H EAD is not really necessary,otherwise,a missing S EEK H EAD leads to longfile loading times or the inability to access certain data.Master,#≥0C LUSTER(→16) ID:1F43B675A C LUSTER contains video,audio and subtitle data.Note that a M ATROSKAfile could contain chapter data or attach-ments,but no multimedia data,so C LUSTER is not a manda-tory element.S EGMENT continued on next page12Element DescriptionMaster,#≥0T RACKS(→6) ID:1654AE6B A T RACKS element contains the description of some or all tracks(preferably all).This element can be repeated once in a while for backup purposes.Afile containing only chapters and attachments does not have a T RACKS element,thus it’s not mandatory.Master,#≤1C UES(→18) ID:1C53BB6B The C UES element contains a timestamp-wise index to C LUSTER s,thus it’s helpful for easy and quick seeking.Master,#≤1A TTACHMENTS(→26) ID:1941A469The A TTACHMENTS element contains allfiles attached to this S EGMENT.Master,#=1C HAPTERS(→21) ID:1043A770The C HAPTERS elements contains the definition of all chap-ters and editions of this S EGMENTMaster,#≤1T AGS(→28) ID:1254C367The T AGS element contains further information about the S EGMENT or elements inside the S EGMENT that is not really required for playback.Index→page2end of S EGMENT5.2SegmentInfoThe S EGMENT I NFO element contains general information about the S EGMENT, such as its duration,the application used for writing thefile,date of creation,a unique128bit ID,to name a few rmation included in the S EGMENT I NFO element is not required for playback,but should be written by any M ATROSKA muxer.13(read:<element name>(<s_size+s_ID>:<size>bytes at<position infile>:value)Table3:The S EGMENT I NFO element,child of S EGMENT(→2) Element Descriptionchar[16],#=1 S EGMENT UID ID:73A4a unique128bit number identifying a S EGMENT.Obviously, afile can only be referred to by anotherfile if a S EGMEN-T UID is present,however,playback is possible without that UID.utf-8,#≤1S EGMENT F ILENAME ID:7384contains the name of thefile the S EGMENT is stored in.Since renamingfiles is easy,the reliability of this element’s value should not be overrated.char[16],#≤1 P REV UIDID:3C B923contains the unique128bit ID of the S EGMENT that is re-played before the currently active S EGMENT,i.e.the ID of the S EGMENT that should be loaded if the user tries to seek to a timecode earlier than the earliest timecode of the ac-tive S EGMENT.That SEGMENT should,of course,be easy to locate,for instance in afile in the same directory.utf-8,#≤1P REV F ILENAME ID:3C83AB contains the name of thefile in which the S EGMENT having the ID$P REV UID is stored.P REV F ILENAME should not be considered reliable for the same reason as S EGMENT F ILE-NAME,however,it could be thefirstfilename the player is looking for when the SEGMENT described in P REV UID is neededS EGMENT I NFO continued on next page14Element Descriptionchar[16],#≤1 N EXT UIDID:3E B923contains the unique128bit ID of the S EGMENT that is re-played after the currently active S EGMENT,i.e.the ID of the S EGMENT that should be loaded if the user tries to seek to a timecode after the end of the active S EGMENT.Like P RE-V UID,the corresponding S EGMENT should be easy to locate.utf-8,#≤1N EXT F ILENAME ID:3E83BB contains the name of thefile in which the S EGMENT having the ID$N EXT UID is stored.N EXT F ILENAME shall not be considered reliable for the same reason as S EGMENT F ILE-NAME.uint,#≤1T IMECODE S CALE ID:2A D7B1Each scaled timecode in a M ATROSKAfile is multiplied by T IMECODE S CALE to obtain a timecode in nanoseconds.Note that not all timecodes are scaled!float,#≤1 D URATION ID:4489The D URATION indicates the duration of the S EGMENT.The duration measured in nanoseconds is scaled and is thus equal to$D URATION*$T IMECODE S CALE.This element should be written.utf-8,#≤1 T ITLEID:7B A9Contains a general name of the S EGMENT,like Lord of the Rings-The Two Towers .No language can be at-tached to the title,however,Tags(→section5.9)could be used to define several titles for a segment.This is not yet commonly done,though.string,#=1 M UXING A PP ID:4D80contains the name of the library that has been used to create thefile(like”libmatroska0.7.0“).This element should be written by any muxer!Especially if non-compliantfiles are encountered,this help to know who must be blamed for that file.utf-8,#=1 W RITING A PP ID:5741contains the name of the application used to create thefile (like”mkvmerge0.8.1“).This element should be written for the same reason as M UXING A PP.int,#≤1 D ATE UTC ID:4461contains the production date,measured in nanoseconds rel-atively to Jan01,2001,0:00:00GMT+0hIndex→page2end of S EGMENT I NFO155.3SeekHeadThe S EEK H EAD element contains a list of positions of Level1elements in the S EGMENT.Each pair(element id,position)is stored in one S EEK element: Table4:The S EEK H EAD element,child of S EGMENT(→2) Element DescriptionMaster,#≥1 S EEK(→5) ID:4D BB One S EEK element contains an EBML-ID and the position within the S EGMENT at which an element with this ID can be found.Index→page2end of S EEK H EAD Table5:The S EEK element,child of S EEK H EAD(→4) Element Descriptionuint,#=1 S EEK ID ID:53AB The S EEK ID element contains the EBML-ID of the element found at the given positionuint,#=1S EEK P OSITION ID:53AC The S EEK P OSITION element contains the position relatively to the S EGMENT’s data at which an element with the ID $S EEK ID can be found.Index→page2end of S EEK Not all Level1elements need to be included.Typical S EEK H EAD s either include a list of all Level1elements,or a list of all Level1elements except for C LUSTER s (→section5.5).S EEK H EAD s can also include references to other S EEK H EAD s if there is,for example,a small S EEK H EAD at the beginning of thefile and a larger one at its end.The following picture illustrates the S EEK H EAD element in a realfile.Note that the EBML Tree Viewer replaced Level1IDs in S EEK ID with their human-readable name:16175.4TracksThe T RACKS element contains information about the tracks that are stored in the S EGMENT,like track type(audio,video,subtitles),the used codec,resolution and sample rate.All tracks shall be described in one(or more,but preferably only one) T RACKS element.Each track is described in one T RACK E NTRY.Theoretically,using the T RACK UID, information about one track could be spread over different T RACK E NTRY s,the UID would allow to know which track the information applies to,however,it is highly discouraged to stretch the specification like this.Also,an empty T RACKS element would be rather useless,but should not lead to a parser error since thefile can be played if all tracks are defined somewhere.Es-pecially pure chapterfiles might have an empty T RACKS element if the muxer doesn’t catch the case that no tracks are present and consequently creates an empty T RACKS element.An example of a T RACK E NTRY element can be found on(→page25)Table6:The T RACKS element,child of S EGMENT(→2)Element DescriptionMaster,#≥1T RACK E NTRY(→7) ID:AE One T RACK E NTRY element describes one track of the S EG-MENTIndex→page2end of T RACKS Table7:The T RACK E NTRY element,child of T RACKS(→6)Element Descriptionuint,#=1(!) T RACK N UMBER ID:D7defines an identification number of the track.This number cannot be equal to0.This number is used by the B LOCK and S IMPLE B LOCK structures.uint,#=1 T RACK UID ID:73C5is a unique identificator of the track within thefile.It cannot be equal to0T RACK E NTRY continued on next page18uint,#=1(!)T RACK T YPE(→13)ID:83defines the type of a track,i.e.video,audio,subtitle etc.bool,#≤1F LAG E NABLEDID:B9def:1When F LAG E NABLED is1,track is usedbool,#≤1 F LAG D EFAULT ID:88def:1When F LAG D EFAULT is1,the track should be selected by the player by default.Obviously,if no video track and/or no audio track has a defaultflag,one video track and one audio track should be chosen by the player,whereas no subtitle should be enabled if no subtitle has a defaultflag.bool,#≤1 F LAG F ORCED ID:55AA def:0When F LAG F ORCED is1,the track must be played.When several subtitle tracks are forced,the one matching the au-dio language should be chose.An example would be a sub-title track that cannot be disabled,like the one youfind on the german DVD“Eiskalte Engel”when you select english audio.Since thisflag can only be used to apply a restriction on digital content,it must be qualified as Digital Restrictions Management.bool,#≤1 F LAG L ACING ID:9C def:0When F LAG L ACING is1,the track may contain laced blocks.A parser that supports all types of lacing(→section6.2)can safely ignore thisflag.uint,#≤1 M IN C ACHE ID:6D E7 def:0indicates the number of frames a player must be able to cache during playback.This is for instance interesting if a native MPEG4file with frames in coding order is played.uint,#≤1 M AX C ACHE ID:6D F8indicates the maximum cache size a player needs to cache frames.A value of NULL means that no cache is required.T RACK E NTRY continued on next page19uint,#≤1D EFAULT D URATION ID:23E383This value indicates the number of nanoseconds a frame lasts.This value is applied if no$D URATION value is in-dicated for a frame or if lacing(→section6.1)is used.A value of0means that the duration of frames of the track is not necessarily constant(e.g.variable framerate video, or Vorbis audio).D EFAULT D URATION should be written for each track with a constant frame rate since it makes seeking easier.float,#≤1T RACK T IMECODE S CALE ID:23314F Every timecode of a block(cluster timecode+block timecode)is multiplied by this value to obtain the real time-code of a block.utf-8,#≤1 N AMEID:536E A N AME element contains a human-readable name for the track.Note that you can’t define which language this track name is in.You have to use Tags(→section5.9))if you want to use several titles in different languages for the same track.string,#≤1 L ANGUAGE ID:22B59C def:eng specifies the language of a track,using ISO639-23.This is NOT necessarily the language of$N AME,for example a german AC3track could be called“German-AC35.1”or “Deutsch-AC35.1”or“Allemand AC35.1”etc.string,#=1(!)C ODEC IDID:86The C ODEC ID specifies the Codec4which is used to decode the track.binary,#≤1 C ODEC P RIVATE ID:63A2C ODEC P RIVATE contains information the codec needs before decoding can be started.An example is the Vorbis initializa-tion packets for Vorbis audio.utf-8,#≤1C ODEC N AMEID:258688C ODEC N AME is a human-readable name of the Codecuint,#≥0A TTACHMENT L INK ID:7446An A TTACHMENT L INK contains the UID of an attachment that is used by this track.T RACK E NTRY continued on next page3/standards/iso639-2/englangn.html 4/technical/specs/codecid/index.html20Master,#≤1V IDEO(→8)ID:E0V IDEO contains information that is specific for video tracksMaster,#≤1A UDIO(→9)ID:E1A UDIO contains information that is specific for audio tracksMaster,#≤1C ONTENT E NCODINGS (→10)ID:6D80C ONTENT E NCODINGS contains information about(lossless) compression or encryption of the trackIndex→page2end of T RACK E NTRY Obviously,the V IDEO element must be present for video tracks,whereas the A UDIO element must be present for audio tracks.Although it doesn’t make sense to have both elements in one T RACK E NTRY element,it wouldn’t make afile unplayable.Table8:The V IDEO element,child of T RACK E NTRY(→7) Element Descriptionuint,#=1P IXEL W IDTHID:B0Width of the encoded video track in pixelsuint,#≤1P IXEL H EIGHTID:BAHeight of the encoded video in pixelsuint,#≤1P IXEL C ROP B OTTOMID:54AAdef:0Number of Pixels to be cropped from the bottomuint,#≤1P IXEL C ROP T OPID:54BBdef:0Number of Pixels to be cropped from the topV IDEO continued on next page21uint,#≤1P IXEL C ROP L EFTID:54CCdef:0Number of Pixels to be cropped from the leftuint,#≤1P IXEL C ROP R IGHTID:54DDdef:0Number of Pixels to be cropped from the rightuint,#≤1D ISPLAY W IDTHID:54B0def:$P IXEL W IDTHWidth of the video during playbackuint,#≤1D ISPLAY H EIGHTID:54BAdef:$P IXEL H EIGHTHeight of the video during playbackuint,#≤1 D ISPLAY U NIT ID:54B2 def:0Unit$D ISPLAY W IDTH and$D ISPLAY H EIGHT is measured in.This can be0→pixels,1→centimeters,2→inchesIndex→page2end of V IDEO $P IXEL C ROPXXXX is applied on$P IXELXXX,so the output is cropped after decod-ing,but before stretching it to the dimensions indicated with$D ISPLAYXXXX.Table9:The A UDIO element,child of T RACK E NTRY(→7) Element Descriptionuint,#≤1S AMPLING F REQUENCYID:B5def:8kHzIndicates the sample rate the track is encoded at in HzA UDIO continued on next page22uint,#≤1O UTPUT-S AMPLING F REQUENCY ID:78B5Indicates the sample rate the track must be played at in Hz.The default value of this element is equal to$S AM-PLING F REQUENCY.uint,#≤1C HANNELSID:9Fdef:1Number of channels of the audio trackuint,#≤1B IT D EPTHID:6264Bits per sample,this is usually used with PCM-Audio. Index→page2end of A UDIOTable10:The C ONTENT E NCODINGS element,child of T RACK E NTRY(→7) Element DescriptionMaster,#≥1C ONTENT E NCODING (→11)ID:6240A C ONTENT E NCODING-element describes one compression or encryption that has been used on this track.Index→page2end of C ONTENT E NCODINGS Table11:The C ONTENT E NCODING element,child ofC ONTENT E NCODINGS(→10)Element Descriptionuint,#≤1C ONTENT E NCODING-O RDERID:5031def:0Tells when to decode according to this pattern.The de-coder starts with the C ONTENT E NCODING that has the high-est C ONTENT E NCODING O RDER.C ONTENT E NCODING continued on next page23uint,#≤1C ONTENT E NCODING-S COPE(→14)ID:5032def:1Defines which parts of the track are compressed or en-crypted this wayuint,#≤1C ONTENT E NCODING-T YPEID:5033def:0Describes which type of encoding is described.0→com-pression,1→encryptionMaster,#≤1C ONTENT C OMPRESSION (→12)ID:5034If C ONTENT E NCODING T YPE=0,this element describes how it is compressedMaster,#≤1C ONTENT E NCRYPTION (→??)ID:5035If C ONTENT E NCRYPTION=1,this element describes how it is encryptedIndex→page2end of C ONTENT E NCODING The C ONTENT E NCODING element allows to apply not only encryption,but also lossless compression to a track.This can be used to compress text subtitles,but also to remove sync headers from audio packets.For example,each AC3frame starts with0B77,and there is no real point in saving those two bytes for each frame in a M ATROSKAfile.For a simple AC3file,this does make sense because there it can be used tofind a new frame start if data is damaged.Table12:The C ONTENT C OMPRESSION element,child ofC ONTENT E NCODING(→11)Element Descriptionuint,#≤1C ONTENT C OMP A LGO (→15)ID:4254def:0The C ONTENT C OMP A LGO element says which algorithm was used for this compression.C ONTENT C OMPRESSION continued on next page24binary,#≤1C ONTENT C OMP S ETTINGS ID:4255Contains settings that are required for decompression. These settings are specific for each compression algorithm. For example,it contains the striped header bytes when $C ONTENT C OMP A LGO=3(→page25).Index→page2end of C ONTENT C OMPRESSION Table13:Values of T RACK T YPE,child of T RACK E NTRY(→7)Value Description0x01track is a video track0x02track is an audio track0x03track is a complex track,i.e.a combined video and audio track0x10track is a logo track0x11track is a subtitle track0x12track is a button track0x20track is a control trackend of T RACK T YPE Table14:Bits in C ONTENT E NCODING S COPE,child ofC ONTENT E NCODING(→11)Value Description1all frames2the track’s C ODEC P RIVATE4the C ONTENT C OMPRESSION in the next C ONTENT E N-CODING(next as in next in decoding order)end of C ONTENT E NCODING S COPEHere is one example of a possible T RACK E NTRY element:A DTS-audio track that is using header striping.The C ONTENT C OMP S ETTINGS element contains the four bytes each DTS frame starts with.25。
![[修订]mkv格式解析](https://img.taocdn.com/s1/m/ae337037bdd126fff705cc1755270722192e5980.png)
