Skip to content

The OTT copy

A headend does not serve viewers — that is the job of Catena or of your CDN. But the signal often has to be handed to the OTT world straight from the station: to show the operator a picture in a browser, to give a copy to internet broadcasting, to push the air onto a platform.

This page is about that copy and about its limits.

HLS and DASH from the station

Any of the station's streams is available at:

http://<station-address>/streaming/v/<stream>/index.m3u8
http://<station-address>/streaming/v/<stream>/Manifest.mpd

HLS (including LL-HLS with partial segments), DASH and MPEG-TS over HTTP are served. Out of the box that is enough to watch the signal in a player and make sure the station is sending exactly what it should.

What to keep in mind:

  • A player needs its own codecs. A browser will not read broadcast MPEG-2 — transcoding into H.264/AAC is required.
  • A player needs subtitles as a track. No OTT player decodes teletext, see Subtitles and teletext.
  • Mass delivery is not the station's job. Balancing, zones, viewer authorisation and session accounting start where the headend ends.

RTMP push

Handing the signal to a platform or to a third-party system that expects an incoming RTMP connection is done with the same push.

The Egress tab, + Add push, the RTMP protocol. It asks only for a Name and a single URL as a whole, stream key included: rtmp://a.rtmp.example.com/live2/<key>.

  • H264+AAC are supported, as well as HEVC and AV1 in enhanced RTMP; audio-only streams go out too.
  • Timestamps in a push start at zero — the way platforms expect them.
  • The errors are distinguished in the status: connection refused, connection timeout, publish rejected (the key is taken or wrong), a hung receiver.
  • There is no outgoing MPEG-TS section for RTMP: this protocol has no transport stream.

Like any other delivery destination, an RTMP push revives itself and keeps its own counters: it has frames but no datagrams and no retransmits.

Encrypting the OTT copy

The OTT copy can be served encrypted. The Delivery encryption (DRM) block on the stream's Delivery tab turns on Common Encryption with the cbcs scheme: HLS and DASH go out as ciphertext, and the playlist and the manifest carry signalling for Widevine, PlayReady, FairPlay and ClearKey. The key comes either straight from the settings or from your key server over SPEKE.

The station encrypts — in this layout it is the origin. Streamers that serve its copy on receive ready ciphertext and hand it out as is: they have no key, and there is nobody for them to ask.

What this changes at the station:

  • HLS and DASH are encrypted, LL-HLS and archive playback included.
  • MPEG-TS over HTTP refuses. There is no encryption for it, and serving such a stream in the clear would be a way around the protection: the request gets a 403.
  • Pushes are untouched. Multicast, RTP, SRT and RTMP leave the station in the clear — what is encrypted is delivery to players, not the transport to your own equipment.

The whole path can be checked without a commercial DRM: leave ClearKey as the only system, set a key in the settings and open the player page — the station issues the licence itself. This mode gives no protection and is good only for checking.

What next

  • Delivery monitoring — did the push reach the platform.
  • Transcoding — bringing the signal to what a player plays.
  • Catena — when a full television service with viewers is needed behind the station.