WELCOM

presentation
by
abraham philip

guided by
Dr.P.Mohanan
 CONTENTS
INTRODUCTION.

WHAT IS MATROSKA ?

DIAGRAMATIC REPRESENTATION.

SPECIFICATIONS.

COMPARISON OF DIFFERENT CONTAINERS.

INTRODUCTION
Open Standards Multimedia Container Project.

Licensed under GNU L –GPL.

Free Parsing & Playback Libraries for commercial

software & hardware adoption.
MULTIMEDIA CONTAINER
A meta-file format whose specification describes how
data & metadata are stored.

A container format could wrap any kind of data.

Contains different types of Audio formats, Audio &

Video streams, Subtitles, Chapter-information &
meta-data(tags) – along with the synchronization
signals.
COMMON CONTAINERS
3GP

AVI (Container for WMA & WMV)

MPEG

Quick Time File Format (From Apple Inc)

RM (Real Media)

WHAT IS MATROSKA ?
It is not a video or audio compression format (video
codec).

It is an envelope for which there can be many audio,

video & subtitles streams, allowing the user to store a
complete movie or CD in a single file.
FEATURES
Fast seeking in the file.
Chapter entries
Full metadata(tags) support.
Selectable subtitle/audio/video streams.
Modularly Expendable.
Error resilience.
Streamable over the internet & local networks.
Menus (like DVD’s have).
STRUCTURAL DIAGRAM
Header HEADER– What EBML Version
this files was created with.
Meta Seek Information
METASEEK – Index of other
groups in the file.
Segment Information
SEGMENT INFORMATION -
Track Basic information
Chapters
about the whole file.

TRACK – Information about each of

Clusters
the tracks.

Cueing Data CHAPTERS – Sets predefined points

Attachment
to jump to in video or audio.

Tagging
STRUCTURAL DIAGRAM
CLUSTERS– All of the video
Header
frames & audio for
each track.
Meta Seek Information

CUEING DATA- Index of each of

Segment Information the tracks.

ATTACHMENT- For attaching any

Track
type of file.
Chapters
TAGGING- Information about the
Clusters singer or writer of a song.

Cueing Data

Attachment

Tagging
 DETAILED DIAGRAM

EBML Version – Tells the Parser weather it can read the file or not.

Doc Type – Detects weather it is a Matroska container file or not.

D
E
T
A
I
L
E
D

D
I
A SEEK ID : Contains the Class-ID of a Level 1 element.
G
SEEK POSITION : Byte position of that particular element.
R
A TITLE : Contains the title of the file.
M
SEGMENT UID : ID used to identify the file.
D
E
T
A
I
L
E
D

D
I
A
G Name : Contains the Name of the track.
R
A Track Number : Contains the number of the track.
M
Track Type : Tells what the track contains, such as audio/video/
subtitles e.t.c.
D
E
T
A
I
L
E
D

D
I
EDITION ENTRY : Gives information about which chapter to be played.
A
G CHAPTERS : Contains the split chapters of a movie or any other data.
R
A
M
D
E
T
A
I
L
E
D

D
I
A
G
R
A
M

HELPS IN SEEKING & WITH ERROR PROTECTION.

Time Code : Time code that the first block should playback.

Block Group: Block of data, & any information relating to Block.

D
E
T
A
I
L
E
D

D
I
A
G
R
A
M
Cue Point : Time code stored in Cue Time.
Cue Position : Listing of the exact position of the in the file for each of the track for
that timecode.
File Name : Name of the attached File.
File Data : The file attached.
D
E
T
A
I
L
E
D

D
I
A
G Tag Element : Contains all of the information of specific tracks or chapters.
R
A Tags : Contains all the extra information about the file, script writer, singer,
M actors, directors, titles, edition, price, dates, comments etc.
 SPECIFICATIONS

EBML Principle.

EBML – Extensible Binary Meta Language.

 It is a binary derivative of XML.

 Specifies a binary & octet format.

 Format is made of 2 parts: Semantic & Syntax.

SEMANTIC OF EBML

Specifies a number of ID’s & their basic type.

Specific tags used are arbitrary.

Semantic of EBML outlines general data types & ID’s.

 BASIC DATA TYPES

Signed Integer - Big-endian, any size from 1 to 8 octets

Unsigned Integer - Big-endian, any size from 1 to 8 octets
Float - Big-endian, defined for 4 and 8 octets (32, 64 bits)
String - Printable ASCII (0x20 to 0x7E), zero-padded when needed
UTF-8 – Unicode string, zero padded when needed (RFC 2279)
Date - signed 8 octets integer in nanoseconds with 0 indicating the
precise beginning of the millennium (at 2001-01-
01T00:00:00,000000000 UTC)
master-element - contains other EBML sub-elements of the next lower
level
Binary - not interpreted by the parser
CODING FORMATS
Element ID – using a UTF-8 like system.

Data size – In octets, is also coded with a UTF-8 like

system.

Only one reserved word for Element Size encoding.

Data - Integers are stored in their standard big-endian

form.
Element ID coded with a UTF-8 like system :
 ELEMENT ID CODING

The leading bits of the Class IDs are used to identify

the length of the ID. The number of leading 0's + 1 is
the length of the ID in octets. We will refer to the
leading bits as the Length Descriptor.

Any ID where all x's are composed entirely of 1's is a

Reserved ID.

The Reserved IDs (all x set to 1) are the only IDs that
may change the Length Descriptor.
SPECIFICATION NOTES

Beginning of file: EBML file always starts with 0x1A,

thus helps to include ASCII text before
EBML data.

• EBML parser is safe from false-alarm with

these ASCII only codes.

• The EBML header is next stored

Block Timecodes:

 Represented by a 16 bit signed integer.

 Represents the raw timecode relative to the Clusters

timecode, multiplied by the Timecode Scale.

Default Values:

 Default value of an element is assumed when not present

in the data stream.
 It is assumed only in the scope of its upper-element.
EBML Class:
A larger class-ID can be used as a synch word in case the file is
damaged.
Elements used frequently, but do not need to act as a synch
word have a small class-ID

Encryption:

Allows people to implement whatever form of encryption is best

for them.
Possible to manipulate encrypted streams without decrypting
them.
Two completely different types of encryption can be used,
requiring two separate keys to decrypt them.
Image cropping :
PixelCropXXX elements help to crop the image before
being resized.

Octet: Refers to a byte made of 8 bits.

Overlay Track :
Overlay tracks should be rendered in the same 'channel'
as the track it's linked to.
When content is found in such a track it is played on the
rendering channel instead of the original track.
Position References:
Refers to the position, in octets, from the beginning of
an element.
The reference is the beginning of the first Segment
element. 0 = first level 1 element in the segment.

Raw Timecode:
The exact time of an object represented in nanoseconds.
To find out a Block's Raw Timecode, you need the
Block's timecode, the Cluster's Timecode, and the
TimecodeScale. For calculation, please see the see the
TimecodeScale notes.
 SEGMENT LINKING
Hard linking:

This linking can also be called splitting.

It's the operation of cutting one segment in several parts. The
resulting parts should play as if it was just one part (the
original segment).
The timecode of each part follows the ones from the previous
parts. The track numbers are the same.
 The chapters only match the current segment (unless the
edition is ordered, where all parts should be in each
segment).
The NextUID and PrevUID points the respective segment
UIDs.
Soft linking:
Used by codec chapters.
They can reference another segment and jump on that
Segment.

Medium linking:
This kind of linking is a mix between hard and soft linking.
Done through chapters using the ChapterSegmentUID
element and only makes sense for ordered editions.
Timecodes of the following content should be shifted by the
duration of the linked segment.
For hard-linking, the resulting segment edition should be
played and considered as one.
Segment UID:

The 128 bits UIDs must be as unique as possible.

TrackTimecodeScale:

Used to align tracks that would otherwise be played at

different speeds.
To avoid problems that may occur in different
Broadcasting standards like NTSC/PAL
3D and multi-planar videos:
There are 2 different ways to compress 3D videos:

 Have each 'eye' track in a separate track and

 Have one track code both 'eyes' into one track (which is more

efficient, compression-wise).

Matroska supports both ways (and even more):

 For the single track variant, there is the StereoMode element

which can define what kind of element (mono or left-right).
 For separate tracks, Matroska needs to define exactly which

track does what.

TRACK OPERATION
TrackOperation allows combining multiple tracks to make
a virtual one.
It uses 2 separate system to combine tracks.
One to create a 3D "composition" (left/right/background
planes)
The other to simply join 2 tracks together to make a single
track.
 EBML ELEMENTS ORDER
Level 1 elements:
Matroska only needs a few level 1 elements to be
playable: Segment Info, Track Info, Clusters.
These elements have to be present in a Matroska file.
And the Segment Info and Track Info must always be
found before the Clusters.

Meta Seek:
When 1 Meta Seek Head is present, it should be the first
element in a Cluster.
In some cases there are 2 Meta Seek Head sections :
 In that case the first one is placed first with only the position of
the level 1 elements except the Clusters. The second Meta Seek is
placed at the end and contains a lengthy list of all Clusters.
Cues (index):

The Cues should always be written after the Clusters.

It is much easier to put the Cues at the "end" of the
segment, once all the Clusters have been written;
otherwise it's hard to predict beforehand the place to
reserve at the beginning of the segment.

Chapters:

Chapters could be used during playback even if the user

doesn't need to seek. It immediately gives the user the
information of what section he's reading and/or the other
available sections.
So Chapters should be placed before the Clusters.
Attachments:

They may contain the cover art bitmaps that users may edit.
Attachment should be placed at the end of the segment.

Tags:

It's better for network streams if the tags are found early in
the stream.
OPTIMUM LAYOUT FROM A MUXER
SUBTITLES
Any Matroska file containing only subtitles should use
the extension ".mks".
As a general rule of thumb for all codecs, information
that is global to an entire stream should be stored in
the CodecPrivate element
Start and stop timecodes in a timecodes native storage
format should be removed when being placed in
Matroska as they could interfere, if the file is edited
afterwards.
 IMAGES SUBTITLES
The requirement for muxing VobSub into matroska is v7
subtitles.

The .IFO file will not be used at all.

If there is more than one subtitle stream in the VobSub set,
each stream will need to be seperated into seperate tracks for
storage in Matroska.

Each .BMP will be stored in its own Block. The Timestamp

with be stored in the Blocks Timecode and the duration will
be stored in the Default Duration.
SRT Subtitles
It consists of four parts, all in text..
1. A number indicating the which subtitle it is in the
sequence.
2. The time that the subtitle should appear on the
screen, and then disappear.
3. The subtitle itself.
4. A blank line indicating the start of a new subtitle.

When placing SRT in Matroska, subtitle is converted to UTF-

8 and placed in the data portion of the Block. Part 2 is used
to set the timecode of the Block, and BlockDuration
element.
SSA/ASS Subtitles
It's the file format used by the popular subtitle editor, Sub
Station Alpha.
All text is converted to UTF-8.
All the headers are stored in CodecPrivate
Start & End field are used to set TimeStamp and the
BlockDuration element.
Events are stored in the Block in this order: ReadOrder,
Layer, Style, Name, MarginL, MarginR, MarginV, Effect,
Text (Layer comes from ASS specs ... it's empty for SSA.)
"ReadOrder field is needed for the decoder to be able to
reorder the streamed samples as they were placed
originally in the file."
MATROSKA STREAMING
In Matroska, there are mostly 2 different kinds of stream:
file access and live streaming.

File Access: Reading a file located on your computer/

accessing it from an HTTP (web) server or CIFS
(windows share) server. All these protocol are usually
safe from reading errors and seeking in the stream is
possible.
Matroska having a small overhead, is well suited for
storing music/videos on file servers without having a big
impact on the bandwidth used.
It doesn't require to load the index before playing, so
playback can start very quickly too.
Live Streaming:

Live streaming is the equivalent of TV broadcasting on the

internet.
Matroska is not meant to be used over RTP. RTP already has
timing and channel mechanisms that would wasted if
doubled in Matroska.
Live streaming of Matroska over HTTP (or any other plain
protocol based on TCP) is very possible.
A live Matroska stream is different than a file, because it may
have no known end. So the Segment must use the "unknown"
size (all 1s in the size).
The other option would be to concatenate Segments with
known sizes one after the other.
 ADVANTAGES OF MKV
The container format MKV is superior to other containers in many
ways:

* supports H.264/AVC:
which is needed for efficient HD content playback,
Xvid/DivX are not suitable!!

* B-Frame support.

* Supports variable audio bitrate.

* Supports chapters, muxed subtitles, metadata/tags and dvd-

like menus.
AUDIO FORMATS SUPPORTED
VIDEO FORMATS SUPPORTED
 LINKS
http://www.matroska.org

http://haali.cs.msu.ru/mkv/

http://www.alexander-noe.com/

http://de.wikipedia.org/wiki/Matroska

http://www.matroska.info/

http://ld-anime.faireal.net/guide/jargon.matroska-en
 O U
K Y
A N
T H