Reference

A byte range inside a resource (RFC 8216 §4.3.2.2).

offset absent means "immediately after the previous range", which is what the tag itself means when the @ clause is left out. Keeping the two apart matters: a reader that filled in zero would fetch the wrong bytes.

The encryption method EXT-X-KEY names (RFC 8216 §4.3.2.4).

Other carries a method this release does not implement, so a playlist that uses one is read and written back unchanged rather than refused.

A wall-clock interval the stream marks, EXT-X-DATERANGE (RFC 8216 §4.3.2.7).

A variable the playlist defines, EXT-X-DEFINE (RFC 8216bis §4.4.2.3).

An I-frame only rendition, EXT-X-I-FRAME-STREAM-INF (RFC 8216 §4.3.4.3).

The initialisation section a segment needs before it can be decoded, the EXT-X-MAP tag (RFC 8216 §4.3.2.5).

A key a segment is encrypted with (RFC 8216 §4.3.2.4).

Segments carry the key that was in force when they were written, not the tag that introduced it: a tag applies to every following segment until it is replaced, and a caller hunting for "what encrypts this segment" should not have to replay the file to find out.

A master playlist: which renditions exist and how to reach them (RFC 8216 §4.3.4).

What an EXT-X-MEDIA rendition carries (RFC 8216 §4.3.4.1).

A media playlist: the segments of one rendition (RFC 8216 §4.3.3).

A partial segment, the unit low-latency HLS publishes before a segment is complete (RFC 8216bis §4.4.4.9).

A playlist, of one kind or the other.

Why a playlist could not be read.

at is the line the parser stopped on, counting from one; got is what was there and want what the grammar allows.

What kind of playlist a media playlist is (RFC 8216 §4.3.3.5).

What to fetch next before it is listed, EXT-X-PRELOAD-HINT (RFC 8216bis §4.4.4.10).

An alternative rendition a variant can switch to (RFC 8216 §4.3.4.1).

How far along a sibling rendition is, EXT-X-RENDITION-REPORT (RFC 8216bis §4.4.4.11).

A frame size, 1920x1080.

One media segment: the URI a player fetches and everything the playlist says about it.

The reload advice a low-latency server gives, EXT-X-SERVER-CONTROL (RFC 8216bis §4.4.3.8).

A piece of session metadata, EXT-X-SESSION-DATA (RFC 8216 §4.3.4.4).

Where playback should start, EXT-X-START (RFC 8216 §4.3.5.2).

One rendition of a master playlist, the body of EXT-X-STREAM-INF (RFC 8216 §4.3.4.2).

One box: a type, a size and its content.

large remembers that the size was written as a 64-bit field rather than the usual 32-bit one, because writing it back the other way would change the file even though it would still be readable.

What a box holds.

A box either contains smaller boxes or a run of bytes. The boxes that hold both — a sample description entry is a fixed header followed by child boxes — keep the fixed part in prefix and the children after it, so the tree stays generic without losing a byte.

The brands a file declares in ftyp.

One movie fragment: the moof that describes it and the media data that follows, up to the next fragment.

One track's contribution to a fragment.

One piece of a segment index: how big the next piece is and how long it plays, or a pointer to another index.

A movie fragment ready to be written: moof and the mdat it points at.

A track's timescale: how many units make a second.

A file and the boxes it was read into.

The bytes are kept because sample data is described by offsets into them: a sample is a view, not a copy, so a track of a hundred thousand frames costs nothing to list.

Why a file could not be read.

at is the offset in the file the reader had reached, want what the format requires there and got what was actually there.

The samples one track contributes to a fragment.

One sample: where its bytes are, when it plays, and whether a player may start here.

A sample as it is written into a fragment: its bytes and what the fragment has to say about it.

A segment index, sidx (ISO/IEC 14496-12 §8.16.3).

It says where the pieces of a fragmented stream are, in a form a player can read without downloading them, which is how a DASH client knows what to fetch next.

A track and the samples it holds, read from the sample table or from the fragments.

What a track carries, from the handler hdlr names.

Write boxes back out.

A file type box.

A media data box holding data.

A fragment header: the fragment's number.

Read a mvhd.

Read the boxes at the start of data.

Reading stops at the first byte that is not a box; a file whose last box was cut short is refused rather than half-read.

Read a sidx box.

The decode time the fragment starts at, so a player can place it without having seen the ones before it.

A track fragment header that says where this track's data is: in this fragment, which is what default-base-is-moof means.

A track run: every sample, with its duration, size, flags and composition offset written out rather than defaulted, so the fragment needs nothing from the header to be read.

The adaptation field: the extra room a packet uses when its payload is shorter than 184 bytes, and where the programme clock reference travels.

The field is kept as the bytes it was, because half of it is flags for features that are rare enough to be worth not modelling; the accessors read the parts that matter and a caller that needs more reads raw.

One transport stream packet: a fixed 188 bytes, of which four or more are header, and the rest either adaptation field or payload.

The programme association table: which programme is on which identifier.

A packetised elementary stream packet: the frame, or the piece of a frame, that a stream carries (ISO/IEC 13818-1 §2.4.3.7).

The optional header is kept as bytes. It carries the timestamps a player needs and a dozen flags about how the frame may be decoded, which it does not; keeping the bytes means a packet read and written again is the same packet, and a caller that wants a timestamp reads it with pts.

The programme map table: what a programme is made of, and which packet carries its clock.

One entry of a programme association table.

A section: what the tables are made of (ISO/IEC 13818-1 §2.4.4).

The body is kept as bytes because a table's shape is fixed but its contents are not, and a reader that wants the parsed form asks for Pat::of or Pmt::of.

One elementary stream a programme carries.

Why a stream could not be read.

at is the offset of the packet the reader was in, want what the format requires there and got what was there.

Whether packet follows previous without a gap.

The checksum every section ends with: MPEG-2's CRC-32, which differs from the one Ethernet uses in not inverting the input or the output.

The continuity counter of the next packet of a stream identifier, which is how a demultiplexer notices that a packet was lost.

A counter only advances on packets that carry a payload, and repeats when a packet is repeated, so the rule is a function of the packet rather than of the count.

Read every packet of data.

A stream that loses its sync is refused: the reader could search for the next 0x47, but a transport stream that lost its alignment is a stream whose packets have already been dropped, and guessing hides that.

The elementary stream packets a PID carries, reassembled from its transport packets.

A packet begins at a transport packet whose payload starts a unit, and ends where its own length says or, when the length is zero, where the next one begins.

The sections a PID carries, with the pointer fields taken out.

The identifier of an audio stream, 0xC0 to 0xDF.

No packet carries this identifier: it is the null packet, put in to keep the bit rate up when there is nothing to send.

The size of every transport stream packet. The format has no other size.

The programme association table always arrives on this identifier.

The byte every packet starts with.

The identifier of the programme association table.

The identifier of a programme map table.

The identifier of a video stream, 0xE0 to 0xEF.

The value types AMF0 defines, which is what a command is written in.

A command is a name followed by arguments, and the arguments are objects: connect carries an object of application and version, publish a stream name. The variants here are the ones a publish session meets; the rest of the encoding — references, records, XML — is not used by any publisher and is refused rather than guessed at.

Reads chunks back into messages.

A chunk stream is stateful: after the first chunk of a message, the ones that follow only carry a few bytes of header, because the type, length and stream are still what they were. The reader keeps that state per chunk stream, which is why it has to see the bytes in order.

Writes messages as chunks.

A handshake as the receiving side sees it.

The server answers with its own block and an echo of the client's, and the client answers with an echo of the server's. The two echoes are what tells each side that the other can read what it writes.

A message: what a chunk stream carries once its chunks are put back together.

Where a session is.

Why a stream could not be read.

The receiving half of a publish: it answers the handshake, answers the commands that set up a stream, and hands the caller the audio, video and metadata that arrives.

A session has no socket. Bytes go in and bytes come out, which is what lets it be tested without one and left to a server to drive.

The message that acknowledges a peer's bytes, which a publisher sends when it has received the window it announced.

What a client has to answer once the server has answered it.

The bytes a client sends before anything else: a version, a time, four zero bytes, and a block that is meant to be random.

The block is not a secret and nothing is derived from it in the simple handshake, which is why a publisher that fills it with zeros is accepted by every server in use. A caller that would rather not can pass its own.

A protocol control message: a payload of four bytes in most cases, on stream zero, which is where control messages live.

Read values until the data runs out.

Write values one after another, which is how a command's arguments are laid out.

The user control event that answers a ping with a pong.

The message that sets the chunk size, which applies to the chunks that follow it and not to itself.

The message that tells the peer how much bandwidth it may use, and how it should react when it goes over.

The message that says how many bytes may be in flight.

The default chunk size, before either side says otherwise.

The message that says a stream was abandoned part way through a message.

The message that acknowledges how much has been received.

An audio message.

A command, which is how a session is set up.

A message of data, which is how metadata is sent.

The message that sets how large a chunk may be.

The message that sets how much bandwidth the peer may use.

The message that carries a user control event, such as a ping.

A video message.

The message that says how large the sender's window is.

How many bytes each of the two random blocks is.

The version byte every peer sends first. Three is the only version in use.

A group of representations a player chooses between: the video renditions of one period, or the audio ones.

One ContentProtection entry: the scheme that names a key system, the value that scheme gives the rendition, and the protection header the key system is handed.

A manifest does not encrypt anything itself; it says which key system opens a rendition and gives that system the box it needs. The box travels base64 in the manifest and is kept here as the bytes it decodes to, so a caller hands it on without decoding anything a second time.

Where the initialisation segment is: a URL, a range inside one, or both.

Whether a presentation is a file to play or a stream still being written.

A media presentation description: what a DASH client reads before it fetches anything.

Why a manifest could not be read.

at is the byte offset the reader had reached, want what the grammar requires there and got what was there.

A stretch of the presentation that is played on its own: a title, or the part of a live stream between two ad breaks.

A range of bytes in a file, as a manifest writes it: 1389-15304, both ends counted.

The end may be left out, which means "to the end of the file".

One encoding of the presentation: a single quality a player can choose.

A single file addressed by byte ranges, with an index a player reads first.

The on-demand profile: one request for the index tells a player where every segment is, so it can fetch the ones it needs without the others.

Segments written out one by one, each with its own URL or its own range.

This is how a packager addresses a stream it wrote into a single file: the manifest lists where each piece starts and ends, so a player fetches a range instead of a file.

One segment of a list: the whole file, or a range inside the file the representation's base URL names.

How the segments of a representation are addressed: a template with the numbers filled in, which is what almost every manifest uses.

Where a segment starts and how long it runs, for a stream whose segments do not have one length.

A duration in seconds written the way a manifest writes it.

Fractions are kept to three places, which is finer than any frame rate and short enough to read.

An ISO 8601 duration in seconds: PT2S, PT1M30.5S, PT1H.

A manifest writes the length of a presentation this way rather than as a count of seconds, and the reader has to take it back apart. Years and months have no fixed length, so a duration that uses them is refused rather than given a length it might not have.

A stream cut into segments a player can fetch one at a time.

The packager is HLS packaging without the files: it turns a movie into an initialisation section and a list of segments, and writes the playlists that name them. Writing them out and answering HTTP requests is the caller's job, and deliberately so — nothing here touches a socket.

One sample, already cut out of the file it came from.

A segment of a packaged stream: the bytes a player fetches, and how long they play.

A track as the packager needs it: what it is, its timescale, and where its samples are.

What a track carries.