In Matroska, there are two kinds of streaming: file access and livestreaming.
File access can simply be reading a file located on your computer, but also includes
accessing a file from an HTTP (web) server or CIFS (Windows share) server. These protocols
are usually safe from reading errors and seeking in the stream is possible. However,
when a file is stored far away or on a slow server, seeking can be an expensive operation
and should be avoided. The following guidelines, when followed, help reduce the number
of seeking operations for regular playback and also have the playback start quickly without
a lot of data needed to read first (like a
Attachment Element or
Matroska, having a small overhead, is well suited for storing music/videos on file servers without a big impact on the bandwidth used. Matroska does not require the index to be loaded before playing, which allows playback to start very quickly. The index can be loaded only when seeking is requested the first time.
Livestreaming is the equivalent of television broadcasting on the internet. There are 2 families of servers for livestreaming: RTP/RTSP and HTTP. Matroska is not meant to be used over RTP. RTP already has timing and channel mechanisms that would be wasted if doubled in Matroska. Additionally, having the same information at the RTP and Matroska level would be a source of confusion if they do not match. Livestreaming of Matroska over HTTP (or any other plain protocol based on TCP) is possible.
A live Matroska stream is different from a file because it usually has no known end
(only ending when the client disconnects). For this, all bits of the “size” portion
Segment Element MUST be set to 1. Another option is to concatenate
with known sizes, one after the other. This solution allows a change of codec/resolution
between each segment. For example, this allows for a switch between 4:3 and 16:9 in a television program.
Segment Elements are continuous, certain
Attachments, MUST NOT be used.
It is possible for a
Matroska Player to detect that a stream is not seekable.
If the stream has neither a
SeekHead list or a
Cues list at the beginning of the stream,
it SHOULD be considered non-seekable. Even though it is possible to seek blindly forward
in the stream, it is NOT RECOMMENDED.
In the context of live radio or web TV, it is possible to “tag” the content while it is
Tags Element can be placed between
Clusters each time it is necessary.
In that case, the new
Tags Element MUST reset the previously encountered
and use the new values instead.