OTT Stream Monitoring: HLS, MPEG-DASH and SRT Explained

Live television reaches viewers over two very different kinds of IP link. Contribution feeds travel from venue or studio to the broadcast center, often over the public Internet using SRT. Distribution to phones, smart TVs and browsers usually uses HTTP adaptive streaming: HLS or MPEG-DASH. The two fail in different ways and need to be monitored differently. This guide explains how each protocol works and what to watch, based on RFC 8216 and its second-edition draft (HLS), ISO/IEC 23009-1 and ETSI TS 103 285 V1.4.1 (MPEG-DASH and DVB-DASH), and the IETF SRT draft with the SRT reference documentation.

Contribution versus distribution

Contribution moves one high-quality feed from point to point. The payload is normally an MPEG-2 transport stream, so it can be judged with the same checks as any broadcast stream, such as ETSI TR 101 290. Delay matters, and lost packets must be recovered before they reach the decoder.

Distribution over HTTP delivers the program to many clients through web servers and CDNs. The program is cut into short segments, encoded at several bitrates and listed in a playlist (HLS) or manifest (DASH), and each player chooses which version to fetch. A fault here is often invisible at the encoder but obvious to viewers: a playlist that stops updating, a segment that returns an HTTP error, or one rendition that is broken while the others play. Good monitoring therefore looks at both the stream entering the packager and what a client receives from the origin or CDN.

How HLS delivers a live stream

HTTP Live Streaming is published as RFC 8216 (August 2017). A second edition, draft-pantos-hls-rfc8216bis, is in progress at the IETF; revision 22 (May 2026) describes version 13 of the protocol and uses the term Multivariant Playlist for what RFC 8216 calls the Master Playlist.

Playlists

  • The Master (Multivariant) Playlist lists the Variant Streams with EXT-X-STREAM-INF. Its required BANDWIDTH attribute is the peak segment bit rate; an inaccurate value can cause stalls. Alternative audio and subtitle renditions are listed with EXT-X-MEDIA.
  • Each Media Playlist lists the segments of one rendition. EXT-X-TARGETDURATION is required and is the maximum segment duration: every EXTINF duration, rounded to the nearest integer, must be less than or equal to it.
  • EXT-X-MEDIA-SEQUENCE numbers the first segment. When a live server removes segments, this value must increase by one for each removed segment and must never decrease or wrap.
  • EXT-X-DISCONTINUITY marks a change in encoding parameters or timestamp sequence, and EXT-X-PROGRAM-DATE-TIME ties a segment to wall-clock time.

Live timing rules

RFC 8216 gives clients and servers firm timing rules, and these are what a live monitor should check:

  • A client must wait at least one target duration before reloading a playlist that has changed, and half a target duration before retrying one that has not changed (section 6.3.4).
  • A client should not start playback at a segment less than three target durations from the end of the playlist (section 6.3.3).
  • A live playlist must not be cut to less than three target durations, and a removed segment must stay available for its own duration plus that of the longest playlist that contained it (section 6.2.2).

Segment formats

RFC 8216 allows MPEG-2 transport stream segments, fragmented MPEG-4 (fMP4) segments, packed audio and WebVTT. A transport stream segment must hold a single program and contain a PAT and a PMT, unless an EXT-X-MAP tag points to them. Every fMP4 segment must have an EXT-X-MAP tag for its initialization section. CMAF segments meet the HLS fMP4 requirements and are also recommended by DVB-DASH, so one set of CMAF media can serve both.

The second-edition draft adds Low-Latency Mode (partial segments with EXT-X-PART, blocking playlist reload and preload hints) and EXT-X-GAP for a segment without media.

How MPEG-DASH delivers a live stream

MPEG-DASH is defined in ISO/IEC 23009-1. The DVB profile, DVB-DASH, is ETSI TS 103 285; the latest published version is V1.4.1 (2023-09).

The MPD

A DASH presentation is described by the Media Presentation Description (MPD), an XML document divided into Periods. Each Period holds Adaptation Sets, sets of interchangeable encoded versions of the same content (for example, all video bitrates), and each Adaptation Set holds Representations, the individual encodings. A static MPD (@type="static") is typically used for on-demand content; a dynamic MPD is used for live services and may be updated, with @minimumUpdatePeriod giving the smallest period between potential changes.

DVB-DASH constraints worth monitoring

  • Segments must be at least 960 ms long (except the last segment of a Period), and video and audio segments must not exceed 15 seconds where subsegments are not signaled (clause 4.5).
  • In a live Adaptation Set with several Representations, segments must be aligned and start with a stream access point of type 1 or 2, or a player may ignore it (clause 4.2.4).
  • Media is ISO BMFF; the DVB profile excludes multiplexed representations, and Representations should conform to CMAF (ISO/IEC 23000-19) (clauses 4.1 and 4.3).
  • A dynamic MPD should contain a UTCTiming element so players can synchronize their clock; without one, segments must be available on time against a globally accurate clock, within 200 ms (clause 4.7.2).

A live DASH player works out which segment is available from the MPD and its own clock, so a wrong clock or a packager that publishes late shows up as HTTP errors for segments that “should” exist, while the MPD itself looks correct.

SRT for contribution

Secure Reliable Transport (SRT) is described in the IETF Internet-Draft draft-sharabayko-srt; revision 01 (September 2021) is the latest and has since expired as a draft. The reference implementation is the open-source SRT library supported by the SRT Alliance. SRT runs over UDP and can carry any data, but it was designed for low-latency video; in broadcast contribution the payload is usually an MPEG-2 transport stream.

  • Recovery. SRT supports selective retransmission (ARQ), where the receiver reports lost packets with NAK messages, and forward error correction, separately or combined.
  • Latency. Each side holds packets in a buffer for a configured latency; a packet can be retransmitted only while it is still inside that window. The connection uses the larger of the latencies proposed by the two sides. The draft recommends a latency of 3 to 4 times the round-trip time and gives 120 ms as the minimum; the reference library also defaults to 120 ms in live mode.
  • Too-late packet drop. A packet that cannot be recovered in time is dropped so that the following packets are still delivered on schedule. The stream keeps its timing, but the decoder sees a gap.
  • Encryption. SRT encrypts the payload with AES in counter mode, using 128, 192 or 256-bit keys. The key-encrypting key is derived from a shared passphrase with PBKDF2; the reference library accepts passphrases of 10 to 80 characters.
  • Connection modes. Caller, listener and rendezvous. A Stream ID string lets a listener identify which stream a caller wants.

What goes wrong, and what to monitor

Playlist and manifest faults

  • A live playlist or MPD that stops updating while the server keeps serving the old file.
  • Media sequence numbers that jump back, repeat or skip, or segments removed out of order.
  • Segment durations longer than the HLS target duration, or outside the DVB-DASH 960 ms to 15 s window.
  • Variants or Representations that are listed but return HTTP errors, and BANDWIDTH values that do not match the measured bitrate.

Segment delivery

  • Missing or late segments, HTTP 4xx/5xx responses and slow downloads: segments that keep taking longer to fetch than to play empty the player buffer.
  • Differences between origin and CDN edges, and between renditions of the bitrate ladder.

Content inside the segments

  • Black or frozen video, and silence, in one rendition only: a fault in one rung of the bitrate ladder is easily missed.
  • Audio loudness that differs between the broadcast and OTT versions of the same channel; see the loudness measurement guide.
  • Subtitle and alternative audio renditions that are missing or out of sync.

Timing and ad signaling

  • Timestamp discontinuities that are not signaled with EXT-X-DISCONTINUITY, and drift between program date-time and the media.
  • SCTE-35 markers lost between the transport stream and the OTT output. RFC 8216 maps SCTE-35 splice information into EXT-X-DATERANGE tags (with SCTE35-CMD, SCTE35-OUT and SCTE35-IN attributes), and TS 103 285 carries it in an MPD EventStream with the scheme urn:scte:scte35:2014:xml+bin, whose event time must be on a segment boundary. See the SCTE-35 guide for the markers themselves.

SRT links

  • Packet loss before and after recovery, retransmissions, and round-trip time against the configured latency: a link whose RTT approaches the latency has no margin left.
  • Connection drops and failed handshakes, including a passphrase or key length mismatch between sender and receiver.
  • The transport stream itself once it arrives: continuity counter errors after a too-late drop, PCR behavior and the PSI tables.

Testing it in practice

The DVBControl products take these sources as live inputs, next to broadcast, IP and SDI sources.

  • DVBAnalyzer opens HLS playlists, MPEG-DASH MPDs and Smooth Streaming manifests through its Streaming input; you pick the stream to receive (automatic or a stream number) and the audio and subtitle tracks the manifest offers. Encrypted presentations can be analyzed by giving the input a license server. The SRT input supports caller, listener and rendezvous modes, a Stream ID and a passphrase, and shows the bitrate, latency and packet loss while receiving. When HLS or MPEG-DASH segments carry an MPEG transport stream, and for the transport stream an SRT link delivers, the other views apply as well, such as ETR 290, PSI/SI, PCR and PTS/DTS timing, the SCTE-35 Viewer and loudness.
  • DVBMonitor monitors many streams 24/7, including HLS, MPEG-DASH and SRT inputs. It checks ETR 290, SI/PSI/PSIP table changes, SCTE-35, video quality and loudness against templates, detects freeze, black, silence, and input, PID and service loss, and raises alarms by SNMP and mail.
  • DVBMosaic is a multiviewer that shows services from DVB, IPTV, OTT (HLS, MPEG-DASH, SRT) and SDI sources in one wall, with detection of freeze, black, silence and PID, service and input loss, and monitoring of subtitles and SCTE-35 events.

Frequently asked questions

What is the difference between HLS and MPEG-DASH?

Both cut a stream into HTTP-delivered segments in several bitrates. HLS describes them in text playlists (RFC 8216); DASH uses an XML MPD (ISO/IEC 23009-1). HLS segments can be MPEG-2 TS or fMP4; DVB-DASH uses ISO BMFF. With CMAF, the same fMP4 media can be served to both.

Is SRT a replacement for HLS?

No. SRT is a point-to-point transport, mainly used for contribution with sub-second latency. HLS and DASH distribute to large numbers of players through web servers and CDNs. A typical chain receives a feed over SRT and packages it as HLS and DASH.

What SRT latency should I use?

The SRT draft recommends 3 to 4 times the round-trip time, with 120 ms as the minimum. A lost packet can only be retransmitted within the latency window, so lossy or long links need more.