# MediaKind Docs > Developer documentation for MediaKind products, APIs, and workflows. Markdown versions are available for each linked documentation page. # Welcome to MK.IO Beam MK.IO Beam is engineered to meet the evolving demands of processing at the edge of your network, delivering high-quality broadcast and streaming headends, low latency contribution encoding and capable video/audio decoding. Its flexible architecture allows for seamless integration into existing workflows, providing a future-proof solution. MK.IO Beam connects to the cloud, enabling direct and automated control, monitoring and life cycle management via the MK.IO cloud portal for the ultimate in efficient operations. [Quick Start](/beam/quick-start) Configure and register your device. [Connect to MK.IO](/beam/connect-to-mkio) Check network requirements and find every device-management guide. [Essentials UI](/beam/essentials) Monitor channels and create new services from the streamlined Essentials dashboard. [Advanced interface](/beam/web-interface) Configure feeds and the individual services behind them in the Advanced interface.

MK.IO Beam overview video

## Solutions [Contribution](/beam/contribution) **For sending high-quality feeds from the field to the studio.**\ Find guides on configuring low-latency encoding, secure transport for live events, and more. [Reception](/beam/reception) **For receiving and decoding feeds from satellite or IP.**\ Find guides on configuring satellite demodulation, IP turnaround, professional decoding, and more. [Headends](/beam/headends) **For processing channels for distribution (Cable, IPTV, OTT).**\ Find guides on configuring statistical multiplexing, ABR transcoding, packaging, and more. --- ## System administration Manage the BEAM platform hardware, security, and connectivity. These guides apply to all solutions. - [Installing the Beam ISO ](/beam/system-admin/iso-installation) - [System Settings ](/beam/system-admin/system-administration) - [Maintenance](/beam/system-admin/maintenance/service-settings) - [Servers](/beam/system-admin/servers/servers) - [Security](/beam/system-admin/security/user-management) - [Network](/beam/system-admin/network/configure-nics) # MK.IO Beam API guides Use the Channels API for device-local channel workflows, the Fleets API for device management, and the Infrastructure API for sites and networks. ## Getting started [Choose an API](/beam/api-guides/getting-started/which-api) Choose the API for your Beam workflow. [API overview](/beam/api-guides/understanding/overview) Understand cloud and device-local connections. ## Channels API [Build with the Channels API](/beam/api-guides/how-to/channels) Create, control, and monitor channels on a Beam device. [Channels API reference](/api-reference/channels-api) Look up endpoints, schemas, and responses. ## Fleets API Register, update, and manage hardware and software device inventory for on-premises edge deployments. [Fleets API Reference](/api-reference/fleets-api) Endpoints, schemas, and request/response examples for fleet operations. [Manage Fleet Devices](/beam/api-guides/how-to/fleets/device-management) Register devices, configure settings, and monitor edge appliance health. [Backups & Restores](/beam/api-guides/how-to/fleets/backups-and-restores) Backup device configurations and restore edge states. [Software & Updates](/beam/api-guides/how-to/fleets/software-and-updates) Manage device software versions and roll out fleet-wide updates. ## Infrastructure APIs Configure network settings and sites across the platform. [Infrastructure API Reference](/api-reference/infrastructure-api) Endpoints, schemas, and details for infrastructure resource operations. [Set up Networks & Sites](/beam/api-guides/how-to/infrastructure/networks-and-sites) Provision network configuration and link sites. # Get started with the Beam APIs Choose the API that owns your workflow before configuring the connection. - [Which API to use](/beam/api-guides/getting-started/which-api): choose Channels, Fleets, or Infrastructure. - [Authentication and connections](/beam/api-guides/getting-started/authentication): prepare cloud or device access. - [Your first API call](/beam/api-guides/getting-started/first-api-call): list registered devices with the Fleets API. - [Connect to a Beam device](/beam/api-guides/how-to/channels/connect-to-a-device): prepare a device-local Channels API workflow. # Authentication and connections Choose the connection for the API you are using. ## Fleets and Infrastructure The Fleets and Infrastructure APIs use `https://app.mk.io/` and bearer authentication: ```http Authorization: Bearer ``` Follow [Create a personal token](/mkio/api-guides/getting-started/authentication#create-a-personal-token) to obtain a token. Replace `` with that token and use a project that your account can access. Keep the token out of source control. ## Channels The Channels API is served by the Beam device. Follow [Connect to a Beam device](/beam/api-guides/how-to/channels/connect-to-a-device) for the device address and supported versions, and consult the [Channels API reference](/api-reference/channels-api) for the operation you need. ## Verify cloud access [Your first API call](/beam/api-guides/getting-started/first-api-call) lists devices through the Fleets API. # Your first Beam API call Use the Fleets API to list devices registered in a project. ## Prerequisites - An MK.IO account with access to the project. - A bearer token and the project name. See [Authentication and connections](/beam/api-guides/getting-started/authentication). ## List devices Replace `` with your project name and `` with your token: ```bash curl -i "https://app.mk.io/api/v1/projects//fleet/devices" \ -H "Authorization: Bearer " \ -H "Accept: application/json" ``` ## Verify the response A successful response returns HTTP `200`. The response contains the device list in `value` and metadata in `supplemental`. See the [Fleets API reference](/api-reference/fleets-api) for the complete response and error definitions. Continue with [Manage devices](/beam/api-guides/how-to/fleets/device-management) to register or inspect a device. For a device-local workflow, use [Connect to a Beam device](/beam/api-guides/how-to/channels/connect-to-a-device). # Which Beam API to use The Beam APIs cover device-local channels and cloud management of devices, sites, and networks.
Workflow API Guide
Create, control, and monitor channels on a Beam device Channels Channel workflows
Register devices, manage software, and back up or restore configurations Fleets Fleet workflows
Configure networks and sites for devices Infrastructure Infrastructure workflows
## Cloud management Use Infrastructure to define sites and networks, then Fleets to register and operate devices. The [API overview](/beam/api-guides/understanding/overview) describes their project-scoped connections. ## Device-local channels The Channels API runs on the Beam device. Start with [Connect to a Beam device](/beam/api-guides/how-to/channels/connect-to-a-device), then [Manage channels](/beam/api-guides/how-to/channels/manage-channels). ## Related account setup The [Management API guides](/mkio/api-guides/how-to/management) cover organizations, projects, users, and tokens. # API workflow guides Choose the API for your workflow. [Channels API](/beam/api-guides/how-to/channels) Open the Channels API workflow guides. [Fleets API](/beam/api-guides/how-to/fleets) Open the Fleets API workflow guides. [Infrastructure API](/beam/api-guides/how-to/infrastructure) Open the Infrastructure API workflow guides. # Build with the Channels API The Channels API is the local API of an MK.IO Beam device. It presents everything the device is doing as a number of _channels_, where one channel can cover the input, the processing, and the output of a single service. It is the API behind the Beam Essentials UI, and it runs on the device itself rather than in the MK.IO cloud.

The Channels API requires an MK.IO Beam device running version 1.12.0 or higher. It is delivered as part of the Beam Essentials UI release, so devices on earlier versions do not serve these endpoints.

## API overview
Detail Value
Base path <DEVICE_ADDRESS>/api/
Scope A single Beam device
Access Network access to the device
Reference Channels API reference
The base URL is the device itself, not `api.mk.io`, and requests go to it over HTTP. The other MK.IO APIs are project-scoped and bearer authenticated against the cloud, so if you already integrate with the Media or Fleets API, treat this as a separate integration. See [Connect to a Beam device](/beam/api-guides/how-to/channels/connect-to-a-device) for how to build the address. ## How the main resources connect The API exposes a handful of resource types, and channels are the centre of all of them: 1. A **channel** holds a `spec` (the configuration you send) and a `status` (what the device reports back). 2. **Interfaces** are the physical and network ports available on the device. You read them to fill in the `interface` and `url` fields of a channel. 3. **Channel alarms** are the active faults raised against a named channel. 4. **Metrics** and **system** information describe the device rather than any one channel. A typical integration reads the interfaces once, creates channels against them, then polls channel status and alarms to drive a dashboard or an alerting rule. ## Common workflow patterns ### Automate a Beam device 1. [Connect and confirm the version](/beam/api-guides/how-to/channels/connect-to-a-device) 2. [Read the available interfaces](/beam/api-guides/how-to/channels/manage-channels) 3. [Create and start a channel](/beam/api-guides/how-to/channels/manage-channels) 4. [Poll status, health, and alarms](/beam/api-guides/how-to/channels/monitor-channels) ## Guides [How Beam channels work](/beam/api-guides/how-to/channels/how-channels-work) Channel types, the split between spec and status, and how configuration is applied asynchronously. [Connect to a Beam device](/beam/api-guides/how-to/channels/connect-to-a-device) Build the base URL, use the Swagger page served by the device, and understand the current authentication model. [Create and manage channels](/beam/api-guides/how-to/channels/manage-channels) A complete worked request, the input and output types each channel type accepts, and how to start, rename, and delete. [Monitor channels and devices](/beam/api-guides/how-to/channels/monitor-channels) Filter the channel list, read health and alarms, fetch thumbnails, and query device metrics. [Import and export channels](/beam/api-guides/how-to/channels/import-and-export) Move a channel configuration between devices, or restore one after a rebuild. ## Where to go deeper - [Beam Essentials UI](/beam/essentials) covers the same channels through the device interface, including the creation wizard. - [Channels API reference](/api-reference/channels-api) is the complete field-level truth for every schema referenced in these guides. # Connect to a Beam device The Channels API is served by the Beam device itself, so there is no central endpoint and no token exchange. You address the device directly, over HTTP, on the same host and port you already use to reach its web interface. ## Build the base URL The API sits under `/api/` on the device: ```text /api/ ``` `` is the HTTP address of the device, for example `http://10.0.0.10:8080`. The device serves the API over HTTP on port 80 or 8080. [Connect to the Controller](/beam/web-interface/connection) covers the access URL forms for a device, including the ports used for containerized solutions. A full request URL therefore looks like this: ```bash curl http://10.0.0.10:8080/api/channels/ ``` Channel operations sit under `/api/channels/`, and the supporting resources are prefixed with `channel-`, such as `/api/channel-system/` and `/api/channel-metrics/current/`. Network interfaces are the exception and sit at `/api/interfaces/`. Each guide gives the full path for the calls it covers. Requests carry no credentials, so reaching the device is what grants access to it. Keep Beam devices on a management network alongside your other infrastructure rather than on a network reachable by untrusted clients. ## Confirm the device version The API is only present on Beam `1.12.0` and higher. Requests to a device on an earlier version do not reach the API at all, so a connection error or a 404 on the base path is the expected symptom rather than an authentication failure. Check the version the device reports: ```bash curl /api/channel-system/ ``` The response wraps the device identity in a `data` object: ```json { "data": { "softwareVersion": "1.12.0.7", "softwareName": "beam", "serialNumber": "", "hardwareModel": "VEGA-7010" } } ``` `softwareVersion` carries a build number as a fourth component, so compare it part by part rather than against the string `1.12.0`. A device that does not report a value returns an empty string, as `serialNumber` does above, so check for emptiness rather than for `null`. A successful response here confirms two things at once: your base URL is correct, and the device is on a supported version. ## Check that the device can be managed A device may be on a supported version but still be running channels that predate the Channels API. `GET /api/channel-deployment/eligibility/` reports whether the API can take over the device: ```bash curl /api/channel-deployment/eligibility/ ``` `canRun` is the verdict. `deploymentState` describes the current state of the device, and `resources` lists the existing services, feeds, and saved configurations found on it. Each entry carries `canUpgrade` and a `reason`, so when `canRun` is `false` the `resources` list tells you which object is blocking it. ## Check what the hardware supports `GET /api/channel-capability/` reports the option cards fitted to the appliance and the features they enable: ```bash curl /api/channel-capability/ ``` `optionCardData` describes the installed SDI, satellite demodulator, and SMPTE ST 2110 cards along with their firmware. `capabilities` reports what the appliance can do, including `bissCaAvailable`, `receiverMultipleInputStream`, and its `st2110OutputProfile`. Use it to find out whether a device supports a feature before you build a channel that depends on it, and [Read the interfaces](/beam/api-guides/how-to/channels/manage-channels) for the individual ports. ## Explore the API The [Channels API reference](/api-reference/channels-api) is the place to browse endpoints and schemas. The device also serves a Swagger page for its own build, which is worth using when you want to execute requests against a specific device rather than read about them: ```text /api/channel-docs/ ``` ## Reach a device you cannot route to If the device is registered in MK.IO, you can open its interface remotely rather than connecting over the local network. See [Access the remote device UI](/mkio/how-to/managing-edge-devices/access-the-remote-device-ui). ## Next step With a base URL that returns a system response, you can create your first channel. See [Create and manage channels](/beam/api-guides/how-to/channels/manage-channels). # How Beam channels work A _channel_ is a single end to end media path on an MK.IO Beam device: one or more inputs, an optional transform, and one or more outputs, managed as one object. The Advanced view of the device interface exposes the individual services that make this up. The Channels API, like the Essentials UI, hides that layer and gives you the channel as a single resource. Every channel is identified by `metadata.name`, which is also the value you put in the path of every request. `metadata.displayName` is the human readable label shown in the interface, and the two do not have to match. ## Spec and status A channel object has two halves, and knowing which one you are looking at saves a lot of confusion:
Half Who writes it What it holds
spec You The configuration you want: type, desired state, inputs, transform, and outputs.
status The device What is actually happening: actual state, health severity, live input and output detail, and sync state.
`spec.state` is your _desired_ state and accepts `Running` or `Stopped`. `status.state` is the _actual_ state and reports the same two values. When you start a channel, the two disagree for a short period, which is normal. `GET /api/channels/{channel_id}/` returns both halves. A create or replace request sends only `kind`, `metadata`, and `spec`, because the device owns everything in `status`. ## The five channel types `spec.type` is the most important decision you make, because it determines which input and output types the device will accept and whether a transform is required.
spec.type Use it for Accepted inputs Accepted outputs
EncodingContribution Encoding a baseband source for onward contribution at high quality SDI, Smpte2110 ASI, UDP, SRTCaller, SRTListener, RF
EncodingDistribution Encoding a baseband source for distribution to viewers SDI, Smpte2110 ASI, UDP, SRTCaller, SRTListener, RF
EncodingStreaming Encoding a baseband source into adaptive bitrate streaming output SDI HttpStreaming
ReceptionDecoding Receiving a transport stream and decoding it back to baseband SRTCaller, SRTListener, UDP, ASI, SatDemod SDI, Smpte2110
ReceptionGateway Receiving a transport stream and passing it on without decoding SRTCaller, SRTListener, UDP, ASI, SatDemod ASI, UDP, SRTCaller, SRTListener, RF
`SDI` is a Serial Digital Interface port, `ASI` is an Asynchronous Serial Interface port, `SatDemod` is a satellite demodulator, `RF` is a satellite modulator output, and the `SRT` types are Secure Reliable Transport callers and listeners. Which of these a device actually has depends on its hardware, so read `GET /api/interfaces/` before you commit to a design. Contribution and distribution accept the same inputs and outputs, so the practical difference is the video codec list each one allows. Contribution offers the mezzanine grade codecs, including the 4:2:2 profiles and JPEG XS. Distribution offers the delivery grade codecs, such as `HEVCMain`, `H264High`, `H264Main`, and `MPEG2`. Choosing the wrong type is the most common reason a codec value is rejected. ## When a transform is required `spec.transform` carries the encoding configuration, and whether you must supply it depends on the channel type: - `EncodingContribution` and `EncodingDistribution` require `transform.encoding`, which holds the video settings and the audio track list. - `EncodingStreaming` requires `transform.abrEncoding` instead, which holds the adaptive bitrate representations. - `ReceptionDecoding` and `ReceptionGateway` do not take a transform at all, because nothing is re-encoded. ## Configuration is applied in the background Create, replace, and import requests return as soon as the device has accepted the channel. The device then pushes the underlying service configuration out separately, so a `200` response means the request was valid rather than that the channel is live. `status.syncState` tells you where that background work got to:
syncState Meaning
Ok The configuration on the device matches the spec you sent.
Configuring The device is still applying the change.
ConfigFailed The device rejected the configuration when it tried to apply it.
SyncFailed The device could not reconcile the channel with its services.
Failed The channel is in a failed state.
Poll `GET /api/channels/{channel_id}/` after any write and treat `syncState` as the asynchronous result of your request, rather than the status code. `status.syncError` is a list of strings carrying the detail behind the failure states. Synchronisation runs in both directions, between the Channels API and the Advanced APIs underneath it, so `syncState` also reports problems that originate from a change made outside the Channels API. ## Fields the Channels API cannot represent Configuration changes made through the Advanced UI are normally synchronised back into the `spec` of the matching channel. The Channels API is deliberately a simpler model, though, so some of the less common Advanced settings have no equivalent in it. When that happens, the affected `spec` fields are given the value `Unsynced`, which most of the enumerations in the API include for this purpose, and the field paths are listed in `status.unsyncedFields`. This is information rather than an error, and it does not mean the channel will not work. Editing a channel in the Advanced UI means taking responsibility for the advanced configuration being correct. What it does mean is that once a channel has drifted far enough from the Channels API model to report `Unsynced`, you need to make further changes to it through the Advanced UI, because the Channels API can no longer describe it in full. ## Health and alarms `status.health.severity` gives a single rolled-up severity for the channel, and the same severity scale appears on each input and output and on every alarm. The values are `Critical`, `Major`, `Minor`, `Notice`, `Ignore`, and `Clear`. A healthy channel reports `Clear`. Health tells you that something is wrong. Alarms tell you what. See [Monitor channels and devices](/beam/api-guides/how-to/channels/monitor-channels) for reading both. ## Where to go deeper - [Beam Essentials UI](/beam/essentials) shows the same model through the device interface, which is often the quickest way to understand a channel before you script it. - [Manage alarms](/beam/system-admin/maintenance/manage-alarms) covers alarm types and overrides at the device level. - [Channels API reference](/api-reference/channels-api) lists every field of `ChannelSpec` and `ChannelStatus`. # Import and export channels Export and import move channel configuration in and out of a device as a single JSON payload. Use them to copy a working setup onto a second device, to keep a copy of a configuration before a risky change, or to rebuild a device to a known state. Both endpoints work on the whole payload rather than on one channel at a time, so they are a different job from the create and replace calls in [Create and manage channels](/beam/api-guides/how-to/channels/manage-channels). ## Export a configuration `POST /api/channel-export/` takes a body, even when you want everything. Omit `channels` to export every channel on the device: ```bash curl -X POST /api/channel-export/ \ -H "Content-Type: application/json" \ -d '{ "description": "Studio A, before firmware update" }' \ --output beam-channels.json ``` To export a subset, name the channels: ```bash curl -X POST /api/channel-export/ \ -H "Content-Type: application/json" \ -d '{ "channels": ["news-contribution", "udp-to-sdi"], "description": "News channels only" }' \ --output beam-channels.json ``` `description` is optional and is carried through into the exported payload, which makes it worth setting when the file is going to sit somewhere for a while. The payload identifies itself with `schemaVersion`, `exportedAt`, and `sourceVersion`, and holds the channels under `channels`. Each exported channel carries its `metadata` and `spec`, and by default also the underlying `services` that the device generated from that spec. Set `includeServices` to `false` for a lighter, specification-only export: ```bash curl -X POST /api/channel-export/ \ -H "Content-Type: application/json" \ -d '{ "includeServices": false }' \ --output beam-channels-spec-only.json ``` On import, the device regenerates the services from its own templates. That is usually what you want when moving between devices, because the target device builds services suited to itself. Keep the services when you want the destination to match the source as closely as possible. ## Import a configuration `POST /api/channel-import/` takes an `ExportPayload` under `payload`, along with the import mode. Send the payload you saved from the export step: ```bash curl -X POST /api/channel-import/ \ -H "Content-Type: application/json" \ -d '{ "payload": , "mode": "merge" }' ``` `` is an object with the `schemaVersion`, `exportedAt`, and `channels` fields described above. Check it against the `ExportPayload` schema in the [Channels API reference](/api-reference/channels-api) if you are assembling one by hand rather than reusing an export. Two modes, and the difference matters:
mode Effect
merge (default) Creates channels that are missing, updates channels that have changed, and leaves every other channel on the device alone.
replace Deletes any channel that is not in the payload, then creates and updates the rest.

mode set to replace with an empty channels list deletes every channel on the device. Check the payload before sending a replace import.

The optional `state` field overrides the desired state of every imported channel, and accepts `Running` or `Stopped`. Setting it to `Stopped` imports a configuration without putting anything on air, which is the safer way to bring a payload onto a live device. ## Check the result The response summarises what the device accepted: ```json { "imported": [ { "name": "news-contribution", "sourceName": "news-contribution", "displayName": "News contribution", "status": "accepted", "error": null } ], "deleted": [], "errors": [], "warnings": [] } ``` Each entry in `imported` has a `status` of `accepted`, `skipped`, or `rejected`, with `error` carrying the reason for a rejection. `deleted` lists the channels a replace import removed. `errors` and `warnings` cover problems with the payload as a whole rather than with one channel. `accepted` means the channel passed validation, not that it is configured. Import returns as soon as the payload is validated, and the device applies the configuration in the background. Poll `GET /api/channels/{channel_id}/` for each imported channel and read `status.syncState` to see how it finished. See [How Beam channels work](/beam/api-guides/how-to/channels/how-channels-work) for the values. ## What goes wrong **A merge import did not remove an old channel.** That is what merge does. Use `replace` if the payload is meant to be the complete set. **Channels came up running when you did not want them to.** The desired state travels with the payload. Set `state` to `Stopped` on the import request to override it. **A channel was accepted but never came up.** Import validation and configuration are separate steps. Check `status.syncState` and `status.syncError` on the channel itself. **The destination device is equipped differently.** A spec that names `eth1` or `slot_1_port_1` depends on the target having that interface. Call `GET /api/interfaces/` on the destination and compare it against the payload before importing, then check both `ImportResult` and each channel's `status.syncState` afterwards. ## Where to go deeper - [Configuration backups](/mkio/how-to/managing-edge-devices/configuration-backups) covers whole-device backups through MK.IO, which is a broader safety net than a channel export. - [Channels API reference](/api-reference/channels-api) documents `ExportPayload`, `ImportRequest`, and `ImportResult` in full. # Create and manage channels Channels are created with `PUT /api/channels/{channel_id}/`, where `{channel_id}` is the channel name you choose. The same request creates a channel that does not exist and replaces one that does, so there is no separate create endpoint and no generated identifier to keep track of. Read [How Beam channels work](/beam/api-guides/how-to/channels/how-channels-work) first if you have not picked a `spec.type` yet, because that choice constrains everything else in the body. ## Read the interfaces first Channel inputs and outputs point at real ports on the device, so start by asking the device what it has: ```bash curl /api/interfaces/ ``` The response groups interfaces by kind. This is a response from a VEGA-7010, abbreviated to the first two of its four slot ports, with the addresses replaced: ```json { "ip": [ { "name": "lo", "type": "IP", "ipAddresses": ["127.0.0.1"], "displayName": "lo" }, { "name": "eth0", "type": "IP", "ipAddresses": ["10.0.0.10"], "displayName": "eth0" }, { "name": "eth1", "type": "IP", "ipAddresses": ["172.16.0.10"], "displayName": "eth1" } ], "sdi": [ { "name": "slot_1_port_1", "type": "SDIASI", "url": "sdi://localhost/slot_1_port_1", "displayName": "Slot 1 / Port 1" }, { "name": "slot_1_port_2", "type": "SDIASI", "url": "sdi://localhost/slot_1_port_2", "displayName": "Slot 1 / Port 2" } ], "asi": [ { "name": "slot_1_port_1", "type": "SDIASI", "url": "asi://localhost/slot_1_port_1", "displayName": "Slot 1 / Port 1" }, { "name": "slot_1_port_2", "type": "SDIASI", "url": "asi://localhost/slot_1_port_2", "displayName": "Slot 1 / Port 2" } ], "rf_demod": [], "rf_modulator": [], "st2110": [] } ``` The groups are `ip`, `sdi`, `asi`, `rf_demod`, `rf_modulator`, `cam`, and `st2110`. Every one of them defaults to an empty array, so what a device returns depends entirely on the hardware fitted to it. The device above has no satellite demodulator or modulator, so `rf_demod` and `rf_modulator` are empty. Another device will list different slots and different port counts, which is why this call belongs at the start of any integration rather than in your notes. Network transports take an interface `name`, such as `eth0`. Baseband and RF transports take the `url` exactly as returned. Copy the `url` rather than composing it. The same physical port is listed under both `sdi` and `asi` with the same `name`, and only the scheme in the `url` distinguishes them. A `name` on its own does not identify a port. Entries under `sdi` also carry a `caps` object describing what the port supports, which the older device above does not report. See the `SdiSlotPortInterface` schema in the [Channels API reference](/api-reference/channels-api). ## Create a channel This request creates a contribution channel that takes a Serial Digital Interface (SDI) source, encodes it, and publishes it as a Secure Reliable Transport (SRT) listener that a remote decoder can connect to. It is created stopped, so nothing goes on air until you ask it to. ```bash curl -X PUT /api/channels/news-contribution/ \ -H "Content-Type: application/json" \ -d '{ "kind": "BeamChannel", "metadata": { "name": "news-contribution", "displayName": "News contribution" }, "spec": { "type": "EncodingContribution", "state": "Stopped", "inputs": [ { "type": "SDI", "name": "sdi-in", "transport": { "url": "sdi://localhost/slot_1_port_1" } } ], "transform": { "encoding": { "video": { "codec": "H264High", "videoFormat": "1920x1080p", "bitrate": 15000000 }, "audios": [ { "codec": "AC3", "mode": "Stereo", "bitrate": 128000 } ] } }, "outputs": [ { "type": "SRTListener", "transport": { "interface": "eth0", "port": 9000 } } ] } }' ``` The fields that are easy to get wrong: - Set `metadata.name` to the same value as the `{channel_id}` in the path. It is the identifier you use in every later request, and it cannot be changed afterwards. Any string works, so a readable slug such as `news-contribution` is easier to live with than a generated identifier. Channels created through the Essentials UI are named with a UUID instead, so expect both forms when you list a device you did not set up. - Each entry in `inputs` needs its own `name`. This is your label for the input, and it is how the audio entries in `transform.encoding.audios` refer back to it through `inputName`. The device assigns its own separate name to the input in `status`, so do not expect this value to appear there. - `bitrate` is in bits per second and accepts `100000` to `60000000`. Audio `bitrate` is also in bits per second, and the accepted values depend on the audio codec and mode. - `port` on an SRT listener accepts `256` to `65535`. - Outputs take no `name`, unlike inputs. The one exception is an `ASI` output, where `name` is optional. The device names every output itself in `status` regardless. The response is the full channel object, including the `metadata.created` timestamp and an initial `status`. A `200` here means the device accepted the configuration, not that the channel is configured. Confirm the result: ```bash curl /api/channels/news-contribution/ ``` Read `status.syncState`. It reports `Configuring` while the device applies the change and `Ok` once the running configuration matches your spec. Anything else means the configuration was accepted but could not be applied, and `status.syncError` carries the detail. ## Choosing between variants The body above is one shape of channel. Use this table to find the shape you need, then adapt the example:
Your situation spec.type Body differences
Encoding a baseband source for onward contribution EncodingContribution Requires transform.encoding. Video codecs are the 4:2:2 and JPEG XS profiles, plus H264High and its variants.
Encoding a baseband source for delivery to viewers EncodingDistribution Requires transform.encoding. Video codecs are the delivery profiles: HEVCMain, HEVCMain10bit, H264High, H264Main, and MPEG2.
Encoding a baseband source into adaptive bitrate output EncodingStreaming Requires transform.abrEncoding instead of transform.encoding. The only output type is HttpStreaming.
Receiving a stream and putting it back to baseband ReceptionDecoding No transform. Outputs are SDI or Smpte2110.
Receiving a stream and passing it on untouched ReceptionGateway No transform. Outputs are the transport types, as for contribution.
A reception channel is considerably shorter, because there is nothing to encode. This one takes a multicast UDP source and decodes it out of an SDI port, and starts immediately: ```bash curl -X PUT /api/channels/udp-to-sdi/ \ -H "Content-Type: application/json" \ -d '{ "kind": "BeamChannel", "metadata": { "name": "udp-to-sdi", "displayName": "UDP to SDI decoder" }, "spec": { "type": "ReceptionDecoding", "state": "Running", "inputs": [ { "type": "UDP", "name": "udp-in", "transport": { "url": "udp://239.100.1.1:5001", "interface": "eth0" } } ], "outputs": [ { "type": "SDI", "transport": { "url": "sdi://localhost/slot_1_port_1" } } ] } }' ``` A UDP input needs both a `url` and an `interface`, because the device has to know which network port to receive the stream on. Unicast and multicast addresses are both supported, and the Channels API has no field to choose between them: an address in the class D range, `224.0.0.0/4`, is treated as multicast, and anything outside that range is treated as unicast. Where an exception to that check is needed, the Advanced interface offers an explicit [**Unicast**](/beam/receiver/parameters#ip) control. For the full list of input and output schemas, including SMPTE 2110 and satellite demodulator inputs, see the [Channels API reference](/api-reference/channels-api). ### Encrypting an SRT output To encrypt an SRT output, set `encryptionStandard` to `AES128`, `AES192`, or `AES256`, and supply a passphrase of at least 10 characters: ```json { "type": "SRTListener", "transport": { "interface": "eth0", "port": 9000, "encryptionStandard": "AES128", "passPhrase": "" } } ``` `passPhrase` is optional while `encryptionStandard` is `None`, which is the default, and required as soon as it is anything else. A passphrase shorter than 10 characters is rejected. ## Start, stop, and rename `PATCH /api/channels/{channel_id}/` handles the two changes you make most often. It accepts only the desired state and the display name, so use `PUT` for anything else. Start a channel: ```bash curl -X PATCH /api/channels/news-contribution/ \ -H "Content-Type: application/json" \ -d '{ "spec": { "state": "Running" } }' ``` Send `"Stopped"` in the same shape to take it off air. Rename it with the other half of the body: ```bash curl -X PATCH /api/channels/news-contribution/ \ -H "Content-Type: application/json" \ -d '{ "metadata": { "displayName": "News contribution, main feed" } }' ``` Both fields are nested under `spec` and `metadata` respectively. A flat body such as `{"state": "Running"}` does not change anything, because neither key is recognised at the top level. Renaming changes `displayName` only. `metadata.name` is fixed for the life of the channel, so a channel that needs a different identifier has to be recreated. ## Delete a channel ```bash curl -X DELETE /api/channels/news-contribution/ ``` A successful delete returns `204` with no body. The device stops the underlying services before removing the channel. Errors during that cleanup are logged on the device but do not stop the channel being removed, so a `204` confirms the channel is gone rather than that everything behind it shut down cleanly. ## What goes wrong **The request succeeded but nothing is on air.** Check `spec.state`. A channel created with `"state": "Stopped"` stays stopped until you patch it. If it is `Running`, check `status.syncState` and `status.syncError`. **A codec value is rejected.** The accepted video codecs depend on `spec.type`. `HEVCMain` is valid for `EncodingDistribution` and `EncodingStreaming` but not for `EncodingContribution`, which takes the 4:2:2 profiles. The accepted `videoFormat` values then depend on the codec you chose, and the interlaced formats are not available with the progressive-only codecs such as JPEG XS. **An audio bitrate is rejected.** Audio bitrate is constrained by codec and mode together. `AC3` with `Stereo` starts at `96000`, while `AC3` with `Surround51` starts at `224000`. **A `PUT` removed settings you did not send.** `PUT` replaces the channel rather than merging into it. Fetch the channel, change what you need in the returned `spec`, and send the whole `spec` back. **The response is `422`.** The body contains a `detail` array, and each entry has a `loc` array giving the exact path to the offending field. Read `loc` before anything else, because it points straight at the field name. **The response is `503`.** The channel endpoints return `503` when the API cannot serve the request. Retry, and if it persists, check the device itself. ## Where to go deeper - [Monitor channels and devices](/beam/api-guides/how-to/channels/monitor-channels) covers reading status, alarms, and thumbnails once a channel exists. - [Beam Essentials UI](/beam/essentials) walks the same configuration through the channel creation wizard, which is a useful way to see a valid combination before you script it. - [Channels API reference](/api-reference/channels-api) holds the complete `ChannelSpec` schema, including every input and output variant. # Monitor channels and devices Everything you need to build a dashboard or an alerting rule comes from four places: the channel list, the alarm list, the thumbnail endpoint, and the device metrics. This page covers each of them and the query options that keep the responses small. ## List channels ```bash curl /api/channels/ ``` The response follows the same envelope as the other MK.IO list endpoints. Channels are in `value`, and `supplemental` carries the counts. This is a response from a device holding nine channels, requested one at a time with `$top=1`, with the addresses replaced: ```json { "value": [ { "kind": "BeamChannel", "metadata": { "name": "9b9c65bd-b383-4ed2-ae5a-fcde805e4e8c", "displayName": "demo-channel_0", "created": "2026-05-20T07:52:01.637000Z" }, "spec": { "type": "EncodingDistribution", "state": "Stopped", "inputs": [ { "type": "SDI", "name": "input_1", "transport": { "url": "sdi://localhost/slot_1_port_3" }, "payload": { "audios": [ { "name": "Audio_1", "aggregation": { "type": "None", "pair": "G1P1" } } ] } } ], "transform": { "encoding": { "video": { "codec": "H264Main", "videoFormat": "1280x720p", "bitrate": 2000000 }, "audios": [ { "name": "Audio_1_encoded_1", "inputName": "input_1", "audioName": "Audio_1", "codec": "PassThrough" } ] } }, "outputs": [ { "type": "UDP", "transport": { "url": "udp://239.1.1.1:5000", "interface": "eth1" } } ] }, "status": { "state": "Stopped", "health": { "severity": "Clear" }, "inputs": [ { "health": { "severity": "Clear" }, "name": "sdi-0", "thumbnailUrl": "thumbnails/sdi-0/thumbnail.jpg", "thumbnailPresence": "Absent", "type": "SDI" } ], "outputs": [ { "name": "udp-0", "health": { "severity": "Clear" }, "type": "UDP", "transport": { "url": "udp://239.1.1.1:5000", "interface": "eth1" }, "payload": { "video": { "resolution": "1280x720", "codec": "H264Main", "bitrate": 2000000 }, "audios": [{ "codec": "PassThrough" }] } } ], "syncState": "Ok", "syncError": [] } } ], "@odata.nextLink": "/channels?%24skiptoken=1&%24top=1&%24orderby=metadata%2Fcreated", "supplemental": { "kind": "BeamChannelList", "count": 1, "operation": "list", "pagination": { "start": 0, "end": 1, "records": 1, "total": 9 } } } ``` Three things in that response are worth pausing on. `metadata.name` is a UUID here because this channel was created in the Essentials UI. A channel you create through the API keeps whatever name you gave it. Both forms appear on the same device, so treat the name as an opaque identifier and show `displayName` to people. The names in `spec` and the names in `status` are not the same values. The spec input is called `input_1`, and the device reports it in `status` as `sdi-0`. Match inputs by position or by `type` rather than by name. `supplemental.pagination.records` counts what came back in this page, and `total` counts every channel that matched. Follow `@odata.nextLink` for the next page rather than calculating the offset yourself, and use it exactly as returned: it is a relative path with the `$` characters percent-encoded. The response above was captured before the API moved under `/api/`, so treat the prefix on that link as whatever your device returns rather than the one shown here. An audio track encoded as `PassThrough` carries no `mode` or `bitrate`, because nothing is re-encoded. Those fields are required for every other audio codec. ## Filter, sort, and page The list endpoint takes OData-style query parameters:
Parameter Default Purpose
$filter none An expression that limits which channels are returned.
$orderby metadata/created A sort field with optional asc or desc. Comma-delimit for multiple keys.
$select none A comma-separated list of fields to return.
$top 1000 Maximum items per page, from 1 to 1000.
$skiptoken 0 Offset into the results.
`$filter` supports the operators `eq`, `ne`, `lt`, `le`, `gt`, and `ge`, combined with `and` and `or`, plus the functions `contains()`, `tolower()`, and `toupper()`. Paths into the object use slashes. Fetch only the channels that are not healthy, worst first: ```bash curl -G /api/channels/ \ --data-urlencode "\$filter=status/health/severity ne 'Clear'" \ --data-urlencode "\$orderby=status/health/severity desc" ``` Escaping the `$` matters in shells that would otherwise treat `$filter` as a variable, and `--data-urlencode` handles the spaces and quotes in the expression for you. A few more expressions that cover most monitoring needs: - `$filter=status/state eq 'Running'` returns the channels that are actually on air, which is not the same as the channels you asked to run. - `$filter=contains(tolower(metadata/displayName), 'news')` does a case-insensitive name search. - `$filter=metadata/created ge 2026-01-01T00:00:00Z` returns recently created channels. Filtering, sorting, and pagination are all applied on the device after every channel has been loaded with its live status. That is fine at the channel counts a single Beam device carries, but it does mean a narrow `$filter` does not make the call cheaper. `$select` is the exception. When you pass it, the device skips loading live status entirely, so a call that only needs names and types is noticeably lighter than a full list. ## Read one channel ```bash curl /api/channels/news-contribution/ ``` The `status` object is where the live detail sits: - `state` is the actual state, `Running` or `Stopped`, which can differ from `spec.state` while a change is being applied. - `health.severity` is the rolled-up channel severity: `Critical`, `Major`, `Minor`, `Notice`, `Ignore`, or `Clear`. - `inputs` and `outputs` carry their own health, along with transport detail such as SRT connection statistics and the services detected on the input. - `syncState` and `syncError` report whether the configuration you sent was successfully applied. See [How Beam channels work](/beam/api-guides/how-to/channels/how-channels-work) for the values. - `errors` holds any faults the device wants to show a person, already written for display. Each entry in `status.errors` carries a short summary in `userShort`, capped at 40 characters, a fuller sentence in `userMessage`, and further context in `detail`. Use those rather than composing your own wording from `code`, which is an internal identifier. Two flags tell you how to present it: `showCode` is the device's own advice on whether the `code` is worth showing to a person, and `transient` marks a fault that may clear without intervention, which is usually a reason to soften how prominently you display it. ## Read active alarms Health tells you a channel is unwell. Alarms tell you why. The alarm endpoint is scoped to one channel, and `channelName` is required: ```bash curl -G /api/channel-channelalarms/active/ \ --data-urlencode "channelName=news-contribution" ``` Each alarm has a `metadata` half identifying it and a `status` half describing it. The placeholders below stand in for values the device supplies: ```json { "value": [ { "kind": "Alarm", "metadata": { "id": "", "name": "", "displayName": "", "objectId": "", "channelName": "news-contribution", "created": "2026-07-01T09:31:12Z" }, "status": { "severity": "Critical", "additionalInfo": "" } } ], "supplemental": { "kind": "AlarmList", "count": 1, "operation": "list", "pagination": { "start": 0, "end": 1, "records": 1, "total": 1 } } } ``` `` is a UUID, and `` is the device's machine name for the fault, with `` its readable form. `` identifies the part of the channel that raised it. `` is the free-text explanation in `status.additionalInfo`, and it is the field worth surfacing in an alert. `severity` uses the same scale as channel health. For the alarms a Beam device raises and how to override them, see [Manage alarms](/beam/system-admin/maintenance/manage-alarms). Because the endpoint takes one channel at a time, an alarm view across a device means listing the unhealthy channels first and then fetching alarms for each one. ## Fetch an input thumbnail Each entry in `status.inputs` carries a `thumbnailUrl`, relative to the channel: ```json { "name": "sdi-0", "thumbnailUrl": "thumbnails/sdi-0/thumbnail.jpg", "thumbnailPresence": "Absent", "type": "SDI" } ``` Use that value rather than building the path yourself. The identifier in it is the name the device assigns to the input in `status`, not the name you gave the input in `spec`, so composing the path from your own spec produces a URL that does not resolve. ```bash curl /api/channels//thumbnails/sdi-0/thumbnail.jpg \ --output thumbnail.jpg ``` Check `thumbnailPresence` before you fetch. It reports `Present`, `Absent`, `Unknown`, or `Unsynced`. The path ends in `.jpg` so that browsers treat the response as a plain image, which means you can point an `` tag straight at it. ## Query device metrics For a point-in-time reading of the device itself: ```bash curl /api/channel-metrics/current/ ``` ```json { "data": { "serverId": "Server1", "cpuUtilizationPercent": 34.52094163392065, "uptimeSeconds": 1041534.8420000076 }, "collectedAt": "2026-07-29T13:13:32.843368Z" } ``` `temperatureCelsius` is not present in the response above. Read every field under `data` defensively: depending on the device and the sensors fitted to it, a metric can come back as `null` or be left out of the response altogether. Show a dash where a value is absent, as the Essentials dashboard does. Narrow the response with `$select`, which accepts `serverId`, `cpuUtilizationPercent`, `temperatureCelsius`, and `uptimeSeconds`: ```bash curl -G /api/channel-metrics/current/ \ --data-urlencode "\$select=cpuUtilizationPercent,temperatureCelsius" ``` For a history rather than a snapshot, `GET /api/channel-metrics/cpu/` and `GET /api/channel-metrics/temperature/` take a time range. Both require `start` and `end`, which accept ISO 8601 timestamps or Unix timestamps, and take an optional `step` that defaults to `60s`: ```bash curl -G /api/channel-metrics/cpu/ \ --data-urlencode "start=2026-07-01T00:00:00Z" \ --data-urlencode "end=2026-07-01T01:00:00Z" \ --data-urlencode "step=60s" ``` These return the Prometheus range format rather than the envelope used elsewhere in this API. `status` is `success` or `error`, and `data.result` is an array of series, each with a `metric` label set and a `values` array of `[unix_timestamp, value_string]` pairs. The value is a string, so parse it before you chart it. `GET /api/channel-metrics/query/` takes an arbitrary PromQL expression in `query`, along with the same `start`, `end`, and `step`. Use it when the two named endpoints do not cover the metric you need. ## What goes wrong **The channel list is slow.** Live status is loaded for every channel before filtering, so the cost is in the channel count rather than the filter. If you are polling frequently and only need identity, pass `$select` to skip status hydration. **A `$filter` returns nothing you expected.** String values in an expression are single quoted, and paths use slashes rather than dots. Compare `status/health/severity ne 'Clear'` against a dotted or unquoted version, which will not match. **A thumbnail URL does not resolve.** The identifier in the path is the input name from `status`, which the device assigns, not the input name you set in `spec`. Read `thumbnailUrl` off the status object instead of composing the path. **A metric field has no value.** A reading the device cannot supply can be `null` or absent from `data`, so a client that reads `data.temperatureCelsius` directly may get either on a device without a temperature sensor. Treat every field under `data` as optional and handle both. ## Where to go deeper - [Manage alarms](/beam/system-admin/maintenance/manage-alarms) covers alarm types and overrides at the device level. - [Beam Essentials UI](/beam/essentials) shows the same status, alarms, and metrics on the device dashboard. - [Channels API reference](/api-reference/channels-api) documents every field of `ChannelStatus`, including the per-transport statistics. # Build with the Fleets API The Fleets API is the operational API for MK.IO Beam devices. Use it to register devices into a project, protect their configuration with backups, manage software versions, and collect support packages when you need diagnostics. ## API overview
Detail Value
Base path /api/v1/projects/{project_name}/fleet/
Scope Project
Reference Fleets API reference
## How the main resources connect The Fleets API revolves around a few resource types: 1. A **device** represents the Beam device record in MK.IO. 2. A **backup** is a configuration snapshot you can restore later. 3. **Software** settings on the device control desired and preloaded versions. 4. A **support package** is a diagnostic bundle generated on the device and uploaded to storage. That means a typical operational flow is: register the device, take backups before risky changes, control software state through device patch operations, and collect support packages when something goes wrong. ## Common workflow patterns ### Operate a Beam device 1. [Register and manage devices](/beam/api-guides/how-to/fleets/device-management) 2. [Back up configuration before changes](/beam/api-guides/how-to/fleets/backups-and-restores) 3. [Control software versions](/beam/api-guides/how-to/fleets/software-and-updates) 4. [Collect a support package for diagnostics](/beam/api-guides/how-to/fleets/software-and-updates) ## Guides [Manage devices](/beam/api-guides/how-to/fleets/device-management) Register devices, inspect state, and work through the core day-to-day operations. [Backups and restores](/beam/api-guides/how-to/fleets/backups-and-restores) Create backups before changes, inspect stored backup metadata, and restore safely. [Software and updates](/beam/api-guides/how-to/fleets/software-and-updates) Control desired and preloaded software versions and collect support packages for diagnostics. # Backups and restores A backup is the safety net for Beam device operations. Take one before a software change or a service removal, and you have a configuration you can roll back to. A backup captures the device's services, templates, failover groups, server definitions, and local users. Backup and restore operations run asynchronously on the device and return `202 Accepted`. ## Create a backup A backup is triggered with `POST` against the device. Use a descriptive `backupName`, such as one with a date, so its purpose is clear later. ```bash curl -X POST "https://app.mk.io/api/v1/projects//fleet/devices/my-device/backup" \ -H "Authorization: Bearer " \ -H "Content-Type: application/json" \ -d '{ "metadata": { "displayName": "Pre-update backup" }, "spec": { "backupName": "pre-update-20260415-100000", "backupAssetFile": false } }' ``` The call returns `202 Accepted` and the backup completes on the device over the next while. Configuration access on the device is blocked while a backup or restore is in progress. ## Browse backups List the backups in a project, and read one to get its stored file details: ```bash curl -X GET "https://app.mk.io/api/v1/projects//fleet/backups" \ -H "Authorization: Bearer " curl -X GET "https://app.mk.io/api/v1/projects//fleet/backups/" \ -H "Authorization: Bearer " ``` A backup record carries its `timestamp`, the `blobStorageUrl` of the stored file, and a `signature` for integrity verification. The list endpoint supports `$filter`; see the [Fleets API reference](/api-reference/fleets-api) for the filterable fields. ## Restore a backup Restore is also a `POST`, with the stored file path from the backup record. It returns `202 Accepted` and applies asynchronously. ```bash curl -X POST "https://app.mk.io/api/v1/projects//fleet/devices/my-device/restore" \ -H "Authorization: Bearer " \ -H "Content-Type: application/json" \ -d '{ "metadata": { "displayName": "Restore pre-update snapshot" }, "spec": { "restoreFilePath": "my-device//pre-update-20260415-100000.tar.gz", "restoreAssetFile": false } }' ``` Confirm the backup identity before you restore it onto a live device. ## Upload an external backup If you already hold a `.tar.gz` backup file, upload it and let MK.IO generate its metadata: ```bash curl -X POST "https://app.mk.io/api/v1/projects//fleet/uploadBackup" \ -H "Authorization: Bearer " \ -H "Content-Type: application/octet-stream" \ --data-binary @my-device-backup.tar.gz ``` ## What goes wrong - **Restoring a backup onto a different Beam server.** This is not supported. A backup restores to the device it came from. See the on-device detail in [Backup and restore](/beam/system-admin/maintenance/backup-restore). - **Old backups disappearing.** A device keeps up to 30 local backups and deletes the oldest when that limit is reached. Download or upload any you must retain. - **Configuration changes blocked mid-operation.** Device configuration access is locked while a backup or restore runs. Wait for it to finish. ## What comes next - [Software and updates](/beam/api-guides/how-to/fleets/software-and-updates): take a backup before changing software state. - [Manage devices](/beam/api-guides/how-to/fleets/device-management): return to the device once protection is in place. # Manage devices Device management is where most Fleets API workflows begin. MK.IO Beam is an on-premises media processing appliance, and the Fleets API is the cloud control plane for it. You register a device into a project, give it a site and the networks it can use, then move into backup, software, or diagnostic operations. For the on-device onboarding steps that precede registration, see [Onboard a fleet device](/mkio/how-to/managing-edge-devices/on-board-fleet-devices/api-onboarding). ## Register a device A device is created with `PUT`, using its name in the URL. You associate the physical appliance with this record using either a `shortCode` or a `locationId` read from the device web interface. ```bash curl -X PUT "https://app.mk.io/api/v1/projects//fleet/devices/beam-encoder-01" \ -H "Authorization: Bearer " \ -H "Content-Type: application/json" \ -d '{ "metadata": { "displayName": "Beam Encoder 01", "labels": { "location": "studio-a", "role": "encoder" } }, "spec": { "shortCode": "XU7U23WD", "siteName": "headquarters", "availableNetworks": [] } }' ``` The fields that matter: - `shortCode`: the 8-character code from the device web interface. It rotates frequently, so use it promptly. - `locationId`: a stable device identifier that does not rotate. Prefer it for scripted, large-scale onboarding. - `siteName`: the site the device belongs to. See [Set up networks and sites](/beam/api-guides/how-to/infrastructure/networks-and-sites). - `availableNetworks`: the networks the device may use. An empty array gives it access to every network with a route to its site. After registration, the device web interface shows **Registered: Yes**. ## Read the device and its status ```bash curl -X GET "https://app.mk.io/api/v1/projects//fleet/devices/beam-encoder-01" \ -H "Authorization: Bearer " ``` The `status` block is where you watch the device's health and software. The fields worth tracking:
Field Tells you
currentSoftwareVersion The version running now.
softwareUpgradeState Idle, Switching, or SwitchFailed during a version change.
alarmSeverity 0 Clear, 1 Info, 2 Warning, 3 Error, 4 Critical.
lastContact When the device last reached the cloud.
The list endpoint supports `$filter`, `$orderby`, `$top`, `$skiptoken`, and label queries, including sorting on `status/alarmSeverity` and `status/currentSoftwareVersion`. ## Update device settings Use `PATCH` to change settings such as the site, networks, or software preferences: ```bash curl -X PATCH "https://app.mk.io/api/v1/projects//fleet/devices/beam-encoder-01" \ -H "Authorization: Bearer " \ -H "Content-Type: application/json" \ -d '{ "spec": { "autoPreloadLatestSoftware": true } }' ``` The software-related fields (`desiredSoftwareVersion`, `preloadSoftwareVersion`, `autoPreloadLatestSoftware`) are covered in [Software and updates](/beam/api-guides/how-to/fleets/software-and-updates). ## What goes wrong - **Registration fails because the short code expired.** Short codes rotate. Keep the device interface open so it shows the current code, or register with the non-rotating `locationId` instead. - **Deleting a device returns `409 Conflict`.** The device is still referenced, for example by an assigned flow. Clear the dependency, then retry the delete. ```bash curl -X DELETE "https://app.mk.io/api/v1/projects//fleet/devices/beam-encoder-01" \ -H "Authorization: Bearer " ``` ## What comes next - [Backups and restores](/beam/api-guides/how-to/fleets/backups-and-restores): protect device state before major changes. - [Software and updates](/beam/api-guides/how-to/fleets/software-and-updates): control desired and preloaded software versions. # Software and updates Software management in the Fleets API is device-centric. You inspect the versions available to a device, then set fields on the device resource to choose what runs or preloads. The same surface produces support packages for diagnostics. For the product background, see [Update device software](/mkio/how-to/managing-edge-devices/update-device-software). ## List available software ```bash curl -X GET "https://app.mk.io/api/v1/projects//fleet/devices/my-device/software" \ -H "Authorization: Bearer " ``` Each entry reports its `version` and whether the device can move to it, through `status.upgradeCompatible` and `status.downgradeCompatible`. Check those before you target a version. ## Choose how the update happens Three device-spec fields control software, and the right one depends on whether you want to apply the change now or stage it for later.
To... Set Effect
Run a specific version now desiredSoftwareVersion The device switches to it. softwareUpgradeState moves Switching then Idle.
Stage a version without applying it preloadSoftwareVersion The device downloads it; watch status.preloadedSoftware for progress.
Always keep the newest staged autoPreloadLatestSoftware The device preloads the latest available version automatically.
Set the running version: ```bash curl -X PATCH "https://app.mk.io/api/v1/projects//fleet/devices/my-device" \ -H "Authorization: Bearer " \ -H "Content-Type: application/json" \ -d '{ "spec": { "desiredSoftwareVersion": "1.2.3.4" } }' ``` Preloading first, then setting the desired version once the download is complete, makes the actual switch fast and predictable. ## Support packages A support package is the main diagnostic bundle. List the packages held for a device (up to five, newest first), and trigger a new one: ```bash curl -X GET "https://app.mk.io/api/v1/projects//fleet/devices/my-device/supportPackages" \ -H "Authorization: Bearer " ``` ```bash curl -X POST "https://app.mk.io/api/v1/projects//fleet/devices/my-device/supportPackages" \ -H "Authorization: Bearer " \ -H "Content-Type: application/json" \ -d '{ "metadata": { "displayName": "Audio sync issue" }, "spec": { "description": "Investigating audio sync drift on the output stream", "name": "audio-sync-issue-20260415", "collectors": ["Logs", "Host"] } }' ``` Only `description` is required. Omit `collectors` to include all of them. The call returns `202 Accepted`, and only one support-package operation can run on a device at a time. ## Remove selected services To remove services from a device, select them by tag. Take a backup first if you might need to restore the current configuration. ```bash curl -X POST "https://app.mk.io/api/v1/projects//fleet/devices/my-device/removeServices" \ -H "Authorization: Bearer " \ -H "Content-Type: application/json" \ -d '{ "metadata": { "displayName": "Remove audio services" }, "spec": { "description": "Remove audio processing services", "selector": { "tags": { "include": ["audio"], "exclude": [] } } } }' ``` ## What goes wrong - **An "upgrade" that becomes a rollback.** Beam devices use a dual-bank mechanism. If the version you set matches the version already in the second bank, the device performs a rollback rather than a fresh upgrade. Confirm the target version is the one you intend. - **A preloaded version that vanished.** Software-bundle storage is limited, and the device deletes older bundles automatically to make room. Preload close to when you plan to apply. - **A support package request rejected.** Only one support-package operation runs per device at a time. Wait for the current one to finish. ## What comes next - [Backups and restores](/beam/api-guides/how-to/fleets/backups-and-restores): create the rollback point before a software change. - [Manage devices](/beam/api-guides/how-to/fleets/device-management): return to the device resource and its site and network settings. # Build with the Infrastructure API The Infrastructure API defines where Beam devices live and which networks they can reach. Use it to create networks first, then create sites with routes that reference those networks, and finally register devices against those sites through the Fleets API. ## API overview
Detail Value
Base path /api/v1/projects/{project_name}/infra/
Scope Project
Reference Infrastructure API reference
## The two core resources ### Networks Networks represent logical network segments. Their status includes: - `status.owner` - `status.scope` These are valid sort and filter fields for the network list endpoint. ### Sites Sites represent locations where devices operate. A site can include routes that reference one or more networks, which is why site creation usually comes after network creation. ## Typical sequence 1. List existing networks and sites. 2. Create the networks you need. 3. Create sites with routes that reference those networks. 4. Register Beam devices to those sites through the Fleets API. 5. Remove dependent references before deleting sites or networks. ## Common workflow patterns ### Set up infrastructure for Beam devices 1. [Create networks](/beam/api-guides/how-to/infrastructure/networks-and-sites) 2. [Create sites with routes referencing those networks](/beam/api-guides/how-to/infrastructure/networks-and-sites) 3. [Register Beam devices to sites](/beam/api-guides/how-to/fleets/device-management) ## Guide [Set up networks and sites](/beam/api-guides/how-to/infrastructure/networks-and-sites) Follow the recommended order for creating and maintaining infrastructure resources. # Set up networks and sites Networks and sites are the topology layer for Beam devices. A network is a logical segment; a site is a location where devices operate, and its routes decide which networks those devices can reach. The order matters: create the networks first, then create sites whose routes reference them, then register devices to the sites through the [Fleets API](/beam/api-guides/how-to/fleets/device-management). ## Create a network A network is created with `PUT`. Its `spec` is currently empty but must be present; the meaningful content is in `metadata`. ```bash curl -X PUT "https://app.mk.io/api/v1/projects//infra/networks/production-network" \ -H "Authorization: Bearer " \ -H "Content-Type: application/json" \ -d '{ "metadata": { "displayName": "Production Network", "labels": { "environment": "production" } }, "spec": {} }' ``` Reading a network back shows its `status.owner` (`User` or `System`) and `status.scope` (`Connecting` between sites, or `Local` within one). System-owned and local networks are created by the platform. ## Create a site with routes Once the network exists, create a site whose `routes` reference it. A route requires only `networkName`. You can add an optional `defaultTransport` to set how content moves on that network. ```bash curl -X PUT "https://app.mk.io/api/v1/projects//infra/sites/headquarters" \ -H "Authorization: Bearer " \ -H "Content-Type: application/json" \ -d '{ "metadata": { "displayName": "Headquarters", "labels": { "region": "europe", "type": "primary" } }, "spec": { "routes": [ { "networkName": "production-network", "defaultTransport": { "type": "SRTListener" } } ] } }' ``` `defaultTransport.type` is one of `Auto`, `SRTListener`, `SRTCaller`, `UDP`, or `RISTListener`. A device assigned to this site (through its `siteName`) automatically reaches the networks the site routes to. ## Update and delete `PATCH` updates labels, display name, or a site's routes. A `PATCH` to `routes` replaces the whole array, so send the complete set. ```bash curl -X PATCH "https://app.mk.io/api/v1/projects//infra/sites/headquarters" \ -H "Authorization: Bearer " \ -H "Content-Type: application/json" \ -d '{ "metadata": { "displayName": "Main Headquarters" } }' ``` ## What goes wrong - **Creating a site before its network exists.** A route references a network by name. Create the networks first. - **A delete returns `409 Conflict`.** A network cannot be deleted while a site routes to it, and a site cannot be deleted while devices or flows reference it. Clear those references first. - **Trying to delete a system-owned resource.** System-owned networks and sites cannot be deleted, though they can be modified. Check `status.owner` before you try. ## What comes next - [Manage devices](/beam/api-guides/how-to/fleets/device-management): register Beam devices against the sites you created. # Understand the Beam APIs - [API overview](/beam/api-guides/understanding/overview): cloud and device-local connections. - [How channels work](/beam/api-guides/how-to/channels/how-channels-work): the Channels API resource model. - [Manage devices](/beam/api-guides/how-to/fleets/device-management): device configuration and reported status. - [Set up networks and sites](/beam/api-guides/how-to/infrastructure/networks-and-sites): connect device locations and networks. # Beam API overview MK.IO Beam has cloud APIs for fleet and infrastructure management, and a device-local API for channels. Choose the connection that matches the resources you need to manage. ## Cloud APIs The Fleets and Infrastructure APIs use `https://app.mk.io/` with bearer authentication. Requests are scoped to a project:
API Path prefix Guide
Fleets /api/v1/projects/{project_name}/fleet/ Fleet workflows
Infrastructure /api/v1/projects/{project_name}/infra/ Networks and sites
Use the Infrastructure API to define sites and networks for a deployment. Use the Fleets API to register devices, manage software, and back up or restore device configurations. Start with [Authentication and connections](/beam/api-guides/getting-started/authentication), then [Your first API call](/beam/api-guides/getting-started/first-api-call). ## Device-local Channels API The Channels API configures channels on the Beam device. Follow [Connect to a Beam device](/beam/api-guides/how-to/channels/connect-to-a-device) for its connection requirements and [How channels work](/beam/api-guides/how-to/channels/how-channels-work) for its resource model. ## API references - [Channels API reference](/api-reference/channels-api) - [Fleets API reference](/api-reference/fleets-api) - [Infrastructure API reference](/api-reference/infrastructure-api) For organization, project, and token administration, see the [Management API guides](/mkio/api-guides/how-to/management). # Connect MK.IO Beam to MK.IO MK.IO Beam devices connect to the MK.IO cloud so you can register, monitor, and manage them from the MK.IO portal. Use this page to find the Beam setup requirements, network details, and device-management guides. ## Why do I need to register my device in MK.IO? Traditional appliances are self-contained: you configure them once, and after that they're largely invisible to the vendor. Beam works differently. Every Beam device ships with all its features unlocked, and usage is metered and reconciled against your entitlements centrally in MK.IO rather than through a fixed on-box license. That model only works if the device is registered and connected. Registration is what links a physical or virtual Beam appliance to your MK.IO Organization and Project so it can be recognized, licensed, and managed. Rather than opening inbound firewall ports for MediaKind to reach your devices, Beam connects out to MK.IO, a more secure approach that avoids exposing your network. That single connection is what unlocks everything MK.IO does for your fleet: - **One cloud pane for every site.** Whether you have one Beam device or hundreds spread across locations, you configure, monitor, and operate all of them from a single MK.IO interface, with no need to VPN or remote into each site individually. - **Centralized software and firmware updates.** MK.IO is the only supported path to new software and upgrades, so registered devices always have a route to the latest features and fixes without manual intervention per box. - **Configuration backup and recovery.** Device configuration is backed up through MK.IO, so a hardware failure or replacement doesn't mean rebuilding a device from scratch. - **Fleet-wide visibility and reliability.** MK.IO tracks device status and connectivity, so you, and MediaKind support if needed, always know whether a device is online and healthy. - **Remote diagnostics and support.** If something goes wrong, MediaKind can help troubleshoot through the connected device rather than requiring an on-site visit. - **Accurate entitlement and cost tracking.** Because usage is metered rather than fixed by an on-box license, registration ensures your billing and entitlement usage reflect what's actually deployed, with no manual license files to manage. In short: registering your device is what turns Beam from a standalone box into part of your managed, cloud-connected fleet, with less operational overhead, faster support, and licensing that flexes with how you actually use it. ## Start with Beam setup If you are preparing a new device, follow [Quick start](/beam/quick-start). It covers the installation, Control interface, network configuration, time synchronization, device registration, and software update sequence. Before registration, make sure the device has: - A configured **Control** interface with an IP address. - A default gateway and DNS servers that can resolve external domains. - A configured time source. ## Network requirements The device must be able to reach the MK.IO services before you register it. Allow outbound TCP port `443` to `https://api.mk.io/` through any customer-managed firewall. If the device can reach the internet only through a proxy, configure the HTTP proxy from **Appliance** > **Fleet** in the device UI. The device must also connect to `https://app.mk.io/` at least once before you register it. For the full checks and diagnostics, see [Troubleshoot edge-device onboarding](/mkio/how-to/managing-edge-devices/on-board-fleet-devices/troubleshooting). ## Register a device Start with [Onboard edge devices](/mkio/how-to/managing-edge-devices/on-board-fleet-devices) to choose the registration path that matches your installation workflow: - [Common onboarding workflow](/mkio/how-to/managing-edge-devices/on-board-fleet-devices/common-workflow): connect the device from its local UI, copy the short code, and add it in MK.IO. - [Onboard from the device terminal](/mkio/how-to/managing-edge-devices/on-board-fleet-devices/terminal-only): use the Device ID when the installer cannot access the device UI. - [Onboard using the API](/mkio/how-to/managing-edge-devices/on-board-fleet-devices/api-onboarding): register the device through the Fleet API. - [Remove a device](/mkio/how-to/managing-edge-devices/on-board-fleet-devices/remove-device): remove a device from an MK.IO project. The device must connect to MK.IO before you can complete registration. The **Connected** field in **Appliance** > **Fleet** shows whether that connection is working. ## Manage registered devices After registration, use MK.IO for the following device-management tasks: - [View device information](/mkio/how-to/managing-edge-devices/display-device-information), including status, software, hardware, network, and service information. - [Access the remote device UI](/mkio/how-to/managing-edge-devices/access-the-remote-device-ui) through a secure MK.IO connection. - [Update device software](/mkio/how-to/managing-edge-devices/update-device-software) with an available software bundle. - [Create and restore configuration backups](/mkio/how-to/managing-edge-devices/configuration-backups). - [Collect device logs](/mkio/how-to/managing-edge-devices/support-packages) in an MK.IO support package. For automation, use the [Fleet device management API Guide](/beam/api-guides/how-to/fleets/device-management). # Contribution
Check which interface you are using

The guides linked from this page configure MK.IO Beam through the Advanced interface, where a workflow is a feed made up of individual services. If your device runs the Essentials interface, build the workflow as a channel instead: see Create a channel. Both interfaces control the same settings underneath, so these pages stay useful as reference for the detail behind a channel.

MK.IO Beam for contribution is engineered to meet the demands of modern live content acquisition, delivering pristine video quality with maximum efficiency. Its flexible architecture allows for field reconfiguration for IP or satellite contribution, up to 4:2:2 10-bit UHD targeted at a range of server options. It’s ideally suited to live events, where we can offer the flexibility of paying on a pure consumption basis MK.IO Beam connects to the cloud, enabling direct and automated control, monitoring and life cycle management via the MK.IO cloud portal for the ultimate experience in efficient operations. ## Common Workflows: ### Input setup [Configure SMPTE ST 2110 Input](/beam/contribution/how-to/setup-smpte-2110-input) How to configure SMPTE ST 2110 Input [Configure SDI/ASI Cards](/beam/system-admin/maintenance/setup-sdi-asi-card) How to configure SDI/ASI cards ### Low Latency & Reliability [Minimise End-to-end Delay](/beam/contribution/how-to/minimize-end-to-end-delay) How to minimise the end-to-end delay. [Drop IP/ASI output on input loss](/beam/contribution/how-to/drop-output-on-input-loss) How to drop IP/ASI output on input loss. ### Transport [Configure SRT/Zixi/RST](/beam/reliable-transport/service-management) How to configure SRT/Zixi/RST [Configure satellite modulator](/beam/contribution/configure-feed-components/satellite-modulator) How to configure the satellite modulator # Configure the feed components After a feed has been created, each service within the feed must be individually configured to create the entire MK.IO Beam configuration. Thus, you will configure: - [the Live Encoder service](/beam/contribution/configure-feed-components/live-encoder) - optionally [the Multiplexer service](/beam/multiplexer) - optionally [the Satellite Modulator](/beam/contribution/configure-feed-components/satellite-modulator) The Reliable Transport service is not included in any of the MK.IO Beam feed templates. It can be added separately via the **Services** page. See [Reliable Transport Configuration](/beam/contribution/configure-feed-components/reliable-transport) When editing component parameters, do not modify any interfaces which have been configured to use the “tap0” or “lo” interfaces as those are used internally to pass data between the services. # Configure the Live Encoder service The following sections explain the basic configuration for the Live Encoder component. For advanced configuration, see the following sections of Live Encoder: \- [Input parameters](/beam/live-encoder/configure/input) \- [Encoding parameters](/beam/live-encoder/configure/encoding) \- [Output parameters](/beam/live-encoder/configure/output/configure-output) To configure the Live Encoder, follow these steps: 1. Click `Edit` icon next to the **Live Encoder** component within the feed. The Live Encoder settings open. ![ce1 channel edit encode cursor](/ce1-img/ce1_channel_edit_encode_cursor.png) 2. When you get to the **General** tab, the name is already pre-defined. It will be incremented at each new feed instance so you don't need to change it. ## Configure the input To configure the video, audio and data components, follow these steps: 1. Go to the **Input** tab. 2. In the **General parameters** section, select the input type: - [**SDI**](/beam/contribution/configure-feed-components/live-encoder#sdi-input) - or [**SMPTE ST 2110**](/beam/contribution/configure-feed-components/live-encoder#smpte-st-2110-input) ### SDI input Before you start: ensure you already [set up the SDI card for HD or UHD operation](/beam/system-admin/maintenance/setup-sdi-asi-card). To configure an SDI input, follow these steps: 1. From the **General parameters** section: - Set the input **Type** to **SDI**. - Select a Connector from the drop-down list. - You can keep the SDI card number, by default **1** or change it. 2. Go to the **Input streams selection** section: the input video is already configured but you can add an input audio: - Go to the **Audio ID** section. - Click **Add**. You can either keep the default parameters or modify them as needed. - Click **Ok** to validate. 3. Click **Save and continue** to save your changes. ### SMPTE ST 2110 input Before you start: ensure you already [set up the SMPTE ST 2110 input operation](/beam/contribution/how-to/setup-smpte-2110-input). To configure an SMPTE ST 2110 input, follow these steps: 1. In the **Input** > **General parameters** section, set the input **Type** to **SMPTE ST 2110**. 2. Configure the input video stream: - In the **Input streams selection** section, go to the **Video ID** section. - Click `Edit` icon then enter the **SDP file location**. - Click **Ok** to validate. 3. Add and configure the input audio stream: - In the **Input streams selection** section, go to the **Audio ID** section. - Click **Add** then enter the **SDP file location**. - Click **Ok** to validate. 4. Click **Save and continue** to save your changes. **See also**\ [Limitations and Considerations for ST2110 and PTP](/beam/contribution/how-to/setup-smpte-2110-input#limitations-and-considerations-for-st2110-and-ptp)\ [Configure SDP files on MK.IO Beam](/beam/contribution/how-to/setup-smpte-2110-input#configure-sdp-files-on-mkio-beam)\ [Setup the PTP for ST 2110](/beam/contribution/how-to/setup-smpte-2110-input#configure-ptp-for-st-2110) ## Configure video, audio and data components ### Configure the video component To configure the video component go to the **Video encoding** section. 1. Click `Edit` icon to check and configure the video parameters. 2. Select the appropriate parameters for the video encoding. 3. Click **Ok** to validate. ### Configure the audio component To configure the audio component go to the **Audio encoding** section. 1. Click **Add**. A new window is displayed. By default audio codec is set to **Pass-through** but you can change it. 2. Select the appropriate parameters for the audio encoding. 3. Click **Ok** to validate. ### Save Click **Save and continue** to save your changes. ## Configure the output 1. Go to the **Output** tab. A default output has already been created. 2. In the top right corner, click `Edit` icon. 3. Scroll to the **Common MPEG-2 TS parameters** section. You may change some parameters, especially **Standard**, **PCR PID**, **Program number**, **Service name**, **Service provider**. 4. Scroll to the **Output streams** section, click `Edit` icon then tick the audio stream. 5. You can change the PIDs if needed. 6. Click **Ok** to validate. 7. Click **Save and continue** to save your changes. ## Configure advanced parameters ### CBR To ensure that the video is output as a CBR elementary stream, you need to add an advanced parameter: 1. Go to the **Advanced parameters** tab. 2. Click **Add** then set **Mpeg2ts.NullPacketStuffing** to **False**. ![ce1 encode adv param](/ce1-img/ce1_encode_adv_param.png) 3. Click **Save and exit** to save and finalize your service configuration. 4. Select the **Home** menu from the left menu bar to go back to the Home page. ### SCTE-35 pass-through If passing through SCTE35 messages with a default configuration, a high proportion of null splice messages will be output in comparison to splice messages which contain actual splices. This can be adjusted using the **capDmif.maxScte35Bitrate** advanced parameter. Setting this to a value of **7520** will reduce the number of null splice messages in the output. # Configure the Multiplexer service For detailed information on the Multiplexer service, refer to the [Multiplexer documentation](/beam/multiplexer). # Configure a Reliable Transport service

Although the Reliable Transport service is not included in all of the MK.IO Beam feed templates, a Reliable Transport service can be added separately and connected to the input or output of a feed. For example, a Reliable Transport service can be added to the output of an Encoder and Multiplexer feed to provide Reliable Transport output.

To create a Reliable Transport service, see [how to create a new Reliable Transport service](/beam/reliable-transport/service-management#create-a-new-reliable-transport-service). If configuring a Reliable Transport service to provide Reliable Transport output, i.e. taking the output from another service and providing a Reliable Transport output, ensure that: 1. In the **Output** section, set the **Output Mode** to **SRT Caller**. 2. Configure the **Network Interface**, **Stream Address** and **Port** with the same information as the upstream service's output. ![ce1 srt service](/ce1-img/ce1_srt_service.png) _Reliable Transport configuration example_ # Configure the Satellite Modulator output The Satellite Modulator option card is only supported on MK.IO Beam running on C-series servers. The Satellite Modulator option card is only supported with the Live Encoder + Multiplexer + Satellite Modulator use case.

On first usage, the Satellite Modulator settings will be read-only. To edit modulation parameters, you must log in to the Satellite Modulator card as an administrator. The administrator user will be logged out after a period of inactivity. If that happens, you will need to log in as an administrator again to be able to edit settings.

To configure the Satellite modulator option card, follow these steps: 1. Create a new feed based on the **Live Encoder + Multiplexer + Satellite Modulator** template. 2. Once created, go to the feed card then edit the Satellite Modulator options by clicking `Edit` icon next to the **Satellite Modulator** component within the feed. 3. Log in to the satellite modulator option card as an administrator: 1. Navigate to the **System** menu, then go to the **Admin** sub-menu. 2. Log in with the following credentials:\ Username: `admin`\ Password: `root` 3. Click the green tick in the top right corner: ![ce1 satellite modulator login](/ce1-img/ce1-satellite-modulator-login.png) ## Configure modulation settings To configure modulation settings, go to **Settings** then **Modulation**: ``` ![ce1 modulation settings](/ce1-img/ce1-modulation-settings.png) ``` ## Configure RF output parameters To configure RF output parameters, go to **Settings** then **Outputs**: ``` ![ce1 rf output settings](/ce1-img/ce1-rf-output-settings.png) ``` Enabling or disabling the RF output must be done on the **Outputs** menu. ``` - To disable the RF output, set the **RF Output** setting to **OFF**, then click on the green tick in the top right corner. - To enable the RF output, set the **RF Output** setting to **ON**, then click on the green tick in the top right corner. ```

Starting and stopping the feed on the MK.IO Beam home page does not change any modulation parameters or enable or disable modulation.

- [LCM and Dolby E Passthrough](/beam/contribution/how-to/lpcm-and-dolby-e-passthrough) - [Minimise Latency](/beam/contribution/how-to/minimize-end-to-end-delay) - [Configure NMOS](/beam/contribution/how-to/configure-nmos) - [Drop Output on Input Loss](/beam/contribution/how-to/drop-output-on-input-loss) - [Configure JPEG XS](/beam/contribution/how-to/configure-jpegxs) - [Output Synchronization with PTS](/beam/contribution/how-to/output-synchronization-with-pts) - [SMPT2110 Input](/beam/contribution/how-to/setup-smpte-2110-input) # JPEG-XS with Jumbo Frames Jumbo frames are Ethernet frames with a payload larger than the standard 1500 bytes. Using them can improve network performance for high-bitrate streams like JPEG-XS by reducing packet header overhead. They are recommended for JPEG-XS services at bitrates of 300 Mbps and higher. To use jumbo frames, you must configure them on your Beam device's network interfaces and in the Live Encoder service.

Jumbo frames only work if all devices on the network path, including switches and routers, are also configured to support them.

## Configure Jumbo Frames on Network Interfaces To use jumbo frames for a JPEG-XS stream, you must first enable them on the network interfaces of your Beam device by setting a higher Maximum Transmission Unit (MTU). See [Configure Jumbo Frames for instructions](/beam/system-admin/network/jumbo-frames). ## Enable Jumbo Frames in the Live Encoder Service After configuring the network interfaces, enable jumbo frames for the specific Live Encoder service. 1. In the **Live Encoder** service configuration, go to the **Input** tab and ensure the **Contribution encoding service** checkbox is checked. 2. Under the **Encoding** tab, ensure the codec is set to **JPEG XS 4:2:2** or **JPEG XS 4:2:2 10 bits**. 3. In the output properties under the **Output** tab, check the **Ensure Large Frames** checkbox.

Secure Reliable Transport (SRT) does not support jumbo frames. If you are using JPEG-XS with SRT, do not enable jumbo frames in the Live Encoder or on the network interfaces.

Jumbo frames are enabled by default in the Live Encoder configuration if the bitrate is higher than 1 Mbit/s.

# Configure NMOS IS-04 and IS-05 ## Overview The diagram below shows how the Controller and Live Encoding components are collaborating on MK.IO Beam. ![ce1 nmos architecture](/ce1-img/ce1-nmos-architecture.png) - The Live Encoding server shown here is contained within the Live Encoding component on MK.IO Beam. - The NMOS Node microservice within the Live Encoding component exposes the NMOS Node API and NMOS Connection API. - The Node API is achieved by retrieving the NMOS resources of the Services running on the server thanks to the products Configuration Managers. - The Configuration API is achieved by updating the Service Configurations thanks again to the products Configuration Managers - The Live Encoding component implements API endpoints so that the NMOS node microservice can retrieve the NMOS resources of a Live Encoding service. ## Prerequisites - You need to provide an NMOS Registration and Discovery Server (RDS) that is NMOS IS-04 compliant, and an NMOS Client, which will interact with the NMOS RDS and NMOS Nodes. - NMOS IS-04 supports different modes of operation for the NMOS Node discovery, Encoding Live mandates discovery using Registered mode with multicast operation. - When configuring a service with NMOS, the SDP file for each input stream is supplied by the NMOS Client, this means that you no longer need to specify the SDP file location. ## Configuration The MK.IO Beam must be configured with a Live Encoding service. ### Create a Live Encoding service 1. Go to the **Services** page, click **Add service** then select **Live Encoding**. ### Configure the Live Encoding service 1. Under the **General** tab, enter a name for the service. 2. Under the **Input** tab: 1. set the **Type** to **SMPTE ST 2110**. 2. Leave the **Input redundancy** set to **None**. 3. Tick the **NMOS enabled** checkbox. 4. Set the **Network interface** to the input network interface. SDP files are greyed for each input stream since this information is supplied by the NMOS Client. 5. Configure video encoding, audio encoding and output parameters as required. ### Save and start the service ``` 1. Click **Save and exit** to save and finalize your service configuration and go back to the **Services** page. 2. Assign a server to run the service. Result:
- The **Stats** \> **Monitoring** tab will display **NMOS Configured** when the NMOS **Enabled** checkbox is ticked. - Upon first start of the service, each input stream will have an alarm raised indicating “waiting for NMOS” that will be cleared once the NMOS client has configured each input stream ``` ## Drop IP/ASI output on input loss MK.IO Beam can be configured to drop IP/ASI output on input loss. This can be configured for **Live Encoder + Multiplexer** feed templates. To configure this, follow these steps: 1. For the Live Encoder: 1. Go to the feed card then edit the Live Encoder by clicking `Edit` icon next to the **LIVE ENCODER** component within the feed. 2. Click the **Output** tab then click `Edit` icon to edit the output. 3. In the **Common MPEG-2 TS Parameters** section, set the **Signal loss management** to **Drop transport stream**. ![Ce1 live output signal loss](/ce1-img/Ce1-live-output-signal-loss.png) 2. For the corresponding Multiplexer: 1. Go to the feed card then edit the Multiplexer by clicking `Edit` icon next to the **MULTIPLEXER** component within the feed. 2. From the **Stream Processing** tab, click **Output stream > Service (x)**. 3. Go to the **Properties** > **Sources** sub-tab then tick the **Output Drop On Input TS Loss** checkbox. ![Ce1 mux input ts loss](/ce1-img/Ce1-mux-input-ts-loss.png) # Set up LPCM and Dolby-E pass-through LPCM and Dolby-E inputs on SDI can be passed through and carried on the TS as SMPTE-302 and Dolby-E respectively by selecting the **SMPTE-302 / Dolby E Pass-Through** codec from Live Encoder **Encoding** > **Audio encoding** section (see [Configure the audio encoding parameters](/beam/live-encoder/configure/encoding/audio-encoding)). ![ce1 el lpcm dolby passthrough](/ce1-img/ce1_el_lpcm_dolby_passthrough.png) This is supported for both SDI and SMPTE ST 2110 ingests. # Minimize the end-to-end delay for contribution In feed templates for contribution use cases, the default configuration for the **Live Encoder** service is already optimized for low delay. If a Multiplexer service is present, this will add delay. If optimizing for low delay, consider whether a Multiplexer service is required. If a Multiplexer service is required, delay can be reduced by adjusting the following parameters in the [Mux Advanced Settings](/beam/multiplexer/parameters/stream-processing#mux-advanced-settings) section: - **Input jitter buffer latency** can be reduced to a minimum of **40** ms. - If **not** using encryption, **Scrambling latency** can be reduced to a minimum of **10** ms. - If using ASI output with a Dektec 2174b or 2178 card, **ASI output buffer latency** can be reduced to a minimum of **50** ms. # 1+1 output synchronization with PTS alignment The synchronization of two MK.IO Beam servers is useful to reduce the redundancy switch time of a downstream device: the two MK.IO Beam units using the same source can output two streams where the encoded frames have their PCR, PTS and IDR aligned. When the downstream device switches between one MK.IO Beam output and the other, the stream looks identical to the downstream device and the only interruption observed is “on the wire”. How it works: - The source fed to the two MK.IO Beam servers needs to be the same (identical) and the timecode needs to be present on the input. With no timecode present, the feature still operates but the alignment is not as accurate. - The two units need to be identically configured. This can be achieved (for example) by exporting a channel configuration from one device to the other. - The synchronization needs to be configured so the two units interact with each other (see [Configuration](/beam/contribution/how-to/output-synchronization-with-pts#configuration) section below for details on how to configure this option) - The two output streams perform an automatic alignment of the PCR as well as the PTS of the encoded frames. The picture types (the IDR being the important one here) are also aligned where the position of the IDR is the same between the two streams. These has been measured to be accurate within a frame (or +/-1 frame when timecode is not used). - The third-party downstream device can be configured with two inputs corresponding to the two MK.IO Beam servers. When the input is manually switched from one to the other, the downstream device recovers with the same PCR and the decoder recovers at the next IDR point. The interruption observed is minimal (looks like a glitch). - Without this feature, the recovery would typically be tens of seconds and the visible impact would be very severe. ## Use cases - The two units need to be configured identically (same configuration parameters apart from the output multicast or ASI output ports). - The support of encoder synchronization is available for SDI ingest and SMPTE ST 2110 ingests. - Only PAL content is supported. Telecine content has not been validated with this feature. ## Configuration From the Live Encoder component UI, you can synchronize two services (with the exact same configuration) on two standalone units: 1. Go to **General** > **Services synchronization** section. 2. Tick the **Activate** checkbox then enter the **Pool name** to identify the services that need to be synchronized together. ![ce1 el synch poolname](/ce1-img/ce1_el_synch_poolname.png)

It is required that the unit IP addresses are not set to the default IP address (127.0.0.1) or the unit control IP addresses which will interfere with this feature.

**See also**\ [Synchronize two services](/beam/live-encoder/configure#synchronize-two-services) # Configure SMPTE ST 2110 input ## Limitations and Considerations for ST2110 and PTP The following limitations apply to the current version: - ST 2110 streams are carried over RTP. RTP header extension is not supported and should be turned off on the source, as described here: . - PTP domain of value 0 is the only domain supported. A workaround is to manually set the value in a file. - ST 2110 support is limited to HD resolutions. - **SMPTE ST 2110** - SMPTE ST 2110-20 uncompressed video up to UHD resolution - SMPTE ST 2110-30/31: uncompressed audio - SMPTE ST 2110-40: data (VITC/Time code, AFD/BAR, Closed captioning, OP-47 Teletext, SMPTE 2031 Teletext) - All SMPTE ST 2110 essences can be input as ST 2022-7 - NMOS IS-04 and NMOS IS-05 support ## Configure SDP files on MK.IO Beam ST 2110 can be configured using SDP files on the **Input** tab of the Live Encoder component (see [Configure an SMPTE ST 2110 input](/beam/contribution/configure-feed-components/live-encoder#smpte-st-2110-input)). The SDP files can be entered either as: - A URL where the SDP files can be retrieved from. - A path to the location of the file stored on the server: - On the host, the SDP file(s) need to be in the `/var/appliance/assets` directory. - When configuring the Encode service, use this directory to specify the SDP file location. SDP files can be transferred to the server either by SSH or by uploading via the UI. If the Asset Management feature is enabled, follow these steps: 1. Navigate to the **Asset Management** > **Assets** page. 2. Click **Add** to add a new asset. 3. Select the SDP file, then check the **Protect the Asset when it is uploaded** checkbox. 4. Click **Start Upload** to upload it. If the Asset Management feature is not enabled, follow these steps: 1. Copy the files to the server via SCP. For example, using Mobaxterm: ```shell copy scp /cygdrive/c/sdp-2110-20.sdp mfeng@192.168.1.1:/tmp ``` 2. Connect to the unit via SSH and copy the files to `/var/appliance/assets`: ```shell copy sudo mv /tmp/sdp-2110-20.sdp /var/appliance/assets ``` After copying over the SDP file, configure it on the Live Encoding service user interface using the following path: `/var/appliance/assets/sdp-2110-20.sdp` ## Configure PTP for ST 2110

PTP is required for ST 2110 operation.

### Set the PTP interface and domain PTP interface configuration is under the **System Settings** page. - Navigate to the **Servers** view. - Click the **Details** `View` icon button to display the server information. - Go to the **System Settings** tab. - Under **Time sources**, select the **PTP** tab. - Set **Interface** to the network interface which will connect to the PTP Grand Master. - Set **Domain number** to the required PTP domain. If the system time source is not set to PTP, click the **Make active** button to set this. Confirm all changes by clicking on **Confirm,** then click the **Save** button at the bottom of the page to save the changes. ## Checking PTP operation ### How to check that PTP services are running To check the p4p4l service: ```shell copy systemctl status ptp4l.service ``` The output from this command should show that the service is loaded and active, for example: ```shell ptp4l.service - Precision Time Protocol (PTP) service Loaded: loaded (/usr/lib/systemd/system/ptp4l.service; enabled; vendor preset: disabled) Active: active (running) since ``` To check the phc2sys service: ```shell copy systemctl status phc2sys.service ``` The output from this command should show that the service is loaded and active, for example: ```shell phc2sys.service - Synchronize system clock or PTP hardware clock (PHC) Loaded: loaded (/usr/lib/systemd/system/phc2sys.service; enabled; vendor preset: disabled) Active: active (running) since ``` ### How to check the PTP Grand Master Run the pmc tool to check the status of the PTP grand master. In the example below, PTP domain 0 is used (`-d 0`). Modify the “`-d`” option to specify a different PTP domain. ```shell copy sudo pmc -u -b 0 -d 0 'GET TIME\_STATUS\_NP' ``` The text `gmPresent true` confirms that the grand master is detected, for example: ```shell sending: GET TIME_STATUS_NP 043f72.fffe.ff60cb-0 seq 0 RESPONSE MANAGEMENT TIME_STATUS_NP master_offset 13 ingress_time 1620380188201784144 cumulativeScaledRateOffset +0.000000000 scaledLastGmPhaseChange 0 gmTimeBaseIndicator 0 lastGmPhaseChange 0x0000'0000000000000000.0000 gmPresent true gmIdentity b8599f.fffe.60ffc8 ``` # Technical specifications ## Input / Output cards ### Baseband input

Optional hardware required

- **SDI over IP (SMPTE ST 2022-6)** ### Combined SDI and ASI input/output

Optional cards

- **4-port card:** 4xHD -SDI or 4x3G-SDI or 1x12G-SDI or 4xASI. Connector: BNC (F) 75 ohm - **8-port card:** 8xHD-SDI or 8x3G-SDI or 1x12G-SDI or 8xASI. Connector: BNC (F) 75 ohm - **Standards supported** - HD-SDI: SMPTE 292M; 3G-SDI: SMPTE 424M; 12G-SDI: SMPTE 2082. - Embedded audio: SMPTE 299M (HD) SDR/HDR - Signaling: SMPTE ST 425-5 - External sync genlock (black and burst) - Max. ASI input rate: 208 Mbps - ASI packet length: 188/204 byte packets - ASI standard: EN50083-9 ### IP output

Optional cards

- **2x10GbE card:** Connector: Dual SFP+ cages. 10G BASE-T optical transceivers or 10Gbe SFP DAC - **2x25GbE card:** Connector: Dual SFP28 cages. Can support 1GbE, 10GbE or 25GbE. Can provide hardware acceleration for SMPTE ST 2110 input ## Compressed output ### Transport stream output - Single or multi-service MPEG Transport Stream(s) - UDP or RTP encapsulated - RTMP/RTMPS ### Reliable transport - **SRT and RIST input/output** - Carriage of UDP or RTP streams over the SRT protocol - SRT listener or caller mode - RIST sender mode - RIST listener mode - **Zixi input/output** - Zixi sender - Zixi feeder or Zixi Receiver mode ### High availability - Automated (standalone) 1+1 output synchronization with PTS alignment (either SDI or ST 2110 inputs) ## Content security ### Encryption - BISS v1 Mode 1 and E - BISS v2 Fixed Key and CA Mode - SRT and RIST Encryption modes (fixed key 128/256 AES) ## Video encoding - **Video codecs:** HEVC, H.264, MPEG-2, JPEG-XS - **Chroma & bit depth:** 4:2:2 10-bit / 8-bit. 4:2:0 8-bit (10-bit UHD). - **Resolutions:** 480i (SD), up to 2160p (UHD) - **Framerates:** 23.98, 24, 25, 29.97, 50, 59.94
UHD HD SD
4:2:2 10-bit or 4:2:0 8 bit-HEVC 4:2:2 10-bit or 4:2:0 8-bit MPEG-4 AVC or HEVC 4:2:0 8-bit MPEG-2, MPEG-4 AVC or HEVC
4:2:2 or 4:2:0 8-bit MPEG-2 4:2:2 8-bit MPEG-2
4:2:2 10-bit or 8-bit JPEG-XS 4:2:2 10-bit or 8-bit JPEG-XS 4:2:2 10-bit or 8-bit JPEG-XS
2160p 23.98, 24, 25, 29.97, 50 or 59.94 frame rates 1080i25/29.97, 720p50/59.94, 1080p50/59.94 frame rate 480i 29.97, 576i 25
## Audio encoding - **Audio codecs:** MPEG-1 Layer-II, AAC, HE-AAC, HE-AAC v2 1. Dolby Digital® 2.0 / 5.1, Dolby Digital Plus® 2.0, 5.1, Dolby AC-3 - **Audio channels:** Up to 8 stereo pairs per service - **Passthrough:** Dolby E®, Dolby Digital®, Dolby Digital Plus®, Linear PCM (as SMPTE 302) - **Data rate:** From 4.75 kbps to 320 kbps (from 64 to 1024 kbps for DD+) ## Metadata - **Subtitles:** Passthrough and translation for EIA-608/CEA-608 and EIA-708/CEA-708 Closed Captions, SCTE-20, DVB Teletext, DVB Subtitles, SCTE-27 ## Satellite modulator ### Connectivity - RF output - SMA 50-ohm connector - RF monitoring output - SMA 50-ohm connector - 10MHz Input/Output reference - SMA 50-ohm connector ### Dual DVB Common Interface option card - Enables support for all major CAM modules - Multi-service decryption - Up to 2 CAM modules per option card ### Modulation - Type: DVB-S, DVB-DSNG, DVB-S2, DVB-S2X - Constellation: QPSK, 8PSK, 16APSK to 32APSK 2 - Roll-off: DVB-S/DSNG: 35% DVB-S2: 20, 25 or 35% - DVB-S2X: 5, 10, 15, 20, 25, 35% - Symbol rate: 0.05 to 36 MSym/s 2 ### RF output - L-Band frequency range: 950 MHz to 2150 MHz (1 KHz step) - L-Band output power: -35 dBm up to +5 dBm (0.1 dB step) - IF frequency range: 50 MHz to 180 MHz (1 Hz step) - IF output power: -35 dBm up to +5 dBm (0.1 dB steps) - IF monitor output power: -20dB on the RF output ### Other functions - Carrier ID insertion - Spectrum inversion - Test mode: PRBS, dummy PL frame, carrier ID only - Configurable option to switch off or mute output at startup ## Monitoring & control - **Remote control:** Provided via the Mediakind MK.IO portal - **Direct control and status monitoring:** Provided via Web browser user interface and REST API - **Standard protocols:** SNMP, NTP, IGMP # Beam Essentials UI The Essentials UI is a simplified operating view for MK.IO Beam devices, designed for day to day monitoring and channel control. Use it to check channel health at a glance, review active alarms, and create new channels without configuring the underlying services directly. You can access a device's Essentials UI locally at the device address, or remotely through MK.IO. For remote access, see [Access the remote device UI](/mkio/how-to/managing-edge-devices/access-the-remote-device-ui).

The MK.IO Beam Essentials UI requires Beam version 1.12.0 or higher, and is only available for new customers or fresh Beam ISO installations.

The Essentials UI also introduces the **Channels API**. This API presents everything the device is doing as a number of _channels_, where one channel can cover the input, the processing, and the output of a single service. It is the API behind the Beam Essentials UI, and it runs on the device. For more information and user guides see: [Channels API guides](/beam/api-guides/how-to/channels/) ## Essentials and Advanced views The device UI is split into two views, available from a toggle in the top right corner of the header. - **Essentials**: day to day operations and monitoring. Channels are presented as a single unified concept, with live thumbnails and clear status. - **Advanced**: deeper engineering and service level configuration, exposing the underlying services, alarms, servers, and templates that power each channel. See [Advanced interface overview](/beam/web-interface) for Advanced view documentation. Both views operate on the same underlying system. Advanced gives full configuration access at the service level, while Essentials presents that configuration as unified channels. A device presents one or the other, never both. A device with the Essentials view manages workflows as _channels_, and a device without it manages them as _feeds_. If the documentation you are reading refers to feeds, you are in the wrong set of pages: see [Advanced interface overview](/beam/web-interface). ### Switch to the Advanced interface The **Essentials** and **Advanced** buttons sit together in the top right of the header, next to the help and account icons. The current view is the highlighted one. Select **Advanced** when you need something the Essentials view does not cover, such as reception and gateway configuration beyond the channel wizard, service level settings, servers, or templates. Select **Essentials** to come back. Both views act on the same device, so a change made in one is visible in the other. The first time you open the Essentials view, a welcome dialog introduces the interface, with links to a short video and to this documentation. ![Welcome dialog introducing Beam Essentials, shown over the dashboard on first use](/_machine-assets/8834cb661c94cd2ecf9a360aed895e3238841d52b6be818ed6e17be098ef3c33.jpg) ## Dashboard Opening a device in the Essentials view displays the dashboard, showing every channel running on that device. ### Quick controls Below the header, the dashboard provides: - **View only alarmed**: a toggle that filters the dashboard to show only channels that currently have alarms. - **Filter**: a search field to filter the channel list by name. - **New channel**: opens the channel creation wizard. See [Create a channel](/beam/essentials/create-a-channel), or [Create a reception channel](/beam/essentials/create-a-reception-channel) for the **Reception (Decoding)** workflow. ![Essentials dashboard showing the channel grid, status panel, and active alarms panel](/_machine-assets/7274e6510dc79229d4d4806e5e0fa0d0563412c0dfb48e671486975ee2987bfe.jpg) ### Status panel In the top right of the dashboard, three summary metrics show the device's current load: **CPU Usage**, **Unit up-time**, and **Temperature**. A dash in place of a value means that reading is not available on this device. Below the summary metrics, a second panel identifies the device: **Software version** and **Installed hardware**. ![Status panel with CPU usage, unit up-time, temperature, software version, and installed hardware, next to the active alarms panel](/_machine-assets/737abd5cbd3a44b396cadfeefd7be42a761feb332b66fd5e5c619fb15c67dd2b.png) ### Active alarms panel Below the status panel, the active alarms panel lists every active alarm across the device, sorted by alarm severity and recency. Each entry shows a timestamp, a severity badge, a title, and a description of the fault, usually including the affected service name. Severity levels are **Critical**, **Major**, and **Notice**. For a full breakdown of alarm types and how to configure alarm overrides, see [Manage alarms](/beam/system-admin/maintenance/manage-alarms). ### Channel cards The channel card grid is the main part of the dashboard. Each card represents a channel on the device and shows: - Its **On Air** or **Stopped** status, and a live video thumbnail when it is on air and healthy (a stopped or unhealthy channel shows **No thumbnail** instead). - Its **Video** parameters (resolution, codec, bitrate, and bit depth) and **Audio** parameters (codec, and mode and bitrate where applicable). - A signal diagram showing the input and output type for the channel, for example **SDI** into **UDP**, or **ASI** into **SDI**, connected by a line of status dots. When a channel has an active alarm, the card makes it clear: - The thumbnail area shows a severity badge, for example a red **Critical** badge. - The card background and the signal diagram dots turn red or orange to match the alarm severity. ![A channel card with a critical alarm: red badge, red signal diagram, and video parameters](/_machine-assets/1b7447cfa2b0324f8ca49539965b12f86fe1a78c498b2528a23c4ae896e30965.png) ## View channel details Select a channel card to open its detail view. At the top of the page, you can see the channel name, its workflow label, and its status. - Select **Stop** to take the channel off air. - Select the three dot menu for additional actions. - Use the channel selector on the left to move to a different channel without returning to the dashboard. Below the video preview, **Input status** and **Output status** report the live condition of the channel: - **Input status** shows the input **Type** and **Status** (for example **Not receiving**), and **Service** identification. - **Output status** shows the output **Type**, and its **Video scaling** and **Dynamic range** settings. The active alarms panel on the right stays scoped to the selected channel, and shows **No alarm** when the channel is healthy. ![Channel detail view showing the video preview, channel selector, and no active alarms](/_machine-assets/8744e7f45c9d8d5e82229b1a6488e1bd789404e40293f21909846700fdfa15da.jpg) ## Edit channel settings From a channel's detail view, use the three dot menu to open its settings. Each section lists the channel's current configuration, with an independent **Modify** button: - **Channel display name** - **Workflow**: the channel's type, for example **Reception (Decoding)**. - **Input**: input type, slot or port, and TS packet size. - **Audio**: configured audio tracks, with an **+ Add** button for adding another. - **Output**: output type, and slot or port. ![Channel settings page with channel display name, workflow, input, audio, and output sections, each with a Modify button](/_machine-assets/1c31414363b886336111f4b18a9d1267f0f9e75877be1e8e93f9b52ed6a8fc5b.png) # Create a channel The channel creation wizard configures a new channel and its underlying input, video, audio, and output settings from the Essentials dashboard. The wizard walks through the same pattern at every step: a step list on the left tracks your progress, and the form for the current step is on the right. The steps after **Input** depend on the workflow you choose. ### Start the wizard Select **New channel** from the dashboard. You can also start a new channel from within an existing channel's detail view. Choose **Create a channel** to configure a channel from scratch, or **Duplicate an existing channel** to base it on one that already exists. Enter a name for the channel and select **Next**. ![Create a new channel: the wizard's Name step](/_machine-assets/dfbe5d3057a4ed2d7d7cffcb58afc943115aa9f54d99109f13c5a4a15731ac69.png) ### Choose the workflow Select the workflow type for the channel, then select **Next**. On the device below, **Encoding (Streaming)**, **Encoding (Distribution)**, **Encoding (Contribution)**, and **Reception (Decoding)** can be selected. **Reception (Gateway)** appears greyed out, because it is not yet available. Availability depends on the device and its software version: the three encoding workflows need Beam `1.12.0` or higher, and **Reception (Decoding)** needs `1.13` or higher. A workflow the device cannot run appears greyed out. See [Contribution](/beam/contribution), [Reception](/beam/reception), and [Headends](/beam/headends) for the workflows behind each type. The workflow you choose determines the steps that follow, so the wizard is not the same length for every channel. A **Reception (Decoding)** channel decodes rather than encodes, so it replaces the encoding steps below with **Decrypt**, **Decoding**, and **Decoded Output**: see [Create a reception channel](/beam/essentials/create-a-reception-channel). ![Create a new channel: the Workflow step, with Reception (Gateway) greyed out and the other four workflows selectable](/_machine-assets/053320f65078f7a45f1541157d015f8a9c2fc6fe1d9d3210978da49a34849ff6.png) ### Select the input Choose the input type, for example **SDI**. If the input has multiple physical connections, choose the **Slot/Port** from the dropdown list, then select **Next**. ![Create a new channel: the Input step with SDI selected and a slot and port chosen](/_machine-assets/2d1cdabe6ed9cf6990362362eb24f077f4635a6e7137d7f778e8a46fe1d9a4d6.png) ### Configure video or encoding For an **Encoding (Streaming)** workflow, this next step is to configure our **Video** settings: Set the **Video Codec**, **Resolution**, **Frame rate**, and **Bitrate** for the rendition, then select **+ Add** to add further renditions. ![Create a new channel: the Video step for a streaming workflow, with codec, resolution, frame rate, and bitrate](/_machine-assets/089920702b122619f2af9ad194764780c9e3461998a816c7bdd0071871c6d608.png)

The channel creation wizard shows different options depending on the selected workflow. For example For Encoding (Contribution) and Encoding (Distribution) workflows, this step is called Encoding and configures a single set of video parameters rather than a ladder.

Select **Next** once the video parameters are set. ### Configure audio Set the audio parameters: **Audio codec**, **Audio Group**, **Mode**, and **Bitrate**. Select the trash icon to remove a track, or **+ Add** to configure an additional one. In a video ladder, the audio you define here is automatically assigned to every rendition. ![Create a new channel: the Audio step with codec, group, mode, and bitrate](/_machine-assets/d2850fcfec5d028019d1ed1107468bf37fd29ca8f51c174993d44b9028bf022b.png) Select **Next**. ### Configure the output For an **Encoding (Streaming)** workflow, the output step is informational: it produces HLS-TS, HLS-fMP4, and DASH segmentation types, each with its own URL available after you create the channel. There are no fields to fill in here. ![Create a new channel: the Output step for HTTP streaming, producing HLS and DASH outputs](/_machine-assets/879377f59e637187d980acbcf2cad4b1003b8c77e916d8a3bd1492e364e4b179.png) For **Encoding (Contribution)** and **Encoding (Distribution)** workflows, choose an output type such as **SRT**, **RF**, **IP**, or **ASI**, and enter its connection details. For the full set of Reliable Transport configuration options available outside the wizard, see [Reliable Transport](/beam/reliable-transport). Select **Next**. ### Review and create the channel Review the channel summary. It covers the channel name, workflow, and input, one entry per video rendition (or a single encoding entry outside the streaming workflow), the audio configuration, and the output. Select **Modify** next to a section to change those settings. ![Review your channel settings: channel name, workflow, input, video renditions, audio, and output](/_machine-assets/0fb7ee723deff486a6a22f87555342c774a587a7837a8ef99d4485a805ed32d1.png) Select **Create channel**. ### Start the channel The new channel opens in its detail view. Select **Start** to take it on air, then return to the dashboard to see it in the channel card grid. # Create a reception channel A **Reception (Decoding)** channel receives a transport stream, optionally decrypts it, decodes the video and audio, and presents the result as baseband. Use it when content arrives over satellite, ASI, IP, or SRT and needs to come back out as SDI or SMPTE ST 2110.
Caution

Reception (Decoding) requires an MK.IO Beam device running version 1.13 or higher.

Reception channels are created in the same wizard as every other channel, so read [Create a channel](/beam/essentials/create-a-channel) first for the parts that do not change. This page covers only what is specific to **Reception (Decoding)**. The steps differ from an encoding channel because nothing is re-encoded. Instead of Encoding and Audio steps, the wizard shows **Decrypt**, **Decoding**, and **Decoded Output**: **Name** > **Workflow** > **Input** > **Decrypt** > **Decoding** > **Decoded Output** 1. **Choose the workflow** Select **Reception (Decoding)**, then choose an **Input resolution mode** of **UHD** or **SD/HD**. If the device has no SDI card configured for UHD, selecting **UHD** shows an **Update required** notice: "None of the SDI cards are configured to support UHD output. Please configure the card modes from the ASI/SDI Interface page." Use **Update** to go to that page, or choose **SD/HD** instead. **Reception (Gateway)** is greyed out, because it is not yet available. ![The Workflow step with Reception (Decoding) selected, Input resolution mode set to SD/HD, and a UHD update notice](/_machine-assets/e85cdbc6c4b855a8a93dfed8f082d47d0b2b3148820fa8c83965cf1f0b53104f.png) Select **Next**. 2. **Select the input** Choose the transport the stream arrives on: **SRT** (Secure Reliable Transport), **IP**, **ASI** (Asynchronous Serial Interface), or **Satellite**. Choosing **SRT** reveals a second choice between **SRT Listener** and **SRT Caller**, and the connection fields for whichever you pick. For **SRT Listener**:
Field Notes
Listener interface The network interface on the device that accepts the connection.
Listener port The port the device listens on, for example 3000.
Encryption Defaults to None.
Latency Defaults to 125 ms.
![The Input step with SRT and SRT Listener selected, showing listener interface, port, encryption, and latency](/_machine-assets/5325914bee217c9a377d5cd2408b6be6e75daab1c74000fd84abdafdb52ac2aa.png) Select **Next**. 3. **Choose the decryption method** Select how the incoming stream is protected: **None**, **BISS**, **BISS-CA**, or **DVB-CI**. Choose **None** for an unencrypted source. ![The Decrypt step with None selected, alongside BISS, BISS-CA, and DVB-CI](/_machine-assets/32764b9edd65132e7d7ce9e7635decc3aa04f5554109f62c057695496783d290.png) Select **Next**. 4. **Configure decoding** This step selects which program and elementary streams to decode. **Program number** takes **Auto**, which is selected by default, or a specific program number. **Delay mode** defaults to **Standard**. Under **Video**, **Auto-assign PID** is selected by default, or you can set a PID. Under **Audio**, **Auto-decode all audio tracks** decodes every audio track found in the stream and includes it in the output. The wizard notes that this applies to SDI only. Leave it clear to configure tracks individually: each track has its own **Auto-assign PID** and a **Mode**, and **+ Add** adds another. ![The Decoding step with program number, delay mode, video PID, and one audio track](/_machine-assets/4eed8bdec3262c5b2ef0b376235979dfcdb087c68d25cdf6e3de181453215e0d.png) Select **Next**. 5. **Configure the decoded output** Choose **SDI** or **SMPTE ST 2110 / NMOS**. Both carry the same **Video** settings, and differ in how the output is addressed. Common to both:
Field Notes
Dynamic Range Conversion None, or Convert to BT.709.
Video scaling None, or a target such as 1080p.
For **SDI**, choose the **Slot/Port** to output on. The **Audios** panel below is read-only and reflects what you configured in the Decoding step, for example "Audio-1 (Stereo), 1 pair of tracks - Using G1P1". ![The Decoded output step with SDI selected, showing dynamic range conversion, video scaling, slot and port, and the audio summary](/_machine-assets/538fbf353494533c7b43375dc2b3f7605d59fec773834f53df973ec4aac054c0.png) For **SMPTE ST 2110 / NMOS**, address the output on the network instead:
Field Notes
Destination IP address Output stream unicast or multicast IPv4 address, for example 239.1.1.1.
Destination port For example 5005.
Network interface The interface the output leaves on.
Auto source port Selected by default. Clear it to set the source port yourself.
There is no multicast option to select here: an address in the class D range, `224.0.0.0/4`, is treated as multicast, and anything outside that range is treated as unicast. The Advanced interface offers an explicit [**Unicast**](/beam/receiver/parameters#ip) control where an exception to that check is needed. ![The Decoded output step with SMPTE ST 2110 / NMOS selected, showing destination address, port, network interface, and auto source port](/_machine-assets/9be1ca1d3d6f996c356761a6bfa311f96864900baf2ee15432ea0178e9202fa1.png) Select **Next**. 6. **Review and create the channel** **Review your channel settings** lists each section with its own **Modify** button, so you can change one part without stepping back through the whole wizard. **Back** returns to the previous step. Select **Create channel**. ## Verify the channel is working The new channel opens in its detail view. Select **Start** to take it on air, then return to the dashboard. On the dashboard, a healthy reception channel shows: - **Reception (Decoding)** under the channel name, with the program it is decoding. - An **On Air** badge and a live thumbnail. - A signal diagram of the input and output types, for example **SRTCaller** into **SDI**, with green status dots at each end. A channel that is not receiving shows **Stopped** or **No thumbnail**, and its **Video** parameters stay empty. See [Beam Essentials UI](/beam/essentials) for how to read the channel cards and the active alarms panel. ## Related - [Create a channel](/beam/essentials/create-a-channel) covers the encoding workflows and the parts of the wizard shared by every channel type. - [Reception](/beam/reception) collects the reception guides for the Advanced interface, including the detail behind decryption and decoding. - [Channels API guides](/beam/api-guides/how-to/channels/) covers creating the same channel programmatically, where this workflow is `ReceptionDecoding`. # MK.IO Beam for headends MK.IO Beam modernizes traditional broadcast and streaming headend workflows with a cloud-connected, software-based approach. Running on standard COTS servers, it delivers cost-effective, portable, and programmable live video processing. Fully integrated with the MK.IO cloud orchestration layer, MK.IO Beam enables centralized control, monitoring, and software lifecycle management. Its flexible commercial models, including pay-as-you-go, multi-year enterprise licenses, and perpetual licenses ensure streamlined procurement and scalability for any deployment. ## Common Workflows ## Architecture & Redundancy [High Availability Distributed](/beam/headends/high-availability) Configure 1+1 or N+M redundancy for encoders. [Server Pair Setup](/beam/headends/server-pair) Configure main and backup server pairs. ## Encoding & Processing [Configure Live Encoding](/beam/live-encoder) Set up video profiles and audio processing. [SCTE-35 Blackouts](/beam/live-encoder/configure/encoding/blackout-encoding) Manage content replacement and regional blackouts [Logo Insertion](/beam/live-encoder/configure/encoding/logo-insertion) Burn in station logos or watermarks ## Multiplexing [Configure Transport Streams](/beam/multiplexer/configure/transport-stream) Create MPTS outputs [Statistical Multiplexing](/beam/multiplexer/configure/statmux-pool) Set up Statmux pools to optimize bandwidth across multiple channels. [Bandwidth Policing](/beam/multiplexer/configure/bandwidth-policy-group) Enforce bitrate limits on output groups. ## Packaging [Configure HLS/DASH Output](/beam/packager/hls-dash-over-cmaf-output) Set up ABR ladders and manifest generation. [Live packaging services](/beam/packager/live-packaging-service) Configure live packaging services ## Layers The solution has three main layers: - The **management layer**: Addresses configuration and control, deployment/orchestration of the applications, entitlement licensing and monitoring of the headend in a centralized way. - The **processing layer**: Processing applications (encoding, packaging, multiplexing). - The **infrastructure layer**: Solution can be deployed in an IT datacenter. These three layers are glued together by the common micro-services architecture of all the MediaKind components. Each layer comprises multiple components as described below. ![aquila high solution level](/aquila-img/aquila-high-solution-level.png) MK.IO Beam for streaming and MK.IO Beam for broadcast use components to address the different processing listed below: - Management and configuration. - Live video service encoding. - Live radio service encoding. - Live video service packaging (MK.IO Beam for streaming only) - Live video service multiplexing - Reliable Transport ### Management Layer The management layer is the control/command of the whole headend. This is the single-entry point to access all functions of the headend. This interface (UI & API) is designed to: - Deploy all the applications on the nodes which are part of the system. - Configure the different services and store the configuration data. - Control services (start, stop, failover, server assignation). - Aggregate the logs and metrics from all nodes and applications. To provide all these features, the management layer includes the controller, and the deployment toolkit. To avoid any impact in case of fault in the management layer, it is designed to be high availability. The recommendation is to deploy three instances of this management node to replicate the critical component and avoid any downtime. #### Configuration, Control and Monitoring MK.IO Beam for streaming and MK.IO Beam for broadcast benefit from a single entry-point for all operations. MediaKind management and configuration component is the centralized point to configure and command the headend. It is built upon the following principles: - **Centralized configuration, control and monitoring** for MediaKind SW components that provides an immediate overview of an entire head-end system. - A **service driven approach** for configuration, control and monitoring providing an optimized granularity compared to device level. - A **flexible** service allocation: selection of the resource, combined with a floating licensing model. - A solution that allows production teams to leverage preparation activities in the lab, and during pre-production using **template** mechanisms. - A **micro-services design** matching different deployment patterns, from a single stand-alone node to a distributed and redundant configuration. - A **Web UI** applicable for all supported products, with embedded help solutions aiming at reducing training investment. Note: Access via **REST API** is also provided to offer network integration capabilities. The management nodes gather all the metrics and logs from the full headend to provide a global health of the system. This monitoring layer provides information on the deployed applications and the infrastructure the headend is running on. ### Processing Layer The processing layer comprises one or multiple components running on any infrastructure. To increase reliability, this layer is designed to be completely independent of the management layer. This independence ensures continuous processing even if the connection with the management layer is lost. #### Live Video Service Encoding MediaKind brings together 25 years of video compression experience to deliver the highest quality, any screen software applications for live video encoding and transcoding. MediaKind's continued investment and focus on the latest compression technologies ensures that the encoding component will efficiently deliver the best picture quality over bandwidth in all encoding environments and networks. This component is ideal for any real-time broadcast application, including IPTV, cable, DTH and Internet TV. As a service-oriented software solution designed to address today’s key technological and operational challenges: - Use one software headend for all video applications: DTH/Satellite, IPTV, Cable and Multiscreen. - Provide the highest video quality by leveraging the latest compression standards (MPEG-2, MPEG-4 AVC & HEVC). - Optimize OPEX and CAPEX going to full IP and leverage the latest IT technologies to reduce infrastructure and maintenance costs. - Reduce operational complexity with a service oriented centralized UI (Single point of entry). - Deploy with confidence by leveraging guaranteed performances and redundancy schemes. #### Live Video Service Packaging The packaging component is a powerful solution designed for the distribution, personalization, and monetization of multiscreen video services. You can also deploy it across your network to drastically reduce the bandwidth, storage or equipment footprint usually required to distribute video services securely to smartphones, tablets, connected TVs, game consoles, PCs, or OTT Set- Top-Boxes. MediaKind architecture is extremely modular and can scale according to your needs. It combines the following key functions: - Stream ingest with efficient buffer and storage management. - Just in Time Packaging (JITP) and encryption with a wide variety of formats and DRMs. - Highly scalable origin server. #### Reliable Transport (SRT, Zixi, RIST) Another complexity for broadcast operations is how to send or retrieve the content to/from a headend via private or public IP networks The integration of SRT, RIST, and Zixi as a component of the MK.IO Beam for streaming and MK.IO Beam for broadcast solutions allows an easy to setup, and secure link for reliably passing data. #### Stream Conditioning The **Stream Conditioning** can be used with **Live Encoder** to trigger functions such as SCTE-35 rewrite, animation/text crawling, slate/logo insertion, live-to-file and file-to-live video switching using operation type **Video clip**. #### Viewing Policy Manager The **Viewing Policy Manager** is used to configure the ingest of programming events schedules. This has limited functionality in the current version of MK.IO Beam. ## Security ### Access & Security Configuration Controller is the single-entry point for any action via the UI or the API. A virtual IP is defined to always redirect the requests to the active controller when the solution is deployed in 1+1 redundancy. ![aquila security access](/aquila-img/aquila-security-access.png) It is possible and recommended to activate the HTTPS connection and to use the API in a secured way to secure the access to the system. By default the user management is activated to access the UI.

This user management can be connected to an LDAP service for better integration in your system.

### OS Security All the products are software products running on Linux operating systems. To ensure the security of the solution MediaKind uses Nessus® vulnerability scanner tool to highlight any security risk. Based on the results, MediaKind regularly (every two months) propose “security packages” to secure the OS the MediaKind products are running on. Each security package will upgrade some of the libraries present on the OS to ensure products are using the secured version of these. Products are tested with these security packages installed to ensure their behavior with the latest libraries. OS should not be upgraded outside of these security packages. # MK.IO Beam for headends, high availability controller, distributed workers ## Live Broadcast use case The target of the Live Broadcast use case is to encode or transcode a set of incoming sources and multiplex them with optional encryption into an MPTS for distribution to end-users via traditional broadcast networks using digital terrestrial, satellite, or cable transmission. ![BeamDistributedBroadcast](/beam-img/BeamDistributedBroadcast.png) In this configuration, Live Encoding receives the incoming sources, encodes or transcodes them into SPTS streams, and sends them to Multiplexing. Multiplexing receives the encoded streams and combines them to produce a DVB-compliant MPTS stream. ## Live Streaming use case The target of the Live Streaming use case is to encode or transcode a set of incoming sources and Package them in different ABR formats including HLS DASH and HSS. ![BeamDistributedStreaming](/beam-img/BeamDistributedLiveStreaming.png) In this configuration, Live Encoding receives the incoming sources, encodes or transcodes them into SPTS streams, these streams are Packaged into segments and manifests so that players can stream them adaptively over HTTP. Live Encoding and Packaging Services may be deployed to the same distributed server nodes, or separate server nodes with the choice dependent on the server node capacity. ## Live Stream Processing use case The target of the Live Streaming use case is to encode or transcode a set of incoming sources and dynamically substitute content in response to Time (POIS) or Signal (SCTE-35) based triggers. ![BeamDistributedStreaming](/beam-img/BeamDistributedStreamProcessing.png) In this configuration, Live Encoding receives the incoming sources, encodes or transcodes them into SPTS streams. Live Stream Processing dynamically substitutes content within a live MPEG-2 Transport Stream without decoding and re-encoding the video content from one source with content from another in response to SCTE-35 trigger signals or a schedule. Live Encoding, Viewing Policy Manager (VPM) Stream Conditioning (SC) and TS Splicer Services may be deployed to the same distributed server nodes, or separate server nodes with the choice dependent on the server node capacity. ## Redundancy ### N+M redundancy N+M redundancy is supported, where N is a collection of servers dedicated to active services and M is a smaller collection of servers that may be used for carrying some active services if some of the dedicated servers, or their dedicated sources, fail. #### Using Controller Failover groups for n+m redundancy MK Controller n+m redundancy is provided through "Failover Groups", this is accessible via the Controller Failover menu. Failover groups provide server or service level redundancy for Live Encoding, Packaging, Viewing Policy Manager, Stream Conditioning and TS Splicer services. From the Failover page: On adding a group, or editing an existing group the user is presented with options to specify a group with - Group name - a name which represents the purpose of the failover group. - Failover level: - Server - failover all services to a backup server, for a failover operation. - Service - failover just the affected services, to a backup server, for a failover operation. - Group Processing Type - The service types that are affected by a failover group, for the case when a worker Server hosts multiple service types. - Group failover mode: - Automatic - failover will be triggered on critical alarm. - Manual - failover is only triggered by user action. - Available servers - The collection of servers that may be used for Primary or Backup operation. - Primary Servers - The collection of servers which are dedicated as Primary servers for a failover group. These servers are those which are expected to be normally active and may not be used as a failover target server. - Backup Servers - The collection of servers which are dedicated as Backup servers for a failover group. These servers are expected to be normally inactive and available for uses solely as backup server(s). 1. The backup server(s) need(s) to be compatible with the services being used for failover, including network interface naming. 2. Following a failover operation, the “now” in-use backup server may not be used for any further failover operations. Clearing the fault condition on the origin server and then reverting the failed services back to the origin server will allow the backup server to be used for failovers from other servers. 3. Manual failover and revert, for an existing group, is exercised through the "Detail" Failover Actions icon. 4. Some Group Processing Type options include "(Dual Output)". This option is to be used with Live Encoding and TS Splicer Services, that have been configured for "Dual Output Prevention". The option's purpose is to reduce/avoid outage seen with failover operations, by starting the Service on the Backup server ahead of stopping it on Primary Server. (On confirming the service has started on the backup, a period of 3s will be waited for stabilisation, prior to stopping the service on the Primary server.) 5. Failover group processing type handling operates on a subset of processing types - any services of the type listed in the chosen "Group processing type" selection will be moved from nominated Primary to backup server(s). If chosen Group processing type list, has processing types which are not in use, these will be ignored during failover and reversion operations. ### 1+1 Redundancy 1+1 redundancy is supported, where two servers are used to host/carry the same active service(s). #### 1+1 Multiplexer service Active Active operation This mode is the default output handling for when two servers are assigned to the same Multiplexer service. When operating in this mode, the service will be transmitting/outputting on both Servers, it will be the responsibility of the downstream recipient to determine which server's Multiplexer output to use. It is recommended that multiple Outputs are defined, and the "Server filter" field is used to ensure that the outputs are unique for each server. \*_If using this mode of operation, consider disabling automatic Multiplexer server failover handling. This maintenance operation is detailed in the MediaKind High Availability Distributed MOP document, and should only be configured by a qualified person._ #### 1+1 Multiplexer service Active Standby operation This handling is enabled by selecting "IP Active/Standby" and/or "ASI Active/Standby" in the Multiplexer service configuration. When enabled and the service is started, both servers will carry the services in an active state, but they are not both actively outputting/transmitting over the configured IP or ASI output. One server is active and outputting/transmitting and the service on the other server will be in an active and synchronised, but standby state. On failure of the actively outputting/transmitting server, the service in standby mode on the other server will take over. #### 1+1 Live Encoding and TS Splicer dual output prevention operation MediaKind Live Encoding and TS Splicer services may be configured in such a way that multiple servers are assigned to the same service but only one Server will be actively outputting/transmitting. This feature is enabled by selecting "Dual Output prevention" in the Live Encoding and TS Splicer services General tab and then detailing parameters for the communication between the servers assigned for the same service. When enabled and the service is started, both servers will carry the services in an active state, but only a single server will be outputting/transmitting. This setting may be used in conjunction with the "Dual Output" Failover group processing type options, to allow the service to be started on the backup server, ahead of stopping it on the Primary server. The effect being to reduce outages during failover operations. ### Packager redundancy considerations In addition to standard Packager service configuration, ensure that the Live Encoding Output(s) include Publishing points for all Backup and 1+1 partner servers, as well as the Primary Server. Two servers running MK.IO Beam for headends can be configured as a server pair, which offers various redundancy options with the options being chosen depending on the desired system behavior. ## Chain redundancy Chain redundancy provides simplified server-level redundancy. ![ServerPairChainRedundancy](/beam-img/ServerPairChainRedundancy.png) Chain redundancy is appropriate for 1+1 server use cases where: - There is no benefit to “meshing” the Encoding Live services from one server to another, to provide additional/secondary redundant sources to each multiplexer within the server pair. - When inter-chassis network bandwidth is limited. ## Mesh redundancy Mesh redundancy provides optimal service-level combined with server-level redundancy. ![ServerPairMeshRedundancy](/beam-img/ServerPairMeshRedundancy.png) Mesh redundancy is appropriate for 1+1 server cases where: - Service-level redundancy is required/beneficial. For example, with SDI sources where a single SDI feed could be lost/damaged and switching just one service is required. - The inter-network infrastructure can carry all traffic between the server pair providing redundant sources, i.e. there is adequate network bandwidth. With mesh redundancy it is necessary to use the externally visible interfaces for all service outputs which are to be meshed between single server partners. Mesh source redundancy between Live Encoding services and Multiplexer services is achieved by offering the Live Encoding sources of one server as an additional set of sources to the other. The above diagram shows that both Multiplexers within the pair are outputting (aka Active/Active). Active/Standby is also supported. # MK.IO Beam for headends, single server A single server installation of MK.IO Beam can provide limited redundancy through redundant/multiple outputs of a Live Encoding service, offering a pair of sources to a Multiplexer service, which in turn can offer redundant multiple transport stream outputs. ![BeamHeadendSingleServer](/beam-img/BeamHeadendSingleServer.png) Reliable Transport services can optionally be used to provide services for ingress to the solution, or egress from the solution. ## Input ### Compressed input - **Type:** IP (IGMPv3-based redundancy and dual multicast redundancy), Dual source redundancy (active/active & active/passive modes), Pro-MPEG FEC support - **Monitoring:** Packet loss statistics - **Protocol:** MPEG-2 TS (MPTS & SPTS), RTMP - **Codec:** JPEG-XS, MPEG-2, H.264, HEVC – MPEG-1 LII, Dolby Digital (AC-3), Dolby Digital Plus (E-AC3), AAC, HEAAC v1 and v2, Dolby E (baseband input only), Dolby Digital Plus ATMOS - **Data rate:** SD / HD up to 50 Mbps, UHD up to 80 Mbps #### Reliable transport - **SRT and RIST input/output:** - Carriage of UDP or RTP streams over the SRT protocol - SRT listener or caller mode - RIST sender mode - RIST listener mode - **Zixi input/output** - Zixi sender - Zixi feeder or Zixi Receiver mode ### Baseband input

Optional hardware required

- **SDI:** 3G / HD / SD-SDI (max 16 per server) - **SDI over IP (SMPTE ST 2022-6)** - **SMPTE ST 2110** - SMPTE ST 2110-20 uncompressed video up to UHD resolution, - SMPTE ST 2110-30/31: uncompressed audio, - SMPTE ST 2110-40: data (VITC/Time code, AFD/BAR, Closed captioning, OP-47 Teletext, SMPTE 2031 Teletext), - All SMPTE ST 2110 essences can be input as ST 2022-7 - NMOS IS-04 and NMOS IS-05 support ## Pre-processing ### Enhancement filters - **Video:** De-interlacing, Cropping, Letter boxing, Stretching, SD and HD Cross-scaling, 3:2 Pull down, MCTF, Deblocking filter, Spatial denoising filter, Cross Talk filter, Sharpening, Diamond filter - **Audio:** Automatic loudness control (A/85), Audio gain adjustment, Mute ### Image - **Image settings:** Brightness, Contrast, Saturation, Hue, Gamma, Temperature - **Image overlays:** Image insertion on input loss - **Aspect ratio:** WSS, AFD, Video index ## Metadata - **Subtitles passthrough and translation:** EIA 608/708 Closed Caption, SCTE-20, DVB Teletext, DVB Subtitles, SCTE-27, ARIB B24 - **Metadata:** SCTE-104, SCTE-35, IA 608 / 708 Closed Caption, SCTE-20, DVB Teletext, DVB-VBI, SCTE-27, OP47, SMPTE 2031, VITC , SMPTE 2038, ARIB B24 - **Streaming subtitles** - Closed Captions: WebVTT for HLS, DFXP for HSS, WebVTT or SMPTE-TT for DASH - DVB-Teletext page 888: WebVTT for HLS, DFXP for HSS, WebVTT or SMPTE-TT for DASH - DVB-Subtitles: DFXP for HSS, SMPTE-TT for DASH - **Ad insertion:** EBIF / EISS / AITSCTE-35 passthrough - **Nielsen:** Watermark extraction for multi-screen devices ## Video encoding - **Video codec:** HEVC Main 10, HEVC Main Profile, H.264 Baseline / Main / High profile, MPEG-2 - **HDR:** HDR10, HLG10, PQ10. Dolby Vision 8.1 & 5.0 - **Rate control:** CBR, VBR, constant video quality - **Data rate:** From 100 kbps to 60 Mbps - **Resolutions:** - Progressive: from QCIF to UHD, up to 60 fps - Interlaced: 480i, 576i, 720i and 1080i - **Templates:** Channel templates creation and management ## Audio encoding - **Audio encoding:** MPEG-4 / MPEG-2 AAC, AAC 5.1, HE-AAC v1 & v2, HE-AAC 5.1 1, Dolby Digital (AC3), Dolby Digital Plus (E-AC3), Dolby Digital Plus ATMOS - **Audio channels per service:** Up to 8 stereo pairs. Radio channels. - **Passthrough:** MPEG 1 LII, Dolby Digital (AC-3), Dolby Digital Plus (E-AC3) 5.1-ch or stereo, Dolby E, Dolby Digital Plus ATMOS - **Data rate:** From 4.75 kbps to 320 kbps (from 64 to 1024 kbps for DD+) ## Multiplexing ### Processing - Full re-multiplexing support including real-time PSI regeneration, and dynamic rules-based passthrough of descriptors - PID re-mapping - SI/PSI generation/re-generation and insertion from external source - Statistical multiplexing bit rate allocation for MediaKind software encoder - Bitrate policing - Input Content Extraction ### Content protection - DVB-CSA V1, V2 scrambling - AES-128 scrambling - BISS Mode 0, 1, 2 ## Broadcast output ### Output type and format - Adaptive TS / MPEG-2 TS (ALD, EBP, IDR or RAP-based signal) - SPTS over UDP ### Transmission - Multicast / Unicast, UDP, RTP ## Streaming output ### Formatting - Apple HTTP Live Streaming (Over CMAF or TS), Microsoft Smooth Streaming, DASH - Common CMAF segment delivery for HLS and DASH - Low latency chunking support for DASH - RTMP ### Multi audio - Multiple audio streams per output for HLS, Smooth Streaming and DASH ### Content protection - Microsoft PlayReady DRM support for HLS/TS, Smooth Streaming and DASH - Apple Segment for HLS/TS - FairPlay support for HLS/TS and HLS/CMAF - Adobe Primetime Access support HLS/TS - Widevine, PlayReady and Marlin support in CTR mode for DASH - Widevine and PlayReady support in CBC mode for DASH - Key provisioning interface to leading CAS & DRM vendors ### Content publishing - Support for pull scenarios in just-in-time packaging - Support publishing to local storage or to WebDAV servers ### Origin server - Built-in live and VOD origin server for HLS, Smooth Streaming and DASH - Custom HTTP headers management (Expiry settings, CORS headers…) - Built-in support of HTTP 1.1 Chunked Transfer Encoding for Low Latency ### CDN - Interfaces to leading CDNs - Certified with Akamai MSL 4 for HLS and DASH ## Monitoring & control - **Control interface:** Up to 2 IP ports, monitoring and control ports (primary and spare) through API & GUI - **Control and system protocols:** REST, HTTP, NTP, FTP, IGMP v2 / v3, SNMP v2 / 3c - **Content replacement:** SCTE-35 in-band / ESAM out-of-band. Triggers: Time signal, Splice-out / Splice-in, Alternate command, or manually triggered from GUI. - **High availability:** Support both 1+1 and N+M redundancy schemes. Service synchronization on encoder and packager ## Infrastructure - **Servers:** MediaKind-referenced hardware IT Datacenter based on COTS servers - **CPU:** Intel, AMD # Video and Audio Encoding A **live encoder** compresses uncompressed baseband video and audio into a lower-bitrate encoded format suitable for contribution, broadcast distribution, or streaming. MK.IO Beam's Live Encoding converts live video feeds into streams for internet, IP, and broadcast delivery. You configure encoding settings, output profiles, and delivery targets through the MK.IO Beam interface, without managing the underlying processing pipeline. The diagram below shows the functional blocks from input to output: ![Live Encoder functional view](/_machine-assets/81049c7d1ac223dddd6ad44aefb2c05e0bf394a3f9a9eba480886b83142ee2b0.png) _Live Encoder: functional view_ ## Processing stages **Input:** The encoder receives and ingests the video signal. Several input types are supported, including SDI for HD and UHD workflows and IP transport streams. **Decoding:** The input can be optionally decoded using a range of audio and video codecs before processing. **Pre-processing:** After decoding, a range of pre-processing functions can be applied to improve signal quality or adapt the video before encoding. **Video and audio encoding:** The video and audio are encoded. Audio pass-through is also supported, meaning audio can be forwarded without re-encoding. **Media composing:** A specific input mode for content operations. You can schedule, start, and stop blackout, logo insertion, crawler insertion, switching to an alternate live input, or switching to a TS playlist. **Post-processing:** After encoding, additional post-processing features are available, including SCTE-35 and SCTE-104 signalling for content replacement and advertising. **Output:** The encoder produces an MPEG-2 Transport Stream over IP, in either CBR or adaptive bitrate modes. FEC (Forward Error Correction) and redundant IP outputs are also supported. ## Rate control and statistical multiplexing MK.IO Beam's Live Encoder uses a leaky bucket rate control model, which defines the constraints on bitrate variation that a decoder can handle. See [Leaky bucket concept](/beam/live-encoder/leaky-bucket) for an explanation of how this works. For headend workflows, Live Encoder services can participate in statistical multiplexing (statmux) as slave services under a Multiplexer master. The Multiplexer dynamically adjusts each encoder's bitrate allocation based on scene complexity across the pool, improving overall quality within a fixed output bandwidth. See [Advanced rate control](/beam/live-encoder/rate-control) for details. ## Common use cases - Contribution encoding: compressing live video for transport from a field location to a production facility. - Headend encoding: producing compressed channels for multiplexing and distribution over cable, IPTV, or satellite. - OTT encoding: producing streams for adaptive bitrate packaging and delivery. To create your first Live Encoding service, see [Create a Live Encoding service](/beam/live-encoder/create-service). # Configure the service general parameters ## Configure general parameters 1. When creating a new service, you can: - Specify its name and optionally the template that will be used to create this new service - Activate the hardware acceleration (Intel QSV) - Define the network interface used for ESAM out-of-band messages - Define the SCTE-104 network interface used for SCTE-104 out-of-band messages

See General parameters for more details.

2. You can activate automation mode and [configure the associated parameters](/beam/live-encoder/parameters/general) (see Technical Note _"Automation for scheduled blackout"_). 3. You can activate the synchronization between two services by ticking the corresponding checkbox (see [Synchronize two services](/beam/live-encoder/configure#synchronize-two-services) and [Split one OTT service on the same server](/beam/live-encoder/configure#split-one-ott-service-on-the-same-server). New parameters are displayed. Enter the appropriate value for each parameter. 4. You can activate the [dual output prevention](/beam/live-encoder/configure#configure-dual-output-prevention) 5. You can define variants: **Redundancy** for 1+1 redundancy (i.e. primary and secondary) and **Subsets**. These variants will be used in output streams to synchronize streams or to distribute the streams across multiple servers. ## Configure clock synchronization By default, the Program Clock Reference (PCR) used in the encoder is locked to the input clock available in the source. As an alternative, Live Encoder can use the external NTP clock

External SDI Genlock clock is only visible if you set the advanced parameter enableExternalGenlockClock to true.

When using the external NTP, it is not possible to enable the service synchronization feature (see Synchronize two services).

To synchronize the PCR to the external NTP clock, follow these steps: 1. From the **General** tab, go to the **Clock synchronization** section. 2. In the **Program Clock Reference (PCR)**, select either **External NTP clock** or **External SDI Genlock clock** from the drop-down menu. 3. Select a **Save** option to save changes. ## Synchronize two services Before you start, ensure the two services are identical, same address and same port. To synchronize two services and achieve the 1+1 redundancy, follow these steps: 1. From the **General** tab, go to the **Services synchronization** section then tick the **Activate** checkbox. Parameters related to the synchronization are displayed. 2. You can edit the [synchronization parameters](/beam/live-encoder/parameters/general#synchronization-of-services). 3. From the **Output** tab, click `Edit` icon to edit the output parameters. 4. In the **General parameters** section, tick the **Synchronize** checkbox. The synchronization is automatically activated in the output, but you can deactivate it (see [Output parameters](/beam/live-encoder/parameters/output#general-mpeg-2-ts-parameters)). 5. Select a **Save** option to save changes. ## Split one OTT service on the same server Before you start: ensure the two services are identical, same address and same port. On SG1-based systems, there are multiple GPUs. In some instances, it can be necessary to create a large ABR ladder that cannot fit on a single GPU. To split an OTT service on the same server, follow these steps: 1. From the **General** tab, define two (or more) QSV services and assign each to a different **QSV Device**. 2. For both services, go to the **Service synchronization** section then tick the **Activate** checkbox. Parameters related to the synchronization are displayed. 3. Edit an identical configuration for both services (see [Synchronize two services](/beam/live-encoder/configure#synchronize-two-services)). 1. Enter a memorable identifier for the **Pool name** (in our example, **SG1**). 2. Select a **Network interface** that can be used for the communication multicast then enter a multicast address and port. ![](/_machine-assets/bb29eef7fca515116bb6ebe1e4fc4a18707a4fc680a35000078bceed477a4e10.png "Example of configuration for a pair of synchronized services") 4. In the **Input** tab, configure both services to ingest the same source. 5. In the **Encoding** tab, ensure that all encoders have matching **GOP settings**. 6. Ensure that all the output multicasts are on different address/port combinations. 7. In the **Output** tab, click `Edit` icon to edit the output parameters then from the 8. In the **General parameters** section, tick the **Synchronize** checkbox. The synchronization is automatically activated in the output, but you can deactivate it (see [Output parameters](/beam/live-encoder/parameters/output#general-mpeg-2-ts-parameters)). 9. Select a **Save** option to save changes. ## Configure dual-output prevention The dual output prevention feature allows the operator to prevent from duplicate media multicast on the same network, especially in the case of active/active encoders. This feature is based on the Multicast Guard Protocol (MGP) according to the following principles: - Point-to-point communication between both encoders using multicast messages on a dedicated port. - Both encoders constantly check that one and ONLY one encoder has its output enabled. ![EL dual output prevention diagram](/_machine-assets/b02802fa09365e5cc0f76af256632b82d251b4a62b98caa4a879556bb2cc09fc.png)

By default, the first encoder that starts has its output enabled, but you can force the output status via the API.

Benefits for the operator are: - Remove network multicast conflicts - Protect against management communication loss - Near-seamless switching during manual failover To configure dual-output prevention, follow these steps: 1. On the first encoder, click the **General** tab then go to the **Dual output prevention** section and tick the **Activate** checkbox. Parameters related to the dual output prevention are displayed. 2. You can edit the dual output prevention parameters:
Parameter Description
Network interface Name of the network interface used to communicate between the two encoders.
Address Multicast address used to communicate between the two encoders.
Port Port used to communicate between the two encoders.
Group name Group name that identifies the pair of encoders for which dual output prevention is managed.

These parameters must be the same for both encoders.

3. Repeat steps #1 to #3 on the second encoder. 4. Select a **Save** option to save changes. 5. You can go to the **Statistics** > **Outputs** to view the encoder status (enabled/disabled). ![EL dual output prevention stats](/_machine-assets/922f4b8ec5b23e5dbeb2abc681c3c92ee68e6e63cc24f7f8695231fc18f7e4ac.png) **See also**\ [Dual-output prevention parameters](/beam/live-encoder/parameters/general#dual-output-prevention) ## Create server variants There are two types of server variants: - variants based on redundancy: primary and secondary - variants based on a defined subset Once created, these variants can be used to synchronize streams or to distribute the streams across multiple servers. ### Create redundancy variants To create redundancy variants, follow these steps: 1. From the **General** tab, go to the **Server variant configuration** section. 2. Tick the **Activate** checkbox. Primary and secondary variants are automatically created. 3. Click `Edit` icon to edit the [**Server tags**](/beam/live-encoder/parameters/general#redundancy). ### Create subset variants To create subset variants, follow these steps: 1. From the **General** tab, go to the **Variants** section. 2. In the **Subset** subsection, click **Add**. A new window is displayed. 3. Enter a subset **Name**, for example **SD** or **HD** and **Server tags** (see [Server variant parameters](/beam/live-encoder/parameters/general#subset)). 4. Click **Ok** to save. 5. You can use these subsets to synchronize streams or to distribute the streams across multiple servers (see [Link an output stream to a predefined subset](/beam/live-encoder/configure/output/configure-output#link-an-output-stream-to-a-predefined-subset). # Configure advanced parameters To add advanced parameters, follow these steps: 1. From the **Advanced parameters** tab, enter a parameter name then enter its value. 2. You can click the **Add** button to add additional advanced parameters. 3. Click **Save and continue** or **Save and exit** to save your changes. # Configure the general encoding parameters Before configuring the input stream general parameters, you must select the export type.\ Select either **IP TV** or **Internet TV**. ``` - The main purpose of **IP TV** is interlaced encoding, dedicated to TV (Progressive encoding is also a configuration to leverage true motion feature). - Codec presets are different between **Internet TV** and **IP TV** export types. Video quality is better with IP TV. We use closed GOP for chunking in Internet TV and open GOP in IP TV. These are the 3 main differences. - Video, audio and metadata parameters and values may differ depending on the selected export type. ``` { /\* TODO: update links (especially ./parameters/) once MD files are created \*/} # Configure the audio encoding parameters Audio encoding parameters are only available if you defined an audio input from the **Input** tab. 1. Click **Add** to create a new audio encoding, or click `Edit` icon to edit an existing one. The **Encoding audio** window displays. 2. Select your audio **Codec** in the drop-down list. Depending on the selected audio codec, different parameters may display.

Pass-Through lets you receive an already encoded stream and forward it to the output.

3. Enter the appropriate value for [audio encoding parameters](/beam/live-encoder/parameters/encoding/audio). 4. Click **Save and continue** or **Save and exit** to save your changes. { /\* TODO: update links (especially ./parameters/) once MD files are created \*/} # Configure blackout ## Configure an automated blackout Live Encoder can blackout a program on SCTE-35 trigger and replace the video with a still image.\ SCTE-35 metadata can be: - either [in-band](/beam/live-encoder/configure/input/inband-metadata) - or [out-of-band](/beam/live-encoder/configure/input/outofband-metadata) Before you start: ensure you have configured the SCTE-35 metadata in the input stream. To create a scheduled blackout, follow these steps: ### Configure the metadata encoding ``` 1. From the **Encoding** tab, go to the **Metadata encoding** section. 2. For each SCTE-35 metadata, click `Edit` icon in the **Actions** column then set the **Codec** to **Conditioning**. 3. Click **Ok** to validate. ``` ### Configure the blackout encoding ``` 1. Go to the **Blackout configuration** section. 2. Click **Add** then configure a blackout configuration by selecting and setting the adequate [blackout parameters](../../parameters/encoding/blackout). ![](./images/EL_encoding_metadata_cfig_blackout_splice.png "Example of blackout configuration with SplieOutSpliceIn") 3. Click **Ok** to validate. ``` ### Configure the video encoding ``` 1. Go to the **Video encoding** section. 2. For each video stream, select the associated [**Stream Conditioning** and **Blackout**](../../parameters/encoding/video#general-parameters) configuration. ![EL encoding video blackout](./images/EL_encoding_video_blackout.png) 3. Click **Ok** to validate. ``` ### Configure the audio encoding ``` 1. Go to the **Audio encoding** section. 2. For each audio stream, select the associated [**Blackout**](/beam/live-encoder/parameters/encoding/audio#mpeg-1-layer-ii-dolby-digital-dolby-digital-plus-aac-he-aac-he-aac-v2-parameters) configuration. ![EL encoding audio blackout](./images/EL_encoding_audio_blackout.png) 3. Click **Ok** to validate. ``` ### Configure the subtitle encoding ``` 1. Go to the **Subtitle encoding** section. 2. For each subtitle stream, select the associated [**Blackout**](../../parameters/encoding/subtitle#general-parameters) configuration. ![EL encoding subtitle blackout](./images/EL_encoding_subtitle_blackout.png) 3. Click **Ok** to validate. ``` ### Check that blackout is present in the output ``` Open the **Output** tab to ensure that blackout is present in the output. ![EL output blackout](./images/EL_output_blackout.png) *Example of output with blackout configured* ``` ### Activate blackout. You can [Manually activate or deactivate a blackout](/beam/live-encoder/configure/encoding/blackout-encoding#manually-activate-or-deactivate-a-blackout). ## Configure a manual blackout To configure a manual blackout, follow these steps: ### Activate ESAM From the **General** tab, set the **ESAM server network interface** to activate ESAM. ### Create an SCTE-35 out-of-band input stream Go to the **Input** > **Sources** > **Out-of-band streams** section to create an SCTE-35 out-of-band input stream. ``` ![EL encoding metadata cfig](./images/EL_encoding_metadata_cfig.png) ``` ### Configure the metadata encoding ``` 1. From the **Encoding** tab, go to the **Metadata encoding** section. 2. Next to your SCTE-35 metadata, click the edit button, `Edit` icon in the **Actions** column then set the **Codec** to **Conditioning**. ![EL encoding metadata cfig conditioning](./images/EL_encoding_metadata_cfig_conditioning.png) 3. Click **OK** to validate. ``` ### Configure the blackout encoding ``` 1. Go to the **Blackout configuration** section. 2. Click **Add** then configure a blackout configuration by selecting and setting the adequate **[blackout parameters](../../parameters/encoding/blackout).** ![](./images/EL_encoding_metadata_cfig_blackout_splice.png "Example of blackout configuration with SplieOutSpliceIn") 3. Click **OK** to validate. ``` ### Configure the video encoding ``` 1. Go to the **Video encoding** section. 2. For each video stream, click `Edit` icon to select the associated [**Stream Conditioning** and **Blackout**](../../parameters/encoding/video#general-parameters) settings. ![EL encoding video blackout](./images/EL_encoding_video_blackout.png) *Example of configuration for Stream Conditioning and Blackout parameters* 3. Click **OK** to validate. ``` ### Check that blackout is present in the output Open the **Output** tab to ensure that blackout is present in the output. ``` ![EL output blackout](./images/EL_output_blackout.png) *Example of output with blackout configured* ``` ### Save Return to the list of services, or edit any parameters then save. ### Check statistics 1. From the list of services, click `Chart` icon to view statistics. 2. Ensure that blackout configurations display as expected in the **Monitoring** section of the **Statistics** page. ![screen stats blackout mfvp el](/_machine-assets/4e98b02ff31f9044b77c625211c792ed8af8557943a06c7862d8746644de5715.png) ### Activate blackout You can [Manually activate or deactivate a blackout](/beam/live-encoder/configure/encoding/blackout-encoding#manually-activate-or-deactivate-a-blackout). ## Configure a scheduled blackout Creating a scheduled blackout is a 4-step process: 1. [Create a scheduled blackout configuration](/beam/live-encoder/configure/encoding/blackout-encoding#create-a-scheduled-blackout-configuration). 2. [Apply a blackout configuration to video encodings](/beam/live-encoder/configure/encoding/blackout-encoding#apply-a-blackout-configuration-to-video-encodings). 3. [Apply a blackout configuration to audio encodings](/beam/live-encoder/configure/encoding/blackout-encoding#apply-a-blackout-configuration-to-audio-encodings). 4. [Check blackout configurations](/beam/live-encoder/configure/encoding/blackout-encoding#check-blackout-configurations). ### Create a scheduled blackout configuration Live Encoder can blackout a program and replace the video with a still image.\ You must first create the blackout configuration, then configure to apply to video encodings. Before you start, ensure that: - A **Metadata input stream** must exist. - Metadata processing is set to **Conditioning** in **Metadata encoding** parameters.

Audio plays during blackout, unless you configure the blackout to mute audio.

1. Display services. 2. Click `Edit` icon to edit the service. 3. Click the **Encoding** tab to display encoding options. 4. Scroll to **Blackout configuration** and click **+Add** to display parameters. The **Blackout configuration** options display.

You can create multiple blackout configurations for a single service.

5. Configure the parameters, then click **Ok** to save. Blackout configurations display in the list (see image below). ![screen encoding blackout configuration mfvp el](/_machine-assets/9c40ec6bdb9ac3494e7537de92a3bc2fe7bc4f52999cf7d4c8d10e0f3db514eb.png)

If no SCTE-35 Input options display in the list, then reconfigure inputs.

``` ![screen blackout configuration list mfvp el](./images/screen_blackout_configuration_list_mfvp-el.png) ``` 6\. Use the save options to save configurations. 7. Apply the blackout configuration to a [video](/beam/live-encoder/configure/encoding/blackout-encoding#apply-a-blackout-configuration-to-video-encodings) and/or [audio](/beam/live-encoder/configure/encoding/blackout-encoding#apply-a-blackout-configuration-to-audio-encodings) encoding. ### Apply a blackout configuration to video encodings You can apply a blackout configuration per video encoding. Before you start: ensure that you created at least one blackout configuration.

Blackout is not supported in Pass-through.

1. Display services. 2. Click `Edit` icon to edit the service. 3. Open the **Encoding** tab, then click `Edit` icon to edit the video stream. 4. Select the blackout option. All previously created blackout configurations display. 5. Check that the applied Blackout option displays for video encodings. ![screen video encoding table blackout mfvp el](/_machine-assets/463b2f26f56b684ddf6532f709b142a650fa1510342f0f766aba7725060f47a6.png) 6. [Apply the blackout configuration to audio](/beam/live-encoder/configure/encoding/blackout-encoding#apply-a-blackout-configuration-to-audio-encodings) streams. 7. [Add encodings to output](/beam/live-encoder/configure/output/configure-output#define-the-output-stream-composition). 8. Use the save options to save configurations. 9. Ensure that [Blackout configurations are configured and applied](/beam/live-encoder/configure/encoding/blackout-encoding#check-blackout-configurations) as expected. ### Apply a blackout configuration to audio encodings You can apply a blackout configuration per audio encoding. before you start, ensure that you have created at least one blackout configuration.

Blackout is not supported in Pass-through.

1. Display services. 2. Click `Edit` icon to edit the service. 3. Open the **Encoding** tab, then click `Edit` icon to edit the audio stream, or **Add** a stream. 4. Click **Blackout** to display the list of previously created blackout configurations, then select a blackout configuration to apply. ![screen blackout configuration parameter audio selection mfvp el](/_machine-assets/2dda7e83e380c2560225df8bacd2d63c9c28cd6efc2de3f63b5d50dbe6313271.png) 5. Click **OK** to save. 6. Check that audio encodings display in the list with the blackout tag displayed. ![screen audio encoding table blackout mfvp el](/_machine-assets/c1050b1512ef35ef373fa339bd296f64563823b49a4dda878fbdc36dece32ec1.png) 7. [Add encodings to output](/beam/live-encoder/configure/output/configure-output#define-the-output-stream-composition). ### Check blackout configurations Blackout configurations are first created, then applied to video and/or audio encodings. The encodings are then configured in an output stream. Check the overviews to ensure that blackouts are configured and applied. 1. Display services. 2. Click `Edit` icon to edit the service. 3. Open the **Encoding** tab and ensure that any expected blackout configurations display in the list. ![screen blackout configuration list mfvp el](/_machine-assets/7bcca72b44e46b5bc22c6eb5d5691c0bd8f8314fe874528b57d089cff1aa5337.png) 4. Check video and audio encodings to ensure that blackout configurations are applied as expected. 5. Open the **Output** tab to ensure expected video and audio encodings display in the list. ![screen output stream list blackout mfvp el](/_machine-assets/91a2dceaef0f86e004e29f9e50af7a1aad39769eb4f6305ba2f92339f09b13a6.png) 6. Return to the list of services, or edit any parameters and then save. 7. From the list of services, click `Chart` icon to view statistics. 8. Ensure that blackout configurations display as expected in the **Statistics** page. ![screen stats blackout mfvp el](/_machine-assets/4e98b02ff31f9044b77c625211c792ed8af8557943a06c7862d8746644de5715.png) ### Activate blackout You can [Manually activate or deactivate a blackout](/beam/live-encoder/configure/encoding/blackout-encoding#manually-activate-or-deactivate-a-blackout). ## Manually activate or deactivate a blackout Once you have configured a [manual](/beam/live-encoder/configure/encoding/blackout-encoding#configure-a-manual-blackout) or an [automated blackout](/beam/live-encoder/configure/encoding/blackout-encoding#configure-an-automated-blackout) and started a service, you can manually activate or deactivate it.

Manual blackout activation/deactivation is only available if Trigger parameter is set to spliceOutSpliceIn.

![EL encoding metadata cfig blackout splice cut](/_machine-assets/bafe96e6e3484361ab5e3d3c0fdb0a9b0bc599d9c8a7cb08f22a0288b5fc3c92.png) ``` 1. Display statistics on [**Outputs**](../../monitor-statistics). ![EL stats outputs blackout](./images/EL_stats_outputs_blackout.png) 2. Click the **Activate Blackout** button. A message informs you that the command has been sent. 3. Click **OK**. The current video is blacked out until the specified **Timeout** \(if configured\); or by clicking the **Deactivate Blackout** button. ``` { /\* TODO: update links (especially ./parameters/) once MD files are created \*/} # Configure logo insertion 1. From the **Encoding** tab, go to the **Logo insertion** section. 2. Tick the **Activate** checkbox. New [parameters](/beam/live-encoder/parameters/encoding/logo-insertion) are displayed. 3. Enter and/or select the appropriate value for each parameter. 4. Click **Save and continue** or **Save and exit** to save your changes. { /\* TODO: update links (especially ./parameters/) once MD files are created \*/} # Configure metadata encoding Before you start: ensure you have defined metadata encoding parameters (see [Configure in-band metadata input stream](/beam/live-encoder/configure/input/inband-metadata) or [Configure out-of-band metadata input stream](/beam/live-encoder/configure/input/outofband-metadata)). 1. From the **Encoding** tab, go to the **Metadata encoding** section. 2. Metadata created from the **Input** tab has been already automatically created. You can click `Edit` icon to edit an existing one or click **Add** to create a new metadata encoding configuration. The **Encoded metadata selection** window displays. 3. Select the **Codec** to define how metadata is processed.
Metadata input type Possible values for Codec
SCTE-35
SCTE-35 OOB
Cuetones
Pass-through or Conditioning
- Select Pass-through to forward SCTE-35 information in dedicated output metadata track without video conditioning. For Automation (Clock icon), metadata must be Pass-through.
- Conditioning allows video stream conditioning and lets you define a POIS server. It can also be used in Blackout.
AIT
EBIF
EISS
Pass-through
SMPTE-2038 Pass-through, Timecode ID3, or Tissot clock metadata ID3
In Pass-through mode, you can specify the Max Bitrate on output. If the bitrate target is exceeded, an alarm is raised.
The Tissot metadata present in the SMPTE-2038 stream contains several game metadata (shot clock, scores, team names,…) sent individually in distinct PES packets. To ensure that the Tissot metadata is available for the clients/players, Live Encoder carries them into one ID3 stream (see Convert SMPTE 2038 to ID3).
4. For **SMPTE-2038** input metadata, if you selected [**Timecode ID3**](/beam/live-encoder/parameters/encoding/metadata#timecode-id3-parameters), or [**Tissot clock metadata ID3**](/beam/live-encoder/parameters/encoding/metadata#tissot-clock-metadata-id3-parameters) codec, specific parameters need to be completed. 5. If metadata is set to **Conditioning**, and if you want to define a POIS server, tick the **Use POIS** checkbox then set the appropriate value for each [POIS parameter](/beam/live-encoder/parameters/encoding/metadata#pois-parameters). 6. If metadata is set to **Conditioning** with a POIS server, and if you want to adjust the PTS to ensure that the SCTE-35 marker is equal to the PTS of the corresponding video frame, tick the [**PTS insertion compensation**](/beam/live-encoder/parameters/encoding/metadata) checkbox. 7. If metadata is set to **Conditioning** and if you want the encoder to retrieve the conditioning status after a failover thus ensuring internal POIS resiliency, tick the [**Recover conditioning state if failover**](/beam/live-encoder/parameters/encoding/metadata) checkbox. 8. Click **OK** to validate. 9. Click **Save and continue** or **Save and exit** to save your changes. 10. You can specify the conditioned metadata in the [video stream parameters](/beam/live-encoder/parameters/encoding/video#stream-metadata-settings). 11. You can add the conditioned metadata in the [output stream](/beam/live-encoder/configure/output/configure-output#define-the-output-stream-composition). ## Convert SMPTE 2038 to ID3 MediaKind Live Encoder ingests and converts SMPTE-2038 to provide data downstream based on the incoming time sources.\ To ensure that metadata is available for the clients/players, the Live Encoder carries them into ID3 streams. Two types of data can be extracted from SMPTE-2038 and carried into ID3 streams: - Tissot metadata: the Tissot metadata in SMPTE-2038 stream contains several game metadata (shot clock, scores, Team names, etc) sent individually in distinct PES packets. - Timecode information: there are multiple sources of time, and the user can configure the type of timecode to use (LTC, VITC1 or VITC2). The timecodes are embedded in an ID3 stream and identified thanks to MPEG2-TS descriptors. If the input source does not have valid timing data, the timing information is not present in the ID3 data.

This feature is only available with Internet TV export type.

To convert SMPTE 2038 to ID3, follow these steps: 1. From the **Input** tab, [configure the SMPTE 2038 in-band metadata in the input stream](/beam/live-encoder/configure/input/inband-metadata). 2. Go to the **Encoding** tab and check that **Export type** is set to **Internet TV**. 3. Go to the **Metadata encoding** section to add and configure the subtitle encoding: - Click the **Add** button then set the **Codec** to **Timecode ID3**, set **Origin** to **LTC** and enter the **Period** (in ms). ![el encoding metadata smpte2038 to id3](/_machine-assets/77603c2e87786c1826e3ba5a223503659129fed445a547b94e796d3b829d0528.png) - Click **OK** to validate. 4. Add the video stream related to the output. 1. From the **Output** tab, go o the **Output streams** section, then click either the **Add** button (if no stream has been selected) or the edit button, `Edit` icon in the **Actions** column. 2. Select the video stream that you configured in Step #3. ![EL output stream metadata id3](/_machine-assets/3d519b42c5bf658e8728976e7daf698c41799ad834e175b11b7a1a7095d0f33e.png) 3. Click **OK** to validate. You should see the selected streams in the list of output streams. 5. Click **Save and exit** to save and finalize your service configuration and go back to the **Services** page. 6. [Assign a server to run the service](/beam/web-interface/services#assign-a-server-to-run-the-service). 7. Click `Chart` icon to display service details and monitor the service: - **Media info** tab shows the SMPTE-30 metadata at input. ![EL stats media info metadata smpte2038](/_machine-assets/627418f7f611fe5f74ed409eb5ba3a5b094126870092c47d30d04ef9fc1e6a25.png) - **Output** tab shows ID-3 metadata at output. ![EL stats output metadata id3](/_machine-assets/aa3e446dc8c60a454b8b5243e940815815e061f6f304b3dc34c432c8b58acbd2.png) { /\* TODO: update links (especially ./parameters/) once MD files are created \*/} # SCTE-104/IP out-of-band metadata Live Encoder supports out-of-band conditioning via SCTE-104/IP, on the same principle as ESAM. - Live Encoder can receive conditioning triggers from an external server, using SCTE-104 over IP messages. - Once received, SCTE-104 messages are decoded, sent to the targeted channel (based on DPI PID index) and converted in SCTE-35 in order to enable stream conditioning actions. ![EL SCTE104 adsmart](/_machine-assets/8ce6190febd26b16683b7cbc115ab4115a705ab67b7a2b4a97ff488c27b6f4a3.png) _SCTE-104 out-of-band IP conditioning_ ## Configure SCTE-104/IP out-of-band metadata Before you start, ensure that [you have added and configured the SCTE-104/IP out-of-band metadata in the input stream](/beam/live-encoder/configure/input/outofband-metadata#configure-scte-104ip-out-of-band-metadata-input-stream). Configuring SCTE-104/IP out-of-band metadata requires multiple steps: ### Configure the metadata encoding ``` 1. From the **Encoding** tab, go to the **Metadata encoding** section. 2. For each SCTE-104/IP metadata, click `Edit` icon in the **Actions** column then set the **Codec** to **Conditioning**. ![EL encoding metadata cfig conditioning](./images/EL_encoding_metadata_cfig_conditioning.png) 3. Click **Ok** to validate. ``` ### Configure the video encoding ``` 1. Go to the **Video encoding** section. 2. For each video stream, select the associated [**Stream Conditioning**](/beam/live-encoder/configure/encoding). ![EL encoding video adsmart](./images/EL_encoding_video_adsmart.png) *Example of video configuration* 3. Click **Ok** to validate. ``` ### Add the SCTE-35 conditioned stream related to the SCTE-104/IP to the output ``` 1. Go to the **Output** tab. 2. Go to the **Output streams** section, then click either the **Add** button (if no stream has been selected) or `Edit` icon in the **Actions** column. 3. For each video stream, tick the associated [**Stream Conditioning**](/beam/live-encoder/configure/encoding). ![EL output metadata conditioning](./images/EL_output_metadata_conditioning.png) 4. Click **Ok** to validate. You should see the selected streams in the list of output streams. ``` # Configure subtitle burn-in You can burn DVB or Teletext subtitles into the video stream. You must have defined one or more DVB or Teletext subtitle(s) (see [Configure input subtitle selection](/beam/live-encoder/configure/input/subtitle)). 1. From the **Encoding** tab, go to the **Subtitle burn-in configuration** section. 2. Click **Add** to create a new subtitle burn-in configuration or click `Edit` icon to edit an existing one. The **Subtitle burn-in configuration** window is displayed. 3. In the **input** value, select the DVB or Teletext subtitle(s) that you previously created from the **Input** tab. 4. Configure the video encoding: 1. For each video stream, click `Edit` icon then go to the **Subtitle settings** section and select a subtitle burn-in that you just created. ![el cfig encoding video subtitle burnin](/_machine-assets/ed51f0494f866081c004bc5db27f608e7f1bc9bc321cf4fe3e82302b645edce8.png) 2. Click **OK** to validate. 5. Click **Save and continue** to save your modifications and go to another tab. 6. [Add subtitle(s) to output stream(s)](/beam/live-encoder/configure/output/configure-output#define-the-output-stream-composition). # Configure subtitle encoding Before you start: ensure you have configured a [subtitle input stream](/beam/live-encoder/configure/input/subtitle). 1. From the **Encoding** tab, go to the **Subtitle encoding** section. 2. Click **Add** to create a new subtitle processing configuration or click `Edit` icon to edit an existing one. The **Subtitles encoding** window displays. 3. Select the **Codec** to define how metadata is processed: - **Pass-through** - **DVB-Subtitles** - **DVB-Teletext** - **Closed caption CEA 608** (only valid with both IP TV export type and 25i/50p to 29.97i/59.94p frame rate conversion) - **DVB-TTML** (only valid with Internet TV export type) - **DASHIF-TTML** (only valid with Internet TV export type)

Possible values depend on subtitle type.

4. Depending on the selected codec, [specific parameters](/beam/live-encoder/parameters/encoding/subtitle) must be configured. 5. Click **Save and continue** or **Save and exit** to save your changes. 6. Add the conditioned metadata to the output stream (see [Define the output stream composition](/beam/live-encoder/configure/output/configure-output#define-the-output-stream-composition)). ## Convert Teletext to Closed Caption To convert Teletext to Closed Caption, follow these steps: ### Add input subtile From the **Input** tab, go to the **Sources** > **Input streams selection** > **Subtitle ID** section then [Configure input subtitle selection](/beam/live-encoder/configure/input/subtitle) by setting the **Type** to **Teletext**. ### Check Video adjustment Go to the **Media processing** tab then go to the **Video processing** > **Video adjustment** section and check that **Frame rate conversion** is set to **25i/50p to 29.97i/59.94p**. ### Check export type Go to the **Encoding** tab then check that **Export type** is set to **IPTV**. ### Configure subtitle encoding Go to the **Metadata encoding** section to add and configure the subtitle encoding: 1. Click the **Add** button then set the **Codec** to **Closed caption CEA 608**. 2. Click the **Add** button then specify the input teletext**Magazine**, the **Page** and the destination CEA 608 **Field**. ![EL encoding video subtitle CC CEA608](/_machine-assets/c7132aa21557047e99ea3c9c37335aed5610ae167b44e9aeadcc6d56e6d1051d.png) 3. Click **OK** to validate. ### Configure subtitle encoding Go to the **Video encoding** section to configure the video encoding. 1. Go to the **Video encoding** > **Stream metadata setting** section. 2. Tick the **Closed caption** checkbox then in the **Closed caption stream**, select the stream created in Step #5. ![EL encoding video metadata settings CC](/_machine-assets/0390aa33a33720f6ca0be31b1261b243e825724aabd260a27d91c14acae164cd.png) 3. Click **OK** to validate. ### Add the video stream related to the output 1. Go to the **Output** tab. 2. Go to the **Output streams** section, then click either the **Add** button (if no stream has been selected) or `Edit` icon in the **Actions** column. 3. Select the video stream that you configured in Step #6 that includes the closed caption. ![EL output stream video CC](/_machine-assets/13600b253ee55f256702c70b78ca03bbace8db2be7c8817b8a40b17e4a51bf14.png) 4. Click **OK** to validate. You should see the selected streams in the list of output streams. ## Convert Teletext to TTML To convert Teletext to TTML, follow these steps: ### Add input subtile 1. From the **Input** tab, go to the **Sources** > **Input streams selection** > **Subtitle ID** section and [Configure input subtitle selection](/beam/live-encoder/parameters/input/subtitle) by setting the **Type** to **Teletext**. ### Check export type 2. Check that **Export type** is set to **Internet TV**. ### Configure the subtitle encoding 1. Click the **Encoding** tab then go to the **Subtitle encoding** section. Teletext subtitle has been added to the **Encoding** tab. By default **Codec** is set to **Pass-through**. 2. Click `Edit` icon to edit the subtitle encoding. 3. Select the codec used to convert the subtitles, **DVB-TTML**. A new window let you configure the [TTML parameters](/beam/live-encoder/parameters/encoding/subtitle#dvb-ttml-with-teletext-subtitles-input). 4. Click **Ok** once done. You should get the following: ![el ttml encoding](/_machine-assets/82fbd4cac8519ceb34a01f4b762ea4c2073b50bc3074a236eb6a75203777811a.png) ### Add the subtitle stream to the output 1. Click the **Output** tab. 2. Go to the **Output streams** section, then click either the **Add** button (if no stream has been selected) or the edit button, `Edit` icon in the **Actions** column. 3. Tick the subtitle stream that you configured in the previous step. 4. Click **OK** to validate. You should see the selected streams in the list of output streams. ![el ttml output](/_machine-assets/484c53060abca88cb99758cade436239bdf7a36e9f3322fdc918eda8e43674a4.png) ## Convert ARIB B24 to DVB-Teletext

Only available with MPEG-2 TS/UDP input type (or MediaComposer with MPEG-2 TS/UDP source only).

To convert ARIB B24 subtitles to Teletext, follow these steps: ### Add an ARIB B24 subtitle at the input 1. From the **Input** tab, go to the **Sources** > **Input streams selection** > **Subtitle ID** section. 2. Click **Add** then set the **Type** to **ARIB B24** and enter either the **PID** or **Language** of the subtitle. You should get the following: ![el arib input](/_machine-assets/66778c1184cfb0d31f941c8efb539f12850963cfdaefc7dfa1c14541761a86d9.png) ### Configure the subtitle encoding 1. Click the **Encoding** tab then go to the **Subtitle encoding** section. ARIB B24 subtitle has been added to the **Encoding** tab. By default **Codec** is set to **Pass-through**. 2. Click `Edit` icon to edit the subtitle encoding. 3. Select the codec used to convert the subtitles, **DVB-Teletext**. You should get the following: ![el arib encoding](/_machine-assets/e9c87b65a07a716293b3f2d5032b2c774ea0e822ff735fea4b517313b4951c04.png) ### Add the subtitle stream to the output 1. Click the **Output** tab. 2. Go to the **Output streams** section, then click either the **Add** button (if no stream has been selected) or the edit button, `Edit` icon in the **Actions** column. 3. Tick the subtitle stream that you configured in the previous step. 4. Click **OK** to validate. You should see the selected streams in the list of output streams. ![el arib output](/_machine-assets/dac776d74d22fbea26c5abd876893fed24399ece6480db8edfb306b89c8a759d.png) ### Check that ARIB B24 subtitles are present ``` . You can check that ARIB B24 subtitles are present in the input by displaying statistics. ![el arib stats](./images/el_arib_stats.png) . You can check that ARIB B24 subtitles are present in the output by opening the output stream in a player. ``` ## Convert CEA-608/708 Closed Captions to TTML for DASH output To convert CEA-608/708 Closed Captions to TTML, follow these steps: ### Add input subtile 1. From the **Input** tab, go to the **Sources** > **Input streams selection** > **Subtitle ID** section and [Configure input subtitle selection](/beam/live-encoder/parameters/input/subtitle) by setting the **Type** to **CEA-608/CEA-708 Closed Captions**. ### Check export type 2. Check that **Export type** is set to **Internet TV**. ### Configure the subtitle encoding 1. Click the **Encoding** tab then go to the **Subtitle encoding** section. 2. Click **Add**. A new window let you configure the subtitle parameters. 3. Select the codec used to convert the subtitles, **DVB-TTML** or **DASHIF-TTML** then configure the [DVB-TTML](/beam/live-encoder/parameters/encoding/subtitle#dvb-ttml-with-cea-608cea-708-closed-captions-input) or [DASHIF-TTML](/beam/live-encoder/parameters/encoding/subtitle#dashif-ttml-with-cea-608cea-708-closed-captions-input). 4. Click **Ok** once done. ### Add the subtitle stream to the output 1. Click the **Output** tab. 2. Go to the **Output streams** section, then click either the **Add** button (if no stream has been selected) or the edit button, `Edit` icon in the **Actions** column. 3. Tick the subtitle stream that you configured in the previous step. 4. Click **OK** to validate. You should see the selected streams in the list of output streams. ## Convert ARIB B24 to DVB-Teletext

Only available with MPEG-2 TS/UDP input type (or MediaComposer with MPEG-2 TS/UDP source only).

To convert ARIB B24 subtitles to Teletext, follow these steps: ### Add an ARIB B24 subtitle at the input 1. From the **Input** tab, go to the **Sources** > **Input streams selection** > **Subtitle ID** section. 2. Click **Add** then set the **Type** to **ARIB B24** and enter either the **PID** or **Language** of the subtitle. You should get the following: ![el arib input](/_machine-assets/66778c1184cfb0d31f941c8efb539f12850963cfdaefc7dfa1c14541761a86d9.png) ### Configure the subtitle encoding 1. Click the **Encoding** tab then go to the **Subtitle encoding** section. ARIB B24 subtitle has been added to the **Encoding** tab. By default **Codec** is set to **Pass-through**. 2. Click `Edit` icon to edit the subtitle encoding. 3. Select the codec used to convert the subtitles, **DVB-Teletext**. You should get the following: ![el arib encoding](/_machine-assets/e9c87b65a07a716293b3f2d5032b2c774ea0e822ff735fea4b517313b4951c04.png) ### Add the subtitle stream to the output 1. Click the **Output** tab. 2. Go to the **Output streams** section, then click either the **Add** button (if no stream has been selected) or the edit button, `Edit` icon in the **Actions** column. 3. Tick the subtitle stream that you configured in the previous step. 4. Click **OK** to validate. You should see the selected streams in the list of output streams. ![el arib output](/_machine-assets/dac776d74d22fbea26c5abd876893fed24399ece6480db8edfb306b89c8a759d.png) ### Check that ARIB B24 subtitles are present ``` . You can check that ARIB B24 subtitles are present in the input by displaying statistics. ![el arib stats](./images/el_arib_stats.png) . You can check that ARIB B24 subtitles are present in the output by opening the output stream in a player. ``` ## Convert DVB-Sub to DVB-Teletext using OCR

This feature relies on an open-source OCR (Optical Character Recognition) engine that extracts printed or written text from images. Once converted to Text, the subtitles are converted to DVB-Teletext.

To convert DVB-Subtitles to DVB-Teletext, follow these steps: ### Add a DVB subtitle at the input 1. From the **Input** tab, go to the **Sources** > **Input streams selection** > **Subtitle ID** section. 2. Click **Add** then set the **Type** to **DVB-Subtitles** and enter either the **PID** or **Language** of the subtitle. You should get the following: ![el dvbsub input](/_machine-assets/8e2aab64285052a0b4979be6329550b5d9fc2d506eee1f9bcd0d4bee405391c9.png) ### Configure the subtitle encoding 1. Click the **Encoding** tab then go to the **Subtitle encoding** section. DVB subtitle has been added to the list of subtitles. By default **Codec** is set to **Pass-through**. 2. Click `Edit` icon to edit the subtitle encoding.

Usually, there is no need to set the Forced language field because the language is directly retrieved from the input DVB Subtitles. If the language is not set or is wrong in the input DVB subtitle descriptor, it can be set by the "Forced language" field.

3. Select the codec used to convert the subtitles, **DVB-Teletext**. You should get the following: ![el dvbsub encoding](/_machine-assets/8894c2171dec0411bcf21797b7c4f5ef8cb696a2d35c719fce8971f94dbc00c3.png) ### Add the subtitle stream to the output 1. Click the **Output** tab. 2. Go to the **Output streams** section, then click either the **Add** button (if no stream has been selected) or the edit button, `Edit` icon in the **Actions** column. 3. Tick the subtitle stream that you configured in the previous step. 4. Click **OK** to validate. You should see the selected streams in the list of output streams. ![el dvbsub output](/_machine-assets/cb6604c66fbcc2f49119914b52d2a0b2a00c63b71e7a13f4799bc3395fc6d59d.png) ### Check the average OCR confidence You can display statistics to check the average OCR confidence (in the range 0-100) on the last converted subtitle. ### Check that DVB subtitles are present You can check that DVB subtitles are present in the output by opening the output stream in a player. { /\* TODO: update links (especially Chunk) once MD files are created \*/} # Configure the video encoding parameters To configure the video encoding parameters, follow these steps: 1. From the **Encoding** tab, go to the **Video encoding** section. 2. Click the **Add** button to create a video profile or click `Edit` icon in the **Actions** column to configure an existing profile. 3. Enter the appropriate value for [**Video encoding**](/beam/live-encoder/parameters/encoding/video) parameters. 4. If you selected Statmux rate control, expand the [**Statmux advanced settings**](/beam/live-encoder/parameters/encoding/video#statmux-advanced-parameters) section then enter the appropriate value for each parameter. 5. Expand the [**Codec settings**](/beam/live-encoder/parameters/encoding/video#codec-settings) section then enter the appropriate value for each parameter. 6. Expand the [**Video processing**](/beam/live-encoder/parameters/encoding/video#video-processing) section then enter the appropriate value for each parameter. 7. Expand the [**GOP settings**](/beam/live-encoder/parameters/encoding/video#gop-settings) section then enter the appropriate value for each parameter. 8. Expand the [**Aspect ratio**](/beam/live-encoder/parameters/encoding/video#aspect-ratio) section then enter the appropriate value for each parameter. 9. Expand the [**Stream metadata settings**](/beam/live-encoder/parameters/encoding/video#stream-metadata-settings) section then enter the appropriate value for each parameter. 10. Expand the [**Subtitle settings**](/beam/live-encoder/parameters/encoding/video#subtitle-settings) section then enter the appropriate value for each parameter. 11. Cick **Ok** to validate. 12. You can create a [child encoding](/beam/live-encoder/configure/encoding/video-encoding#create-a-child-encoding-factorization). 13. You can configure [HDR signaling conversion (HEVC)](/beam/live-encoder/configure/encoding/video-encoding#configure-hdr-signaling-conversion-hevc). 14. Click **Save and continue** or **Save and exit** to save your changes. ## Create a child encoding (factorization) MediaKind Live Encoder can factorize the encoding of ABR profiles that have the same resolution and frame rate: processing for parent and child encodings is mutualized to optimize CPU usage. Before you start: ensure you have created a video encoding stream. This main video stream will be considered as parent. To create a child video encoding, follow these steps: 1. Select the parent video stream you want to factorize. 2. Click `Fork` icon in the **Actions** column to create and configure a child encoding with the corresponding [target bit rate](/beam/live-encoder/parameters/encoding/video#general-parameters).

Child stream bitrates must be more than half of the parent bitrate.

![MFVP EL video encoding factorization](/_machine-assets/005c3158adab12ad2990b3ea97b39cd85de06c3d5df5dffa5c0c20a1588bf6fe.png) 3. Click **Save and continue** or **Save and exit** to save your changes. ## Configure HDR signaling conversion (HEVC) You can configure HDR signaling conversion in the encoding options, or choose to keep the initial input ‘as is’ using the **Follow input** option. 1. From the **Video encoding** section, click **Add** to create and configure a new video stream or click `Edit` icon to edit an existing video stream. 2. Set the video codec to **HEVC main 10 bits**. 3. Expand the **Codec settings** section. 4. Configure the [**Dynamic range mode**](/beam/live-encoder/parameters/encoding/video#codec-settings) depending on your conversion requirements. ![encoding video hevc10 el](/_machine-assets/32f9e40339e0108a9c7d18a323ac26e974c4416917ecf2deb5cd76635302b939.png) 5. Click **Ok** to validate. The **Encoding** page is displayed. 6. Click **Save and continue** or **Save and exit** to save your changes. ## Align EBP acquisition time on timecodes

This feature is only available with advanced parameters.

This feature allows aligning wallclock time in the output segments. A typical use case is when you have several live channels with feeds coming from distinct cameras. The use of the Timecode for the EBP acquisition time allows the end-user player to switch to the closest segment when switching from one live channel to another. To configure a service, follow these steps: 1. Create an Internet TV service named **wallClock**. 2. Go to the **Advanced parameters** tab, then click **Add** an enter the following parameters:
Parameter name Description Value
videoSynchronizer.alignEbpAcquisitionTimeOnTimecodes Activates this feature. Set to true
videoSynchronizer.alignEbpAcquisitionTimeOnTimecodes.margin Margin in seconds Default value is 10
3. Go to the **Output** tab, click **Add an output** then go to the **General parameters** section and set the **GOP signaling** to **EBP-based**. 4. Click **Save and exit** to save and finalize your service configuration and go back to the **Services** page. 5. From the **Services** page, click the `Clock` icon icon of the wallClock service to display statistics. 6. Go to the **Monitoring** page: **EBP alignment on timecode** information is displayed at the bottom right. It includes two parameters: - **Aligned** status: indicates if the UTC time was aligned with the Timecode. Possible values: true or false - **Offset (ms)**: offset in milliseconds between the Timecode and UTC time (average on 1 second). These two parameters let you check if the Timecode and NTP time are almost aligned. They are almost aligned: - if the absolute value of the difference is lower than the margin specified in the **Advanced parameters**, - or if the absolute value of the difference is greater than the number of seconds in an hour (3600) minus the margin. This means that the timecode and UTC time are spread on two distinct hours.

An alarm can be raised if the UTC Timecode cannot be aligned on the EBP Timecodes, either because there are no Timecodes or because the offset is larger than the margin.

# Configure the input 1. From the **services** page, click `Edit` icon to edit the service. The **General parameters** display. 2. Select **Input** tab to display parameters. 3. Enter the appropriate value for each [parameter](/beam/live-encoder/parameters/input/general).

Parameters may differ depending on the selected input type, especially SDI or SMPTE ST 2110 that have a limited number of parameters.

4. You can [configure the source error management](/beam/live-encoder/configure/input/source-error-management). 5. [Configure source(s)](/beam/live-encoder/configure/input/input-stream-source): the primary source and optionally the secondary source. 6. Select a **Save** option to save changes. { /\* TODO: update links (especially ./parameters/) once MD files are created \*/} # Configure the audio input stream 1. Display services. 2. Click `Edit` icon to edit the service. The **General parameters** display. 3. Select **Input** tab to display parameters. 4. Go to the **Sources** > **Input streams selection** > **Audio ID** section then click **Add** to configure a new audio stream or click `Edit` icon to edit an existing one. 5. Enter the appropriate value for each [audio stream parameter](/beam/live-encoder/parameters/input/video-and-audio#audio).

Parameters differ depending on the selected input type.

6. Click **Ok**. The audio input is added to the list of audio inputs. 7. Click **Save and continue** or **Save and exit** to save your changes. { /\* TODO: update links (especially ./parameters/) once MD files are created \*/} # Configure cross stream prevention 1. From the **Input** tab, go to the **Cross stream prevention** section then click the **Add** button. The **Metadata selection** window displays. 2. Enter the **Stream ID** and optionally the **Period** (see [Cross stream prevention parameters](/beam/live-encoder/parameters/input/cross-stream-prevention)). 3. Click **Ok** to save settings and return to the service edition options. The Cross-stream prevention metadata stream is added to the list. 4. Save your settings to continue or click **Exit** to quit without saving. 5. You can add the metadata to the output stream (see [Define the output stream composition](/beam/live-encoder/configure/output/configure-output#define-the-output-stream-composition)). { /\* TODO: update links (especially ./parameters/) once MD files are created \*/} # Configure in-band metadata in input stream To configure in-band metadata input stream, follow these step:

In our example, we consider that you have selected an MPEG-2 TS input.

1. From the **Input** tab, go to the **Input streams selection** > **Metadata ID** section then click the **Add** button. The **Metadata selection** window displays. ![view add input metadata el](/_machine-assets/d24f8fec6bcb29b49c57648b9f0c2c6bf7821888ed9582d4c2fef08430cf41e1.png) 2. Select a [**Type**](/beam/live-encoder/parameters/input/metadata#in-band-metadata). ![view metadata selection type](/_machine-assets/2e2f80dcc59eaa854dffc31d56e0576ef7892ae88e47f5e07b0a2102e90695ea.png) 3. Enter or select the following information depending on the selected type: 1. Enter a [**PID**](/beam/live-encoder/parameters/input/metadata#in-band-metadata). 2. If you selected **SCTE-35** type, you can apply a **Delay**. 3. If you selected **Cuetones** type, select the audio source that you previously created. 4. Click **Ok** to save. - The in-band metadata stream is added to the list of metadata. - The in-band metadata is automatically added to the **Encoding** tab. 5. Click **Save and continue** or **Save and exit** to save your changes. { /\* TODO: Transition? Are the two next items necessary? \*/ } - You can [configure the metadata encoding](/beam/live-encoder/configure/encoding/metadata-encoding). - You can [add the metadata to the output stream](/beam/live-encoder/configure/output/configure-output#define-the-output-stream-composition). { /\* TODO: update links (especially ./parameters/) once MD files are created \*/} # Configure stream source(s) in input stream You can configure two multicast sources. To configure a first source, complete the parameters in the **Primary** tab. If you want to configure a second source, you just have to click the **Add** button in the top right corner then complete the parameters in the **Secondary** tab.

For more information on SDI/IP redundancy, see Configure an SDI/IP redundancy.

1. Display services. 2. Click `Edit` icon to edit the service. The **General parameters** display. 3. Select **Input** tab to display parameters. 4. Go to the **Sources** section then enter and/or select the appropriate values for each [input source](/beam/live-encoder/parameters/input/source). 5. Depending on the input type, you can add: - [video input(s)](/beam/live-encoder/configure/input/video-stream) - [audio input(s)](/beam/live-encoder/configure/input/audio-stream) - [subtitles input(s)](/beam/live-encoder/configure/input/subtitle), - [VANC data input(s)](/beam/live-encoder/configure/input/vanc-data) _(SMPTE ST 2110 input only)_ - [in-band metadata input(s)](/beam/live-encoder/configure/input/inband-metadata) - [out-of-band metadata](/beam/live-encoder/configure/input/outofband-metadata) - [cross stream prevention](/beam/live-encoder/configure/input/cross-stream-prevention) 6. Click **Save and continue** or **Save and exit** to save your changes. ## Configure an SDI/IP redundancy You can configure two SDI/IP input sources to allow the management of losses on the input of the encoder. The redundancy works in active/passive mode. On primary input signal loss, the secondary input is used as source, if the backup input is lost, the primary input switches back to the primary source. To activate the redundancy, follow these steps: 1. Set the input type to **SDI/IP**. 2. Set the timeout before switching, [Input loss timeout](/beam/live-encoder/parameters/input/general). 3. Complete the [parameters](/beam/live-encoder/parameters/input/source#sdiip) in the **Primary** and **Secondary** tabs: - Network interface - Stream address - Protocol - IGMPv3 source filtering ## Configure SMPTE ST 2110 input

We recommend using the Mellanox ConnectX6 card to ingest SMPTE ST 2110 streams in Live Encoder. Without this card the ST 2110 is limited (no PTP support, no ST 2022-7 support, lower density, no UHD, audio level A only).

You can create SMPTE® ST 2110 input to ingest a source that is compliant with the SMPTE ST 2110 specification.\ You can optionally configure the input to use SMPTE ST 2022-7 (see [Configure SMPTE ST 2110 input with ST 2022-7 redundancy](/beam/live-encoder/configure/input/input-stream-source#configure-smpte-st-2110-input-with-st-2022-7-redundancy)). You can configure the SMPTE ST 2110 input either: - [by specifying an SDP file](/beam/live-encoder/configure/input/input-stream-source#configure-an-smpte-st-2110-input-with-sdp-files) that contains information about the SMPTE ST 2110 content, - or [by configuring the input to use NMOS IS-04 and IS-05](/beam/live-encoder/configure/input/input-stream-source#configure-an-smpte-st-2110-input-with-nmos) to provide that information. ## Configure an SMPTE ST 2110 input with SDP files When configuring a service with ST 2110 input, every input stream must contain an SDP File location. To configure an SMPTE ST 2110 input with SDP files, follow these steps: ### Create a service ### Configure the input parameters ``` 1. From the **Input** tab, set the **Type** to **SMPTE ST 2110**. 2. Leave the **Input redundancy** to **None**. 3. Complete the parameters in the **Primary** tab: - **Network interface** - Video input: enter a unique **SDP file location** for both sources and a different **Index** for each source. Both primary and secondary sources share a common SDP file but each source has a different index to select a stream within that SDP file. - Audio input: enter a unique **SDP file location** for both sources and a different **Index** for each source, then leave other fields unchanged. - VANC input: enter a unique **SDP file location** for both sources and a different **Index** for each source to add video metadata such as Closed Captions, Subtitles or SCTE-104. ``` ### Configure video encoding parameters ``` 1. Click the **Encoding** tab. 2. In the **Video encoding** section, click **Add** then go to the **Subtitle settings** section and tick the **Closed caption** checkbox. 3. Leave the other parameters unchanged. 4. Click **Ok** to validate. ``` ### Configure audio encoding parameters ``` 1. In the **Audio encoding** section, click **Add** then set the codec to **MPEG-1 Layer II**. 2. Leave the other parameters unchanged. 3. Click **Ok** to validate. ``` ### Configure the subtitle encoding parameters for path-through

If you added Teletext subtitles as VANC data input, you need to configure the Subtitle encoding section.

``` 1. If you want the Teletext subtitles to be passed-through, in the **Audio encoding** section, click **Add** then set the codec to **Pass-through**. 2. Select **Initial Teletext page** then enter **Language**. **Magazine** and **Page**. 3. Select **Teletext subtitle page** then enter **Language**, **Magazine** and **Page**. ![el encoding subtitles teletext passthrough](./images/el_encoding_subtitles_teletext_passthrough.png) *Example of subtitle encoding configuration Pass-through* 4. Click **Ok** to validate. ``` ### Configure the subtitle encoding parameters for DVB conversion

If you added Teletext subtitles as VANC data input, you need to configure the Subtitle encoding section.

``` 1. If you want the Teletext subtitles to be converted to BVB, in the **Audio encoding** section, click **Add** then set the codec to **DVB Subtitles**. 2. Enter **Magazine** and **Page**. ![el encoding subtitles teletext dvb](./images/el_encoding_subtitles_teletext_dvb.png) *Example of subtitle encoding configuration (DVB)* 4. Click **Ok** to validate. ``` ### Configure output parameters ``` 1. Click the **Output** tab then click the **Add an output** button. 2. Go to the **Output streams** section then click **Add**. 3. Enter the **IP address** and **Port**, then tick the video, audio and optionally VANC stream checkboxes. 4. Click **Ok**. ``` ### Save Click **Save and exit** to save your service configuration and go back to the **Services** page. ## Configure an SMPTE ST 2110 input with NMOS Before you start: - You need to provide an NMOS Registration and Discovery Server (RDS) that is NMOS IS-04 compliant, and an NMOS Client, which will interact with the NMOS RDS and NMOS Nodes. - NMOS IS-04 supports different modes of operation for the NMOS Node discovery, Live Encoder mandates discovery using Registered mode with multicast operation. When configuring a service with NMOS, the SDP file for each input stream is supplied by the NMOS Client, this means that you no longer need to specify the SDP file location. To configure an SMPTE ST 2110 input with NMOS, follow these steps: ### Create a service ### Configure the input parameters ``` 1. From the **Input** tab, set the **Type** to **SMPTE ST 2110**. 2. Leave the **Input redundancy** to **None**. 3. Tick the **NMOS enabled** checkbox. 3. Complete the parameters in the **Primary** tab: - **Network interface** - SDP files are greyed for each input stream since this information is supplied by the NMOS Client. ``` ### [Configure the video encoding parameters](/beam/live-encoder/configure/encoding/video-encoding) ### [Configure the audio encoding parameters](/beam/live-encoder/configure/encoding/audio-encoding) ### [Configure the output parameters](/beam/live-encoder/configure/output/configure-output) ### Save Click **Save and exit** to save your service configuration and go back to the **Services** page. ``` - The **Stats** \> **Monitoring** tab will display **NMOS Configured** when the NMOS **Enabled** checkbox is ticked. - In the **Stats** \> **Monitoring** tab, if the SDP file is available, you can click the `Download` icon button next to the **Download SDP file** row to download and view the content of the SDP file, otherwise **Not available** will be displayed and download will not be available. - Upon first start of the service, each input stream will have an alarm raised indicating “waiting for NMOS” that will be cleared once the NMOS client has configured each input stream.

The state is retained across restarts of the service.

``` ## Configure SMPTE ST 2110 input with ST 2022-7 redundancy The SMPTE ST 2022-7 standard specifies a form of input redundancy that aims at providing a resiliency against data loss at the IP packet level when two identical streams are received. When one stream loses a packet, the receiver picks out the lost data from the other stream. Senders may transmit duplicated streams by using the mechanisms of separate destination addresses or separate source addresses. This use case is an example of how to configure SMPTE ST 2110 input with ST 2022-7 redundancy. ### Create a service ### Configure the input parameters ``` 1. From the **Input** tab, set the **Type** to **SMPTE ST 2110**. 2. Set the **Input redundancy** to **SMPTE ST 2022-7**. 3. You can set the **Max Skew** which is the maximum expected delay (in ms) between the two sources. 3. Click **Add** to add a secondary source. e. Complete the parameters in the **Primary** and **Secondary** tabs: - **Network interface** - Video input: enter a unique **SDP file location** for both sources and a different **Index** for each source. **Note:** Both primary and secondary sources share a common SDP file but each source has a different index to select a stream within that SDP file. - Audio input: enter a unique **SDP file location** for both sources and a different **Index** for each source, then leave other fields unchanged. - VANC input: enter a unique **SDP file location** for both sources and a different **Index** for each source to add video metadata such as Closed Captions and SCTE-104. ``` ### Configure video encoding parameters ``` 1. Click the **Encoding** tab. 2. In the **Video encoding** section, click **Add** then go to the **Subtitle settings** section and tick the **Closed caption** checkbox. 3. Leave the other parameters unchanged. 3. Click **Ok** to validate. ``` ### Configure audio encoding parameters ``` 1. In the **Audio encoding** section, click **Add** then set the codec to **MPEG-1 Layer II**. Leave the other parameters unchanged. 2. Leave the other parameters unchanged. 3. Click **Ok** to validate. ``` ### Configure output parameters ``` 1. Click the **Output** tab then click the **Add an output** button. 2. Go to the **Output streams** section then click **Add**. 3. Enter the **IP address** and **Port**, then tick the video and audio stream checkboxes. 3. Click **Ok**. ``` ### Save Click **Save and exit** to save your service configuration and go back to the **Services** page. **Related information**\ [SMTPE ST 2110 parameters](/beam/live-encoder/parameters/input/source#smtpe-st-2110) ## SMPTE ST 2110 SDP file

The SDP file must conform to the Session Description Protocol as defined in Section 8 of the SMPTE ST 2110-10-2017 specification.

SDP file example: ```shell v=0 o=- 1443716955 1443716955 IN IP4 192.168.61.19 s=emsfp-a0-9b-b8 1-0-0 t=0 0 m=video 60020 RTP/AVP 96 c=IN IP4 239.0.2.22/64 a=source-filter: incl IN IP4 239.0.2.22 172.23.240.105 a=rtpmap:96 raw/90000 a=fmtp:96 sampling=YCbCr-4:2:2; width=1920; height=1080; exactframerate=30000/1001; depth=10; TCS=SDR; colorimetry=BT709; PM=2110GPM; SSN=ST2110-20:2017; TP=2110TPN; interlace; a=mediaclk:direct=0 a=ts-refclk:ptp=IEEE1588-2008:b8-59-9f-ff-fe-60-ff-c8:0 ``` ### ST 2022-7 configuration

The SDP file may specify duplicate RTP streams that are compliant to ST 2022-7, as defined in Section 8 of the ST2110-10-2017 specification.

SDP file example: ```shell v=0 o=- 123456 2 IN IP4 192.168.1.2 s=SMPTE ST2022-7 DUP streams t=0 0 a=recvonly a=group:DUP primary secondary m=video 50020 RTP/AVP 96 c=IN IP4 224.1.1.1/64 a=source-filter: incl IN IP4 224.1.1.1 192.168.1.2 a=rtpmap:96 raw/90000 a=fmtp:96 sampling=YCbCr-4:2:2; width=1920; height=1080; exactframerate=25; depth=10; TCS=SDR; colorimetry=BT709; PM=2110GPM; TP=2110TPN; SSN=ST2110-20:2017 a=ts-refclk:ptp=IEEE1588-2008:39-A7-94-FF-FE-07-CB-D0:127 a=mediaclk:direct=0 a=mid:primary m=video 50020 RTP/AVP 96 c=IN IP4 224.2.1.2/64 a=source-filter: incl IN IP4 224.2.1.2 192.168.1.2 a=rtpmap:96 raw/90000 a=fmtp:96 sampling=YCbCr-4:2:2; width=1920; height=1080; exactframerate=25; depth=10; TCS=SDR; colorimetry=BT709; PM=2110GPM; TP=2110TPN; SSN=ST2110-20:2017 a=ts-refclk:ptp=IEEE1588-2008:39-A7-94-FF-FE-07-CB-D0:127 a=mediaclk:direct=0 a=mid:secondary ``` ### Multi-channel audio For multi-channel audio, the SDP file can specify how audio channels are grouped. SDP file example: ```shell a=fmtp:97 channel-order=SMPTE2110.(ST,ST,ST,ST) - 4 Stereo pairs a=fmtp:97 channel-order=SMPTE2110.(51,ST) - 5.1 (6 channels) plus a stereo pair a=fmtp:97 channel-order=SMPTE2110.(M,M,DM,ST,ST) - mono, mono, dual mono, stereo, stereo ``` { /\* TODO: update links (especially ./parameters/) once MD files are created \*/} # Configure out-of-band metadata in input stream There are different types of out-of-band metadata: - The ESAM out-of-band signal interface allows an external module (typically a POIS) to send splice information to Live Encoder. The splice information is used by MediaKind Live Encoder to generate SCTE-35 signals and/or ad markers in the output. - The SCTE-104/IP out-of-band interface allows an external server to send SCTE-104 over IP messages to Live Encoder that converts them in SCTE-35 to enable stream conditioning actions. - The ID3 out-of-band allows extracting the Nielsen watermark from the input audio stream, translate it to ID3 tags and output it enabling the monitoring of the audience of each channel distributed over the Internet. To configure out-of-band metadata input stream, follow these steps:

In our example, we consider that you have selected an MPEG-2 TS input type.

1. From the **Input** tab, go to the **Metadata** section then click the **Add** button. The **Metadata selection** window displays. 2. Select a [**Type**](/beam/live-encoder/parameters/input/metadata#out-of-band-metadata). ![view metadata oob selection type](/_machine-assets/356bc9f637f77071a9e13496f75aec009ce866664ffb5b7e861887695732864f.png) _Example of configuration for SCTE-35 OOB metadata_

SCTE-35 OOB can be used for automation (Clock icon) or when there is no SCTE-35 in the input.

3. Enter the appropriate values for the following [parameter](/beam/live-encoder/parameters/input/metadata#scte-35-oob): { /\* NEEDS REVISION. The following seems to apply only to SCTE-35 OOB although these steps are not specific to SCTE-35 OOB \*/} - **Network name** - **Zone identity** - **ESAM server network interface** 4. Click **Ok** to save settings and return to the service edition options. The metadata stream is added to the list.

If you selected SCTE-35 OOB metadata, Live Encoder ESAM out-of-band signal interface is now accessible from http://<controller.ip>:8080/api/esam/LiveEncodings/<network_name>.

5. Save your settings to continue or click **Exit** to quit without saving. 6. You can [configure the metadata encoding](/beam/live-encoder/configure/encoding/metadata-encoding) and [add the metadata to the output stream](/beam/live-encoder/configure/output/configure-output#define-the-output-stream-composition). For ESAM out-of-band, the POIS should perform an HTTP POST request to the following URL: `http://:8080/api/esam/LiveEncodings/`\ where: - `controller.ip` is the [IP address used to connect to the Controller](/beam/web-interface/connection). - `network_name` is the unique acquisition point network name corresponding to the Live Encoder configuration to the input stream metadata.oob you create.
  • The body of the HTTP request should be an XML document containing a SignalProcessingNotification element as defined in the CableLabs Real-time Event Signaling and Management (ESAM) API (OC-SP-ESAM-API-I03-131025).
    • The acquisitionPointIdentity attribute of the SignalProcessingNotification element and/or the ResponseSignal element should match the Network name parameter.
    • If the ResponseSignal contains an AlternateContent element to trigger alternate content switching, the zoneIdentity attribute of the AlternateContent element should match the Zone identity parameter.
## Configure SCTE-35 out-of-band metadata input stream To configure SCTE-35 out-of-band metadata input stream, follow these steps:

In our example, we consider that you have selected an MPEG-2 TS input.

1. From the **Input** tab, go to the **Out-of-band streams** section then click the **Add** button. The **Metadata selection** window displays. 2. Set the [**Type**](/beam/live-encoder/parameters/input/metadata#out-of-band-metadata) to **SCTE-35 OOB**. ![view metadata oob selection type](/_machine-assets/356bc9f637f77071a9e13496f75aec009ce866664ffb5b7e861887695732864f.png) _Example of configuration for SCTE-35 OOB metadata_

SCTE-35 OOB can be used for automation ( Clock icon ) or when there is no SCTE-35 in the input.

3. Enter the appropriate value for the following [parameters](/beam/live-encoder/parameters/input/metadata#scte-35-oob): - **Network name** - **Zone identity** - **ESAM server network interface** 4. Click **Ok** to save settings and return to the service edition options. The metadata stream is added to the list.

If you selected SCTE-35 OOB metadata, Live Encoder ESAM out-of-band signal interface is now accessible from: http://<controller.ip>:8080/api/esam/LiveEncodings/<network_name>.

5. Save your settings to continue or click **Exit** to quit without saving. 6. You can [configure the metadata encoding](/beam/live-encoder/configure/encoding/metadata-encoding) and [add the metadata to the output stream](/beam/live-encoder/configure/output/configure-output#define-the-output-stream-composition). **Related information**\ [Configure blackout](/beam/live-encoder/configure/encoding/blackout-encoding) ## Configure SCTE-104/IP out-of-band metadata input stream To configure SCTE-104/IP out-of-band metadata input stream, follow these steps:

In our example, we consider that you have selected an MPEG-2 TS input.

1. From the **Input** tab, go to the **Out-of-band streams** section, click the **Add** button. **Metadata selection** window displays. 2. Set the [**Type**](/beam/live-encoder/parameters/input/metadata#out-of-band-metadata) to **SCTE-104 / IP OOB**. ![view metadata oob SCTE104 selection type](/_machine-assets/601ad10ca669bda22fa95fdd97b93b31133045b7a7c8b94708709814511262c1.png) _Example of configuration for SCTE-104/IP out-of-band metadata_ 3. Enter the appropriate value for the following [parameters](/beam/live-encoder/parameters/input/metadata#scte-104ip-oob): - **DPI PID index** - **SCTE-104 server network interface** (if not already configured in the **General** tab). 4. Click **Ok** to save settings and return to the service edition options. The metadata stream is added to the list. 5. Save your settings to continue or click **Exit** to quit without saving. 6. You can [configure the metadata encoding](/beam/live-encoder/configure/encoding/metadata-encoding) and [add the metadata to the output stream](/beam/live-encoder/configure/output/configure-output#define-the-output-stream-composition). # Configure source error management You can configure the encoder behavior in case of source error management. You can : - [Activate the switch on ES data loss](/beam/live-encoder/configure/input/source-error-management#configure-switch-on-es-data-loss) to backup the source if video or audio input is lost. - [Configure a slate (replacement image)](/beam/live-encoder/configure/input/source-error-management#configure-a-slate) that will be displayed if the input is not detected at start. - [Activate the fast recovery](/beam/live-encoder/configure/input/source-error-management#configure-fast-recovery) to recover the signal faster. ## Configure switch on ES data loss You can activate the **Switch on ES data loss** to backup the source if video or audio input is lost. In case of video or audio input loss of both sources, the option selected with frame freeze management applies (see [Configuring the video prefiltering](/beam/live-encoder/parameters/input/source-error-management)).

Works both in Active/Active and in Active/Passive redundancy mode.

1. Display services. 2. Click `Edit` icon to edit the service. The **General parameters** display. 3. Select the **Input** tab to display parameters. 4. In the **Source error management** section, tick the **Switch on ES data loss** check box. 5. Under **Delay**, specify the time before switching to the backup source when loss of video or audio occurs. See [Input - Source error management](/beam/live-encoder/configure/input/source-error-management). ## Configure a slate You can specify a slate (replacement image) that will be displayed if the input is not detected. 1. Display services. 2. Click `Edit` icon to edit the service. The **General parameters** display. 3. Select **Input** tab to display parameters. 4. In the **Source Error Management** section, tick the **Slate if no source at start** check box.

The image displayed is the same as the one configured for Media Processing > Video Processing > Freeze Frame Management section.

5. Select the **Default frame rate** for this slate. ## Configure fast recovery The **Fast recovery** option is activated by dafault. - When checked, the encoder will process the access units as soon as possible to recover the signal faster, though temporary macroblocks may appear. - When unchecked, the encoder will wait for the closest random access point (RAP), prioritizing video quality over signal recovery speed. 1. Display services. 2. Click `Edit` icon to edit the service. The **General parameters** display. 3. Select **Input** tab to display parameters. 4. In the **Source Error Management** section, tick or untick the **Fast recovery** check box depending on your needs. { /\* TODO: update links (especially Chunk) once MD files are created \*/} # Configure subtitle in input stream To configure the input stream subtitle parameters, follow these steps: 1. Display Services. 2. Click `Edit` icon to edit the service. 3. From the **Input** tab, scroll to **Input stream selection** > **Subtitle ID** and click **Add**. 4. [Set Subtitles options](/beam/live-encoder/parameters/input/subtitle), then click **OK** to save. Subtitles are automatically added to the **Encoding** tab in pass-through only. - You can [configure subtitle encoding parameters](/beam/live-encoder/configure/encoding/subtitles-encoding). - You can [configure subtitle burn-in](/beam/live-encoder/configure/encoding/subtitle-burnin-encoding). - You can [add subtitles to output streams](/beam/live-encoder/configure/output/configure-output#define-the-output-stream-composition). { /\* TODO: update links (especially ./parameters/) once MD files are created \*/} # Configure VANC in input stream To configure a VANC data input stream, follow these steps:

Only available with SMPTE ST 2110 input type.

1. Display services. 2. Click `Edit` icon to edit the service. The **General parameters** display. 3. Select **Input** tab. 4. Set the input type to **SMPTE ST 2110**. 5. Go to the **Sources** > **Input streams selection** > **VANC ID** section then click **Add** to configure the VANC data selection or click `Edit` icon to modify an existing one. 6. Enter the appropriate value for each \[VANC data parameter]\(./parameters/input#VANC data parameter). 7. Click **OK**. The ANC data input is added to the list of VANC data inputs. 8. Click **Save and continue** or **Save and exit** to save your changes. { /\* TODO: update links (especially ./parameters/) once MD files are created \*/} # Configure video in input stream To select a video stream, follow these steps: 1. Display services. 2. Click `Edit` icon to edit the service. The **General parameters** display. 3. Select the **Input** tab. 4. Go to the **Sources** > **Input streams selection** > **Video ID** section, then enter the appropriate value for each [video stream parameter](/beam/live-encoder/parameters/input/video-and-audio#video): - **Video PID** (PID is only configurable if **Input synchronization mode** is set to **PidLocked** mode.) - **Decoding capability** - In case of **SMPTE ST 2110** input type, **Stream Index** and **SDP File Location**. 5. In [IPTV export type](/beam/live-encoder/configure/encoding), you can delete the video input to get an audio-only service. 6. Click **Save and continue** or **Save and exit** to save your changes. - [Configure video processing](/beam/live-encoder/configure/media-processing/video-processing) - [Configure audio processing](/beam/live-encoder/configure/media-processing/audio-processing) - [True Motion](/beam/live-encoder/configure/media-processing/true-motion): Use True Motion to convert interlaced video to progressive video with motion-compensated de-interlacing and frame rate doubling for OTT delivery. { /\* TODO: update links (especially ./parameters/) once MD files are created \*/} # Configure the audio processing parameters To configure the audio processing parameters, follow these steps: 1. From the **Media Processing** tab, go to the **Audio processing** section. The audio processing parameters are displayed for each audio input. 2. Select the audio tab stream you want to configure then \[set the appropriate value for each parameter]. 3. You can [configure **Watermarking**](/beam/live-encoder/configure/media-processing/audio-processing#audio-watermarking). 4. You can [configure **DTMF extraction**](/beam/live-encoder/configure/media-processing/audio-processing#dtmf-extraction). 5. You can configure \[**Signal loss management replacement sound**]). 6. Click **Save and continue** or **Save and exit** to save your changes. ## Audio watermarking To configure audio watermarking, follow these steps: 1. From the **Media Processing** > **Audio processing** tab, go to the **Watermarking** section. 2. Select the watermarking type you want to activate by clicking `Edit` icon. 3. Activate **Insertion** and/or **Extraction** by ticking **Enable**. 4. [Set the appropriate value for each parameter](/beam/live-encoder/parameters/media-processing/audio-processing#watermarking). 5. Click **Ok** to validate. 6. Click **Save and continue** or **Save and exit** to save your changes. ## DTMF extraction To configure DTMF extraction, follow these steps: ### Create service Create a Live Encoding service. ### Configure the input parameters ``` 1. From the **Input** tab, set the **Type** to **MPEG-2 TS/UDP**. 2. Enter the primary source parameters: - **Network interface** - **Stream address** and **Port** 3. Click **Ok** to validate. 4. Go to the **Input streams selection** \> **Audio ID** section then click **Add** to define the audio stream. Enter the **PID** of the audio track with cue tones. You should get the following: ![el cfig input audio cuetone](./images/el_cfig_input_audio_cuetone.png) 5. Click **Ok** to validate. 6. Go to the **Metadata ID** section then click **Add** to define the metadata stream. - Set **Type** to **Cuetones**. - Select the audio input stream you just configured as **Source**. You should get the following: ![el cfig input metadata cuetone](./images/el_cfig_input_metadata_cuetone.png) 7. Click **Ok** to validate. ``` 3\. From the **Media Processing** > **Audio processing** tab, go to the **Cue Tones** section. The **Extract DTMF** checkbox should already be checked to enable DTMF extraction and cue tones detection. You can keep the default parameters. ``` ![el cfig processing cuetone](./images/el_cfig_processing_cuetone.png) ``` ### Configure the encoding parameters ``` 1. Go to the **Encoding** tab. 2. From the **Video encoding** section, click **Add** to add and configure the video stream. You can keep the default parameters or adjust them if needed. 3. Click **Ok** to validate. 4. From the **Audio encoding** section, click **Add** to add and configure the audio stream. - Set the **Codec** to **MPEG-1 Layer II**. - You can keep the default parameters or adjust them if needed. 5. Click **Ok** to validate. 6. If you go to the **Metadata encoding** section, you can see that it is already configured in **Pass-through**. ``` ### Configure the output ``` 1. From the **Output** tab, click the **Add an output** button then set the output parameters, especially the **Network interface**. 2. Go to the **Output stream** section then click **Add**. - Enter the multicast output **IP address** and **Port**. - Tick the metadata, audio and video streams. You should get the following: ![el cfig output stream cuetones](./images/el_cfig_output_stream_cuetones.png) 3. Click **Ok** to validate. ``` ### Save Click **Save and exit** to save and finalize your service configuration and go back to the **Services** page. ### Run the service [Assign a server to run the service](/beam/web-interface/services#assign-a-server-to-run-the-service). ### Check statistics Click `Chart` icon to display service details and to monitor the service. Specific cue tones statistics are displayed. # True Motion de-interlacing True Motion is MediaKind's motion-compensated de-interlacing technology. It converts interlaced video to progressive video using advanced de-interlacing, cross-scaling, and inverse telecine filters, and doubles the frame rate of interlaced sources to produce smooth content for OTT players. > When the input is progressive, enabling True Motion has no effect. Live Encoder does not double frames for progressive sources. ## Frame rate conversion For interlaced inputs, True Motion doubles the frame rate. For example, a 1080i30 input becomes a 1080p60 output.
Ingest OTT Configuration Output
1080i30 1080 True Motion 1080p60
1080p30 1080 True Motion 1080p30
1080i30 720p True Motion 720p60
1080p30 720p True Motion 720p30
## Benefits **For end users:** Video does not present interlace artifacts on progressive displays. **For operators:** Content is adapted to internet TV constraints without loss of fine detail. ## Enable True Motion 1. Open the service configuration and go to the **Media Processing** tab. 2. In the **Video Pre Filtering** section, enable the **True Motion** option. 3. Select the target OTT configuration (for example, **1080 True Motion** or **720p True Motion**). 4. Select **Save and continue** or **Save and exit** to apply the changes. # Configure the video processing parameters ## Video prefiltering To configure the video prefiltering parameters, follow these steps: 1. From the **Media Processing** tab, click the arrow at the right of the **Video Pre Filtering** section. The video prefilters are displayed. 2. You can [configure the video prefilters](/beam/live-encoder/parameters/media-processing/video-processing#video-prefiltering). 3. Click **Save and continue** or **Save and exit** to save your changes. ## Video adjustment To configure the video adjustment parameters, follow these steps: 1. From the **Media Processing** tab, click the arrow at the right of the **Video Adjustment** section. The video prefilters are displayed. 2. You can configure the [video adjustment parameters](/beam/live-encoder/parameters/media-processing/video-processing#video-adjustment). 3. Click **Save and continue** or **Save and exit** to save your changes. ## Video colorimetry To configure the video colorimetry parameters, follow these steps: 1. From the **Media Processing** tab, click the arrow at the right of the **Video Pre Filtering** section. The video prefilters are displayed. 2. You can configure the [video colorimetry parameters](/beam/live-encoder/parameters/media-processing/video-processing#video-colorimetry). 3. Click **Save and continue** or **Save and exit** to save your changes. ## Image on frame freeze To configure a default image that will be displayed in case of frame freeze, follow these steps: 1. From the **Media processing** tab, go to the **Freeze frame management** section. 2. Tick the **Activate** checkbox. 3. [Set the appropriate value for each parameter](/beam/live-encoder/parameters/media-processing/video-processing#freeze-frame-management). 4. Click **Save and continue** or **Save and exit** to save your changes. ## Video metadata To configure the video metadata parameters, follow these steps: 1. From the **Media Processing** tab, click the arrow at the right of the **Video Metadata** section. 2. You can select the **Timecode** source. 3. You can [insert this timecode in the SEI](/beam/live-encoder/parameters/encoding/video#stream-metadata-settings). 4. Click **Save and continue** or **Save and exit** to save your changes. ## Video watermarking 1. From the **Media Processing** > **Video processing** tab, go to the **Watermarking** section. 2. Tick the **Activate** checkbox then [set the appropriate value for each parameter](/beam/live-encoder/parameters/media-processing/video-processing#video-watermark-parameters). 3. Click **Ok** to validate. 4. Click **Save and continue** or **Save and exit** to save your changes. - [Manage the output](/beam/live-encoder/configure/output/manage-output) - [Configure the output ](/beam/live-encoder/configure/output/configure-output) { /\* TODO: update links (especially ./parameters/) once MD files are created \*/} # Configure the output ## Configure the output stream general parameters To configure the output stream general parameters, follow these steps: 1. From the **Output** tab, click `Edit` icon to edit the output parameters. The Output parameters display. 2. Configure the [**General parameters**](/beam/live-encoder/parameters/output#general-parameters). 3. With MPEG-2 TS output, configure the [associated parameters](/beam/live-encoder/parameters/output#general-mpeg-2-ts-parameters). 4. With DASH-IF CMAF Ingest, configure the [associated parameters](/beam/live-encoder/parameters/output#general-dash-if-cmaf-ingest-parameters). 5. Configure the [output streams](/beam/live-encoder/parameters/output#output-stream-parameters). 6. Click **Save and continue** or **Save and exit** to save your changes. ### Activate EBP on audio output 1. From the **Output** tab, click `Edit` icon to edit the output. 2. From the **General parmeters** section, unfold the **GOP signaling** dropdown menu to display possible values. 3. Select either **EBP based** or **ALD based** to display **EBP on audio** checkbox. ![screen output parameters ebp on audio mfvp el](/_machine-assets/469a3be2bffe7ee1071ff418969230d3d49501dab82088b11b4114df967df174.png) 4. Tick the checkbox to activate **EBP on audio**, then click **OK**. ![screen output parameters ebp on audio box mfvp el](/_machine-assets/a0918b5df1bd7630d717a57a7e401c3bddefdcd85e9f172c68f9a8894b44f9ad.png) ## Configure the output stream MPEG-2 TS parameters To configure the output stream MPEG-2 TS parameters, follow these steps: 1. From the **Output** tab, click `Edit` icon to edit the output. 2. Go to the **Common MPEG-2 TS parameters** section. The MPEG-2 TS parameters are displayed. 3. Enter the appropriate values for each [MPEG-2 TS parameter](/beam/live-encoder/parameters/output#mpeg-2-ts-common-parameters). 4. You can [specify the streams that will be included in the output stream](/beam/live-encoder/configure/output/configure-output#define-the-output-stream-composition)). 5. Click **Save and continue** or **Save and exit** to save your changes. ## Create output streams Before you start: ensure input streams are configured. 1. From the **Output** tab, click `Edit` icon to edit the output. 2. Go to the **Output streams** section then click the **Add** button. Output stream parameters are displayed. ![screen output parameters blank mfvp el](/_machine-assets/e94bfa37be951c7e1ac59dbef3f1167f34470256e8d52cb9f6d56930ad4096d9.png) 3. Configure settings and select streams. 4. [Activate FEC](/beam/live-encoder/configure/output/configure-output#activate-fec-on-existing-output-streams) to display additional FEC options. 5. [Link the output to a predefined subset](/beam/live-encoder/configure/output/configure-output#link-an-output-stream-to-a-predefined-subset) to synchronize streams or to distribute the streams across multiple servers. 6. Select any video, audio or subtitle [streams to add to the output](/beam/live-encoder/configure/output/configure-output#define-the-output-stream-composition). 7. Click **Ok** to save. ### Define the output stream composition You can specify the composition of the output stream by selecting the video, audio and private streams that will be sent to the output. Before you start: ensure input stream configurations are set. 1. From the **Output** tab, click `Edit` icon to edit the output. 2. Go to the **Output streams** section then click `Edit` icon to edit the output stream. ![screen output parameters blank mfvp el](/_machine-assets/e94bfa37be951c7e1ac59dbef3f1167f34470256e8d52cb9f6d56930ad4096d9.png) _Example of output stream configuration_ 3. Tick the check boxes to select the streams to include in the output. Available streams depend on configured Inputs, Processing, and Encoding options. - video - audio - subtitle - metadata - etc.

By default, one transport stream is defined using the first video stream and the first audio stream.

4. Click **Ok** to confirm. The output stream configuration is displayed in the output stream IP address and stream composition. 5. Click **Save and continue** or **Save and exit** to save your changes. ### Activate FEC on existing output streams ```

Only available with MPEG-2 TS/RTP transport protocol.

``` 1. From the **Output** tab, click `Edit` icon to edit the output. 2. Go to the **Output streams** section then click `Edit` icon to edit the output stream. 3. Tick the **FEC** checkbox to activate. Additional FEC parameters display. 4. Enter [FEC parameters](/beam/live-encoder/parameters/output#output-stream-parameters) 5. Click **Ok** to save. ### Link an output stream to a predefined subset You can link an output stream to a subset. Once linked, these subsets can be used to synchronize streams or to distribute the streams across multiple servers. Before you start: ensure [server subsets](/beam/live-encoder/configure#create-subset-variants) are created. 1. From the **Output** tab, click `Edit` icon to edit the output. 2. Go to the **Output streams** section then click `Edit` icon to edit the output stream. 3. For the **Subset** parameter select an existing preset in the drop-down list. The output stream is linked to the selected subset. 4. Click **Ok** to save. ## Configure a DASH-IF CMAF output DASH-IF CMAF Ingest is a protocol for transport of fragmented MP4 in CMAF container format between Live Encoder and a Packager. To configure a DASH-IF CMAF output, follow these steps: 1. From the **Encoding** tab, go to the **Video** > **Gop settings** section then enter a value for **Low latency fragment(s) per GOP** (see [GOP settings](/beam/live-encoder/parameters/encoding/video#gop-settings)). 2. From the **Output** tab, create or edit an existing output. - In the **General parameters** section, set the **Transport protocol** to **DASH-IF CMAF INGEST**, then define the associated parameters (see [Output general parameters](/beam/live-encoder/parameters/output#general-parameters)). - In the **MP4 general parameters** section, set the number of **GOPs per segment**. You can optionally enable Low latency and Unix epoch relative timestamps. Fragment(s) per GOP value is retrieved from the Low latency fragment(s) per GOP field that you previously defined. (See [DASH-IF CMAF parameters](/beam/live-encoder/parameters/output#general-dash-if-cmaf-ingest-parameters)) - The **Tracks** section displays all the streams configured in the **Encoding** tab. [You can change their track ID and add an optional label](/beam/live-encoder/parameters/output#tracks). - In the **Output groups** section, select the tracks to be added in the output (see [Defining the output stream composition](/beam/live-encoder/configure/output/configure-output#define-the-output-stream-composition)). # Manage the output ## Add an output You can create several outputs. To create an output you can either: - [Create a new one](/beam/live-encoder/configure/output/manage-output#create-a-new-output-from-scratch). - [Duplicate an existing one](/beam/live-encoder/configure/output/manage-output#duplicate-an-existing-output). ### Create a new output from scratch When connecting for the first time or if you want to add an output, you can create a new one from scratch. To create an output, follow these steps: 1. From the **Output** tab, click the **Add** button. A new output section is created. 2. [Edit the output](/beam/live-encoder/configure/output/manage-output#edit-an-output). 3. Click **Ok** to save your changes. The new output is added in the output tab. ### Duplicate an existing output You can create an output by duplicating an existing one. To duplicate an output, follow these steps: 1. Click the duplicate icon `Clone` icon in the top right corner of the reference output. A new output section is created with the same parameters as the reference output. 2. If needed, you can [edit the output](/beam/live-encoder/configure/output/manage-output#edit-an-output) 3. Click **Ok** to save your changes. The new output is added in the output tab. ## Edit an output Before you start, ensure an output exists. If no output exists, see [Add an output](/beam/live-encoder/configure/output/manage-output#add-an-output). 1. From the **Output** tab, click **Output** to open the tab and display outputs. 2. Click `Edit` icon to display parameters and edit the output. The output parameters display.

Depending on your configuration type and settings, additional parameters may display.

3. [Edit the general parameters](/beam/live-encoder/configure/output/configure-output#configure-the-output-stream-mpeg-2-ts-parameters). 4. [Configure the MPEG-2 TS parameters](/beam/live-encoder/configure/output/configure-output#configure-the-output-stream-mpeg-2-ts-parameters). 5. [Select the streams to include in the output.](/beam/live-encoder/configure/output/configure-output#define-the-output-stream-composition). 6. Click **Ok** to save your changes. The new output is added in the output tab. ## Delete an output

If deleted, the stream is automatically removed from any outputs.

From the **Output** tab, click `Delete` icon in the top right corner of the selected output stream. A message asks you to confirm the deletion. # Create a new service To create a new service, follow these steps: 1. From the **Services** page, click **Add service** then select **Live Encoding**. 2. Enter a service name. 3. You can [create the service from an existing template](/beam/live-encoder/create-service#create-a-service-from-a-template). 4. Start configuring or completing the service parameters: - **Input** (see [Configure the input](/beam/live-encoder/configure/input)) - **Media Processing** (see [Configure the media processing](/beam/live-encoder/configure/media-processing/video-processing)) - **Encoding** (see [Configure the encoding parameters](/beam/live-encoder/configure/encoding)) - **Output** (see [Configure the output](/beam/live-encoder/configure/output/configure-output))

If you create a service from a template, some parameters are already configured. Enter any missing parameters (displayed in orange) and, if needed, modify the predefined ones.

## Create a service from a template Templates are a set of saved parameters that are based on an existing service configuration. You can create a new service from a template to automatically apply its configuration. Before you start: ensure you have previously created one or more template(s). 1. From the **Services** page, click **Add service** then select **Live Encoding**. 2. In the **Template** drop-down list, select a template. Template parameters display. Missing parameters appear in orange. 3. Edit the missing parameters (in the **General**, **Input** and **Output** tabs) and, if needed, modify the predefined parameters. # Leaky bucket concept Leaky bucket is a flow-control mechanism designed to reduce the effect of the inevitable variability in input data streams as they are "injected" into communication networks. The leaky bucket algorithm performs the following functions: - It controls what the encoder can inject into the network. - It prevents the data "bucket" from overflowing by automatically regulating the bit rates in the event that the encoder generates too much data or very complex data. - It prevents “burstiness” in the input stream, ensuring a smooth, even data flow. ![leaky bucket](/_machine-assets/89310f4a8423364242c4573eaa4d19de26f50f1f00947d23696121762025dd83.jpg) _Leaky bucket algorithm_ { /\* TODO: update links (especially ./parameters/) once MD files are created \*/} # Monitor service statistics You can retrieve and monitor detailed statistics information on a service.

The Chart icon icon is only accessible when a Live encoding servive is associated to a server and then running.

1. From the **Services** page, identify the service that you want to monitor and click the related `Chart` icon icon. The **Statistics** page displays. 2. You can navigate between three tabs: - [**Media info**](/beam/live-encoder/monitor-statistics#media-info) - [**Input monitoring**](/beam/live-encoder/monitor-statistics#input-monitoring) - [**Outputs**](/beam/live-encoder/monitor-statistics#outputs).

You can customize the information displayed such as activating or deactivating the auto refresh by clicking the Auto refresh button.

## Media info From the **Media info** tab, you can view the following information for each program: - Video statistics - Audio statistics - Preview of the video - List of other available programs ![MFVP EL service statistics mediainfo](/_machine-assets/ca8d164a2c596a68e85639e6a76062436b1e188f057c9fa536c8561e948dc9b0.png) _Example of Service Statistics>Media info_ ## Input monitoring From the **Input monitoring info** tab, you can view the following information: - Quality indicators (ETR290) - RTP quality indicators - FEC quality indicators - Input CC Errors - Splice schedule ![MFVP EL service statistics input](/_machine-assets/19bbdf2199dce329229b4e4fa68081cf79129c25dbf30a44cdda657cb3180f96.png) _Example of Service Statistics>Input monitoring_ ## Outputs From the **Outputs** tab, you can view the following information for each output: - PID number - Media type (audio, video, subtitles, metadata) - CC errors - Information ![MFVP EL service statistics output](/_machine-assets/f87062f31522ae6131db7f25a919bcd0feb272f045ee47a725bf58f3fe9459dd.png) _Example of Service Statistics>Output monitoring_ - Once you have configured an automated blackout and started a service, you can manually [activate or deactivate the blackout](/beam/live-encoder/configure/encoding/blackout-encoding#manually-activate-or-deactivate-a-blackout). - Once you have activated and configured the [Switch to CBR option](/beam/live-encoder/parameters/encoding/video#switch-to-cbr-parameters), and started the service, you can manually switch from Statmux to CBR (**Switch to CBR** button) or switch back from CBR to Statmux (**Switch to Statmux** button). ![EL service statistics output switch to CBR](/_machine-assets/e9585a8571bb82122831c13660c6590b80461df588986156b0850075d09d4f40.png) _Example of Service Statistics>Outputs with Switch to CBR option activated_ - [Encoding](/beam/live-encoder/parameters/encoding): Pages in the Encoding section. - [General](/beam/live-encoder/parameters/general) - [Input](/beam/live-encoder/parameters/input): Pages in the Input section. - [Media Processing](/beam/live-encoder/parameters/media-processing): Pages in the Media Processing section. - [Lineup](/beam/live-encoder/parameters/lineup) - [Output](/beam/live-encoder/parameters/output) - [General](/beam/live-encoder/parameters/encoding/general) - [Video](/beam/live-encoder/parameters/encoding/video) - [Audio](/beam/live-encoder/parameters/encoding/audio) - [Subtitle](/beam/live-encoder/parameters/encoding/subtitle) - [Metadata](/beam/live-encoder/parameters/encoding/metadata) - [Blackout](/beam/live-encoder/parameters/encoding/blackout) - [Logo insertion](/beam/live-encoder/parameters/encoding/logo-insertion) # Audio encoding parameters
Parameter Description
Codec Specify the codec for the audio encoding. 'Passthrough' is not supported when audio input is uncompressed. For PCM or Dolby E Passthrough, select 'SMPTE302 / Dolby E Passthrough'.
## Pass-through specific parameters
Parameter Description
Insert audio frames on signal loss Generate audio frames according to the input loss management configured in Media processing tab (silence, 1kHz tone) when the input source is lost.
Note: If you activate this option, associated monitoring statistics are available from the Service statistics (see example below).
Glitch supression Only available if Insert audio frames on signal loss is checked.
Repeat 3 audio frames before enabling input loss audio frames generation.
Generate audio frames if no source at start Only available if Insert audio frames on signal loss is checked.
If the audio service is missing at startup, generate audio frames according to the input loss management configured in Media processing tab (silence, 1kHz tone). Frames may be encoded in a different codec from the real audio.
Note: Applies to both use cases where Live Encoder is configured either with SDI or as IP input.
![el encoding audio passthrough silence stats](/_machine-assets/a5fa873c6f90ba400a23e4720e21d6d7817b386417bb7abdb9ca8d03d43249dc.png) _Example of audio silence generation statistics_ ## SMPTE-302 / Dolby E Pass-through additional parameters
Parameter Description
Data Width Data width of AES audio sample to be encoded.
Possible values: Follow input, 16-bit, 20-bit, or 24-bit
## MPEG-1 Layer II, Dolby Digital, Dolby Digital Plus, AAC, HE-AAC, HE-AAC v2 parameters
Parameter Description
Watermarking Type of watermarking insertion to use
Profile Profile to use with AAC codec
Channels mode Number of audio channels in the encoded audio track
Bit rate Bandwidth used to encode the audio stream
Sampling rate Number of audio samples per second defined in Hz
Frame rate Frame rate as defined in video input
Blackout This blackout configuration will be applied to the related audio/video/subtitles stream.
## Dolby Digital additional parameters
Parameter Description
Dialog normalization Metadata parameter that controls playback gain.
Possible values: Auto or, from -1 dB to -31 dB. Auto means that no processing will be done on the input.
Dolby Surround mode Decoders can use this flag to automatically switch on Pro Logic decoding.
DRC Line Mode Profile The Dynamic Range Control restricts the signal's absolute peak level for a decoder using the line mode.
DRC RF Mode Profile The Dynamic Range Control restricts the signal's absolute peak level for decoder using the RF mode.
DC highpass filter A DCblocking 3Hz highpass filter applied on the main Dolby channel. Used to remove DC offsets in the program audio. Only switch off in exceptional circumstances.
**Related information**\ [Configure the audio encoding parameters](/beam/live-encoder/configure/encoding) # Blackout parameters ## General parameters
Parameter Description
Tracks SCTE-35 Select tracks to trigger blackout.
Note: Options for this parameter depend on metadata configured in Input.
Trigger Select the command to trigger blackout.
Possible values:
- spliceOut/SpliceIn: blackout triggered on reception of an SCTE 35 splice out, end of blackout on splice in.
- webDeliveryAllowedFlag: blackout triggered on reception of an SCTE 35 containing a web delivery flag set to false.
- alternateContent: alternate content triggered on reception of an SCTE 35 message.
Timeout Maximum duration of the blackout. If 0, there will be no maximum duration set.
Note: If no "alternate content off" command is received, the blackout will be removed at the end of this timeout.
Range: From 0 to 60000 ms
## Specific webDeliveryAllowedFlag & spliceOutSpliceIn parameters
Parameter Description
Image URL Note:
- Image URL can be a web URL (http://server/image, https://server/image) or a local file defined with an absolute path (such as /directory/filename.png).
- Authorized file types are .gif, .png or.jpg.
## Specific alternateContent parameters
Parameter Description
Default image URL Enter the path to the default alternate content to display. If empty, a black frame is used.
Note: Default image URL can be empty, but if an alternate content image with an Id and Image URL is added, both fields are mandatory.
Id Define an ID used to identify the alternate content to apply. This ID should be passed in the SCTE35 message triggering the blackout condition. If no alternate content is configured, the default image is used.
Image URL Enter the path to the alternate content to display. The default image is used if no alternate content is configured.
Note:
- Image URL can be a web URL (http://server/image, https://server/image) or a local file defined with an absolute path (such as /directory/filename.png).
- Authorized file types are .gif, .png or.jpg.
# General parameters
Parameter Description
Export type Select either IP TV or Internet TV export type.
# Logo insertion
Parameter Description
Image URL The path to the replacement image (GIF, PNG or JPEG file).
Syntax can be either HTTP://path or /path.
Placement Select the image placement.
Possible values: Top left corner, Top right corner, Bottom left corner, or Bottom right corner
Horizontal gap Position of the image in relation to the screen corner.
Vertical gap Position of the image in relation to the screen corner.
Size The percentage of the image height.
# Metadata encoding parameters
Parameter Description
Codec Select the codec used to refine the stream object type.
Use POIS Only available with Conditioning.
Tick this checkbox if you want to define a POIS server.
PTS insertion compensation Only available with Conditioning.
Enable pts insertion compensation.
If checked, the pts_adjustment of an SCTE-35 event will be adjusted so that the splice_time + pts_adjustment corresponds to the PTS of the video frame, as illustrated below:
pts insertion compensation
Note: Arm time is the time that separates the SCTE-35 event from its execution.
Recover conditioning state if failover If 'By Controller' is selected, this option enables to keep the conditioning status after an encoder failover without the need of any external system.
## POIS parameters
Parameter Description
Delay If metadata stream is SCTE35, a delay adjusts the trigger time value.
Possible values: From 30000 to 60.000
URL URL for the POIS (Placement Opportunity Information Service) (if any)
Network interface Name of the network interface used to communicate with the POIS
Network name ID shared with the POIS for the current channel
Zone identity The area ID for this channel distribution. Commonly used for regionalization.
## Tissot clock metadata ID3 parameters
Parameter Description
Period Target frequency of sending encoded metadata.
If higher than the key frame period, encoded metadata will only be present on key frames.
Possible values: From 0 to 65535 ms
## Timecode ID3 parameters
Parameter Description
Origin Type of the timecode used to filter SMPTE 2038 input.
Period Target frequency of the Timecode ID3 in ms.
Possible values: From 0 to 65535 ms
# Subtitle encoding parameters ## General parameters
Parameter Description
Codec Select the codec used to convert the subtitles. DVBTTML and DASHIFTTML are only valid when ITV export type is used. Closed caption CEA 608 is only valid when both IPTV export type and 25i/50p to 29.97i/59.94p frame rate conversion are used.
Blackout This blackout configuration will be applied to the related audio/video/subtitles stream.
## Teletext subtitles ### Teletext Pass-through
Parameter Description
Codec Select the codec used to convert the subtitles, in this case, Pass-through.
Override subtitle language in the teletext descriptor Override language information (ISO639 language triplet) of a selected subtitle. The subtitle selected by the magazine and page should be already present in the descriptor
### SDI Teletext Pass-through

Only available with SDI and SDI/IP input.

Parameter Description
Codec Select the codec used to convert the subtitles, in this case, Pass-through.
Adjust display height Only available with DVB-Subtitles input subtitles.
Adjust the display height for NTSC resolution. If not checked, optimized for PAL resolution.
#### Teletext descriptor
Parameter Description
Language Input language to encode in ISO 639 format (3letter code, lowercase). If not present in the input stream, the subtitles will not be transcoded.
Magazine 1digit magazine number (18) used to identify the Teletext service.
Page Page number (099) used to identify the Teletext service.
Field Closed caption field as defined by the standard. Only one of each value is allowed.
### DVB-Subtitles with Teletext subtitles input
Parameter Description
Codec Select the codec used to convert the subtitles, in this case, DVB-Subtitles.
Magazine 1digit magazine number (18) used to identify the Teletext service.
Page Page number (099) used to identify the Teletext service.
### DVB-TTML with Teletext subtitles input

Only available with Teletext input subtitles and Internet TV export type.

Parameter Description
Codec Select the codec used to convert the subtitle, in this case, DVB-TTML.
Magazine 1digit magazine number (18) used to identify the Teletext service.
Page Page number (099) used to identify the Teletext service.
Profile Specify the DVB TTML processor profile.
Purpose Purpose of the subtitle service.
Suitable for TTS Boolean value that indicates whether the subtitles are suitable for texttospeech (TTS). If the value is not set, this means unknown suitability.
Forced language Overwrites the language of the audio track. If not set the original language is kept.
Format: 3 alphanumeric characters
### DASH-IF-TTML with Teletext subtitles input

Only available with Teletext input subtitles and Internet TV export type.

Parameter Description
Codec Select the codec used to convert the subtitle, in this case, DASHIF-TTML.
Magazine 1digit magazine number (18) used to identify the Teletext service.
Page Page number (099) used to identify the Teletext service.
Profile Specify the DASHIF TTML processor profile.
Role Role of the subtitle service.

  • Main: Programme uses subtitles to translate foreign soundtrack or parts of soundtrack into preferred language.

  • Alternate: Subtitles providing a translation of the main audio of the programme.

  • Commentary: Subtitles providing additional information for the programme.

  • Forcehardofhearing: Subtitles for the hard of hearing in the same language as the programme.

  • Subtitle: Generate subtitles.
Forced language Overwrites the language of the audio track. If not set the original language is kept.
Format: 3 alphanumeric characters
### DVB-TTML with CEA-608/CEA-708 Closed Captions input

Only available with CEA-608/CEA-708 Closed Captions input subtitles and Internet TV export type.

Parameter Description
Codec Select the codec used to convert the subtitle, in this case, DVB-TTML.
Profile Specify the DVB TTML processor profile.
Purpose Purpose of the subtitle service.
Suitable for TTS Boolean value that indicates whether the subtitles are suitable for texttospeech (TTS). If the value is not set, this means unknown suitability.
Forced language Overwrites the language of the audio track. If not set the original language is kept.
Format: 3 alphanumeric characters
Closed caption service Specify the CEA608 or CEA708 service number.
Possible values for CEA-608: cc_1, cc_2, cc_3 and cc_4.
Possible values for CEA-708: service_1, service _2, service _3 and service _4
### DASHIF-TTML with CEA-608/CEA-708 Closed Captions input

Only available with CEA-608/CEA-708 Closed Captions input subtitles and Internet TV export type.

Parameter Description
Codec Select the codec used to convert the subtitle, in this case, DASHIF-TTML.
Profile Specify the DASHIF TTML processor profile.
Role Role of the subtitle service.

  • Main: Programme uses subtitles to translate foreign soundtrack or parts of soundtrack into preferred language.

  • Alternate: Subtitles providing a translation of the main audio of the programme.

  • Commentary: Subtitles providing additional information for the programme.

  • Forcehardofhearing: Subtitles for the hard of hearing in the same language as the programme.

  • Subtitle: Generate subtitles.
Forced language Overwrites the language of the audio track. If not set the original language is kept.
Format: 3 alphanumeric characters
Closed caption service Specify the CEA608 or CEA708 service number.
Possible values for CEA-608: cc_1, cc_2, cc_3 and cc_4.
Possible values for CEA-708: service_1, service _2, service _3 and service _4
### Closed caption CEA 608

Only available with Teletext subtitle input, IPTV export type and 25i/50p to 29.97i/59.94p frame rate conversion.

Parameter Description
Codec Select the codec used to convert the subtitles, in this case, Closed caption CEA 608.
Magazine 1digit magazine number (18) used to identify the Teletext service.
Page Page number (099) used to identify the Teletext service.
Field Closed caption field as defined by the standard. Only one of each value is allowed.
## DVB-Subtitles Pass-through
Parameter Description
Codec Select the codec used to convert the subtitles, in this case, Pass-through.
Forced language Overwrites the language of the audio track. If not set the original language is kept..
Adjust display height Only available with DVB-Subtitles input subtitles.
Adjust the display height for NTSC resolution. If not checked, optimized for PAL resolution.
## DVB-Subtitles with SCTE-27 subtitles input
Parameter Description
Codec Select the codec used to convert the subtitles, in this case, DVB-Subtitles.
Forced language Overwrites the language of the audio track. If not set the original language is kept..
## DVB-Teletext with ARIB B24 subtitles input You should define the following parameters: - Codec used to convert the subtitle, in this case, **DVB-Teletext**.| - [Selected stream](/beam/live-encoder/parameters/encoding/subtitle#selected-stream): Selection of the stream to encode in the input subtitle. One subtitle encoding section must be defined per language. - [Teletext encoding](/beam/live-encoder/parameters/encoding/subtitle#teletext-descriptor): Configuration of the encoding of the teletext stream. - [Teletext descriptor](/beam/live-encoder/parameters/encoding/subtitle#teletext-encoding): Configuration of the descriptor of the teletext stream. ### Selected stream
Parameter Description
Language Input language to encode in ISO 639 format (3letter code, lowercase). If not present in the input stream, the subtitles will not be transcoded.
### Teletext encoding
Parameter Description
Magazine 1digit magazine number (18) used to identify the Teletext service.
Page Page number (099) used to identify the Teletext service.
### Teletext descriptor
Parameter Description
Language Input language to encode in ISO 639 format (3letter code, lowercase). If not present in the input stream, the subtitles will not be transcoded.
Magazine 1digit magazine number (18) used to identify the Teletext service.
Page Page number (099) used to identify the Teletext service.
Field Closed caption field as defined by the standard. Only one of each value is allowed.
**Related information**\ [Configure subtitle encoding](/beam/live-encoder/configure/encoding/subtitles-encoding) ## Subtitle burn-in configuration parameters
Parameter Description
Burn-in Configuration of the subtitle to be used for burnin in the video. Format available for burnin: DVBsubtitles, Teletext.
**Related information**\ [Configure subtitle burn-in](/beam/live-encoder/configure/encoding/subtitle-burnin-encoding) # Video encoding parameters ## General parameters
Parameter Description
Rate control Define how the bitrate is managed for this stream. Trick Play only applies to CBR.Possible values: VBR, CBR, CVQ (Constant Video quality), Statmux.
- With CBR (Constant bit rate), you can stream content over a limited bit rate channel such as a network. The output stream fits in one bit rate, which you specify as a parameter. Constant bit rate means that the bit rate is constant according to the leaky bucket concept.
- For more information on Statmux, see Statmux, Statistical rate control.
Note: In case of H.264, the stream remains compliant with the normative HRD.
Trick play Only available with CBR rate control.Provides a low frame rate video stream that can be used for Trick play. This option requires CBR and is not compatible with shared encoding.
Low delay encoding Only available with CBR rate control.This mode decreases latency by forcing the encoder to use a simplified codec analysis. The video quality is impacted, and only CBR mode is allowed.
Note: If activated, Buffer duration in Codec settings section is limited to Short and Custom values.
CVQ mode Only available with CVQ rate control.
Define how to manage bandwidth in CVQ rate mode.
Select Average bit rate to define Target bit rate in kbps. While keeping homogeneous quality, this mode guarantees the Target bitrate over a long period of time (several hours).
Select Quality level to define a Target quality using a decimal number on a scale from 1.0 to 5.0.
Target quality Only available with CVQ rate control.
Define the Target quality of the CVQ encoding using a decimal number on a scale from 1.0 to 5.0. 5.0 is the highest quality.
Pool name Only available with Statmux rate control.
Each statmux stream is included in a pool that defines the global multiplex bitrate. This parameter defines the pool this stream must be attached to.
Service name in profile name Service name is in profile name.
Minimum bit rate Only available with Statmux rate control.
In statmux each stream is encoded in VBR. Minimum bit rate defines the lowest bit rate limit.
Note: This bit rate can be changed on-the-fly.
Maximum bit rate Only available with Statmux or VBR rate control.
In statmux, VBR or CVQ mode, each stream is encoded with variable bitrate. Maximum bit rate defines the highest bit rate limit.
Note: This bit rate can be changed on-the-fly.
Target bit rate Bandwidth used to encode the video stream.
Possible values: From 100 to 60000 kbps
Note:
- Video bit rate corresponds to "raw" video bit rate, and does not include bit rate overhead due to encapsulation (such as PES headers, MPEG-2 TS headers).
- This bit rate can be changed on-the-fly.
Resolution Define the output size of each image (length x height).
Note: Resolutions are sorted by the total number of pixels per frame.
You can either choose a value from the drop-down list or enter a custom resolution.
Codec The different codecs (MPEG2, H.264, HEVC, JPEG XS) can be used to encode the content. Select a codec and its profile for each video stream.
Video quality mode Different tradeoffs between video quality and density. UP! and UP!+ provide the highest video quality. With Adaptive quality mode the codec leverages ACT (AI Compression Technology) to ensure the best video quality while using all the available resources to process the channel. Adaptive (ACT) is an option if the service runs on constrained resources (like a Kubernetes POD with limited vCPU resources).
Note:
- The list of available video quality modes depends on codec, rate control, export type and resolutions values.
- For Internet TV, output a mix of these presets is recommended to optimize both the VQ and the density.
Stream conditioning Conditions stream encoding based on the metadata stream.
Note: You can select several SCTE-35 streams (either in-band or out-of-band) to condition video streams.
Blackout This blackout configuration will be applied to the related audio/video/subtitles stream.
Chunking policy Select the policy to apply when a splice occurs (ad insertion, ad replacement, blackout management, etc).
The policy applies for both stream conditioning and blackout to ensure relevant chunk sizing.

  • Distribute: chunks before the splice point are adapted to have the same duration. Subsequent GOP boundaries are modified.

  • Merge: chunks before or after the splice point are merged. Subsequent GOP boundaries are unchanged.
chunking distribute
Chunking policy: Distributechunking merge
Chunking policy: Merge
### Switch to CBR parameters

Only available when Rate control is set to Statmux.

Parameter Description
Switch to CBR Enable switching from Statmux to CBR based on SCTE35 splice triggers.The switch relies on SCTE-35 splice commands: a Splice out is used to exit Statmux rate control and switch to CBR then a Splice in is used to switch back to Statmux.
If enabled and configured, when you start the service new buttons are available in the Services > Statistics > Outputs menu:
- Switch to CBR to manually switch from Statmux to CBR.
- Switch to Statmux to manually switch back from CBR to Statmux.
Constant bit rate Bandwidth used to encode the video stream
Triggering stream Select the SCTE35 metadata stream used to trigger the switch between Statmux and CBR. Note that SCTE35 metadata stream codec must be set to conditioning.
Timeout Timeout in milliseconds for switching back to Statmux. Disabled if not filled.
Possible values: from 1s to 24h
## Statmux advanced parameters
Parameter Description
Stream priority Ability to set the priority (or weight) of a service when it joins a statmux group.
'Normal' does not change the default behavior of the statmux algorithm.
'High' and 'Highest' will distribute more bandwidth to the video stream than normal computation of the statmux algorithm.
'Low' and 'Lowest' will distribute less bandwidth in order to favor the other streams of the group.
## Codec settings
Parameter Description
Video quality experience Select the codec configuration for subjective or objective measurement. If you have a proprietary probe then select MSSSIM finetuning.The last algorithms integrated in our codec improve the subjective video quality: the quality of experience of the end user is increased. However, these specific fine-tuning in the encoder may decrease objective scores measured by automatic metrics such as PSNR, SSIM, MS-SSIM. If the customer wants to evaluate the video quality with one of these metrics, he can select a fine-tuning of the encode to keep high scores. If the customer uses proprietary probes, we recommend choosing MS-SSIM.
Possible values: Objective: Human visual fine-tuning or Subjective: SSIM fine-tuning, MS-SSIM fine-tuning, or PSNR fine-tuning
Buffer duration Define the size of the video buffer. Delay increases with buffer size. Encoding quality improves with buffer size. The default values offered correspond to: Short = 500ms, Standard = 1000ms, Long=2000ms. Customizable value in ms is also an option.
Note: The video buffer is the standard VBV (Video Buffering Verifier), it guarantees the encoded stream doesn't overflow or underflow the decoder's buffer.
Possible values: Short, Standard, Long, or Custom
- If Low delay encoding is activated, Short = 500 ms (for both Internet TV and IP TV)
- If Low delay encoding is not activated,
Short = 500 ms, Standard = 1000 ms, Long = 2000 ms (for both Internet TV and IP TV)
B-frames Select the number of B-frames that will be inserted between two I/IDR or P frames.
B-frames are used to increase quality. They can be considered as interpolated frames between reference frames (I or P), interpolation is done using forward and backward motion vectors used to select pieces of pictures in reference frames.
Modes: (1) Auto: allows the encoder to choose the number of Bframes depending on the source. (2) OFF: If no Bframes are required. (3)(4)(5) 1/2/3: If the number of Bframes must be fixed.
Coding mode Only available with Internet TV export type.
Modes: (1) Progressive. (2) Interlaced: only available with framerate 'regular' and resolution 'height' 480, 576 or 1080.
In case of shared encoding, only progressive is available.
Frame/field coding mode Video encoding options: (1) Frame only: each image is considered progressive. (2) Field only: each image is considered interlaced. (3) Frame MBAFF: each image is encoded as progressive with a interlaced/progressive choice at the macroblock level. (4) Auto: recommended setting to automatically detect the best encoding option for each frame.
A picture to be encoded may have interlaced structure (2 fields) or progressive structure. Even though a picture may be interlaced, video quality may be improved with frame coding when the correlation between odd and even fields is very strong.
Dynamic range mode Follow input leaves input format unchanged. Otherwise, the format is converted if necessary: color space, tone mapping (HDR to SDR) or inverse tone mapping (SDR to HDR).
HDR formats are only available with HEVC main 10 or JPEG XS 4:2:2 10 bits codec. Dolby Vision formats are only available with progressive outputs (internet TV or UHD).
See restrictions and notes below.
**Restrictions for Dynamic range mode:** - HDR conversions are only available with **HEVC Main 10 bits** codec. - **Dolby Vision** is only available with **Progressive** coding mode (Internet TV or UHD). - At the input, **Dolby Vision** streams are not supported for ST2110, but for SDI, SDI over IP, and compressed IP. - **SDR**: - Transfer characteristic: BT 709 - Colorspace: BT 709 - **Dolby Vision 8.1 & 5**: - Backward compatibility to HDR 10 **Notes for Dynamic range mode:**\ If the input source is not HDR 10 (expected format to convert to DV 8.1 or DV 5), a pre-conversion is performed. - **PQ 10**: - Transfer characteristic: EOTF SMPTE ST-2084 - Colorspace: BT 2020 - **HDR 10** - PQ 10 + - optional metadata - **HLG 10** - Transfer characteristics: Hybrid Log Gamma - Static metadata - Colorspace: BT 2020 - **HLG-10 SEI compatibility**: HLG10 SEI compatibility is another way to signal HL-G10 through an SEI message instead of the default VUI parameters. This mode provides backward compatibility with UHD TV/decode system only compatible with version 1 of HEVC (not supporting HLG); that would discard the SEI and interpret the signal as SDR BT.2020. ## Video processing
Parameter Description
Detail enhancement filter This filter boosts frequencies for improved sharpness. Use this filter when input is downscaled. Example: when converting 1080i to 720p. This filter is applied to the source before encoding starts.
Compliant with the EIA-608 standard.
## GOP settings
Parameter Description
GOP policy The GOP policy defines the way GOPs are finished.Values: (1) Open: reference frames can be picked across the GOPs. (2) Closed: all the reference frames must be in the same GOP. Impact depends on player capabilities.
- Open mode provides the best video quality.
- Closed mode is often used for interoperability.
Key frame period Enter the maximum time between two key frames.
Key frames are inserted into the video stream periodically to synchronize the decoder and enable it to recover from errors.
In an OTT use case, the key frame period defines the chunk duration.
Setting the value at 2 seconds will generate a chunk duration of 2000 ms for a PAL/DVB output and 2002 ms for a ATSC/NTSC output.
Possible values for IPTV: 500 to 10000
Possible values for Internet TV: 1000 to 10000
Key frame period policy Enter the maximum time between two key frames.
Key frames are inserted into the video stream periodically to synchronize the decoder and enable it to recover from errors.
In an OTT use case, the key frame period defines the chunk duration.
Setting the value at 2 seconds will generate a chunk duration of 2000 ms for a PAL/DVB output and 2002 ms for a ATSC/NTSC output.
Possible values:
- Auto: adjusts the number of B-frames to have a complete sub-GOP before the key frame period, round key frame period to superior GOP size
- Maximum: adjusts the number of B-frames to have a complete sub-GOP before the key frame period but round key frame period to inferior GOP size
- Strict: not below key frame period ( in ms)
Low latency fragment(s) per GOP Fragments/chunks count generated inside of the Key frame period for low latency DASHIF CMAF INGEST outputs.
1 means no chunks, no low latency.
## Aspect ratio Whatever the original stream aspect ratio, the best compromise is always performed by the encoder using the AFD, Video Index information. But you can use a specific aspect ratio scaling (anamorphic, letterbox, center cut or stretching.) to adapt the output to 4:3 or 16:9 aspect ratios for terminal not supporting the dynamic changes.\ Aspect ratio adjustment is coupled with cropping when necessary: different modes are available depending of your needs.\ Cropping can be used to remove black bars on the sides of the video, remove scrolling banners that are not readable on a handset screen or focus on a specific area of the video.
Parameter Description
AFD If present at the input, AFD (Active Format Description) information is added in the output stream.
Scaling Method applied to the video when rescaling. The Anamorphic type dynamically adapts the pixel aspect ratio (width x height) per frame. Letterbox inserts black stripes to fit the target aspect ratio. Center cut adjusts the video to keep the subject in the center of the frame and removes the black stripes, Stretching adapts the pixel aspect ratio (width x height) per frame, AFD from input follows the AFD information present in the input.
Note: some options are not available with hardware acceleration
Cropping Only available with Anamorphic and Stretching.
Specify the cropping value in % of video from Top, Bottom, Right and Left.
Output aspect ratio Only available with Letterbox and Stretching.
Targeted output aspect ratio.
Zoom adjustment Only available with Letterbox.
Adjust the zoom level to remove the black bars at the top and bottom of the picture (% of black stripes)
Fallback option Only available with AFD from input.
Fallback value when scaling is based on AFD information and AFD is not present in the stream.
## Output aspect ratio and cropping ### Picture aspect ratio handling (Auto) If the input video signal embeds WSS information and if the **Aspect ratio** parameter is set to **Auto**, MediaKind Live Encoder can extract the picture aspect ratio (PAR) information and transforms the input video as follows.

The signal always comes as 4:3, but the picture could be 16:9 anamorphic.

Video Input WSS Flag Processing 4:3 Video Output
out 43 43 4:3 Full None out 43 43
in 149 full 14:9 FullOnly available in PAL Restore PAR and fit in letterbox out 149 43
out 169 169 16:9 Full Restore PAR and fit in letterbox out 43 169
in 149 letterbox 14:9 Letterbox (center)
Only available in PAL
None out 149 43
out 43 169LBC 16:9 Letterbox (center)
Only available in PAL
None out 43 169LBC
out 43 209LBC 16:9 Letterbox (center)
Only available in PAL
None out 43 209LBC
in 149 letterbox top 14:9 Letterbox (top)
Only available in PAL
None in 149 letterbox top
Image Removed 16:9 Letterbox (top)
Only available in PAL
None Image Removed
out 43 43 4:3 Full None out 169 43
in 149 full 14:9 Full Only available in PAL Restore PAR and fit in letterbox out 149full 169
out 169 169 16:9 Full Restore PAR and fit in letterbox out 169 169
in 149 letterbox 14:9 Letterbox (center)
Only available in PAL
None out 169 169
out 43 209LBC 16:9 Letterbox (center)
Only available in PAL
None out 169 209LBC
in 149 letterbox top 16:9 Letterbox (center)
Only available in PAL
None out 149letterboxtop 169
in 149 letterbox top 14:9 Letterbox (top)
Only available in PAL
None out 149letterboxtop 169
### Cropping management Cropping is managed in a different way depending on the output aspect ratio management.
Cropping method Parameters Input display Output display
Dynamic Crop Left, Right, Top, Bottom and keep Aspect ratio in crop C L R T C4 iphone cropping dyn out
Letter Boxing Adaptation of input 16:9 to output 4:3 zoom level 0% out 169 169 out 43 169
Letter Boxing Adaptation of input 16:9 to output 4:3 zoom level 50% out 169 169 C4 iphone cropping lbox out
Stretch to fit Crop Left, Right, Top, Bottom and Stretch in crop C L R T C4 iphone cropping stretch out
## Stream metadata settings
Parameter Description
Timing and VUI insertion The output streams contains the Timecode and Video Usability Information (VUI), and inserts this information in SEI data and PPS/SPS data.
Timecode insertion Passthrough the source timecode located within the NAL SEI (H.264/HEVC), within the User Data (MPEG2), or in the jxes_header() (JPEG XS).
SCTE-20 If present at the input, SCTE20 closed captions are added in the output stream or converted to SCTE20 if input is closed caption (EIA608 or EIA708).
This option is only available with IPTV export type, with Resolution ≤720, MPEG-2 Main codec with Frame/field coding mode set to Frame only.
## Subtitle settings
Parameter Description
Closed caption If present at the input, closed captions (EIA608 or EIA708) will be added in the output stream or converted to closed captions if input is SCTE20.
Compliant with the EIA-608 standard.
Burn-in This caption burnin configuration will be applied to the related video stream.
Possible values: subtitle(s) burn-in defined in Encoding > Subtitle burn-in configuration section (see Configure subtitle burn-in).
## Shared encoding (factorization) This feature aims to share the encoding process of ABR profiles with the same resolution and frame rate. The information is re-used to simplify lower bitrates encoding. **Restriction:** Shared encoding is only available if **Coding mode** is set to **Progressive** (see [Codec settings](/beam/live-encoder/parameters/encoding/video#codec-settings)).
Parameter Description
Parent encoding The name of the parent encoding stream configuration used to preconfigure this child encoding. Processing for parent and child encodings is mutualized to optimize CPU usage.
Important: Parent and child stream will have the same rate control mode (CBR or CVQ).
Target bit rate Bandwidth used to encode the video stream.
Note: Configure the parent stream with the highest bitrate, then configure child stream bitrates to be more than half of the parent bitrate.
**Related information**\ [Configure the video encoding parameters](/beam/live-encoder/configure/encoding/video-encoding) # General configuration parameters ## General parameters
Parameter Description
Name Service name
Template Live encoding template that used to create a new service. If no template is selected, service is created from scratch.
Hardware acceleration mode (Intel QSV) Activate Intel QSV to accelerate video input, video processing and video encode. If acceleration is enabled some features are unavailable.
Full acceleration is only available for Input types MPEG2 TS/UDP and SDI.Possible values:
- None: Default mode, no hardware acceleration.
- Fully accelerated service: It corresponds to the legacy Hardware acceleration mode.
- Software input processing, accelerated video processing and encode: It enables you to run most of the input processing tools on the CPU. For example, FMTS watermarking.
- Accelerated encode only: It runs the whole software processing graph followed by a QSV encoder, most features that are available on software services are available in this mode. Only a few options that applied to the encoder itself are not available.
Note: When selected, some parameters are grayed out in the other tabs.
QSV Device Define the QSV/SG1 device to run service. If running on QSV previous generation (Intel E3 CPU), select device 1. For QSV new generation (SG1/GPU), select the suitable number.
ESAM server network interface Network interface used for ESAM outofband messages applied to the entire service.
Note: To configure the ESAM out-of-band, go to the Input tab.
SCTE-104 server network interface Network interface used for SCTE104 outofband messages applied to the entire service. To modify, open the General tab.
## Automation
Parameter Description
Activate Define an automation system to trigger events with the encoder. The Automation system can be any external Automation System. The Automation System can use either SCTE 104 and SCTE 30 interfaces or ESAM interfaces.
Interface Type Protocol used with automation system.
POIS URL Only available with ESAM.
URL for the POIS (Placement Opportunity Information Service) (if any).
POIS network name Only available with ESAM.
ID shared with the POIS for the current channel.
POIS zone identity Only available with ESAM.
The area ID for this channel distribution. Commonly used for regionalization.
Assets directory You can specify the directory where assets are stored. Must be an absolute directory path (starting by '/'). For logo and blackout files, an http url is also possible.
## Clock synchronization
Parameter Description
Program Clock Reference (PCR) Reference clock used in the encoder. By default, the encoder is locked to the input clock available in the source.
The external NTP clock is not compatible with the service synchronization feature.
The external analogue genlock signal (bi and trilevel sync signals) is only compatible by services using SDI input with the correct SDI card.
## Synchronization of services
Parameter Description
Activate Define network parameters for the synchronization between two encoders. The synchronization is used either for 1+1 availability or split encoding (distribution of one ABR channel over several HW resources).
Protocol Specifies which protocol will be used to ensure the synchronization
- Multicast is recommended for on-prem deployments.
- Redis is recommended for cloud deployments to ensure inter-region synchronization of the encoder, but it can also be applied for on-prem deployments.
Mode Specifies which streams will be synchronized. Only 'All' (audio + video + subtitles + metadata) is available.
Pool name Unique ID to identify the services that need to be synchronized together.
Network interface(s) List of names of the network interfaces used for synchronization. Use a comma to separate. Only one is mandatory. Two maximum can be set.
Address Multicast address used for synchronization.
Port Port used for synchronization.
Output source address IP address specified as source in the IPv4 header for synchronization communication. If empty, source address of network interface from which packets are sent is used.
IGMPv3 source filtering IGMP source IP address. List of addresses allowed in IGMPv3. Use a comma to separate.
## Dual output prevention
Parameter Description
Network interface The name of the network interface used for dual output prevention.
Address Multicast address used for dual output prevention.
Port Port used for dual output prevention.
Group name A group gathers a pair of encoders for which dual output prevention is managed. The group name field identifies the group.
Format: String respecting the following rules [azAZ09_]{1,32}
## Server variant configuration ### Redundancy
Parameter Description
Activate Activate the use of variants for 1+1 synchronization (needed when 1+1 synchronization is done with the same service).
Name The subset tag name used to identify the subset.
Server tags Enter one or multiple server tags to identify the servers that can be used. Server tags are used for redundancy and for subset configurations.
### Subset
Parameter Description
Name The subset tag name used to identify the subset.
Server tags Enter one or multiple server tags to identify the servers that can be used. Server tags are used for redundancy and for subset configurations.
- [General](/beam/live-encoder/parameters/input/general) - [Source error management](/beam/live-encoder/parameters/input/source-error-management) - [Live source & file source management](/beam/live-encoder/parameters/input/live-and-file-source-management) - [Source](/beam/live-encoder/parameters/input/source) - [Video and audio](/beam/live-encoder/parameters/input/video-and-audio) - [VANC](/beam/live-encoder/parameters/input/vanc) - [Subtitle](/beam/live-encoder/parameters/input/subtitle) - [Metadata](/beam/live-encoder/parameters/input/metadata) - [Cross-stream prevention](/beam/live-encoder/parameters/input/cross-stream-prevention) # Cross-stream prevention When multiple channels are broadcast on the network, operators need to ensure that the distributed content actually corresponds to the expected channel.MediaKind Live Encoder proposes a cross-stream prevention mechanism. This feature allows the operator to add an ID to a stream. This ID can then be read and checked by all the systems downstream.

The cross-stream prevention feature relies on ANSI/SCTE35 2016 (Digital Program Insertion Cueing Message for Cable standard).

Parameter Description
Stream ID Stream ID value inserted in SCTE35 messages for crossstream prevention.
Period Time period between SCTE35 messages.
**Related information**\ [Configure cross stream prevention](/beam/live-encoder/configure/input/cross-stream-prevention) # General parameters
Parameter Description
Type Input streams are either compressed or uncompressed, over a variety of interfaces.

  • If IP: supports compressed MPEG2 TS with MPEG2, H.264 and H.265 codec up to UHD.

  • If SDI: supports uncompressed inputs with SD, HD and UHD resolutions depending on the SDI board.

  • If SDI/IP: supports uncompressed input over IP, up to HD resolution, following SMPTE ST 20226 standard.

  • If RTMP: supports H.264 up to HD resolution and AAC only.

  • If SMPTE ST 2110: supports uncompressed input over IP, up to HD resolution, following SMPTE ST 2110 standard.

  • If MediaComposer : specific input to manage dynamic sources use cases via interface with an ESAM Signal Processing System.
Encoder can ingest SMPTE-2022-6 and encode it to any format with any codec.
As for SDI, video and audio are extracted from the input stream.
SD and HD formats are supported up to 1080p60. Any HD format will require a 10GB network and a hardware with a 10 GbE input port.
## MPEG-2 TS/UDP parameters
Parameter Description
Input redundancy Choose the redundancy settings: two modes can be set when two multicast sources (primary and secondary) are available.
In active/passive mode, the passive source is idle and doesn't even join the multicast address or capture UDP packets.
In active/active mode, both sources capture in parallel, provide statistics on transport and demux layers, but only one source is fully decoded at any given time.
Input loss timeout The time between the loss of input (full stream or elementary stream) and the switch to another source.
Possible values: From 1000 to 9999 ms
Input clock computation MPEG-2 TS clock interpolation mode: "auto" for default mode, "advanced" for newClock mode. Only "auto" mode is compatible with synchronization.
## SDI parameters
Parameter Description
Ingest UHD Select to enable UHD capture. UHD capture uses the first four input connectors on the SDI card for quad 3GSDI (2 sample interleave or square division) or the first input connector for 12GSDI format.
Connector SDI port used to capture this specific service
SDI card number Select the SDI card number to use.
Input label Input label used for SDI input router, mandatory in case of failover configuration.
The label is case sensitive and should match with router settings.Format: String of 32 characters maximum. Allowed characters: letters (lower and upper case), digit, _ and
Note: See router configuration.
## SDI/IP parameters
Parameter Description
Input loss timeout The time between the loss of input (full stream or elementary stream) and the switch to another source.
## RTMP parameters
Parameter Description
Network interface Name of the network interface used to capture the input stream
Stream name Name of the stream to request from RTMP server.
Connection retry period Period to wait between source reconnection retries.
Possible values: From 1 to 10 seconds.
Input buffer length Period of input material to buffer before starting decode. A longer buffer will be more tolerant to input network issues, but will introduce more delay.
Possible values: From 1 to 10 seconds.
## SMPTE ST 2110 parameters
Parameter Description
Input redundancy Choose the redundancy settings: SMPTE ST 20227 aims at providing against data loss at the IP packet level when two identical streams are received. Mellanox ConnectX6 card is required to select this mode. None provides no redundancy in the event of failure.
When SMPTE ST 2022-7 is selected as Input redundancy, then only the primary source is displayed. You can create a secondary source and specify the network interfaces, as well as the stream indices independently within the SDP file and a single SDP file location or URL for both sources. Note that ST 2022-7 is not supported in v14 but will be available starting v15.
Note: Thanks to the Mellanox card connectX-6 Dx, Live Encoder benefits from the Rivermax library for ST 2110 ingest. It supports:
- ST 2110-20: HD Video-only
- ST 2110-30, ST 2110-31: Audio
- ST 2110-40: Data
This requires a specific license which is being bought alongside the cards. The default path where Rivermax expects to find the license file is:/opt/mellanox/rivermax/rivermax.lic.
NMOS Enabled Enables NMOS for EL service.
Max Skew Only available with SMPTE ST 2022-7 redundancy.Define the maximum acceptable timestamp difference between the two input streams, beyond which an alarm will be raised and/or stats updated to indicate skew.
Possible values: From 10 to 450 ms
## MediaComposer parameters
Parameter Description
Input loss timeout The time between the loss of input (full stream or elementary stream) and the switch to another source..
**Related information**\ [Configure the input stream general parameters](/beam/live-encoder/configure/input) # Live source & File source management

Only available with MediaComposer input type.

## Live source management
Parameter Description
Default service ID ID of the live content that will be used at the start of the service.
The ID can be:

  • an existing ID: the live content can be selected from the list of existing IDs. If required, it can be directly modified via the 'Edit' button.

  • a new ID: in this case, the live content can be created and configured either immediately via the 'Create' button, or later from the 'Settings>Live service lineup' menu.
Default frame rate Default frame rate used when live input is not yet detected.
Possible values: from 23.98p to 60p
## File source management
Parameter Description
Auto return to live Returns to live at end of the offline source playlist. Note: Unused in Switch to Live use case.
Return to live on error Returns to live if offline source playlist cannot be loaded. Note: Unused in Switch to Live use case.
# Metadata ## In-band metadata
Parameter Description
Type Input metadata expected format.
### MPEG-2 TS input type
Parameter Description
PID Corresponds to the stream identifier in the MPEG2 TS stream. Otherwise use the 'auto' setting for automatic detection.
Possible values: From 16 to 8190 or "auto"
Delay If metadata stream is SCTE35, a delay adjusts the trigger time value.
Possible values: From 30000 to 60.000 ms
Automation stream Stream used for automation.
### SDI or SDI over IP input type
Parameter Description
DPI PID index Specifies the index to the DPI PID which will carry the resulting splice_info_sections.
Possible values: From 0 to 65535
Delay If metadata stream is SCTE35, a delay adjusts the trigger time value.
Possible values: From 30000 to 60.000 ms
**Related information**\ [Configure in-band metadata in input stream](/beam/live-encoder/configure/input/inband-metadata) ## Out-of-band metadata ### SCTE-35 OOB
Parameter Description
Network name Corresponds to the Acquisition Point Identity defined in the ESAM specification.
Zone identity Corresponds to the Zone Identity defined in the ESAM specification.
ESAM server network interface Network interface used for ESAM outofband messages applied to the entire service.
Recover conditioning state if failover If 'POIS' is selected, this options enables to keep the conditioning status after an encoder failover by asking to an external system.
If POIS is selected, you have to enter the POIS URL and the POIS network interface name.
Note: Configuration of POIS to recover is mandatory if:
- live service is restarted during EAS,
- or input dual source redundancy.
- or live service failover.
Else let the filed to No.
Automation stream Stream used for automation.
### SCTE-104/IP OOB
Parameter Description
DPI PID index Specifies the index to the DPI PID which will carry the resulting splice_info_sections.
Possible values: From 0 to 65535
SCTE-104 server network interface Network interface used for SCTE104 outofband messages applied to the entire service. To modify, open the General tab.
Can be modified from this field if not yet set in the General tab, otherwise the field is grayed out.
Automation stream Stream used for automation.
Splice countdown insertion Insert splice countdown field in adaptation field around splice points.
Splice null period Period between generated splice null commands.
Possible values: From 400 to 3600000
**Related information**\ [Configure out-of-band metadata in input stream](/beam/live-encoder/configure/input/outofband-metadata)\ [Configure the input](/beam/live-encoder/configure/input) # Source ## MPEG-2 TS/UDP
Parameter Description
Network interface Name of the network interface used to capture the input stream.
Stream address Input stream unicast or multicast IPv4 address
Only defined source addresses can be used to retrieve the multicast stream.
Port Port used to capture the input stream
Example: 1234
IGMPv3 source filtering IGMP source IP address. List of addresses allowed in IGMPv3 using a comma to separate.
Example: *239.2.3.123
FEC port(s) Port(s) used to activate FEC (Forward Error Correction) and resolve RTP packet loss issues due to network transport.
Use a comma to separate in case of dual mode. One port (column) or two ports (combined raw and column) can be set, in any order. Data is retrieved from these ports.
Note: Leave this field empty if you want to disable the FEC support.- In case of mono FEC mode, only column is used. In case of dual FEC mode, both column and rows are used.
- In dual FEC modes, statistics are displayed for both the column and row.
el stats dual fec mode
Input synchronization mode Input can be synchronized based on PMT program ID or on VCT major and minor channel numbers or the stream PIDs. Make a selection based on the information present on the input stream.
Program ID Select the correct program from the MTPS input stream.
Possible values: From 1 to 65535
Major channel The major channel number present in the VCT
Possible values: From 1 to 99
Minor channel The minor channel number present in the VCT
Possible values: From 1 to 999
PCR PID Enter the packet identifier of the Program Clock Reference. This clock is used to synchronize audio and video packets. If left blank, the PCR PID is set to the output Video PID.
Possible values: From 16 to 8190
## SDI/IP
Parameter Description
Network interface Name of the network interface used to capture the input stream.
Stream address Input stream unicast or multicast IPv4 address
Only defined source addresses can be used to retrieve the multicast stream.
Port Port used to capture the input stream
Example: 1234
IGMPv3 source filtering IGMP source IP address. List of addresses allowed in IGMPv3 using a comma to separate.
Example: 239.2.3.123
## SMTPE ST 2110
Parameter Description
Network interface Name of the network interface used to capture the input stream.
## RTMP
Parameter Description
Server URL URL of RTMP server to connect to.
## MediaComposer
Parameter Description
Input redundancy Choose the redundancy settings: two modes can be set when two multicast sources (primary and secondary) are available.
In active/passive mode, the passive source is idle and doesn't even join the multicast address or capture UDP packets.
In active/active mode, both sources capture in parallel, provide statistics on transport and demux layers, but only one source is fully decoded at any given time.
Primary interface Name of the input interface used to capture the input stream.
Secondary interface Name of the input interface used to capture the input stream (secondary source).
**Related information**\ [Configure stream source(s) in input stream](/beam/live-encoder/configure/input/input-stream-source) # Source error management
Parameter Description
Switch on ES data loss Switch to backup source if video or audio is lost.
Delay The amount of time between the video or audio loss and the switch to the backup source.
Needs to be defined if Switch on ES data loss is activated.
Slate if no source at start Display an image when live input is not yet detected. The replacement image can be defined in Video processing>Freeze frame management section (Media Processing tab).
Default frame rate Default frame rate used when live input is not yet detected.
Needs to be defined if Slate if no source at start is activated.
# Subtitle
Parameter Description
Type Input subtitles expected format.
## Teletext
Parameter Description
Subtitles ID type Subtitles can be captured using either the stream PID or the subtitles language.
PID Numerical identifier for subtitles track
Possible values: From 1 to 65535
## SCTE-27
Parameter Description
Subtitles ID type Subtitles can be captured using either the stream PID or the subtitles language.
PID Numerical identifier for subtitles track.
Range: From 1 to 65535
## DVB-Subtitles
Parameter Description
Subtitles ID type Subtitles can be captured using either the stream PID or the subtitles language.
PID Numerical identifier for subtitles track.
Range: From 1 to 65535
## ARIB B24
Parameter Description
PID Numerical identifier for subtitles track.
Range: From 1 to 65535
**Related information**\ [Configure subtitle in input stream](/beam/live-encoder/configure/input/subtitle) # VANC

Only available with SMPTE ST 2110 input type.

Parameter Description
Data Type Data Type carried on the VANC input. This determines what data streams will be generated. Video Metadata will be carried on the Video PID or a separate PID.
Possible values: Video Metadata, Subtitles or STCE-104
SDP File Location Location of SDP file describing the input stream. Either a URL or a file location.
Stream Index Index of stream within the SDP file. 1 is the first stream.
DPI PID index Only available with STCE-104 data type.
Specifies the index to the DPI PID which will carry the resulting splice_info_sections.
Delay Only available with STCE-104 data type.
If metadata stream is SCTE35, a delay adjusts the trigger time value.
Possible values: From 30000 to 60.000 milliseconds.
Max bitrate Highest bitrate that can be used to capture Teletext subtitles
**Related information**\ [Configure the VANC data input stream](/beam/live-encoder/configure/input/vanc-data)\ [SMPTE ST 2110 SDP file](/beam/live-encoder/configure/input/input-stream-source#smpte-st-2110-sdp-file) # Video and audio ## Video
Parameter Description
Video PID Numerical identifier of the video track. Enter 'auto' to capture the video present in the input stream.
Restriction: PID is only configurable if Input synchronization mode is set to PidLocked mode.
Possible values: From 1 to 65535
Decoding capability Select the standards to be decoded. Specific licenses are required for AVS+, AVS2 and JPEG XS decoding.
JPEG XS options are exclusive. Please select only one option at a time.
### SMPTE ST 2110
Parameter Description
SDP File Location Location of SDP file describing the input stream. Either a URL or a file location.
Stream Index Index of stream within the SDP file. 1 is the first stream.
**Related information**\ [Configure video in input stream](/beam/live-encoder/configure/input/video-stream)\ [SMPTE ST 2110 SDP file](/beam/live-encoder/configure/input/input-stream-source#smpte-st-2110-sdp-file) ## Audio ### MPEG-2 TS/UDP
Parameter Description
Audio ID Type Choose the audio stream type used to identify the input audio stream.
Possible values: PID, Language
PID Only available with PID audio type. Numerical identifier of the audio track. Or auto to use any language in the stream.
Language Only available with Language audio type. Audio track languages in ISO 639 format (3letter code, lowercase). This can be defined using a comma to separate, or enter 'auto' to use any language.
Max bitrate Highest bitrate that can be used to capture Audio
Decoding capability Select Dolby if you decode Dolby Digital or Dolby Digital Plus. Select Dolby E if Dolby E decoding is required (SDI or SDI/IP only). Specific licenses are required for Dolby decoding.
### SDI
Parameter Description
Type Type of audio to create (1) Audio (2) Aggregated audio: Used to extract up to 5.1 audio tracks from the SDI audio pairs
Audio Pair Only available with Audio type.
Select the stereo audio pair (Group/Pair).
Audio format Only available with Audio type.
Select if the audio format should be automatically detected or forced. For uncompressed/Dolby E Passthrough select either 'AES Uncompressed audio' or 'Dolby E' as the input format, and 'SMPTE302/Dolby E Passthrough' from the encoding menu. Dolby E input will not work with Dolby AC4. To decode/reencode Dolby E select Auto or SMPTE337 compressed input as the input format.
Decoding capability Only available with Audio type.
Select Dolby if you decode Dolby Digital or Dolby Digital Plus. Select Dolby E if Dolby E decoding is required (SDI or SDI/IP only). Specific licenses are required for Dolby decoding.
Dolby E program Only available with Dolby E decoding capability.
The Dolby E algorithm is optimized for handling discrete multichannel audio programs and multiple audio programs. Encoded audio channels are grouped as programs that are typically mono (one channel), stereo or matrix surround (Lt/Rt) encoded (two channels), or discrete six-channel audio with five full-range channels and a bass-only Low-Frequency Effects (LFE) channel (5.1 channels).
Dolby E makes use of the available data space only for the number of audio channels that are present, so requiring less space if fewer than eight audio channels are used. The channel configuration is determined at the time of encoding, allowing users to choose the best mode for the specific application.
Possible values: See table below.
Mode Only available with Aggregated audio type.
Defines the number of channels to configure. In case of 5.1 audio, 6 channels need to be configured: Left, Right, Center, LFE, Left surround and Right surround.
PCM audio mapping Only available with Aggregated audio type.
You can aggregate multiple SDI audio pairs to have up to 5.1 streams.
Associate the Group/pairs SDI (Gn Pn) with Left and Right as needed by scrolling the menus.Live SDI aggregated audio
#### Dolby-E program values
Program Configuration program Channel count Sequence Channel sequence
0 2 8 5.1+2 0L, 0C, 0Ls, 1L, 0R, 0LFE, 0Rs, 1R
1 3 8 5.1+1+1 0L, 0C, 0Ls, 1C, 0R, 0LFE, 0Rs, 2C
2 2 8 4+4 0L, 0C, 1L, 1C, 0R, 0S, 1R, 1S
3 3 8 4+2+2 0L, 0C, 1L, 2L, 0R, 0S, 1R, 2R
4 4 8 4+2+1+1 0L, 0C, 1L, 2C, 0R, 0S, 1R, 3C
5 5 8 4+1+1+1+1 0L, 0C, 1C, 3C, 0R, 0S, 2C, 4C
6 4 8 2+2+2+2 0L, 1L, 2L, 3L, 0R, 1R, 2R, 3R
7 5 8 2+2+2+1+1 0L, 1L, 2L, 3C, 0R, 1R, 2R, 4C
8 6 8 2+2+1+1+1+1 0L, 1L, 2C, 4C, 0R, 1R, 3C, 5C
9 7 8 2+1+1+1+1+1+1 0L, 1C, 3C, 5C, 0R, 2C, 4C, 6C
10 8 8 1+1+1+1+1+1+1+1 0C, 2C, 4C, 6C, 1C, 3C, 5C, 7C
11 1 6 5.1 0L, 0C, 0Ls, 0R, 0LFE, 0Rs
12 2 6 4+2 0L, 0C, 1L, 0R, 0S, 1R
13 3 6 4+1+1 L, 0C, 1C, 0R, 0S, 2C
14 3 6 2+2+2 0L, 1L, 2L, 0R, 1R, 2R
15 4 6 2+2+1+1 0L, 1L, 2C, 0R, 1R, 3C
16 5 6 2+1+1+1+1 0L, 1C, 3C, 0R, 2C, 4C
17 6 6 1+1+1+1+1+1 0C, 2C, 4C, 1C, 3C, 5C
18 1 4 4 0L, 0C, 0R, 0S
19 2 4 2+2 0L, 1L, 0R, 1R
20 3 4 2+1+1 0L, 1C, 0R, 2C
21 4 4 1+1+1+1 0C, 2C, 1C, 3C
22 1 8 7.1 0L, 0C, 0Ls, 0Bsl, 0R, 0LFE, 0Rs, 0Bsr
23 1 8 7.1 screen 0L, 0C, 0Ls, 0Lc, 0R, 0LFE, 0Rs, 0Rc
24–63 Reserved Reserved Reserved Reserved
### SDI/IP
Parameter Description
Audio Pair Select the stereo audio pair (Group/Pair).
Audio format Select if the audio format should be automatically detected or forced. For uncompressed/Dolby E Passthrough select either 'AES Uncompressed audio' or 'Dolby E' as the input format, and 'SMPTE302/Dolby E Passthrough' from the encoding menu. Dolby E input will not work with Dolby AC4. To decode/reencode Dolby E select Auto or SMPTE337 compressed input as the input format.
Decoding capability Select Dolby if you decode Dolby Digital or Dolby Digital Plus. Select Dolby E if Dolby E decoding is required (SDI or SDI/IP only). Specific licenses are required for Dolby decoding.
Dolby E program Only available with Dolby E decoding capability.
The Dolby E algorithm is optimized for handling discrete multichannel audio programs and multiple audio programs. Encoded audio channels are grouped as programs that are typically mono (one channel), stereo or matrix surround (Lt/Rt) encoded (two channels), or discrete six-channel audio with five full-range channels and a bass-only Low-Frequency Effects (LFE) channel (5.1 channels).
Dolby E makes use of the available data space only for the number of audio channels that are present, so requiring less space if fewer than eight audio channels are used. The channel configuration is determined at the time of encoding, allowing users to choose the best mode for the specific application.
Possible values: See table above.
### SMPTE ST 2110
Parameter Description
Stream Index Index of stream within the SDP file. 1 is the first stream.
SDP File Location Location of SDP file describing the input stream. Either a URL or a file location.
Channel Group Index Index of channel group within the SDP audio stream. 1 is the first channel group.
Audio format Select if the audio format should be automatically detected or forced. For uncompressed/Dolby E Passthrough select either 'AES Uncompressed audio' or 'Dolby E' as the input format, and 'SMPTE302/Dolby E Passthrough' from the encoding menu. Dolby E input will not work with Dolby AC4. To decode/reencode Dolby E select Auto or SMPTE337 compressed input as the input format.
Decoding capability Select Dolby if you decode Dolby Digital or Dolby Digital Plus. Select Dolby E if Dolby E decoding is required (SDI or SDI/IP only). Specific licenses are required for Dolby decoding.
Channel Order Select if the audio channel groups should be automatically read from the SDP file or manually specified.
Possible values: M, DM, ST, LtRt, 51, 71, 222, SGRP See table below.
For multi-channel audio, Live Encoder relies on the SDP file to specify how audio channels are grouped, but the channel order parameter that specifies the quantity and order of audio channels is optional in the SDP file. If the channel order is not specified, you can manually specify it.el input audio st2110 channelorder
#### Channel order values
Channel grouping symbol Quantity of audio channels in group Description of group Order of audio channels in group
M 1 Mono Mono
DM 2 Dual Mono M1, M2
ST 2 Standard Stereo Left, Right
LtRt 2 Matrix Stereo Left Total, Right Total
51 6 5.1 Surround L, R, C, LFE, Ls, Rs
71 8 7.1 Surround L, R, C, LFE, Lss, Rss, Lrs, Rrs
222 24 22.2 Surround Order shall be per SMPTE ST 2036-2, Table 1
SGRP 4 One SDI audio group 1, 2, 3, 4
U01…U64 As indicated by Grouping Symbol (Unn where nn is the number of channels in the group) Undefined None specified, the order of channels in this group is Undefined.
  • The Channel Order described above was developed such that phase-coherent multichannel audio groups (or simply mono channels) can have their channels clearly defined within SDP. It does not attempt to provide any “higher level” description of the purpose of the audio channels (such as “secondary language”). It only addresses fixed multichannel audio groups commonly used at the time of publication of this document, and does not attempt to deal with object-based audio.
    • The 5.1 Surround and 7.1 Surround channel orders defined in Table 1 are based on typical ordering of those channels found in SMPTE ST 2035, EBU R 123, and SMPTE ST 429-2.
**Related information**\ [Configure the audio input stream](/beam/live-encoder/configure/input/audio-stream)\ [SMPTE ST 2110 SDP file](/beam/live-encoder/configure/input/input-stream-source#smpte-st-2110-sdp-file) # Live service lineup encoding parameters For each source, you can edit the following parametersdepending on the source input type, either MPEG-2 TS/UDP or SMPTE ST 2110. ## MPEG-2 TS/UDP lineup
Parameter Description
Stream address Input stream unicast or multicast IPv4 address
Port Port used to capture the input stream
IGMPv3 source filtering IGMP source IP address. List of addresses allowed in IGMPv3 using a comma to separate.
Input synchronization mode Input can be synchronized based on PMT program ID or on VCT major and minor channel numbers or the stream PIDs. Make a selection based on the information present on the input stream.
FEC port Port used for FEC
Possible values: From 1 to 65535
Streams For each source select which streams will be used and enter the PIDs: List of stream identifiers using a comma to separate.
Note: If no PID is specified, default PID will be used.
## SMPTE ST 2110 lineup
Parameter Description
Stream Index Index of stream within the SDP file. 1 is the first stream.
Possible values: From 1 to 1000
SDP File Location Location of SDP file describing the input stream. Either a URL or a file location.
Note: The SDP File Location must be specified when Live Encoder service is configured with MediaComposer input type and an SMPTE ST 2110 source, but if you are using NMOS, you don't need to specify it, otherwise it will be ignored since the NMOS Controller supplies the SDP file.
Audio format Select if the audio format should be automatically detected or forced. For uncompressed/Dolby E Passthrough select either 'AES Uncompressed audio' or 'Dolby E' as the input format, and 'SMPTE302/Dolby E Passthrough' from the encoding menu. Dolby E input will not work with Dolby AC4. To decode/reencode Dolby E select Auto or SMPTE337 compressed input as the input format.
Stream Index Index of stream within the SDP file. 1 is the first stream.
Possible values: From 1 to 1000
SDP File Location Location of SDP file describing the input stream. Either a URL or a file location.****
Channel Group Index Index of channel group within the SDP audio stream. 1 is the first channel group.
Possible values: From 1 to 65535
Stream Index Index of stream within the SDP file. 1 is the first stream.
Possible values: From 1 to 1000
SDP File Location Location of SDP file describing the input stream. Either a URL or a file location.****
DPI PID index Specifies the index to the DPI PID which will carry the resulting splice_info_sections.
Possible values: From 0 to 65535
Stream Index Index of stream within the SDP file. 1 is the first stream.
Possible values: From 1 to 1000
SDP File Location Location of SDP file describing the input stream. Either a URL or a file location.****
Stream Index Index of stream within the SDP file. 1 is the first stream.
Possible values: From 1 to 1000
SDP File Location Location of SDP file describing the input stream. Either a URL or a file location.****
- [Video processing](/beam/live-encoder/parameters/media-processing/video-processing) - [Audio processing](/beam/live-encoder/parameters/media-processing/audio-processing) # Audio processing parameters
Parameter Description
Mute Tick the checkbox to mute the audio volume.
Forced language Overwrites the language of the audio track. If not set the original language is kept.
Possible values: 3 alphanumeric characters
## Advanced
Parameter Description
Force audio type Indication set in audio type.

  • Clean effects: indicates that the referenced program element has no language.

  • Hearing impaired: indicates that the referenced program element is prepared for the hearing impaired.

  • Visual impaired commentary: indicates that the referenced program element is prepared for the visually impaired viewer.

  • Primary: indicates the default recommended language.

  • Native: indicates the language in which the program was produced.

  • If not set, no override is performed.
Using audio description When present in the source, this signals the use of audio description. It carries mono audio on the left channel and modulated pan/fade data on the right channel of an AES stereo pair. If enabled, it is possible to enable ''Audio description bitrate saving'' and drop the audio stream if the description is not present. (See Signal loss management).
Audio delay Adjust the delay between audio and video. Example: helps resolve lip sync issues.Possible values: From 300 to 300
Downmix compression mode Select a mode for Dolby input stream downmixing from 5.1 to stereo.Possible values: Line mode, RF mode
## Target loudness
Parameter Description
Mode Select the required target loudness mode:

  • 'Static gain' to set a fixed gain.

  • 'Loudness control' to use a predefined standard or set a target loudness.

  • 'Advanced Loudness control' for country specific regulatory (requires specific licenses).
Profile Select a predefined standard or 'Custom' (only available in 'Loudness control' mode) to define a target loudness
Target loudness Maintains the audio level at the level defined by the Target loudness parameter.
Gain Amplify or attenuate the incoming signal.Possible values: From 100 to 20
## Dolby E to PCM fallback
Parameter Description
Audio Select a fallback audio input stream to switch on if Dolby E is no more available on this stream. A fallback audio input stream must have been previously defined.
## Watermarking ### Nielsen Linear watermarking #### Insertion
Parameter Description
Process type Linear watermarking insertion process type
SID Linear watermarking insertion source ID
One or more SIDs (Source Identification) are assigned to each content provider or distribution source. Included as a component of each watermark, the SID uniquely identifies the distribution source.
Only available with NAES watermarking.
CBET SID Linear watermarking insertion CBET source ID
Only available with CBET watermarking.
Check digits Two uppercase alpha characters, corresponding to the SID that are assigned by Nielsen. If the check-digit string does not match the SID, the authenticator does not permit watermarking with the SID.
Only available with NAES watermarking.
CBET Check digits Only available with CBET watermarking.
Two uppercase alpha characters, corresponding to the CBET SID that are assigned by Nielsen. If the CBET check-digit string does not match the SID, the authenticator does not permit watermarking with the CBET SID.
Enable CBET Step-aside mode Only available with CBET watermarking.
Activate the CBET stepaside mode.
Determines the method of CBET insertion mode when prior encoding is detected on the same layer. The default mode is overwrite but you can enable the step-aside mode.
Distribution type Linear watermarking insertion distribution type
Typically, Program Content watermarks are assigned to syndication content or to content providers (i.e. broadcast networks etc.), while Final Distributor watermarks are assigned to local broadcast affiliates or to cable network content.
Existing N2 Watermarks Linear watermarking NAES II insertion mode
Specifies whether the watermark engine overwrites existing NAES audio watermarks of the same type as the watermark that is currently proposed for insertion.
- If the mode is set to Refrain, then preexisting watermarks are left intact; new watermarks are inserted only in portions of the audio stream where there are no preexisting watermarks.
- If the mode is set to Overwrite, then the watermark engine replaces the original watermarks with the new one.
#### Extraction
Parameter Description
Watermark Type of watermark that must be extracted from this audio track.
Distributor ID DNS domain name of the company or entity operating the device.
Note: This value must be identical for each watermarking within the same service.
Breakout code Type of content that must be extracted.
### Nielsen RTVOD #### Extraction
Parameter Description
Distributor ID DNS domain name of the company or entity operating the device.
Breakout code Type of content that must be extracted.
## Cue tones
Parameter Description
Extract DTMF Enable DTMF extraction for detecting cuetones.
### Cue tones with DTMF extraction
Parameter Description
Tone duration Duration of the tone expected by the DTMF detection algorithm. It is assumed the gaps have the same duration.
Possible values: From 0 to 1000 ms
Detection threshold Detection threshold required in the algorithm to suit the input stream characteristic. The cue tones information in the statistics page or the knowledge of the upstream cue tone system provide help to define the value. The value is expressed in %, it is the threshold ratio versus total signal energy to detect the tone.
Possible values: From 0 to 100
## Signal loss management
Parameter Description
Replacement Selects the audio sound to be generated when no input is detected.Possible values: Silence, 1kHz audio tone, Audio Description bitrate saving (drop audio stream)
**Related information**\ [Configuring the audio processing parameters](/beam/live-encoder/configure/media-processing/audio-processing) # Video processing ## Video prefiltering
Parameter Description Details
Deblocking filter Removes the MPEG2 blocking artifacts. This filter is fully automated to remove the blocking and ringing effects.
Cross-talk filter Removes noise by processing noise in the source frame by frame. If activated, reduces crosscolor and crossluminance artifacts remaining in the input video. The cross-color processing is only visible on "rainbows" in PAL and NTSC sequences. If the video has been scaled beforehand, the filter is not efficient. That's why the cross-color processing is deactivated on HD sequences.
The cross-luminance artifact is a temporal effect; it is not transformed after upscale. The filter is still efficient on HD sequences.
Sharpening filter Filter applied on all output profiles with a resolution lower than the selected resolution. Used to increase image sharpness.
Example: Enhance text readability on lower resolutions.
Spatial denoising filter Removes noise by processing noise in the source frame by frame. Possible values: Off, Low, Medium, High
Diamond filter Removes noise by processing noise in the source frame by frame.
The adaptive mode uses both edges and noise detection filters to choose the areas to filter, and to adapt the filtering strength.
Possible values: Off, Medium, High, Adaptive
MCTF Removes noise by processing noise in the source with a temporal factor. Has a 7 frame rolling window. The 'Adaptive' mode uses a noise detection filter to adapt the filter strength. TPossible values: Off, Low, Medium, High, Adaptive
**Related information**\ [Configure the video prefiltering](/beam/live-encoder/configure/media-processing/video-processing#video-prefiltering) ## Video adjustment
Parameter Description
Crop overscan Removes the input video overscan area from each edge (left, top, right and bottom).
Frame rate conversion You can convert the frame rate from PAL to NTSC or NTSC to PAL.Video frame rate can be converted from PAL to NTSC (25i to 29.97i / 50p to 59.94p) or NTSC to PAL (29.97i to 25i / 59.94p to 50p).
Subtitles, closed captions or timecode are not converted.
Aspect ratio Aspect ratio can be passthrough from WSS and AFD information. You can also override/force the aspect ratio to 16/9 or 4/3.
Possible values: Auto, Force 16/9, Force 4/3
Note: See Picture aspect ratio handling (Auto) for more information.
Noise edge removal Number of lines removed from the top of the video (up to 6 in SD and 14 in HD)
Possible values: From 0 to 6 for SD, from 0 to 14 for HD
Note: 0 means no adjustment.
**Related information**\ [Configure the video adjustment parameters](/beam/live-encoder/configure/media-processing/video-processing#video-adjustment)\ [Output aspect ratio and cropping](/beam/live-encoder/parameters/encoding/video#output-aspect-ratio-and-cropping) ## Video colorimetry
Parameter Description
Brightness, Contrast, Saturation, Temperature, Hue, Gamma You can adjust these parameters by dragging the sliders back and forth or enter a value.Possible values: from -100 to +100 in whole digit increments.Note: A value of 0 has no effect.
**Related information**\ [Configure the video colorimetry parameters](/beam/live-encoder/configure/media-processing/video-processing#video-colorimetry) ## Freeze frame management
Parameter Description
Activate Display a replacement image when an input freezes (due to input loss or image freeze), if this option is deactivated, then the last decoded image is displayed.
Type The replacement image can be predefined or custom.
Image Replacement image displayed when input freezes (due to input loss or image freeze)
Image URL The path to the replacement image (GIF, PNG or JPEG file).
Syntax can be either HTTP://path or /path.You should copy your image to the following directory: /var/mediakind/streams
The image URL should then be: /tmp/streams/<your-file-name>; for example, /tmp/streams/<your-file-name>
Insertion delay The time between the loss of input (full stream or elementary stream) and the switch to another source.
**Related information**\ [Configure image on frame freeze](/beam/live-encoder/configure/media-processing/video-processing#image-on-frame-freeze) ## Video metadata
Parameter Description
Timecode Origin of the timecode that can be inserted in the SEI (Insert timecode option is available from the Encoding tab in the Video encoding>Stream metadata settings). Choose Passthrough for the input stream timecode.
**Related information**\ [Configure video metadata](/beam/live-encoder/configure/media-processing/video-processing#video-metadata) ## Video watermark parameters
Parameter Description
Type The watermarking type
Identifier Define the subscriber ID/distributor Id/payload that will be included into the watermark
Territory Country where the video is brodcasted.
**Related information**\ [Configure video watermarking](/beam/live-encoder/configure/media-processing/video-processing#video-watermarking) # Output configuration parameters ## General parameters
Parameter Description
Transport protocol DASHIF CMAF Ingest, RTMP, RTMPS, WAVE/SRT or MPEG2 TS outputs are possible. MPEG2 TS output can use either UDP or RTP transport protocol. Choose DASHIF CMAF Ingest to push content to an external DASHIF CMAF Ingest origin server. Choose RTMP(S) to push content to an external RTMP origin server. The RTMP variant is identified within the publishing point (no mix of variants is possible between primary and secondary publishing points).
## General MPEG-2 TS parameters
Parameter Description
Synchronize Output stream to be synchronized.
Stream synchronization signaling Activate to signal downstream equipment the status of stream synchronization. Requires EBP signaling.
Network interface Name of the network interface used to distribute the output stream
TTL Time To Live: defines the number of routers an UDP/RTP packet can go through before being discarded.
Possible value: From 1 to 255
ToS Type of Service: information added in the IPv4 header to specify service priority on the network. Used to specify that a service requires low delay and/or high reliability.
Possible value: From 0 to 224
GOP signaling Specifies signaling for stream synchronization. When encoding ABR outputs, the GOPs need to be synchronized across all the lineup streams.
Source address IP address specified as source in the IPv4 header
Source port Port specified as source in the IPv4 header
Possible values: From 1 to 65535
## General RTMP parameters Live Encoder can push content to an external RTMP origin server so that the operator can contribute to social media such as youtube, facebook or periscope. The H.264 encoding video stream and the optional audio stream are packaged and written to a given defined publishing point.
Parameter Description
Publishing point URL of the primary Flash Media Server (FMS) publishing point for live streaming. Configuration shall be done the following way: rtmp://{Primary FMS IP Address}/live or rtmp://{Primary FMS host name}/live. Complete the URL with the stream key defined for each stream in the configuration below. Use rtmps server for RTMPS variant: it is not possible to mix RTMP and RTMPS servers between primary and secondary publishing points.
Secondary publishing point URL of the secondary Flash Media Server publishing point.
Network interface The name of the network interface used for dual output prevention.
**Note:** See [MPEG-2 TS common parameters](/beam/live-encoder/parameters/output#mpeg-2-ts-common-parameters) for specific parameters. ## General DASH-IF CMAF Ingest parameters DASH-IF CMAF Ingest is a protocol for transport of fragmented MP4 in CMAF container format between a Live Encoder and a Packager. Live Encoder can generate fragmented MP4 in CMAF container format and HTTP push CMAF media segments to a Packager.
Parameter Description
Publishing point The URL of the Packager entry point, to which the Live Encoder will send the stream (e.g., https://example.com/ingest1).|
Secondary publishing point The URL of the secondary Packager entry point, to which the Live Encoder will send a duplicate stream (e.g., https://example.com/ingest2). You can configure up to 5 publishing points by clicking the Add button.
**Note:** See [DASH-IF CMAF parameters](/beam/live-encoder/parameters/output#dash-if-cmaf-specific-parameters) for specific parameters. **Related information**\ [Configuring the output stream general parameters](/beam/live-encoder/configure/output/configure-output#configure-the-output-stream-general-parameters) ## MPEG-2 TS common parameters
Parameter Description
Standard MPEG2 TS information is encapsulated to fit the ATSC or the DVB standard.
PMT PID Enter the packet identifier of the Program Map Table. This table defines the structure of the MPEG2TS stream.
PCR PID Enter the packet identifier of the Program Clock Reference. This clock is used to synchronize audio and video packets. If left blank, the PCR PID is set to the output Video PID.
Target PCR period The target time between two PCR information
Target PSI period The target time between two PSI information
Program number Associated to a specific program. Commonly used in MPTS to differentiate programs within the same MPEG2 TS stream.
Service name Service added to the service description table (SDT)
Service provider Service provider name added to the service description table (SDT)
Maximum bitrate insertion in PMT The PMT can provide the maximum bitrate information for each elementary stream.
Signal loss management Defines the behavior in case of signal loss.

  • None: this corresponds to the default behavior. The encoder follows the freeze frame management settings. The output will contain either a color bar, a black frame, the last image (by default) or a slate.

  • Drop video stream: if the input video elementary stream is lost, the corresponding packets are dropped and replaced by stuffing.

  • Drop transport stream: this option allows dropping the whole transport stream. The Encoder also mutes the statmux communication.
Video frames alignment on PES packets Each new frame starts with a new PES packet. If a frame finishes before the end of a PES packet then it is filled with stuffing information. Bandwidth is increased if activated.
Note: This parameter often needs to be activated for interoperability purposes. When activated, it will increase the bandwidth used by null packets.
LATM encapsulation for AAC Support for both ADTS and LATM encapsulation are available for AAC audio tracks.
Broadcast ID insertion The VCT information (if present in the source content) is translated to the broadcaster ID format and inserted in the output stream.
Encoding info insertion The output stream contains the number of black frames, freeze frames, the average bit rate, and the target bitrate between 2 encoding information structures.
These encoding statistics present in the output TS stream can then be used by downstream equipment for monitoring and error detection purposes.
Splice countdown insertion Insert splice countdown field in adaptation field around splice points.
One AU per PES on audio splices Enforce a single access unit per PES packet around splice points on audio PIDs.
Direct Path for low latency Activates the optimized data transmission between MK Live Encoding and MK Packaging for OTT latency.
It is required to activate this mode on both encoding and packaging sides.
CBR output with stuffing packets Tick this checkbox to use a CBR bitrate on transport stream output in statmux rate control mode
**Related information**\ [Configure the output stream MPEG-2 TS parameters](/beam/live-encoder/configure/output/configure-output#configure-the-output-stream-mpeg-2-ts-parameters) ## DASH-IF CMAF specific parameters DASH-IF CMAF Ingest is a protocol for transport of fragmented MP4 in CMAF container format between Live Encoder and a Packager. Live Encoder can: - Generate fragmented MP4 in CMAF container format. - HTTP push CMAF media segments to a Packager. ### MP4 general parameters
Parameter Description
GOPs per segment The number of GOPs per segment
Low latency Enable low latency for DASHIF CMAF Ingest.
This uses HTTP chunked transfer. As a rough guide, the latency from the output of the encoder, can be reduced from around 2 seconds, down to as low as 0.5 seconds, depending on the number of chunks per segment.
Unix epoch relative timestamps Generate timestamps using the Unix epoch as the anchor point.
When enabled, the output timestamps are anchored to the Unix epoch instead of being anchored to the service start time.
### Tracks List of tracks. Track IDs can be modified if needed. An optional label can be added to provide a textual description of the content (See ISO/IEC 23009-1 \[4], clause 5.3.7.2 Table 9). ### Output groups Click **Add** to include tracks that will be added to the output. See [Define the output stream composition.](/beam/live-encoder/configure/output/configure-output#define-the-output-stream-composition) **Related information**\ [Configure a DASH-IF CMAF output](/beam/live-encoder/configure/output/configure-output#configure-a-dash-if-cmaf-output) ## Output stream parameters ### MPEG-2 TS, SDI, SDI/IP or SMPTE ST 2110 parameters
Parameter Description
IP Address Unicast or multicast output stream IPv4 address
Port Port used to distribute the output stream
Range: From 1 to 65535
FEC Activate FEC (Forward Error Correction) along with the output transport stream to resolve RTP packet loss issues due to network transport.
Only available in case of MPEG2 TS/RTP.
FEC port(s) Only available if FEC is activated.
Port used to transport FEC information
Range: From 1 to 65535
Column count Only available if FEC is activated.
Defines the horizontal size of the FEC matrix.
Range: From 1 to 20
Row count Only available if FEC is activated.
Defines the vertical size of the FEC matrix.
Range: From 4 to 20
### RTMP(S) parameters
Parameter Description
Stream name/key Stream name, also known as stream key, that identifies the live stream.
{ /\* TODO: update links (especially ./parameters/) once MD files are created _/} { /_ TODO: Check calouts: This mode requires media conditioning licensing.\*/} # Advanced Rate Control ## CBR mode In CBR mode, the total rate is set and always maintained. ![Bitrate cbr](/_machine-assets/01b0b279b514246004b340a23bac878275e80ce49b785a9b1d3fb75406f995ec.jpg) _CBR mode_ **Example**\ Over a Satellite link limited to 1.5 Mbps, the encoder can be set at a target bit rate of 1.4 Mbps. We guarantee that the encoder will never go over or under the target bit rate. ```

As the IP packets might be fragmented, in IP output mode the bit rate can only be guaranteed within ± 3% of the selected rate.

``` **Benefits**\ This mode can be used in video contribution or any other application where a limited bandwidth is fully allocated to the video feed. By maintaining the data rate constant, one can easily check that the feed is not dropping. This mode is particularly useful with IP Satellite modems. ## Statistical VBR mode For many years the broadcast industry has used expensive and proprietary hardware to provide statistical multiplexing (statmux) features in MPEG-2 transport stream-based networks. With the advent of IP-based networks, the notion of multiplexing and demultiplexing sources that are bundled together is becoming less important, while the requirement to fit multiple channels in a bandwidth-constrained network remains essential. Drawing from its expertise in MPEG-4 and IP-based video networks, MediaKind has developed a next generation, IP-based, statistical rate control module for broadcast TV networks that provides the highest quality video services in a bandwidth constrained environment. By adding statistical rate control capabilities within the core of the MediaKind Live Encoder encoder, MediaKind enables service providers to both optimize the use of their bandwidth, and avoid the cost of purchasing proprietary statmux technology. In the case of DTH, multiple IP services are transmitted in bursts on a fixed bandwidth channel. In order to respect the overall bandwidth constraint, there are generally two ways of transmitting the IP traffic: Fixed bandwidth allocation: each service utilizes a constant bandwidth and the streams must be constant bit rate (CBR). The burst size and period are fixed. Dynamic, variable allocation: each service utilizes a variable bandwidth. The burst size and period are variable. The latter case is better for video transmission. Given the heterogeneous nature of video signals, it is more appropriate to use more bandwidth on parts of the video that are hard to encode and less on the easier parts. Statistically, there is a high chance that different sources do not need high bandwidth at the same time, so there is an interest in dynamically assigning the bit rate for the transmission of each source. This method is called Statistical Variable Bit Rate mode, or Statistical VBR, and the allocation mechanism Statistical Rate Control. ![Bitrate statmux](/_machine-assets/ade220c48cee7e70f5d1446068edf0deb8c676d2d17205a0ea2c3f64ca272fca.png) _Aggregated bandwidth of 4 services in Statistical VBR_ The bandwidth savings in this case are very significant. Up to a 30% bit rate reduction has been measured with 8 services. **Benefits**\ With scarce spectrum resources, the use of statistical rate control in DTH allows the number of available channels to be doubled. The overall subjective quality of the service is also greatly improved. ## Statmux, Statistical rate control Statistical rate control for HEVC, H264 and MPEG-2, SD, HD and UHD video is available in DVB and ATSC extreme export types, each statistical rate control pool can be composed of up to 64 services or 80Mbps. Statistical rate control is a Master/Slave architecture. - **Slave**: encoder on the network set to encode in VBR with a nominal quality. The slave sends the budget requirements for encoding to a central Master. - **Master**: module controlling the encoders and distributing the overall bandwidth to the different encoder available on the network. The “Master” module resides on one encoder. The “Master” guarantees that: - the sum of all the slave throughputs respect the bandwidth constraints. - the bit rate is controlled in case of failure: no service interruption, master is automatically replaced by an available “Slave”. **Benefits for operators**\ Multi-protocol, SD and HD compatible, self-contained statistical rate control for simple integration in existing architecture. MediaKind Live Encoder provides built-in features to ease Statmux operations. In order to ensure that the bit rate is always correctly distributed over content, MediaKind Live Encoder can detect that a slate has been inserted and thus reduce the bit rate to a slate level CBR bit rate to better manage bandwidth for other streams. ![Bitrate Statmux benefits](/_machine-assets/e4208a1fc916ce49bde5453b17d74a82ce451c542d5dac0e1202ad4b598c4abe.png) No operation is required when a slate is displayed on one channel of the pool, the statistical rate control automatically reclaims the bit rate from this channel. ## CVQ - Constant Video Quality A constant quality algorithm with capped bit rate can be used instead of a Constant Bit Rate target. Image bit rate is defined by its instantaneous complexity based on a sophisticated psycho-visual metric. You can define how to manage the bandwidth: - **Quality level** mode: the content is encoded at a constant perceptual quality without information on the bandwidth consumption. The aim is to achieve the desired **Quality level**. The scale works with a \[1.0-5.0] decimal scale and can be directly translated to an equivalent MOS score.

We recommend limiting the usage of this mode to lab testing. This mode requires media conditioning licensing.

- **Average bit rate** mode: our latest and more complete algorithm of CVQ. While keeping homogeneous quality, the algorithm guarantees the specified **Target bit Rate** over a long period of time (6 hours by default).

This mode requires media conditioning licensing.

To define the **Target quality** used by the algorithm, a mapping between the bit/pixels of the configuration and the average bit rate was internally measured on a test set for each quality level. **Related information**\ [Video encoding parameters](/beam/live-encoder/parameters/encoding/video) # Set up the SDI card for HD or UHD operation In this version, the card variant for HD or UHD operation is not set via the UI. You need to manually set the SDI card variant before configuring it for the use case required. - **Variant 1**: - HD SDI input (each input is up to 3G-SDI) - **Variant 2**: - 1 UHD channel over 4x3G-SDI on ports 1,2,3 and 4 with DTA-2174B - 1 UHD channel over 4x3G-SDI on ports 1-4 or 5-8 with DTA-2178 1. Connect to the unit using SSH. 2. Edit the file (using vi) or set the value in it using cat: ```shell sudo chmod +777 /var/opt/mediakind/platform/dta_217x_variant echo 2 > /var/opt/mediakind/platform/dta_217x_variant ```

The file contains 1 or 2 which is the variant number.

3. Check if the value is correct: ```shell cat /var/opt/mediakind/platform/dta_217x_variant ``` 4. Reboot the unit: ```shell sudo reboot ``` At this stage, all cards within the unit will be set to that variant. Note that if you have multiple cards you need to be in different variants, you can make **/var/opt/mediakind/platform/dta\217x\variant** a folder and a file inside for each card, for example: ```shell echo 2 > /var/opt/mediakind/platform/dta_217x_variant/1 # First card in variant 2 ``` # Multiplexing A **multiplexer** (mux) combines multiple audio, video, and data streams into a single MPEG-2 Transport Stream (MPEG-2 TS). In broadcast and headend environments, multiplexing is how multiple channels from separate sources are consolidated into one output for delivery over cable, IPTV, or satellite. MK.IO Beam's Multiplexer takes transport stream inputs from live encoders or other sources and assembles them into a combined output for delivery over IP or ASI. It supports re-multiplexing and de-multiplexing of IP input streams, with PID remapping, PID filtering, service information (SI/PSI) management, and output adaptation for a range of network environments. Stream assembly and timing alignment are handled automatically. ## Input redundancy Input sources can be configured with redundancy. If the active source becomes unhealthy, the Multiplexer automatically switches to a secondary source. When secondary sources are monitored, the Multiplexer checks their health before switching, ensuring it only moves to a source in a good state. ## Statistical multiplexing Standard multiplexing assigns a fixed bitrate to each program in the output transport stream. Statistical multiplexing (statmux) improves on this by dynamically sharing available bandwidth across a pool of encoding services based on encoding complexity at any given moment. Channels with complex scenes receive more bitrate; simpler scenes return bandwidth to the pool. MK.IO Beam's Multiplexer supports statmux through pools. Each pool has a defined bitrate budget and works with Live Encoder services configured as statmux slaves. The Multiplexer acts as the statmux master, coordinating bitrate allocation across all participating encoders. See [Advanced rate control](/beam/live-encoder/rate-control) for how Live Encoder services participate in a statmux pool. ## Common use cases - Assembling multiple channels for cable or IPTV headend distribution. - Combining live-encoded services into a single transport stream for satellite uplink. - Remultiplexing incoming transport streams for downstream processing or conditioning. To start configuring a Multiplexer service, see [Configure the Multiplexer](/beam/multiplexer/configure/input). # ASI Card Configuration Tool ## Installation & Usage The configuration tool is installed as part of the cRPM ASI driver installation. It is available from the following location on the M1 or G8 platform: `/opt/mediakind/utility/bin/asi_config/` To get help on the command line options, add -h to the command line. **Example:** `./asi_config -h` or `./asi_config set connector -h` By default, the ASI configuration tool connects to the Multiplexer ASI API on the machine where the tool is running, i.e., **localhost**. To tell the tool to connect to a different server, use the `--host` optional command line argument: **Example:** `./asi_config --host ` For commands that produce output, you can use the optional argument --json to request that the output is rendered in as a JSON document. This can be useful if the content is used for further processing. ## Known Server Types & Aliases Many of the commands require the user to identify a specific card for the ASI API. To simplify this for the users, the tool allows server definition files to be created, in which one or more aliases can be associated with a pre-defined PCI bus number/slot number pair. If you provide your own servers, you can create your own server definition files by using the existing ones (for example: m1.json) as templates. ## Server Type Description File Definition Each server description file is a JSON document and is composed of an array of objects, one for each board location. Each board entry in the array has three properties: pciBusNumber, pciSlotNumber and aliases. - pciBusNumber - The PCI bus number required for the ASI API. - pciSlotNumber - The slot number required for the ASI API. Also known as device by tools such as lspci. - aliases - An array of strings containing several alternative aliases for this board location. - **Example:** “2”, “top-middle” and “tm” might all be alternatives. To help with identifying bus numbers and device slots in usage, you can use the lspci command. This provides the location of every PCI device in the format `[[[[]:]]:][][.[]]`. The domain is optional, or only shown if various domains are present.

All values are hexadecimal.

Here is an example output of the lspci command for an M1 with 2 Dektec cards, on bus 01 and 02: ``` [root@m1-225 asi_config]# lspci | grep DekTec 01:00.0 Non-VGA unclassified device: DekTec Digital Video B.V. Device 0882 02:00.0 Non-VGA unclassified device: DekTec Digital Video B.V. Device b87e ``` ## Commands ### get servers Displays a list of the ASI servers configured for the system. **Example of usage:** ``` [root@m1-227 asi_config]# ./asi_config get servers m1-217 m1-227 ``` Gets the configured ASI servers for **localhost**. ### get connectors Displays a list of the configured connectors. Required arguments in order: `asi_server_name`: The name of the ASI server to show ASI information for. Optional arguments: - `--type server_type`: Specifies a server type to look up an alias for a specific board. (Example: m1) - `--alias alias`: Specifies a board alias when used with the --type argument. (Example: top-left) - `--pci bus_number`: Specifies the PCI bus number associated with a specific ASI card. - `--slot slot_number`: Specifies a specific slot number associated with a specific ASI card. Use with the --pci option. **Example of usage:** - `asi_config get connectors m1-227`: Gets the configured connectors for ASI server 'm1-227'. - `asi_config get connectors m1-227 --type m1 --alias top-left`: Gets the configured connectors for the card in the top-left slot of the m1 ASI server 'm1-227'. - `asi_config get connectors m1-227 --pci 1 --slot 0`: Gets the configured connectors for the card attached to PCI bus 1 in slot 0 on ASI server 'm1-227'. **Example with output:** ``` [root@m1-227 asi_config]# ./asi_config get connectors m1-227 Server: m1-227 REST ID | Direction | PCI Bus No. | PCI Slot No. | Connector | Interface | Multicast | Port | Input Packet Length | Alias ================================================================================================================================ 1 | input | 1 | 0 | 1 | lo | 239.123.1.1 | 1234 | auto | 2 | input | 1 | 0 | 2 | lo | 239.123.1.2 | 1234 | auto | 3 | input | 1 | 0 | 3 | lo | 239.123.1.3 | 1234 | auto | 4 | input | 1 | 0 | 4 | lo | 239.123.1.4 | 1234 | auto | ``` ### remove server Removes all the connectors associated with the specified server. **Example of usage:** - `asi_config remove server m1-227`: Removes the ASI server m1-227 and all the connectors associated with it. ### remove connector Removes a single connector. Required arguments in order: 1. `asi_server_name`: The name of the ASI server to update. 2. `server_type_or_pci_bus_number`: The type of server when using an alias or the actual PCI bus number (int) of the board being removed. 3. `alias_or_slot_number`: The alias for the board or the actual slot number (int) for the board. 4. `connector`: The physical connector index (1 based) on the board. **Example of usage:** - `asi_config remove connector m1-227 m1 top-left 3`: Removes the third connector for the top-left board in an M1 server. - `asi_config remove connector m1-227 1 0 3`: Removes the third connector for the board associated with PCI bus 1 on slot 0. ### remove api-connector Removes a single connector identified by its API number (REST ID in the table from get connectors). Required arguments in order: 1. `asi_server_name`: The name of the ASI server to update. 2. `api_connector`: The API connector number associated with the connector to remove. This is the value that is set in Multiplexer configurations. **Example of usage:** - `asi_config remove api-connector m1-227 1`: Removes the connector with the API number of 1 from the server called m1-227. ### set connector Sets the properties for a connector. Connectors can be identified via the board and index. Required arguments in order: 1. `server`: The name of the ASI server to update. 2. `server_type_or_pci_bus_number`: The type of server when using an alias or the actual PCI bus number (int) of the board being removed. 3. `alias_or_slot_number`: The alias for the board or the actual slot number (int) for the board. 4. `connector`: The physical connector index (1 based) on the board. After these arguments, you must specify either input or output. ### input Sets the connector as an ASI input. Optional arguments: - `--multicast` or `-m`: The multicast address (URL format) to which the content from this ASI connector should be re-transmitted. If not set, the tool will pick a multicast that is not already in use for an existing connector. - `--interface` or `-i`: The name of the network interface to use for the multicast transmission. If not specified, the interface 'lo' is used. - `--set_api_id` or `-a`: Specifies the ID to associate with this connector in the REST API. If not set, an ID is auto-generated. - `--input_packet_length` or `-ipl`: Specifies the input packet length for the connector. Values supported are `auto`, `188` and `204`. **Example of usage:** ``` [root@m1-227 asi_config]# ./asi_config set connector m1-227 1 0 1 input --interface lo --multicast udp://239.123.1.1:1234 -ipl 204 REST ID | Direction | PCI Bus No. | PCI Slot No. | Connector | Interface | Multicast | Port | Input Packet Length | Alias ================================================================================================================================ 1 | input | 1 | 0 | 1 | lo | 239.123.1.1 | 1234 | 204 | ``` Configures the API connector with the ID of 1 to be an input and have the multicast and port values. Additionally, it configures the input packet length to be 204 bytes. Please note that supported Dektec cards always operate in `auto` mode. Output packet length can be configured in the Multiplexer output settings. ### output Sets the connector as an ASI output. Optional arguments: - `--set_api_id`: Specifies the ID to associate with this connector in the REST API. If not set, an ID is auto-generated. - `asi_config set connector m1-227 m1 top-left 3 input`: Sets the third connector on the card in the top-left slot of the M1 server m1-227 to be an input. - `asi_config set connector m1-227 m1 top-left 3 input --multicast udp://239.34.221.1:5000 --interface lo --set_api_id 3`: Sets the third connector on the card in the top-left slot of the M1 server m1-227 to be an input with data transmitted on the loopback interface using a multicast group address of 229.34.221.1 on port 5000. The ASI content can be used by setting the ASI connector to 3 in the Multiplexer configuration. - `asi_config set connector m1-227 m1 top-left 3 output`: Sets the third connector on the card in the top-left slot of the M1 server m1-227 to be an output. **Example of usage:** ``` [root@m1-227 asi_config]# ./asi_config set connector m1-227 1 0 1 output REST ID | Direction | PCI Bus No. | PCI Slot No. | Connector | Interface | Multicast | Port | Input Packet Length | Alias ================================================================================================================================ 1 | output | 1 | 0 | 1 | lo | 239.123.1.1 | 1234 | 204 | ``` Configures the API connector with the ID of 1 to be an output. Interface, Multicast, Port and Input Packet Length values in the table do not apply to output connectors. ### set api-connector Changes an existing connector using its REST ID. Required arguments in order: 1. `asi_server_name`: The name of the ASI server to update. 2. `api_connector`: The API connector number associated with the connector. This is the value that is set in Multiplexer configurations. After these arguments, you must specify either input or output. The same optional arguments as in [set connector](/beam/multiplexer/asi-card#set-connector) are supported. **Example of usage:** ``` [root@m1-227 asi_config]# ./asi_config set api-connector m1-227 1 input --multicast udp://239.123.1.6:1234 -ipl auto REST ID | Direction | PCI Bus No. | PCI Slot No. | Connector | Interface | Multicast | Port | Input Packet Length | Alias ================================================================================================================================ 1 | input | -1 | -1 | 1 | lo | 239.123.1.6 | 1234 | auto | ``` ### export Exports the current configuration to a file. Required arguments in order: - `file`: The path to the file to create. Optional arguments: - `--server`: The name of a single ASI server to export. If not set, all servers are exported. **Example of usage:** - `asi_config export /home/mfeng/asi_settings.json`: Exports all the ASI configuration to the file asi\_settings.json. - `asi_config export /home/mfeng/m1-227.json --server m1-227`: Exports the ASI configuration for server m1-227 to the file m1-227.json. ### import Imports the ASI configuration from a file. Required arguments in order: - `file`: The path to the file to import the settings from. Optional arguments: - `--server`: The name of a single ASI server to import. If not set, all servers are imported. **Example of usage:** - `asi_config import /home/mfeng/asi_settings.json`: Imports all the ASI configuration from the file asi\_settings.json. - `asi_config import /home/mfeng/m1-227.json --server m1-227`: Imports the ASI configuration for server m1-227 from the file m1-227.json. - [Input](/beam/multiplexer/configure/input) - [Transport Stream](/beam/multiplexer/configure/transport-stream) - [Transport Stream Mode For Outputs](/beam/multiplexer/configure/transport-stream-mode-for-outputs) - [Output](/beam/multiplexer/configure/output) - [Virtual Component](/beam/multiplexer/configure/virtual-component) - [Descriptor](/beam/multiplexer/configure/descriptor) - [Remux](/beam/multiplexer/configure/remux) - [Bandwidth Policy Group](/beam/multiplexer/configure/bandwidth-policy-group) - [Statmux pools switching](/beam/multiplexer/configure/statmux-pool) - [Configure Regional Statmux](/beam/multiplexer/configure/regional-statmux): Configure a Regional Statmux in MK.IO Beam. ## Configuring Bandwidth Policing Group 1. Create a new Multiplexing Service and configure the service settings. 2. Configure **Transport Stream** parameters. 1. Open the **Mux** tab to configure total bitrate. 2. Open and configure the **Output** tab: - Set an **Output Name**. - Set the output **Type**to IP. - Select the **network interface** and define the **stream address**. 3. Open the **Bandwidth Policing** tab and configure the groups: - Click the **Add Group** button to configure a first group defined with a name and a bitrate. - Click the **Add Group** button to configure as many groups as needed defined with specific name and bitrate. 3. Assign the **Bandwidth Policing Group** to an output service to the transport stream. 1. Click **add** to create a new output service. ![view output stream add service ts sp](/_machine-assets/948d0339574884306739c6ef4aac285985fe881bffa44b77f8c28765ce85c222.png) 2. Set the **Service Passthrough**mode to **On** to display specific parameters. 3. Select one of the **Bandwidth Policing Group** previously created. 4. Configure the **Sources**' **Input** parameters with the appropriate **Network Interface**, **Destination IP Address** and **Port**number. 4. Assign the **Bandwidth Policing Group** to a video component of an output service. 1. Click **add** to create a new component to an existing output service. ![view output stream add component to service](/_machine-assets/1c1153790de11f400a99196d0c1f9f766f8e578093dc9abcb7268641557884f6.png) 2. Configure the **Input** tab parameters. 3. Open and configure the **Output** tab and select one of the **Bandwidth Policing Group** previously created. 4. Create and configure any other video component needed with specific **Bandwidth Policing Group**. 5. Click **Save and continue** to save your modifications. 6. Assign a server and start the service. The service is running and **Bandwidth Policing Group** information (bpgId) are assigned to the service configuration files at both services and component level. You can also monitor the [**Bandwidth Policing Group** statistics](/beam/multiplexer/monitor#bandwidth-policing) by clicking the `Pie chart` icon button on the Services page. ## Configuring a service descriptor 1. Display services. 2. Click `Edit` icon to edit the service and display parameters. The transport stream parameters display. 3. Select the service and add a custom descriptor to the transport stream service if none exists, or select an existing descriptor to display **Properties**. ![view ts service descriptor properties sp](/_machine-assets/8f4681fa0109341c3d4b7872e63da0e67ee93e5b177e4daaaf81df46c1662458.png) 1. Enter the service Name 2. Enter the service provider name 3. Select the service type in the drop-down list 4. Select the regeneration mode for this descriptor when descriptor regeneration is on. ## Configuring a component descriptor 1. Click `Edit` icon. The transport stream parameters display. 2. Select the component and add a custom descriptor to the transport stream component if none exists or select an existing descriptor to display **Properties**. ![view ts custom descriptor properties sp](/_machine-assets/087490078e25dfc328581cada6d53a49ea49cc9f18f6ebf7ac785ee7c5a55848.png) # Input source redundancy modes If a source has bad health, Multiplexer can automatically switch to an alternative source. Conversely, if the secondary has bad health, it can prevent from an unnecessary redundancy switch. Monitoring the secondary provides the advantage of having a health report for all sources, allowing the automatic switch to use this information when necessary. However, this behavior has the drawback of higher CPU and network bandwidth usage. The behavior of the input source switch mechanism can be summarized into two modes: 1. Automatic switch behavior **when the secondary sources are monitored**: - If the active source input shows bad health, then a switch to another source reporting source with good health (green) occurs. - If the active source reports PID or PIDs missing and they are reported as critical, then a switch to another source reporting source with good health (green) occurs. - If the active source has missing PID or PIDs reported but only as warning, then no change occurs. 2. Automatic switch behavior **when the secondary sources are not monitored**: - If the active source input goes missing, then a switch to another source occurs. - If the active source has missing PID or PIDs reported and they are reported as critical then a switch to another source occurs. - If the active source has missing PID or PIDs reported but only as warnings, then no change occurs.

If all sources have bad health, the Multiplexer continues cycling through the sources until a source with good health (green) is available.

## Input source health monitoring view The Input Redundancy Health view displays information on the health of an input source for all servers the configuration is assigned to. This page is an overview of redundant input sources, the input source health, the DVB services per source and you can manually switch between sources. Both the input name assigned by the user in the Multiplexer configuration and the input details are visible for added convenience. If the input is used for multiple output services and/or components, the full list under _Output Services_ can be expanded by clicking it. ![view input health sp](/_machine-assets/769889f8414a110b4d4f2f097be4c46e2d0f42041d7862dc9a0698f209d33d62.png) ## Displaying health information for an input source The Input Redundancy health page can be used to monitor input sources and manually switch sources. 1. Edit the **Multiplexing** service from the Services page. Alternatively, go to the services **Statistics** view. 2. Select **Input redundancy** to display the input sources, and their redundancies and statuses. ![view input health sp button highlight](/_machine-assets/36071b6de6b686e08d52f640c53df0d6d1b40fb802f0ff7906d3ad780a68ddc4.png) 3. Hover the mouse over the status for a source to display information. ![view input health details sp](/_machine-assets/cf972b04e6f72ddf0562fb42e5ff70cd916f044ce3fd72c3fe1d6ec7d5eb29d4.png) ## Switching the active input source manually A transport stream is running with primary and secondary inputs. 1. Display Services. 2. Edit the **Multiplexing** service to display the transport stream. 3. Select **Input Redundancy** to display the health page. 4. Click `Left/Right` icon to switch to the other input source. ![view manually switch input source sp](/_machine-assets/32608a0514844850e069a8784c77b453654e57a1ce3cedec4cffa8cb4dc87116.png) The previously inactive source becomes active. ## Automatic input source switch health monitoring You can monitor the health for individual input components (PIDs) or input DVB services. You can configure a missing component or DVB service to contribute to the health of an input source and trigger a redundancy switch if necessary. ### Monitoring input source health at the service level 1. Display Services. 2. Edit the **Multiplexing** service to display the transport stream. 3. Select the Transport Stream to display the **Properties** configuration. 4. Configure the **Source Redundancy Mode** parameter to **Automatic with monitoring**. ![view switch input source config sp](/_machine-assets/d51e17384d0df40a1480f756cf63eefa9520f334b4df2d0e2c1abb2f36504158.png) 5. From the Output Stream tree, select the **Service** to display **Output** parameters. 6. Select **Monitor health of all signalled Input components** to activate the automatic health monitoring for this service. 7. Check the health of the input sources for this service: 1. Stop the primary source supplying the Multiplexer. 2. Click `Left/Right` icon in the header menu to display the Input source health monitoring page. 3. Hover the mouse over the input source statuses to get more details. As a result, the input source is showing an unhealthy status. The missing PIDs from the service are now reported as critical issues and they are labelled _Missing Mandatory Component_. If the secondary source is healthy, the input source automatic switches to the healthy input. ### Monitoring input source health at the component level 1. Display Services. 2. Edit the **Multiplexing** service to display the transport stream. 3. Select the Output component in the Transport Stream tree to display the **Properties** configuration. ![view auto switch input source config sp](/_machine-assets/111c345c94ca9e55eb9befb118490e6b41b335a9ea31404c7e256a04c232e494.png) 4. From the **Input** tab, select **Alarm if input component missing** to enable. 5. From the **Input tab**, select **Contributes for input health Monitoring**. 6. Check that the automatic switch occurs when necessary: 1. Stop the primary source for the PID. 2. Click `Left/Right` icon in the header menu to display the Input source health monitoring page. 3. Hover the mouse over the input source statuses to get more details. The active input source switches to the healthy input source. ## Using the Input Content panel To preview the inputs to the Multiplexer configuration being created, use the **Input Content** panel. ![mux input content panel](/_machine-assets/e1892f8f1e26a06895fc09e828e32d091f3ed36189e02e840a48c97104f32dcb.png) The **Input Content** panel is pre-loaded with any input in use by a configuration output services. ### Adding a new input to the Input Content panel on a new configuration or an existing configuration 1. Click the plus (+) button next to the panel title banner. ![mux input content panel plus](/_machine-assets/25f13e0a645287af7e45b9ffaf029a59eaaab70f404859b9f7f94ae172ae91c9.png) 2. Fill the fields.

The field validation similar to the output panel applies in this window. Invalid fields are highlighted in red and an error message shows.

![mux input content add](/_machine-assets/f52c7a8a53931d8d3cafea7bfbe6da43fe0274a2cc3369ec276b995ade2305d1.png) 3. Once all the required fields are filled and valid, click **Add**. The newly created input shows, collapsed, in the **Input Content** panel.The new input enters the Loading state until it has extracted all the information or up to a maximum of 30 seconds. ![new input loading](/_machine-assets/171755aad6fa57680872ad54b0f6fd2d1b09d8ca14de264c1bf82b3eb5abe10b.png) 4. To expand the input, click the **arrow** to the left of the input entry. You can also expand the child service or the component entries to reveal all the information extracted. ![mux input content expanded](/_machine-assets/d1c8fd8a8cd541ca14e90fff9da07d71e5b18450955daff6af19f5238dadc2ba.png) 5. To use the input as a source, go to the **Properties** panel and click the **List of the existing sources** drop-down box. ![mux input content list of existing sources](/_machine-assets/259370f8864ecec65fd00624594e5ff4d7f52298335fbe87c439df532d815bbe.png) 6. Click the input. The input panel fields fill automatically. If there are multiple inputs that use this input as a source, it will also be set as a shared source. ![mux input content shared source](/_machine-assets/17300790e16051c46ba7fdceec9878fba33622c624c70a5edb32d7cba10c4e99.png) ### Drag & Drop

This is only supported from Multiplexer versions 21.3 onwards.

Alternatively, it is possible to create output items by dragging items from the Input Content Panel to the Output Stream Panel. This heavily reduces the burden of manual data introduction and checking. When using the Drag & Drop functionality, a copy of the item that was dragged will be created in _snapshot_ mode. This is ideal for remux head end scenarios, where multiple MPTS sources that are outside of the user’s control need to be manipulated. This process normally involves breaking the incoming MPTS sources apart and recombining the services into new output MPTS containing different sets of services. Since the user may not have control over the incoming transport streams, their only source of control of the output is in the mux configuration itself. In these types of systems, we would expect the user to explicitly configure the services and components being passed through along with PSI/SI manipulations required to make it "their" output. Because of this, when considering a UX based on dragging input items to the output we believe operations should work recursively on whole branches to produce a static output i.e. one that does not change because items have been added to the input. We are calling this the "snapshot approach" when discussing the drag and drop operations as it produces a fixed configuration based on the "snapshot" of the input when the user was editing the configuration. **Once the content finishes loading** in the Input Content Panel, click, hold, and drag the desired item to the desired target parent in the Output Stream panel. If it is dragged to a valid target, the target itself will be highlighted in green (see picture below) and the input item can be dropped. If the target is highlighted in red, it is not a valid operation and no action will take place. ![mux input content drag drop 1](/_machine-assets/1eb590a7d438907410fc25fd281eebeb965625839b4581137ece1487fc7ba25d.png) Once the item is dropped to a valid target parent, a copy of it will be added to the output stream. Available configuration fields will be autofilled from the content extracted and displayed in the Input Content Panel. Any children items will be recursively added in the same way. Do any edits to the autofilled new items under the Output Stream panel. Save the configuration. ![mux input content drag drop 2](/_machine-assets/c2e8dcf865009125b1610224473be65f769f910e43637e0bbcb3dd4e4b788db9.png) The following drag and drop operations are currently implemented:
Drag (Source) Drop to (Target) Mode
Service Transport Stream / Service Snapshot
Component Transport Stream / Service / Component Snapshot
Descriptor Component / Descriptor Snapshot
### Managing inputs in the Input Content panel You can manipulate the inputs added to the **Input Content** panel manually or retrieved from the configuration: - by using the buttons next to the **Input Content** panel title; - by right-clicking on each input to reveal the context menu. The buttons and options in the context menu are greyed out for any entry that is not a top-level input. ![manage inputs](/_machine-assets/98066cff3c559390afa00e9fb20f5b2bf9c1150c39fa8412621fc9d48f6ccfbb.png) You can bring back the input details window: - by selecting **Edit Input**; - by clicking the **pencil** button. You can change any of the original input details. Once saved, the changes automatically apply to any output source that uses this input. If you select **Refresh Input** or click the **cycle arrows** button, the selected input enters the Loading stage again and extracts up-to-date information on the input.

Once loaded, the input-extracted information does not refresh automatically.

You can delete inputs: - by selecting **Delete Input**; - by clicking the **trash can** button.

The inputs that are in use cannot be deleted. If the input is in use, the Delete Input option and the trash can button are greyed out.

![input content cant delete](/_machine-assets/0ef227e219f533a38eebc79cdbeb9f8da552c4a647abe5da526bb2042a426871.png)

The inputs in the Input Content panel that are not in use are not saved when you exit or refresh the configuration page.

## Configuring a video output A video output stream exists in the transport stream configuration. See [Configuring output transport stream elements](/beam/multiplexer/configure/transport-stream#configure-output-transport-stream-elements) for more information. 1. Display services. 2. Click `Edit` icon to edit the service and display parameters. The transport stream parameters display. 3. Select the service and add a video output to the transport stream if none exists, or select an existing video output to display **Properties**. ![view ts video properties sp](/_machine-assets/3d0b9c1ed80f630bfef5dc63d09609ad475676d7552f1e106fe0637dfa288c7c.png) ## Configuring an audio output 1. Display services. 2. Click `Edit` icon to edit the service and display parameters. The transport stream parameters display. 3. Select the service and add an audio output to the transport stream if none exists, or select an existing audio output to display **Properties**. ![view ts video properties sp](/_machine-assets/3d0b9c1ed80f630bfef5dc63d09609ad475676d7552f1e106fe0637dfa288c7c.png) # Configure Regional Statmux Regional statmux lets you efficiently combine national and regional channels in the same pool. MK.IO Beam supports encoding **multiple** regional channels. Each regional set can be inserted into its corresponding **regional multiplex** alongside shared national channels, while still using **statistical multiplexing** to save bandwidth. For example, if you have 4 **national channels** and 2 **regional channels** for each of 2 regions, you can create 2 multiplexes: ### Multiplex 1 (Region 1) - National Channel 1 - National Channel 2 - National Channel 3 - National Channel 4 - Regional Channel 1 (Region 1) - Regional Channel 2 (Region 1) ### Multiplex 2 (Region 2) - National Channel 1 - National Channel 2 - National Channel 3 - National Channel 4 - Regional Channel 1 (Region 2) - Regional Channel 2 (Region 2) National channels are common across multiplexes, while regional channels are unique to each multiplex. ## Configuring Remux ECMs 1. Display the services. 2. Click `Edit` icon to edit the services and display the parameters. The transport stream parameters display. 3. Select the service or component. 4. You can either add a Remux ECM if none exists or select an existing Remux ECM to display.

You can change the order of the Remux ECMs within the service or component by selecting that item and selecting a direction.

![move remux ecms](/_machine-assets/2839c228655beb4a5ccf9f06048d5e22a750f94f0d8d4811720d624b20c8017e.jpg) ![remux ecm properties](/_machine-assets/4d421a2e8867871678174ce148f4cee91f3c533ce7b2366bdf8e1077fb550fff.jpg) 5. Enter a user-friendly **Name**. 6. Select the **Mode**. - **Remux By CAS ID**: Enter the incoming **CAS ID** of the ECM to remux. ![remux by cas](/_machine-assets/8261118373d9e8886f6c3adef96f4b5cedbb48a741486b40bbcc401e87e3fc00.jpg) - **Remux By PID**: Enter the incoming **Input PID** of the ECM to remux. ![remux by pid](/_machine-assets/95d7def8ef5841f36b91eb04506f8440d5643f3bc8881dabedf45ba7c315b1b7.jpg) - **Remux By Position**: Enter the **CA Descriptor position** of the incoming ECM to remux.\ Position index is based only on the CA Descriptors and is zero based. Depending on the number of CA Descriptors available, possible position could be 0 or 1 (for 2 CA Descriptors), 0, 1 or 2 (for 3 CA Descriptors), etc. ![remux by position](/_machine-assets/9180864660b869e66a242ddb33ee47c8a4fc6a27391d1816e2b46e8c0f55636a.jpg) 7. Enter the **Input Program** number that contains the ECM to remux. 8. Enter the **Output PID** value that will be applied to the outgoing Remuxed ECM. 9. Enter the **Output CAS ID** value of the Remuxed ECM that will be signaled in the CA Descriptor. 10. Select the **Private Data Source** mode: - **Extract from input PMT**: Tracks the incoming changes in private data on the incoming ECM. - **User specified private data**: Overrides the private data on the remuxed ECM. ![remux ecm private data](/_machine-assets/66eabb2fac23f410e511d8a4b3803f0f5546c42a166046ae9175476b671969c4.jpg) 11. Select the **ECM reference** in the output PMT mode: - **Always include in PMT**: The Remux ECM will always be signaled in the output PMT table. - **Follow source**: The output PMT table will only signal the Remux ECM if the incoming PMT contains the ECM that is to be remuxed. - **Do not include in PMT**: The Remux ECM is not signaled in the output PMT table. 12. To enable an alarm to be raised when the required incoming ECM is missing: 1. Check the “Alarm if input component is missing” box. 2. Specify a **Raise Alarm After** time in milliseconds. 3. Provide any **User Alarm Text** to be displayed with the alarm. 13. For the Remux ECM to contribute to the input health monitoring, check the “Component Contributes For Input Health Monitoring” box. ![remux ecm alarm settings](/_machine-assets/8b373a643a52dad0c1cd947d99168bc7c2404b1bbcf0f61b859270f7796fe5c0.jpg) 14. Select the incoming source that contains the ECM to be remuxed. ![remux ecm source input](/_machine-assets/2d31f219fd3b5761fa55354d8903f36d92beb6e2ab6fbaed6e74be040dcafb1a.jpg) ## Statmux pools switching Statistical bitrate allocation is a feature that involves a multiplexing service (statmux master) and multiple encoding live services (slaves). When two mux servers are configured for redundancy, which means that two servers are assigned to the same service (which includes one or more statmux pools definition), you can allocate different pools to different servers. 1. Create and configure the Multiplexing service. 2. From the service configuration main page, select the **Statistical Multiplexing** tab. 3. Check the **Enable Statistical Bitrate allocation** box. 4. To add two or more pools as required, click the **Add pool** button. 5. For each pool, specify the parameters: - **Name**: It is a unique identifier used when configuring Live Encoder services to be added to the pool. - **Bitrate**: It is the overall bitrate allocated to the pool. - **Interface**: It is the control interface on which messages are exchanged between the statmux master and the slaves. - The **Video Only** flag. Possible values are **On** or **Off**. 6. Save the configuration and exit. 7. Assign the service to two servers. 8. Start the service. 9. Open the **Statistics** page. 10. Go to the **Statistical Bitrate allocation** tab. 11. Scroll to the lower part of the page to check where each pool is running. ![statmux pools running](/_machine-assets/c26e3e7dee85d5f548ab836c2160416f3b063fc215c1c3093e1c6832701634c7.jpg) In this example, two pools called smxpool1 and smxpool2 have been defined. They have both been assigned to two servers, spark-statmux-1 and spark-statmux-2. They are both running on spark-statmux-1: both show “active” on that server. 12. To switch all the pools to the other server, select the button at the right of the server name. ![statmux pools tick button location](/_machine-assets/04cce387372c0d051544b726c23b0927208b18ac58cbe3b451a045fb35326637.jpg) Both pools appear “active” on the second server. ![statmux pools active](/_machine-assets/122b0ae647a189110b93e657316305c5a391b14d451b4bfe95976613b4f74515.jpg) 13. To switch a single pool to the other server, select the button at the right of the pool name. ![statmux pools single pool](/_machine-assets/8fd8b0ba362bcc5f546756cf89833980d6abad934740c2625a4361f4620b5476.jpg) The pool appears “active” on the first server. ![statmux pools active2](/_machine-assets/afd7cc7aa7e84a433aed7a41025dfedc3370c1825d0dc475ede24e3efbc18450.jpg) ### Important note about redundancy configuration The address associated to the multicast announcers on a specific server is dynamically allocated at the installation time, either via default values or configuration options (see Installation guides for further details). It can be retrieved by logging on the server and addressing the content of the configmap for each microservice (see paragraph “Interaction with the deployment on a specific server”). To configure two servers as a redundancy pair, the announcers for all microservices need to be set the same value on both servers. To do that: 1. Edit the configmap. 2. Restart the mux, statmux, biss-ca and simulcrypt microservices. In case of statmux, the statmux multicast address must also be specified on the encoding-live services configuration as an advanced parameter (statmux.announce.addr). ## Create an output transport stream (mux) 1. Display services. 2. Click **Add service** > **Multiplexing**. ![view add multiplexing new sp](/_machine-assets/fb57aa6640240bc70e661d0000ce2330f37ddcac25956cc5b6c46b073b845ae1.png) ## Configure output transport stream elements 1. Display services. 2. Click `Edit` icon to edit the service and display parameters. The transport stream parameters display. 3. Select the transport stream, or an element in the stream, and use the action buttons to add, delete or organize items.

Parameters, properties and options vary depending on the selected transport stream item.

![view configure ts sp](/_machine-assets/fc5e349b284fc189ba59636588605c426e1f88a3069dc22399875b3667cbab5a.png) ## Configure a transport stream Create an output Transport Stream to aggregate outputs from multiple Encoding Live encoder sources. Before you start, ensure the multicast addresses of the Encoding Live output streams are known. 1. Create a new **Multiplexing** service and configure the service settings. 2. Configure the Transport Stream parameters: 1. Open the **Mux** tab to configure bit rate and TS levels. 2. Open the **Output** tab and select the output type: - IP output type: enter the IP stream address and destination UDP port - ASI output type: select the connector(s) - RIST output type: select the RIST mode (Caller or Listener) and connections details 3. Open the **PSI/SI** tab and configure the PSI/SI generation and table repetition rates. 3. Click **add** to add more Pass-through encoding services to the transport stream. ![view output stream ts sp](/_machine-assets/fe69e2797bd09dd79fe9ac51e4bba9f36fc5656921a86cae301f945fc5d820d7.png)

If the Input Program number is unknown then set to 0 to choose the first program referenced in the PAT of the incoming SPTS.

4. Save settings to return to the services page. 5. Assign a server and start the Output Transport stream. ## Organize elements in the transport stream 1. Display services. 2. Click `Edit` icon to edit the service and display parameters. The transport stream parameters display. 3. Use the buttons to shift up or down, to add or delete, or filter items in the stream. ![view ts actions buttons add delete filter sp](/_machine-assets/2ae3aebdb7f410fe9db09ee4e9a89879b9b4048879fdcd4b38b9230c42ca6c46.png) ## Delete an element from the transport stream 1. Display services. 2. Click `Edit` icon to edit the service and display parameters. The transport stream parameters display. 3. Click `Delete` icon to delete the item. ![view ts actions buttons add delete filter sp](/_machine-assets/2ae3aebdb7f410fe9db09ee4e9a89879b9b4048879fdcd4b38b9230c42ca6c46.png) ## Configure a service in the transport stream 1. Display services. 2. Click `Edit` icon to edit the service and display parameters. The transport stream parameters display. 3. Select the **Service** item in the transport stream, or select the transport stream and add a service to the output transport stream. The properties display. ![view output conf sp](/_machine-assets/20db6aa698a15010cc1e915f913f16b6fb5ac28e3affa42066c89dd0edb0b68b.png) ## Configuring a remux transport stream Create a basic output TS from fixed source input SPTS or MPTS. This section will describe how to select incoming PIDs and remap them into a new output Transport stream. The multicast addresses and PID mappings of the input transport streams are known. 1. Create a new Multiplexing Service and configure the service settings. 2. Configure Transport Stream parameters. 1. Open the **Mux** tab to configure bitrate and TS levels. 2. Open the **Output** tab and select the output type: - IP output type: enter the IP stream address and destination UDP port - ASI output type: select the connector(s) - RIST output type: select the RIST mode (Caller or Listener) and connections details 3. Open the **PSI/SI** tab and configure the PSI/SI generation and table repetition rates. 3. Click **add** to add output services to the transport stream. - **Service Passthrough**: At a Service level it is possible to configure **Service Passthrough** mode to re-multiplex an entire incoming service. Selecting **Service Passthrough** displays the input specific parameters - **Descriptor Regeneration**: Regenerate descriptors from an incoming TS. Enabling the **Regenerate Descriptor** setting displays the input TS parameters required to configure the incoming TS and Program number. 4. Choose to re-order TS components using the Output Stream tool-bar. ![view output stream ts sp](/_machine-assets/fe69e2797bd09dd79fe9ac51e4bba9f36fc5656921a86cae301f945fc5d820d7.png) 5. Save settings to return to the services page. 6. Assign a server and start the Output Transport stream. ## Configuring a simulcrypt output transport stream ### Specific configuration with an external EIS If External EIS is being used: 1. Click **Services** in the left-side menu panel. 2. Edit the Multiplexing Service that you want to scramble. 3. Select the **Scrambling** tab. 4. Select **Transport Stream** under the **Scrambling Groups** panel. 5. Click the **Enable EIS** check-box. ![stream processing External EIS config](/_machine-assets/81c35c8fe408e176cfc40ae69421551308909e70627e0618254591c5f0b7dba3.png) ### Configuring a simulcrypt output transport stream Create a basic output TS from fixed source input SPTS or MPTS. This section will describe how to remux services and scramble them in the output transport stream. - An unscrambled Transport Stream with three services is configured in Multiplexer. - The IP addresses and SuperCASID of any ECMG and EMMG servers are known. - The Access Criteria required for each SCG is known. Add Simulcrypt scrambling with an EMM stream to the unscrambled TS. 1. Create **SCG 1**. 1. Click **Services** in the left-side menu panel. 2. Edit the Multiplexing Service that you want to scramble. The service configuration options display. 3. Select the **Scrambling** tab. ![view scrambling tab sp](/_machine-assets/438bfca2525424a3aacafed77602d1cd98e267521c76890ce391f7e1dd4806fb.png) 2. Configure scrambling for **Service 1**. 1. Drag and drop **Service 1** to the **Transport Stream** in the **Scrambling Groups** panel. ![view scrambling groups sp](/_machine-assets/4c353f53b0e0c0c2fc8e915571417c0f1f52d06611b5c9131b97d61ea6244255.png) A new **SCG** is created. 2. Click the **SCG** to display options. The **Scrambling Group Properties** display. 3. Enter a name for the **SCG**. ![view scrambling groups configuration sp](/_machine-assets/c0e3d0da922be8a85b3645347fdab3cf580f1c29af86e0f623dc57de2da39e18.png) The **SCG** name updates in the tree view. 4. Select the **Scrambling Algorithm** that applies: - **CSA V1 48bits (Conformance Mode On)** - **CSA V2 64bits (Conformance Mode Off)** - **CISSA V1 TS Level** - **CISSA V1 PES Level** - **AES-ECB** 5. Select the behavior until all required ECMs for SCG first received: - Component(s) in SCG not present in output TS - Component(s) in SCG in-the-clear in output TS 6. Select the scrambling behavior to apply to the components: - Checkbox ticked: Scramble components in the group - Checkbox unticked: Does not scramble the components in the group 7. Configure an **ECMG** for the **SCG** by clicking **Scrambling Vendors** tab, then click **+ Add Vendor** to configure. ![view scrambling vendors configuration sp](/_machine-assets/07f5589020adf8e9be3ac78a01b0ffa5fbd85199370d58a109860d5273c52374.png) The ECMG configuration will be used to create **ECMs** that scramble services and components. 8. Add an ECM to **SCG 1** by selecting the **ECMs** tab, then click **+ Add ECM** to add and configure. (The **Vendor** is based on the ECMG definition). The **ECM** is now configured. ![view scrambling groups properties sp](/_machine-assets/16fff78dbc41ff001cf6776ee450fb90e5e6184432326bd6bb20592a9fb9ea56.png) 9. Click **Save and continue** to scramble Service 1. The MediaKind ECM is present in the output transport stream. 3. Configure scrambling for **Service 2**. 1. Drag and drop the video component with **PID 200** from Service 2 to the **Transport Stream** in the **Scrambling Groups** panel. A new SCG is created with **PID 200** as the scrambled component. ![view scrambling groups2 sp](/_machine-assets/a1e8d90aa7fb2b88c60f298540d823a4243e1c624a85a1bc9a671d2f4927cfe5.png) 2. Drag and drop the video component with **PID 300** from Service 3 to the new SCG in the **Scrambling Groups**. PID 300 is added to the new SCG. ![view scrambling groups2bis sp](/_machine-assets/9d1b3391f4671e3cf8b862177d82b8dcaaeac3ee7f7aa55305af0410384a6037.png) 3. Select the added SCG to edit the **Scrambling Groups Properties** and enter a name for it. 4. Add an ECM to **SCG 2** by selecting the **ECMs** tab, then click **+ Add ECM** to add and configure. **SCG 2** is complete. ![view scrambling group properties ecm](/_machine-assets/e1d1090518d6fb537edcdcf79582991f9f26351d20eda2429cb644e95e36c682.png) 5. Click **Save and continue** to scramble PIDs in the SCG and to continue the configuration. MediaKind ECM is present in the output transport stream. 4. Create an **EMM stream**. 1. In the **Multiplexing** tab, right click the **Transport Stream** node, then click **Add...** to add a new EMM. ![view scrambling add emm sp](/_machine-assets/1f9590b46d16de8420e5a9b35b80117499295919722a38316af4412a59fcee4d.png) The EMM stream is created. ![view output stream emm sp](/_machine-assets/a5a4bf05a31daf62a46d2043d003ecf257a74873a2641541cbd05ce8166cfbd4.png) 2. Add the EMMG vendor using the **Scrambling Vendors** tab in the EMM properties.

Destination UDP port is only required when streaming EMMs via UDP. Automatic mode allows the first Simulcrypt channel and stream to connect from the defined EMMG ClientID. Any later connection requests are rejected. Clear the check box to allow multiple connections and to manually add channel and stream definitions.

``` ![view scrambling vendors properties sp](../images/view_scrambling_vendors_properties_sp.png) ``` 3\. Select the **EMM** tab and enter an **output PID** and **Vendor**. 4. If the EMM is streamed from an EMMG, the set **mode** to **Local Insertion**, otherwise leave the default value. 5. Save the configuration to accept the EMMG connection. The EMM is present in the output Transport Stream. ## Configuring a fixed key output transport stream Create a basic output TS from fixed source input SPTS or MPTS. This section will describe how to remux services and scramble them in the output transport stream. An unscrambled Transport Stream with three services is configured in Multiplexer. Add fixed key scrambling to the unscrambled TS. 1. Create SCG 1. 1. Click **Services** in the left-side menu panel. 2. Edit the Multiplexing Service that you want to scramble. The service configuration options display. 3. Select the **Scrambling** tab. ![view scrambling tab sp](/_machine-assets/438bfca2525424a3aacafed77602d1cd98e267521c76890ce391f7e1dd4806fb.png) 2. Configure scrambling for Service 1. 1. Drag and drop **Service 1** to the **Transport Stream** in the **Scrambling Groups** panel. ![view scrambling groups sp](/_machine-assets/4c353f53b0e0c0c2fc8e915571417c0f1f52d06611b5c9131b97d61ea6244255.png) A new **SCG** is created. 2. Click the **SCG** to display options. The **Scrambling Group Properties** displays. 3. Enter a name for the **SCG**. ![view scrambling groups configuration fixedkey sp](/_machine-assets/6e26bb076693cd3a637068192080f8f139170e883d74028b8a464a5968dfac71.png) The **SCG** name updates in the tree view. 4. Select the fixed key **Scrambling Algorithm** to apply: - BISS Mode1 - BISS Mode2 5. Enter the related **BISS Session Word**: - 12 hex characters for BISS Mode1 - 32 hex characters for BISS Mode2 6. Select the scrambling behavior to apply to the components: - Checkbox ticked: Scramble components in the group - Checkbox unticked: Does not scramble the components in the group 3. Configure scrambling for **Service 2**. 1. Drag and drop the video component with **PID 200** from Service 2 to the **Transport Stream** in the **Scrambling Groups** panel. ![view scrambling groups2 sp](/_machine-assets/a1e8d90aa7fb2b88c60f298540d823a4243e1c624a85a1bc9a671d2f4927cfe5.png) A new SCG is created with **PID 200** as the scrambled component. 2. Drag and drop the video component with **PID 300** from Service 3 to the new SCG in the **Scrambling Groups**. ![view scrambling groups2bis sp](/_machine-assets/9d1b3391f4671e3cf8b862177d82b8dcaaeac3ee7f7aa55305af0410384a6037.png) PID 300 is added to the new SCG. 3. Select the added SCG to edit the **Scrambling Groups Properties** and enter a name for it. 4. Select the fixed key **Scrambling Algorithm** to apply: - BISS Mode1 - BISS Mode2 5. Enter the related **BISS Session Word**: - 12 hex characters for BISS Mode1 - 32 hex characters for BISS Mode2 6. Select the scrambling behavior to apply to the components: - Checkbox ticked: Scramble components in the group - Checkbox unticked: Does not scramble the components in the group 4. Save the configuration. Scrambled components are present in the output transport stream. ## Configuring a BISS-CA output transport stream Create a basic output TS from fixed source input SPTS or MPTS. This section will describe how to remux services and scramble them in the output transport stream. An unscrambled Transport Stream with three services is configured in Multiplexer. Add BISS-CA scrambling with an EMM stream to the unscrambled TS: - EMM stream on PID 400 from ClientID 0x5555 with 500Kbs limit Channel and Stream unknown. - Create two output Scrambling Control Groups (SCG): - **SCG 1** - Scramble all components in Service 1 - Scramble with CSA1 scrambler - Access Criteria 0x11112222 - Private Data 0x33334444 - One ECM with SuperCASID 0x12345678 with PSI signaling at service level - **SCG 2** - Scramble with CSA1 scrambler - Scramble video PID 200 from Service 2 - Scramble video PID 300 from Service 3 - No Access Criteria or Private Data required - One ECM SuperCASID 0x12345678 with PSI signaling at service level 1. Create **SCG 1**: 1. Click **Services** in the left-side menu panel. 2. Edit the Multiplexing service that you want to scramble. The service configuration options display. 3. Select the **Scrambling** tab. ![view scrambling tab sp](/_machine-assets/438bfca2525424a3aacafed77602d1cd98e267521c76890ce391f7e1dd4806fb.png) 2. Configure scrambling for **Service 1**: 1. Drag and drop **Service 1** to the **Transport Stream** in the **Scrambling Groups** panel. ![view scrambling groups sp](/_machine-assets/4c353f53b0e0c0c2fc8e915571417c0f1f52d06611b5c9131b97d61ea6244255.png) A new **SCG** is created. 2. Click **SCG** to display options. The **Scrambling Group Properties** displays. 3. Enter a name for the **SCG**. ![view scrambling groups configuration biss ca sp](/_machine-assets/bdbed94e6a692ecc9013dd0b8be7e873be51fdb2e99463d204f7f00527b052f7.png) The **SCG** name updates in the tree view. 4. Select the **BISS-CA** as **Scrambling Algorithm**. 5. Enter the **ECM PID** and **EMM PID**. 6. Select the location in the PMT of the **CA descriptor**: - Service - Component 7. Enter the four-hex unique ID for the **Entitlement Session**. 8. Select a pre-imported file that contains the **Active Key**. 9. Select the **Behaviour until all required ECMs for SCG first received**: - Component(s) in SCG not present in output TS - Component(s) in SCG in-the-clear in output TS 10. Select the scrambling behavior to apply to the components: - Checkbox ticked: scramble components in the group - Checkbox unticked: does not scramble the components in the group

Changing the default value of an advanced parameter promotes from the Advanced Settings area to the Main Settings area.

``` - **EMM bitrate** - **Period to play the session word** (must be greater than the **Additional Descrambler Delay** and less than or equal to the **Session Key Period**) - **Period to play the key session** (defaults to 0, if not 0 must be greater than 60 seconds and a multiple of the session word period) - **Prevent Descrambled Forward** - **Prevent Decode Forward** - **Insert Watermark** - **EMM ingest Buffer Duration** - **Additional Descrambler Delay** ``` 11\. Click **Save and continue** to scramble Service 1. MediaKind ECM is present in the output transport stream. 3. Configure scrambling for **Service 2**: 1. Drag and drop the video component with **PID 200** from Service 2 to the **Transport Stream** in the **Scrambling Groups** panel. ![view scrambling groups2 sp](/_machine-assets/a1e8d90aa7fb2b88c60f298540d823a4243e1c624a85a1bc9a671d2f4927cfe5.png) A new SCG is created with **PID 200** as the scrambled component. 2. Drag and drop the video component with **PID 300** from Service 3 to the new SCG in the **Scrambling Groups**. ![view scrambling groups2bis sp](/_machine-assets/9d1b3391f4671e3cf8b862177d82b8dcaaeac3ee7f7aa55305af0410384a6037.png) PID 300 is added to the new SCG. 3. Select the added SCG to edit the **Scrambling Groups Properties** and enter a name for it. 4. Click **Save and continue** to scramble PIDs in the SCG and to continue the configuration. MediaKind ECM is present in the output transport stream. 4. Save the configuration to accept the EMMG connection. The EMM is present in the output Transport Stream.

Please be aware of the following considerations when configuring BISS-CA:

  • If interoperability with MediaKind RX8200 is required, Additional Descrambler Delay must be set to 60 seconds.
  • BISS-CA timings are not accurate when session word and session key change at same time.
  • The EMM repetition period has an effect on the EMM bitrate. If the EMM repetition rate is too low and the key files are too large, the EMM bitrate on the output will be higher than the configured bitrate.
## Configuring a dynamic PID output transport stream (remapping PID for remuxing) Create a basic output TS from fixed source input SPTS or MPTS. This example configuration describes how to select incoming PIDs and remap them into a new output Transport stream. The multicast addresses and PID mappings of the input transport streams are known. Create a DVB Transport Stream with the following requirements: - **Output TS bitrate:** 40 Mbs - **TS ID and Original Network ID:** 10 - **Multicast address:** 239.0.0.1, Port 5000, UDP delivery - **PSI required:** PAT, PMT, SDT, TOT, TDT - **3 Output Services:**
Channel Video Input PID Video Output PID Audio Input PID Audio Output PID Service descriptor
1 100 100 101 101 Use existing descriptor
2 100 200 101 201 Use existing descriptor
3 Set Input Tag to 30 on Program 3 300 Set to English on Program 3 301 Replace Service Type for type 23
1. Create a new Multiplexing Service: **Services** > **Add service** > **Multiplexing**. The service options display. 2. Configure the required (\*) parameters in the **Mux** tab.

Changing the default value of an advanced parameters promotes from the Advanced Settings area to the Main Settings area.

![view properties mux sp](/_machine-assets/883663462c699b93650840f99129769fcb692eb9dd0ab3ae4a95aa2f8d8b59e1.png) 3. Configure the output multicast details in the **Output** > **Output** tab. Multiple outputs for the same Transport Stream can be added using the `+Add` button. ![view properties output sp](/_machine-assets/8bb2a00e11552bd46850d83046090819baf3508507585b7c807771a956250365.png) 4. Configure **Tables** in the **PSI/SI** tab. ![view properties psi si sp](/_machine-assets/e8fad1cfacc016a4d317a326934e15c8b1d9d0bc2c5137a89176854555be838b.png) 5. Add a TOT descriptor to the output service. ![view tot descriptor local time offset ts sp](/_machine-assets/ad113a320181782b39395da1bcf791359890fc8a4825c2ad13b17083c6d50979.png) 6. Click **Add output** and configure components for **Service 1**. 1. Set the **Regenerate Descriptor** to **On**.

Parameters vary in relation to your selection and configuration. Orange indicates that a change is made. The changes are applied upon saving the configuration.

``` ![view output conf sp](../images/view_output_conf_sp.png) ``` 2\. Add video and audio components, then configure (see table above for example parameters). ![view input conf sp](/_machine-assets/93ace011878605d2ed1bc83a60a12cf873d551ba0e959439216224c702d5aebe.png) ![view input conf sp sources](/_machine-assets/5e76edba505f2a25f9a4cc7f7bc7efa71b0db8ceb2041e92479ccc4b8cd8c99a.png) - **To regenerate a descriptor:** You can regenerate descriptors from an incoming TS by enabling the Regenerate Descriptor option with the incoming TS and Program number. - **For Service Passthrough:** Set to **On** in order to re-multiplex an entire incoming service. **This avoids the need to explicitly define the components and descriptors** included in the service. 7. Click **Add output** and configure components for **Service 2**. In our example, Service 2 needs the input PIDs to be remapped to new PIDs in the output TS. ![view input pid conf sp](/_machine-assets/f4980f09a9773015bbfc393694b214a6d56b398d6082f4fb9d3083b3a5e77079.png) ![view output pid conf sp](/_machine-assets/f0e5b38c96a253e3eac95da6f3d1a84430debb082624edc40e5a31efee22ec61.png) 8. Click **Add output** and configure components for **Service 3**.

See example settings in the table above for dynamic PID tracking using a Video Input Tag.

1. Set the Input selection mode to **Tag**, and set the **Input tag** to 30 for **Program number** 3 (this is for dynamic PID tracking using the example parameters from the table above). ![view input selection mode tag sp](/_machine-assets/55afdbcff8e258522ba0008f5278321311064e95ac0ae7e5b8b09eacabe72525.png) 2. Configure the **Audio Language** using the example parameters from the table above. ![view audio input selection mode tag sp](/_machine-assets/bd5ee9758d8d95a422eff8a25280d93f987ee3b3e38789b3a94fbb60e542119f.png) 3. Add a service descriptor to replace the existing descriptor with the new service type. ![view service descriptor sp](/_machine-assets/f1d088a6134eaad565fc75c8a216b5eb750b96b557f3609f5246cf7e9f9d65a6.png) The output Transport Stream is populated with services ready for play out. 4. Use the buttons in the toolbar to reorder elements in the stream.Edited elements display in orange. ![view ts sp](/_machine-assets/37d7a9690b9ff723f1aa40901f84a88319e3aa168b8ed2f5c99bfc9123169f84.png) Changes are applied when saved. 9. Click **Save and exit** to apply changes. 10. Assign a server to the service. 11. Click `Play` icon to start the transport stream. The Status column shows **started**. ![view mux server selection sp](/_machine-assets/de7f3b08f5b9f6605c24b78344c0a913e32171cf24479c8794710a9e51f93af0.png) # Transport Stream Mode For Outputs The transport stream (TS) mode selects whether the output is constant bitrate (CBR) or variable bitrate (VBR). It is controlled using advanced settings described below.

An advanced settings property will be placed in the Properties panel when set to a non-default value, and placed in the Advanced Settings drop-down panel when set to its default value. The settings are described in the Stream Processing tab of the Multiplexer Parameters.

## Transport stream mode for ASI outputs The TS mode for ASI outputs is always CBR and cannot be changed. ## Configuring the transport stream mode for IP outputs

The TS mode for IP outputs and the number of packets per frame are configurable from Beam version 1.12. Prior to that version, the TS mode for IP outputs is always CBR, and there are always 7 packets per frame.

The TS mode for IP outputs may be CBR or VBR. It is a single setting that applies to all IP outputs. The default is CBR. The supported VBR mode is SMPTE ST 2022-3, and hence the TS will only be valid if it contains no more than one referenced PCR PID. When the TS mode for IP outputs is set to CBR, null and non-null packets populate each IP frame. IP frames will be output regularly at a frame rate determined by the total bitrate of the multiplexer and the number of packets per frame. When the TS mode for IP outputs is set to VBR, non-null packets populate each IP frame. All null packets are discarded, providing maximum latency requirements are met (see [Controlling latency for VBR TS IP outputs](/beam/multiplexer/configure/transport-stream-mode-for-outputs#controlling-latency-for-vbr-ts-ip-outputs)). IP frames will be output at a frame rate that is no greater than the equivalent CBR frame rate. The total bitrate of the multiplexer determines the maximum bitrate of the VBR TS payload of each IP output. ### To configure CBR TS mode for all IP outputs: 1. Click on the transport stream in the **Output Stream** panel. 2. Find the **TS mode for all IP outputs** property, either in the **Mux** tab of the **Properties** panel or in the **Advanced Settings** drop-down panel. 3. Select **CBR** from the **TS mode for all IP outputs** property. ### To configure VBR TS mode for all IP outputs: 1. Click on the transport stream in the **Output Stream** panel. 2. Find the **TS mode for all IP outputs** property, either in the **Mux** tab of the **Properties** panel or in the **Advanced Settings** drop-down panel. 3. Select **VBR - SMPTE ST 2022-3 (Single referenced PCR PID only)** from the **TS mode for all IP outputs** property.

Ensure the output TS contains no more than a single referenced PCR PID. If the output TS contains multiple referenced PCR PIDs, the output TS will not be compliant with ISO/IEC 13818-1.

## Controlling latency for VBR TS IP outputs The TS packet period for a CBR TS is constant. When encapsulated in IP frames, there is a latency of between 0 and 6 TS packets. This latency is usually small - for example, a 10 Mbps TS encapsulated in a 7-packet IP frame would incur a latency of less than 1 ms. The TS packet period for a VBR TS is not constant. For a low VBR TS bitrate, the TS packet period will be high. After IP encapsulation, the IP latency could be much higher than that of the equivalent CBR TS. The maximum VBR frame period guards against excessive latencies. The maximum VBR frame period is a single setting that applies to all IP outputs. The default is 100 ms. It defines the maximum time between consecutive VBR frames. Null packets are inserted in IP frames if necessary to meet the maximum VBR frame period. This setting is necessary for the following reasons: - Certain protocols such as RTP, FEC and RIST must buffer data, and equipment using those protocols expect a minimum frame rate to ensure a reasonable latency through their buffers. - Downstream equipment is likely to declare a loss of input if a frame does not arrive within a certain period after the previous frame arrived. - The latency through the buffers, both in downstream equipment and the multiplexer output buffer, can be controlled directly via the maximum VBR frame period. Note that the latency for IP outputs is increased by the maximum VBR frame period. The default is sufficient for most applications, and it is only necessary to change the maximum VBR frame period to reduce the latency for IP outputs and/or reduce the maximum latency through downstream equipment input buffers. For low-latency applications, there is a trade-off between latency, packets-per-frame and the minimum TS bitrate before nulls are allowed into a VBR IP output. For example: - Using the default of 7 packets per frame, the default maximum VBR frame period of 100 ms results in a minimum TS bitrate of approximately 105 Kbps. The maximum latency through a downstream RTP buffer of 20 frames is 2 seconds. - Reducing the maximum VBR frame period to 10 ms increases the minimum TS bitrate to approximately 1 Mbps. The maximum latency through the same downstream RTP buffer is 200 ms. - With the maximum VBR frame period still at 10 ms, reducing frame occupancy to 1 packet per frame reduces the minimum TS bitrate to approximately 150 Kbps. ### To configure the maximum VBR frame period for all IP outputs: 1. Click on the transport stream in the **Output Stream** panel. 2. Find the **Maximum VBR frame period for all IP outputs** property, either in the **Mux** tab of the **Properties** panel or in the **Advanced Settings** drop-down panel. 3. Set the **Maximum VBR frame period for all IP outputs** property to the desired value in milliseconds. ### To configure the number of TS packets per IP frame: 1. Click on the transport stream in the **Output Stream** panel. 2. Find the **Number of TS packets per IP frame** property, either in the **Mux** tab of the **Properties** panel or in the **Advanced Settings** drop-down panel. 3. Set the **Number of TS packets per IP frame** property to the desired value. ## Configuring a virtual component A user can now add component and their descriptors for inclusion in the generated PSI with re-multiplexing and associated input PID. Virtual compoments are present as just another type of component like video and audio. 1. Display services. 2. Click `Edit` icon to edit the service and display parameters. The transport stream parameters display. 3. Select the service, then add and configure a virtual component to the service. ![view ts virtual component sp](/_machine-assets/7afd649d199066ebd588adf3a3e6a1ca2f232dabc62dd3d2bd290a39c49b6c16.png) 4. You can then add a component descriptor as per any other service output. # Interaction with the deployment on a specific server The product is installed as a set of pods running on a k3s deployment in a namespace called mediakind. In the following paragraphs, more information is provided about how to interact with the different microservices composing the product as well as where to find useful information about the installation. Interaction is possible using either the kubectl command line tool or the k9s environment tool. - For more details about the usage of the kubectl tool, please refer to the official documentation available here: - For more details about the usage of the k9s tool, please refer to the official documentation available here: ## Monitor the status of microservices The product is composed of a set of microservices. Faults in any of them may result in misbehavior and affect customer operations. 1. Login on the server where the product is installed. 2. Switch to user mediakind (for password information, ask MediaKind support): su - mediakind ### Using kubectl 1. Type `kubectl get pods -n mediakind | grep stream-processor`. A list of pods appears with some information associated to each of them: name, ready, status, restarts, age. ![1 using kubectl](/_machine-assets/2322c6c09c714dfff0241238b3617087054ba1fa08e21dc48bd9c3bcb9595bf7.jpg)

The installation of the stream-processor-asi and the stream-processor-simulcrypt controls is optional. They should not be present on your system unless you have chosen to install them and executed the additional installation steps as described in the installation guides.

2. Verify that the status is “Running” for all the pods. If this is not the case, the system may not behave as expected. If any of the pods is not in “Running” state, type any or all of these commands to help you understand what is wrong: - kubectl get pods -n mediakind: Get the status of all the pods running on the server. It may be that some other microservice is also not in “Running” state. - kubectl describe pod -n mediakind `: ` is the name of the pod that is not in “Running” state. Check the last part of the information. It can contain a list of warning or error events. ### Using k9s 1. Type `k9s`. An interactive user interface appears. It can contain different information depending on whether it is the first time that the k9s runs on the server or not. 2. Type `:namespaces`. 3. Press **Enter**. ![2 using k9s monitor1](/_machine-assets/3b25e02caea971f7894a29568f923fb437d84fed393e50c82a2d16dba9f7922c.jpg) 4. Use the **down arrow** key to highlight the line containing the string mediakind. 5. Press **Enter**. The user interface shows the complete list of pods running in the mediakind namespace. To check the status of the stream-processor pods, use the **down arrow** to scroll down until the group of pods starting with stream-processor appears. ![3 using k9s monitor2](/_machine-assets/6c8230c8e16cf1e82976145f5d4ca9e348192f0f8ace37b0a773e66f617ea89c.jpg)

The microservices listed on your installation may be a subset of the ones in this image. The installation of the stream-processor-asi and the stream-processor-simulcrypt controls is optional. They should not be present on your system unless you have chosen to install them and executed the additional installation steps as described in the installation guides.

6. Verify that the status is “Running” for all the pods. If this is not the case, the system may not behave as expected. If any of the pods is not in “Running” state, try the following to help you understand what is wrong: 1. Use the **up arrow** and **down arrow** keys to scroll the list of all the pods and check if any other microservice is also not in “Running” state. 2. When the line containing the name of the pod is highlighted, press the **d** key. A description of the pod appears. 3. Use the **down arrow** key to scroll down and check the last part of the information. It can contain a list of warning or error events. 4. To exit from the pod description, press the **Esc** key. ## Get the logs from a specific service 1. Login on the server where the product is installed. 2. Switch to user mediakind (for password information, ask MediaKind support): `su - mediakind` ### Using kubectl 1. Type `kubectl get pods -n mediakind | grep stream-processor`. A list of pods appears with some information associated to each of them: name, ready, status, restarts, age. ![1 using kubectl](/_machine-assets/2322c6c09c714dfff0241238b3617087054ba1fa08e21dc48bd9c3bcb9595bf7.jpg)

The installation of the stream-processor-asi and the stream-processor-simulcrypt controls is optional. They should not be present on your system unless you have chosen to install them and executed the additional installation steps as described in the installation guides.

2. Type `kubectl logs -n mediakind ` where `` is the name of the pod associated to the microservice of interest as it appears in the output of the previous command. - For most microservices, the output contains the logs for the (single) container running in the pod. For the mux pod, add -c mux to get the logs from Mux or to get the logs from PSI. - The output of the kubectl logs command can be easily used as input into less, grep, sed or other string/stream manipulation commands. - It is possible to also use the bark utility installed by default with the host application: `kubectl logs -n mediakind | bark` to increase readability of the kubectl logs output. ### Using k9s 1. Type `k9s`. An interactive user interface appears. It can contain different information depending on whether it is the first time that the k9s runs on the server or not. 2. Type `:pods`. 3. Press **Enter**. 4. Use the **up arrow** and **down arrow** keys to scroll through the list and highlight the microservice of interest. 5. Press **Enter**. The list of containers running in the pod appears. Usually, there is only one container per pod, but some microservices have more. For example, the stream-processor-mux pod runs two containers. In this case, the user interface looks as follows: ![4 using k9s getlogs](/_machine-assets/2d9619a58a8384b58f813067975f6d61421f716447d00ad288005bb66fcd2eee.jpg) 6. If more than container is available, use the **up arrow** and **down arrow** keys to highlight the container of interest. Otherwise, the one container of the pod will already be highlighted. 7. Press the **l** key. The logs for the microservice appears.

The CTRL+L option may also be available. It can provide logs in a more readable format.

8. To exit the logs screen, press the **Esc** key. To return to the pods list, press the **Esc** key again. ## Restart a microservice The product microservices run as pods on the k3s deployment. The k3s framework ensures that all the required pods are always running. To restart a microservice, you only need to delete the corresponding pod. The k3s framework will restart it. 1. Login on the server where the product is installed. 2. Switch to user mediakind (for password information, ask MediaKind support): su - mediakind ### Using kubectl 1. Type `kubectl get pods -n mediakind | grep stream-processor`. A list of pods appears with some information associated to each of them: name, ready, status, restarts, age. ![1 using kubectl](/_machine-assets/2322c6c09c714dfff0241238b3617087054ba1fa08e21dc48bd9c3bcb9595bf7.jpg)

The installation of the stream-processor-asi and the stream-processor-simulcrypt controls is optional. They should not be present on your system unless you have chosen to install them and executed the additional installation steps as described in the installation guides.

2. Verify that the status is “Running” for all the pods. If this is not the case, the system may not behave as expected. 3. Type `kubectl delete pod -n mediakind` where `` is the name of the pod associated to the microservice of interest as it appears in the output of the previous command. For example, to delete the mux pod in the previous deployment, you need to type `kubectl delete pod stream-processor-config-8774bf6c-8gwkr -n mediakind`. The string pod `` deleted appears, which means that the pod has been successfully deleted. 4. Type `kubectl get pods -n mediakind | grep stream-processor` again to check that a new pod for the microservice is running. The full name of the new pod is different than the previous one. After the Mux pod has been deleted from the previous deployment, the new name can be “stream-processor-mux-c6f5f5579-f82mz”. ### Using k9s 1. Type `k9s`. An interactive user interface appears. It can contain different information depending on whether it is the first time that the k9s runs on the server or not. 2. Type `:pods`. 3. Press **Enter**. A list of all the pods appears. 4. Use the **down arrow** key to highlight the name of the pod of the microservice of interest. 5. Press **CTRL+D**. A popup window appears and asks to confirm. ![5 using k9s restart](/_machine-assets/6b445899b83864aa799c4b567088992c8c9ee886704f118359206404907171b0.jpg) 6. If you want to cancel the operation, press **Enter**. If you want to confirm, use the **right arrow** key to highlight the **OK** option and press **Enter**. A new pod appears for the microservice. The status of the current pod shows briefly as “Terminating”, then the corresponding line disappears. 7. Verify that the status of all the microservice is “Running”. It means that the system is healthy. ## Check and edit the configuration of microservices The behavior of each stream-processor microservice depends not only on the configuration chosen for the Multiplexing service (on the user interface or through the API) but also on a set of microservice-specific configuration parameters. In other types of deployment, these could be available through config and/or ini files. In this deployment, for each microservice, these parameters are stored in the corresponding configmap. To view and change them, you can use either the kubectl command line tool or the k9s environment tool. Such configuration parameters include, for example: - the announcer addresses used for redundancy by the biss-ca, simulcrypt, statmux and Mux microservices; - the advanced Mux configuration parameters not exposed in the user interface but available in the “mpeg4.cfg” configuration section.

Any configmap change on your server is only applicable for the server where it is applied. If you need the same change on other servers, connect to the specific server and perform the same changes. The changes will persist across the restarts of the same microservice, but will NOT persist if a new version of the product is installed on your server.

### Using kubectl ### To view a specific microservice configuration: 1. Type `kubectl get configmap -n mediakind | grep stream-processor`. A list of configmaps appears with some information associated to each of them: name, ready, status, restarts, age. ![1 using kubectl](/_machine-assets/2322c6c09c714dfff0241238b3617087054ba1fa08e21dc48bd9c3bcb9595bf7.jpg)

The installation of the stream-processor-asi and the stream-processor-simulcrypt controls is optional. They should not be present on your system unless you have chosen to install them and executed the additional installation steps as described in the installation guides.

2. Type `kubectl get configmap -n mediakind -o yaml` where `` is the name of the configmap associated to the microservice of interest as it appears in the output of the previous command. The output contains all the configuration parameters for the specified microservice. To check the announcer muticast information for the Mux microservice, type `kubectl get configmap -n mediakind stream-processor-mux-config -o yaml` and search for the `announcer` part of the `sparkmuxIni.json:` section. It should look like this, but with a different value for the `multicastAddr` field, depending on your deployment and installation options: ![7 using kubectl edit configuration2](/_machine-assets/165755cb7da07b82ba352e317ae70093ead95c8cf957a7e64d02666945e8ac0e.jpg) ### To edit a specific microservice configuration: 1. Type `kubectl get configmap -n mediakind | grep stream-processor`. 2. Type `kubectl edit configmap -n mediakind ` where `` is the name of the configmap associated to the microservice of interest as it appears in the output of the previous command. The configmap is now open in vi editor and can be edited. 3. Apply your changes and save the configmap. 4. Restart the microservice.

Although the changes have been saved in the configmap and can be viewed, they will not be applied by the microservice code until it is restarted.

### Using k9s ### To view a specific microservice configuration: 1. Type `k9s`. An interactive user interface appears. It can contain different information depending on whether it is the first time that the k9s runs on the server or not. 2. Type `:configmaps`. 3. Press **Enter**. A list of all the configmaps appears. 4. Use the **down arrow** key to highlight the name of the configmap of the microservice of interest. 5. Press **Enter** to view its content. To check the announcer multicast information for the Mux microservice, use the **up arrow** and **down arrow** keys to highlight the stream-processor-mux-config: ![8 using k9s edit configuration1](/_machine-assets/7d64ffebaf9c00cf78e5a81674ba1aa8cf18a4ae73122681c891f01c0cf44898.jpg) Then press **Enter** and use the **down arrow** key. It should look like this, but with a different value for the “multicastAddr” field, depending on your deployment and installation options: ![9 using k9s edit configuration2](/_machine-assets/831e2afff7333ea3b3e28c9383443e5b59d087d9bb55380158ed42c1f8d8339d.jpg)

To exit the configmap content view and return to the list of configmaps, press the Esc key.

### To edit a specific microservice configuration: 1. Type `k9s`. An interactive user interface appears. It can contain different information depending on whether it is the first time that the k9s runs on the server or not. 2. Type `:configmaps`. 3. Press **Enter**. 4. Use the **down arrow** key to highlight the name of the configmap of the microservice of interest. 5. Press the **e** key. The configmap is now open in vi editor, and can be edited. 6. Apply your changes and save the configmap. 7. Restart the microservice.

Although the changes have been saved in the configmap and can be viewed, they will not be applied by the microservice code until it is restarted.

## Further interaction with your k3s deployment You can use kubectl or k9s to get additional information about your deployment status and configuration. Here are a few examples of useful operations, assuming that the user is now familiar with either tool. - Check the version of a specific microservice: if the user interface is not available, it is possible to see the version of the microservices and all the containers by accessing their deployment. - `k9s: deployments:, **d**` (describe) - `kubectl: kubectl get deployments -n mediakind, kubectl get deployment -n mediakind -o yaml` - Save the deployment or configmap for a microservice as yaml to file for later comparison with configuration on other servers ## Check latest installation options To check the options used for the last product installation: 1. Check the version of the product currently running on your server (either using the user interface or the kube commands). 2. Navigate to the `/var/install` folder and list its content: ``` cd /var/install ls ``` You see at least one subfolder named `stream-processor-xxx` where xxx is the version of the installed product. If you have installed different versions, you may see a few similar folders. 3. Navigate to the `stream-processor-xxx` folder corresponding to the version currently running. It contains a subfolder called either standalone, controller, compact or server, depending on the type of installation (see the installation guides for details). 4. Navigate to the subfolder. 5. Read the previous installation parameters from the `last_configure.sh` file: ``` cat last_configure.sh ``` # Service Monitoring ## Monitor service alarms The MediaKind user interface allows you to access active and cleared alarms list for each service. 1. Go to the Services page. 2. Identify the service that you want to monitor and click the related `Alarm` icon icon in the **info** column. Depending on the severity of the alarm, the `Alarm` icon will appear in different colors and will display the most severe color alarm in case of multiple alarms. - red: critical alarm - orange: major alarm - blue: minor alarm - grey: notice alarm The following page displays. ![Services multiplexer alarms](/_machine-assets/b9bfd73e3d248f9bd1034087c38fe0d867c7c908219accdb630838857af531b8.png) From this page, you can access the following information: - The active alarms table applied on the current server including: - date and time of the alarm rise - alarm description (label) - alarm severity - detailed information - The alarm history table including: - date and time of the alarm rise - alarm description (label) - alarm status - alarm severity - server on which the service was applied when the alarm raised. - detailed information

The alarm tables display up to 10 alarms per page. Use the arrows or page number at the bottom of the table to navigate through the complete alarms list.

## Monitor service statistics When a multiplexer configuration is running, you can retrieve and monitor on MediaKind user interface detailed statistics information. 1. From the **Services** page, identify the service that you want to monitor and click the related `Pie chart` icon icon in the **Stats** column.

The Pie chart icon is only accessible when an encoder configuration is associated to a server and then running.

The **Statistics** page displays. 2. You can navigate between two tabs: **Overview** and **Input**. ### Overview From the **Overview** tab, you can view the following information for each program: - Multiplexer Graphs (one graph per processing server) - Multiplexer statistics: - MPTS Output - Active/Passive state of the IP output - Info - Bitrate (in bps) - FEC Bitrate (in bps) - CC errors - Dropped packets Additionally, the following actions can be taken in this page: - Customise the data displayed in the graphs by clicking the labels in the graph legend. - Customise the information displayed such as activating or deactivating the input statistics by clicking the toggle button _Inputs displayed_. - View detailed per PID information by expanding the available information in the _Multiplexer Statistics_ table using the arrow buttons under the _MPTS Output_ column. - Reset the current statistics displayed in _Multiplexer Statistics_ table using the buttons under the _Actions_ column. - Change the active Mux, when Active/Standby mode has been enabled, using the buttons under the _Activate_ column. ![MFVP SP service statistics mux graphs](/_machine-assets/dd8b73ebcb60e057e0b77886ced621a867268e3dd9b1cf9be75ff310eff04d52.png) ### Statistical bit rate allocation

The Statistical bit rate allocation tab is only available when statmux is enabled at the service level.

From the **Statistical bit rate allocation** tab, you can view the following information for each program: - **Statmux pool graph** Display options: - Select the statmux pool to display amongst the pools available. - Select the type of view to display (Line graph or Pool bitrates). - Select the video and audio components to display on the graph (all are activated and visible by default). - **Statmux pool table** The table shows the active/passive status of the servers used for the statmux setup. - Click the button in the Actions column to change the active server: - Click the button in front of the server line to cause it to become active for all statmux pools. - Click the button in front of a statmux pool to activate it in the corresponding server. - Click the `Play` icon button to display detailed information about the statmux group: - Service name or ID - Codec - Priority - Bit rate (min/max) - Resolution - Total bitrate - Video bitrate - Audio bitrate - Private bitrate ![MFVP SP service statistics statmux](/_machine-assets/4805e04e792922e6fe2bc9dab9f8341111c5e730c3cccc209d31bbb1ad9d3335.png) ### Input From the **Input** tab, you can view the following information: - Input sources information, especially service name, input source IP address and Multiplexer IP address. - RTP quality indicators - FEC quality indicators ![SparkSE Stats input](/_machine-assets/73646bf270a6ff97a520469e4d730b374a07ff92c9befee30945fd9a916c282a.png "Service Statistics - Input page") **Tip:** You can refresh the statistics displayed by clicking the ![Stats AutoRefresh button](/_machine-assets/7072394f8a848dc26f0d1b364cb6161f05a68f8b52898f60aa8abdc48f4e63ee.png) button. ### Bandwidth Policing From the **Bandwidth Policing** tab, you can view the following information: - Bandwidth Policing Groups Bitrate Graphs. ![MFVP SP BPC stat graph2](/_machine-assets/3ebc73de2829d22692549516cf749ff0d89c267b495440c80cc493afea07ec92.png) The page will display 1 or 2 graphs depending on the number of servers assigned for the given service. **Tip:** You can filter the information displayed by selecting the Bandwidth Policing Group and the PID to display. - Bandwidth Policing Groups Statistics. ![MFVP SP BPC stat table](/_machine-assets/aa806d52c7e2d3fa63ff02c917e5d84a19316b7e1e151286c6eeb06a67eec760.png) **Tip:** You can refresh the statistics displayed by clicking the ![Stats AutoRefresh button](/_machine-assets/7072394f8a848dc26f0d1b364cb6161f05a68f8b52898f60aa8abdc48f4e63ee.png) button. # Notes about Multiplexer parameters Multiple definitions may exist for the same parameter name. For example, parameters may have the same name but are used in different configuration contexts. All Parameters followed by an asterisk (\*) in the UI are mandatory. Default values, if any exist, are already supplied in the UI. # Scrambling Tab This tab allows to enable scrambling via external Eis. By default, scrambling via Eis is disabled for multiplexing services. ![Mux Scrambling Tab](/_machine-assets/7b43af7d7dd3dfc781658ba8d4feffe63342a25c57485127ac102ffc240ffacd.png) To enable scrambling via External Eis tick the corresponding box.

Existing SCGs will be disabled on any output where external Eis is enabled.

## Scrambling Group Properties These settings are only for advanced configurations. Default values should be suitable for the majority of use cases. ![Mux Scrambling Tab scrambling group](/_machine-assets/2356db3109f82382c395cf089cc2dff4a8a6d5f601fca3e0d81e62033fd5bfb4.png)
Parameter name Description Possible values
Minimum bitrate modifier Controls the next minimum bitrate for each statmux interval. Lower values results in faster bitrate decrease Floating point values between 0.1 and 1
Scrambling Algorithm* Chosen Scrambling Algorithm Version. Changing it on a running service requires a service restart. Dropdown menu: CSA V1 48bits, CSA V2 64bits, BISS Mode1, BISS Mode2, CISSA V1 TS Level, CISSA V1 PES Level, AES-ECB, BISS CA, Director 6
Behaviour until all required ECMs for SCG first received Choose how to output until all scrambling information is available. Dropdown menu: Component(s) in SGC not present in output TS, Component(s) in SCG in-the-clear inn output TS
## Scrambling Vendors Parameters To add information about a vendor, click on the corresponding **+ Add Vendor** button. ![Mux Scrambling Tab scrambling vendors](/_machine-assets/6a5392e77f09bf1687cb8f680f0f85222cff61885d1c4a55ea5f6cb043a41426.png)
Parameter name Description Possible values
Name* Name of the vendor. When the configuration is saved, the name will appear as title of the vendor panel. You can use the arrow on the right to collapse or expand the panel for easier management of multiple vendors configuration. String of max 32 characters
Details about the parameters available for the different tabs in the following paragraphs. ### ECMG parameters ![Mux Scrambling Tab scrambling vendors ECMG](/_machine-assets/b009f2bf9598571e52ac562cc23a36a80b4f508bb5e022ce240c7349afb8c4a6.png)
Parameter name Description Possible values
Network interface Name of network interface used for the ECMG communications String of max 32 characters
Primary address* An IPv4 address for the primary ECMG IPv4 address string
Primary port* Port number for the primary ECMG 0 to 65535
Secondary address An IPv4 address for the optional secondary ECMG IPv4 address string
Secondary port Port number for the optional secondary ECMG 0 to 65535
Super CAS ID* As per ETSI 103197 DVB Simulcrypt. Hexadecimal format. From 0 to 4294967295
CA descriptor location* The location in the PMT for the CA descriptor that describes the ECM streams Dropdown menu: Service, Component
#### ECMG Advanced Settings These settings are only for advanced configurations. Default values should be suitable for the majority of use cases. ![Mux Scrambling Tab scrambling vendors ECMG advanced](/_machine-assets/5204469aa1cb3a4cd6f7f8a47bbbe4252941661090f85b673b910cf877625f13.png)
Parameter name Description Possible values
EIS ECM ID To PID Mappings Comma-separated list of ECM IDs to PIDs. The ID is the field position unless specified. Example: 200,201,3:400,5-10:500 would map ID->PID: 0->200, 1->201, 3->400, [5,10]->500 String of max 32 characters
### EMMG parameters ![Mux Scrambling Tab scrambling vendors EMMG](/_machine-assets/83441b69878045ebae961b2358c46935ddc3d6bc95c6b58cde26b067ace8498e.png)
Parameter name Description Possible values
Network interface Name of network interface used for the CA communications String of max 32 characters
TCP Port* TCP port for EMMG traffic 0 to 65535
Destination UDP port* Destination UDP port for EMMG traffic 0 to 65535
Client ID* As per ETSI 103197 DVB Simulcrypt. Hexadecimal format. From 0 to 4294967295
Automatic Will accept the first connection request from the EMMG regardless of Channel or Stream ID Tick box, checked by default.
Input Bitrate Limit* Limit to the incoming bitrate (only present when Automatic is not checked) From 1 to 4294967295
#### EMMG Streams Configuration Settings If the **Automatic** tickbox is unchecked the following table will appear, which will allow to add and remove EMMG streams configurations. ![Mux Scrambling Tab scrambling vendors EMMG stream config](/_machine-assets/1444abb4aa03ddc448c7bbcfcfa577fab8a83f0e8b24ccb2d482e1affa0f2137.png) For each EMM stream the following parameters are available:
Parameter name Description Possible values
Name Name of network interface used for the CA communications String of max 32 characters
Channel Channel identifier as per ETSI 103197 DVB Simulcrypt From 0 to 4294967295
Stream Stream ID as per ETSI 103197 DVB Simulcrypt From 0 to 4294967295
Input Bitrate Limit Limit to the incoming bitrate From 1 to 4294967295 ????
#### EMMG Advanced Settings These settings are only for advanced configurations. Default values should be suitable for the majority of use cases. ![Mux Scrambling Tab scrambling vendors EMMG advanced](/_machine-assets/c9969d18368c685630109045ac51cfb17f129366c09643bde6dc1c1dfb37f94b.png)
Parameter name Description Possible values
Ingest buffer duration At steady state how long EMMs should sit in the ingest buffer before being played. This is for smoothing the playout. from 0.001 to 30 seconds
### ECMG Override parameters ![Mux Scrambling Tab scrambling vendors ECMG override](/_machine-assets/9e2f1587b847c6a22c5ce254208710a1878196b3e9ddf84ced111acde6ba3cf8.png)
Parameter name Description Possible values
Override ECMG transition delay When this tick box is enabled, the subsequent parameters Transition delay start and Transition delay stop are used to override the transition delay information in the ECMG Tick box, disabled by default
Transition delay start Transition delay start in ms From -6000 to 6000 ms
Transition delay stop Transition delay stop in ms From -6000 to 6000 ms
ECM delay start/stop When this tick box is enabled, the subsequent parameters ECM delay startand ECM delay stop are used to override the ECM delay information Tick box, disabled by default
ECM delay start ECM delay start in ms From -6000 to 6000 ms
ECM delay stop ECM delay stop in ms From -6000 to 6000 ms
AC delay start/stop When this tick box is enabled, the subsequent parameters AC delay startand AC delay stop are used to override the AC delay information Tick box, disabled by default
AC delay start AC delay start in ms From -6000 to 6000 ms
AC delay stop AC delay stop in ms From -6000 to 6000 ms
Override Max Comp Time When this tick box is enabled, the subsequent parameter Max Comp Time is used to override the value of Max Comp Time Tick box, disabled by default
Max Comp Time The maximum processing time for ECM CW provisioning. If increasing ensure CP duration is still greater than the new value. From 1 to 60000 ms
### PDG parameters ![Mux Scrambling Tab scrambling vendors PDG](/_machine-assets/d06f84de63753691db33f2799f23d86e8ccc77987bafa3200cff1d688ef5ea9f.png)
Parameter name Description Possible values
Network interface Name of network interface used for the PDG communications String of max 32 characters
TCP Port* TCP port for PDG traffic 0 to 65535
UDP port* Destination UDP port for PDG traffic 0 to 65535
Client ID* As per ETSI 103197 DVB PDG. Hexadecimal format. From 0 to 4294967295
Automatic Will accept the first connection request from the PDG regardless of Channel or Stream ID Tick box, checked by default.
Input Bitrate Limit* Limit to the incoming bitrate (only present when Automatic is not checked) From 1 to 4294967295
#### PDG Streams Configuration Settings If the **Automatic** tickbox is unchecked the following table will appear, which will allow to add and remove PDG streams configurations. ![Mux Scrambling Tab scrambling vendors PDG stream config](/_machine-assets/8eeca62b03fff70097128a74f18efd5cce4c2a258f70faddbaa7767bfc8d3564.png) For each PDG stream the following parameters are available:
Parameter name Description Possible values
Name Name of network interface used for the CA communications String of max 32 characters
Channel Channel identifier as per ETSI 103197 DVB PDG From 0 to 4294967295
Stream Stream ID as per ETSI 103197 DVB PDG From 0 to 4294967295
Input Bitrate Limit Limit to the incoming bitrate From 1 to 4294967295
# Statistical Multiplexing Tab By default, statistical multiplexing is disabled for multiplexing services. To enable Statistical Bitrate allocation, tick the corresponding box. To add additional statistical multiplexing pools, click the _Add Pool_ button. ![Mux Statmux Tab](/_machine-assets/ef7e2ffe6ebeba4d1300e75ac2995184029f794109b2799a1cdbb4cd2fc88b5e.png) ## Statmux Advanced Settings These settings are only for advanced configurations. Default values should be suitable for the majority of use cases. ![Mux Statmux Tab advanced](/_machine-assets/ecac1bad276e9b0ef4eb2dd1dafca9bd2b2b26b3f1ad8d276eb3927d29d09d48.png)
Parameter name Description Possible values
Minimum bitrate multiplier Controls the next minimum bitrate for each statmux interval. Lower values results in faster bitrate decrease Floating point values between 0.1 and 1
Priority rate factor Adjusts the strength of the priorities rate factor. Higher values result in greater differences between the allocated bitrates for different levels of priority. Floating point values between 0.1 and 1
Show service names on statmux graph Causes the statmux statistics page to display the encoding live service name instead of the Channel Id. Tickbox, enabled by default
{/\* This will change at some point, once EL makes that advanced parameter default. \*/}

For encoding live service names to be showed in the statmux statistics page, tick the Service name in profile name parameter checkbox in the Live encoder configuration.

## Specific Pool Settings To add pools, click the corresponding button. For each pool, the following parameters must be specified:
Parameter name Description Possible values
Name Unique name of the pool for this service. String of max 32 characters
Bitrate Bitrate allocated to the current pool 0 to 200000000 bps
Primary Network Interface Specifies the interface (as seen by the operating system) used to communicate with members of the statmux group. String of max 32 characters
Secondary Network Interface (Optional) Specifies a secondary, redundant, interface used to communicate with members of the statmux group. String of max 32 characters
Video Only Specify if only Video components are to be included in the statmux pool. Dropdown menu: Off, On
# Stream Processing tab ## Transport Stream properties ### Mux Parameters ![Mux SP Tab Transport Stream Properties Mux](/_machine-assets/29d137261c253fdcd60b986c71fc0bf0f326488c70454596c7430eece1259253.png)
Parameter name Description Possible values
Total Bitrate* The total bitrate of a CBR TS, or the maximum bitrate of a VBR TS. Nulls are inserted into a CBR TS to maintain the total bitrate. 0 to 200000000 bps
Minimum Null Bitrate* Minimum null bitrate. If component bitrate + null bitrate > total bitrate then packets will be discarded. Note that nulls will not appear in a VBR TS. 0 to 200000000 bps
Transport Stream ID* Sets the Transport Stream ID in the output PAT, SDT and NIT (if enabled). 0 to 65535
Original Network ID* Sets the Original Network ID in the output SDT and NIT (if enabled). 0 to 65535
Source Redundancy Mode See redundancy mode paragraph. Dropdown menu: Automatic no monitoring, Manual no monitoring, Automatic with monitoring, Manual with monitoring
IP Active/Standby Enable Active/Standby for IP output. Tick box, disabled by default
Scramble transport stream packets containing a PES header TS packets containing a PES header are scrambled if scrambling is required for the current service. Tick box, enabled by default
#### Mux Advanced Settings These settings are only for advanced configurations. Default values should be suitable for the majority of use cases.
Parameter name Description Possible values
Input jitter buffer latency The latency on each input used to absorb input jitter. Requires a service restart to apply. Reducing this value can reduce the latency of the service in the multiplexing stage. However, depending on the service configuration (FEC and or RTP enabled) and on the input bitrate, reducing this value could lead to insufficient buffering available for the muxing process. In such case, an alarm will be raised to notify about possible problems in the output stream. 10 to 30000 ms
Scrambling latency The added latency during which scrambling occurs. 10 to 30000 ms
ASI Active/Standby Whether ASI outputs should stop when in standby or not. Tick box
Copy SDT as SDT Other Controls which other transport streams will receive a copy of the SDT Dropdown menu: To all networks, To same network, Do not copy
Hide transport stream Hide this transport stream in the NIT included in other transport streams of the same DVB network Tick box
ASI output buffer latency The output latency added when using ASI. Applies only to DekTec 2174b and 2178 cards when being used for ASI output. Latencies below 50ms are not recommended. 10 to 30000 ms
IP output buffer latency The IP output latency. 10 to 30000 ms
TS mode for all IP outputs Controls whether the TS for all IP outputs is CBR or VBR. For VBR TS, the maximum VBR frame period applies, and non-zero minimum null bit rates will not result in nulls in IP outputs.
Note that a VBR TS will be invalid if it contains multiple referenced PCR PIDs.
The TS mode for ASI outputs is always CBR.
See Configuring the transport stream mode for IP outputs for more information.
Dropdown menu: CBR, VBR - SMPTE ST 2022-3 (Single referenced PCR PID only)
Maximum VBR frame period for all IP outputs (ms) The maximum time between VBR frames for all IP outputs. Enforces a minimum VBR frame rate. Only applies if TS mode is VBR, and increases latency for IP outputs. Lower periods result in more nulls in IP outputs.
See Controlling latency for VBR TS IP outputs for more information.
10 to 30000 ms
Number of TS packets per IP frame The number of TS packets per IP frame. Applies to all IP outputs.
See Controlling latency for VBR TS IP outputs for more information.
1 to 7 packets per frame
### Output Parameters #### IP ![Mux SP Tab Transport Stream Properties Output](/_machine-assets/c548109d8e5504148ccce0121c432198f76d81232a20484dc920c302c48d36bf.png)
Parameter name Description Possible values
Output Name* Used to identify the specific output String of max 32 characters
Type Select the output type Dropdown menu: IP, ASI, RIST
Network interface Name of network interface used for the output transport stream (as seen by the operating system). String of max 32 characters
Stream Address* Unicast or multicast destination IPv4 address for the Transport Stream packets IPv4 address
Destination UDP port* Destination port for the Transport Stream packets 0 to 65535
User-specified source details If unticked, the output transport stream source IP address will be the IP address of the specified Network interface.
Otherwise, the source IP address field and source UDP port field of the output IP packet headers will be populated with the user-specified source IP address and source UDP port regardless of the IP address of the specified Network interface.
The specified Network interface will not respond to ARP or PING on a user-specified source IP address (unless the user-specified source IP address is the same as the specified Network interface).
If ticked, Source IP address and Source IP port field will be required (respectively, IPV4 address and value between 0 and 65535)
Time to live Sets the IPv4 Time To Live field (maximum number of routersa multicast packet can reach before being discarded) 0 to 255
IP encapsulation Type of IP encapsulation. E.g., FEC packets can be generated to protect the media packets. Dropdown menu: UDP, RTP, FEC
Server filter Assigned servers matching this pattern will output using these settings. * = wildcard of any length. For example: s*1 would match 'server 1' and not 'server 2' String of max 32 characters
Output in the clear Output all components in the clear. Overrides SCG config. Tick box, disabled by default
#### ASI If ASI mode is selected, the available configuration parameters will be as follows. ![Mux SP Tab Transport Stream Properties Output ASI](/_machine-assets/b402ecb831a5bfa15a41975c5c008a56f371c08d0c7dd5873fecf2df0f54fd66.png)
Parameter name Description Possible values
Output Name* Used to identify the specific output String of max 32 characters
Type* Select the output type Dropdown menu: IP, ASI, RIST
Connector(s)* [ASI only] Specify one or more ASI card connectors to output this Transport Stream on. ASI connector configuration is covered in ASI Card Configuration Tool Comma-separated list of integers greater than zero
204 Byte Packet Length [ASI Only] Changes ASI output from 188 to 204 byte packets. Requires a service restart to apply. Tick box, disabled by default
Server filter Assigned servers matching this pattern will output using these settings. * = wildcard of any length. For example: s*1 would match 'server 1' and not 'server 2' String of max 32 characters
Output in the clear Output all components in the clear. Overrides SCG config. Tick box, disabled by default
#### RIST If RIST mode is selected, the available configuration parameters will be as follows. ![Mux SP Tab Transport Stream Properties Output RIST](/_machine-assets/e29e911b2d1873712cddf9b77217b1801f71fb487f7ecccc3ce8acddd910c27a.png)
Parameter name Description Possible values
Output Name* Used to identify the specific output String of max 32 characters
Type* Select the output type Dropdown menu: IP, ASI, RIST
Mode* Configures the RIST output to operate in either Listener or Caller mode. Dropdown menu: Listener, Caller
Network interface In RIST Listener mode, the interface to listen on. Not available for Caller mode. String of max 32 characters
Listener Address* In RIST Caller mode, configures the address of the remote RIST Listener to connect to. IPv4 address
Listener Port* Configures the port to either listen on or call, in Listener and Caller mode respectively. 0 to 65535
Maximum Caller Connections If Listener mode is selected, configures the maximum allowed connections to the RIST output. 1 to 65535
### PSI SI Parameters ![Mux SP Tab Transport Stream Properties PSI SI](/_machine-assets/744778a329fc15ca104485433de257a9db41ea05ebeab12fbe10976293a55906.png) If the Enable or disable PSI SI tick box is enabled (default), it is possible to override the repetition rate (in ms) for any of the listed tables. ### Bandwidth Policing Parameters ![Mux SP Tab Transport Stream Properties BP](/_machine-assets/2593173ccbeaf848b5ebffa0afc00458e980ca3f3fb71c47ed93898c45993aaa.png) Use the **Add Group** button to add as many groups as needed. Use the `Delete` icon button on the right to remove a group. For each added group, the following parameters will be required:
Parameter name Description Possible values
Name* Used to identify the specific bandwidth policing group String of max 32 characters
Bitrate Maximum bitrate allowed for the group. If the total bitrate of the components in the group exceeds this value, packets will be dropped and alarms raised. 0 to Total Bitrate (as set in the Mux parameters)
## TOT and NIT Properties ### TOT TOT: no configuration parameters available. ![Mux SP Tab TOT](/_machine-assets/c6e8560f90bf8048b44f22738543161d1a7a5b8edcd218615fe692d5f2045e1b.png) ### NIT ![Mux SP Tab NIT](/_machine-assets/b2667bf19a11d26680d1dbbc6afc884cd46cf5dad3eb86b60c57f1d9c8ab4fb5.png)
Parameter name Description Possible values
Network ID* Sets the Network ID used in the output NIT (if enabled) 0 to 65535
## Service Properties ### Output parameters ![Mux SP Tab services output](/_machine-assets/aec5807a63c2dc362b0ae644ca79fd4072c3ec05fdf41d4ce52aad604197123a.png)
Parameter name Description Possible values
Name A user-friendly name for the service. Note that this is not the Service Name, which must be configured via the Service Descriptor. String of max XX characters
Program Number* Program Number used to populate the output PMT and ServiceID in the SDT 1 to 65535
PMT PID* Output PMT PID 0 to 8190
Logical Channel Number Sets the Logical Channel Number in the NIT (if NIT is enabled and the Logical Channel Descriptor is present).
Values above 1023 are only allowed if the descriptor specifies the NorDig range.Leave blank if not required.
1 to 16383
PCR Component Dropdown menu: Auto, Manually specified PID, None
Regenerate Descriptor Dropdown menu: On, Off
Service Passthrough Automatically add components and descriptors from the specified input service to this output service. If the specified input service cannot be found, there will not be an output PMT or PAT reference. This behaviour is dynamic and the output PAT/PMT references will track changes to the incoming service. Dropdown menu: Off, On
Input Program Specifies the input Program Number to search for the incoming PMT in order to find the required input Service 0 to 65535
If Service Passthrough is set to **On**, additional configuration parameters will be available: ![Mux SP Tab services output passthrough](/_machine-assets/d89bba0afa2e5f4be4616375d44ef8d1dcd6ff45540e1903a981bf32ebdb3c61.png)
Parameter name Description Possible values
Dropped PIDs Comma separated list of PIDs which will not be passed through to the output service
Monitor health of all signalled input components Health of all signalled components in source PSI/SI will be monitored. If Source redundancy mode is not manual, health failure of any of these components will result in a source switch if a healthy alternative is available Tick box, disabled by default
Bandwidth Policing Group If any Bandwidth Policing Group has been defined for the transport stream (see previous paragraph), the list of all group names will appear as a dropdown menu. Assign the service to one of the groups or leave the selection empty to avoid policing it. Dropdown menu: names of any defined bandwidth policing group.
### Sources parameters Define the parameters for the first input and then use the “+Add” Tab to define more other inputs. For each input, new parameters can be configured manually or, if a source already exist, it can be shared between different services and components. This will be highlighted with red text as in the picture below.

It is recommended to add a User-defined name to the source to make it easily recognizable. The name will also be used to rename the tab.

![Mux SP Tab services output sources](/_machine-assets/b2e475f86fc7bb56e58d9e678edfa2e66c809e6e941f42e2f24a918debdaf406.png)
Parameter name Description Possible values
User defined name for source* Name and also source tab name. This is the identifier of the current input which will also be used, when saving the configuration, to rename the current Source Tab. String of max 32 characters
Type Type of input: IP, ASI or RIST Dropdown menu: IP, ASI, RIST
Lock without seeking input PCR Lock without seeking input PCR Tick box, disabled by default
Output Drop On Input TS Loss If this input transport stream is lost, all the Transport Stream outputs will be stopped. Tick box, disabled by default
IF TYPE = IP (as in the previous figure)
Parameter name Description Possible values
Network Interface Input network interface name specifies the one (as seen by the operating system) used to capture Transport Stream packets. String of max 32 characters
Destination IP Address* Destination IP address used to capture Transport Stream packets IPv4 address
Port* Destination UDP used to capture Transport Stream packets 0 to 65535
FEC Enabled If selected, the IP encapsulation for the input TS is expected to be FEC. When enabled the FEC packets can be used to try to recover missing media packets. Requires RTP. Tick box, disabled by default
Source Address List of comma separated IPv4 addresses used to filter the sources of the current input (based on IGMPv3 protocol). Examples: 172.18.2.39 or 172.18.2.39,172.18.2.40
IF TYPE = ASI
Parameter name Description Possible values
Connector* An ASI connector index, greater than zero. In case of multiple ASI cards available on the same box, this is the logical identifier of the connector (see ASI configuration tool paragraph) 1 to 65535
IF TYPE = RIST
Parameter name Description Possible values
Mode* Configures the RIST output to operate in either Listener or Caller mode. Dropdown menu: Listener, Caller
Network interface In RIST Listener mode, the interface to listen on. Not available for Caller mode. String of max 32 characters
Listener Address* In RIST Caller mode, configures the address of the remote RIST Listener to connect to. IPv4 address
Listener Port* Configures the port to either listen on or call, in Listener and Caller mode respectively. 0 to 65535

Configuration of RIST inputs is only available via the Properties panel.

# Packaging A **packager** takes an encoded video stream and prepares it for delivery across different devices and streaming platforms. It segments the stream into small chunks and generates manifest files that tell the player what is available, at what bitrates, and in what order to request segments. This is the foundation of adaptive bitrate (ABR) streaming, where a player adjusts quality in real time based on network conditions. MK.IO Beam's Packager converts live encoded outputs into HLS and DASH formats, handling the underlying segmentation and manifest generation automatically. ## Output formats - **HLS and DASH over CMAF (Common Media Application Format):** A modern packaging approach where HLS and DASH manifests reference the same underlying media segments, reducing storage and simplifying multi-format delivery. - **HLS over TS (HTTP Live Streaming):** The original HLS format using MPEG-2 TS segments, broadly supported across a wide range of players and devices. Outputs can include encryption and manifest filtering to control which bitrates or tracks are exposed. ## Key concepts **Catalog:** The catalog links outputs to live packaging services. It must be created first to host outputs. Any live packaging service added to a catalog can be delivered by any output in that catalog. **Output:** A set of specific delivery parameters for a defined input stream. It contains processing and encryption parameters and is added to a catalog to serve content to viewers. **Live Packaging service:** Configuration of the live input parameters. Once associated with a catalog, the service is available for delivery using the outputs defined in that catalog. ## DVR and thumbnails Live Packaging services include DVR (Digital Video Recording) configuration, which controls how much of the live stream is held in the sliding window available to the player. Thumbnail generation is also available, providing preview images from the live stream. ## Enabling the Packager The Packager function is not enabled by default on a MK.IO Beam server. You need to enable live packaging in the server's general parameters before creating Packager services. See [Enable Packager](/beam/packager/enable-packager) for instructions. ## Common use cases - Delivering live events over OTT platforms to web and mobile players. - Publishing live channels with DVR for catch-up viewing. - Producing multi-format output from a single live source. To start configuring outputs, see [Manage Catalogs, outputs and thumbnails](/beam/packager/catalog). # Advanced Parameters ## Configuring credentials for direct remote storage access ### Format The file is in the YAML format and located at `/etc/mediakind/mkp/charts/customer-values.yaml`. A specific script must be executed to apply the changes brought to the file that remain after a product update. If no value is specified or if a value is removed from the file, default values from installer are used. Each entry contains the following elements: - `url`: the base URL of a storage. - `type`: the type of credential to be used for this base URL. It can be: - `user` for access with username and password - `s3` for access using AWS S3 object store credentials - `azureSasToken` for access using Blob Azure credential - `certificate` for HTTPS access #### User credential The entry should contain the following elements: - `username` - `password` It can be used for FTP or SFTP access (`ftp://…` or `sftp://…`). ```yaml copy credentials: [ {"type": "user", "url": "sftp://myServer/share1", "username": "test", "password": "1234"} ] ``` #### Blob Azure credential To configure the Azure authentication for your system, the entry in the credential file should contain the following elements: - `url`: URL provided at the Blob storage creation. - `type`: Type of credential to be used for this URL. It must be: `azureSasToken`. - `sasToken`: Token provided at the Blob storage creation. ```yaml copy credentials: [{"type" : "azureSasToken", "url" : "https://myaccount.blob.core.windows.net/mycontainer", "sasToken" : "?sv=2020-02-10&ss=bfqt&srt=o&sp=rwdlacupx&se=2021-02-24T00:46:59Z&st=2021-02-23T16:46:59Z&spr=https&sig=..."} ] ``` #### AWS S3 object store credential This credential corresponds to an AWS access key. The entry should contain the following elements: - `accessKeyId`: The ID of the access key - `secretAccessKey`: The secret access key ```yaml copy credentials: [{ "type": "s3", "url" : "", "accessKeyId" : "", "secretAccessKey":""} ] ``` #### Certificate credentials The entry should contain the following elements: - `certificateFile`: to be defined in client\_crt\_certificate value - `privateKeyFile`: to be defined in client\_key\_certificate value - `privateKeyPassword` ```yaml copy credentials: [ {"type": "certificate", "url": "https://mysecure-webdav.com/secure", "certificateFile": "/tmp/client-crt.pem", "privateKeyFile": "/tmp/client-key.pem", "privateKeyPassword": "xxyyzz"} ] ``` #### Multiple credentials display ```yaml copy credentials: [ {"type": "user", "url": "sftp://myServer/share1", "username": "test", "password": "1234"}, {"type" : "azureSasToken", "url" : "https://myaccount.blob.core.windows.net/mycontainer", "sasToken" : "?sv=2020-02-10&ss=bfqt&srt=o&sp=rwdlacupx&se=2021-02-24T00:46:59Z&st=2021-02-23T16:46:59Z&spr=https&sig=..."}, { "type": "s3", "url" : "", "accessKeyId" : "", "secretAccessKey":""} ] ``` ### Deployment This configuration file should be created by the user and needs to be deployed on every Packager server under the following path: /etc/mediakind/mkp/charts/customer-values.yaml. Once the file `customer-values.yaml` is configured, the following script must be executed to apply the changes: ```shell /etc/mediakind/mkp/charts/apply_customer_values.sh ``` ### Example When a job is created, it will parse this file to find the associated credentials of the file URL it needs to access. For example, if the file contains the following credentials: ```yaml copy credentials: [ {"type" : "user", "url" : "sftp://server1", "username" : "admin", "password":"1234"}, {"type" : "user", "url" : "sftp://server2/share", "username" : "admin", "password":"4321"} ] ``` If a job input file is `sftp://server2/share/video.ts`, the second credential will be used: the input URL matches with the base URL of the second credential.

The selected credentials configuration is logged into the high-level logs of the job.

# Manage catalog, outputs, and thumbnails A catalog is an inventory of one or more outputs on which the following delivery parameters are configured: - **Catalog**'s **name** and **output types** - **Delivery** parameters - **Manifests**' **Filtering** parameters (audio, video and subtitle bitrates) - **Encryption** parameters
Note

At least one output must be configured.

## Creating a new catalog To create a new catalog, follow these steps: 1. Access the MK.IO Beam user interface. 2. Click **Services** in the left panel. 3. Click **Add service** > **Catalog**. 4. Enter the catalog name. 5. Do one of the following: - Click **Save and continue** to complete the catalog creation and start adding outputs. - Click **Save and exit** to save and finalize the catalog creation and go back to the **Services** page. - Click **Cancel** to go back to the **Services** page without saving. ## Adding an output to a Catalog Once created, an output can be used by any Packager service for delivery. #### Two output types are available: To add an output to a Catalog, follow these steps: 1. From the **Services** page, click the **Name** related to the Catalog on which the output will be added. 2. Click **Add new output** then select the output type and configure the parameters according to your needs. - [HLS or DASH over CMAF specific output settings](/beam/packager/hls-dash-over-cmaf-output) - [HLS over TS (HTTP Live Streaming)](/beam/packager/hls-output) 3. **Save** configurations. # Enable Packager in MK.IO Beam To enable the Packager function in MK.IO Beam, follow these steps: 1. Click **Servers** in the left panel. 2. Click the **detail** icon `View` icon in **Actions**. 3. Select the **Enable Live Packaging** check box. This is available under **General parameters**. 4. Once selected, click **Save** to apply the changes. # HLS or DASH over CMAF specific output settings The CMAF (Common Media Application Format) is a fMP4 based format that is used as a common format for both HLS and DASH content delivery. A single copy of the media segments is needed, which leads to significant gains in terms of storage and bandwidth. ## General You can configure for both HLS and DASH: - [General parameters](/beam/packager/parameters/hls-or-dash-over-cmaf) - [DASH Manifests](/beam/packager/parameters/hls-or-dash-over-cmaf#dash) - [HLS Playlists](/beam/packager/parameters/hls-or-dash-over-cmaf#hls) - [Delivery](/beam/packager/parameters/hls-or-dash-over-cmaf#delivery) - [Encryption](/beam/packager/parameters/hls-or-dash-over-cmaf#common-encryption-cenc) ## DASH output type configuration ### Manifests By default, the output manifest is delivered without any specific bitrate filtering. Depending on your delivery needs, you can adjust the bitrate filtering on your manifest and add manifests with variant filtering parameters. **Stream characteristics** filtering for **DASH over CMAF** outputs can be based on: - Bitrate in kbps - for Video/Audio/Subtitle streams filters. ![MFVP stream char filtering bitrate](/_machine-assets/c74639c0664210ffa258f32bdcd906f6345f3521fdd78447efd30be3d39b8f33.png) - Codec (H.264 or HEVC) - for the Video streams filter. ![MFVP stream char filtering codec](/_machine-assets/69df1ec9748c4938ca43c5a5d7fb6c1480060c6c548418e077da6e3fa6b3eaad.png) - Language (H.264 or HEVC) - for the audio streams filter. ![MFVP stream char filtering language](/_machine-assets/31b8dc987e3751d76e613e911f9e326d31d50594c453dea307fdda79333135f6.png) - Width (pixels) or Height (pixels) for the Thumbnail streams filter. ![MFVP stream char filtering thumbnail](/_machine-assets/3bb5ba148336d9c248dd3aff46c9e08689f0b132ab7e444973bbd56930994dba.png) ## HLS output type configuration ### Playlists By default, the output manifest is delivered without any specific bitrate filtering. Depending on your delivery needs, you can adjust the bitrate filtering on your manifest and add manifests with variant filtering parameters. **Stream characteristics** filtering for **HLS** outputs can be based either on: - Bitrate in kbps - for Video/Audio/Subtitle streams filters. ![MFVP stream char filtering bitrate](/_machine-assets/c74639c0664210ffa258f32bdcd906f6345f3521fdd78447efd30be3d39b8f33.png) - Codec (H.264 or HEVC) - for the Video streams filter. ![MFVP stream char filtering codec](/_machine-assets/69df1ec9748c4938ca43c5a5d7fb6c1480060c6c548418e077da6e3fa6b3eaad.png) - Language (H.264 or HEVC) - for the audio streams filter. ![MFVP stream char filtering language](/_machine-assets/31b8dc987e3751d76e613e911f9e326d31d50594c453dea307fdda79333135f6.png) - Width (pixels) or Height (pixels) for the Thumbnail streams filter. ![MFVP stream char filtering thumbnail](/_machine-assets/3bb5ba148336d9c248dd3aff46c9e08689f0b132ab7e444973bbd56930994dba.png) ## Delivery You can define **Access URL** for playlist, manifests and segments. For more details, see [Delivery](/beam/packager/parameters/hls-or-dash-over-cmaf#delivery). ## Encryption By default, the output manifest is published without any specific encryption. To configure output encryption parameters, you can choose between two encryption modes: CENC or CBCS. You can also disable audio encryption. For more details, see [Key usage rules](/beam/packager/parameters/hls-or-dash-over-cmaf#common-encryption-cenc).
CENC CBCS
Fixed keys
PlayReady X X
Widevine X X
Fairplay X X
External keys (compatible CPIX)
PlayReady X X
Widevine X X
MediaRoom X X
Fairplay X X
Clearkey X X
## Content replacement This feature is not currently used in MK.IO Beam. # HLS over TS specific output settings (HTTP Live Streaming) Packager can enable the HLS (HTTP Live Streaming) mode over TS (Transport Streams). In this mode, you can configure the following parameters. ## General You can configure for HLS over TS: - [General parameters](/beam/packager/parameters/hls-over-ts#general) - [HLS playlists](/beam/packager/parameters/hls-over-ts#hls) - [Delivery](/beam/packager/parameters/hls-over-ts#delivery) ## HLS output type configuration ### Playlists By default, the output manifest is delivered without any specific bitrate filtering. Depending on your delivery needs, you can adjust the bitrate filtering on your manifest and add manifests with variant filtering parameters. **Stream characteristics** filtering for **HLS** outputs can be based either on: - Bitrate in kbps - for Video/Audio/Subtitle streams filters. ![MFVP stream char filtering bitrate](/_machine-assets/c74639c0664210ffa258f32bdcd906f6345f3521fdd78447efd30be3d39b8f33.png) - Codec (H.264 or HEVC) - for the Video streams filter. ![MFVP stream char filtering codec](/_machine-assets/69df1ec9748c4938ca43c5a5d7fb6c1480060c6c548418e077da6e3fa6b3eaad.png) - Language (H.264 or HEVC) - for the audio streams filter. ![MFVP stream char filtering language](/_machine-assets/31b8dc987e3751d76e613e911f9e326d31d50594c453dea307fdda79333135f6.png) - Width (pixels) or Height (pixels) for the Thumbnail streams filter. ![MFVP stream char filtering thumbnail](/_machine-assets/3bb5ba148336d9c248dd3aff46c9e08689f0b132ab7e444973bbd56930994dba.png) ## Delivery You can define **Access URL**. For more details, see [Delivery](/beam/packager/parameters/hls-over-ts#delivery). ## Content replacement This feature is not currently used in MK.IO Beam. # Accessing MK.IO Beam Packaged Output Over HTTPS The packaged output is optionally accessible via HTTPS. The Beam server must first be configured with certificates, see [Enable customer-signed SSL certificates](/beam/system-admin/security/ssl-certificates). You can access packaged HTTPS output on port 8443 with the same URL path as used for HTTP access. # Configuring Live Packaging services ## Creating a new Live Packaging service To create a new Live Packaging service, follow these steps: 1. Access the MK.IO Beam user interface and click **Services** in the left panel. 2. Click the **Add service** button, then select **Live Packaging**. 3. You can configure the [parameters](/beam/packager/parameters/live). ## Starting a Live Packaging service **To start a Live Packaging service, you need to have previously configured**: - A Catalog that contains at least one output ([Adding an output to a Catalog](/beam/packager/catalog#adding-an-output-to-a-catalog)). - A Live Packaging service that: - contains at least one source and a publishing point ([DVR](/beam/packager/parameters/live#dvr)). - is linked to an existing Catalog. **To start a Live packaging service, follow these steps:** 1. Access the MK.IO Beam user interface then click **Services** in the left panel. 2. Assign the service to a server. (Remember: A server must be assigned to Start the service.) 3. Click the `Play outline` icon button in the **Actions** column to start the related service. The service status turns from **stopped** to **started**. The service starts publishing the DVR as configured. ## Stopping a Live Packaging service

In a solution deployment with servers, any Live Packaging service associated to a Live Encoding service must be stopped and started again after a modification of the Live Encoding configuration. The associated DVR must also be deleted.

To stop a Live Packaging service, follow these steps: 1. Go to the **Actions** column. 2. Click the `Stop outline` icon button to stop the related service. The service status turns from **started** to **stopped**. The service stops publishing the DVR. The origin server will return 404 errors 60 seconds after the DVR is stopped. ## Deleting a Live Packaging service and managing DVR Depending on the context, deleting a Live Packaging service by clicking `Delete` icon in the **Actions** column has different behaviors and results.

A Live Packaging service with the Play outline icon (started) status cannot be deleted. Click the Stop outline icon button to stop the service.

### The Live Packaging service has no server assigned - The service configuration is deleted and removed from the service list. It cannot be recovered after deletion. - The DVR generated by the service remains on the storage point. # Service Monitoring ## Monitoring service alarms The user interface allows you to access active and cleared alarms list for each service. 1. From the services page, identify the service that you want to monitor. 2. Click the related `Alarm` icon icon in the **info** column. Depending on the severity of the alarm, the `Alarm` icon will appear in different colors and will display the most severe color alarm in case of multiple alarms. - `Alarm red` icon: critical alarm - `Alarm yellow` icon: major alarm - `Alarm green` icon: minor alarm The following page displays. ![Services liveencoding alarms](/_machine-assets/d2577afb4056612b016d236a6a3808f6547a319d238ec7489728c07601785b9a.png) From this page, you can access the following information: - The active alarms table applied on the current server including: - Date and time of the alarm rise - Alarm description (label) - Alarm severity - Detailed information - The alarm history table including: - Date and time of the alarm rise - Alarm description (label) - Alarm status - Alarm severity - Server on which the service was applied when the alarm raised.

The alarm history table displays up to 10 alarms per page. Use the arrows or page number at the bottom of the table to navigate through the complete alarms list.

- [HLS or Dash over CMAF](/beam/packager/parameters/hls-or-dash-over-cmaf) - [HLS over TS](/beam/packager/parameters/hls-over-ts) - [Live Packaging](/beam/packager/parameters/live) - [Settings](/beam/packager/parameters/settings) # HLS or DASH over CMAF Below are the parameters accessed in the **HLS or DASH over CMAF** output. ## General ### General
Parameter Description
Output name Output name. The name you want to use for the output.
Naming scheme Naming scheme for DASH manifests.
Timeline mode: every fragment is listed and requested by the player.
trun v1 Enable trun version 1 for fragments allowing negative CTO (Composition Time Offset) values
Enable thumbnails Enable thumbnails generation
**Related information**\ [HLS or DASH over CMAF output configuration](/beam/packager/hls-dash-over-cmaf-output) ## Dash ### Manifest
Parameter Description
Name Name of the manifest/playlist generated for the current output.. Default value is index (for HLS) or manifest (for DASH). If a filtering has been applied to the manifest/playlist, it is recommended to use a name that clearly identifies the defined filtering.
Important: The manifest name must be unique and different from any other manifest name.
#### Filtering - Stream characteristics
Parameter Description
Audio streams filter Build a filter to select the audio streams that will be included in manifest/playlist.
Applicable filters: bitrate in kbps and Language
Video streams filter Build a filter to select the video streams that will be included in manifest/playlist.
Applicable filters: bitrate in kbps, codec (H.264 or HEVC) and No video
Subtitle streams filter Build a filter to select the subtitle streams that will be included in manifest/playlist.
Applicable filters: bitrate in kbps and Language
Thumbnail streams filter Build a filter to select the thumbnail streams that will be included in manifest/playlist.
Applicable filters: width and height in pixels
#### Player wall-clock
Parameter Description
Scheme Scheme to use for the UTCTiming element in DASH manifest.
Value Value to use for UTCTiming element depending on the selected scheme.
**Notes** - More than one UTCTiming can be added - The `urn:mpeg:dash:utc:direct:2014` has no value, the packager will derive it from the stream UTC time **Related information** See [UTCTiming](/beam/packager/parameters/hls-or-dash-over-cmaf#utctiming) below for details on possible values and roles. ## HLS ### Playlist
Parameter Description
Name Name of the manifest/playlist generated for the current output. Default value is index (for HLS) or manifest (for DASH).
Recommendation: If a filtering has been applied to the manifest/playlist, it is recommended to use a name that clearly identifies the defined filtering.
**Important:** The manifest name must be unique and different from any other manifest name. #### Filtering - Stream characteristics
Parameter Description
Audio streams filter Build a filter to select the audio streams that will be included in manifest/playlist.
Applicable filters: bitrate in kbps and Language
Video streams filter Build a filter to select the video streams that will be included in manifest/playlist.
Applicable filters: bitrate in kbps, codec (H.264 or HEVC) and No video
Subtitle streams filter Build a filter to select the subtitle streams that will be included in manifest/playlist.
Applicable filters: bitrate in kbps and Language
Thumbnail streams filter Build a filter to select the thumbnail streams that will be included in manifest/playlist.
Applicable filters: width and height in pixels
## Delivery ### General parameters
Parameter Description
Access URL Portion of the complete access URL that defines the service.
Prefer URI unreserved characters (alphanumerical characters plus (, ), -, _, .). Declaring a subpath (a/b) is possible but may impact performance.
Example: https://[Server IP or FQDN]/packaging/[Output Access URL]/[Live Packaging Service Access URL]/[index.m3u8 OR manifest OR manifest.mpd]
## Common encryption (CENC) ### Fixed key generation mode
Parameter Description
Key AES key used for encrypting the content.
Key ID Identifier used to uniquely identify the key within the system.
PlayReady Enables PlayReady encryption.
Widevine Enables Widevine encryption.
Fairplay Enables Fairplay encryption.
PlayReady mode enabled:
Parameter Description
License acquisition URL License acquisition URL to be used by the player.
License UI URL Nonsilent license acquisition URL to be used by the player.
Domain service ID Domain service identifier.
Microsoft provides a unique identifier to the PlayReady technology supplier.
Widevine mode enabled:
Parameter Description
Provider Name of the content provider. Also used as the name of the signer.
Policy Usage rules for the encypted output.
### Compatible CPIX ext. key
Parameter Description
Key server URL URL of the server that will deliver the encryption keys.
PlayReady Enables PlayReady encryption.
Widevine Enables Widevine encryption.
Fairplay Enables Fairplay encryption.
Mediaroom Enables Mediaroom encryption.
Clearkey Enables Clearkey encryption.
**Key rotation**
Parameter Description
Enable key rotation Enable key rotation. Leaving key rotation disabled means a single key is requested and used for the whole output.
Period Key rotation period. Choose a value and a unit for the period
Start time Date and time of the first occurrence. All crypto periods are aligned on this date and time, modulo the period: it fixes the phase of the period grid rather than the timestamp of an actual, one-time key request.
Time spread Duration (in seconds) of the time window for spreading key requests out in time. The actual offset is a pseudo-random value in that window, so it is stable for a given output but different across outputs — this staggers key requests instead of having every channel hit the key server at the same instant.
Period mode Choose mode for rotation keys. Possible values are Index and Start/end (default). In Index mode, the CPIX request/response identifies a crypto period by an integer index. In Start/end mode, it is identified by its actual validity window.
Number of key periods to request Number of key periods to request in advance from the key server. Requesting more than one fetches the current key plus the upcoming one(s) from the key server in a single round trip; the extra keys are cached and reused so no additional request is needed when the next crypto period starts.
**Key usage rules**
Parameter Description
Track filters/Filtering Build a filter to select the streams that will be included in Cpix track.
Applicable filters: streamType (video or audio), width (in pixels), height (in pixels) and codec (H.264 or HEVC)
Track type Type of a track associated to the track.
Only AZaz09 _,;:@ and space character are accepted
Labels List of labels associated to the track
Only AZaz09 _,;:@ and space character are accepted
Disable audio encryption Disables audio encryption for the output.
This setting overrides any encryption setting received from the key provider.
**Related information**\ See [CPIX key rotation and track keys](/beam/packager/parameters/hls-or-dash-over-cmaf#cpix-key-rotation-and-track-keys) below for details on how these settings shape the key requests sent to the key server. ## Common encryption (CBCS) ### Fixed key generation mode
Parameter Description
Key AES key used for encrypting the content. Unit: hexadecimal.
Initialization vector Initialization vector to be used with the key.
Key ID Identifier used to uniquely identify the key within the system.
PlayReady Enables PlayReady encryption.
Widevine Enables Widevine encryption.
Fairplay Enables Fairplay encryption.
PlayReady mode enabled:
Parameter Description
License acquisition URL License acquisition URL to be used by the player.
License UI URL Nonsilent license acquisition URL to be used by the player.
Domain service ID Domain service identifier.
Microsoft provides a unique identifier to the PlayReady technology supplier.
Widevine mode enabled:
Parameter Description
Provider Name of the content provider. Also used as the name of the signer.
Policy Usage rules for the encypted output.
Fairplay mode enabled:
Parameter Description
URI URI to be used by the player.
Key format Specify how the key is declared in the resource specified in the URL.
**Key usage rules**
Parameter Description
Disable audio encryption Disables audio encryption for the output.
This setting overrides any encryption setting received from the key provider.
### Compatible CPIX ext. key
Parameter Description
Key server URL URL of the server that will deliver the encryption keys.
PlayReady Enables PlayReady encryption.
Widevine Enables Widevine encryption.
Fairplay Enables Fairplay encryption.
Mediaroom Enables Mediaroom encryption.
Clearkey Enables Clearkey encryption.
**Key rotation**
Parameter Description
Enable key rotation Enable key rotation. Leaving key rotation disabled means a single key is requested and used for the whole output.
Period Key rotation period. Choose a value and a unit for the period
Start time Date and time of the first occurrence. All crypto periods are aligned on this date and time, modulo the period: it fixes the phase of the period grid rather than the timestamp of an actual, one-time key request.
Time spread Duration (in seconds) of the time window for spreading key requests out in time. The actual offset is a pseudo-random value in that window, so it is stable for a given output but different across outputs — this staggers key requests instead of having every channel hit the key server at the same instant.
Period mode Choose mode for rotation keys. Possible values are Index and Start/end (default). In Index mode, the CPIX request/response identifies a crypto period by an integer index. In Start/end mode, it is identified by its actual validity window.
Number of key periods to request Number of key periods to request in advance from the key server. Requesting more than one fetches the current key plus the upcoming one(s) from the key server in a single round trip; the extra keys are cached and reused so no additional request is needed when the next crypto period starts.
**Key usage rules**
Parameter Description
Track filters/Filtering Build a filter to select the streams that will be included in Cpix track.
Applicable filters: streamType (video or audio), width (in pixels), height (in pixels) and codec (H.264 or HEVC)
Track type Type of a track associated to the track.
Only AZaz09 _,;:@ and space character are accepted
Labels List of labels associated to the track
Only AZaz09 _,;:@ and space character are accepted
Disable audio encryption Disables audio encryption for the output.
This setting overrides any encryption setting received from the key provider.
## CPIX key rotation and track keys The **Compatible CPIX ext. key** provider (CENC or CBCS) delegates key generation to an external key server through the [DASH-IF CPIX](https://dashif.org/guidelines/cpix/) protocol. Two independent CPIX mechanisms are available on top of a single fixed key: **key rotation**, which periodically requests a new key over time, and **track keys**, which requests distinct keys for different tracks of the same output. ### Key rotation When key rotation is enabled, the packager requests a new key from the key server for every crypto period instead of a single key for the whole output: - The **period** and its **unit** set the crypto period duration (converted to seconds for the key request). - The **start time** anchors the period grid: period boundaries fall at `start time + n × period`, for every integer `n`. Only the start time's position _within_ one period matters. - The **time spread** adds jitter on top of that grid. Rather than requesting a key exactly on the period boundary, the packager offsets the request by a pseudo-random duration somewhere inside the spread window. This avoids many outputs sharing the same period and start time from all hitting the key server at the same instant, while keeping the offset stable for a given output. - The **period mode** controls how the current crypto period is identified in the CPIX exchange: - **Index** — the request/response carries an integer period number. - **Start/end** (default) — the request/response carries the period's actual validity window. - The **number of key periods to request** lets the packager fetch more than the current key in one CPIX round trip — the current key plus one or more upcoming (lookahead) keys. Setting the crypto period to 0 (or leaving key rotation disabled) means a single key is requested and used for the entire output — none of the other key rotation parameters apply in that case. ### Track keys By default, a single CPIX key applies to every track of an output. Declaring one or more entries in **Tracks** requests one key per entry instead, so different tracks (e.g. UHD video vs. SD video vs. audio) can be encrypted with different keys — a common requirement for tiered DRM policies (for example restricting 4K playback to devices with a stronger security level). Each track entry combines two independent things: - **Track type** and **Labels** are sent to the key server as the CPIX usage rule for that track's key. Both are free-form strings with no built-in normalization — their meaning is a convention agreed with the key server. - **Filtering** is evaluated locally by the packager only — it is never sent to the key server — to decide which of the output's actual streams that track key applies to. It supports `streamType` (video or audio), `width` and `height` (in pixels), and `codec` (H.264 or HEVC). The first track whose filter matches a given stream wins; a track without any filtering has no local restriction. **Important:** the key server may return a different key ID and key periods than the one the packager sent for a given track — always match tracks and keys on the identity returned in the CPIX response, not on the request. ### Combining key rotation with track keys Key rotation and track keys can be combined: the packager then requests one key per **(track, crypto period)** combination — for example, 2 tracks with 3 lookahead periods results in 6 keys in a single CPIX exchange. In that case, each `` additionally carries a `` element tying that specific track's key to the crypto period it is valid for. **Related information**\ [HLS or DASH over CMAF output configuration](/beam/packager/hls-dash-over-cmaf-output)\ [HLS over TS output configuration](/beam/packager/hls-output) ## UTCTiming The `` element of the MPD tells a DASH client how to synchronize its clock with the server's wall-clock time. For live streams, the client needs this reference to compute which segment is currently available at the live edge, using `availabilityStartTime`, `timeShiftBufferDepth` and `suggestedPresentationDelay`. Without it, a client with a drifting local clock can request segments that do not exist yet or that have already left the time-shift window. `UTCTiming` is defined in ISO/IEC 23009-1 (MPEG-DASH), clause 5.8.4.11 "UTC timing scheme" and can appear zero or more times as a child of the `MPD` element: ```xml ```
Attribute Description
schemeIdUri Required. A URN that identifies the method the client uses to obtain the time.
value Scheme-specific. For most schemes this is one or more URLs (or host names) to query. For direct, it is the UTC time from the input stream.
id Optional. Identifier of the descriptor, not supported in the packager
When several `UTCTiming` elements are present, they are listed in order of preference: the client should try the first scheme it supports and fall back to the next ones if the request fails. The schemes defined by the specification are:
schemeIdUri value Description
urn:mpeg:dash:utc:ntp:2014 NTP server host name(s), space separated The client obtains the time using the NTP protocol (RFC 5905).
urn:mpeg:dash:utc:sntp:2014 SNTP server host name(s), space separated The client obtains the time using the SNTP protocol (RFC 4330).
urn:mpeg:dash:utc:http-head:2014 URL, space separated if several The client issues an HTTP HEAD request and reads the time from the Date response header.
urn:mpeg:dash:utc:http-xsdate:2014 URL, space separated if several The client issues an HTTP GET request. The body is the time as an xs:dateTime string (for example 2024-01-01T12:00:00.123Z).
urn:mpeg:dash:utc:http-iso:2014 URL, space separated if several The client issues an HTTP GET request. The body is the time in ISO 8601 format.
urn:mpeg:dash:utc:http-ntp:2014 URL, space separated if several The client issues an HTTP GET request. The body is a 64-bit NTP timestamp (RFC 5905 format).
urn:mpeg:dash:utc:direct:2014 UTC time as xs:dateTime The time is carried directly in the MPD. It is only as accurate as the delay between MPD generation and reception, so it should be used only if no other scheme is available.
**Related information** - [ISO/IEC 23009-1](https://www.iso.org/standard/79329.html) - [DASH-IF Interoperability Guidelines](https://dashif.org/guidelines/). # HLS over TS Below are the parameters accessed in the **HLS over TS** output: ## General
Parameter Description
Output name Output name. The name you want to use for the output.
Naming scheme Timeline
## HLS ### Playlist
Parameter Description
Name Name of the manifest/playlist generated for the current output. Default value is index (for HLS) or manifest (for DASH). If a filtering has been applied to the manifest/playlist, it is recommended to use a name that clearly identifies the defined filtering.
Important: The manifest name must be unique and different from any other manifest name.
#### Filtering - Stream characteristics
Parameter Description
Audio streams filter Build a filter to select the audio streams that will be included in manifest/playlist.
Applicable filters: bitrate in kbps and Language
Video streams filter Build a filter to select the video streams that will be included in manifest/playlist.
Applicable filters: bitrate in kbps, codec (H.264 or HEVC) and No video
Subtitle streams filter Build a filter to select the subtitle streams that will be included in manifest/playlist.
Applicable filters: bitrate in kbps and Language
Thumbnail streams filter Build a filter to select the thumbnail streams that will be included in manifest/playlist.
Applicable filters: width and height in pixels
#### Filtering - Bitrate
Parameter Description
Audio streams filter Build a filter to select the audio streams that will be included in manifest/playlist.
Applicable filters: bitrate in kbps and Language
Video streams filter Build a filter to select the video streams that will be included in manifest/playlist.
Applicable filters: bitrate in kbps, codec (H.264 or HEVC) and No video
Subtitle streams filter Build a filter to select the subtitle streams that will be included in manifest/playlist.
Applicable filters: bitrate in kbps and Language
#### Filtering - Stream index
Parameter Description
Indexes Range or comma separated list of stream indexes, based on the stream position in the input.
Index of the first stream is '0'.
## Delivery ### General parameters
Parameter Description
Access URL Portion of the complete access URL that defines the service.
Prefer URI unreserved characters (alphanumerical characters plus (, ), -, _, .). Declaring a subpath (a/b) is possible but may impact performance.
Example: https://[Server IP or FQDN]/packaging/[Output Access URL]/[Live Packaging Service Access URL]/[index.m3u8 OR manifest OR manifest.mpd]
**Related information**\ [HLS or DASH over CMAF output configuration](/beam/packager/hls-dash-over-cmaf-output)\ [HLS over TS output configuration](/beam/packager/hls-output) # Live packaging parameters Below are the parameters accessed in the **Live Packaging** service settings: ## DVR
Parameter Description
Name Live Packaging service name
Ingest type Dash-IF Injest is only supported value
Base URL
Duration Rolling buffer size (DVR window). In initial version of Beam this also controls manifest/playlist duration for live service
## Asset
Parameter Description
Catalog Catalog that will host this content.
Content will be available for delivery using all outputs from the given catalog.
Access URL Portion of the complete access URL that defines the service.
Prefer URI unreserved characters (alphanumerical characters plus (, ), -, _, .). Declaring a subpath (a/b) is possible but may impact performances.
**Related information**\ [Live Packaging configuration](/beam/packager/live-packaging-service) # Packager settings Below are the parameters accessed in the Packager settings. ## Credentials ### User type
Parameter Description
URL Server URL.
Username The user name to access the server.
Password The password associated to the user name accessing the server.
### Crypto type
Parameter Description
URL Server URL.
Key seed Key seed used to decrypt the content.
# Adding a thumbnail to a Catalog A thumbnail is a still image that acts as the preview image for the video for a given time. Video thumbnails are small images that give you a snapshot of the video streams when moving forward or backward. The thumbnail streams parameters apply for all the outputs of the catalog for which thumbnails have been enabled. For specific needs, several thumbnails streams can be configured within a catalog. The thumbnails layout and periodicity are defined at the output level. To add a thumbnail to a Catalog, follow these steps: 1. From the **Services** page, click the **Name** related to the Catalog on which the output will be added. 2. On the Catalog page, click the **Add new thumbnail stream** button from the **Thumbnails** tab. 3. Enter the appropriate value for each parameter: - **Name** - **Source stream** - **Thumbnail size** This configuration applies for all the outputs of the catalog. 4. Click **OK** to save. 5. Further configuration steps are required in the output settings configuration: - Tick **Enable thumbnails** and configure the [thumbnail layout and periodicity](/beam/packager/hls-dash-over-cmaf-output). - You can also configure the thumbnail streams filtering for your manifests for [DASH](/beam/packager/hls-dash-over-cmaf-output) and [HLS](/beam/packager/hls-output) outputs. # Quick start

Default credentials differ by purchase type:

  • MK.IO Beam hardware purchased from MediaKind: credentials are on the paper Quick Start Guide supplied with the hardware.
  • SW Only: credentials are in the email from SWSupply with a subject containing "Your recent MK.IO Beam purchase...".

Change the default password after your first login. Select the user icon in the upper right corner of the device UI and choose Change password.

Complete the following steps to configure and register your MK.IO Beam device. ### Install the ISO

This step is required for SW Only customers only. The ISO is pre-installed on MK.IO Beam hardware purchased from MediaKind.

See [Install the ISO](/beam/system-admin/iso-installation). ### Set control IP address

This step is only required if the device has not obtained a DHCP address. The IP address displays on the terminal when a monitor and keyboard are attached. Press Return if needed to clear the screen.

1. Log in to the terminal with the default credentials. 2. Type `control-wizard` and press Enter to configure the _Control_ interface. You can also configure an HTTP proxy here if one is needed to reach MK.IO. ### Connect to the web user interface 1. In a web browser, go to `http://`, where `` is the control IP address set in the previous step. 2. Enter the default **username** and **password** on the login page. The **Home** page displays. ### Configure the network See [Network Configuration](/beam/system-admin/network/configure-nics). Set at least one DNS server. DNS is required for connection to MK.IO unless you have configured an HTTP proxy. For the MK.IO connection requirements and device-management guides, see [Connect MK.IO Beam to MK.IO](/beam/connect-to-mkio). ### Configure and activate time synchronization See [How to configure the system clock](/beam/system-admin/network/system-clock). Configure a time source and make it active. ### Register the MK.IO Beam device with MK.IO See [device onboarding](/mkio/how-to/managing-edge-devices/on-board-fleet-devices). Registration status persists over an upgrade but does not persist if the device is re-imaged. ### Upgrade to the latest software version See [updating device software](/mkio/how-to/managing-edge-devices/update-device-software). # Receiving and Decoding
Check which interface you are using

The guides linked from this page configure MK.IO Beam through the Advanced interface, where a workflow is a feed made up of individual services. If your device runs the Essentials interface, build the workflow as a channel instead: see Create a channel. Both interfaces control the same settings underneath, so these pages stay useful as reference for the detail behind a channel.

A **broadcast receiver** demodulates an incoming signal and decodes the video and audio it contains, converting a compressed transport stream back into a baseband output. Receivers are a fundamental part of any workflow where content arrives over satellite or IP and needs to be decoded for monitoring, processing, or re-distribution. MK.IO Beam's Receiver handles both satellite and IP inputs. For satellite, it supports DVB-S, DVB-S2, and DVB-S2X standards with hardware demodulator cards. For IP, it accepts transport stream inputs directly from the network. You can route a single satellite input to multiple Receiver services, or assign each input independently. ## Decoding Once the transport stream is received, MK.IO Beam decodes the video and audio from the selected service. By default, the first video and audio components listed in the service Programme Map Table (PMT) are decoded automatically. Supported audio formats include MPEG-1 Layer II, Dolby Digital, and Dolby Digital Plus, as well as pass-through of formats such as Dolby E and LPCM. See the [Video Decoding](/beam/reception/tech-specs/#video-decoding) and [Audio Decoding](/beam/reception/tech-specs/#audio-decoding) sections in the technical _Reference_ documentation for a full list of supported formats and configuration options. See [Decoding configuration](/beam/receiver/decoding) for details on how to configure decoding. ## Outputs MK.IO Beam's Receiver delivers decoded output in several formats: - SDI (HD, 3G SDI) for broadcast equipment and monitors. - UHD SDI for ultra-high-definition workflows. - SMPTE ST 2022-6 and SMPTE ST 2110 for IP-based studio and production environments. - HDR to SDR conversion and HD downconversion for compatibility with legacy equipment. - SCTE-35 to SCTE-104 conversion for passing ad insertion signals to downstream encoders. Multiple outputs can be configured from a single Receiver service. See [Output configuration](/beam/receiver/output) for the full range of options. ## Decryption Broadcast streams are often encrypted to prevent unauthorized access. MK.IO Beam's Receiver supports several decryption methods: - **BISS (Basic Interoperable Scrambling System):** A broadcast standard for contribution and distribution encryption (BISS1, BISS2, BISS-CA). - **Director 6:** MediaKind's conditional access system which features over-air-control functionality. - **DVB-CI:** A common interface standard that uses a removable Conditional Access Module (CAM). See [Decryption configuration](/beam/receiver/decryption) for setup details. ## Receiver Configuration Type When a _Receiver_ service is created by [adding a Feed](/beam/web-interface/#add-a-feed), one or more services are generated from a template. In this case, the _Receiver_ service **Configuration Type** is selected automatically based on the chosen Feed type. Alternatively, when [creating a service](/beam/web-interface/services/#create-a-service) directly, you are prompted to select the **Configuration Type** if it is a _Receiver_ service. The **Configuration Type** determines the behaviour of the _Receiver_ service, as shown in the table below. It can be changed at any time as part of the Receiver service configuration.
Configuration Type Description
TS passthrough Does not decode video, audio, or data, but supports descrambling. The input transport stream is then output as an IP/UDP multicast.
SD/HD Decodes video (SD and HD), audio, and data, and supports descrambling, with output in formats such as SDI.
UHD Decodes video (SD, HD, and UHD), audio, and data, and supports descrambling, with output in formats such as SDI. Includes additional UHD-specific configuration settings.
If the selected Configuration Type is not appropriate, some configuration settings may be unavailable in the web interface, or the _Receiver_ service may be prevented from starting and entering the _Running_ state. If the service is blocked from starting, an alarm is raised indicating that the service configuration is incompatible with the selected Configuration Type. Refer to the alarm description for guidance on resolving the issue and bringing the service into the _Running_ state. ### Change the Configuration Type To change the configuration type for an existing Receiver service: 1. From the **Home** page, select the RECEIVER item from the required feed then click `Edit` icon to edit. 2. Select the appropriate type from the **Configuration Type** drop-down list. ![Changing the configuration type in edit page](/rx1-img/view_edit_configuration_type.png) 3. Click **Save and Continue** to apply change. ## Common use cases - Receiving satellite-delivered channels for headend or monitoring workflows. - Decoding IP contribution feeds for production or re-encoding. - Converting encrypted broadcast streams to baseband for downstream processing. For reception solution guides, see [Reception](/beam/reception). # Configure the decoding After MK.IO Beam locks to an input transport stream, it enables selection of available services (programmes) for decoding. These services are then processed and output according to the configured decoding and output parameters. ## Service selection Before you start, ensure at least one _Receiver_ service has started and is in a _Running_ state. The input should be configured and locked to a valid input. 1. From the **Home** page, select the RECEIVER item from the required feed then click `Edit` icon to edit. 2. From the **Parameters** section, select the **Decoding** tab. 3. Select a service from the **Service** drop-down list to decode. The first video and audio components listed in the service PMT will be automatically selected for decode. 4. Click **Save and Continue** to apply change.

It may be necessary to configure the correct Configuration Type.

### Delay Mode By default, the **Delay mode** is set to _Standard_, which is optimised for most decode use cases. For more information, see the [Delay Modes](/beam/reception/delay-modes) section. ### Checking Service Status Service status can be checked on the same **Edit** `Edit` icon page or by viewing the **Stats** `Chart` icon page. 1. Check **Service Status** panel with the following fields: - **Selected Service** shows the service number and service name - **PCR PID** shows the current PCR PID in use ![view status service cp](/rx1-img/view_status_service_cp.png) 2. Check the **Video Status** panel. The video PID, component bit rate, codec being used, resolution, picture aspect ratio and frame rate are displayed. ![view status service video cp](/rx1-img/view_status_service_video_cp.png) 3. Check the **Input Monitor** panel. This displays a thumbnail of the decoded video which is updated every 5 seconds. ![view status service input monitor cp](/rx1-img/view_status_service_input_monitor_cp.png) 4. Check the **Audio Status** panel. The audio PID, status and codec are displayed. Hover over each audio status field to display additional information, including channel mode, language and bit rate. ![view status service audio cp](/rx1-img/view_status_service_audio_cp.png) The colour of each field provides a quick indication of audio decode status, with green indicating success and red indicating errors. ## Video Decoding See the **[Video Decoding](/beam/reception/tech-specs/#video-decoding)** section in the technical _Reference_ documentation for video codec and resolution capabilities supported by MK.IO Beam. ### Configure video decoding The video PID is automatically selected based on the configured [Service Selection](/beam/receiver/decoding#service-selection). This can be overridden as follows: 1. From the **Parameters** section, select the **Decoding** tab. 2. Select the **Video** tab. ![Select Edit > Parameters > Video](/rx1-img/view_decoding_video.png) 3. Select a video PID from the **Input PID** drop-down list, or manually enter a PID value. 4. Click **Save and Continue** to apply change. ## Audio decoding

Up to 8 audio components (stereo pairs), or 16 audio channels, can be decoded per Receiver service.

See the **[Audio Decoding](/beam/reception/tech-specs/#audio-decoding)** section in the technical _Reference_ documentation for details of the audio codecs supported by MK.IO Beam for decoding and pass-through. ### Decode Channel Configuration Each audio component selected for decoding can be configured with a different number of output channels for embedding in the output stage.
Decode Channel Configuration Use case Output channels
Stereo Decode stereo, dual mono, mono, joint stereo or 5.1 downmix 2
5.1 Decode 5.1 audio 6
16 Mandatory for MPEG-H decode 16
Pass-through No decode. Use this option for compressed audio output 2
### Configure audio decoding Before you start, ensure [Service Selection](/beam/receiver/decoding#service-selection) is configured. 1. From the **Parameters** section, select the **Decoding** tab. 2. Select the **Audio** tab to view the audio decode table. ![Select Edit > Parameters > Audio](/rx1-img/view_decoding_audio.png) 3. The first decoded audio **Name** is automatically given the reference **Audio 1**. This reference is used when configuring audio in the output stage. 4. Select an audio PID from the **Input** drop-down list, or manually enter a PID value. 5. Select the appropriate **[Decode channel configuration](/beam/receiver/decoding#decode-channel-configuration)**. 6. Click **Save and Continue** to apply change. ### Add Audio Decode To add a single audio entry (for example, **Audio 2**) to the audio decode table: 1. From the **Parameters** section, select the **Decoding** tab. 2. Select the **Audio** tab to view the audio decode table. 3. Select **Add audio decode** to create a new entry. 4. Configure the new entry by following the steps in [Configure audio decoding](/beam/receiver/decoding#configure-audio-decoding) above. ### Remove Audio Decode To remove a single audio entry from the audio decode table: 1. From the **Parameters** section, select the **Decoding** tab. 2. Select the **Audio** tab to view the audio decode table. 3. Click the `Delete` icon icon on the audio decode entry. ### Decode All Input Audio To add audio entries for all detected audio components in the configured [Service Selection](/beam/receiver/decoding#service-selection) (this option is only effective when a valid input is incoming): 1. From the **Parameters** section, select the **Decoding** tab. 2. Select the **Audio** tab to view the audio decode table. 3. Select **Decode all input audio** to create entries for all detected audio components (up to a maximum of eight, **Audio 8**). 4. For each entry, select the appropriate **[Decode channel configuration](/beam/receiver/decoding#decode-channel-configuration)**. ### Remove All Input Audio To remove all audio entries from the audio decode table: 1. From the **Parameters** section, select the **Decoding** tab. 2. Select the **Audio** tab to view the audio decode table. 3. Select **Remove all input audio** to empty the audio decode table. ### Auto Select When **Auto Select** is enabled, the receiver automatically selects and configures audio components based on the PMT order of the configured [Service Selection](/beam/receiver/decoding#service-selection) from the input transport stream. Existing manual audio decode entries are replaced with automatically generated entries, each configured with the [Decode channel configuration](/beam/receiver/decoding#decode-channel-configuration) set to **Stereo**. This feature also manages the embedding of audio channels in the output stage. It is best suited for [SDI](/beam/receiver/output/sdi) output and is not recommended for use with [SMPTE ST 2110](/beam/receiver/output/smpte-st-2110/) output configurations.

After a PMT update, the currently assigned audio decoders are reviewed and may be modified:

  • Automatic audio selection is based on PMT order, so audio components may be moved, added, or removed.
  • Only the first 8 audio components (Stereo) are automatically selected and embedded in the output stage.
To configure _Auto Select_: 1. From the **Parameters** section, select the **Decoding** tab. 2. Select the **Audio** tab to view the audio decode table. 3. Select the **Auto Select** tick box. ![view decoding audio auto select mode cp](/rx1-img/view_decoding_audio_auto_select_mode_cp.png) ## Data decoding

Up to 8 data components can be decoded per Receiver service.

See the **[Ancillary Data](/beam/reception/tech-specs/#ancillary-data)** section in the technical _Reference_ documentation for the ancillary data types supported by MK.IO Beam. The following data types, encapsulated in video (for example, SEI messages or MPEG-2 user data) or as packetised elementary stream (PES) packets, can be processed by the _Receiver_ service and converted for output, for example to SDI.
Format Output format
AFD / Bar data SMPTE ST 2016
Teletext OP-47 / SMPTE ST 2031
Closed captions SMPTE ST 334 for EIA-708-B
Timecode SMPTE ST 12 + RP 188
Generic VANC SMPTE ST 2038
SCTE-35 SCTE-104
### Data Type Configuration Where data types are carried as data components (PES packets) in the transport stream, they can be selected as described in the sections below. Each selected data component must be configured with the appropriate **Data Type configuration** to enable embedding at the output stage.
Data Type Configuration Use case
Ancillary Extraction of generic VANC data
Teletext Extraction of CCIR Teletext System B (EBU Teletext) for conversion to OP-47 or SMTPE ST 2031
SCTE 35 Splicing Extraction of SCTE-35 data for conversion to SCTE-104
### Configure data decoding Before you start, ensure [Service Selection](/beam/receiver/decoding#service-selection) is configured. 1. From the **Parameters** section, select the **Decoding** tab. 2. Select the **Data** tab to view the data decode table. ![view edit service decode data cp](/rx1-img/view_edit_service_decode_data_cp.png) 3. Select **Add data decode** to create a new entry. The first decoded data **Name** is automatically given the reference **Data 1**. 4. Select a data PID from the **Input** drop-down list, or manually enter a PID value. 5. Select the appropriate **[Data type configuration](/beam/receiver/decoding#data-type-configuration)**. 6. Click **Save and Continue** to apply change. ### Add Data Decode To add a single data entry (for example, **Data 2**) to the data decode table: 1. From the **Parameters** section, select the **Decoding** tab. 2. Select the **Data** tab to view the data decode table. 3. Select **Add data decode** to create a new entry. 4. Configure the new entry by following the steps in [Configure data decoding](/beam/receiver/decoding#configure-data-decoding) above. ### Remove Data Decode To remove a single data entry from the data decode table: 1. From the **Parameters** section, select the **Decoding** tab. 2. Select the **Data** tab to view the data decode table. 3. Click the `Delete` icon icon on the data decode entry. ### Decode All Input Data To add data entries for all detected data components in the configured [Service Selection](/beam/receiver/decoding#service-selection) (this option is only effective when a valid input is incoming): 1. From the **Parameters** section, select the **Decoding** tab. 2. Select the **Data** tab to view the data decode table. 3. Select **Decode all input data** to create entries for all detected data components (up to a maximum of eight, **Data 8**). 4. For each entry, select the appropriate **[Data type configuration](/beam/receiver/decoding#data-type-configuration)**. ### Remove All Input Data To remove all data entries from the data decode table: 1. From the **Parameters** section, select the **Decoding** tab. 2. Select the **Data** tab to view the data decode table. 3. Select **Remove all input data** to empty the data decode table. # Phase Aligned Audio Phase-aligned audio (PAA) uses multiple synchronised MPEG‑1 Layer II audio components (PIDs), each carrying two audio channels. Together, these components deliver surround sound channels alongside additional audio services. ## Assignment of PAA Audio Components

Automatic selection of PAA components for a configured Service Selection is currently not supported. Each PAA component must therefore be manually added and configured using the guidelines below.

Audio components assigned for PAA are identified using three-letter language codes in the language descriptors, normally defined in ISO 639. The tables below show how audio components are assigned to audio decoders based on the language descriptor, and how they should be embedded in the output (for example, SDI audio embedding). For the first PAA group, the output channel order is as follows:
Decode Name Language Descriptors Intended Output Channels Output Embedding
Audio 1 a,a,a (a,a,b) 1 & 2 Embedded 1
Audio 2 a,a,c (a,a,d) 3 & 4 Embedded 2
Audio 3 a,a,e (a,a,f) 5 & 6 Embedded 3
Audio 4 a,a,g (a,a,h) 7 & 8 Embedded 4
For the second PAA group, the output channel order is as follows:
Decode Name Language Descriptors Intended Output Channels Output Embedding
Audio 5 b,b,a (b,b,b) 1 & 2 Embedded 5
Audio 6 b,b,c (b,b,d) 3 & 4 Embedded 6
Audio 7 b,b,e (b,b,f) 5 & 6 Embedded 7
Audio 8 b,b,g (b,b,h) 7 & 8 Embedded 8
## Configuring PAA Decode and Output ### Configure PAA Decoding To set up decode of audio components for PAA, follow these steps: 1. Configure the [Service Selection](/beam/receiver/decoding/#service-selection), selecting a service that includes PAA content. 2. From the **Parameters** section, select the **Decoding** tab. 3. Select the **Audio** tab to view the audio decode table. 4. Use the [Add audio decode](/beam/receiver/decoding/#add-audio-decode) button or [Decode all input audio](/beam/receiver/decoding/#decode-all-input-audio) button to create entries in the audio decode table. 5. For each audio entry, select an audio PID from the **Input** drop-down list, based on the language descriptors defined in the [Assignment of PAA Audio Components](/beam/receiver/decoding/paa#assignment-of-paa-audio-components) section above. 6. For each PAA audio entry, set the **Decode channel configuration** to _Stereo_. ### Configure PAA Output To set up the output of audio component for PAA, follow these steps: 7. Select the **Output** tab. 8. Select the tab for the output type, for example **SDI 1**. 9. Under the **Audio** tab, click **Add all** to automatically add all the decoded audio components already configured. ![receiver output audio add component](/rx1-img/rx1_output_audio_add_component.png) 10. Click **Save and Continue** to apply change. # Configure the decryption ## Decryption MK.IO Beam supports several **Conditional Access (CA)** schemes for decrypting services from an incoming transport stream. If the service selected for decode is encrypted (scrambled), a **locked padlock** symbol is displayed next to the service name. **Example**: ![decryption locked padlock](/rx1-img/decryption_locked_padlock.png) When the service selected for decode is successfully being decrypted (descrambled), an **unlocked padlock** symbol is displayed next to the service. **Example**: ![decryption unlocked padlock](/rx1-img/decryption_unlocked_padlock.png) { /\* TODO: update links (contact information once MD files are created \*/} # BISS-CA Decryption

A Trusted Platform Module (TPM) must be fitted. If not fitted, the BISS-CA functionality will be hidden. Please contact MediaKind Customer Support on how to check this.

BISS2 mode CA, or BISS-CA (as specified in EBU Tech 3292-s1 Version 1.0 March 2018) is an extension to BISS2 which replaces the fixed Session Word (SW) used to descramble an incoming feed with a cycling Session Word that is transmitted in the transport stream using Entitlement Control Messages (ECMs). Receivers may be entitled by the headend to decrypt the cycling Session Words via an intermediary Session Key (SK) which are transmitted in the transport stream using Entitlement Management Message (EMMs). Entitlement of the receiver is handled through public/private key cryptography where the public and private keys are both known to the receiver and only the public key is known to the headend. For each entitled receiver, the SK is encrypted using the receiver’s public key. ## BISS-CA Key Types The receiver component supports the following BISS-CA features: - Self-generated key pair - Injected key pair Multiple **Self-Generated Key Pairs** and/or **Injected Key Pairs** can be stored on a single unit. This allows the receiver operator to switch the unit between headend scramblers without having to reload or regenerate the key pairs. For all key pair types, you can [export the public key](/beam/receiver/decryption/biss-ca-decryption#export-the-public-key) from the receiver and provide it to the _Content Provider_, who will issue the entitlements. ## Managing BISS-CA Keys You can view the BISS-CA keys currently stored on the unit in the **BISS-CA Key Pairs** table found in `sliders` icon **Appliance** section from the Beam web UI (see [Display BISS-CA key pairs table](/beam/receiver/decryption/biss-ca-decryption#display-biss-ca-key-pairs-table)) The BISS-CA Key Pairs table will list the following information: - **EKID**: This is the Entitlement Key ID derived from the key pair stored on the unit. It will be unique to the key pair and may be used to reference or identify the key pair when communicating with the _Content Provider_. - **Key Pair Type**: This indicates the Key Pair Type as either Self-Generated or Injected. - **Creation Date**: The date when the key pair was generated or imported on to the unit. - **Description**: A text field that the operator can optionally fill to help identify what the key pair is used for such as, name of content provider, event name, etc. This field has no effect on the operation of BISS-CA decryption. - **Download Actions**: The download actions available for the key pair vary according to the key pair type: - **Public**: Download the public portion of the key pair - **Delete**: Remove the key pair from storage on the unit ### Display BISS-CA Key Pairs table To navigate to the BISS-CA Key Pairs table, follow these steps: 1. Select `sliders` icon **Appliance** from the left-hand side menu. 2. Click the **BISS-CA Key Pairs** tab ![rx1 servers rx1 app biss ca kp tables](/rx1-img/rx1_servers_rx1_app_biss-ca_kp_tables.png) ### Create a self-generated key pair To create a self-generated key pair, follow these steps: 1. [Display BISS-CA Key Pairs Table.](/beam/receiver/decryption/biss-ca-decryption#display-biss-ca-key-pairs-table) 2. Click **Add key Pair**. 3. Select **Self-Generated Key Pair**. A pop-up window should appear stating **Success**. ![rx1 servers rx1 app biss ca kp generate](/rx1-img/rx1_servers_rx1_app_biss-ca_kp_generate.png) 4. Click **OK** to close the pop-up window. A new Key Pair entry should appear in the BISS-CA Key Pair table. 5. Enter a suitable descriptive title in the **Description** field to help identify what content provider this key pair will be registered to or the name of the event it will be used for. ### Import injected key pair To import an injected key pair, follow these steps: 1. [Display BISS-CA key pairs table](/beam/receiver/decryption/biss-ca-decryption#display-biss-ca-key-pairs-table). 2. Click **Add Key Pair**. 3. Select **Import Injected Key Pair**. A pop-up browser window should appear showing the required fields necessary for importing an Injected key pair. ![rx1 servers rx1 app biss ca kp import](/rx1-img/rx1_servers_rx1_app_biss-ca_kp_import.png) 4. Click on the **Select Public Key** field where it states _Select a File_, browse and select the file for the **public** key. 5. Click on the **Select Private Key** field where it states _Select a File_, browse and select the file for the **private** key. 6. Enter a suitable descriptive title in the **Description** field to help identify what content provider this key pair will be registered to or the name of the event it will be used for. 7. Click the **Import** button. A pop-up window should appear stating Success. ![rx1 servers rx1 app biss ca kp import result](/rx1-img/rx1_servers_rx1_app_biss-ca_kp_import_result.png) 8. Click **OK** to close the pop-up window. A new key pair entry should appear in the BISS-CA key pair table. ### Export the public key To export the public key, follow these steps: 1. [Display BISS-CA key pairs table](/beam/receiver/decryption/biss-ca-decryption#display-biss-ca-key-pairs-table). 2. Locate the row with the desired key pair. 3. From the **Download Actions** column, click the **Public** button. ### Remove stored key Pair

Removing a key pair is irreversible. Any service using the removed key pair will no longer be descrambled, and new entitlements must be obtained from the Content Provider (see BISS-CA entitlements).

To remove a stored key pair, follow these steps: 1. [Display BISS-CA Key Pairs Table.](/beam/receiver/decryption/biss-ca-decryption#display-biss-ca-key-pairs-table) 2. Locate the row with the desired key pair. 3. From the **Download Actions** column click the **Delete** button. A pop-up window should appear confirming the action. 4. Select **Yes, Delete Key** to complete the action. A pop-up window should appear stating **Success**. 5. Click **OK** to close the pop-up window. ## Configuring BISS-CA Decryption [Entitlements](/beam/receiver/decryption/biss-ca-entitlements) Managing BISS-CA entitlements Popular ### Enable BISS-CA decryption for service decode For a service that has been configured for **UHD** or **SD/HD**, enable BISS-CA with the following steps: 1. From the `fa-home` icon **Home** page, select the RECEIVER item from the required feed then click `Edit` icon to edit 2. From the **Parameters** window, select the **Decrypt** tab. 3. Tick the **BISS-CA** checkbox to enable decryption (untick the checkbox to disable decryption). ![rx1 decrypt biss ca](/rx1-img/rx1_decrypt_biss-ca.png) 4. Click **Save and continue** to save your changes. ### Enable BISS-CA decryption for TS passthrough For a service that has been configured for **TS Passthrough**, enable BISS-CA with the following steps: 1. From the `sliders` icon **Home** page, select the RECEIVER item from the required feed then click `Edit` icon to edit 2. From the **Parameters** window, select the **Decrypt** tab. 3. Click **Add Decrypted Program** button. A new row will appear in the decryption table. 4. Set the **Service** to be decrypted and set the **Decryption Type** to **BISS-CA**. ![rx1 decrypt biss ca TS passthrough](/rx1-img/rx1_decrypt_biss-ca_TS_passthrough.png) 5. Click **Save and continue** to save your changes. # Managing BISS-CA entitlements To successfully decrypt BISS-CA content, MK.IO Beam Distribution must have the correct entitlements. The _Content Provider_ requires a public key exported from the receivers [BISS-CA Key Pair table](/beam/receiver/decryption/biss-ca-decryption#managing-biss-ca-keys). To get the correct entitlements, follow these steps: ### Obtaining BISS-CA entitlements 1. [Contact content provider](/beam/receiver/decryption/biss-ca-entitlements#step-1---contact-content-provider) 2. [Exchange keys](/beam/receiver/decryption/biss-ca-entitlements#step-2---exchange-keys) 3. [Check authorization](/beam/receiver/decryption/biss-ca-entitlements#step-3---check-authorization) ## Step #1 - Contact content provider Contact the provider of the scrambled content and determine how they wish to exchange key pairs. They will require one of the following methods: ``` - **Method 1**: The receiver operator must send a public key to the content provider. - **Method 2**: The content provider will send a public/private key pair to the receiver operator. ``` The keys will need to be exchanged between the content provider and the receiver operator using an out-of-band method chosen by the content provider. ## Step #2 - Exchange keys ### Method 1: Send Public Key If requested by the content provider, the receiver operator must supply a **public key** to enable entitlement by the scrambler using a **self-generated key pair**. 1. If a self-generated key pair is not already available, [create a self-generated key pair](/beam/receiver/decryption/biss-ca-decryption#create-a-self-generated-key-pair). 2. [Export the public key](/beam/receiver/decryption/biss-ca-decryption#export-the-public-key). 3. Send the public key to the content provider who will manage entitlements. ### Method 2: Import Public/Private Key The content provider will supply a public and private key pair to the receiver operator, which must be imported into the receiver. This is done using an **injected key pair**. 1. [Import injected key pair](/beam/receiver/decryption/biss-ca-decryption#import-injected-key-pair). 2. The public key should already be registered with the content provider who will manage entitlements. ## Step #3 - Check authorization 1. [Enable BISS-CA decryption for service decode](/beam/receiver/decryption/biss-ca-decryption#enable-biss-ca-decryption-for-service-decode). 2. From the `video-plus` icon **Services** page, click `Alarm` icon to view the alarms page. 3. Confirm that no alarms are raised. 4. If the raised alarm **Label** reports **BISS CA not decrypting** and the **Info** column states **not authorized** then this is due to one or more of the following conditions: - The EKID recovered from the transport stream does not match the EKID of any key pair stored on the receiver. - The content provider has not enabled entitlements. - The content provider has revoked entitlements. 5. Contact the content provider to confirm that the correct public key has been registered and that entitlements have been enabled.

It may be necessary to refer to the EKID value, see Managing BISS-CA keys.

# BISS Decryption BISS refers to either BISS1 or BISS2, both of which, from a receiver perspective, use a fixed Control/Session Word to decrypt scrambled content, except in the case of BISS‑CA. The supported modes are listed in the table below and are defined in EBU Tech 3292. These modes are supported by MK.IO Beam Distribution.
BISS Protocol Version Supported Modes Scrambling Algorithm Key Length
BISS1 Mode 1
Mode E
DVB-CSA 48 bits
BISS2 Mode 1
Mode E
Mode CA (BISS-CA)
DVB-CISSA 128 bits
For details on BISS-CA, refer to the [BISS-CA Decryption](/beam/receiver/decryption/biss-ca-decryption) section ## BISS Mode 1 BISS mode 1 (BISS1-1 or BISS2-1) is recommended for short‑term events, such as sports broadcasts. Mode 1 uses a fixed key called the Session Word for encryption and decryption. The session word, referred to as the **Clear Session Word (CSW)**, is entered into the receiver via the web interface. If the same CSW is also configured on a BISS‑compliant encoder, the receiver successfully decrypts the encrypted service. ### Set BISS to mode 1

Beam automatically switches between the BISS1 or BISS2 version based on the BISS Key length entered in the configuration.

To set BISS to mode 1, follow these steps: 1. From the **Home** page, select the RECEIVER item from the required feed then click `Edit` icon to edit 2. Select the **Decrypt** tab in the **Parameters** window. 3. Select **Mode 1** for [**BISS mode**](/beam/receiver/parameters#decrypt-parameters). 4. Update the **BISS Key** with the 12-digit hexadecimal CSW for BISS1 or the 32-digit hexadecimal CSW for BISS2. The CSW digits will remain visible whilst being entered but once clicked away, the BISS key will be obscured with \*\*\*\*\*\*\*\*\*\*\*\*. **Example**: ![rx1 decrypt biss mode1](/rx1-img/rx1_decrypt_biss_mode1.png) 5. Click **Save and Continue** The service configured for decode should now be decrypted and successfully decoding. If the BISS key is incorrectly entered or the service is encrypted using a different CA scheme then erroneous packets will be output from the descrambler and the decoder will fail to decode the service. ## BISS Mode E In BISS Mode E (BISS1-E or BISS2-E), the Clear Session Word (CSW) is encrypted to form the **Encrypted Session Word (ESW)**. Because the ESW is used as the BISS key input, Beam requires an **Injected ID** to derive the CSW. Ideally, the **BISS Injected ID** is securely embedded on the device by the _Content Provider_ and is not shared. If both the ESW (BISS key) and the Injected ID are known, BISS Mode E offers no additional security over BISS Mode 1. ### Set BISS Injected ID The BISS Injected ID is required for BISS Mode E and should be configured or made available by the _Content Provider_. 1. Select **Appliance** from the left-hand side menu. 2. Click the **BISS Injected IDs** tab. 3. In the **New Injected ID** field, enter the 14-digit Injected ID provided for BISS1 or the 32-digit Injected ID provided for BISS2. 4. In the **Description** field, enter a unique description that allows the Injected ID to be referenced later on. 5. Click **Upload**. The new Injected ID is added to the list of Injected IDs embedded on the device. Multiple Injected IDs can be entered using the same process. Each Injected ID must have a unique description, as this description is used to select the correct Injected ID when configuring BISS Mode E. ### Set BISS to mode E

Beam automatically switches between the BISS1 or BISS2 version based on the BISS Key length entered in the configuration.

To set BISS to mode E, follow these steps: 1. From the **Home** page, select the RECEIVER item from the required feed then click `Edit` icon to edit 2. Select the **Decrypt** tab in the **Parameters** window. 3. Select **Mode E** for [**BISS mode**](/beam/receiver/parameters#decrypt-parameters). 4. Update the **BISS Key** with the 16-digit hexadecimal ESW for BISS1 or the 32-digit hexadecimal ESW for BISS2. The ESW digits will remain visible whilst being entered but once clicked away, the BISS key will be obscured with \*\*\*\*\*\*\*\*\*\*\*\*. **Example**: ![rx1 decrypt biss modeE](/rx1-img/rx1_decrypt_biss_modeE.png) 5. From the **Injected ID** drop down option list, select the appropriate **description** name to the required Injected ID embedded in the Beam device. 6. Click **Save and Continue** The service configured for decoding should now be decrypted and decoding successfully. If the BISS key is entered incorrectly, an incorrect Injected ID is used, or the service is encrypted using a different CA scheme, the descrambler will output erroneous packets and the decoder will fail to decode the service. # Common Interface Decryption **Common Interface** (DVB-CI) provides a descrambling solution using a PCMCIA-based card, commonly referred to as a **Conditional Access Module** (CAM). CAMs are available from many different **CA vendors** and offer varying capabilities. Consumer CAMs are typically limited to descrambling a single service and may also restrict the number of components (PIDs) that can be descrambled simultaneously. Professional CAMs, in contrast, can often descramble multiple services and multiple components per service. Each CAM is typically limited to a single CA vendor. Therefore, supporting multiple CA vendors requires multiple CAMs, one provided by each vendor. Entitlements are usually stored either on the CAM itself or on a smartcard inserted into the CAM. Decryption can only be enabled on a CAM once the appropriate entitlements have been delivered to the CAM or its associated smartcard, in accordance with the CA vendor’s implementation. System-level analysis is required to select an appropriate CAM for a given deployment. ## Supported DVB-CI Option Cards To decrypt transport streams on MK.IO Beam using CAMs, supported **Common Interface** option cards are required. Refer to the **[Decryption](/beam/reception/tech-specs#decryption)** section of the technical _Reference_ documentation for a list of compatible cards. MK.IO Beam supports multiple PCMCIA slots for CAM insertion.

The Common Interface option card supported by MK.IO Beam is capable of descrambling transport streams with bitrates of up to 96 Mbps. The actual bitrate that can be processed by each CAM depends on the capabilities of the CAM itself.

If the transport stream bitrate exceeds the CAM’s limit, there is no service-limiting feature to remove unused PIDs and reduce the bitrate before it enters the CAM.

## Mutli-Service Descrambling Depending on the capabilities of the CAM in use, one or more programmes (services) can be descrambled using a single CAM. When the [Receiver Configuration Type](/beam/receiver/#receiver-configuration-type) is set to **TS passthrough**, multiple programmes from a single MPTS can be descrambled using the CAM. For decode-oriented _Receiver Configuration Types_, such as **SD/HD** or **UHD**, only one programme can be configured for descrambling per CAM.

A CAM cannot be shared between multiple running Receiver services. To work around this, a common approach is to configure a single TS passthrough Receiver service to descramble multiple programmes using one CAM and output them as a local multicast stream on the MK.IO Beam server. Additional decode-oriented Receiver services can then ingest this locally descrambled multicast and decode individual programmes as required.

## Configuring Common Interface Decryption Refer to [DVB-CI configuration parameters](/beam/receiver/parameters#dvb-ci) for additional settings. ### Enable Common Interface Decryption for Service Decode Common Interface decryption is enabled by assigning a CAM slot in the receiver service configuration. For a _Receiver_ service that has been configured for **UHD** or **SD/HD**, enable Common Interface decryption using the following steps. 1. From the **Home** page, select the **RECEIVER** item from the required feed, then click `Edit` icon to edit 2. From the **Parameters** window, select the **Decrypt** tab. 3. Click the **DVB-CI** tab. 4. Select the required CAM from the list of detected CAMs in the **CAM slot** drop-down menu to enable descrambling. ![Enable descrambling for Decoding](/rx1-img/decode_dvbci_cam_slot.png) 5. From the **Parameters** window, select the **Decoding** tab. 6. From the **Service** drop-down menu, select the programme to be descrambled and decoded, or enter the programme number manually. 7. Once configuration is complete, click **Save and Continue** to apply the changes. ### Enable Common Interface Decryption for TS Passthrough For a _Receiver_ service that has been configured for **TS Passthrough**, enable Common Interface decryption using the following steps. 1. From the **Home** page, select the **RECEIVER** item from the required feed then click `Edit` icon to edit 2. From the **Parameters** window, select the **Decrypt** tab. 3. Click the **DVB-CI** tab. 4. Under the **Program Configuration** section, click the **Add Decrypted Program** button. A new row will appear in the decryption table. ![Enable descrambling for TS Passthrough](/rx1-img/tspassthrough_dvbci_cam_slot.png) 5. Under the **Service** column, select the programme to be descrambled, or enter the programme number manually. 6. Under the **Decryption Type** column, select the required CAM from the drop-down list of detected CAMs and other CA types to enable descrambling. 7. Repeat steps 4 - 6 to add more programmes for descrambling. 8. Once configuration is complete, click **Save and Continue** to apply change.

When a Receiver service is configured for TS Passthrough, the DVB-CI tab includes a CAM selection option listing detected CAM slots. Selecting a CAM here enables exploring CAM information and resetting the CAM.

## Explore CAM Information CAM information varies by vendor and between different versions of the same CAM. You can configure parameters such as the CA PIN or language, and view details including the model number, version, and CAM status. The menu structure and its contents are generated by the CAM. To explore CAM information: 1. The _Receiver_ service or _Feed_ must be in a _Running_ state. 2. From the **Home** page, select the **RECEIVER** item from the required feed then click `Edit` icon to edit 3. From the **Parameters** window, select the **Decrypt** tab. 4. Click the **DVB-CI** tab. 5. Select the required CAM according to the [Receiver Configuration Type](/beam/receiver/#receiver-configuration-type): ### TS Passthrough Select the CAM from the **CAM selection** drop-down menu. ### SD/HD or UHD Select the CAM from the **CAM slot** drop-down menu.

Switching between CAMs will interrupt any programmes currently being descrambled!

6. Click the **Explore CAM in Slot** button to bring up the CAM menu for the CAM assigned in the previous step. 7. A CAM Menu pop-up dialog appears showing the menu structure generated by the CAM. ![view cam information cp](/rx1-img/view_cam_information_cp.png) 8. Click menu items to navigate through the CAM menus. Some navigation terms within the CAM Menu may be confusing, such as “pressing OK” on a television remote control. In a web browser, simply clicking the menu item performs the same action. 9. Click **Exit** at the bottom of the CAM Menu pop-up dialog to close it. ## Reset the CAM If the CAM or smartcard develops a fault, it may be necessary to remove and reinsert it. If immediate access is not possible, the CAM can be reset remotely through the user interface.

Resetting the CAM briefly stops descrambling, which may disrupt the output transport stream or cause decode errors.

To reset the CAM: 1. The _Receiver_ service or _Feed_ must be in a _Running_ state. 2. From the **Home** page, select the RECEIVER item from the required feed then click `Edit` icon to edit 3. From the **Parameters** window, select the **Decrypt** tab. 4. Click the **DVB-CI** tab. 5. Select the required CAM according to the [Receiver Configuration Type](/beam/receiver/#receiver-configuration-type): ### TS Passthrough Select the CAM from the **CAM selection** drop-down menu. ### SD/HD or UHD Select the CAM from the **CAM slot** drop-down menu.

Switching between CAMs will interrupt any programmes currently being descrambled!

6. Click the **Reset CAM in Slot** button to reset the CAM # Director 6 Director 6 delivers secure, end‑to‑end management for contribution and distribution networks, with enhanced content security beyond Director 5 (not supported in Beam). ## Director Features [Conditional Access](/beam/receiver/decryption/director#conditional-access-ca) Enhanced content protection and entitlement management. [Over Air Control](/beam/receiver/decryption/over-air-control) Remotely configure receivers through satellite links. ## Conditional Access (CA)

A Trusted Platform Module (TPM) must be fitted. If not fitted, the Director 6 functionality will be hidden. Please contact MediaKind Customer Support on how to check this.

When the [Receiver Configuration Type](/beam/receiver/#receiver-configuration-type) is set to **TS passthrough**, it is possible to configure multiple programmes from a single MPTS to be descrambled using Director 6. For decode-oriented _Receiver Configuration Types_, such as **SD/HD** or **UHD**, only a single service can be configured for descrambling and decoding. ### Supplying Information to the Director Headend Receivers under the control of a _Director 6 headend_ system must be registered by supplying the **Director Key File** downloaded from the unit. This contains all the information necessary for the _Director 6 headend_ to authorize decrypting scrambled content or accepting Over-Air-Control (OAC) commands. Before you start, ensure at least one service is configured. 1. From the **Home** page, select the **RECEIVER** item from the required feed then click `Edit` icon to edit 2. From the **Parameters** window, select the **Decrypt** tab. 3. Click the **Director 6** tab. 4. From the **Director 6 hardware ID** drop down list, select an ID entry that the _content provider_ can use to address the receiver service. ![Exporting Director 6 Keyfile](/rx1-img/director_export_keyfile.png) 5. Click **Export Keyfile** button to download the **Director Key File**. 6. If other Director 6 hardware IDs are assigned to other receiver services, repeat the above steps to export and download the Director Key File for each unique Director 6 hardware ID assignment. 7. Send the Director Key File(s) to the _content provider_ who will manage entitlements. ## Configuring Director 6 Decryption ### Enable Director 6 Decryption for Service Decode Director 6 decryption is enabled by ticking the **Descrambling Enable** check box in the receiver service configuration. This allows multiple service configurations to decrypt using **Director 6** without being limited to the Director 6 hardware ID. For a receiver service that has been configured for UHD or SD/HD, enable Director 6 decryption with the following steps. 1. From the **Home** page, select the **RECEIVER** item from the required feed then click `Edit` icon to edit 2. From the **Parameters** window, select the **Decrypt** tab. 3. Click the **Director 6** tab. 4. Tick the **Descrambling Enable** check box. ![Enable descrambling for Decoding](/rx1-img/director_enable_decryption.png) 5. Once configuration is complete, click **Save and Continue** to apply change. ### Enable Director 6 Decryption for TS Passthrough For a receiver service that has been configured for TS Passthrough, enable Director 6 decryption with the following steps. 1. From the **Home** page, select the **RECEIVER** item from the required feed then click `Edit` icon to edit 2. From the **Parameters** window, select the **Decrypt** tab. 3. Click the **Director 6** tab. 4. Under the **Program Configuration** section, click the **Add Decrypted Program** button. 5. A new row will appear in the decryption table, set the **Service** to be decrypted and set the _Decryption Type_ to **Director 6**. ![Enable descrambling for TS Passthrough](/rx1-img/director_enable_decryption_passthrough.png) 6. Once configuration is complete, click **Save and Continue** to apply change. # Director 6 ## Over Air Control Director provides a list of Over Air Control (OAC) commands that can target an individual Beam device, a group of Beam devices or the entire population of Beam devices registered in the Director Headend database. This feature is often referred to as **Over Air In-Band control**. The OAC commands can be used to configure the Beam device settings remotely, such as satellite tuning parameters and service selection, through commands injected into the transport stream. Upgrading Beam devices via Director’s over‑the‑air software download feature is not supported. Software updates for MediaKind Beam devices are instead performed using MK.IO.

The receiver MUST be registered to the Director headend before it is able to receive and respond to any OAC commands. Please refer to Supplying Information to the Director Headend

### OAC Commands Supported The following general OAC commands are supported by MK.IO Beam Distribution:
OAC Command Description
Set Message Sets the over air messages that can be viewed in Director Status panel of the UI. This is often used to confirm the receiver will respond OAC commands.
Force Service Selection Changes the receiver to a service within the current carrier.
Force Carrier Retune Retune the receiver to a service in a different carrier, either from a stored configuration or from the command itself.
Store Carrier Data Store service and carrier data within a configuration in the receiver.
Reset Carrier Data Clears the service and carrier data for a stored configuration.
Service Selection Allows the user to select which service is decoded or transcoded when using Stream Processing (SP) to service filter the incoming multiple program transport streams.
Set Receiver Password Sets the password of an existing user account.
Set Receiver State Sets the receiver into one of the following states: Reboot, OAC mode or Local mode.
Set BISS Data Allows the user to configure BISS mode 1 and mode E decryption parameters on the receiver.
### Set Message The **Set Message** OAC command sent to a receiver will be displayed next to the **Over air message** field within the **Director Status** panel from the **Stats** page of a receiver service. The example below has the text message _"Group Message 1"_ sent from the _Director headend_. Example: ![Director Set Message status](/rx1-img/director_status_set_message.png "Set Message status") ### Power Up Carrier The **Power Up Carrier (PUC)** is a feature of Director’s over air control. The PUC can only be configured by the _Director headend_ as it is not possible to do so locally and will be stored in the **PUC Carrier Data Preset slot**. When the PUC has been configured correctly, the next time the receiver is powered up or rebooted and the _Over Air Control_ setting is **enabled**, the receiver will ignore any previous input settings and immediately apply the input settings stored in the **PUC Carrier Data Preset slot**. If the _Over Air Control_ setting was **disabled**, then there will be no change to the current input settings during boot up and the stored **PUC Carrier Data Preset slot** is ignored. It may be useful to configure the PUC so that every time the receiver is powered up, it automatically tunes to the _Director headend_ so that it can maintain over air control of the unit. Status of the Power Up Carrier is available on the **Director Status** panel from the **Stats** page of a receiver service. **Example:** ![Director PUC status](/rx1-img/director_status_set_puc.png "Director PUC status") ### Emergency Home Carrier The **Emergency Home Carrier (EHC)** is a feature of Director’s over air control. The EHC can only be configured by the _Director headend_ as it is not possible to do so locally and will be stored in the **EHC Carrier Data Preset slot**. Once the EHC has been configured correctly and the _Over Air Control_ setting is **enabled**, the receiver will continuously monitor its input status. If the receiver loses transport stream lock on its input or the current program number being decoded is no longer present, after a pre-defined timeout (EHC Timeout), the receiver will immediately apply the input settings stored from the **EHC Carrier Data Preset slot**. If the _Over Air Control_ setting was **disabled**, then there will be no change to the current input settings if the transport stream lock is lost or the selected program number disappears. If a mistake is made when configuring carrier settings for the receiver resulting in a loss of lock, then the _Director headend_ would lose control. The EHC is a safeguard that allows the headend to regain over air control of the receiver. Status of the Emergency Home Carrier is available on the **Director Status** panel from the **Stats** page of a receiver service. **Example:** ![Director EHC status](/rx1-img/director_status_set_ehc.png "Director EHC status") ### Execution Time The receiver uses the time from the incoming Time and Date Table (TDT) to determine when the OAC message is actioned, rather than the system clock time used in the logs. For debugging purposes, the logs display the offset between the system clock and the TDT.

If the unit is locked to the incoming TDT then the system clock will match the TDT time.

## Configuring Director 6 OAC ### Assign Director 6 Hardware ID At least one Receiver service is configured. 1. From the **Home** page, select the RECEIVER item from the required feed then click `Edit` icon to edit 2. From the **Parameters** section, select the **Decrypt** tab. 3. From the **Director 6 hardware ID** drop down field, assign a _hardware ID value_ that is not in use by any of the other receiver services that have been started. ![Assign Director 6 HWID](/rx1-img/director_assign_hwid.png) 4. Once configuration is complete, click **Save and Continue** to apply change.

A receiver service in a running state must be assigned a unique Director hardware ID.

A receiver service in a stopped state may be assigned a Director hardware ID that is already assigned to another service; however, it cannot be started while another service using the same Director hardware ID is running.

### Enable Director 6 Over Air Control At least one Receiver service is configured and already assigned to a unique Director hardware ID. 1. From the **Home** page, select the RECEIVER item from the required feed then click `Edit` icon to edit 2. From the **Parameters** section, select the **Decrypt** tab. 3. Tick the **Over air control enable** check box. Units added to the Director headend database and tuned to the Director headend transport stream will now respond to over the air commands. ![Director enable OAC](/rx1-img/director_enable_oac.png) 4. Once configuration is complete, click **Save and Continue** to apply change. # Transport Stream Input Configuration There are multiple types of transport stream configurations. Each type presents a different set of parameters. ![view edit service cp](/rx1-img/view_edit_service_cp.png) ## Satellite transport stream input The number of satellite inputs will depend on the option card installed. You can route each satellite input to an independent service, or route a single satellite input to multiple services. The satellite input option cards that are compatible with MK.IO Beam will comply with the following standards: - DVB-S (EN300-421) - DVB-S2 (EN302-307-1) - DVB-S2X (EN302-307-2) DVB-S2 offers up to a 30% increase in data rate carriage for an equivalent link margin compared to what the older DVB-S standard can offer. This functionality is often partnered with MPEG-4 or HEVC compression to give bandwidth efficient distribution of high definition or ultra-high definition services. DVB-S2X is an extension to the DVB-S2 standard and can provide up to 20% performance improvement compared to DVB-S2 and increase the efficiency of satellite links. This will enable an increase in video quality or an increase in the number of video services or a reduction in leased satellite bandwidth, bringing lower operational expenditure. ### Supported Satellite Demodulator Cards Satellite input on MK.IO Beam requires supported hardware option cards. See the **[Satellite Input](/beam/reception/tech-specs#satellite-input)** section in the technical _Reference_ documentation for a list of compatible cards. ### Input ports with multiple Tuners and Demodulators Some satellite demodulator cards support more than one tuner and demodulator pairs connected to each RF input port. In this case, an additional tuning parameter is available in the configuration called **Tuner** where the tuner is referenced alphabetically for that RF port, for example **Tuner A** and **Tuner B**.
Physical RF Input First Tuner/Demod Second Tuner/Demod
RF port 1 Tuner A Tuner B
RF port 2 Tuner A Tuner B
Each tuner operates independently and can tune to either a different frequency or the same frequency as another tuner. LNB control is independent per physical RF input; therefore, **Tuners A and B share the same LNB control**. ### Configure a receiver service for satellite input Before you start, ensure a **Receiver** service is configured. 1. From the **Home** page, select the RECEIVER item from the required feed then click `Edit` icon. 2. From the **Primary** tab, select **Satellite** for the **Input type**. Satellite input options display. 3. Set the **LNB** parameters, [**LNB frequency**, **LNB voltage** and **22kHz**](/beam/receiver/parameters#satellite). 4. Set the [**Tuning** parameters](/beam/receiver/parameters#satellite). This will vary based on the card fitted: ### Digital Devices SX8 If **Digital Devices SX8** installed, configure **Tuner**, **Frequency**, **Symbol rate**, **Search range**, **C/N Margin Alarm**, **MIS enable**, **MIS Stream ID**, and **Gold code** ![view parameters satellite input cp](/rx1-img/view_parameters_satellite_input_cp.png) ### Dektec DTA-2127 If **Dektec DTA-2127** installed, configure **Frequency**, **Symbol rate** and **C/N Margin Alarm** ![view parameters dektec satellite input cp](/rx1-img/view_parameters_dektec_satellite_input_cp.png) 5. Ensure that the **Source Status** is green (receiving) for existing sources, and that no errors occur. ![view parameters satellite input status cp](/rx1-img/view_parameters_satellite_input_status_cp.png) ## ASI transport stream input ### Supported ASI Input Cards ASI input on MK.IO Beam requires supported hardware option cards. See the **[ASI Input](/beam/reception/tech-specs#asi-input)** section in the technical _Reference_ documentation for a list of compatible cards. ### Setup ASI/SDI option card for ASI mode To use the card as an ASI card it must be configured as follows (see also [Set up SDI/ASI cards](/beam/system-admin/maintenance/setup-sdi-asi-card/)): 1. Select `sliders` icon **Appliance** from the left-hand side menu. 2. Click the **ASI/SDI Interface** tab. 3. Select the **Slot** Tab corresponding to the SDI/ASI card. If more than one card is present, there will be a separate slot tab for each card. 4. Select : - For the Dektec 2174B cards : **4 ASI/HD-SDI/SD-SDI** from the **ASI/SDI Mode** drop down menu. - For the Dektec 2178 cards : **8 ASI/HD-SDI/SD-SDI** from the **ASI/SDI Mode** drop down menu. 5. Click the **Apply and Reboot** button. 6. A confirmation pop-up window will appear asking, "Are you sure?" 7. Review any warnings or guidance provided. If you are sure, click **Yes, configure and REBOOT!** Otherwise, click **Cancel** to abort. 8. Following the reboot, refresh the web page. The reboot may take a few minutes to complete. ### Configure a receiver service for ASI input Before you start, ensure a **Receiver** service is configured. 1. From the **Home** page, select the RECEIVER item from the required feed then click `Edit` icon to edit. 2. From the **Primary** tab, select **ASI** for **Input type**. 3. Select the port on the ASI card where the transport stream is connected (the port number maps directly to the numbering on the card). 4. Ensure that the [**Input Status**](/beam/receiver/parameters#asi) is green (receiving) and that they're no errors (this only applies if the source currently exists). ## IP transport stream input A Receiver service can support decoding or passthrough of transport streams via Ethernet. ### Configure a receiver service for IP unicast input Before you start, ensure at least one **Receiver** service is configured. 1. From the **Home** page, select the RECEIVER item from the required feed then click `Edit` icon to edit. 2. From the **Primary** tab, tick [**Unicast**](/beam/receiver/parameters#ip). [**Stream address**](/beam/receiver/parameters#ip) is greyed out and a port parameter displays. ![view edit service input unicast cp](/rx1-img/view_edit_service_input_unicast_cp.png) 3. Enter the UDP [**Port**](/beam/receiver/parameters#ip) number for the incoming transport stream. 4. Select the Ethernet port for the [**Network interface**](/beam/receiver/parameters#ip) that the incoming transport stream is available on. 5. Ensure that the [**Input status**](/beam/receiver/parameters#ip) is green (receiving) and that they're no errors (this only applies if the source currently exists). ### Configure a receiver service for IP multicast input Before you start, ensure at least one **Receiver** service is configured. Transport streams can be streamed over either Ethernet (IP) or ASI depending on the hardware installation. 1. From the **Home** page, select the RECEIVER item from the required feed then click `Edit` icon to edit. 2. From the **Primary** tab, check that the [**Unicast**](/beam/receiver/parameters#ip) checkbox is unticked then enter a multicast [**Stream address**](/beam/receiver/parameters#ip). ![view edit service cp](/rx1-img/view_edit_service_cp.png)

The Multicast parameter is grayed out if Unicast is selected.

3. Enter the [**UDP port**](/beam/receiver/parameters#ip) number for the incoming transport stream. 4. Select the Ethernet port for the [**Interface**](/beam/receiver/parameters#ip) that the incoming transport stream is available on. 5. Ensure that the [**Input status**](/beam/receiver/parameters#status) is green (receiving) and that they're no errors (this only applies if the source currently exists). # Receiver Input Redundancy For each _Receiver_ service configuration, the default input is designated as the **Primary** input. If the this input fails, the service will stop descrambling and/or decoding. It is possible to configure **input redundancy** for the _Receiver_ service by choosing a **Redundancy Mode** and defining a **Secondary** (backup) input. ## Redundancy Mode Options
Redundancy Mode Key Behaviour Speed Auto Switching
Off Primary only — None
Active Passive (one-hit) One-time failover, Primary active and Secondary on demand Slow One-hit
Active Active (one-hit) One-time failover, Primary and Secondary both active Fast One-hit
Active Active (switch on failure) Continuous failover between Primary and Secondary active inputs Fast Ongoing
SMPTE ST 2022-7 Seamless Protection Switching between two IP data paths. Fast Ongoing
### Off The service only uses the Primary input. It is not possible to automatically or manually use the Secondary input. ### Active passive (one-hit) If the Primary input fails then the _Receiver_ service will make a **one-hit** switch to the Secondary input. The Secondary input is only **started on demand** so the switch occurs without verifying whether the Secondary input has a valid source that can be locked to. Once the service switches to the Secondary input, it will not automatically revert to the Primary input. Manual intervention is required. The user can manually switch between inputs at any time. ### Active active (one-hit) If the Primary input fails then the _Receiver_ service will make a **one-hit** switch to the Secondary input. The Secondary input is **always active** so will result in quicker switching. However, the switch still occurs without verifying whether the Secondary input has a valid source that can be locked to. Once the service switches to the Secondary input, it will not automatically revert to the Primary input. Manual intervention is required. The user can manually switch between inputs at any time. ### Active active (switch on failure) If the current input (Primary or Secondary) fails, the _Receiver_ service switches to the alternate input. Both Primary and Secondary inputs are **always active** so switching between them is fast. The service switches on failure regardless of whether the alternate input has a valid lock. If neither input is valid, the service continuously switches between them until a valid lock is detected. The user can manually switch between inputs at any time. ### SMTPE ST 2022-7 SMPTE ST 2022-7 Seamless Protection Switching is only available when both Primary and Secondary inputs are configured as IP inputs. It requires two identical RTP transport streams to be carried independently over separate network paths for redundancy. Both streams are received simultaneously and synchronised within the receiver, allowing packet loss on either path to be mitigated using packets from the other. ## Receiver Input Redundancy Configuration Any of the [Input Types](/beam/receiver/input) supported by the _Receiver_ service can used as the **Primary** or **Secondary** input when enabling any of the **Input Redundancy** modes. ### Configure a Receiver service for Input Redundancy mode Before you start, ensure at least one **Receiver** service is configured. 1. From the **Home** page, select the RECEIVER item from the required feed then click `Edit` icon to edit. 2. Select the **Input** tab under the _Parameters_ section. 3. Select the desired **Redundancy mode** [option](/beam/receiver/input/input-redundancy#redundancy-mode-options). ![Select Redundancy mode option](/rx1-img/receiver-input-redundancy.png) 4. Set the **Input loss timeout** to the delay (in milliseconds) between detecting an input error and switching to the alternate input.

If the input error is cleared before the end of the Input loss timeout, the redundancy switch is aborted and the service will continue to use the current input.

5. If **SMPTE ST2022-7** is selected as the _Redundancy mode_, the **Max skew** parameter specifies the maximum permitted timing difference (in milliseconds) between two IP data streams. If the measured skew exceeds this value, packets may be lost during seamless protection switching. 6. Select the **Primary** tab and configure the input as decribed in the [Transport Stream Input Configuration](/beam/receiver/input) section. 7. Select the **Secondary** tab and configure the input as decribed in the [Transport Stream Input Configuration](/beam/receiver/input) section. 8. Once complete, click **Save and exit**.

A 20 second delay occurs from the moment you save in order to initialize the redundancy configuration. Any loss of input or alarms raised on the Primary input during this time does not cause a switch.

### Manually Switch Between Primary and Secondary inputs Manual switching between Primary and Secondary inputs is possible even when both inputs are healthy. This is not supported for SMPTE ST 2022-7. Before you start, ensure at least one **Receiver** service is configured with a **Redundancy mode** selected. 1. From the **Home** page, select the RECEIVER item from the required feed then click `Edit` icon to edit (or click `Chart` icon to view the Statistics page). 2. Locate the **Input Status** section of the page and click the **Switch Input** icon `Left/Right` icon. ![Click Switch Input button](/rx1-img/receiver-input-redundancy-switch-input.png) # Configure the output MK.IO Beam can output decoded video, audio and data using one or more of the following transport methods for distribution to other devices: [SDI Output](/beam/receiver/output/sdi) Broadcast standard for transmitting uncompressed video, audio, and data over coaxial or fiber cables. [SMPTE ST 2022-6 Output](/beam/receiver/output/smpte-st-2022-6) IP-based standard that encapsulates a complete SDI signal (video, audio, and data) into a single stream. [SMPTE ST 2110 Output](/beam/receiver/output/smpte-st-2110) Native IP standard that transports video, audio, and data as separate, independent streams. [Transport Stream Passthrough](/beam/receiver/output/ts-passthrough) Convert a satellite feed into an IP UDP multicast transport stream and decrypt the content. ## Output Profile selection Some output configurations require optimizations to get the best performance. The following **output profiles** are available:
Output Profile Receiver Service Type Other Service Types
Standard Recommended for:
- SDI output (all video formats)
- SMPTE ST 2022-6 output (all video formats)
- SMPTE ST 2110 output (SD/HD video formats)
Recommended
SMPTE ST 2110 UHD Output Mandatory for:
- SMPTE ST 2110 output (UHD video formats)
Not recommended
These **output profiles** are optimized for the _Receiver_ service and support mixed output configurations. For other service types, such as _Live Encoding_, use the **Standard** output profile. ### Service Running Blocked by the Current Output Profile In some cases, a _Receiver_ service may be prevented from starting and entering the _Running_ state. In this case, an alarm is raised indicating that the service configuration is not compatible with the selected **output profile**. Refer to the alarm description for guidance on resolving the issue and bringing the service into the _Running_ state. For example, if the output profile is set to **Standard** and a UHD receiver service is configured for SMPTE ST 2110 output, a **Service blocked** alarm will indicate that **SMPTE ST 2110 UHD Output** is required. While the alarm is active, the service remains in a _Failed_ state and cannot enter the _Running_ state. ## Configure the Output Profile To configure the output profile, follow these steps: 1. Select `sliders` icon **Appliance** from the left-hand side menu. 2. Click the **Output Profile** tab. 3. Select the appropriate output profile setting from the **Output profile** drop-down menu 4. Click the **Apply and Reboot** button. 5. A confirmation pop-up window will appear asking, "Are you sure?" 6. Review any warnings or guidance provided. If you are sure, click **Yes, configure and REBOOT!** Otherwise, click **Cancel** to abort. 7. Following the reboot, refresh the web page. The reboot may take a few minutes to complete. # Set 3G SDI output level The 3G‑SDI output level is applicable only to 1080p video outputs, either as a standalone HD service or as part of a quad‑link 3G‑SDI 4K service. - **Level A** maps the SMPTE ST 274 format directly to a 3 Gb/s serial digital interface. - **Level B Dual-Link** splits the 1080p image into SMPTE ST 372 dual‑link streams and conveys them within a 3 Gb/s serial digital interface.

When 3G‑SDI Level B Dual Link is selected and the video format is 1080p or 2160p, ancillary data is inserted into the specified line number (n) of each link. For example, if Line 9 is selected for VITC, the data is inserted into line 9 of Link 1 and line 572 of Link 2.

### Configuring 3G-SDI Level To set the 3G-SDI level for outputting 1080p video, follow these steps: 1. On the **Home** page, select the **RECEIVER** item from the required feed, then click `Edit` icon to edit. 2. In the **Parameters** window, select the **Output** tab. 3. Select the tab for the SDI output type, for example **SDI 1**. 4. Select the required SDI output level from the **3G-SDI Level** drop-down menu: ![view 3G SDI level cp RX1](/rx1-img/view_sG-SDI_level_cp_RX1.png) 5. Click **Save and Continue** to apply change. # Configure audio output The Receiver service supports a maximum of 16 channels (8 stereo pairs) of embedding for any baseband audio output. Before you start, ensure: - At least one Receiver service is configured. - A video service and at least 1 audio component is configured to be decoded. ## Add an output audio component 1. From the **Home** page, select the required field. 2. Select the **RECEIVER** item from the required feed then click `Edit` icon. 3. From the **Parameters** section, select **Output** to display options. 4. Go to the **Audio** tab to open the tab and display options then select **Add component**. An audio component displays. 5. Configure audio output parameters.

Lipsync may be adjusted in the range +- 50mS. In low delay modes negative lip-sync adjustments may not be possible.

## Add all output audio 1. From the **Home** page, select the **RECEIVER** item from the required feed then click `Edit` icon. 2. From the **Parameters** section, select **Output** to display options. ![rx1 output audio add all](/rx1-img/rx1_output_audio_add_all.png) 3. Go to the **Audio** tab then select **Add all**. All the decoded audio components that are not currently included in the output audio configuration are added to the component column (**up to a maximum number of embedded channels available for the output video format in use**). Embedded channels are allocated in sequence until all available channels are filled. ## Delete an output audio 1. From the **Home** page, select the **RECEIVER** item from the required feed then click `Edit` icon. 2. From the **Parameters** section, select **Output** to display options. 3. Go to the **Audio** tab then click `Delete` icon in the **Actions** column. The audio component no longer displays. ## Delete all output audio 1. From the **Home** page, select the **RECEIVER** item from the required feed then click `Edit` icon. 2. From the **Parameters** section, select **Output** to display options. 3. Go to the **Audio** tab then select **Remove all**. All the audio components are now removed from the list of output configurations. ## Configure Audio Embedding 1. From the **Home** page, select the **RECEIVER** item from the required feed then click `Edit` icon. 2. From the **Parameters** section, select **Output** to display options. 3. Go to the **Audio** tab then select a **Component** from the drop-down list. Available audio components are based on the audio being decoded for the service. 4. Select an **Embedding** position from the drop-down list.
  • A single Embedded channel is required to output a stereo audio.
    • 3 Embedded channels are required to output a 5.1 audio.
![rx1 receiver output audio embedding](/rx1-img/rx1_receiver_output_audio_embedding.png) Each audio component is embedded into the output SDI at the selected position.
Output Format Embedded options
1.5G SDI (720p/1080i) Embedded 1 to 8
3G SDI (1080p) Embedded 1 to 16
4 x 3G SDI (2160p) Embedded 1 to 16
12G SDI (2160p) Embedded 1 to 16
# Clock reference ## Prerequisites for using an External sync - The studio feed must be of the same frequency as the video service being decoded by the receiver. - If multiple services are being decoded they must all be of the same frequency: - 50 Hz (field timing for interlaced or frame timing for progressive) - 59.94 Hz (field timing for interlaced or frame timing for progressive) ## Contribution decoder The Beam server supports an external sync input BNC (located on the rear of the unit). This allows you to select one of the following options: - **Free running:** uses an internally generated reference clock. - **External sync:** synchronize the unit to either a reference 10MHz studio reference clock so that the output video (either in UHD, HD or SD) aligns with the studio feed.

The Beam server automatically detects the type of external-sync applied and attempts to lock the SDI output to the external reference supplied. If the unit detects a signal mismatch then frame sync will not be acquired and the unit will continue to run using its own internal sync.

## Configure the clock reference To configure the clock reference, follow these steps: 1. From the **Home** page, select the **RECEIVER** item from the required feed then click `Edit` icon. 2. Select the **Clock reference** format required for the SDI output.\ Possible options: - **Free running** - **External sync** (External sync requires a specific cable installation, see Installation Guide).

For further information on options, see SDI output parameters and status.

## Configure the external sync offset The server has been set to **External sync** with a valid reference studio clock applied to the Sync input. The playout timing of each SDI output frame can be adjusted (advanced or delayed) in single pixel increments relative to the external frame sync.

External sync requires a specific cable installation (see Quick Start Guide).

1. From the **Home** page, select the **RECEIVER** item from the required feed then click `Edit` icon. 2. From the **Parameters** section, select to **Output** tab. ![view clock reference output cp rx1](/rx1-img/view_clock_reference_output_cp_rx1.png) 3. Enter the offset required in pixels to be applied in the **External sync offset** field. # Configure data output Data is embedded into the VANC (Vertical Ancillary) lines of the SDI output. It is possible to embed more than one data type onto a single VANC line. MK.IO Beam Distribution currently supports the following data types: - VITC / Time code - AFD / BAR - Closed Captions - OP-47 Teletext - SMPTE 2031 Teletext - Generic data

See output parameters descriptions for additional information.

Before you start, ensure: - At least one Receiver service is configured. - The service to be decoded has been selected from the **Selected Service** list in the **Input** tab. 1. From the **Home** page, select the **RECEIVER** item from the required feed then click `Edit` icon. 2. From the **Parameters** section, select **Output** to display options. 3. Select **Data** to open the tab and display options. ![view edit service output sdi data cp](/rx1-img/view_edit_service_output_sdi_data_cp.png) 4. Select the Line number from the drop-down menu.\ Each selected data component (if present on the incoming transport stream) is now either decoded from a data PID or is extracted from User data or SEI in the video elementary stream.

Generic data is automatically reinserted into the same line it came in.

## Disable data output Before you start, ensure: - At least one Receiver service is configured. - The service to be decoded has been selected from the **Selected Service** list in the **Input** tab. 1. From the **Home** page, select the **RECEIVER** item from the required feed then click `Edit` icon. 2. From the **Parameters** section, select **Output** to display options. 3. Select **Data** to open the tab and display options. ![rx1 receiver output data disable](/rx1-img/rx1_receiver_output_data_disable.png) 4. Select **OFF** from the drop-down menu for each data that you want to disable. Once disabled, the data is no longer embedded into SDI outputs. # Video Conversion Each _Receiver_ service can convert an input video resolution to a different output resolution (i.e. up-conversion or down-conversion). The processed video can be passed through to output standards such as SDI, SMPTE ST 2022-6, or SMPTE ST 2110. ## Supported Conversions The following output resolution conversions are supported. Frame-rate is preserved; conversions between interlaced and progressive formats are supported where applicable.
Input resolution SD Output 720p Output 1080i Output 1080p Output 2160p Output
UHD ✔ ✔ ✔ ✔
1080p ✔ ✔ ✔
1080i ✔ ✔ ✔
720p ✔ ✔
SD ✔
## Configuring Video Scaling Video conversion is controlled using the **Video Scaling** option. It is also available when [Multiple Outputs](/beam/receiver/output/multiple-outputs) have been added.

If the decoded input format is not supported by the target output (for example, UHD routed to a 3G-SDI-capable output port), the video must be down-converted to a supported format such as 1080p.

### Enabling Video Scaling To enable video scaling for a specific _Receiver_ service, follow these steps: 1. On the **Home** page, select the **RECEIVER** item from the required feed, then click `Edit` icon to edit. 2. In the **Parameters** window, select the **Output** tab. 3. From the **Video scaling** drop-down menu, select the required output resolution. Select **No scaling** to disable conversion. 4. After completing the configuration, click **Save and Continue** to apply the changes.

If the decoded input format and the selected Video scaling is not supported, an alarm will be raised.

# HDR to SDR Conversion MK.IO Beam supports HDR-to-SDR conversion for decoded video, compressing the dynamic range of HDR content to ensure compatibility with standard dynamic range (SDR) systems. ### Supported HDR formats Conversion is supported for the following HDR formats: - PQ10/HDR10 - HLG10 Inputs in these formats are tone-mapped to SDR, producing an SDR signal with transfer characteristics compliant with BT.709, as defined by the selected tone-mapping _lookup table (LUT)_. ## Configuring HDR to SDR Conversion ### Enabling Dynamic Range Conversion Each _Receiver_ service can be configured for HDR to SDR conversion. Before you start, ensure at least one Receiver service is configured. 1. From the **Home** page, select the **RECEIVER** item from the required feed then click `Edit` icon. 2. In the **Parameters** window, select the **Output** tab. 3. Configure _HDR-to-SDR conversion_ by setting the **Dynamic Range Conversion** option to one of the following selections: - **None**: HDR-to-SDR conversion is disabled; the video is passed through unchanged - **Custom HDR to BT.709 lookup table**: Use the specified custom LUT to output BT.709 encoded SDR - **Convert to BT.709**: Use proprietary tone-mapping LUT to output BT.709 encoded SDR 4. If _Dynamic Range Conversion_ has been set to **Custom HDR to BT.709 lookup table** then select the required custom LUT description from the **Custom HDR to BT.709 lookup table** drop-down option. ![receiver decoding video hdr to sdr](/_machine-assets/62cd9b5a072ac620985f2f46bc2a32491f0cc284997e4ccfdc117d98546471a0.png) 5. Click **Save and continue** to save your changes.
  • If the incoming stream is already SDR, conversion is automatically bypassed.
  • It cannot be verified whether a selected custom LUT is compatible with the supported HDR formats listed above, so care should be taken when selecting custom LUTs.
  • If an issue occurs during HDR-to-SDR conversion, an alarm is raised.
## HDR to SDR Conversion Lookup Tables HDR-to-SDR conversion uses **3D look-up tables (3D LUTs)**, provided as **.cube** files, to map input RGB values to output RGB values within a three-dimensional grid, enabling complex colour transformations. MK.IO Beam supports **size 33** LUTs. ### Viewing Stored LUTs Multiple LUTs can be stored on MK.IO Beam and individually selected by a _Receiver_ service. The **Stored LUTs** section lists custom LUTs which have been uploaded to the MK.IO Beam device: 1. Select `sliders` icon **Appliance** from the left-hand side menu. 2. Click the **HDR > SDR Conversion** tab. ![hdr sdr conversion tab](/_machine-assets/77fed46835940d423e697558e4466a5fc0256f0b8ea413b324eb10edaf4adc74.png) Each row in the **Stored LUTs** section provides the following information and their current settings. Some settings can be modified and saved using the **Update** button.
Parameter Description
Description The reference description given to the custom LUT. This will be listed in the selection when configuring HDR to SDR conversion in the Output settings of a Receiver service.
Filename The filename of the .cube file that was uploaded.
Input Full Range This determines whether input samples are processed using the full (EBU R 103) range or the standard (limited) YUV range.
Output Full Range This determines whether output samples are processed using the full (EBU R 103) range or the standard (limited) YUV range.
Creation Date Date and time when the custom LUT was uploaded.
Last Modified Data and time when the custom LUT was last modified.
File CRC Unique CRC value of the .cube file that was uploaded.
Actions Possible actions for the custom LUT:
- Update: Any modifications must be saved by using this button
- Delete: Delete the custom LUT from the device
### Built-in LUTs MK.IO Beam includes built-in 3D LUTs. These do not appear in the **Stored LUTs** table on the `sliders` icon **Appliance** pages, but are available for selection when configuring HDR to SDR conversion in the Output settings of a _Receiver_ service. See the [Configuring HDR to SDR Conversion](/beam/receiver/output/hdr-sdr#configuring-hdr-to-sdr-conversion) section for more information. ### Uploading Custom LUTs To upload additional LUTs, follow these steps: 1. Select `sliders` icon **Appliance** from the left-hand side menu. 2. Click the **HDR > SDR Conversion** tab. 3. Select the **Upload LUT** textbox. A file explorer window will appear. 4. Use the file explorer to navigate to the LUT file to upload. Only **.cube** files will be accepted by MK.IO Beam. 5. Click the **Description** testbox to add a unique description of the LUT so that it can be easily referenced when enabling _Dynamic Range Conversion_. 6. Enable or disable the **Input Full Range** setting as required. 7. Enable or disable the **Output Full Range** setting as required. 8. Once the settings are complete, click the **Upload** button to store the custom LUT on the device. ![hdr sdr conversion tab](/_machine-assets/341abe88ca6844746c85836bab21949d8c94773d72f4665733ce5d0c13e01a34.png) # Configure multiple outputs on a service It is possible to add multiple outputs to a single decode. When a service is created a single SDI output or SMPTE ST2110 output is automatically assigned. ![view parameters output sdi cp rx1](/rx1-img/view_parameters_output_sdi_cp_rx1.png) 1. From the **Home** page, select the **RECEIVER** item from the required feed then click `Edit` icon. 2. From the **Parameters** section, select to **Output** tab. 3. Click + to add an output. ![view output SDI tabs cp rx1](/rx1-img/view_output_SDI_tabs_cp_rx1.png) 4. Select the **Output Type**.\ If another service is already using this interface when you try to start the service then it will be blocked from starting until one of the following conditions is met: - an unused port is selected for the new service - the current running service is stopped - the service is reconfigured to avoid a clash - the added Output interface is deleted. If the service is blocked from starting for this reason, then the alarm icon displays an appropriate alarm, for example: `Insufficient Resources – SDI 1 already in use`. # SCTE-35 to SCTE-104 Each _Receiver_ service can extract SCTE‑35 messages from the incoming transport stream when SCTE‑35 PIDs are configured for data decoding using the [SCTE‑35 Splicing](/beam/receiver/decoding/#data-decoding) data type. These messages are then filtered and converted into SCTE‑104, enabling output over SDI VANC or SMPTE ST 2110‑40, for example.

This functionality is available for each decode service on MK.IO Beam.

## SCTE-35 commands A number of Splice commands are defined within SCTE-35 but only the following commands are filtered by the _Receiver_ service, all others are silently ignored:
SCTE-35 Splice Command Splice Command Type Conversion to SCTE-104 Description
splice_null() 0x00 splice_null_request_data() This command is provided for extensibility and can be used to generate a heartbeat message for downstream splicing equipment. It is passed through the receiver transparently without modification.
splice_insert() 0x05 splice_request_data() This command syntax supports multiple types of splice messages. The primary subtypes include splice Network Out/In points and splice cancel messages.
time_signal() 0x06 time_signal_request_data() Provides precise timing for splice events. It is typically used in conjunction with segmentation descriptors.
Segmentation descriptors will be preserved and converted into SCTE‑104 segmentation descriptor messages.
## Configuring SCTE-35 to SCTE-104 Conversion ### Configuring SCTE-35 Decode Use the following steps to configure SCTE-35 decoding: 1. Ensure [Service Selection](/beam/receiver/decoding/#service-selection) is configured. 2. Follow [Configure data decoding](/beam/receiver/decoding/#configure-data-decoding) to add a **data** component that contains SCTE-35 messages. 3. Set the **Data type** for the newly added data component to **SCTE 35 Splicing**. 4. Click **Save and Continue** to apply the changes. Decoded SCTE‑35 messages are automatically converted to SCTE‑104 when SCTE‑104 output is enabled. ### Configuring SCTE-104 Output SCTE‑104 messages are inserted into the output either by **pass-through as generic VANC data**, or by **conversion from decoded SCTE‑35 messages**. Use the following steps to configure SCTE-104 output: 1. From the **Home** page, select the RECEIVER item from the required feed then click `Edit` icon to edit. 2. From the **Parameters** section, select the **Output** tab. 3. Select the **Data** tab. 4. From the **SCTE 104 splicing** drop-down list, select the line on which to insert the generated SCTE‑104 message. Valid lines ranges are: - Line 7 to line 41 (Field 1) - Line 569 to line 583 (Field 2)

When SCTE‑104 Splicing is enabled with a valid line number, the additional SCTE 104 splicing configuration options become available. Setting the SCTE-104 Splicing line selection to OFF hides these options.

![enable scte 104 splicing](/rx1-img/beam_output_splice_enable.png) 5. Refer to [SCTE 104 Splicing configuration parameters](/beam/receiver/parameters#scte-104-splicing) for additional settings. 6. Click **Save and Continue** to apply the changes. ## Time Signal Conversion A `time_signal()` splice command may include an optional `segmentation_descriptor()`. When present, this can be translated into SCTE‑104 `multiple_operation_message`, comprising: - `time_signal_request_data()`, followed by - `insert_segmentation_descriptor_request_data()` ### Configuring Time Signal Conversion To enable or disable time signal conversion: 1. Enable Splicing by following [Configuring SCTE-104 output](/beam/receiver/output/scte35-to-scte104#configuring-scte-104-output). 2. Select the **Time Signal** checkbox to enable or disable conversion of the `time_signal()` splice command. 3. Click **Save and Continue** to apply the changes. ## Event ID filtering Event ID filtering, also referred to as _Addressable DPI_, allows the _Receiver_ service to filter out undesired DPI events according to the `splice_event_id` in the incoming SCTE-35 messages. Typically, this would be used at downlink sites. For example, Receiver services can be grouped so that: - all receivers in **Group 1** output only messages with `splice_event_id` = 1, - all receivers in **Group 2** output only messages with `splice_event_id` = 2, and so on. When Event ID filtering is enabled, each SCTE‑35 message is evaluated against the filter. Only messages that match the filter are converted to SCTE‑104 for output; all others are dropped. When filtering is disabled, all SCTE‑35 messages are converted to SCTE‑104. ### How the Filter Works The filter compares two values: - _A_ = bitwise AND of the **Event ID mask** and `splice_event_id` from the `splice_insert()` message - _B_ = bitwise AND of the **Event ID mask** and the user-defined **Event ID value** If _A_ equals _B_, the SCTE‑35 message passes the filter and is converted to SCTE‑104. **Example** Worked example with: - SCTE-35 message with the **splice\_event\_id** = 0xA0001200 - **Event ID mask** = 0x10001000 - **Event ID value** = 0x00001000 ``` Binary (Hex) splice_event_id: 10100000 00000000 00010010 00000000 (0xA000 1200) Event ID mask: AND 00010000 00000000 00010000 00000000 (0x1000 1000) Result A: = 00000000 00000000 00010000 00000000 (0x0000 1000) Binary (Hex) Event ID value: 00000000 00000000 00010000 00000000 (0x0000 1000) Event ID mask: AND 00010000 00000000 00010000 00000000 (0x1000 1000) Result B: = 00000000 00000000 00010000 00000000 (0x0000 1000) ``` - A = 0x00001000 - B = 0x00001000 Since _A_ equals _B_, the SCTE‑35 message passes the filter and is converted to SCTE‑104. ### Configuring Event ID filtering To configure the Event ID filter: 1. Enable Splicing by following [Configuring SCTE-104 output](/beam/receiver/output/scte35-to-scte104#configuring-scte-104-output). 2. Select the **Event ID filter** checkbox to enable filtering. ![enable scte 104 event id filter](/rx1-img/beam_output_splice_event_id_filter.png) 3. Set the **Event ID mask** with a value in hexadecimal. 4. Set the **Event ID value** with a value in hexadecimal. 5. Click **Save and Continue** to apply the changes. # Configure SDI output The _Receiver_ service on MK.IO Beam can output uncompressed digital video, audio, and ancillary data using the SDI output standards. ## Supported SDI Output Cards SDI output on MK.IO Beam requires supported hardware option cards. See the **[SDI Output](/beam/reception/tech-specs#sdi-output)** section in the technical _Reference_ documentation for a list of compatible cards. ## Configuring SDI Output ### Configuring ASI/SDI mode To use the card as a SDI output card it must be configured as follows (see also [Set up SDI/ASI cards](/beam/system-admin/maintenance/setup-sdi-asi-card/)): 1. Select `sliders` icon **Appliance** from the left-hand side menu. 2. Click the **ASI/SDI Interface** tab. 3. Select the **Slot** Tab corresponding to the SDI/ASI card. If more than one card is present, there will be a separate slot tab for each card. 4. Select the appropriate ASI/SDI mode from the **ASI/SDI Mode** drop down menu. The _description_ shows which SDI standards are supported (for example, UHD output may not be supported). 5. Click the **Apply and Reboot** button. 6. A confirmation pop-up window will appear asking, "Are you sure?" 7. Review any warnings or guidance provided. If you are sure, click **Yes, configure and REBOOT!** Otherwise, click **Cancel** to abort. 8. Following the reboot, refresh the web page. The reboot may take a few minutes to complete. ### Determine SDI output card Slot number SDI port selection is referenced with its card slot number to differentiate where multiple cards are fitted to the server. The card name/type for an assigned slot number can be determined using the following steps: 1. Select `sliders` icon **Appliance** from the left-hand side menu. 2. Click the **ASI/SDI Interface** tab. 3. Select the **Slot** Tab corresponding to the SDI/ASI card. If more than one card is present, there will be a separate slot tab for each card. The selected Slot tab should list some useful data such as card model, serial number, etc.

There is a known issue on some servers where the reported slot number does not match the slot number printed on the rear chassis.

### SDI output port Before you start, ensure at least one _Receiver_ service is configured. 1. From the **Home** page, select the ****RECEIVER**** item from the required feed then click `Edit` icon. 2. In the **Parameters** window, select the **Output** tab. 3. Select the **SDI 1** tab. If the **SDI** tab is not present under the **Output** tab: - Click the `Add` icon to bring up a prompt to add a new output - Select **SDI** from the drop down menu - Click the **Add** button to complete and add the SDI output tab 4. Select the **SDI port** required from the drop down menu. ![rx1 receiver output sdi](/rx1-img/rx1_receiver_output_sdi.png) 5. Select any required video options as detailed in the [SDI output parameters](/beam/receiver/parameters#sdi-output-parameters-and-status) section

SDI ports in use by other running services are listed in the drop-down menu, along with the associated service name. A service configured to use an SDI port that is already in use will be prevented from running.

If an SDI port appears to be missing or listed as 3G-capable instead of 12G-capable, this may be due to the selected ASI/SDI mode. Refer to the Configuring ASI/SDI mode section to update the setting.

# Set SDR/HDR Signalling SDR/HDR signalling ensures that downstream devices interpret the video signal correctly and apply the appropriate display characteristics (for example, brightness, contrast, and colour gamut). In most cases, the signalling information is extracted from the incoming transport stream. If this metadata is missing or incomplete, you can override it and explicitly specify the desired dynamic range signalling.

The Dynamic range signalling setting does not perform any dynamic range conversion of the decoded video. It only defines the signalling metadata embedded in the outgoing video stream.

## Dynamic Range and Color Standards SDR and HDR describe the luminance range and transfer characteristics of a video, not the chromaticity or color primaries. ITU-R recommendations BT.601, BT.709, and BT.2020 define those color primaries and colorimetry independently of dynamic range. BT.601 covers SD, with distinct primary sets for 525-line (NTSC) and 625-line (PAL) systems; BT.709's HD primaries match BT.601's 625-line variant; BT.2020 covers the wider gamut used for UHD and HDR.
Video Format Dynamic Range Color Standard
SD SDR BT.601
HD SDR BT.709
HD HDR (PQ or HLG) BT.2020
UHD HDR (PQ or HLG) BT.2020
In practice, HDR workflows typically use BT.2020 as the color container because modern displays and delivery systems support wider gamuts, but this is a pairing choice rather than a strict requirement. ## Dynamic Range Signalling ### Supported Signalling Options The two most commonly used HDR transfer functions are **PQ (SMPTE ST 2084)** and **HLG (ITU-R BT.2100)** and so these are available when selecting the **Dynamic range signalling** in the _Receiver_ service configuration.
Dynamic range signalling option Dynamic range signalled on the output Color standard signalled on the output
Follow input - -
SDR (BT.709) SDR BT.709
SDR (BT.2020) SDR BT.2020
HDR HLG10 HDR HLG transfer function with 10-bit precision BT.2020
HDR PQ10 HDR PQ transfer function with 10-bit precision BT.2020

Notes on the Follow input selection:

  • By default, a new Receiver service outputs video signalling SDR (BT.709).
  • When a dynamic range standard is successfully extracted, the output video signals the extracted standard.
  • When the dynamic range standard is lost, the last extracted standard continues to be signalled on the output video.
  • If the video input is lost, the last decoded standard continues to be signalled on the output video, and outputs video according to the Video fail mode selection.
  • Follow input will automatically follow any conversions made with HDR to SDR conversion so it will be unnecessary to manually override and select SDR.
### Configuring Dynamic Range Signalling To manually set the standard to be used for SDR or HDR signalling follow the steps below: 1. On the **Home** page, select the **RECEIVER** item from the required feed, then click `Edit` icon to edit. 2. In the **Parameters** window, select the **Output** tab. 3. Select the tab for the required output type, for example **SDI 1**. 4. Select the appropriate setting from the **[Dynamic range signalling](/beam/receiver/output/sdr-hdr#supported-signalling-options)** drop-down menu: - Select **Follow input** to extract the video format from the incoming transport stream and embed into the output video. - Select one of the **SDR** or **HDR** standards to override the incoming format and embed into the output video. ![view service output parameters sdr hdr signalling](/rx1-img/view_service_output_parameters_sdr_hdr_signalling.png) 5. Click **Save and Continue** to apply change. # SMPTE ST 2022-6 output The Receiver service on MK.IO Beam can output SDI over IP using SMPTE ST 2022-6 via the server's network interfaces. ## Capabilities ### Video #### Video formats The following video formats are supported:
Resolution Frame rate Bandwidth Limitations
720 x 480i 29.97 fps 0.3 Gbps
720 x 576i 25 fps 0.3 Gbps
1280 x 720p 50/59.94 fps 1.6 Gbps
1920 x 1080i 25/29.97 fps 1.6 Gbps
1920 x 1080p 50/59.94 fps 3.2 Gbps 3G-SDI Level A only
UHD is not supported. #### Video processing The following video processing functions are available: - Video down-convertion (to 1080p, 1080i or 720p) - Dynamic range conversion, with optional user-supplied lookup table - Dynamic range signaling of transfer characteristics and colorimetry - Video failure modes ### Audio Up to eight audio components, or a total of eight stereo channels, can be added. ### Data Data is embedded into the VANC (Vertical Ancillary) lines of the SDI frame before encapsulation into SMPTE ST 2022-6. It is possible to embed more than one data type onto a single VANC line. The following data types are supported: - VITC/Time code - AFD/BAR - Closed captions - OP-47 teletext - SMPTE-2031 teletext - SCTE-104 splicing - Generic data ### Clock Reference SMPTE ST 2022-6 output is synchronized to the PCR contained in the incoming transport stream. ## Network card Any network card with sufficient network bandwidth may be used. ## Add SMPTE ST 2022-6 output 1. From the **Home** page, select the ****RECEIVER**** item from the required feed then click `Edit` icon. 2. Check that the **Configuration type** is **SD/HD.** 3. In the **Parameters** window, select the **Output** tab. 4. Click the + button, then select **SMPTE ST 2022-6** from the drop down menu. ## Configure video processing For each video processing parameter, select the required value from the drop down list.

See video descriptions for additional information.

### HDR to SDR conversion custom lookup table When the **Dynamic range conversion** option is set to **Custom HDR to BT.709 lookup table,** a custom lookup table may be specified. Please refer to the [HDR to SDR](/beam/receiver/output/hdr-sdr) section for information on uploading custom lookup tables. ## Configure audio From the **SMPTE ST 2022-6** tab, select the **Audio** tab. The output audio component list is initially populated with the decoding audio components at the time the SMPTE ST 2022-6 output was created. ### Add an audio component Select **Add component.** A new entry is added to the audio component list.

A new entry is added only when decoding audio components have been configured.

### Configure audio embedding For the row corresponding to the output audio component to be configured: 1. Select the audio decoding component from the **Component** drop down list. 2. Select the position where the audio decoding component will be embedded from the **Embedding** drop down list (select the **No embedding** option to disable embedding). 3. Set the lip-sync adjustment in the **Lip-sync adjustment** field. Lip-sync may be adjusted in the range +/- 50 milliseconds. In low delay modes negative lip-sync adjustments may not be possible.

A single embedded channel is required to output stereo audio.

### Remove an audio component Click the `Delete` icon button in the **Action** column for the row corresponding to the audio component to be removed. ### Add all audio components Select **Add all.** All the decoding audio components that are not currently included in the output audio configuration are added to the component list. Embedded channels are allocated in sequence until all available channels are filled. ### Remove all audio components Select **Remove all.** All the audio components are removed from the list of outputs. ## Configure data 1. From the **SMPTE ST 2022-6** tab, select the **Data** tab. 2. Set the line number from the drop down menu for each data type. 3. Select **OFF** from the drop-down menu for each data type that you want to disable. Once disabled, the data is no longer embedded into the output.

Generic data is automatically reinserted into the same line it came in.

### SCTE-104 splicing 1. The SCTE-104 configuration is displayed when the **SCTE 104 splicing** line is set. 2. Apply the configuration values based on the information in the [SCTE-35 to SCTE-104](/beam/receiver/output/scte35-to-scte104) section.

See SCTE 104 Splicing descriptions for additional information.

## Configure the primary stream 1. From the **SMPTE ST 2022-6** tab, select the **Primary stream** tab. 2. Set the **Destination IP address,** **Destination port** and **Network interface.** 3. Optionally, set the **Source IP address** and **Source port.** 4. Optionally, set the **TTL.**

See streams descriptions for additional information.

## Configure the secondary stream 1. Optionally, from the **SMPTE ST 2022-6** tab, click the + button next to the **Primary stream** tab. 2. Follow the same instructions as for the primary stream to configure the secondary stream. # Configure SMPTE ST 2110 output The Receiver service on MK.IO Beam can output uncompressed digital video, audio, and ancillary data over IP networks using SMPTE ST 2110. Unlike [SDI](/beam/receiver/output/sdi) and [SMPTE ST 2022‑6](/beam/receiver/output/smpte-st-2022-6), where all content is carried in a single stream, SMPTE ST 2110 transports each Media Type (i.e. video, audio, and ancillary data) as separate, independently routed **essence streams**. SMPTE ST 2110 uses the Precision Time Protocol (IEEE 1588 PTP) to ensure accurate synchronization between video, audio and data streams. In some cases, it may be necessary to update the server performance profile by selecting an alternative output profile. See [Output Profile Selection](/beam/receiver/output#output-profile-selection) for details. ## Supported Network Cards SMPTE ST 2110 output on MK.IO Beam requires supported hardware option cards. See the **[SMPTE ST 2110](/beam/reception/tech-specs#smpte-st-2110-output)** section in the technical _Reference_ documentation for a list of compatible cards. ## Rivermax License When installing the NVIDIA (Mellanox) ConnectX network adapter card into an existing MK.IO Beam system, a Rivermax license is required to enable SMPTE ST 2110 functionality. Follow the steps below to obtain and install the license. **Rivermax License Procedure** ### Install adapter card and connect to server 1. Install the adapter card into the server then power on. 2. Connect to the server over SSH as a user with `sudo` privileges. 3. Confirm that the adapter card is detected by the OS with the following command: ```shell copy lspci | grep ConnectX ``` An example of a single card installed with two ports should look like the following: ```shell 01:00.0 Ethernet controller: Mellanox Technologies MT2894 Family [ConnectX-6 Lx] 01:00.1 Ethernet controller: Mellanox Technologies MT2894 Family [ConnectX-6 Lx] 41:00.0 Ethernet controller: Mellanox Technologies MT2892 Family [ConnectX-6 Dx] 41:00.1 Ethernet controller: Mellanox Technologies MT2892 Family [ConnectX-6 Dx] ``` The above example indicates that a ConnectX-6 Lx card is present on PCI Bus/Slot `01:00` and that a ConnectX-6 Dx card is present on PCI Bus/Slot `41:00`. ### Obtain adapter card serial number Run the following command to list detected PCIe cards and extract the adapter card serial number. Use the `-s` option to specify PCI bus/slot IDs if you need to narrow down the target card for licensing. ```shell copy sudo lspci -vv -s 41:00 | grep "Serial number" ``` The serial numbers should look similar to: ```shell [SN] Serial number: MT2051X19249 [SN] Serial number: MT2051X19249 ``` ### MediaKind Supply Provide the serial number to MediaKind supply: MediaKind Supply will return a Rivermax license key file. ### Copy Rivermax license to the server If this is the first time the server has had an adapter card installed, use the following steps: 1. Rename the license file to `rivermax.lic`. 2. Copy the license file to the server (for example using SCP). 3. Connect to the server via SSH and copy the file to the Rivermax license directory: ```shell copy sudo cp rivermax.lic /opt/mellanox/rivermax/rivermax.lic ``` ### License persistence note After the first reboot, the Rivermax license file is automatically backed up so it can be preserved across [software bundle upgrades](/mkio/how-to/managing-edge-devices/update-device-software). If the new license file is intended to replace an existing Rivermax license, additional steps are required to remove the backed‑up license. In this case, contact MediaKind Customer Support for assistance. ### Restart receiver services If any receiver services configured for SMPTE ST 2110 output are currently **running**, stop and restart them to ensure the updated Rivermax license is applied. A full system reboot is not required. ## Configure SMPTE ST 2110 Output ### SMPTE ST 2110 Output Before you start, ensure at least one Receiver service is configured. 1. From the **Home** page, select the **RECEIVER** item from the required feed then click `Edit` icon. 2. Check that the **Configuration type** is **SD/HD** or **UHD** as required. 3. In the **Parameters** window, select the **Output** tab. 4. If the **SMPTE ST 2110** tab is not present under the **Output** tab: - Click the `Add` icon to bring up a prompt to add a new output - Select **SMPTE ST 2110** from the drop down menu - Click the **Add** button to complete and add the SMPTE ST 2110 output tab 5. Delete the **SDI 1** output using `Remove` icon button on the tab if not required to maintain optimal performance. 6. Configure each Media Type such as [Video](/beam/receiver/output/smpte-st-2110#video-output), [PCM Digital Audio](/beam/receiver/output/smpte-st-2110#pcm-digital-audio-output), [AES3 Audio](/beam/receiver/output/smpte-st-2110#aes3-audio-output) and [Ancillary Data](/beam/receiver/output/smpte-st-2110#data-output) to create the necessary essence streams. 7. When two or more outputs exist, they can be deleted by using the `Remove` icon button on the associated tab.

If a UHD SMPTE ST 2110 output is created, then all other outputs must be deleted as the UHD service only supports a single output.

### Video Output To configure ST 2110-20 video for [SMPTE ST 2110 Output](/beam/receiver/output/smpte-st-2110#smpte-st-2110-output), follow these steps: 1. From the **SMPTE ST 2110** tab, select the **Video** tab. 2. Select any required video options as detailed in the [SMPTE ST 2110 output parameters](/beam/receiver/parameters#smpte-st-2110-output-parameters) section 3. Check the [Essence](/beam/receiver/output/smpte-st-2110#configure-essence-output) settings. ### PCM Digital Audio Output

Audio Auto Select should be disabled when using SMPTE ST-2110 outputs, as it may result in too many or too few audio channels being carried in the ST 2110-30 essence stream.

SMPTE ST 2110-30 Conformance Level C supports 1 to 8 channels with a 1 msec packet time, or 1 to 64 channels with a 125 usec packet time. Selecting a **Packet Time** of **1 msec** ensures optimal interoperability between devices, while selecting a **Packet Time** of **125 usec** allows more channels to be carried into a single essence stream. Note that, on MK.IO Beam, the actual number of available channels will be limited by the number and configuration of the available audio decoders. For mixed-vendor environments, 1 ms packet time is recommended unless higher channel density is explicitly required. MK.IO Beam supports additional ST 2110-30 essences if more channels need to be carried. To configure ST 2110-30 PCM digital audio for [SMPTE ST 2110 Output](/beam/receiver/output/smpte-st-2110#smpte-st-2110-output), follow these steps: 1. From the **SMPTE ST 2110** tab, select the **PCM Audio** tab. 2. Use the **Add component,** **Add all** or **Remove all** buttons to set the required number of decoded audio components to the list of output components. By default, each audio component will be embedded (carried) in **Essence 1**. 3. If the number of channels exceed the current Essence settings, add more essences by selecting `Add` icon in the Essence section. For example, `Add` icon button next to the **Essence 1** tab. 4. Review the list of output audio components and assign to the desired essence stream under the **Embedding** column. For example, **Essence 1** or **Essence 2**. 5. Alternatively, change the **Packet Time** setting in Essence section to change the numbers of channels that can be carried in each essence stream. 6. Select any required PCM audio options as detailed in the [SMPTE ST 2110 output parameters](/beam/receiver/parameters#smpte-st-2110-output-parameters) section 7. Check the [Essence](/beam/receiver/output/smpte-st-2110#configure-essence-output) settings. ### AES3 Audio Output

Audio Auto Select should be disabled when using SMPTE ST-2110 outputs, as it may result in too many or too few audio channels being carried in the ST 2110-31 essence stream.

SMPTE ST 2110-31 Conformance Level C supports 1 to 6 channels with a 1 msec packet time, or 1 to 60 channels with a 125 usec packet time. Selecting a **Packet Time** of **1 msec** ensures optimal interoperability between devices, while selecting a **Packet Time** of **125 usec** allows more channels to be carried into a single essence stream. Note that, on MK.IO Beam, the actual number of available channels will be limited by the number and configuration of the available audio decoders. For mixed-vendor environments, 1 ms packet time is recommended unless higher channel density is explicitly required. MK.IO Beam supports additional ST 2110-31 essences if more channels need to be carried. To configure ST 2110-31 AES3 audio for [SMPTE ST 2110 Output](/beam/receiver/output/smpte-st-2110#smpte-st-2110-output), follow these steps: 1. From the **SMPTE ST 2110** tab, select the **AES3 Audio** tab. - If AES3 Audio tab is not shown, select the `Add` icon button next to the Media Type tabs (e.g Video, Data, etc) to add the **AES3 Audio** tab. 2. Use the **Add component,** **Add all** or **Remove all** buttons to set the required number of decoded audio components to the list of output components. By default, each audio component will be embedded (carried) in **Essence 1**. 3. If the number of channels exceed the current Essence settings, add more essences by selecting `Add` icon in the Essence section. For example, `Add` icon button next to the **Essence 1** tab. 4. Review the list of output audio components and assign to the desired essence stream under the **Embedding** column. For example, **Essence 1** or **Essence 2**. 5. Alternatively, change the **Packet Time** setting in Essence section to change the numbers of channels that can be carried in each essence stream. 6. Select any required AES3 audio options as detailed in the [SMPTE ST 2110 output parameters](/beam/receiver/parameters#smpte-st-2110-output-parameters) section 7. Check the [Essence](/beam/receiver/output/smpte-st-2110#configure-essence-output) settings. ### Data Output To configure ST 2110-40 ancillary data output, follow these steps: 1. From the **SMPTE ST 2110** tab, select the **Data** tab. 2. For each available ancillary data type, select the **line number** that the data should appear on or **OFF** to disable the data type. Details for each data type can be found in the [SMPTE ST 2110 output parameters](/beam/receiver/parameters#smpte-st-2110-output-parameters) section. 3. Check the [Essence](/beam/receiver/output/smpte-st-2110#configure-essence-output) settings. ### Configure Essence Output

An SDP file is generated for each essence regardless of whether it is enabled. However, IP streams are only created for enabled essences.

Each **Media Type** is configured as a separate **essence stream** for the SMPTE ST 2110 output. To configure the essence output, follow these steps: 1. From the **Essence 1** tab, enable the output by ticking the **Output enable** checkbox. 2. Override the default value for the **Payload type** if required. 3. Configure any extra parameter specific to the Media Type: - **PCM Audio**: The **Packet Time** determines the maximum number of channels carried in the essence. - **AES3 Audio**: The **Packet Time** determines the maximum number of channels carried in the essence. 4. Under the **Primary** tab for the current Essence: 1. Enter the **Destination IP Address** and **Destination Port** for the primary essence stream. 2. Select the **Network interface** from the options in the pull-down list. 3. Either leave the **Source port** setting on **Auto** or enter a valid value. 4. Set a value for the **TTL** parameter. 5. Repeat the above steps for each **Essence** tab introduced. 6. Click **Save and continue** to save your changes. ### SMTPE ST 2022-7 For downstream SMPTE ST 2110 receivers (e.g. monitors, encoders) that support **SMPTE ST 2022-7 Seamless Protection Switching**, two identical RTP streams are required for each essence. These streams must be carried independently over separate network paths to provide redundancy. This can be facilitated by MK.IO Beam for each _Receiver_ service outputting SMPTE ST 2110. By enabling a **Secondary** output for each essence stream, the **Primary** stream is duplicated. To configure this, follow the steps below: 1. From the **SMPTE ST 2110** tab, review each Media Type tab. For example, the **Video** tab. 2. Select the **Essence 1** tab. 3. Click `Add` icon button next to the **Primary** tab to add the **Secondary** tab. 1. Enter the **Destination IP Address** and **Destination Port** for the secondary essence stream. 2. Select the **Network interface** from the options in the pull-down list. 3. Either leave the **Source port** setting on **Auto** or enter a valid value.

The Secondary source port will use the same value for source port as the Primary setting. This is due to a driver limitation that may be resolved in future releases.

4. Set a value for the **TTL** parameter. 4. Repeat the above steps for each **Essence** tab under the selected Media Type. 5. Repeat the above steps for each Media Type tab. For example, **PCM Audio**, **AES3 Audio** and **Data** tabs. 6. Click **Save and continue** to save your changes. ## Download SDP File The SDP (Session Description Protocol) files that describe each SMPTE ST 2110 essence are generated each time the essence parameters and source input are changed. These SDP files can be used to configure the inputs of equipment that are required to receive the SMPTE ST 2110 essence streams. The SDP file for each media type can be obtained by clicking `Download` icon in the **Output status** section. This appears on the **Stats** `Chart` icon page and on the **Edit** `Edit` icon page for the Output.

The SDP files are automatically regenerated whenever a change to the input source or essence parameters are detected. The initial SDP file generation may only contain the changes related to either the input source or the essence parameters.

It is advisable to wait 30 seconds after setting up an essence and providing a source stream before downloading the SDP files to ensure the SDP file is fully updated. ## NMOS Support Once the required service has been started, SMPTE ST 2110 outputs can be discovered using products that support the NMOS IS-04 Discovery and Registration standard. In addition, active SMPTE ST 2110 outputs can be managed using products that support the NMOS IS-05 Device Connection Management standard.

If the device hostname is changed, a reboot is recommended to ensure continued NMOS operation.

### mDNS Configuration The MK.IO Beam supports the ability to use **multicast DNS (mDNS)** protocol to resolve domain names within the attached SMPTE ST 2110 network.

Do not enable this setting in unsupported networks, this may lead to memory issues.

This can be enabled from the GUI via the NMOS tab on the appliance page: 1. Select `sliders` icon **Appliance** from the left-hand side menu. 2. Click the **NMOS** tab. 3. Enable the **mDNS Eanble** checkbox as shown below: ![rx1 receiver output mds](/rx1-img/rx1_receiver_output_mds.png) 4. Set an appropriate name or description in the **Label** so that your node device can be easily identified. ### NMOS Basic Settings
Parameter Description
mDNS Eanble If enabled, use multicast DNS to automatically configure NMOS registration settings.
Label This is the label used for the device when used as an NMOS node.
### NMOS Registration Settings
Parameter Description
Registration Address Manually assign the IP address of the NMOS registration server.
Registration Version Manually assign the registry version for NMOS.
Registration Port Manually assign the port of the NMOS registration server.
### NMOS Advanced Settings
Parameter Description
mDNS multi-label domains When selected, you can enable mDNS to support domains with multiple labels. For example, en.mediakind.local, where en is subdomain of mediakind.local.
DNS priority (pri) This is used for the 'pri' TXT record when advertising the node via mDNS. Specifying 2147483647 (maximum value) disables advertisement completely.
Registration Server highest Priority This is used to specify the highest 'pri' value of discovered registration server, to avoid development and live systems colliding. Smaller numbers indicate higher priority; 0 is highest priority.
Registration Server lowest Priority This is used to specify the lowest 'pri' value of discovered registration server, to avoid development and live systems colliding. Larger numbers indicate lower priority; 2147483647 is lowest priority.
# Transport Stream Passthrough The _Receiver_ service [Configuration Type](/beam/receiver/#receiver-configuration-type) can be configured for **TS passthrough** instead of **decode**. The incoming transport stream can be received via any supported receiver input -- such as [satellite](/beam/receiver/input/#satellite-transport-stream-input), [ASI](/beam/receiver/input/#asi-transport-stream-input), or [IP](/beam/receiver/input/#ip-transport-stream-input) -- and the resulting output transport stream is transmitted only as an IP/UDP multicast. The transport stream is passed through unaltered, except when it is [decrypted](/beam/receiver/decryption/) by one of the supported Conditional Access (CA) systems. Refer to [TS Output parameters](/beam/receiver/parameters/#ts-output-parameters) for additional settings. ### Configure a receiver service TS Passthrough 1. From the `video` icon **Services** page, click **Add service** then select **Receiver**. A new window displays: ![Add Service TS Passthrough cp RX1](/rx1-img/Add_Service_TS_Passthrough_cp_RX1.png) 2. Configure the following parameters: - Enter a suitable **Name** for the service. - Select the **Type** to be **TS Passthrough**. - Select the **Server** to be Receiver to create and configure the service. 3. Click **OK** to create the service which will now appear in the services list. 4. From the `video` icon **Services** page, click the _service name_ for the newly created **TS Passthrough** service to edit the configuration. 5. Configure the input source for [satellite](/beam/receiver/input/#satellite-transport-stream-input), [ASI](/beam/receiver/input/#asi-transport-stream-input), or [IP](/beam/receiver/input/#ip-transport-stream-input). 6. Configure [decryption](/beam/receiver/decryption) settings to define how incoming services in the transport stream are decrypted. 7. Select the **Output** tab under the **Parameters** section. ![Config output TS over IP cp RX1](/rx1-img/Config_output_TS_over_IP_cp_RX1.png) 8. Configure the following parameters: - Select the **Network interface** for the outgoing transport stream. - Enter a **Stream address** (Multicast IP address) and **UDP port** number for the outgoing transport stream. - Enter the **Time to live** for the outgoing data packets. 9. Once complete, click **Save and exit**. ### Output Smoothing Enabling **Output Smoothing** for a **TS Passthrough** _Receiver_ service helps distribute UDP packets more evenly during transmission without modifying any timestamps. This can reduce packet inter-arrival time (IAT) variability and mitigate issues in downstream components that are sensitive to bursty UDP delivery. However, enabling this feature introduces a slight increase in CPU usage and end-to-end latency. Additionally, if the input stream contains packet loss or gaps, Output Smoothing may preserve or even amplify those gaps in the resulting UDP output stream, as it does not reconstruct missing data but only reshapes packet timing. To change this setting: 1. From the `video` icon **Services** page, click the _service name_ for the **TS Passthrough** service to edit the configuration. 2. In the **Parameters** window, select the **Output** tab. 3. Select or clear the **Output Smoothing** checkbox to enable or disable the feature. 4. Once complete, click **Save and exit**. # Configure UHD Video Output For a _Receiver_ service to output decoded UHD video in the same format, the [Configuration Type](/beam/receiver/#receiver-configuration-type) must be set to **UHD**. This _Configuration Type_ enables decoding of SD, HD, and UHD video and exposes additional settings for UHD output. ## UHD Output Over SDI UHD video is output over SDI using the following SDI output standards, referred to as **Link Mode**: - Quadrant (Quad‑Link 3G‑SDI, ST 425‑5 Annex B — Square Division) - Interleaved (Quad‑Link 3G‑SDI, ST 425-5 Two Sample Interleave) - 12G-SDI (Single‑link UHD)

The Link Mode options available will depend on the SDI output option card installed in the MK.IO Beam server.

### Configuring Link Mode To configure the Link Mode for UHD output for a specific _Receiver_ service, follow these steps: 1. Set the _Configuration Type_ is set to **UHD**: - See [Change the Configuration Type](/beam/receiver/#change-the-configuration-type) 2. Set the SDI output option card so that it is configured for UHD output: - See [Set up SDI/ASI cards](/beam/system-admin/maintenance/setup-sdi-asi-card) 3. On the **Home** page, select the **RECEIVER** item from the required feed, then click `Edit` icon to edit. 4. In the **Parameters** window, select the **Output** tab. 5. Select the tab for the SDI output type, for example **SDI 1**. ![view edit service decode output cp](/rx1-img/view_edit_service_decode_output_cp.png) 6. Select the [**Link Mode**](/beam/receiver/parameters#sdi-output-parameters-and-status) format required for the video output. 7. Select the [**SDI port**](/beam/receiver/output/sdi/) required from the drop-down menu that supports UHD output. 8. Click **Save and Continue** to apply change. ## UHD Output Over SMPTE ST 2022-6 Currently, UHD output is not supported using SMTPE ST 2022-6. ## UHD Output Over SMPTE ST 2110 To output UHD video using SMPTE ST 2110, ensure the following settings are configured: 1. Set the _Output Profile_ to **SMPTE ST 2110 UHD Output**: - See [Configure the Output Profile](/beam/receiver/output/#configure-the-output-profile) 2. Set the _Configuration Type_ is set to **UHD**: - See [Change the Configuration Type](/beam/receiver/#change-the-configuration-type) # Parameter descriptions ## Service parameters
Parameter Description
Configuration name The name of the Receiver Configuration
Configuration type Determines the behaviour of the Receiver service, such as TS passthrough output or decoded video output. See Receiver Configuration Type for details.
## Input parameters and status Input parameters vary depending on the **Current input** type. ### Redundancy Mode
Parameter Description
Redundancy mode Select an input redundancy mode to enable switching between a Primary and Secondary (backup) input. See the Receiver Input Redundancy section for configuration details.
Input loss timeout Set the delay (in milliseconds) between detecting an input error and switching to the alternate input.
Max skew Specifies the maximum allowed skew (receiver buffer depth), in milliseconds, between the two data paths. If the measured skew exceeds this value, packets may be lost during seamless protection switching. Available only when SMPTE ST 2022-7 is selected.
Note: The Max skew setting increases the receiver buffer delay and therefore contributes to overall system latency. This may impact Delay Modes such as Super Low Delay.
### IP
Parameter Description
Current input Select an input type: IP, ASI, Satellite
Unicast Set input stream to be unicast
Note: In Unicast mode, the control is read only.
Stream address Input stream unicast or multicast IPv4 address
IGMPv3 source filtering IGMP source IPv4 address. List of addresses using a comma to separate, or leave empty to disable source-specific multicast
UDP Port Port used to capture the input stream
Network interface Name of the network interface used to capture the input stream
Input Status Description
Input type Indicates IP is selected as the source
Source status Indicates whether a valid transport stream is present on the input and reports the number of services carried. For example, "Receiving (2 services)" or "Not receiving".
CC errors Indicates the number of transport stream packets that experienced Continuity Counter (CC) errors. Each CC error indicates that one or more transport stream packets were lost or duplicated for a particular PID.
Bit rate Total bit rate of the incoming transport stream
### ASI
Parameter Description
Current input Select an input type: IP, ASI, Satellite
Port Port used to capture the input stream
Input Status Description
Input type Indicates ASI is selected as the source
Source status Indicates whether a valid transport stream is present on the input and reports the number of services carried. For example, "Receiving (2 services)" or "Not receiving".
CC errors Indicates the number of transport stream packets that experienced Continuity Counter (CC) errors. Each CC error indicates that one or more transport stream packets were lost or duplicated for a particular PID.
Bit rate Total bit rate of the incoming transport stream
### Satellite
Input Parameter Description
Current input Select an input type: IP, ASI, Satellite
Status Status indicating if the source input is shared with other services
Source Select the RF input port number from the available detected card slots
LNB Control Parameter Description
LNB frequency The LNB frequency (low noise block down-converter) in MHz input up to 3 decimal places used with the satellite dish. Typically a value of 9750 MHz or 10600 MHz would be used to cover the satellite KU band frequency range 11.70 GHz-12.75 GHz. With this value correctly entered and with the satellite frequency entered the IRD can calculate the frequency of the wanted signal at L-band present on the input connector.
LNB voltage Voltage supplied to LNB. Allows the user to turn the voltage off or to set the LNB to the following different LNB voltages:
- 13v (Vertical polarization)
- 18v (Horizontal polarization)
22kHz LNB band select. Check to select LNB high band. Clear the check box to select LNB low band. This check box enables the LNB 22 kHz signal to be activated. Enabling the 22 kHz tone will command the LNB to switch to its high band local oscillator frequency.
Tuning Parameter Description
Tuner Where applicable, some satellite demodulator cards provide more than one independent tuner/demodulator pair per physical RF port. These tuners are referenced alphabetically (for example, Tuner A and Tuner B). If a satellite demodulator card supports only a single tuner/demodulator per RF port, Tuner A is assigned by default. In all cases, LNB control is associated with the RF port and is therefore shared across all tuners associated with that RF port.
Frequency The satellite input downlink frequency. This will normally be within the C-band or KU band frequency range. Alternatively, if the LNB LO Frequency was entered as 0 MHz the user can manually calculate and directly enter the wanted L-band frequency.
Symbol rate The symbol rate in MSymbols/sec. This field should be entered with the symbol rate of the wanted signal.
Search range The search range in KHz. Owing to frequency inaccuracies of the transmission system (mostly LNB inaccuracies) the wanted carrier may not be exactly on frequency. This option provides the satellite input with the maximum frequency search limits within which to attempt to acquire the wanted signal. A typical search range is 5000 kHz.
C/N Margin Alarm Carrier-to-Noise margin alarm threshold in dB.
MIS Enable Enable Multiple Input Stream (MIS) filtering of a single stream identified by the Input Stream ID (ISI). MIS is a DVB-S2 / DVB-S2X feature that allows multiple independent transport streams to be carried simultaneously on a single satellite carrier (one RF frequency).
Disable this for single stream carriers.
MIS Stream ID This parameter sets the Input Stream ID (ISI) used to filter and select a single input stream when MIS is enabled. If the configured ISI does not match any transmitted stream, the device will report a zero transport stream bit rate and raise a satellite input signal loss alarm.
Gold Code The Gold code sequence seed defines the initialization value for the physical‑layer scrambling (Gold) sequence. This sequence can be used to uniquely identify a transmission. The satellite input will lock to the incoming signal only when the Gold code configured matches the code set on the uplink modulator. For this reason, the Gold sequence is often used as a form of fixed‑key signal identification, although it does not provide true conditional‑access security.
Input Status Description
Input type Indicates Satellite is selected as the source
Source status Indicates whether a valid transport stream is present on the input and reports the number of services carried. For example, "Receiving (2 services)" or "Not receiving".
CC errors Indicates the number of transport stream packets that experienced Continuity Counter (CC) errors. Each CC error indicates that one or more transport stream packets were lost or duplicated for a particular PID.
Bit rate Total bit rate of the incoming transport stream
Signal strength Input signal strength measured in dBm
Bit error ratio The Bit Error Ratio reported by the satellite demodulator. This is reported as a ratio of number of bit errors divided by total number of bits.
FEC errors The number of FEC errors reported by the satellite demodulator.
FEC rate The FEC rate detected for the locked incoming signal e.g. 3/4, 8/9, etc.
Delivery system Displays the satellite delivery system detected for the locked incoming signal e.g. DVB-S, DVB-S2 or DVB-S2X.
Roll off The roll-off factor detected for the locked incoming signal e.g. 35%, 25%, etc.
Pilot Indicates if pilot symbols are present.
Inversion Indicates the spectrum inversion detected by the demodulator.
Modulation The modulation scheme detected for the locked incoming signal e.g. QPSK, 8PSK, etc.
C/N Margin The Carrier-to-Noise margin for the locked incoming signal reported in dB.
## Decoding parameters and statuses ### Decoding
Parameter Description
Service Select the service to decode
Delay mode Controls buffer levels and timing, which affects latency across the Receiver service. For more information, Delay modes.
### Video
Parameter Description
Input Select a PID to decode from the incoming stream or manually enter a PID value to decode
### Audio
Parameter Description
Auto Select Enables automatic selection of audio streams, disabling manual selection. See Auto Select for more information.
Input Select a PID to decode from the incoming stream or manually enter a PID value to decode
Decode channel configuration Configure the number of output channels for each decoded audio stream. For details, refer to Decode Channel Configuration
### Data
Parameter Description
Input Select a PID to decode from the incoming stream or manually enter a PID value to decode
Data Type configuration Configure the data format for each decoded data stream. For details, refer to Data Type Configuration
### Service status
Parameter Description
Selected service Program number (and service name if present)
PCR PID Numeric value PCR PID being used for the reference clock to decode the selected service
### Video status
Parameter Description
PID Numeric value of the PID being used to decode the video from the incoming transport stream
Rate Elementary stream rate of the video being decoded
Codec Video codec being used to decode the video
Chroma Format of chrominance samples
Example: 4:2:2 or 4:2:0
Bit depth Number of bits precision in each luminance/chrominance sample
Resolution Video resolution being decoded
Aspect ratio Signalled aspect ratio of the video being decoded
Example: 4:3 or 16:9
Frame rate Frame rate of the video being decoded*
Example: 25Hz / 29.97Hz / 50Hz / 59.94Hz
### Audio Status
Parameter Description
Audio X Displays status as OK or Error the audio PID being decoded, the audio codec being used, the channel mode and the bitrate
## Decrypt parameters ### BISS
Parameter Description
BISS Mode The BISS decryption mode supported by both BISS1 and BISS2. Beam will automatically switch between the BISS1 or BISS2 version based on the length of the BISS Key entered. For example,
- Mode 1 for BISS1-1 and BISS2-1
- Mode E for BISS1-E or BISS2-E
- None to disable BISS decryption
BISS Key The BISS key (hexadecimal characters only) for decrypting the service according to the BISS Mode selection:
- Mode 1 requires 12 characters for BISS1, or 32 characters for BISS2
- Mode E requires 16 characters for BISS1, or 32 characters for BISS2
Injected ID Select the appropriate BISS injected ID stored on the device required for BISS Mode E decryption.
**Related information** - [Set BISS to mode 1](/beam/receiver/decryption/biss-decryption-modes#set-biss-to-mode-1) - [Set BISS to mode E](/beam/receiver/decryption/biss-decryption-modes#set-biss-to-mode-e) - [Set BISS Injected ID](/beam/receiver/decryption/biss-decryption-modes#set-biss-injected-id) ### BISS-CA
Parameter Description
BISS-CA Enable or disable BISS-CA decryption.
**Related information** - [Managing BISS-CA entitlements](/beam/receiver/decryption/biss-ca-entitlements) ### Director 6
Parameter Description
Descrambling Enable Enable or disable Director 6 decryption.
Director 6 Hardware ID A unique identifier used by the Director headend to address the receiving device for over air commands and other Director functionality.
Note: Setting the Director Hardware ID to None disables Director functionality for that service.
Over air control enable Allow or ignore Director over air commands sent by the Director headend to remotely control the receiving device.
Note: This state can be overridden by the Director headend.
Export Keyfile Click this button to download the Director Export Keyfile associated with the currently selected Director 6 Hardware ID. This keyfile must be registered with the Director headend in order to receive entitlements for successful service decryption.
Status Description
Hardware ID The unique Director Hardware ID (HWID) currently assigned to the running service configuration.
Over air message Displays messages received over air (transport stream) from the Director headend.
Emergency home carrier Indicates if the Emergency Home Carrier (EHC) associated with the current HWID has been set.
Power up carrier Indicates if the Power Up Carrier (PUC) associated with the current HWID has been set.
Download status Shows progress of any over air download images present in the transport stream triggered by the Director headend. For example, bundle upgrades or new configuration updates.
**Related information** - [Supplying Information to the Director Headend](/beam/receiver/decryption/director#supplying-information-to-the-director-headend) ### DVB-CI
Parameter Description
CAM slot Selects the CAM to be used for decrypting the incoming service.
Auto recover CAM When enabled, the device monitors the CAM status and automatically resets the CAM if a decryption failure is detected. This feature is activated by selecting a timeout threshold. If the decryption failure persists beyond the configured timeout, the CAM is reset. This process repeats until the decryption failure is resolved. Resetting the CAM will temporarily disrupt the decrypted service.
Explore CAM Extracts the status information and allows setting CAM manufacturer parameters.
Reset CAM Resets the CAM in the selected slot. Resetting the CAM will disrupt the service being decrypted.
## SDI output parameters and status ### Video
Parameter Description
Link mode Select the SDI format for carrying UHD video:
- Quadrant (Quad‑Link 3G‑SDI, ST 425‑5 Annex B — Square Division)
- Interleaved (Quad‑Link 3G‑SDI, ST 425-5 Two Sample Interleave)
- 12G SDI (Single‑link UHD)
SDI port Selects the SDI output port on which the video is output.
Video Scaling Configure up-conversion / down‑conversion for the output video. For details, see the Video Conversion page.
Dynamic Range Conversion Configure the Dynamic Range Conversion for the output video. For details, see the HDR to SDR page.
Dynamic range signalling Configure the transfer characteristics and colorimetry signalled on the output video. For details, see the SDR/HDR signalling page.
Clock reference Clock reference of the SDI output.
- Free running uses an internally generated reference clock.
- External sync synchronizes to externally provided framesync pulses.
3G-SDI level Select SMPTE mapping scheme for 3G-SDI.
Video failure mode Defines the behavior of the SDI output when the video decode fails.
### Audio
Parameter Description
Component Select which decoded audio to embed in the SDI output.
Embedding Select the position where the audio component will be embedded in the SDI output.
Add component Add a single entry to the list of audio components.
Add all Add all decoded audio components to the list of embedded audio components.
Remove all Remove all entries from the list of embedded audio components.
### Data
Parameter Description
VITC/Time code If present at the input, VITC/time code information will be inserted in the output SDI at the selected line number.
AFD/BAR If present at the input, AFD (Active Format Description) information will be inserted in the output SDI at the selected line number.
Closed captioning If present at the input, closed captions information will be inserted in the output SDI at the selected line number.
OP-47 teletext If present at the input, OP-47 teletext information will be inserted in the output SDI at the selected line number.
SMPTE 2031 teletext If present at the input, SMPTE 2031 teletext information will be inserted in the output SDI at the selected line number.
SCTE 104 splicing If SCTE 35 splice_null, splice_insert or time_signal messages are present at the input, they will be converted to SCTE 104 packets and these will be inserted in the output VANC data at the selected line number.
See SCTE 104 Splicing for additional settings.
### Status
Parameter Description
SDI Outputs Displays the available SDI output ports and the SDI standard supported by each port (for example, 3G or 12G). If a running service has been assigned to an SDI port, the service name and its port assignment are displayed here.
## SMPTE ST 2022-6 output parameters ### Video
Parameter Description
Video Scaling Configure up-conversion / down‑conversion for the output video. For details, see the Video Conversion page.
Dynamic Range Conversion Configure the Dynamic Range Conversion for the output video. For details, see the HDR to SDR page.
Dynamic range signalling Configure the transfer characteristics and colorimetry signalled on the output video. For details, see the SDR/HDR signalling page.
Video failure mode Defines the behavior of the output when the video decode fails
Possible values: Freeze frame, Black
### Audio
Parameter Description
Component Select which decoded audio to embed in the output
Embedding Select the position where the audio component will be embedded in the output
Add component Add a single entry to the list of audio components
Add all Add all decoded audio components to the list of embedded audio components
Remove all Remove all entries from the list of embedded audio components
### Data
Parameter Description
VITC/Time code If present at the input, VITC/time code information will be inserted in the output at the selected line number
AFD/BAR If present at the input, AFD (Active Format Description) information will be inserted in the output at the selected line number
Closed captioning If present at the input, closed captions information will be inserted in the output at the selected line number
OP-47 teletext If present at the input, OP-47 teletext information will be inserted in the output at the selected line number
SMPTE 2031 teletext If present at the input, SMPTE 2031 teletext information will be inserted in the output at the selected line number
SCTE 104 splicing If SCTE 35 splice_null, splice_insert or time_signal messages are present at the input, they will be converted to SCTE 104 packets and these will be inserted in the output VANC data at the selected line number.
See SCTE 104 Splicing for additional settings.
### Primary and Secondary Streams
Parameter Description
Output enable Enable the output
Destination IP address Output multicast IPv4 address
Destination port Output UDP port
Possible values: from 1024 to 65535
Network interface Name of the network interface used for the output stream
Source IP address Source IPv4 address
Note: Set to Auto to automatically use the network interface address
Source port Source UDP port
Possible values: from 1024 to 65535
Note: Set to Auto to automatically allocate a value
TTL TTL (time to live) on each RTP output packet
Possible values: from 0 to 255
### Status
Parameter Description
Bitrate The output bitrate
## SMPTE ST 2110 output parameters ### Video
Parameter Description
Video Scaling Configure up-conversion / down‑conversion for the output video. For details, see the Video Conversion page.
Dynamic Range Conversion Configure the Dynamic Range Conversion for the output video. For details, see the HDR to SDR page.
Dynamic range signalling Configure the transfer characteristics and colorimetry signalled on the output video. For details, see the SDR/HDR signalling page.
Video failure mode Defines the behavior of the SMPTE ST 2110 output when video decode fails
Possible values: Freeze frame or Black
### PCM Audio
Parameter Description
Component Select which decoded audio to carry in the ST 2110-30 output.
Embedding Select the essence stream where the audio component will be carried in the ST 2110-30 output.
Lip-sync adjustment Advance or delay audio output timing with respect to the video.
### AES3 Audio
Parameter Description
Component Select which decoded audio to carry in the ST 2110-31 output.
Embedding Select the essence stream where the audio component will be carried in the ST 2110-31 output.
Lip-sync adjustment Advance or delay audio output timing with respect to the video.
### Data
Parameter Description
VITC/Time code If present at the input, VITC/time code information will be carried in the ST 2110-40 essence stream for the specifed line number.
AFD/BAR If present at the input, AFD (Active Format Description) information will be carried in the ST 2110-40 essence stream for the specifed line number.
Closed captioning If present at the input, closed captions information will be carried in the ST 2110-40 essence stream for the specifed line number.
OP-47 teletext If present at the input, OP-47 teletext information will be carried in the ST 2110-40 essence stream for the specifed line number.
SMPTE 2031 teletext If present at the input, SMPTE 2031 teletext information will be carried in the ST 2110-40 essence stream for the specifed line number.
SCTE 104 splicing If SCTE 35 splice_null, splice_insert or time_signal messages are present at the input, they will be converted to SCTE 104 packets and these will be inserted in the output VANC data at the selected line number.
See SCTE 104 Splicing for additional settings.
### Essence
Parameter Description
Output enable Enable the output.
Payload type RTP payload typePossible values: from 0 to 255
Packet Time Determines the maximum number of channels that can be carried in the essence stream.
Applicable to PCM Audio and AES3 Audio only.
### Primary / Secondary
Parameter Description
Destination IP address Output multicast IPv4 address
Destination port Output UDP port Possible values: from 1024 to 65535
Network interface Name of the network interface used for the output streams
Source port Source IPv4 port.
Note: Set to Auto to automatically allocate a value.
TTL TTL (time to live) on each RTP output packet Possible values: from 0 to 255
## SCTE 104 Splicing
Parameter Description
Time signal Convert SCTE 35 time_signal messages and output as SCTE 104 time_signal_request_data messages
Clamp pre-roll Clamp minimum pre-roll in SCTE 104 messages to 4 seconds
Event ID Filter Enable filtering on the value of the splice_event_id field of SCTE 35 splice_insert messages. When enabled, for each bit set in Event ID mask, the corresponding bit in Event ID value must match the corresponding bit in splice_event_id to allow the splice_insert message to be processed and a SCTE 104 message inserted in the output
Event ID mask Bit mask for filtering on splice_event_id of SCTE 35 splice_insert messages. Bits which are set must match the Event ID value with the splice_event_id field to be inserted as SCTE 104 VANC data
Event ID value Bit value for filtering on splice_event_id of SCTE 35 splice_insert messages. Only bits with the corresponding bit set in Event ID mask are considered
## TS output parameters
Parameter Description
Network interface Name of the network interface used for the output streams
Stream address Output multicast IPv4 address
Destination port Output UDP port Possible values: from 1024 to 65535
TTL TTL (time to live) on each RTP output packet Possible values: from 0 to 255
Output Smoothing Enables UDP output smoothing. See Output Smoothing for more details.
## Backup parameters
Parameter Description
Host Remote server Hostname or IP address.
Possible values: 32 characters max
Port IP Port for the secure FTP or FTPS connection.
Possible values: 1 to 65535
Recommended value: 21
Path Backup file storage directory on the remote server. This path is a relative path, and must exist on the remote server.
Possible values: 128 characters max
Username For the secure FTP connection. Must be a valid secure FTP or FTPS server user.
Possible values: 16 characters max
Password Allows the configured username to connect to the secure FTP server.
Possible values: 16 characters max
**Related information**\ [Backup and restore configurations](/beam/system-admin/maintenance/backup-restore) ## Failover parameters
Parameter Description
Group name Enter a unique failover group name for your selected primary and backup servers.
Group processing type Select the processing type to display compatible servers.
Group mode In Automatic mode, the system triggers a server failover when a critical alarm occurs (manual triggers are still possible).
**Related information**\ [Create a failover group](/beam/system-admin/servers/failover#create-a-failover-group) # Reception
Check which interface you are using

The guides linked from this page configure MK.IO Beam through the Advanced interface, where a workflow is a feed made up of individual services. If your device runs the Essentials interface, build the workflow as a channel instead: see Create a channel. Both interfaces control the same settings underneath, so these pages stay useful as reference for the detail behind a channel.

**MK.IO Beam for reception** is engineered to meet the evolving demands of processing at the edge of your network, delivering high-quality video and audio decode with maximum efficiency. Its flexible architecture allows for seamless integration into existing workflows, providing a future-proof solution for content turnaround and distribution. ## Common Workflows: ### Receive & Decrypt Configure the input interfaces and handle decryption. [Satellite/ASI Input](/beam/receiver/input) Setup tuners, LNB frequencies, and ASI ports. [Reliable Transport Input](/beam/reliable-transport/service-management) Ingest SRT, Zixi, or RIST streams. [BISS-CA Decryption](/beam/receiver/decryption/biss-ca-decryption) Configure BISS-CA entitlements and keys. [Common Interface (DVB-CI)](/beam/receiver/decryption/common-interface-module) Manage physical Conditional Access Modules (CAM) for decryption ### Decoding & Process Convert the transport stream into baseband video and audio. [Video Decoding](/beam/receiver/decoding) Manage codecs and resolutions. [Delay Modes](/beam/reception/delay-modes) Adjust buffer settings for Standard, Low or Super Low latency. [HDR to SDR](/beam/receiver/output/hdr-sdr) Down-convert HDR signals for standard displays. ### Output Route the decoded signal to local infrastructure. [SDI Output](/beam/receiver/output/sdi) Map services to physical SDI ports. [SMPTE ST 2022-6 Output](/beam/receiver/output/smpte-st-2022-6) Output SDI over IP. [SMPTE ST 2110 Output](/beam/receiver/output/smpte-st-2110) Output uncompressed IP video. # Configure the feed components After a feed has been created, each service within the feed must be individually configured to create the entire MK.IO Beam configuration. Thus, you will configure: - [the Receiver service](/beam/receiver) - optionally [the Multiplexer service](/beam/multiplexer) - optionally [the Live Encoder service](/beam/live-encoder/configure) The Reliable Transport service is not included in all of the MK.IO Beam feed templates. It can be added separately via the **Services** page. See [Reliable Transport Configuration](/beam/reception/configure-feed-components/reliable-transport) When editing service parameters, do not modify any interfaces which have been configured to use the “tap0” or “lo” interfaces as those are used internally to pass data between the services. # Configure the Live Encoder service For detailed information on the Live Encoder service, refer to the [Live Encoder documentation](/beam/live-encoder/configure). # Configure the Multiplexer service For detailed information on the Multiplexer service, refer to the [Multiplexer documentation](/beam/multiplexer). # Configure the Receiver service For detailed information on the Receiver service, refer to the [Receiver documentation](/beam/receiver). # Configure a Reliable Transport service

Although the Reliable Transport service is not included in any of the MK.IO Beam feed templates, a Reliable Transport service can be added separately and connected to the input or output of a feed. For example, a Reliable Transport service can be added to the input of a Receiver + Multiplexer feed to ingest Reliable Transport input to the MK.IO Beam device.

To create a Reliable Transport service, see [how to create a new Reliable Transport service](/beam/reliable-transport/service-management#create-a-new-reliable-transport-service). If configuring a Reliable Transport service to ingest a Reliable Transport input and provide a TS output to other services running on the MK.IO Beam device, ensure that the upstream service is configured with the **Network Interface**, **Stream Address** and **Port** from the output of the Reliable Transport service. # Delay modes ## Contribution decoding delay modes (latency) The modes described here are used to configure decoding delay, or latency of the Contribution decoder. The delay modes affect the delay between the PCR/PTS relationship and delaying picture display (when compared to the system clock reference). **Delay modes:** - **Standard:** This is the default value. Standard mode allows using all encoders, in all modes. - **Low:** This is the **recommended setting for most contribution link use cases.** You can also use this mode in any context where a low delay is required. - **Super Low:** This is the **recommended setting for simple contribution links when using TS input with SDI output** where the lowest delay is required. **Low** delay and **Super Low** delay modes have been designed and tested with MK.IO Beam encoders to ensure an optimized error-free minimum end-to-end delay. Post-processing operations in the receiver such as video scaling or HDR/SDR conversion will add to the overall processing time and may not be compatible with these delay modes. If a problem occurs trying to decode a valid input transport stream, please try the **Standard** delay mode before raising a support request.

Additional input processing, such as descrambling or SMPTE ST 2022-7 input, increases overall latency across all delay modes in the Receiver service.

### Setting delay mode 1. From the **Home** page, select the RECEIVER item from the required feed then click `Edit` icon. 2. Open the **Decoding** tab in the **Parameters** window. 3. Select a **Delay mode.** ![view Delay mode setting](/rx1-img/view_delay_mode_cp.png) 4. Click **Save and Continue** to apply change. ### Considerations when using Super Low delay mode - **Super Low** delay mode is only guaranteed to work with the MK.IO Beam encoder. The encoder configuration needs to be optimized for use with **Super Low** delay mode. - 1080i25/29.97 inputs are not supported with **Super Low** delay mode. - Dolby Digital decode requires approximately 15ms of additional processing time which will extend the delay when **Super Low** delay mode is selected. Dolby Digital passthrough is not affected. ## Compressed Input ### IP input - **Type:** IP (IGMPv3-based redundancy and dual multicast redundancy) - **Protocols:** MPEG Transport Stream (SPTS, MPTS), RTP / UDP, RTMP, SMPTE ST 2022-7 - **Bitrate:** Constant Bitrate (CBR) - **Error Correction:** ProMPEG FEC ### Reliable transport - **Input:** IP based - **Protocols:** SRT, RIST and Zixi **SRT and RIST input** - Carriage of UDP or RTP streams over the SRT protocol - SRT listener or caller mode - RIST sender mode - RIST listener mode **Zixi input** - Zixi sender - Zixi feeder or Zixi Receiver mode ### Satellite input - **Standards:** DVB-S, DVB-S2, DVB-S2X - **Hardware requirements:** Requires one or more of the following cards **2-port satellite demodulator option card with 3G-SDI/ASI output (Dektec DTA-2127)** MediaKind marketing code: - **MKP/HWO/DEMODSDI** (Dektec DTA-2127 DVB-S2X Quad Receiver with 3G-SDI/ASI Output)

The Dektec DTA-2127 option card has 2 x RF input ports. Currently MK.IO Beam only supports configuring one tuner/demodulator per RF input.

Features: - **Frequency range:** L-band (950 – 2150 MHz) - **Standards:** DVB-S, DVB-S2, DVB-S2X - **Modulation schemes:** QPSK, 8PSK, 16APSK and 32APSK - **Connector:** 2 x F-type 75 ohm - Each connector allows 1x independent tuner/demodulator powered by a single LNB control - Long FEC Frame only **4-port satellite demodulator option card (Digital Devices SX8)** MediaKind marketing code: - **MKP/HWO/PCI/SAT/DEMOD** (Digital Devices SX8 Satellite Demod)

The Digital Devices SX8 is only available as a full-height PCIe card and is therefore limited to servers such as the C-series.

Features: - **Frequency range:** L-band (950 – 2150 MHz) - **Standards:** DVB-S, DVB-S2, DVB-S2X - **Modulation schemes:** QPSK, 8PSK, 16APSK, 32APSK and 64APSK - **Connector:** 4 x F-type 75 ohm - Each connector allows 2x independent tuners/demodulators that share a single LNB control

Mixing both types of satellite demodulator cards within the same server is not supported.

### ASI input - **Standards:** DVB-ASI - **Hardware requirements:** Requires one or more of the following cards **4-port ASI/SDI option card (Dektec DTA-2174B)** MediaKind marketing code: - **MKP/HWO/PCI/SDI/DTA** (Dektec 2174B SDI/ASI) Features: - **Port configurations:** 4x ASI input/output - **Connector:** micro BNC 75 ohms **8-port ASI/SDI option card (Dektec DTA-2178)** MediaKind marketing code: - **MKP/HWO/PCI/SDI/8** (Dektec 2178 SDI/ASI) Features: - **Port configurations:** 8x ASI input/output - **Connector:** micro BNC 75 ohms ### Input redundancy - **Dual source redundancy:** Active Passive (one-hit); Active Active (one-hit); Active Active (switch on failure) - Supported across input types e.g. Primary satellite input, Secondary (Backup) IP input - **IP redundancy protocols:** SMPTE ST 2022-7 Seamless protection switching ## Video decoding - **Video codecs:** MPEG-2, H.264, HEVC, JPEG-XS - **Supported resolutions:** 480i, 576i, 720p, 1080i, 1080p, 2160p - **Chroma:** 4:2:0 and 4:2:2 - **Bit depth:** 8-bit and 10-bit (codec-dependent) **Video formats and decoding standards**
Resolution Frame Rate Chroma MPEG-2 H.264 HEVC JPEG-XS (4:2:2 only)
2160p 23.98, 24,
25, 29.97,
50, 59.94 fps
4:20 / 4:2:2 ✔ ✔
1080p 50, 59.94 fps 4:20 / 4:2:2 ✔ ✔ ✔ ✔
1080i 25, 29.97 fps 4:20 / 4:2:2 ✔ ✔ ✔ ✔
720p 50, 59.94 fps 4:20 / 4:2:2 ✔ ✔ ✔ ✔
576i 25 fps 4:20 / 4:2:2 ✔ ✔ ✔
480i 29.97 fps 4:20 / 4:2:2 ✔ ✔ ✔
**Full video width scaling** Horizontally subsampled video is automatically rescaled to full frame width, as detailed below. Supported for all video codecs listed above.
Input resolution Output resolution Expected sample aspect ratio
1440 x 1080 1920 x 1080 4:3
1280 x 1080 1920 x 1080 3:2
960 x 1080 1920 x 1080 2:1
960 x 720 1280 x 720 4:3
640 x 720 1280 x 720 2:1
**Video down-conversions** Supported down-conversions: - 2160p > 1080p, 1080i, 720p - 1080p > 1080i, 720p - 1080i > 720p **Video up-conversions** Supported up-conversions: - 1080i > 1080p - 720p > 1080i **HDR to SDR conversions** - **Supported HDR inputs:** PQ10 (HDR10), HLG10 - **Output:** SDR BT.709 with tone mapping ## Audio decoding - **Audio codecs:** MP1L2, AAC, AAC 5.1, HE-AAC v1 & v2, HE-AAC 5.1, Dolby Digital (AC-3), 2.0 & 5.1, Dolby Digital Plus (E-AC-3) 2.0 & 5.1, MPEG-H - **Passthrough:** Linear PCM, Dolby E, Dolby ED2, Dolby Digital (AC-3), Dolby Digital Plus (E-AC-3) - **Audio sampling rate:** 48 kHz - **Audio Channels:** Up to 8 stereo pairs per service - **Phase Aligned Audio (PAA):** Supported ## Ancillary Data - **Closed captions:** CEA-608, CEA-708 - **Timecode:** VITC - **Teletext:** SMPTE 2031, OP-47 - **Metadata:** AFD/BAR, VANC - **Signalling:** SCTE-35 conversion to SCTE-104 ## Video transcoding ### Video encoding - **Codecs:** MPEG-2, MPEG-4 AVC (H.264), HEVC (H.265) - **Chroma:** 4:2:0 - **Conversions:** - HD to HD or SD - SD to SD ### Audio encoding - **Audio codecs:** MPEG-1 Layer-II, AAC, HE-AAC, HE-AAC v2 1. Dolby Digital® 2.0 / 5.1, Dolby Digital Plus® 2.0, 5.1, Dolby AC-3 - **Audio channels:** Up to 8 stereo pairs per service. - **Passthrough:** Dolby E®, Dolby Digital®, Dolby Digital Plus®, Linear PCM (as SMPTE 302) - **Data rate:** From 4.75 kbps to 320 kbps (from 64 to 1024 kbps for DD+). ## Compressed output - **Transport Stream Passthrough:** IP, ASI (requires multiplexer service), unmodified or decrypted - **Protocols:** IP, UDP, RTP, RTMP/RTMPS, ASI **SRT and RIST output** - Carriage of UDP or RTP streams over the SRT protocol - SRT listener or caller mode - RIST sender mode - RIST listener mode **Zixi output** - Zixi sender - Zixi feeder or Zixi Receiver mode ## Uncompressed output - **Output formats:** SDI, SMPTE ST 2022-6, SMPTE ST 2110 ### SDI output - **Standards:** SDI, HD-SDI, 3G-SDI, 12G-SDI, Quad‑Link 3G‑SDI - **Video formats:** 480i, 576i, 720p, 1080i, 1080p, 2160p - **Hardware requirements:** Requires one or more of the following cards **4-port ASI/SDI option card (Dektec DTA-2174B)** MediaKind marketing code: - **MKP/HWO/PCI/SDI/DTA** (Dektec 2174B SDI/ASI) Features: - **Output configurations:** - 4x independent 3G-SDI/ASI input/output - 12G-SDI (Single‑link UHD) or Quadrant (Quad‑Link 3G‑SDI, ST 425‑5 Annex B — Square Division) or Interleaved (Quad‑Link 3G‑SDI, ST 425-5 Two Sample Interleave) - 12G-SDI with 3G-SDI/ASI side channel - **Connector:** micro BNC 75 ohms **8-port ASI/SDI option card (Dektec DTA-2178)** MediaKind marketing code: - **MKP/HWO/PCI/SDI/8** (Dektec 2178 SDI/ASI) Features: - **Output configurations:** - 8x independent 3G-SDI/ASI input/output - 2x 12G-SDI (Single‑link UHD) or Quadrant (Quad‑Link 3G‑SDI, ST 425‑5 Annex B — Square Division) or Interleaved (Quad‑Link 3G‑SDI, ST 425-5 Two Sample Interleave) - 2x 12G-SDI with 2x 3G-SDI/ASI side channels - **Connector:** micro BNC 75 ohms **2-port satellite demodulator option card with 3G-SDI/ASI output (Dektec DTA-2127)** MediaKind marketing code: - **MKP/HWO/DEMODSDI** (Dektec DTA-2127 DVB-S2X Quad Receiver with 3G-SDI/ASI Output) Features: - **SDI output:** 1x SDI output supporting SD/HD/3G-SDI - **Connector:** BNC 75 ohms ### SDI over IP (SMPTE ST 2022-6) output - **Standards:** SMPTE ST 2022-6 - **Video formats:** 480i, 576i, 720p, 1080i, 1080p (2160p not supported) - **Hardware requirements:** Any network card with sufficient network bandwidth may be used ### SMPTE ST 2110 output - **Standards:** SMPTE ST 2110 - ST 2110-20: Uncompressed video for 480i, 576i, 720p, 1080i, 1080p, 2160p - ST 2110-30: PCM digital audio output - ST 2110-31: AES3 audio output - ST 2110-40: Ancillary data (VITC/Time code, AFD/BAR, Closed captioning, OP-47 Teletext, SMPTE 2031 Teletext) - **Protocols:** Supports duplicate essence streams on separate output ports to facilitate SMPTE ST 2022-7 - **NMOS:** NMOS IS-04 and NMOS IS-05 support - **Hardware requirements:** Requires one of the following cards **NVIDIA ConnectX-6 Dx EN adapter card 25GbE (MCX621102AN-ADAT)** MediaKind marketing code: \- **MKP/HWO/PCI/NIC/25G/2PORT/B** (MCX621102AN-ADAT) ``` Features: - NVIDIA Mellanox ConnectX-6 Dx EN adapter card, 25GbE, **Dual-port SFP28**, PCIe 4.0 x8, No Crypto ``` **NVIDIA ConnectX-6 Lx EN adapter card 25GbE (MCX631102AN-ADAT)** MediaKind marketing code: \- **MKP/HWO/PCI/NIC/25G/2PORT/C** (MCX631102AN-ADAT) ``` Features: - NVIDIA Mellanox ConnectX-6 Lx EN adapter Card, 25GbE, **Dual-Port SFP28**, PCIe 4.0 x8, No Crypto ``` **NVIDIA ConnectX-6 Dx EN adapter card 100GbE (MCX623106AN-CDAT)** MediaKind marketing code: \- **MKP/HWO/PCI/NIC/100G** (MCX623106AN-CDAT) ```

The ConnectX-6 Dx 100GbE card enables higher output bandwidth; however, it does not increase decoding capacity on a COTS platform.

Features: - NVIDIA Mellanox ConnectX-6 Dx EN adapter card, 100GbE, **Dual-port QSFP56**, PCIe 4.0 x16, No Crypto ```

NVIDIA / Mellanox Ethernet network adapter cards must be sourced from NVIDIA rather than Dell, as OEM variants may impose restrictions on firmware upgrades.

## Multiplexing ### Inputs and outputs - IP (UDP or RTP) input and output of MPEG Transport Streams - RTP re-ordering - IGMP V3 redundancy - Input bitrate monitoring and CC error detection - SMPTE 2022-1 FEC on input and output ### Processing - PID filtering and PID remapping by re-multiplexing input programs Real-time PSI regeneration ## Content security ### Decryption - **Conditional Access (CA):** BISS1, BISS2, BISS-CA, Director 6, DVB-CI - **Hardware requirements:** A _Trusted Platform Module (TPM)_ may be required or suitable option cards. See details below **BISS1 & BISS2** BISS version 1 (BISS1) - **Modes:** Mode 1 and Mode E - **Key length:** 48-bit - **Standards:** DVB-CSA BISS version 2 (BISS2) - **Modes:** Mode 1, Mode E and BISS-CA - **Key length:** 128-bit - **Standards:** DVB-CISSA **BISS-CA**

A Trusted Platform Module (TPM) must be installed on the server.

- **Key length:** 128-bit - **Standards:** DVB-CISSA - **Features:** Entitlement management, Self-generated key pairs, Injected key pairs **Director 6 CA**

A Trusted Platform Module (TPM) must be installed on the server.

- **Key length:** 128-bit - **Features:** Entitlement management, Over Air Control (OAC) **Dual Common Interface (CI) option card (Digital Devices Octopus Duo CI)** MediaKind marketing code: - **MKP/HWO/PCI/CI/DUAL** (Digital Devices Octopus Duo CI)

The Digital Devices Octopus Duo CI is only available as a full-height PCIe card and is therefore limited to servers such as the C-series.

Features: - DVB-CI compliant - 2x CI slots for two independent Conditional Access Modules (CAM) on each option card - Capable of processing transport streams of up to 96 Mbps per CAM (though actual bitrate may be limted by the CAM) - All major CAMs supported - Multiple _Dual Common Interface (CI) option cards_ supported

Some CA descramblers will require a Trusted Platform Module (TPM) to be installed on the server.

## Ad insertion - **Ingest format:** - MPEG-TS over IP (SPTS), with a video buffer of 1 second minimum - Assets pre-encoded and stored locally - **Scheduling control:** Triggered via advanced scheduling control options: - **Signal-based:** based on submitted SCTE-35 signal (with matching criteria) - **Signal based / fallback to time:** SCTE-35 expected, but not present, fallback to out-of-band operations triggering - **Asset management:** - Storage of up to 90 minutes of assets in the unit - Assets and schedules fetched automatically from a central asset server - Automatic housekeeping of the asset store ## Monitoring & control - **Remote control:** Provided via the Mediakind MK.IO portal - **Direct control and status monitoring:** Provided via Web browser user interface and REST API - **Standard protocols:** SNMP, NTP, IGMP **High Availability (HA) Controller** - Automated (standalone) 1+1 output synchronization with PTS alignment (either SDI or ST 2110 inputs) # SRT input with decode and SDI output The configuration is based on the following main steps: - Step 1: you configure a **Reliable Transport** input. - Step 2: you configure a **Reliable Transport** listener with UDP IP output. - Step 3: you connect that UDP output to a **Receiver** service. - Step 4: you configure the **Receiver** service for SDI output. To setup this use case, follow these steps: ## Configure a Reliable Transport input 1. Connect to the web interface then navigate to the **Services** menu on the left-hand pane. 2. Click **Add service** and select **Reliable Transport** to create and configure the service. 3. Enter a name for this service. 4. In the **Input** section, set the **Input Mode** to **SRT Listener**. 5. In the **Output** section, set the **Output Mode** to **UDP**. ## Configure a Reliable Transport listener with UDP IP output 1. Configure the SRT Listener **Connection** parameters with the listener address and port. If required, then **Encryption**. **Link characteristics** parameters can also be set or adjusted. 2. Configure the **Output Connection** parameters. You should get the following: ![rx1 cfig service srt listener](/rx1-img/rx1_cfig_service_srt_listener.png) 3. Click **Save and exit** to save your changes. ## Configure the Receiver service for SDI output 1. Navigate to the **Services** menu on the left-hand pane. 2. Click **Add service** and select **Receiver** to create a new service. 3. Set the **Name** for the new service, the service **Type** to **SD/HD** and the **Output type** to **SDI**. ![rx1 create service receiver sdhd](/rx1-img/rx1_create_service_receiver_sdhd.png) 4. Click **OK** to create the service which will now appear in the services list. 5. From the **Services** pane, click the _service name_ for the newly created service to edit the configuration. 6. Select the **Input** tab under the **Parameters** section. 7. Set the **Input Type** to **IP** and configure the multicast **Stream address** and **Port** number. ![rx1 cfig receiver input IP](/rx1-img/rx1_cfig_receiver_input_IP.png) 8. Select the **Output** tab under the **Parameters** section. 9. Configure SDI output parameters as required such as the SDI output port number from **Output interface** option. ![rx1 cfig receiver output sdi](/rx1-img/rx1_cfig_receiver_output_sdi.png) 10. Once complete, click **Save and exit**. ## Start services On the **Services** page, assign a server to each service you want to run, then start the services. # MK.IO Beam Release Notes ## MK.IO Beam 1.16.0.10 30th October 2026 ### New features - Contribution encoding support for HEVC 420 8 bit / 10 bit - Support for the Dektec DTA-2175 card for encoding and reception channels. - Density improvements for reception decoding use cases on the Large V2 server. - Channel duplication for Essentials UI channels. - Expose SRT statistics for Essentials UI channels. - Support for satellite demodulation, SRT and IP inputs for encoding on Essentials UI. ## MK.IO Beam 1.15.0.5 28th September 2026 ### New features - Support for key rotation with fallback for fMP4 mezzanine - Support Beam on XOS Large V2 Server - Support Beam on XOS XL V2 Server - Reception gateway features enabled on the Essentials UI - Added an optional additional transport stream output for reception decode channels ## MK.IO Beam 1.14.0.1 4th September 2026 ### New features - Support for reception workflows using the Essentials UI - Automatic CPIX key rotation. See [Key Rotation](/beam/packager/parameters/hls-or-dash-over-cmaf/#compatible-cpix-ext-key) - BEAM ISO to support Servers with hardware RAIDed Disks. See [RAID and FakeRAID configuration](/beam/system-admin/iso-installation/raid-configuration) ## MK.IO Beam 1.13.0.7 21st August 2026 ### New features - Addition of an RT (reliable transport) failover group for high availability distributed deployments - Manual CPIX key rotation ## MK.IO Beam 1.12.0.7 17th July 2026 ### New features - Essentials UI for new customers only - Ability to change the audio line-up on a Receiver service without interruption in the video output for SDI output only - Null Packet Removal from Multiplexer transport stream output bitrate allowing users to remove NULL packets (PID 0x1FFF) from the MPEG transport stream output ## MK.IO Beam 1.11.0.4 2nd July 2026 ### New features - SMPTE ST 2110 end to end latency reduced to match SDI performance - Packager - CPIX key and credential support - Support for multiple UHD ST2110 outputs on a single Mellanox card ## MK.IO Beam 1.10.0.2 29th May 2026 ### New features - Add Support for 100G ST 2110 Network Card in MK.IO Beam - Add support for ConnectX-6 Lx EN Adapter Card - Make 3pp software persistent over upgrade - Ability to enter a Stream ID for a SRT session ## MK.IO Beam 1.9.0.5 24th April 2026 ### New features - Configuration of IP settings of bonded interfaces on the UI - Creation and deletion of VLAN interfaces on the UI - Configuration of IP settings of VLAN interfaces on the UI - Configuration of route metrics on the UI to allow support for multiple default gateways - Configuration of jumbo frames on the UI to simplify configuration of JPEG-XS encode - Configuration of static routes on the UI - 8 tuners supported on the 4-port RF input card (Digital Devices SX8) - Add information from Dell SupportAssist to Beam support package ## MK.IO Beam 1.8.0.3 27th March 2026 ### New features - Add H.264 High to the list of Contribution codecs - Removal of the four service limitation for SMPTE ST 2110 output - Support for down conversion modes: 1080i to 720p, 1080P to 720P, 720P to 1080i, UHD to 1080i, UHD to 1080P, UHD to 720P - Beam with distributed headends including Packaging - Static routes configuration now retained on upgrade ## MK.IO Beam 1.7.0.4 27th February 2026 ### New features - ST2022-6 output over IP - UI configuration support for HTTPS Proxy - Add Support for Multi-Payload SMPTE ST 2110-40 VANC Reception - Reception – support for super low delay mode for 1080i video sources - Packager redundancy in Beam using a failover group - MK.IO should pick up RF cards from Beam appliances and add them to the 'Device' page similar to 'IP' and 'SDI/ASI' - BEAM with HA Head ends - Support for Multiplexer redundancy ## MK.IO Beam 1.6.0.5 30th January 2026 ### New features - Support for router control for headend deployments of MK.IO Beam - HDR/SDR custom Look-up Table (LUT) upload and selection - It is now possible to enable/disable Packaging on the MK.IO Beam UI - CPIX integration using HMAC for live events and linear channels - Include alarms exposed to Prometheus so they can be viewed on a remote Grafana instance - Support for UHD decode over SMPTE ST 2110 output - BEAM with HA Head ends - Support for Packager and EL on separate servers - Provide HTTPS access to Packaged output - Splicing now supported in Distributed Head end deployments ## MK.IO Beam 1.5.0.4 27 November 2025 ### New features - Introduction of the X20 server - Live to live splicing is now supported - Support for backup and apply of device configurations from MK.IO ## MK.IO Beam 1.4.0.3 31 October 2025 ### New features - Support for high availability headend deployments with Live Encoding - Support for SD resolutions with SMPTE ST 2110 output - Improvements to decode latency - Bonding capability for all ports ## MK.IO Beam 1.3.0.0 9 October 2025 ### New features - Introduction of X40 server - Support for multiple CI option cards in a single chassis - Software decode supports HDR to SDR dynamic range conversion - Software decode support for additional sub-sampled resolutions for 720p- and 1080i-based content - Support for running MK.IO Beam in a VM for controller use cases on ESXI virtualization - Support for installing the MK.IO Beam software ISO via BMC or iDRAC - PTP, clock source and IGMP parameters can be configured on the UI - Network status information available on the UI ## MK.IO Beam 1.2.0.1 5 August 2025 ### New features - Introduction of C30 and H70 servers - Server pair 1+1 redundancy for headends - Support for multiple Digital Devices RF input cards in a single chassis - Receiver service support for AMD CPUs - Simplification of JPEG-XS encode configuration - Support for ASI output on Dektec DTA-2127 ## MK.IO Beam 1.1.0.2 23 June 2025 ### New features - Support for E50 and E60 servers for contribution encode and headend use cases. - 4:2:2 8-bit and 10-bit progressive and interlaced H.264 and H.265 HD software encode. - RF input and SDI output via Dektec DTA-2127 RF input option card. - 4:2:2 and 4:2:0 H.265 UHD software decode. - 4:2:2 10-bit SMPTE ST 2110 output with software decode. - The Dektec DTA-2178 8-port SDI option card is now supported with reception. It is possible to output up to 8 baseband outputs with one Dektec DTA-2178 card and more with multiple DTA-2178 cards. - Hostname, IP, NTP, firewall zones, DHCP and DNS parameters can be configured on the MK.IO Beam web UI. - New “Super Low” decode delay mode introduced for lower latency decoding. - Server health monitoring now available. - Support for active-backup redundant bonded network management interfaces. # Reliable Transport Reliable transport refers to a class of protocols designed to deliver media streams over IP networks that are unpredictable or lossy, such as the public internet. Standard UDP streaming is fast but offers no recovery if packets are lost. Reliable transport protocols add error correction and retransmission on top of UDP, so brief network disruptions do not result in visible artefacts in the stream. MK.IO Beam's Reliable Transport takes UDP packets and forwards them over SRT, Zixi, or RIST. It can also take SRT, Zixi, or RIST input and output as UDP or any other supported protocol. The UDP content is processed as a pipe without modification, and is typically used to carry transport streams encapsulated in UDP or RTP. ## Supported protocols - **SRT (Secure Reliable Transport):** An open-source protocol for low-latency video contribution over unpredictable networks. SRT supports both Caller and Listener connection modes and includes built-in AES encryption (128-bit, 192-bit, and 256-bit). - **RIST (Reliable Internet Stream Transport):** An open standards-based protocol for reliable video transport, also supporting Caller and Listener modes. - **Zixi:** A managed transport protocol with Feeder and Receiver roles, designed for reliable delivery over the internet. - **RTMP:** Available from v3.0.0 as a beta feature. Supports RTMP passthrough (RTMP input to RTMP output) and decode mode (RTMP input to UDP output). Not all features available for other protocols are present in the RTMP beta. ## Connection modes Each protocol operates in one of two roles, depending on which end of the connection initiates it: - **Caller (or Feeder):** The service initiates the connection to a remote listener. - **Listener (or Receiver):** The service waits for an incoming connection. Each Reliable Transport service is configured with an independent input mode and output mode. This flexibility means MK.IO Beam can sit at either end of a transport link, or act as a protocol bridge between two different connection types. ## Common use cases - Sending a live encoder output from a venue to a production facility over the public internet. - Receiving a contribution feed from a remote location for local decoding or processing. - Distributing a transport stream to multiple destinations with protocol conversion. To create and configure a Reliable Transport service, see [Service configuration and management](/beam/reliable-transport/service-management). # Monitoring the Reliable Transport service ## Service alarms The user interface allows you to access active and cleared alarms list for each service. Alarms information can be accessed for any service, either started or stopped, by clicking the "Alarm" button in front of each service. If a service is running, information about **Active alarms** as well as **Alarms history** is available. If a service is not running, only the Alarms history is available. For each running service: - If no alarms are active, the corresponding line on the Services page will show the alarm (`Alarm` icon) button in light gray on the right of the service name. - If any alarms are active, the corresponding line on the Services page will show the alarm (`Alarm` icon) button with a color indicating the level of severity. 1. From the **Services** page, identify the service that you want to monitor. 2. Click the related `Alarm` icon icon in the **Alarm** column. ![rt view alarms](/_machine-assets/e8865714aa621b072cf9e30134a1c69744dc910630e3dfef4aeb0f6a96ca845f.png) Depending on the severity of the alarm, the `Alarm` icon will appear in different colors and will display the most severe color alarm in case of multiple alarms. - `Alarm red` icon (critical alarm): the service is not running as expected, customer operations are affected. - `Alarm yellow` icon (major alarm): issues are affecting the service which may result in it not running as expected and could affect customer operations. - `Alarm green` icon (minor alarm): minor issues are affecting the service, but it is running as expected and customer operations are not affected. - `Alarm` icon (notice): an expected, meaningful event has happened for the service, worth logging in the Alarms history. From this page, you can access the following information: - The active alarms table applied on the current server including: - date and time of the alarm rise - alarm description (label) - alarm severity - detailed information - The alarm history table including: - date and time of the alarm rise - alarm description (label) - alarm status - alarm severity - server on which the service was applied when the alarm raised. - detailed information ### Alarms raised by the Reliable Transport service {/\* Update according to microservices/worker/worker/src/lib/Alarms.cpp "Maximum input connections have been established" excluded as not currently used and could cause confusion about available functionality \*/}
Name Description Values
No Reliable Transport input connection Input connection cannot be established Critical
No Reliable Transport input data No packets are received in input Critical
Packets skipped on Reliable Transport input Packets have been dropped during the last 10 seconds Major
Encryption error (input) Error with input encryption configuration Critical
No input connections have been established Notice
No Reliable Transport output connection Output connection cannot be established Critical
No Reliable Transport output data No packets are being sent to output Critical
Packets error on Reliable Transport output Problems detected in the output. E.g. packets being skipped Major
Encryption error (output) Error with encryption configuration Critical
No output connections have been established Output is listening but no connections have been started Notice
Maximum output connections have been established The maximum configured number of output connections has been reached. Further connection requests will be denied. Notice
Connection with license server lost Connection with the license server was lost. The service will only run for a grace period, after which functionality will be disabled unless connection with the license server is re-established. Major
Functionality disabled; connection with license server lost Service not running because connection with the license server has been lost and the grace period expired. Major
License period expires soon Additional information is provided when this alarm is raised, specifying when the current license will expire. Major
Undefined Reliable Transport alarm An unexpected error occurred for the service Critical
Failed to start Prometheus metrics Metrics are not available for this service Minor
### Example Below is an example for the alarms page of a Reliable Transport configuration using UDP input and SRT Listener output. ![rt alarms example](/_machine-assets/2eb2360b6658b55d223bbc610c89883af93049f333aa46fdad04751e250a0a2c.png) As per the previous sections described, both active and historic alarms are listed. The following information can be gleamed from it: - The page URL above shows this Alarms page applies to service "Demo UDP - SRT" - Active alarms - There is 1 currently raised alarm with "notice" severity. - This is an info level message advising that no outgoing connections to the output listener have been established (e.g. due to no incoming client requests). - It has been raised at 10:11:03 UTC by server "srt-1". - Alarm history - Other than the currently raised alarm, a "critical" severity alarm has been raised and cleared before. - This was a "No Reliable Transport input data" alarm, impacting the configuration running in server srt-1. - Further info is presented identifying providing details on why the alarm is raised. In this case, "No UDP packets being received". - The missing input alarm was raised at 09:50:37 UTC and cleared at 10:12:00 UTC. ## Service statistics When a Reliable Transport configuration is running, you can retrieve and monitor on user interface detailed statistics information. 1. From the **Services** page, identify the service that you want to monitor. 2. Click the related `Pie chart` icon icon in the **Stats** column.

The Pie chart icon is only accessible when an service configuration is associated to a server and then running.

![rt view alarms](/_machine-assets/e8865714aa621b072cf9e30134a1c69744dc910630e3dfef4aeb0f6a96ca845f.png) The **Statistics** page is displayed showing: - On the left side of the page, the statistics for the service input. - On the right side of the page, the statistics for the service output. This is an example for a configuration using UDP input and an SRT Listener output. At the time, 2 clients were connected to the Listener output. ![rt stats udp srt listener](/_machine-assets/1d54c53d7fc26d05612bb77fc2305a71418254f15d414d19e910f98d9ffe7928.png) Depending on the service Input Mode and Output mode configuration, the page will show different information. If Input/Output Mode is **UDP**, the following statistics will be available:
Information Details
Connection details UDP source. Top-right of the Input/Output Statistics panel
Received/Transmitted Packets Number of packets received/transmitted; expected to increment constantly.
Receive/Transmit Rate In Mb/s.
If Input/Output Mode is **SRT Caller** or **SRT Listener**, the following stats will be available:
Information Details
Connection details Listener address and number of connected clients (output listener only). Top-right of the Input/Output Statistics panel
Uptime Time since the connection was established; expected to increment constantly.
Received/Transmitted Packets Number of packets received/transmitted; expected to increment constantly.
Retransmitted Packets Number of packets which required retransmission; expected to be zero or increment very slowly in time. A rapid increase may indicate potential instability in the network connection.
Lost Packets Number of packets lost; expected to be zero. If not zero and incrementing, there may be issues with the network connection and the quality of other services using SRT as input could be affected.
Dropped Packets Number of packets dropped; expected to be zero. If not zero and incrementing, there may be issues with the network connection; quality of other services using SRT as input could be affected. It may be possible to reduce the number of dropped packets by changing the configuration for Latency and Maximum Bandwidth Overhead parameters.
Receive/Transmit rate In Mb/s
Link Bandwidth Bandwidth of the link in Mb/s. It should not be too much smaller than Receive/Transmit rate to prevent packet drop.
Round Trip Time Measured for the current connection between caller and listener, in milliseconds. Could be used to tune the Latency and Maximum Bandwidth Overhead parameters.
Receive/Transmit buffer Size of the receive/transmit buffer in milliseconds.

For SRT Listener outputs with multiple connections it is possible to monitor individual statistics for each connection using the dropdown in front of the field Display statistics for connection.

If Input/Output Mode is **Zixi Feeder** or **Zixi Receiver**, the following stats will be available:
Information Details
Uptime Time elapsed since the Zixi connection was started.
Packets Total number of sent data packets, including retransmitted packets.
Out of order Packets Total number of packets not in order (but will be reordered).
Dropped Packets Displays the total number of packets dropped since the beginning of the stream.
Duplicate Packets Total number of duplicated packets.
Overflow packets Total number of overflow packets.
Packet rate Transmitted/received packets per second.
Packets Jitter In milliseconds.
Round Trip Time In milliseconds.
Latency In milliseconds.
Congested Link congestion status (flag – true/false).
Transmit/Receive rate In Mb/s.
ARQ Packets: Total number of Automatic Repeat reQuest packets.
FEC Packets Total number of Forward Error Correction packets.
ARQ recovered Packets Total number of ARQ packets which were recovered.
FEC Recovered Packets Total number of FEC packets which were recovered.
Not Recovered Packets Total number of packets which were not recovered (FEC or ARQ).
Error Correction Duplicated Packets Total number of duplicated error correction packets.
Error Correction Requests Total number of error correction requested packets.
Error Correction Overflow Total number of error correction overflow packets.
If Input/Output Mode is **RIST Caller** or **RIST Listener**, the following stats will be available:
Information Details
Connection details Listener address and number of connected clients (output listener only). Top-right of the Input/Output Statistics panel
Uptime Time since the connection was established; expected to increment constantly.
Received/Transmitted Packets Number of packets received/transmitted; expected to increment constantly.
Retransmitted Packets (Output only) Number of packets which required retransmission; expected to be zero or increment very slowly in time. A rapid increase may indicate potential instability in the network connection.
Lost Packets (Input only) Number of packets lost. Out-of-order packets are also treated as lost. Lost packets may be recovered.
Dropped Packets (Input only) Number of packets dropped. These packets are too late to be played and can no longer be recovered.
Receive/Transmit rate In Mb/s
Round Trip Time Measured for the current connection between caller and listener, in milliseconds.
Quality Quality of the RIST connection. 100% means all packets are sent successfully the first time.

For RIST Listener outputs with multiple connections it is possible to monitor individual statistics for each connection using the dropdown in front of the field Display statistics for connection.

# Interact with an existing Reliable Transport service Each Reliable Transport service is displayed within a row in the Services page. To interact with an existing service, identify the name of the service of interest in the list of available services. Use the search option at the top of the page if needed. ## Start a service 1. On the service row corresponding to the service to be started, click **Choose a server to run** and select the name of the server to which the service will be assigned. The service is not automatically started. 2. Click `Play outline` icon to launch the service. The service Status changes to **starting** and then to **started**. The `Play outline` icon action button changes to `Stop outline` icon. ## Stop a service **Important:** Stopping a running service could disrupt customer operations. 1. On the service row corresponding to the service to be stopped, click `Stop outline` icon on the right of the service row. 2. On the dialog window that appears, confirm using the **Yes, stop it!** button. The service Status changes to **stopping** and then to **stopped**. The `Stop outline` icon action button changes to `Play outline` icon. ## Edit a service **Important:** Editing a running service could disrupt customer operations! It is recommended that services are only edited when stopped. 1. On the service row corresponding to the service to be edited, click `Edit` icon on the right of the service row. The service configuration page appears. 2. You can start editing your service. **Important:** Changing encryption configuration for SRT Caller or Listener modes requires similar changes on the corresponding Listener and Caller for the stream to be properly managed 3. Click **Save and continue** to save your changes and continue configuring the service, click **Save and exit** to save and finalize your service configuration and go back to the **Services** page, or click **Exit** to go back to the **Services** page without saving. ## Delete a service **Important:** Once a service is deleted, it is not possible to recover it. 1. Stop the service. 2. Click `Delete` icon to delete the service. 3. On the dialog window that appears, confirm using the **Yes, stop it!** button. The service row disappears from the Services page. ## What is the `service_id`? Every service has a name provided by the user and used to identify it in the services page. It also has an “id” (short for “identifier”). Although users usually do not need to know about the existence and value of the service id, it is worth mentioning the following: - The `service_id` must be unique for each service managed by a Controller. It is a field present in the JSON configuration structure that is saved to file when the service is exported, and must be present in any imported configuration. If you wish to export a service and want re-import it to have a second service with exactly the same configuration, make sure that you change the `service_id` before importing the file again. - The `service_id` is visible on the browser address bar when you edit a service, in the last part of the address (e.g. `srt_9850ef9e49c0adf7baa91602e1c8`). This is useful to know because the same identifier is used to create the filename when the service configuration is exported. It can be useful to know if you export a service and you are not sure which service you have exported. In this situation you may also just open the exported file and check the service name, but because the `service_id` is unique, it can be used in case of multiple services with the same name. - For advanced interaction with your services, you may use the product API, in which case the `service_id` is often required. - Note that, no matter if your service is configured for SRT or Zixi connection, the `service_id` will always contain `srt` in its name. # Reliable Transport services configuration and management ## Import a Reliable Transport service Prior importing a service, make sure: - the format of the file is correct (valid json); - the `service_type` field in your configuration file is `srt` (even though the configuration may be for a Zixi connection); - the imported service id is different from the existing services; - if the same id as an existing service is used, an option to override the existing service will be provided by the import UI. 1. Display services.

You can import files retrieved from a service exported from a different server.

2. Click **Import service...** and follow the instructions to [import Reliable Transport configurations](/beam/web-interface/services#import-a-service). 3. Once imported, the service(s) appear in the list of services. ## Create a new Reliable Transport service 1. Display services. 2. Click **Add service** 3. Select **Reliable Transport**. The following page displays: ![Services add rt new](/_machine-assets/2deb75459e8c4770b4cf61179c25a1f237cff230b9a8b96836f94e1b8523afb7.png) 4. Assign a **name** to the new service (100 characters max). This name will appear in your Services page, therefore it is recommended to choose a unique name for each service for easier identification from the Services page. 5. Continue the service configuration depending on your needs: - [SRT connection configuration](/beam/reliable-transport/service-management#srt-or-rist-connection-configuration) - [Zixi connection configuration](/beam/reliable-transport/service-management#zixi-connection-configuration) - [RIST connection configuration](/beam/reliable-transport/service-management#srt-or-rist-connection-configuration) ## Configure a Reliable Transport service ### SRT or RIST connection configuration Below is an example of a typical SRT or RIST use case. A single input transport stream is sent via SRT or RIST to multiple clients. ![rt srt rist multi output configuration example](/_machine-assets/14af7cbd1ce7bd03f8c477a857502f5e53fc1cc13e05bb9445e19e5475a80a96.png) To implement the use case above, the following Reliable Transport services are required: - 1 service with Input Mode = **UDP** and Output Mode = **SRT Listener** or Output Mode = **RIST Listener** - 1 service per client with Input Mode = **SRT Caller** or Input Mode = **RIST Caller** (respectively) and Output Mode = **UDP**

It is possible also to have UDP in ->SRT Caller -> SRT Listener -> UDP out. In that case just swap the Output/Input modes for the two services.

### Zixi connection configuration Zixi services can be created to implement the following use case: Two services are required: ![RT Zixi workflow](/_machine-assets/5955e282e5be75583d5c733986f5e0ae547839c10414b047c43a86bc3c788053.png) - Service 1 with Input Mode = **UDP** and Output Mode = **Zixi Feeder** - Service 2 with Input Mode = **Zixi Receiver** and Output Mode = **UDP** ### Reliable Transport parameters The configuration of the Input and Output section for the service depends on the use case needed. 1. Select the **Input Mode** from the corresponding drop-down menu on the left side of the Reliable Transport service configuration page. ![rt select input](/_machine-assets/242538eee2018d3adfc044907b03acfbbbf3b573bd008e71e940bce72501ae44.png) 2. Select the **Output Mode** from the corresponding drop-down menu on the right side of the Reliable Transport service configuration page. ![rt select output](/_machine-assets/724faf059690534ae902a3897e4e2e1c241b6afc212a4077eb65929a659bffb6.png) 3. Complete the **Input** and **Output** parameters that come with the selected mode: - [UDP configuration](/beam/reliable-transport/service-management#udp-configuration) - [SRT Caller configuration](/beam/reliable-transport/service-management#srt-caller-configuration) - [SRT Listener configuration](/beam/reliable-transport/service-management#srt-listener-configuration) - [Zixi Feeder configuration](/beam/reliable-transport/service-management#zixi-feeder-configuration) - [Zixi Receiver configuration](/beam/reliable-transport/service-management#zixi-receiver-configuration) - [RIST configuration](/beam/reliable-transport/service-management#rist-configuration) - [RTMP Caller configuration](/beam/reliable-transport/service-management#rtmp-caller-configuration) - [RTMP Listener configuration](/beam/reliable-transport/service-management#rtmp-listener-configuration) ### UDP configuration ![rt config udp](/_machine-assets/778344cb8d4029074365c140bc8e59df183c7780a71f203e246585522e494a69.png) Fields marked with \* are mandatory. #### Input
Name Description Values
Network interface* Name of the network interface on which the UDP stream will be received as it appears in the list from Servers->System Settings->Nework Settings: Devices. A dropdown is available for convenience but free text can also be used. String of max 32 alphanumeric characters
Stream Address* Multicast address of the UDP stream IPv4 address. Does not allow leading zeros.
Port* Multicast port of the UDP stream Integer number between 1024 and 65535
Source Address Source address of the input multicast stream IPv4 address. Does not allow leading zeros.
#### Output
Name Description Values
Network interface* Name of the network interface on which the UDP stream will be sent as it appears in the list from Servers->System Settings->Nework Settings: Devices. A dropdown is available for convenience but free text can also be used. String of max 32 alphanumeric characters
Stream Address* Multicast address of the UDP stream IPv4 address. Does not allow leading zeros.
Destination Port* Multicast port of the UDP stream Integer number between 1024 and 65535
Source Address User-specified source multicast address for the outgoing stream IPv4 address. Does not allow leading zeros.
Source Port User-specified source multicast port for the outgoing stream Integer number between 1024 and 65535
### SRT Caller configuration ![rt config srt caller](/_machine-assets/590b027c8765ba8b4f3588e5f4c981783cfd97dd6a7f34a9492ea4806d738f02.png)
Name Description Values
Listener Address* IP Address or hostname of the SRT Listener to connect to. IPv4 address (without leading zeros) or hostname.
Listener Port* Port of the SRT Listener Integer number between 1024 and 65535
Caller Port The local port to bind SRT connection to. Default 0 value means auto assigned. Integer number between 1024 and 65535
Network interface Name of the network interface the SRT Caller will use as it appears in the list from Servers->System Settings->Nework Settings: Devices. A dropdown is available for convenience but free text can also be used. String of max 32 alphanumeric characters
Stream ID The SRT Stream ID sent to the remote listener. Supports opaque strings and structured access-control format as per the SRT spec. String, up to 512 bytes
Encryption Choose the type of encryption for the SRT stream. Drop-down menu: Not set, AES-128, AES-192, AES-256
Pass Phrase If Encryption parameter value is Not set, this field is grayed out. Otherwise, will contain the encryption passphrase. String of minimum 10 characters.
Latency These values can be adjusted depending on the link characteristics in terms of round-trip time and packet loss rate. In milliseconds, between 60 and 8000.
Maximum Bandwidth Overhead Percentage bitrate overhead that can be used by the SRT link. Percentage, between 5 and 100. Value=0 means infinite.
#### Predicted Worst Case Link Characteristics The **Latency** and **Maximum Bandwidth Overhead** should match for Listener and Caller on the same connection. In case of mismatch, the highest values will be used. To calculate the optimal values for **Latency** and **Maximum Bandwidth Overhead**: 1. Click the **Calculate** button to launch the **Latency and Bandwidth overhead calculator**. 2. Set **Round Trip Time** and **Packet Loss Rate** according to the instructions and make sure the calculated values for **SRT latency** and **Maximum Bandwidth Overhead** do not show errors. 3. Use the calculated values to fill in the **Latency** and **Maximum Bandwidth Overhead** in the SRT Caller parameters section. 4. Click **Set** to automatically apply the calculated values. ### SRT Listener configuration ![rt config srt listener](/_machine-assets/e09dbc906ae2ecab4b748e5245f9c0ccf2304945038db682c2d211109b8caa4d.png)
Name Description Values
Listener Interface* Name of the network interface on which the Listener will be active as it appears in the list from Servers->System Settings->Network Settings: Devices. A dropdown is available for convenience but free text can also be used. String of max 32 alphanumeric characters
Listener Port* Port of the SRT Listener Integer number between 1024 and 65535
Maximum connections Maximum allowed number of SRT Callers that can connect to the output SRT Listener. Integer number between 1 and 65535
Encryption Choose the type of encryption for the SRT stream. Drop-down menu: Not set, AES-128, AES-192, AES-256
Pass Phrase If Encryption parameter value is Not set, this field is grayed out. Otherwise, will contain the encryption passphrase. String of minimum 10 characters.
Latency These values can be adjusted depending on the link characteristics in terms of round-trip time and packet loss rate. In milliseconds, between 60 and 8000.
Maximum Bandwidth Overhead Percentage bitrate overhead that can be used by the SRT link. Percentage, between 5 and 100. Value=0 means infinite.
The latency and overhead can be configured as per [Predicted Worst Case Link Characteristics](/beam/reliable-transport/service-management#predicted-worst-case-link-characteristics) above. ### Zixi Feeder configuration ![rt config zixi feeder](/_machine-assets/13f2c6012c65b5e1df089e8fbd67be4afdc56611a99838a8df34f8ee4d875b15.png)
Name Description Values
Host The Zixi Broadcaster address (FQDN or IP Address) String or IPv4 address.
Port The Zixi Broadcaster port to connect to. Integer number between 1024 and 65535, default 2088.
Encryption Choose the type of encryption for the Zixi stream. Drop-down menu: Not set, AES-128, AES-192, AES-256
Pass Phrase If Encryption parameter value is Not set, this field is grayed out. Otherwise, contain the encryption passphrase. Hexadecimal characters string. Expected length: 32 chars for AES-128, 48 chars for AES-192, 64 chars for AES-256.
Steam ID Zixi stream ID. Custom identifier. String of max 128 characters.
Password [Optional] Password associated to the Zixi stream. String of max 128 characters.
Maximum Bitrate Maximum bitrate of the stream sent through the Zixi connection, in kbps. Integer number between 1 and 2147483.
Maximum Latency Zixi stream latency in milliseconds. Integer number between 30 and 10000
#### Multiple Zixi Broadcasters management A Zixi Feeder output can be configured and connected to multiple Zixi Broadcasters, however: - The Zixi Feeder will only connect to one of them; - The choice is random (will not necessarily connect to the first one specified, even if available). 1. Click **Add New Connection** to configure a new pair of **Host**/**Port** information for a different Zixi Broadcaster. 2. Repeat for each new Zixi Broadcaster to configure. ### Zixi Receiver configuration ![rt config zixi receiver](/_machine-assets/954997b6d84a382acfcd6199a25dab0ffc36e9165b4285a96c38df07b2af482e.png)
Name Description Values
Host The Zixi Broadcaster address (FQDN or IP Address) String or IPv4 address.
Port The Zixi Broadcaster output port to connect to. Integer number between 1024 and 65535, default 2077.
Remote ID Zixi Remote ID (unique identifier for the Zixi receiver). This value cannot be edited. It is assigned automatically when creating the service.
Encryption Choose the type of encryption for the Zixi stream. Drop-down menu: Not set, AES-128, AES-192, AES-256
Pass Phrase If Encryption parameter value is Not set, this field is grayed out. Otherwise, contain the encryption passphrase. Shall match the corresponding feeder configuration. Hexadecimal characters string. Expected length: 32 chars for AES-128, 48 chars for AES-192, 64 chars for AES-256.
Steam ID Zixi stream ID. Custom identifier. Shall match the corresponding feeder configuration. String of max 128 characters.
Password [Optional] Password associated to the Zixi stream. Shall match the corresponding feeder configuration. String of max 128 characters.
Maximum Latency Zixi stream latency in milliseconds. Integer number between 30 and 10000
### RIST configuration ![rt config rist](/_machine-assets/0d1dca27bf3de799151540e430c0a8cd5c54f8e45ddf9eb0157aa72a830be9e3.png) #### Input - RIST Caller
Name Description Values
Listener Address* Address or hostname of the RIST Listener to connect to. IPv4 address (without leading zeros) or hostname.
Listener Port* Port of the RIST Caller Integer number between 1024 and 65535
Network interface Name of the network interface the RIST Caller will use as it appears in the list from Servers->System Settings->Nework Settings: Devices. A dropdown is available for convenience but free text can also be used. String of max 32 alphanumeric characters
Encryption Choose the type of encryption for the SRT stream. Drop-down menu: Not set, AES-128, AES-192, AES-256
Pass Phrase If Encryption parameter value is Not set, this field is grayed out. Otherwise, will contain the encryption passphrase. String of minimum 10 characters.
An advanced settings section is available by expanding the panel at the bottom of the Input configuration page. While the default settings are suitable for most applications, an experienced user can tune these to optimise the configuration their specific scenario. Detailed descriptions of each setting can be seen by hovering the cursor over the question mark between each configuration parameter's name and the configuration box for the value. #### Output - RIST Listener
Name Description Values
Listener Interface* Name of the network interface on which the Listener will be active as it appears in the list from Servers->System Settings->Network Settings: Devices. A dropdown is available for convenience but free text can also be used. String of max 32 alphanumeric characters
Listener Port* Port of the RIST Listener Integer number between 1024 and 65535
Maximum connections Maximum allowed number of SRT Callers that can connect to the output SRT Listener. Integer number between 1 and 65535
Encryption Choose the type of encryption for the SRT stream. Drop-down menu: Not set, AES-128, AES-192, AES-256
Pass Phrase If Encryption parameter value is Not set, this field is grayed out. Otherwise, will contain the encryption passphrase. String of minimum 10 characters.
An advanced settings section is available by expanding the panel at the bottom of the Output configuration page. While the default settings are suitable for most applications, an experienced user can tune these to optimise the configuration their specific scenario. Detailed descriptions of each setting can be seen by hovering the cursor over the question mark between each configuration parameter's name and the configuration box for the value. ### RTMP Caller configuration ![rt config rtmp caller](/_machine-assets/751fd3795150752599b29def5df0af72ec96f41dc350aeba083e5b669a53947b.png)
Name Description Values
Listener Address* IP Address of the RTMP Listener to connect to. IPv4 address (without leading zeros).
Listener Port* Port of the RTMP Listener Integer number between 256 and 65535
Caller Port The local port to bind RTMP connection to. Default 0 value means auto assigned. Integer number between 1024 and 65535
Application* Name of the RTMP application instance to connect to. String
Stream* The name of the stream being transferred. String
rtmps Enables RTMPS encryption. Tick box, off by default.
### RTMP Listener configuration ![rt config rtmp listener](/_machine-assets/6b2c775474d8ff5fe4d87d3884afb064d26ba38dd277cc748ede9a8a42418e78.png)
Name Description Values
Listener Interface* Name of the network interface on which the Listener will be active as it appears in the list from Servers->System Settings->Network Settings: Devices. A dropdown is available for convenience but free text can also be used. String of max 32 alphanumeric characters
Listener Port* Port of the RTMP Listener Integer number between 256 and 65535
Maximum connections Maximum allowed number of RTMP Callers that can connect to the output RTMP Listener. Integer number between 1 and 65535
# SCTE-35 Rewriting Stream conditioning is the process of managing, normalizing, and distributing the event signals that control content switching in a live broadcast workflow. These signals most commonly relate to advertising, blackout, and content substitution, and they are standardized as SCTE-35 (in-band triggers) and SCTE-224 (schedule-based policies). MK.IO Beam's SCTE-35 Rewriting service ingests normalized event data using the SCTE-224 standard, maps media points (made up of policy, viewing policy, audience, and other attributes) to scheduled and signal-based SCTE-35 controls, and distributes that control downstream to encoders and TS processors. ## How MK.IO Beam distributes control signals Rather than performing content substitution itself, Stream Conditioning acts as the event management and signal distribution layer. It communicates with downstream devices over industry-standard interfaces: - **CableLabs ESAM (2013):** Sends signal processing notifications to downstream encoders or TS processors, which act on the instructions to insert, replace, or modify content. - **SCTE-104/30:** Carries in-band ad insertion signals from Stream Conditioning to downstream encoders. - **SCTE-30/30:** Communicates with ad decision servers using the SCTE-30 protocol. ## Variables and filtering Stream Conditioning uses a variable and expression system to extract values from SCTE-35 and SCTE-224 messages. Variables are referenced in connection and input configurations to filter which events trigger which actions and to map event data to the appropriate downstream target. MK.IO Beam ships with a pre-configured set of variables, and you can create custom collections for your specific workflow. See [Manage Variables](/beam/stream-conditioning/variables) for details. ## Stream Conditioning and TS Splicer In a complete ad insertion or blackout workflow, Stream Conditioning and TS Splicer work together. Stream Conditioning handles the event management layer: receiving schedules, processing SCTE-35 triggers, and sending ESAM or SCTE signals downstream. TS Splicer is the downstream component that performs the actual content substitution in the transport stream. See [TS Splicing](/beam/ts-splicer) for how that component handles the substitution side of the workflow. ## Common use cases - Centralizing ad schedule management for multiple downstream encoders or TS processors. - Rewriting or filtering SCTE-35 signals before they reach downstream equipment. - Implementing blackout control across a distribution chain using SCTE-224 schedules. To begin configuring Stream Conditioning, see [Manage Connections](/beam/stream-conditioning/connections). # Configure connections MK.IO Beam implements industry-standard communication interface, namely: - [CableLabs ESAM communication (ESAM-SCC)](/beam/stream-conditioning/connections#esam-configuration) - [SCTE-104/30](/beam/stream-conditioning/connections#scte-10430-configuration) - [SCTE-30/30](/beam/stream-conditioning/connections#scte-3030-configuration) Above-mentioned interfaces provide a way for MK.IO Beam to control and enforce previously ingested events by interfacing with third-party components such as encoder/transcoder. ## ESAM configuration To configure ESAM communication to downstream target devices (such as an encoder, a TS processor for instance), proceed as follows: 1. Click the **Connections** tab 2. Enter and/or select the appropriate value for each parameter:
Parameter Description
Connection type Select ESAM.
Version Select 2013.
Expect notifications When enabled, allows Stream Conditioning to get notifications from ESAM devices processing.
3. In the **Endpoints** section, click the **Add** button to configure the endpoints.
Parameter Description
ID Set to Auto by default. You can switch to Manual and specify and ID.
Network name This field corresponds to the acquisition Point Identity defined by the ESAM standard. The same field value must be configured at the target device level for appropriate communication. It is used to identify the target device on a specific channel.
Zone identity Additional field that can be used to represent the location of the stream/channel.
Signal acquisitions Possible values:
- URL: URL to which the Signal Processing System endPoint can reach the Signal Acquisition System endPoint (such as encoder, TS processor).
- Listening path: The listening path is used by the SAS endPoint to return status notifications to the SPS endPoint. A typical use of this path is when signals are received from multiple acquisition points. It allows identifying which systems issued the response.
Default value: listening path = /, Example: listening path = /encoder1
Note: You can add an additional URL/path by clicking the Add button.
Attributes EndPoint attributes can be used for additional filtering in SCTE-224 input translations. It allows applying the translation actions to specific endPoint(s).
Example: name = VIRD, value= NY
![EndPoint configuration](/_machine-assets/02158c816a0ad118846d678e28500bc36d2aff5dae692743a9d876d34a055329.png)

Encoders or TS processors that will submit received SCTE-35 trigger to Stream Conditioning must also configure the ESAM endpoint.

Assuming that the controller managing Stream Conditioning is located at the following IP/port: 192.168.1.10:8080, with an endPoint configured named GAMEHD100, then the ESAM endpoint to configure will be: http://192.168.1.10:8080/api/esam/streamConditionings/GAMEHD100.

## SCTE-104/30 configuration To configure SCTE-104/30 communication to downstream target devices (such as an encoder, a TS processor for instance), proceed as follows: 1. Click the **Connections** tab. 2. Enter and/or select the appropriate value for each parameter:
Parameter Description
Connection type Select SCTE 104/SCTE 30.
3. Click **Add** to configure the end points. 4. Enter and/or select the appropriate value for each parameter:
Parameter Description
ID Set to Auto by default. You can switch to Manual and specify and ID.
DPI PID index Digital Program Insertion PID index (shall be aligned with the one configured on the encoding/transcoding device for instance).
Channel name Identifier for the SCTE-30 communication.
Injectors - Address: IP address of the device implementing SCTE-104/30.
- SCTE-104 port: communication port used for SCTE-104 communication.
- SCTE-30 port: communication port used for SCTE-30 communication.
Note: You can add an additional URL/ports by clicking the Add button.
Attributes EndPoint attributes can be used for additional filtering in SCTE-224 input translations. It allows applying the translation actions to specific endPoint(s).
Example: name = VIRD, value= NY
## SCTE-30/30 configuration To configure SCTE-30/30 communication to downstream target devices (such as an encoder, a TS processor for instance), proceed as follows: 1. Click the **Connections** tab. 2. Enter and/or select the appropriate value for each parameter:
Parameter Description
Connection type Select SCTE 30/SCTE 30.
3. Click **Add** to configure the end points. 4. Enter and/or select the appropriate value for each parameter:
Parameter Description
Channel name Identifier for the SCTE 30 communication.
Injectors - Address: IP address of the device implementing SCTE-30.
- SCTE-30 port: communication port used for SCTE-30 communication.
Note: You can add an additional URL/ports by clicking the Add button.
Attributes EndPoint attributes can be used for additional filtering in SCTE-224 input translations. It allows to apply the translation actions to specific endPoint(s).
Example: name = VIRD, value= NY
# Configure input ## Connect to SCTE-224 events database **Input** tab section allows **Stream Conditioning** service to connect to the list of events formatted using SCTE 224 standard (media points). In other words, **Input** section connects to a SCTE 224 database, and maps media points into video headend operations (such as switch to blackout using ESAM for instance). Mapping of media points over ESAM or SCTE-104 controls is stored in a separate database. 1. Click the **Input** tab. 2. Enter and/or select the appropriate value for each parameter:
Parameter Description
Type Select ESNI SCTE-224.
ESNI Server Stream Conditioning can connect to its own database of SCTE-224 events or connect to an external database.
When connecting to SCTE-224 events database managed by the viewing policy manager service (one database per service), a drop-down list will list all the different events database available (one per Viewing policy manager service). This generally corresponds to a programmer (ESPN, FOX etc.).
ESNI Media ID From the selected SCTE-224 events database, select the Media ID containing all the different media points, viewing policies, policies and audience. Selected Media ID generally corresponds to a linear channel for instance.
Ignore metadata Check this box if ESNI SCTE-224 metadata are not used in conditioning to improve performance.
Enable audit Return status of the events to the SCTE-224 database to enable SCTE-224 audit creation.
Once the connection to the SCTE-224 events database is configured, you need to configure the way media points will be converted into operations. Indeed, a Media (identified by its **Media ID**) contains a collection of Media Points. These Media points provide information about: - When the event shall be triggered (@matchTime attribute, @effective and @expire may also be used to provide validity window). - SCTE-35 in-band trigger conditions (via `` section). - The policy to apply or remove. A policy being a collection of viewing policies. ## Translations: identify events using Media point filtering Events (SCTE-224 media points) must be mapped to ESAM/SCTE-104 or SCTE-30 controls. To configure media point filtering, proceed as follows: 1. From the **Input** tab, go to the **Translations** section then click **Add rule**. 2. Enter and/or select the appropriate value for each parameter:
Parameter Description
Name Name of the translation rule.
SCTE-224 filters Configure filtering rules to identify a n SCTE-224 event, using filters such as Viewing Policy ID, audience ID, action etc.
## Translations: Operations Stream Conditioning implements different types of operations that may be grouped in two categories: ### Standard operations Alternate content and SCTE-35. These operations are based on standard and supported by any device compatible ESAM/SCTE-104/SCTE-30.
Parameter Description Use case example Target component
Alternate content Switch-over from a live feed to another one Sim-subs, regional substitution. Encoder, TS processor
SCTE-35 Configure-able SCTE-35 insertion to signal ad break, program start/end etc. Manage rewriting (Placement management) Ad insertion, SCTE-35 rewrite Encoder
### Advanced operations Image overlay, Animation, slate and video clip operations require specific functionalities only available within MediaKind portfolio (Live Encoder for instance).
Parameter Description Use case example Target component
Image overlay Control the video composing of a linear feed with an image Logo insertion Encoder (specific to Live Encoder solution)
Animation Video composing control using Flash animation (Flash object are assumed stored on target component) Advanced graphics Encoder (specific to Live Encoder solution)
Slate Control changeover from the linear stream to a slate Blackout Encoder (specific to Live Encoder solution)
Video clip Control the insertion of file-based assets Linear ad replacement Encoder (specific to Live Encoder solution)
None This operation has been introduced to specifically manage the deletion of a given SCTE-35 matching with matching criteria SCTE-35 deletion Encoder, TS processor
### Operation: General parameters To configure one or more operation(s) associated with the filtering of events configured in the [previous section](/beam/stream-conditioning/inputs#translations-identify-events-using-media-point-filtering), follow these steps: 1. From the **Input** tab, go to the **Operations** section then click **Add**. 2. Enter and/or select the appropriate value for each parameter:
Parameter Description
Name Configure a name for your operation.
Apply on Mandatory field indicating when the operation is launched. Possible options:
- Policy begin: operation triggered when the policy is applied (SCTE-224 <Apply> tag from the media point element).
- Policy end: operation triggered when the policy is removed (SCTE-224 <remove> tag from the media point element).
Scheduling mode Defines the criteria for launching the operations, namely:
- Auto (follow SCTE-224): This mode allows triggering an operation:
- based on time (if only at least one of the following attribute is present: @matchTime, @effective, @expires),
- based on incoming signal only (if only @matchSignal is present),
- or based on @matchSignal with a time-based fallback.
- Time-Based: operation can be forced to be exclusively time-based (even if the media point contains @matchSignal).
- SCTE-35 Signal-based: operation is launched only based on SCTE-35 signal (@matchSignal from the media point, with matching criteria configured in scheduling tab).
Discard incoming signal Restriction: Only available when selecting SCTE-35 Signal-based scheduling mode.
When checked, it instructs the encoder or TS processor to remove submitted SCTE-35 from its output.
The next sections provide information regarding the configuration of the different types of operations, as well as scheduling restrictions, ESAM properties and fallback operations. ### Operation: Alternate Content When selecting **Live Alternate content** type of operation, the following configuration is expected:
Parameter Description
Input ID This ID represents the alternate content ID configured at the target device (encoder, TS processor etc.). When using ESAM type of communication, this corresponds to the altContID information passed within the ESAM response.
![Example: Live stream switch configuration](/_machine-assets/97e5290232c0bcd11cefe48fc6f7c66dadea855939504c3476a7d7c6f6fae489.png) When the **Input ID** field is left blank, this implicitly means a return to “default” asset. In the case of a live to live stream switching for instance, configuring a blank value will lead to returning to main live stream. **Scheduling**, **ESAM properties** and **Fallback operation** tabs are common to all operations. Please refer to: - [Operation (all): Scheduling configuration](/beam/stream-conditioning/inputs#operation-all-scheduling-configuration) - [Operation: ESAM properties](/beam/stream-conditioning/inputs#operation-esam-properties) - [Operation: Fallback operation](/beam/stream-conditioning/inputs#operation-fallback-operation) ### Operation: SCTE-35 SCTE-35 operation can be used for two main purposes: - **SCTE-35 insertion:** Stream Conditioning controls the encoder or TS processor to insert a given SCTE-35 in its output stream. In this case, **Scheduling mode** shall be set to **Time-based**. This mode is also referred to as “out-of-band”. - **SCTE-35 rewrite:** This operation is aimed at modifying the incoming SCTE-35 to normalize the information for instance (rewriting descriptors, translating the SCTE-35 commands from splice insert to time signal). In this case, **Scheduling mode** shall be set to **SCTE-35 Signal-based** and **Discard incoming signal** must be checked (to avoid two signals in the output stream).

Auto scheduling mode (following SCTE-224) can be used in either SCTE-35 insertion or SCTE-35 management use case. We do not recommend using this mode for SCTE-35 operations as it may lead to unexpected behavior.

#### SCTE-35 Insertion To configure out-of-band (time-based) SCTE-35 insertion, follow these steps: 1. Make sure **Scheduling mode** is set to **Time-based**. 2. Under the **Operation** tab, set **Type** to **SCTE-35** from the list of available type of operations. 3. Configure Splice info: under the **Splice info** tab, select **Splice info type** from the list of SCTE-35 command types. ![SCTE-35 insertion configuration](/_machine-assets/b0f30937d6986b324bf3b07456da72671d83e9afecf06fb8cfd3f8fb464bdf39.png)

The set of parameters to configure will depend on the selected command. Users shall be familiar with the SCTE-35 standard. The main commands used are generally the following one: Splice Insert and Time Signal.

Some parameters can be automatically configured (retrieved from the media point/event schedule), for instance the Break duration or segmentation duration.

The figure below shows a **Splice insert** command configuration example with **Break duration** set automatically to the duration of the media point policy. ![Splice Insert: splice info section configuration](/_machine-assets/00a761e3c8c78a0f3ed3b46cca4cdf6644cddc21af2125f1d418e138edaede08.png)

Any SCTE-35 message, whether it’s a splice null, splice insert etc. contains a splice info section, as well as (optionally) a set of one or more segmentation descriptors. These segmentation descriptors are used to convey additional information and characterize the placement opportunity.

4. Configure segmentation descriptors: 1. Click the **Splice descriptors** tab. 2. Click the **Add descriptor** button then select **SegmentationDescriptor**. The configuration of all the different fields is user-defined and aligned with the SCTE-35 standard. Some fields can be configured automatically based on the event it is attached to (such as **Policy Duration** for the segmentation duration). ![Segmentation descriptor configuration](/_machine-assets/342383de1b94cdc38dfaf46be00c57f7634624d94f222ef291cc9f0b83113f9e.png) #### SCTE-35 Rewriting SCTE-35 signal submitted by an encoder or TS processor can be modified using Stream Conditioning. To configure SCTE-35 rewriting, follow these steps: 1. Make sure that **Scheduling mode** is set to **SCTE-35 Signal-based**. 2. Under the **Operation** tab, set **Type** to **SCTE-35** from the list of available type of operations. 3. Under the **Splice info** section, check the **Use source as template** option if you want to keep the SCTE-35 as is, and just modify attached segmentation descriptors for instance. You still have the possibility to override few parameters such as event ID or break duration for splice insert type of commands as show below. ![SCTE-35 rewriting using source as template](/_machine-assets/52457a9028b56dfc63833f7de0ff82a8cd226cc1d837914e591ffbc89e6b2ecd.png) 4. Uncheck this option if you want to convert an SCTE-35 splice insert into time signal for instance (and vice versa). 1. Configure splice info: see example below where we assuming that time signal SCTE-35 are received and translated into **Splice insert** type of command. ![SCTE-35 rewriting: command translation](/_machine-assets/4cb9ae14bb52e75d34f70916b3042abea6f00f0cd75e35d6f2b4492e856ad708.png) 2. Modify the incoming SCTE-35 descriptors: go to the **Source splice descriptors** section then click **Add modifier** then select whether you want to remove or rewrite segmentation descriptors from the SCTE-35 signal. - If you select **Remove**, configure the filter to identify the segmentation descriptor that needs to be deleted. The figure below shows an example of SCTE-35 rewrite where Stream Conditioning deletes the segmentation descriptor of type program start. ![Remove segmentation descriptor](/_machine-assets/908c600f65fb2db8dea5ec1b4b334f8a01805402aab2e67c562eb1faaeb4da29.png) - If you select **Rewrite**, configure the filter to identify the segmentation descriptor to rewrite/modify. Then, under override section, select the field to modify and configure its value. ![SCTE-35 rewrite](/_machine-assets/33447e5c7c0469df6ad2f792a55e0bdb92d199d530ca0dd3854265bf426a614f.png) 3. To add segmentation descriptors to the SCTE-35 submitted to Stream Conditioning: go to **Additional splice descriptors** section, click on **Add descriptor** then select **SegmentationDescriptor** and configure the segmentation descriptor, either manually, or leveraging pre-defined value (such as splice duration or segmentation duration for instance). ![Adding a segmentation descriptor](/_machine-assets/12b69514e22e9df41db40804fb4d919c441432f8db14d90b4cb3ebd132096875.png) ### Advanced Operation: image overlay Image overlay operation is used for use cases such as logo insertion. It allows controlling the insertion of an image on top of ongoing video. Parameters such as width, height, and X-Y coordinate must be configured to determine size and position of the image overlay. To configure image overlay operation, follow these steps: 1. From the **Operation** tab set the **Type** to **Image overlay**. 2. Enter and/or select the appropriate value for each parameter:
Parameter Description
Duration Can be manually configured, or automatically configured with Policy duration when selecting trigger point with value At the beginning.
Material ID ID of the image on the target device (can be a name like logo.jpg for instance)
Width image width, in pixels
Height Image height, in pixels
X X-horizontal coordinate
Y Y-vertical coordinate
Layer Specify which layer the image will be positioned on.
Up to 8 layers can be managed (7 images overlaying).
Elements with higher layers will be displayed on top of others.
3. Click **Ok** to validate. The new operation is added to the list of operations. ### Advanced Operation: Animation When combining Stream Conditioning with MediaKind Encoding Live, linear transcoded channel can be combined with Flash animation. Encoding Live embeds a Flash decoding module, enabling composing of Flash animation with the video. Flash animation can be used for: - Providing crawling functionality (for Emergency Alert System (EAS) application). - Promoting a service, while keeping the live channel (stretch video, and use space for advertising or promo). To configure animation type of operation, follow these steps: 1. From the **Operation** tab set the **Type** to **Animation**. 2. Enter and/or select the appropriate value for each parameter:
Parameter Description
Duration Can be manually configured, or automatically configured with Policy duration when selecting trigger point with value at the beginning
Material ID ID of the Flash SWF object on Encoding Live.
Layer Specify which layer the image will be positioned on. Up to 8 layers can be managed (7 images overlaying). Elements with higher layers will be displayed on top of others.
Fields Name/value that are MediaKind-specific. A description of the options is given in the table below.
Parameter Description
SWF_TEXT_01 Crawling text that will be passed as a variable by Stream Conditioning when controlling Encoding Live to trigger crawling insertion.
Example: This is my crawling text
SWF_SPEED Crawling speed. Configured value ranges from 1 to n (number of point per frame).
Default value is 4.
SWF_BACK_ALPHA Background transparency. Value range: [0..1].
Default value is 0.6.
SWF_COLOR_BACK Background color of the crawler, using RGB color system. Example: 55A9B0.
Default value is no background.
SWF_COLOR Text color using RBG system. Example: 55A9B0.
Default value is FFFFFF.
![Animation configuration](/_machine-assets/c97048dffe74b2ba9a9195df821fd058ecb14c8e955e4e6ac15c2cfd7de90c00.png) 3. Click **Ok** to validate. The new operation is added to the list of operations. ### Advanced Operation: Slate Stream Conditioning can control a target device to enable slate insertion. An obvious use case being global blackout at the encoder, or TS processing component level. Contrary to Image overlay, the underlying live channel is entirely replaced by the slate, either rat the baseband level, or TS level for instance. To configure slate insertion, follow these steps: 1. From the **Operation** tab set the **Type** to **Slate**. 2. Enter and/or select the appropriate value for each parameter:
Parameter Description
Duration Can be manually configured, or automatically configured with Policy duration when selecting trigger point with value at the beginning
Material ID ID of the Flash SWF object on Encoding Live.
![slate insertion configuration](/_machine-assets/dd73751191dc478537213500cf5502326949e73e80d7ff0ee95bc126ae35eb21.png) 3. Click **Ok** to validate. The new operation is added to the list of operations. ### Advanced Operation: Video clip Stream Conditioning can control live to file and file to live video switching using operation type “Video clip”. This operation, like “Image overlay” or “Animation” requires support of such behavior at the target device level.

Integration with MediaKind Live Encoder only supports video clip file in MPEG-TS file format.

To configure video clip, follow these steps: 1. From the **Operation** tab set the **Type** to **Video clip**. 2. Enter and/or select the appropriate value for each parameter:
Parameter Description
Clip Set to Custom to manually configure the video clip or set to Auto (following SCTE-224) to use material from SCTE-224 viewing policy.
Duration Can be manually configured, or automatically configured with Policy duration when selecting trigger point with value at the beginning
Material ID ID of the Flash SWF object on Encoding Live.
Start offset Offset in seconds the video clip will start playing at.
Default value is 0, meaning the video clip will start from the beginning.
![Prisma sc op clip](/_machine-assets/8b66eca5430771cb2768097dbd251d509b6dc09fb971c160afe872a76aa06508.png) 3. Click **Ok** to validate. The new operation is added to the list of operations. ### Scheduling, ESAM properties & Fallback **Scheduling**, **ESAM properties** and **Fallback operation** tabs are common to all operations. Please refer to: - [Operation (all): Scheduling configuration](/beam/stream-conditioning/inputs#operation-all-scheduling-configuration) - [Operation: ESAM properties](/beam/stream-conditioning/inputs#operation-esam-properties) - [Operation: Fallback operation](/beam/stream-conditioning/inputs#operation-fallback-operation) ### Operation (all): Scheduling configuration As explained in [Translations: Operations](/beam/stream-conditioning/inputs#translations-operations), scheduling mode can be automatically set based on media point configuration (using either @matchTime and or @matchSignal attributes), or forced to be time-based or signal-based. In such a case, the **Scheduling** tab will not appear. When forcing to **Time-based** or **SCTE-35 signal-based**, a **Scheduling** tab appears to adjust the timing or validity window and matching criteria respectively. #### SCTE-35 time-based scheduling mode To configure **Scheduling** tab when **Scheduling mode** is set to **Time-based**, follow these steps: 1. Configure **Time:** select among the list of available options: - **Auto (follow SCTE-224):** based on ingested schedule (@matchTime, @effective or @expire attribute of the media point) - **Match time:** force to @matchTime attribute of the media point - **Effective:** force to @effective attribute of the media point - **Expires:** force to @expires attribute of the media point Timing can be adjusted in seconds (positive or negative, for example-30) to launch the operation before or after the time configured in the media point. #### SCTE-35 signal-based scheduling mode When launching operations based on SCTE-35 (submitted by an encoder for instance), a validity window must be configured: - if the SCTE-35 falls within the window, the operation will be launched, - otherwise, the operation will be canceled. To configure the **Scheduling** tab when **Scheduling mode** is set to **SCTE-35 Signal-based**, follow these steps: 1. Go to the **Scheduling** tab. 2. Activate and select the appropriate value for each parameter.
Parameter Description
Create on alternate service Stream Conditioning allows launching the operation on another service at the same time.
Note: This configuration is optional, and reserved for advanced workflow.
Define stop condition Define the condition for canceling the ongoing operation (started by startcondition).
Restriction: This parameter is only displayed is you selected an ESAM (advanced) operation (see advanced operations table).
Enable priority Define the priority at which the signal-based operations should be applied:
- If matching criteria are met for one or more signal-based operations, only those with the highest priority will be triggered, 0 being the highest.
- If no priority is set all matching signal-based operations will be triggered.
3. Locate the **Condition** section. 4. Enter and/or select the appropriate value for each parameter:
Parameter Description
Validity period begin This setting determines the lower boundary of the validity window period. It can be automatically set based on the mediaPoint configuration (Auto (follow SCTE-224) i.e. equal to @effective if present else @matchTime) or forced to @matchTime, @effective or @expires.
Timing can be adjusted in seconds (positive or negative value).
Validity period end This setting determines the upper boundary of the validity window. It can be automatically set based on the mediaPoint configuration (Auto (follow SCTE-224) i.e equal to @matchTime + @signalTolerance is present else @expires) or forced to @matchTime or @expires.
Occurrence This setting controls the occurrence of the submitted SCTE-35.Possible values:
- Auto (follow SCTE-224): Occurrence based on the media point configuration. When @matchTime contains reusable attribute, this means that multiple occurrences are allowed. If not, this is equivalent to enabling occurrence to once. If @matchTime and @matchSignal are configured, this is equivalent to “once with time-based fallback”.
- Multiple: allows multiple SCTE-35 occurrence. In other words, if more than one SCTE-35 with matching criteria is received within the validity window, the operation will be launched as many times as there are matching SCTE-35 signals.
- Once: this mode allows launching the operation once, and de-activate it. Should other SCTE-35 signal be received within the validity window with matching criteria, the operation will not be triggered.
- Once with time-based fallback: launch the operation upon SCTE-35 with matching criteria within the validity window. If no signal is received, the operation will be launched based on time (timing linked to validity period end configuration).
- Time-based fallback only: this special mode enables to de-activate the operation when a SCTE-35 signal with matching criteria within the validity period is received. If no signal is received, the operation is forced time-based.
Note: When configuring occurrence with Time-based fallback only or Once with time-based fallback, the fallback operation must be configured. This configuration is detailed in Operation: Fallback operation.
SCTE-35 matching When the media point configuration contains @matchSignal, SCTE-35 matching can be automatically managed using Auto (follow SCTE-224). This is the case for SCTE-224 ingest, or Disney PCC type of ingest. For other types of ingest like ESNI-I02, no matching criteria are conveyed as part of the schedule. They must then be configured by selecting Custom.
An example of signal-based scheduling configuration is given in the figure below, where a validity period of 60 seconds surrounding @matchTime is configured, with an **Occurrence** set to **Once**, and **Custom** **SCTE-35 matching** criteria: only match if time signal and segmentation type ID is set to **Program start**. ### Operation: ESAM properties When selecting **ESAM** communication at the **Connection** tab level, ESAM properties can be configured when configuring the operation. To configure ESAM properties, follow these steps: 1. Go to the **ESAM properties** tab. 2. Enter and/or select the appropriate value for each parameter:
Parameter Description
Enable conditioning info Stream Conditioning supports enabling/disabling conditioning info.
Enable event schedule Enable repetition of a signal using EventSchedule element in ESAM response.
Type EventSchedule supports a choice of two scheduling models:
- Absolute start and end UTC times,
- Relative (to signal time) start and end offsets
Interval Specifies a desired repetition interval for the scheduled signal.
Start UTC Note: Available when scheduling type is set to Absolute.
Specifies the time to start broadcasting the data as a UTC date and time.
End UTC Note: Available when scheduling type is set to Absolute.
Optional time to stop broadcasting the data as a UTC date and time.
Start offset Note: Available when scheduling type is set to Relative.
Specify the time to start broadcasting the data as a duration from the associated/related signal.
End offset Note: Available when scheduling type is set to Relative.
Optional time to stop broadcasting the data as a duration from the associated/related signal.
![ESAM Properties](/_machine-assets/f50508bf48ab1af8cba288fe7c6c8344a4467a1be27acca4cd5a07480415999c.png) ### Operation: Fallback operation For Signal-based operation, a fallback may need to be configured in case the SCTE-35 signal is not received during the window validity period. This is crucial for use cases like blackout, where the switch-over is generally done based on SCTE-35. In case this signal does not show up, a fallback mechanism must be put in place to make sure the restriction is being handled properly. To configure fallback operation, set the following parameters: 1. **Define fallback operation:** enable or disable operation fallback configuration: 1. Click the **Copy initial operation** button to copy the settings from the **Operation** tab. 2. If you want to configure a different operation from the one in **Operation** tab, configuration is fully customizable, providing the user with all the different operations to be triggered as fallback. ![fallback operation configuration](/_machine-assets/369510d6587a2f6124fe7b711a281925d0b156083f5ea7effe8bf54fb24e462f.png) # Configure Notifications The notification tab allows you to configure notifications for incoming or ongoing SCTE35 signals. A description of the different fields to configure is given below:
Parameter Description
Name Name of the webhook endpoint.
Type Type of notification to send. Only scte35 is supported.
URL HTTP URL of the webhook endpoint.
Key Secret used by the webhook listener to authenticate the webhook sender.
Signal Required for Type “SCTE-35”. Value is either Incoming or Outgoing
Filters Notification is sent only if the SCTE-35 matches these conditions.
You can configure as many SCTE35 filters and notification as needed by clicking the **+ Add** button. # Operations scheduling view Once the connection to SCTE 224 database has been configured, and operations mapped against those SCTE 224 events, **Stream Conditioning** service will automatically create and store the operations/actions into its scheduling & control database.

Scheduling view is only available if the service is started.

To visualize the scheduling & control timeline, follow these steps: 1. You can either: 1. Click on the timeline button located at the top right corner of a **Stream Conditioning** configuration page. ![Prisma timeline icon top right corner](/_machine-assets/bd05f99dd98b320cf239c726018ed4cdb14b29047c10d100b1fc33896a469b85.png) 2. or click on the timeline button from the **Actions** list of configured service. ![Prisma timeline icon service actions](/_machine-assets/afe006df85d23f8cd5929c7bedf0af93ef75002ade9d29824f2ff71f9d21facb.png) As a result, when events from the SCTE 224 database match criteria configured under **Stream Conditioning** service, the operations will appear in the timeline. ![Scheduling and Control Operation timeline](/_machine-assets/a585879d15f966f46d51abea60825b969d6b40b446009fcf1dba70985a44cd19.png) # Configure Timings A tab is available to configure timing, retention time for **Stream Conditioning** service. A description of the different fields to configure is given below:
Parameter Description
Event history Configure (in seconds) the duration the events will be kept in database once they have been processed.
Event transfer time This timing defines how long in advance the event shall be sent to the target component.
Media clip pre-roll delay Necessary pre-roll time for the target component to fetch files such as creatives, program before it gets processed.
Live stream switch pre-roll delay Pre-roll time required by the target component when switching from one live source to another. This value may vary depending on the target component.
Default values are configured by default. **Event transfer time**, as well as **Media clip pre-roll delay** and **Live stream switch pre-roll delay** are values applicable to MediaKind Live Encoder. ![Example of timings settings](/_machine-assets/319fcfc3c8d68385c05077b1ff21ebd2768ef9daa9c3bbbda7dca47e18078a11.png) # Manage variables MK.IO Beam comes with a pre-configured set of variables that you can use to manage SCTE-35/SCTE-224 filtering, creation and rewriting. ## Display variables To see the list of variables, follow these steps: 1. From the left menu, select **Settings** > **Stream Conditioning variables** tab. Predefined collections of variables are displayed: ![Stream Conditioning variables](/_machine-assets/b7022f36eedef09a953ff2b200bc8e68ba46ba87a2e73143c2868e18c403a4c8.png) 2. You can create a custom variable. ## Create a new collection of variables To extract a well-defined value (such as the segmentation duration of the segmentation descriptor which type ID = program start), you need to create a variable. To create a new collection of variables, proceed as follows: 1. Click the **Create** button located at the bottom left of the variables table. 2. Enter and/or select the appropriate value for each parameter:
Parameter Description
Collection name Define the collection name, must be unique
Type The type of the collection which will be used to the variables. Select one of the three available values: scte35, scte224 and context.
Description Provide information about the collection.
![Prisma sc settings variables collection add](/_machine-assets/87a2e3eadadc0f5e5300959c03d04c3fac8ba95a968e7f0c964008b4e4c14a92.png) 3. Click **Add** to add a variable to your collection. 4. Enter and/or select the appropriate value for each parameter:
Parameter Description
Name The name of the variable is the reference which can be used in the configs, must be unique in the collection, and cannot be modified.
Label The label of the variable is more natural way to display the variable in the UI.
Description Short description of the variable. We recommend configuring an explicit variable name.
Type Select the variable type.
Method The method which is applied to the data retrieved to the Xpath. Only available for the following types: Boolean, Number and String.
Path Define the Xpath of the variable which will be used to retrieved data
Group The group of the variable allow to group this variable in dropdown list
Tags The tags are used in the UI do display the variables in expected input fields
![Prisma sc settings variables add](/_machine-assets/f69f1d5cfede9410969de1fc141c9a12565d3afe8aec0ecef61c27b663cac58c.png) 5. Click **Ok** to save then **Save** to validate. The new collection is added to the list of predefined collections and can. You can now assign this new collection of variables to a service and use it to create replacement operations or filters. ## Associate a collection of variables to a service Once you have created a new collection of variables you can assign it to a service. 1. From a **Stream Conditioning** service, click the **Variables** tab. The list of predefined collections is displayed. 2. Click the **Select variable collection** button then select the collection you want to add. The new collection is added to the list of predefined collections. You can use it to create replacement operations or filters. 3. Click **Save and continue** or **Save and exit** to save your changes. ## Context variables on SCTE-35 signal-based operations The goal of context variables is to maintain any state, so that any operation triggered could be managed according to information from the past. - Stream Conditioning can now keep track of any event modification to condition downstream processing and signaling. - When operation like SCTE-35 rewrite or insertion are triggered, the operation on information can be conditioned by previously triggered operation. Context variables can only be defined from a Stream Conditioning service on which collection of variables have been created or imported. It consists in configuring the Post Processing for a signal-based operation in order to change current value for one or several context variables when the operation is starting. The configuration of context variables can be done either from: - The Stream Conditioning configuration page (**Input** > **+ Add rule** > **+ Add Operations** > **Post-processing**). - The Stream Conditioning scheduling & control timeline page (**Resident SCTE-35 signal-based operations** > **+ Add** > **Post-processing**). ![Prisma sc context variables](/_machine-assets/fe07754773b4524cc0a25a11804b58ab6645eff81460e4f37f19baf0390fdf8c.png) Click the **Add** button to select the predefined variable and enter the new value associated to this variable. The context variable value car be updated either with a new value defined and set in the configuration or with a value retrieved from an information coming from the SCTE-35 signal that triggered the operation. The values of the context variables are reset to the default value after a service is stopped. # System Administration This section covers the management of the BEAM platform itself (the hardware, operating system, security, and more), rather than the media workflows running on it.

The majority of these tasks are performed via the System Center menu in the web interface (accessed via the gear icon in the top right corner).

## Server Management Manage the physical or virtual notes in your BEAM cluster. [Manage Servers](/beam/system-admin/servers/servers) Add, remove, or reboot nodes. [Failover Groups](/beam/system-admin/servers/failover) Configure redundancy groups for automatic failover. ## Security & Access Configure security settings and user access controls. [User Management](/beam/system-admin/security/user-management) Create local users and assign roles. [LDAP Configuration](/beam/system-admin/security/ldap-management) Integrate with Active Directory for centralised auth. [SSL Certificates](/beam/system-admin/security/ssl-certificates) Install customer-signed certificates for HTTPS. ## Network & Time Configure the network settings and time synchronization. [Configure Network Interfaces](/beam/system-admin/network/configure-nics) Set IP addresses, DNS, IGMP, and firewall zones. [Control Interface Wizard](/beam/system-admin/network/control-interface-wizard) Configure the Control interface, MK.IO HTTP proxy, and diagnose network issues. [Bonded Interfaces](/beam/system-admin/network/bonded-interfaces) Configure active-backup interfaces for redundancy. [VLAN Interfaces](/beam/system-admin/network/vlan-interfaces) Add and delete VLAN interfaces from the command line. [Jumbo Frames](/beam/system-admin/network/jumbo-frames) Set the MTU to enable jumbo frames for high data rate streams. [System Clock](/beam/system-admin/network/system-clock) Synchronize time via NTP, TDT or PTP. [Router Configuration](/beam/system-admin/network/router-configuration) Connect to external SDI routers for input switching. ## Maintenance & Monitoring Keep the system healthy and monitor its performance. [Backup & Restore](/beam/system-admin/maintenance/backup-restore) Save and restore system configurations. [Manage Alarms](/beam/system-admin/maintenance/manage-alarms) Configure alarm severity and SNMP traps. [Generate Support Package](/beam/system-admin/maintenance/generate-support-package) Create log bundles for MediaKind support. [Install the ISO](/beam/system-admin/iso-installation) How to install the beam ISO. [Processing Types](/beam/system-admin/maintenance/processing-types) Enable or disable processing types to optimize performance. # How to install the MK.IO Beam ISO This step is only required for servers which have not been purchased from MediaKind. If the MK.IO Beam server and software are purchased separately, the MK.IO Beam software will need to be installed on the server. The MK.IO Beam software is distributed in the form of an ISO image.

Note: For XOS Large V2, XOS XLarge V2, HPE DL360, and HPE DL325 servers, installing or upgrading to MK.IO Beam 1.16 or later automatically hardens the default BIOS and iLO configuration for known BIOS and firmware versions. See Installing Beam on XOS Large V2, XOS XLarge V2, HPE DL360, HPE DL325 servers.

### BIOS configuration

Note: Enabling High Performance mode in the BIOS is recommended.

If the system drive uses hardware RAID or FakeRAID, see RAID and FakeRAID configuration for supported configurations before continuing.

Review the following settings in the BIOS.

  • Secure boot should be disabled.
  • TPM support should be disabled.
  • The Real Time Clock (RTC) should be set to the correct time and date.
#### ASI/SDI PCIe card support If compatibility with 4-port or 8-port Dektec ASI/SDI option cards is required, then the **PCIe Data Link Feature Exchange** option must be disabled. This must be done before installing any 4-port or 8-port Dektec ASI/SDI option cards into the server.

Installing a 4- or 8-port Dektec ASI/SDI in a server before checking and changing the following settings could prevent the server from booting up.

- If supplied, install the MK Custom BIOS Firmware. - Boot into the BIOS. - Check for the **PCIe Data Link Feature Exchange** or **DLFE** setting and disable it.\ If this setting does not exist and the server will not boot with a Dektec card installed, note the server make, model and BIOS version and contact MediaKind Support. ### Boot configuration #### Create a bootable USB drive The USB drive must be at least 16GB. There are several methods for writing ISO files to USB drives. The following procedure describes the process using the free tool, [Rufus](https://rufus.ie/en/) in Microsoft Windows: 1. Download and install the Rufus tool 2. Run Rufus and connect the target USB drive to the Windows PC 3. Check that the USB drive is detected and shown in the user interface: ![ISO install USB 000](/beam-img/ISO-install-USB-000.png) 4. Click the Select button and browse to the ISO file: ![ISO install USB 001](/beam-img/ISO-install-USB-001.png) 5. Leave all configuration settings at their defaults and click the Start button: ![ISO install USB 002](/beam-img/ISO-install-USB-002.png) 6. When prompted about ISOHybrid image, leave the default ISO Image mode set and click OK: ![ISO install USB 003](/beam-img/ISO-install-USB-003.png) 7. If prompted to download the Syslinux installation files, click Yes: ![ISO install USB 004](/beam-img/ISO-install-USB-004.png) 8. Check that the correct USB drive is being written to and click OK: ![ISO install USB 005](/beam-img/ISO-install-USB-005.png) 9. When the ISO file has been written to the USB drive, Rufus will change the status to READY: ![ISO install USB 006](/beam-img/ISO-install-USB-006.png) 10. Click Close and remove the USB drive from the computer: ![ISO install USB 007](/beam-img/ISO-install-USB-007.png) The USB drive is now ready to use to install MK.IO Beam. #### Boot from the USB drive - Insert the bootable USB drive with the MK ISO into a USB port on the server. - Boot to the One Time Boot Menu or into the BIOS to configure the server to boot from the USB drive. The exact steps for this will vary between different types of server. Refer to the server manufacturer's documentation for more information. ### ISO installation 1. When first booting to the MK.IO Beam ISO, you will see a screen which shows two options, **Start MediaKind Field Service 2.x** and **Troubleshooting**. Select **Start MediaKind Field Service 2.x** and press the Return key. ![ISO install 001](/beam-img/ISO-install-001.png) 2. A dialog will be shown stating that no existing configuration has been found. Wait for 5 seconds and the installation will continue. ![ISO install 002](/beam-img/ISO-install-002.png) 3. When prompted to install the bundle, click **OK** to continue the installation: ![ISO install 003](/beam-img/ISO-install-003.png) 4. A progress screen will be shown. This process can take 20 minutes or more depending on the speed of the USB drive. ![ISO install 004](/beam-img/ISO-install-004.png) The progress bar may not change for several minutes, this is normal. 5. Once the install process has completed, the server will reboot: ![ISO install 005](/beam-img/ISO-install-005.png) 6. The MediaKind Boot Manager will start: ![ISO install 006](/beam-img/ISO-install-006.png) 7. Then the AlmaLinux boot screen will be displayed: ![ISO install 007](/beam-img/ISO-install-007.png) 8. When prompted to login, MK.IO Beam is installed on the server. # Installing Beam on G8 and G9 servers There is no upgrade path from Aquila to MK.IO Beam, but: 1. MK.IO Beam can be installed on G8 and G9 servers using the MK.IO Beam ISO. 2. Density should be roughly similar to Aquila, but if in doubt, contact Product Management for guidance. 3. MK.IO Beam requires more disk space due to its support for multiple banks and a broader set of default components, compared to a dedicated Live Encoding, Multiplex, or Packager server. 4. Server configurations can be exported from Aquila and, in most cases, will be compatible with MK.IO Beam deployments, with the following caveats: - Aquila V21 Packager service configuration is not fully compatible with V30 Packager supplied with MK.IO Beam, seek guidance from the MediaKind Packager community for migrating Aquila V21 Packager configurations to Beam V30 Packager. - It should be possible to import Aquila Live Encoding service configurations to Beam servers, but json service editing may be required in some cases. - Following the import of Aquila json service configuration, it will be necessary to review and update the associated service for interface usage. (Beam default interface naming may not match the previous Aquila interface naming.) - If advanced parameters were applied to config maps, to affect all services under Aquila deployments, they will need to be reapplied to config maps on the Beam deployment 5. Prior to using the MK.IO Beam ISO, confirm the BIOS is configured appropriately with respect to Real-time clock configuration and specifically for the following options with G9 servers:\ **\[BIOS::Advanced::Processor Configuration]**\ Intel(R) Virtualization Technology=Enabled\ X2APIC=Enabled\ **\[BIOS::Advanced::Integrated IO Configuration]**\ Intel(R) VT for Directed I/O=Enabled\ PCIe Pll SSC=Disabled\ **\[BIOS::Advanced::Integrated IO Configuration::PCIe Slot Bifurcation Setting]**\ Riser1\_Slot\_1 Bifurcation=x8x8\ Riser2\_Slot\_1 Bifurcation=x8x8\ Riser2\_Slot\_2 Bifurcation=x8x8\ **\[BIOS::Advanced::Integrated IO Configuration::PCIe Misc. Configuration]**\ PCIe ASPM Support (Global)=Disabled\ **\[BIOS::Advanced::Integrated IO Configuration::Processor PCIe Link Speed::Socket 0 PCIe Link Speed]**\ Socket 0, PCIe Port 1a=Gen 3\ Socket 0, PCIe Port 1c=Gen 3\ **\[BIOS::Advanced::Integrated IO Configuration::Processor PCIe Link Speed::Socket 1 PCIe Link Speed]**\ Socket 1, PCIe Port 1a=Gen 3\ Socket 1, PCIe Port 2a=Gen 3\ Socket 1, PCIe Port 2c=Gen 3\ **\[BIOS::Advanced::Integrated IO Configuration::PCIe Misc. Configuration::Socket 0 Configuration::Port 1A]**\ Data Link Feature Exchange=Disabled\ **\[BIOS::Advanced::Integrated IO Configuration::PCIe Misc. Configuration::Socket 0 Configuration::Port 1C]**\ Data Link Feature Exchange=Disabled\ **\[BIOS::Advanced::Integrated IO Configuration::PCIe Misc. Configuration::Socket 1 Configuration::Port 1A]**\ Data Link Feature Exchange=Disabled\ **\[BIOS::Advanced::Integrated IO Configuration::PCIe Misc. Configuration::Socket 1 Configuration::Port 2A]**\ Data Link Feature Exchange=Disabled\ **\[BIOS::Advanced::Integrated IO Configuration::PCIe Misc. Configuration::Socket 1 Configuration::Port 2C]**\ Data Link Feature Exchange=Disabled # Installing Beam on XOS Large V2, XOS XLarge V2, HPE DL360, HPE DL325 servers Installing or upgrading to MK.IO Beam 1.16 or later automatically hardens the default BIOS and iLO configuration for known BIOS and firmware versions on XOS Large V2, XOS XLarge V2, HPE DL360, and HPE DL325 servers. The settings are applied during the installation or upgrade process only once and will not be reapplied during subsequent reboots. # RAID and FakeRAID configuration This page covers the disk RAID configurations supported for the MK.IO Beam system drive.

RAID vs FakeRAID: With hardware RAID, the controller assembles the array itself and presents it to the OS as a single ordinary disk (/dev/sdX). With FakeRAID, the controller only stores RAID metadata; the OS assembles the array in software, and it appears as /dev/mdX with the member disks still visible separately. Check the controller model in the server's RAID/BIOS utility or management console (for example, iDRAC) to determine which type is in use.

Sector size: From MK.IO Beam 1.14.0, the system drive may use either a 512-byte or a 4Kn (4096-byte) sector size. On earlier releases it must be 512 bytes: installation onto a 4Kn drive fails when the installer mounts the boot partition.

## Hardware RAID Hardware RAID has always been supported for the MK.IO Beam system drive. Before 1.14.0 the virtual disk must be created with a 512-byte block size; from 1.14.0 a 4096-byte block size is also supported. Controllers often default to 4096, so check the block size when creating the virtual disk if the server is running an earlier release. ## FakeRAID From MK.IO Beam 1.14.0, FakeRAID is supported for the system drive. The following settings are required:
Setting Value
Sector size 512 or 4096
OS RHEL
RAID Type Linux RAID
RAID Level RAID 1
# Troubleshooting the ISO installation ## If the installation stops and this message is displayed: ![ISO install 008](/beam-img/ISO-install-008.png) - Check the MD5 of the ISO file against the supplied MD5 checksum.\ There are several ways to verify MD5 checksums. Please check online for a suitable method for your operating system. - Check host compatibility\ Contact MediaKind to confirm that your hardware is supported by MK.IO Beam ## If ISO installation fails with Chassis configuration issues relating to "RTC date/time not valid": - Check the BIOS and ensure the Real Time Clock (RTC) is set to the correct time and date. ## If ISO installation succeeds but the server fails to boot to Beam software: - Check Secure boot is disabled. - Check TPM support is disabled.\ Beam software uses a custom bootloader, and this requires the above BIOS options to be set. - [Service Settings](/beam/system-admin/maintenance/service-settings) - [Health Monitoring](/beam/system-admin/maintenance/health-monitoring) - [Backup and Restore](/beam/system-admin/maintenance/backup-restore) - [Alarms and Events](/beam/system-admin/maintenance/alarms-events) - [Manage Alarms](/beam/system-admin/maintenance/manage-alarms) - [Setup SDI/ASI Cards](/beam/system-admin/maintenance/setup-sdi-asi-card) - [Generate Support Package](/beam/system-admin/maintenance/generate-support-package): How to generate a Support Package (Collect device logs) on a Beam server, and how to collect a Dell SupportAssist Collection. - [Parameters](/beam/system-admin/maintenance/parameters) - [Processing Types](/beam/system-admin/maintenance/processing-types): Enable or disable specific processing types to optimize system resources on lower-spec units. # Manage alarms and events ## Alarm icons and alarm state descriptions Alarm icons use a color code to indicate levels of severity. Alarms may trigger different automatic system responses, like failover. Certain intended, manual actions may trigger a notification event, like when you manually start or stop a service. Color codes for alarm and event states: - Alarms - `Alarm red` icon critical - `Alarm yellow` icon major - `Alarm green` icon minor - `Alarm` icon information - States
State Description
raised An alarm is active and triggered. Service may be stopped or the server is down. A backup server may be used if assigned in a failover group
cleared The issue related to the alarm is resolved. This includes restoring services after a failover to a backup server, even if the primary server is down.
## Customize alarm display time The alarm display refreshes automatically every few seconds. By default, all timestamps are shown in Universal Time (UTC), but you can customize the time zone. 1. Click `Gear` icon in the upper right corner. 2. Select **Settings**. 3. In the **General** tab, choose your preferred **Alarm display time zone** from the drop-down list. 4. Click **Save** to apply the changes. ## Types of alarms Different pages are dedicated to specific alarm displays. For example, the **Alarms** page is a centralized alarm overview, the **Service alarms** page displays alarms for the specific service, and the **Failover alarms** page displays alarm and event overviews. ### Alarms page The alarms page centralizes all alarms and events into a table. The Alarms page is a general alarms overview.

See the Service alarms page or the Failover alarms page for specific alarm information.

#### Display all alarms and events The **Alarms** page is an overview of all alarms and events. To access the **Alarms** page you can: - Click **Alarms** on the left-side menu to access all **Active alarms**, **Alarm history** and **Alarm overrides**. ![view active alarms menu](/_machine-assets/1a948c678ed004fd445811420bc51759ba3a21ea75259fb3da2be4d36a8474d2.png) - Click **Services** on the left-side menu then click `Alarm` icon in the **Alarm** column to display alarms for a specific service. The Alarm icon is the color of the active alarm with the highest level of severity. - Use the shortcuts in the top-right corner banner. ![view alarm shortcut header](/_machine-assets/aedf4a92f3a3094e17048a921a5442d0eae384f00f5cdafe14284e0bcd4cabf2.png) You can then use the sort options in the table headers or the search bar to filter on specific alarms, services or servers. #### Display alarm history The alarm history for all alarms displays in a tab in the **Alarms** page.

By default, the alarm history is stored for approximately 7 days, or a maximum of 100,000 alarm events.

1. Click **Alarms** from the left-side menu. 2. Click **Alarm History** to view the history for all alarms. 3. Use the sort options in the table headers or the search bar to filter on specific alarms, services or servers. 4. The **Auto refresh** button can be used to control whether new alarms automatically appear in the table. This can be useful to disable on a busy system to stop the screen scrolling. 5. Click the **Download history** button to download a .csv file containing the alarm history. ### Service alarms page You can access the alarms for a specific service from the **Services** page. An icon in the **Alarms** column indicates that there is at least one alarm for the service. Alarm icons use a color code. The color of the alarm icon in the Alarms column is based on the highest severity alarm known for that service. An alarm status icon displays per service in relation to the alarm with the highest severity for that service. More than one alarm may exist for a single service. #### Display service-specific alarms page The service-specific alarms display in a dedicated page that also displays the alarm history for the service. 1. Display **Services**. 2. Click the alarm icon in the **Alarms** column. The service alarms display. ### Failover alarms page If a failover group exists, then certain critical alarms may trigger a failover. You can check alarms for failover groups, and then drill down to alarms to investigate servers and related services. In the [Failover group page](/beam/system-admin/servers/failover#display-failover-groups), the alarm with the highest severity (in relation to the servers in the failover group) displays in the **Alarm Status** column.

The alarm display is automatically refreshed every few seconds. All time stamps are in Universal Time (UTC).

#### Display failover alarms page The failover alarms page displays alarms and the alarm history for servers in a failover group. 1. Display the **Failover** page from the left-side menu panel. 2. Click the alarm icon in the **Alarm Status** column. The alarms for the failover group display. You can use failover alarms to determine if a server in the failover group has an alarm, and then if there are service alarms for services running on that server. ## Alarm forwarding (SNMP) SNMP alarm forwarding requires you to define a destination where alarms are sent. ### Display the list of SNMP destination configurations 1. Click `Gear` icon in the upper right corner of the window. 2. Select **Settings** then click the **SNMP notifications** tab. The SNMP destinations display. You can use the search options or column filters to browse the SNMP notification configurations. ![view snmp trap destination table list mfmms](/_machine-assets/eacdb048a41bf5358031c5b8bbc2513dd01948ec6ce225509bdbb24f8f3f13c8.png) ### Add a new SNMP destination 1. Click `Gear` icon in the upper right corner of the window then select **Settings**. 2. From the **SNMP notifications** tab, click **Add destination**. The SNMP destination parameters display. 3. Enter the [SNMP parameters](/beam/system-admin/maintenance/parameters#snmp-parameters-settings-menu) to configure the destination and the version.

The parameters that display to edit SNMP destinations depend on the SNMP version.

5. Save settings to return to the list of SNMP configurations. ### Edit SNMP destination configurations 1. Click `Gear` icon in the upper right corner of the window then select **Settings**. 2. From the **SNMP notifications** tab, click `Edit` icon to display SNMP destination parameters. 3. Edit the [SNMP parameters](/beam/system-admin/maintenance/parameters#snmp-parameters-settings-menu) and save.

The parameters that display to edit SNMP destinations depend on the SNMP version.

![view snmp v3 parameters](/_machine-assets/d8f48fc2c332b25de49641b6356399e9cb7400aa4c7b6d086a889688a95933c8.png) _Example of SNMP v3 configuration_ ### Activate/deactivate SNMP notifications 1. Click `Gear` icon in the upper right corner of the window then select **Settings**. 2. From the **SNMP notification** tab, you can activateSNMP notifications either: - tick the **Activate** checkbox from the table where SNMP configurations are listed. - or click `Edit` icon and tick the **Activate** checkbox at the top of the SNMP parameters. ### Delete an SNMP destination server 1. Click `Gear` icon in the upper right corner of the window then select **Settings**. 2. From the **SNMP notifications** tab, click `Delete` icon to delete the SNMP destination configuration. You are prompted to confirm and delete. ## Alarm overrides

The alarm overrides feature requires specific user rights.

You can manually override alarm severity levels. You can also view the alarms that trigger failover. You can filter the alarms using the search bar.

Changing the Triggers failover value impacts the possibility of a failover occurring.

### Override an alarm severity You can change the alarm severity to either critical, major, minor, notice or ignore. The initial default severity displays in the **Alarm overrides** tab if you need to revert to the initial default severity setting. Setting an alarm to "ignore" will exclude that alarm type from displaying in the active and historical alarm views. It will also be excluded from the API responses and SNMP traps. The only evidence of "ignored" alarms will be in log files.

Changes to severity are only applied to future occurrences. Any current or previously existing alarms are unchanged.

1. Click **Alarms** in the left-hand menu panel. 2. Click the **Alarm overrides** tab to display options. The following page displays. ![view alarm overides controller](/_machine-assets/aaa90b80163c526039bdb41037f27cd70437a88ec17004329c4c021ef9301e30.png) 3. Click the **Current severity** for the specific alarm to display options. A list of severity options displays. ![view current severity button alarm override controller](/_machine-assets/7fd008701bfc4863e93ee01844e46c7c7502e0e34520f0a662a45be5cf3018bd.png) 4. Select a severity from the list. The **Current severity** changes.

Changing the severity may increase or decrease the possibility of failover occurrence.

``` ![view alarm override select severity controller](../images/view_alarm_override_select_severity_controller.png) ``` ### Reset the alarm severity to the default setting Alarm severity can be manually changed. You can reset the alarm severity to the default setting. Changing the **Triggers failover** value impacts the possibility of a failover occurring.

Changes to severity are only applied to future occurrences. Any current or previously existing alarms are unchanged.

1. Click **Alarms** in the left hand menu. 2. Click the **Alarm overrides** tab to display options. 3. Click the **Default severity** for the specific alarm to display options. A list of severity options displays. 4. Select a severity from the list. The **Default severity** changes.

Changing the severity may increase or decrease the possibility of failover occurrence.

## Events Events are displayed in the **Alarms** page. Events notify you of actions that do not impede proper functioning. Example of an event when you intentionally start or stop a service: ![view active alarms menu table](/_machine-assets/2c153cf0ce76d741d86015c8b99fb57410dbb76d01e5f9c91bc3adb44beef8cd.png) # Backup and restore Backups include services, templates,failover groups,server definitions and locally defined users. You can back up your configurations to restore a previous configuration (for upgrades or rollbacks or after a server crash, etc.)

The access to configurations is blocked while a backup or restore is in progress. Up to 30 backup files are supported for local backups. The oldest backup is deleted once 30 backups are detected.

The database backup operation is supported; but copying the exported database and restoring it onto another MK.IO Beam server is not supported.

## Backup database configurations Create a backup of MediaKind configurations to save a version locally or on a remote server. ### Display backup MediaKind database options Back up the MediaKind configuration to a local or remote server. Backups include services, servers, templates and users. Backups are time-stamped. 1. Click `Gear` icon in the upper-right corner of the screen. The **System Center** menu displays. 2. Select **Backup**. The Backup Controller Database options display. ### Create a local backup Local backups of MediaKind settings are still accessible even when no remote access is possible. Backups only include the list of servers, services, templates and user configurations. 1. [Display backup options](/beam/system-admin/maintenance/backup-restore#display-backup-mediakind-database-options). **Local Backup** is selected by default. ![view backup db remote mfvp controller](/_machine-assets/7e170c8e6a74d2b09228b97fe3790984671b2be9bf44b2b8370d56653d9b9834.png)

The Host, Port and Path are only required for a remote backup. FTPS is also authorized.

2. Click **Backup now**. The backup is stored on the local drive. ### Create a remote backup Create remote backups to restore MediaKind settings from a remote server using FTP or FTPS. 1. [Display backup options](/beam/system-admin/maintenance/backup-restore#display-backup-mediakind-database-options). 2. Select **Remote backup**. [Required fields](/beam/system-admin/maintenance/parameters#backup-parameters) are highlighted. 3. Enter the required remote backup settings information.

FTPS is also authorized.

``` ![view backup db remote mfvp controller](../images/view_backup_db_remote_mfvp_controller.png) ```

Editing the backup file storage location impacts scheduled backups.

4. Click **Backup Now**. 5. Click **Save and exit** to save your changes. ### Schedule an automatic backup (periodic) Set a schedule to back up the MediaKind database on a regular basis: weekly, daily or hourly. Backup guard times may impact backup availability. 1. [Display backup options](/beam/system-admin/maintenance/backup-restore#display-backup-mediakind-database-options). 2. Select the **Scheduled Backup** tab to define the scheduled backup. 3. Select the **Enable scheduled backup** checkbox. 4. Select the backup schedule time (hourly, weekly, daily and so on).

The time stamp is based on the current time on the Controller server.

``` ![view scheduled backup db remote mfvp controller](../images/view_scheduled_backup_db_remote_mfvp_controller.png) ``` 5\. Open the **Backup Location** tab to set the backup file storage settings, if they are not currently configured. 6\. Click **Save and exit** to save your changes. ### Download the Controller database file This tab enables users to download the Controller database file. This file includes Services, Servers, Templates, Failover Groups and Users and indicates the backup of the Controller database at the time stamped date. 1. [Display backup options](/beam/system-admin/maintenance/backup-restore#display-backup-mediakind-database-options). 2. Select the **Download File** tab to download the Controller database file. 3. Select **Local Backup** to download the locally backed up database.

Downloading remote backups is not currently available.

4. Use the **Year/Month/Backup** drop down lists to select the backup instances to download, as follows: 1. From the **Year** drop down list, select the year when the required backup was created. 2. From the **Month** drop down list, select the month when the required backup was created. 3. From the **Backup** drop down list, select the required backup which includes the time stamp with the time and date. ![view download file db remote mfvp controller](/_machine-assets/905f5ca52b30f55cc83d238e99dc444942de978db3626ba307080c3e721ddc8b.png) 5. Click **Download Now** to begin downloading the file locally. 6. Click **Save and exit** to save your changes. ## Restore configurations Restore configurations for recovery or troubleshooting. You must have already created a local or remote backup in order to restore. Backups are selected based on the backup time stamp.

The Database is inaccessible until the restore completes. Only one restore can be launched at a time. Alarms and statistical data are not restored because they are dynamic. The alarms banner is not displayed until the restore completes.

### Display restore options You can restore the MediaKind database configuration from existing local or remote backups. 1. Click `Gear` icon in the upper-right corner of the screen. The **System Center** menu displays. 2. Select **Restore**. The Restore Controller Database page displays. ### Restore configurations from a remote backup 1. [Display restore options](/beam/system-admin/maintenance/backup-restore#display-restore-options). 2. Select **Remote Backup**. 3. Select a **Year** > **Month** > **Backup**.

Available backups are time-stamped. Be aware of backup guard time configurations to ensure availability.

``` ![view restore mfvp controller](../images/view_restore_mfvp_controller.png) ``` 4\. Click **Restore**. The Controller is unavailable to all users until the restore completes. ### Restore configurations from a local backup 1. [Display restore options](/beam/system-admin/maintenance/backup-restore#display-restore-options). **Local Backup** is selected by default. ![view restore mfvp controller](/_machine-assets/d33f764b3a162f4f201dcff6656f23d9ad56acf84e70a229b201a540d35388a5.png) 2. Expand the **Backup** drop-down list to display available backups, then select a backup to restore.

Available backups are time-stamped. Be aware of backup guard time configurations to ensure availability.

3. Click **Restore**. All users are temporarily assigned to the [Monitoring user group](/beam/system-admin/security/user-management#user-group-permissions) until the restore completes or is terminated. # Generate a Support Package A Support Package contains files that allow MediaKind support to recreate your system configuration for testing and troubleshooting. On MK.IO the same process is called **Collect device logs**. If the server is managed through MK.IO, you can also generate a Support Package from the MK.IO UI using [Collect device logs](/mkio/how-to/managing-edge-devices/support-packages). That flow runs from the cloud, so you do not need direct LAN or VPN access to the server, and it emails you a download link which can be forward to support.

Downloading a Support Package from the Servers page is not supported using Access remote UI. To generate a Support Package through MK.IO, use Collect device logs.

## Generate a Support Package from the server UI 1. Go to **Servers** and select a server. 2. In the **Actions** column, click `Package` icon to open the **Support Package generation** page. 3. Adjust the selection marks next to the collectors to control what the package contains. By default all collectors run. 4. Click **Generate** to create a new Support Package. 5. Click **Download** to save a copy of the Support Package. The Support Package Generator creates compressed tar files in the most widely accepted (POSIX-PAX) format.

Open the file with a compliant utility such as 7-Zip (at least v21.07), WinRAR, or Linux tar. Other tools may corrupt the filenames.

## Collect a Dell SupportAssist Collection

Generating a Dell SupportAssist Collection with the collect_dell_support_assist.sh script is available in Beam 1.9 and later.

A Dell SupportAssist Collection is a hardware diagnostic bundle gathered from the server's iDRAC. Collect it when you need deeper hardware-level diagnostics than the standard Support Package provides, for example when investigating a suspected hardware fault with Dell or MediaKind support.

In Beam 1.9 and later, the SupportAssist Collection is included automatically in the Host collector of the Support Package, so you do not need to run this script separately.

### Generate a Dell SupportAssist Collection Run the `collect_dell_support_assist.sh` script on the server over SSH, then copy the resulting zip file to your workstation. ### Connect to the server Connect to the server over SSH as a user with `sudo` privileges. ### Run the collection script Run the script as root. The script clears the iDRAC job queue, accepts the SupportAssist EULA, collects the logs from the iDRAC, and exports them to a zip file. Collection can take several minutes. ```shell copy sudo collect_dell_support_assist.sh ``` The script accepts the following options: - `--output-file `: output file path. Defaults to `/tmp/dell_supportassist.zip`. - `-h`, `--help`: display help and exit. If the export fails, the iDRAC may be in a state where it cannot start new jobs or copy collections; in this case, answer `y` at the interactive prompt, to reset the iDRAC and retry. The reset itself takes a few minutes. ### Copy the collection off the server From your workstation, use `scp` to copy the zip file off the server: ```shell copy scp mfeng@:/tmp/dell_supportassist.zip . ``` Adjust the source path if you used `--output-file`. You can then attach the zip file to your support case. # Configure health monitoring and remote metrics ## Enable/disable health monitoring Health monitoring is enabled in MK.IO Beam by default. If required, it can be disabled to free up server resources. To enable/disable health monitoring: 1. Log in as a user with Administrative privileges. 2. Click `Gear` icon in the upper right corner of the window. 3. Select **Settings.** 4. Under the **General** tab, check or uncheck the **Enable health monitoring features** checkbox as required.

Disabling health monitoring will also disable the remote metrics feature.

## Configure remote metrics To configure the MK.IO Beam device to push metrics to a remote Grafana endpoint, SSH into the server and execute the `configure_prometheus.sh enable` command, specifying the following parameters: - `-–username ` defines the username for the endpoint of the Grafana instance. - `-–password ` defines the password for the endpoint of the Grafana instance. - `-–remoteurl ` defines the URL for the endpoint of the Grafana instance. - `-–env ` defines the name of the node/machine. If not specified, the hostname is used. - `-–zone ` defines the location zone for the node/machine.

This step will need to be repeated after upgrading the MK.IO Beam software.

## Disable remote metrics To disable remote metrics, execute the `configure_prometheus.sh disable` command. The following commands are also available: - `configure_prometheus.sh show-secret` displays the stored username and password for the Grafana endpoint. - `configure_prometheus.sh update-secret` update the stored username and password for the Grafana endpoint. - `-–username ` defines the username for the endpoint of the Grafana instance. - `-–password ` defines the password for the endpoint of the Grafana instance. - `configure_prometheus.sh show-remoteurl` displays the stored URL for the endpoint of the Grafana instance. If any of the `remoteurl`, `env` or `zone` parameters need to be updated after remote metrics has been enabled, remote metrics must be disabled first. Then enable remote metrics again, passing in the updated parameter values. ## Usage examples How to enable remote metrics using a defined username, password, and URL for Grafana. The username and password are stored in a Kubernetes secret: - `configure_prometheus.sh enable --username myuser --password mypassword -–remoteurl https:///api/prom/push` How to disable remote metrics and delete the secret: - `configure_prometheus.sh disable` How to update the secret without disabling remote metrics: - `configure_prometheus.sh update-secret --username myuser --password mypassword` # Manage alarms When the feed is running: - If no alarm is raised, you should have the following: ![ce1 channel playing noAlarm](/ce1-img/ce1_channel_playing_noAlarm.png) - If one or more alarms are raised, a color alarm indicator along the top of the feed is shown. The alarm indicator takes the color of the active alarm with the highest level of severity. You can click the alarm icon on each component to go to the alarms page for that component. ![ce1 channel alarms critical](/ce1-img/ce1_channel_alarms_critical.png)

If you select a component, you will access the related alarm page that will display the active alarms and the alarm history.

## Show alarms in local time Alarm times can be displayed in local time instead of UTC. To configure this, click `Gear` icon in the top right corner then select the **Settings** menu. From the **General** tab, set the **Alarm display time zone** to the required time zone. ![alarms local](/ce1-img/alarms-local.png) # Configuration parameters ## Backup parameters
Parameter Description
Host Remote server hostname or IP address.
Port IP Port for the secure FTP or FTPS connection.
Possible values: 1 to 65535
Recommended value: 21
Path Backup file storage directory on the remote server. This path is a relative path, and must exist on the remote server.
Possible values: 128 characters max
Username For the secure FTP connection. Must be a valid secure FTP or FTPS server user.
Possible values: 16 characters max
Password Allows the configured username to connect to the secure FTP server.
Possible values: 16 characters max
**Related information**\ [Backup and restore configurations](/beam/system-admin/maintenance/backup-restore) ## Failover parameters
Parameter Description
Group name Enter a unique failover group name for your selected primary and backup servers.
Failover level Whether this failover group should act at server or service level.
Group processing type Select the processing type to display compatible servers.
Group mode In Automatic mode, the system triggers a server failover when a critical alarm occurs (manual triggers are still possible).
**Related information**\ [Create a failover group](/beam/system-admin/servers/failover#create-a-failover-group) ## SNMP parameters (Settings menu) ### Destination properties
Parameter Description
Active activate the SNMP notification to this destination.
Notification type Type of SNMP message (Traps and Inform messages).
Name The name of the SNMP notification configuration (up to 64 characters)
IP address IP Address for the SNMP destination server (Hostnames and FQDNs are not supported).
Example: 192.168.1.1
Port Port used to send SNMP notifications.
Range: 0-65535
Version Select the SNMP version to use.
### Version Properties (2c)
Parameter Description
Community name Define the community that SNMP notification uses.
### Version properties 3
Parameter Description
Mode Select authorization and privacy settings.
Options:
- authNoPriv (authentication but no encryption)
- noAuthNoPriv (no authentication and no encryption)
- authPriv (authentication and encryption)
Note: The Version properties for version 3 vary depending on the Mode.
Security Name Name you want to give this security property.
Authorization algorithm Select the hash-based algorithm.
Options: HMAC-SHA HMAC-MD5
Authorization key Key for the authorization.
Encryption algorithm Select the type of encryption.
Encryption key Key for the encryption.
**Related information**\ [Alarm forwarding (SNMP)](/beam/system-admin/maintenance/alarms-events#alarm-forwarding-snmp) ## Router parameters ### Router Properties
Parameter Description
Name The name used to identify the router.
IP Address The IP address of the router. This field must be unique.
Username The username used to login to the router via telnet.
Password The password used to login to the router via telnet.
Type The type of router being added to the system.
Possible values: Panacea, Platinum or Nevion.
### Input Labels
Parameter Description
Input Count The number of input connectors on the router. This will alter the amount of input labels you are able to specify.
Label The user-defined useful label for inputs to the router.
Important: The label must match the Input label referred to in the Live Encoder service Input tab.
### Output Connections
Parameter Description
Output Count The number of output connectors on the router. This will alter the amount of output connections you are able to specify.
Server Name The name of the server. This name must match an Live Encoder server from the server list.
Server Board The SDI board in the server.
Important: This must match the SDI card number in the Live Encoder service.
Board Connector The connector on the SDI board. Important: This must match the Connector in the Live Encoder service.
**Related information**\ [Router configuration](/beam/system-admin/network/router-configuration) # Enable or Disable Processing Types To optimize resource utilization on a Beam unit, especially on lower-spec units, you can enable or disable certain processing types. Disabling unused functionalities can free up RAM and CPU, improving throughput for the tasks you are running. The specific processing types available for configuration may change over time as the Beam platform evolves. ## How to change processing types To enable or disable a processing type: 1. Click **Servers** in the left panel to see the list of units in your cluster. 2. For the desired unit, click the **detail** `View` icon button in the **Actions** column. 3. Locate and select or deselect the checkboxes for the processing types you want to enable or disable. These are listed under **General Parameters**. 4. Click **Save** to apply the changes. # Service settings You can access additional menus from the **Settings** menu. This menu only displays if Packager, Stream Conditioning or Live Encoder products are used. ## Stream Conditioning menus - Stream Conditioning variables ## Live Encoder menus - [Nielsen archiving](/beam/system-admin/maintenance/service-settings#enable-nielsen-log-archiving) (only available in container mode) - [Live service lineup](/beam/system-admin/maintenance/service-settings#live-service-lineup) ## Enable Nielsen log archiving When enabled, Nielsen watermarking logs are sent using an SFTP server. Watermarking is enabled from the Live Encoding service: **Media processing** > **Audio Processing** > **Watermarking** > **`Edit` icon** > **Insertion** > **Enable**. 1. Select **Settings** from the left-side menu panel to expand and display menu options. 2. Select **Nielsen archiving** from the drop-down menu list. The **Archiving** options display. 3. Select the check box to enable Nielsen archiving. 4. Enter parameters for the SFTP server.

Certain parameters are Nielsen provided and must be registered with Nielsen. See parameter glossary for details.

## Live service Lineup The lineup file describes a list of sources (including all the parameters needed to capture the source i.e. multicast address and port, input streams, …) to be used with the Media composer input. This configuration is unique per controller and is used by all the Live Encoder services. To import the lineup configuration file, follow these steps: 1. Select **Settings** from the left-side menu panel to expand and display menu options. 2. Select **Live service lineup** from the drop-down menu list. The **Live service lineup** options display. 3. You can either create a new service lineup or import an existing one. - To create a new service lineup, click **Add** then [enter and/or select the appropriate value for each parameter](/beam/live-encoder/parameters/lineup). ![UDP lineup file configuration"](/_machine-assets/203bc6166e2950db933f49a9ab79a428bd2f277dbbccba5e446d01332b0a6af0.png "Example of an MPEG-2 TS/UDP lineup file configuration") ![live servicelineup view st2110](/_machine-assets/3f3160796fe50b166a6123bd585312c9f7077af3a03553fc48593f8d998e08bf.png "Example of an SMPTE ST 2110 lineup file configuration") - To import an existing service lineup, click **Import** then browse to select a service lineup (json file). 4. In the **Actions** column, you can click the `Edit` icon button to display each service lineup parameters. 5. You can export an existing service lineup: - You can either click the **Export** button then copy/paste the json file. - Or right-click the **Export** button then select the **Save link as** option and browse to select a location. # Set up SDI/ASI cards ASI/SDI cards can be configured for different modes of operation. For example, if there are two 4-port ASI/SDI cards in the same chassis, one card can be configured for SDI/ASI output and the other card for HD or UHD SDI input. ## Set up a 4-port SDI/ASI card The following three modes are supported. #### 4 ASI/HD-SDI/SD-SDI - 4 independent 3G-SDI/ASI ports. Each port can be either SDI or ASI, input or output. Use this mode for 4 independent SDI/ASI ports, each of which can be an input or an output. #### 1 UHD 12G or Quad Link 3G - Port 1 SDI input/output (up to UHD 12G-SDI) or ASI input/output, **or** - Ports 1-4 SDI input/output for Interleaved mode for UHD. For contribution or headend use cases, use this mode for UHD SDI input. For reception use cases, use this mode for UHD SDI output. #### 1 UHD 12G with downconversion This mode is not recommended for contribution or headend use cases. For reception use cases, use this mode for UHD SDI output with downconversion. ## Set up an 8-port SDI/ASI card The following three modes are supported. #### 8 ASI/HD-SDI/SD-SDI - 8 independent 3G-SDI/ASI ports. Each port can be either SDI or ASI, input or output. Use this mode for 8 independent SDI/ASI ports, each of which can be an input or an output. #### Dual 4K channels over 12G-SDI or Quad link - Port 1 SDI input/output (up to UHD 12G-SDI) or ASI input/output, **or** - Ports 1-4 SDI input/output in Interleaved mode for UHD. - Port 5 SDI input/output (up to UHD 12G-SDI) or ASI input/output, **or** - Ports 5-8 SDI input/output in Interleaved mode for UHD. For contribution or headend use cases, use this mode for UHD SDI input. For reception use cases, use this mode for UHD SDI output. #### Dual 12G-SDI with ASI/SDI side channel This mode is not recommended for contribution or headend use cases. For reception use cases, use this mode for UHD SDI output with ASI/SDI output side channel. ## To set the mode of operation of an SDI/ASI card 1. From the MK.IO Beam web UI, select the **Appliance** tab. 2. Select the **ASI/SDI interface** tab. 3. Select the **Slot** tab corresponding to the SDI/ASI card. If more than one card is present, there will be a separate slot tab for each card. 4. Select the **ASI/SDI mode** from the drop-down menu. - [Configure Network Interfaces](/beam/system-admin/network/configure-nics): How to configure network interfaces, static routes, DNS, time synchronization, IGMP settings, and bonded interfaces on an MK.IO Beam device. - [Control Interface Wizard](/beam/system-admin/network/control-interface-wizard): Use the control-wizard command-line tool to configure the Control network interface, set an HTTP proxy, and diagnose connectivity. - [Configure Bonded Interfaces](/beam/system-admin/network/bonded-interfaces): How to configure active-backup bonded interfaces for network redundancy on a Beam device using the command line. - [Configure VLAN Interfaces](/beam/system-admin/network/vlan-interfaces): How to add and delete VLAN interfaces on a Beam device from the UI or command line. - [Configure Jumbo Frames](/beam/system-admin/network/jumbo-frames): How to enable jumbo frames on MK.IO Beam network interfaces by setting the Maximum Transmission Unit (MTU). - [Configure System Clock](/beam/system-admin/network/system-clock) - [Configure Routers](/beam/system-admin/network/router-configuration) # Configure Bonded Network Interfaces You can configure bonded network interfaces for redundancy from the command line. The following instructions show how to create an active-backup bond, which keeps one interface active and the other as a passive backup. If the active interface fails, the backup interface takes over automatically. The example commands use the two 1G onboard NICs available on the E50 and E60 servers (`eno8303` and `eno8403`), and assume that the `eno8303` interface is already configured and working as the management interface. Run these commands using SSH or directly on the terminal. ### Create the bond interface In this example, `bond0` is the name of the bond interface being created. ```shell copy sudo nmcli connection add type bond con-name bond0 ifname bond0 bond.options "mode=active-backup" ``` ### Add the slave interfaces In this example, `eno8303` and `eno8403` are added as slave interfaces. ```shell copy sudo nmcli connection add type ethernet slave-type bond con-name bond0-eno8303 ifname eno8303 master bond0 sudo nmcli connection add type ethernet slave-type bond con-name bond0-eno8403 ifname eno8403 master bond0 ``` ### Configure the IP address of the bond interface The bond interface IP address can be allocated via DHCP or assigned statically. - To use DHCP: ```shell copy sudo nmcli connection modify bond0 ipv4.method auto ``` - To assign a static IP address, use the values currently assigned to `eno8303`. For example: ```shell copy sudo nmcli connection modify bond0 ipv4.addresses 192.168.1.42/24 ipv4.gateway 192.168.1.1 ipv4.dns "192.168.1.99,192.168.1.98" ipv4.method manual ``` ### Activate the bond interface ```shell copy sudo nmcli connection down eno8403 && sudo nmcli connection down eno8303 && sudo nmcli connection up bond0 ``` ### Disable the non-slave connections Disabling non-slave connections prevents them from conflicting with the bond at reboot or after an upgrade. ```shell copy sudo nmcli connection modify eno8403 ipv4.method "disabled" ipv6.method "disabled" connection.autoconnect no sudo nmcli connection modify eno8303 ipv4.method "disabled" ipv6.method "disabled" connection.autoconnect no ``` ### Configure the firewall

Firewall zone for bonded interfaces can be set on the UI in Beam 1.9 and later. See Configure network interfaces.

- For bonded management ports, set the firewall zone to `control`: ```shell copy sudo nmcli connection modify bond0 connection.zone control && sudo nmcli connection up bond0 ``` - For bonded data ports, set the firewall zone to `data`: ```shell copy sudo nmcli connection modify bond0 connection.zone data && sudo nmcli connection up bond0 ``` The bonded network interface configuration persists on reboot and upgrade when you follow the instructions above. Rebooting after configuration is recommended to confirm that networking continues to function after a reboot or power failure. # Configure network interfaces You can configure network settings from the **System Settings** tab on the server information page: 1. Go to the **Servers** view. 2. Click the **Details** `View` icon button to open the server information. 3. Go to the **System Settings** tab.

Changes to network interface configuration can result in the device becoming unreachable.

## Set the hostname 1. Enter the new hostname in the **Hostname** field. 2. Click **Save** at the bottom of the page. ## Set IP addresses, subnet masks, gateway address, DHCP, and firewall zone 1. Go to the **Network devices** section on the **System Settings** page. 2. Click the **Edit** `Edit` icon button next to an interface to open its settings. 3. Enable or disable **DHCP**. When DHCP is enabled, the interface IP address and DNS servers are allocated automatically. DHCP-allocated values cannot be edited and are shown for reference only. 4. If DHCP is disabled, enter the IP address and subnet mask in the **Addresses** field using CIDR notation. 5. Optionally, enter the default gateway in the **Gateway** field. 6. Optionally, enter a value in the **Gateway metric** field. Usually this is left blank. 7. Optionally, set the firewall zone in the **Firewall zone** field. Valid values are **control**, **data**, or **control & data (public)**. 8. Click **Confirm**, then click **Save** at the bottom of the page.

While you can configure multiple default gateways, this can cause routing issues and should be done with caution. If you define multiple gateways, ensure the Control interface has the lowest gateway metric. In most cases, adding a static route is the recommended way to achieve the desired routing.

## Configure static routes

Configuring static routes and gateway metric is possible in Beam 1.9 and later.

You can add static routes to an interface to direct traffic for specific subnets through a particular gateway. This is often a better alternative to configuring multiple default gateways. 1. In the **Network devices** section, click the **Edit** `Edit` icon button for the interface you want to configure. 2. In the **Edit Network Device** dialog, in the **Static routes** section: - To **add** a route, click **+ Add route**. Enter the **Destination (CIDR)** and **Gateway**, then click **Add Route**. - To **edit** a route, click the **Edit** `Edit` icon button next to it. - To **delete** a route, click the **Delete** `Delete` icon button next to it. 3. Click **Confirm** in the **Edit Network Device** dialog. 4. Click **Save** at the bottom of the **System Settings** page to apply the changes. ## Set DNS addresses 1. Go to the **DNS** section on the **System Settings** page. 2. Click the **Edit** `Edit` icon button next to an interface to open its DNS settings. 3. If DHCP is disabled, add at least one DNS server in the **Addresses** field using CIDR notation. DNS servers allocated by DHCP cannot be edited and are shown for reference only. 4. Click **Confirm**, then click **Save** at the bottom of the page. ## Set IGMP version 1. Go to the **IGMP mode** section on the **System Settings** page. 2. From the drop-down, select **Automatic v2/v3** or **Force v2**. 3. Click **Save** at the bottom of the page. ## Set time synchronization See [Configure System Clock](/beam/system-admin/network/system-clock). ## Configure bonded interfaces To configure active-backup bonded interfaces for redundancy from the command line, see [Configure Bonded Network Interfaces](/beam/system-admin/network/bonded-interfaces). # Control Interface Wizard (`control-wizard`) The `control-wizard` is a command-line tool for network configuration on a Beam device. It provides a text-based wizard to configure the primary _Control_ interface, set up an HTTP proxy, and diagnose connectivity issues. This tool is especially useful during the initial setup of a device before the web UI is accessible, or for troubleshooting network problems directly from the terminal. ## Aliases For convenience, you can use shorter commands: - `cw` is an alias for `control-wizard`. - `cs` is an alias for `control-wizard --status`, which runs the wizard in a read-only monitoring mode. ## When to use the wizard You can use the `control-wizard` to: - Set the IP address for the _Control_ interface during initial device setup. - Configure an HTTP proxy if one is required to connect to MK.IO. - Diagnose network connectivity problems from the terminal. - View a real-time display of network interface status. ## Configure the Control IP Address During the initial quick start, if the device has not obtained an IP address via DHCP, you must use `control-wizard` to set one manually. 1. Log in to the terminal with the default credentials. 2. Type `control-wizard` (or `cw`) and press Enter. 3. Follow the on-screen prompts to configure the IP address, subnet mask, and gateway for the _Control_ interface. ## Configure an HTTP Proxy If the device requires an HTTP proxy to reach the internet to connect to MK.IO, you can configure it from the wizard. ### Open the proxy configuration 1. Log in to the device's terminal. 2. Run the `control-wizard` command. 3. Press **P** to configure a proxy. ### Enter proxy details 1. Enter the **Proxy IP Address**, **Port**, **Username**, and **Password** when prompted. 2. Press **Enter** to apply the settings. ### Verify and quit 1. The wizard automatically tests the proxy settings, and the results are displayed on screen. 2. Press **Q** to quit the wizard. ## Diagnose and View Network Status (`cs`) The `cs` command provides a read-only, real-time view of network status, which is useful for diagnosing connectivity issues and monitoring interface state. It is an alias for `control-wizard --status`. When you run `cs`, it displays both the connectivity status to the MK.IO API and the state of local network interfaces, including IP addresses and traffic. This is a useful first step when troubleshooting on-boarding issues. To use the status viewer, type `cs` in the terminal and press Enter.

Running the full control-wizard (or cw) for configuration also shows the MK.IO API connectivity test on startup.

# Configure Jumbo Frames Jumbo frames are Ethernet frames with a payload larger than the standard 1500 bytes. Using jumbo frames can improve network performance for high-bitrate video streams by reducing the overhead of packet headers. A common jumbo frame size is 9000 bytes. To use jumbo frames, you must set the Maximum Transmission Unit (MTU) on the network interfaces of your Beam device. You can configure the MTU using the web UI or the command line.

Jumbo frames only work if all devices on the network path, including switches and routers, are configured to support them.

## Configure MTU using the UI

Editing MTU on the UI is available in Beam 1.9 and later.

You can set the MTU for a network interface from the **System Settings** page. 1. Navigate to **Servers**, select a server, and go to the **System Settings** tab. 2. In the **Network devices** section, click the **Edit** `Edit` icon button for the interface you want to configure. 3. In the **Edit Network Device** dialog, enter the desired MTU value (e.g., `9000`) in the **MTU** field. 4. Click **Confirm**. 5. Click **Save** at the bottom of the **System Settings** page to apply the changes. ## Configure MTU using the command line To set the MTU from the command line, run the following `nmcli` command. Replace `ens259f2` with the name of the interface you are configuring. ```shell copy sudo nmcli connection modify ens259f2 802-3-ethernet.mtu 9000 ``` # Router configuration The **Router settings** window enables users to configure the router parameters by establishing the connection and control of the SDI Router. This is performed by setting the input labels and using these labels to map the inputs for the Live Encoder services. The output connections must be configured to map the router outputs to the input SDI ports of the encoder servers. ## Display the router configuration settings 1. Click `Gear` icon to display the system center menu. 2. Click **Settings** > **Router settings**. The **Router settings** display. ![router display](/_machine-assets/a9740c0b9682716144adc14f932e56f5616e859b7d2a703118f837b8fd10fb1a.png) ## Add a new router configuration 1. Click `Gear` icon to display the system center menu. 2. Click **Settings** > **Router settings**. The **Router settings** display. 3. Click **Add router**. The **Router Configuration** parameters display. 4. Enter the parameters to configure the router.

For more details on the parameters below, see Router parameters.

``` ![view router configuration](../images/view_router_configuration.png) ``` 5\. Click **Create** to save the configuration and return to list of routers. ## Edit an existing router configuration 1. Click `Gear` icon to display the system center menu. 2. Click **Settings** > **Router settings**. The **Router settings** display. 3. Click `Edit` icon to edit the router configuration.

For more details on the parameters below, see Router parameters.

``` ![router edit](../images/router_edit.png) ``` 4\. Click **Update** to save the configuration and return to list of routers. ## Import a router configuration 1. Click `Gear` icon to display the system center menu. 2. Click **Settings** > **Router settings**. The **Router settings** display. 3. Click **Import router**. The **Import Router** display appears, enabling you to import a router configuration file (yaml) from another system. ![import router](/_machine-assets/fddd74413a503e50ad4c19580aab7c3427aa521e2df5338f933dd938894ee08c.png) 4. Click **Select file**. 5. Select the required file then click **Open**. The file appears in the **Import Router** window. ![import router json](/_machine-assets/b67e754f34ee2be777a66e3ca72c9b48643af80fc4a16c8084b935c66c782b6b.png) 6. Click **Import**. The imported file displays in the list in the **Router settings** tab. ## Export a router configuration 1. Click `Gear` icon to display the system center menu. 2. Click **Settings** > **Router settings**. The **Router settings** display. 3. Click `Download` icon. The **Downloads** window display appears showing the location of the exported router from which can now be used in another system. ## View router crosspoints 1. Click `Gear` icon to display the system center menu. 2. Click **Settings** > **Router settings**. The **Router settings** display. 3. Click `View` icon. The **Router Crosspoints** display, showing the crosspoints set on the router. 4. Select the **Show uncontrolled** checkbox to view the state of the entire router, including the inputs and outputs that have not been labelled or connected. 5. Toggle between Auto **refresh** and **No refresh** to enable or disable an automatic refresh. ![router crosspoints](/_machine-assets/f35f1429c06c6d3eb2abd10c35b7680cbba3934c06e97f1963f2fafef58bee99.png) 6. Click **Back** to return to **Router settings** tab. # How to configure the system clock The system clock is used by all the applications on the unit as both a time reference for different functional operations such as application of Over Air Commands, but also for recording log entries and events. To confirm events and logs are synchronized across a system it is often desirable for customers to synchronize the system clocks of all units within the system to a known reference clock. Where all the units are co-located or where all units have access to a reliable ethernet connection the synchronization is often performed using an NTP source. Where units are remote, or a network connection is not reliable, it is possible to synchronize the system using the TDT within the transport stream. ## Operating modes The following **Time Source** operating modes can be configured from the **System Settings** page on the web UI. ``` - Free running - NTP - PTP - TDT ```

All services and functions running on the server use a single system clock and will be affected by the system clock setting.

### Free running The time is set on the unit when the server is manufactured. The system clock will continue to increment based on the clock accuracy of the motherboard clock within the unit. ### NTP When set to NTP and a valid IP address of an NTP server has been configured, the server will attempt to adjust the system clock to be aligned to the time provided by the NTP messages. If no valid NTP messages are received or if the messages stop after a period of time, the unit will free run from its current time. If the unit was previously adjusting, this adjustment will be stopped until valid NTP messages are resumed. ### PTP When set to PTP, the device will synchronize its system clock with a PTP Grand Master. ### TDT When set to TDT and a service has been selected containing a valid TDT component, the unit will attempt to adjust the system clock to be aligned to the time provided in the TDT. Operation of locking the system clock to the incoming TDT is the same as for NTP. See Select the TDT source. ## Initial status and set up ![clock initial status](/rx1-img/clock-initial-status.png) ## Select the TDT source - Go to the **Time sources** section on the **System Settings** page. - Select the **TDT** tab. - Select the **Service name** from the drop-down menu. - To set TDT as the time source, click on the **Make active** button, then click the **Save** button at the bottom of the page to save the change. ## Configure NTP servers - Go to the **Time sources** section on the **System Settings** page. - Select the **NTP** tab. - To add a new NTP server, click **+ Add NTP server** then enter the NTP server's IP address in the **Address** field then click **Confirm.** - To update the IP address of an existing NTP server, click the **Edit** `Edit` icon button next to that server, then update the IP address in the **Address** field. - Confirm the changes by clicking on **Confirm,** then to save the changes, click the **Save** button at the bottom of the page. - To set NTP as the time source, click on the **Make active** button, then click the **Save** button at the bottom of the page to save the change. ## Configure PTP synchronization - Go to [Configure PTP for ST-2110](/beam/contribution/how-to/setup-smpte-2110-input#configure-ptp-for-st-2110) ## Set up the system to operate in Free Running Mode - Go to the **Time sources** section on the **System Settings** page. - Select the **Free Running** tab. - Click the **Disable time synchronization** button, then click the **Save** button at the bottom of the page to save the change. ## Clock Detection ![clock detection](/rx1-img/clock-detection.png) ## Clock Synchronization ![clock synchronization](/rx1-img/clock-synchronization.png) # Configure VLAN Interfaces VLANs (Virtual LANs) allow you to segment your network by isolating traffic into different broadcast domains on the same physical network infrastructure. You can add and delete VLAN interfaces on your Beam device from the web UI or the command line.

Configuring VLANs from the UI is available in Beam 1.9 and later.

## Configure VLANs using the UI You can add, edit, and delete VLAN interfaces from the **System Settings** page. To rename an interface or change its VLAN ID or parent interface, you must add a new interface and delete the old one. ### Add a VLAN interface 1. Go to **Servers**, select a server, and open the **System Settings** tab. 2. In the **Network devices** section, click **+ Add VLAN interface**. 3. In the **Add VLAN Interface** dialog, select the **Parent Interface** and enter the **VLAN ID**. 4. Click **Add VLAN interface**. The new interface appears in the list. 5. Configure its settings, such as IP address and firewall zone. See [Configure network interfaces](/beam/system-admin/network/configure-nics) for details. 6. Click **Save** at the bottom of the page to apply the changes.

The new interface is automatically named in the format <parent_interface>.<vlan_id>, for example, eth1.100.

### Delete a VLAN interface 1. Go to **Servers**, select a server, and open the **System Settings** tab. 2. In the **Network devices** section, find the VLAN interface you want to remove and click its **Delete** `Delete` icon button. 3. In the confirmation dialog, click **Yes, delete it!**. 4. Click **Save** at the bottom of the page to apply the change. ## Configure VLANs using the command line To manage VLANs from the command line, use the `nmcli` tool. Run these commands using SSH or directly on the device terminal. ### Add a VLAN interface ### Create the VLAN interface Create the VLAN interface with the `nmcli connection add` command. You must specify a connection name, an interface name, the VLAN ID, and the parent physical device. - `con-name`: A descriptive name for the connection, for example `vlan10`. - `ifname`: The name for the new VLAN interface, for example `eth0.10`. - `id`: The VLAN tag number, for example `10`. - `dev`: The parent physical interface, for example `eth0`. This example creates a VLAN with ID 10 on the `eth0` interface: ```shell copy sudo nmcli connection add type vlan con-name vlan10 ifname eth0.10 id 10 dev eth0 ``` ### Configure the IP address After creating the interface, configure its IP address. You can use DHCP or assign a static IP. - **To use DHCP:** ```shell copy sudo nmcli connection modify vlan10 ipv4.method auto ``` - **To assign a static IP address:** ```shell copy sudo nmcli connection modify vlan10 ipv4.addresses 192.168.10.50/24 ipv4.gateway 192.168.10.1 ipv4.method manual ``` ### Configure the firewall zone Assign the VLAN to a firewall zone based on its purpose. - For a VLAN on a management port, set the zone to `control`: ```shell copy sudo nmcli connection modify vlan10 connection.zone control ``` - For a VLAN on a data port, set the zone to `data`: ```shell copy sudo nmcli connection modify vlan10 connection.zone data ``` ### Activate the interface Activate the new VLAN connection to apply the configuration. ```shell copy sudo nmcli connection up vlan10 ``` ### Delete a VLAN interface To remove a VLAN interface, delete its `nmcli` connection. This action removes the VLAN interface and its configuration. ```shell copy sudo nmcli connection delete vlan10 ``` - [User Management](/beam/system-admin/security/user-management) - [LDAP Management](/beam/system-admin/security/ldap-management) - [SSL Certificates](/beam/system-admin/security/ssl-certificates) # LDAP management ## LDAP configuration By default, accessing the Controller user interface is restricted to people that have a user account defined through the MediaKind system center. You can also configure the user access by retrieving user credentials from an existing LDAP server directory. 1. Log in as a user with Administrative privileges. 2. Click `Gear` icon in the upper right corner of the window. 3. Select **Settings**. The Settings page displays 5 tabs: 4. In the **LDAP** tab, configure the LDAP settings to integrate with the local LDAP server. ![menu system settings ldap](/_machine-assets/ca078088f8859bf5be5a7b8648e364d97b82b8e14fe311ca293e6876ba89af6f.png)

After changing the LDAP settings, for changes to take affect, the authentication service must be restarted. Either restart the Controller, or consult MediaKind Services for guidance on restarting the correct services for your deployment.

## Loading LDAP certificates If LDAP certificates are being loaded, configure LDAP on the settings page, then load the certificates.

For HA deployment, the following procedures must be done on both controller servers.

1. On the controller server, place the LDAPS certificates in /etc/pki/ca-trust/source/anchors/ 2. Run the following command: ``` update-ca-trust extract ``` This will extract it to the standard OS trust store location (default path used in the controller UI): ``` /etc/pki/ca-trust/extracted/pem/tls-ca-bundle.pem ``` 3. Edit the config file to set the right values: ``` /opt/mediakind/utility/bin/controller/ldaps.conf ``` The conf file must contain the fully qualified domain name for the LDAP server (same as in the certificate) and the IP address of that server. ``` ############################################################################### # # # Config file used by add-ldaps-certs.sh # # Needs to be populated by the customer specific parameters # # # ############################################################################### # newLDAPServerName must be fully resolvable # FQDN that matches the provided root CA newLDAPServerName=ldaps.sou.new newLDAPServerIP=10.1.1.1 deployment=unified-ui ```
LDAP Field Description Example value
server Address of the LDAP server to communicate with. ldap://fr-my.companydomain.com:389
Bind DN Distinguished name to use when binding to the LDAP server; leave empty (default) for an anonymous bind. CN=apache, OU=COM, OU=Sites, DC=companydomain, DC=com
Bind password Password to use for binding with protected binding; leave empty (default) for anonymous binding. Password123
Search base DN DN to use when binding to the server in order to perform searches. Leave empty for anonymous binding. OU=COM, OU=Sites, DC=companydomain, DC=com
Username field Name of the field to use in the LDAP search, for username matching (against LDAP attributes). sAMAccountName
Firstname field Name of the field (from LDAP attributes) holding the user’s first name. givenName
Lastname field Name of the field (from LDAP attributes) holding the user’s last name.  firstname_field & lastname_field shall be used together, or they will be ignored. firstname_field & lastname_field can be used to retrieve the user’s full name. This will then be displayed instead of the username once the user is logged in. sn
CA certificate file Location of the CA certificate file used to verify the LDAP server’s certificate when using TLS or LDAPS. /etc/pki/ca-trust/extracted/pem/tls-ca-bundle.pem
Cipher suite Open SSL-format string defining the list of ciphers to use for TLS communication. kEECDH+aECDSA+AES:kEECDH+AES+aRSA:kEDH+aRSA+AES:-SSLv2:-SSLv3:-TLSv1:-TLSv1.1
Required group The LDAP group required for a user to be able to log in. cn=lcl.cnt.dfw.di.mediakind.allowlogon, ou=Resources,ou=Groups, ou=MediaKind,ou=CP, dc=example,dc=org
Group search The filter used to search for required group. dc=example, dc=org
Default group A Controller group assigned to a user that has logged in via LDAP. Mutually exclusive with ldap_group_mappings section. Monitoring
Group type The type of group used to search through LDAP. NestedActiveDirectoryGroupType and GroupOfNames are supported if anything other than NestedActiveDirectoryGroupType it will default to GroupOfNames NestedActiveDirectoryGroupType
LDAP group mappings A section that can be used to control authorisation through LDAP groups. Configure group_search (and don’t use default group). In the example, any user that belongs to the LDAP group MK_Configuration will be given the privileges for the Controller group Configuration. LDAP group
MK_Admin Admin
MK_Configuration Configuration
MK_Monitoring Monitoring
4. Run the script: ``` /opt/mediakind/utility/bin/controller/add-ldaps-server.sh ``` Running the script will restart the required containers. # Reset mfeng password ## Purpose This page describes a procedure to reset the mfeng user password of a Beam 1.x.x server in case: - you have forgotten it - you inherit a Beam unit and do not know the mfeng user password ## Pre-requisites You will need console access to see and interact with the bootloader.: - Either at a keyboard and monitor locally - Or via Virtual Machine remote console ## Steps 1. Reboot the machine: As soon as the bootloader comes up with the selection screen, quickly tap the up and down arrow keys to pause the countdown. ![os-bootloader](/images/beam/system-admin/os-bootloader.png) 2. Select the kernel you want to boot into. In the screenshot above, the kernel is `AlmaLinux (4.18.0-553.144.1.el8_10.0.x86_64) 8.10 (Cerulean Leopard)`. Hit `e`: This will take you into a screen where you can edit the grub bootloader script. ![os-bootscript](/images/beam/system-admin/os-bootscript.png) 1. Find the line that refers to the kernel: There will be a series of _boot parameters_ here: these are instructions passed during the loading of the kernel. For RHEL/CentOS/AlmaLinux/RockyLinux 8x or above the line usually starts with `linux`. ![os-bootscript-edit](/images/beam/system-admin/os-bootscript-edit.png) 2. Add `rd.break` at the end of that line (There are other things you can do here, but for now, this is all you need) **Note: This change is temporary.**. 3. Now hit Ctrl-x to run the edited bootloader script. 4. You’ll boot to a 'rescue' prompt that looks like this: `switch_root:/#`. ![os-switchroot](/images/beam/system-admin/os-switchroot.png) 5. Remount the root partition in read-write mode so that you can run commands. Enter the following: `mount -o remount,rw /sysroot` and then hit ENTER. 6. Now type `chroot /sysroot` and hit enter. This will change you into the sysroot (/) directory, and make that your path for executing commands. 7. Now you can simply change the password for mfeng using the `passwd mfeng`command. ![os-switchroot-edit](/images/beam/system-admin/os-switchroot2.png) 8. You should get confirmation that the password was changed, such as: `passwd: all authentication tokens updated successfully.` 9. Next, before you reboot, you will need to make sure that SELinux allows the file changes. At the prompt ,enter: `touch /.autorelabel`. This will signal SELinux on the next reboot that the filesystem has changed (the changed password) and allow the change to be loaded. This will cause the whole filesystem to be 'relabeled' which might take a while, depending on the size of the filesystem and the speed of the machine, so be aware of this possibility. 10. Type `exit` to leave the chroot environment and enter `reboot`. The system will reboot and SELinux should attempt to relabel files. Once relabelling is complete, the system should reboot again and present the regular terminal prompt. Congratulations, you've reset the mfeng user password! # Enable customer-signed SSL certificates ## Certificate file location It is advisable to keep the cert files (.crt/.key) in `/etc/pki/tls/certs/` custom folder. The configuration script allows for this place to be different but if it is not here, it will not be backed up on upgrade. ## Configuration file The configuration file which is used for this process is `/usr/bin/certs/certs.conf`. It needs to be updated with user's custom values for the correct certs to be added. Sample file: ```shell ############################################################## # # # Config file used by add-https-certs.sh # # Needs to be populated by the customer specific file names # # # ############################################################## CERTS_input_file_location=/etc/pki/tls/certs/custom client_KEY_file=customer.key client_CRT_file=customer.crt CA_auth_file=TrustedRoot.crt http_deployment=api-gateway ```
Parameter Value
CERTS_input_file_location This is the place where the .key and .crt files should be placed.
client_KEY_file, client_CRT_file, CA_auth_file Customer files; needs to be updated to show the actual file names used.
http_deployment In the current deployment, this is always api-gateway so no need to change.
## Configuration script The script that does the configuration is `/usr/bin/certs/add-https-certs.sh`. Running just the script without any arguments will give possible actions. Usage: ```shell add-https-certs.sh ``` Actions: ```shell -a, --add Add custom certs to the unit -h, --help Display configuration details ``` Once the configuration file has been updated, run the script: ```shell copy ./add-https-certs.sh --add ``` Progress will be displayed on the CLI. If successful, there is no need to do anything else, the certs will be in place and in use. The HTTPS port used is 31443, so to see certs once added use: `https://myunitIP.com:31443` As well as configuring the HTTPS web access the same certificate also configures HTTPS packaged output, see [HTTPS Packaged Output](/beam/packager/https-output). # User management ## Manage users Administrators have rights to create users and assign groups. User groups reflect different user roles with specific permissions. Permissions authorize access to applications, menus and features.

Menu options depend on your processing type and product installation.

### User groups A user group is a set of access rights and permissions. Permissions authorize users to either display or edit configurations. Users are assigned to at least one user group. A user can be assigned to multiple groups.

New users are automatically assigned to the Monitoring group.

### User group permissions There are 3 default user groups. Permissions are either Read (R), Write (W), or Read and Write (R/W). Yes means the user group can carry out the action, but may be limited to specific options.

User group options depend on your processing type and product installation.

Admin Configuration Monitoring API
Services R/W R/W R R/W
Servers R/W R/W R R/W
Templates R/W R/W R R/W
Failover R/W R/W R R/W
Alarms and Stats R R R R
Settings R/W N/A N/A R/W
Restore Yes Yes No R/W
Backup Yes Yes Yes R/W
User Management R+W N/A N/A N/A
#### Failover default user rights per user group

Admin users have all rights.

**Monitoring** users can (based on Failover control privilege): - View groups - View group details - View failover audit history - Trigger manual failover - Trigger a manual revert - Trigger a maintenance mode **Configuration** users (based on Failover configuration privilege): - View groups - View group details - Trigger manual failover - Trigger a manual revert - Trigger a maintenance mode - Create groups - Edit groups - Delete groups - Edit default failover mode - Edit timeout period
Group Services Servers Templates System Center Restore Backup User Management
Admin R+W R+W R+W R+W Yes Yes R+W
Monitoring R R R N/A No Yes N/A
Configuration R+W R+W R+W N/A Yes Yes N/A
### Display the list of users 1. Click `Gear` icon in the upper right corner of the window. 2. Select **User Management**. The User Management Administration page displays. 3. Select **Users**. The list of users displays. You can scroll to the end of the list to display the total number of users. ### Add a new group 1. Click `Gear` icon in the upper right corner of the window. 2. Select **User Management**. The User Management Administration page displays. 3. Select **Groups**. The list of groups displays. You can scroll to the end of the list to display the total number of groups. 4. Select **Add Group**. You are prompted to enter group information. 5. Enter the **Name** and define the **Permissions** for the group, as shown in the example below: ![add new group](/_machine-assets/d1cf612d4a11dd79efef29214fc8699e05c20f389e6a74d0d1a53629dd9cc446.png) 6. Select a **Save** option. The new **Group** appears in the list of groups. ![group list](/_machine-assets/c7ac7f137a2edecb8abcf1f160f7a640cd0c4f4d0e9258d5e23648c959a76ca2.png) The group permissions for **Monitoring**, **Configuration**, **Admin** and **API** are listed below (permissions for these groups cannot be modified by the user): **Monitoring**: The users with **Monitoring** access can perform the following actions in the code: - Access the GUI - Backup databases - Manually perform a revert and failover of servers **Configuration**: The users with **Configuration** access can perform the following actions in the code, in addition to the permissions described in the **Monitoring** group above: - Restore databases - Create, edit and delete services - Create, edit and delete templates - Create and edit servers - Modify licenses - Create, edit and delete failover groups - Access settings - Modify SNMP configurations - Schedule jobs on services - Edit alarm overrides - Generate catalogs, outputs and assets **Admin**: The users with **Admin** privileges can perform the following actions in the code, in addition to the permissions described in the **Monitoring**, **Configuration** and **API** groups above (meaning, these users have the rights to perform everything in the system): - Modify external links and general settings - Delete licenses and servers - Reboot Servers **API**: The users with **API** privileges have the right to access the API. ### Create a new user The Controller is a single access point for products. Administrators manage users, groups and permissions from the system center. 1. [Display users](/beam/system-admin/security/user-management#display-the-list-of-users). 2. Select **Add User**. You are prompted to enter User information. 3. Enter the User information. - **Username** - **Password** 4. Select a **Save** option. 5. [Assign a user to a group](/beam/system-admin/security/user-management#assign-a-user-to-a-group) to manage user access [rights and permissions](/beam/system-admin/security/user-management#user-group-permissions). By default, new users are assigned to the **Monitoring** group.

An Admin user can edit or create other Admin users and profiles, including passwords and permissions.

### Assign a user to a group Groups are a set of access rights and permissions. Permissions authorize users to either display or edit configurations. Give a user access rights by assigning the user to a group. 1. [Display users](/beam/system-admin/security/user-management#display-the-list-of-users). 2. Click the user in the list to display user information and permissions. 3. Scroll to **Permissions** then use the arrows to add the group to the list of **Chosen groups**. You can add multiple groups, or click **Choose all** to assign the user to all available groups. ![view permissions arrows user mgt controller](/_machine-assets/06214b442ad9132587a72f9ae4afdedf6c8fde1f405de3e89f975b68d1c2078d.png) 4. Click **Save**. ### Link LDAP or Active Directory The MediaKind Controller can be linked with an external server (LDAP or _ActiveDirectory_) to identify and authenticate users. If activated, the authentication page displays before granting access to the **Home** page.

The LDAP connection parameters are defined in a dedicated configuration file. If using LDAP, the MediaKind Controller neither stores nor manages user passwords that are managed by the external LDAP server. Users defined on the external server can coexist with locally defined users.

1. See [LDAP configuration](/beam/system-admin/security/ldap-management) for LDAP configuration procedures. 2. Follow the steps. When users are first installed from the LDAP or _ActiveDirectory_ server, they are by default, automatically assigned to the Monitoring group. The default group can be configured. Alternatively, LDAP can be configured to assign groups based on LDAP group membership. Administrators can [edit user groups](/beam/system-admin/security/user-management#editing-user-information) to [manage permissions](/beam/system-admin/security/user-management#user-group-permissions) and access rights. ### Editing user information 1. [Display users](/beam/system-admin/security/user-management#display-the-list-of-users). 2. Select a **User**. 3. Edit the user information: - **Username** - **Password** - **Personal information** - [Permissions](/beam/system-admin/security/user-management#user-group-permissions) 4. Select a save option to continue or exit.

An Admin user can edit or create other Admin users and profiles, including passwords and permissions.

### Edit a user password Any user can edit their password, but only users with admin or configuration permissions can edit passwords for other users. 1. [Display the list of users](/beam/system-admin/security/user-management#display-the-list-of-users) in the System Center. 2. Click the current **Admin** user from the list to edit. 3. Click the **this form** link to change the password. ![view user management mfvp controller change password](/_machine-assets/7213df160f427b72e7612a40407f890f849b7ac3ef2b44fed9e68ff1cd011334.png) 4. Edit user profile settings then click **Save**. ## Save options for user management
Save option Result
Save** The user is added to the list.
Save and continue** Additional user information displays (groups and permissions).
Save and add another User is added to the list and the add user page is refreshed to add another new user.
- [Manage Servers](/beam/system-admin/servers/servers) - [Failover](/beam/system-admin/servers/failover) # Manage failover ## Failover and revert (redundancy) Failover mechanisms ensure service continuity. If a whole server fails, or if critical alarms are detected by the processing application, services can be moved to a backup server. The Controller automatically manages failover when the automatic mode is configured. You can also manually failover, or revert once the primary server is repaired. Both server-level and service-level failover are supported. - For server-level failover, when an alarm is received which is configured to trigger failover: - All services on the involved server will be moved to one of the configured backups. - That backup server will no longer be available for further failovers - For service-level failover, when an alarm is received which is configured to trigger failover: - If it is a server-level alarm: all services on the involved server will be moved to one of the configured backups (as for a server-level failover). - If it is a service-level alarm: only the affected service will be moved. - The backup server in use will be reserved for further failovers _from the same primary_

Packager redundancy is managed by the Packager application (cluster of servers). The Controller is not involved in Packager redundancy.

### Timestamps - All timestamps are in **Universal Time (UTC)**. - Failover servers are [selected and grouped](/beam/system-admin/servers/failover#create-a-failover-group) according to processing type. - [User permissions](/beam/system-admin/security/user-management#user-group-permissions) are required to edit failover groups, or to failover or revert. - If the server has no services assigned, then **default user rights for failover** apply. ### Triggers - Automatic failovers are triggered by alarms that are marked as “triggers failover”. - By default, all critical alarms will trigger failovers. See [Alarm overrides](/beam/system-admin/maintenance/alarms-events#alarm-overrides) for more details. ## Display failover groups 1. Click **Failover** from the left-side menu pane. Failover groups display in the table. ![view failover groups list mfvp](/_machine-assets/e21e7af442d9e4dee7b3e84a6fa0ba7161e7189f3b096f6ac5f94b97de3cd8a3.png)

The alarm icon displays the alarm status for the highest severity alarm based on the servers in the failover group.

2. Click `View` icon in the **Actions** column to display details.

All time stamps are in Universal Time (UTC).

## Display a failover summary The failover summary table shows progress and status for failover procedures. 1. Click **Failover** from the left-side menu pane. Failover groups display. 2. Scroll to the bottom of the page to display the **Failover summary** table. ![view table failover summary mfvp mc](/_machine-assets/a7b65a9abb89c8afd9e51f975bb860673103115ae9ba3033e75a664dd044ef76.png)

All time stamps are in Universal Time (UTC).

3. Click `View` icon in the **Actions** column to display details. ## Create a failover group 1. [Display failover groups](/beam/system-admin/servers/failover#display-failover-groups). 2. Click **Add group...** 3. Enter a [**Group name**](/beam/system-admin/maintenance/parameters#failover-parameters). 4. Select a [**Failover level**](/beam/system-admin/maintenance/parameters#failover-parameters). 5. Select a [**Group processing type**](/beam/system-admin/maintenance/parameters#failover-parameters) for the servers in the group. 6. Select a [**Group failover mode**](/beam/system-admin/maintenance/parameters#failover-parameters).

The default Group failover mode is Automatic. You can manually trigger a failover, or revert, even in Automatic group failover mode.

``` ![view failover setup edit mfvp](../images/view_failover_setup_edit_mfvp.png) ``` 7\. Select available servers, and use the arrows to define the list of primary and backup servers. The new failover group displays in the list.

You can use the search option to display and select specific servers (for example, per processing type).

## Edit a failover group 1. [Display failover groups](/beam/system-admin/servers/failover#display-failover-groups). 2. Click `Edit` icon. The **failover setup** page displays.

Edit options are only available when Server settings are modifiable. If there is no button, check user rights or contact an administrator.

3. Edit the [group settings](/beam/system-admin/servers/failover#create-a-failover-group) configuration.
  • Failover level can only be changed if there is no active failover for this group (no services assigned to a backup).
  • Group processing type cannot be changed.
``` ![view failover setup group settings mfvp](../images/view_failover_setup_group_settings_mfvp.png) ``` 4\. Edit the server selection for primary and backup servers, then click **Save and exit**. The group is added to the list. ``` ![view failover setup select server mfvp](../images/view_failover_setup_select_server_mfvp.png) ``` ## Request a failover or a revert between servers manually Before you start: At least one [Failover group exists](/beam/system-admin/servers/failover#create-a-failover-group).

User permissions are required to request a failover or a revert. If the server has no services assigned, then default user rights for failover apply.

1. [Display failover groups](/beam/system-admin/servers/failover#display-failover-groups). 2. Click `View` icon to display details. 3. Click `Left/Right` icon to failover to backup servers, or revert to primary servers. You are prompted to continue. 4. A modal pop-up is displayed, showing progress and success/failure of this operation. 5. When complete, confirm that the assigned servers are correct, by checking the [services page](/beam/web-interface/services#display-services).

For a service-level group, manual failover/revert behave exactly as for a server-level group; all services on the primary server will be moved to the backup. All services on the backup server will be moved back to the configured primary (whether all services due to a manual failover, or service(s) which have been automatically moved in response to an alarm).

If the failover group is service-level, manual failover and revert can be done from the services page.

Manual service failover/revert is only available for services that are assigned to a single server.

1. From the **Services** page, click `Ellipsis` icon to show more actions on the service you want to failover or revert. 2. Click on the `Service failover` icon (failover) or `Service revert` icon (revert) icon to perform the action. Only the icon for the available action is displayed. 3. Click **Yes** to confirm the action. 4. A modal pop-up is displayed, showing progress and success/failure of this operation.

If multiple services are selected, the failover/revert action is only available if all selected services are on the same server.

## Select failover trigger settings By default, a failover is triggered for any critical alarm. You can select the failover trigger option for any alarm. This also applies to alarms that you have changed from the default alarm severity.

Changes to severity are only applied to future occurrences. Any current or previously existing alarms are unchanged.

1. Click **Alarms** in the left hand menu. 2. Click **Alarm overrides** to display options. The following page displays. ![view alarm overides controller](/_machine-assets/aaa90b80163c526039bdb41037f27cd70437a88ec17004329c4c021ef9301e30.png) 3. Select a response for **Trigger failover**. ![view alarm override failover trigger controller](/_machine-assets/0859e970261979203c1f87088d8cdd75746f72f49635676e17a4acf06fbf6d2a.png) # Manage servers The **Servers** view displays system information to monitor and manage servers. The statuses indicate server availability: **connected** or **connection lost**. ## Server Status

The actions available are dependent on the installation type, server type and the user role.

- Administrators can click the **Delete** `Delete` icon button to remove a server that is no longer in use in the system. - You can use the **Reboot** `Reload` icon button to restart the server by clicking **Yes** at the displayed **Are you sure?** confirmation message. - Click the **Details** `View` icon button to display the server information ([Display server information (system)](/beam/system-admin/servers/servers#display-server-information-system)). - Click the **Stats** `Chart` icon button to view server statistics, such as CPU, memory, disk usage, and network statistics. - Click the **Support package** `Package` icon button to [generate a support package](/beam/system-admin/maintenance/generate-support-package). - If the connection is lost when the server is in a failover group then check if failover occurred. - You can also check alarms or alarm history to investigate possible causes. - You can also check server information for IP configurations. ## Server processing types Additional processing types are available from the **Servers** page.
Processing type Required Software
Controller Controller provides a centralized configuration and control interface, manages failover for Live Encoder, and offers a flexible licensing management for MediaKind applications.
Arbiter A server which is fulfilling the role of the database arbiter.
## Display servers Servers are listed in a table. You can view server settings and usage statistics per server. 1. Click **Servers** from the left-side menu. The table of servers displays. 2. Edit the number of [rows displayed](/beam/web-interface/navigation#edit-the-number-of-rows-displayed) or use the [search bar](/beam/web-interface/navigation#use-the-search-bar) to filter the display. ## Display server information (system) Check server functions and performance to manage server and service allocation, or to view license information. System settings and information displays for each server. 1. Click **Servers** on the left-side menu. 2. Click `View` icon in the **Actions** column to view server information. Information based on the server type displays. 3. Click the tabs to display server information. - **General** - **System Settings** - **Statistics** # System administration ## System center Management and administration features such as SNMP, SDI routers, external links and LDAP configuration, as well as [backup and restore](/beam/system-admin/maintenance/backup-restore) and [user management](/beam/system-admin/security/user-management) are available in the **System Settings** menu, `Gear` icon. ![menu mfvp system settings](/_machine-assets/03efef2b88141a39bf999a8214e1f15ed73b696d5fc8d416e5bdd93f097c6654.png) The following tabs are available from the **Settings** menu: \- **General** \- [**SNMP notifications**](/beam/system-admin/maintenance/alarms-events#alarm-forwarding-snmp) \- [**External links**](/beam/web-interface/navigation#external-links-to-third-party-tools) \- [**Router Settings**](/beam/system-admin/network/router-configuration) \- [**LDAP**](/beam/system-admin/security/ldap-management) From the **General** tab, you can customize the system name (see below) and the [alarm display time](/beam/system-admin/maintenance/alarms-events#customize-alarm-display-time). ## System name customization Administrators have rights to edit and customize system name displayed in the user interface. Depending on deployed solutions or environment, multiple systems including distinct controller(s) managing separate servers and services may be necessary. Customizing the system name allows you to easily identify from the home page the system you need to access. 1. Click `Gear` icon in the upper right corner. 2. Select **Settings**. The Settings page displays 5 tabs: 3. In the **General** tab, enter the name to display for this system and click **Save** to apply the changes. The new system name displays on the top left side of the system user interface. # Third-party software ## Overview This capability is only supported for drivers and software pre-approved by Mediakind. Beam is designed and operated as an appliance. Changes made directly to the underlying OS installation are not preserved across software upgrades — when Beam is upgraded and the system is restored, the OS is returned to its baseline state. Beam 1.10 introduces a dedicated persistent volume mounted at `/opt/third_party`. This volume is not touched during upgrades, so anything placed there survives across software updates. It follows a traditional application layout:
Directory Purpose
bin/ Executables
lib/ Libraries
etc/ Configuration files
install/ Hooks for modifying other parts of the system on restore
For most use cases, placing software into `bin/`, `lib/`, and `etc/` is sufficient. The `install/` subdirectory is only needed when changes must be made to other parts of the system (such as installing RPM packages into the OS or importing container images into k3s) each time the system is restored after an upgrade. ## System hooks (`install/`) Files placed under `/opt/third_party/install` are processed automatically each time the system is restored after an upgrade. Place files in the appropriate subdirectory: ### `images/` Container image archives (`.tar` files) to be imported into k3s. All `.tar` files found in this directory are imported during restore using: ```bash /usr/local/bin/k3s ctr image import --digests .tar ``` ### `rpms/` RPM packages (`.rpm` files) to be installed during restore, before k3s starts. A typical use case is NIC drivers not included in the standard Linux kernel. RPMs may be placed directly in `rpms/` to apply on all OS versions, or in a version-specific subdirectory to target a particular OS major release:
Directory Applied on
rpms/el8/ Enterprise Linux 8 (e.g. AlmaLinux 8)
rpms/el10/ Enterprise Linux 10 (e.g. AlmaLinux 10)
RPMs from both `rpms/` and the matching `el#/` subdirectory are installed in the same invocation. The appropriate `el#/` subdirectory is created automatically during restore if it does not already exist. ### `scripts_early/` Shell scripts executed during early restore, before k3s starts. Scripts are discovered by name (`*.sh`), must be executable, and are run in descending numeric sort order (for example, `20_foo.sh` runs before `10_bar.sh`). ### `scripts_k3s/` Shell scripts executed during k3s configuration restore, after container images have been imported. The same discovery and ordering rules apply as for `scripts_early/`. ### `data/` Supporting data files for use by scripts. Nothing in this directory is executed or installed automatically. Scripts may reference files here using the full path, for example `/opt/third_party/install/data/`. ## Script requirements Scripts placed in `scripts_early/` or `scripts_k3s/` must meet the following requirements: **Executable permission** — Scripts must have the executable bit set before they will be run: ```bash chmod +x myscript.sh ``` **Shebang** — Scripts must begin with a valid interpreter line, for example: ```bash #!/bin/bash ``` **Idempotent** — The restore process runs on the first boot after a software upgrade. If the unit reboots part-way through an upgrade (for example to upgrade device firmware), the restore runs again from the beginning. Scripts must not fail or produce unintended side effects when run more than once.

All scripts are executed with root privileges. A faulty script can leave the system in an unbootable state. Ensure all scripts are reviewed and tested before deployment.

# TS Splicing A **TS Splicer** (Transport Stream Splicer) dynamically substitutes content within a live MPEG-2 Transport Stream without decoding and re-encoding the video. It works at the compressed domain, swapping content from one source with content from another in response to SCTE-35 trigger signals or a schedule. MK.IO Beam's TS Splicer enables seamless insertion, replacement, or switching of MPEG-TS content within a live workflow. It supports alternate content and blackout management as well as linear ad insertion, maintaining stream continuity and standards compliance throughout. ## Alternate content and blackout TS Splicer uses linear stream switching inline with CableLabs ESAM specifications (version 2013) to manage alternate content and blackout scenarios. Content substitution can be initiated in two ways: - **Time-based:** The POIS (Placement Opportunity Information Service) instructs TS Splicer to switch to blackout or alternate content at a specified time. In this mode, known as ESAM out-of-band, no SCTE-35 signal is required. - **Signal-based:** On detecting an SCTE-35 signal, TS Splicer sends an ESAM request for each configured output group. Each output group has distinct ESAM parameters, so the POIS reviews its schedule and cross-references it with the SCTE-35 signal. If there is a match, the POIS directs the output group to switch to blackout or alternate content as defined in the schedule. Example use cases: - **Sport blackout:** A sports channel is replicated across multiple geographical areas. Although each area receives an identical stream, unique ESAM parameters characterize each. Based on a pre-determined schedule, certain regions enable blackout to comply with rights restrictions or regional viewing guidelines. - **Content regionalization:** At specific times, a national channel distributes localized content to different regions. See [Placement configuration](/beam/ts-splicer/placement) for how to set up blackout and alternate content rules. ## Linear ad insertion Linear ad insertion replaces a segment of the primary content with an advertisement in response to SCTE-35 triggers. Similarly to the blackout mechanism, an input channel is duplicated based on the number of geographical zones it serves. TS Splicer supports three ad insertion modes: - **SCTE-30:** Communication with legacy ad servers using the SCTE-30 standard. - **VAST:** Connects directly to a digital Ad Decision Server (ADS), unifying ad insertion for both broadcast and OTT workflows. - **ESAM (extended):** Uses a MediaKind extension of the ESAM format that returns a content list rather than a single alternate content ID. This mode combines at-the-edge linear schedule ingest with splicing. MK.IO Beam manages the linear schedule ingest, while TS Splicer handles the splicing. ## Dual output prevention When two TS Splicer instances are deployed in an active/active configuration, MK.IO Beam provides dual output prevention using the Multicast Guard Protocol (MGP). This ensures only one instance has its output enabled at any time, preventing duplicate multicast on the same network. ## Where TS Splicer fits in a workflow A TS Splicer sits downstream of encoding, receiving a live transport stream and delivering conditioned output to distribution. For workflows where SCTE-35 event management, signal normalization, and rewriting are needed before the TS Splicer, MK.IO Beam's [SCTE-35 Rewriting](/beam/stream-conditioning) capability handles that upstream layer. # Configure advanced parameters

Warning: Setting advanced parameters can have unexpected results. Contact Mediakind before changing

1. From the **Advanced parameters** tab, enter a parameter name then enter its value. 2. Optional: You can click the **Add** button to add additional advanced parameters. 3. Click **Save and continue** or **Save and exit** to save your changes. # Configuring Alternate content sources Blackout and alternate content switching is managed using ESAM (standard) communication interface. As an example, below is the response TS Splicer receives from a POIS (either in an out-of-band fashion, or following the SCTE-35 submission): ```xml ``` This response from the POIS instructs TS Splicer to switch to an alternate content which ID is ECE-SLATE. This content ID shall be mapped to a physical content. To configure such alternate source content mapping: - Select **Settings** from the left-side menu panel and display menu options. - Select **Alternate content sources.** - Source collection can be exported or imported using Import or Export button. When adding a collection the field **Name** will be populated automatically. - To add a new alternate source, click the **+Add** button. - **Alternate Content ID**: ID of the source, for instance: ECE-SLATE (based on previous SPN response) - **Type**: Select the type of alternate content source: - MPGE2 TS/UDP: Alternate content source is a multicast feed for which stream address, Port and Program ID (optional) must be configured. - File: Alternate content source is mapped to a file (Transport Stream) which should be aligned with the underlying live programming. - HLS: Alternate content source is an HLS for which the URL to manifest must be configured. ![ESAM SPN](/_machine-assets/c6390628049eb31edfef93de989c07342b7fb35e1c6bcaa8cb871bdfd295d425.png) # General parameters Upon creating a TS Splicer service, the **General.** tab is the first to appear. It gathers general settings for redundancy and common network interfaces used for communication with Ad servers and POIS components. ## Configure dual output prevention The dual output prevention feature safeguards against duplicate media multicast on the same network. This is particularly useful in scenarios with active/active encoders. This functionality leverages the Multicast Guard Protocol (MGP) and according to the following principles: - Point-to-point communication between both encoders, utilizing multicast messages over a dedicated port. - Constant check so only one encoder has its output enabled at any given time. ![dual output prevention](/_machine-assets/803ee3631f4f55dcbf9604d6726090cc5acad405f4fd4b2984394868198022d4.png) By default, the first active TS processing instance will have its output enabled. To set up dual output prevention: - Check the **Activate** checkbox. - **Network interface:** Specify the network interface for dual output prevention. - **Address**: Define the multicast address for communication. - **Port**: Set the designated port. - **Group name**: A group encompasses a pair of TS Splicers under dual output prevention. Use this field to identify the group. ## Configure server variant Initiating a server variant is straightforward: simply check the **Activate** checkbox. This action will auto-generate both primary and secondary variants. ## Configure network interfaces TS Splicer orchestrates communication with various decision-making entities, notably the Ad Decision Server (ADS) and the POIS component for blackout and alternate content decisioning. To configure network interfaces: - **ESAM Network interface:** Specify the name for the interface used to communicate with the POIS - **VAST Network interface:** Designate the interface for VAST, typically an interface with public internet access. - **SCTE-30 Network interface:** Define the interface for SCTE-30, which communicates with an Ad Server. # Configuring the input TS Splicer is designed to support live MPEG2-TS ingest multicast. Additionally, it integrates RIST support to receive TS multicast streams sent over the internet. To configure the service input, select the **Input** tab in the user interface. ## Live multicast MPEG2-TS ingest - **type:** Select MPEG-TS/UDP - **input redundancy:** When two multicast input sources (primary and secondary) are accessible, choose between two modes. In the active/passive mode, the secondary source remains idle, not joining the multicast address or receiving UDP packets. The active/active mode lets both sources are captured simultaneously, offering statistics on transport and demux layers. - **input loss timeout**: Set to 1000ms by defaut, this is the time taken to switch between two sources if signal loss occurs. - **Switch on ES data loss**: Initiate a switch to the backup source in case of audio or video loss. - **Delay**: Only applicable if "Switch on ES data loss" is enabled. If audio or video is lost, it specifies the time to wait before switching to the backup source. In the **Primary** section of the UI, configure the live multicast MPEG2-TS details: - **Network interface:** Designate the network interface capturing the input stream. - **Stream address:** Define the input stream's unicast or multicast IPv4 address. - **Port:** Input the port for capturing the stream. - **IGMPv3 source filtering:** Enumerate allowed IP addresses for IGMPv3, separated by commas. - **Input synchronization mode:** Depending on the input stream data, synchronize input via PMT program ID or stream PIDs. - **Program ID:** Select the appropriate program from the MTPS input stream. - **PCR PID**: Input the packet identifier for the Program Clock Reference, essential for synchronizing audio and video packets. If unspecified, it defaults to the output Video PID. To configure a secondary input, click the **+Add** button under the Primary section. This action mirrors your primary settings in a new secondary section. ## Select Input streams for Primary (and Secondary, if configured) - In the **Video ID** section, set the Video PID. If the input synchronization mode is set to PMT, video PID will be set to _auto._ Otherwise, specify the video PID to filter. - In the **Audio ID** section, add audio tracks by either PID or language. - In the **Subtitle ID** section, configure which subtitle tracks you wish to pass through to the output. You can select from the following subtitle types: Teletext, SCTE-27, DVB-Subtitles, ARIB B24. Set up filtering based either on PID or language. - Under **Metadata ID**: section covers passthrough for non-audio or video data, such as SCTE-35 signals, cuetones, AIT, EBIF, EISS, and PES metadata. # Service Monitoring ## Monitor service alarms The MediaKind user interface allows you to access active and cleared alarms list for each service. Severity of the alarm appears in different colors: - `Alarm red` icon: critical alarm - `Alarm yellow` icon: major alarm - `Alarm green` icon: minor alarm # Output streams configuration TS Splicer enables the duplication of a configured input service multiple times to manage distribution to various geographical areas, zones (also referred to as DMA or Designated Market Area in the US) or content partners. Content substitution or modification can happen in a differentiated way for each output group defined. ## Creating an output group An output group represents a collection of TS streams, all behaving identically. For instance, if an output group dedicated to a particular zone initiates a blackout, all TS streams within this group will adhere to the blackout. Multiple TS streams might be necessary for redundancy. From an ad placement perspective, only one ESAM or ad call per output group is made. - Click the pencil icon to edit the service settings. - Navigate to the **Outputs** tab. - To create a new output group, click the **Add output group** button and assign a name. For clarity, consider using meaningful names like geographical identifiers (VIRD, DMA...) or the content partner name. - Click **OK** to validate. ## Adding MPEG2-TS Streams to an output group TS Splicer supports the creation of MPEG2-TS outputs, whether they're multicast MPEG2-TS over UDP or utilize a RIST listener. **Configuration specific to MPEG2-TS/UPD output type** - **Type:** Select _MPEG2 TS/UDP._ - **Network interface:** Specify the network interface used for the output stream distribution. - **Source address:** IP address marked as the source in the IPv4 header. - **Source port:** Designated source port in the IPv4 header. - **Stream address:** Unicast or multicast IPv4 address for output stream distribution. - **Stream port:** Port specified as destination in the IPv4 header. **Configuration specific to RIST output type** - **Type**: Select _RIST Listener._ - **Network interface**: Specify the network interface used to distribute the output stream. - **Listener port**: Port to listen on for RIST connections. **Common MPEG-2 TS parameters** Once specific output settings are configured, configure the following parameters for your MPEG-2 TS output: - **Standard:** MPEG-2 TS information is encapsulated to fit the ATSC or the DVB standard. - **PMT PID:** Packet identifier of the Program Map Table (PMT). - **PCR PID:** Input the packet identifier for the Program Clock Reference, utilized for synchronizing audio and video packets. If unspecified, the PCR PID defaults to the output Video PID. - **Target PCR period:** The target time between two PCR information. - **Target PSI period:** The target time between two PSI information. - **Program number:** Associated to a specific program. Commonly used in MPTS to differentiate programs within the same MPEG-2 TS stream. - **Service name:** Service added to the service description table (SDT). - **Service provider:** Service provider name added to the service description table (SDT). The last section of the output configuration allows for defining which Elementary Stream (ES) you want to convey to your output, offering PID rewriting capabilities: - Select the video, audio and metadata streams to include in your output. - Use the PID column to specify a PID override. - Click OK to validate the configuration. # Configuring content substitution and processing For each output group created, content substitution and processing can be associated to enable use cases such as: - Managing alternate content & blackout - Implementing linear ad replacement - Controlling SCTE-35 placement (upcoming feature) TS Splicer implements industry-standard communication protocols towards content decisioning services such as POIS services (for Alternate Content & Blackout, using MK.IO Beam POIS Control or any 3PP POIS) and Ad decision servers. ## Using TS Splicer for Blackout & Alternate Content TS Splicer uses CableLabs ESAM (2013 version) for handling linear stream switching: - On detecting an SCTE-35 input signal, TS Splicer sends the signal to a POIS entity. It then decides on the switching strategy based on the scheduled provisions and SCTE-35 matching criteria. - Out-of-band switching (also known as time-based switching) is also supported. Here, a POIS instructs TS Splicer to shift to alternate content, even if no SCTE-35 signal was received. To configure ESAM for blackout & alternate content switching: 1. Go to the **Placement** tab and find the desired output group. 2. Click **+Add placement rule.** 3. Fill in the necessary parameters: - **Name**: Unique name for the placement. - **Type**: Select ESAM (standard) for blackout & alternate content switching. - **URL**: The endpoint where TS Splicer submits SCTE-35 signals and retrieves status. (ESAM SPE and PSN messages) - **Network name:** Correlates with the AcquisitionPointIdentity in the CableLabs ESAM specifications, and identifies TS Splicer at a specific site on a specific channel/network feed. - **Zone identity:** Corresponds to the Zone Identity defined in the ESAM specification: a string that represents the location of this stream. Examples may include VIRD (Virtal IRD identifier). - **Start in black/silence:** If enabled, the output will start in blackout until configured timeout, or upon alternate content switching response/request from a POIS - **Black/silence timeout:** Sets the maximum time TS Splicer output will stay in black/silence. A value of 0 seconds sets it to infinite. Only alternate content switching can disengage black/silense output. Under the **Asset** tab, few settings are configured: - **Source location:** this note explains the mapping between the alternate content ID returned by the POIS entity and the actual content is retrieved from _Alternate Content sources_ - **Asset loop:** Traditionally, blackout has been managed for broadcast by switching to an alternate live input feed. TS Splicer provides the ability to switch to a file that will be played out in loop. This file shall be configured under **Settings > Alternate content sources**. Under the **Routing** tab: - **Filters:** Configure the conditions for TS Splicer to submit SCTE-35 signals to the POIS entity.To ensure proper communication with specific placements, such as one for linear advertising or another for blackout, it is necessary to set up SCTE-35 conditions accordingly. ![SCTE-35 routing](/_machine-assets/ce09da0d52c29293a52498252ef430c157ff5b0ada52280781121ccd46e0af25.png) Upon statup, TS Splicer sends an SSR (Signal State Request) request to the configured POIS to determine in which state it should start its output processing. Upon failover for instance, TS Splicer will start in blackout if the primary system was in blackout. For Out-of-band notification, the POIS needs to know which URL to contact. For TS Splicer, the URL is: `http://:/api/esam/TsSplicer/` ## Using TS Splicer for Linear advertising TS Splicer enables linear ad insertion based on SCTE-35 signal. Upon SCTE-35 reception, each output group sends a placement request to a well-defined endpoint. This endpoint can be: - **SCTE-30 Ad Server:** This is the legacy way of managing linear ad insertion. In this architecture, the SCTE-30 compatible Ad Server initiates a communication with TS Splicer via port 5168. Once the communication is established, upon ad break SCTE-35 signal, TS Splicer will exchange SCTE-30 messages with the Ad server that will respond by instructing TS Splicer to switch to an ad multicast at the designated SCTE-35 splice point. - **VAST**: TS Splicer implements a very innovative way of managing linear ad insertion over multicast using VAST. Upon detection of SCTE-35 ad break signal, a VAST HTTP request is sent to an Ad Server that will respond with a VAST document. This VAST document will contain a list of ads (creatives), and the access to each creative via a \ element. Creatives shall be available as HLS ad assets. - **ESAM (Extended)**: This mode is MediaKind-proprietary. ESAM protocol has been extended to manage playlist of content (ads). It requires POIS Control acting as an ad server: POIS ingests linear ad schedule per zone (output group) in a certain format (CCMS, CSV, STE-224). Upon reception of a SCTE-35 signal, each TS Splicer output group submits an ESAM request, and POIS responds with a list of creatives using extended fields of the ESAM response. ### SCTE-30 To configure linear ad replacement using SCTE-30 protocol, follow these steps: - Under **Placement** tab, locate the output group you want to configure with linear ad insertion. - Click **+Add placement rule.** Fill in: - **Name:** Name of the placement. It shall be unique per placement configured. - **Type:** Select SCTE-30 for linear ad insertion based on SCTE-30 protocol - **Channel name:** Name given to the output (group) channel. This setting is also used to verify the correct API connection when TS Splicer responds to the Ad Server. - **Network interface:** Name of the interface used to exchange SCTE-30 messages. Under **routing** tab: - **Filters:** Configure the conditions for TS Splicer to submit SCTE-35 signals to Ad Servery. For blackout, segmentation type id may be set to program start for instance. For advertising, splice insert or time signal descriptor filtering can be configured as shown below. ### VAST To configure linear ad replacement using SCTE-30 protocol, follow these steps: - Under **Placement** tab, locate the output group you want to configure with linear ad insertion. - Click **+Add placement rule.** Fill in: - **Name:** Name of the placement. it shall be unique per placement configured. - **Type:** select VAST for linear ad insertion based on VAST (Video Ad Serving Template) communication - **Decision server URL:** URL of the Ad server. it may contain hardcoded query parameters - **Audience server type:** ad-hoc integration enabling retrieval of audience information to be passed as query param dynamically. Current integration has been done against AM Lite audience server. for more information, or new audience server connection, please contact us. Under the **Routing** tab, fill in: - **Filters:** Configure the SCTE-35 matching criteria for TS Splicer to submit HTTP placement request to the Ad Server. Current implementation does not show any **Asset** tab. Path to the different creatives is automatically derived from \ elements of the VAST response (one \ element per creative). Only Creatives/ad assets in HLS format is supported today. ### ESAM (MK proprietary) - Under the **Placement** tab, locate the output group you want to configure with linear ad insertion. - Click **+Add placement rule.** Fill in: - **Name:** Name of the placement. It shall be unique per placement configured. - **Type:** Select ESAM (MK proprietary) for linear ad insertion based on CableLabs ESAM MK proprietary extension. - **URL:** The URL to which TS Splicer submits SCTE-35 signals and returns status (ESAM SPE and PSN messages). - **Network name:** This parameter corresponds to the _AcquisitionPointIdentity_ parameter defined in CableLabs ESAM specifications and identifies TS Splicer at a specific site on a specific channel/network feed. - **Zone identity:** Corresponds to the _Zone Identity_ defined in the ESAM specification: a string that represents the location of this stream. Examples may include VIRD (Virtal IRD identifier). - **Start in black/silence:** When enabled, TS Splicer will start in blackout until configured timeout, or upon alternate content switching response/request from a POIS. - **Black/silence timeout:** This parameter sets the maximum time TS Splicer output will stay in black/silence. Value of 0 sets it to infinite. Only alternate content switching can disengage black/silense output. # Advanced interface overview
Check which interface you are using

This page documents the Advanced interface, where a workflow is configured as a feed made up of individual services. On Beam 1.12.0 and higher, the Essentials interface manages the same workflows as channels instead, and a toggle in the top right of the header switches between the two. If your device shows channels rather than feeds, start at Beam Essentials UI.

The MK.IO Beam interface is designed for operators to simplify and accelerate feed configuration and control. The interface allows viewing all the running services as well as alarms and warnings in a single view. You can easily start or stop the services without navigating to the sub-menus. ## Home page When you connect to MK.IO Beam, the **Home** page is displayed: ![beam homepage empty](/ce1-img/beam_homepage_empty.png) At the first connection, no feeds are created. ## Add a feed To add a feed, follow these steps: 1. Click the **Add feed** icon. A new window is displayed. 2. You can either: - [Create a feed using default configurations](/beam/web-interface#create-a-feed-using-default-configurations). When creating a feed for the first time, use this method. - [Reuse a saved configuration](/beam/web-interface#reuse-a-saved-configuration). ### Create a feed using default configurations To add a feed, follow these steps: 1. Under **Feed types**, select a feed type. The selected template is surrounded by a blue frame. 2. Enter a name for that feed then click the **Add feed** button. A new feed is displayed on the Home page. This feed has some basic predefined settings for Live Encoder and Multiplexer components, but you will need to complete and configure some parameters. ### Feed monitoring panel Once you have created a feed, it is added to the **Home** page. For each feed, the following information is displayed: ![CE1 feed panel text](/ce1-img/CE1_feed_panel_text.png) Depending on the feed status, the feed monitoring panel color may change. For more information on alarms, see [Manage alarms](/beam/system-admin/maintenance/manage-alarms). ![ce1 channel status](/ce1-img/ce1-channel-status.png) ### Reuse a saved configuration Before you start: ensure [you have previously saved an existing configuration.](/beam/web-interface#save-an-existing-feed-configuration) To reuse an existing configuration, follow these steps: 1. Select the saved configuration from the list in the **Saved Configuration** section of the **Add Feed** dialog. 2. Set the **Feed name**. 3. Click the **Add feed** button. A new feed is displayed on the Home page. This feed can be edited, started, saved, or downloaded. ## Save an existing feed configuration You can save an existing feed configuration. The saved configurations can then be reused thus facilitating a new feed configuration process. To save a feed, follow these steps: 1. From the Home page, select a feed then click `Ellipsis` icon then select **Save Configuration** from the menu. ![CE1 feed save cfig](/ce1-img/CE1_feed_save_cfig.png) A new window is displayed. ![CE1 feed save cfig edit](/ce1-img/CE1_feed_save_cfig_edit.png) 2. Enter a **Name** and a **Description** then click **Save**.

For the Description, we recommend entering useful details that will help to know what parameters are set.

3. Click **Save** to validate. A message informs you that the configuration was saved. You can access the saved configurations by clicking the **Manage configurations** link in the top right corner of the Home page. Saved configurations can then be renamed, deleted, or downloaded. ## Export an existing feed configuration To export an existing channel configuration, follow these steps: 1. From the Home page, select a feed then click the `Ellipsis` icon then select **Download Configuration** from the menu. ![CE1 feed download cfig](/ce1-img/CE1_feed_download_cfig.png) A new window is displayed. ![CE1 feed download cfig edit](/ce1-img/CE1_feed_download_cfig_edit.png) 2. Enter a **Name** and a **Description** then click **Download**. 3. Locate the folder where you want to export the configuration, enter a file name then click **Save**. The configuration is downloaded. The exported configurations can then be sent by email, imported on the same device or onto another device. ## Import an existing feed configuration Before you start: ensure [you have previously exported a feed configuration.](/beam/web-interface#export-an-existing-feed-configuration) To import a configuration, follow these steps: 1. From the Home page, click the **Manage Configurations** in the top right corner. 2. You can either: 1. Drag and drop a configuration file, 2. or click on the **Add from file** area. A file explorer will be shown, select your file from the file explorer. This new configuration is added to the saved configurations. You can change the name and description. ## Show active feeds on top The home page displays a maximum number of 32 feeds. You can toggle the **Show running feeds at the top** button to display the active feeds at the top of the home page. ```

This setting is retained per browser session and will need to be re-enabled after closing and re-opening the browser.

``` ## Delete a ghost feed from the Home page It is best practice to delete and create feeds from the Home page. - When a user starts services from the service page, the thumbnails on the Home page will not be updated until the feed is started again from the Home page. - When a user deletes a service from the service page, the feed on the MK.IO Beam home page remains present and has to be deleted manually. To delete such a feed, follow these steps: 1. Go to the Home page. The feed will still be shown on the homepage, with a warning displayed. ![ce1 ghost](/ce1-img/ce1_ghost.png) 2. Click `Ellipsis` icon then select the **Delete feed** option. # Connect to the Controller 1. Open a web browser. 2. Enter the access URL, then press Enter. Your access is either HTTP or HTTPS depending on your security settings. - **HTTP example:**\ `http://[IP-Address]:8080` or `http://[IP-Address]:30020` for containerized solutions. - **HTTPS example:**\ `https://[IP-address]:8443` or `http://[IP-Address]:30001` for containerized solutions. 3. When the login page displays, enter your **username** and **password**. Default admin user login information: - **Username**: admin - **Password**: admin The **Home** page displays.

We strongly recommend that you change the default password to increase security. Password can be changed by clicking the user account on the upper right corner of the window.

# Menus and navigation ## User interface orientation Features, menus and options vary depending on your product and the MediaKind components installed. ### Home page and dashboard overviews The **Home** page displays a dashboard with overviews for services, servers, templates and alarms. Click an overview to link to the related page. ![home controller 4widgets v10.0](/ce1-img/beam_homepage_empty.png) ### Health indicator and alarms banner The Health indicator and alarms banner displays in the upper right corner of the screen. Health indicator status: - Green: everything is OK. - Amber: something needs attention. - Red: something isn't working. Functionality could be limited. If the indicator is amber or red, alarms will also be triggered.

You can click the Health indicator or the Health left menu to display an embedded Grafana page showing an overview of Controller health.

### System Center for solution administration The **System Center** menu provides access to administration features. Administrators can manage users, system backups and restore options, as well as monitor servers, and manage settings. To access the **System Center**, click the `Gear` icon in the top right corner. The displayed menu includes a number of options for system administration and monitoring. Features are available depending on your user rights.
Group Restore Backup User Management Settings
Admin Yes Yes R+W Yes
Monitoring No Yes N/A Yes
Configuration Yes Yes N/A Yes
**Related information**\ [System center](/beam/system-admin/system-administration#system-center) ### Edit the number of rows displayed For most menu pages available in the Controller UI, you can display more or less rows in the table by selecting the number of rows to display. 1. Use the left-side **Menu** panel to display a specific page. 2. Scroll to the bottom of the selected page and edit the number of rows to display per page. ![view rows per page mfvp unified ui](/_machine-assets/10999920db77ca549585176350351a2455dd17b68aa6cc9050f25349fef90710.png) ### Use the search bar The **Search** bar displays in pages with table displays. 1. Use the left-side **Menu** panel to display a specific page. 2. Enter one or several keywords in the **Search** bar to filter the table. Search requirements: - Keyword based - No wildcard ![view search bar table small mfvp controller](/_machine-assets/57c9e516f88e0b13ed6edcf037904b8935ad5d3ba5387b7eb1d2b41893885aaf.png) _Example: Server page_ ## Menus ### Alarms The **Alarms** menu is a link to a page that centralizes alarms and events. There are other types of alarm pages (services, failover, etc.) that show alarm information in a similar table display. **Related information**\ [Manage alarms and events](/beam/system-admin/maintenance/alarms-events) ### Templates Templates are saved service configurations. Templates simplify the creation of services that share common settings and ensure configuration consistency across services. This menu only displays if Live Encoder component is used.

You can edit any service configuration, even if the parameters were created from a template. Deleting a template has no impact on existing services created from that template. Configurations and parameters in templates vary per service type.

**Related information**\ [Create a service from a template](/beam/live-encoder/create-service#create-a-service-from-a-template) ### Failover You can configure **Failover** settings and groups for redundant systems. Go to the Failover display table to view running states and alarm statuses. ![menu failover](/_machine-assets/1529f1831f28ba7dbc534c7038668e9c20e4e0220e93e1ec95a38711d8704fcf.png)
  • All timestamps are in Universal Time (UTC) but you can customize them (see Alarm display time).
  • To optimize performance, do not exceed 100 servers per failover group.
**Related information**\ [Manage failover](/beam/system-admin/servers/failover) ### Reports The reports menu provides access to specific information. You can export the report to a .csv file.

Menu displays vary depending on your product installation.

### Settings You can access additional menus from the **Settings** menu. This menu only displays if the Packager or Live Encoder components are used. **Related information**\ [Service settings](/beam/system-admin/maintenance/service-settings) ### Health The Controller utilizes Prometheus and Grafana to enhance monitoring capabilities. The Health page presents a dashboard with various indicators to effectively monitor your solution. This page will look different depending on the deployment type. - The **At a glance** section displays key indicators for the Controller framework and service health including **Disk Space Used**. Alarms are triggered at 60% disk space usage, with critical alarms at 90%. Health indicators are also provided for the key-value store (etcd), the database (Mongo) and the message queue (Rabbit), as well as uptime CPU, CPU and memory usage. - Details on any alerts raised by the Controllers are also shown. - Additional expandable indicators offer more detailed information for advanced troubleshooting. At the top of the page, variables allow control over the displayed data. The **Data source** is particularly useful as it determines which Controller is used to serve the data. ![controller health](/_machine-assets/c7feb0e31f7b7bd6c2803738e7a8e0d3d2d1aeccf7a133d8d3260811eed1a7a6.png) ### External links to third-party tools Access third-party tools directly from the Controller. Once added to the system, external links are available from the left side menu panel. # Manage services A service is a set of parameters required for a given processing type. Services can be manually started and stopped. You can access services from the **Home** page dashboard or the left-side menu panel. ## Display services Services are listed in a table and are associated to a specific processing type. Service parameters and options depend on the processing type. Before you start: ensure at least one service is configured. To display services, follow these steps: 1. Click **Services** in the left-side menu panel. The table of services displays. 2. To easily find a service or refine the display, you can then: - Use the [search bar](/beam/web-interface/navigation#use-the-search-bar); - Filter by specific fields (such as tag, status, processing types, resource, source, animation, alarm level); - Show/hide columns by clicking `Ellipsis` icon at the right of the table headings; - Sort the table using the up and down arrows next to each column heading. ## Edit a service To edit a service, just click the name. It takes you to the service editing page. ## Create a service Service configurations vary per processing type. See the specific component documentation for detailed information about service creation. 1. From the **Services** page, click **Add Service**. 2. Select a processing type. The service parameter options display. 3. You can configure the service parameters. 4. Once you have completed the service configuration, click **Save and exit**. 5. You can [assign a server](/beam/web-interface/services#assign-a-server-to-run-the-service) to the service. Multiple servers may be assigned to a same service. 6. You can use the buttons in the action column to [start](/beam/web-interface/services#start-a-service) or [stop](/beam/web-interface/services#stop-a-service) the service. ## Assign a server to run the service Services require a server to run. Select a server for each service before starting the service.

For failover configurations:

  • Failover only applies to certain processing types and configurations.
  • Inactive backup servers (in a failover group) cannot be assigned to run a service.
  • A primary server (in a failover group) that is in failover, meaning that a backup server has taken over and it is no longer running services, cannot be assigned to run services.
### Typical use case, a service is assigned to one or more servers 1. From the **Services** page, click **Add Server** in the **Resources** column to display the available servers. 2. Tick one or more servers from the list then click **Save**. The selected servers are shown in the **Resources** column. 3. You can start the service. ### In case of redundant outputs (Live Encoder) 1. From the **Services** page, go to the **Resources** column then click **Add Server** to display the available servers. 2. Select a server from the list then select either **Set Primary** or **Set Secondary**. **Related information**\ [Create redundancy variants](/beam/live-encoder/configure#create-redundancy-variants) ### In case of variants (Live Encoder) 1. From the **Services** page, go to the **Resources** column. 2. Only servers that match the server tags for subsets are offered. 3. Select a server from the list. **Related information**\ [Create server variants](/beam/live-encoder/configure#create-subset-variants) ### In case of variants and redundant outputs (Live Encoder) 1. From the **Services** page, go to the **Resources** column. 2. Only servers that match the server tags for subsets are offered. 3. Select a server from the list then select either **Set Primary** or **Set Secondary**. **Related information**\ [Create server variants](/beam/live-encoder/configure#create-subset-variants)\ [Create redundancy variants](/beam/live-encoder/configure#create-redundancy-variants) ## Unassign a server from a service 1. From the **Services** page, go to the **Resources** column. 2. Select a server then click **X** next to the server name. The server is removed and is unassigned from the service.

Jobs that are running on an unassigned server are canceled and put back in the queue to be started again on another server.

## Export a service configuration Exported service configurations are for importing onto a **different MediaKind** system. This is useful for component or production support, or testing (parameters and expected function).

Exports exclude the service state (started or stopped). Importing service configurations may require manually starting or stopping other services.

From the **Services** page, click `Ellipsis` icon in the **Actions** column then click `Download` icon to export. A file will download in your browser's default location.

The download date in the file name is in the following format: YYYY/MM/DD.

Multiple services can be exported at once (See the [Bulk Actions](/beam/web-interface/services#bulk-actions) section). The services selected do not need to all be of the same type. Once you have selected your services click `Ellipsis` icon in the **Actions** column of any service then click `Download` icon to export. This will download a tar.gz file containing all the configurations of the selected services.

The download tar.gz file will always be called service_exports_YYYY-MM-DD.tar.gz.

## Import a service You can import a single service, or multiple services to a different server where the service is not currently configured. Import files must match expected formatting requirements. The supported files are:
File extension Description
json A single service configuration
tar An archive containing several json files
tar.gz / tgz A compressed archive containing several json files
zip A zipped archive containing several json files

Archives must only contain json files.

Before you start, ensure that the exported configuration files for the services are available. (See the [Export a service configuration](/beam/web-interface/services#export-a-service-configuration) section)

Services on a same server require unique ids. Only import the service to a server where the service DOES NOT currently exist. If there is a conflict detected during import, you will be given the option to overwrite the existing service.

1. From the **Services** page, click the **Import services...** button. 2. Click **Select files** to browse for the .json or .tar.gz file previously exported for this service or services. You may select multiple files. 3. Click **Import**. The services are imported and appear in the list of services. 4. Click **Close** to close the import dialog. If there are any errors during the import, you will be given the option to ignore, continue or ignore all.

If you select to ignore all errors, the import process will continue to completion without stopping on future errors.

Importing a lot of files can take several minutes to complete. During the import process DO NOT navigate away from the import page.

## Start a service Services can be started and stopped manually from the **Services** page. Before you start: At least one service has been created and is available in the list of services, and at least one server is assigned to run the service. From the **Services** page, click `Play outline` icon in the **Actions** column to launch the service. The **Status** changes to **started**.

If an alarm is raised, click Alarm icon to display all alarms. Alarm colors are based on severity.

## Stop a service Stop a service manually for support, testing or for general system administration purposes. Once stopped, the assigned server no longer executes the service.

Stopping a service cancels any jobs in progress.

1. From the **Services** page, click `Stop outline` icon in the **Actions** column to stop the service. You are prompted to confirm. 2. Click **Yes, Stop it!**. The service status changes to **stopped**. The service stops running. ## Copy a service From the **Services** page, click `Ellipsis` icon in the **Actions** column then select `Clone` icon to copy the service. A "-copy" suffix is added to the name of the duplicated service.

You can simultaneously select and copy several services at once (see Bulk actions).

## Delete a service Deleting a service removes a service from the list of available services.

For detailed information regarding a Live Packaging service deletion, see Deleting a Live Packaging service and managing DVR.

1. From the **Services** page, click `Ellipsis` icon in the **Actions** column then select `Delete` icon to delete the service. 2. Click **Yes, delete it!** to confirm. The service is removed from the services table and is no longer available. ## Failover or revert a service If a service is running on a server that is in a service-level failover group, a manual failover/revert can be triggered. For information on this, please refer to the [Request a failover or a revert between servers manually](/beam/system-admin/servers/failover#request-a-failover-or-a-revert-between-servers-manually) section. ## Bulk actions Some operations support bulk actions. You can select multiple services by ticking the corresponding boxes, or you can select all services on the page by ticking the box next to the **Name** column. Then, you can apply bulk operations such as start, stop, copy, and delete. Stopping or deleting multiple services will prompt a warning message.

You can use the search bar, filter by specific fields, or sort the table using the up and down arrows to refine the services displayed before performing a bulk action..

## Configure advanced parameters for an existing service 1. From the **Services** page, click the service name to edit the service then click the **Advanced parameters** tab. 2. Click **Add** then enter the parameter name and value. You can add multiple advanced parameters to the service. 3. Click **Save and continue** before continuing in order to avoid losing the configuration. # System and architecture description The web interface provides a single access point to monitor components, manage users, and configure solutions from end-to-end. Configuration and control are separated for flexible resource allocation ## Software and applicative layers The platform design relies on a **micro-services architecture** to promote modularity and software component independence. The solution is split into a Front-End (UI) and a Back-End (API) layer. Each layer is interfaced through a REST API. ![schema architecture controller](/_machine-assets/b21864c984435d81317da08599bdda7f4c0638d85f2aed0724e46a56d3c25ad9.png)

If menus or options in the web interface are grayed then contact your administrator about user rights.

### UI Layer (Front-End) The generic UI framework provides a same environment to display the web pages for all compatible products: - Web pages (services, servers, etc.) are shared across the product line. - Certain web pages are specific to each processing type (statistics, services, etc.). ### API Layer (Back-End) The Back-End features are triggered through a REST API that can be used either from a _Command Line Interface_, or from the Front-End Layer. The API layer allows: - A centralized redundant database. - The logic handling for cross-products and product specific features. ## High availability Management access is provided through a Virtual IP, allowing for a **single connection access**. This is based on an **active/active** implementation that ensures high availability. ![schema active active controller](/_machine-assets/3808fae2fa70f6bf10781077dd45a18a3cf413ee5e4058bf37bd3c7434c1901a.png) The **database is synchronized in real-time** between both nodes. **In case of failure, the remaining node is instantly ready** to process requests. If the primary server fails, then the Virtual IP is seamlessly re-assigned to the secondary server. **This mechanism involves _arbiter_ software**, installed on a separate server. This arbiter server is in charge of electing the primary database if the network is partitioned (in the event of communication loss between synchronized databases). # Manage templates Templates are a set of parameters saved from an existing service configuration. This allows you to easily create new services that share the same settings. You can create a template from an existing service configuration. The template is stored separately from the services.\ Service templates include: - Constants: all parameters that are common to all services sharing the template. - Variables: parameters that depend on the service. Selecting a template when creating a service replaces the default settings with the template presets. It still requires entering missing variable information identified in the user interface.

You can export variables to a CSV file for mass configuration.

Changing a template requires: - Changing the template name. - Version management is implemented (can embed versions). ## Display templates 1. Click **Templates** from the left-side menu panel. If any, the available templates display in a table. ![view templates home controller](/_machine-assets/73a8852adb808b1342165ddca5fc3b2d61097ac94a1675b894ee1d9bf3c53cb1.png) 2. You can edit the number of rows displayed or use the search bar to filter the display. ### Template parameters
Column Description
Name Unique template name.
Processing Type The service processing type.
No. of Services Total number of services in your solution that are configured with the template.
Creation date Template creation date (YYYY-MM-DD) and time (HH:MM:SS).
Actions Export or delete.
## Create a template To create a template, follow these steps: 1. [Display services](/beam/web-interface/services#display-services). 2. Click `Edit` icon and ensure that service parameters comply to expected configurations. 3. From the **Services** page, Click the 3-vertical dots icon then select **Save as template**. 4. Enter a unique **Name** and click **Create**. 5. [Check that the template displays in the **Templates** table](/beam/web-interface/templates#display-templates). 6. You can [create a new service from the template](/beam/web-interface/templates#create-a-new-service-from-a-template). ## Delete a template

Deleting a template has no impact on services created from that template.

To delete a template, follow these steps: 1. Display templates. 2. Click `Delete` icon in the **Actions** column. 3. Confirm the action if prompted. The template is deleted and no longer displays in the table. ## Create a new service from a template When creating a new service, you can apply a template to automatically insert existing service configuration parameters.

You can edit any service settings, even if the service was created from a template.

Before you start, [ensure a template already exists](/beam/web-interface/templates#display-templates). 1. Click **Services** in the left-side menu panel. 2. Click **Add service** then select a service type from the list to display options. 3. Next to the **Template** parameter, select a template from the list of available templates. 4. Click **Save**. The service is created and displays in the **Services** grid. 5. Click `Edit` icon to edit or to check the service configuration for accuracy. ## Export a template You can export templates to share them on different MediaKind Controllers. 1. [Display templates](/beam/web-interface/templates#display-templates). 2. Click ![button export template mfvp controller](/_machine-assets/71e457044d160a03f4e7c024c8b1ea6af4f52c7cf35d00cd5266890ea4ccbc3c.png) to export. The file is downloaded in relation to your web browser download settings.

The download date is in the downloaded file name. The date is in the following format: MM/DD/YYYY.

## Export a template variables form You can download template variables to use in massive configurations. 1. [Display templates](/beam/web-interface/templates#display-templates). 2. Click ![button export form template mfvp controller](/_machine-assets/2b9e7ec6a9230a44dcf98d42b82e584c59d33736a15f0554ce1d95d4c67d98da.png) to export. A .csv file is downloaded in relation to your web browser download settings.

The download date is in the downloaded file name. The date is in the following format: MM/DD/YYYY.

## Import a template Before you start, ensure a template file exported from a different Controller environment is available. 1. [Display templates](/beam/web-interface/templates#display-templates). 2. Click **Actions**. 3. Select **Import template**. ![button actions import template mfvp controller](/_machine-assets/283b3c6fa8324aad12b0b5a0eee21be5759c4bd1f7bc39c4456c2d65f0877661.png) 4. Click **Select file** to choose a file, then click **Import**. ![view import service mfvp controller](/_machine-assets/f27b4e20492e77b16763b276831b1d809a544f4016b0d968bad52aa36646e5a2.png) The template is uploaded and available in the **Templates** table.
  • Template names must be unique.
    • You are unable to import a template if the template with the same name already exists on this Controller.
# Welcome to MK.IO MK.IO is a cloud-native media transformation and delivery application designed for building and operating modern video services. It provides a scalable SaaS environment with both UI and API control for end-to-end media processing workflows. ## Start a workflow [Live stream in five minutes](/mkio/getting-started/live-stream-in-five-minutes) Create a live event, connect an RTMP source, and open a playback URL. [Publish your first VOD asset](/mkio/getting-started/video-on-demand-vod-workflows) Upload, process, and publish a video for on-demand playback. [Connect cloud storage](/mkio/getting-started/connect-cloud-storage) Connect the storage MK.IO uses for source files, outputs, and live recordings. [Make your first API call](/mkio/api-guides/getting-started/first-api-call) Authenticate and retrieve your MK.IO organizations and projects. ## Find a product area The guide names below reflect the main areas of the MK.IO portal. [Assets and storage](/mkio/how-to/content-management) Add, import, organize, verify, and publish media assets. [Live events](/mkio/how-to/live-streaming) Configure live events and connect OBS, FFmpeg, or GStreamer sources. [Video processing](/mkio/how-to/video-processing-encoding) Configure reusable transforms and run processing jobs. [Streaming endpoints and playback](/mkio/how-to/content-delivery-publishing) Publish assets, retrieve playback URLs, and integrate delivery services. [Content key policies](/mkio/how-to/drm-content-protection) Protect live and VOD playback with encryption and DRM policies. [API Guides](/mkio/api-guides) Build media, management, fleet, and infrastructure workflows with the APIs. ## Learn and look up - [What is MK.IO?](/mkio/getting-started/what-is-mkio) - [Concepts](/mkio/understanding/overview-understanding) - [Reference](/mkio/reference/reference) - [Changelog](/mkio/changelog) - [Community and support](https://support.mk.io) # MK.IO API guides Build media processing, live streaming, and account-management workflows with the MK.IO APIs. ## Getting Started Prepare your environment, authenticate your API calls, and learn how the platform represents resources. [Quick Start & Authentication](/mkio/api-guides/getting-started/authentication) Get your API credentials, authenticate your requests, and make your first API call. [Shared Concepts](/mkio/api-guides/understanding/overview) Understand platform-wide concepts like pagination, rate limiting, error handling, and resource states. ## Media API Ingest, transcode, package, protect, and publish live and on-demand video assets. [Media API Reference](/api-reference/media-api) Interactive endpoints, schemas, and request/response examples for the Media API. [Automate a VOD Pipeline](/mkio/api-guides/how-to/media/vod-pipeline) A complete recipe from upload through encoding and packaging to playout. [Storage](/mkio/api-guides/how-to/media/storage) Configure input and output storage containers. [Assets](/mkio/api-guides/how-to/media/assets) Upload media files and track asset lifecycles. [Transforms & Jobs](/mkio/api-guides/how-to/media/transforms-and-jobs) Define transcode settings and submit transcode jobs. [Live Streaming](/mkio/api-guides/how-to/media/live-streaming) Configure live events, inputs, outputs, and streaming channels. [Publishing & Delivery](/mkio/api-guides/how-to/media/publishing) Create streaming locators and construct playback URLs. [Content Protection](/mkio/api-guides/how-to/media/content-protection) Apply DRM and content key policies to secure streams. ## Management API Control organizations, users, teams, projects, webhook notifications, and usage reporting. [Management API Reference](/api-reference/management-api) Endpoints, schemas, and request/response examples for organization management. [Provision Organizations & Users](/mkio/api-guides/how-to/management/org-provisioning) Bootstrap organizations, structure projects, and define team memberships. [Tokens](/mkio/api-guides/how-to/management/tokens) Create and rotate personal access tokens. [Webhook Rules](/mkio/api-guides/how-to/management/webhooks) Configure HTTP callbacks to receive event-driven notifications. [Usage & Billing](/mkio/api-guides/how-to/management/usage-and-billing) Query billing telemetry and track resource consumption. ## Live API Create and manage live channels, events, and multiview compositions for live media processing. [Live API Reference](/api-reference/live-api) Endpoints, schemas, and request/response examples for live media processing. [Core concepts](/mkio/api-guides/how-to/live/core-concepts) Understand resource types, billing models, and how live resources connect to templates and sources. [Live channels and events](/mkio/api-guides/how-to/live/manage-live) Create and operate liveChannels and liveEvents for single-input live encoding. [Multiview](/mkio/api-guides/how-to/live/multiview) Compose multiple live inputs into a single multiview output. [Scheduled operations](/mkio/api-guides/how-to/live/scheduled-operations) Automate start and stop times for any live resource. ## Templates API Manage the versioned configuration templates that live encoding, multiview, and stream conditioning resources depend on. [Templates API Reference](/api-reference/templates-api) Endpoints, schemas, and request/response examples for the Templates API. [Manage templates](/mkio/api-guides/how-to/templates/manage-templates) Create, version, tag, and reference configuration templates. Start from presets or upload your own. # Get started with the APIs Use these guides to choose the right API, create a personal token, and confirm your access with a first request. [Which API to use](/mkio/api-guides/getting-started/which-api) Match your workflow to the Media, Live, Templates, or Management API. [Authentication and tokens](/mkio/api-guides/getting-started/authentication) Create a personal API token and send it with your requests. [Your first API call](/mkio/api-guides/getting-started/first-api-call) Make one authenticated request to confirm your token and project access. # Authentication and tokens The MK.IO APIs use bearer authentication. You create a personal API token in the MK.IO web application, send it in the `Authorization` header, and the request runs with the same organization and project access as the user who created it. ## Create a personal token Create a token in the MK.IO web application: 1. Open the profile menu in the top right corner and select your email address. 2. Go to [**Your personal API tokens**](https://app.mk.io/user/profile). 3. Select **Add Token**. 4. Enter a description and an expiration date in UTC. 5. Select **Create**. 6. Copy the token to a secure location. It is visible for 5 minutes only. For the full token-management pages in the MK.IO product, see [API tokens](/mkio/how-to/managing-your-organization/api-tokens). ## What a personal token represents The personal token contains: - The identity of the user. - The identity of the organization. - The token type and expiration date. - Optionally, a reduced set of permissions when the token grants only a subset of the user's access. The token therefore carries the access of the user who created it. When that user's access changes, the token's effective access changes with it. ## Send the token with every request Every MK.IO API uses the same header: ```http Authorization: Bearer ``` For requests that carry a body, send JSON headers as well: ```http Content-Type: application/json Accept: application/json ``` A complete request looks like this: ```bash curl -X GET "https://app.mk.io/api/v1/projects//media/assets" \ -H "Authorization: Bearer " \ -H "Accept: application/json" ``` Replace `` with the project you want to query and `` with the token you created. ## Base URL The MK.IO APIs share one base URL: ``` https://app.mk.io ``` Combine it with the path for the endpoint you want to call, for example: ``` https://app.mk.io/api/v1/projects//media/assets ``` ## A practical local setup When you work from the command line, export the values you reuse: ```bash export MKIO_TOKEN="" export MKIO_PROJECT="" export MKIO_BASE_URL="https://app.mk.io" ``` Then reference them in later commands: ```bash curl -X GET "$MKIO_BASE_URL/api/v1/projects/$MKIO_PROJECT/media/assets" \ -H "Authorization: Bearer $MKIO_TOKEN" \ -H "Accept: application/json" ``` This keeps the examples short and makes it easier to switch projects or rotate tokens. ## Keep tokens out of source code A token grants MK.IO access to anyone who holds it, so treat it as a secret: - Do not commit tokens to source control. - Do not embed them in client-side code or public applications. - Rotate and replace them if they are exposed. - Use a narrower token type when you want to reduce the blast radius. See [Tokens](/mkio/api-guides/how-to/management/tokens) for the Management API workflow. ## Next steps - [Your first API call](/mkio/api-guides/getting-started/first-api-call): confirm that your token and project access work. - [Tokens](/mkio/api-guides/how-to/management/tokens): create, inspect, and revoke tokens through the Management API. - [Which API to use](/mkio/api-guides/getting-started/which-api): choose the API that owns the resources in your workflow. # Your first API call Before you build a larger integration, confirm your setup with one request. The goal is to make a single authenticated call against a project-scoped endpoint, inspect the response, and prove that your token and project access work. ## Prerequisites You need: - An MK.IO account with access to at least one project. - A personal API token. - The name of the project you want to query. If you still need a token, follow [Authentication and tokens](/mkio/api-guides/getting-started/authentication). ## Set the values you reuse Export the values the request needs, so the command stays readable and retries are less error-prone: ```bash export MKIO_BASE_URL="https://app.mk.io" export MKIO_PROJECT="" export MKIO_TOKEN="" ``` ## Send the request Run the Media API list-assets operation: ```bash curl -X GET "$MKIO_BASE_URL/api/v1/projects/$MKIO_PROJECT/media/assets" \ -H "Authorization: Bearer $MKIO_TOKEN" \ -H "Accept: application/json" ``` To see the HTTP status line as well, add `-i`: ```bash curl -i -X GET "$MKIO_BASE_URL/api/v1/projects/$MKIO_PROJECT/media/assets" \ -H "Authorization: Bearer $MKIO_TOKEN" \ -H "Accept: application/json" ``` ## Check the response A successful response is HTTP `200` with a list body. List endpoints return two top-level fields: - `value`: the returned assets. - `supplemental`: list metadata, including `supplemental.pagination` with the record counts. ```json { "value": [ { "name": "example-asset" } ], "supplemental": { "count": 1, "kind": "Asset", "operation": "list", "pagination": { "start": 0, "end": 1, "records": 1, "total": 1 } } } ``` Many MK.IO list endpoints use this same shape, so it is worth recognising now. See [Pagination and filtering](/mkio/api-guides/understanding/pagination) for how to page and narrow these responses. ## If the call does not succeed This endpoint returns the platform's standard error responses:
Status code Meaning What to check next
400 Bad Request Recheck the URL, query parameters, and request syntax.
401 Unauthorized Recheck the bearer token and Authorization header.
403 Forbidden Recheck that the user has access to the target project and operation.
404 Not Found Recheck the project name and path.
429 Too Many Requests Slow down and retry later.
500 Internal Server Error Record the response ref value before retrying or contacting support.
The error body carries `error.code` for programmatic handling, `error.detail` for logs, and `ref` for support follow-up. See [Error handling](/mkio/api-guides/understanding/error-handling) for the full model. ## What this confirms A successful request proves that your token is valid, your base URL is correct, your project name is correct, and you can reach a real project-scoped endpoint. That is enough to move on to resource creation with far less guesswork. ## Next steps - [Which API to use](/mkio/api-guides/getting-started/which-api): choose the API that owns your workflow. - [API overview](/mkio/api-guides/understanding/overview): the patterns shared across the APIs. - [Build with the Media API](/mkio/api-guides/how-to/media): move into storage, assets, transforms, jobs, and publishing. # Which API to use Choose an MK.IO API based on the resource you need to manage, not the kind of code you are writing. The cloud APIs share a base URL and bearer authentication, but they own different parts of the platform and are often combined in a single automation flow. ## Start with the workflow Use this table for a quick answer:
To automate... Use the...
Reusable content, sources, destinations, storage registration, assets, transforms, jobs, Media API live events and live outputs, streaming locators, streaming endpoints, streaming policies, or content key policies Media API
Template-based live channels, live events, and static multiview resources Live API
Discover encoding presets, create reusable configs, and manage config versions Templates API
Organizations, projects, users, teams, tokens, payment methods, usage reports, metrics, or webhook rules Management API
## How the APIs fit together The APIs are separate, but the workflows connect: 1. Use the **Management API** to create a project and assign billing. 2. Use the **Media API** to process or publish content inside that project. 3. Use the **Management API** again to add webhook rules, so your integration reacts to events instead of polling. A complete platform integration typically uses the Management API for setup, then the Media, Live, or Templates API for day-to-day operations. ## Media API The Media API owns media processing and delivery, and it is where most developers start. Reach for it to ingest, encode, package, protect, or stream content. Its resources include storage instances and credentials, assets and asset filters, transforms and jobs, live events and live outputs, streaming locators and endpoints, and streaming policies and content key policies. ## Live and Templates APIs Use the Live API for the resources shown in the portal's **Live** view: live channels, live events, and static multiview channels and events. The Templates API supplies the encoding and composition configs they reference. The Media API supplies their sources, content, destinations, recording assets, and playback resources. Start with the [Live event walkthrough](/mkio/api-guides/how-to/live/walkthrough) for one camera or the [Multiview walkthrough](/mkio/api-guides/how-to/live/multiview/multiview-walkthrough) for a composed output. Existing integrations using `/media/liveEvents` and `/media/liveEvents/{event_name}/liveOutputs` use the separate [Media live-streaming workflow](/mkio/api-guides/how-to/media/live-streaming), shown under **Live Events** in the portal. ## Management API The Management API owns organization and project administration: access, billing, and account-level configuration. Reach for it to provision an environment, assign permissions, issue tokens, or configure event delivery. Its resources include organizations and projects, users and invites, teams, roles and scopes, personal and organization tokens, payment methods, usage and metrics, and webhook rules. ## Common combinations
Workflow APIs involved
Build a template-based live or multiview stream Media API for sources and publishing, Templates API for configs, Live API for processing
Create a project, assign billing, then start a VOD workflow Management API, then Media API
Register a webhook for job-completion events Management API and Media API
Audit token usage and restrict automation access Management API
## Next step Once you know which API owns your workflow, make one authenticated request before you build anything larger. [Your first API call](/mkio/api-guides/getting-started/first-api-call) is the quickest way to confirm that your base URL, token, and project access are correct. # API workflow guides Choose the API for your workflow. [Media API](/mkio/api-guides/how-to/media) Open the Media API workflow guides. [Live API](/mkio/api-guides/how-to/live) Open the Live API workflow guides. [Templates API](/mkio/api-guides/how-to/templates) Open the Templates API workflow guides. [Management API](/mkio/api-guides/how-to/management) Open the Management API workflow guides. # Live API The Live API manages live encoding and multiview composition in MK.IO. It gives you programmatic control over the full lifecycle of a live stream: from accepting ingest, through encoding or composing, to writing output into an asset and optionally delivering it to a downstream system. To see the API working before reading the full model, start with the [walkthrough](/mkio/api-guides/how-to/live/walkthrough). It builds a complete `liveEvent` and links back to the relevant concepts. ## What this API does The Live API sits between your ingest sources and your published streams. You use it to define what the platform should do when a live feed arrives and where the result should go. With the Live API you can: - Accept live feeds from sources configured in the Media API (SRT, UDP, SDI, or HLS) - Encode live video according to a versioned template you define - Compose multiple live feeds into a single tiled multiview output - Write encoded output to an MK.IO asset for recording and live-to-VOD - Push live output to downstream destinations over SRT or RTMP - Schedule automatic start and stop windows for any live resource - Monitor running resources through sampled state, metrics, and thumbnail URLs ## When to use the Live API Use the Live API when you need to encode or compose a live stream programmatically. It is the right API for: - **Continuous live channels**: A 24/7 broadcast feed that is always encoding - **Scheduled live events**: A broadcast that starts and stops at defined times, billed per minute - **Multiview production**: Taking multiple camera feeds and composing them side by side in a single output. - **Automated live workflows**: Integrations that create, start, stop, and monitor live resources without manual steps ## How it differs from Media API live events The Media API has its own, separate `liveEvents` resource for ingest and packaging. It is not the same resource as the Live API's `liveEvents`. They live under different base paths (`/media/liveEvents` vs. `/live/liveEvents`), and a resource created in one is invisible to the other. ### Media API workflow The Media API sets `encodingType` directly on a `liveEvents` resource, for example `PassthroughBasic` or `Premium1080p`. Recording uses a nested live output and an asset, and playback uses a streaming locator and streaming endpoint. It does not require a Templates API config. ### Live API workflow The Live API's `liveChannels` and `liveEvents` reference a source or content resource from the Media API, an `encodingLive` config from the Templates API, and an output asset. This separates input connections from reusable encoding settings and the processing lifecycle. If you only need basic live ingest and packaging with no separate template to manage, start with the [Media API live streaming guide](/mkio/api-guides/how-to/media/live-streaming). If you need custom, reusable encoding templates, multiview, scheduled automation, or sampled monitoring of the encoding pipeline, use the Live API described on this page. ## Resource types The Live API provides four resource types. All four share the same structure and lifecycle; the difference is in what they do and how they are billed.
Resource Billing Purpose
liveChannels Monthly flat fee Continuous 24/7 live encoding
liveEvents Per-minute Time-bounded live encoding
staticMultiviewChannels Monthly flat fee Continuous 24/7 multi-input composition
staticMultiviewEvents Per-minute Time-bounded multi-input composition
The Channel variants run until you stop them and are billed at a flat monthly rate the moment they start. The Event variants are ideal for scheduled broadcasts because they use per-minute billing. ## What the Live API depends on The Live API does not work in isolation. Before you create a live resource, you need resources from two other APIs: ### Media API resources The Media API manages your connections to the outside world. Your camera feeds, the storage container for your recordings, and any downstream systems you push output to are all defined here. The Live API references them by name but does not create or manage them. - **Sources**: define how each live feed physically arrives at the platform, including the transport protocol, network, and connection settings. Create a source for each camera or ingest point before creating a live resource. - **Assets**: live resources write encoded output into an MK.IO asset. You create the asset first, then name it in the live resource spec. This is also where recordings end up for playback and live-to-VOD. - **Destinations**: optional. If you want to push output to a downstream system (an RTMP or SRT endpoint), define a destination in the Media API and reference it from your live resource output. ### Templates API resources The platform needs to know how to encode your live feed: codec, bitrate, resolution, frame rate, and more. Rather than embed all of that complexity into every live resource you create, you upload these settings once as a template, give it a name, and reference it. This means you can share the same encoding settings across many resources without repeating them. - **encodingLive template**: required for every live resource. Holds the encoding parameters: how the platform compresses and packages your output. - **multiviewComposing template**: optional, multiview only. Defines the composition layout (how multiple camera feeds are arranged on screen), separately from the encoding settings. Useful when different events need different layouts but the same encoding configuration. ## Start an SRT listener input For SRT listener inputs, prepare the encoder with the source URL and connection settings. Request `Running`, begin contribution, and poll until startup completes. A resolved input or `Active` source confirms assignment or use. Verify the expected video and audio through playback as well. ## API overview
Detail Value
Base path /api/v1/projects/{project_name}/live/
Scope Project
Reference Live API reference
## Guides New to the Live API? Start with the walkthrough for a hands-on introduction, then read Core concepts for the full model. [Live event walkthrough](/mkio/api-guides/how-to/live/walkthrough) A complete, hands-on example: source, asset, and template through to a running, playable liveEvent. [Core concepts](/mkio/api-guides/how-to/live/core-concepts) Resource types, billing models, inputs and outputs, transform types, and how templates connect to live resources. [Manage live channels and events](/mkio/api-guides/how-to/live/manage-live) Create, start, stop, and delete liveChannels and liveEvents with context for each step. [Multiview](/mkio/api-guides/how-to/live/multiview) Compose multiple live inputs into a single output. Covers concepts, both composition modes, and end-to-end setup. [Scheduled operations](/mkio/api-guides/how-to/live/scheduled-operations) Automate start and stop times for any live resource without manual intervention. [Monitor live resources](/mkio/api-guides/how-to/live/monitor-live) Check resource state, read metrics, and access thumbnail and metadata monitoring URLs. # Core concepts The Live API is built around a small set of ideas that appear in every resource you create. If you'd rather start hands-on, the [live event walkthrough](/mkio/api-guides/how-to/live/walkthrough) covers the same concepts in the context of a working example, and links back here wherever more depth is useful. ## Guides [Resource types and lifecycle](/mkio/api-guides/how-to/live/core-concepts/resource-types) The four resource types, billing models, the desired state model, and sites. [Inputs](/mkio/api-guides/how-to/live/core-concepts/inputs) Connecting a live resource to a stream: `sourceName`, `contentName`, `flowName`, refiners, and transform pins. [Outputs](/mkio/api-guides/how-to/live/core-concepts/outputs) Where encoded output goes: destinations, internal outputs, and the archive asset. [Templates](/mkio/api-guides/how-to/live/core-concepts/templates) How encoding templates connect to live resources, and the `configValues`/`configOverrides` model. [Resource states](/mkio/api-guides/how-to/live/core-concepts/resource-states) `spec.state` vs. `status.state`, and what the 13 reported values mean. ## What the Live API depends on The Live API references two other APIs by name but doesn't manage them directly: - **Media API**: sources, content, destinations, and assets. See [Content, sources, and destinations](/mkio/api-guides/how-to/media/content-and-sources). - **Templates API**: the encoding and composition templates referenced from your live resources. See [Build with the Templates API](/mkio/api-guides/how-to/templates). ## What comes next - [Live event walkthrough](/mkio/api-guides/how-to/live/walkthrough): a complete end-to-end example. - [Manage live channels and events](/mkio/api-guides/how-to/live/manage-live): create and operate liveChannels and liveEvents. - [Multiview](/mkio/api-guides/how-to/live/multiview): compose multiple live inputs into a single output. # Inputs An input connects a live resource to a stream. You define inputs as a list in `spec.inputs`, and each input specifies exactly one source of stream data. You choose exactly one of three fields per input. They are mutually exclusive, so you cannot mix them in a single input entry:
Field Connects to Use when
sourceName One specific, named source resource (Media API) You know exactly which physical feed you want, and it won't change.
contentName A content identifier, resolved to a candidate source that can supply it (Media API) The physical source behind the feed might change, and you want the platform to resolve among available candidates.
flowName Another live resource's output You are chaining resources together, feeding the output of one flow into another.
Before defining an input, retrieve the created config and copy its `status.inputPins[].name`. Replace `` in the following examples with a returned pin name. A single camera with a direct source reference uses: ```json "inputs": [ { "sourceName": "camera-1-source", "transformInput": "" } ] ``` A setup where several sources can supply the same logical content instead references their shared content name: ```json "inputs": [ { "contentName": "camera-1", "transformInput": "" } ] ``` In both cases, the live resource keeps the same processing config. `contentName` lets the platform resolve among candidates, but it does not guarantee seamless media-aware failover. ## Flow input refiners When an input uses `contentName`, the platform has to pick one specific source (or another flow's output) to actually supply it. See [Resolving content](/mkio/api-guides/how-to/media/content-and-sources#resolving-content) for how that resolution works by default. A `refiner` narrows that choice further, without you having to switch to a hard-pinned `sourceName` or `flowName`: ```json "inputs": [ { "contentName": "camera-1", "transformInput": "", "refiner": { "flow": { "name": "upstream-encode" } } } ] ``` There are two kinds of input refiner. **`flow`** restricts resolution to a single named upstream flow, the same "another live resource's output" concept as the `flowName` field above, useful when several flows could technically supply the same content but you want this input fed by one specific one, without giving up the flexibility of `contentName` resolution entirely. **`labelMatch`** restricts resolution to sources or flows carrying a specific label `key` and `value`, useful when you tag a group of resources and want an input to resolve to whichever one of them is currently reachable, rather than a single fixed name. ```json "refiner": { "labelMatch": { "key": "region", "value": "eu-west" } } ``` Refiners only apply to inputs today. The Live API schema also defines a `refiner` field on outputs and on the flow as a whole, but both are currently empty placeholders reserved for future functionality, setting them has no effect yet. ## What transform pins are Every input has a `transformInput` field. This field names the slot, or **pin**, in the processing config that receives the stream. Single-input resources bind one input to one pin. Multiview resources bind several inputs to separate pins. Think of pins as labelled input jacks on a mixing desk. Your `encodingLive` template defines how many inputs it expects and what each one is called. The `transformInput` value on each flow input tells the platform which jack to plug that camera feed into. If you send four camera feeds, each one gets routed to a different named pin, and the template decides how they are arranged on screen. ### Get pin names Pin names come from the config itself. After creating a config, retrieve it and read `status.inputPins[].name`. Use those exact values for `transformInput`. Presets and configs can change, so do not treat a pin name from an example as universal. ### Check multiple bindings Each pin also reports `allowMultipleBindings`. If it's `false`, only one input can target that pin, a second input pointed at the same pin is a conflict, not a merge. If it's `true`, the template has been built to accept more than one input on that pin. Check this before assuming you can route two feeds to what looks like the same slot. Inspect your created config before assigning an input to a pin. ## What comes next - [Outputs](/mkio/api-guides/how-to/live/core-concepts/outputs): where encoded output goes. - [Content, sources, and destinations](/mkio/api-guides/how-to/media/content-and-sources): create the sources and content this page references. # Outputs An output defines where encoded stream data goes after processing. You define outputs as a list in `spec.outputs`. An output can: - Connect to a named destination (`destinationName`), sending the stream to an external RTMP or SRT endpoint. - Publish a content name (`contentName`), making the processed stream available to downstream live resources by name. - Be internal: omitting both `destinationName` and `contentName` makes the output available to downstream resources without external egress. An internal output is useful when you want to chain resources together inside the platform without sending anything to an external system. ## Outputs are not the same as the archive asset `spec.outputs` controls optional egress: pushing to a destination, publishing a content name, or chaining to another flow. It is a separate thing from `assetName`, which lives on `spec.transform` alongside `encodingLive` and is **required** on every `LiveChannel`, `LiveEvent`, `StaticMultiviewChannel`, and `StaticMultiviewEvent`: you cannot create one of these resources without naming an asset. Include `assetName` in requests for all four transform types. Use `archiveWindowLength` to control the archive and time-shift window, up to the documented maximum of 30 days. Configuring an external destination does not remove the required asset field. ```json "transform": { "type": "LiveEvent", "assetName": "my-event-archive", "encodingLive": { "configRef": { "name": "my-encoding-template", "version": "latest" } } } ``` ## What comes next - [Templates](/mkio/api-guides/how-to/live/core-concepts/templates): how encoding templates connect to live resources. - [Manage live channels and events](/mkio/api-guides/how-to/live/manage-live#connect-to-a-destination): create a destination and connect an output to it. # Resource states There are two different "state" concepts, and mixing them up is a common source of confusion: - **`spec.state`** is what you set. It only ever has two values: `Stopped` or `Running`. This is the desired state described in [Resource types and lifecycle](/mkio/api-guides/how-to/live/core-concepts/resource-types). - **`status.state`** is what the platform reports back. It has 13 possible values, because getting from `Stopped` to `Running` (and back) involves several intermediate steps. ## Poll resource state You can poll just the reported state without reading the full resource object. The state endpoint at `GET /api/v1/projects/{project_name}/live/{resource_type}/{name}/state` returns only `status.state`. This is more efficient for polling loops than fetching the whole resource. Those 13 values group into four phases: initialising (`""`, `Pending`, `Allocating`, `Allocated`), starting or running (`Starting`, `Started`, `Running`, `Updating`), winding down (`Stopping`, `Stopped`, `Deleting`, `Deleted`), and one error value (`UnableToStart`, meaning the resource failed to reach `Running`). ### Start contribution during startup For an SRT listener input, prepare the encoder with the source URL and connection settings before requesting startup. Begin contribution as part of the startup procedure and monitor both encoder connection status and `status.state`. A source marked `Active` is in use; verify playback separately to confirm that media is arriving. See [Monitor live resources](/mkio/api-guides/how-to/live/monitor-live#check-the-current-state) for the reported state values and the rest of the status object. ## What comes next - [Manage live channels and events](/mkio/api-guides/how-to/live/manage-live): create and operate liveChannels and liveEvents. - [Monitor live resources](/mkio/api-guides/how-to/live/monitor-live): metrics, monitoring URLs, and the full status object. # Resource types and lifecycle ## The four resource types Every resource in the Live API is a live processing unit. You create one, define its inputs and outputs, assign a template that controls how it encodes, and then start it. There are four types, chosen by the combination of what you need and how you want to be billed.
Resource Billing Use when
liveChannels Monthly flat fee, charged immediately on start You need a 24/7 live feed that is always encoding
liveEvents Per-minute You need a live feed for a defined broadcast window
staticMultiviewChannels Monthly flat fee, charged immediately on start You need to compose multiple feeds into a multiview output, continuously
staticMultiviewEvents Per-minute You need to compose multiple feeds into a multiview output for a specific event
All four share the same body structure, the same lifecycle, and the same endpoints pattern. Choose the matching `spec.transform.type` and configuration fields for your resource. Multiview can also reference a `multiviewComposing` config. ## The desired state model Live API resources use a desired state model. The `spec.state` field tells the platform what you want the resource to be doing. Set it to `Stopped` to create and configure the resource without active processing. Set it to `Running` to begin startup. This means you can create a resource in advance and verify its configuration before startup. A stopped resource can still take time to move through `Starting`. Stop a resource by patching `spec.state` back to `Stopped`, not by deleting it. Create with `Stopped`. Start by patching to `Running`. Stop by patching back to `Stopped`. Delete when you no longer need the resource at all. ## Sites Each live resource runs on a site. For a normal cloud workflow, omit `spec.siteName` so MK.IO uses the project's cloud site. Set an explicit site only when you deliberately target that site. Do not copy `world` into cloud examples because it can route the resource toward a device site. ## What comes next - [Inputs](/mkio/api-guides/how-to/live/core-concepts/inputs): connect a live resource to a stream. - [Live event walkthrough](/mkio/api-guides/how-to/live/walkthrough): see these resource types created and started in a working example. # Templates The live resource spec controls _what_ to do: which inputs to accept, where to send output, when to run. What it does not control is _how_ to encode. Codec settings, bitrate, output resolution, frame rate are complex, reusable settings that would be cumbersome to repeat in every resource you create. Templates solve this. You upload your encoding settings once to the **Templates API**, give the template a name, and reference it from as many live resources as you need. This means you can share the same encoding configuration across many resources and update it in one place when settings change. ## Reference a template Templates are managed through the Templates API and are completely separate from the Live API. Each time you upload a new version, the platform tracks it. The most recently uploaded version is automatically tagged `latest`. Reference a template in a live resource spec like this: ```json "encodingLive": { "configRef": { "name": "my-encoding-template", "version": "latest" } } ``` The `configRef.name` value must identify a customer config, not a MediaKind preset. Create the config from a preset first, then retrieve the config and read `status.inputPins` and `status.outputPins`. These pin names provide the `transformInput` and `transformOutput` values for the resource. The `latest` tag is mutable. Pin `configRef.version` to a version hash for production workflows that must remain reproducible. ## Customize a resource configuration There are two ways to adjust a template's behavior for a single resource, without changing the shared template itself. ### Use declared parameters The first, and the one to prefer, is `configValues`. A template can optionally declare a set of named **parameters**, each one pointing at a specific location (or several) inside the template's content. If a template declares a parameter, you can set it by name in `configValues` on the resource that references that template: ```json "encodingLive": { "configRef": { "name": "my-encoding-template", "version": "latest" }, "configValues": { "": "" } } ``` Add `configValues` only for parameters listed in the created config's `spec.parameters`. Replace the placeholders with a declared name and its required leaf JSON value. You cannot invent a parameter name on the resource side. See [Manage templates](/mkio/api-guides/how-to/templates/manage-templates) for how a template declares them. ### Apply direct overrides The second way is `configOverrides`, which applies JSON Patch operations directly against the template's content, at any path, whether or not the template author intended it to be changed. It's more powerful, since it isn't limited to declared parameters, but it requires knowing the template's internal structure in detail. If both `configValues` and `configOverrides` touch the same field, `configValues` is applied first and `configOverrides` applied second, so `configOverrides` wins. Alongside `configRef`, `configOverrides`, and `configValues`, the same object accepts an `advancedSettingsName` field. This points at an advanced-settings configuration block that MediaKind manages on your behalf. You will not normally set this yourself. Leave it out unless MediaKind support has specifically asked you to reference one. ## Template types The template types used by the four documented Live API resource types are:
Config type Required by Purpose
encodingLive All four resource types Live encoding parameters
multiviewComposing StaticMultiviewChannel, StaticMultiviewEvent (optional) Composition layout for multiview, defined separately from encoding
streamConditioning Optional on any Stream conditioning parameters
## What comes next - [Build with the Templates API](/mkio/api-guides/how-to/templates): every endpoint, presets, and the full config type reference. - [Resource states](/mkio/api-guides/how-to/live/core-concepts/resource-states): `spec.state` vs. `status.state`. # Manage live channels and events A `liveChannel` is a 24/7 resource billed monthly. A `liveEvent` is a time-bounded resource billed per minute. Both encode live input according to an `encodingLive` template and use an MK.IO asset for recording. The examples below configure one input. Use liveChannels for permanent infrastructure and liveEvents for scheduled or one-off broadcasts. ## Prerequisites Before you create a liveChannel or liveEvent, you need: - A source or content resource for the input. See [Content, sources, and destinations](/mkio/api-guides/how-to/media/content-and-sources). - An `encodingLive` configuration template. See [Manage templates](/mkio/api-guides/how-to/templates/manage-templates). - The input pin name from the created config's `status.inputPins[].name`. Every input must bind to a config pin through `transformInput`. - An MK.IO asset to write output into. This is not optional: `assetName` is a required field on every liveChannel and liveEvent, so create the asset first even if you don't plan to keep the recording. See [Assets](/mkio/api-guides/how-to/media/assets). ## Create a liveChannel Create the resource with `spec.state` set to `Stopped`. This allocates the resource without starting processing. ```bash curl -X PUT "https://app.mk.io/api/v1/projects//live/liveChannels/my-channel" \ -H "Authorization: Bearer " \ -H "Content-Type: application/json" \ -d '{ "metadata": { "displayName": "My Channel" }, "spec": { "state": "Stopped", "inputs": [ { "sourceName": "encoder-london", "transformInput": "" } ], "outputs": [], "transform": { "type": "LiveChannel", "assetName": "my-channel-archive", "encodingLive": { "configRef": { "name": "my-encoding-template", "version": "latest" } } } } }' ``` The required transform fields are `type`, `assetName`, and `encodingLive.configRef`. You can also set `archiveWindowLength` to control how much content is retained in the archive window. The value is an ISO 8601 duration string such as `PT1H30M` for 1 hour 30 minutes. The maximum value is 30 days. If the asset has a subpath you want to write into, set `assetPath` alongside `assetName`. ## Create a liveEvent The body structure is identical to a liveChannel. Change the `transform.type` to `LiveEvent`: ```bash curl -X PUT "https://app.mk.io/api/v1/projects//live/liveEvents/my-event" \ -H "Authorization: Bearer " \ -H "Content-Type: application/json" \ -d '{ "metadata": { "displayName": "My Event" }, "spec": { "state": "Stopped", "inputs": [ { "sourceName": "encoder-london", "transformInput": "" } ], "outputs": [], "transform": { "type": "LiveEvent", "assetName": "my-event-archive", "encodingLive": { "configRef": { "name": "my-encoding-template", "version": "latest" } } } } }' ``` ## Connect to a destination To send output to an external destination, set `destinationName` on the output. Omit `destinationName` to create an internal output that makes the stream available to downstream resources without external egress. ```json "outputs": [ { "destinationName": "playout-system" } ] ``` For an **internal** output (no `destinationName` or `contentName`), you can cap how many downstream flows are allowed to connect to it by setting `transport.maxConnections`: ```json "outputs": [ { "transport": { "maxConnections": 10 } } ] ``` `maxConnections` only takes effect when the output has no destination. Once you set `destinationName`, connection limits are controlled by the destination resource itself, not by this field. ## Reference content instead of a source To let the system resolve which source supplies the stream based on network reachability, use `contentName` on the input instead of `sourceName`: ```json "inputs": [ { "contentName": "channel-1", "transformInput": "" } ] ``` `contentName` lets the platform resolve among candidates that can supply the content. It does not by itself guarantee seamless media failover when an encoder stops sending. ## Set per-instance parameter values If the config you reference declares parameters, set values for them by name with `configValues`. Retrieve the created config first and inspect its current `spec.parameters`; presets can change. ```json "encodingLive": { "configRef": { "name": "my-encoding-template", "version": "latest" }, "configValues": { "": "" } } ``` Add a `configValues` object only when you need an override. Replace the placeholders with a name from `spec.parameters` and its required leaf JSON value: a string, number, or boolean. The API checks values against those declarations. See [Declare parameters on a config](/mkio/api-guides/how-to/templates/manage-templates#declare-parameters-on-a-config). ## Apply per-instance configuration overrides For anything a template's declared parameters don't cover, use `configOverrides` to apply JSON Patch operations to the template for this resource only. The shared template is not modified. There's also an `advancedSettingsName` field on the same object, reserved for MediaKind-managed advanced settings blocks. It isn't something you'd normally set yourself, only add it if MediaKind support has specifically pointed you at one. ```json "encodingLive": { "configRef": { "name": "my-encoding-template", "version": "latest" }, "configOverrides": { "type": "application/json-patch+json", "operations": [ { "op": "replace", "path": "", "value": "" } ] } } ``` Replace `` with an existing JSON pointer in the retrieved config and `` with the replacement value using that field's JSON type. If a resource sets both `configValues` and `configOverrides`, `configValues` is applied first and `configOverrides` second, so an override wins on any field they both touch. ## Check dependencies before startup Immediately before each start, retrieve the asset, source or content, and config referenced by the live resource. Confirm that each reference still points to the resource you intend to use. ```bash curl -X GET "https://app.mk.io/api/v1/projects//media/assets/my-channel-archive" \ -H "Authorization: Bearer " curl -X GET "https://app.mk.io/api/v1/projects//media/sources/encoder-london" \ -H "Authorization: Bearer " curl -X GET "https://app.mk.io/api/v1/projects//templating/configs/encodingLive/my-encoding-template" \ -H "Authorization: Bearer " ``` ## Start the resource Set `spec.state` to `Running` with a PATCH request: ```bash curl -X PATCH "https://app.mk.io/api/v1/projects//live/liveChannels/my-channel" \ -H "Authorization: Bearer " \ -H "Content-Type: application/json" \ -d '{ "spec": { "state": "Running" } }' ``` Starting the resource incurs channel or event billing. After requesting startup, begin sending SRT from the contribution encoder using the source's returned URL. Poll until the resource reaches `Running`, then verify playback. ## Stop the resource Set `spec.state` to `Stopped`: ```bash curl -X PATCH "https://app.mk.io/api/v1/projects//live/liveChannels/my-channel" \ -H "Authorization: Bearer " \ -H "Content-Type: application/json" \ -d '{ "spec": { "state": "Stopped" } }' ``` ## Get a resource ```bash curl -X GET "https://app.mk.io/api/v1/projects//live/liveChannels/my-channel?\$detailedStatus=true" \ -H "Authorization: Bearer " ``` The response includes `spec`, `metadata`, and `status`. For lightweight state polling, use the state endpoint instead. See [Monitor live resources](/mkio/api-guides/how-to/live/monitor-live). ## List resources ```bash curl -X GET "https://app.mk.io/api/v1/projects//live/liveChannels" \ -H "Authorization: Bearer " ``` The list endpoint supports `$top`, `$skiptoken`, `$filter`, `$orderby`, `$label`, and `$label_key` query parameters. Filterable fields include: `name`, `displayName`, `spec/state`, `spec/transform/type`, `status/state`, `created`, `updated`, and others. See the [Live API reference](/api-reference/live-api) for the full list. To search across all resource types at once, use the search endpoint: ```bash curl -X GET "https://app.mk.io/api/v1/projects//live/search" \ -H "Authorization: Bearer " ``` ## Update metadata Use PATCH to update `metadata.displayName` or `metadata.labels` without affecting the resource spec: ```bash curl -X PATCH "https://app.mk.io/api/v1/projects//live/liveChannels/my-channel" \ -H "Authorization: Bearer " \ -H "Content-Type: application/json" \ -d '{ "metadata": { "displayName": "My Channel (updated)" } }' ``` ## Delete a resource ```bash curl -X DELETE "https://app.mk.io/api/v1/projects//live/liveChannels/my-channel" \ -H "Authorization: Bearer " ``` If the resource does not exist, the API returns `204`. Stop the resource before deleting it. Deletion can return `409` while downstream flow inputs still reference the resource. ## What comes next - [Live event walkthrough](/mkio/api-guides/how-to/live/walkthrough): see every step in this page combined into one worked example, from source creation onward. - [Monitor live resources](/mkio/api-guides/how-to/live/monitor-live): check state, read metrics, and access thumbnail and metadata URLs. - [Scheduled operations](/mkio/api-guides/how-to/live/scheduled-operations): automate start and stop times. - [Multiview](/mkio/api-guides/how-to/live/multiview): compose multiple inputs into a multiview output. # Monitor live resources The Live API provides three ways to observe a running resource: a lightweight state endpoint for polling, a full status object on the resource GET response, and a monitoring object that carries thumbnail and metadata URLs for visual inspection. ## Check the current state The state endpoint returns only the current state of the resource. Use it in polling loops rather than reading the full resource each time. ```bash curl -X GET "https://app.mk.io/api/v1/projects//live/liveChannels/my-channel/state" \ -H "Authorization: Bearer " ``` The response contains `status.state`. This is a separate concept from the `spec.state` you set (which only has two values, `Stopped` and `Running`). `status.state` reflects everything the platform reports while getting there, and has 13 possible values: ```text "", Pending, Allocating, Allocated, Starting, Started, Running, Updating, Stopping, Stopped, Deleting, Deleted, UnableToStart ``` Compare the reported state with the desired state and check `status.info` on the full resource for any informational message. Do not assume every resource visits every intermediate value. Use the same pattern for liveEvents, staticMultiviewChannels, and staticMultiviewEvents by substituting the resource type in the path. ### Handle a resource that does not start `Starting` means the resource is still transitioning. The API does not guarantee that a resource leaves `Starting` within a fixed time, so set your own timeout in any polling loop rather than waiting indefinitely. If a resource stays in `Starting` for longer than you expect, check that the contribution encoder is sending media. Check the source URL, listener allow list, encryption settings, and encoder connection status alongside `status.state` and `status.info`. Confirm that every referenced resource still exists. Check the asset named in `spec.transform.assetName`, the sources or content named in `spec.inputs`, and the config named in `spec.transform.encodingLive.configRef`. ## Read full status The full GET response includes `status.state`, input status, output status, and the assigned device and site: ```bash curl -X GET "https://app.mk.io/api/v1/projects//live/liveChannels/my-channel?\$detailedStatus=true" \ -H "Authorization: Bearer " ``` The `status` object includes:
Field Description
state Current resource state.
siteDisplayName Display name of the site the resource runs on.
deviceName Name of the device the resource is assigned to, if applicable.
deviceDisplayName Display name of the device, if applicable.
shortId Short visual identifier. Do not use for programmatic purposes.
inputs Array of input status objects.
outputs Array of output status objects.
metrics Dictionary of metric samples.
monitoring Dictionary of monitoring context objects.
## Inspect input and output status ### Input status Each entry in `status.inputs` reflects the resolved assignment for that input. See [Resolving content](/mkio/api-guides/how-to/media/content-and-sources#resolving-content) for how the platform gets from `contentName` to one of these:
Field Description
contentName The resolved content name for this input.
contentDisplayName The display name of the resolved content.
sourceName The source assigned to this input, if resolution landed on a source rather than a flow.
sourceDisplayName Display name of that source.
sourceShortId Short visual identifier for the source. Do not use for programmatic purposes.
sourceUrl The ingress URL for the source, if it has one.
upstreamFlowName The name of an upstream flow providing the input, if resolution landed on a flow rather than a source.
networkName The network the input is assigned to. Empty if resolved from a directly-connected source such as SDI.
networkDisplayName Display name of the network.
deviceInterfaceName The device interface assigned to the input, if applicable.
When an input is resolved, `sourceName` identifies the assigned source or `upstreamFlowName` identifies the upstream flow. Both can be empty when no assignment has been resolved. None of these fields report whether media is arriving. They describe assignment and resolution, not what is flowing through the input. A source `Active` state, successful Domain Name System (DNS) resolution, or an established listener connection has the same boundary: each confirms assignment or use, not live media flow. Read the current input assignments from each response; do not substitute the desired `spec.inputs` values when a status field is empty. ### Output status Each entry in `status.outputs` shows where output is being sent:
Field Description
contentName The content name published by this output, if set.
contentDisplayName Display name of that content.
destinationUrl The egress URL of the connected destination, if applicable.
destinationDisplayName Display name of the destination. Empty for an internal output with no destination.
downstreamFlowNames Names of downstream flows connected to this output.
networkName The network the output is assigned to. Empty for a directly-connected destination such as SDI.
networkDisplayName Display name of the network.
deviceInterfaceName The device interface assigned to the output, if applicable.
transport Transport settings specific to this output.
## Read metrics The full resource response includes `status.metrics`, a dictionary keyed by metric name. Inspect the returned metrics alongside resource state, input assignments, and playback. A resource state or a single metric is not a substitute for checking that the expected sources reach the output. For project-level metrics export and monitoring storage, see [Monitor MK.IO services](/mkio/how-to/monitor-your-services). Use the export URL returned for your project and retain samples in your monitoring system when you need history. ## Verify media delivery 1. Check `status.inputs` against the source or content references in `spec.inputs`. 2. Confirm that each contribution encoder is sending to its source's returned URL. 3. Use the monitoring URLs below for a preview when they are returned. 4. [Publish the output asset](/mkio/api-guides/how-to/media/publishing) and verify the expected video and audio in a compatible player. For multiview, check every tile. An `Active` source means it is in use. Input assignment, resource state, and a reachable manifest each verify a different part of the workflow; none alone proves that the current media reaches viewers. ## Access monitoring URLs The `status.monitoring` object provides URLs for visual monitoring. Each key is a monitoring context name. Each value contains:
Field Description
thumbnailUrl URL of a thumbnail image for the stream at this context.
metadataUrl URL of stream metadata at this context.
The contexts available depend on the transform type and configuration. Fetch the thumbnail URL to display a visual preview of the stream. Fetch the metadata URL for structured data about the current stream state. ```json "monitoring": { "encode": { "thumbnailUrl": "https://...", "metadataUrl": "https://..." } } ``` # Multiview Multiview is a production technique where multiple camera feeds or source streams are combined into a single tiled video output. Instead of broadcasting one camera at a time, a multiview output shows all feeds simultaneously, arranged in a grid or picture-in-picture layout. The Live API handles multiview composition through two resource types: `staticMultiviewEvents` and `staticMultiviewChannels`. ## Which resource type to use Both resource types produce the same multiview output. The only difference is how they are billed and how long they run.
Resource Billing Use when
staticMultiviewEvents Per-minute Sports matches, live shows, any broadcast with a defined start and end
staticMultiviewChannels Monthly flat fee, charged immediately on start 24/7 production infrastructure that runs continuously
If for example you are running a 90-minute football match on a Saturday, use `staticMultiviewEvents`. If you are building a permanent control room feed that is always on, use `staticMultiviewChannels`.
Caution

Starting a staticMultiviewChannels resource incurs monthly billing. Review the current project rate card before starting. Use staticMultiviewEvents for time-bounded workloads that need event billing.

## How composition works When the Live API receives multiple input streams for a multiview resource, it routes each one into a processing template that composes them into a layout and then encodes the result. The template is where the composition happens. The Live API resource is the control plane: it tells the platform which streams to accept, which template to use, and where to send the output. ### What a pin is Processing configs expose named input slots called **pins** when the actual config declares them. A pin is a labelled placeholder that says "a video feed goes here". A multiview config might expose four pins. When you create a multiview resource, each input includes a `transformInput` value that names its pin. This is how the platform knows which camera feed to put in which position. The template controls what happens at each pin (size, position, any overlays). The `transformInput` value on your resource input connects a specific source stream to that pin. Pin names are defined by the template and retrieved by reading the template's `status.inputPins[].name`. They are not standardized across templates, so always read them from your specific template before creating a resource. ### Two composition modes There are two ways to configure how composition works, depending on how your template is built. There's no separate "multiview" config type. The Templates API only has `encodingLive` and `multiviewComposing`, that's the whole vocabulary. A multiview resource always needs an **`encodingLive`** template, since that's what actually encodes the output, and optionally a **`multiviewComposing`** template if you want the layout defined separately. Common multiview preset examples include `default_1080p_2up`, `default_1080p_3up`, and `default_1080p_4up`. Discover the presets available to your project at runtime. When returned as `encodingLive`, these are Mode 1 presets where one config does both jobs. #### Mode 1: Layout inside the encodingLive template The simpler approach. Your `encodingLive` template is built to handle both composition and encoding in one. The template defines the grid layout internally, and each flow input maps to a pin in that template. You only need one template reference in the resource spec. The `transformInput` pin names come from the `encodingLive` template. Use this mode when: - A single template handles both the composition layout and encoding settings. - The layout is fixed and does not need to change independently of encoding. - You want the simplest possible configuration. #### Mode 2: Separate multiviewComposing template The more flexible approach. You have two templates: an `encodingLive` template that handles encoding only, and a separate `multiviewComposing` template that defines the composition layout. You set both in the resource spec. The `transformInput` pin names come from the `multiviewComposing` template, not the `encodingLive` template. Use this mode when: - You want to change the visual layout without touching the encoding configuration. - Multiple events share the same encoding settings but have different camera arrangements. - Your production team manages layouts and encoding parameters separately. For example: a broadcast platform running events across different sports might use one `encodingLive` template for all of them (same output codec and bitrate ladder) but different `multiviewComposing` templates per sport (different number of cameras, different layout grids).
Note

If you are new to multiview on the Live API, start with Mode 1. It requires one template instead of two and has less moving parts to configure. Move to Mode 2 when you need layout flexibility across multiple events.

## The setup sequence Before you create a multiview resource, you need to set up these dependencies in order: 1. **A source for each input** (Media API): each camera feed or ingest point needs its own source resource. See [Content, sources, and destinations](/mkio/api-guides/how-to/media/content-and-sources). 2. **An encodingLive template** (Templates API): required for all multiview resources. List the current presets, create a customer config from one, then retrieve that config's pins. See [Manage templates](/mkio/api-guides/how-to/templates/manage-templates). 3. **A multiviewComposing template** (Templates API): required only for Mode 2. 4. **An MK.IO asset** (Media API): live resources write encoded output into an asset. See [Assets](/mkio/api-guides/how-to/media/assets). For a complete walkthrough that covers all of these steps in order, see [Multiview setup walkthrough](/mkio/api-guides/how-to/live/multiview/multiview-walkthrough). `transformInput` also applies to single-input Live resources. For multiview, each input normally binds to a different pin. Resolved inputs, source `Active` state, and event-level health do not prove that each tile receives media. Check every encoder's contribution and verify that each expected tile updates in the composed picture. ## Guides [End-to-end walkthrough](/mkio/api-guides/how-to/live/multiview/multiview-walkthrough) Follow a complete setup from sources and templates through to a running multiview event. [Static Multiview Event](/mkio/api-guides/how-to/live/multiview/static-multiview-event) Reference guide for creating and operating a per-minute multiview resource. [Static Multiview Channel](/mkio/api-guides/how-to/live/multiview/static-multiview-channel) Reference guide for creating and operating a monthly-billed multiview resource. # Multiview setup walkthrough This guide walks through the complete setup for a live multiview event, from creating ingest sources to a running `staticMultiviewEvents` resource composing four camera feeds into a single output. The scenario: four cameras covering a live sports match. Each camera sends an SRT stream to the platform. The output is a single tiled multiview feed stored in an asset and optionally delivered to a downstream playout system. ## Prerequisites - A project name and [API token](/mkio/api-guides/getting-started/authentication) with access to Media, Templates, and Live resources. - [Registered storage](/mkio/api-guides/how-to/media/storage) for the recording. - Four SRT encoders and their public IP addresses. - An existing streaming endpoint, or the project location needed to create one. Use unused resource names and replace every placeholder. The workflow creates and starts a billed event; complete the cleanup step after testing. Create its content, sources, asset, and config before creating the Live API resource. ## Step 1: Create content resources Content resources are named stream identifiers. Each camera feed gets its own content resource so the platform can track which sources supply which streams. Create one content resource per camera: ```bash curl -X PUT "https://app.mk.io/api/v1/projects//media/content/camera-1" \ -H "Authorization: Bearer " \ -H "Content-Type: application/json" \ -d '{ "metadata": { "displayName": "Camera 1" } }' curl -X PUT "https://app.mk.io/api/v1/projects//media/content/camera-2" \ -H "Authorization: Bearer " \ -H "Content-Type: application/json" \ -d '{ "metadata": { "displayName": "Camera 2" } }' curl -X PUT "https://app.mk.io/api/v1/projects//media/content/camera-3" \ -H "Authorization: Bearer " \ -H "Content-Type: application/json" \ -d '{ "metadata": { "displayName": "Camera 3" } }' curl -X PUT "https://app.mk.io/api/v1/projects//media/content/camera-4" \ -H "Authorization: Bearer " \ -H "Content-Type: application/json" \ -d '{ "metadata": { "displayName": "Camera 4" } }' ``` A `201 Created` response for each confirms the content resources are created. `status.state` reports whether active flows use the content: `Active` or `Inactive`. Creating the content identifier alone does not start media processing. ## Step 2: Create sources for each camera A source connects a content resource to a physical ingest transport. Each camera encoder will connect to the platform using SRT, so you create an `SRTListener` source for each. The platform allocates an SRT URL that the camera encoder connects to. Create one source per camera, linking each to its content resource: ```bash curl -X PUT "https://app.mk.io/api/v1/projects//media/sources/camera-1-source" \ -H "Authorization: Bearer " \ -H "Content-Type: application/json" \ -d '{ "metadata": { "displayName": "Camera 1 Source" }, "spec": { "contentName": "camera-1", "networkName": "internet", "transport": { "type": "SRTListener", "port": 5001, "allowList": [""], "latency": 0.5, "maxBitrate": 30000000, "ipResource": { "type": "External" } } } }' ``` Repeat for `camera-2-source` through `camera-4-source`, using ports `5002`, `5003`, and `5004` respectively, linking each to its content name, and setting `allowList` to that encoder's public IP address. After each PUT succeeds, read back the source to get the allocated SRT connection URL: ```bash curl -X GET "https://app.mk.io/api/v1/projects//media/sources/camera-1-source" \ -H "Authorization: Bearer " ``` The `status.transport.urls` array contains the URL your camera encoder should connect to. Share this URL with whoever configures the encoder for that camera. `networkName` and most transport settings are configured at creation. The source PATCH endpoint supports content reassignment and selected transport changes. See [Update a source](/mkio/api-guides/how-to/media/content-and-sources#update-a-source) before recreating a source. ## Step 3: Create an output asset The multiview resource writes its encoded output into an MK.IO asset. Create the asset before you create the live resource. ```bash curl -X PUT "https://app.mk.io/api/v1/projects//media/assets/match-multiview" \ -H "Authorization: Bearer " \ -H "Content-Type: application/json" \ -d '{ "properties": { "storageAccountName": "", "description": "Multiview archive for the match" } }' ``` The `storageAccountName` must reference a registered storage instance in your project. See [Storage](/mkio/api-guides/how-to/media/storage) if you have not registered storage yet. ## Step 4: Set up your encodingLive template The `encodingLive` template controls how the multiview output is encoded. It also defines the input pins that map your camera feeds to positions in the layout. List the presets available to the project. If the endpoint returns `default_1080p_4up`, you can use it as a Mode 1 example where one `encodingLive` config handles the tiled layout and encoding. ```bash curl -X GET "https://app.mk.io/api/v1/projects//templating/presets/encodingLive" \ -H "Authorization: Bearer " ``` Create your own config from it: ```bash curl -X PUT "https://app.mk.io/api/v1/projects//templating/configs/encodingLive/my-multiview-template" \ -H "Authorization: Bearer " \ -H "Content-Type: application/json" \ -d '{ "metadata": { "description": "Match Multiview Encoding" }, "spec": { "presetName": "default_1080p_4up" } }' ``` Retrieve its input pins: ```bash curl -X GET "https://app.mk.io/api/v1/projects//templating/configs/encodingLive/my-multiview-template" \ -H "Authorization: Bearer " ``` Look at `status.inputPins` in the response. Each entry has a `name` field. These are the exact values you will use as `transformInput` in the next step. Inspect `spec.parameters` as well. If the created config declares `multiviewLayout`, you can adjust it with `configValues` when you create the event. Read the four returned pin names and use them in place of these placeholders: ```json "inputPins": [ { "name": "", "allowMultipleBindings": false }, { "name": "", "allowMultipleBindings": false }, { "name": "", "allowMultipleBindings": false }, { "name": "", "allowMultipleBindings": false } ] ``` Your template's pin names may be different. Use whatever `status.inputPins[].name` returns for your template. ## Step 5: Create the multiview event Now create the `staticMultiviewEvents` resource. This is where you wire everything together: the sources created in Step 2 connect to pins from Step 4, the template is referenced, and the asset from Step 3 is named. Create it with `spec.state` set to `Stopped`. This allocates the resource without starting processing. ```bash curl -X PUT "https://app.mk.io/api/v1/projects//live/staticMultiviewEvents/match-multiview" \ -H "Authorization: Bearer " \ -H "Content-Type: application/json" \ -d '{ "metadata": { "displayName": "Match Multiview" }, "spec": { "state": "Stopped", "inputs": [ { "contentName": "camera-1", "transformInput": "" }, { "contentName": "camera-2", "transformInput": "" }, { "contentName": "camera-3", "transformInput": "" }, { "contentName": "camera-4", "transformInput": "" } ], "outputs": [], "transform": { "type": "StaticMultiviewEvent", "assetName": "match-multiview", "archiveWindowLength": "PT4H", "encodingLive": { "configRef": { "name": "my-multiview-template", "version": "latest" } } } } }' ``` Add a `configValues` object only if the created config declares the parameter you need in `spec.parameters`. Leave it out to use the config defaults. Each input uses `contentName` instead of `sourceName`, which lets the platform resolve among candidates that can supply the content. This does not guarantee seamless media-aware failover. To select a specific source, use `sourceName` instead. The `transformInput` values must exactly match the pin names from `status.inputPins[].name`. The `archiveWindowLength` of `PT4H` keeps up to 4 hours of content available in the asset. Adjust this to match the expected length of your event. ## Step 6: Confirm the dependencies Immediately before startup, retrieve every source or content resource, the asset, the config, and the multiview resource. Repeat the first two requests for all four cameras. ```bash curl -X GET "https://app.mk.io/api/v1/projects//media/sources/" \ -H "Authorization: Bearer " curl -X GET "https://app.mk.io/api/v1/projects//media/content/" \ -H "Authorization: Bearer " curl -X GET "https://app.mk.io/api/v1/projects//media/assets/match-multiview" \ -H "Authorization: Bearer " curl -X GET "https://app.mk.io/api/v1/projects//templating/configs/encodingLive/my-multiview-template" \ -H "Authorization: Bearer " curl -X GET "https://app.mk.io/api/v1/projects//live/staticMultiviewEvents/match-multiview" \ -H "Authorization: Bearer " ``` Check `spec.inputs` to confirm all four inputs have the correct content names and pin assignments. Check `spec.transform.encodingLive.configRef` against the retrieved config. The resource `status.state` should be `Stopped` or `Pending`. ## Step 7: Start the resource When your camera encoders are ready and the match is about to begin, start the resource by patching `spec.state` to `Running`: ```bash curl -X PATCH "https://app.mk.io/api/v1/projects//live/staticMultiviewEvents/match-multiview" \ -H "Authorization: Bearer " \ -H "Content-Type: application/json" \ -d '{ "spec": { "state": "Running" } }' ``` Starting the resource incurs event billing. After requesting startup, begin sending from all four SRT encoders using their sources' returned URLs. Poll the state endpoint until startup completes: ```bash curl -X GET "https://app.mk.io/api/v1/projects//live/staticMultiviewEvents/match-multiview/state" \ -H "Authorization: Bearer " ``` Once `status.state` is `Running`, the multiview composition is active and encoding into the asset. ## Step 8: Monitor during the event While the event runs, use the full GET to check input resolution, output status, and metrics: ```bash curl -X GET "https://app.mk.io/api/v1/projects//live/staticMultiviewEvents/match-multiview?\$detailedStatus=true" \ -H "Authorization: Bearer " ``` In the response: - `status.inputs[].contentName` shows which content name each input resolved to. - `status.metrics` contains metrics reported by the resource. - `status.monitoring` contains thumbnail and metadata URLs if your template produces them, allowing you to verify the composition visually. Confirm that every encoder is sending. Inspect the composed picture to verify that all four expected sources are present and updating; resource state alone does not establish that every camera is delivering media. See [Monitor live resources](/mkio/api-guides/how-to/live/monitor-live) for the full breakdown of what each status field means. ## Step 9: Publish and verify playback A healthy `status.metrics` reading confirms the pipeline is running, not that anyone can watch it. Publish the archive asset the same way you'd publish a VOD asset, with a streaming endpoint and a streaming locator, then check the manifest actually plays. If you don't already have a running streaming endpoint in this project, create one and start it: ```bash curl -X PUT "https://app.mk.io/api/v1/projects//media/streamingEndpoints/default" \ -H "Authorization: Bearer " \ -H "Content-Type: application/json" \ -d '{ "location": "", "properties": { "scaleUnits": 0 } }' curl -X POST "https://app.mk.io/api/v1/projects//media/streamingEndpoints/default/start" \ -H "Authorization: Bearer " ``` Confirm it reports `Running`: ```bash curl -X GET "https://app.mk.io/api/v1/projects//media/streamingEndpoints/default/state" \ -H "Authorization: Bearer " ``` Publish the `match-multiview` asset with a streaming locator. This example uses clear, unprotected streaming so you can verify playback before adding DRM: ```bash curl -X PUT "https://app.mk.io/api/v1/projects//media/streamingLocators/match-multiview-locator" \ -H "Authorization: Bearer " \ -H "Content-Type: application/json" \ -d '{ "properties": { "assetName": "match-multiview", "streamingPolicyName": "Predefined_ClearStreamingOnly" } }' ``` Ask the locator for its playback paths: ```bash curl -X POST "https://app.mk.io/api/v1/projects//media/streamingLocators/match-multiview-locator/listPaths" \ -H "Authorization: Bearer " ``` Each `streamingPaths[]` group can contain several entries in its `paths[]` array. Select the protocol and encryption combination you need, then retrieve the streaming endpoint you are using: ```bash curl -X GET "https://app.mk.io/api/v1/projects//media/streamingEndpoints/default" \ -H "Authorization: Bearer " ``` Replace `default` if you are reusing an endpoint with a different name. Read `properties.hostName` and `properties.cdnBasePath` from the response. Insert the CDN base path between the hostname and the selected locator path. Omit that part when no base path is returned, and use one slash at each boundary: ```text https:// ``` `` is `properties.hostName`, `` is the optional `properties.cdnBasePath`, and `` is the selected entry from `streamingPaths[].paths[]`. Check that it's actually reachable: ```bash curl -I "https://" ``` A `200 OK` confirms that the manifest is reachable. Confirm that its timestamps or segments advance, then open the URL in an HLS-capable player or inspect it with `ffprobe`. Check the composed picture to verify that all four cameras are flowing and tiled correctly. This is live-to-VOD playback of a sliding DVR window while the event is still `Running`, bounded by the `archiveWindowLength` you set in Step 5. See [Streaming and publishing](/mkio/api-guides/how-to/media/publishing) for DASH, DRM, and CDN options. ## Step 10: Stop and clean up When the match ends, stop the resource: ```bash curl -X PATCH "https://app.mk.io/api/v1/projects//live/staticMultiviewEvents/match-multiview" \ -H "Authorization: Bearer " \ -H "Content-Type: application/json" \ -d '{ "spec": { "state": "Stopped" } }' ``` Billing stops once the resource transitions to `Stopped`. The encoded content remains in the asset and is available for playback. When you no longer need the resource, delete it: ```bash curl -X DELETE "https://app.mk.io/api/v1/projects//live/staticMultiviewEvents/match-multiview" \ -H "Authorization: Bearer " ``` Review the recording and your retention requirements before removing any related assets or storage. ## Automating start and stop Rather than manually patching the state, you can pre-schedule start and stop times using scheduled operations. Create the scheduled operation after the resource is created and before the event starts: ```bash curl -X PUT "https://app.mk.io/api/v1/projects//live/staticMultiviewEvents/match-multiview/scheduledOperations/match-window" \ -H "Authorization: Bearer " \ -H "Content-Type: application/json" \ -d '{ "spec": { "type": "MediaKind.ScheduledOperation.StartStop", "startTime": "", "endTime": "", "correlationData": { "matchId": "premier-league-round-5" } } }' ``` See [Scheduled operations](/mkio/api-guides/how-to/live/scheduled-operations) for the full guide. # Static Multiview Channel A `staticMultiviewChannels` resource composes multiple live inputs into a single encoded multiview output. It is designed to run continuously as 24/7 production infrastructure and is billed at a monthly flat rate.
Caution

Starting a staticMultiviewChannels resource incurs monthly billing. Review the current project rate card before starting. For time-bounded multiview workloads, use Static Multiview Event.

For a complete setup guide that covers sources, templates, and the multiview resource together, see [Multiview setup walkthrough](/mkio/api-guides/how-to/live/multiview/multiview-walkthrough). ## When to use this resource type Use `staticMultiviewChannels` when your multiview feed needs to be available continuously without a defined start and end time. Common use cases are control room monitoring feeds, permanent studio outputs, and production infrastructure that is always on. If your multiview feed runs for a defined window (a match, a show, a scheduled broadcast), use `staticMultiviewEvents` instead. Events use per-minute billing. ## Prerequisites - One source or content resource per input (Media API). See [Content, sources, and destinations](/mkio/api-guides/how-to/media/content-and-sources). - An `encodingLive` customer config with input pins configured for multiview (Templates API). Discover presets at runtime, create a config from one, then retrieve the created config's pins. See [Manage templates](/mkio/api-guides/how-to/templates/manage-templates). - Optionally, a `multiviewComposing` template if you are separating composition from encoding. - An MK.IO asset to write output into. ## Step 1: Check template input pins Before creating the resource, read your `encodingLive` template and note the pin names in `status.inputPins[].name`. Each input in the resource spec uses a `transformInput` value that must exactly match a pin name from this list. ```bash curl -X GET "https://app.mk.io/api/v1/projects//templating/configs/encodingLive/my-multiview-template" \ -H "Authorization: Bearer " ``` If you are using a `multiviewComposing` template (Mode 2), also read its pins. In Mode 2, `transformInput` must match pins from the `multiviewComposing` template, not the `encodingLive` template. ## Step 2: Create the resource Create with `spec.state` set to `Stopped`. The resource is provisioned but does not start processing until you patch it to `Running`. Choose Mode 1 or Mode 2 depending on how your templates are structured. If you are not sure which to use, see [How composition works](/mkio/api-guides/how-to/live/multiview#how-composition-works). ### Mode 1: Layout inside the encodingLive template Use this when a single `encodingLive` template handles both the visual composition and encoding. ```bash curl -X PUT "https://app.mk.io/api/v1/projects//live/staticMultiviewChannels/main-studio" \ -H "Authorization: Bearer " \ -H "Content-Type: application/json" \ -d '{ "metadata": { "displayName": "Main Studio Multiview" }, "spec": { "state": "Stopped", "inputs": [ { "sourceName": "camera-1", "transformInput": "" }, { "sourceName": "camera-2", "transformInput": "" }, { "sourceName": "camera-3", "transformInput": "" }, { "sourceName": "camera-4", "transformInput": "" } ], "outputs": [], "transform": { "type": "StaticMultiviewChannel", "assetName": "main-studio-archive", "archiveWindowLength": "PT4H", "encodingLive": { "configRef": { "name": "my-multiview-template", "version": "latest" } } } } }' ``` Each input can use `sourceName` or `contentName`. The example uses `sourceName`. `contentName` lets the platform resolve among candidates that can supply the content, but it does not guarantee seamless media failover. The pin names in `transformInput` (`` etc.) are illustrative. Use the exact values from your template's `status.inputPins[].name`. ### Mode 2: Separate multiviewComposing template Use this when you want independent control over the visual layout and the encoding parameters. The `multiviewComposing` template defines how feeds are arranged on screen. The `encodingLive` template defines how the composed output is encoded. Pin names in `transformInput` must match the `multiviewComposing` template. ```bash curl -X PUT "https://app.mk.io/api/v1/projects//live/staticMultiviewChannels/main-studio" \ -H "Authorization: Bearer " \ -H "Content-Type: application/json" \ -d '{ "metadata": { "displayName": "Main Studio Multiview" }, "spec": { "state": "Stopped", "inputs": [ { "sourceName": "camera-1", "transformInput": "composing/input_1" }, { "sourceName": "camera-2", "transformInput": "composing/input_2" } ], "outputs": [], "transform": { "type": "StaticMultiviewChannel", "assetName": "main-studio-archive", "archiveWindowLength": "P7DT0S", "encodingLive": { "configRef": { "name": "my-encoding-template", "version": "latest" } }, "multiviewComposing": { "configRef": { "name": "my-composing-template", "version": "latest" } } } } }' ``` ## Optional fields
Field Description
archiveWindowLength ISO 8601 duration string controlling how much content is retained in the asset. Examples: PT4H (4 hours) and P7DT0S (7 days). Maximum 30 days.
assetPath A subpath within the asset to write output into.
streamConditioning Optional reference to a streamConditioning template for stream conditioning.
configOverrides Per-instance JSON Patch operations applied to a template without modifying the shared template.
## Step 3: Check dependencies Immediately before startup, retrieve each source or content resource, the asset, and every referenced config. Confirm that the references still point to the resources you intend to use. ## Step 4: Start the resource
Caution

Starting the resource incurs monthly billing. Confirm the configuration and review the current project rate card before starting.

```bash curl -X PATCH "https://app.mk.io/api/v1/projects//live/staticMultiviewChannels/main-studio" \ -H "Authorization: Bearer " \ -H "Content-Type: application/json" \ -d '{ "spec": { "state": "Running" } }' ``` After requesting startup, begin sending from every SRT encoder using its source's returned URL. Poll the state endpoint until `status.state` is `Running`: ```bash curl -X GET "https://app.mk.io/api/v1/projects//live/staticMultiviewChannels/main-studio/state" \ -H "Authorization: Bearer " ``` ## Step 5: Monitor the resource Once running, use the full GET to see input resolution, output status, and encoding metrics: ```bash curl -X GET "https://app.mk.io/api/v1/projects//live/staticMultiviewChannels/main-studio?\$detailedStatus=true" \ -H "Authorization: Bearer " ``` The `status.inputs` array shows which content each input resolved to. Resolution and event-level status do not prove that every source is delivering media. Check each encoder's contribution and verify that every expected tile updates in the composed picture. The `status.monitoring` object contains thumbnail and metadata URLs if your config produces them. For a full breakdown of what each status field means, see [Monitor live resources](/mkio/api-guides/how-to/live/monitor-live). ## Stop and delete To take the resource down for maintenance or permanently, stop it first: ```bash curl -X PATCH "https://app.mk.io/api/v1/projects//live/staticMultiviewChannels/main-studio" \ -H "Authorization: Bearer " \ -H "Content-Type: application/json" \ -d '{ "spec": { "state": "Stopped" } }' ``` Stopping a `staticMultiviewChannels` resource does not change the monthly billing already incurred. When you no longer need the resource: ```bash curl -X DELETE "https://app.mk.io/api/v1/projects//live/staticMultiviewChannels/main-studio" \ -H "Authorization: Bearer " ``` Review the recording and your retention requirements before removing any related assets or storage. ## Scheduled automation To automate start and stop windows for maintenance windows or planned events, create a scheduled operation on the resource. See [Scheduled operations](/mkio/api-guides/how-to/live/scheduled-operations). # Static Multiview Event A `staticMultiviewEvents` resource composes multiple live inputs into a single encoded multiview output. It is billed per minute and suits time-bounded broadcasts such as sports events, live shows, and scheduled productions. For permanent 24/7 multiview infrastructure, see [Static Multiview Channel](/mkio/api-guides/how-to/live/multiview/static-multiview-channel). For a complete setup guide that covers sources, templates, and the multiview resource together, see [Multiview setup walkthrough](/mkio/api-guides/how-to/live/multiview/multiview-walkthrough). ## Prerequisites - One source or content resource per input (Media API). See [Content, sources, and destinations](/mkio/api-guides/how-to/media/content-and-sources). - An `encodingLive` customer config with input pins configured for multiview (Templates API). Discover presets at runtime, create a config from one, then retrieve the created config's pins. See [Manage templates](/mkio/api-guides/how-to/templates/manage-templates). - Optionally, a `multiviewComposing` template if you are separating composition from encoding. - An MK.IO asset to write output into. ## Step 1: Check template input pins Before creating the resource, read your `encodingLive` template and note the pin names in `status.inputPins[].name`. These are the values you will use for `transformInput` when defining each input. ```bash curl -X GET "https://app.mk.io/api/v1/projects//templating/configs/encodingLive/my-multiview-template" \ -H "Authorization: Bearer " ``` Look for the `status.inputPins` array in the response. Each object has a `name` field. Copy these values exactly. If you are using a `multiviewComposing` template (Mode 2), read its pins using the same request with `multiviewComposing` as the config type. In Mode 2, the `transformInput` values must match pins from the `multiviewComposing` template, not the `encodingLive` template. ## Step 2: Create the resource Create the resource with `spec.state` set to `Stopped`. This provisions the resource without starting processing. You can verify the configuration and start it when you are ready. Choose Mode 1 or Mode 2 depending on how your templates are structured. If you are not sure which to use, see [How composition works](/mkio/api-guides/how-to/live/multiview#how-composition-works). ### Mode 1: Layout inside the encodingLive template Use this when a single `encodingLive` template handles both the visual composition and the encoding. Each input maps to a pin in that template. ```bash curl -X PUT "https://app.mk.io/api/v1/projects//live/staticMultiviewEvents/multiview-event-01" \ -H "Authorization: Bearer " \ -H "Content-Type: application/json" \ -d '{ "metadata": { "displayName": "Multiview Event 01" }, "spec": { "state": "Stopped", "inputs": [ { "sourceName": "camera-source-1", "transformInput": "" }, { "sourceName": "camera-source-2", "transformInput": "" }, { "sourceName": "camera-source-3", "transformInput": "" }, { "sourceName": "camera-source-4", "transformInput": "" } ], "outputs": [], "transform": { "type": "StaticMultiviewEvent", "assetName": "multiview-event-01-archive", "archiveWindowLength": "PT4H", "encodingLive": { "configRef": { "name": "my-multiview-template", "version": "latest" } } } } }' ``` Each input can specify either `sourceName` or `contentName`. The example uses `sourceName`. `contentName` lets the platform resolve among candidates that can supply the content, but it does not guarantee seamless media failover. The `transformInput` values must exactly match the pin names returned by `status.inputPins[].name` in your template. The example values (`` etc.) are illustrative only. The `archiveWindowLength` sets how much content is retained in the asset. `PT4H` is 4 hours. The maximum is 30 days. Set this to match the expected length of your event plus some buffer. ### Mode 2: Separate multiviewComposing template Use this when you want to control the visual layout independently from encoding. The `multiviewComposing` template defines how the feeds are arranged on screen. The `encodingLive` template defines how the composed output is encoded. You set both in the resource spec, and the `transformInput` pin names come from the `multiviewComposing` template. ```bash curl -X PUT "https://app.mk.io/api/v1/projects//live/staticMultiviewEvents/multiview-event-02" \ -H "Authorization: Bearer " \ -H "Content-Type: application/json" \ -d '{ "metadata": { "displayName": "Multiview Event 02" }, "spec": { "state": "Stopped", "inputs": [ { "sourceName": "camera-source-1", "transformInput": "composing/input_1" }, { "sourceName": "camera-source-2", "transformInput": "composing/input_2" } ], "outputs": [], "transform": { "type": "StaticMultiviewEvent", "assetName": "multiview-event-02-archive", "archiveWindowLength": "PT2H", "encodingLive": { "configRef": { "name": "my-encoding-template", "version": "latest" } }, "multiviewComposing": { "configRef": { "name": "my-composing-template", "version": "latest" } } } } }' ``` When `multiviewComposing` is present in the spec, pin names in `transformInput` must match pins from that template. Do not use pin names from the `encodingLive` template for Mode 2 resources. ## Apply per-instance configuration overrides If you need to change one or two settings in a template for this specific resource only, use `configOverrides` instead of creating a separate template version. `configOverrides` applies JSON Patch operations on top of the referenced template at resource creation time, leaving the shared template unchanged. This is useful when the same template is used across many events but one event needs a different bitrate or resolution. ```json "encodingLive": { "configRef": { "name": "my-multiview-template", "version": "latest" }, "configOverrides": { "type": "application/json-patch+json", "operations": [ { "op": "replace", "path": "", "value": "" } ] } } ``` Replace `` with an existing JSON pointer in the retrieved config and `` with the replacement value using that field's JSON type. The path and value depend on the structure of your specific template. ## Step 3: Check dependencies Immediately before startup, retrieve each source or content resource, the asset, and every referenced config. Confirm that the references still point to the resources you intend to use. ## Step 4: Start the resource Once you have confirmed its dependencies, start the resource by patching `spec.state` to `Running`. Starting the resource incurs event billing. ```bash curl -X PATCH "https://app.mk.io/api/v1/projects//live/staticMultiviewEvents/multiview-event-01" \ -H "Authorization: Bearer " \ -H "Content-Type: application/json" \ -d '{ "spec": { "state": "Running" } }' ``` After requesting startup, begin sending from every SRT encoder using its source's returned URL. Poll the state endpoint until `status.state` is `Running`: ```bash curl -X GET "https://app.mk.io/api/v1/projects//live/staticMultiviewEvents/multiview-event-01/state" \ -H "Authorization: Bearer " ``` ## Step 5: Monitor the resource Once running, use the full GET to see input resolution, output status, and metrics. The `status.inputs` array shows which content each input resolved to. The `status.metrics` field contains metrics reported by the resource. ```bash curl -X GET "https://app.mk.io/api/v1/projects//live/staticMultiviewEvents/multiview-event-01?\$detailedStatus=true" \ -H "Authorization: Bearer " ``` Input resolution and event-level stages do not prove that every source is delivering media. Check each encoder's contribution and verify that every expected tile updates in the composed picture. For status fields and monitoring URLs, see [Monitor live resources](/mkio/api-guides/how-to/live/monitor-live). ## Step 6: Stop and clean up When the event ends, request `Stopped` and poll until `status.state` confirms that processing has stopped. ```bash curl -X PATCH "https://app.mk.io/api/v1/projects//live/staticMultiviewEvents/multiview-event-01" \ -H "Authorization: Bearer " \ -H "Content-Type: application/json" \ -d '{ "spec": { "state": "Stopped" } }' ``` When you no longer need the resource, delete it. Review the recording and your retention requirements before removing any related assets or storage. ```bash curl -X DELETE "https://app.mk.io/api/v1/projects//live/staticMultiviewEvents/multiview-event-01" \ -H "Authorization: Bearer " ``` ## Automate start and stop To pre-schedule when the resource starts and stops, create a scheduled operation on the resource. This removes the need to send PATCH requests manually at broadcast time. See [Scheduled operations](/mkio/api-guides/how-to/live/scheduled-operations) for the full guide. # Scheduled operations Scheduled operations let you pre-program a start and stop time for any Live API resource. The operation schedules startup at `startTime` and shutdown at `endTime`. These transitions are asynchronous: monitor the live resource's `status.state` to confirm that it has reached `Running` or `Stopped`. The only supported operation type is `MediaKind.ScheduledOperation.StartStop`. Each operation is a named resource scoped to its parent live resource. ## Create a scheduled operation Set the operation name in the URL path. `startTime` and `endTime` are both required and must be ISO 8601 UTC datetime strings. `correlationData` is a required field for user-defined metadata; pass an empty object if you have no metadata to attach. ```bash curl -X PUT "https://app.mk.io/api/v1/projects//live/liveEvents/my-event/scheduledOperations/broadcast-window" \ -H "Authorization: Bearer " \ -H "Content-Type: application/json" \ -d '{ "spec": { "type": "MediaKind.ScheduledOperation.StartStop", "startTime": "", "endTime": "", "correlationData": { "eventId": "summer-finale" } } }' ``` The same endpoint works for `liveChannels`, `liveEvents`, `staticMultiviewChannels`, and `staticMultiviewEvents`. Substitute the resource type and resource name in the path. Before creating the operation, retrieve the live resource and each referenced asset, source or content resource, and config. Repeat this dependency check shortly before execution. Confirm that all references are valid before the scheduled broadcast. ## List scheduled operations ```bash curl -X GET "https://app.mk.io/api/v1/projects//live/liveEvents/my-event/scheduledOperations" \ -H "Authorization: Bearer " ``` ## Get a scheduled operation ```bash curl -X GET "https://app.mk.io/api/v1/projects//live/liveEvents/my-event/scheduledOperations/broadcast-window" \ -H "Authorization: Bearer " ``` The response includes `spec` with the scheduled times and `status` with the current state of the operation. ## Update a scheduled operation PUT replaces the full operation spec. To change only the start or end time, issue a new PUT with the updated times. ```bash curl -X PUT "https://app.mk.io/api/v1/projects//live/liveEvents/my-event/scheduledOperations/broadcast-window" \ -H "Authorization: Bearer " \ -H "Content-Type: application/json" \ -d '{ "spec": { "type": "MediaKind.ScheduledOperation.StartStop", "startTime": "", "endTime": "", "correlationData": { "eventId": "summer-finale" } } }' ``` ## Delete a scheduled operation ```bash curl -X DELETE "https://app.mk.io/api/v1/projects//live/liveEvents/my-event/scheduledOperations/broadcast-window" \ -H "Authorization: Bearer " ``` If the operation does not exist, the API returns `204`. ## Usage notes - A single resource can have multiple scheduled operations with non-overlapping time windows. - The resource must exist before you create a scheduled operation on it. - A scheduled state change does not provide media. Coordinate the contribution encoder to begin at the scheduled start or when the resource enters `Starting`. - `spec.correlationData` is returned with the scheduled operation and can be used to correlate it with external scheduling systems. - All times are in UTC. Confirm your `startTime` and `endTime` values before creating operations for production broadcasts. # Live event walkthrough This guide builds a real, running `liveEvent` from scratch: a single-camera SRT feed, encoded with a MediaKind-provided template, and verified playable at the end. The scenario: a single encoder pushes an SRT stream to the platform for a scheduled broadcast, gets encoded according to a template, and lands in an asset for live-to-VOD. If you need several cameras composed into one tiled output instead of just one, see the [multiview walkthrough](/mkio/api-guides/how-to/live/multiview/multiview-walkthrough) instead, it follows the same structure with more inputs. ## Prerequisites - A project name and [API token](/mkio/api-guides/getting-started/authentication) with access to its Media, Templates, and Live resources. - [Registered storage](/mkio/api-guides/how-to/media/storage) for the recording. Use its name for ``. - An SRT encoder, its public IP address, and a chosen listening port. - An existing streaming endpoint, or the project location needed to create one. The commands create resources and start a billed event. Use names that are unused in your project, replace every placeholder, and complete the cleanup step after testing. Template presets and pin names are discovered during the walkthrough. ## Step 1: Create the source A source tells the platform how your encoder will physically connect. This example uses `SRTListener`, meaning the platform opens a listening port and your encoder connects in to it; use `SRTCaller` if you'd rather have the platform connect out to an SRT server your encoder is already running. ```bash curl -X PUT "https://app.mk.io/api/v1/projects//media/sources/encoder-london" \ -H "Authorization: Bearer " \ -H "Content-Type: application/json" \ -d '{ "metadata": { "displayName": "London Encoder" }, "spec": { "networkName": "internet", "transport": { "type": "SRTListener", "port": 5010, "allowList": [""], "latency": 0.5, "maxBitrate": 30000000, "ipResource": { "type": "External" } } } }' ``` Replace `` with the public IP address from which your encoder connects. Read the source back to get the SRT URL your encoder should connect to: ```bash curl -X GET "https://app.mk.io/api/v1/projects//media/sources/encoder-london" \ -H "Authorization: Bearer " ``` `status.transport.urls` contains that connection URL. This example omits `contentName`, so the resource below references the source directly by `sourceName`. See [Inputs](/mkio/api-guides/how-to/live/core-concepts/inputs) for when to use `contentName` instead. ## Step 2: Create the output asset The live resource needs somewhere to write its encoded output. This is required, not optional, on every `liveEvent` and `liveChannel`. ```bash curl -X PUT "https://app.mk.io/api/v1/projects//media/assets/london-broadcast-archive" \ -H "Authorization: Bearer " \ -H "Content-Type: application/json" \ -d '{ "properties": { "storageAccountName": "", "description": "Archive for the London broadcast" } }' ``` `storageAccountName` must reference storage already registered in your project. See [Storage](/mkio/api-guides/how-to/media/storage) if you haven't set that up yet. ## Step 3: Get an encodingLive template Every live resource needs an `encodingLive` template telling it how to encode. MediaKind publishes ready-made presets for this, so start there rather than writing encoding configuration by hand. See [Build with the Templates API](/mkio/api-guides/how-to/templates) for the full picture of configs, presets, and parameters. List what's available: ```bash curl -X GET "https://app.mk.io/api/v1/projects//templating/presets/encodingLive" \ -H "Authorization: Bearer " ``` This example uses `default_1080p`, if the presets endpoint returns it for your project. Create your own config from the discovered preset: ```bash curl -X PUT "https://app.mk.io/api/v1/projects//templating/configs/encodingLive/london-broadcast-encoding" \ -H "Authorization: Bearer " \ -H "Content-Type: application/json" \ -d '{ "metadata": { "description": "London Broadcast Encoding" }, "spec": { "presetName": "default_1080p" } }' ``` Read your new config back to inspect its parameters and pins: ```bash curl -X GET "https://app.mk.io/api/v1/projects//templating/configs/encodingLive/london-broadcast-encoding" \ -H "Authorization: Bearer " ``` Inspect `spec.parameters` to find the values this config lets you override. Presets can change, so do not assume that a particular parameter is present. Copy the single-input pin name from `status.inputPins[].name`. Use the returned pin name for `` in the next request. See [Manage templates](/mkio/api-guides/how-to/templates/manage-templates) if you need to customize the template's contents beyond what its declared parameters allow. ## Step 4: Create the liveEvent Everything from the previous steps comes together here: the source from Step 1, the asset from Step 2, and the config from Step 3. Create with `spec.state` set to `Stopped` so processing does not start. ```bash curl -X PUT "https://app.mk.io/api/v1/projects//live/liveEvents/london-broadcast" \ -H "Authorization: Bearer " \ -H "Content-Type: application/json" \ -d '{ "metadata": { "displayName": "London Broadcast" }, "spec": { "state": "Stopped", "inputs": [ { "sourceName": "encoder-london", "transformInput": "" } ], "outputs": [], "transform": { "type": "LiveEvent", "assetName": "london-broadcast-archive", "archiveWindowLength": "PT4H", "encodingLive": { "configRef": { "name": "london-broadcast-encoding", "version": "latest" } } } } }' ``` Replace `` with the exact pin name returned by your config. To override a declared parameter, add `configValues` using a name from `spec.parameters`. Omit `configValues` to use the config defaults. `outputs` is left empty here because this example only archives to the asset. If you also need to push the stream to a downstream playout system, add a `destinationName`. See [Connect to a destination](/mkio/api-guides/how-to/live/manage-live#connect-to-a-destination) for details. ## Step 5: Confirm before starting Immediately before startup, retrieve every dependency as well as the live event. This catches a source, asset, or config that was deleted after the event was created. ```bash curl -X GET "https://app.mk.io/api/v1/projects//media/sources/encoder-london" \ -H "Authorization: Bearer " curl -X GET "https://app.mk.io/api/v1/projects//media/assets/london-broadcast-archive" \ -H "Authorization: Bearer " curl -X GET "https://app.mk.io/api/v1/projects//templating/configs/encodingLive/london-broadcast-encoding" \ -H "Authorization: Bearer " curl -X GET "https://app.mk.io/api/v1/projects//live/liveEvents/london-broadcast" \ -H "Authorization: Bearer " ``` Check `spec.inputs[0].sourceName`, `spec.inputs[0].transformInput`, `spec.transform.assetName`, and `spec.transform.encodingLive.configRef`. `status.state` should read `Stopped` or `Pending`. ## Step 6: Start the event When your encoder is ready, patch `spec.state` to `Running`: ```bash curl -X PATCH "https://app.mk.io/api/v1/projects//live/liveEvents/london-broadcast" \ -H "Authorization: Bearer " \ -H "Content-Type: application/json" \ -d '{ "spec": { "state": "Running" } }' ``` After requesting startup, begin sending from FFmpeg or your contribution encoder using the source's returned SRT URL. Monitor resource state and encoder connection status while startup proceeds. Starting the resource incurs event billing. Poll the lightweight state endpoint while startup continues: ```bash curl -X GET "https://app.mk.io/api/v1/projects//live/liveEvents/london-broadcast/state" \ -H "Authorization: Bearer " ``` `status.state` moves through several values on the way to `Running`. See [Resource states](/mkio/api-guides/how-to/live/core-concepts/resource-states) for the full list. Set a timeout on the polling loop rather than waiting indefinitely, and see [Handle a resource that does not start](/mkio/api-guides/how-to/live/monitor-live#handle-a-resource-that-does-not-start) if the event stays in `Starting`. Treat an established listener connection as confirmation that the encoder reached the listener, not as confirmation that media is flowing. Wait for `Running`, then verify playback. ## Step 7: Monitor while it runs ```bash curl -X GET "https://app.mk.io/api/v1/projects//live/liveEvents/london-broadcast?\$detailedStatus=true" \ -H "Authorization: Bearer " ``` `status.inputs[0]` shows what the input resolved to, and `status.monitoring` links to thumbnail and metadata URLs if the config produces them. Resolution and event-level health do not prove that media is arriving. Check that the encoder is sending and verify the expected video and audio during the playback step. See [Monitor live resources](/mkio/api-guides/how-to/live/monitor-live) for the full breakdown. ## Step 8: Publish and verify playback Everything so far confirms the pipeline is configured correctly, not that anyone can actually watch it. The asset is required, but it isn't playable on its own: publish it with a streaming endpoint and a streaming locator, the same way you'd publish a VOD asset. If you don't already have a running streaming endpoint in this project, create one and start it: ```bash curl -X PUT "https://app.mk.io/api/v1/projects//media/streamingEndpoints/default" \ -H "Authorization: Bearer " \ -H "Content-Type: application/json" \ -d '{ "location": "", "properties": { "scaleUnits": 0 } }' curl -X POST "https://app.mk.io/api/v1/projects//media/streamingEndpoints/default/start" \ -H "Authorization: Bearer " ``` Confirm it reports `Running` before testing playback: ```bash curl -X GET "https://app.mk.io/api/v1/projects//media/streamingEndpoints/default/state" \ -H "Authorization: Bearer " ``` Publish the archive asset with a streaming locator. This example uses clear, unprotected streaming so you can verify playback before adding DRM: ```bash curl -X PUT "https://app.mk.io/api/v1/projects//media/streamingLocators/london-broadcast-locator" \ -H "Authorization: Bearer " \ -H "Content-Type: application/json" \ -d '{ "properties": { "assetName": "london-broadcast-archive", "streamingPolicyName": "Predefined_ClearStreamingOnly" } }' ``` Ask the locator for its playback paths: ```bash curl -X POST "https://app.mk.io/api/v1/projects//media/streamingLocators/london-broadcast-locator/listPaths" \ -H "Authorization: Bearer " ``` Each `streamingPaths[]` group can contain several entries in its `paths[]` array. Select the protocol and encryption combination you need, then retrieve the streaming endpoint you are using: ```bash curl -X GET "https://app.mk.io/api/v1/projects//media/streamingEndpoints/default" \ -H "Authorization: Bearer " ``` Replace `default` if you are reusing an endpoint with a different name. Read `properties.hostName` and `properties.cdnBasePath` from the response. Insert the CDN base path between the hostname and the selected locator path. Omit that part when no base path is returned, and use one slash at each boundary: ```text https:// ``` `` is `properties.hostName`, `` is the optional `properties.cdnBasePath`, and `` is the selected entry from `streamingPaths[].paths[]`. Check that the manifest is reachable: ```bash curl -I "https://" ``` A `200 OK` response confirms that the manifest is reachable. It does not prove that current media is flowing through the complete chain. Confirm that manifest timestamps or segments advance, then open the URL in an HLS-capable player or inspect it with `ffprobe` to verify decoding. Because the event is still `Running`, what you're watching is live-to-VOD playback of a sliding DVR window, not a finished recording. The window length is whatever you set as `archiveWindowLength` when you created the event in Step 4. See [Streaming and publishing](/mkio/api-guides/how-to/media/publishing) for DASH, DRM, and CDN options beyond this clear-streaming example. ## Step 9: Stop and clean up ```bash curl -X PATCH "https://app.mk.io/api/v1/projects//live/liveEvents/london-broadcast" \ -H "Authorization: Bearer " \ -H "Content-Type: application/json" \ -d '{ "spec": { "state": "Stopped" } }' ``` Poll the state endpoint until `status.state` is `Stopped`. When you no longer need the live resource, delete it: ```bash curl -X DELETE "https://app.mk.io/api/v1/projects//live/liveEvents/london-broadcast" \ -H "Authorization: Bearer " ``` Stop the contribution encoder. If you started a streaming endpoint only for this test, stop it after confirming no other streams need it: ```bash curl -X POST "https://app.mk.io/api/v1/projects//media/streamingEndpoints/default/stop" \ -H "Authorization: Bearer " ``` Use the endpoint name you created and poll its `/state` endpoint until it reports `Stopped`. Keep a shared endpoint running while other streams need it. Review the recording before deleting assets or storage. ## What comes next You have created a source, asset, encoding config, and live event, then published the output and checked playback. Multiview, scheduled automation, destinations, and refiners all build on the same structure. - [Core concepts](/mkio/api-guides/how-to/live/core-concepts): inputs and outputs, refiners, resource states, and how templates connect to live resources, in full. - [Streaming and publishing](/mkio/api-guides/how-to/media/publishing): the full publishing model, including DASH, DRM, CDN, and playback filters. - [Manage live channels and events](/mkio/api-guides/how-to/live/manage-live): the full reference for every operation on liveChannels and liveEvents, including destinations and config overrides. - [Scheduled operations](/mkio/api-guides/how-to/live/scheduled-operations): pre-program the start and stop times instead of patching state by hand. - [Monitor live resources](/mkio/api-guides/how-to/live/monitor-live): the full status object, metrics, and monitoring URLs. - [Multiview](/mkio/api-guides/how-to/live/multiview): the equivalent walkthrough for composing several camera feeds into one output. # Build with the Management API The Management API is the control plane for MK.IO. Use it when you need to create projects, manage users and teams, issue tokens, assign payment methods, enable metrics, or configure webhook rules that other workflows depend on. ## API overview
Detail Value
Base path /api/v1/
Scope Organization and project
Reference Management API reference
## How the Management API fits into other workflows You often use this API before you use anything else: 1. Create a project and assign billing. 2. Grant access to the right users and teams. 3. Create or rotate tokens for automation. 4. Add webhook rules so media or fleet workflows can notify your application. That makes the Management API the setup and governance layer for the rest of the platform. ## Common workflow patterns ### Provision and govern an organisation 1. [Create a project and assign billing](/mkio/api-guides/how-to/management/org-provisioning) 2. [Set up users and teams](/mkio/api-guides/how-to/management/users-and-teams) 3. [Create tokens for automation](/mkio/api-guides/how-to/management/tokens) 4. [Configure webhook rules](/mkio/api-guides/how-to/management/webhooks) 5. [Monitor usage and billing](/mkio/api-guides/how-to/management/usage-and-billing) ## Guides [Users and teams](/mkio/api-guides/how-to/management/users-and-teams) Understand users, invites, teams, roles, scopes, and the JSON Patch operations used to evolve team access. [Tokens](/mkio/api-guides/how-to/management/tokens) Create full-access or restricted tokens, inspect token metadata, and revoke user or organization tokens. [Organizations and invites](/mkio/api-guides/how-to/management/organizations-and-invites) Inspect accessible organizations, accept pending invitations, and leave or decline organization access cleanly. [Webhook rules](/mkio/api-guides/how-to/management/webhooks) Register webhook destinations, choose events, and inspect event delivery status for each rule. [Usage and billing](/mkio/api-guides/how-to/management/usage-and-billing) Inspect current project usage, run date-range reports, assign payment methods, and enable metrics export. ## Workflow guide [Provision org and users](/mkio/api-guides/how-to/management/org-provisioning) Create a project, assign billing, then move into access and token setup for the people and systems that will use it. # Provision org and users This guide covers the setup that happens first in a new MK.IO environment: confirm the organization, create a project, assign billing, then prepare access for the people and automation that will use it. Each resource here has its own detailed guide; this page is the order to do them in. A project is the container that holds your media objects, and each project and payment method belongs to exactly one organization. So the sequence is always organization, then billing, then project, then access. ## Step 1: Confirm or create the organization Check which organization the current token belongs to: ```bash curl -X GET "https://app.mk.io/api/v1/organization" \ -H "Authorization: Bearer " ``` If the user needs a new organization, create one. Only `name` is required; the legal-entity fields are optional. ```bash curl -X POST "https://app.mk.io/api/v1/organization" \ -H "Authorization: Bearer " \ -H "Content-Type: application/json" \ -d '{ "spec": { "name": "Example Media Organization", "legalEntityName": "Example Media Ltd", "legalEntityContactEmail": "legal@example.com" } }' ``` ## Step 2: Pick a payment method A project cannot be created without a payment method, so list the ones available first: ```bash curl -X GET "https://app.mk.io/api/v1/organization/paymentMethods" \ -H "Authorization: Bearer " ``` If the chosen method requires terms acceptance, accept them before assigning it: ```bash curl -X POST "https://app.mk.io/api/v1/organization/paymentMethods//acceptTermsAndConditions" \ -H "Authorization: Bearer " ``` ## Step 3: Create the project A project is created with `PUT`, using the name in the URL. It requires `displayName`, `locationName`, and `paymentMethodId`. ```bash curl -X PUT "https://app.mk.io/api/v1/projects/production-media" \ -H "Authorization: Bearer " \ -H "Content-Type: application/json" \ -d '{ "displayName": "Production Media", "locationName": "westeurope", "paymentMethodId": "" }' ``` Assigning a payment method also activates the project. You can read or replace the assignment later through `/projects//paymentMethod`; see [Usage and billing](/mkio/api-guides/how-to/management/usage-and-billing). ## Step 4: Prepare access Review the users, roles, and scopes the organization already has, which are the inputs for team setup: ```bash curl -X GET "https://app.mk.io/api/v1/organization/users" \ -H "Authorization: Bearer " curl -X GET "https://app.mk.io/api/v1/organization/roles" \ -H "Authorization: Bearer " curl -X GET "https://app.mk.io/api/v1/organization/scopes" \ -H "Authorization: Bearer " ``` Then create a team that grants roles under a scope. See [Users and teams](/mkio/api-guides/how-to/management/users-and-teams) for the full access model and the JSON Patch operations used to evolve a team. ```bash curl -X PUT "https://app.mk.io/api/v1/organization/teams/video-engineering" \ -H "Authorization: Bearer " \ -H "Content-Type: application/json" \ -d '{ "spec": { "description": "Team for day-to-day project operations", "members": {}, "scopes": { "": { "roles": [""] } } } }' ``` ## Step 5: Create automation tokens Create a token for the systems that will call the APIs. Prefer a `restricted` token for automation so it cannot do more than the job needs. See [Tokens](/mkio/api-guides/how-to/management/tokens). ```bash curl -X POST "https://app.mk.io/api/v1/user/tokens" \ -H "Authorization: Bearer " \ -H "Content-Type: application/json" \ -d '{ "type": "restricted", "description": "Project automation token", "organizationId": "", "permissions": {} }' ``` ## Step 6: Add webhook rules early If the project will run jobs or live workflows, add [webhook rules](/mkio/api-guides/how-to/management/webhooks) at the start rather than waiting until polling becomes painful. That lets your application react to job completion, live channel state changes, and locator creation from day one. ## What goes wrong - **Creating a project before billing exists.** A project needs a `paymentMethodId`, and some methods need terms accepted first. Do Step 2 before Step 3. - **Assigning everything to individual users.** Grant roles to teams under scopes, then add users to teams. It is reusable and far easier to audit. ## What comes next - [Users and teams](/mkio/api-guides/how-to/management/users-and-teams): roles, scopes, and JSON Patch in detail. - [Tokens](/mkio/api-guides/how-to/management/tokens): choose token types and inspect token metadata. - [Build with the Media API](/mkio/api-guides/how-to/media): move from setup into media workflows. # Organizations and invites Organization membership has two sides. An admin invites people to an organization and can cancel a pending invite. A user accepts or declines invitations, lists the organizations they can reach, and leaves an organization. The two use different endpoint groups: `/organization/invites` for the admin side, and `/user/organizations` for the user side. ## Invite a user (admin) Create a pending invitation by email. A `comment` explains why, and `teams` adds the user to those teams when they accept. ```bash curl -X POST "https://app.mk.io/api/v1/organization/invites" \ -H "Authorization: Bearer " \ -H "Content-Type: application/json" \ -d '{ "spec": { "email": "jane.smith@example.com", "comment": "Video encoding specialist for the Delphi project", "teams": ["encoding-team"] } }' ``` The invited user receives an email with an invitation link. Two things are worth knowing: an invitation **expires after 14 days**, and an accepted user **automatically joins the Everyone team** in addition to any teams you name. List pending invites, and cancel one that is no longer needed: ```bash curl -X GET "https://app.mk.io/api/v1/organization/invites" \ -H "Authorization: Bearer " curl -X DELETE "https://app.mk.io/api/v1/organization/invites/" \ -H "Authorization: Bearer " ``` ## List the organizations a user can reach From the user side, list every organization the current user belongs to, plus any they have a pending invite to: ```bash curl -X GET "https://app.mk.io/api/v1/user/organizations" \ -H "Authorization: Bearer " ``` If an organization record carries an `invite` object, the user has not joined it yet. The `invite` includes who sent it, a comment, and a `state`. ## Accept an invitation Accepting is a `PATCH` on the user's organization record. The invite `state` is the only field you can change; set it to `accepted` to join. ```bash curl -X PATCH "https://app.mk.io/api/v1/user/organizations/" \ -H "Authorization: Bearer " \ -H "Content-Type: application/json" \ -d '{ "spec": { "invite": { "state": "accepted" } } }' ``` ## Decline an invite or leave an organization `DELETE` on the same resource handles both, depending on the current relationship: it declines a pending invite, or removes a current member from the organization. ```bash curl -X DELETE "https://app.mk.io/api/v1/user/organizations/" \ -H "Authorization: Bearer " ``` Leaving is only reversible by accepting a fresh invitation, so confirm before you call it. ## What goes wrong - **An invite that is never accepted in time.** Invitations expire after 14 days. Re-send if the window passes. - **Using the wrong endpoint group.** Use `/organization/invites` when an admin manages invitations for others, and `/user/organizations` when the current user accepts, declines, or leaves. They are not interchangeable. ## What comes next - [Users and teams](/mkio/api-guides/how-to/management/users-and-teams): the team, role, and scope model new members are granted access through. - [Provision org and users](/mkio/api-guides/how-to/management/org-provisioning): the full setup sequence from organization to access. # Tokens Tokens authenticate applications to the MK.IO APIs. The Management API gives you two views: user-level management for your own tokens, and organization-level management for auditing or revoking tokens across the organization. A token never grants more than the user who created it has, so the main decision is how much of that access to expose. ## Choosing a token type There are four types. For automation, prefer `restricted` so an exposed token cannot do more than its job requires.
Type Capabilities Expiry
login Full user capabilities Short-lived
full-access Full user capabilities Optional, up to one year
restricted A scoped subset you define Optional, up to one year
ephemeral A scoped subset, short-lived Short-lived
## Create a full-access token A token is created with `POST`. `type` and `organizationId` are always required. ```bash curl -X POST "https://app.mk.io/api/v1/user/tokens" \ -H "Authorization: Bearer " \ -H "Content-Type: application/json" \ -d '{ "type": "full-access", "description": "CI deployment token", "organizationId": "", "expireDate": "2027-01-01T00:00:00Z" }' ``` The response includes the generated token as `metadata.JWT`. MK.IO does not store it, so it is **visible only at creation time, for five minutes**. Copy it somewhere secure immediately. ## Create a restricted token A `restricted` token adds a `permissions` object that must be a strict subset of your own capabilities. Read your access first so you know what you can grant: ```bash curl -X GET "https://app.mk.io/api/v1/user/rbac" \ -H "Authorization: Bearer " ``` Then build `permissions` from a subset of that structure. This example grants only asset operations on one project: ```bash curl -X POST "https://app.mk.io/api/v1/user/tokens" \ -H "Authorization: Bearer " \ -H "Content-Type: application/json" \ -d '{ "type": "restricted", "description": "Asset automation, one project", "organizationId": "", "expireDate": "2027-01-01T00:00:00Z", "permissions": { "core.project": { "": { "ams.asset": ["create", "delete", "get", "update"] } } } }' ``` ## Inspect and revoke List or read your own tokens. Expired tokens are filtered out of the list. ```bash curl -X GET "https://app.mk.io/api/v1/user/tokens" \ -H "Authorization: Bearer " ``` A token record carries operational fields including `issued`, `expires`, `lastUsed`, `revoked`, and (for restricted tokens) `permissions`. Revoke one token, or all of your tokens at once: ```bash curl -X DELETE "https://app.mk.io/api/v1/user/tokens/" \ -H "Authorization: Bearer " ``` ```bash curl -X DELETE "https://app.mk.io/api/v1/user/tokens" \ -H "Authorization: Bearer " ``` Use the revoke-all carefully: it affects all of your tokens across organizations. ## Audit tokens across the organization An organization admin can list every token with access to the organization, and revoke any of them: ```bash curl -X GET "https://app.mk.io/api/v1/organization/tokens" \ -H "Authorization: Bearer " curl -X DELETE "https://app.mk.io/api/v1/organization/tokens/" \ -H "Authorization: Bearer " ``` ## What goes wrong - **The token is lost after creation.** The `JWT` is shown once, for five minutes, and is never stored. If you miss it, revoke the token and create a new one. - **A restricted token returns `403`.** Its `permissions` must be a subset of your own access. Compare against `/api/v1/user/rbac`, and remember the token loses capabilities if your own access is later reduced. - **Forgetting the expiry ceiling.** `expireDate` cannot be more than one year after creation. ## What comes next - [Users and teams](/mkio/api-guides/how-to/management/users-and-teams): the access model a token's permissions draw from. - [Authentication and tokens](/mkio/api-guides/getting-started/authentication): bearer-auth basics and UI-based personal token creation. # Usage and billing The Management API offers two reporting views. Project usage gives the current billing-month view for one project. Organization usage reports query a custom date range across selected projects or payment methods. The same surface manages payment methods and project metrics export. MK.IO bills on metered, pay-as-you-go usage, so these reports map directly to what you are charged. ## Current project usage For a quick month-to-date view of one project: ```bash curl -X GET "https://app.mk.io/api/v1/projects//usage" \ -H "Authorization: Bearer " ``` This returns usage since the start of the current month, grouped by meter. ## Date-range usage reports For any other range, post a query to the reporting endpoint. `startDate` is inclusive and `endDate` is exclusive, both as `YYYY-MM-DD` in UTC. ```bash curl -X POST "https://app.mk.io/api/v1/organization/reports/usage" \ -H "Authorization: Bearer " \ -H "Content-Type: application/json" \ -d '{ "startDate": "2026-01-01", "endDate": "2026-02-01", "granularity": "day", "projectNames": ["my-project"] }' ``` The query supports: - `granularity`: `hour`, `day`, `week`, `month`, or `year`. The range is capped by granularity: 31 days for `hour`, one year for `day`, and unbounded for `week` and above. - `projectNames` or `paymentMethodIds` to filter. These two are mutually exclusive. - `format`: `json` (default) or `csv`. - `download`: set `true` to return the report as a file download. - `filterOnReportedDate`: set `true` to filter by when usage was charged rather than when it occurred, which helps reconcile against invoice dates. To pull a CSV for finance: ```bash curl -X POST "https://app.mk.io/api/v1/organization/reports/usage" \ -H "Authorization: Bearer " \ -H "Content-Type: application/json" \ -d '{ "startDate": "2026-01-01", "endDate": "2026-02-01", "format": "csv", "download": true, "filterOnReportedDate": true }' ``` ## Payment methods List the organization's payment methods, and read one method's rate card to see per-meter prices: ```bash curl -X GET "https://app.mk.io/api/v1/organization/paymentMethods" \ -H "Authorization: Bearer " curl -X GET "https://app.mk.io/api/v1/organization/paymentMethods//rateCard" \ -H "Authorization: Bearer " ``` Read or replace the method assigned to a project: ```bash curl -X GET "https://app.mk.io/api/v1/projects//paymentMethod" \ -H "Authorization: Bearer " curl -X POST "https://app.mk.io/api/v1/projects//paymentMethod" \ -H "Authorization: Bearer " \ -H "Content-Type: application/json" \ -d '{ "paymentMethodId": "" }' ``` ## Enable metrics export Enabling metrics export is billable. Confirm the action and current rate card before turning it on. Enable the project metrics endpoint with a `PATCH`: ```bash curl -X PATCH "https://app.mk.io/api/v1/projects//metricsEndpoint" \ -H "Authorization: Bearer " \ -H "Content-Type: application/json" \ -d '{ "spec": { "enabled": true } }' ``` The read response returns `url`, `username`, and `password`. Treat the username and password as secrets. The URL exposes current Prometheus-format samples through `/federate`; it is not a historical query API. Source values refresh at approximately 30-second intervals. Faster scraping does not create fresher values. Use external Prometheus-compatible storage and Grafana for retained history, trends, and dashboards. Metrics ending in `_total`, including ETR-290 totals, are cumulative counters. Calculate rates from retained samples. The export does not provide viewer count, viewer geography, startup time, rebuffering, or player errors. Streaming endpoint request rate and egress bitrate represent delivery traffic, not viewer, session, or concurrency counts. ## What goes wrong - **A payment method seems stuck on a project.** A method cannot be removed, only replaced with another. Assigning one also activates the project. - **An hourly report is rejected for too wide a range.** `hour` granularity is limited to 31 days. Use `day` or coarser for longer ranges. - **Report totals do not match an invoice.** The report defaults to when usage occurred. Set `filterOnReportedDate` to `true` to align with billing dates. ## What comes next - [Provision org and users](/mkio/api-guides/how-to/management/org-provisioning): set up projects before reporting on them. - [Management API reference](/api-reference/management-api): the full reporting and billing schemas. # Users and teams The Management API models access in layers. Users belong to an organization, teams group users, roles define capabilities, and scopes define which resources those capabilities apply to. Access is granted by giving a team one or more roles under a scope, then adding users to the team. Granting access team-by-team rather than user-by-user keeps it reusable and easy to audit. The usual sequence is: identify the users, inspect the available roles and scopes, create or update a team that maps roles to a scope, and add members. ## List users, roles, and scopes Start by looking at what already exists. List the users in the organization: ```bash curl -X GET "https://app.mk.io/api/v1/organization/users" \ -H "Authorization: Bearer " ``` Inspect the roles and scopes the organization defines, which are the building blocks of a team's access. A role record lists its `capabilities`; a scope record lists the `resources` it covers. ```bash curl -X GET "https://app.mk.io/api/v1/organization/roles" \ -H "Authorization: Bearer " curl -X GET "https://app.mk.io/api/v1/organization/scopes" \ -H "Authorization: Bearer " ``` ## Create a team A team is created or replaced with `PUT`. The `spec` holds `members` (a map keyed by user ID, where `isTeamAdmin` lets a member edit the team) and `scopes` (a map keyed by scope name, each with a `roles` array). ```bash curl -X PUT "https://app.mk.io/api/v1/organization/teams/video-engineering" \ -H "Authorization: Bearer " \ -H "Content-Type: application/json" \ -d '{ "spec": { "description": "Team for media workflow operations", "members": { "": { "isTeamAdmin": true } }, "scopes": { "": { "roles": [""] } } } }' ``` A `PUT` replaces the whole team spec. To change one thing on an existing team, use JSON Patch instead, as shown next. ## Evolve a team with JSON Patch The team `PATCH` endpoint takes a JSON Patch document (an array of operations), which is the safe way to change one part of a team without resending the whole spec. Add a member: ```bash curl -X PATCH "https://app.mk.io/api/v1/organization/teams/video-engineering" \ -H "Authorization: Bearer " \ -H "Content-Type: application/json" \ -d '[ { "op": "add", "path": "/spec/members/", "value": { "isTeamAdmin": false } } ]' ``` Add a role under a scope: ```bash curl -X PATCH "https://app.mk.io/api/v1/organization/teams/video-engineering" \ -H "Authorization: Bearer " \ -H "Content-Type: application/json" \ -d '[ { "op": "add", "path": "/spec/scopes//roles/-", "value": "" } ]' ``` Remove a member: ```bash curl -X PATCH "https://app.mk.io/api/v1/organization/teams/video-engineering" \ -H "Authorization: Bearer " \ -H "Content-Type: application/json" \ -d '[ { "op": "remove", "path": "/spec/members/" } ]' ``` The same `op` values (`add`, `replace`, `remove`) work for scopes and roles. Use `replace` on `/spec/members//isTeamAdmin` to promote or demote a member. ## Check what a token can actually do To see the capabilities the current token holds, read its role-based access control (RBAC) data. This is the fastest way to debug a `403 Forbidden`, and it is the starting point for building a restricted token. ```bash curl -X GET "https://app.mk.io/api/v1/user/rbac" \ -H "Authorization: Bearer " ``` ## What goes wrong - **A `PUT` wipes team members you meant to keep.** `PUT` replaces the entire spec. To change one member or role on a live team, use the JSON Patch endpoint. - **Deleting a team does not remove the users.** It removes the team and the access it granted; the users remain in the organization. - **A restricted token cannot exceed your own access.** When you design one, compare it against `/api/v1/user/rbac`; the token's permissions must be a subset. See [Tokens](/mkio/api-guides/how-to/management/tokens). ## What comes next - [Organizations and invites](/mkio/api-guides/how-to/management/organizations-and-invites): the invitation lifecycle for adding new users. - [Tokens](/mkio/api-guides/how-to/management/tokens): create restricted automation tokens against this access model. # Webhook rules This guide covers the management side of webhooks: creating rules, updating them, and reading delivery history. For the event model and the delivered payload shape, see [Webhooks](/mkio/api-guides/understanding/webhooks). Each rule is project-scoped and identified by a stable name in the URL. The practical pattern is to name the rule for its purpose, create or update it with `PUT`, read it back to confirm the non-secret configuration, and inspect its `/events` history when debugging delivery. ## Create or update a rule A rule is created or replaced with `PUT` at its name. The `spec` requires `enabled`, `url`, and `events`. Put secrets in `authentication.headers` or `authentication.queryParams`, which are write-only; put non-sensitive decoration in the top-level `headers` and `queryParams`. ```bash curl -X PUT "https://app.mk.io/api/v1/projects//webhook/rules/job-notifications" \ -H "Authorization: Bearer " \ -H "Content-Type: application/json" \ -d '{ "spec": { "url": "https://your-endpoint.example.com/webhook", "enabled": true, "events": ["MediaKind.JobStarted", "MediaKind.JobFinished"], "authentication": { "headers": { "X-Webhook-Secret": "" } }, "headers": { "X-Source": "mkio" } } }' ``` Because `PUT` replaces the whole rule, include the full `spec` each time. To pause delivery without losing the rule, send the same `PUT` with `enabled` set to `false`. ## Read the rule ```bash curl -X GET "https://app.mk.io/api/v1/projects//webhook/rules" \ -H "Authorization: Bearer " curl -X GET "https://app.mk.io/api/v1/projects//webhook/rules/job-notifications" \ -H "Authorization: Bearer " ``` Authentication values read back masked, so use the read response to confirm the structure, enabled state, URL, events, and non-secret headers, not the secrets themselves. ## Inspect delivery history When an application reports a missing event, the rule's `events` collection is the first place to look: ```bash curl -X GET "https://app.mk.io/api/v1/projects//webhook/rules/job-notifications/events" \ -H "Authorization: Bearer " ``` Each record carries `created`, `source`, `type`, and a `status` of `Pending`, `Retrying`, `Failed`, or `Sent`. A `Failed` or stuck `Retrying` status points at the receiving endpoint rather than MK.IO. ## Delete a rule ```bash curl -X DELETE "https://app.mk.io/api/v1/projects//webhook/rules/job-notifications" \ -H "Authorization: Bearer " ``` Deleting a rule also removes its event history, so export anything you need first. ## What goes wrong - **A `PUT` drops fields you forgot to include.** It replaces the entire `spec`. Read the rule, change what you need, and send the complete spec back. - **Secrets look wrong on read.** Authentication values are write-only and read back masked. That is expected; they are still sent on delivery. - **Events never arrive.** Check the `/events` history. A `Failed` status means your endpoint rejected the delivery, so verify it is reachable over HTTPS and returns a success response. See the handler guidance in [Webhooks](/mkio/api-guides/understanding/webhooks). ## What comes next - [Webhooks](/mkio/api-guides/understanding/webhooks): the payload model, supported events, and handler design. - [Transforms and jobs](/mkio/api-guides/how-to/media/transforms-and-jobs): pair job workflows with completion events. # Build with the Media API The Media API is the operational API for media processing and delivery in MK.IO. Use it when you need to register storage, create assets, run transforms and jobs, manage live events, publish content with streaming locators, or protect playback with streaming and content key policies. ## API overview
Detail Value
Base path /api/v1/projects/{project_name}/media/
Scope Project
Reference Media API reference
## How the core resources connect The Media API becomes much easier to use once you understand the sequence: 1. A **storage** instance tells MK.IO how to reach cloud storage. 2. An **asset** points to content in that storage. 3. A **transform** defines processing instructions. 4. A **job** applies the transform to the asset and creates output assets. 5. A **streaming locator** publishes an asset by linking it to a **streaming policy**. 6. A **streaming endpoint** provides the delivery domain for the playback paths returned by `listPaths`. 7. A **content key policy** becomes part of the chain when you need DRM or token-based key delivery. That resource model supports both VOD and live workflows. The difference is whether the asset is created from existing stored content or continuously written by a live output.
Two live APIs

/media/liveEvents and /live/liveEvents are separate resource models. A resource created through one API is invisible to the other. Use the Live API workflow for template-based encoding and multiview.

## Common workflow patterns ### VOD workflow 1. [Register storage](/mkio/api-guides/how-to/media/storage). 2. [Create a source asset](/mkio/api-guides/how-to/media/assets). 3. [Run a transform job](/mkio/api-guides/how-to/media/transforms-and-jobs). 4. [Publish with a streaming locator](/mkio/api-guides/how-to/media/publishing). ### Media API live event 1. [Register storage](/mkio/api-guides/how-to/media/storage). 2. [Create and start a live event](/mkio/api-guides/how-to/media/live-streaming). 3. [Create a live output to archive the stream](/mkio/api-guides/how-to/media/live-streaming). 4. [Publish with a streaming locator](/mkio/api-guides/how-to/media/publishing). ### Live API template-based workflow 1. [Create a source and asset](/mkio/api-guides/how-to/media/content-and-sources). 2. [Create a config from a preset](/mkio/api-guides/how-to/templates/manage-templates). 3. [Create and start the Live API event](/mkio/api-guides/how-to/live/walkthrough). 4. [Publish the output asset](/mkio/api-guides/how-to/media/publishing). ### Protected playback 1. [Publish with a DRM-capable streaming policy](/mkio/api-guides/how-to/media/publishing). 2. [Create a content key policy](/mkio/api-guides/how-to/media/content-protection). 3. [Create a streaming locator referencing both](/mkio/api-guides/how-to/media/publishing). ## Guides [Storage](/mkio/api-guides/how-to/media/storage) Register Azure, AWS, or Google storage and manage the credentials MK.IO uses to access it. [Assets](/mkio/api-guides/how-to/media/assets) Create assets, inspect tracks, request file access information, organize content with labels, and apply filters. [Download asset files](/mkio/api-guides/how-to/media/download-asset-files) Retrieve one file from an asset by requesting access information, then using the returned access URL and JWT. [Playback filters](/mkio/api-guides/how-to/media/playback-filters) Create asset or account filters for time ranges, track selection, and startup quality, then apply them through locators. [Transforms and jobs](/mkio/api-guides/how-to/media/transforms-and-jobs) Define reusable processing profiles and run them against assets. [Live streaming](/mkio/api-guides/how-to/media/live-streaming) Create Media API live events, connect encoders, archive with live outputs, and publish live playback. [Live API walkthrough](/mkio/api-guides/how-to/live/walkthrough) Build a template-based Live API event. Use this workflow for multiview and reusable encoding configs. [Streaming and publishing](/mkio/api-guides/how-to/media/publishing) Create streaming endpoints, locators, and policies, then retrieve playback URLs. [Content protection](/mkio/api-guides/how-to/media/content-protection) Add DRM and key-delivery configuration to published assets. [Content, sources, and destinations](/mkio/api-guides/how-to/media/content-and-sources) Create content identifiers, ingest sources, and egress destinations for use with the Live API. ## Workflow guide [Automate a VOD pipeline](/mkio/api-guides/how-to/media/vod-pipeline) Follow an end-to-end flow from source asset through transform job to published playback. # Assets An asset is the core media record in the Media API. It points to content in a registered storage location and becomes the unit you pass into jobs, attach to streaming locators, inspect for tracks, and organize with labels. An asset maps to a container in Azure or a bucket in AWS storage. See [Assets](/mkio/understanding/core-concepts/assets) for the product background. In a typical workflow you create an asset that points to source content or a target output location, run a job against it or write live output into it, then publish it through a streaming locator. ## Create an asset An asset is created with `PUT`. The only required field is `properties.storageAccountName`, which names the storage instance you registered. The rest position the asset within that storage and attach metadata. ```bash curl -X PUT "https://app.mk.io/api/v1/projects//media/assets/source-video" \ -H "Authorization: Bearer " \ -H "Content-Type: application/json" \ -d '{ "properties": { "storageAccountName": "primary-azure", "container": "source-video", "description": "Source video for encoding", "subPath": "incoming", "containerDeletionPolicy": "Retain" }, "labels": { "series": "my-show", "season": "2" } }' ``` The fields worth knowing: - `storageAccountName` (required): the registered storage instance to use. - `container`: the storage container or bucket for the asset. - `subPath`: a directory path inside the container. It is immutable after creation. - `containerDeletionPolicy`: `Delete` or `Retain`. It controls whether deleting the asset also deletes the underlying storage container. - `labels`: up to 32 key-value pairs, used for filtering and grouping. Storage placement is fixed at creation. Treat `storageAccountName`, `container`, and `subPath` as create-time decisions in your automation. ## Read the asset or just its state Read the full asset with a `GET`: ```bash curl -X GET "https://app.mk.io/api/v1/projects//media/assets/source-video" \ -H "Authorization: Bearer " ``` When you only need readiness in a polling loop, read the lightweight state endpoint instead of the full object. See [Resource states](/mkio/api-guides/understanding/resource-states) for the asset state values. ```bash curl -X GET "https://app.mk.io/api/v1/projects//media/assets/source-video/state" \ -H "Authorization: Bearer " ``` ## Inspect tracks and request file access Two read operations are commonly useful once an asset exists. Enumerate the container contents and track listings, including language and bitrate where available: ```bash curl -X GET "https://app.mk.io/api/v1/projects//media/assets/source-video/storage/" \ -H "Authorization: Bearer " ``` Request the information needed to read files directly from the underlying storage: ```bash curl -X POST "https://app.mk.io/api/v1/projects//media/assets/source-video/getFileAccessInfo" \ -H "Authorization: Bearer " ``` The response returns `storageAccountName`, `containerName`, `jwt`, `url`, and an optional `subPath`. The storage instance must have a valid credential for this to succeed. For the full two-step download flow, see [Download asset files](/mkio/api-guides/how-to/media/download-asset-files). ## Organize assets with labels Labels are part of the asset schema and are designed for retrieval, not just description. Query by an exact label value: ```bash curl -X GET "https://app.mk.io/api/v1/projects//media/assets?\$label=series=my-show" \ -H "Authorization: Bearer " ``` Or require the presence of several keys at once: ```bash curl -X GET "https://app.mk.io/api/v1/projects//media/assets?\$label_key=series&\$label_key=region" \ -H "Authorization: Bearer " ``` The asset list also supports `$top`, `$skiptoken`, `$orderby`, and `$filter`. See [Pagination and filtering](/mkio/api-guides/understanding/pagination). ## See where an asset is published To find out whether an asset is already exposed for playback, list the locators attached to it rather than scanning every locator in the project: ```bash curl -X POST "https://app.mk.io/api/v1/projects//media/assets/source-video/listStreamingLocators" \ -H "Authorization: Bearer " ``` ## What goes wrong - **Deleting an asset can delete the content.** When `containerDeletionPolicy` is `Delete`, removing the asset also removes the underlying container and everything in it. Set `Retain` when the stored files must survive the asset record. - **Deleting an asset can strand a stopped Live API resource.** Deletion does not immediately repair or invalidate the dependent resource. A later start can be accepted and remain in `Starting`. Search for dependencies where possible, and retrieve each referenced asset immediately before startup. - **`getFileAccessInfo` fails after a credential expires.** The most common cause is an expired storage credential. Rotate it first; see [Storage](/mkio/api-guides/how-to/media/storage). - **Trying to move an asset after creation.** Storage placement fields are immutable. To relocate content, create a new asset. ```bash curl -X DELETE "https://app.mk.io/api/v1/projects//media/assets/source-video" \ -H "Authorization: Bearer " ``` ## What comes next - [Transforms and jobs](/mkio/api-guides/how-to/media/transforms-and-jobs): process assets through reusable transforms. - [Playback filters](/mkio/api-guides/how-to/media/playback-filters): publish a shaped subset of an asset. - [Streaming and publishing](/mkio/api-guides/how-to/media/publishing): publish assets for playback. # Content, sources, and destinations Content, sources, and destinations are the ingest and egress building blocks for Live API workflows. They are managed through the Media API and referenced by name in Live API resource inputs and outputs. - **Content** is a named logical identifier for a stream. It carries no transport settings. - **Sources** attach an ingest transport to content on a specific network. A source is how a stream physically arrives. - **Destinations** define where a resource output is delivered. A destination is how a stream physically leaves. ## Content ### Create a content resource ```bash curl -X PUT "https://app.mk.io/api/v1/projects//media/content/channel-1" \ -H "Authorization: Bearer " \ -H "Content-Type: application/json" \ -d '{ "metadata": { "displayName": "Channel 1" } }' ``` The content name is set in the URL path. It must match `^[a-z0-9]([a-z0-9-]{0,61}[a-z0-9])?$`. A content resource has no spec fields; it is a named identifier only. ### Get and list content ```bash curl -X GET "https://app.mk.io/api/v1/projects//media/content/channel-1" \ -H "Authorization: Bearer " curl -X GET "https://app.mk.io/api/v1/projects//media/content" \ -H "Authorization: Bearer " ``` The response includes `status.state`, which is `Active` when one or more live resources are using this content, or `Inactive` otherwise. ### Update content PATCH updates `metadata.displayName` and `metadata.labels` only. Content has no mutable spec fields. ### Delete content ```bash curl -X DELETE "https://app.mk.io/api/v1/projects//media/content/channel-1" \ -H "Authorization: Bearer " ``` If the resource does not exist, the API returns `204`. ## Sources A source associates content with a transport on a specific network. When a Live API resource specifies a `contentName` as its input, the system resolves which sources supply that content on a network the resource can reach. You can also reference a source directly by `sourceName` to bypass content resolution. ### Create a source ```bash curl -X PUT "https://app.mk.io/api/v1/projects//media/sources/encoder-london" \ -H "Authorization: Bearer " \ -H "Content-Type: application/json" \ -d '{ "metadata": { "displayName": "Encoder London" }, "spec": { "contentName": "channel-1", "networkName": "internet", "transport": { "type": "SRTListener", "port": 5000, "latency": 0.5, "maxBitrate": 30000000, "ipResource": { "type": "External" } } } }' ``` After creation, `status.transport.urls` contains the allocated connection URL for listener-type transports. ### Update a source `networkName`, transport `type`, and transport settings such as the listener port and latency are set at creation. Source PATCH supports the following changes:
Field Applies to
spec.contentName Assign the source to content, or set null to remove the association.
spec.transport.passPhrase SRTCaller and SRTListener.
spec.transport.allowList SRTListener.
spec.transport.url SRTCaller and HLSPullInput.
spec.transport.user and spec.transport.password HLSPullInput.
For example, update the SRT listener allowlist without recreating the source: ```bash curl -X PATCH "https://app.mk.io/api/v1/projects//media/sources/encoder-london" \ -H "Authorization: Bearer " \ -H "Content-Type: application/json" \ -d '{ "spec": { "transport": { "allowList": [""] } } }' ``` Replace `` with the encoder's public IP address. Retrieve the source afterwards and confirm `spec.transport.allowList`. Changes to the destination resource use a different update contract, described under [Destinations](/mkio/api-guides/how-to/media/content-and-sources#destinations). ### Source transport types The `transport.type` field determines which other fields apply. #### SRTListener The system opens an SRT listener. Encoders or upstream systems connect to it.
Field Default Immutable Description
port 5000 Yes The port to listen on.
latency 0.5 Yes Minimum latency in seconds.
maxBitrate 30000000 Yes Maximum bitrate in bits per second.
maxOverheadBandwidth 100 Yes Maximum overhead bandwidth percentage (5 to 100).
encryptionStandard None Yes None, AES128, AES192, or AES256.
passPhrase "" No Passphrase for encrypted connections. Can be updated via PATCH.
allowList Not set No IP addresses permitted to connect. Can be updated via PATCH.
ipResource.type Not set Yes External to reserve a public IP. None or omit for on-premises.
#### SRTCaller The system calls out to a remote SRT listener.
Field Required Immutable Description
url Yes No URL of the remote SRT listener. Can be updated through PATCH.
latency No Yes Minimum latency in seconds. Default 0.5.
maxBitrate No Yes Maximum bitrate in bits per second.
encryptionStandard No Yes None, AES128, AES192, or AES256.
passPhrase No No Passphrase for encrypted connections. Can be updated via PATCH.
#### UDP The system receives a UDP stream.
Field Required Immutable Description
url Yes Yes The UDP multicast or unicast URL.
#### SDI Content arrives via SDI.
Field Required Immutable Description
url Yes Yes The SDI input identifier.
#### HLSPullInput The system pulls from an HLS source.
Field Required Immutable Description
url Yes No The HLS manifest URL. Can be updated through PATCH.
user No No Username for HLS pull authentication. Can be updated through PATCH.
password No No Password for HLS pull authentication. Can be updated through PATCH.
### List and get sources ```bash curl -X GET "https://app.mk.io/api/v1/projects//media/sources" \ -H "Authorization: Bearer " curl -X GET "https://app.mk.io/api/v1/projects//media/sources/encoder-london" \ -H "Authorization: Bearer " ``` Source status includes `state` (`Active` or `Inactive`), `networkDisplayName`, `shortId`, and `transport.urls` for listener-type transports. ### Source state and encoder connections A source is `Active` while an active flow uses it. This state does not mean that an encoder is connected or that media is arriving. It can remain `Active` after FFmpeg or another encoder stops sending. For an SRT listener input, request `Running` on the live resource first. Start the encoder as soon as the resource enters `Starting`. Do not wait for source `Active` before sending. An established listener connection confirms that the encoder reached the listener. It does not confirm live media flow. After the live resource reaches `Running`, verify the expected video and audio through playback. See [Verify media delivery](/mkio/api-guides/how-to/live/monitor-live#verify-media-delivery). ### Delete a source ```bash curl -X DELETE "https://app.mk.io/api/v1/projects//media/sources/encoder-london" \ -H "Authorization: Bearer " ``` If the source does not exist, the API returns `204`. ## Resolving content When a live resource's input uses `contentName` instead of a direct `sourceName`, the platform selects a candidate that can supply that content. Network reachability constrains resolution: a source declares its `networkName`, and the flow must be able to reach that network. If more than one source is attached to the same content name on reachable networks, the platform selects one. This resolution does not by itself guarantee seamless media-aware failover when an encoder stops sending. To select a specific source, reference it directly by `sourceName`. You can also use a [flow input refiner](/mkio/api-guides/how-to/live/core-concepts/inputs#flow-input-refiners) to narrow the candidates. ### Chain live resources Content can also resolve to another flow's output rather than a source, if that flow publishes the content name on its output. This is what makes chaining flows together with `contentName` possible, as an alternative to referencing the upstream flow directly by `flowName`. ### Inspect resolved inputs Use `?$detailedStatus=true` when reading a live resource's resolved inputs. Each `status.inputs` entry reports `sourceName` and `sourceDisplayName` for a source, or `upstreamFlowName` for another flow's output. Resolution still does not confirm media flow. See [Monitor live resources](/mkio/api-guides/how-to/live/monitor-live) for the full status object and source telemetry. ## Destinations A destination defines where a live resource output is delivered. A destination uses a transport for protocol-based egress, or an `aquilaSourceId` for Aquila-based routing. Only live resources that can reach the destination's network can use it. ### Create a destination ```bash curl -X PUT "https://app.mk.io/api/v1/projects//media/destinations/playout-system" \ -H "Authorization: Bearer " \ -H "Content-Type: application/json" \ -d '{ "metadata": { "displayName": "Playout System" }, "spec": { "networkName": "internet", "transport": { "type": "SRTListener", "port": 6000, "latency": 0.5, "maxBitrate": 15000000, "ipResource": { "type": "External" } } } }' ``` Destination transport settings are create-time fields. Destination PATCH accepts metadata only. To change a passphrase, allowlist, network, or other transport setting, recreate the destination. Source and destination PATCH operations do not have the same mutability. To send output to an Aquila source instead of a transport, set `aquilaSourceId` in place of `transport`: ```json "spec": { "aquilaSourceId": "1bfa932d36604506824fdd78642ad08f" } ``` ### Destination transport types Destinations support the following transport types:
Type Description
SRTListener The system opens an SRT listener. Downstream systems connect to receive the stream.
SRTCaller The system calls out to a remote SRT listener at the specified url.
UDP The system pushes UDP to the specified url.
RTMPPushOutput The system pushes RTMP to the specified url. Set streamKey if required.
For SRTListener destinations, `status.transport.urls` contains the allocated connection URL after creation. ### List and get destinations ```bash curl -X GET "https://app.mk.io/api/v1/projects//media/destinations" \ -H "Authorization: Bearer " curl -X GET "https://app.mk.io/api/v1/projects//media/destinations/playout-system" \ -H "Authorization: Bearer " ``` Destination status includes `state` (`Active` or `Inactive`), `networkDisplayName`, and `transport.urls`. ### Delete a destination ```bash curl -X DELETE "https://app.mk.io/api/v1/projects//media/destinations/playout-system" \ -H "Authorization: Bearer " ``` ## What comes next - [Manage live channels and events](/mkio/api-guides/how-to/live/manage-live): create live resources that read from your sources. - [Multiview](/mkio/api-guides/how-to/live/multiview): compose multiple source inputs into a single multiview output. - [Manage templates](/mkio/api-guides/how-to/templates/manage-templates): create the encoding templates your live resources require. # Content protection To configure protected playback with Digital Rights Management (DRM) using the Media API, you combine three resources that meet at the streaming locator: - A **content key policy** defines _how_ decryption keys and DRM licenses are delivered, and _who_ is allowed to receive them. - A **streaming policy** defines _how_ the content is encrypted for playback. - A **streaming locator** ties a policy pair to an asset and publishes it. Separating these resources lets you reuse one key-delivery policy across many assets while choosing a different encryption model for each publication context. You need a content key policy whenever playback must be restricted to entitled viewers or encrypted with DRM, and you can skip it entirely for unprotected playback. This guide builds a working multi-DRM policy. For conceptual background on each DRM system, see the [content protection overview](/mkio/understanding/core-concepts/content-protection). ## How the pieces fit together The protected playback chain is always the same three steps: 1. Create or choose a **content key policy** (the subject of this guide). 2. Create or choose a **streaming policy** (predefined policies cover most cases). 3. Create a **streaming locator** that references the asset, the streaming policy, and the content key policy. The rest of this guide builds that chain. ## The minimal working policy A content key policy is a named resource. Its `properties.options` array holds one or more _options_, and every option pairs two things: - a `configuration`: the DRM system and its license rules. - a `restriction`: who is allowed to receive a license. The most common production setup is multi-DRM (PlayReady and Widevine) gated behind a JSON Web Token (JWT). The request below creates that policy. Replace `` and the verification key with your own values. ```bash curl -X PUT "https://app.mk.io/api/v1/projects//media/contentKeyPolicies/multi-drm-policy" \ -H "Authorization: Bearer " \ -H "Content-Type: application/json" \ -d '{ "properties": { "description": "PlayReady and Widevine, gated by a JWT token", "options": [ { "name": "playready-jwt", "configuration": { "@odata.type": "#Microsoft.Media.ContentKeyPolicyPlayReadyConfiguration", "licenses": [ { "allowTestDevices": false, "licenseType": "NonPersistent", "contentType": "Unspecified", "contentKeyLocation": { "@odata.type": "#Microsoft.Media.ContentKeyPolicyPlayReadyContentEncryptionKeyFromHeader" } } ] }, "restriction": { "@odata.type": "#Microsoft.Media.ContentKeyPolicyTokenRestriction", "issuer": "https://your-company.com", "audience": "your-video-app", "restrictionTokenType": "Jwt", "primaryVerificationKey": { "@odata.type": "#Microsoft.Media.ContentKeyPolicySymmetricTokenKey", "keyValue": "" } } }, { "name": "widevine-jwt", "configuration": { "@odata.type": "#Microsoft.Media.ContentKeyPolicyWidevineConfiguration", "widevineTemplate": "{}" }, "restriction": { "@odata.type": "#Microsoft.Media.ContentKeyPolicyTokenRestriction", "issuer": "https://your-company.com", "audience": "your-video-app", "restrictionTokenType": "Jwt", "primaryVerificationKey": { "@odata.type": "#Microsoft.Media.ContentKeyPolicySymmetricTokenKey", "keyValue": "" } } } ] } }' ``` The fields that matter most: - `@odata.type` is the discriminator on every nested object. It selects which configuration, restriction, or key type the object is. The values are fixed strings and must match exactly. - `widevineTemplate` is a JSON string, not a JSON object. An empty `"{}"` tells MK.IO to generate a default Widevine license. Supply a custom template only when you need to control persistence or validity. - `keyValue` is the Base64-encoded HMAC secret your application signs tokens with. It is the same secret on both sides: the policy verifies what your token server signs. - `issuer` and `audience` must match the `iss` and `aud` claims your tokens carry. A mismatch rejects the license request. A successful create returns `201 Created` with the stored policy. A name that already exists returns `409 Conflict`. For the full request and response schema, see the [Media API reference](/api-reference/media-api). ## Choosing the configuration The `configuration` block selects the DRM system. Each system covers different platforms, so the choice is driven by the devices you need to reach.
You need to reach Use this configuration @odata.type
Edge, Xbox, Windows PlayReady #Microsoft.Media.ContentKeyPolicyPlayReadyConfiguration
Chrome, Firefox, Android, Android TV Widevine #Microsoft.Media.ContentKeyPolicyWidevineConfiguration
Safari, iOS, tvOS, macOS FairPlay #Microsoft.Media.ContentKeyPolicyFairPlayConfiguration
Basic encryption, lowest latency, no DRM license server Clear Key #Microsoft.Media.ContentKeyPolicyClearKeyConfiguration
To cover every platform, include all three DRM configurations in one policy, as the minimal example does for two of them. FairPlay is the one configuration that needs extra setup: it requires a Base64-encoded certificate (`fairPlayPfx`), its password (`fairPlayPfxPassword`), and a Base64-encoded application secret key (`ask`). Supply the certificate password directly, without Base64 encoding it. The FairPlay configuration also requires `rentalAndLeaseKeyType` and `rentalDuration`; see `ContentKeyPolicyFairPlayConfiguration` in the [Media API reference](/api-reference/media-api) for their supported values. The other systems work with the fields shown above. Clear Key uses AES-128 and does not reach the security of the three DRM systems. Do not add Clear Key to a policy intended for DRM, because it lowers the overall protection. For the per-system setup detail, see [multi-DRM encryption](/mkio/how-to/drm-content-protection/multi-drm-encryption). ## Choosing the restriction The `restriction` block decides who receives a license.
Your situation Use this restriction @odata.type
Production: only entitled viewers may play Token restriction #Microsoft.Media.ContentKeyPolicyTokenRestriction
Testing only: anyone with the stream may play Open restriction #Microsoft.Media.ContentKeyPolicyOpenRestriction
An open restriction needs no other fields and is for testing only. A token restriction is the production default and needs `issuer`, `audience`, `restrictionTokenType`, and a `primaryVerificationKey`. The verification key type is itself chosen by `@odata.type`:
Signing approach Key type @odata.type Required fields
Symmetric (HMAC, HS256) Symmetric #Microsoft.Media.ContentKeyPolicySymmetricTokenKey keyValue
Asymmetric (RSA) RSA #Microsoft.Media.ContentKeyPolicyRsaTokenKey modulus, exponent
Certificate (X.509) X.509 #Microsoft.Media.ContentKeyPolicyX509CertificateTokenKey rawBody
Symmetric (HS256) is the default and the simplest. Choose RSA when your security model requires asymmetric keys; see [RSA key for token validation](/mkio/how-to/drm-content-protection/rsa-key-for-token-validation). ## Attach the policy at the locator A content key policy takes effect only when a streaming locator references it. The locator joins the asset, a streaming policy, and the content key policy. ```bash curl -X PUT "https://app.mk.io/api/v1/projects//media/streamingLocators/protected-locator" \ -H "Authorization: Bearer " \ -H "Content-Type: application/json" \ -d '{ "properties": { "assetName": "output-video", "streamingPolicyName": "Predefined_MultiDrmCencStreaming", "defaultContentKeyPolicyName": "multi-drm-policy" } }' ``` Use a predefined streaming policy unless you have a reason not to. The predefined policies remove all custom encryption configuration:
Streaming policy Encryption Requires in the content key policy
Predefined_ClearStreamingOnly None Nothing
Predefined_ClearKey Clear Key (AES-128) A Clear Key option
Predefined_MultiDrmCencStreaming PlayReady and Widevine Both PlayReady and Widevine options
Predefined_MultiDrmStreaming PlayReady, Widevine, and FairPlay All three options
The minimal example pairs with `Predefined_MultiDrmCencStreaming` because it defines PlayReady and Widevine. To add Safari and Apple devices, add a FairPlay option to the policy and switch the locator to `Predefined_MultiDrmStreaming`. ## What goes wrong - **The streaming policy and the content key policy disagree.** The streaming policy enforces which DRM schemes the content key policy must contain. A `Predefined_MultiDrmStreaming` locator fails if the policy does not include all three schemes, and a `Predefined_MultiDrmCencStreaming` locator fails if it lacks PlayReady or Widevine. Match the table above. - **The token is signed with a different key, issuer, or audience.** MK.IO validates the token signature against `primaryVerificationKey`, and the `iss` and `aud` claims against the policy. Any mismatch rejects the license, even when the stream itself publishes correctly. - **The verification key leaks into client code.** Generate tokens on your server and pass them to the player at runtime. Never ship the `keyValue` secret in client-side code. - **Playback shows a license error during testing.** A protected stream opened without a token can surface a `DRM_FAILED_LICENSE_REQUEST` error. That is expected: the encrypted stream needs a token that has not been provided yet. For the token flow and the required claims, see [JWT token authentication](/mkio/how-to/drm-content-protection/jwt-token-authentication). ## Related operations List the content key policies in a project: ```bash curl -X GET "https://app.mk.io/api/v1/projects//media/contentKeyPolicies" \ -H "Authorization: Bearer " ``` Retrieve a single policy: ```bash curl -X GET "https://app.mk.io/api/v1/projects//media/contentKeyPolicies/multi-drm-policy" \ -H "Authorization: Bearer " ``` A standard `GET` never returns secret values, such as the verification key. When you need to inspect or rotate secrets, use the secrets variant, and only then: ```bash curl -X POST "https://app.mk.io/api/v1/projects//media/contentKeyPolicies/multi-drm-policy/getPolicyPropertiesWithSecrets" \ -H "Authorization: Bearer " ``` ## Where to go deeper For the concepts and platform-level setup behind these requests: - [Content protection overview](/mkio/understanding/core-concepts/content-protection): how DRM, keys, and licenses work in MK.IO. - [Multi-DRM encryption](/mkio/how-to/drm-content-protection/multi-drm-encryption): per-system configuration detail. - [JWT token authentication](/mkio/how-to/drm-content-protection/jwt-token-authentication): the token flow and claim requirements. - [Using custom claims in content key policies](/mkio/how-to/drm-content-protection/custom-claims): route different licenses from one policy. For the complete, field-level request and response schema, including every configuration and restriction variant this guide does not cover: - [Media API reference](/api-reference/media-api). ## What comes next - [Streaming and publishing](/mkio/api-guides/how-to/media/publishing): connect the policy to locators and live playback. # Download asset files To read a file from an asset, call `getFileAccessInfo` to get temporary access details, then use those details to request the file. You need an asset that already points to stored content, a bearer token, the asset name, and the path of the file you want. ## Get the access details `getFileAccessInfo` is a `POST` with no body: ```bash curl -X POST "https://app.mk.io/api/v1/projects//media/assets//getFileAccessInfo" \ -H "Authorization: Bearer " ``` The response contains the information needed to access files associated with the asset: ```json { "storageAccountName": "mystorageaccount", "containerName": "mycontainer", "jwt": "", "url": "https://cluster-1.eastus.streaming.mediakind.com/project//", "subPath": "incoming" } ```
Field Description
url Base URL to use for the file access request.
jwt Token used to authenticate the file access request.
storageAccountName Storage account associated with the asset.
containerName Container holding the asset files.
subPath Optional path prefix. Include it when specifying the file path.
The `jwt` returned by `getFileAccessInfo` is different from the bearer token used to call the MK.IO API. It can also expire, so request fresh access details immediately before downloading a file. ## Build the file path Combine `subPath`, if present, with the file name. If `subPath` is `incoming` and the file is `manifest.mpd`, the path is `incoming/manifest.mpd`. With no `subPath`, the path is just `manifest.mpd`. ## Download the file Append `downloadBlob` to the returned `url`, pass the returned `jwt` as the bearer token, and provide the storage and file details in the request body: ```bash curl -X POST "downloadBlob" \ -H "Authorization: Bearer " \ -H "Content-Type: application/json" \ -d '{ "storageAccountName": "", "containerName": "", "fileName": "" }' \ --output ``` For example: ```bash curl -X POST \ "https://cluster-1.eastus.streaming.mediakind.com/project//downloadBlob" \ -H "Authorization: Bearer " \ -H "Content-Type: application/json" \ -d '{ "storageAccountName": "mystorageaccount", "containerName": "mycontainer", "fileName": "video.mp4" }' \ --output video.mp4 ``` If the asset uses a `subPath`, include it in `fileName`: ```json { "storageAccountName": "mystorageaccount", "containerName": "mycontainer", "fileName": "incoming/video.mp4" } ``` ## What goes wrong - **`getFileAccessInfo` fails.** A common cause is an expired storage credential. Rotate it; see [Storage](/mkio/api-guides/how-to/media/storage). - **`401` or `token is expired`.** Call `getFileAccessInfo` again and retry the download with the newly returned `jwt`. - **`404 page not found`.** Do not append the file name directly to the returned `url`. Append `downloadBlob` and provide the file name in the request body. - **`502 Bad Gateway`.** The file access service could not complete the request. Confirm that the file exists and that the asset's registered storage is accessible. If both are valid and the request continues to fail, contact MediaKind support. - **Using your MK.IO bearer token for the download.** Use the `jwt` returned by `getFileAccessInfo` for the `downloadBlob` request. ## What comes next - [Assets](/mkio/api-guides/how-to/media/assets): manage the assets these files belong to. - [Storage](/mkio/api-guides/how-to/media/storage): rotate credentials if access stops working. # Live streaming A live workflow in the Media API is built from a few resources that you manage independently: a **live event** defines ingest and encoding, a **live output** archives the running stream into an asset, a **streaming locator** publishes that asset, and a **streaming endpoint** serves the playback hostname. Separating ingest, archive, and playback lets you, for example, keep an archive asset for VOD long after the event ends. See [Live events](/mkio/understanding/core-concepts/live-event) for the product background.
Media API workflow

This guide covers /media/liveEvents. The newer /live/liveEvents resource belongs to the Live API. Resources created through one API are invisible to the other, and their lifecycle methods and configuration models are different.

## Create the live event A live event is created with `PUT`. Several of its properties are create-time only, including `input`, `encoding`, `streamOptions`, and `useStaticHostname`, so create it only when you are ready to use it. The example below is a passthrough event that ingests over RTMP. ```bash curl -X PUT "https://app.mk.io/api/v1/projects//media/liveEvents/main-stage" \ -H "Authorization: Bearer " \ -H "Content-Type: application/json" \ -d '{ "tags": {}, "properties": { "useStaticHostname": false, "streamOptions": ["Default"], "encoding": { "encodingType": "PassthroughBasic" }, "input": { "streamingProtocol": "RTMP", "accessControl": { "ip": { "allow": [] } }, "accessToken": "", "keyFrameIntervalDuration": "PT2S", "timedMetadataEndpoints": [] } } }' ``` An empty `accessControl.ip.allow` array allows ingest from any address. For production, list the encoder addresses explicitly. When `useStaticHostname` is `true` you can also set `hostnamePrefix` for a stable ingest and preview hostname; when it is `false`, MK.IO generates the addresses. ## Choosing an encoding type `encodingType` decides whether MK.IO forwards your encoder's output as-is or transcodes it into an adaptive ladder. Passthrough is cheaper and lower-latency but pushes the adaptive-bitrate work onto your encoder; the encoding types produce the ladder for you.
encodingType What it does Ingest cap Maximum archive
PassthroughBasic Forwards incoming layers, no transcoding 5 Mbps 8 hours
PassthroughStandard Forwards incoming layers, no transcoding 60 Mbps 25 hours
Standard Transcodes to a 720p adaptive ladder - 25 hours
Premium1080p Transcodes to a 1080p adaptive ladder - 25 hours
For ingest protocol, `RTMP` and `RTMPS` work with passthrough and encoding. `SRT` (Secure Reliable Transport) is supported for the encoding types. ## Start the event and get the ingest URL Start the event when you are ready to receive the stream: ```bash curl -X POST "https://app.mk.io/api/v1/projects//media/liveEvents/main-stage/start" \ -H "Authorization: Bearer " ``` Then read the event back. The `input.endpoints` field is populated server-side and holds the ingest URLs you give to your encoder: ```bash curl -X GET "https://app.mk.io/api/v1/projects//media/liveEvents/main-stage" \ -H "Authorization: Bearer " ``` Point your encoder at that URL. Configure the encoder's keyframe interval (Group of Pictures, or GOP) to match `keyFrameIntervalDuration`. For example, at 30 frames per second with a 2-second interval, set the encoder to a 60-frame GOP. ## Archive the stream with a live output A live output writes the running stream into an asset. It requires `assetName` and `archiveWindowLength`, an ISO 8601 duration that sets the Digital Video Recorder (DVR) window. ```bash curl -X PUT "https://app.mk.io/api/v1/projects//media/liveEvents/main-stage/liveOutputs/main-archive" \ -H "Authorization: Bearer " \ -H "Content-Type: application/json" \ -d '{ "properties": { "assetName": "main-stage-archive", "archiveWindowLength": "PT4H", "manifestName": "index", "description": "Archive of the main stage feed" } }' ``` ## Publish live playback The live output writes into an asset, so you publish it the same way as VOD: create a streaming locator on the asset, then retrieve its paths. ```bash curl -X PUT "https://app.mk.io/api/v1/projects//media/streamingLocators/main-stage-live" \ -H "Authorization: Bearer " \ -H "Content-Type: application/json" \ -d '{ "properties": { "assetName": "main-stage-archive", "streamingPolicyName": "Predefined_ClearStreamingOnly" } }' ``` Combine the paths from `listPaths` with the `hostName` of a running streaming endpoint to form the playback URLs. See [Streaming and publishing](/mkio/api-guides/how-to/media/publishing) for the full publishing model. ## Stop, reset, and delete Stopping is a deliberate, billing-relevant action. Stop the event when the stream ends: ```bash curl -X POST "https://app.mk.io/api/v1/projects//media/liveEvents/main-stage/stop" \ -H "Authorization: Bearer " ``` `reset` restarts ingest on the same event without recreating it. To tear the event down, delete the live output first, then the event: ```bash curl -X DELETE "https://app.mk.io/api/v1/projects//media/liveEvents/main-stage/liveOutputs/main-archive" \ -H "Authorization: Bearer " curl -X DELETE "https://app.mk.io/api/v1/projects//media/liveEvents/main-stage" \ -H "Authorization: Bearer " ``` The archived asset survives the event and can keep serving VOD playback. ## What goes wrong - **Ingest stops after a pause.** RTMP and RTMPS drop the connection after roughly 10 seconds with no data. Encoder pauses between scenes, network instability, or an idle source can all trigger this. Keep the feed flowing. - **Playback stutters or fails because keyframes do not align.** The encoder GOP must match `keyFrameIntervalDuration`. A mismatch produces broken segments. - **Ongoing charges after the broadcast.** A running live event and a running streaming endpoint both bill while active. A streaming endpoint can serve many locators and assets. Before stopping it, confirm that no other playback workflow depends on it. - **Trying to allocate before starting.** The `allocate` operation is not implemented and returns an error. Start the event directly. - **Editing a create-time field.** Input, encoding, stream options, and static-hostname settings cannot change after creation. To change them, create a new event. ## What comes next - [Streaming and publishing](/mkio/api-guides/how-to/media/publishing): locators, policies, endpoints, and playback URLs. - [Webhooks](/mkio/api-guides/understanding/webhooks): react to `MediaKind.ChannelInstanceStarted`, `ChannelInstanceStopped`, and `ChannelInstanceError` without polling. # Playback filters A filter publishes a shaped version of an asset without creating a new one. Use a filter when the manifest should expose only part of the content, only certain tracks, or a different startup quality. Filters shape the manifest at playback time; they do not reprocess content. The asset holds the full media, the filter describes the subset, and the streaming locator applies the filter when it publishes. ## Choosing the filter scope There are two scopes, and the choice is about reuse.
Scope Path Use when
Asset filter .../media/assets/{asset_name}/assetFilters/{filter_name} The rule belongs to one title or archive.
Account filter .../media/accountFilters/{filter_name} The same rule should apply across many assets in the project.
Both use the same `MediaFilterProperties` body, which supports three controls: `presentationTimeRange` to clip a time window, `tracks` to select tracks, and `firstQuality` to set the startup bitrate. ## Clip a time window This asset filter exposes only the section from 10 to 70 seconds. With `timescale` set to `1`, the timestamps are in seconds. ```bash curl -X PUT "https://app.mk.io/api/v1/projects//media/assets/source-video/assetFilters/highlights" \ -H "Authorization: Bearer " \ -H "Content-Type: application/json" \ -d '{ "properties": { "presentationTimeRange": { "timescale": 1, "startTimestamp": 10, "endTimestamp": 70 } } }' ``` `timescale` is the number of units per second. It defaults to `10000000` (100-nanosecond units), so set it to `1` when you want to work in whole seconds. The same block also supports the live-only fields `presentationWindowDuration` (the rewind window) and `liveBackoffDuration` (the delay from the live edge). ## Select tracks This account filter includes audio tracks that are not English, and video tracks between 3 and 5 megabits per second. ```bash curl -X PUT "https://app.mk.io/api/v1/projects//media/accountFilters/non-english-mid-bitrate" \ -H "Authorization: Bearer " \ -H "Content-Type: application/json" \ -d '{ "properties": { "tracks": [ { "trackSelections": [ { "property": "Type", "operation": "Equal", "value": "audio" }, { "property": "Language", "operation": "NotEqual", "value": "en" } ] }, { "trackSelections": [ { "property": "Type", "operation": "Equal", "value": "video" }, { "property": "Bitrate", "operation": "Equal", "value": "3000000-5000000" } ] } ] } }' ``` The selectable properties are `Type` (`video`, `audio`, `text`), `Name`, `Language` (an RFC 5646 tag such as `en` or `en-US`), `FourCC` (a codec such as `avc1` or `mp4a`), and `Bitrate` (a single value or a range like `3000000-5000000`). Values are case-insensitive, and each property uses an `operation` of `Equal` or `NotEqual`. The nesting controls the logic, and it is easy to misread: - Conditions inside one `trackSelections` array are combined with **AND**. - Entries in the top-level `tracks` array are combined with **OR**. So the filter above means "(audio AND not English) OR (video AND 3-5 Mbps)". ## Set the startup quality Add `firstQuality` to start HLS playback near a target bitrate. The closest available rung in the ladder is used if the exact bitrate is absent. ```bash curl -X PUT "https://app.mk.io/api/v1/projects//media/accountFilters/high-start-quality" \ -H "Authorization: Bearer " \ -H "Content-Type: application/json" \ -d '{ "properties": { "firstQuality": { "bitrate": 5000000 } } }' ``` ## Apply the filter Add a filter name to the streaming locator's `filters` list to apply it to playback through that locator. The list accepts both asset and account filters. ```bash curl -X PUT "https://app.mk.io/api/v1/projects//media/streamingLocators/highlights-locator" \ -H "Authorization: Bearer " \ -H "Content-Type: application/json" \ -d '{ "properties": { "assetName": "source-video", "streamingPolicyName": "Predefined_ClearStreamingOnly", "filters": ["highlights"] } }' ``` You can also request named filters in the manifest URL with `filter=`, using a semicolon-separated list of asset or account filter names. For example, `filter=highlights` applies the named filter to that playback request. See [Streaming locators](/mkio/understanding/core-concepts/locators) for the complete manifest URL syntax. ## What goes wrong - **The filter has no effect.** Confirm that the locator lists it in `filters` or that the manifest URL requests it with `filter=`. Creating a filter alone does not apply it to playback. - **Time values look wrong.** Without `timescale: 1`, timestamps are in 100-nanosecond units by default. Set `timescale` to match the unit you intend. - **A delete is rejected.** A filter cannot be deleted while an active streaming locator still references it. Remove it from the locator first. ```bash curl -X DELETE "https://app.mk.io/api/v1/projects//media/assets/source-video/assetFilters/highlights" \ -H "Authorization: Bearer " ``` ## What comes next - [Streaming and publishing](/mkio/api-guides/how-to/media/publishing): apply filters at publication time. - [Assets](/mkio/api-guides/how-to/media/assets): use an asset filter when the rule belongs to one asset. # Streaming and publishing Publishing has two parts that meet at the playback URL. A **streaming locator** publishes a specific asset and decides its playback and protection behaviour through a streaming policy. A **streaming endpoint** provides the hostname that players connect to and does the just-in-time packaging and encryption. You need both: a locator gives you a path, an endpoint gives you a host, and the playback URL is the two combined. See [Streaming locators](/mkio/understanding/core-concepts/locators) and [Streaming endpoints](/mkio/understanding/core-concepts/endpoints) for the product background. ## Create and start a streaming endpoint An endpoint is created with `PUT` and requires `location` and `properties.scaleUnits`. A `scaleUnits` of `0` provisions a shared Standard endpoint; a value above `0` provisions dedicated Premium capacity. ```bash curl -X PUT "https://app.mk.io/api/v1/projects//media/streamingEndpoints/default" \ -H "Authorization: Bearer " \ -H "Content-Type: application/json" \ -d '{ "location": "", "properties": { "scaleUnits": 0, "description": "Default streaming endpoint" } }' ``` Playback only works while the endpoint is running, so start it and confirm the state: ```bash curl -X POST "https://app.mk.io/api/v1/projects//media/streamingEndpoints/default/start" \ -H "Authorization: Bearer " curl -X GET "https://app.mk.io/api/v1/projects//media/streamingEndpoints/default/state" \ -H "Authorization: Bearer " ``` The endpoint's `hostName` is the value you combine with locator paths to build playback URLs. To enable a Content Delivery Network (CDN), set `cdnEnabled` to `true`; the response then includes a `cdnBasePath` that goes into the URL after the hostname. A streaming endpoint is shared project infrastructure. It can serve many locators and assets. Confirm all dependencies before stopping an endpoint, because stopping it can interrupt every locator that uses it. ## Publish an asset with a streaming locator A locator is created with `PUT` and requires `assetName` and `streamingPolicyName`. The example publishes an asset for clear (unprotected) streaming. ```bash curl -X PUT "https://app.mk.io/api/v1/projects//media/streamingLocators/my-locator" \ -H "Authorization: Bearer " \ -H "Content-Type: application/json" \ -d '{ "properties": { "assetName": "output-video", "streamingPolicyName": "Predefined_ClearStreamingOnly" } }' ``` The locator is also where playback windowing, filters, and protection meet, through optional fields: `startTime` and `endTime` to bound availability, `filters` to apply [playback filters](/mkio/api-guides/how-to/media/playback-filters), `defaultContentKeyPolicyName` for [content protection](/mkio/api-guides/how-to/media/content-protection), and `suppressed` to take output offline without deleting the locator. ## Choosing a streaming policy The `streamingPolicyName` decides what playback the locator allows. Use a predefined policy unless you need behaviour they do not cover.
Policy Playback
Predefined_DownloadOnly Download only, no streaming.
Predefined_ClearStreamingOnly Streaming, no protection.
Predefined_DownloadAndClearStreaming Download and clear streaming.
Predefined_ClearKey Clear Key (AES-128) protection.
Predefined_MultiDrmCencStreaming PlayReady and Widevine.
Predefined_MultiDrmStreaming PlayReady, Widevine, and FairPlay.
List the policies available in a project, including any custom ones, with `GET .../media/streamingPolicies`. The DRM policies require a matching content key policy on the locator; see [Content protection](/mkio/api-guides/how-to/media/content-protection). ## Build the playback URL Ask the locator for its relative paths with `listPaths`: ```bash curl -X POST "https://app.mk.io/api/v1/projects//media/streamingLocators/my-locator/listPaths" \ -H "Authorization: Bearer " ``` The response groups paths by protocol and encryption under `streamingPaths`. Each group can contain several entries in `paths[]`, so enumerate every returned entry instead of assuming one path per group. The response also lists any `downloadPaths`. Build a playback URL from the endpoint hostname, optional `cdnBasePath`, and selected path. Normalize the boundaries so the result contains one slash between each part: ``` https:// ``` The manifest path takes format and encryption options in parentheses. For example, an HLS manifest with Apple sample encryption and two filters applied: ``` https:////manifest.ism/manifest(format=m3u8-cmaf,encryption=cbcs-aapl,filter=account-filter;asset-filter) ``` Use `format=m3u8-cmaf` for HLS and `format=mpd-time-cmaf` for DASH. The MK.IO product docs recommend fetching playback URLs dynamically through `listPaths` rather than hard-coding them, so that origins can change without breaking clients. Use progressive verification when testing a live URL: 1. An HTTP `200 OK` response confirms that the manifest is reachable. 2. Advancing manifest timestamps or segments confirm that live material is updating. 3. Successful playback or `ffprobe` inspection confirms that the media decodes. Streaming endpoint request rate and egress bitrate describe delivery traffic. Do not convert them into viewer, session, or concurrency counts. ## What goes wrong - **Playback returns nothing because the endpoint is stopped.** The endpoint must be in the `Running` state. Start it and confirm before testing. - **A locator returns `404` or `410`.** Before its `startTime`, a locator returns `404 Not Found`; after its `endTime`, it returns `410 Gone`. A `suppressed` locator also returns `404`. Check the time window if playback is unexpectedly unavailable. - **A DRM policy without a key policy.** Selecting `Predefined_MultiDrmCencStreaming` or similar without a matching content key policy on the locator produces unplayable, encrypted output. See [Content protection](/mkio/api-guides/how-to/media/content-protection). ## What comes next - [Content protection](/mkio/api-guides/how-to/media/content-protection): add DRM and key delivery. - [Automate a VOD pipeline](/mkio/api-guides/how-to/media/vod-pipeline): see publishing in an end-to-end workflow. # Storage Most Media API workflows begin with storage. Before MK.IO can process or publish content, it needs a storage instance: its record of an external Azure, AWS, or Google location, together with the credentials it uses to reach that location. The underlying bucket or account stays in your cloud provider. MK.IO only holds the connection details. For the product background on how storage relates to assets, see [Assets](/mkio/understanding/core-concepts/assets). ## Register a storage instance A storage instance is created with `PUT`, and the `spec` body is discriminated by a `type` field. The three supported types are `Microsoft.Storage` (Azure), `AWS.S3`, and `Google.Storage`. The example below registers an Azure account. ```bash curl -X PUT "https://app.mk.io/api/v1/projects//media/storage/primary-azure" \ -H "Authorization: Bearer " \ -H "Content-Type: application/json" \ -d '{ "spec": { "type": "Microsoft.Storage", "url": "https://mystorageaccount.blob.core.windows.net", "description": "Input media files for processing.", "credential": { "sasToken": "?sv=2022-11-02&ss=bfqt&srt=co&sp=rwdlacupiyx&se=2026-12-31T23:59:59Z&st=2026-01-01T00:00:00Z&spr=https&sig=" } } }' ``` A few fields are immutable after creation: the Azure `url`, and the `bucketName` for AWS and Google. The shared secret material differs by provider, as the next section shows. ## Choosing the credential for your provider Each provider has a different credential shape and a different immutable identifier.
Provider type Identifier (immutable) Credential field
Azure Microsoft.Storage url credential.sasToken (include the leading ?)
AWS S3 AWS.S3 bucketName credential.accessKeyId and credential.secretAccessKey
Google Google.Storage bucketName credential.gac (the service-account JSON)
An AWS registration looks like this: ```bash curl -X PUT "https://app.mk.io/api/v1/projects//media/storage/primary-s3" \ -H "Authorization: Bearer " \ -H "Content-Type: application/json" \ -d '{ "spec": { "type": "AWS.S3", "bucketName": "my-media-bucket", "description": "Input media files for processing.", "credential": { "accessKeyId": "", "secretAccessKey": "" } } }' ``` ## Rotate a credential before it expires Credentials are immutable once created, so rotation is always a create-new, then delete-old sequence. This matters most for Azure, where an expired Shared Access Signature (SAS) token silently stops asset access. A storage instance can hold many credentials at once, and MK.IO uses the one with the longest remaining expiry, so adding the replacement first means there is no gap. 1. Add the replacement credential to the storage instance: ```bash curl -X POST "https://app.mk.io/api/v1/projects//media/storage/primary-azure/credentials" \ -H "Authorization: Bearer " \ -H "Content-Type: application/json" \ -d '{ "spec": { "type": "Microsoft.Storage", "credential": { "sasToken": "?sv=2022-11-02&ss=bfqt&srt=co&sp=rwdlacupiyx&se=2027-12-31T23:59:59Z&st=2027-01-01T00:00:00Z&spr=https&sig=" } } }' ``` 2. Confirm access still works by running an operation that depends on the credential, such as requesting file access on an asset: ```bash curl -X POST "https://app.mk.io/api/v1/projects//media/assets/source-video/getFileAccessInfo" \ -H "Authorization: Bearer " ``` 3. Delete the old credential once the new one is working: ```bash curl -X DELETE "https://app.mk.io/api/v1/projects//media/storage/primary-azure/credentials/" \ -H "Authorization: Bearer " ``` ## Update behaviour `PUT` and `PATCH` differ in what they can change: - `PATCH` updates only `description` and `privateLinkServiceConnection`. - `PUT` updates `description`, the credential, and `privateLinkServiceConnection`. To move an Azure instance off private-link access, rotate the SAS token and clear the private-link reference in one `PUT` by setting `privateLinkServiceConnection` to `null`. Disable the private-link setup in Azure as well, then confirm asset access before you treat the change as complete. ## What goes wrong - **An expired SAS token breaks asset access without an obvious error.** Assets in the affected storage stop resolving. Rotate the credential using the create-new, delete-old sequence above. - **A trailing slash on the Azure `url`.** Register the account URL without a trailing `/`. - **Deleting a storage instance that assets still use.** Deletion removes only the MK.IO record, not the underlying account or bucket, but assets that depend on it stop resolving. A stopped Live API resource can still reference those assets and later remain in `Starting`. Check for dependent assets and Live resources first: ```bash curl -X DELETE "https://app.mk.io/api/v1/projects//media/storage/primary-azure" \ -H "Authorization: Bearer " ``` ## What comes next - [Assets](/mkio/api-guides/how-to/media/assets): create assets that point to content in this storage. - [Automate a VOD pipeline](/mkio/api-guides/how-to/media/vod-pipeline): see how storage feeds the rest of a workflow. # Transforms and jobs A transform describes what processing should happen. A job applies that processing to a specific input. Together they are the core of Video on Demand (VOD) processing in the Media API. A transform is a recipe you write once; a job runs that recipe against an asset and writes one or more output assets. You usually create a small number of transforms and reuse them across many jobs. ## Create a transform A transform is created with `PUT`. Its `outputs` array holds the preset that defines the processing. The example below builds an adaptive-bitrate encoding transform using a built-in encoder preset. ```bash curl -X PUT "https://app.mk.io/api/v1/projects//media/transforms/abr-720p" \ -H "Authorization: Bearer " \ -H "Content-Type: application/json" \ -d '{ "properties": { "description": "H.264 720p multi-bitrate encoding", "outputs": [ { "preset": { "@odata.type": "#Microsoft.Media.BuiltInStandardEncoderPreset", "presetName": "H264MultipleBitrate720p" }, "onError": "StopProcessingJob", "relativePriority": "Normal" } ] } }' ``` Each output also accepts `onError` (`ContinueJob` or `StopProcessingJob`) and `relativePriority` (`High`, `Normal`, or `Low`). ## Choosing a preset The preset is selected by `@odata.type`. The most common choice is the built-in encoder, but the Media API also offers format conversion, thumbnails, track insertion, and an Artificial Intelligence (AI) pipeline.
To... Use preset @odata.type Key field
Encode to adaptive bitrate H.264 or H.265 #Microsoft.Media.BuiltInStandardEncoderPreset presetName
Convert or repackage to MP4 without re-encoding #Microsoft.Media.BuiltInAssetConverterPreset presetName
Generate thumbnails #MediaKind.ThumbnailGeneratorPreset thumbnails
Insert a track (for example, captions) #MediaKind.TrackInserterPreset tracks
Run an AI pipeline (transcription, translation) #MediaKind.AIPipelinePreset pipeline
For the built-in encoder, `presetName` chooses the encoding ladder. Single-bitrate options include `H264SingleBitrate720p`, `H264SingleBitrate1080p`, `H265SingleBitrate1080p`, and `H265SingleBitrate4K`. Multi-bitrate options include `H264MultipleBitrateSD`, `H264MultipleBitrate720p`, and `H264MultipleBitrate1080p`, each also available in a `WithCVQ` variant. The [Media API reference](/api-reference/media-api) lists the complete enum. ## Run a job A job is created with `PUT` under the transform. It needs an `input` and `outputs`. The input is discriminated by `@odata.type`: use `JobInputAsset` to process a stored asset, or `JobInputHttp` to pull from an external HTTP source. Outputs are always `JobOutputAsset`. ```bash curl -X PUT "https://app.mk.io/api/v1/projects//media/transforms/abr-720p/jobs/job-001" \ -H "Authorization: Bearer " \ -H "Content-Type: application/json" \ -d '{ "properties": { "input": { "@odata.type": "#Microsoft.Media.JobInputAsset", "assetName": "input-video", "files": ["video.mp4"] }, "outputs": [ { "@odata.type": "#Microsoft.Media.JobOutputAsset", "assetName": "output-video" } ], "description": "Encode input-video with the 720p transform", "priority": "Normal" } }' ``` The output asset named here is created and populated by the job. It does not need to exist beforehand. ## Clip the input `JobInputAsset` accepts `start` and `end` clip times. Use `AbsoluteClipTime` with an ISO 8601 duration to process only part of the source: ```bash curl -X PUT "https://app.mk.io/api/v1/projects//media/transforms/abr-720p/jobs/clip-job" \ -H "Authorization: Bearer " \ -H "Content-Type: application/json" \ -d '{ "properties": { "input": { "@odata.type": "#Microsoft.Media.JobInputAsset", "assetName": "input-video", "start": { "@odata.type": "#Microsoft.Media.AbsoluteClipTime", "time": "PT0S" }, "end": { "@odata.type": "#Microsoft.Media.AbsoluteClipTime", "time": "PT30S" } }, "outputs": [ { "@odata.type": "#Microsoft.Media.JobOutputAsset", "assetName": "clip-output" } ] } }' ``` ## Monitor the job Poll the job state endpoint while you wait: ```bash curl -X GET "https://app.mk.io/api/v1/projects//media/transforms/abr-720p/jobs/job-001/state" \ -H "Authorization: Bearer " ``` A job moves through these states:
State Meaning
Queued Waiting to be processed.
Scheduled Accepted and scheduled for work.
Processing Running.
Finished Completed successfully.
Error Completed with an error.
Canceling Cancellation is in progress.
Canceled Cancelled.
For background workers and high-volume pipelines, subscribe to the `MediaKind.JobStarted` and `MediaKind.JobFinished` [webhooks](/mkio/api-guides/understanding/webhooks) instead of polling. ## Cancel a job Cancel a job that is no longer needed: ```bash curl -X POST "https://app.mk.io/api/v1/projects//media/transforms/abr-720p/jobs/job-001/cancelJob" \ -H "Authorization: Bearer " ``` ## What goes wrong - **An invalid `presetName`.** `presetName` must be one of the documented enum values, such as `H264MultipleBitrate720p`. A made-up name like `AdaptiveStreaming` is rejected. Check the [Media API reference](/api-reference/media-api) for the exact list. - **Publishing the input asset instead of the output.** A job writes to the output asset. Publish that one, not the source. - **A job reaches `Error`.** The job output object carries an `error` field with the detail. Read the full job, not just `/state`, to see it. ## What comes next - [Automate a VOD pipeline](/mkio/api-guides/how-to/media/vod-pipeline): transforms and jobs in a full publishing workflow. - [Streaming and publishing](/mkio/api-guides/how-to/media/publishing): publish the job output for playback. - [Webhooks](/mkio/api-guides/understanding/webhooks): replace status polling with events. # Automate a VOD pipeline This guide walks the complete Video on Demand (VOD) path through the Media API, from a source asset to a playable URL. The individual resources have their own guides; the goal here is to show how they connect so you can build a pipeline with less trial and error. The sequence is: 1. Create an input asset that points to the source content. 2. Create or reuse a transform. 3. Create a job that applies the transform to the input asset. 4. Wait for the job to finish and the output asset to be ready. 5. Create a streaming locator on the output asset. 6. Start a streaming endpoint and call `listPaths` for the playback URLs. You need a project with storage already configured, a personal API token, and source content in that storage. ## Step 1: Create the input asset ```bash curl -X PUT "https://app.mk.io/api/v1/projects//media/assets/input-video-001" \ -H "Authorization: Bearer " \ -H "Content-Type: application/json" \ -d '{ "properties": { "storageAccountName": "primary-azure", "container": "input-video-001", "description": "Source video for transcoding" } }' ``` This asset is the input reference for the job. See [Assets](/mkio/api-guides/how-to/media/assets) for the full set of fields. ## Step 2: Create or reuse the transform Because transforms are reusable, you usually do this once per processing profile, not once per asset. ```bash curl -X PUT "https://app.mk.io/api/v1/projects//media/transforms/standard-encoding" \ -H "Authorization: Bearer " \ -H "Content-Type: application/json" \ -d '{ "properties": { "description": "H.264 1080p multi-bitrate encoding", "outputs": [ { "preset": { "@odata.type": "#Microsoft.Media.BuiltInStandardEncoderPreset", "presetName": "H264MultipleBitrate1080p" }, "relativePriority": "Normal" } ] } }' ``` `presetName` must be one of the documented enum values. See [Transforms and jobs](/mkio/api-guides/how-to/media/transforms-and-jobs) for the available presets. ## Step 3: Create the job ```bash curl -X PUT "https://app.mk.io/api/v1/projects//media/transforms/standard-encoding/jobs/job-001" \ -H "Authorization: Bearer " \ -H "Content-Type: application/json" \ -d '{ "properties": { "input": { "@odata.type": "#Microsoft.Media.JobInputAsset", "assetName": "input-video-001" }, "outputs": [ { "@odata.type": "#Microsoft.Media.JobOutputAsset", "assetName": "output-video-001" } ], "description": "Transcode input-video-001 with the standard transform" } }' ``` The job creates and populates the output asset named here. ## Step 4: Wait for the job to finish Poll the job state until it reaches `Finished`: ```bash curl -X GET "https://app.mk.io/api/v1/projects//media/transforms/standard-encoding/jobs/job-001/state" \ -H "Authorization: Bearer " ``` For background automation, subscribe to the `MediaKind.JobStarted` and `MediaKind.JobFinished` [webhooks](/mkio/api-guides/understanding/webhooks) instead of polling. ## Step 5: Publish the output asset Create a streaming locator on the output asset, not the source: ```bash curl -X PUT "https://app.mk.io/api/v1/projects//media/streamingLocators/locator-001" \ -H "Authorization: Bearer " \ -H "Content-Type: application/json" \ -d '{ "properties": { "assetName": "output-video-001", "streamingPolicyName": "Predefined_ClearStreamingOnly" } }' ``` ## Step 6: Start the endpoint and get the URLs Start the streaming endpoint if it is not already running, then list the locator paths: ```bash curl -X POST "https://app.mk.io/api/v1/projects//media/streamingEndpoints/default/start" \ -H "Authorization: Bearer " curl -X POST "https://app.mk.io/api/v1/projects//media/streamingLocators/locator-001/listPaths" \ -H "Authorization: Bearer " ``` Combine each path with the endpoint `hostName` to build the playback URLs. See [Streaming and publishing](/mkio/api-guides/how-to/media/publishing) for URL construction. ## What goes wrong - **Publishing too early.** A locator can only publish the asset you point it at. In a VOD pipeline, publish the output asset created by the job, after it reaches `Finished`, not the source asset. - **Confusing the endpoint and the locator.** The endpoint provides the delivery hostname; the locator provides the asset-specific path. You need both, and the endpoint must be running. ## What comes next - [Transforms and jobs](/mkio/api-guides/how-to/media/transforms-and-jobs): deeper detail on jobs and presets. - [Content protection](/mkio/api-guides/how-to/media/content-protection): add DRM to the published output. - [Webhooks](/mkio/api-guides/understanding/webhooks): replace polling with event-driven completion. # Build with the Templates API The Templates API manages the configuration templates that Live API resources depend on for encoding, composition, and stream conditioning. Templates are versioned: each upload creates a new version, and the most recent version is always tagged `latest`. ## API overview
Detail Value
Base path /api/v1/projects/{project_name}/templating/
Scope Project
Reference Templates API reference
Every endpoint the Templates API has, in full:
Endpoint What it does
GET /templating/types Lists the config types your project supports
GET /templating/configs, GET /templating/configs/{config_type} List your own configs, across all types or filtered to one
GET /templating/configs/{config_type}/{name} Read the latest version of one config
PUT /templating/configs/{config_type}/{name} Create a config, or a new version of one that already exists
DELETE /templating/configs/{config_type}/{name} Delete a config and every version of it
GET /templating/configs/{config_type}/{name}/versions List every version of a config
GET /templating/configs/{config_type}/{name}/versions/{version} Read one specific version, by hash or tag
DELETE /templating/configs/{config_type}/{name}/versions/{version} Delete one specific version
GET /templating/presets, GET /templating/presets/{config_type} List MediaKind's presets, across all types or filtered to one
GET /templating/presets/{config_type}/{name} Read one specific preset
That's the complete list. Presets have no PUT, POST, or DELETE anywhere, everything writable lives under `/configs`. ## How templates connect to live resources ### Reference a config A template is referenced by name and version in a Live API resource's transform spec. For example, an `encodingLive` template is required by every `LiveChannel`, `LiveEvent`, `StaticMultiviewChannel`, and `StaticMultiviewEvent`. A `multiviewComposing` template is optional but provides a way to separate composition layout from encoding settings in multiview workflows. Reference a template from a live resource like this: ```json "encodingLive": { "configRef": { "name": "my-encoding-template", "version": "latest" } } ``` Use `"version": "latest"` to always reference the most recently uploaded version. Pin to a specific version hash when you need stable, reproducible deployments. ### Start from a preset A live resource's `configRef` always points at a **config**, the template you create and own. It never points at a **preset**, a separate, read-only, MediaKind-managed starting point you can optionally copy into a config. See [Configs and presets](/mkio/api-guides/how-to/templates/manage-templates#configs-and-presets) for how the two relate. Use this sequence for a preset-based Live API workflow: 1. List the presets available to the project. 2. Create a customer config from the selected preset. 3. Retrieve the created config and copy its input or output pin names. 4. Reference the customer config from the Live API resource. A Live API resource cannot reference the preset directly. For production, use a version hash instead of the mutable `latest` tag when the broadcast must use reproducible configuration. ### Customize a live resource Alongside `configRef`, a live resource can set **`configValues`**, named values for any parameters the template declares, and **`configOverrides`**, JSON Patch operations against the template's content directly. Prefer `configValues` where the template supports it: it's checked against parameters the template author explicitly declared, while `configOverrides` can touch any path and requires knowing the template's internal structure in detail. See [Set per-instance parameter values](/mkio/api-guides/how-to/live/manage-live#set-per-instance-parameter-values) and [Declare parameters on a config](/mkio/api-guides/how-to/templates/manage-templates#declare-parameters-on-a-config). ## Template types
Config type Purpose
encodingLive Live encoding configuration. Required by liveChannels, liveEvents, staticMultiviewChannels, staticMultiviewEvents.
multiviewComposing Composition layout, optional on staticMultiviewChannels and staticMultiviewEvents.
streamConditioning Optional stream conditioning settings, usable on any of the four resource types.
Call the types endpoint for the full list of types supported by your project. It is the source of truth, since types can be added over time. `config_type` is a string path parameter. Choose a type returned by `GET /api/v1/projects/{project_name}/templating/types` and supported by the resource you plan to create. The [Live API reference](/api-reference/live-api) defines the four resource transforms and their accepted config types. ## Guides [Manage templates](/mkio/api-guides/how-to/templates/manage-templates) Create, version, tag, delete, and reference configuration templates. Use presets as a starting point. # Manage templates The Templates API stores reusable processing settings for Live API resources. A customer config belongs to your project; a MediaKind preset provides a starting point to copy into a config. Create an `encodingLive` config from a preset, inspect its input pins, and reference that config when you create a live resource. Each upload creates a version, and the most recently uploaded version is tagged `latest`. ## Prerequisites You need a project name and an API token with permission to read presets and create configs. Replace `` and `` in the requests below. See [Authentication and tokens](/mkio/api-guides/getting-started/authentication) if you need a token. ## Configs and presets
Resource Managed by How you use it
Preset MediaKind Read it and copy its content into a config with spec.presetName.
Config Your project Create and version it, then reference it from a live resource with configRef.name.
Copying a preset creates a customer config. Later config uploads version that config independently of the preset. ## Browse available presets List the encoding presets available to your project: ```bash curl -X GET "https://app.mk.io/api/v1/projects//templating/presets/encodingLive" \ -H "Authorization: Bearer " ``` Read the returned `value` array. Choose a preset by its `metadata.name` and `metadata.description`. Availability can differ by project, so use the returned name in the next request. To inspect a preset before copying it, retrieve it by name: ```bash curl -X GET "https://app.mk.io/api/v1/projects//templating/presets/encodingLive/" \ -H "Authorization: Bearer " ``` Replace `` with the name from the list. The preset's `spec.config` contains the processing configuration. Presets are managed by MediaKind and are read-only. ## Create from a preset Copy your selected preset into a customer config named `my-encoding-template`. Set `spec.presetName` to the name returned by the preset list: ```bash curl -X PUT "https://app.mk.io/api/v1/projects//templating/configs/encodingLive/my-encoding-template" \ -H "Authorization: Bearer " \ -H "Content-Type: application/json" \ -d '{ "metadata": { "description": "My Encoding Template created from a preset" }, "spec": { "presetName": "" } }' ``` The response returns `200` or `201` with the config. Its content is copied from the named preset and can be versioned independently. A Live API resource references this customer config through `configRef.name`. ## Get the latest version Retrieve the created config to check its content and the pins available to live resources: ```bash curl -X GET "https://app.mk.io/api/v1/projects//templating/configs/encodingLive/my-encoding-template" \ -H "Authorization: Bearer " ``` The response includes:
Field Description
spec.config The template content.
spec.parameters Array of declared parameters, if any. Each has a name, paths, and optional description.
status.inputPins Array of available input pins. Each has a name and may include allowMultipleBindings.
status.outputPins Array of available output pins. Each has a name and may include allowMultipleBindings.
The `inputPins[].name` values are the exact strings to use as `transformInput` in Live API resource inputs. The `outputPins[].name` values map to `transformOutput` in resource outputs. The `spec.parameters[].name` values are the exact strings to use as keys in `configValues` when referencing this config from a live resource. Check `allowMultipleBindings` on each pin before wiring up inputs. A pin with `allowMultipleBindings: false` accepts at most one binding. Only pins with `allowMultipleBindings: true` are built to accept more than one. ## Template types Call the types endpoint to list the configuration types supported by your project: ```bash curl -X GET "https://app.mk.io/api/v1/projects//templating/types" \ -H "Authorization: Bearer " ``` Each entry in the response's `types` array describes a configuration type by `name` and `description`. The types you will use for the four documented Live API resource types (`liveChannels`, `liveEvents`, `staticMultiviewChannels`, `staticMultiviewEvents`) are:
Config type Used by
encodingLive Required on every LiveChannel, LiveEvent, StaticMultiviewChannel, and StaticMultiviewEvent
multiviewComposing Optional, StaticMultiviewChannel and StaticMultiviewEvent only
streamConditioning Optional on any of the four resource types
Other types may appear in the response. Confirm that the resource you plan to create supports a type before selecting it. The [Live API reference](/api-reference/live-api) defines the supported template references for each live resource. ## Create or update a template Use `PUT` at the config's name to upload a complete `spec.config` object. If the name exists, the upload creates a new version identified by a hash. The new version receives the `latest` tag. Any tags supplied in `metadata.tags` move from their previous versions to this one. For a custom configuration, start with the full `spec.config` returned by your created config. Its internal fields depend on the encoding engine and config type. Keep the existing processing configuration and change only settings supported by that config. The Templates API accepts the JSON object, but does not define the engine's encoding fields. Include `spec.parameters` with the upload if the config exposes parameters you want to retain. The request uses `spec.config` for a full configuration or `spec.presetName` to copy a preset; these are alternative request shapes. After uploading, [retrieve the latest version](/mkio/api-guides/how-to/templates/manage-templates#get-the-latest-version) and check `metadata.hash`, `spec`, and `status.inputPins` before referencing it from a live resource. ## Declare parameters on a config Parameters expose selected fields so that each live resource can supply its own values while sharing the same config. Add `spec.parameters` alongside the complete `spec.config` when you upload a version. Each parameter has:
Field Requirement Purpose
name Required The key that a live resource uses in configValues.
paths Required, at least one entry Locations in the config where the parameter applies. Each path must be unique.
description Optional Explains the setting to someone using the config.
Use paths from the actual config you are uploading. A parameter can target several paths when the same value applies in multiple places. Declaring a parameter does not supply the rest of the encoding configuration. A config can omit `parameters`. If the created config already exposes the setting you need, use its existing parameter name in `configValues` instead of uploading a changed config. See [Set parameter values](/mkio/api-guides/how-to/templates/manage-templates#set-parameter-values). ## List versions Retrieve the saved revisions of a config: ```bash curl -X GET "https://app.mk.io/api/v1/projects//templating/configs/encodingLive/my-encoding-template/versions" \ -H "Authorization: Bearer " ``` ## Get a specific version Retrieve a version by its hash or by a tag name: ```bash curl -X GET "https://app.mk.io/api/v1/projects//templating/configs/encodingLive/my-encoding-template/versions/latest" \ -H "Authorization: Bearer " curl -X GET "https://app.mk.io/api/v1/projects//templating/configs/encodingLive/my-encoding-template/versions/" \ -H "Authorization: Bearer " ``` ## Delete a version Delete the revision identified by ``: ```bash curl -X DELETE "https://app.mk.io/api/v1/projects//templating/configs/encodingLive/my-encoding-template/versions/" \ -H "Authorization: Bearer " ``` ## Delete a template and all its versions Delete the named config and its version history: ```bash curl -X DELETE "https://app.mk.io/api/v1/projects//templating/configs/encodingLive/my-encoding-template" \ -H "Authorization: Bearer " ``` ## Referencing templates in Live API resources ### Reference a config version Live API resources reference templates by name and version in the `configRef` field: ```json "encodingLive": { "configRef": { "name": "my-encoding-template", "version": "latest" } } ``` The `latest` tag is mutable and follows the most recently uploaded version. Pin a specific version hash for production workflows that need reproducible configuration. ### Set parameter values If the config declares parameters, set values for them by name with `configValues`. Read the created config first because preset content and declared parameters can change: ```json "encodingLive": { "configRef": { "name": "my-encoding-template", "version": "latest" }, "configValues": { "": "" } } ``` Add `configValues` only for names present in the created config's `spec.parameters`. Replace the placeholders with a declared name and its required leaf JSON value. The reliable source for `transformInput` and `transformOutput` is the created config's `status.inputPins` and `status.outputPins`. A preset response can expose pins, but the workflow does not depend on it. `configValues` only accepts names the template has already declared as parameters, and only leaf JSON values (string, number, or boolean) per name. Values apply only to the resource that sets them; the shared template is not modified. ### Apply direct overrides To modify a template's content directly, at any path, whether or not the template author declared a parameter there, add `configOverrides` with JSON Patch operations instead: ```json "encodingLive": { "configRef": { "name": "my-encoding-template", "version": "latest" }, "configOverrides": { "type": "application/json-patch+json", "operations": [ { "op": "replace", "path": "", "value": "" } ] } } ``` Replace `` with the exact path in the referenced config and `` with the value, using the JSON type that field expects. A `replace` operation targets an existing field. Overrides apply only to the resource that specifies them. The shared template is not modified. If a resource sets both `configValues` and `configOverrides`, `configValues` is applied first and `configOverrides` second, so an override always wins on any field they both touch. Alongside `configRef`, `configOverrides`, and `configValues`, the reference object also accepts `advancedSettingsName`, which points at an advanced-settings configuration block managed by MediaKind. Leave it unset unless MediaKind support has asked you to reference one, since it is not a customer-authored setting. ## List all templates List all templates across all types: ```bash curl -X GET "https://app.mk.io/api/v1/projects//templating/configs" \ -H "Authorization: Bearer " ``` Filter by type: ```bash curl -X GET "https://app.mk.io/api/v1/projects//templating/configs/encodingLive" \ -H "Authorization: Bearer " ``` ## What goes wrong - **The preset name is unavailable.** List presets in the target project and copy a returned name into `spec.presetName`. - **The live resource uses the wrong pin.** Retrieve the created config and use the exact `status.inputPins[].name` value for `transformInput`. - **A shared tag points to a new version.** Uploading moves the tags supplied in the request. Use a version hash when a live resource must keep a specific revision. ## Where to go deeper - [Live event walkthrough](/mkio/api-guides/how-to/live/walkthrough): use a config to encode a single live input. - [Multiview](/mkio/api-guides/how-to/live/multiview): choose between combined composition and encoding or separate configs. - [Templates API reference](/api-reference/templates-api): inspect `TemplatingConfigPutSchema`, `ConfigParameterSchema`, and the version endpoints. # Understand the APIs These guides explain the conventions shared across the MK.IO APIs, including authentication, pagination, rate limits, errors, and resource states. [API overview](/mkio/api-guides/understanding/overview) Learn the shared base URL, authentication, list responses, and resource states. [Pagination](/mkio/api-guides/understanding/pagination) Understand how list responses expose pages of resources. [Rate limits](/mkio/api-guides/understanding/rate-limits) Learn how the APIs communicate request limits. [Error handling](/mkio/api-guides/understanding/error-handling) Interpret API errors and handle failed requests. [Resource states](/mkio/api-guides/understanding/resource-states) Track the state of resources and long-running operations. [Webhooks](/mkio/api-guides/understanding/webhooks) Understand event notifications from the platform. # Error handling The MK.IO APIs return the same error body for every failure. Once your client handles that one shape, the rest of error handling is consistent across the platform: inspect the HTTP status, branch on the machine-readable code, log the human-readable detail, and keep the request reference for follow-up. ## The standard error body When an operation fails, the API returns a JSON object with this shape: ```json { "error": { "code": "", "detail": "", "extraDetail": {} }, "status": 400, "ref": "" } ``` Each field has a distinct job:
Field Use it for
error.code Programmatic branching in your application.
error.detail Logs, dashboards, and operator-facing messages.
error.extraDetail Any additional context the API includes.
status The HTTP status code, repeated in the body.
ref Support follow-up and request tracing.
If you keep only one field beyond the status line, keep `ref`. It is the quickest way to identify a failing request afterwards. ## Status codes across the platform The exact response set varies by endpoint, but these codes appear throughout the APIs. Success responses:
Code Meaning
200 The request succeeded and returned a body.
201 The resource was created.
202 The request was accepted and continues asynchronously.
204 The request succeeded with no response body.
Client-side problems:
Code Meaning What to do next
400 Bad Request Recheck the path, query parameters, and body format.
401 Unauthorized Recheck the bearer token and Authorization header.
403 Forbidden Recheck organization, project, and operation access for the token's user.
404 Not Found Recheck names and path parameters, especially project-scoped names.
409 Conflict Recheck the resource state, or whether the operation conflicts with an existing reference.
429 Too Many Requests Back off and retry later. See Rate limits.
Server-side problems:
Code Meaning What to do next
500 Internal Server Error Retry carefully and keep the ref value.
503 Service Unavailable Treat it as temporary and keep the ref value if it persists.
## A handling order that works When a request fails: 1. Record the HTTP status code. 2. Parse `error.code` and `error.detail`. 3. Record `ref`. 4. Decide whether to fix the request, retry it, or surface it to an operator. As a guide to that decision: - `400`, `401`, `403`, and many `404` responses mean the request needs correcting. - `409` usually means the operation is valid, but the target resource is not in the right state yet, or is still referenced elsewhere. - `429`, `500`, and `503` are the cases where careful retry logic pays off. ## See the status and body together When you debug from the command line, print the transport status alongside the body so a log line captures both: ```bash curl -sS \ -H "Authorization: Bearer " \ -H "Accept: application/json" \ -w "\nHTTP Status: %{http_code}\n" \ "https://app.mk.io/api/v1/projects//media/assets/nonexistent" ``` # API overview The MK.IO cloud APIs are separated by product area and share request conventions. Once you know how paths are scoped, how list responses are shaped, and how long-running resources expose state, you can move between the APIs without learning a new set of conventions each time. ## One base URL The Media, Live, Templates, and Management APIs use this base URL: ```text https://app.mk.io ``` The resource path is what differs between them:
API Path prefix Scope
Media API /api/v1/projects/{project_name}/media/ Project
Live API /api/v1/projects/{project_name}/live/ Project
Templates API /api/v1/projects/{project_name}/templating/ Project
Management API /api/v1/ Organization and project
When a path includes `/projects/{project_name}/`, the request is project-scoped. When it does not, it usually targets organization-level or user-level configuration through the Management API. ## Authentication is shared The cloud APIs above use bearer authentication: ```http Authorization: Bearer ``` A single token works across setup and operational workflows. The same token can create a project through the Management API and then list assets through the Media API, as long as the issuing user has access to both operations. See [Authentication](/mkio/api-guides/getting-started/authentication) for how to create one. ## Requests are HTTP plus JSON The request shape follows a small set of rules: - `GET` reads a resource or lists a collection. - `PUT` creates or replaces a resource whose name is part of the URL. - `PATCH` applies a partial update where the endpoint supports it. - `POST` runs an action, such as `start`, `stop`, `allocate`, `scale`, `backup`, or `restore`. - `DELETE` removes a resource. Send `Content-Type: application/json` on any request that has a JSON body. ## List responses share a shape A `list` endpoint returns the resources in `value` and metadata in `supplemental`: - `value`: the array of resources on the current page. - `supplemental`: counts and pagination metadata, including `supplemental.pagination` with `start`, `end`, `records`, and `total`. Read `value` for the current page and check the endpoint's pagination contract for the next page. Media collections can return `@odata.nextLink`; follow that link when present. See [Pagination and filtering](/mkio/api-guides/understanding/pagination) for the query parameters and the paging mechanism. ## Many resources expose a lightweight state endpoint Several resources expose a `/state` endpoint next to the main resource, including Media API assets, content key policies, jobs, live events, live outputs, streaming endpoints, and streaming locators. These endpoints let you monitor a long-running resource without retrieving the full object each time. See [Resource states](/mkio/api-guides/understanding/resource-states). ## Long-running workflows are common Several important workflows are not single calls: - A **job** moves from queued work, through processing, to a terminal state. - A **Media API live event** is created, then started, then paired with one or more live outputs. - A **Live API resource** references sources, an asset, and template configs. Set `spec.state` to request `Running` or `Stopped`, then monitor `status.state` until the transition completes. - A **streaming endpoint** is created and started before playback works. Designing around these workflows means combining list or get operations with either polling on `/state` or subscribing to [webhooks](/mkio/api-guides/understanding/webhooks). ## Where to go next - [Authentication](/mkio/api-guides/getting-started/authentication): create a token and make your first call. - [Error handling](/mkio/api-guides/understanding/error-handling): the shared error body and status codes. - [Pagination and filtering](/mkio/api-guides/understanding/pagination): page and narrow list responses. - [Resource states](/mkio/api-guides/understanding/resource-states): read lifecycle state and design around it. # Pagination and filtering Most MK.IO `list` endpoints accept query parameters that page, sort, and filter the results on the server. Using them keeps responses small, removes client-side filtering work, and reduces the number of follow-up requests your integration makes. ## The shape of a list response A list response includes these fields: - `value`: the array of resources on the current page. - `supplemental`: metadata about the result set, including pagination counts. - `@odata.nextLink`: the URL for the next page, when another page is available. A trimmed response looks like this: ```json { "value": [ { "name": "asset-001" }, { "name": "asset-002" } ], "supplemental": { "count": 2, "kind": "Asset", "operation": "list", "pagination": { "start": 0, "end": 2, "records": 2, "total": 145 } }, "@odata.nextLink": "" } ``` The `pagination` block tells you where you are in the collection: `records` is how many items this page returned, and `total` is how many exist across the whole project. Use `@odata.nextLink` to continue through the result set, including when you have applied filters. ## Limit a page with $top `$top` caps how many items a single page returns. The service returns up to that many, and never more than exist. ```bash curl -X GET "https://app.mk.io/api/v1/projects//media/assets?\$top=10" \ -H "Authorization: Bearer " ``` The `$` is escaped as `\$` in these examples so that your shell does not treat the parameter as a variable. ## Page through results with $skiptoken The service uses `$skiptoken` to identify the start offset of a page. It supplies the next request URL in `@odata.nextLink`, so you do not need to construct the token yourself. After processing the current page's `value` array, request the URL returned in `@odata.nextLink` with the same bearer authentication: ```bash curl -X GET "" \ -H "Authorization: Bearer " ``` Replace `` with the complete `@odata.nextLink` value from the response. Continue following each returned link until `@odata.nextLink` is absent. Keep the query parameters in the returned URL so the next request continues the same result set. ## Sort with $orderby `$orderby` orders the result collection by a field. The valid fields depend on the endpoint. ```bash curl -X GET "https://app.mk.io/api/v1/projects//media/assets?\$orderby=properties/created%20desc" \ -H "Authorization: Bearer " ``` For the Media API asset list, sortable fields include `name`, `properties/created`, `properties/lastModified`, and `properties/storageAccountName`. Other APIs expose their own sort keys. Check the [API reference](/api-reference/media-api) for the fields a given endpoint supports. ## Filter with $filter `$filter` restricts the result set to items that match an expression. ```bash curl -X GET "https://app.mk.io/api/v1/projects//media/assets?\$filter=name%20eq%20'my-asset'" \ -H "Authorization: Bearer " ``` The fields available to filter on vary by resource. Common examples are assets by `name` or `properties/created`, live events by `properties/resourceState`, devices by `spec/siteName`, and sites by `status/locationName`. ## Filter by label Several list endpoints also support label queries, which are separate from `$filter`. Return items that carry a given label key with `$label_key`: ```bash curl -X GET "https://app.mk.io/api/v1/projects//media/assets?\$label_key=studio" \ -H "Authorization: Bearer " ``` When you pass more than one `$label_key`, an item must carry all of those keys to match. Match a key and value with `$label`. Use `=` for an exact match and `~` for a partial match: ```bash curl -X GET "https://app.mk.io/api/v1/projects//media/assets?\$label=studio=paravalley" \ -H "Authorization: Bearer " ``` Label queries are supported on the asset, live event, device, network, and site list endpoints. ## Combine parameters to do less work The parameters compose. A single request can limit, sort, and filter at once: ```bash curl -X GET "https://app.mk.io/api/v1/projects//media/assets?\$top=10&\$orderby=properties/created%20desc&\$label=studio=paravalley" \ -H "Authorization: Bearer " ``` That one call returns the ten most recent assets for one studio, which would otherwise take a full list plus client-side sorting and filtering. ## A pattern for scanning large collections When you need to process an entire collection, work from narrow to broad: 1. Apply the narrowest `$filter` or label query the task allows. 2. Add `$orderby` if processing order matters. 3. Set a bounded `$top`. 4. Follow `@odata.nextLink` until the response no longer includes it. Filtering and sorting on the server is almost always better than listing everything and filtering locally. It returns less data, needs fewer follow-up requests, and keeps you clear of the [rate limits](/mkio/api-guides/understanding/rate-limits). ## Related reading - [API overview](/mkio/api-guides/understanding/overview): the request and response conventions these endpoints share. - [Rate limits](/mkio/api-guides/understanding/rate-limits): why server-side filtering matters for request volume. # Rate limits The MK.IO APIs limit request rates to protect platform stability. Most integrations never reach those limits during normal use. Background workers, tight polling loops, and bulk scans are the patterns that approach them, so they are worth designing carefully. ## What a 429 looks like When you exceed a limit, the API responds with `429 Too Many Requests`. The body uses the same standard error shape as any other failure: ```json { "error": { "code": "", "detail": "", "extraDetail": {} }, "status": 429, "ref": "" } ``` Record the `ref` value before you retry. If a `429` is unexpected for your request volume, `ref` is the fastest way to identify the request later. See [Error handling](/mkio/api-guides/understanding/error-handling) for the full error model. ## Published limits Most endpoints enforce these limits:
Request type Limit
GET 2,000 per minute
DELETE, PATCH, POST, PUT 1,000 per minute
Some endpoints, including authentication flows, apply stricter limits. Limits are scoped to the resource the path targets. Project-scoped endpoints (those with `/projects/{project_name}/` in the path) count per project. Endpoints without a project in the path count per organization. This matters for multi-project automation: a process that fans out across projects behaves differently from one that repeatedly targets a single project. ## The most common way to hit a limit Aggressive polling is the usual cause. Polling 50 jobs once per second is 3,000 `GET` requests per minute against one project, which exceeds the read limit before any list or detail requests are counted. This is why event-driven workflows scale better than timer-based status checks. ## Design within the limits ### Prefer events over polling Where an operation has webhook coverage, subscribe instead of polling. Use `MediaKind.JobFinished` rather than polling a job, and use channel state events for live workflows. One event delivery replaces many repeated reads. See [Webhooks](/mkio/api-guides/understanding/webhooks). ### Narrow list requests on the server Use `$filter`, `$label`, `$label_key`, and `$top` so you request only what you need: ```bash curl -X GET "https://app.mk.io/api/v1/projects//media/assets?\$top=20&\$label=studio=paravalley" \ -H "Authorization: Bearer " ``` This returns far fewer items than listing everything and filtering locally. See [Pagination and filtering](/mkio/api-guides/understanding/pagination). ### Page forward instead of restarting scans When you scan a large collection, continue from your last `$skiptoken` rather than rerunning the first page from the top. ### Back off between retries When you retry after a temporary failure, add a delay between attempts rather than retrying immediately. Even a fixed delay helps prevent a brief problem from becoming a sustained rate-limit issue. ## A design pattern for long-running workflows 1. Create the resource. 2. If webhook events exist for it, wait for the event. 3. If you must poll, poll the narrowest endpoint available, such as `/state`. 4. Add a delay between attempts. 5. Stop polling once the resource reaches the state you need. This keeps request volume predictable and usually improves end-to-end latency. ## If you keep hitting the limit If a normal workflow returns `429` consistently after you have narrowed requests and reduced polling, collect the project or organization context, the endpoint being called, the approximate request rate, and the `ref` values from the failing responses. That gives you enough to investigate the traffic pattern rather than guess. # Resource states Many MK.IO resources are asynchronous. A request to create or start one returns quickly, but the resource then moves through internal processing before it is ready to use. An integration that ignores state eventually tries to publish, stream, or delete a resource at the wrong moment. ## Where state appears State is exposed in two ways: - A dedicated `/state` endpoint next to the resource, for lightweight polling. - State fields on the full resource record, returned by a normal `GET`. In the Media API, the resources with a `/state` endpoint are assets, content key policies, jobs, live events, live outputs, streaming endpoints, and streaming locators. Poll the `/state` endpoint when you only need the current status. Read the full resource when you also need its configuration. Live API channels, events, and multiview resources also expose `/state`. Their desired state is `spec.state`, and their reported state is `status.state`. See [Live resource states](/mkio/api-guides/how-to/live/core-concepts/resource-states) for that lifecycle. The Media API examples below use a different resource model. ## Read the /state endpoint The `/state` endpoint returns a small, uniform body. The `state` value is a string whose meaning depends on the resource type. ```bash curl -X GET "https://app.mk.io/api/v1/projects//media/transforms//jobs//state" \ -H "Authorization: Bearer " ``` ```json { "status": { "state": "Processing" } } ``` ## Media API resource states Each resource moves through its own lifecycle. The table below lists the states you observe in normal operation, taken from the MK.IO [resource states reference](/mkio/reference/resource-states). Use them to decide when the next step in a workflow is valid.
Resource Initial Ready Running lifecycle
Asset Pending Ready -
Content key policy Creating Created -
Live output Creating Running -
Streaming locator Creating Created -
Streaming endpoint Creating Created Starting, Running, Stopping, Stopped
Live event Allocating StandBy Starting, Running, Stopping, Stopped
Jobs use a separate set of states, reported in `properties.state`: `Queued`, `Scheduled`, `Processing`, `Finished`, `Canceling`, `Canceled`, and `Error`. Two states apply to almost every resource: - `Deleting`: the resource is deleted and the system is processing the removal. - `Deleted`: removal is complete. You rarely observe this value, because the resource no longer exists and the endpoint returns `404`. The API may also report extra transient states for some resources, such as `Updating`, `Scaling`, or `Error`. The [Media API reference](/api-reference/media-api) lists the complete enum for each resource, while the [resource states reference](/mkio/reference/resource-states) explains what each value means. ## Tell runtime state from provisioning state Live events, live outputs, streaming endpoints, and streaming locators expose two separate ideas of state: - `provisioningState` reports whether the control plane finished creating or updating the resource. Its values are `InProgress`, `Succeeded`, and `Failed`. - `resourceState` reports whether the resource is currently running, stopped, or being deleted. When you wait for a resource to become usable, do not stop at `provisioningState` of `Succeeded`. A streaming endpoint can be provisioned but not yet `Running`. Check `resourceState` as well. ## Design state transitions into the workflow A safe automation flow waits for the right state before each dependent call: 1. Create or start the resource. 2. Poll until it reaches the state that makes the next step valid. 3. Make the next call only then. In practice: - Wait for a job to reach `Finished` before you publish its output asset. - For Media API `/media/liveEvents`, follow the [Media live-streaming startup sequence](/mkio/api-guides/how-to/media/live-streaming). - For Live API `/live/liveEvents`, prepare the contribution encoder as part of startup and monitor `status.state`. See the [Live event walkthrough](/mkio/api-guides/how-to/live/walkthrough#step-6-start-the-event). - Wait for a streaming endpoint to reach `Running` before you expect playback to succeed. ## When to stop polling Polling suits short waits and one-off scripts. It becomes expensive when you monitor many jobs or long-running live workflows, because each check is a request that counts against the [rate limits](/mkio/api-guides/understanding/rate-limits). At that scale, [webhooks](/mkio/api-guides/understanding/webhooks) deliver the same state changes without the repeated reads. A common pattern is to use webhooks for change notification and a single `GET` for current detail when a user asks for it. ## What comes next - [Webhooks](/mkio/api-guides/understanding/webhooks): replace repeated polling with event delivery. - [Transforms and jobs](/mkio/api-guides/how-to/media/transforms-and-jobs): see how job state fits a VOD workflow. - [Live streaming](/mkio/api-guides/how-to/media/live-streaming): see how live-event state affects ingest and publishing. # Webhooks Webhooks let your integration react to MK.IO events as they happen. Rather than polling jobs, live events, or streaming locators on a timer, you register a webhook rule and receive an HTTP `POST` request whenever a subscribed event fires. Webhook rules belong to the Management API. ## How a webhook rule works A rule belongs to a project and defines where to deliver events, whether delivery is on, and which events trigger it: - `url`: the target for the `POST` request. - `enabled`: whether the rule delivers. - `events`: the event types that trigger the rule. - `headers` and `queryParams`: non-sensitive request decoration. - `authentication.headers` and `authentication.queryParams`: sensitive values, such as a shared secret. The configuration endpoint is `/api/v1/projects/{project_name}/webhook/rules`. For the create, edit, and delete calls, see [Webhook rules](/mkio/api-guides/how-to/management/webhooks). ## The events you can subscribe to
Event Use it to
MediaKind.JobStarted Track when a job leaves the queue and begins processing.
MediaKind.JobFinished Trigger downstream work when a job reaches a terminal state.
MediaKind.StreamingLocatorCreated React when newly published content is ready.
MediaKind.ChannelInstanceStarted Track live channel startup.
MediaKind.ChannelInstanceStopped Track live channel shutdown.
MediaKind.ChannelInstanceError Alert on live channel failures.
MediaKind.ScheduledOperationAccepted Observe scheduled work entering the pipeline.
MediaKind.ScheduledOperationOngoing Track scheduled work in progress.
MediaKind.ScheduledOperationCompleted Trigger follow-up work after a scheduled operation finishes.
MediaKind.ScheduledOperationError Alert on scheduled-operation failures.
Scheduled operation events are available only when that feature is enabled for the organization. ## The delivered payload MK.IO delivers events in the [CloudEvents](https://cloudevents.io/) format. Every payload has the same envelope: ```json { "specversion": "1.0", "id": "", "type": "", "source": "", "time": "", "datacontenttype": "application/json", "data": { "projectName": "", "previousState": "", "state": "", "resource": {} } } ``` The `data.resource` object holds the full resource, exactly as a `GET` on `source` would return it. The `data.previousState` and `data.state` fields tell you which transition fired the event:
Event previousState state
MediaKind.JobStarted Queued Processing
MediaKind.JobFinished Processing Finished, Canceled, or Error
MediaKind.StreamingLocatorCreated Creating Created
## What webhooks change in your design Without webhooks, a client creates a resource, then polls a `GET` or `/state` endpoint until the resource reaches a terminal state, handling retry timing and rate limits along the way. With webhooks the flow becomes: 1. Create the resource. 2. Return control to the user or job runner. 3. Wait for the event that reports the state change. 4. Retrieve the resource only when you need fresh detail. This is most valuable for jobs and live workflows, where the wait can be long and unpredictable. ## A useful first rule For a Video On Demand (VOD) workflow, the smallest useful subscription is `MediaKind.JobStarted` and `MediaKind.JobFinished`, which signal when a job begins and when it reaches a terminal state. For live workflows, start with `MediaKind.ChannelInstanceStarted`, `MediaKind.ChannelInstanceStopped`, and `MediaKind.ChannelInstanceError`. ## Authentication fields are write-only A rule separates general request decoration from sensitive values. `headers` and `queryParams` carry general fields. `authentication.headers` and `authentication.queryParams` carry secret or authentication values. Fields under `authentication` are write-only: when you read a saved rule back, those values appear masked rather than in clear text. ## Build a handler that survives retries If a delivery fails, MK.IO retries it. Your endpoint should therefore handle duplicate deliveries safely: - Make event handling idempotent where possible. - Log the event `id`, `type`, and `source`. - Return a success response as soon as you have safely accepted the event. Treat the endpoint as a security surface. Serve it over HTTPS, pass a shared secret through the `authentication` fields, and verify that secret in your handler before acting on a payload. ## When a direct read is still the right tool Webhooks suit asynchronous workflows, but they do not replace every read. Use a direct `GET` when a user asks for the current state now, when you need to list resources on demand, or when the resource has no event coverage. The strongest integrations combine both: webhooks for change notification, and API reads for current detail. ## Related reading - [Resource states](/mkio/api-guides/understanding/resource-states): the state values these events report. - [Rate limits](/mkio/api-guides/understanding/rate-limits): why event delivery scales better than polling. # Changelog ## Live streaming and multiview **September 9, 2026** The **Live** interface brings reusable sources, encoding profiles, and scheduled start and stop controls together for live events and continuous channels. Multiview combines several sources into one tiled stream. The Live and Templates Application Programming Interfaces (APIs) let you automate these workflows and reuse versioned encoding and composition configurations across broadcasts. See [Live and multiview](/mkio/how-to/live-streaming/live), [Live API](/mkio/api-guides/how-to/live), and [Templates API](/mkio/api-guides/how-to/templates) for details. ## Project billing assignments **July 6, 2026** Organization administrators can now view and manage the payment method assigned to each project. Administrators can move one or more projects to another payment method within the same organization, helping keep usage charges allocated correctly when billing arrangements change. See [Billing](/mkio/how-to/managing-your-organization/billing#move-a-project-between-payment-methods) for details. ## Payment methods can be deleted **July 3, 2026** Organization administrators can now delete payment methods from the Admin UI. A deleted payment method no longer appears to the organization's customers or in the Admin UI, and any redemption links associated with it stop working. A payment method with projects still attached cannot be deleted. A payment method deleted by mistake can be restored via the API. ## Styled WebVTT subtitles **June 25, 2026** MK.IO can now preserve color and style information from input subtitles in Web Video Text Tracks (WebVTT) output. ## Teletext to TTML conversion for Static Multiview **June 24, 2026** Static Multiview now accepts Teletext tracks at the input and converts them to Timed Text Markup Language (TTML) tracks at the output, matching support already available for Elastic Multiview. ## New MK.IO billing view **June 23, 2026** The new **Billing** view is now generally available in MK.IO. Administrators can review organization spend across MK.IO and MK.IO Beam, filter by product, inspect monthly and daily usage, download comma-separated value (CSV) reports, and manage the Beam billing model for each payment method. See [Billing](/mkio/how-to/managing-your-organization/billing) for details. ## Improved payment method redemption for multi-organization accounts **June 15, 2026** Redemption links for direct sales payment methods are now scoped to a single organization when possible, reducing the risk of a payment method being associated with the wrong organization. If a link can't be scoped automatically and your account has multiple organizations, MK.IO now prompts you to choose which organization to redeem it against. ## Payment method display names **June 3, 2026** Payment methods now support display names in the MK.IO user interface and Management Application Programming Interface (API). Use display names to distinguish multiple payment methods associated with the same sales order. The name appears in payment method lists and details. See [Billing](/mkio/how-to/managing-your-organization/billing#understand-payment-methods) for details. ## Beam usage summaries for partner customers **June 3, 2026** Customers who access MK.IO through a channel partner can now see current-month Beam usage summaries on the MK.IO dashboard, including encoding and reception hours. Billing information remains managed by the channel partner and is not shown to those customers. ## Extended live event archive window **May 19, 2026** Live event archive windows now support durations of up to 7 days, up from the previous maximum of 25 hours. When the archive window is set to more than 25 hours, the manifest presents a rolling 25-hour window of the most recent content. To access content older than 25 hours, specify start and end times in the manifest request query parameters. You can also use asset or account filters to control exactly which portion of the archive each manifest request returns. See [Extended archive window](/mkio/how-to/live-streaming/extended-archive-window) for details. ## Fastly CDN delivery **May 19, 2026** MK.IO self-service and managed deployments previously using Akamai now use Fastly for Content Delivery Network (CDN) delivery. The migration also adds updated monitoring and metering for CDN-backed streaming endpoints. ## ESAM automation for Static Multiview flows **May 19, 2026** Static Multiview flows now support Event Signaling and Management (ESAM) out-of-band signaling and automation, including slate insertion, matching functionality already available for live channels. ## AWS Marketplace private offers **May 18, 2026** MK.IO now supports private offers through Amazon Web Services (AWS) Marketplace. This release supports pre-committed marketplace agreements with custom rate cards and entitlements. ## Expanded Static Multiview layouts **May 7, 2026** Static Multiview now supports layouts with up to 9 tiles, up from the previous maximum. ## High-scale flow resilience **April 13, 2026** MK.IO now handles high-volume flow workloads with fewer and less complex database queries. These changes reduce platform load and improve resilience for customers. ## Broader packaging interoperability **March 6, 2026** MK.IO can now apply advanced settings to the just-in-time packager. These settings support packaging interoperability requirements, including DASH interoperability and cache values. ## RIST distribution for Multiview **January 28, 2026** MK.IO now supports Reliable Internet Stream Transport (RIST) distribution for Multiview sources. A source can be reused up to 250 times in downstream flows across multi-cluster locations without distributing multiple copies over the internet. ## Self-service Multiview **November 19, 2025** Self-service Multiview is now available to select MK.IO customers. You can create Multiview channels, with quotas and usage statistics available for the supported flow types. ## VOD audio dubbing **November 14, 2025** MK.IO now supports on-demand audio dubbing for Video on Demand (VOD) content. Use an Artificial Intelligence (AI) workflow to generate translated audio tracks from an existing audio track. VOD audio dubbing is available in all regions and is billed per minute of processed content. See [Multi-language VOD dubbing](/mkio/how-to/ai-features/multi-language-vod-dubbing) for details. ## Audio track side loading **November 14, 2025** You can now side-load additional audio tracks into existing VOD assets through the API. Use this feature to add commentary, alternate languages, or descriptive audio. Audio track side-loading is available in all regions at no additional charge. See [Track insertion transform](/mkio/reference/encoding-transform-presets/add-a-track-to-a-vod-asset) for details. ## Streaming endpoint charge notifications **October 22, 2025** MK.IO now displays a billing message before you start a streaming endpoint. The message also appears in the **Create and start** workflow, so you can confirm that charges apply before the endpoint starts. ## Compare live channel templates **October 15, 2025** You can now compare Live Channel template versions in the MK.IO interface. Choose a revision to see a side-by-side or inline comparison, review highlighted metadata and configuration changes, and navigate directly to modified sections. ## Uninterrupted live service upgrades **October 15, 2025** Nightly MK.IO control plane upgrades no longer interrupt running Live Events or Live Channel services. Planned service interruptions remain limited to agreed maintenance windows. ## Expanded Dolby Vision support **October 10, 2025** MK.IO now supports Dolby Vision Profile 8.4 for Hybrid Log-Gamma (HLG) channels and Dolby Vision Profile 8.1 passthrough. Profile 8.4 avoids converting HLG sources to PQ10, while Profile 8.1 passthrough preserves source metadata in the encoded output. ## AV1 support in live streaming **July 21, 2025** MK.IO live encoding and packaging now support the AV1 video codec as an alternative to HEVC, reducing bitrate and Content Delivery Network (CDN) costs for progressive, internet-delivered streams up to HD resolution. AV1 support is in limited availability and not enabled by default. ## Dynamic live outputs for events **July 2nd, 2025** You can now dynamically add or remove live outputs from a live event in MK.IO, even while the event is running. **What is new** - Add or remove one or more live outputs at any time, without stopping or restarting the event. - Manage destinations on the fly for greater flexibility in live production workflows. - Streamline your transition from Live to VOD by controlling exactly how and where your live content is output and recorded. ## Live transcription **July 2025** Live encoding events can generate real-time subtitles through the `Predefined_ACSLiveTranscription` AI pipeline. The pipeline produces WebVTT subtitles for HLS output and TTML subtitles for DASH output, with less than five seconds of added latency. Configure the source language and optional expected phrases when creating the live event. The feature launched in all regions and is billed per minute of a running live event. See [Configure a live event](/mkio/how-to/live-streaming/set-up-a-live-streaming-event) for details. ## VOD translation **July 2025** VOD translation can transcribe an audio track and translate the result into up to 25 languages in one operation. The workflow produces WebVTT subtitle tracks for the source and target languages. The feature launched in all regions and is billed per minute of processed VOD content. See [Transcription and translation transforms](/mkio/how-to/ai-features/vod-transcription-and-translation-transforms) for details. ## Subtitle support in asset conversion **June 9th, 2025** MK.IO now supports subtitle preservation during asset conversion, ensuring that captions from your live events remain available in your on-demand MP4 content. ## Audio-only transcoding for Live Events **May 22nd, 2025** MK.IO now supports audio-only transcoding for live events, helping you deliver optimized, bandwidth-efficient audio streams. ## Simplify your account with the new billing view **May 20th, 2025** MK.IO added detailed billing information for the current or a selected month. The initial view grouped usage into Live Processing and Recording, Content Processing and Transcoding, Video Streaming, Content Protection, and Storage Management. Customers with multiple projects could inspect each project or an aggregate view. Usage across multiple subscriptions was aggregated for reporting, while charges remained separated by subscription. The detailed view launched in all regions at no extra cost. See [Billing](/mkio/how-to/managing-your-organization/billing) for the current billing view. ## MK.IO now supports MK.IO Beam devices **May 5th, 2025** MK.IO now includes MK.IO Beam device management, allowing you to monitor, control, and update devices through the same interface. **Fleet Management for MK.IO Beam Devices**\ Access your Beam device UI remotely and troubleshoot issues with the new remote access capabilities. You can also add, edit, and remove devices directly in the MK.IO UI without using the API. The release added a unified device-status view and a map of registered device locations. **Customer Onboarding Workflow**\ The new onboarding flow makes it simple to get started with Beam devices: - Create or link your organization - Add a payment method - Set up your first project - Register and activate your Beam device from MK.IO **Beam Software Upgrades**\ Beam bundle downloads and software upgrades are now available through MK.IO for connected devices. Docs: [MK.IO Beam devices onboarding](/mkio/how-to/managing-edge-devices/on-board-fleet-devices) Fleet management became available in April 2025 at no additional charge. ## Job notifications via webhooks **April 14th, 2025** MK.IO jobs now support webhook notifications through the Management API. Payloads use the CloudEvents format, delivery runs asynchronously, and MK.IO retries failed deliveries. Webhooks launched in all regions at no additional cost. Docs: [Webhooks](/mkio/how-to/managing-your-organization/webhooks) ## MK.IO available on AWS marketplace **February 28th, 2025** MK.IO can now be discovered, subscribed to, and deployed directly through the AWS Marketplace. This simplifies procurement for enterprise customers and makes it easier to integrate MK.IO within your existing AWS infrastructure. Key Benefits: - Streamlined procurement through your AWS account - Consolidated billing with your existing AWS usage - Faster onboarding for enterprise customers AWS users can access MK.IO without additional contracts or setup. At launch, the subscription used pay-as-you-go billing with no activation or setup fees. Customers could apply an AWS enterprise commitment and run processing close to content stored in Amazon S3. Docs: [Subscribe through AWS Marketplace](/mkio/how-to/managing-your-organization/subscribe-through-aws-marketplace) ## Live & VOD transcription enhancements **February 10th, 2025** MK.IO now offers more flexibility, accuracy, and insight into your transcription workflows across Live and VOD content. **Update Caption Language Values**\ Easily update transcription language codes (e.g., en-UK → en-GB) directly from the UI or API - no more manual fixes or request errors. **Live Transcription Monitoring**\ MK.IO now includes metrics and alerts for monitoring Live transcription performance. **Language Selection for Live and VOD**\ Choose your preferred transcription language for both Live and VOD workflows - ensuring accurate captions and localized experiences for every audience. **In-Band Audio Transcriptions**\ Generate transcriptions automatically from in-band audio streams in your Live Encodes, simplifying setup and improving reliability. **VOD Speech-to-Text Translation**\ Upload any VOD asset and automatically generate translated transcripts in multiple languages, expanding global reach and accessibility. Docs: [Live transcription](/mkio/how-to/live-streaming/set-up-a-live-streaming-event) | [VOD transcription and translation](/mkio/how-to/ai-features/vod-transcription-and-translation-transforms) ## Streaming endpoints: separate domain and name fields **February 3rd, 2025** MK.IO now generates Streaming Endpoint URLs with separate domain and name fields for improved security, privacy, and naming flexibility. **What is new:** - The Streaming Endpoints API now includes a new field: publicName - This publicName is used exclusively for published endpoint URLs, ensuring that only approved, share-safe identifiers appear in public addresses. - The publicName is validated as globally unique and formatted for compatibility in both DNS names and URL paths. Docs: [Streaming endpoints](/mkio/understanding/core-concepts/endpoints) ## Upload local files for transform from the UI **January 14th, 2025** You can now upload local files directly from the MK.IO UI to initiate transformations without using the API or external storage. Docs: [Add assets into MK.IO](/mkio/how-to/content-management/add-an-asset-in-mkio) ## ALAC support **January 10th, 2025** ✨ Features added\ Apple Lossless Audio Codec support is now available. Docs: [Encoding Transform](/mkio/reference/encoding-transform-presets/encoding-transform) ## Asset Filtering by UTC Start and End Time **January 7th, 2025** You can now filter and trim assets using precise UTC start and end times in MK.IO. **What is new** - Specify start and end times in UTC when filtering or trimming your content. - Achieve frame-accurate control over the portions of live or recorded content you want to keep. - Ideal for editing live events, highlights, or scheduled content that spans multiple time zones. ## Use live output name during asset conversion **January 6th, 2025** When converting assets, MK.IO now automatically uses the Live Output name, ensuring consistent naming conventions across workflows. Docs: [Asset conversion transform](/mkio/reference/encoding-transform-presets/asset-conversion-transform) ## Sorenson Spark support **December 23rd, 2024** ✨ Features added\ Sorenson Spark support is now available for Flash content. Docs: [Encoding Transform](/mkio/reference/encoding-transform-presets/encoding-transform) ## ADPCM and DPCM for WAV **November 19th, 2024** ✨ Features added\ ADPCM and DPCM support is now available for WAV content. Docs: [Encoding Transform](/mkio/reference/encoding-transform-presets/encoding-transform) ## Operational metrics **November 5, 2024** Operational metrics became available in all regions on September 12, 2024. Projects can publish Prometheus metrics for an external monitoring framework. Early adopters needed to update their scrape URL to the documented endpoint. Docs: [Activate and scrape operational metrics](/mkio/how-to/monitor-your-services) ## AI-based VOD transcription **October 28, 2024** AI-based transcription became available for VOD assets in all regions. The workflow generates a WebVTT subtitle track from an audio track and is billed per minute of processed VOD content. Docs: [VOD transcription](/mkio/how-to/ai-features/vod-transcription-and-translation-transforms) ## Role-based access control **October 21, 2024** Role-based access control (RBAC) became available in all regions at no additional charge. It replaced individual project assignments with teams, roles, scopes, and rights assignments. During the rollout, the earlier and new authorization models ran together and MK.IO applied the more restrictive result. Docs: [Access, users and teams](/mkio/how-to/managing-your-organization/access-users-and-teams) ## MP3 ingest | Cover images **October 11th, 2024** ✨ Features added\ Encoding transform can now ingest MP3. Cover images are also supported. Docs: [Encoding Transform](/mkio/reference/encoding-transform-presets/encoding-transform) ## WebM AV1 | WMV Microsoft MPEG4 | H.263 ingest **September 24th, 2024** ✨ Features added\ Encoding transform can now ingest files in WebM format including AV1 video codec.\ Encoding transform can now ingest files in WMV format with Microsoft MPEG4 video codec.\ Encoding transform can now ingest using H.263 video codec. Docs: [Encoding Transform](/mkio/reference/encoding-transform-presets/encoding-transform) ## MJPEG ingest **September 18th, 2024** ✨ Features added\ Encoding transform can now ingest files in content using MJPEG video codec. Docs: [Encoding Transform](/mkio/reference/encoding-transform-presets/encoding-transform) ## VP8 | VP9 | Opus | Vorbis ingest **August 29th, 2024** ✨ Features added\ Encoding transform can now ingest files in WebM format including VP8, VP9 video codecs and Opus, Vorbis audio codecs. Docs: [Encoding Transform](/mkio/reference/encoding-transform-presets/encoding-transform) ## WebVTT subtitle side-loading **August 19, 2024** Web Video Text Tracks (WebVTT) subtitles can now be side-loaded to an existing VOD asset through the Media API. The feature launched in all regions at no additional charge. Docs: [Track insertion transform](/mkio/reference/encoding-transform-presets/add-a-track-to-a-vod-asset) ## VOD input clipping **August 16, 2024** VOD processing jobs now support clipping an asset or HTTP input with a start and end time through the Media API. The feature launched in all regions at no additional charge. Docs: [Job with input clipping](/mkio/how-to/video-processing-encoding/vod-processing-job-with-input-clipping) ## New region: West US **August 8th, 2024** ✨ New region deployed\ We are opening one new region: West US Docs: [Cloud region support](/mkio/reference/cloud-region-support) ## RTMPS ingest **July 25th, 2024** ✨ Features added\ Live events can now use RTMPS as ingest transport protocol. ## SRT ingest **July 17, 2024** Live encoding events can now use Secure Reliable Transport (SRT) for ingest. SRT uses a passphrase and AES-128 encryption by default, although protocol negotiation can select another supported key length. Live passthrough remains limited to RTMP ingest. SRT ingest launched in all regions at no additional charge. Docs: [Advanced live streaming features](/mkio/getting-started/live-streaming-workflows/advanced-features#secure-reliable-transport-ingest) ## MP4 transition | Variable frame rate | Thumbnails | JWT **July 9, 2024** - The transition to the current MP4 output format completed in all regions. Existing MK.IO and Azure Media Services assets remained deliverable, and existing transforms required no changes. - Encoding transforms added support for variable-frame-rate input. - Standard VOD transcoding began generating one JPEG thumbnail at 50 percent of the size of the highest-resolution rendition. The release also added the `MediaKind.ThumbnailGeneratorPreset` for custom thumbnails and sprite generation. Thumbnail generation launched in all regions at no additional charge. - JSON Web Token (JWT) became the main authentication and authorization format. Docs: [Generate thumbnails](/mkio/reference/encoding-transform-presets/how-to-generate-thumbnails) | [API tokens](/mkio/how-to/managing-your-organization/api-tokens) ## Personal access tokens **July 9, 2024** MK.IO personal access tokens use the JSON Web Token (JWT) format and can authenticate API requests with a bearer authorization header. This release began the transition away from the earlier `x-mkio-token` header, which remained temporarily supported during migration. Personal access tokens launched in all regions. See [API tokens](/mkio/how-to/managing-your-organization/api-tokens) for details. ## Asset conversion presets | MPEG-1 | VC-1 ingest **June 27, 2024** - The `CopyTopBitrateInterleaved`, `CopyAllBitratesNonInterleaved`, and `CopyAllBitratesInterleaved` presets became available in all regions. They convert live-event recordings or legacy MP4 content to the current MP4 layout. At launch, processing minutes were billed at the Foundation SD rate. - Encoding transforms added MPEG-1 and VC-1 video-codec ingest. Docs: [Asset Conversion Transform](/mkio/reference/encoding-transform-presets/asset-conversion-transform) | [Encoding Transform](/mkio/reference/encoding-transform-presets/encoding-transform) ## Download streaming presets **June 13, 2024** The `Predefined_DownloadOnly` and `Predefined_DownloadAndClearStreaming` policies became available in all regions. They let a streaming locator return direct file-download URLs for workflows such as post-production, thumbnail retrieval, and subtitle retrieval. The policies had no additional feature charge at launch, but outbound traffic remained billable. Docs: [Streaming locators](/mkio/understanding/core-concepts/locators) ## Aspect ratio | Rotation preserved **May 29th, 2024** ✨ Features added\ Encoding transforms have now been updated to preserve the source aspect ratio and rotation information. Docs: [Encoding Transform](/mkio/reference/encoding-transform-presets/encoding-transform) ## Integrated CDN endpoints **May 2024** MK.IO added Content Delivery Network (CDN) enabled streaming endpoints in all regions for live and on-demand HLS CMAF and DASH delivery. The initial integrated provider was Akamai. The release also retained support for bringing an external CDN to an MK.IO origin. Integrated CDN delivery launched as a pay-as-you-go capability backed by dedicated endpoint capacity. At launch, customers needed to create a new CDN endpoint because an existing endpoint could not be converted. In May 2026, MK.IO moved integrated CDN delivery from Akamai to Fastly. See [Publish content for streaming](/mkio/how-to/content-delivery-publishing/stream-content) for current endpoint options. ## OpenID Discovery | Multiple options per DRM **May 8th, 2024** ✨ Features added\ Support OpenID Discovery for Content Key Policy with a token protection.\ It is now possible to use Multiple ContentKeyPolicyOptions with the same DRM type in Content Key Policy. Docs: [Use an OpenID to retrieve Primary Verification Key](/mkio/how-to/drm-content-protection/openid-verification-key) | [Content protection](/mkio/understanding/core-concepts/content-protection) ## Private storage links **April 22, 2024** MK.IO added private network links for Azure Storage accounts in all regions. The connection requires configuration in MK.IO and approval by the storage account owner in Azure. Requests fail until both sides are configured. At launch, the private link could not be removed from that MK.IO storage resource after it was enabled. At launch, the feature required the MK.IO 2024 plan and had a fixed monthly fee. Private-link ingress and egress traffic also incurred charges. See [Set up a private storage link](/mkio/how-to/security-access-control/private-storage-link) for details. ## ISMV and AVI ingest **March 28th, 2024** ✨ Features added\ Encoding transform can now ingest ISMV and AVI containers. Docs: [Encoding Transform](/mkio/reference/encoding-transform-presets/encoding-transform) ## New region: Central US **March 18th, 2024** ✨ New region deployed\ We are opening one new region: Central US Docs: [Cloud region support](/mkio/reference/cloud-region-support) ## Persistent licenses | External PlayReady server **February 29th, 2024** ✨ Features added\ Persistent licenses are now supported for FairPlay, Widevine and PlayReady DRMs. This enables offline playback of content.\ It is now possible to use an External PlayReady License Server when a custom streaming policy is defined. Docs: [Content protection](/mkio/understanding/core-concepts/content-protection) ## Constant Video Quality presets **February 9, 2024** Three Constant Video Quality (CVQ) presets became available for on-demand transforms in all regions: `H264MultipleBitrateSDWithCVQ`, `H264MultipleBitrate720pWithCVQ`, and `H264MultipleBitrate1080pWithCVQ`. At launch, CVQ was available in the Advanced and Premium encoding tiers. Docs: [Encoding transform](/mkio/reference/encoding-transform-presets/encoding-transform#constant-video-quality-presets) ## Asset deletion policies | Private offer **January 5th, 2024** ✨ Features added\ Asset deletion policies have been added to allow you to determine how MK.IO manages the underlying content upon the deletion of an asset.\ Private offer support has been introduced to our Azure Marketplace offer to cater specifically to high-volume users and address complex use cases. ## Bulk Asset Ingest Tool **December 15th, 2023** ✨ Features added\ MK.IO now includes a Bulk Asset Ingest Tool for migrating and managing multiple assets in one operation. ## DASH & HLS playback | Players **December 1st, 2023** ✨ Features added\ Now introducing DASH & HLS playback with support for multiple players. Choose your preferred experience with AMS Player, Shaka Player, or MKPlayer, providing enhanced flexibility and compatibility for a seamless video playback journey. ## First Quality | Asset Filters by name **November 17th, 2023** ✨ Features added\ Support for the “First Quality” setting, allowing you to set the initial playback quality level directly in the manifest, offering a customized video experience right from the beginning.\ Asset Filters now include name-based track filtering. ## ClearKey for DASH | Latency | Security | New regions **November 3rd, 2023** ✨ Features added\ ClearKey encryption support for DASH-packed content is now added. This robust addition fortifies the security of your digital assets, ensuring that content packaged in DASH format is now seamlessly compatible with ClearKey encryption.\ Enhanced end-to-end latency in live encoding, achieving a 25-second threshold; performance benchmarks required for marketing validation.\ We have further enhanced our advanced storage security measures, incorporating the latest advancements in encryption, access controls, and threat mitigation.\ We are opening two new availability regions: Japan West and Europe West. Docs: [Content protection](/mkio/understanding/core-concepts/content-protection) | [Latency](/mkio/understanding/advanced-concepts/latency) | [Cloud region support](/mkio/reference/cloud-region-support) ## DRM with client JWT entitlement **October 20th, 2023** ✨ Features added\ Expanded DRM support for client JWT entitlement management. This enhancement guarantees improved control, heightened security measures, and smoother access management for your content. Docs: [Using custom claims in content key policies](/mkio/how-to/drm-content-protection/custom-claims) ## Video Quality enhancements **October 6th, 2023** ✨ Features added\ Video quality enhancements improve PSSI and VMAF scores without changing the output bitrate. ## Asset Filters | Bug fixes **September 22nd, 2023** ✨ Features added\ MK.IO now supports Asset Filters that allow you to dynamically modify the output of your HLS and DASH manifests. You can filter tracks in the manifest based on Bitrate and FourCC, a video codec identifier. 🪲 Bugs resolved\ Resolved playback issues with DRM-protected content on the Live Events page. ## Content protection | Encoding | Live encoding **September 6th, 2023** ✨ Features added\ Content Key Policies enable you to control access to their content delivered via MK.IO. MK.IO now supports the following protection schemes: AES-128, ClearKey, and industry grade multi-DRM options like Widevine, FairPlay, and PlayReady. Access control can be managed by authorizing users based on claims in JWT tokens. Video Encoding is now available and allows you to set up encoding jobs based on preconfigured Transforms. Supported encoding codecs include H.264 and H.265 with either single bitrate or multi-bitrate configurations. Live Events functionality now includes support for live encoding, enabling you to transcode your live event into 720p or 1080p multi-bitrate HLS or DASH output. Users can select these options either through via the Create Live Event page or the /liveEvents API. Docs: [Content protection](/mkio/understanding/core-concepts/content-protection) | [Encoding Transform](/mkio/reference/encoding-transform-presets/encoding-transform) ## Multi‑bitrate RTMP | Live streaming | Bug fixes **August 4th, 2023** ✨ Features added\ MK.IO now accepts multi-bitrate RTMP input for live passthrough events. MK.IO exposes each input bitrate in the HLS and DASH output. MK Player then selects a bitrate based on the viewer's playback conditions. Live Streaming is now available. Transcode your RTMP input stream into multiple HLS and DASH output bitrates. Foundation level outputs up to 720p, while the Advanced level provides up to 1080p output. 🪲 Bugs resolved\ A bug that resulted in streaming endpoints not starting due to malformed labels has been resolved. # Frequently asked questions Find the right starting point for common MK.IO setup, playback, account, and automation questions. The portal guides focus on the user interface, while the Application Programming Interface (API) Guides cover automated workflows. ## Onboarding **Where should I start with MK.IO?** Start with [What is MK.IO?](/mkio/getting-started/what-is-mkio) if you want to understand the platform and its resources. To validate a live workflow, follow [Live stream in five minutes](/mkio/getting-started/live-stream-in-five-minutes). For Video on Demand (VOD) processing, follow [Publish your first VOD asset](/mkio/getting-started/video-on-demand-vod-workflows). **Should I start with live or on-demand video?** Choose live streaming when an encoder sends a continuous source to MK.IO. Choose Video on Demand (VOD) when your video already exists as a file or when you want to publish a completed live recording. [What is MK.IO?](/mkio/getting-started/what-is-mkio#choose-live-or-on-demand-video) compares both workflows. **What do I need for my first workflow?** You need an activated MK.IO account, a project, and connected cloud storage. A live workflow also needs a prepared source encoder. Start with [Set up your MK.IO account](/mkio/getting-started/account-setup-and-first-steps) and [Connect cloud storage](/mkio/getting-started/connect-cloud-storage). **How do I navigate the portal?** [Navigate the MK.IO portal](/mkio/getting-started/platform-navigation-and-key-features) maps the **Organize**, **Create**, and **Deliver** groups to the relevant guides. Transforms and jobs are both under **Video Processing**. **Can I migrate from Azure Media Services?** Yes. Start with [Migrate from Azure Media Services](/mkio/how-to/migrate-from-azure-media-services) for the migration path and links to asset, playback, and organization guidance. ## Storage and assets **Why does MK.IO need my cloud storage?** MK.IO uses connected cloud storage for source files, processing outputs, and live recordings. The media files remain in storage that you control. [Connect cloud storage](/mkio/getting-started/connect-cloud-storage) explains the portal setup. **Which storage providers can I connect?** The portal guide covers Amazon S3 and Azure Blob Storage. The Media API also defines Google Cloud Storage registration through `Google.Storage`. See [Connect cloud storage](/mkio/getting-started/connect-cloud-storage) and the [Storage API Guide](/mkio/api-guides/how-to/media/storage). **Does MK.IO copy my existing media?** An MK.IO asset is a logical pointer to a location in your cloud storage. Read [Assets and asset filters](/mkio/understanding/core-concepts/assets) before referencing existing content or choosing deletion behavior. **Can deleting an asset delete its files?** Yes, depending on the deletion behavior selected when the asset was created. Check the asset setting before deletion because MK.IO may also delete the associated files from cloud storage. See [Assets and asset filters](/mkio/understanding/core-concepts/assets#what-is-an-asset). ## Playback and delivery **Why do I need an endpoint and locator?** A streaming endpoint supplies the delivery hostname. A streaming locator publishes a specific asset under a streaming policy and supplies its playback path. MK.IO combines them into the playback URL. See [Publish content for streaming](/mkio/how-to/content-delivery-publishing/stream-content). **Why is my asset not playing?** Confirm that the asset has playable content, its streaming locator is applied, and the selected streaming endpoint is running. MK.IO displays the HTTP Live Streaming (HLS) and Dynamic Adaptive Streaming over HTTP (DASH) paths after these resources are in place. Use [Publish content for streaming](/mkio/how-to/content-delivery-publishing/stream-content) to check the complete setup. **What does a content delivery network do?** A Content Delivery Network (CDN) caches content across distributed servers so viewers can retrieve it from a closer location. MK.IO supports CDN endpoints and external CDN configurations. Start with [Streaming endpoints](/mkio/understanding/core-concepts/endpoints) and [Streaming endpoints and playback](/mkio/how-to/content-delivery-publishing). ## Workflows and APIs **How do transforms and jobs relate?** A transform defines a reusable processing task. A job applies that transform to an input and produces an output asset. See [Transforms and jobs](/mkio/understanding/core-concepts/transforms-and-jobs), [Video processing](/mkio/how-to/video-processing-encoding), or the [Transforms and jobs API Guide](/mkio/api-guides/how-to/media/transforms-and-jobs). **Can I use both the portal and APIs?** Yes. Use the portal guides for MK.IO user interface workflows and the API Guides for automation. The guides link between both approaches where the same resources are available. Start with [Choose an API](/mkio/api-guides/getting-started/which-api). **How do I automate MK.IO workflows?** Use the [API Guides](/mkio/api-guides) for task-based automation guidance and the [API Reference](/api-reference/media-api) for endpoint and schema details. Start with [Choose an API](/mkio/api-guides/getting-started/which-api) and [API authentication](/mkio/api-guides/getting-started/authentication). **How do I create an API token?** Create personal, service, or restricted access tokens from the organization settings. See [Create API tokens](/mkio/how-to/managing-your-organization/api-tokens) and the [Token API Guide](/mkio/api-guides/how-to/management/tokens). **Does MK.IO provide a player?** Yes. Use the [MK Player Software Development Kit (SDK)](/mkio/reference/player-sdk) for setup, playback, events, subtitles, and Digital Rights Management (DRM). Use [Player customization](/mkio/reference/player-customization) to configure the player interface. **How do I protect content?** Start with [Content protection concepts](/mkio/understanding/core-concepts/content-protection), then choose a guide under [Content key policies](/mkio/how-to/drm-content-protection). The [Content protection API Guide](/mkio/api-guides/how-to/media/content-protection) covers API-based workflows. **How do I know a resource is ready?** MK.IO resources move through provisioning and runtime states. For example, a live event reaches `Running`, while an asset reaches `Ready`. Use [Resource states](/mkio/reference/resource-states) to interpret the values shown by MK.IO and returned by the APIs. ## Accounts and billing **Can I subscribe through a marketplace?** MK.IO supports subscriptions through Azure Marketplace and Amazon Web Services (AWS) Marketplace. See [Set up your MK.IO account](/mkio/getting-started/account-setup-and-first-steps) for Azure and [Subscribe through AWS Marketplace](/mkio/how-to/managing-your-organization/subscribe-through-aws-marketplace) for AWS. **Where can I review usage and pricing?** Use [Billing and usage](/mkio/how-to/managing-your-organization/billing) to review organization usage. Check the [MK.IO pricing page](https://mediakind.com/mkio/pricing/) for current rates, and stop resources when a guide tells you they continue to incur charges. **Which resources should I stop after testing?** Stop live events and streaming endpoints when you no longer need them because both incur charges while running. The live quickstart includes a [cleanup checklist](/mkio/getting-started/live-stream-in-five-minutes#stop-the-test-resources). **How do I manage users and access?** MK.IO uses organizations, projects, users, and teams to control access. See [Organizations and teams](/mkio/understanding/fundamentals/orgsandteams) and [Manage users and teams](/mkio/how-to/managing-your-organization/access-users-and-teams). ## Support and availability **Where can I get technical support?** Use the [MK.IO support portal](https://support.mk.io) for technical assistance and documentation questions. **Where can I find availability information?** Review [Platform availability](/mkio/reference/platform-availability) and the [MK.IO service-level agreement](https://www.mediakind.com/pdf/legal/MKIO-Service-Level-Agreement_Rev.24_05.pdf). # Get started with MK.IO Choose the workflow that matches your first goal. Each path takes you through a complete result and links to deeper guides when you need more control. If MK.IO is new to you, start with [What is MK.IO?](/mkio/getting-started/what-is-mkio) for a short explanation of live and Video on Demand (VOD) workflows. Use the MK.IO portal for guided setup. Use the APIs when you need to automate the same resources. ## Choose your first workflow [What is MK.IO?](/mkio/getting-started/what-is-mkio) Understand the platform, its main workflows, and the resources that connect them. [Live stream in five minutes](/mkio/getting-started/live-stream-in-five-minutes) Send a Real-Time Messaging Protocol (RTMP) source to MK.IO and open the generated playback URL. [Publish your first VOD asset](/mkio/getting-started/video-on-demand-vod-workflows) Upload a video, process it with a transform, and publish the output. [Choose the right API](/mkio/api-guides/getting-started/which-api) Find the API for media, management, fleet, or infrastructure work. ## Prepare your account Complete these setup tasks before a live or VOD workflow requires them: 1. [Set up your account and first project](/mkio/getting-started/account-setup-and-first-steps). 2. [Connect cloud storage](/mkio/getting-started/connect-cloud-storage) for assets, outputs, and recordings. 3. [Learn the MK.IO portal navigation](/mkio/getting-started/platform-navigation-and-key-features). If your account and storage are already ready, start with one of the workflows above. ## Continue after onboarding - [Browse MK.IO guides](/mkio/how-to/overview) for portal tasks. - [Understand MK.IO concepts](/mkio/understanding/overview-understanding) for the resource model. - [Make your first API call](/mkio/api-guides/getting-started/first-api-call) to verify API access. - [Use the Media API](/mkio/api-guides/how-to/media) for automated media workflows. - [Open the API Reference](/api-reference) for endpoint and schema lookup. ## Video overview # Set up your MK.IO account Activate a marketplace or direct-sales subscription before you create media resources. After activation, sign in to MK.IO and create a project for your workflows. ## Choose a subscription path MK.IO supports Azure Marketplace, Amazon Web Services (AWS) Marketplace, and direct-sales payment methods. Use the path that matches your agreement with MediaKind. Marketplace subscriptions have no upfront activation cost. Billing begins when you use chargeable MK.IO services. ### Azure Marketplace 1. Open MK.IO in Azure Marketplace and select **Get it now**. 2. Complete your profile information and allow Microsoft to share the required account information with MediaKind. 3. Configure the subscription: - Select the MK.IO plan and choose **Subscribe**. - Select an Azure subscription and resource group. - Enter a name for the MK.IO subscription under **SaaS details**. - Select **Review + subscribe** and review the terms. 4. Confirm your contact details and select **Subscribe**. 5. When **Configure your account** becomes available, select it to complete activation in MK.IO. If MediaKind issued a private offer, follow [Accept an Azure Marketplace private offer](/mkio/how-to/managing-your-organization/accept-an-azure-marketplace-private-offer).

Keep marketplace auto-renewal enabled if the MK.IO subscription should remain active beyond its current term.

### AWS Marketplace Use [Subscribe through AWS Marketplace](/mkio/how-to/managing-your-organization/subscribe-through-aws-marketplace) to purchase the subscription, activate it in MK.IO, and create an AWS-based project. ### Direct sales If your organization has a direct agreement with MediaKind, use the redemption link provided for that agreement. Direct agreements can include volume pricing and professional services. 1. Open the redemption link and sign in to MK.IO. 2. If you do not have an account, select **Create an account** and use Microsoft authentication or email. 3. Enter the requested organization details when creating an email-based account. 4. Review the terms and redeem the purchase. 5. Create a project and select the required cloud region. If you belong to more than one organization, select the intended organization before redeeming the purchase. ## Sign in to MK.IO 1. Go to [mk.io](https://mk.io) and select **Sign in**. 2. Use the authentication method associated with your account. 3. Select an organization and project in the portal. See [Navigate the MK.IO portal](/mkio/getting-started/platform-navigation-and-key-features) for a map of the portal areas and their documentation. ## Create a project A project contains the media resources for a workflow. Each project uses a selected cloud provider and region. Creating a project does not incur a charge. You cannot change the project's cloud provider or region after creation, so confirm both selections before you continue. 1. Open [Projects Overview](https://app.mk.io/settings/overview/projects). 2. Select **Create new**. 3. Select the cloud provider, region, project name, and payment method. 4. Select **Create**. After creating the project, [connect cloud storage](/mkio/getting-started/connect-cloud-storage). You can manage project access from [Access Management](https://app.mk.io/settings/accessManagement/teams). ## Video walkthrough # Connect cloud storage MK.IO uses your own cloud storage to hold media assets. Before you can upload, transform, or publish content, connect at least one storage account. This portal guide covers Amazon S3 and Azure Blob Storage. For automated storage configuration, MK.IO provides an application programming interface (API) called the Media API. It also defines Google Cloud Storage registration through `Google.Storage`. See the [Storage API Guide](/mkio/api-guides/how-to/media/storage). ### Amazon S3 ### Prerequisites You need an Amazon Web Services (AWS) account with permissions to create Identity and Access Management (IAM) users and manage Amazon S3 buckets. ### Step 1: Create an S3 bucket If you do not already have an S3 bucket for MK.IO to use: 1. Go to the [AWS Console](https://console.aws.amazon.com) and open **S3**. 2. Select **Create bucket**. 3. Choose a bucket name and select the AWS region closest to your MK.IO project region. MK.IO automatically detects the bucket region, so you do not enter a region in MK.IO. 4. Leave **Block Public Access** settings enabled (MK.IO accesses the bucket using credentials, not public URLs). 5. Select **Create bucket**.

MK.IO detects your bucket's region automatically from the bucket name. There is no region field to fill in when connecting S3 storage.

### Step 2: Create an IAM user with S3 permissions MK.IO accesses your S3 bucket using an IAM access key. Create a dedicated IAM user with the minimum required permissions. #### Create the IAM user 1. Open **IAM** in the AWS Console. 2. Go to **Users** and click **Create user**. 3. Enter a username (for example, `mkio-storage`) and select **Next**. 4. Select **Attach policies directly**, then select **Create policy**. 5. Switch to the **JSON** editor and paste the following policy, replacing `your-bucket-name` with your actual bucket name: ```json { "Version": "2012-10-17", "Statement": [ { "Effect": "Allow", "Action": [ "s3:GetObject", "s3:PutObject", "s3:DeleteObject", "s3:ListBucket" ], "Resource": [ "arn:aws:s3:::your-bucket-name", "arn:aws:s3:::your-bucket-name/*" ] } ] } ``` 6. Name the policy (for example, `mkio-s3-access`) and select **Create policy**. 7. Return to the user creation tab, refresh the policy list, select your new policy, and complete the user creation. #### Create access keys 1. Open your newly created IAM user. 2. Go to the **Security credentials** tab. 3. Under **Access keys**, click **Create access key**. 4. Choose **Application running outside AWS** as the use case. 5. Select **Create access key**. 6. Copy the **Access key ID** and **Secret access key** and store them securely. AWS does not show the secret access key again after this screen. ### Step 3: Add the S3 bucket in MK.IO 1. Go to [app.mk.io](https://app.mk.io) and open your project. 2. Select **Storage** from the left navigation. 3. Select **Add Storage**. 4. Fill in the required fields: - **Storage account name**: A display name for this connection (for example, `my-s3-bucket`). - **Description**: Optional. - **Bucket name**: The exact name of your S3 bucket. - **Access key ID**: The access key ID you copied in Step 2. - **Secret access key**: The secret access key you copied in Step 2. 5. Select **Submit**. MK.IO connects to the bucket and the storage account appears in your storage list. ### Troubleshooting **Error: "Access Denied: Invalid AWS credentials" or "Error getting region for bucket"** This error means MK.IO cannot authenticate with your AWS credentials. There is no region field in MK.IO because the region is detected automatically from the bucket. If you see this error: - Verify that the **Access key ID** and **Secret access key** are correct and have not been regenerated since you copied them. - Confirm that the IAM user or role associated with these credentials has the `s3:GetObject`, `s3:PutObject`, `s3:DeleteObject`, and `s3:ListBucket` permissions on the bucket. - Check that the bucket name you entered in MK.IO is spelled exactly as it appears in AWS, including the case. - If the credentials belong to an IAM role rather than a user, confirm that the role's trust policy allows the credentials to be used from outside AWS. **Error: "Bucket does not exist"** Confirm the bucket name and that the bucket exists in your AWS account. Bucket names are globally unique. If the name exists but belongs to a different AWS account, you receive this error. ### Azure Blob Storage ### Prerequisites You need an Azure account with permissions to manage storage accounts and create Shared Access Signatures (SAS tokens). ### Step 1: Locate your storage account 1. Go to the [Azure Portal](https://portal.azure.com). 2. Open **Storage accounts** and select the storage account you want to connect to MK.IO.

Your Azure Storage account should be in the same region as your MK.IO project to avoid data egress costs.

### Step 2: Generate a SAS token A Shared Access Signature (SAS) token grants MK.IO time-limited, permission-scoped access to your storage account without sharing your account keys. #### Open the SAS configuration 1. In your storage account, go to **Security + networking** > **Shared access signature**. #### Configure the SAS token permissions Set the following options: - **Allowed services**: Check **Blob** only. - **Allowed resource types**: Check **Container** and **Object**. - **Allowed permissions**: Check **Read**, **Write**, **Delete**, **List**, **Add**, and **Create**. - **Start and expiry date/time**: Set an expiry date appropriate for your use. MK.IO will lose access to the storage account when the token expires. #### Generate and copy the SAS token 1. Select **Generate SAS and connection string**. 2. Copy the **Blob service SAS URL**. It looks like this: ```text https://.blob.core.windows.net/?sv=2022-11-02&ss=b&srt=co&sp=rwdlac&se=2026-12-31T00:00:00Z&spr=https&sig= ``` 3. Split this URL into two parts for use in MK.IO: - **URL**: Everything up to and including `.blob.core.windows.net`. Do not include a trailing slash: ```text https://.blob.core.windows.net ``` - **SAS token**: The query string beginning with `?`: ```text ?sv=2022-11-02&ss=b&srt=co&sp=rwdlac&se=2026-12-31T00:00:00Z&spr=https&sig= ``` ### Step 3: Add the storage account in MK.IO 1. Go to [app.mk.io](https://app.mk.io) and open your project. 2. Select **Storage** from the left navigation. 3. Select **Add Storage**. 4. Fill in the required fields: - **Storage account name**: A display name for this connection. - **Description**: Optional. - **URL**: The base blob endpoint without a trailing slash (for example, `https://mystorageaccount.blob.core.windows.net`). - **SAS token**: The query string beginning with `?`. 5. Select **Submit**. MK.IO validates the credentials and the storage account appears in your storage list. ### Troubleshooting **Error on submit: "Invalid URL" or validation failure** - Confirm the **URL** field does not have a trailing slash. The URL must end with `.blob.core.windows.net`. - Confirm the **SAS token** field begins with `?`. Do not include the base URL in the SAS token field. **Storage account connects but MK.IO cannot read or write files** - Check that the SAS token includes **Container** and **Object** under allowed resource types. A token scoped to Object only cannot list containers. - Check that the SAS token has not expired. Generate a new token with a future expiry and update the connection in MK.IO. - Confirm the **Allowed permissions** include Read, Write, Delete, List, Add, and Create. Missing permissions cause specific operations to fail without a clear error. **Egress costs are unexpectedly high** Your Azure Storage account and MK.IO project are likely in different regions. Data transferred between regions incurs egress charges. Create a storage account in the same Azure region as your MK.IO project. # Live stream in five minutes This guide uses **Live Events**. For the **Live** interface, including reusable sources and multiview, start with [Live and multiview](/mkio/how-to/live-streaming/live). In this guide we will send a live video source via OBS to MK.IO and play it through the built-in player. This path uses Real-Time Messaging Protocol (RTMP) and the MK.IO portal, so you can see how the main live resources fit together before exploring advanced options. The five-minute workflow begins after your account, storage, and source encoder are ready. ## What you will create Your source passes through four parts of MK.IO before you can watch it: 1. A **live event** receives and encodes the RTMP source. 2. A **streaming endpoint** supplies the delivery hostname. 3. A **streaming locator** applies a streaming policy and provides the playback path. 4. The built-in player opens the completed playback URL. The live event also records the stream to an asset in your connected cloud storage. ## Prerequisites You need: - An [MK.IO account](/mkio/getting-started/account-setup-and-first-steps) and an [MK.IO project](https://app.mk.io/settings/overview/projects). - [Connected cloud storage](/mkio/getting-started/connect-cloud-storage) for the live recording. - OBS Studio or another encoder with a video and audio source ready to send. If you still need to prepare OBS, follow [Stream with OBS Studio](/mkio/how-to/live-streaming/set-up-the-source-stream-using-obs), then return here.
Resources incur charges while running

Live events and streaming endpoints continue to incur charges while they are running. The final section shows which resources to stop after your test.

## Create your first stream ### Create the live event The live event receives your source and produces the encoded stream. The 720p encoding option gives this first workflow an adaptive output without requiring the source encoder to produce every output quality. 1. In the MK.IO portal, open **Live Events** from the left sidebar. 2. Select **+ Create Live Event** in the top right. 3. Enter a name for the event. 4. Select **Live Encoding (720p)** as the event type. 5. Select **RTMP** as the input protocol. 6. Select the storage account for the recording. 7. Select **Review**, then **Submit**. ![create a live event.](/images/mkio/create-live-event.png) For passthrough, Secure Reliable Transport (SRT), transcription, and archive settings, use [Configure a live event](/mkio/how-to/live-streaming/set-up-a-live-streaming-event). ### Start a streaming endpoint A streaming endpoint is the origin service that delivers your content. You can reuse an existing running endpoint or, if the project does not have one, create it now: 1. Open **Streaming Endpoints**. 2. Select **+ Create Streaming Endpoint**. 3. Enter a name and base URL. 4. Select **Shared** for this first stream. 5. Create and start the endpoint. ![start a streaming endpoint image.](/images/mkio/mkio-live-quickstart-endpoint.png)

The endpoint must be running before it can deliver the stream. Select Start streaming endpoint after creation to start the endpoint immediatly, or alternatively you can go to the Streaming Endpoints page at anytime to start, stop, and manage your Streaming Endpoints

### Add the streaming locator A streaming locator publishes the live recording under a streaming policy. Return to your previously created Live Event and create the locator: 1. In the left sidebar select **Live Events**, then select your previously created **Live Event**. 2. Under **Streaming Locator**, select **+ Add streaming locator**. 3. Enter a unique name. 4. Select `Predefined_ClearStreamingOnly` as the streaming policy. 5. Leave the content key policy, expiration, and filters empty. 6. Select **Add**. 7. Select **Apply**

Its important to Apply the streaming locator once created, otherwise the Live Event cannot publish the stream!

![Create streaming locator.](/images/mkio/create-streaming-locator.png) `Predefined_ClearStreamingOnly` creates unprotected playback paths for this test. The locator supplies the path, while the endpoint supplies the hostname. [Publish content for streaming](/mkio/how-to/content-delivery-publishing/stream-content) explains both resources and the available protection options. ### Send the source to MK.IO (OBS) Now its time to start the live event! Once your Live event has started, MK.IO will provide the input address that tells OBS where to send the stream. 1. **Start the live event** in MK.IO. 2. Copy the **Input URL**. 3. In OBS, open **Settings** > **Stream**. 4. Set **Service** to **Custom**. 5. Enter the Input URL without the `/stream` suffix as the **Server**. 6. Enter `stream` as the **Stream Key**. 7. Select **Start Streaming** in OBS. 8. When MK.IO receives the input, apply the streaming locator. The `/stream` suffix becomes the OBS stream key, which is why you remove it from the server address. When MK.IO receives the source, it generates HTTP Live Streaming (HLS) and Dynamic Adaptive Streaming over HTTP (DASH) playback URLs. ### FFmpeg Alternatively, if you would prefer to send a stream using a local FFmpeg command in the terminal, you can do so by copying the "Example FFmpeg command" within the live event view. This command has the current live event input URL preflled for you: just copy, paste, and run in your terminal window: ![Create streaming locator.](/images/mkio/exampleffmpeg.png) You can then see via your terminal window: 1. The Ingest URL 2. The current bitrate and 3. the elapsed time of the stream. Amongst a lot of other information! This can be usefull for simple monitoring and latency testing on systems where you either do not have OBS installed, or want to quickly test a stream. ### Watch the stream Once the live event shows that it is receiving your source, you are ready to watch the stream! You can use the built-in player for this first test, or copy a playback URL if you want to test the stream in another player. 1. Open **Live Events** and select the live event you created. 2. Confirm that the event shows the incoming stream from OBS or FFmpeg. 3. Open the built-in player and start playback. 4. Check that you can see the video and hear the audio. If you want to test playback outside the MK.IO portal, copy one of the generated HTTP Live Streaming (HLS) or Dynamic Adaptive Streaming over HTTP (DASH) URLs. Use the URL with a compatible external player or application. If the player does not show video or audio, check the workflow in this order: - Make sure OBS or FFmpeg is still sending the source. - Confirm that the live event shows the incoming stream. - Confirm that the streaming endpoint is running. - Confirm that the streaming locator was created for the live event. ![confirmplayback.](/images/mkio/confirmplayback.png) When video and audio play, your first MK.IO live workflow is complete! The same locator paths can be used in a compatible external player or application. ## Stop the test resources 1. Stop streaming in OBS/FFmpeg. 2. Stop the live event in MK.IO. 3. Stop the streaming endpoint if it is no longer needed. The live recording remains in the selected storage account as an asset. You can process or publish that asset as Video on Demand (VOD) content after the event ends. ## Your first live stream is complete Well done! You have now created a live event, sent a source to MK.IO, published it through a streaming endpoint and locator, and watched the result in the built-in player. ## Continue with live streaming - [Explore the complete live workflow](/mkio/getting-started/live-streaming-workflows). - [Configure advanced live features](/mkio/getting-started/live-streaming-workflows/advanced-features). - [Build the workflow with the Media API](/mkio/api-guides/how-to/media/live-streaming). # Live streaming workflows An MK.IO live workflow receives a continuous source, processes or passes through the signal, records it to an asset, and publishes it for playback. Use this page to choose the guide for each part of that workflow. ## Start with the shortest path For the **Live** interface, follow [Create an SRT source](/mkio/how-to/live-streaming/live/create-a-live-source), then [Create a live event](/mkio/how-to/live-streaming/live/create-a-live-event). For several sources in one picture, use [Create a multiview live event](/mkio/how-to/live-streaming/live/create-a-multiview-live-event). The **Live Events** workflow below uses the Media API resource model. [Live stream in five minutes](/mkio/getting-started/live-stream-in-five-minutes) takes you from a Real-Time Messaging Protocol (RTMP) source to a playback URL. Use it for a first test with OBS Studio or another prepared encoder. ## Build a live workflow ### Live workflow 1. [Configure the live event](/mkio/how-to/live-streaming/set-up-a-live-streaming-event) 2. [Connect the source](/mkio/how-to/live-streaming/set-up-the-source-stream-using-obs) 3. [Publish the stream](/mkio/how-to/content-delivery-publishing/stream-content) 4. [Monitor the services](/mkio/how-to/monitor-your-services) ### Configure the event [Configure a live event](/mkio/how-to/live-streaming/set-up-a-live-streaming-event) explains live encoding and passthrough modes, RTMP, Real-Time Messaging Protocol Secure (RTMPS), Secure Reliable Transport (SRT), archive settings, and optional transcription. ### Connect the source Choose the source software you use: - [OBS Studio](/mkio/how-to/live-streaming/set-up-the-source-stream-using-obs) - [FFmpeg](/mkio/how-to/live-streaming/set-up-the-source-stream-using-ffmpeg) - [GStreamer](/mkio/how-to/live-streaming/set-up-the-source-stream-using-gstreamer) ### Publish and monitor [Publish content for streaming](/mkio/how-to/content-delivery-publishing/stream-content) explains streaming endpoints, locators, and playback URLs. [Monitor your services](/mkio/how-to/monitor-your-services) covers operational metrics for live events and streaming endpoints. ### Use the recording MK.IO writes the live output to an asset in the selected storage account. After the event stops, you can process and publish that asset through the same guides used for Video on Demand (VOD): - [Configure VOD transforms](/mkio/how-to/video-processing-encoding/configure-transformations) - [Run VOD processing jobs](/mkio/how-to/video-processing-encoding/run-vod-transcode-jobs) - [Publish content for streaming](/mkio/how-to/content-delivery-publishing/stream-content) ## Advanced live workflows - [Advanced live streaming features](/mkio/getting-started/live-streaming-workflows/advanced-features) - [Extended archive window](/mkio/how-to/live-streaming/extended-archive-window) - Automate the workflow through an application programming interface (API) with the [Live streaming API Guide](/mkio/api-guides/how-to/media/live-streaming). # Advanced live streaming features This guide uses **Live Events**. For the **Live** interface, including reusable sources and multiview, start with [Live and multiview](/mkio/how-to/live-streaming/live). These capabilities extend the core live streaming workflow. All advanced features require the **Live Encoding** event type unless noted otherwise. ## Automatic live transcription MK.IO can generate real-time subtitles as your stream runs using Azure Cognitive Services. Transcribed captions appear as a selectable subtitle track in compatible players. This workflow uses the **Artificial Intelligence (AI) Pipeline** setting on the live event. **To enable:** 1. When creating the live event, select **Live Encoding** as the event type. 2. In **Advanced settings**, set **AI Pipeline** to `Predefined_ACSLiveTranscription`. 3. Set **Language** to the BCP-47 language code of the source audio (for example, `en-US` for US English, `fr-FR` for French, `de-DE` for German). Only one source language can be transcribed per live event. For source language guidance, see [Transcription transform](/mkio/reference/encoding-transform-presets/audio-speech-transcription#source-language).

Live transcription is billed as an additional service. See MK.IO pricing for details.

## Secure Reliable Transport ingest Secure Reliable Transport (SRT) is an open-source protocol designed for reliable streaming over unpredictable networks. Compared to Real-Time Messaging Protocol (RTMP), SRT: - Recovers from packet loss without visible artefacts - Works over high-latency or congested connections - Provides encrypted transport by default - Is increasingly used in professional broadcast workflows SRT connections use a passphrase. MK.IO uses AES-128 encryption by default, although protocol negotiation can select another supported key length. **To use SRT:** 1. When creating the live event, select **Live Encoding** as the event type. SRT is not available with passthrough mode. 2. In **Input Settings**, set **Input protocol** to **SRT**. 3. After the event starts, use the SRT input URL shown on the live event page as the destination in your encoder (for example, in FFmpeg or a hardware encoder that supports SRT). ## Extended archive window By default, the archive window determines how much of the live stream is available for time-shifted playback and how long the recording is retained before the event is stopped. - Minimum: 1 minute - Maximum: 30 days - When the archive window exceeds 25 hours, the player manifest presents a rolling 25-hour window of the most recent content. The full recording is still stored in your cloud storage. For details on accessing long recordings and time-based playback, see [Extended archive window](/mkio/how-to/live-streaming/extended-archive-window). ## Low-latency streaming MK.IO supports reduced-latency delivery for scenarios where real-time viewer interaction matters. Examples include live auctions, sports betting, and interactive broadcasts where a few seconds of delay changes the viewer experience. Contact the [MK.IO sales team](https://mediakind.com/contact/) for access and configuration details. ## Artificial intelligence for recordings After stopping a live event, the recording becomes a standard Video on Demand (VOD) asset. You can then apply AI transforms to the recorded content: - **Transcription and translation**: Generate subtitle files in multiple languages from the recorded audio. See [VOD transcription and translation](/mkio/how-to/ai-features/vod-transcription-and-translation-transforms). - **Dubbing**: Replace the audio track with AI-generated dubbed audio in another language. See [VOD dubbing](/mkio/how-to/ai-features/multi-language-vod-dubbing). # Navigate the MK.IO portal Use the portal navigation to find the resources for a workflow. The main groups follow the sequence from organizing source media to creating and delivering video. ## Select an organization and project If you belong to more than one organization, use the organization selector in the top-right corner to switch between them. Select a project to work with its storage, assets, processing resources, and delivery resources. ## Organize media The **Organize** group contains the resources that connect MK.IO to your media. - **Assets**: Add media from connected storage, upload files, and manage asset filters. See [Assets and storage](/mkio/how-to/content-management). - **Storage**: Connect the cloud storage that holds your media. The portal workflow covers Amazon S3 and Azure Blob Storage. See [Connect cloud storage](/mkio/getting-started/connect-cloud-storage). For automated storage configuration, MK.IO provides an application programming interface (API) called the Media API. It also defines Google Cloud Storage registration through `Google.Storage`. See the [Storage API Guide](/mkio/api-guides/how-to/media/storage). ## Create video workflows The **Create** group contains live and file-based processing resources. - **Live**: Create reusable sources, live events, and multiview streams. Start with [Live and multiview](/mkio/how-to/live-streaming/live). - **Live Events**: Configure a live event, connect an input, and create live outputs. See [Live events](/mkio/how-to/live-streaming). - **Video Processing**: Configure reusable transforms and submit jobs that apply them to input content. See [Video processing](/mkio/how-to/video-processing-encoding). Transforms and jobs appear together under **Video Processing** because a job runs a selected transform against an input. ## Deliver and protect content The **Deliver** group contains the resources used to publish and play media. - **Content Key Policies**: Configure encryption, Digital Rights Management (DRM), and playback authorization. See [Content key policies](/mkio/how-to/drm-content-protection). - **Streaming Endpoints**: Run the origin service that packages and delivers live or on-demand content. See [Streaming endpoints and playback](/mkio/how-to/content-delivery-publishing). - **MKPlayer**: Test playback and integrate the web player. See the [MK Player Software Development Kit (SDK)](/mkio/reference/player-sdk). ## Monitor and administer MK.IO Use the operational and organization areas for tasks that span individual media workflows. - **Usage & Metrics**: Publish service metrics for monitoring. See [Monitor MK.IO services](/mkio/how-to/monitor-your-services). - **Organization Settings**: Manage users, teams, API tokens, webhooks, billing, and marketplace subscriptions. See [Organization settings](/mkio/how-to/managing-your-organization). - **Devices**: Onboard and manage devices connected to MK.IO. See [Edge devices](/mkio/how-to/managing-edge-devices). ## Work with the APIs Use the [API Guides](/mkio/api-guides) when you need to automate a portal workflow. The [Live API Guide](/mkio/api-guides/how-to/live) covers template-based live processing and multiview. The [Media API Guide](/mkio/api-guides/how-to/media) covers sources, assets, publishing, and Media API live events, while the [Management API Guide](/mkio/api-guides/how-to/management) covers organizations, access, tokens, billing, and webhooks. Generate credentials from **Organization Settings** > **API Tokens** before making an API request. See [Create API tokens](/mkio/how-to/managing-your-organization/api-tokens) and [API authentication](/mkio/api-guides/getting-started/authentication). ## Video walkthrough # Publish your first VOD asset Follow the standard Video on Demand (VOD) workflow from source video to playback URL. Each stage links to the canonical guide that explains the portal fields and alternatives. ## Prerequisites You need: - An [MK.IO account and project](/mkio/getting-started/account-setup-and-first-steps). - A [connected cloud storage account](/mkio/getting-started/connect-cloud-storage). - A source video file. ## Add the source asset Choose how MK.IO should access the source content: - [Upload files from your device](/mkio/how-to/content-management/add-an-asset-in-mkio/import-files-from-your-device). - [Reference existing cloud storage content](/mkio/how-to/content-management/add-an-asset-in-mkio/reference-existing-storage). - [Import Azure Media Services assets](/mkio/how-to/content-management/add-an-asset-in-mkio/import-your-ams-assets). After the asset appears in MK.IO, [verify its files and tracks](/mkio/how-to/content-management/verify-your-assets-in-mkio) before processing it. ## Configure the transform A transform is a reusable processing configuration. [Configure VOD transforms](/mkio/how-to/video-processing-encoding/configure-transformations) explains the transform types available in the portal and how to create one from a built-in preset. For a first adaptive bitrate output, the existing guide uses an encoding transform with the **H.264 Multiple Bitrate 1080p** built-in preset. ## Run the processing job A job applies the transform to the source asset and writes the result to an output asset. Follow [Run VOD processing jobs](/mkio/how-to/video-processing-encoding/run-vod-transcode-jobs) to select the transform, source asset, output storage, and priority. Wait for the job to reach the `Finished` state, then open and verify the output asset. ## Publish the output asset [Publish content for streaming](/mkio/how-to/content-delivery-publishing/stream-content) takes you through the two resources required for playback: 1. A running streaming endpoint that supplies the delivery hostname. 2. A streaming locator that publishes the output asset under a streaming policy. After both resources are applied, MK.IO displays HTTP Live Streaming (HLS) and Dynamic Adaptive Streaming over HTTP (DASH) playback URLs on the asset. ## Verify playback 1. Open the output asset. 2. Confirm that the streaming endpoint is running and the locator is applied. 3. Play the asset in the built-in MKPlayer. 4. Open **Show all URLs** if you need the HLS, DASH, or download paths allowed by the streaming policy. ## Automate the workflow [Automate a VOD pipeline](/mkio/api-guides/how-to/media/vod-pipeline) follows the same asset, transform, job, locator, and endpoint sequence through an application programming interface (API), using the Media API. # What is MK.IO? MK.IO is a cloud-native Software as a Service (SaaS) platform for processing, protecting, and delivering live and on-demand video. You can work through guided workflows in the MK.IO portal or automate its resources through the MK.IO APIs. ## Choose live or on-demand video MK.IO supports two main media workflows. The right starting point depends on whether your video is arriving continuously or already exists as a file. [Live video](/mkio/getting-started/live-stream-in-five-minutes) Send a continuous stream from an encoder to MK.IO, process or pass through the signal, and publish it for playback. [Video on Demand](/mkio/getting-started/video-on-demand-vod-workflows) Add an existing video file, process it when needed, and publish it so viewers can play it on demand. **Video on Demand (VOD)** describes video that viewers can start when they choose, rather than a stream tied to a live source. Live recordings can also become VOD assets after an event ends. **Live workflows** include scheduled events, interviews, continuous channels, and prerecorded content sent as a live source. When MK.IO creates **adaptive bitrate (ABR)** output, it produces several quality levels so a compatible player can select the rendition that suits the viewer's connection and device. ## Understand the resource model MK.IO combines a small set of resources into complete media workflows:
Resource Role in a workflow
Project Contains the storage, media, processing, and delivery resources for a workload.
Storage account Connects MK.IO to the cloud storage that holds source files, outputs, and live recordings.
Asset References a set of files in connected cloud storage.
Transform Defines a reusable processing task for file-based content.
Job Applies a transform to an input and writes the result to an output asset.
Live event Receives a continuous input for passthrough or encoding.
Streaming locator Associates an asset with a streaming policy and provides the path used for playback.
Streaming endpoint Packages and delivers content through playback protocols such as HTTP Live Streaming (HLS) and Dynamic Adaptive Streaming over HTTP (DASH).
Content key policy Defines how MK.IO issues content keys and authorizes protected playback.
You do not need every resource for every task. For example, a live workflow uses a live event instead of a transform and job while the stream is running. The [media resource model](/mkio/understanding/core-concepts) explains these relationships in more detail. ## Deliver video to viewers A streaming endpoint acts as the origin service for your content. A streaming locator links an asset to that endpoint and generates its playback paths. For wider delivery, a **Content Delivery Network (CDN)** uses a distributed network of servers to cache content closer to viewers. MK.IO supports integrated CDN endpoints and external CDN configurations. [Streaming endpoints and playback](/mkio/how-to/content-delivery-publishing) explains the available publishing workflows. You can also protect playback with encryption and Digital Rights Management (DRM). [Content protection](/mkio/understanding/core-concepts/content-protection) explains streaming policies, content key policies, and DRM options. ## Choose where to begin - [Live stream in five minutes](/mkio/getting-started/live-stream-in-five-minutes) for a first live workflow with a prepared source. - [Publish your first VOD asset](/mkio/getting-started/video-on-demand-vod-workflows) for a file-based workflow. - [Set up your account](/mkio/getting-started/account-setup-and-first-steps) if you do not yet have a project. - [Navigate the MK.IO portal](/mkio/getting-started/platform-navigation-and-key-features) to find product areas and organization settings. - [Choose an MK.IO API](/mkio/api-guides/getting-started/which-api) when you are ready to automate a workflow. - [Guides overview](/mkio/how-to/overview): Find task-based MK.IO guides organized around the main areas of the portal and common operational workflows. - [Assets and storage](/mkio/how-to/content-management): Connect storage and manage the assets, files, tracks, filters, and playback resources used by MK.IO workflows. - [Live events](/mkio/how-to/live-streaming): Configure MK.IO live events, connect RTMP or SRT sources, manage recording, and publish live playback URLs. - [Video processing](/mkio/how-to/video-processing-encoding): Configure reusable transforms and run MK.IO jobs for encoding, conversion, clipping, thumbnails, and AI workflows. - [Streaming endpoints and playback](/mkio/how-to/content-delivery-publishing): Publish MK.IO assets with streaming endpoints and locators, retrieve playback URLs, and connect delivery services. - [Content key policies](/mkio/how-to/drm-content-protection): Protect live and VOD streams with content key policies, encryption, DRM, and token authentication in MK.IO. - [AI workflows](/mkio/how-to/ai-features): Configure MK.IO transcription, translation, and multi-language VOD dubbing workflows. - [Operational metrics](/mkio/how-to/monitor-your-services): Enable operational metrics and scrape MK.IO service data with a Prometheus-compatible monitoring system. - [Organization settings](/mkio/how-to/managing-your-organization): Manage MK.IO users, teams, tokens, webhooks, billing, and marketplace subscription tasks. - [Edge devices](/mkio/how-to/managing-edge-devices): Onboard and operate MK.IO edge devices through the portal or Fleet API. - [Security Access Control](/mkio/how-to/security-access-control): Pages in the Security Access Control section. - [Migrate from Azure Media Services](/mkio/how-to/migrate-from-azure-media-services): Choose the MK.IO guides for importing Azure Media Services assets, converting legacy formats, and restoring playback. # AI workflows MK.IO AI workflows run through transforms and jobs. Choose the guide for transcription and translation outputs or for multi-language VOD dubbing. ## Transcription and translation - [Configure transcription and translation transforms](/mkio/how-to/ai-features/vod-transcription-and-translation-transforms). - [Review AI workflow concepts and supported languages](/mkio/understanding/core-concepts/vod-processing/ai-workflows). ## VOD dubbing - [Convert HSS assets for VOD dubbing](/mkio/how-to/ai-features/convert-hss-for-vod-dubbing). - [Create multi-language VOD dubbing output](/mkio/how-to/ai-features/multi-language-vod-dubbing). - [Automate a multi-language dubbing workflow](/mkio/how-to/ai-features/vod-dubbing-automation-multi-lang). For general transform and job automation, use the [Transforms and jobs API Guide](/mkio/api-guides/how-to/media/transforms-and-jobs). # Convert HSS assets for VOD dubbing VOD dubbing requires assets in the MP4v4 format, which produces a `.mpd` DASH manifest. Assets encoded using older presets, including those from Azure Media Services (AMS) or any source that produces a `.ismc` manifest, are **not compatible**. This guide helps you identify your asset's format and convert it before proceeding to the [Multi-language VOD Dubbing Guide](/mkio/how-to/ai-features/multi-language-vod-dubbing). ## Check your asset format 1. In MK.IO, navigate to **Assets** and select your asset. 2. Open the **Files** tab to view the files in the asset's storage container. 3. Identify the manifest file type:
Manifest file Format Compatible with VOD dubbing?
.mpd MP4v4 Yes: no conversion needed
.ismc HSS (legacy) No: convert first using this guide
If your asset contains a `.mpd` file, it is already in the correct format. To dub your assets, follow the [Multi-language VOD Dubbing Guide](/mkio/how-to/ai-features/multi-language-vod-dubbing). If your asset contains a `.ismc` file, continue with this guide. ## Choose a conversion preset The preset you choose depends on whether each video rendition file in your asset contains audio, or whether audio is stored in completely separate files.
Source structure Preset to use
Each video rendition file contains audio CopyAllBitratesInterleaved
Video rendition files contain video only, audio is separate CopyAllBitratesNonInterleaved
**How to check your asset's structure:** Open the **Files** tab of your asset and look at the file listing. You are trying to find if the video rendition files contain audio, or not. - **Count distinct file types.** If all your MP4 files appear to be video renditions at different resolutions or bitrates, with no separate audio-only file, audio is likely interleaved in each. If you can see one or more files that have no resolution dimension in the name and appear to represent audio only, those are separate audio tracks. - **Check the file naming.** Encoding tools often include the codec or track type in the filename. A video rendition file that includes an audio codec name (such as `AAC`) alongside a video resolution is a strong sign that audio is interleaved. A file with only an audio bitrate and no resolution is likely audio-only. - **When in doubt, use `CopyAllBitratesInterleaved`.** Most assets from AMS or older encoding pipelines have audio interleaved in each video rendition. If you are unsure, this is the correct choice for the majority of legacy HSS assets.

A standalone audio file alongside your video renditions does not mean audio is non-interleaved. The deciding factor is whether the video rendition files themselves contain audio. If they do, use CopyAllBitratesInterleaved regardless of whether a separate audio file also exists.

## Step 1: Create an asset conversion transform 1. Navigate to **Video Processing** → **Transforms** → **+ Create Transform**. 2. Configure the transform: - **Name:** give it a descriptive name, for example `hss-to-mp4-interleaved`. - **Type:** select **Asset conversion**. - **Built-in preset:** select the preset you identified above: `CopyAllBitratesInterleaved` or `CopyAllBitratesNonInterleaved`. 3. Select **Create**. ## Step 2: Run the conversion job 1. Navigate to **Video Processing** → **Jobs** → **+ Create Job**. 2. Configure the job: - **Job name:** provide a unique name for this conversion, for example `convert-hss-asset`. - **Transform:** select the transform you created in Step 1. - **Select input:** select **Existing asset** and choose your legacy HSS asset. - **Output asset name:** provide a name for the converted asset, for example `my-asset-mp4v4`. 3. Select **Create**. MK.IO automatically identifies the source files: you do not need to select a specific input file. **Monitor progress:** Navigate to **Video Processing** → **Jobs** and wait for the job status to show **Finished**. **Verify the output:** Open the new converted asset and confirm that a `.mpd` file is present in the **Files** tab. This confirms the asset is in MP4v4 format. ## Next steps Your converted asset is now ready for VOD dubbing. Return to the [Multi-language VOD Dubbing Guide](/mkio/how-to/ai-features/multi-language-vod-dubbing) and use the converted asset as your source. # Multi-language VOD Dubbing Guide This guide shows how to use the MK.IO AI dubbing pipeline to generate Spanish, German, and French audio tracks from English-language video content. The completed source asset streams with the original English track and three dubbed tracks that viewers can select. For a full list of supported languages and more detailed information about the available transforms, visit the [transcription and translation reference page](/mkio/reference/encoding-transform-presets/transcription-and-translation-transforms).

Format requirement: VOD dubbing requires assets in the MP4v4 format, which produces a .mpd DASH manifest. Assets from older encoding pipelines, including Azure Media Services (AMS) or any source that generates a .ismc manifest, are not supported directly. If your asset is in the legacy HSS format, convert it first using the Convert assets to MP4v4 guide, then return here. For supported languages and specifications, see the AI workflows documentation.

## Prerequisites - Active MK.IO project access - API token: available in **Organisation Settings** → **API Tokens** - English-language MP4 video (2 to 10 minutes recommended for testing) - Azure Storage account connected to MK.IO **Starting point:** If you already have an MP4v4 asset with a `.mpd` manifest, skip to [Step 2](/mkio/how-to/ai-features/multi-language-vod-dubbing#step-2-create-multi-language-dubs). If your asset is in the legacy HSS format (it has a `.ismc` manifest), see [Convert HSS assets for VOD dubbing](/mkio/how-to/ai-features/convert-hss-for-vod-dubbing) before continuing. ## Step 1: Upload and encode source video ### 1.1 Create an asset 1. In the MK.IO dashboard, navigate to **Assets** → **+ Add Asset**. 2. Select your storage location. 3. Enter the asset details: - **Asset name:** `english-source-video` - **Container:** `videos` - **Storage account:** select your Azure Storage account 4. Upload your MP4 file. This guide uses a file named `english-video-demo.mp4`. 5. Select **Upload** and wait for it to complete. ### 1.2 Create an encoding transform and job 1. Navigate to **Video Processing** → **Transforms** → **+ Create Transform**. 2. Configure the transform: - **Name:** `encode-streaming` - **Type:** Encoding - **Preset:** H.264 Multiple Bitrate 1080p 3. Select **Create**. 4. Navigate to **Video Processing** → **Jobs** → **+ Create Job**. 5. Configure the job: - **Name:** `encode-english-source` - **Transform:** `encode-streaming` - **Input asset name:** `english-source-video`. Select `english-video-demo.mp4`. - **Output asset name:** `english-encoded` 6. Select **Create** and monitor the job status. ![Encoding job status view in MK.IO dashboard](/images/mkio-dubbing-encoding-jobs.png) 7. Wait for the job status to show **Finished**.

Why encode first? Encoding generates the .mpd manifest file that track insertion operations require.

## Step 2: Create multi-language dubs ### 2.1 Create a dubbing transform A dubbing transform defines the source language and the target languages for the AI dubbing pipeline.
Parameter Description
@odata.type Must be set to #MediaKind.AIPipelinePreset
pipeline name Predefined_ACSVodSpeechToSpeech
language Source language code (for example, en-US)
targetLanguages Array of target language codes
speakerCount Number of speakers in the source audio (auto for automatic detection)
personalVoice true to preserve the original speaker's voice characteristics
### UI 1. Navigate to **Video Processing** → **Transforms** → **+ Create Transform**. 2. Enter a **Transform name**, for example `dubbing-transform`. 3. Select **AI workflow** as the transform type. 4. Select **Predefined\_ACSVodSpeechToSpeech** from the **AI pipeline** dropdown. 5. Configure the pipeline settings: - **Language:** `en-US` - **Translate to:** select `es-ES`, `de-DE`, and `fr-FR` - **Speaker count:** `auto` - **Personal voice:** leave unchecked to use synthetic voices 6. Select **Create**. ### API **PUT** `https://app.mk.io/api/v1/projects//media/transforms/` **Path parameters** - ``: Your unique project identifier - ``: Transform name (for example, dubbing-transform) **Request body** ```json { "properties": { "description": "AI dub: English to Spanish, German, French", "outputs": [ { "preset": { "@odata.type": "#MediaKind.AIPipelinePreset", "pipeline": { "name": "Predefined_ACSVodSpeechToSpeech", "arguments": { "VodSpeechToSpeechTranslation": [ { "name": "language", "value": "en-US" }, { "name": "targetLanguages", "value": [ "es-ES", "de-DE", "fr-FR" ] }, { "name": "speakerCount", "value": "auto" }, { "name": "personalVoice", "value": false } ] } } } } ] } } ``` **Notes on the configuration:** - **Target languages:** A single dubbing job generates all three language dubs simultaneously. - **Personal voice:** Setting `personalVoice` to `false` uses a synthetic voice. Set to `true` to attempt to preserve each speaker's voice characteristics across languages. ### 2.2 Create a dubbing job ### UI 1. Navigate to **Video Processing** → **Jobs** → **+ Create Job**. 2. Enter a **Job name**, for example `dub-english-source`. 3. Under **Select a transform**, choose `dubbing-transform`. 4. Under **Select input**, set: - **Input asset name:** `english-encoded` - **Filename:** `english-video-demo_320x180_400k.mp4` 5. Under **Configure output**, set: - **Asset storage account:** select your Azure Storage account - **Output asset name:** enter a new name, for example `dubbed-audio`. MK.IO creates this asset automatically. 6. Select **Create**. ### API **PUT** `https://app.mk.io/api/v1/projects//media/transforms//jobs/` **Path parameters** - ``: Your unique project identifier - ``: The dubbing transform (for example, dubbing-transform) - ``: Unique identifier for this dubbing job **Request body** ```json { "properties": { "description": "Generate Spanish, German, French dubs", "priority": "Normal", "input": { "files": [ "english-video-demo_320x180_400k.mp4" ], "@odata.type": "#Microsoft.Media.JobInputAsset", "assetName": "english-encoded" }, "outputs": [ { "@odata.type": "#Microsoft.Media.JobOutputAsset", "assetName": "dubbed-audio" } ] } } ```

If you are creating the output asset via the API rather than through the job form, create it first using a PUT request to /projects/<PROJECT_NAME>/media/assets/dubbed-audio before submitting the job.

**Input file:** Specify any single encoded bitrate variant from the source asset (for example, `english-video-demo_320x180_400k.mp4`). All variants contain the audio track required for dubbing, so you can use the lowest bitrate file. **Monitor progress:** Navigate to **Video Processing** → **Jobs** and wait for the job status to show **Finished**. **Output files:** When the job completes, the `dubbed-audio` asset contains three files: - `english-video-demo_320x180_400k.mp4_es-ES.mp4`: Spanish - `english-video-demo_320x180_400k.mp4_de-DE.mp4`: German - `english-video-demo_320x180_400k.mp4_fr-FR.mp4`: French ## Step 3: Insert audio tracks This step adds the dubbed audio tracks to the encoded video asset, making all languages available to viewers. ### 3.1 Create track insertion transforms

Track insertion transforms must be created through the API. Track insertion jobs can be created using either the UI or API. See step 3.2.

Create three transforms: one per language. Each transform defines the track name, display name, and language code for the inserted audio. **Spanish insert transform:** **PUT** `https://app.mk.io/api/v1/projects//media/transforms/` **Path parameters** - ``: Your unique project identifier - ``: Transform name (for example, spanish-insert) **Request body** ```json { "properties": { "description": "Insert Spanish audio", "outputs": [ { "preset": { "tracks": [ { "@odata.type": "#MediaKind.AudioTrack", "trackName": "audio-spanish", "displayName": "Español (AI Dubbed)", "languageCode": "es-ES" } ], "@odata.type": "#MediaKind.TrackInserterPreset" }, "relativePriority": "Normal" } ] } } ``` **Repeat for German and French:** - **German transform:** set `trackName` to `audio-german`, `displayName` to `Deutsch (AI Dubbed)`, and `languageCode` to `de-DE` - **French transform:** set `trackName` to `audio-french`, `displayName` to `Français (AI Dubbed)`, and `languageCode` to `fr-FR` ### 3.2 Create track insertion jobs Create one job per language. Each job inserts the corresponding dubbed audio file into the `english-encoded` asset. ### UI Repeat the following for each language (Spanish, German, French): 1. Navigate to **Video Processing** → **Jobs** → **+ Create Job**. 2. Enter a **Job name**, for example `job-insert-spanish`. 3. Under **Select a transform**, choose the corresponding insertion transform (for example, `spanish-insert`). 4. Under **Select input**, set: - **Input asset name:** `dubbed-audio` - **Filename:** the dubbed file for this language (for example, `english-video-demo_320x180_400k.mp4_es-ES.mp4`) 5. Under **Configure output**, set: - **Output asset name:** `english-encoded` 6. Select **Create**.
Language Transform Input filename Output asset
Spanish spanish-insert ..._es-ES.mp4 english-encoded
German german-insert ..._de-DE.mp4 english-encoded
French french-insert ..._fr-FR.mp4 english-encoded
### API **Spanish insertion job:** **PUT** `https://app.mk.io/api/v1/projects//media/transforms//jobs/` **Path parameters** - ``: Your unique project identifier - ``: The track insertion transform (for example, spanish-insert) - ``: Unique job identifier (for example, job-insert-spanish) **Request body** ```json { "properties": { "input": { "files": [ "english-video-demo_320x180_400k.mp4_es-ES.mp4" ], "@odata.type": "#Microsoft.Media.JobInputAsset", "assetName": "dubbed-audio" }, "outputs": [ { "@odata.type": "#Microsoft.Media.JobOutputAsset", "assetName": "english-encoded" } ], "priority": "Normal" } } ``` **Repeat for German and French:** - **German:** input file `english-video-demo_320x180_400k.mp4_de-DE.mp4`, job name `job-insert-german` - **French:** input file `english-video-demo_320x180_400k.mp4_fr-FR.mp4`, job name `job-insert-french` **Monitor progress:** Wait for all three jobs to show **Finished**. **Verify:** Navigate to **Assets** → `english-encoded` and open the **Tracks** section. You should see three audio tracks for Spanish, German, and French. ![Asset tracks view showing Spanish, German, and French dubbed audio tracks](/images/mkio-vod-dubbing-panel.png) ## Step 4: Configure streaming ### 4.1 Create a streaming endpoint 1. Navigate to **Streaming Endpoints** → **+ Create Streaming Endpoint**. 2. Configure the endpoint: - **Name:** `production` - **Base URL:** `content` - **Type:** Dedicated 3. Select **Create**, then **Start**. ### 4.2 Create a streaming locator 1. Navigate to **Assets** and select `english-encoded`. 2. Select the `production` endpoint created in step 4.1. 3. Add a streaming locator: - **Name:** `live` - **Policy:** `Predefined_DownloadAndClearStreaming` 4. Copy the playback URLs provided. ### 4.3 Test multi-language playback 1. Select the embedded player in the asset details. 2. Use the audio track selector to switch between languages. 3. Confirm that Spanish, German, and French audio tracks are selectable alongside the original English track. # VOD Dubbing Automation Example Build an automated multi-video dubbing system with the MK.IO API and webhooks. Submit the dubbing jobs, then use webhooks to start track insertion when each job completes. **What you will build:** - A job submission script that creates temporary assets and submits dubbing jobs - A webhook listener that automatically inserts dubbed tracks when jobs complete

Before starting you will need encoded source videos in separate assets

You need three English-language videos that are already encoded for streaming using the mp4-v4 format, each in its own asset with a .mpd manifest present (for example, video-001-encoded, video-002-encoded, video-003-encoded).

If you do not have these yet, follow the previous guide to upload, create assets, and run an encoding job before using this demo.

## Prerequisites ### Step 1: Install Python Packages ```bash pip install requests flask python-dotenv ``` ### Step 2: Install ngrok

Why ngrok? (local webhooks):

Webhooks must call a publicly reachable HTTPS URL - localhost is not accessible from MK.IO’s servers.

ngrok creates a temporary public URL that tunnels to your local Flask server so MK.IO can POST job events to your machine during development.

In production, you can replace ngrok with a real HTTPS endpoint (cloud/app host) and keep the same webhook flow.

**Installing ngrok:** macOS (Homebrew): ```bash brew install ngrok/ngrok/ngrok ``` Windows (Chocolatey): ```powershell choco install ngrok ``` Linux: 1. Download from ngrok.com/download, 2. unzip, and add the binary to your PATH ### Step 3: Create Environment File Create a file named `.env` in your project directory: Add these lines (replace with your actual values): ```dotenv MKIO_API_TOKEN=your_jwt_here MKIO_PROJECT_NAME=your_project_name STORAGE_ACCOUNT_NAME=your_storage_account_name WEBHOOK_SECRET= ``` **How to get each value:**
Variable How to Get
MKIO_API_TOKEN MK.IO Dashboard → Organisation Settings → API Tokens → Create Token
MKIO_PROJECT_NAME Your MK.IO project name (visible in dashboard URL or settings)
STORAGE_ACCOUNT_NAME Azure Storage account name where your assets/ videos are stored
WEBHOOK_SECRET Any random string you choose (for example, <YOUR_WEBHOOK_SECRET>)
### Step 4: Create Transforms You need to create 4 transforms in your MK.IO project. These are reusable templates that define how to process videos. **Important:** Refer to the [VOD Dubbing Demo Guide](/mkio/how-to/ai-features/multi-language-vod-dubbing) section "Create Transforms" for the exact API requests. You need to create: 1. `dubbing-multi-lang` - The main dubbing transform (English → Spanish, German, French) 2. `insert-spanish` - Add Spanish audio track 3. `insert-german` - Add German audio track 4. `insert-french` - Add French audio track All 4 should return 200 OK. ## Creating the Scripts ### File 1: submit\_jobs.py This script creates temporary assets for dubbed audio and submits dubbing jobs. Create a file named `submit_jobs.py`: ```python # submit_jobs.py # This script simply creates temporary output assets to hold the dubbed audio results and submits dubbing jobs for each encoded video file. import os import requests from dotenv import load_dotenv load_dotenv() # ===== Get environment variables ===== API_TOKEN = os.getenv('MKIO_API_TOKEN') PROJECT_NAME = os.getenv('MKIO_PROJECT_NAME') STORAGE_ACCOUNT = os.getenv('STORAGE_ACCOUNT_NAME') # ===== Define api endpoint and headers ===== BASE_URL = f"https://app.mk.io/api/v1/projects/{PROJECT_NAME}/media" HEADERS = { 'Authorization': f'Bearer {API_TOKEN}', 'Content-Type': 'application/json' } # ===== Define encoded video names - CHANGE THESE to your actual encoded video asset names ===== VIDEOS = [ 'video-001-encoded', 'video-002-encoded', 'video-003-encoded' ] # ===== This is the first step: To create an asset for each video to contain the generated dubbed audio .mp4 files. ===== def create_dubbed_audio_asset(source_asset): asset_name = f"{source_asset}-dubbed-audio" url = f"{BASE_URL}/assets/{asset_name}" body = { "properties": { "description": f"Dubbed audio for {source_asset}", "storageAccountName": STORAGE_ACCOUNT } } response = requests.put(url, headers=HEADERS, json=body) # If we get error 409, the asset already exists - this is fine we can still proceed. if response.status_code == 409: print(f"Asset already exists: {asset_name}") else: response.raise_for_status() print(f"Created asset: {asset_name}") return asset_name # ===== Get the first mp4 files from the encoded asset to run the dubbing job on. They all contain the neccesary audio files - lowest bitrate is fine. ===== def get_first_mp4(asset_name): """ How this works: 1. make a GET request to /assets/{asset}/storage to list files 2. Parse the response.spec.files 3. Find the first file that ends with .mp4 (can be adjusted to find the lowest bitrate) """ url = f"{BASE_URL}/assets/{asset_name}/storage" response = requests.get(url, headers=HEADERS) # If the asset has no storage container it will return error 400 if response.status_code == 400: return None response.raise_for_status() storage = response.json() files = storage.get('spec', {}).get('files', []) # Find the first .mp4 file for f in files: name = f.get('name') or f.get('path') if name and name.endswith('.mp4'): return name return None # ===== Submit a dubbing job to the dubbing transform created during setup. In this example it is called 'dubbing-multi-lang'. ===== def submit_dubbing_job(source_asset, dubbed_asset, input_file): """ This function: - takes the {input_file} from the {source_asset} - Applies the dubbing-multi-lang transform - Writes the results to the output {dubbed_asset} - the service then sends a webhook to our listener when done """ job_name = f"dub-{source_asset}" url = f"{BASE_URL}/transforms/dubbing-multi-lang/jobs/{job_name}" body = { "properties": { "description": f"Dub {source_asset}", "priority": "Normal", "input": { "@odata.type": "#Microsoft.Media.JobInputAsset", "assetName": source_asset, "files": [input_file] }, "outputs": [{ "@odata.type": "#Microsoft.Media.JobOutputAsset", "assetName": dubbed_asset }] } } response = requests.put(url, headers=HEADERS, json=body) response.raise_for_status() print(f"Submitted dubbing job: {job_name}") return job_name # ===== The main entry point ===== def main(): print("=================================") print(" MK.IO VOD Dubbing - submit jobs") print("=================================") print("Videos to process:") for video in VIDEOS: print(f" - {video}") print(f"\nCreating temporary assets for dubbed audio...\n") jobs_submitted = [] for video in VIDEOS: # Create the output asset for dubbed audio dubbed_asset = create_dubbed_audio_asset(video) # Get the input file from the source asset input_file = get_first_mp4(video) if not input_file: print(f" ERROR: No mp4 file found in asset: {video}.") continue print(f" Input file for {video}: {input_file}") # Submit the dubbing job job_name = submit_dubbing_job(video, dubbed_asset, input_file) jobs_submitted.append(job_name) print() print("="*10 + "\n") print(f"\n✓ Submitted {len(jobs_submitted)} dubbing jobs\n") print("\nDubbing will process in the background.") print("="*10 + "\n") if __name__ == "__main__": main() ```

Edit lines 23-26 and change VIDEOS to your actual video asset names

**What it does:** - For each video: creates a temp asset + submits a dubbing job - Takes \~1-2 seconds per video - Then exits and tells you what to do next ### File 2: webhook\_listener.py This script receives webhooks from MK.IO and automatically handles track insertion. Create a file named `webhook_listener.py`: ```python # Webhook_listener.py """ This is a simple Flask server that: 1. Recieves webhooks when the dubbing jobs are complete 2. Extracts the dubbed audio files from the output asset 3. Automatically submits the track insertion jobs using the insertion transforms created earlier. 4. Recieves webhooks when the track insertion jobs are complete. Note the track insertion transforms must already exist in your MK.IO project for this to work. # insert-spanish # insert-french # insert-german """ import os import requests from flask import Flask, request, jsonify from dotenv import load_dotenv load_dotenv() # ===== Get environment variables ===== API_TOKEN = os.getenv('MKIO_API_TOKEN') PROJECT_NAME = os.getenv('MKIO_PROJECT_NAME') WEBHOOK_SECRET = os.getenv('WEBHOOK_SECRET') # ===== Define api endpoint and headers ===== BASE_URL = f"https://app.mk.io/api/v1/projects/{PROJECT_NAME}/media" HEADERS = { 'Authorization': f'Bearer {API_TOKEN}', 'Content-Type': 'application/json' } app = Flask(__name__) """ Function to get a list of the dubbed audio files from the output asset After dubbing completes, the output asset contains three files: - video_es-ES.mp4 (Spanish dub) - video_de-DE.mp4 (German dub) - video_fr-FR.mp4 (French dub) This function lists those files and returns them organised by language. """ def get_dubbed_files(asset_name): url = f"{BASE_URL}/assets/{asset_name}/storage" response = requests.get(url, headers=HEADERS) if response.status_code == 400: # The asset has no files yet return {} response.raise_for_status() storage = response.json() files = storage.get('spec', {}).get('files', []) dubbed = {} # Parse the filenames to identify the language codes for f in files: path = f.get('path') or f.get('name') if path: if '_es-ES.mp4' in path: dubbed['es-ES'] = path elif '_de-DE.mp4' in path: dubbed['de-DE'] = path elif '_fr-FR.mp4' in path: dubbed['fr-FR'] = path return dubbed """ Helper function to submit the track insertion job for a single track This function takes a single dubbed audio file and submits a track insertion job (using the appropriate insert transform created earlier). This adds the dubbed audio as a new audio track to the original encoded video asset. After all the track insertion jobs are submitted, the asset will have multiple audio tracks available for playback, and viewers can select their language. """ def submit_track_insertion_job(dubbed_asset, target_asset, dubbed_file, language_code, transform_name): lang_short = language_code.split('-')[0] # e.g., 'es' from 'es-ES' job_name = f"insert-{target_asset}-{lang_short}" url = f"{BASE_URL}/transforms/{transform_name}/jobs/{job_name}" body ={ "properties": { "description": f"Insert {language_code} track", "priority": "Normal", "input": { "@odata.type": "#Microsoft.Media.JobInputAsset", "assetName": dubbed_asset, "files": [dubbed_file] }, "outputs": [{ "@odata.type": "#Microsoft.Media.JobOutputAsset", "assetName": target_asset }] } } response = requests.put(url, headers=HEADERS, json=body) response.raise_for_status() print(f"{job_name} submitted for {language_code}") """ Function to insert all three language tracks for a video. This is called automatically when a dubbing job completes (via webhooks) Steps: 1. Get a list of dubbed files from the output asset 2. For each language - submit a track insertion job """ def insert_all_tracks(source_asset, dubbed_asset): print (f"\n Inserting dubbed tracks for asset: {source_asset}") dubbed_files = get_dubbed_files(dubbed_asset) if not dubbed_files: print("No dubbed files found.") return # Map language codes to transform names languages = { 'es-ES': 'insert-spanish', 'fr-FR': 'insert-french', 'de-DE': 'insert-german' } # Submit a track insertion job for each language for lang_code,transform in languages.items(): if lang_code in dubbed_files: dubbed_file = dubbed_files[lang_code] submit_track_insertion_job(dubbed_asset, source_asset, dubbed_file, lang_code, transform) """ Flask route to handle incoming webhooks. """ @app.route('/webhook', methods=['POST']) def webhook(): # Verify the webhook is authentic by checking with the auth header auth = request.headers.get('Authorization', '') expected_auth = f"Bearer {WEBHOOK_SECRET}" if auth != expected_auth: print("!! Webhook received with invalid authorization !!") return jsonify({"error": "Unauthorized"}), 401 event = request.get_json() if not event: return jsonify({"error": "There is no body"}), 400 # Etract the information from the webhook payload event_type = event.get('type') data = event.get('data',{}) resource = data.get('resource',{}) job_name = resource.get('name') job_state= data.get('state') # Log the webhjook print(f"\n Webhook received: {event_type}") print(f" Job: {job_name}") print(f" State: {job_state}") # Handle dubbing job completion # Job names follow the pattern "dub-{source_asset}" if job_state == 'Finished' and job_name.startswith('dub-'): source_asset = job_name.replace('dub-', '') dubbed_asset = f"{source_asset}-dubbed-audio" #automatically trigger the track insertion insert_all_tracks(source_asset, dubbed_asset) # Handle track insertion job completion # Job names follow the pattern "insert-{source_asset}-{lang_short}" elif job_state == 'finished' and job_name.startswith('insert-'): parts = job_name.split('-') lang = parts [-1] print (f" Track insertion for language {lang} completed.") # Handle errors elif job_state =='error': print(f" !! Job {job_name} failed !! ") # Always return 200 so MKIO doesn't retry the webhook over and over return jsonify({"status": "received"}), 200 @app.route('/health', methods=['GET']) def health(): # Health check endpoint to verify if the server is running return jsonify({"status": "ok"}), 200 if __name__ == '__main__': print("\n" + "="*60) print("MK.IO VOD Dubbing - Webhook Listener") print("="*60) print("\nListening on http://localhost:5000") print("Webhook endpoint: http://localhost:5000/webhook\n") print("Make sure you:") print(" 1. Created all transforms (using the guide)") print(" 2. Created webhook rule in MK.IO dashboard") print(" 3. Ran submit_jobs.py to submit dubbing jobs") print("\nWaiting for webhooks...\n") print("="*60 + "\n") app.run(host='0.0.0.0', port=5000, debug=False) ``` ## Running the Complete Pipeline ### Step 1: Set Up ngrok Tunnel Open a new terminal and run: ```bash ngrok http 5000 ``` The terminal displays the forwarding URL: ```text Forwarding https://abc123def456.ngrok.io -> http://localhost:5000 ``` **Copy the HTTPS URL** (the `https://abc123def456.ngrok.io` part). ![996fe706626cbbcca972e3507fc21c04bf0f2efabc4764b4329c7ce53cbc6a21 image](/images/mkio-vod-dubbing-subtitle.png)

Add /webhook to the end of the ngrok URL when creating the webhook rule below.

### Step 2: Create Webhook Rule Using **Postman**, make a PUT request: ```http PUT https://app.mk.io/api/v1/projects/YOUR_PROJECT_NAME/webhook/rules/dubbing-demo Headers: Authorization: Bearer YOUR_MKIO_JWT Content-Type: application/json Body: { "spec": { "enabled": true, "url": "https://soundless-ninfa-runcinate.ngrok-free.dev/webhook", "authentication": { "headers": { "Authorization": "Bearer " } }, "events": [ "MediaKind.JobStarted", "MediaKind.JobFinished" ] } } ``` Replace: - `YOUR_PROJECT_NAME` with your project name - `YOUR_API_TOKEN` with your API token - `https://abc123def456.ngrok.io` with your ngrok URL from Step 3 + `/webhook` - `` with your `WEBHOOK_SECRET` from `.env` You should get 200 OK. ### Step 3: Start the Webhook Listener Open a terminal and run: ```bash python webhook_listener.py ``` Output: ```text ❯ python webhook_listener.py ============================================================ MK.IO VOD Dubbing - Webhook Listener ============================================================ Listening on http://localhost:5000 Webhook endpoint: http://localhost:5000/webhook Make sure you: 1. Created all transforms (using the guide) 2. Created webhook rule in MK.IO dashboard 3. Ran submit_jobs.py to submit dubbing jobs Waiting for webhooks... ``` This server is now listening for webhooks on your local machine at `localhost:5000`. ### Step 4: Submit Dubbing Jobs Open a new terminal and run: ```bash python submit_jobs.py ``` Output: ```text ❯ python submit_jobs.py ================================= MK.IO VOD Dubbing - submit jobs ================================= Videos to process: - video-001-encoded - video-002-encoded - video-003-encoded Creating temporary assets for dubbed audio... Created asset: video-001-encoded-dubbed-audio Input file for video-001-encoded: demo-video-1_1280x720_3400k.mp4 Submitted dubbing job: dub-video-001-encoded Created asset: video-002-encoded-dubbed-audio Input file for video-002-encoded: demo-video-2_1280x720_3400k.mp4 Submitted dubbing job: dub-video-002-encoded Created asset: video-003-encoded-dubbed-audio Input file for video-003-encoded: demo-video-3_1280x720_3400k.mp4 Submitted dubbing job: dub-video-003-encoded ========== ✓ Submitted 3 dubbing jobs Dubbing will process in the background. ========== ``` ## Monitor the workflow The webhook listener terminal will start showing live updates: ```text ============================================================ Webhook received: MediaKind.JobStarted Job: dub-video-001-encoded State: Scheduled 127.0.0.1 - - [13/Nov/2025 11:09:45] "POST /webhook HTTP/1.1" 200 - Webhook received: MediaKind.JobStarted Job: dub-video-002-encoded State: Scheduled 127.0.0.1 - - [13/Nov/2025 11:09:46] "POST /webhook HTTP/1.1" 200 - Webhook received: MediaKind.JobFinished Job: dub-video-001-encoded State: Finished Inserting dubbed tracks for asset: video-001-encoded insert-video-001-encoded-es submitted for es-ES insert-video-001-encoded-fr submitted for fr-FR insert-video-001-encoded-de submitted for de-DE 127.0.0.1 - - [13/Nov/2025 11:13:19] "POST /webhook HTTP/1.1" 200 - Webhook received: MediaKind.JobStarted Job: dub-video-003-encoded State: Scheduled 127.0.0.1 - - [13/Nov/2025 11:13:22] "POST /webhook HTTP/1.1" 200 - Webhook received: MediaKind.JobFinished Job: dub-video-002-encoded State: Finished Inserting dubbed tracks for asset: video-002-encoded insert-video-002-encoded-es submitted for es-ES insert-video-002-encoded-fr submitted for fr-FR insert-video-002-encoded-de submitted for de-DE 127.0.0.1 - - [13/Nov/2025 11:15:20] "POST /webhook HTTP/1.1" 200 - Webhook received: MediaKind.JobStarted Job: insert-video-001-encoded-es State: Scheduled 127.0.0.1 - - [13/Nov/2025 11:15:23] "POST /webhook HTTP/1.1" 200 - Webhook received: MediaKind.JobFinished Job: insert-video-001-encoded-es State: Finished 127.0.0.1 - - [13/Nov/2025 11:15:33] "POST /webhook HTTP/1.1" 200 - Webhook received: MediaKind.JobStarted Job: insert-video-001-encoded-fr State: Scheduled 127.0.0.1 - - [13/Nov/2025 11:15:40] "POST /webhook HTTP/1.1" 200 - ### And so on... ``` You should also see on the MK.IO dashboard the jobs appear and complete, as well as assets being created and populated: ![0d2bbba4b0ba43376266106385909a16ae0b22efa8ee5205b5feb599af0f627c image](/images/mkio-vod-dubbing-multi-lang-1.png) Assets ![](/images/mkio-vod-dubbing-multi-lang-2.png) Video Processing -> Jobs #### Once all jobs are complete you should see the following new tracks in your encoded assets: ![68ca4872e192e257d07a794d924fe97867c8e5b36f4af72316098a414a76ef1b image](/images/mkio-vod-dubbing-multi-lang-3.png) From here you can set up your streaming endpoints and locators to playback and test the new dubbed audio! ## Understanding the Code ### Key Concepts **Job Naming Convention:** - Dubbing jobs: `dub-{source_asset}` → Makes it easy to parse in webhooks - Track insertion: `insert-{source_asset}-{lang}` → Identifies which video and language **Webhook Flow:** 1. MK.IO processes a job 2. When complete, MK.IO POSTs to your webhook URL 3. Your webhook handler parses the job name 4. If it is a dubbing job, automatically submit track insertion. 5. If it is track insertion, log completion. **Authentication:** - Webhook verification via Bearer token in Authorization header - This ensures webhooks come from MK.IO, not malicious third parties ## Next Steps Once you see this working, you can: 1. **Add asset purging for dubbed-audio assets** 2. **Add automatic subtitle generation/ insertion stages** 3. **Scale to more videos** - Remove hardcoded `VIDEOS` list - Query all assets via API - Loop through them 4. **Optimise:** - Submit multiple dubbing jobs in parallel - Adjust delays and settings based on your needs ## Key Files - `submit_jobs.py` - Submits the dubbing jobs (one-time run) - `webhook_listener.py` - Listens for webhooks and auto-inserts tracks (long-running) - `.env` - Your credentials (never commit to git) Both scripts read from `.env` for configuration, so you only need to update credentials in one place. # Transcription and translation transforms VOD transcription and VOD translation transforms use MK.IO's AI pipeline to generate subtitle and caption tracks from video audio. Both transform types use the `#MediaKind.AIPipelinePreset` value for the `@odata.type` attribute, and they are created using the transform endpoint in the [MK.IO API](/api-reference/media-api).

VOD transcription and VOD translation are only available for MP4 content.

## VOD transcription A VOD transcription transform generates a text transcript from the audio track of a video asset. Once the resulting transcript file is available, you can insert it as a subtitle track using a [track insertion transform](/mkio/reference/encoding-transform-presets/add-a-track-to-a-vod-asset). ### Configuration parameters
Parameter Description
@odata.type Must be set to #MediaKind.AIPipelinePreset
pipeline name Predefined_ACSVodTranscription
language Language spoken in the audio to transcribe
phrases Words or phrases expected in the audio. Providing domain-specific terms improves recognition accuracy
### Transform example The example below configures a transform that transcribes audio in `en-US`. A custom phrase list improves recognition accuracy for domain-specific terms. Once the transform exists, use it to [create a job on a VOD asset](/mkio/how-to/video-processing-encoding/run-vod-transcode-jobs). ```bash curl --request PUT \ --url https://app.mk.io/api/v1/projects//media/transforms/transform_name \ --header 'accept: application/json' \ --header 'content-type: application/json' \ --header 'Authorization: Bearer bearer-token' \ --data ' { "properties": { "description": "Transcription en-US", "outputs": [ { "preset": { "@odata.type": "#MediaKind.AIPipelinePreset", "pipeline": { "name": "Predefined_ACSVodTranscription", "arguments": { "VodTranscription": [ { "name": "language", "value": "en-US" }, { "name": "phrases", "value": [ "Cyperus papyrus", "Heliotropium indicum", "Zamioculcas zamiifolia", "Monstera deliciosa", "Alocasia odora", "Tillandsia cyanea", "Drosera capensis", "Euphorbia tirucalli", "Ficus lyrata", "Calathea orbifolia" ] } ] } } } } ] } } ' ``` ## VOD translation A VOD translation transform transcribes the audio track and translates the output into one or more target languages, generating caption files for each. Once the translation job completes, use track insertion transforms to add the resulting VTT files to your encoded asset. ### Configuration parameters
Parameter Description
@odata.type Must be set to #MediaKind.AIPipelinePreset
pipeline name Predefined_ACSVodTranslation
language Language spoken in the audio to transcribe
targetLanguages Languages into which the transcription should be translated
phrases Words or phrases expected in the audio. Providing domain-specific terms improves recognition accuracy
### Transform example The example below configures a transform that transcribes audio in `en-US` and translates the output into `pt-PT`, `fr-FR`, and `es-ES`. A custom phrase list improves recognition accuracy for domain-specific terms. Once the transform exists, use it to [create a job on a VOD asset](/mkio/how-to/video-processing-encoding/run-vod-transcode-jobs). ```bash curl --request PUT \ --url https://app.mk.io/api/v1/projects//media/transforms/transform_name \ --header 'accept: application/json' \ --header 'content-type: application/json' \ --header 'Authorization: Bearer bearer-token' \ --data ' { "properties": { "description": "Transcription en-US, translation fr-FR pt-PT es-ES", "outputs": [ { "preset": { "@odata.type": "#MediaKind.AIPipelinePreset", "pipeline": { "name": "Predefined_ACSVodTranslation", "arguments": { "VodTranscription": [ { "name": "language", "value": "en-US" }, { "name": "targetLanguages", "value": [ "pt-pt", "fr-FR", "es-ES" ] }, { "name": "phrases", "value": [ "Cyperus papyrus", "Heliotropium indicum", "Zamioculcas zamiifolia", "Monstera deliciosa", "Alocasia odora", "Tillandsia cyanea", "Drosera capensis", "Euphorbia tirucalli", "Ficus lyrata", "Calathea orbifolia" ] } ] } } } } ] } } ' ``` ## Track insertion Once a VOD transcription or VOD translation job completes, use [track insertion transforms](/mkio/reference/encoding-transform-presets/add-a-track-to-a-vod-asset) to insert the generated VTT files into a previously encoded asset as subtitle or caption tracks. # Streaming endpoints and playback Streaming endpoints provide the delivery hostname, while streaming locators control how an asset can be accessed. Configure both resources to generate playback or download URLs for live and VOD content. ## Publish content - [Publish content for streaming](/mkio/how-to/content-delivery-publishing/stream-content). - [Publish imported or migrated assets](/mkio/how-to/content-management/playback-your-migrated-assets). - [Integrate Amazon CloudFront](/mkio/how-to/content-delivery-publishing/integrating-amazon-cloudfront). ## Understand delivery resources - [Streaming endpoints](/mkio/understanding/core-concepts/endpoints). - [Streaming locators and policies](/mkio/understanding/core-concepts/locators). - [MKPlayer SDK](/mkio/reference/player-sdk). Use the [Publishing API Guide](/mkio/api-guides/how-to/media/publishing) to automate endpoints and locators. Use the [Download asset files API Guide](/mkio/api-guides/how-to/media/download-asset-files) when you need direct access to asset files. # Integrate Amazon CloudFront For production workloads that require global reach, consistent low latency, or more than a few hundred concurrent viewers, you can place Amazon CloudFront in front of your streaming endpoint. CloudFront acts as the CDN layer: viewer requests hit CloudFront edge nodes globally, which cache content and forward cache misses to your MK.IO streaming endpoint as the origin. This reduces load on the endpoint and lowers latency for viewers worldwide. ## How it fits together ```text Viewer → CloudFront Edge → MK.IO Streaming Endpoint → Your Cloud Storage ``` Your playback URLs change from pointing directly at the MK.IO endpoint to pointing at your CloudFront distribution domain. The assets, locators, and streaming policies in your MK.IO workflow stay the same. ## Prerequisites - An AWS account with permissions to create CloudFront distributions - An MK.IO project on AWS with at least one streaming endpoint created and started. See [Publish content for streaming](/mkio/how-to/content-delivery-publishing/stream-content). ## Create a CloudFront distribution ### Open CloudFront in the AWS Console Sign in to the [AWS Console](https://console.aws.amazon.com) and navigate to **CloudFront**. Click **Create distribution**. ### Set the origin The origin is your MK.IO streaming endpoint hostname. - **Origin domain**: Enter the hostname of your MK.IO streaming endpoint (for example, `..streaming.mediakind.com`). Find this in MK.IO under **Streaming Endpoints**. - **Protocol**: Select **HTTPS only**. MK.IO endpoints require HTTPS. - **Origin shield**: Optional. Enable and choose the AWS region closest to your MK.IO deployment region to reduce origin load. ### Configure the default cache behaviour - **Viewer protocol policy**: Select **Redirect HTTP to HTTPS** or **HTTPS only**. - **Allowed HTTP methods**: Select **GET, HEAD**. Streaming manifests and segments are read-only. - **Cache policy**: Use **CachingOptimized** for most streaming content. If your streams use query-string token authentication or DRM signed URLs, use **CachingDisabled** or a custom policy that forwards the required query strings to the origin. - **Origin request policy**: If your streaming policies use query strings (for example, DRM tokens or signed URLs), attach an origin request policy that forwards those query strings to the MK.IO origin. ### Configure distribution settings - **Price class**: Select the regions where CloudFront should serve content. Selecting all regions gives the widest global coverage. - **Web Application Firewall**: Optional. Attach an AWS WAF Web ACL if you want to filter requests at the edge. - **Standard logging**: Set **Log delivery** to **Off** unless you need CloudFront access logs. Enabling logs, especially with CloudWatch, can generate high data volumes and unexpected costs. - **Default root object**: Leave empty. MK.IO streaming manifests are accessed by path, not by a default file. ### Create the distribution Click **Create distribution**. CloudFront assigns a distribution domain in the format `.cloudfront.net`. Wait for the **Last modified** field to update before testing the distribution. ## Update your playback URLs Once the distribution is active, replace the MK.IO streaming endpoint hostname in your playback URLs with the CloudFront domain: **Before (direct to MK.IO endpoint):** ```text https://..streaming.mediakind.com//... ``` **After (via CloudFront):** ```text https://.cloudfront.net//... ``` If you configure a custom domain in CloudFront, use that domain instead. ## Custom domain (optional) To use your own domain (for example, `cdn.example.com`) instead of the `.cloudfront.net` domain: 1. Request a certificate for your domain in **AWS Certificate Manager (ACM)** in the `us-east-1` region. CloudFront requires certificates in this region regardless of where your content is hosted. 2. In your CloudFront distribution, add your domain under **Alternate domain names (CNAMEs)** and attach the ACM certificate. 3. In your DNS provider, create a CNAME record pointing your domain to the `.cloudfront.net` distribution domain. For detailed steps, see the [AWS CloudFront custom domains documentation](https://docs.aws.amazon.com/AmazonCloudFront/latest/DeveloperGuide/CNAMEs.html). # Publish content for streaming To deliver content to viewers, MK.IO uses two infrastructure components that must both be in place before playback is possible: - **Streaming Endpoint**: The delivery server that handles viewer requests and serves your content from storage. Think of it as the origin that your CDN or media players connect to. - **Streaming Locator**: Attached to a specific asset, this generates the playback URLs and controls which streaming protocols and protections are applied. Both must exist before anyone can watch the content. You typically create one endpoint per environment, such as `production` and `staging`, and reuse it across many assets. A locator belongs to one asset, while any streaming endpoint in the same subscription can serve its paths. ## Prerequisites - At least one asset with content ready to stream (see [Video on demand workflows](/mkio/getting-started/video-on-demand-vod-workflows) or [Live streaming workflows](/mkio/getting-started/live-streaming-workflows)) - Cloud storage connected to your project (see [Connect cloud storage](/mkio/getting-started/connect-cloud-storage)) ## Create a streaming endpoint A streaming endpoint is the network infrastructure that serves content from your storage to viewers. Each endpoint has a hostname that becomes part of every playback URL for assets assigned to it. You can create multiple endpoints, for example separate endpoints for live and VOD content. Each asset is assigned to one endpoint at a time, though you can reassign it. **Endpoint types:**
Type Capacity Best for
Shared Up to 600 Mbps on shared infrastructure Development, testing, and workloads within the shared capacity
Dedicated 200 Mbps of guaranteed bandwidth per unit Production workloads that require dedicated, scalable capacity
CDN Backed by dedicated endpoint capacity Production delivery that benefits from integrated edge caching
### Open Streaming Endpoints Go to **Streaming Endpoints** in the left navigation and click **+ Create Streaming Endpoint**. ### Configure the endpoint - **Name**: A unique identifier using lowercase letters, numbers, and hyphens (for example, `production`). This becomes part of your playback URLs and is visible to viewers, so keep it descriptive. - **Description**: Optional. Useful if you run multiple endpoints for different content types. - **Type**: Shared, Dedicated, or CDN based on your scale requirements. You can switch between Shared and Dedicated at any time. - **Scale units** (Dedicated only): Start at 1 and increase as your audience grows. - **CDN**: Enable integrated CDN delivery. See [Streaming endpoints](/mkio/understanding/core-concepts/endpoints#cdn-behavior-and-constraints) for cache behavior and constraints. - **Auto-start**: Enable to activate the endpoint immediately after creation. - **Tags**: Optional labels for resource grouping and cost tracking. ### Activate the endpoint Click **Create**. If you did not enable auto-start, select your endpoint from the list and click **Start**.

A running streaming endpoint incurs costs even when no content is actively being played. Stop endpoints when they are no longer needed. See MK.IO pricing for details.

## Create a streaming locator A streaming locator is attached to one asset and generates the playback URLs for it. It controls: - **Which streaming protocols are available** - Clear streaming, adaptive bitrate streaming, or DRM-protected - **Access window**: Optional start and end dates that restrict when content can be viewed - **Output modification**: Optional filters that trim or adjust the manifest Every asset needs at least one locator before it can be played. You can create multiple locators on the same asset, for example one for public access and one for DRM-protected access. Locator names must be unique within your project. ### Open the asset Go to **Assets** and click the name of the asset you want to publish. ### Add a streaming locator Scroll to the **Streaming Locators** section and click **+ Add Streaming Locator**.

You can also open the Streaming locator dropdown at the top of the asset page and choose + Add Streaming Locator.

### Configure the locator - **Name**: A unique identifier for this locator (for example, `public-access`). This appears in the playback URL path. - **Streaming policy**: Controls which protocols and protections apply. Common options:
Policy Use when
Predefined_ClearStreamingOnly Adaptive streaming (HLS/DASH) with no download or DRM
Predefined_DownloadAndClearStreaming Both streaming and direct file download, no DRM
Predefined_MultiDrmCencStreaming HLS/DASH protected with Widevine and PlayReady
For protected content, you also need a content key policy. See [Content protection](/mkio/understanding/core-concepts/content-protection). - **Content key policy**: Required when using a DRM streaming policy. Leave empty for clear streaming. - **Start time** (optional): The earliest date and time the content is accessible. Leave empty for immediate access. - **Expiration time** (optional): The date and time the locator expires and content becomes unavailable. Leave empty for content that does not expire. - **Asset filter** (optional): Limits or modifies the output for this asset specifically. See [Create an asset filter](/mkio/how-to/content-management/create-an-asset-filter). - **Account filter** (optional): An account-level filter applied across all assets on this locator. - **Streaming locator ID** (optional): A custom UUID. MK.IO auto-generates one if left empty. ### Create the locator Click **Add**. The locator appears in the Streaming Locators list with its generated ID. ## Apply the endpoint and locator to your asset With both components created, link them to the asset to generate the playback URLs. ### Select a streaming endpoint On the asset page, open the **Streaming Endpoint** dropdown and select your running endpoint. Only running endpoints appear in this list. ### Select a streaming locator Open the **Streaming locator** dropdown and select the locator you created. ### Apply Click **Apply**. MK.IO generates the playback URLs and displays them at the top of the asset page. Your asset's HLS and DASH playback URLs are now available. You can copy them for use in players, embed them in your application, or test them directly in the built-in MKPlayer on the asset page. **Playback URL format:** ```text https://..streaming.mediakind.com//.ism/manifest(format=m3u8-cmaf) https://..streaming.mediakind.com//.ism/manifest(format=mpd-time-cmaf) ``` ## Next steps [DRM content protection](/mkio/how-to/drm-content-protection) Protect your content with Widevine, PlayReady, or FairPlay DRM. [MKPlayer SDK](/mkio/reference/player-sdk) Embed content in your app using the MediaKind player. [Amazon CloudFront](/mkio/how-to/content-delivery-publishing/integrating-amazon-cloudfront) Add a CloudFront CDN in front of your AWS streaming endpoint. [Asset filters](/mkio/how-to/content-management/create-an-asset-filter) Trim or modify content delivery without re-encoding. Use the [Publishing API Guide](/mkio/api-guides/how-to/media/publishing) to automate streaming endpoints and locators through the Media API. # Assets and storage Assets organize the source files and outputs used by live and VOD workflows. Connect storage first, then choose how MK.IO should add or reference your media. ## Connect storage - [Connect cloud storage](/mkio/getting-started/connect-cloud-storage) through the portal. - [Configure storage with the Media API](/mkio/api-guides/how-to/media/storage), including the `Google.Storage` provider defined by the API. - [Configure private storage access](/mkio/how-to/security-access-control/private-storage-link) when your storage does not use public network access. ## Add assets [Choose an asset workflow](/mkio/how-to/content-management/add-an-asset-in-mkio) Compare upload, existing storage, and Azure Media Services import workflows. [Reference existing storage](/mkio/how-to/content-management/add-an-asset-in-mkio/reference-existing-storage) Create an asset that references files already held in Azure Blob Storage or Amazon S3. [Upload from your device](/mkio/how-to/content-management/add-an-asset-in-mkio/import-files-from-your-device) Upload local files to a new MK.IO asset. [Import AMS assets](/mkio/how-to/content-management/add-an-asset-in-mkio/import-your-ams-assets) Import assets from Azure Media Services storage. ## Manage assets - [Add files to an existing asset](/mkio/how-to/content-management/add-files-to-an-existing-asset) - [Verify asset files and tracks](/mkio/how-to/content-management/verify-your-assets-in-mkio) - [Create an asset filter](/mkio/how-to/content-management/create-an-asset-filter) - [Publish imported assets](/mkio/how-to/content-management/playback-your-migrated-assets) For automation, use the [Assets API Guide](/mkio/api-guides/how-to/media/assets) and [Playback filters API Guide](/mkio/api-guides/how-to/media/playback-filters). # Create an asset An asset in MK.IO is a container for your media content: it groups your video, audio, subtitle files, and encoding outputs together and links them to a location in your cloud storage (Azure Blob Storage or Amazon S3). You create an asset first, then add content to it.

You need at least one storage account connected before creating assets. See Connect cloud storage.

## Steps ### Go to Assets Navigate to **Assets** in the left sidebar and click **+ Create Asset**. ### Choose a source - **From a storage account**: Creates an asset linked to your cloud storage. Use this when pointing to existing files or creating an empty location for new files. - **From local files**: Uploads files from your device and creates the asset in one step. See [Upload from your device](/mkio/how-to/content-management/add-an-asset-in-mkio/import-files-from-your-device). ### Fill in the details
Field Description
Storage account The connected Azure or S3 account where this asset's files will live
Storage container The container (Azure) or bucket (S3) name. Use lowercase letters, numbers, and hyphens.
Storage directory Optional subfolder path within the container
Asset name The display name you will see in MK.IO
Description Optional notes
Upon asset deletion Whether deleting the asset also deletes files from storage. You cannot change this setting later.
### Create Click **Add**. The asset is created and linked to the storage location you specified.

If you point to an existing container and the asset appears empty, the container name may be misspelled or the wrong storage account selected. The field is case-sensitive. See Verify your assets for troubleshooting.

## Next steps Once the asset exists, add content and prepare it for streaming: [Content already in Azure or S3](/mkio/how-to/content-management/add-an-asset-in-mkio/reference-existing-storage) Point an asset at existing cloud storage, find the container name, and troubleshoot empty assets. [Upload from your device](/mkio/how-to/content-management/add-an-asset-in-mkio/import-files-from-your-device) Upload files from your computer directly into the asset. [Verify the asset](/mkio/how-to/content-management/verify-your-assets-in-mkio) Confirm files and tracks are visible before publishing. [Migrating from AMS?](/mkio/how-to/content-management/add-an-asset-in-mkio/import-your-ams-assets) Reference existing AMS asset containers without re-encoding. ## Automate asset management Use the [Assets API Guide](/mkio/api-guides/how-to/media/assets) to create assets, reference source files, retrieve tracks, and manage asset lifecycle operations through the Media API. # Bulk import your AMS assets Practical steps for bulk importing video assets using MediaKind’s migration tool. Importing a large video library from Azure Media Services one at a time can be impractical and time-consuming. Below is a walk-through of how to leverage MediaKind’s bulk-ingest tool for a smooth and quick bulk migration of video assets: - from your AMS storage account to MK.IO - OR from one MK.IO subscription to another MK.IO subscription. You can retrieve the script for the MK.IO bulk-ingest tool in this public GitHub repository: [mediakind-video/ams-migration-tool](https://github.com/mediakind-video/ams-migration-tool). ## Import your assets 1. Navigate to the **Media Services** section of your AMS portal. 2. Enter the MK.IO portal under the subscription instance to which you want to import your AMS assets. 3. Build the program using the bulk-ingest script using the binary from [our public GitHub repository](https://github.com/mediakind-video/ams-migration-tool). 4. In the command-line terminal, type in _mkio-ams-migration_. 5. Import is available from AMS to MK.IO or from MK.IO subscription to MK.IO subscription in the same account. 6. Populate the below parameters and their values:
Option Value
--azure-subscription* Your Azure AMS account > Overview > Essentials > Subscription ID
--azure-resource-group Your Azure AMS account > Overview > Essentials > Resource Group
--azure-account-name Your Azure account ID
--mediakind-import-subscription Your subscription name, found under Dashboard > Subscription Summary
--mediakind-export-subscription Your subscription name, found under Dashboard > Subscription Summary
--export Pulls data from Azure Media Services (or MK.IO), creating a JSON file as output.
--import Reads the JSON file and inserts data into MK.IO.
--validate Validates imported assets.
--assets Boolean: option defaults to false, but will set to true if flags are added.
--asset-filters Boolean: option defaults to false, but will set to true if flags are added.
--streaming-locators Boolean: option defaults to false, but will set to true if flags are added.
--content-key-policies Boolean: option defaults to false, but will set to true if flags are added.
--streaming-endpoints Boolean: option defaults to false, but will set to true if flags are added.
--streaming-policies Boolean: option defaults to false, but will set to true if flags are added.
--migration-file value Specify migration file to use for import and/or export.
--overwrite Overwrite resources that already exist.
--debug Enable debug logging while running the tool.
--workers Number of workers to process assetFilters in parallel.
--created-before Filters exports to resources created before the given date.
--created-after Filters exports to resources created after the given date.
To import from AMS to MK.IO the command will look like the example below: `./mkio-ams-migration --azure-subscription 29628ffc-5d07-4af3-88a8-3f710582a73b --azure-resource-group ams-test --azure-account-name amstest --mediakind-import-subscription migration --export --import --assets --streaming-locators --asset-filters --content-key-policies --streaming-endpoints` To import from MK.IO subscription to MK.IO subscription in the same MK.IO account, the command will look like the example below: `./mkio-ams-migration --mediakind-export-subscription mkioexportsubscription --mediakind-import-subscription mkioimportmigration --export --import --assets --streaming-locators --asset-filters --content-key-policies --streaming-endpoints` 7. Run the migration using the information gathered in **Setup.** You can view the migration progress in the command terminal as the steps complete.

Need some help with your bulk migration from AMS to MK.IO? Take a look at this tutorial in our support portal or visit the MediaKind support center.

# Upload files from your device Use this method when you have media files on your local machine that you want to bring into MK.IO. The upload creates a new asset and copies the files directly into your connected cloud storage (Azure or S3).

You need at least one storage account connected to your MK.IO project before uploading. See Connect cloud storage.

## Supported file types You can upload any of the following: - **Video**: MP4, MOV, MXF, MKV, AVI, TS - **Audio**: MP3, AAC, WAV - **Subtitles / captions**: VTT, SRT, TTML - **Images**: JPG, PNG (for thumbnails) For production streaming, MP4 (H.264/AAC) is the most reliable source format for encoding jobs. ## Upload steps ### Go to Assets Navigate to **Assets** in the left sidebar and click **+ Create Asset**. ### Select "From local files" Choose the **From local files** option. A file picker and upload form appear. ### Select your files Click to browse for files or drag and drop them into the upload area. You can select multiple files at once: they will all be added to the same asset. ### Configure the asset - **Storage account**: Select the connected storage account where the files will be uploaded. Both Azure and S3 accounts appear here if connected. - **Storage container**: The name of the container or folder that will be created in your cloud storage to hold these files. Use lowercase letters, numbers, and hyphens. - **Asset name**: A display name for this asset in MK.IO (for example, `interview-raw-2024`). This is what you will see in the Assets list. - **Description** (optional): Notes about this content. ### Upload Click **Upload**. MK.IO transfers the files to your cloud storage and creates the asset. Upload time depends on file size and your connection speed. Once the upload completes, the asset appears in your **Assets** list. Open it to verify your files are listed under **Files on storage**. ## What to do next - **Verify the upload**: See [Verify your assets](/mkio/how-to/content-management/verify-your-assets-in-mkio). - **Encode for streaming**: Raw files need to be encoded into adaptive bitrate format before they can be published. See [Configure VOD transforms](/mkio/how-to/video-processing-encoding/configure-transformations). - **Publish**: After encoding, add a streaming locator. See [Publish content for streaming](/mkio/how-to/content-delivery-publishing/stream-content). # Import your AMS assets Use this workflow to migrate assets from **Azure Media Services (AMS)**. For other content in Azure Blob Storage or Amazon S3, use [Reference existing cloud storage content](/mkio/how-to/content-management/add-an-asset-in-mkio/reference-existing-storage). MK.IO references your existing AMS asset containers directly: no re-encoding or file movement needed. Your files stay exactly where they are in Azure Storage.

Azure Media Services has been retired. MK.IO is a drop-in replacement: your existing AMS streaming locators, content key policies, and asset containers can all be migrated.

## Import your assets Three approaches are available depending on your scale and tooling preference.

Whatever the approach, your assets remain in their Azure storage after migration: MK.IO does not copy or move them.

## Using the MK.IO web interface 1. From the MK.IO dashboard view, go to **Storage** from the left-hand side menu. 2. Select the **Add Azure storage** option then fill in the required information:
Parameter Description
Storage Account From the drop down, select the connected Storage Account linked to your MK.IO account, where the hosted assets lives in your Azure Storage Account.
Storage container Enter the name of the specific container where the hosted assets lives in your Azure Storage Account.

In AMS, each asset is stored in a specific container. You can confirm the storage container name by navigating to the Assets view in AMS, locating your 'output' asset name you need to migrate and copying the name of the 'Storage Link' field. This will typically start with an asset-XXX naming convention and point to the container where the associated files are stored.
Sub-container (optional) Enter the name of the sub-container if any.
Asset name The unique identifier you want to use in MK.IO for that asset.
Description Provide an optional description for that asset.
Upon asset deletion Choose whether you want to preserve the container upon asset deletion.
When you click **Add,** the files will be uploaded and a new asset will be saved in your list. MK.IO will connect, ingest, and make the content available to be configured for streaming. ## Using Azure Media Services Migration tool from MediaKind All the steps are detailed in [Bulk asset migration from AMS storage](/mkio/how-to/content-management/add-an-asset-in-mkio/bulk-asset-migration-from-ams-storage). ## Using Azure Media Services Explorer tool You can retrieve the AMS Explorer tool in this public GitHub repository: This version of the Azure Media Services Explorer supports creating assets in MK.IO from existing AMS assets. # Reference existing cloud storage content If you already have media files in Azure Blob Storage or Amazon S3, you can reference them in MK.IO without moving, re-encoding, or copying anything. MK.IO creates an asset that maps directly to the existing container or prefix in your storage, and streams content from there.

This only works for storage accounts that are already connected to your MK.IO project. If you have not connected storage, see Connect cloud storage first.

## Before you start: find your container details You need the exact name of the container (Azure) or bucket/prefix (S3) where your files live. The container name is **case-sensitive** and must match exactly: even a small typo will result in an empty asset. **Azure Blob Storage:** 1. Open the [Azure Portal](https://portal.azure.com) and navigate to your Storage Account. 2. In the left menu, select **Containers**. 3. Copy the exact name of the container that holds your media files. 4. If your files are in a subfolder within that container, note the folder path (for example, `videos/2024/campaign`). **Amazon S3:** 1. Open the [AWS S3 Console](https://s3.console.aws.amazon.com). 2. Find your bucket and navigate to the folder containing your media files. 3. Note the bucket name and the full folder path (for example, `my-bucket` with prefix `content/episodes/`). ## Create an asset from existing storage ### Go to Assets Navigate to **Assets** in the left sidebar and click **+ Create Asset**. ### Select "From a storage account" Choose the **From a storage account** option. This mode lets you point the asset at an existing location in your connected cloud storage. ### Select your connected storage account From the **Storage Account** dropdown, choose the storage account that contains your files. Only storage accounts that have already been connected to MK.IO appear here. ### Enter the container name In the **Storage container** field, type the exact name of your existing container (Azure) or bucket (S3). This must already exist and contain your media files.

This field is case-sensitive. If your container is named Media-Assets and you type media-assets, MK.IO will create an empty container and your asset will appear empty. Double-check the spelling against your cloud storage console.

### Set the storage directory (if files are in a subfolder) If your media files are in a subfolder within the container, enter the folder path in the **Storage directory** field (for example, `episodes/season-1`). Leave this empty if your files are at the root of the container. ### Name the asset Enter a name for this asset in MK.IO. This is the display name you will see in MK.IO: it does not need to match the container name. ### Create the asset Click **Add**. MK.IO creates the asset and immediately scans the storage location. If files are present, you will see them listed in the **Files on storage** section of the asset page within a few seconds. ## Verify the asset has loaded correctly After creation, open the asset and check: 1. **Files on storage**: You should see your media files listed with their names and sizes. If this section is empty, see [Why is my asset empty?](/mkio/how-to/content-management/add-an-asset-in-mkio/reference-existing-storage#why-is-my-asset-empty) below. 2. **Tracks**: If you have pre-encoded content (with `.ism` manifest and encoded segments), tracks will be detected automatically. If you have only a raw source file, you need to run an encoding job before tracks appear. See [Verify your assets](/mkio/how-to/content-management/verify-your-assets-in-mkio) for full verification steps. ## Why is my asset empty? If the **Files on storage** section shows no files after creation, check the following: **Container name does not match** The most common cause. Go to your cloud storage console and confirm the exact spelling and casing of the container name. Update the asset or delete it and recreate it with the correct name. **Wrong storage account selected** If you have multiple storage accounts connected, ensure you selected the one that contains the files. **Files are in a subfolder but directory was left empty** If your files are at `my-container/episodes/show-1/` and you set the container to `my-container` but left the directory empty, MK.IO looks at the root of the container. Set the **Storage directory** to `episodes/show-1`. **Storage account credentials have expired** SAS tokens and access keys can expire. Go to **Storage** in the left navigation and check that your storage account status is active. If credentials have expired, update them and try again. **Content type not yet supported** MK.IO indexes files with recognised media extensions. Very unusual file types or non-standard extensions may not appear in tracks even if files are present. ## What to do next Once your asset shows files in storage, you can proceed based on what type of content you have: - **Pre-encoded content** (`.ism` manifest + encoded segments from AMS or another encoder): Add a streaming locator and publish directly. See [Publish content for streaming](/mkio/how-to/content-delivery-publishing/stream-content). - **Raw source files** (MP4, MXF, MOV): Run an encoding transform to produce adaptive bitrate output. See [Configure VOD transforms](/mkio/how-to/video-processing-encoding/configure-transformations). - **Files you need to add**: See [Add files to an existing asset](/mkio/how-to/content-management/add-files-to-an-existing-asset). # Add files to an existing asset You can add files to an asset at any point after it is created. Common reasons to add files include: - **Adding subtitle or caption files** (`.vtt`, `.srt`): Make your content accessible with captions without re-encoding. - **Adding additional audio tracks**: Attach alternate language dubs or audio descriptions to the same asset. - **Uploading an original source file**: Reference the master file alongside the encoded outputs. - **Replacing or supplementing encoded outputs**: Add a new encoded version alongside existing ones. Files you upload are stored in the asset's cloud storage container. After uploading, MK.IO detects the new files and they appear in the asset's **Files on storage** list. ## Steps ### Open the asset Go to **Assets** in the left navigation and click the name of the asset you want to update. ### Navigate to Files on storage Scroll down to the **Tracks** section and select the **Files on storage** tab. This lists all files currently stored in the asset's container. ### Add files Click **+ Add Files**. A file picker opens: you can click to browse or drag and drop files directly. ### Upload Select your file or files and click **Upload**. MK.IO transfers the files to the asset's cloud storage container.

After uploading, MK.IO reflects the new files in the asset immediately. If you upload a subtitle or audio track file, you may need to create a new transform job or use the track insertion feature to attach it formally to the manifest. See Add a track to a VOD asset.

## Supported file types MK.IO accepts any file type in an asset container: the asset is a general-purpose storage container. However, only recognised media formats are processed for streaming: - **Video**: `.mp4`, `.mov`, `.mxf`, `.ts`, and other common formats - **Audio**: `.mp3`, `.aac`, `.wav` - **Subtitles**: `.vtt`, `.srt`, `.ttml` - **Manifests**: `.ism`, `.mpd`, `.m3u8` (generated by encoding jobs) If you need to add a subtitle track to an already-encoded asset without re-encoding, see [Add a track to a VOD asset](/mkio/reference/encoding-transform-presets/add-a-track-to-a-vod-asset). # Create an asset or account filter When delivering content through live streaming or Video on Demand (VOD), you may need more flexibility than the default asset manifest provides. MK.IO can generate dynamic manifests based on predefined filters. Filters allow you to define specific subsets of your media content within an Asset that will be available to viewers. Filters can be based on time constraints and track constraints. You can combine multiple constraints in a single filter. - **Time range constraints**: You can select specific portions of the media content to show to viewers by defining the start and end times. For live media, you can also define the maximum rewind window and the broadcast delay. - **Track constraints**: You can select tracks (video, audio and text) and the associated qualities that you want to make available to target specific viewers. For example, you can filter on a specific language or/and on a particular video bitrate.

Asset filters can only be applied to the asset with which they were created, and last as long as the asset exists. Account filters can be applied to any asset in your account, and last for the lifetime of the account.

## Preserve required track types When you configure track constraints for an asset filter in the MK.IO interface, do not assume that an unmentioned track type remains in the filtered manifest. A filter that contains only an Audio or Text rule can omit required Video or Audio tracks. The resulting manifest may fail playback or contain audio without video. It may also return a Hypertext Transfer Protocol (HTTP) 500 response. Add an explicit rule for every track type that the filtered manifest must retain. Broad bitrate ranges can preserve Video and Audio tracks while a separate rule excludes a specific language or named track. For example, use these constraints to preserve Video and Audio tracks while excluding the Audio track named `audio-spanish`:
Track Type Value
Video Bitrate = 1-
Audio Bitrate = 1-
Audio Name ≠ audio-spanish
Use these constraints to preserve Video and Audio tracks while excluding Polish subtitles:
Track Type Value
Video Bitrate = 1-
Audio Bitrate = 1-
Text Language ≠ pl-PL
The range `1-` includes tracks with a bitrate of 1 bit per second (bps) or higher. If you use a more restrictive bitrate range or a four-character code (FourCC) rule, match the value to the renditions and codecs in the asset. A filter value that does not match the asset's track metadata can remove a required stream. To create an asset filter or an account filter: 1. Log in to [MK.IO](https://app.mk.io) and select a subscription. 2. From the left-hand side menu, navigate to **Assets** to see your list of available assets, then click on the name of the asset for which you want to create an asset filter. This will display the asset's properties. 3. Scroll to the bottom of the page to find the **Asset filters** or **Account filters** panel, which lists any filter already applied to that asset, then click **+ Add Asset filter** or **+ Add Account filter** depending on your needs. 4. Enter a name for the asset filter then select the filter type. - For a time constraints-based filter, select if the time range is based on timestamp or on UTC date & time (live event only), then fill in the required information. For live media, you can also define the maximum rewind window and the broadcast delay. - For a track constraints-based filter select the tracks (video, audio, or text) and the associated qualities that you want to include or exclude in the output. You can create as many filters as needed.
Type Possible values
Bitrate The bitrate (in bps) can be specified as a single numeric value (for example, 100000) or as a range (for example, 500000-1000000). The range can also be partial. 1000000- includes any track with a bitrate of 1,000,000 bps or higher, while -1000000 includes any track with a bitrate of 1,000,000 bps or lower.
FourCC The video codec may be avc1, hev1, or hvc1. The audio codec may be mp4a or ec-3.
Language Language tag to include, as specified in RFC 5646 (see https://datatracker.ietf.org/doc/html/rfc5646).
Name Name of the track as specified in the manifest.
Values are not case-sensitive. 5. Click **Create** to validate the creation of the asset filter. Once created, you will be able to [associate your filter with a **Streaming Locator**](/mkio/how-to/content-delivery-publishing/stream-content#create-a-streaming-locator). ## Verify playback Apply the filter to a streaming locator, then request the playback URL. Confirm that: - The manifest request succeeds without an HTTP 500 response. - Video and each required Audio track play. - The track targeted by the exclusion rule is absent. If playback fails or a required track is missing, compare every filter value with the asset's track metadata. Adjust the preservation rules to match the asset before testing again. ## Configure filters with the API Use the [Playback filters API Guide](/mkio/api-guides/how-to/media/playback-filters) to create asset or account filters and apply them when publishing content. # Enable assets for streaming After you import, upload, or create assets in MK.IO, you need two components before viewers can play them: - A **Streaming Endpoint**: the origin server that serves content to players and CDNs - A **Streaming Locator**: attached to each asset, it generates playback URLs and controls access For full step-by-step instructions including configuration options, streaming policies, and DRM, see [Publish content for streaming](/mkio/how-to/content-delivery-publishing/stream-content). ## Quick steps ### Create and start a streaming endpoint Go to **Streaming Endpoints** and click **+ Create Streaming Endpoint**. Give it a name, choose **Shared** for testing or **Dedicated** for production, and start it.

Running streaming endpoints incur costs even when idle. Stop endpoints you are not actively using.

### Create a streaming locator on your asset Open the asset, scroll to **Streaming Locators**, and click **+ Add Streaming Locator**. Give it a unique name and select `Predefined_ClearStreamingOnly` for basic unprotected streaming. ### Apply and get playback URLs Select your running endpoint and the locator from the dropdowns on the asset page, then click **Apply**. MK.IO generates HLS and DASH playback URLs immediately. ### Test playback Use the built-in MKPlayer on the asset page to verify the stream plays correctly before distributing the URLs. ## Migrating from Azure Media Services If you are enabling playback for assets imported from AMS: - Your existing content does not need to be re-encoded: MK.IO streams files directly from your connected Azure storage. - Streaming locator names from AMS are not automatically carried over. Create new locators with your preferred names in MK.IO. - If you previously used AMS streaming endpoints, remember that MK.IO endpoint names form part of the playback URL. Choose names that reflect your production setup. For large-scale AMS migrations, see [Bulk asset migration from AMS storage](/mkio/how-to/content-management/add-an-asset-in-mkio/bulk-asset-migration-from-ams-storage). # Verify your assets in MK.IO After creating, importing, or running an encoding job on an asset, verify that MK.IO has correctly indexed the content before publishing. This helps you catch storage configuration issues or encoding errors early. ## What to check On the asset page, scroll down to see two key sections: - **Tracks**: Shows the video, audio, and subtitle tracks MK.IO has detected in the asset's files. After a successful encoding job, you see entries for each resolution, audio track, and any included subtitles. If this section is empty after encoding, something went wrong. - **Files on storage**: Lists every file in the asset's cloud storage container, along with file size and last-modified date. This updates as files are added or generated. ## Steps ### Open the asset Go to **Assets** and click the asset name you want to verify. ### Check Tracks Scroll to the **Tracks** section. After an encoding job completes, you should see rows for each video track (labelled by resolution), each audio track, and any subtitle tracks. ### Check Files on storage Select the **Files on storage** tab. You should see the source files you uploaded and output files generated by encoding, including `.ism` manifest files, encoded video chunks, and log files. ## Troubleshooting **No tracks appear after an encoding job** The encoding job may have failed. Go to **Video Processing** > **Jobs** and check the status of the job. If it shows **Error**, open the output asset and check the `highlevel.log` file in **Files on storage**. This file contains diagnostic details you can share with MK.IO support. **Files on storage is empty** Your cloud storage may not be connected correctly, or the asset was created pointing to an empty container. - Confirm your storage account is still connected and credentials have not expired. Go to **Storage** in the left navigation and check the status. For help reconnecting, see [Connect cloud storage](/mkio/getting-started/connect-cloud-storage). - Check that the container name in the asset matches an actual container in your cloud storage. **Files appear but Tracks section is empty** MK.IO detects tracks from encoded output files (manifest + encoded segments). If you see only a raw source file (for example, `source.mp4`) with no `.ism` file, the asset has not been encoded yet. Run an encoding job first. See [Configure VOD transforms](/mkio/how-to/video-processing-encoding/configure-transformations). **Asset looks correct but content does not play** Tracks and files being present means the content is stored and indexed correctly. Playback also requires a streaming endpoint and streaming locator. See [Publish content for streaming](/mkio/how-to/content-delivery-publishing/stream-content).

If you have checked the above and still cannot see your assets, visit the MK.IO support portal for further help.

# Content key policies Digital Rights Management (DRM) encrypts your media content so that only authorized players and devices can decrypt and play it back. MK.IO handles DRM key management and license delivery, so you can protect live and VOD streams without running your own license server. ## How DRM works in MK.IO DRM protection in MK.IO relies on three components working together: 1. **Content key policy**: defines which encryption schemes to use (ClearKey, Widevine, PlayReady, FairPlay) and whether a JWT token is required for license acquisition. 2. **Streaming policy**: determines the encryption format applied to your packaged streams (CENC or CBCS). 3. **Streaming locator**: ties an asset to a streaming policy and content key policy, producing encrypted playback URLs and license acquisition URLs. When a player requests a protected stream, it contacts the MK.IO license server with the appropriate credentials. MK.IO validates the request, issues the decryption key or license, and the player decrypts the stream for playback. ## Encryption types MK.IO supports four encryption modes. Choose the one that matches your security requirements and target platforms.
Encryption type Protocols Encryption format Use case
ClearKey HLS, DASH HLS: CBCS, DASH: CENC Lowest latency encryption. Suitable for basic protection and testing.
Widevine HLS, DASH CENC Chrome, Android, smart TVs, and other Widevine-licensed devices.
PlayReady HLS, DASH CENC Edge, Xbox, Windows devices, and PlayReady-licensed smart TVs.
FairPlay HLS only CBCS Safari and Apple devices. Requires an Apple FairPlay certificate.

Do not add ClearKey to a policy that also uses DRM schemes (Widevine, PlayReady, or FairPlay). Combining ClearKey with DRM reduces the security effectiveness of the policy.

## Streaming policy and encryption pairing When you create a streaming locator, the streaming policy you select must match the content key policy. MK.IO provides predefined streaming policies for common configurations:
Streaming policy Required DRM schemes Notes
Predefined_ClearStreamingOnly None No encryption. Use for testing unprotected playback.
Predefined_ClearKey ClearKey Basic encryption without a full DRM license server.
Predefined_MultiDrmStreaming Widevine, PlayReady, and FairPlay Full multi-DRM. The content key policy must include all three schemes.
Predefined_MultiDrmCencStreaming Widevine and PlayReady CENC-only multi-DRM. No FairPlay required.
## DRM support by platform Each browser and platform supports specific DRM systems. The player automatically selects the correct DRM based on the environment.
Platform Recommended DRM Protocol
Chrome, Firefox, Android Widevine DASH
Safari, iOS, macOS FairPlay HLS
Edge (Windows) PlayReady DASH
Smart TVs (varies) Widevine or PlayReady DASH
For a detailed compatibility matrix, refer to the [Bitmovin DRM support reference](https://developer.bitmovin.com/playback/docs/drm-content-protection). ## High-level workflow Follow these steps to protect and play back an encrypted asset: 1. **Verify your asset plays unencrypted.** Create a streaming locator with `Predefined_ClearStreamingOnly` and confirm playback works before adding encryption. 2. **[Create a content key policy](/mkio/how-to/drm-content-protection/create-content-key-policy)** with your chosen DRM schemes and token settings. 3. **Create a streaming locator** that references both your streaming policy and content key policy. 4. **[Test playback](/mkio/how-to/drm-content-protection/test-drm-playback)** using MKPlayer or your player SDK with the encrypted URLs and license acquisition URLs. ## Guides [Create a Content Key Policy](/mkio/how-to/drm-content-protection/create-content-key-policy) Configure DRM schemes and token restrictions. [ClearKey Encryption](/mkio/how-to/drm-content-protection/clearkey-encryption) Set up basic encryption with or without JWT tokens. [Multi-DRM Encryption](/mkio/how-to/drm-content-protection/multi-drm-encryption) Configure Widevine, PlayReady, and FairPlay together. [JWT Token Authentication](/mkio/how-to/drm-content-protection/jwt-token-authentication) Generate and configure JWT tokens for license requests. [Test DRM Playback](/mkio/how-to/drm-content-protection/test-drm-playback) Validate encrypted playback with MKPlayer. ## Automate content protection Use the [Content protection API Guide](/mkio/api-guides/how-to/media/content-protection) to create content key policies and protected streaming locators through the Media API. ## Advanced configuration [External PlayReady License](/mkio/how-to/drm-content-protection/external-playready-license-url) Use a third-party PlayReady license server. [Explicit Content Keys](/mkio/how-to/drm-content-protection/explicit-content-keys) Define your own encryption keys instead of auto-generated ones. [RSA Key for Token Validation](/mkio/how-to/drm-content-protection/rsa-key-for-token-validation) Use RSA keys instead of symmetric keys for JWT validation. [OpenID Verification Key](/mkio/how-to/drm-content-protection/openid-verification-key) Delegate token validation to an external identity provider. [Custom Claims in Policies](/mkio/how-to/drm-content-protection/custom-claims) Use custom JWT claims to select between multiple policy options. # ClearKey Encryption ClearKey provides basic content encryption with the lowest possible latency for media encryption and decryption. It works with both HLS and DASH playback. ClearKey does not use a full DRM license server, making it simpler to set up than Widevine, PlayReady, or FairPlay. ## Prerequisites - A running streaming endpoint. - An asset verified to play without encryption using `Predefined_ClearStreamingOnly`. ## ClearKey without token restriction Use this configuration when you want basic encryption without requiring a JWT token for license acquisition. This is useful for testing or low-security scenarios. ### Create the content key policy 1. Navigate to **Content Key Policies** and select **Create Content Key Policy**. 2. Enter a descriptive **name** (for example, `clearkey-open`). 3. Select **Add** next to the **Clear Key** section. 4. Enter a **policy option name**. 5. Under **Use token restriction**, select **No**. 6. Select **Add**, then **Create**. ### Create a streaming locator 1. Navigate to your asset and select **Add streaming locator**. 2. Enter a **name** for the locator. 3. Set **Streaming policy** to `Predefined_ClearKey`. 4. Set **Content key policy** to the ClearKey policy you created. 5. Select **Add**. ### Get the playback URLs Select the streaming locator you created, choose a running streaming endpoint, and select **Apply**. MK.IO generates HLS and DASH playback URLs. ### Test playback 1. Navigate to the **MKPlayer** page. 2. Select **HLS** as the protocol and **ClearKey** as the DRM. 3. Paste the HLS playback URL. 4. Select **Play**. For DASH playback, select **DASH** as the protocol and provide the ClearKey license acquisition URL: this URL is displayed at the bottom of the asset streaming locator page. ## ClearKey with JWT token restriction Add a JWT token requirement to ClearKey encryption for an additional layer of access control. ### Create the content key policy 1. Navigate to **Content Key Policies** and select **Create Content Key Policy**. 2. Enter a descriptive **name** (for example, `clearkey-jwt`). 3. Select **Add** next to the **Clear Key** section. 4. Enter a **policy option name**. 5. Under **Use token restriction**, select **Yes**. 6. Configure the token fields: - **Token type**: `JWT` - **Issuer**: a string of your choice (for example, your company name). - **Audience**: a string of your choice (for example, your audience identifier). - **Primary verification key**: a Base64-encoded string. You can generate this by encoding a passphrase at a site such as `base64encode.org`. For example, encoding `mycompanyaudience` produces `bXljb21wYW55YXVkaWVuY2U=`. 7. Select **Add**, then **Create**. ### Create a streaming locator 1. Navigate to your asset and select **Add streaming locator**. 2. Enter a **name** for the locator. 3. Set **Streaming policy** to `Predefined_ClearKey`. 4. Set **Content key policy** to the ClearKey JWT policy you created. 5. Select **Add**, then select the locator and select **Apply**. The player page may show a `DRM_FAILED_LICENSE_REQUEST` error. This is expected because the encrypted stream requires a JWT token that has not been provided yet. ### Generate a JWT token Follow the [JWT token authentication guide](/mkio/how-to/drm-content-protection/jwt-token-authentication) to generate a token using the same issuer, audience, and primary verification key you configured in the content key policy. ### Test playback 1. Navigate to the **MKPlayer** page. 2. Select your protocol (**HLS** or **DASH**) and **ClearKey** as the DRM. 3. Paste the playback URL in **Source URL**. 4. For HLS: the license URL is auto-populated (`HLS_AES`). For DASH: paste the ClearKey license acquisition URL. 5. In the **License request headers** field, enter the authorization header with your JWT token: ```json {"Authorization": "Bearer "} ``` 6. Select **Play**. # Create a Content Key Policy A content key policy defines which DRM encryption schemes protect your content and whether viewers must present a JWT token to obtain a decryption license. You create the policy once and reference it from any number of streaming locators. ## Prerequisites - A running streaming endpoint. - An asset ready for playback. Verify it plays without encryption using a `Predefined_ClearStreamingOnly` streaming locator before adding DRM. ## Choose your policy type Before creating a policy, decide which DRM schemes you need. This determines which predefined streaming policy you will pair it with later.
If you need Create a policy with Pair with streaming policy
Basic encryption only ClearKey Predefined_ClearKey
Widevine and PlayReady (no FairPlay) Widevine + PlayReady Predefined_MultiDrmCencStreaming
Widevine, PlayReady, and FairPlay Widevine + PlayReady + FairPlay Predefined_MultiDrmStreaming

A Predefined_MultiDrmStreaming policy requires all three DRM schemes (Widevine, PlayReady, and FairPlay) in the content key policy. A Predefined_MultiDrmCencStreaming policy requires both Widevine and PlayReady. If the content key policy does not include the required schemes, creating the streaming locator will fail.

## Create a policy in the UI ### Open the Content Key Policies page Navigate to **Content Key Policies** from the left-hand menu and select **Create Content Key Policy**. ### Name your policy Enter a **name** for the policy and an optional **description**. Use a descriptive name that indicates the encryption type and token setting, such as `multidrm-jwt` or `clearkey-open`. ### Add encryption schemes Add the DRM schemes your policy requires: - For ClearKey: select **Add** next to the **Clear Key** section. - For DRM: select **Add** in the **Digital Rights Management** section, then add each scheme individually (**Add Widevine**, **Add PlayReady**, **Add FairPlay**). For each scheme, configure: 1. **Policy option name**: a recognizable label for this scheme within the policy. 2. **Use token restriction**: select **Yes** to require a JWT token for license acquisition, or **No** for open access. 3. If token restriction is enabled, provide: - **Token type**: select `JWT`. - **Issuer**: a string identifying who issued the token (for example, your company name or service identifier). - **Audience**: a string identifying the intended recipient of the token. - **Primary verification key**: a Base64-encoded symmetric key used to validate the JWT signature. 4. For Widevine: optionally provide a **Widevine template** (defaults to `{}`). 5. For PlayReady: optionally configure PlayReady-specific license settings. 6. For FairPlay: provide the Apple FairPlay **certificate**, **password**, and **application secret key**. Select **Add** to save each scheme.

Use the same issuer, audience, and primary verification key values across all DRM schemes in a single policy. These values must match the JWT token you generate for playback.

### Create the policy Select **Create** at the bottom of the page. The policy appears in the **Content Key Policies** list and is ready to use in a streaming locator. ## What to do next - [Set up ClearKey encryption](/mkio/how-to/drm-content-protection/clearkey-encryption) for basic content protection. - [Set up Multi-DRM encryption](/mkio/how-to/drm-content-protection/multi-drm-encryption) for Widevine, PlayReady, and FairPlay. - [Generate a JWT token](/mkio/how-to/drm-content-protection/jwt-token-authentication) if your policy uses token restriction. # Custom Claims in Policies When a content key policy contains multiple options for the same DRM system, MK.IO needs a way to determine which option to use for a given license request. Custom claims in the JWT token solve this by letting MK.IO match the token's claims against the `requiredClaims` defined in each policy option. ## How custom claims work 1. You define `requiredClaims` on each policy option with a `claimType` and `claimValue`. 2. When a license request arrives, MK.IO inspects the JWT token for matching claims. 3. The policy option whose required claims match the token is selected for license delivery. This is useful when you want the same content key policy to serve different license configurations, for example, a persistent license and a time-limited license, based on the viewer's entitlements. ## Create a policy with custom claims Use the MK.IO API to create a content key policy with multiple options that use different required claims: ```bash curl --request PUT \ --url https://app.mk.io/api/v1/projects/project_name/media/contentKeyPolicies/content_policy_name \ --header 'accept: application/json' \ --header 'content-type: application/json' \ --header 'Authorization: Bearer ' \ --data ' { "properties": { "options": [ { "name": "widevine-persistent", "restriction": { "issuer": "issuer", "audience": "audience", "@odata.type": "#Microsoft.Media.ContentKeyPolicyTokenRestriction", "restrictionTokenType": "Jwt", "primaryVerificationKey": { "keyValue": "12345678", "@odata.type": "#Microsoft.Media.ContentKeyPolicySymmetricTokenKey" }, "requiredClaims": [ { "claimType": "persistency", "claimValue": "permanent" } ] }, "configuration": { "@odata.type": "#Microsoft.Media.ContentKeyPolicyWidevineConfiguration", "widevineTemplate": "{}" } }, { "name": "widevine-2h", "restriction": { "issuer": "issuer", "audience": "audience", "@odata.type": "#Microsoft.Media.ContentKeyPolicyTokenRestriction", "restrictionTokenType": "Jwt", "primaryVerificationKey": { "keyValue": "12345678", "@odata.type": "#Microsoft.Media.ContentKeyPolicySymmetricTokenKey" }, "requiredClaims": [ { "claimType": "persistency", "claimValue": "2hours" } ] }, "configuration": { "@odata.type": "#Microsoft.Media.ContentKeyPolicyWidevineConfiguration", "widevineTemplate": "{}" } } ], "description": "" } } ' ``` In this example, the policy has two Widevine options: - **widevine-persistent**: selected when the JWT token contains `"persistency": "permanent"`. - **widevine-2h**: selected when the JWT token contains `"persistency": "2hours"`. ## Include custom claims in the JWT token When generating the JWT token, add the custom claim to the payload: ```json { "iss": "issuer", "aud": "audience", "persistency": "permanent" } ``` MK.IO matches this claim against the `requiredClaims` in the policy options and selects the corresponding configuration for license delivery. The content key policy can then be used when preparing the asset for streaming. See [Stream live and VOD assets](/mkio/how-to/content-delivery-publishing/stream-content) for details. # Explicit Content Keys By default, MK.IO generates and propagates encryption keys for use with the key server and license server. You can override this behavior by defining your own key and key ID for any encryption type in a streaming locator. ## Create a streaming locator with explicit keys Use the MK.IO API to create a streaming locator that specifies `contentKeys` for CENC, CBCS, and ClearKey encryption: ```bash curl --request PUT \ --url https://app.mk.io/api/v1/projects/project_name/media/streamingLocators/locator_name \ --header 'accept: application/json' \ --header 'content-type: application/json' \ --header 'Authorization: Bearer ' \ --data ' { "properties": { "assetName": "ASSET_NAME", "streamingPolicyName": "SP_NAME", "contentKeys": [ { "id": "d1e755c0-14cd-491e-aafb-83277872dd3a", "type": "CommonEncryptionCenc", "labelReferenceInStreamingPolicy": "ContentKey_CENC", "value": "4UqLohAfWsEGkULYxHjYZg==", "policyName": "KP_NAME" }, { "id": "deaea8ec-5509-4c38-80a3-ab0767cd9bab", "type": "CommonEncryptionCbcs", "labelReferenceInStreamingPolicy": "ContentKey_CBCS", "value": "5UqLohAfWsEGkULYxHjYZg==", "policyName": "KP_NAME" }, { "id": "b1c4dcac-30cc-41f9-b09b-bf4d16226c91", "type": "EnvelopeEncryption", "labelReferenceInStreamingPolicy": "ContentKey_AES", "value": "6UqLohAfWsEGkULYxHjYZg==", "policyName": "KP_NAME" } ] } } ' ``` Each content key object requires:
Field Description
id A unique GUID for the key.
type The encryption type: CommonEncryptionCenc, CommonEncryptionCbcs, or EnvelopeEncryption.
labelReferenceInStreamingPolicy The label that maps this key to the corresponding encryption in the streaming policy.
value The Base64-encoded encryption key.
policyName The name of the content key policy to associate with this key.
When you define keys in the streaming locator, MK.IO propagates them to the key server and license server. MK.IO removes the keys when the streaming locator is deleted. ## Combine with external PlayReady For PlayReady, you can combine explicit content keys with an [external PlayReady license URL](/mkio/how-to/drm-content-protection/external-playready-license-url) to manage the entire DRM workflow outside of MK.IO. # External PlayReady License By default, MK.IO handles PlayReady license delivery for your content. If you need to use a separate license server, you can configure a custom license acquisition URL in a streaming policy. ## Configure an external license URL Create a streaming policy with a `customLicenseAcquisitionUrlTemplate` value for PlayReady using the MK.IO API: ```bash curl --request PUT \ --url https://app.mk.io/api/v1/projects/project_name/media/streamingPolicies/policy_name \ --header 'accept: application/json' \ --header 'content-type: application/json' \ --header 'Authorization: Bearer ' \ --data ' { "properties": { "commonEncryptionCenc": { "enabledProtocols": { "download": false, "dash": true, "hls": false, "smoothStreaming": false }, "contentKeys": { "defaultKey": { "label": "cencDefaultKey" } }, "drm": { "playReady": { "customLicenseAcquisitionUrlTemplate": "https://test.playready.microsoft.com/service/rightsmanager.asmx?cfg=(contentkey:eNqVnXrElmo2NSsn7IXeEA==,kid:e13a7861-d8cc-4284-9245-7c835ebde9f0)" } } } } } ' ``` Replace the `customLicenseAcquisitionUrlTemplate` value with the URL of your PlayReady license server. Use the streaming policy when preparing the asset for streaming. See [Stream live and VOD assets](/mkio/how-to/content-delivery-publishing/stream-content) for details. ## Combine with explicit content keys You can combine an external PlayReady license URL with [explicit content keys](/mkio/how-to/drm-content-protection/explicit-content-keys) to build a complete DRM workflow where MK.IO does not manage the encryption keys or license delivery. # JWT Token Authentication When a content key policy uses token restriction, the player must include a valid JWT token in the license acquisition request. MK.IO validates the token against the issuer, audience, and primary verification key configured in the policy before issuing a decryption license. ## How JWT tokens work with DRM The token acts as proof that the viewer is authorized to access the content. The flow works as follows: 1. Your application generates a JWT token using the same signing key configured in the content key policy. 2. The player includes the token as an `Authorization` header in the license request. 3. MK.IO validates the token signature, issuer, and audience. 4. If valid, MK.IO returns the decryption license. If invalid, the request is rejected. ## Required and optional claims The JWT token payload must include certain claims that match the content key policy configuration.
Claim Required Description
iss Yes The issuer value. Must match the Issuer field in the content key policy.
aud Yes The audience value. Must match the Audience field in the content key policy.
exp No Token expiry time as a Unix epoch timestamp in seconds. The token cannot be used after this time.
nbf No "Not before" time as a Unix epoch timestamp in seconds. The token cannot be used before this time.
urn:microsoft:azure:mediaservices:contentkeyidentifier No The streaming locator content key ID. Use this claim to bind the token to a specific locator. The value is available through the MK.IO API.
## Generate a JWT token ### Gather your policy values Retrieve the following values from the content key policy you created: - **Issuer**: the string you entered in the issuer field. - **Audience**: the string you entered in the audience field. - **Primary verification key**: the Base64-encoded key you entered. ### Build the token payload Construct the JWT payload with the required claims: ```json { "iss": "", "aud": "" } ``` To add an expiry, include the `exp` and optionally `nbf` claims: ```json { "iss": "", "aud": "", "nbf": 1707942000, "exp": 1707942300 } ``` The `nbf` and `exp` values are Unix epoch timestamps in seconds. Do not wrap them in quotes. ### Sign the token Use a JWT generation tool such as [jwt.io](https://jwt.io) to sign the token: 1. In the **PAYLOAD** section, enter your claims JSON. 2. In the **VERIFY SIGNATURE** section, paste your **primary verification key** in the secret field. 3. Check the **secret base64 encoded** checkbox. 4. The **Encoded** panel on the left displays the signed JWT token. The algorithm must be `HS256` (HMAC with SHA-256), which is the default. ### Use the token in playback Include the JWT token in the license request headers when configuring your player: ```json {"Authorization": "Bearer "} ``` In MKPlayer, paste this value in the **License request headers** field. In the MKPlayer SDK, pass it in the `headers` object of the DRM configuration. See [Test DRM playback](/mkio/how-to/drm-content-protection/test-drm-playback) for details. ## Example The following example shows a complete JWT configuration: **Content key policy settings:**
Field Value
Issuer mycompany
Audience myaudience
Primary verification key bXljb21wYW55YXVkaWVuY2U=
**JWT payload:** ```json { "iss": "mycompany", "aud": "myaudience", "nbf": 1707942000, "exp": 1707942300 } ``` **Signing secret:** `bXljb21wYW55YXVkaWVuY2U=` (with **secret base64 encoded** checked). The resulting encoded token is used as the `Bearer` value in the `Authorization` header. ## Programmatic token generation For production use, generate JWT tokens server-side rather than using jwt.io. Any JWT library that supports HS256 signing can produce valid tokens. Decode the Base64 primary verification key and use it as the HMAC secret.

Never expose the primary verification key in client-side code. Generate tokens on your server and pass them to the player at runtime.

# Multi-DRM Encryption Multi-DRM encryption protects your streams with industry-standard DRM systems so that content plays securely across all major browsers and devices. MK.IO supports two multi-DRM configurations: full multi-DRM (Widevine + PlayReady + FairPlay) and CENC-only (Widevine + PlayReady). ## Prerequisites - A running streaming endpoint. - An asset verified to play without encryption using `Predefined_ClearStreamingOnly`. - For FairPlay: an Apple FairPlay Streaming certificate, password, and application secret key. ## Choose your configuration
Configuration Streaming policy Required schemes Use when
Full multi-DRM Predefined_MultiDrmStreaming Widevine + PlayReady + FairPlay You need to support all platforms, including Safari and Apple devices.
CENC multi-DRM Predefined_MultiDrmCencStreaming Widevine + PlayReady You do not need FairPlay support. Covers Chrome, Edge, Android, and most smart TVs.

The streaming policy enforces which DRM schemes must be present in the content key policy. A Predefined_MultiDrmStreaming locator fails if the policy does not include all three schemes. A Predefined_MultiDrmCencStreaming locator fails if it does not include both Widevine and PlayReady.

## Full multi-DRM with JWT tokens This example creates a content key policy with Widevine, PlayReady, and FairPlay, all protected by JWT token authentication. ### Create the content key policy 1. Navigate to **Content Key Policies** and select **Create Content Key Policy**. 2. Enter a **name** (for example, `multidrm-jwt`) and optional **description**. 3. Select **Add** in the **Digital Rights Management** section. ### Add Widevine 1. Select **Add Widevine**. 2. Enter a **policy option name**. 3. Under **Use token restriction**, select **Yes**. 4. Configure the token fields: - **Token type**: `JWT` - **Issuer**: your chosen issuer string. - **Audience**: your chosen audience string. - **Primary verification key**: your Base64-encoded key. 5. Leave **Widevine template** as `{}` unless you need a custom template. 6. Select **Add**. ### Add PlayReady 1. Select **Add PlayReady**. 2. Enter a **policy option name**. 3. Under **Use token restriction**, select **Yes**. 4. Enter the same **issuer**, **audience**, and **primary verification key** as Widevine. 5. Leave the PlayReady-specific options at their defaults unless you need custom settings. 6. Select **Add**. ### Add FairPlay 1. Select **Add FairPlay**. 2. Enter a **policy option name**. 3. Under **Use token restriction**, select **Yes**. 4. Enter the same **issuer**, **audience**, and **primary verification key** as the other schemes. 5. Provide your Apple FairPlay **certificate**, **password**, and **application secret key**. 6. Select **Add**. ### Create the policy Select **Create**. The policy now includes all three DRM schemes with JWT protection. ### Generate a JWT token Follow the [JWT token authentication guide](/mkio/how-to/drm-content-protection/jwt-token-authentication) to generate a token using the issuer, audience, and primary verification key you configured. ### Create a streaming locator 1. Navigate to your asset and select **Add streaming locator**. 2. Enter a **name**. 3. Set **Streaming policy** to `Predefined_MultiDrmStreaming`. 4. Set **Content key policy** to the multi-DRM policy you created. 5. Select **Add**, then select the locator and select **Apply**. MK.IO generates playback URLs and license acquisition URLs for each DRM system. ### Test playback See [Test DRM playback](/mkio/how-to/drm-content-protection/test-drm-playback) for instructions on testing with MKPlayer. ## CENC multi-DRM without tokens This example creates a content key policy with Widevine and PlayReady only, with no token restriction. Use this for scenarios where token-based authentication is handled elsewhere or is not required. ### Create the content key policy 1. Navigate to **Content Key Policies** and select **Create Content Key Policy**. 2. Enter a **name** (for example, `multidrm-cenc-open`) and optional **description**. 3. Select **Add** in the **Digital Rights Management** section. ### Add Widevine 1. Select **Add Widevine**. 2. Enter a **policy option name**. 3. Under **Use token restriction**, select **No**. 4. Leave **Widevine template** as `{}`. 5. Select **Add**. ### Add PlayReady 1. Select **Add PlayReady**. 2. Enter a **policy option name**. 3. Under **Use token restriction**, select **No**. 4. Leave PlayReady options at defaults. 5. Select **Add**. ### Create the policy and streaming locator 1. Select **Create** to save the policy. 2. Navigate to your asset and select **Add streaming locator**. 3. Set **Streaming policy** to `Predefined_MultiDrmCencStreaming`. 4. Set **Content key policy** to the CENC policy you created. 5. Select **Add**, then select the locator and select **Apply**. ### Test playback 1. Navigate to the **MKPlayer** page. 2. Select **DASH** as the protocol and **Widevine** as the DRM. 3. Paste the DASH playback URL in **Source URL**. 4. Paste the Widevine license acquisition URL in **License URL**. 5. Select **Play**. # OpenID Verification Key You can delegate JWT token authentication to an external identity provider using OpenID Connect (OIDC). Instead of configuring a static verification key in the content key policy, MK.IO retrieves the signing key from the identity provider's OIDC discovery document. ## How it works OpenID Connect is a protocol that enables applications to support authentication through a centralized identity provider. When you configure OIDC in a content key policy, MK.IO: 1. Fetches the discovery document from the URL you provide. 2. Extracts the public signing key from the document. 3. Uses that key to validate JWT tokens in license requests. This means the `keyValue` of the primary verification key can be left empty in the policy, since MK.IO obtains the key dynamically. ## Create a policy with OpenID Connect Use the MK.IO API to create a content key policy that includes an `openIdConnectDiscoveryDocument` field: ```bash curl --request PUT \ --url https://app.mk.io/api/v1/projects/project_name/media/contentKeyPolicies/policy_name \ --header 'accept: application/json' \ --header 'content-type: application/json' \ --header 'Authorization: Bearer ' \ --data ' { "properties": { "options": [ { "restriction": { "issuer": "issuer", "audience": "audience", "@odata.type": "#Microsoft.Media.ContentKeyPolicyTokenRestriction", "restrictionTokenType": "Jwt", "primaryVerificationKey": { "@odata.type": "#Microsoft.Media.ContentKeyPolicySymmetricTokenKey", "keyValue": "" }, "openIdConnectDiscoveryDocument": "https://{host_url}/.well-known/OpenIdConfiguration" }, "configuration": { "@odata.type": "#Microsoft.Media.ContentKeyPolicyWidevineConfiguration", "widevineTemplate": "{}" } } ] } } ' ``` Replace `https://{host_url}/.well-known/OpenIdConfiguration` with the discovery document URL from your identity provider. MK.IO retrieves the JWT signing key from the discovery document and uses it to validate tokens for this content key policy. The content key policy can then be used when preparing the asset for streaming. See [Stream live and VOD assets](/mkio/how-to/content-delivery-publishing/stream-content) for details. # RSA Key for Token Validation By default, MK.IO uses a symmetric key (HS256) for JWT token validation. If your security requirements call for asymmetric cryptography, you can configure an RSA key pair instead. This is done through the MK.IO API by providing the RSA `exponent` and `modulus` in the content key policy. ## Create a policy with an RSA verification key Use the MK.IO API to create a content key policy that uses `ContentKeyPolicyRsaTokenKey` as the primary verification key type: ```bash curl --request PUT \ --url https://app.mk.io/api/v1/projects/project_name/media/contentKeyPolicies/policy_name \ --header 'accept: application/json' \ --header 'content-type: application/json' \ --header 'Authorization: Bearer ' \ --data ' { "properties": { "options": [ { "restriction": { "issuer": "issuer", "audience": "audience", "@odata.type": "#Microsoft.Media.ContentKeyPolicyTokenRestriction", "restrictionTokenType": "Jwt", "primaryVerificationKey": { "@odata.type": "#Microsoft.Media.ContentKeyPolicyRsaTokenKey", "modulus": "", "exponent": "" } }, "configuration": { "@odata.type": "#Microsoft.Media.ContentKeyPolicyWidevineConfiguration", "widevineTemplate": "{}" } } ] } } ' ``` Replace the `modulus` and `exponent` values with your RSA public key parameters. Both values must be Base64-encoded. The content key policy can then be used when preparing the asset for streaming. See [Stream live and VOD assets](/mkio/how-to/content-delivery-publishing/stream-content) for details. # Test DRM Playback After creating a content key policy and streaming locator, test that your encrypted streams play correctly. MK.IO provides the MKPlayer testing page for quick validation. For integration into your own application, use the MKPlayer SDK. ## Test with MKPlayer ### Get the playback and license URLs 1. Navigate to the **Assets** page and select your asset. 2. Select the streaming locator and a running streaming endpoint. 3. Select **Apply** to generate the URLs. 4. Copy the **playback URL** for your chosen protocol (HLS or DASH). 5. Copy the **license acquisition URL** for your DRM system (Widevine, PlayReady, FairPlay, or ClearKey). ### Configure MKPlayer 1. Navigate to the **MKPlayer** page. 2. Select the **protocol** (HLS or DASH). 3. Select the **DRM system** that matches your content key policy. 4. Paste the playback URL in **Source URL**. 5. Paste the license acquisition URL in **License URL**. ### Add authorization (token-protected content) If your content key policy uses token restriction, add the JWT token in the **License request headers** field: ```json {"Authorization": "Bearer "} ``` See [JWT token authentication](/mkio/how-to/drm-content-protection/jwt-token-authentication) to generate a token. ### Play Select **Play**. If the configuration is correct, the player decrypts and plays the stream. ### Troubleshooting playback errors
Error Cause Solution
DRM_FAILED_LICENSE_REQUEST Missing or invalid JWT token. Verify the token and add it to the license request headers.
License URL not populated Streaming locator not applied. Select Apply on the streaming locator to generate URLs.
Playback fails on specific browser DRM system not supported on that browser. Select the correct DRM for the browser. See DRM support by platform.
## Configure the MKPlayer SDK For integration into your own application, use the MKPlayer SDK to configure DRM playback programmatically. ### Prerequisites - Install the latest version of [MKPlayer SDK](https://www.npmjs.com/package/@mediakind/mkplayer). - Complete the **Getting Started** steps in the [MKPlayer documentation](/mkio/reference/player-sdk). ### Build the source configuration Create a source configuration object with your playback URLs and DRM license URLs. You can include multiple DRM systems in the configuration. The player automatically selects the most suitable one for the current platform. ```javascript const sourceConfig = { title: "Title for your source", description: "Description for your source", hls: "HLS URL as copied from the Assets page", dash: "DASH URL as copied from the Assets page", drm: { // For Safari Browser with HLS + FairPlay Content Protection fairplay: { LA_URL: "FairPlay License URL as copied from the Assets page", certificateURL: "FairPlay Certificate URL as copied from the Assets page", headers: { "Authorization": "Bearer " } }, // For Chrome, Edge browsers widevine: { LA_URL: "Widevine License URL as copied from the Assets page", headers: { "Authorization": "Bearer " } }, // For Edge (Windows) browser playready: { LA_URL: "PlayReady License URL as copied from the Assets page", headers: { "Authorization": "Bearer " } } } }; ``` Each platform or browser has a preferred DRM system. If you are uncertain which DRM to use, include all applicable systems in the configuration. The player selects the best match for the current environment. Remove the `headers` objects if your content key policy does not use token restriction. ### Load and play Pass the source configuration to the player: ```javascript player.load(sourceConfig) .then(() => { console.log("Source loaded successfully"); }) .catch((error) => { console.error("An error occurred while loading the source"); }); ``` Refer to the [MKPlayer documentation](/mkio/reference/player-sdk) for additional configuration options and event handling. # Live events MK.IO has two live streaming workflows. Use the **Live** interface for new events, sources, and multiview events. Use the Media API workflow when you already automate live events and outputs through the Media API. ## Use Live and multiview The **Live** interface is the recommended starting point for new work. It keeps source creation, single-source events, multiview events, and playback checks in one workflow. Create sources first, then use them in either a live event or a multiview event. - [Live and multiview](/mkio/how-to/live-streaming/live) for the complete Live workflow. - [Create an SRT source](/mkio/how-to/live-streaming/live/create-a-live-source) to prepare Secure Reliable Transport (SRT) ingest. - [Create a live event](/mkio/how-to/live-streaming/live/create-a-live-event) to stream one source. - [Create a multiview live event](/mkio/how-to/live-streaming/live/create-a-multiview-live-event) to combine sources in one layout. ## Use the Media API workflow The established workflow creates Media API live events, live outputs, streaming locators, and streaming endpoints. Keep using it for existing API-backed integrations. - [Live stream in five minutes](/mkio/getting-started/live-stream-in-five-minutes) for a first Real-Time Messaging Protocol (RTMP) test. - [Configure a Media API live event](/mkio/how-to/live-streaming/set-up-a-live-streaming-event) for passthrough, encoding, RTMP, encrypted RTMP (RTMPS), SRT, archive, and transcription options. - [Configure an extended archive window](/mkio/how-to/live-streaming/extended-archive-window) when the default archive duration is not enough. ## Connect a Media API source Choose the guide for your source software: - [OBS Studio](/mkio/how-to/live-streaming/set-up-the-source-stream-using-obs) - [FFmpeg](/mkio/how-to/live-streaming/set-up-the-source-stream-using-ffmpeg) - [GStreamer](/mkio/how-to/live-streaming/set-up-the-source-stream-using-gstreamer) ## Publish and monitor - [Publish the live output](/mkio/how-to/content-delivery-publishing/stream-content) with a streaming endpoint and locator. - [Monitor MK.IO services](/mkio/how-to/monitor-your-services) through operational metrics. - [Build live workflows with the Media API](/mkio/api-guides/how-to/media/live-streaming). # Extended archive window When you run a live event in MK.IO, the **archive window** controls how far back viewers can rewind or seek into the recorded stream. MK.IO supports archive windows of up to 30 days, which is useful for multi-day events, nPVR, or catch-up TV scenarios where viewers need access to content long after it aired. When the archive window is longer than 25 hours, the manifest behaves differently. You need to use filters or manifest URL parameters to control what portion of the archive is returned to the player. ## How the manifest works A **manifest** is the file a video player fetches to know which segments of video and audio are available. It acts as a table of contents for the stream. The size of the manifest determines how much content the player can see and seek through at any given time. You set the archive window length when [creating a live event](/mkio/how-to/live-streaming/set-up-a-live-streaming-event). It accepts any value from 1 minute up to 30 days. Once the live event starts, the manifest grows as new content is recorded. It continues growing until it reaches a maximum size of **25 hours**. After that, the manifest becomes a rolling window: it always contains the most recent 25 hours of content, and older segments drop off the front as new ones are added. The archive window itself still retains content beyond 25 hours (up to 30 days). The 25-hour limit applies only to the manifest returned in a default request. To reach content older than 25 hours, you specify start and end times in the manifest URL. See [Accessing content older than 25 hours](/mkio/how-to/live-streaming/extended-archive-window#accessing-content-older-than-25-hours) below. ## Controlling manifest size If your player does not need the entire window in every request, you can narrow it down using filters or manifest URL parameters. ### Asset or account filters **Filters** let you define a specific time range or track subset that the manifest presents to viewers. For example, you can create a filter that limits the manifest to a 2-hour window, or one that excludes certain audio tracks. - **Asset filters** apply to a single asset and last for the lifetime of that asset. - **Account filters** apply to any asset in your account and last for the lifetime of the account. See [Create an asset filter or an account filter](/mkio/how-to/content-management/create-an-asset-filter) for instructions. ### Manifest URL parameters You can include `start` and `end` parameters directly in the manifest URL to control which portion of the archive the player receives. Both values use ISO 8601 datetime format (UTC). To return a manifest starting at a specific time up to the live edge: ```http https:////index.qfm/manifest(format=m3u8-cmaf,start=) ``` To return a manifest ending at a specific time: ```http https:////index.qfm/manifest(format=m3u8-cmaf,end=) ``` To return a manifest for a specific time range: ```http https:////index.qfm/manifest(format=m3u8-cmaf,start=,end=) ``` Replace `` with a UTC datetime string such as `2024-06-01T13:15:00.000Z`. Replace `m3u8-cmaf` with the output format your player requires, such as `mpd-time-cmaf` for DASH. ## Accessing content older than 25 hours Content older than 25 hours is still in the archive, but it is not included in the default manifest. To reach it, specify both `start` and `end` times in the manifest URL. Both values must refer to points in the past that fall within your configured archive window. For example, to retrieve a one-hour segment that started at 13:15 UTC on 1 June 2024: ```http https:////index.qfm/manifest(format=m3u8-cmaf,start=2024-06-01T13:15:00.000Z,end=2024-06-01T14:15:00.000Z) ``` When both the start and end are in the past, MK.IO returns a closed playlist covering exactly that time range. The player treats it like a VOD asset: it has a fixed duration and a seek bar, rather than a live edge. If the requested range falls outside your archive window, MK.IO returns a 404 response. ## Manifest types Depending on the parameters you provide, the returned manifest behaves in one of three ways:
Type Description
Growing The start is fixed and the end moves forward with the live edge. The manifest gets longer over time. Use case: start-over, where a viewer joins a program from the beginning while it is still airing.
Sliding Both the start and end move with the live edge. The window duration stays constant. Use case: standard live playback with a fixed rewind buffer.
Fixed Both the start and end are in the past. The manifest does not change. Use case: catch-up or nPVR playback of a completed program.
## Parameter reference These parameters are placed inside the manifest URL parentheses, not as query string parameters.
Parameter Format Description
start ISO 8601 datetime Start of the manifest window. Example: 2024-06-01T13:15:00.000Z
end ISO 8601 datetime End of the manifest window. Example: 2024-06-01T14:15:00.000Z
# Live and multiview Use the **Live** interface to build streams from reusable sources and encoding profiles. It starts with reusable sources, then lets you create a live event for one source or a multiview event that presents several sources in one output. Use this workflow when you want to create a new event in the MK.IO interface, especially when you need multiview. Use the [Live API guides](/mkio/api-guides/how-to/live) to automate live events, multiview events, and related configuration. ## Choose an event or channel
You want to Create
Stream one source A live event
Display more than one source in one output A multiview live event
Run a continuous 24×7 stream A channel
Run a continuous multiview output A multiview channel
Multiview creation is available in the **Live** interface. Select **New live** and then **Create a multiview event** to start that workflow. ## Create a source first Each event uses the sources you select during creation. Create the required sources and check their connection settings before you create the event. Verify the video after the event starts and the encoder is sending. [Create an SRT source](/mkio/how-to/live-streaming/live/create-a-live-source) shows the external Secure Reliable Transport (SRT) setup, including the address your encoder uses. ## Create a channel Channels use the same source and encoding concepts for continuous 24×7 streaming. Events suit broadcasts with a defined end. Live channels and multiview channels use monthly billing; starting one incurs the full monthly charge even partway through the month. Review your project rate card before starting a channel. Use an event for a short test. Before you begin, create the required [sources](/mkio/how-to/live-streaming/live/create-a-live-source) and have an encoding profile and recording storage available in your project. 1. Go to **Live** > **New live**. 2. Select **Create a channel** for one source, or **Create a multiview channel** to compose several sources. 3. Enter a **Name**. For multiview, select a **Layout** first. 4. Select **Add source** to assign the source, or assign a source to each multiview tile. 5. Select an **Encoding profile**, **Storage**, and **Window length**. 6. Optionally enable **Schedule start and stop** and enter the start and stop dates and times. 7. Leave **Start channel immediately after creation** disabled while preparing the configuration. Enable it only when you are ready to start the channel and incur monthly billing. 8. Select **Create**. Return to the **Live** list to find the channel by name and check its **Status**. Resource creation alone does not verify media delivery. The API guides for [live channels](/mkio/api-guides/how-to/live/manage-live) and [multiview channels](/mkio/api-guides/how-to/live/multiview/static-multiview-channel) explain startup, monitoring, and stopping. ## Automate the workflow The Live interface and the Live API use the same source, event, multiview, and template concepts. Use the API guides when you need to create or manage this workflow through automation: - [Live event walkthrough](/mkio/api-guides/how-to/live/walkthrough) creates a source through the Media API, then creates a single-input Live API event. - [Multiview walkthrough](/mkio/api-guides/how-to/live/multiview/multiview-walkthrough) creates a multiview event through the Live API. - [Manage templates](/mkio/api-guides/how-to/templates/manage-templates) explains the configuration templates used for live encoding and multiview composition. # Create a live event This guide creates a live event that turns one source into a stream that viewers can watch. During creation, you select the source, encoding profile, recording storage, and viewing window. You can schedule the event or start it immediately after creation. ## Prerequisites - A source created in **Live** > **Sources**. See [Create an SRT source](/mkio/how-to/live-streaming/live/create-a-live-source). - An encoding profile and storage option available in the Live interface. ## Choose event settings
Setting Choose it for
Sources The one input that this live event streams.
Encoding profile The output quality and bitrate options shown by the profile picker.
Storage The location where the event saves recorded content.
Window length How far back viewers can watch.
Schedule start and stop A planned start and stop time.
Start event immediately after creation Starting the event as part of creation.
The encoding profile determines output quality and bitrate for the renditions. For a first test, use a profile agreed for your audience and playback devices. After creation, **Overview** > **View encoding profile** shows the selected profile's **Renditions**, including **Name**, **Codec**, and **Bitrate**, so you can check what it produces before starting. ## Create the event 1. Go to **Live**. 2. Select **New live**. 3. Select **Create an event**. 4. Enter a value in **Name**. 5. Under **Sources**, select **Add source**, then select the source you created. The source selection identifies the input used by the event. 6. Under **Encoding profile**, select the required profile. The Live interface shows options including **default\_AV1**, **default\_1080p**, and **default\_720p**. 7. Under **Storage**, select where to save recorded content. Choose the storage location that owns the recording for this event. 8. Under **Window length**, select how far back viewers can watch. The Live interface offers **30 minutes**, **2 hours**, **4 hours**, **8 hours**, **1 day**, **10 days**, and **30 days**. 9. To plan a broadcast, enable **Schedule start and stop** and enter **Start date and time** and **Stop date and time**. This keeps the planned start and end with the event configuration. 10. To begin as soon as the event is created, enable **Start event immediately after creation**. Leave it disabled when you want to check the configuration before starting. 11. Select **Create**. ![The Create a live event page showing source selection, encoding profile, storage, window length, scheduling, and immediate-start options.](/_machine-assets/75833350762b67c518a6636846ab6bc0006f9dd5d27836f9670fc4a97281cabe.png) For API options that configure live event inputs and encoding, see [Manage Live resources](/mkio/api-guides/how-to/live/manage-live), [Live API inputs](/mkio/api-guides/how-to/live/core-concepts/inputs), and [Live templates](/mkio/api-guides/how-to/live/core-concepts/templates). ## Start and verify the event If you did not enable **Start event immediately after creation**, open the event and select **Start**. The event page displays **Event is running** when the event is running. Select **Overview** to see the selected source, its input address, and the player. Configure your encoder with the source address and connection settings, then begin sending the stream. In **Live** > **Sources**, **Active** means the source is in use; it does not prove that media is arriving. Complete the playback checks below to verify the broadcast. ## View and manage the event Open **Live** and select the event from the **Live** tab. The event page has **Overview** and **Settings** tabs. - Use **Overview** to view the selected source and event player. - Select **Settings** to view **General** and **Streaming configuration**. The streaming configuration includes **Streaming locators**. - Select **Playback settings** to manage streaming locators. - Select **Schedule options** to manage the event schedule. - Select **Stop** to stop a running event, or **Delete** to remove the event. ![The Settings tab for a running live event, showing General, Streaming configuration, and Streaming locators.](/_machine-assets/71cad5d8b841a28e8ff841dd1dfc5e21a8a85befeff65e6c672a0ffa8595bcf9.png) ## Create a streaming locator Select **Playback settings** on the event page to manage the streaming locators shown for the event. 1. Select **Playback settings**. 2. Select **Customize playback settings** to open **Settings**. 3. Under **Streaming locators**, select **Create a streaming locator**. 4. Enter a value in **Name**. 5. Select the required **Streaming policy**. Select a **Content key policy** when your playback policy uses one. 6. Optionally enter an **Expiration date and time**. 7. Select **Create**. ![The Create a streaming locator dialog with fields for Name, Streaming policy, Content key policy, Expiration date and time, and ID.](/_machine-assets/a06e6f4f9c61e850b1f1bbdc92285e55cd851a3c40c107e357fd38301f7954bb.png) For locator and streaming endpoint automation, see [Publishing with the Media API](/mkio/api-guides/how-to/media/publishing).
Start the streaming endpoint

Playback does not work until the streaming endpoint is running. Start the endpoint before you test the player or share playback with viewers.

For the endpoint and publishing model, see [Publish content for streaming](/mkio/how-to/content-delivery-publishing/stream-content). ## Copy a playback URL and verify the stream 1. Open the event and select **Playback settings**. 2. Select **HLS streaming URL** for HTTP Live Streaming (HLS), or **DASH streaming URL** for Dynamic Adaptive Streaming over HTTP (DASH), to copy the playback address for the locator. 3. Open that address in a player that supports the selected format and streaming policy. 4. Confirm that the picture updates and that the expected audio is present. A running event or a loaded player alone does not establish that the current source is reaching viewers. Use **Overview** to compare the event's player with the expected source. If playback fails, follow [Troubleshoot Live playback](/mkio/how-to/live-streaming/live/troubleshoot-live-playback). ## Finish a test Select **Stop** on the event when the test ends, then check that its **Status** in the **Live** list is **Stopped**. Stop your contribution encoder too. If you started a streaming endpoint only for this test, follow [Stop the test resources](/mkio/getting-started/live-stream-in-five-minutes#stop-the-test-resources) after checking that no other streams use it. A shared endpoint may still be serving other viewers. ## What comes next If the source remains inactive or the player cannot load playback, use [Troubleshoot Live playback](/mkio/how-to/live-streaming/live/troubleshoot-live-playback). For an automated equivalent, follow the [Live event walkthrough](/mkio/api-guides/how-to/live/walkthrough). It creates the source through the Media API, references an encoding template, and creates the event through the Live API. # Create an SRT source A source supplies video to a Live event. Create the source before you create a live event or multiview event. Use an SRT listener source to receive an external Secure Reliable Transport (SRT) stream from your encoder. Configure network access, then copy the source address into the encoder. ## How a source fits into the workflow The source is the ingest connection for your encoder. After you create it, it becomes available from **Add source** when you create a live event or multiview event. The source keeps its input mode, port, encryption, and network access settings so that you can use the same source configuration when planning an event. For an external SRT connection, the encoder must send to the source address and its public IP address must be listed in **Allowed IPs**. Configure those settings before you start the event, so that the connection settings are ready when you begin the broadcast. ## Prerequisites - An MK.IO project with access to **Live**. - The public Internet Protocol (IP) address of the encoder you will use for this test. - A chosen port and an encoder ready to send Secure Reliable Transport (SRT). ## Create the source 1. Go to **Live** > **Sources**. The Sources tab lists the sources available to use in new events. 2. Select **New source**. 3. Enter a value in **Name**. 4. Under **Input mode**, select **SRT Listener**. 5. Enter the listening port in **Port**. 6. Under **Encryption type**, select the option that matches your encoder. The available choices are **No encryption**, **AES-256**, **AES-192**, and **AES-128**. 7. If you selected an encryption option, enter its matching value in **Passphrase**. 8. Expand **Advanced settings**. 9. Set **IP resource** to **External**. 10. Under **Allowed IPs**, select **Add IP address** and enter the public IP address of the encoder. 11. Select **Create source**. ![The Create a source page with SRT Listener selected.](/_machine-assets/7556c2294f00b6b2138f45a0085f390a90350d080ee50477715d042808c9878a.png) ## Check the connection settings Before you create the source, check these values against the encoder configuration:
Setting What to check
Port Use the same port in the encoder connection.
Encryption type Select the same encryption option as the encoder.
Passphrase Enter the matching passphrase when encryption is enabled.
IP resource Select External for an encoder that connects from outside MK.IO.
Allowed IPs Add the public IP address used by the encoder.
## Use the source in an event When you create an event, select **Add source** and choose the source you created. Search for the source by name if required. ![The Add source menu shows a search field and an SRT Listener source named camera-1.](/_machine-assets/0aa89dc46c154b8633ef1f7542102befbb26b9c2773265ab30024eb9ef3098e3.png) After you create the source, go to **Live** > **Sources**. Copy its address from the **Host and port** column and use those values in your encoder configuration. The event's **Overview** also displays the full SRT URLs for its assigned source. Use the same port, encryption type, and passphrase that you entered when creating the source. ## Verify the source settings Open the source and confirm that **IP resource** is **External** and that **Allowed IPs** includes the public IP address of the encoder. Then create an event that uses the source. The **Sources** tab reports whether a source is **Active** or **Inactive**. **Active** means the source is in use. It does not confirm that video or audio is arriving. If the source stays inactive, confirm that the event references it and check the event state. If the event is using the source but playback is missing, check the source address, allowed encoder IP address, and encoder settings. [Troubleshoot Live playback](/mkio/how-to/live-streaming/live/troubleshoot-live-playback) gives the checks in order. ## What comes next - [Create a live event](/mkio/how-to/live-streaming/live/create-a-live-event) to use one source. - [Create a multiview live event](/mkio/how-to/live-streaming/live/create-a-multiview-live-event) to assign sources to a layout. - [Content, sources, and destinations](/mkio/api-guides/how-to/media/content-and-sources) for API source configuration. - [Live API inputs](/mkio/api-guides/how-to/live/core-concepts/inputs) for API source-to-event assignments. # Create a multiview live event A multiview live event presents several sources in a single output. Choose a layout first, then assign a source to each tile. The event uses one encoding profile, recording location, and viewer window for the composed output. ## Prerequisites - The required sources created in **Live** > **Sources**. - An encoding profile and storage option available in the Live interface. ## Plan the layout The layout picker shows the tile arrangement before you add sources. Select a layout that gives every required source a tile, then assign the sources in the order you want them displayed. The creation page provides layouts for two, three, and four tiles. Create all the required sources before you open this page. This keeps the layout assignment step focused on choosing the right source for each tile rather than interrupting event creation to configure ingest. For API configuration of multiview inputs and composition, see [Multiview](/mkio/api-guides/how-to/live/multiview) and [Live API inputs](/mkio/api-guides/how-to/live/core-concepts/inputs). ## Create the multiview event 1. Go to **Live**. 2. Select **New live**. 3. Select **Create a multiview event**. 4. Enter a value in **Name**. 5. Under **Layout**, select the layout that has the tiles you need. The available layout cards show the tile arrangement before you assign a source. 6. In each tile, select **Add source** and choose the source to assign to that tile. Before creation, select **Replace** to choose a different source or **Remove** to clear the tile. 7. Under **Encoding profile**, select the output profile for the composed multiview stream. 8. Under **Storage**, select where to save recorded content. 9. Under **Window length**, select how far back viewers can watch. 10. Optionally enable **Schedule start and stop**, then enter the event dates and times. 11. To begin as soon as the event is created, enable **Start event immediately after creation**. Leave it disabled when you want to confirm the layout and source assignments before starting. 12. Select **Create**. ![The Create a multiview live event page with the two-tile layout selected and two SRT Listener sources assigned.](/_machine-assets/c0b37c612369d973643020a93da087298b7b2d871070923177419e558d25f08d.png) For API options that control live event resources, sources, and encoding configuration, see [Manage Live resources](/mkio/api-guides/how-to/live/manage-live) and [Live templates](/mkio/api-guides/how-to/live/core-concepts/templates). ## Start and verify the event If you did not enable **Start event immediately after creation**, open the new event and select **Start**. The Live interface shows **Event is running** when it is running. On **Overview**, the source list and player show the assigned inputs and the composed multiview output. Check each assigned source in **Live** > **Sources**. **Active** means a source is in use. Verify the composed picture as well: every tile should show its expected source and update as that source changes. ![A running two-camera multiview event with two sources and the composed output in the player.](/_machine-assets/b467d69d8df30c391c85cb53d65c3377b28c7a62d26ecaa640049526cc96c1a8.png) For API monitoring options, see [Monitor live resources](/mkio/api-guides/how-to/live/monitor-live). ## Configure playback Open **Settings** > **Streaming configuration** to manage the event's **Streaming locators**. Follow [Create a streaming locator](/mkio/how-to/live-streaming/live/create-a-live-event#create-a-streaming-locator), then start the streaming endpoint before you expect playback to work.
Start the streaming endpoint

The multiview player cannot play the output until the streaming endpoint is running.

[Publish content for streaming](/mkio/how-to/content-delivery-publishing/stream-content) explains streaming endpoints and locators. For locator and streaming endpoint automation, see [Publishing with the Media API](/mkio/api-guides/how-to/media/publishing). ## Verify playback and finish the test Follow [Copy a playback URL and verify the stream](/mkio/how-to/live-streaming/live/create-a-live-event#copy-a-playback-url-and-verify-the-stream). Check every tile and the expected audio in the composed output. A working tile does not prove that the other sources are receiving media. When testing is complete, follow [Finish a test](/mkio/how-to/live-streaming/live/create-a-live-event#finish-a-test) to stop the event and any delivery resources dedicated to the test. ## What comes next Use [Troubleshoot Live playback](/mkio/how-to/live-streaming/live/troubleshoot-live-playback) if a source is inactive or the player cannot load playback. To automate the same workflow, follow the [Multiview walkthrough](/mkio/api-guides/how-to/live/multiview/multiview-walkthrough). Use [Manage templates](/mkio/api-guides/how-to/templates/manage-templates) when you need to create or adjust the encoding and composition templates that the Live API resources reference. # Troubleshoot Live playback Use these checks in order when a live event does not receive its source or the player cannot load playback. Start with the source, then confirm the event state, and finally check the playback configuration. ## The source is inactive **Inactive** means the source is not in use. Check the event assignment before investigating the encoder connection: 1. Go to **Live** > **Sources** and confirm the source exists. 2. Open the event and confirm the source on **Overview**. 3. Check the event's state. If the broadcast should be running, use the [event startup steps](/mkio/how-to/live-streaming/live/create-a-live-event#start-and-verify-the-event). ## The event is not receiving the stream A source can be **Active** without receiving video or audio. Check the connection independently: 1. Open the event and confirm the selected source on **Overview**. 2. Compare the source address shown there with the encoder configuration. You can also find **Host and port** in **Live** > **Sources**. 3. Open the source and compare **Port**, **Encryption type**, and **Passphrase** with the encoder. 4. For an external SRT listener source, confirm **IP resource** is **External** and **Allowed IPs** includes the encoder's public IP address. 5. Confirm that the encoder is sending, then check for an updating picture and the expected audio using the playback checks below. ## The player cannot load playback 1. Confirm the event shows **Event is running**. 2. Select **Playback settings** and confirm that the event has the required streaming locator configuration. 3. Confirm that the streaming endpoint is running. Playback does not work until the streaming endpoint is running. 4. Review [Publish content for streaming](/mkio/how-to/content-delivery-publishing/stream-content) for the relationship between streaming locators and streaming endpoints. ## The event needs different source settings Check which setting needs to change before recreating resources. The Media API supports updates to selected source fields, including SRT passphrases, listener allow lists, caller URLs, and HLS credentials. See [Update source settings](/mkio/api-guides/how-to/media/content-and-sources#update-a-source) for the supported fields and transport restrictions. Source configuration and the event's source assignment are separate settings. ## Gather information before contacting support If the checks do not resolve the problem, collect the source name, input mode, selected IP resource, encoder public IP address, event state, source status, and the playback result. This gives your MK.IO administrator or support team the context needed to investigate the connection. # Configure a Live Event A live event in MK.IO is the component that receives an inbound video stream (via RTMP or SRT), processes it, and packages it for delivery to viewers. Once created and started, it generates an ingest URL that your encoder sends video to. Live content is recorded to your connected cloud storage as an asset, which you can use for VOD playback after the event ends. For a step-by-step walkthrough of the complete live streaming workflow including OBS setup and viewer delivery, see [Live streaming workflows](/mkio/getting-started/live-streaming-workflows). ## Event type The first decision when creating a live event is whether to use **passthrough** or **encoding** mode. This determines what happens to your stream inside MK.IO.
Mode What MK.IO does Best for
Live passthrough (up to 5 Mbps) Passes the stream through without modification. Your encoder must produce the final output. Low-bandwidth streams already encoded at source
Live passthrough (up to 60 Mbps) Same as above with a higher bandwidth ceiling. High-bitrate professional sources
Live encoding (720p) Ingests your stream and produces adaptive bitrate output at 720p and lower. Most use cases where MK.IO handles quality adaptation
Live encoding (1080p) Ingests and produces ABR output up to 1080p. High-quality productions

Live encoding mode is recommended for most users. It lets MK.IO automatically generate multiple bitrate levels so viewers on different network connections all get a smooth experience. Passthrough requires your encoder to produce the quality levels you want.

## Configure a live event ### Create the live event Go to **Live Events** in the left navigation and click **+ Create Live Event**. ### Basic settings - **Name**: A unique identifier for this event (for example, `weekly-show-ep12`). Names cannot be reused within a project once a live event is deleted. - **Description**: Optional. Useful for identifying events in a busy project. ### Select the event type Choose one of the four modes described above. If you are unsure, **Live encoding (720p)** is a good default.

Low-latency streaming is available. Contact the MK.IO sales team for details.

### Select the input protocol Choose how your encoder sends video to MK.IO: - **RTMP**: The most widely supported streaming protocol. Used by OBS, Wirecast, and most hardware encoders. - **RTMPS**: Encrypted RTMP. Use this when your network requires encrypted ingest. - **SRT**: Secure Reliable Transport. Better reliability over unpredictable networks. Requires live encoding mode. ### Configure output settings - **Archive window length**: How long MK.IO retains the live stream recording, from 1 minute up to 30 days. When you stop the event, the full recording is stored as an asset in your cloud storage. When the archive window exceeds 25 hours, the manifest shows only the most recent 25-hour window for viewers. The full recording is still stored. See [Extended archive window](/mkio/how-to/live-streaming/extended-archive-window). - **Storage account**: The connected storage account where the live recording is saved. ### Configure advanced settings (optional) - **Input key frame interval** (passthrough only): The key frame interval your encoder sends. Should match your encoder's GOP setting. - **Image fitting** (encoding only): How MK.IO handles source resolutions that do not match the output aspect ratio. - **AI pipeline** (encoding only): Enable real-time transcription. Select `Predefined_ACSLiveTranscription` and specify the source audio language code (for example, `en-US`). See [Transcription transform](/mkio/reference/encoding-transform-presets/audio-speech-transcription#source-language) for source language guidance. ### Review and create Click **Review** to confirm all settings, then click **Submit** to create the live event. ## Live transcription Live transcription is available for live encoding events. It generates Web Video Text Tracks (WebVTT) subtitles for HTTP Live Streaming (HLS) output and Timed Text Markup Language (TTML) subtitles for Dynamic Adaptive Streaming over HTTP (DASH) output. Set the source audio language with a BCP-47 language tag. You can also provide expected words or phrases to improve recognition of names and specialist terms. Live transcription adds less than five seconds to the event latency and is billed for each minute the live event runs. See [MK.IO pricing](https://mediakind.com/mkio/pricing/) for current rates. ## Start streaming After the live event is created, you still need to set up streaming infrastructure before viewers can watch. This requires a streaming endpoint and a streaming locator. See [Publish content for streaming](/mkio/how-to/content-delivery-publishing/stream-content). Once those are in place, click **Start** on the live event. MK.IO generates an **Input URL**: copy this and enter it in your encoder. Set up your encoder with one of these guides: - [OBS Studio](/mkio/how-to/live-streaming/set-up-the-source-stream-using-obs) - [FFmpeg](/mkio/how-to/live-streaming/set-up-the-source-stream-using-ffmpeg) - [GStreamer](/mkio/how-to/live-streaming/set-up-the-source-stream-using-gstreamer) ## Connection timeout If MK.IO receives no data on an RTMP or RTMPS connection for 10 seconds, it drops the connection automatically. This timeout is fixed and cannot be configured. If your stream stops unexpectedly, check whether your encoder or network stopped sending data for more than 10 seconds. Common causes include: - Network instability or packet loss - Encoder pauses between scenes - Video conferencing software that halts transmission when a participant is idle Your encoder must reconnect and resume sending data to restore the stream.

When your event ends, stop the live event and the streaming endpoint in MK.IO. Both incur costs while running, even if no one is watching. If you do not need the recording, also delete the output asset to avoid ongoing storage charges.

## Automate live events Use the [Live streaming API Guide](/mkio/api-guides/how-to/media/live-streaming) to create and control live events and outputs through the Media API. # Set up the source stream using FFmpeg Use FFmpeg to generate a test source and send it to an MK.IO live event. For SRT input, use an FFmpeg binary compiled with `libsrt`. ## RTMP basic example This command generates a 1080p test pattern and a 150 Hz tone. It encodes the video with H.264, encodes the audio with AAC, and sends the constant-bitrate output to an RTMP input URL. ```shell ffmpeg -threads 0 \ -re \ -f lavfi \ -i testsrc=rate=30:size=1920x1080,format=yuv420p \ -f lavfi \ -i "sine=frequency=150:sample_rate=48000:beep_factor=2" \ -c:a aac \ -ab 48k \ -ac 2 \ -ar 48000 \ -c:v libx264 \ -preset:v fast \ -b:v 500k \ -minrate 500k -maxrate 500k -bufsize 500k \ -r 30 \ -g 60 -keyint_min 60 \ -sc_threshold 0 \ -f flv \ rtmp://in-7334a7c7-a376-4edf-aeb9-d6bfd7fab995.japaneast.streaming.mediakind.com:1935/de04ea37-ace5-46e1-9a54-6cb045c424df/stream ``` ### Command breakdown The table describes each part of the command:
Command Description
-threads 0 Sets the number of threads for processing. 0 lets FFmpeg decide the number of threads based on the available CPU cores.
-re Makes FFmpeg read input in real time rather than as fast as possible. This makes the generated input match playback speed.
-f lavfi Specifies the lavfi input format so FFmpeg generates input with a filter instead of reading an external file or stream.
-i testsrc=rate=30:size=1920x1080,format=yuv420p Generates a test pattern at 30 frames per second with a resolution of 1920x1080 and a YUV 4:2:0 pixel format.
-f lavfi -i "sine=frequency=150:sample_rate=48000:beep_factor=2" Generates a 150 Hz audio tone at a 48 kHz sample rate. beep_factor=2 adds breaks instead of producing a continuous tone.
-c:a aac Sets the audio codec to AAC, a widely used audio compression format.
-ab 48k Sets the audio bitrate to 48 kbps.
-ac 2 Sets the number of audio channels to 2 (stereo).
-ar 48000 Sets the audio sample rate to 48 kHz.
-c:v libx264 Sets the video codec to H.264 using libx264, which is efficient and compatible with most streaming platforms.
-preset:v fast Uses the fast libx264 encoding preset.
-b:v 500k Sets the target video bitrate to 500 kbps.
-minrate 500k -maxrate 500k -bufsize 500k Sets the minimum rate, maximum rate, and buffer size to 500 kbps for constant-bitrate output.
-r 30 Sets the output frame rate to 30 fps, matching the input video frame rate.
-g 60 -keyint_min 60 Sets the group of pictures (GOP) length and minimum keyframe interval to 60 frames. This produces a keyframe every two seconds at 30 fps. Match this value to the Input key frame interval in MK.IO.
-sc_threshold 0 Sets the scene change threshold to 0 so FFmpeg does not add keyframes for scene changes. This keeps the GOP structure stable.
-f flv Specifies the output format as flv, which is commonly used for streaming to RTMP servers.
rtmp://... Specifies the RTMP server URL. Paste the Input URL provided after you start the live event.
## RTMP example with multiple bitrates This example sends three video qualities to an MK.IO passthrough event. Use a unique stream name for each quality and align keyframes across all qualities. ```shell ffmpeg.exe -threads 0 -re / -stream_loop -1 -i "C:\Videos\sample.mp4" / -c:a aac -ab 128k -ac 2 -ar 48000 -c:v libx264 -s svga -b:v 500k -minrate 500k -maxrate 500k -bufsize 500k -r 30 -g 48 -keyint_min 48 -sc_threshold 0 -f flv rtmp://in-7334a7c7-a376-4edf-aeb9-d6bfd7fab995.japaneast.streaming.mediakind.com:1935/de04ea37-ace5-46e1-9a54-6cb045c424df/stream_500 / -c:a aac -ab 128k -ac 2 -ar 48000 -c:v libx264 -s vga -b:v 300k -minrate 300k -maxrate 300k -bufsize 300k -r 30 -g 48 -keyint_min 48 -sc_threshold 0 -f flv rtmp://in-7334a7c7-a376-4edf-aeb9-d6bfd7fab995.japaneast.streaming.mediakind.com:1935/de04ea37-ace5-46e1-9a54-6cb045c424df/stream_300 / -c:a aac -ab 128k -ac 2 -ar 48000 -c:v libx264 -s qvga -b:v 150k -minrate 150k -maxrate 150k -bufsize 150k -r 30 -g 48 -keyint_min 48 -sc_threshold 0 -f flv rtmp://in-7334a7c7-a376-4edf-aeb9-d6bfd7fab995.japaneast.streaming.mediakind.com:1935/de04ea37-ace5-46e1-9a54-6cb045c424df/stream_150 ```

Adjust the encoding settings for the available CPU capacity, network bandwidth, and required output quality.

# Set up the source stream using GStreamer Use GStreamer, a command-line tool to configure your source stream.

We recommend using GStreamer v1.18 or later.

## Example ```shell gst-launch-1.0 -v videotestsrc ! video/x-raw,width=1920,height=1080,framerate=30/1 ! x264enc tune=zerolatency bitrate=500 speed-preset=superfast key-int-max=60 ! h264parse ! queue ! mux. audiotestsrc ! audio/x-raw,rate=44100 ! voaacenc bitrate=128000 ! queue ! mux. flvmux streamable=true name=mux ! rtmpsink location="rtmp:///" ``` ## Command breakdown The table describes each part of the command: ### Video component
Command Description
videotestsrc This is a test video source in GStreamer, which generates a test pattern. Replace this with your actual video source (e.g. v4l2src for webcams).
video/x-raw,width=1920,height=1080,framerate=30/1 This caps filter sets the resolution and framerate of the raw video (1920x1080 sets the resolution to 1080p).
x264enc Encodes the video as H.264. tune=zerolatency lowers latency. bitrate=500 sets the bitrate to 500 kbps. speed-preset=superfast selects the encoding-speed preset. key-int-max=60 sets a 60-frame keyframe interval, which is two seconds at 30 frames per second. Match this value to the Input key frame interval configured in MK.IO. h264parse prepares the H.264 stream for RTMP.
### Audio component
Command Description
audiotestsrc A test audio source for generating sample audio. Replace with your own audio source.
voaacenc Encodes the audio to AAC, which is compatible with RTMP.
queue Adds buffers between streams to help with sync issues.
### RTMP component
Command Description
flvmux Packs the H.264 video (and audio if included) into an FLV container, suitable for RTMP.
rtmpsink Sends the output stream to an RTMP server.
location="rtmp://<rtmp-server-ip-or-url>/<path>" The RTMP Input URL provided after you start the live event.
# Set up the source stream using OBS Open Broadcaster Software (OBS) Studio can send a camera, capture device, or test source to an MK.IO live event over RTMP. Configure the source, encoder, and MK.IO input URL before you start streaming. ## Install OBS Studio 1. Download and install OBS for your operating system on the [Open Broadcaster Software website](https://obsproject.com/). 2. Start the application. OBS starts with a default scene but with no inputs selected. ## Add a video source 1. From the **Sources** panel, select the add icon. 2. Select **Video Capture Device**. 3. Select **Add Existing**, then select **OK**. 4. From the **Device** list, select the video input for the broadcast. 5. Leave the remaining settings unchanged and select **OK**. The input appears in the **Sources** panel and the video appears in the preview. ### Add a browser test source If you do not have a capture device ready, you can use a browser source for a first test: 1. Select the add icon under **Sources**. 2. Select **Browser**. 3. Name the source `Clock` and enter `https://vclock.com` as its URL. If the source shows a cookie-consent prompt, right-click the browser source, select **Interact**, and accept the prompt. ## Add an audio source 1. From the **Sources** panel, select the add icon. 2. Select **Audio Input Capture**. 3. Select **Add Existing**, then select **OK**. 4. From the **Device** list, select the audio capture device for the broadcast. 5. Leave the remaining settings unchanged and select **OK**. The audio capture device appears in the audio mixer. ## Set up streaming and advanced encoding settings Before continuing, [start the live event](/mkio/how-to/live-streaming/set-up-a-live-streaming-event#start-streaming) and copy its **Input URL**. 1. Select **Settings** in the **Controls** panel. 2. Select **Stream** in the left menu. 3. From **Service**, select **Show all**, then select **Custom**. 4. In **Server**, paste the RTMP input URL without the final `/stream` suffix. 5. In **Stream Key**, enter a valid stream name, such as `stream`. 6. Select **Output** in the left menu. 7. Set **Output Mode** to **Advanced**. 8. On the **Streaming** tab, select the encoder settings for the computer's processor and capabilities: - Set **Audio Encoder** to FFmpeg AAC or CoreAudio AAC. - Set **Video Encoder** to x264. - Use constant bitrate (CBR) rate control. - Match **Keyframe interval** to the **Input key frame interval** configured in [MK.IO](/mkio/how-to/live-streaming/set-up-a-live-streaming-event#configure-a-live-event). ## Set audio settings 1. Select **Output** > **Audio**. 2. Set **Audio Bitrate** for the source. 3. Set **Sample Rate** to 48 kHz. ## Set video settings 1. Select **Output** > **Video**. 2. Set **Output (Scaled) Resolution** to **1920x1080**. 3. Set **Common FPS Values** for the source. 4. Select **OK**. ## Start streaming The combined video and audio bitrate must not exceed the live event's bandwidth limit. 1. In the **Controls** panel, select **Start Streaming**. 2. Return to the live event in MK.IO, then select **Apply**. 3. Confirm that the source appears in the preview. 4. Copy the playback URLs for use in a compatible player or application. ## Check the OBS status Use the OBS status bar to check the source while it is running: - **Bitrate** shows how much data OBS sends each second. It should remain stable. - **Dropped frames** should remain at 0 percent. A rising value indicates a network or processor problem. - **FPS** shows the frame rate sent by OBS. - **CPU usage** should remain below 60 percent. Usage near 90 percent can affect the output quality. ![OBS status bar showing stream bitrate, dropped frames, frame rate, and CPU usage](/images/obs-example.png) # Edge devices Use the MK.IO portal to onboard an edge device, inspect fleet status and device locations, open a remote device UI, update software, and collect recovery or support data. The **Edge** section provides a unified device list and a map of registered device locations. ## Device lifecycle - [Onboard edge devices](/mkio/how-to/managing-edge-devices/on-board-fleet-devices) - [View device information](/mkio/how-to/managing-edge-devices/display-device-information) - [Access the remote device UI](/mkio/how-to/managing-edge-devices/access-the-remote-device-ui) - [Update device software](/mkio/how-to/managing-edge-devices/update-device-software) - [Manage configuration backups](/mkio/how-to/managing-edge-devices/configuration-backups) - [Create support packages](/mkio/how-to/managing-edge-devices/support-packages) Use the [Fleet API Guides](/beam/api-guides/how-to/fleets) for device management, backups and restores, and software update automation. # Access the remote device UI Access a registered device's local web interface through MK.IO when you cannot connect to its local network. MK.IO proxies the interface over a secure tunnel. 1. Open the project that contains the device, then go to **Devices**. 2. Select the device. 3. In the top-right corner of the properties panel, select **Access remote UI**. Log in to the device interface and use it as you would on the local network. The following functionality is not available through the remote UI: - Downloading a support package from **Servers**. Use [Collect device logs](/mkio/how-to/managing-edge-devices/support-packages) in MK.IO instead. MK.IO generates the package and emails you a download link. - Uploading a software bundle from **Appliance**. You can perform these actions by accessing the unit directly on a connected network. # Configuration backups Use configuration backups to save and restore the services configuration of a Beam device. Backup and restore only apply to services created on the device. Backups are stored as `.tar.gz` files in cloud storage and can optionally include the device's Asset Management service configuration. ## Where to find it To view backups for a specific device: 1. Go to **Devices**, and select a device. 2. Click `Ellipsis` icon on the device. 3. Select **Configuration backups**. To view backups across all devices, under one view 1. go to **Devices** 2. Click **All config backups** button. ## Create a backup 1. Open the device's **Configuration backups** page 2. Click **Backup Now** button. 3. The **Backup name** field is pre-filled with `{devicename}-{datetime}`. Edit it or keep it as-is. 4. To include the device's Asset Management service configuration, check **Backup asset file**.

Configuration backup does not include the asset files, only the Asset Management service's configuration.

5. Click **Create**.

You can create a maximum of 100 backups per project. Delete older backups before creating new ones if the limit is reached.

You can create only one backup per device at a time. A second request while one is in progress returns a 429 error.

## Restore a backup ### Restore to the current device Available only from a device-specific **Configuration backups** page. 1. Open **Configuration backups** for the device 2. **Configuration backups** page lists all backups for the device 3. Click `Ellipsis` icon on the backup you want to restore 4. Click **Restore** in the menu. 5. To restore the Asset Management service configuration, check **Restore asset file** (only applies if the backup includes it). 6. Click **Restore** to confirm.

Restoring a backup removes all services on the device and replaces them with the backed-up configuration. This cannot be undone. Consider creating a new backup before you restore.

### Restore to a different device 1. Open **Configuration backups** page 2. Click `Ellipsis` icon on the backup row you want to restore 3. Click **Restore to devices...**. 4. To restore the Asset Management service configuration, check **Restore asset file**. 5. Select one or more target devices. 6. Click **Restore**. MK.IO restores the backup to all selected devices simultaneously. If only some devices fail, the successful restores are still applied and an error is shown for the failed ones. ## Rename a backup 1. On a backup row, click `Ellipsis` icon 2. Click **Rename backup**. 3. Enter a new **Backup Name**. 4. Click **Save**. ## Download a backup 1. On a backup row, click `Ellipsis` icon 2. Click **Download backup**. 3. The `.tar.gz` file downloads to your local machine. You can re-upload downloaded backups to the same or a different project. ## Upload a backup 1. Go to device's **Configuration backups** page 2. Click **Upload** button. 3. In the **Upload backup file** drawer, drag and drop or select a `.tar.gz` backup file previously downloaded from MK.IO. 4. Click **Upload**. MK.IO verifies the file's signature, customer ID, and metadata before accepting it. Once uploaded, the backup appears in the list and can be restored like any other. ## Delete a backup 1. On a backup row, click `Ellipsis` icon 2. Click **Delete backup**. 3. Click **Delete** to confirm.

Deletion is permanent. There is no recovery mechanism.

# View device information Devices provide detailed information about their status and configuration, including: - Alarm and contact status: facilitates centralized monitoring. - Current software version and preloaded software versions that are ready to deploy: enables centralized [software upgrade](/mkio/how-to/managing-edge-devices/update-device-software). - Network interfaces: displays IP and ASI/SDI interfaces. # On-board edge devices Prepare an edge device, connect it to MK.IO, and register it to a project. Choose the onboarding path that matches how the installer can access the device. ## On-boarding paths Different network environments call for different on-boarding approaches. Choose the path that fits your setup: [Common workflow](/mkio/how-to/managing-edge-devices/on-board-fleet-devices/common-workflow) Set the device Control interface IP, connect to the device web UI, copy a short code, and enter it in MK.IO. [On-boarding via device terminal only](/mkio/how-to/managing-edge-devices/on-board-fleet-devices/terminal-only) Use when the installing engineer cannot access the device web UI. Obtain the Device ID from the terminal and register using the MK.IO UI. [On-boarding via API](/mkio/how-to/managing-edge-devices/on-board-fleet-devices/api-onboarding) Register the device using the MK.IO API instead of the MK.IO UI. The device must still have internet access. [Removing devices](/mkio/how-to/managing-edge-devices/on-board-fleet-devices/remove-device) How to remove an edge device from MK.IO using the UI or API. [Troubleshooting](/mkio/how-to/managing-edge-devices/on-board-fleet-devices/troubleshooting) How to troubleshoot common issues when on-boarding edge devices. Use the [Fleet device management API Guide](/beam/api-guides/how-to/fleets/device-management) to register, inspect, update, or remove devices through the Fleet API. # On-board edge devices using MK.IO API Prepare an edge device and register it to a project through the MK.IO Fleet API instead of the portal. The device must still be connected to the internet. ## Prerequisites - You can access the device's local web UI or terminal. - You have an [API token](/mkio/api-guides/getting-started/authentication) with access to the target project. ## Add the device to MK.IO The on-boarding process has two parts: 1. Prepare the device and obtain a **short code** or **device ID**. 2. Use the code to register the device [via the MK.IO API](/mkio/how-to/managing-edge-devices/on-board-fleet-devices/api-onboarding#add-the-device-using-the-mkio-api). Once registered, the device is available for monitoring and control through MK.IO.

Remote on-boarding

The two steps above do not need to be completed by the same person. In a remote on-boarding scenario, the engineer installing the device can pass the short code verbally to an MK.IO user with permission to register it.

## Prepare the device Choose one preparation path: - **Local web UI**: Follow [Connect the device to MK.IO](/mkio/how-to/managing-edge-devices/on-board-fleet-devices/common-workflow#connect-the-device-to-mkio-from-the-device-ui), then copy the short code or device ID. - **Device terminal**: Follow [Obtain the device ID](/mkio/how-to/managing-edge-devices/on-board-fleet-devices/terminal-only#obtain-the-device-id).

The short code rotates periodically. Keep the device UI open until registration is complete, or use the longer-lived device ID.

### Add the device using the MK.IO API Register the device using the short code in the `spec.shortCode` field. Alternatively, use the longer-lived device ID shown in the device web UI or terminal in the `spec.locationId` field: **PUT** `https://app.mk.io/api/v1/projects/project_name/fleet/devices/device1` ```json { "metadata": { "displayName": "Device 1" }, "spec": { "siteName": "world", "locationId": "a7dafdba-4923-4317-aad1-dc76284b85b5" } } ``` ### Verify on-boarding Once the device is registered, go back to **Appliance** > **Fleet** in the device's local web UI. The **Registered** field shows **Yes** and displays the device's name. You can now [view device information](/mkio/how-to/managing-edge-devices/display-device-information) and [access the remote UI](/mkio/how-to/managing-edge-devices/access-the-remote-device-ui). ### Update device software Once the device is registered, before commissioning, [update the device software to the latest version](/mkio/how-to/managing-edge-devices/update-device-software). # On-board edge devices common workflow Register an edge device with the standard portal workflow. Set the device Control interface IP, open the local web UI, copy its short code, and enter the code in MK.IO. ## Prerequisites - You can access the device's local web UI at `http://`, where `` is the IP address of the _Control_ interface of the edge device. ## Overview of adding the device to MK.IO This on-boarding process has two parts: 1. From the device's local web UI, [connect the device to MK.IO](/mkio/how-to/managing-edge-devices/on-board-fleet-devices/common-workflow#connect-the-device-to-mkio-from-the-device-ui). The UI displays a **short code**. 2. Use the short code to register the device [via the MK.IO UI](/mkio/how-to/managing-edge-devices/on-board-fleet-devices/common-workflow#add-the-device-using-the-mkio-ui). Once registered, the device is available for monitoring and control through MK.IO.

Remote on-boarding

The two steps above do not need to be completed by the same person. In a remote on-boarding scenario, the engineer installing the device can pass the short code verbally to an MK.IO user with permission to register it.

### Configure an HTTP proxy (optional) A proxy only needs to be configured when internet connectivity for MK.IO is only possible via a proxy. 1. Open the device's local web UI: `http://`. 2. Go to **Appliance** > **Fleet**. 3. Select `Gear` icon next to the **Connected** field. 4. Enter the **Proxy IP Address**, **Port**, **Username**, and **Password**. 5. Select **Apply**. ### Connect the device to MK.IO from the device UI 1. Open the device's local web UI: `http://`. 2. Go to **Appliance** > **Fleet**. After a few seconds, additional information appears. 3. Confirm the **Connected** field shows **Yes**. This confirms the device can reach MK.IO. Select `Wrench` icon to run diagnostics if needed. 4. Confirm that the **Registered** field shows **No** before you complete registration. 5. Copy the **short code** (eight random letters and numbers) from this page.

The short code rotates periodically. Keep the device UI open until you complete registration because the UI updates automatically when the code changes.

### Add the device using the MK.IO UI The device must have connected to MK.IO before you can register it. If the **Connected** field showed **No** in the previous step, resolve that before continuing. 1. In a separate browser tab, log in to MK.IO. If you do not have an account, see [Sign up to MK.IO](/mkio/getting-started/account-setup-and-first-steps). 2. Open the project you want to add the device to and go to the **Devices** page. 3. Select **Add device**, then enter the short code, a display name, and the site. 4. Select **Add**. The device appears in the list of edge devices. ### Verify on-boarding Once the device is registered, go back to **Appliance** > **Fleet** in the device's local web UI. The **Registered** field shows **Yes** and displays the device's name. You can now [view device information](/mkio/how-to/managing-edge-devices/display-device-information) and [access the remote UI](/mkio/how-to/managing-edge-devices/access-the-remote-device-ui). ### Update device software Once the device is registered, before commissioning, [update the device software to the latest version](/mkio/how-to/managing-edge-devices/update-device-software). # Remove edge devices Remove an edge device through the MK.IO portal or Fleet API when it should no longer belong to the project. ## Remove a device ### Remove a device using the MK.IO UI 1. Log in to MK.IO. 2. Open the project you want to remove the device from and go to the **Devices** page. 3. Click on the device you want to remove. If needed, use **Search here**. 4. Click `Ellipsis` icon then **Delete device**. 5. Click **Delete** to confirm. ### Remove using the MK.IO API To remove a device, send a DELETE request: ```http DELETE https://app.mk.io/api/v1/projects/project_name/fleet/devices/device1 ``` ### Resolve removal warnings The API (and UI) displays a warning if either of the following is true: - The device does not have an up-to-date usage report. - The last usage report shows services were still running on the device. To resolve this: 1. Confirm the device is powered on and can connect to MK.IO. Check the **Connected** status under **Appliance** > **Fleet**. 2. Stop all services on the device. Use the [remote UI](/mkio/how-to/managing-edge-devices/access-the-remote-device-ui) if needed. 3. Wait for the usage report to update. This can take 10 to 20 minutes. 4. Retry the DELETE request. ### Force delete an unreachable device If the device cannot be accessed due to hardware failure, force the deletion by adding query parameters to the request: ```http DELETE https://app.mk.io/api/v1/projects/project_name/fleet/devices/device1?force=true&reason=¬es= ```
Parameter Description
force Set to true to enable force deletion.
reason One of: Failed, Maintenance, Storage, Other.
notes A description of the reason. Required when reason is Other. Minimum 5 characters, maximum 255 characters.
# On-board edge devices using device terminal only Connect and register an edge device from its terminal when the installing engineer cannot access the local web UI. ## Prerequisites - The device has been [configured with a _Control IP address_](/beam/quick-start#set-control-ip-address). - You can access the device's terminal via a keyboard and monitor or via SSH. ## Overview of adding the device to MK.IO This on-boarding process has two parts: 1. From the device's local terminal, copy the **Device ID**. 2. Use the **Device ID** to register the device [via the MK.IO UI](/mkio/how-to/managing-edge-devices/on-board-fleet-devices/terminal-only#add-the-device-using-the-mkio-ui). Once registered, the device is available for monitoring and control through MK.IO, including its web UI.

Remote on-boarding

The two steps above do not need to be completed by the same person. In a remote on-boarding scenario, the engineer installing the device can pass the Device ID verbally to an MK.IO user with permission to register it.

### Configure an HTTP proxy (optional) A proxy only needs to be configured when internet connectivity for MK.IO is only possible via a proxy. Running this command without changing any settings also lets you diagnose connectivity issues. 1. Log in to the device's terminal. 2. Run the `control-wizard` command. 3. Press **P** to configure a proxy. 4. Enter the **Proxy IP Address**, **Port**, **Username**, and **Password**. 5. Press **Enter** to apply. 6. Proxy settings are tested and results displayed on screen. 7. Press **Q** to quit. ### Obtain the Device ID The **Device ID** displays on the device's terminal. Press **Enter** if needed to clear the screen. It also displays when you log in to the device terminal through SSH. ### Add the device using the MK.IO UI

The device must have connected to MK.IO before you can register it. If the device cannot reach MK.IO, see Troubleshooting on-boarding.

Follow [Add the device using the MK.IO UI](/mkio/how-to/managing-edge-devices/on-board-fleet-devices/common-workflow#add-the-device-using-the-mkio-ui). Enter the **Device ID** in place of the short code. ### Verify on-boarding You can now [view device information](/mkio/how-to/managing-edge-devices/display-device-information) and [access the remote UI](/mkio/how-to/managing-edge-devices/access-the-remote-device-ui). ### Update device software Once the device is registered, before commissioning, [update the device software to the latest version](/mkio/how-to/managing-edge-devices/update-device-software). # Troubleshooting on-boarding of edge devices Use these checks when an edge device cannot connect to MK.IO or complete registration. ## Prerequisites - All edge devices require a [network interface configured as Control with an IP address](/beam/quick-start#set-control-ip-address). - [DNS addresses that can resolve external domain names](/beam/system-admin/network/configure-nics#set-dns-addresses) such as `https://api.mk.io/`. - To register and manage an edge device, it must be able to connect to `https://api.mk.io/`. This requires either: - A default gateway that can route to the internet, and any customer-managed firewall MUST allow egress TCP port 443 to `https://api.mk.io/`. - _Or_, configuration to use an [HTTP proxy](/mkio/how-to/managing-edge-devices/on-board-fleet-devices/common-workflow#configure-an-http-proxy-optional) that can reach `https://api.mk.io/`. - The device must have connected at least once to `https://app.mk.io/` before it can be registered. ## Cannot add device When manually adding a device via the MK.IO UI, you may see an error similar to: `1000.4500.1500.1300 - Device is not recognised. A device with this ID has never connected to MK.IO. Connect the device to MK.IO and try again.` Check that the device network settings are correctly configured. See [Network Configuration](/beam/system-admin/network/configure-nics). ## Connected field shows No in the device web UI **Diagnose via the device's local web UI:** 1. Open the device's local web UI: `http://`. 2. Go to **Appliance** > **Fleet**. After a few seconds, additional information appears. 3. Click `Wrench` icon next to the **Connected: No** field to run diagnostics. 4. Resolve the network problem or configuration issue, then try again. **Diagnose via the device's local terminal:** 1. Log in to the device's terminal. 2. Run the `control-wizard` command. 3. MK.IO API connectivity is tested and results display on screen. 4. Press **Q** to quit. ## Short code not accepted Short codes are short-lived. You can also use the **Device ID**. # Support packages Use **Collect device logs** in MK.IO to generate a support package for a Beam device and share it with MediaKind support. When you trigger the collection, MK.IO gathers the logs from the device in the background and emails you a download link you can forward to support. "Collect device logs" and "generate support package" are synonymous terms. If the device is managed directly rather than through MK.IO, generate the support package from the server UI instead. See [Generate a Support Package](/beam/system-admin/maintenance/generate-support-package). ## Where to find it 1. Go to **Devices** and select a device. 2. Click `Ellipsis` icon on the device. 3. Select **Collect device logs**.

Collect device logs is disabled if the device software version does not support this feature.

## Collect logs 1. Open the device action menu and click **Collect device logs**. 2. In the **Describe the issue** field, enter a description of the problem you are experiencing. This field is required. 3. Click **Collect logs**. MK.IO collects logs from the device in the background. Once complete, an email is sent to your account address with a download link that you can share with support. The download link will be valid for 30 days. A maximum of 5 support packages per device will be kept.

Only one log collection can run per device at a time. If a collection is already in progress, the drawer shows the current status. Wait for it to complete before requesting a new one.

In a Beam HA setup, log collection is only available on the active controller device.

# Update device software Use MK.IO to inspect and update the software running on a MediaKind Beam device. When the subscription supports software updates, available versions appear on the device's **Software** panel. 1. In MK.IO, open the project that contains the device. 2. Go to **Devices**, then select the device. 3. In the **Software** panel, use the version menu to preload an available bundle or deploy a downloaded bundle. For automation, use the [Software and updates API Guide](/beam/api-guides/how-to/fleets/software-and-updates). MK.IO provides the following functions: - View the current software bundle version. - View the bundle available for rollback. - View the bundles downloaded and ready to deploy. - Download a bundle and monitor its progress. - Switch the device to a downloaded bundle. - Roll back to the previous bundle.

Software bundles

MK.IO updates the full operating system and software stack through software bundles and the dual-bank mechanism in Beam devices. If the selected version matches the version in the second bank, the device performs a rollback instead of an upgrade or downgrade.

Beam devices can store multiple software bundles for deployment. Storage for bundles is limited, so the device automatically deletes older bundles when a new bundle needs more space. # Organization settings Organization settings control who can access MK.IO, how integrations authenticate, where event notifications are sent, and how usage is billed. ## Access and authentication - [Invite a user](/mkio/how-to/managing-your-organization/invite-users-to-organization). - [Manage users, teams, and project access](/mkio/how-to/managing-your-organization/access-users-and-teams). - [Create API tokens](/mkio/how-to/managing-your-organization/api-tokens). - [Create restricted access tokens](/mkio/how-to/managing-your-organization/restricted-access-tokens). ## Integrations and billing - [Configure webhooks](/mkio/how-to/managing-your-organization/webhooks). - [Review billing](/mkio/how-to/managing-your-organization/billing). - [Accept an Azure Marketplace private offer](/mkio/how-to/managing-your-organization/accept-an-azure-marketplace-private-offer). - [Subscribe through AWS Marketplace](/mkio/how-to/managing-your-organization/subscribe-through-aws-marketplace). Use the [Management API Guides](/mkio/api-guides/how-to/management) to automate users, teams, tokens, organizations, webhooks, usage, and billing workflows. # Accept an Azure Marketplace private offer A private offer is a custom Azure Marketplace plan that MediaKind prepares for a specific customer, typically in exchange for a committed spend. Use this guide to redeem a private offer for MK.IO through Azure Marketplace and activate the resulting subscription. ## Prerequisites Before you begin, make sure you have: - A private offer for MK.IO that MediaKind has issued to your organization in Azure Marketplace. - Permission to create resources in the Azure subscription and resource group where the Software as a Service (SaaS) subscription will live. - An MK.IO account that belongs to the organization the offer was issued to. This applies even if you are a partner or contractor completing the redemption on the organization's behalf. If you are not yet a member, ask an administrator of that organization to [invite you](/mkio/how-to/managing-your-organization/invite-users-to-organization).
Expect delays between steps

Azure can take up to an hour to move from one step to the next. If a status does not update immediately, wait before retrying.

## Redeem the offer ### Review and accept the offer Open the offer on the private offer management page in Azure Marketplace. Once you accept the offer, its status changes to **Accepted**, and the associated product shows a status of **Ready for purchase**. ![The private offer management page in Azure Marketplace showing an accepted offer with the product ready for purchase.](/_machine-assets/784617872177c3db134230711eef29623b4fb0e36a295d4db06cd32356641ffd.png) ### Purchase the offer Select **Purchase** next to the product to start the subscription wizard. On the **Basics** tab: - Choose your Azure subscription and resource group, or select **Create new** to create a resource group. - Enter a name for your MK.IO subscription under **SaaS details**. ![The Basics tab of the Azure subscription wizard showing the subscription, resource group, and SaaS name fields.](/_machine-assets/77ecbadcac77bbc7753a5d68c586e58019c74e7159028fe43f9bd3a8b6a538b1.png) The **Plan** field shows the plan MediaKind prepared for your organization. Continue to the **Tags** tab, then select **Review + subscribe**. Review the terms of use, confirm your contact details (name, email, and phone number), and select **Subscribe**. Azure creates the SaaS subscription. This can take several minutes. ### Configure your MK.IO account Once the subscription is created, Azure shows a confirmation page stating that the purchase is not yet complete, and emails you instructions for setting up your SaaS account. Select **Configure account now** to continue. ![The Azure subscription progress page showing the Configure account now button and the 30-day completion warning.](/_machine-assets/e811201aea93f96f9b726bee7008d78e97fcf2e4df764cd1d2485cfb786d3a73.png)
Complete this step within 30 days

Billing does not start until you configure your account. If you take no action within 30 days, Azure automatically deletes the SaaS subscription.

**Configure account now** redirects you to MK.IO. Sign in with the MK.IO account associated with your organization, then accept the MK.IO terms and conditions to activate the subscription. MK.IO creates a payment method for the offer. You can now create a new project and assign it to the payment method. To use the offer for existing projects, [move the projects to the new payment method](/mkio/how-to/managing-your-organization/billing#move-a-project-between-payment-methods). ## Next steps - [Create your first project](/mkio/getting-started/account-setup-and-first-steps#create-a-project) - [How payment methods work](/mkio/understanding/fundamentals/orgsandteams) # Access, users and teams MK.IO uses **role-based access control (RBAC)** to manage who can access resources and what they can do. Users are assigned permissions through teams, allowing you to control access to projects across your organization. ## Concepts - **Organization:** A company or group that uses MK.IO. - **Project:** Holds resources such as assets, live events, and transforms. Projects are linked to an organization and to a subscription **or** payment method for billing. - **User:** An individual who may belong to multiple teams and organizations. A user's permissions are granted through teams. - **Team:** A group of users within an organization. Teams are granted permissions on projects and resources. ![Relationship between Organization, Team, User and Project](/images/mkio-rbac-simplified.png) Relationship between Administrators, Teams, Users and Projects The first user in an organization is automatically granted **Administrators** access. Administrators have full control over the system, including the ability to invite users and create new teams. ## Manage teams Project access is granted to users through teams. By default, every organization has two predefined teams: **Administrators** and **Everyone**. - **Administrators**: full access and administrative rights to all projects, including organization-level permissions such as viewing billing information. - **Everyone**: automatically includes all users in the organization. By default, this team provides access to all projects at a permission level set by Administrators: either _User_ or _Reader_. Optionally, it can be configured to have no access. ![Teams management page showing Administrators and Everyone teams](/images/mkio-access-users-teams-2.png) ## Create a team

This action is only available to members of the Administrators team.

1. From the profile drop-down menu in the top right corner, navigate to **Organization Settings**, then select **Access Management**. 2. From the **Teams** tab, click **Create Team**, then enter a name and a description. 3. Click the team name to open it and manage members, projects, and access levels. ## Edit team members

This action is only available to members of the Administrators team, or Team admins for the relevant team.

From the **Teams** tab, select a team. Use the **Add user** button to add members. To set a user as a **Team admin** or remove them from the team, select the three-dot menu to the right of their username. ## Edit project access for a team

This action is only available to members of the Administrators team.

1. From the **Teams** tab, select a team. 2. In the right-hand pane, add the projects the team should have access to. 3. For each project, select the access level: - **Reader**: read-only access. - **User**: full access to create and modify objects in the project. ## Edit team details or delete a team

This action is only available to members of the Administrators team.

From the **Teams** tab, select the three vertical dots in the top right corner, then select the appropriate action. ## Manage access with the API Use the [Users and teams API Guide](/mkio/api-guides/how-to/management/users-and-teams) to manage organization membership and team access through the Management API. # API tokens Making an API request to access MK.IO services requires a token for authentication. An API token is a unique character string that identifies you to the API. It acts like a key that tells the API who you are and what you are allowed to do. Using an API token ensures that only authorized users and applications can access API services. The personal token contains the following information: - The identity of the user. - The identity of the organization. - The token type and expiration date. - Optionally, a set of permissions if the token only grants a subset of the user's permissions. ## Create a personal API token 1. From the profile drop-down menu in the top right corner, click your email, then navigate to the **Your personal API tokens** section. 2. Click **Add Token**, then enter a description and the expiration date (UTC time). 3. Click **Create**. Once created, copy the token to a secure location. It is only visible for 5 minutes. ## View tokens - **As a user:** From the profile drop-down menu in the top right corner, click your email, then navigate to the **Your personal API Tokens** section. You can only see the tokens you created. - **As an Admin:** From the profile drop-down menu, navigate to **Organization Settings**, then select **API Tokens**. You can view all API tokens and their creators. ## Revoke an API token For each token in the list, select the action button at the right of the row to view the token details or revoke it. ## Manage tokens with the API Use the [Tokens API Guide](/mkio/api-guides/how-to/management/tokens) for token endpoints, authentication headers, and revocation workflows. # Billing Use the **Billing** view within **Organization settings** to see your entitlements, review your spend, and understand your usage.

Billing information is organization-level, so the full billing view is available to Administrators only.

## Open billing 1. Select the profile menu in the top-right corner. 2. Select **Organization settings**. 3. Select **Billing** in the left sidebar. If you belong to multiple organizations, switch to the correct organization before opening **Billing**. You will be presented with the following information: ![Billing overview page showing billing filters, month-to-date totals, previous month spend, and payment method rows](/images/mkio/billing-overview.png) ## Understanding the billing overview The billing overview shows organization spend across projects, products, and payment methods. Use the product tabs to filter the view by **All**, **MK.IO**, or **MK.IO Beam**.
Area What it shows
Total now The current billing-month total across the selected product view. The line chart includes a dotted estimate for the rest of the month.
Previous month Previous monthly spend. Use the range selector to switch between 1 year, 6 months, and 3 months.
Payment method rows Each payment method associated with the organization, with the current total, project-level amounts, and a small spend chart when data is available.
Add payment method Add a new payment method via either Azure Marketplace or AWS Marketplace.
Billing updates can take approimately an hour to appear in the overview. ## Understand payment methods A **payment method** represents how your organization pays MediaKind for MK.IO services. Payment methods can represent **Azure Marketplace**, **AWS Marketplace**, or **direct sale contracts** with MediaKind. Each project is associated with a payment method. An organization can have more than one payment method, and each payment method can have different projects associated with it. For more context, see [Payment methods](/mkio/understanding/fundamentals/orgsandteams#payment-methods). Each payment method can have a display name, which helps distinguish it from other payment methods associated with the same sales order, for example, when separate payment methods cover an Enterprise License Agreement (ELA) and contribution charges. Display names appear in the **Name** column of the payment methods list. If you can access only some projects in an organization, the full billing page may not be available. In that case, MK.IO can show that billing is managed by another organization instead of showing organization-wide billing details. ## Move a project between payment methods Organization administrators can assign an existing project to another payment method in the same organization. Use this when a billing arrangement changes, such as when you activate a private marketplace offer. 1. Select the profile menu in the top-right corner. 2. Select **Organization settings**. 3. Select **Projects** in the left sidebar. 4. Find the project you want to move. The **Payment method** column shows its current assignment. 5. Open the three-dot menu for the project, then select **Change payment method**. 6. Assign the project to the destination payment method. Repeat these steps for each additional project you want to move. ## View payment method details Select a payment method row to open its monthly details: ![Payment method details page showing project tabs, service filtering, meter rows, and CSV download](/images/mkio/billing-payment-method-details.png) The payment method detail view includes: - Month navigation, including **This month**. - Project tabs, including **All projects** and one tab for each project associated with the payment method. - A **Service** filter. - Service groups and meter rows with monthly capacity, monthly peak usage, usage, and total columns. - **Download details as CSV** for the selected view. ## View daily meter details Select a meter row to open the daily detail view for that meter. ![Daily billing detail dialog showing total overage amount, usage, daily rows, and CSV download](/images/mkio/billing-daily-detail.png) The daily detail view shows the total overage amount, total usage, daily rows, and a separate **Download details as CSV** link.
Usage can be reported later

A monthly detail view can include usage from a previous month when that usage was reported during the selected month.

## Change Beam billing model Administrators can edit the Beam billing model for a payment method. ![Edit payment method dialog showing measured consumption and capacity consumption options](/images/mkio/billing-model-edit.png) 1. From the billing overview, open the three-dot menu for a payment method. 2. Open **Edit payment method**. 3. Under **Beam billing model**, select one of the following options: - **Measured consumption**: overages are billed per minute for each running workload on Beam devices. This is the default model. - **Capacity consumption**: billing is based on the highest number of channels or workloads running at the same time during the calendar month. Additional entitlements are valid for the current calendar month. 4. Select **Save changes**.
Beam billing model scope

The Beam billing model setting does not affect MK.IO cloud services.

The Beam billing model choice applies to Beam contribution, reception, and encoding meters. Throughput meters, such as multiplexing and packaging, are always charged by usage, even when **Capacity consumption** is selected. Enterprise License Agreement (ELA) usage is also an exception: usage above purchased capacity is handled as additional capacity for the month.

Measured consumption can be more suitable for short overages. Capacity consumption can be more suitable when additional channels or workloads run for longer periods.

# Invite a user to your organization To collaborate on projects, you need to invite users to join your organization. Invitees receive an email and can accept the invite to gain access.

This action is only available to members of the Administrators team.

1. From the profile drop-down menu in the top right corner, navigate to **Organization Settings**, then select **Access Management**. 2. From the **Invites** tab, click **Invite User**, then enter an email address. Invitees automatically join the [**Everyone** team](/mkio/how-to/managing-your-organization/access-users-and-teams#manage-teams), but you can also invite them to an additional team. 3. Click **Add**. Your colleague will receive an invitation in their mailbox.

The invitation appears as Pending until accepted. Pending invitations can be re-sent or canceled. Invitations expire after 14 days.

## Accept an invitation If an Administrator invites you, you will receive an email containing an MK.IO invitation link. 1. Follow the link in the email. 2. Log in using one of the following options: - **Microsoft account**: make sure you have added a [verified contact email address](https://app.mk.io/user/profile). - **Continue with email**: use the email address the invitation was sent to, or create a new account. If you create a new account, you will receive a verification code by email. 3. You will be redirected to a page prompting you to accept the invitation. Click **Accept**. If you do not see an invitation to accept, confirm that your [verified contact email address](https://app.mk.io/user/profile) matches the address the invitation was sent to. # Restricted access tokens A restricted access token lets you provide a token to an automation system or script without exposing all of your capabilities. It cannot grant more rights than you already have. **Role-based access control (RBAC)** in MK.IO is controlled by granting permissions to users. Each permission is composed of: - A **scope**: defines the resources the permission applies to. - A **role**: defines what capabilities are granted on those resources. For more details on RBAC in MK.IO, see [Access, users and teams](/mkio/how-to/managing-your-organization/access-users-and-teams). ## View your RBAC capabilities Because a restricted access token cannot exceed your existing rights, the first step is to check what you have access to. Log in to the MK.IO application at [app.mk.io](https://app.mk.io), then open [app.mk.io/api/v1/user/rbac](https://app.mk.io/api/v1/user/rbac) in a second browser tab. The response is a JSON document that describes your capabilities. If you have access to multiple organizations, switch to the correct organization first to see the right set of capabilities. The `teams` field shows how your RBAC capabilities are derived. The `rbac` field is what you use when defining a restricted token. ```json { "rbac": { "core.customer": { "00000000-0000-0000-0000-000000000000": { "core.customer": [ "get", "update" ], "core.invite": [ "create", "delete", "get", "update" ], "core.project": [ "assign", "create", "delete", "get", "update" ] } }, "core.project": { "11111111-1111-1111-1111-111111111111": { "ams.asset": [ "create", "delete", "get", "update" ], "ams.assetfilter": [ "create", "delete", "get", "update" ] } } } } ``` This example shows capabilities on a single organization (`core.customer`) and a single project (`core.project`). ## Create a restricted token Send a POST request to the tokens endpoint with a `permissions` object that is a strict subset of the `rbac` object you received above. ```shell curl --request POST \ --url https://app.mk.io/api/v1/user/tokens \ --header 'accept: application/json' \ --header 'authorization: Bearer bearer-token' \ --header 'content-type: application/json' \ --data ' { "permissions": { "core.project": { "11111111-1111-1111-1111-111111111111": { "ams.asset": [ "create", "delete", "get", "update" ] } } }, "type": "restricted", "description": "Restricted token for automation", "expireDate": "2025-08-22T10:15:00.000Z", "organizationId": "00000000-0000-0000-0000-000000000000" } ' ``` This request creates a token scoped to asset management on project `11111111-1111-1111-1111-111111111111` only. Requests using this token will be denied for any operation outside that scope. If the request succeeds, the response includes the new token details and the JWT string. ```json { "metadata": { "id": "00000000-0000-0000-0000-000000000000", "type": "restricted", "JWT": "eyJ..." }, "spec": { ... ... } } ``` Use the returned JWT for subsequent asset management operations. # Subscribe through AWS Marketplace Use AWS Marketplace when you want MK.IO usage billed through an AWS account or covered by an AWS enterprise agreement. Running MK.IO in an AWS location also lets you keep media-processing workloads close to content stored in Amazon Simple Storage Service (Amazon S3). An AWS Marketplace subscription becomes a payment method in MK.IO and provides access to the MK.IO locations available for AWS. ## Subscribe to MK.IO Open [MK.IO on AWS Marketplace](https://aws.amazon.com/marketplace/pp/prodview-ngwosmbogkc5c) and complete the subscription workflow provided by AWS. After the subscription is associated with MK.IO, use it as the payment method for projects that run in an available AWS location. See [Cloud region support](/mkio/reference/cloud-region-support#available-regions-for-aws) for the current location list. ## Prepare the project 1. [Create or open an MK.IO project](/mkio/getting-started/account-setup-and-first-steps). 2. [Connect Amazon S3 storage](/mkio/getting-started/connect-cloud-storage). 3. [Review project access](/mkio/how-to/managing-your-organization/access-users-and-teams). 4. [Review billing and payment methods](/mkio/how-to/managing-your-organization/billing). You can use subscriptions from more than one cloud marketplace in the same MK.IO organization. Each subscription appears as a separate payment method. ## AI services When you use MK.IO Artificial Intelligence (AI) services on AWS, an underlying capability may be provided by a third party. All AI use is governed by the MediaKind Data Privacy Agreement. # Webhooks Webhooks let you receive HTTP POST requests when specific events occur in MK.IO, such as a completed transcode job. You configure rules that define which events to watch and where to send the notifications. Configure webhook rules through the Management API. The MK.IO portal does not provide webhook-rule configuration. ## Configure a webhook rule Each webhook rule specifies: - The target URL for the HTTP POST request. - Custom headers (for example, an authentication token). - Query parameters to append to the request URL. - A list of event types that trigger the rule. ### Example rule ```json { "spec": { "enabled": true, "url": "https://api.example.com/webhooks", "authentication": { "headers": { "Authorization": "Bearer mytoken1234" } }, "queryParams": { "process": "123456" }, "events": [ "MediaKind.JobStarted", "MediaKind.JobFinished" ] } } ``` This rule is enabled and fires on `MediaKind.JobStarted` and `MediaKind.JobFinished` events. MK.IO sends a POST request to `https://api.example.com/webhooks?process=123456` with the `Authorization` header included. Query parameters can be set in `spec.queryParams` or `spec.authentication.queryParams`. HTTP headers can be set in `spec.headers` or `spec.authentication.headers`. Fields under the `authentication` section are write-only. When you read the rule back, those values appear as asterisks to protect your credentials from other users. ## API reference See the [webhook rules API reference](/api-reference/management-api/webhook-rules/list-webhook-rules) for endpoints to create, edit, and remove rules. ## Delivery behavior Webhook delivery runs separately from the operation that changes the resource, so a notification may not arrive immediately. MK.IO retries failed deliveries. Build the receiving endpoint to process duplicate deliveries safely and inspect the rule's event history when troubleshooting. Webhooks report the supported lifecycle events listed below. They do not notify you about every change to a resource. ## Webhook events All webhook payloads use a standard body based on [CloudEvents](https://cloudevents.io/). ### Standard data format ```json { "specversion": "1.0", "id": "{unique_id}", "type": "{webhook_type}", "source": "{object_url}", "time": "{event_time}", "datacontenttype": "application/json", "data": { "projectName": "{project_name}", "previousState": "{value of state before this event}", "state": "{new value of state}", "resource": { # The contents of the object, as if you had done a GET on {object_url} } } } ```

The resource field contains the full object as returned by a GET request on {object_url}. The comment above is illustrative and is not valid JSON.

### Jobs #### MediaKind.JobStarted This event fires when a job is removed from the queue and begins processing.
Field Value
.source /api/v1/projects/{project_name}/transforms/{transform_name}/jobs/{job_name}
.data.previousState Queued
.data.state Processing
#### MediaKind.JobFinished This event fires when a job completes, whether successfully or not.
Field Value
.source /api/v1/projects/{project_name}/transforms/{transform_name}/jobs/{job_name}
.data.previousState Processing
.data.state Canceled | Error | Finished
### Streaming locators #### MediaKind.StreamingLocatorCreated This event fires once a new streaming locator has been successfully created and is ready to use.
Field Value
.source /api/v1/projects/{project_name}/media/streamingLocators/{locator_name}
.data.previousState Creating
.data.state Created
### Scheduled operations

Scheduled operations events are only available if this feature is enabled for your organization.

#### MediaKind.ScheduledOperationAccepted This event fires once a new scheduled operation has been accepted by the scheduling engine. Initial checks have passed and the operation will proceed as requested.
Field Value
.source /api/v1/projects/{project_name}/.../scheduledOperations/{scheduled_operation_name}
.data.previousState Pending
.data.state Accepted
#### MediaKind.ScheduledOperationOngoing This event fires once the scheduling engine begins processing a scheduled operation.
Field Value
.source /api/v1/projects/{project_name}/.../scheduledOperations/{scheduled_operation_name}
.data.previousState Accepted
.data.state Ongoing
#### MediaKind.ScheduledOperationCompleted This event fires once the scheduling engine finishes processing a scheduled operation.
Field Value
.source /api/v1/projects/{project_name}/.../scheduledOperations/{scheduled_operation_name}
.data.previousState Ongoing
.data.state Completed
## Configure webhooks with the API Use the [Webhooks API Guide](/mkio/api-guides/how-to/management/webhooks) for the rule lifecycle and a complete create, list, and delete workflow. # Migrate from Azure Media Services Move existing Azure Media Services (AMS) assets into MK.IO without treating migration as a separate product area. Choose the import path for your library, then convert or publish the imported assets as required. ## Choose an import path [Import selected AMS assets](/mkio/how-to/content-management/add-an-asset-in-mkio/import-your-ams-assets) Import existing AMS assets from connected Azure storage. [Bulk import an AMS library](/mkio/how-to/content-management/add-an-asset-in-mkio/bulk-asset-migration-from-ams-storage) Import multiple AMS assets from a storage account. ## Prepare imported assets - [Verify the imported files and tracks](/mkio/how-to/content-management/verify-your-assets-in-mkio). - [Convert legacy assets](/mkio/reference/encoding-transform-presets/asset-conversion-transform) when the target workflow requires the current MP4 format. - [Publish migrated assets](/mkio/how-to/content-management/playback-your-migrated-assets) with an MK.IO streaming endpoint and locator. Use the [Assets and storage guides](/mkio/how-to/content-management) for ongoing asset management after migration. # Monitor with operational metrics Enable operational metrics when you need to monitor live events, streaming endpoints, and completed on-demand encoding jobs. The metrics you can scrape from your MK.IO can be used to monitor workflow services, including: - Live events (input & output bitrate monitoring) - Streaming endpoints (error rate, bitrate & latency) - On-demand encode jobs (count of successful & unsuccessful completed jobs) Metrics are enabled per subscription. Once enabled, you will have access to metrics for all services within your subscription.

Metrics publishing is a chargeable service and is not enabled by default. Check MK.IO pricing for current rates.

## Enable metrics on your MK.IO subscription To enable metrics on your MK.IO subscription: 1. Log in to [MK.IO](https://app.mk.io) and select a subscription. 2. From the left-hand side menu, navigate to **Usage and Metrics**. 3. Enable the metrics using the switch at the top right of the page. Once metrics are activated, MK.IO will provide you with a **URL**, a **Username** and a **Password**. This information can be used by your monitoring infrastructure to scrape the metrics from MK.IO.

You can also enable metrics through the Management API.

## Scrape metrics into Grafana Cloud Once metrics are enabled in MK.IO, you can obtain a real-time stream of metrics by scraping the “federate” endpoint returned in the enable API call. Metrics are updated every 30s. To scrape metrics into your Grafana Cloud account: 1. Log in to Grafana Cloud. Create an account if you do not already have one. 2. From the left-hand menu, go to **Connections** and click **Add new connection**. 3. In the search bar, type **Metrics Endpoint**, then open the **Metrics Endpoint** integration. 4. Click **Add new scrape job**. ### Configure the scrape job Get the details below from the MK.IO portal and enter them into Grafana. 1. **Name**: Enter a name for your scrape job. 2. **Scrape Job URL**: Use the URL provided by MK.IO (the federate endpoint), for example `https://`. 3. **Basic authentication**: Enter the **Username** and **Password** provided by MK.IO. 4. **Scrape interval**: Set the interval to **30s or 1 minute**. Use 30s if you need tighter real-time visibility; use 1 minute to reduce cost and data volume. 5. **Test Connection** to verify the endpoint is reachable. 6. Click **Save Scrape Job**. ### View metrics 1. Import the [MK.IO dashboard](https://grafana.com/grafana/dashboards/21657-mk-io-metrics-monitor/) into your Grafana Cloud account, or 2. Open **Explore** and search for metrics starting with `mk_`. For a full list of MK.IO services and supported metrics, see the **Metrics and labels** section below. ## Metrics and labels Each service in MK.IO provides different sets of metrics and labels. The "Labels" column shows labels specific to each metric. Additionally, there are labels that are common to all customer metrics: **region**, **project\_name**, **project\_id**. ### Subscription Services exposing: Subscription, Subscription quotas.
metric Description Type Labels
mk_up Always present and equal to 1 when metrics are enabled Gauge
mkio_api_assetfilters_total Total number of Asset Filters in the subscription Gauge
mkio_api_assets_total Total number of Assets in the subscription Gauge
mkio_api_contentkeypolicies_total Total number of Content Key Policies in the subscription Gauge
mkio_api_devices_total Total number of Devices in the subscription Gauge
mkio_api_filters_total Total number of Filters in the subscription Gauge
mkio_api_jobs_total Total number of Jobs in the subscription Gauge
mkio_api_jobs_running_total Total number of Jobs currently running Gauge
mkio_api_liveeventoutputs_total Total number of Live Event Outputs in the subscription Gauge
mkio_api_liveevents_total Total number of Live Events in the subscription Gauge
mkio_api_liveevents_running_total Total number of Live Events currently running Gauge
mkio_api_liveevents_stopped_total Total number of Live Events currently stopped Gauge
mkio_api_remoteconnections_total Total number of Remote Connections in the subscription Gauge
mkio_api_storageaccounts_total Total number of Storage Accounts linked to the subscription Gauge
mkio_api_streamingendpoints_total Total number of Streaming Endpoints in the subscription Gauge
mkio_api_streamingendpoints_running_total Total number of Streaming Endpoints currently running Gauge
mkio_api_streamingendpoints_stopped_total Total number of Streaming Endpoints currently stopped Gauge
mkio_api_streamingendpoints_unit_total Total number of Streaming Endpoint Units allocated Gauge
mkio_api_streaminglocators_total Total number of Streaming Locators in the subscription Gauge
mkio_api_streamingpolicies_total Total number of Streaming Policies in the subscription Gauge
mkio_api_transforms_total Total number of Transforms in the subscription Gauge
mkio_api_tunnels_total Total number of Tunnels in the subscription Gauge
### Streaming endpoint Services exposing: StreamingEndpoint.
metric Description Type Labels
mk_jitp_up Equal to 1 if a streaming endpoint is started Gauge resource_name, endpoint_type, cdn_enabled
mk_jitp_bitrate Current bitrate (bits/s). Also usable to calculate total bytes egress Gauge sc_status, content_type, resource_name, (live only: streaming_locator_id, availability)
mk_jitp_request_rate Current request rate (reqs/s) Gauge sc_status, content_type, resource_name, (live only: streaming_locator_id, availability)
mk_jitp_latency_bucket_rate Histogram providing response times for requests Histogram rate sc_status, content_type, resource_name, le, (live only: streaming_locator_id, availability)
mk_cdn_bytes_total Bytes emitted from CDN Counter resource_name
### Live events Services exposing: LiveEventPassThru, LiveEventEncode.
metric Description Type Labels
mk_live_up Equal to 1 if a live event is running Gauge resource_name
mk_live_input_bitrate_bps Bitrate arriving via RTMP or SRT Gauge resource_name, type, stream, mode
mk_live_output_storage_bitrate_bps Bitrate written to storage; includes storage write response code Gauge resource_name, sc_status
mk_live_input_etr290_bitrate_bps Input MPEG-2 TS bitrate (informational) Gauge resource_id, resource_name
mk_live_input_etr290_ts_sync_loss_total Total TS sync loss events detected (ETR-290 Priority 1) Counter resource_id, resource_name
mk_live_input_etr290_sync_byte_error_total Total sync byte errors detected (ETR-290 Priority 1) Counter resource_id, resource_name
mk_live_input_etr290_pat_error_total Total PAT errors detected (ETR-290 Priority 1) Counter resource_id, resource_name
mk_live_input_etr290_cc_error_total Total continuity counter (CC) errors detected per PID (ETR-290 Priority 2) Counter resource_id, resource_name, stream_type, stream_pid
mk_live_input_etr290_pmt_error_total Total PMT errors detected (ETR-290 Priority 2) Counter resource_id, resource_name
mk_live_input_etr290_pid_error_total Total invalid/missing PID errors detected per PID (ETR-290 Priority 2) Counter resource_id, resource_name, stream_type, stream_pid
mk_live_input_etr290_transport_error_total Total MPEG-2 TS transport errors detected (ETR-290 Priority 2) Counter resource_id, resource_name
mk_live_input_max_pcr_jitter_ppm Maximum PCR jitter (ppm) observed on MPEG-2 TS input (informational) Gauge resource_id, resource_name
### Jobs Services exposing: Jobs (VideoProcessing, etc.).
metric Description Type Labels
mk_jobs_completed_total Number of completed jobs, includes error code if success == false; for VideoProcessing “type=encoding” Counter success, type, error
# MK.IO guides Choose the product area that matches your task. The primary groups reflect the MK.IO portal so you can move between the documentation and the application without translating the navigation. ## Organize [Assets and storage](/mkio/how-to/content-management) Connect storage, add assets, manage files and tracks, and configure asset filters. ## Create [Live events](/mkio/how-to/live-streaming) Configure live events, connect a source, extend the archive window, and monitor a stream. [Video processing](/mkio/how-to/video-processing-encoding) Configure transforms, run jobs, clip inputs, and generate thumbnail outputs. [AI workflows](/mkio/how-to/ai-features) Generate transcription and translation outputs or build multi-language VOD dubbing workflows. ## Deliver [Streaming endpoints and playback](/mkio/how-to/content-delivery-publishing) Publish content, retrieve playback URLs, and integrate Amazon CloudFront. [Content key policies](/mkio/how-to/drm-content-protection) Configure encryption, DRM, token authentication, and protected playback. ## Operate and administer [Monitoring](/mkio/how-to/monitor-your-services) Publish operational metrics and monitor MK.IO services. [Organization settings](/mkio/how-to/managing-your-organization) Manage access, tokens, webhooks, billing, and marketplace offers. [Edge devices](/mkio/how-to/managing-edge-devices) Onboard devices, inspect status, update software, and manage backups and support packages. [Private storage access](/mkio/how-to/security-access-control/private-storage-link) Configure secure access between MK.IO and private storage. ## Build with the APIs The [API Guides](/mkio/api-guides) organize the same platform capabilities for automation. Start with the [Media API Guide](/mkio/api-guides/how-to/media) for assets, transforms, jobs, live events, and publishing, or the [Management API Guide](/mkio/api-guides/how-to/management) for organization workflows. - [Private storage link](/mkio/how-to/security-access-control/private-storage-link): Create and approve a private network connection between MK.IO and an Azure Storage account. # Configure a private storage link Create a private network connection when an Azure Storage account must exchange data with MK.IO through a private link. The [Storage API Guide](/mkio/api-guides/how-to/media/storage) explains the storage resource and credential model used by the request below. MK.IO already encrypts traffic to Azure Storage and authenticates with the storage account's Shared Access Signature (SAS) token. A private link adds network isolation by restricting storage traffic to an approved connection. ## Before you configure the link - Create a new MK.IO storage resource for the private connection where possible. - Complete the MK.IO request and Azure approval as one change. MK.IO requests to the storage account time out and fail until both sides are configured. - If you enable a private link on an existing storage resource, access to that storage account is interrupted until Azure approves the connection. Before making the request, configure an Azure Storage account and collect its subscription ID, resource group name, and storage account name. The request creates the MK.IO storage resource and asks Azure to establish the private connection. ```bash curl --request PUT \ --url https://app.mk.io/api/v1/projects/{project_name}/media/storage/{storage_name} \ --header 'accept: application/json' \ --header 'authorization: Bearer {your token}' \ --header 'content-type: application/json' \ --data ' { "spec": { "credential": { "sasToken": "?sv=2022-11-02&ss=bfqt&srt=co&sp=rwdlacupiyx&se=2024-11-12T00:05:04Z&st=2024-11-11T16:05:04Z&spr=https&sig=" }, "privateLinkServiceConnection": { "requestMessage": "Request access message", "resourceGroupName": "storage_account_resource_group", "storageAccountName": "storage_account", "subscriptionId": "storage_account_subscription" }, "type": "Microsoft.Storage", "description": "Input media files for processing.", "url": "https://{storage_account}.blob.core.windows.net/" } } ``` Upon successful creation of the storage account, MK.IO will issue a request to the storage account and give the request message as the description of the connection request. The request will remain pending until an explicit approval is done by the owner of the storage account in Azure. To list the pending connection requests, you will need to browse to the **Networking** configuration section of your storage account in Azure and open the **Private endpoint connections** tab as shown below: ![4fe8fcb image](/images/mkio-private-storage-link-1.png) Select the connection you want approve and hit the **Approve** button. You can use the description message to validate that this is the request from MK.IO. ![287163d image](/images/mkio-private-storage-link-2.png) Validate the connection by clicking on **Yes**. All traffic between MK.IO and the storage account now uses the private link. See [MK.IO pricing](https://mediakind.com/mkio/pricing/) for current private-link and storage-traffic rates. ## Remove a private link Update the storage resource and set `privateLinkServiceConnection` to `null`, then disable the private-link configuration in Azure. Rotate the SAS token during the same update and confirm asset access before treating the change as complete. See [Storage API Guide](/mkio/api-guides/how-to/media/storage#update-behaviour) for the update behavior. # Video processing The **Video Processing** area of the MK.IO portal contains Transforms and Jobs. A transform defines reusable processing, while a job applies that transform to an input asset and writes the result to an output asset. ## Transforms - [Configure VOD transforms](/mkio/how-to/video-processing-encoding/configure-transformations) with the presets available in the portal. - [Compare encoding transform presets](/mkio/reference/encoding-transform-presets/encoding-transform). - [Configure asset conversion transforms](/mkio/reference/encoding-transform-presets/asset-conversion-transform). - [Understand transforms and jobs](/mkio/understanding/core-concepts/transforms-and-jobs). ## Jobs - [Run VOD processing jobs](/mkio/how-to/video-processing-encoding/run-vod-transcode-jobs). - [Clip the job input](/mkio/how-to/video-processing-encoding/vod-processing-job-with-input-clipping). - [Generate thumbnail seeking output](/mkio/how-to/video-processing-encoding/playout-of-a-vod-asset-with-thumbnail-seeking). Use the [Transforms and jobs API Guide](/mkio/api-guides/how-to/media/transforms-and-jobs) to automate both resources. ## AI workflows AI workflows are configured as transforms and run as jobs. Use the [AI workflows guides](/mkio/how-to/ai-features) for transcription, translation, and VOD dubbing tasks. # Configure VOD transforms A _transform_ is a reusable template that defines how MK.IO should process a piece of content. You create a transform once with a specific type and preset, then apply it to assets by running jobs. This means you can encode hundreds of assets consistently without reconfiguring the settings each time. ## Transform types Three transform types are available in the MK.IO portal:
Type What it does
Encoding Re-encodes video into streaming-optimised formats (HLS/DASH). Supports adaptive bitrate with multiple resolution tracks. This is the most common type for VOD streaming.
AI Generates transcriptions or translations from audio. Output is a subtitle file (WebVTT or TTML) attached to the asset.
Asset conversion Converts between container formats or extracts audio without full re-encoding.

Additional transform types (for example, thumbnail generation and track insertion) are available through the MK.IO API but not in the portal. See Reference: transform presets for the full list.

## Create a transform ### Open Transforms Go to **Video Processing** > **Transforms** in the left navigation and click **+ Create Transform**. ### Name the transform Give it a descriptive name (for example, `streaming-720p` or `transcription-english`). You reference this name when creating jobs. Avoid spaces: use hyphens or underscores. ### Select the type and preset - **For Encoding**: Select **Encoding** as the type, then choose a preset. The preset defines the output resolutions, codecs, and bitrates. Common presets: - `H264MultipleBitrate1080p`: Adaptive bitrate 1080p, good for general streaming - `H264MultipleBitrate720p`: Adaptive bitrate 720p, lower cost - `H264SingleBitrate1080p`: Fixed quality single output See [Encoding transform presets](/mkio/reference/encoding-transform-presets/encoding-transform) for the complete list with bitrate specifications. - **For AI**: Select **AI** as the type, then choose the pipeline (for example, speech transcription). Specify the source audio language code (for example, `en-US` for English). See [AI workflows](/mkio/reference/encoding-transform-presets/audio-speech-transcription) for supported languages. - **For Asset conversion**: Select **Asset conversion**, then choose the conversion preset. ### Create Click **Submit**. The transform appears in your Transforms list and is ready to use. ## Run the transform A transform on its own does nothing: you apply it to an asset by creating a job. See [Run VOD processing jobs](/mkio/how-to/video-processing-encoding/run-vod-transcode-jobs) for how to create and monitor jobs. Use the [Transforms and jobs API Guide](/mkio/api-guides/how-to/media/transforms-and-jobs) to create and manage transforms through the Media API. # VOD asset with thumbnail seeking The prerequisite for a VOD playout with thumbnails seeking is the availability of a thumbnail sprite file from MK.IO. You can use the sample and guidelines from [Generate thumbnail images](/mkio/reference/encoding-transform-presets/how-to-generate-thumbnails) and [Run VOD processing jobs](/mkio/how-to/video-processing-encoding/run-vod-transcode-jobs) to generate the sprite file. A streaming locator suitable for download will also be needed to get a URL to the sprite file. More information in [Stream live or VOD assets](/mkio/how-to/content-delivery-publishing/stream-content). ## Configuring MKPlayer for playback Install the latest version of [MKPlayer SDK](https://www.npmjs.com/package/@mediakind/mkplayer), then follow the **Getting Started** steps in the [player documentation](/mkio/reference/player-sdk) for basic playback. In step 5 of the **Getting Started** guide, you configure the source content to use. Enabling thumbnail seeking is as easy as adding thumbnailTrack object to the sourceConfig object with the associated url. ```javascript const sourceConfig = { title: "Title for your source", description: "Brief description of your source", poster: "https://my-cdn.com/mysource/poster.png", hls: "https://my-cdn.com/mysource/hls/index.m3u8", dash: "https://my-cdn.com/mysource/dash/manifest.mpd", thumbnailTrack: { url: 'https://my-cdn.com/mysource/thumbnails/f08e80da-bf1d-4e3d-8899-f0f6155f6efa.vtt' } }; ``` Once this is done, reloading the source in the player will make the thumbnails available. You can scroll over the time bar and see the thumbnails pop up like in the screenshot below: ![bad98da image](/images/mkio-vod-thumbnail-seeking.png) See the [player documentation](/mkio/reference/player-sdk) for integration details. The `thumbnailTrack` configuration is documented in [MKThumbnail](https://mkplayer.azureedge.net/%24web/websdk/latest/docs/interfaces/MKThumbnailTrack.html). # Run VOD processing jobs A VOD processing job applies a transform to one of your assets. It can transcode adaptive bitrate renditions, extract thumbnails, generate subtitles, or convert the asset format. Each job takes an input (an asset or an HTTPS URL), runs it through your selected transform, and writes the output to a new asset in your chosen storage account. ![VOD transcode job view in MK.IO](/images/mkio-run-vod-transcode.png) Job with VOD transcoding as transform ## Prerequisites - An asset with source content ready to process. See [Add an asset in MK.IO](/mkio/how-to/content-management/add-an-asset-in-mkio) or [add the source asset](/mkio/getting-started/video-on-demand-vod-workflows#add-the-source-asset). - A transform configured for the type of processing you want to run. See [Configure transformations](/mkio/how-to/video-processing-encoding/configure-transformations). ## Create a processing job ### Open Video Processing Go to **Video Processing** in the left navigation and click **Create Job**. ### Select a transform Choose the transform to apply from the dropdown. The transform determines the output, such as an adaptive bitrate encode, thumbnails, or an AI transcription. ### Name and configure the job - **Name** (required): A unique identifier for this job. - **Description** (optional): A note about what this job is doing. - **Priority**: Jobs run at **Normal** priority by default. Set it to **High** to move the job to the front of the queue. High-priority jobs do not interrupt running jobs, but are picked up next when a slot is free. Set it to **Low** for background processing that should not compete with time-sensitive work. ### Configure the input The job input can be an existing asset or an external URL: - **Asset**: Click **Select existing asset** to browse assets in your project, or enter the asset name and filename directly. You can also click **Upload asset** to create a new asset by uploading files. - **External URL**: Enter the full HTTPS or SAS URL of the source file. The URL must be publicly accessible. ### Configure the output - **Storage account**: Select where the output asset should be stored. - **Asset name**: Give the output asset a descriptive name. ### Submit the job Click **Submit**. The job enters the queue immediately.

You can duplicate an existing job from the Jobs list to reuse its settings with minor adjustments.

## Monitor job progress The job moves through these states: **queued → scheduled → processing → finished**. Track progress from the **Video Processing** page, or poll the jobs endpoint in the MK.IO API for programmatic monitoring. The progress percentage updates as each output is produced. Once the job reaches **finished**, the output asset appears on the **Assets** page. Add a streaming locator to make it available for playback. See [Publish content for streaming](/mkio/how-to/content-delivery-publishing/stream-content). Use the [Transforms and jobs API Guide](/mkio/api-guides/how-to/media/transforms-and-jobs) to submit, monitor, cancel, and delete jobs through the Media API. # Job with input clipping In some cases, you might want to apply a transform to only a specific portion of the source asset. MK.IO enables this by allowing you to set time for the input in the job configuration. Setting a time range to a job input is not exposed in the UI and must be configured using the job endpoint in [MK.IO API](/api-reference/media-api). MK.IO jobs support two types of input: `#Microsoft.Media.JobInputAsset` and `#Microsoft.Media.JobInputHttp`. Both input types can be clipped prior to applying the transform. The start and end parameters can be either relative to the content using `#Microsoft.Media.AbsoluteClipTime` or based on UTC time using `#Microsoft.Media.UtcClipTime`. For VOD content, UTC time is not applicable, in this case absolute clip time should be used instead. ## Use absolute time to transcode a portion of an asset The following job generates a new asset containing only the first 3 minutes of an input asset. ```bash curl --request PUT \ --url https://app.mk.io/api/v1/projects/project_name/media/transforms/transform_name/jobs/job_name \ --header 'accept: application/json' \ --header 'content-type: application/json' \ --header 'Authorization: Bearer bearer-token' \ --data ' { "properties": { "input": { "files": [ "my_asset.mp4" ], "assetName": "myasset", "@odata.type": "#Microsoft.Media.JobInputAsset", "start": { "@odata.type":"#Microsoft.Media.AbsoluteClipTime", "time":"PT0S" }, "end": { "@odata.type":"#Microsoft.Media.AbsoluteClipTime", "time":"PT3M" } }, "outputs": [ { "assetName": "clipped-asset", "@odata.type": "#Microsoft.Media.JobOutputAsset" } ] } } ' ``` ## Use UTC time to clip a live event The following job extracts a time range between two Coordinated Universal Time (UTC) values from a live-event asset: ```bash curl --request PUT \ --url https://app.mk.io/api/v1/projects/project_name/media/transforms/transform_name/jobs/job_name \ --header 'accept: application/json' \ --header 'content-type: application/json' \ --header 'Authorization: Bearer bearer-token' \ --data ' { "properties": { "input": { "files": [ "" ], "assetName": "live-event-output", "@odata.type": "#Microsoft.Media.JobInputAsset", "start": { "@odata.type":"#Microsoft.Media.UtcClipTime", "time":"2024-07-26T08:30:00.000Z" }, "end": { "@odata.type":"#Microsoft.Media.UtcClipTime", "time":"2024-07-26T08:40:00.000Z" } }, "outputs": [ { "assetName": "clipped-asset", "@odata.type": "#Microsoft.Media.JobOutputAsset" } ] } } ' ``` - [Reference overview](/mkio/reference/reference): Find MK.IO platform availability, regions, transform presets, resource states, and player references. - [Platform Availability](/mkio/reference/platform-availability): Review the MK.IO availability target, exclusions, and service level agreement calculation. - [Cloud Region Support](/mkio/reference/cloud-region-support): Reference the MK.IO regions available through Azure and AWS marketplace subscriptions. - [Encoding Transform Presets](/mkio/reference/encoding-transform-presets): Pages in the Encoding Transform Presets section. - [Resource States](/mkio/reference/resource-states): Reference the provisioning states reported by MK.IO resources and their operations. - [Player SDK](/mkio/reference/player-sdk): Use the MKPlayer HTML5 SDK to play HLS and DASH adaptive bitrate streams. - [Player Customization](/mkio/reference/player-customization): Build and customize MKPlayer playback interfaces with the MKCustomUI plugin. # Cloud region support Each business account on Azure or AWS can create an MK.IO account. Each account can have multiple marketplace subscriptions. Each project you create in your business acount (called **organization**) is attached to one subscription (or method of payment) and one region. Each project can have different users & admins added to it. (Learn more on [access, users and teams](/mkio/how-to/managing-your-organization/access-users-and-teams).) ## Available regions for Azure Our current [Azure Marketplace offer](https://azuremarketplace.microsoft.com/marketplace/apps/mksystemsusainc.mediakind) is available for deployment in the following Azure regions:
Region Id
West Europe westeurope
West US westus
West US 2 westus2
Central US centralus
East US eastus
UK South uksouth
France Central francecentral
Japan East japaneast
Japan West japanwest
## Available regions for AWS Our current [AWS Marketplace offer](https://aws.amazon.com/marketplace/pp/prodview-ngwosmbogkc5c) is available for deployment in the following AWS regions:
Region Id
Europe (Ireland) eu-west-1
US East (N. Virginia) us-east-1
## Future planned support If your required region is not available, contact [MK.IO support](https://support.mk.io) or email . ## Azure Marketplace offer availability Our current [Azure Marketplace offer](https://azuremarketplace.microsoft.com/marketplace/apps/mksystemsusainc.mediakind) is available in the following marketplaces:
Armenia Australia Austria Belgium Bulgaria
Canada Chile Colombia Croatia Cyprus
Czechia Denmark Estonia Finland France
Germany Greece Hungary Iceland India
Indonesia Ireland Italy Japan Kenya
Korea Latvia Liechtenstein Lithuania Luxembourg
Malaysia Malta Monaco Netherlands New Zealand
Nigeria Norway Poland Portugal Puerto Rico
Romania Saudi Arabia Serbia Singapore Slovakia
Slovenia South Africa Spain Switzerland Taiwan
Thailand Türkiye United Arab Emirates United Kingdom United States
Vietnam
- [Encoding transform](/mkio/reference/encoding-transform-presets/encoding-transform): Reference the built-in encoding presets available for MK.IO VOD transforms. - [Asset Conversion Transform](/mkio/reference/encoding-transform-presets/asset-conversion-transform): Convert live recordings or VOD assets to the MP4 formats produced by MK.IO asset conversion presets. - [Thumbnail generation transform](/mkio/reference/encoding-transform-presets/how-to-generate-thumbnails): Create Media API transforms that generate individual thumbnails, image sequences, or sprite files from VOD assets. - [Track insertion transform](/mkio/reference/encoding-transform-presets/add-a-track-to-a-vod-asset): Create a track insertion transform that adds subtitle or audio tracks to an existing VOD asset. - [Audio Speech Transcription](/mkio/reference/encoding-transform-presets/audio-speech-transcription): Create an AI transcription transform that generates WebVTT subtitles from a VOD audio track. - [Transcription and translation transforms](/mkio/reference/encoding-transform-presets/transcription-and-translation-transforms): Reference the AI pipeline presets used for VOD transcription and translation transforms. # Track insertion transform A **track insertion transform** adds a subtitle or audio track to an existing Video on Demand (VOD) asset. It also updates the asset's client and server manifests with the new track. Create track insertion transforms through the [Media API](/api-reference/media-api). The MK.IO portal does not create this transform type.

Track side-loading is only available for MP4 content.

Set the preset's `@odata.type` to `#MediaKind.TrackInserterPreset`. Each transform output can insert one text or audio track.

If clients requested the manifest shortly before insertion, caching can delay the updated manifest by a couple of minutes.

## Configuration parameters The following parameters configure the inserted track:
Parameter Description
@odata.type Use #MediaKind.TextTrack for a subtitle track or #MediaKind.AudioTrack for an audio track.
trackName The name of the track as it will appear in the manifest.
hlsSettings The HLS specific setting for the track. The attributes for this object are described in a separate table.
dashSettings The DASH settings for the track. Only available for audio tracks. The attributes for this object are described in a separate table.
languageCode The language code for the track. The value is an RFC5646 language code.
displayName The display name of the track on a video player. In HLS, this maps to the NAME attribute of EXT-X-MEDIA.
playerVisibility Set playerVisibility to Visible to include a text track in the DASH manifest or HLS playlist. Set it to Hidden to exclude the track. The default is Visible.
### HLS specific settings
Parameter Description
characteristics The characteristics of the track as they appear in the HLS playlist. For subtitles, provide a comma-separated string containing public.accessibility.transcribes-spoken-dialog, public.accessibility.describes-music-and-sound, public.easy-to-read, or public.machine-generated. For audio, provide a comma-separated string containing public.accessibility.describes-video or public.machine-generated.
default Indicates whether the HLS playlist marks this track as the default. A value of 1 adds the DEFAULT=YES attribute.
forced Indicates whether the HLS playlist marks this track as essential for playback. A value of 1 adds the FORCED=YES attribute.
### DASH settings for audio tracks
Parameter Description
role The role of the audio track in the DASH manifest. Provide a comma-separated string containing main, alternate, supplementary, commentary, dub, or emergency.
## Transform example The following transform shows how to use these parameters. Once the transform is in place, it can be used to [create a job on a given VOD asset](/mkio/how-to/video-processing-encoding/run-vod-transcode-jobs). ## Add a subtitle track to a VOD asset The following transform adds an English VTT subtitle track for viewers who are deaf or hard of hearing. ```bash curl --request PUT \ --url https://app.mk.io/api/v1/projects/project_name/media/transforms/transform_name \ --header 'accept: application/json' \ --header 'content-type: application/json' \ --header 'Authorization: Bearer bearer-token' \ --data ' { "properties": { "outputs": [ { "preset": { "@odata.type": "#MediaKind.TrackInserterPreset", "tracks": [ { "@odata.type": "#MediaKind.TextTrack", "trackName": "subtitle_en_US", "displayName": "eng (hearing-impaired)", "hlsSettings": { "characteristics": "public.accessibility.describes-music-and-sound" }, "languageCode": "en-US" } ] } } ] } } ' ``` ## Add an audio track to a VOD asset The following transform adds a secondary audio track to VOD content. ```bash curl --request PUT \ --url https://app.mk.io/api/v1/projects/project_name/media/transforms/transform_name \ --header 'accept: application/json' \ --header 'content-type: application/json' \ --header 'Authorization: Bearer bearer-token' \ --data ' { "properties": { "outputs": [ { "preset": { "@odata.type": "#MediaKind.TrackInserterPreset", "tracks": [ { "@odata.type": "#MediaKind.AudioTrack", "trackName": "ai-generated-fr-audio", "displayName": "fra", "languageCode": "fr-FR", "hlsSettings": { "characteristics": "public.machine-generated" }, "dashSettings": { "role": "dub" } } ] } } ] } } ' ``` # Asset conversion transform A reusable **asset conversion transform** converts a live-event recording or Video on Demand (VOD) asset to an MP4 asset. The selected preset determines the files MK.IO creates. Use asset conversion for legacy Azure Media Services (AMS) events or older Smooth Streaming assets that need the MP4v4 format. After conversion, the asset can use features such as thumbnails, subtitle side-loading, Artificial Intelligence (AI) transcription and translation, and VOD dubbing. MK.IO provides three built-in presets: - **CopyTopBitrateInterleaved:** Generates a single MP4 file using the top-bitrate video rendition with all audio interleaved. Use this for download-only scenarios. This file requires a `Predefined_DownloadOnly` or `Predefined_DownloadAndClearStreaming` streaming policy. - **CopyAllBitratesNonInterleaved:** Copies all video and audio streams as separate output files. Use this when your source video rendition files contain video only, with no audio interleaved. Output includes: - MP4 files (`.mp4`), one per video or audio rendition. - A server manifest (`.ism`) used as the access point for streaming endpoints. - A client manifest (`.mpd`). - Index files (`.mpi`), one per rendition. - **CopyAllBitratesInterleaved:** Copies all video streams as separate files with all audio interleaved in each. Use this when your source asset has audio bundled within each video rendition. This is the most common structure for HTTP Smooth Streaming (HSS) assets from AMS. Output includes: - MP4 files (`.mp4`), one per video rendition with all audio interleaved. - A server manifest (`.ism`) used as the access point for streaming endpoints. - A client manifest (`.mpd`). - Index files (`.mpi`), one per rendition.

For VOD dubbing: Use CopyAllBitratesInterleaved when converting legacy HSS assets for use with VOD dubbing. This is the most common choice for AMS-sourced assets. See the Convert HSS assets for VOD dubbing guide for step-by-step instructions.

When you run an asset conversion job, select the source asset. MK.IO identifies its source files automatically. ## Use an asset conversion transform Create a transform with one of the built-in asset conversion presets, then run a job against the live recording or VOD asset you want to convert. - [Configure transforms](/mkio/how-to/video-processing-encoding/configure-transformations) explains how transforms define a reusable processing operation. - [Run VOD jobs](/mkio/how-to/video-processing-encoding/run-vod-transcode-jobs) explains how to apply a transform to an input asset and write the result to an output asset. # Transcription transform MK.IO offers an AI-powered VOD transcription feature that allows you to generate subtitles from audio tracks. The generated subtitles are delivered in WebVTT format into the output asset and can be subsequently added to the manifest of the asset with a [track insertion transform.](/mkio/reference/encoding-transform-presets/add-a-track-to-a-vod-asset)

On-demand transcription is only available for MP4 assets.

MK.IO provides the built-in **Predefined\_ACSVodTranscription** preset for this workflow. When selecting the preset, specify the original language of the audio track using a BCP-47 locale. ## Source language MK.IO uses Azure AI Speech for transcription. Azure maintains the current [language and voice support table](https://learn.microsoft.com/en-us/azure/ai-services/speech-service/language-support) for speech-to-text locales. Confirm that the locale required by your workflow is available before creating the transform. # Encoding transform An **encoding transform** defines how MK.IO processes an input asset into one or more MP4 renditions. Select a built-in preset based on the required codec, resolution, bitrate ladder, and encoding tier. ## Built-in presets MK.IO supports the following built-in presets:
Built-in preset name Video Audio
AACGoodQualityAudio (Foundations) n/a 192 kbps
H264SingleBitrateSD (Foundations) 848x480 @ 30fps / 2200kbps 128 kbps
H264MultipleBitrateSD (Foundations) H264MultipleBitrateSDWithCVQ (Advanced) 432x240 @ 30fps / 400kbps 640x360 @ 30fps / 650kbps 848x480 @ 30fps / 900kbps 848x480 @ 30fps / 1300kbps 848x480 @ 30fps / 1900kbps 128 kbps
H264SingleBitrate720p (Foundations) 1280x720 @ 30fps / 4500kbps 128 kbps
H264MultipleBitrate720p (Foundations) H264MultipleBitrate720pWithCVQ (Advanced) 320x180 @ 30fps / 400kbps 640x360 @ 30fps / 600kbps 640x360 @ 30fps / 1000kbps 960x540 @ 30fps / 1500kbps 960x540 @ 30fps / 2250kbps 1280x720 @ 30fps / 3400kbps 128 kbps
H264SingleBitrate1080p (Foundations) 1920x1080 @ 30fps / 6750kbps 128 kbps
H264MultipleBitrate1080p (Foundations) H264MultipleBitrate1080pWithCVQ (Advanced) 320x180 @ 30fps / 400kbps 640x360 @ 30fps / 600kbps 640x360 @ 30fps / 1000kbps 960x540 @ 30fps / 1500kbps 960x540 @ 30fps / 2250kbps 1280x720 @ 30fps / 3400kbps 1920x1080 @ 30fps / 4700kbps 1920x1080 @ 30fps / 6000kbps 128 kbps
H265SingleBitrate720p (Advanced) 1280x720 @ 30fps / 1800kbps 128 kbps
H265SingleBitrate1080p (Advanced) 1920x1080 @ 30fps / 3500kbps 128 kbps
H265SingleBitrate4K (Advanced) 3840x2160 @ 30fps / 9500kbps 128 kbps

Audio streams are encoded in stereo with HE-AAC audio codec.

If you require a different encoding ladder, contact MK.IO support.

## Constant video quality presets The presets with `CVQ` in their name use Constant Video Quality (CVQ). These presets adjust the bitrate and encoding parameters to maintain consistent visual quality across the input content. Use a standard preset for content shorter than 30 seconds. For content longer than 60 seconds, the CVQ presets can reduce the output bitrate by 15 to 30 percent without a perceptible change in visual quality. Older Windows CE and Roku clients may not be compatible with CVQ output. CVQ presets use the Advanced encoding tier. See [MK.IO pricing](https://mediakind.com/mkio/pricing/) for current rates. ## Input file formats
File formats (file extensions) Supported
MP4 (.mp4, .m4a, .m4v) Yes
MPEG2-PS, MPEG2-TS (.ts, .ps, .mpg) Yes
Matroska MKV (.mkv) Yes
QuickTime (.mov) Yes
MXF (.mxf) Yes
Flash Video FLV (.flv) Yes
3GP (.3gp, .3gpp) Yes
Matroska WebM (.webm) Yes
ISMV (.ismv, .isma) Yes
AVI (Uncompressed 8bit/10bit) (.avi) Yes
Windows Media Format (WMV) (.wmv) Yes
## Output file format MK.IO uses the MP4 format for Video on Demand (VOD) assets. An asset generated through VOD transcoding contains the following files: - MP4 files (`.mp4`), one per video rendition with all audio streams interleaved. - A server manifest (`.ism`) used as the access point for streaming endpoints. - A client manifest (`.mpd`). - Index files (`.mpi`), one per rendition, used to improve streaming-delivery performance. VOD transcoding uses the input filename as the prefix for all output files in the asset. Existing assets that use the earlier Smooth Streaming or MP4 layout remain deliverable through MK.IO streaming endpoints. Use an [asset conversion transform](/mkio/reference/encoding-transform-presets/asset-conversion-transform) when a newer workflow requires the current MP4v4 layout. ## Input video codecs
File formats (file extensions) Supported
H264/AVC, including AVCIntra Main and High Profiles, 8-bit/10-bit Up to 4:2:2
HEVC/H.265 Main Profile, 8-bit/10-bit Up to 4:2:2
MPEG-2 Main and High Profiles Up to 4:2:2
Sony XAVC / XAVC S Yes
DVCPro SD and HD Yes
Digital video DV and HDV Yes
JPEG 2000 Yes
Apple ProRes 422, including LT and HQ Yes
Apple ProRes 4444, including XQ Yes
Sony XAVC Yes
Sony XDCAM IMX Yes
Sony XDCAM, including HD and EX Yes
Dolby Vision 5 and 8.1 Yes
V210 Video Picture Encoding Yes
MPEG-1 Yes
VC-1 Yes
VP8 Yes
VP9 Yes
MJPEG Yes
AV1 Yes
Microsoft MPEG4v1, v2 and v3 Yes
H263 Yes
Avid DNxHD and DNxHR Yes
Sorenson Spark Yes
## Input audio codecs
File formats (file extensions) Supported
AAC, including AAC-LC, HE-AAC, and HE-AACv2 Up to 5.1
MPEG Layer 2 Yes
MP3 (MPEG-1 Audio Layer 3) Yes
PCM, LPCM, DPCM and ADPCM Yes
AES (SMPTE 331M and 302M, AES3-2003) Yes
Dolby E Passthrough only
Dolby Digital (AC3) Yes
Dolby Digital Plus (E-AC3) Yes, including Dolby Atmos in passthrough
DTS Yes
Opus Yes
Vorbis Yes
Apple Lossless Audio Code (ALAC) Yes
# Thumbnail generation transform Extract one or more images from a Video on Demand (VOD) asset for posters, previews, or seek thumbnails. Create the transform through the Media API, then run it against the source asset.

Thumbnail generation is only available for MP4 content and requires a server manifest (.ism) as the job input.

The portal does not create thumbnail generation transforms. Create the transform through the Media API, then select it when you run the processing job. If the source asset uses Smooth Streaming format, convert it first with an [asset conversion transform](/mkio/reference/encoding-transform-presets/asset-conversion-transform). You can extract a single image, an image sequence, or a sprite image. The thumbnail preset must use `#MediaKind.ThumbnailGeneratorPreset` for the `@odata.type` attribute. ## Default thumbnail A standard VOD transcoding job generates one JPEG thumbnail at 50 percent of the size of the highest-resolution video rendition. Create a thumbnail generation transform when you need another position, size, format, image sequence, or sprite. ## Configuration parameters The following parameters configure thumbnail generation:
Parameter Description
format The output file format for the thumbnail. Can be either Png or Jpeg. Only Jpeg can be used to produce sprite files.
width The width of the output video for this layer. The value can be absolute (in pixels) or relative (in percentage). For example 50% means the output video has half as many pixels in width as the input. If only width is given and value is in pixels, the height will be calculated to preserve aspect ratio. If either width/height is defined as percentage, the other dimension must be the same percentage.
height The height of the output video for this layer. The value can be absolute (in pixels) or relative (in percentage). For example 50% means the output video has half as many pixels in height as the input. If only height is given and value is in pixels, the width will be calculated to preserve aspect ratio. If either width/height is defined as percentage, the other dimension must be the same percentage.
start The position in the input video from where to start generating thumbnails. The value can be in ISO8601 format with second-level precision (For example, PT05S to start at 5 seconds) or a relative value to asset duration (For example, 10% to start at 10% of stream duration). The default value is 0, which means to start at the beginning of the asset.
range The position relative to start time in the input video at which to stop generating thumbnails. The value can be in ISO8601 format with second-level precision (For example, PT5M30S to stop at 5 minutes and 30 seconds from start time) or a relative value to the asset duration (For example, 50% to stop at half of stream duration from start time). The default value is 100%, which means to stop at the end of the asset. If this value is 1, only a single thumbnail will be generated at the start time.
step The interval at which thumbnails are generated. The value can be in ISO8601 format with second-level precision (For example, PT05S for one image every 5 seconds) or a relative value to asset duration (For example, 10% for one image every 10% of stream duration). If step is not specified or if range is set to 1, a single thumbnail will be generated.
label Used to create the output filename as {BaseFilename}_{Label}{Index}{Extension}. When generating sprites, the output VTT file will be named {BaseFilename}_{Label}.vtt
quality The compression quality of the JPEG images between 0 and 100. Default value is 70.
spriteColumn Multiple thumbnails can be aggregated in a sprite image.
## Transform examples The following transforms show how to use these parameters. Once the transform is in place, it can be used to [create a job on a given VOD asset](/mkio/how-to/video-processing-encoding/run-vod-transcode-jobs). ## Transform to generate a single thumbnail The following transform generates a single PNG image 10 seconds after the content starts. The image is half the size of the highest-resolution input rendition. ```bash curl --request PUT \ --url https://app.mk.io/api/v1/projects/project_name/media/transforms/transform_name \ --header 'accept: application/json' \ --header 'content-type: application/json' \ --header 'Authorization: Bearer bearer-token' \ --data ' { "properties": { "outputs": [ { "preset": { "@odata.type": "#MediaKind.ThumbnailGeneratorPreset", "thumbnails": [ { "format": "Png", "start": "PT10S", "width": "50%", "height": "50%" } ] } } ] } } ' ``` ## Transform to generate multiple thumbnails The transform below generates one JPEG image every 30 seconds during 80 percent of the input content. The width determines the image size, and MK.IO calculates the height to preserve the aspect ratio. ```bash curl --request PUT \ --url https://app.mk.io/api/v1/projects/project_name/media/transforms/transform_name \ --header 'accept: application/json' \ --header 'content-type: application/json' \ --header 'Authorization: Bearer bearer-token' \ --data ' { "properties": { "outputs": [ { "preset": { "@odata.type": "#MediaKind.ThumbnailGeneratorPreset", "thumbnails": [ { "format": "Jpeg", "start": "10%", "range": "90%", "step": "PT30S", "width": "480", "quality": 70 } ] } } ] } } ' ``` When a transform generates multiple thumbnails, MK.IO also creates a Web Video Text Tracks (WebVTT) file containing their timing. ## Transform to generate a sprite file MK.IO can generate a sprite file and its associated WebVTT file. The transform below generates one JPEG image for every 1 percent of the content and organizes the images in a 10 by 10 sprite file. ```bash curl --request PUT \ --url https://app.mk.io/api/v1/projects/project_name/media/transforms/transform_name \ --header 'accept: application/json' \ --header 'content-type: application/json' \ --header 'Authorization: Bearer bearer-token' \ --data ' { "properties": { "outputs": [ { "preset": { "@odata.type": "#MediaKind.ThumbnailGeneratorPreset", "thumbnails": [ { "format": "Jpeg", "start": "PT0S", "range": "100%", "step": "1%", "width": "10%", "height": "10%", "spriteColumn": 10 } ] } } ] } } ' ``` Players can use sprite files for seek previews. See [Play a VOD asset with thumbnail seeking](/mkio/how-to/video-processing-encoding/playout-of-a-vod-asset-with-thumbnail-seeking). ## Combined generation of thumbnail and sprite files One transform can contain multiple thumbnail configurations. The transform below generates one JPEG image for every 1 percent of the content and organizes the images in a 10 by 10 sprite file. It also generates one PNG thumbnail at a fixed size of 1920 by 960 pixels. ```bash curl --request PUT \ --url https://app.mk.io/api/v1/projects/project_name/media/transforms/transform_name \ --header 'accept: application/json' \ --header 'content-type: application/json' \ --header 'Authorization: Bearer bearer-token' \ --data ' { "properties": { "outputs": [ { "preset": { "@odata.type": "#MediaKind.ThumbnailGeneratorPreset", "thumbnails": [ { "format": "Jpeg", "start": "PT0S", "range": "100%", "step": "1%", "width": "10%", "height": "10%", "spriteColumn": 10, "quality": 90, "label": "Sprite" }, { "format": "Png", "start": "PT01S", "width": "1920", "height": "960", "label": "Thumbnail" } ] } } ] } } ' ``` ## Download generated files Create a streaming locator on the output asset with the `Predefined_DownloadOnly` streaming policy to retrieve download URLs for generated thumbnails and sprite files. See [Streaming locators](/mkio/understanding/core-concepts/locators) for locator and download policy details. # Transcription and translation transforms MK.IO offers AI-powered VOD transcription and VOD translation features that allow you to generate subtitles from audio tracks. The generated subtitles are delivered in WebVTT format into an output asset and can be subsequently added to the manifest of the asset with a [track insertion transform](/mkio/reference/encoding-transform-presets/add-a-track-to-a-vod-asset).

On-demand transcription and translation are only available for MP4 assets.

## VOD transcription MK.IO provides a built-in preset, **Predefined\_ACSVodTranscription,** to be used in such AI workflow transform for VOD Transcription. When selecting this VOD transcription preset, all you need to do is specify the original language of the audio track using the BCP-47 format. It is also possible to provide a list of words or phrases that are expected in the audio feed in order to improve their recognition. A full list of supported languages is available below: ## Supported languages The table below summarizes the locales available in the AI model for transcription.
Language Locale (BCP-47)
Afrikaans (South Africa) af-ZA
Amharic (Ethiopia) am-ET
Arabic (United Arab Emirates) ar-AE
Arabic (Bahrain) ar-BH
Arabic (Algeria) ar-DZ
Arabic (Egypt) ar-EG
Arabic (Israel) ar-IL
Arabic (Iraq) ar-IQ
Arabic (Jordan) ar-JO
Arabic (Kuwait) ar-KW
Arabic (Lebanon) ar-LB
Arabic (Libya) ar-LY
Arabic (Morocco) ar-MA
Arabic (Oman) ar-OM
Arabic (Palestinian Authority) ar-PS
Arabic (Qatar) ar-QA
Arabic (Saudi Arabia) ar-SA
Arabic (Syria) ar-SY
Arabic (Tunisia) ar-TN
Arabic (Yemen) ar-YE
Azerbaijani (Latin, Azerbaijan) az-AZ
Bulgarian (Bulgaria) bg-BG
Bengali (India) bn-IN
Bosnian (Bosnia and Herzegovina) bs-BA
Catalan ca-ES
Czech (Czechia) cs-CZ
Welsh (United Kingdom) cy-GB
Danish (Denmark) da-DK
German (Austria) de-AT
German (Switzerland) de-CH
German (Germany) de-DE
Greek (Greece) el-GR
English (Australia) en-AU
English (Canada) en-CA
English (United Kingdom) en-GB
English (Ghana) en-GH
English (Hong Kong SAR) en-HK
English (Ireland) en-IE
English (India) en-IN
English (Kenya) en-KE
English (Nigeria) en-NG
English (New Zealand) en-NZ
English (Philippines) en-PH
English (Singapore) en-SG
English (Tanzania) en-TZ
English (United States) en-US
English (South Africa) en-ZA
Spanish (Argentina) es-AR
Spanish (Bolivia) es-BO
Spanish (Chile) es-CL
Spanish (Colombia) es-CO
Spanish (Costa Rica) es-CR
Spanish (Cuba) es-CU
Spanish (Dominican Republic) es-DO
Spanish (Ecuador) es-EC
Spanish (Spain) es-ES
Spanish (Equatorial Guinea) es-GQ
Spanish (Guatemala) es-GT
Spanish (Honduras) es-HN
Spanish (Mexico) es-MX
Spanish (Nicaragua) es-NI
Spanish (Panama) es-PA
Spanish (Peru) es-PE
Spanish (Puerto Rico) es-PR
Spanish (Paraguay) es-PY
Spanish (El Salvador) es-SV
Spanish (United States)* es-US
Spanish (Uruguay) es-UY
Spanish (Venezuela) es-VE
Estonian (Estonia) et-EE
Basque eu-ES
Persian (Iran) fa-IR
Finnish (Finland) fi-FI
Filipino (Philippines) fil-PH
French (Belgium) fr-BE
French (Canada)* fr-CA
French (Switzerland) fr-CH
French (France) fr-FR
Irish (Ireland) ga-IE
Galician gl-ES
Gujarati (India) gu-IN
Hebrew (Israel) he-IL
Hindi (India) hi-IN
Croatian (Croatia) hr-HR
Hungarian (Hungary) hu-HU
Armenian (Armenia) hy-AM
Indonesian (Indonesia) id-ID
Icelandic (Iceland) is-IS
Italian (Switzerland) it-CH
Italian (Italy) it-IT
Japanese (Japan) ja-JP
Javanese (Latin, Indonesia) jv-ID
Georgian (Georgia) ka-GE
Kazakh (Kazakhstan) kk-KZ
Khmer (Cambodia) km-KH
Kannada (India) kn-IN
Korean (Korea) ko-KR
Lao (Laos) lo-LA
Lithuanian (Lithuania) lt-LT
Latvian (Latvia) lv-LV
Macedonian (North Macedonia) mk-MK
Malayalam (India) ml-IN
Mongolian (Mongolia) mn-MN
Marathi (India) mr-IN
Malay (Malaysia) ms-MY
Maltese (Malta) mt-MT
Burmese (Myanmar) my-MM
Norwegian Bokmål (Norway) nb-NO
Nepali (Nepal) ne-NP
Dutch (Belgium) nl-BE
Dutch (Netherlands) nl-NL
Punjabi (India) pa-IN
Polish (Poland) pl-PL
Pashto (Afghanistan) ps-AF
Portuguese (Brazil) pt-BR
Portuguese (Portugal) pt-PT
Romanian (Romania) ro-RO
Russian (Russia) ru-RU
Sinhala (Sri Lanka) si-LK
Slovak (Slovakia) sk-SK
Slovenian (Slovenia) sl-SI
Somali (Somalia) so-SO
Albanian (Albania) sq-AL
Serbian (Cyrillic, Serbia) sr-RS
Swedish (Sweden) sv-SE
Kiswahili (Kenya) sw-KE
Kiswahili (Tanzania) sw-TZ
Tamil (India) ta-IN
Telugu (India) te-IN
Thai (Thailand) th-TH
Turkish (Türkiye) tr-TR
Ukrainian (Ukraine) uk-UA
Urdu (India) ur-IN
Uzbek (Latin, Uzbekistan) uz-UZ
Vietnamese (Vietnam) vi-VN
Chinese (Wu, Simplified) wuu-CN
Chinese (Cantonese, Simplified) yue-CN
Chinese (Mandarin, Simplified) zh-CN
Chinese (Jilu Mandarin, Simplified) zh-CN-shandong
Chinese (Southwestern Mandarin, Simplified) zh-CN-sichuan
Chinese (Cantonese, Traditional) zh-HK
Chinese (Taiwanese Mandarin, Traditional) zh-TW
isiZulu (South Africa) zu-ZA
> **Note:** The model is bilingual and also supports English. ## VOD translation MK.IO also provides a built-in preset, **Predefined\_ACSVodTranslation,** to be used in such AI workflow transform for VOD translation. When selecting this VOD translation preset, you need to specify the original language of the audio track using the BCP-47 format. You also need to specify a list of languages to which you want the subtitles to be translated. It is also possible to provide a list of words or phrases that are expected in the audio feed in order to improve their recognition. # MK.IO application availability We understand the pivotal role that our video streaming Software as a Service (SaaS) plays in your operations. We are committed to ensuring high levels of availability and uptime, delivering a consistent, reliable experience for all our users. ## Service availability Service availability is a measure of the time our service is operational and accessible by our users. We strive to maintain an industry-leading level of service availability, which is why we use the best in cloud-native techniques to build in fault tolerance, ensuring your content is available when you need it. ## Control plane/API availability The control plane, or API, serves as the foundation for our service, allowing users to manage their accounts, set up streams, and perform other administrative functions. We take extra measures to ensure the high availability of our control plane to prevent any disruption to your ability to manage and control your streaming services. ## Video streaming availability Video streaming availability refers to the uptime and accessibility of your video streams. It is critical to us that your content is always available to your viewers whenever they choose to access it. ## Monitoring and reporting We use sophisticated monitoring tools to continuously oversee the performance and availability of both our control plane/API and our video streaming service. If a disruption occurs, our dedicated incident response team is immediately alerted to investigate and resolve the issue as swiftly as possible. ## Unplanned downtime While we endeavour to maintain the highest levels of service availability and uptime, unforeseen issues can occur. In such instances, our top priority is to address and resolve the issues as swiftly and effectively as possible, minimizing any disruption to your services. SLA document can be accessed via this link: [Platform availability and SLA](https://mediakind.com/mkio-service-level-agreement) # MKPlayer customization The `@mediakind/mkplayer-customui-plugin` lets you build and customize playback interfaces on top of Bitmovin Player UI V3. Previously, MKPlayer supported a basic `ui: true | false` flag to show or hide the default playback UI. The MKCustomUI plugin extends this by enabling full layout, control, behavior, and styling customization. ## What you can do - Build MKPlayer's default-style UI - Create fully custom playback UIs - Configure UI behavior through `uiConfig` - Use responsive UI variants for mobile and browser layouts - Style playback controls using CSS class overrides - Apply UI updates dynamically at runtime based on screen size, app state, and user context ## In this section [Install and initialize](/mkio/reference/player-customization/installation-and-initialization) Install the plugin, disable the default UI, and initialize MKPlayer and MKCustomUI. [UI configuration and variants](/mkio/reference/player-customization/ui-configuration-and-variants) Configure `uiConfig`, build responsive layouts, and use lifecycle events. [MKCustomUI API](/mkio/reference/player-customization/mkcustomui-api) Reference list of constructors and UI factory methods. [CSS customization](/mkio/reference/player-customization/css-customization) Apply CSS overrides for seekbars, typography, and branded visual styling. ## External references - NPM package: [@mediakind/mkplayer-customui-plugin](https://www.npmjs.com/package/@mediakind/mkplayer-customui-plugin) - API docs: [MKCustomUI API reference](https://mkplayer.azureedge.net/$web/websdk/plugins/customui/latest/docs/index.html) - Sample code: [MKPlayerSamples custom UI example](https://github.com/mediakind-video/MKPlayerSamples/blob/main/Web/index_customUI.html) # CSS customization Bitmovin UI renders playback controls and overlays as DOM elements with predefined CSS class names (for example, `.bmpui-seekbar` and `.bmpui-ui-uicontainer`). Using CSS overrides lets you: - Customize colors, fonts, and sizes - Align playback controls with your brand - Improve accessibility and responsive behavior - Change visual behavior at runtime ## Example: larger seekbar and branded colors ```css /* Big seekbar font size */ .bmpui-seekbar.bigseek > * { font-size: 3em; } /* Seekbar backdrop colors */ .bmpui-seekbar-backdrop.green { background-color: #034728 !important; } ``` This makes seekbar elements larger and changes the seekbar backdrop color. ## Example: base font defaults ```css .bmpui-ui-uicontainer { font-family: "Roboto"; font-size: 16px; } ``` This sets a consistent font baseline across UI elements. You can also update label and button text styling to signal UI states such as on/off transitions. ## Related references - UIConfig: [Bitmovin UIConfig interface](https://cdn.bitmovin.com/player/ui/3/docs/interfaces/UIConfig.html) - Bitmovin UI modules: [Bitmovin UI modules](https://cdn.bitmovin.com/player/ui/3/docs/modules.html) - UI factory variants: [Bitmovin UI factory docs](https://cdn.bitmovin.com/player/ui/3/docs/modules/UIFactory.html) - CSS class reference: [Bitmovin CSS class reference](https://developer.bitmovin.com/playback/docs/player-ui-css-class-reference#labels) # Install and initialize MKCustomUI Use the MKCustomUI plugin to replace the default MKPlayer playback UI with a customizable UI built on Bitmovin Player UI V3. ## 1. Install the plugin Install the package in your project: ```bash npm install @mediakind/mkplayer-customui-plugin ``` ## 2. Import the plugin Import `MKCustomUI` from the plugin in your source code. ## 3. Disable the default player UI Set `playerConfig.ui` to `false` when using MKCustomUI: ```js const playerConfig = { ...otherConfigs, ui: false, // disable default Bitmovin UI }; ``` ## 4. Initialize MKPlayer Create the player instance with your video container and config: ```js const player = new mkplayer.MKPlayer(videoContainer, playerConfig); ``` ## 5. Initialize MKCustomUI Create `MKCustomUI` with the initialized player instance: ```js const mkCustomizeUI = new mkplayercustomuiPlugin.MKCustomUI(player); ``` ## 6. Release an existing UI manager before rebuilding If you rebuild or switch UI layouts dynamically, release the previous `uiManager` first: ```js if (uiManager) { uiManager.release(); uiManager = undefined; } ``` This avoids duplicate controls and prevents memory leaks when switching UI variants. # MKCustomUI API Use the `MKCustomUI` class and method reference when configuring or controlling a custom MKPlayer user interface. ## Constructor - `new MKCustomUI(player)`: creates a UI builder using the MKPlayer instance and its internal Bitmovin engine. ## Default UI variants (classic style, return `UIManager`) - `buildDefaultUI(config?)`: Builds the standard defauly UI for browser use. - `buildDefaultSmallScreenUI(config?)`: Builds the default UI optimized for mobile and small screens. - `buildDefaultTvUI(config?)`: Builds the default UI tailored for TV devices. - `buildDefaultCastReceiverUI(config?)`: Builds the default UI for Chromecast receiver. ## Modern UI variants (return `UIManager`) - `buildModernUI(config?)`: Builds the modern UI layout for general use. - `buildModernSmallScreenUI(config?)`: Builds the modern UI layout for mobile and small screens. - `buildModernTvUI(config?)`: Builds the modern UI layout for TV devices. - `buildModernCastReceiverUI(config?)`: Builds the modern UI layout for Chromecast receiver. ## Fully custom UI (advanced, return `UIManager`) - `customUi(uiContainer, config?)`: Attach a fully custom `UIContainer`. - `customUiVariant(uiVariants, config?)`: Configure multiple responsive UI variants and switch by condition. ## UI container factory methods (no `UIManager` attachment) - `modernUI(config)`: Creates a general modern UI container without attaching it to the player. - `modernSmallScreenUI()`: Creates a modern UI container optimized for small screens. - `modernCastReceiverUI()`: Creates a modern UI container structure for cast receivers. ## Ads-only UI container methods - `modernAdsUI()`: Creates a modern ads-only UI container. - `modernSmallScreenAdsUI()`: Creates a modern ads-only UI container optimized for small screens. - `modernTvAdsUI()`: Creates a modern ads-only UI container tailored for TV devices. ## TV UI with spatial navigation (container only) - `modernTvUI()`: Creates a modern TV UI container with spatial navigation support. # UI configuration and variants `uiConfig` controls global playback UI behavior and can be shared across custom and responsive UI variants. ## uiConfig example ```js const uiConfig = { disableAutoHideWhenHovered: false, container: HTMLElement, disableStorageApi: false, autoUiVariantResolve: false, playbackSpeedSelectionEnabled: true, metadata: { markers: [ { time: 24, title: "Marker1" }, { time: 69, title: "Marker2" }, ], }, }; ``` Key fields from the source guide: - `disableAutoHideWhenHovered`: keeps the control bar visible while the cursor is over the player. - `playbackSpeedSelectionEnabled`: enables playback speed controls in settings. - `metadata.markers`: adds visual seekbar markers at specific timestamps. ## Build a custom browser UI with `customUi`

customUi with basic controls

```js const simpleUI = new mkplayercustomuiPlugin.MKCustomizeUI.UIContainer({ components: [ new mkplayercustomuiPlugin.MKCustomizeUI.SubtitleOverlay(), settingsPanel, // Contains selection controls on the settings panel new mkplayercustomuiPlugin.MKCustomizeUI.BufferingOverlay(), new mkplayercustomuiPlugin.MKCustomizeUI.ReplayButton(), new mkplayercustomuiPlugin.MKCustomizeUI.PlaybackToggleButton(), new mkplayercustomuiPlugin.MKCustomizeUI.QuickSeekButton({ seekSeconds: -10 }), new mkplayercustomuiPlugin.MKCustomizeUI.QuickSeekButton({ seekSeconds: 10 }), new mkplayercustomuiPlugin.MKCustomizeUI.VolumeToggleButton(), ], }); uiManager = mkCustomizeUI.customUi(simpleUI, uiConfig); ``` This pattern creates a custom UI container and attaches it through `customUi`. The source guide's browser custom UI example includes: - Subtitles and overlays (subtitle display, buffering indicator, play/pause overlay, error messages) - Settings panel options for video quality, audio quality, audio track, playback speed, and subtitles - Control bar items such as replay, play/pause, skip `-10s/+10s`, volume, PiP, fullscreen, and settings - Title bar metadata display ## Build responsive UIs with `customUiVariant`

responsive UI

```js const isSmallScreen = (context) => { return context.documentWidth < 800; }; function createMobileUIContainer() { return mkCustomizeUI.modernSmallScreenUI(); } const simpleUI = createBrowserUIContainer(); uiManager = mkCustomizeUI.customUiVariant( [ { ui: createMobileUIContainer(), condition: isSmallScreen, }, { ui: simpleUI, }, ], uiConfig ); ``` Behavior: - Mobile variant is selected when `isSmallScreen` returns `true`. - Desktop/browser UI is used as fallback when no condition matches. - A shared `uiConfig` applies across all variants. ## Lifecycle events Use lifecycle hooks to observe when variants resolve and become active: ```js uiManager.onActiveUiChanged.subscribe(() => { console.log("[customUi] UI is ready, attaching onUiVariantResolve"); }); uiManager.onUiVariantResolve.subscribe((context) => { console.log("[customUi] onUiVariantResolve fired:", context); }); ``` - `onActiveUiChanged`: triggered when the active UI is fully attached. - `onUiVariantResolve`: triggered when the variant-selection logic runs. ## UI factory variant shortcuts The guide also includes built-in factory-based options: ```js uiManager = mkCustomizeUI.buildDefaultUI(uiConfig); uiManager = mkCustomizeUI.buildDefaultSmallScreenUI(uiConfig); uiManager = mkCustomizeUI.buildModernTvUI(uiConfig); ``` - `buildDefaultUI`: default responsive UI that adapts between browser and mobile dimensions:

default UI

- `buildDefaultSmallScreenUI`: default small-screen style UI layout:

default small screen UI

- `buildModernTvUI`: modern TV playback UI layout:

default TV UI

# MKPlayer SDK MKPlayer is an HTML5 video player SDK used for playing back HLS and DASH adaptive bitrate streams without using browser plugins. ![7302df2 mkplayer sdk](/images/mkio-player-sdk.png) ## MKPlayer SDK This comprehensive guide to the MKPlayer SDK will help you navigate the features and functionalities of our powerful streaming video player. MediaKind created this guide for developers and MK.IO users to help you make the most of the MKPlayer for importing assets from your cloud storage and/or integrating our player into your application. You can find our NPM library at . Start with [Install and initialize MKPlayer](/mkio/reference/player-sdk/setup). # DRM protection MKPlayer supports Widevine, PlayReady, and FairPlay DRM. You configure DRM by adding a `drm` property to your `MKSourceConfig` before calling `player.load()`. The player selects the first key system supported by the current platform. To support playback across browsers and devices, it is recommended to provide both a Widevine and a PlayReady configuration. FairPlay applies only to HLS sources on Apple devices. ## Prerequisites You have an initialised `MKPlayer` instance and a loaded source. See [Installation and setup](/mkio/reference/player-sdk/setup) and [Loading and playing content](/mkio/reference/player-sdk/playback). ## Configure DRM Add a `drm` object to your source configuration. Each key system is optional: include only the ones your licence server supports: ```javascript const sourceConfig = { title: "Protected Stream", hls: "https://my-cdn.com/mysource/hls/index.m3u8", dash: "https://my-cdn.com/mysource/dash/manifest.mpd", drm: { widevine: { LA_URL: "https://your-widevine-license-server/license", headers: { "X-CustomHeader": "custom-value" } }, playready: { LA_URL: "https://your-playready-license-server/license", headers: { "X-CustomHeader": "custom-value" } }, fairplay: { LA_URL: "https://your-fairplay-license-server/license", certificateURL: "https://your-fairplay-certificate-url", headers: { "X-CustomHeader": "custom-value" } } } }; player.load(sourceConfig); ``` ## Widevine and PlayReady options Both `widevine` and `playready` accept the same core properties:
Property Type Description
LA_URL string URL of the DRM licence server.
headers MKHeaders Custom HTTP headers sent with licence requests.
### PlayReady on smart TVs Most smart TV platforms require `plaintextChallenge` and `utf8message` to be set for PlayReady licence requests to succeed: ```javascript playready: { LA_URL: "https://your-playready-license-server/license", utf8message: true, plaintextChallenge: true, headers: { "Content-Type": "text/xml" } } ``` ## FairPlay options FairPlay requires a `certificateURL` in addition to the licence server URL. It applies only to HLS sources on Apple devices.
Property Type Description
LA_URL string URL of the FairPlay licence server.
certificateURL string URL to the FairPlay certificate. Required.
headers MKHeaders Custom HTTP headers for licence requests.
certificateHeaders MKHeaders Custom HTTP headers for the certificate request.
prepareContentId function Callback to transform the content ID extracted from the HLS manifest before it is sent to the licence server.
prepareMessage function Callback to prepare the licence acquisition message before it is sent.
prepareLicense function Callback to transform the licence response before it is passed to the browser.
prepareCertificate function Callback to transform the certificate response before it is passed to the browser.
withCredentials boolean Send cookies and auth headers with licence requests. Default: false.
licenseResponseType MKHttpResponseType Sets an explicit response type for the licence request. Default: TEXT.
useUint16InitData boolean Use Uint16Array instead of Uint8Array for init data. Depends on your FairPlay licence server. Default: false.
maxLicenseRequestRetries number How many times to retry a failed licence request. Default: 1. Set to 0 to disable retries.
maxCertificateRequestRetries number How many times to retry a failed certificate request. Default: 1. Set to 0 to disable retries.
## Common DRM errors
Error code Meaning
PLAYER_DRM_FAILED_LICENSE_REQUEST The licence request failed. Check that LA_URL is correct and that required headers and tokens are present.
PLAYER_DRM_NO_KEY_SYSTEM The current platform does not support any of the key systems in the source config.
PLAYER_DRM_CERTIFICATE_ERROR The FairPlay certificate could not be loaded or parsed. Check certificateURL.
PLAYER_DRM_INIT_DATA_MISSING No DRM init data was found in the manifest or segments. Check your stream packaging.
PLAYER_DRM_RESTRICTED_OUTPUT The device cannot securely present the content, for example due to a non-HDCP display.
PLAYER_NO_DRM_LICENSE_SERVER_URL_PROVIDED LA_URL is missing or invalid in the DRM config.
See [Events and error handling](/mkio/reference/player-sdk/events) for how to listen for and respond to DRM errors at runtime. # Events and error handling MKPlayer fires events throughout the player lifecycle, from setup through playback to teardown. You subscribe to events either in the player configuration or dynamically using `player.on()`. Errors arrive as a specific event type with a structured error object. ## Subscribe to events You can register event handlers in two ways. **In the player configuration** (before the player is created): ```javascript const playerConfig = { key: "YOUR_PLAYER_LICENSE_KEY", events: { [mkplayer.MKPlayerEvent.SourceLoaded]: (event) => { console.log("Source loaded"); }, [mkplayer.MKPlayerEvent.Playing]: (event) => { console.log("Playback started"); }, [mkplayer.MKPlayerEvent.Error]: (event) => { console.error("Player error: ", event.code, event.message); } } }; ``` **Dynamically at runtime** using `player.on()`: ```javascript player.on(mkplayer.MKPlayerEvent.Ready, (event) => { console.log("Player is ready"); }); player.on(mkplayer.MKPlayerEvent.TimeChanged, (event) => { console.log("Current time: ", event.time); }); ``` ## Remove event handlers To remove a specific handler: ```javascript const handler = (event) => { console.log("Playing"); }; player.on(mkplayer.MKPlayerEvent.Playing, handler); // Remove this specific handler later player.off(mkplayer.MKPlayerEvent.Playing, handler); ``` To remove all handlers for a given event type: ```javascript player.offAll(mkplayer.MKPlayerEvent.Playing); ``` ## Key player events
Event Fires when
Ready The player has enough data to start playback.
SourceLoad A new source load has been initiated.
SourceLoaded A source has finished loading.
SourceUnloaded The current source has been unloaded.
Play The player enters the play state via a public API call or user interaction. Note: autoplay does not fire this event.
Playing Playback has started.
Paused The player enters the paused state.
PlaybackFinished Playback of the current video has finished.
TimeChanged The current playback time has changed.
StallStarted The player has begun buffering due to an empty buffer.
StallEnded The player has resumed after buffering.
Destroy The player instance has been destroyed.
Error An error has occurred during setup or playback.
See the `MKPlayerEvent` enum in the SDK reference for the full list of events. ## Handle errors All errors arrive on the `Error` event. The event object implements `MKErrorEvent` and includes:
Property Type Description
code string A structured error code, for example "4-70-1103".
message string A human-readable description of the error.
name string The name of the error.
troubleShootLink string A link to a detailed troubleshooting guide, if available.
data object Additional error data, if available.
```javascript player.on(mkplayer.MKPlayerEvent.Error, (event) => { console.error(`Error [${event.code}]: ${event.message}`); if (event.troubleShootLink) { console.info("Troubleshooting: ", event.troubleShootLink); } }); ``` ## Common error codes ### Setup errors
Code Constant Meaning
4-70-1101 PLAYER_SETUP_NO_HTML_ELEMENT The container element passed to the player is not a valid HTMLElement. Check that the element exists in the DOM before creating the player.
4-70-1102 PLAYER_SETUP_MISSING_CONFIGURATION No MKPlayerConfig was provided when creating the player instance.
4-70-1103 PLAYER_SETUP_LICENSE_ERROR The player key was not granted playback. Check that your license key is correct.
4-70-1104 PLAYER_SETUP_MISSING_DOMAIN_LICENSE_ALLOWLIST The player build is domain-locked and the current domain is not in the allowlist.
4-70-1105 PLAYER_SETUP_MISSING_LICENSE_ALLOWLIST The current domain has not been added to the license allowlist.
4-70-1113 PLAYER_SETUP_UNSUPPORTED_PROTOCOL The page was loaded using the file:// protocol. Host the page on a web server using http or https.
### Source errors
Code Constant Meaning
4-71-1201 PLAYER_SOURCE_INVALID The MKSourceConfig passed to player.load() is invalid. Ensure at least one valid stream URL is present.
4-71-1202 PLAYER_SOURCE_MANIFEST_INVALID The downloaded manifest could not be parsed.
4-71-1208 PLAYER_SOURCE_COULD_NOT_LOAD_MANIFEST The manifest request failed after retries. By default, manifests are retried 2 times.
### Network errors
Code Constant Meaning
4-73-1009 PLAYER_GENERAL_NETWORK_ERROR The device is not connected to the internet.
4-73-1401 PLAYER_NETWORK_MANIFEST_DOWNLOAD_TIMEOUT The manifest request timed out after the default 20-second timeout.
4-73-1402 PLAYER_NETWORK_SEGMENT_DOWNLOAD_TIMEOUT A segment download timed out.
### DRM errors See [DRM protection](/mkio/reference/player-sdk/drm) for the full list of DRM-specific error codes and guidance on resolving them. # Loading and playing content Pass a source configuration object to `player.load()` to load content into an initialised player. You can then control playback or destroy the player instance when it is no longer needed. ## Prerequisites You have an initialised `MKPlayer` instance. See [Installation and setup](/mkio/reference/player-sdk/setup). ## Load a source Build a `MKSourceConfig` object that describes your content, then call `player.load()`: ```javascript const sourceConfig = { title: "My Stream", description: "A brief description of the content", poster: "https://my-cdn.com/mysource/poster.png", hls: "https://my-cdn.com/mysource/hls/index.m3u8", dash: "https://my-cdn.com/mysource/dash/manifest.mpd" }; player.load(sourceConfig) .then(() => { console.log("Source loaded successfully"); }) .catch((error) => { console.error("Source load failed: ", error); }); ``` Pass only one stream type in the source configuration: either `hls` or `dash`. When both are present, the player selects based on platform support. For DRM-protected content, you also need to pass a `drm` property. See [DRM protection](/mkio/reference/player-sdk/drm). ## Source configuration options
Property Type Description
title string Display title for the source.
description string Brief description of the source.
poster string URL to a poster image shown before playback starts.
hls string URL to an HLS master playlist.
dash string URL to a DASH manifest.
drm MKDrmConfig DRM configuration for protected content. See DRM protection.
subtitleTracks MKSubtitleTrack[] External subtitle tracks to register with the player.
enableLowLatency boolean Enables low-latency mode for live streams.
assetType MKAssetType Required for registered sources. Values: live, event, catchup, dvr, vod.
## Control playback After a source is loaded, use the player API to control playback: ```javascript // Start or resume playback player.play(); // Pause player.pause(); // Seek to a position (seconds) player.seek(30); // Set volume (0–100) player.setVolume(80); // Mute and unmute player.mute(); player.unmute(); // Set playback speed (HTML5 player only) // Values between 0 and 1 are slow motion; values above 1 are fast forward player.setPlaybackSpeed(1.5); ``` ## Unload a source To stop playback and clear the current source without destroying the player instance: ```javascript player.unload() .then(() => { console.log("Source unloaded"); }) .catch((error) => { console.error("Unload failed: ", error); }); ``` You can call `player.load()` again after `unload()` to play a different source. ## Destroy the player To tear down the player entirely and release all held resources: ```javascript player.destroy(); ``` You must create a new `MKPlayer` instance after calling `destroy()`. Calling a player API method after `destroy()` returns a `PLAYER_API_NOT_AVAILABLE` error. It is recommended to wait for the `Destroy` event before discarding your player reference: ```javascript player.on(mkplayer.MKPlayerEvent.Destroy, () => { console.log("Player destroyed and resources released"); player = null; }); player.destroy(); ``` # Installation and setup Install MKPlayer, add it to an HTML page, and create an initialised player instance before loading media. ## Prerequisites - npm available in your project - A player license key from MediaKind - Your deployment domain added to the MediaKind license allowlist

The player will not start if your domain is not allowlisted. You will see a PLAYER_SETUP_MISSING_LICENSE_ALLOWLIST error. Contact MediaKind to add your domain before going further.

## Install and initialise ### Install the package ```bash npm i @mediakind/mkplayer ``` ### Include the scripts in your page Add `mkplayer.js` and `mkplayer-ui.css` to the `` of your HTML page: ```html My Video Player ``` ### Add a video container element Add a `
` to your page ``. MKPlayer uses this element as the playback container: ```html
``` ### Create a player instance In your JavaScript, get the container, build a configuration object, and pass both to `MKPlayer`: ```javascript const videoContainer = document.getElementById("video-container"); const playerConfig = { key: "YOUR_PLAYER_LICENSE_KEY", playback: { muted: true, autoplay: true } }; const player = new mkplayer.MKPlayer(videoContainer, playerConfig); ``` The player is now initialised and ready to load a source. See [Loading and playing content](/mkio/reference/player-sdk/playback) for the next step. ## Player configuration options The `MKPlayerConfig` object controls how the player behaves. All properties are optional except where noted.
Property Type Description
key string Your player license key.
playback MKPlaybackConfig Playback options such as autoplay and muted.
ui boolean Enables the built-in player UI. Requires mkplayer-ui.css to be loaded. Default: false.
events MKPlayerEventConfig Map of player events to handler callbacks. You can also register handlers dynamically using player.on().
analytics MKAnalyticsConfig | false Analytics configuration. Set to false to disable analytics even if the analytics module is loaded.
buffer MKBufferConfig Buffer configuration.
log MKLogConfig Log level and output configuration.
tweaks MKTweaksConfig Advanced player tweaks. Use these only if you understand their effect on playback behaviour.
## Additional requirements for Apple devices Safari on Mac, iPhone, and iPad requires an extra step to support secure URLs and custom HTTP headers via `setHttpHeaders`. 1. Download `serviceWorker.js` from the MKPlayer SDK resources. 2. Place the file at the root of the domain where your web app is hosted, for example `https://yourdomain.com/serviceWorker.js`. 3. Explicitly enable `native_hls_parsing` in your player configuration: ```javascript const playerConfig = { key: "YOUR_PLAYER_LICENSE_KEY", tweaks: { native_hls_parsing: true } }; ``` The SDK enables `native_hls_parsing` by default if the property is not set, but setting it explicitly ensures consistent behaviour across environments. # Subtitles and captions MKPlayer supports in-stream subtitles and captions from HLS and DASH manifests, as well as external subtitle tracks you add programmatically. You manage tracks through the `player.subtitles` API. **Subtitles** have a `kind` of `"subtitle"`. **Captions** (closed captions) have a `kind` of `"caption"`. The API handles both the same way. ## Prerequisites You have an initialised `MKPlayer` instance with a source loaded. See [Loading and playing content](/mkio/reference/player-sdk/playback). ## Enable and disable tracks After a source loads, list available subtitle tracks and enable the one you want: ```javascript // List all available subtitle and caption tracks const tracks = player.subtitles.list(); console.log(tracks); // Enable a track by its ID // By default, enabling one track disables all others player.subtitles.enable("track-id"); // Enable a track without disabling others player.subtitles.enable("track-id", false); // Disable a track player.subtitles.disable("track-id"); ``` Each track in the list is an `MKSubtitleTrack` object with the following properties:
Property Type Description
id string Track identifier used to enable, disable, or remove the track.
label string Display name shown to the user.
lang string Language of the track.
kind string Either "subtitle" or "caption".
enabled boolean Whether the track is currently active.
forced boolean If true, the player automatically selects this track to match the active audio language.
url string URL to the subtitle file, for external tracks.
## Add external subtitle tracks You can add external subtitle tracks programmatically. Pass an `MKSubtitleTrack` object to `player.subtitles.add()`: ```javascript player.subtitles.add({ id: "en-subs", label: "English", lang: "en", kind: "subtitle", url: "https://my-cdn.com/subtitles/en.vtt" }); ``` Alternatively, include external tracks in the source configuration before calling `player.load()`: ```javascript const sourceConfig = { title: "My Stream", hls: "https://my-cdn.com/mysource/hls/index.m3u8", subtitleTracks: [ { id: "en-subs", label: "English", lang: "en", kind: "subtitle", url: "https://my-cdn.com/subtitles/en.vtt" } ] }; ``` ## Remove a track ```javascript player.subtitles.remove("track-id"); ``` If the track is currently enabled, it is disabled before removal. ## Style subtitles You can change subtitle appearance at runtime using `player.setSubtitleStyle()`. Pass a style options object with any combination of the supported properties: ```javascript player.setSubtitleStyle({ fontSize: "50", fontStyle: "normal", fontFamily: "normal", fontColor: "white", fontOpacity: "75", backgroundColor: "black" }); ``` Supported style options:
Property Supported values
fontSize "1" to "100"
fontStyle "normal", "italic", "bold"
fontFamily "Times New Roman", "fantasy", "cursive", "serif", "monospace", "Font Awesome 5 Free"
fontColor "normal", "white", "black", "red", "green", "blue", "cyan", "yellow", "magenta"
fontOpacity "0" to "100"
backgroundColor "normal", "white", "black", "red", "green", "blue", "cyan", "yellow", "magenta"
## Subtitle overlay The player renders subtitles using a built-in overlay by default (`enableSubtitleOverlay: true`). To handle subtitle rendering yourself, disable the overlay and listen for cue events: ```javascript const playerConfig = { key: "YOUR_PLAYER_LICENSE_KEY", enableSubtitleOverlay: false }; ``` Then subscribe to cue events to receive subtitle text as it becomes active: ```javascript player.on(mkplayer.MKPlayerEvent.CueEnter, (event) => { // event.html contains the cue content console.log("Subtitle cue entered: ", event.html); }); player.on(mkplayer.MKPlayerEvent.CueExit, (event) => { console.log("Subtitle cue exited"); }); ``` Note: the subtitle overlay is automatically disabled when the built-in UI (`ui: true`) is enabled. To use the overlay, keep `ui` disabled. # End-to-end walkthrough Build an MKPlayer integration from a blank HTML file to a working player that loads DRM-protected content, displays subtitles, and handles errors. Complete the sections in order because each one builds on the previous result. By the end you will have a self-contained page you can adapt for your own project. ## What this covers - Installing MKPlayer and wiring up the HTML - Initialising the player with a full configuration - Loading DRM-protected content with Widevine, PlayReady, and FairPlay - Enabling subtitles and styling them at runtime - Subscribing to events and surfacing errors to the user - Cleaning up the player correctly when done ## Prerequisites - npm available in your project - A player license key from MediaKind - Your deployment domain added to the MediaKind license allowlist - A Widevine and/or PlayReady license server URL for your content ## The HTML page Start with a minimal HTML page. Include the MKPlayer script and stylesheet in ``, and add a container `
` and a few controls in ``: ```html MKPlayer Example

``` The `status` paragraph is where you will surface error messages to the user. The actual player logic lives in `player.js`. ## Step 1: Initialise the player In `player.js`, wait for the DOM to be ready, then create an `MKPlayer` instance. The player configuration sets your license key, enables the built-in UI, and registers event handlers inline. Subscribing to `Error` and `Playing` here ensures you catch events that fire early in the player lifecycle, before you have a chance to call `player.on()` after construction. ```javascript // player.js const statusEl = document.getElementById("status"); function setStatus(message) { statusEl.textContent = message; } // Wait for the DOM to be ready before accessing elements window.addEventListener("load", () => { const container = document.getElementById("player-container"); const playerConfig = { key: "YOUR_PLAYER_LICENSE_KEY", ui: true, playback: { // muted is required for autoplay to work in most browsers muted: false, autoplay: false, // Prevent the video going fullscreen automatically on iOS playsInline: true }, events: { [mkplayer.MKPlayerEvent.Playing]: () => { setStatus(""); }, [mkplayer.MKPlayerEvent.Error]: (event) => { setStatus(`Error ${event.code}: ${event.message}`); console.error("MKPlayer error", event); }, [mkplayer.MKPlayerEvent.StallStarted]: () => { setStatus("Buffering..."); }, [mkplayer.MKPlayerEvent.StallEnded]: () => { setStatus(""); } } }; const player = new mkplayer.MKPlayer(container, playerConfig); loadContent(player); }); ```

Unmuted autoplay is blocked by most browsers unless the user has previously interacted with the page. If you need autoplay, set muted: true. The user can then unmute using the player controls.

## Step 2: Load DRM-protected content Define `loadContent()` to build a source configuration and call `player.load()`. The `drm` block covers Widevine and PlayReady for Chrome, Firefox, and Edge, plus FairPlay for Safari on Apple devices. The player selects the first key system supported by the current browser. ```javascript function loadContent(player) { const sourceConfig = { title: "My Protected Stream", description: "An example of DRM-protected DASH and HLS playback", poster: "https://my-cdn.com/content/poster.jpg", // Provide both DASH and HLS. The player picks based on platform support dash: "https://my-cdn.com/content/dash/manifest.mpd", hls: "https://my-cdn.com/content/hls/index.m3u8", drm: { widevine: { LA_URL: "https://your-widevine-license-server/license", headers: { "X-DRM-Token": "your-token-value" } }, playready: { LA_URL: "https://your-playready-license-server/license", utf8message: true, plaintextChallenge: true, headers: { "Content-Type": "text/xml", "X-DRM-Token": "your-token-value" } }, // FairPlay applies only to HLS sources on Apple devices fairplay: { LA_URL: "https://your-fairplay-license-server/license", certificateURL: "https://your-fairplay-certificate-url", headers: { "X-DRM-Token": "your-token-value" } } }, subtitleTracks: [ { id: "en-subs", label: "English", lang: "en", kind: "subtitle", url: "https://my-cdn.com/content/subtitles/en.vtt" }, { id: "fr-subs", label: "French", lang: "fr", kind: "subtitle", url: "https://my-cdn.com/content/subtitles/fr.vtt" } ] }; setStatus("Loading..."); player.load(sourceConfig) .then(() => { console.log("Source loaded successfully"); setupSubtitles(player); }) .catch((error) => { setStatus(`Failed to load source: ${error.message}`); console.error("Load failed", error); }); } ``` ## Step 3: Enable subtitles Once the source has loaded, list the available subtitle tracks and enable one by default. You can also let the player select a preferred language by setting `subtitleLanguage` in the `playback` configuration. This example selects the track explicitly so you can use its ID in the next step. ```javascript function setupSubtitles(player) { const tracks = player.subtitles.list(); if (tracks.length === 0) { return; } // Log available tracks for debugging console.log("Available subtitle tracks:", tracks.map(t => `${t.id} (${t.lang})`)); // Enable English subtitles by default if available const englishTrack = tracks.find(t => t.lang === "en"); if (englishTrack) { player.subtitles.enable(englishTrack.id); applySubtitleStyle(player); } } function applySubtitleStyle(player) { player.setSubtitleStyle({ fontSize: "50", fontStyle: "normal", fontFamily: "normal", fontColor: "white", fontOpacity: "100", backgroundColor: "black" }); } ``` ## Step 4: Add remaining event handling Add event listeners after the player is created to handle the remaining playback lifecycle. This example registers them dynamically with `player.on()` instead of adding them to the configuration: ```javascript function attachEvents(player) { player.on(mkplayer.MKPlayerEvent.SourceLoaded, () => { console.log("Source loaded"); }); player.on(mkplayer.MKPlayerEvent.PlaybackFinished, () => { console.log("Playback finished"); setStatus("Playback complete."); }); player.on(mkplayer.MKPlayerEvent.Destroy, () => { console.log("Player destroyed"); }); } ``` Call `attachEvents(player)` immediately after creating the player instance, before `loadContent()`. ## Step 5: Clean up When the page unloads, or when you are done with the player, unload the source and destroy the instance to release all held resources: ```javascript window.addEventListener("beforeunload", () => { if (player) { player.unload() .then(() => player.destroy()) .catch(() => player.destroy()); } }); ``` Do not call any player API methods after `destroy()`. The player will throw a `PLAYER_API_NOT_AVAILABLE` error. ## Complete player.js Putting it all together: ```javascript // player.js const statusEl = document.getElementById("status"); function setStatus(message) { statusEl.textContent = message; } function applySubtitleStyle(player) { player.setSubtitleStyle({ fontSize: "50", fontStyle: "normal", fontFamily: "normal", fontColor: "white", fontOpacity: "100", backgroundColor: "black" }); } function setupSubtitles(player) { const tracks = player.subtitles.list(); if (tracks.length === 0) return; const englishTrack = tracks.find(t => t.lang === "en"); if (englishTrack) { player.subtitles.enable(englishTrack.id); applySubtitleStyle(player); } } function attachEvents(player) { player.on(mkplayer.MKPlayerEvent.SourceLoaded, () => { console.log("Source loaded"); }); player.on(mkplayer.MKPlayerEvent.PlaybackFinished, () => { setStatus("Playback complete."); }); player.on(mkplayer.MKPlayerEvent.Destroy, () => { console.log("Player destroyed"); }); } function loadContent(player) { const sourceConfig = { title: "My Protected Stream", description: "An example of DRM-protected DASH and HLS playback", poster: "https://my-cdn.com/content/poster.jpg", dash: "https://my-cdn.com/content/dash/manifest.mpd", hls: "https://my-cdn.com/content/hls/index.m3u8", drm: { widevine: { LA_URL: "https://your-widevine-license-server/license", headers: { "X-DRM-Token": "your-token-value" } }, playready: { LA_URL: "https://your-playready-license-server/license", utf8message: true, plaintextChallenge: true, headers: { "Content-Type": "text/xml", "X-DRM-Token": "your-token-value" } }, fairplay: { LA_URL: "https://your-fairplay-license-server/license", certificateURL: "https://your-fairplay-certificate-url", headers: { "X-DRM-Token": "your-token-value" } } }, subtitleTracks: [ { id: "en-subs", label: "English", lang: "en", kind: "subtitle", url: "https://my-cdn.com/content/subtitles/en.vtt" }, { id: "fr-subs", label: "French", lang: "fr", kind: "subtitle", url: "https://my-cdn.com/content/subtitles/fr.vtt" } ] }; setStatus("Loading..."); player.load(sourceConfig) .then(() => setupSubtitles(player)) .catch((error) => { setStatus(`Failed to load source: ${error.message}`); console.error("Load failed", error); }); } window.addEventListener("load", () => { const container = document.getElementById("player-container"); const playerConfig = { key: "YOUR_PLAYER_LICENSE_KEY", ui: true, playback: { muted: false, autoplay: false, playsInline: true }, events: { [mkplayer.MKPlayerEvent.Playing]: () => setStatus(""), [mkplayer.MKPlayerEvent.Error]: (event) => { setStatus(`Error ${event.code}: ${event.message}`); console.error("MKPlayer error", event); }, [mkplayer.MKPlayerEvent.StallStarted]: () => setStatus("Buffering..."), [mkplayer.MKPlayerEvent.StallEnded]: () => setStatus("") } }; const player = new mkplayer.MKPlayer(container, playerConfig); attachEvents(player); loadContent(player); window.addEventListener("beforeunload", () => { player.unload() .then(() => player.destroy()) .catch(() => player.destroy()); }); }); ``` ## What to replace Before running this, replace the following placeholder values with your own:
Placeholder Replace with
YOUR_PLAYER_LICENSE_KEY Your player license key from MediaKind
https://your-widevine-license-server/license Your Widevine license server URL
https://your-playready-license-server/license Your PlayReady license server URL
https://your-fairplay-license-server/license Your FairPlay license server URL
https://your-fairplay-certificate-url Your FairPlay certificate URL
your-token-value Your DRM auth token or other required header values
All https://my-cdn.com/... URLs Your actual stream manifest, poster, and subtitle URLs
## Common issues at this stage **The player throws `PLAYER_SETUP_MISSING_LICENSE_ALLOWLIST`.** Your domain is not on the MediaKind license allowlist. Contact MediaKind to add it before testing. **The player throws `PLAYER_DRM_FAILED_LICENSE_REQUEST`.** The license server rejected the request. Check that your `LA_URL` is correct, that any required auth headers are present, and that the token has not expired. **Subtitles do not appear after `player.subtitles.enable()`.** Check that `enableSubtitleOverlay` is not set to `false` in your player configuration and that `ui` is set to `false`. The built-in subtitle overlay is disabled when `ui` is enabled. If you are using `ui: true`, the UI layer handles subtitle rendering. **Safari does not play back the stream.** Ensure you have placed `serviceWorker.js` at the root of your domain and set `tweaks: { native_hls_parsing: true }` in your player config. See [Installation and setup](/mkio/reference/player-sdk/setup) for details. # MK.IO reference Use these pages to look up platform availability, supported locations, preset behavior, resource states, and player integration details. [Platform availability](/mkio/reference/platform-availability) Review the platform availability model and service-level options. [Cloud region support](/mkio/reference/cloud-region-support) Find supported regions and available deployment options. [Transform presets](/mkio/reference/encoding-transform-presets/encoding-transform) Look up built-in transforms for encoding and other processing tasks. [Resource states](/mkio/reference/resource-states) Interpret resource and provisioning states returned by MK.IO APIs. [MK Player SDK](/mkio/reference/player-sdk) Integrate MK Player and configure playback, events, subtitles, and DRM. [Player customization](/mkio/reference/player-customization) Configure and customize the MK Player user interface. [API Reference](/api-reference/media-api) Look up Media API endpoints, schemas, and example requests. [API Guides](/mkio/api-guides) Follow task-based guidance for Media, Management, Fleet, and Infrastructure APIs. # Resource states Use resource states to determine whether an MK.IO operation is still in progress or has reached a stable result. ## Common resource states - `Deleting`: deleted by the user and and waiting for the deletion to be processed by the system. - `Deleted`: deleted by the user and deletion processed by the system. This value will not show up because the resource being deleted means the endpoint will return 404. ## Transitional and terminal states
Initial Created Starting Started Stopping Stopped
Asset Pending Ready | - - - -
ContentKeyPolicy Creating Created | - - - -
LiveEvent Allocating StandBy | Starting Running Stopping Stopped
LiveOutput Creating Running | - - - -
StreamingLocator Creating Created | - - - -
StreamingEndpoint Creating Created | Starting Running Stopping Stopped
Aquila Source (with IP set) Created - | - Running - Created Running: in use by a started Channel
Aquila Source (with IP allocated) Pending Created | - Running - Created Running: in use by a started Channel
Aquila Channel Stopped - | Starting Running Stopping Stopped
Flow "" - | Starting Running Stopping Stopped
- [Concept overview](/mkio/understanding/overview-understanding): Learn the resources and platform concepts behind MK.IO media workflows. - [Fundamentals](/mkio/understanding/fundamentals): Pages in the Fundamentals section. - [Core Concepts](/mkio/understanding/core-concepts): Understand how MK.IO resources organize, process, protect, and deliver live and on-demand media. - [Advanced Concepts](/mkio/understanding/advanced-concepts): Pages in the Advanced Concepts section. - [What is Latency](/mkio/understanding/advanced-concepts/latency): Understand the sources of delay in live video workflows and how MK.IO reports latency. - [Device on-boarding](/mkio/understanding/advanced-concepts/devices): Understand how MK.IO registers, monitors, and controls MediaKind software running on edge equipment. # Devices MK.IO supports the use of MediaKind software running on on-prem equipment by allowing the equipment to be registered within the platform. Once registered, the software can be monitored and controlled from MK.IO, simplifying and centralizing the management of MediaKind appliances and servers hosting MediaKind software. The registration of on-prem equipment is handled through **device** resources. A **Device** refers to a VM or bare-metal server running MediaKind media processing software that is registered for control by MK.IO. The device can be either a pre-installed MediaKind appliance or a **COTS** server. Devices are added to on-prem sites within your organization.

Devices Overview

## Device health and status MK.IO tracks each registered device's health from what the device last reported: - **Alarm severity**: the most severe alarm currently active on the device, from `0` (Clear) through `1` (Info), `2` (Warning), `3` (Error), to `4` (Critical). - **Last contact**: the timestamp of the device's last check-in with MK.IO, and how many seconds have elapsed since. - **Software version**: the current running version, the desired version, and the rollback version available if an upgrade needs to be reverted. - **Software upgrade state**: `Idle`, `Switching` (an upgrade is being applied), or `SwitchFailed`. Not every device reports every field. For example, configuration backup support depends on the device's Beam software version. ## Device on-boarding To learn more about device on-boarding, read our guide on [how to on-board edge devices](/mkio/how-to/managing-edge-devices/on-board-fleet-devices). ## Device access For MediaKind devices with a local web user interface, MK.IO provides remote access through a secure connection. Open the device in the MK.IO portal to access its user interface. To learn more about accessing the remote device UI, read our guide on [how to access the remote device UI](/mkio/how-to/managing-edge-devices/access-the-remote-device-ui). # Latency **Latency** is the term used to define the amount of delay for the processing and transmission of data from one point to another. **End-to-end latency** in live streaming refers to the time it takes for a live video signal to be captured by a camera, transmitted over a network, and displayed on a viewer's screen. The term **"glass to glass"** refers to this production workflow from the camera lens to the moment it is displayed on a screen. End-to-end latency includes the time it takes to encode the video signal, transmit it over the network, and decode it on the viewer's device.

End-to-end latency in a live video workflow

End-to-end latency in a live video workflow

Latency is introduced throughout the entire broadcast chain. The delay can vary depending on many factors, including the technology being used, the software implementation, and how the production and transmission equipment is configured. Reducing latency is critical for live events to minimize the gap between the action and the viewer's experience. ## Latency introduced in video streaming Before the introduction of low-latency formats and optimized software architectures, a typical OTT streaming platform would introduce 40+ seconds of delay from source to playback. With the latest improvements in **MK.IO**, the delay from encoding to playback has been **reduced to 25 seconds.** Additional enhancements are in development, utilizing standardized low-latency streaming to further reduce this delay. A [live event](/mkio/understanding/core-concepts/live-event) can also be created with the `LowLatency` stream option instead of the default, for workflows where reducing glass-to-glass delay matters most. ### Delay in the encoder The delay in the Live Encoder is the sum of the delay necessary for decoding, encoding, and output.

Latency overview in the encoder

Latency overview in the encoder

At the input of the live encoder, an IP input buffer compensates for network jitter and out-of-order packets. The input is then decoded, with the duration varying based on the format. ### Delay in the packager

Latency overview in the packager

Latency overview in the packager

Content is first written to the DVR before being packaged and played out. CMAF chunks are issued as soon as they are completed by the Just-In-Time Packager (JITP). The packaged output cannot be delivered until the Manifest is generated and delivered to the player. ### Delay introduced at player level

Latency overview in the player

Latency overview in the player

The player fetches video segments over the network (each several seconds long). To ensure a smooth experience, the player typically waits until it has multiple segments before beginning playback to prevent interruptions from network fluctuations. Finally, the player decodes and renders the video frames and audio samples. # Media resource model MK.IO workflows combine resources for storage, processing, and delivery. The resources you use depend on whether the input is an on-demand file or a continuous live stream.

MK.IO media resources for live and on-demand workflows

## Organize media An [asset](/mkio/understanding/core-concepts/assets) is a logical reference to files in connected cloud storage. Processing jobs and live outputs use assets as inputs or destinations. Streaming locators also reference assets when publishing content. Connect storage before you add or create assets. See [Connect cloud storage](/mkio/getting-started/connect-cloud-storage) and [Assets and storage](/mkio/how-to/content-management). ## Process on-demand media A [transform](/mkio/understanding/core-concepts/transforms-and-jobs) defines a reusable processing task for file-based content. A job applies that transform to an input and writes the result to an output asset. Use [Video processing](/mkio/how-to/video-processing-encoding) for portal instructions. Use the [Transforms and jobs API Guide](/mkio/api-guides/how-to/media/transforms-and-jobs) to automate the same workflow. ## Process live media A [live event](/mkio/understanding/core-concepts/live-event) receives a continuous input for passthrough or encoding. A live output writes the processed stream to an asset and maintains the archive window used for playback. Use [Live events](/mkio/how-to/live-streaming) for portal instructions. Use the [Live streaming API Guide](/mkio/api-guides/how-to/media/live-streaming) for API workflows. ## Publish media A [streaming locator](/mkio/understanding/core-concepts/locators) associates an asset with a streaming policy and provides the path used for playback. A [streaming endpoint](/mkio/understanding/core-concepts/endpoints) packages and delivers the content through HLS or DASH. Use [Streaming endpoints and playback](/mkio/how-to/content-delivery-publishing) to publish content in the portal. The [Publishing API Guide](/mkio/api-guides/how-to/media/publishing) covers the corresponding API resources. ## Protect playback A [content key policy](/mkio/understanding/core-concepts/content-protection) defines how MK.IO issues content keys and authorizes protected playback. A streaming policy can refer to that content key policy when you create a locator. Use [Content key policies](/mkio/how-to/drm-content-protection) for configuration guides. Use the [Content protection API Guide](/mkio/api-guides/how-to/media/content-protection) for API-based workflows. # API Concepts Use these API concepts and data models when building MK.IO video workflows.

Four building blocks of the API

Four building blocks of the API

The **MK.IO** API is conceptually broken into four main parts: **Inputs**, **Assets**, **Streaming Locators**, and **Streaming Endpoints**. ## Explore the API ### Input Inputs are the methods used to bring content into the system. - Content is **transformed** into an Asset upon entry. - **Static content** is uploaded to cloud storage and processed using a **Job**. - **Live content** is ingested via a **Live Event**, with a time-shift buffer defined by a **Live Output**. ### Storage **Assets** represent the location where content is stored in your cloud storage. They are decoupled from inputs, allowing the content to be managed and accessed at any point in the future. ### Content protection and rewrites **Streaming Locators** connect DRM policies and filters to an asset, allowing a dynamic packager (JITP) to process the content. Locators handle DRM and manifest rewrites; you can create several locators for a single asset to support different business rules. ### Publishing **Streaming Endpoints** define the domain name for your content and provide options for integrating with CDNs. Streaming Endpoints are used for scaling your output and delivering content to global audiences.

Every Streaming Locator you create is available at every Streaming Endpoint within your project.

## Authentication Every MK.IO API request must be authenticated with an API token. See [API tokens](/mkio/how-to/managing-your-organization/api-tokens) to create and manage tokens, and the [Tokens API Guide](/mkio/api-guides/how-to/management/tokens) for the authentication header format and token endpoints. ## Data model Everything within **MK.IO** revolves around an **Asset**. File-based and live inputs are treated as assets on the output side. Assets have policies attached to them via a [Streaming Locator](/mkio/understanding/core-concepts/locators), which are then bound to a [Streaming Endpoint](/mkio/understanding/core-concepts/endpoints) for delivery.

Data Model

MK.IO Data Model Overview

# Assets & Asset Filters Understand how MK.IO assets map to cloud storage and how asset filters change the manifests delivered to players. ## What is an asset? An **asset** in MK.IO is a logical pointer to a location in your cloud storage. It is not a copy of your files: it is a reference that tells MK.IO where to find, process, and stream content. Every asset maps to exactly one storage location: - **Azure Blob Storage** → a container (or a subfolder within a container) - **Amazon S3** → a bucket or prefix The files themselves live in your cloud storage. MK.IO reads from and writes to that location on your behalf. This is why: - Creating an asset does not move or copy any files - An asset can appear empty if the storage location is empty or the container name is incorrect - Deleting an asset in MK.IO can delete the associated files from storage (depending on the deletion setting chosen at creation time)

Assets Overview

## What goes into an asset? Assets contain information about digital files stored in cloud storage, including: - **Source files**: the original uploaded video, audio, or image files - **Encoded output**: adaptive bitrate segments and manifests produced by encoding jobs - **Subtitle and caption files**: VTT, SRT, TTML - **Thumbnails and images** - **Log files**: generated during processing jobs On the input side, an **encoding job** or a **live output** references an asset as its source or destination. On the output side, a **streaming locator** references an asset to generate playback URLs. ## Naming files within an asset File names within an asset must follow both: - [Azure blob name requirements](https://learn.microsoft.com/en-us/rest/api/storageservices/naming-and-referencing-containers--blobs--and-metadata) and [NTFS name requirements](https://learn.microsoft.com/en-us/windows/win32/fileio/naming-a-file) (for Azure storage) - [AWS bucket naming rules](https://docs.aws.amazon.com/AmazonS3/latest/userguide/bucketnamingrules.html) (for S3 storage) ### Reserved characters The output URL for streaming content is built from the asset file name. File names must not contain any of the following percent-encoding-reserved characters: `!*'();:@&=+$,/?%#[]"`. There can also be only one `.` for the file extension. File names must be 260 characters or fewer.

Deleting an asset in MK.IO may also delete the underlying files in your cloud storage, depending on the containerDeletionPolicy set when the asset was created. Delete removes the storage container's contents along with the asset record, Retain leaves your files in place. Check this setting before deleting.

## Asset Filters and Account Filters Filters let you trim the timeline or restrict the tracks and bitrates exposed by a streaming locator without re-encoding the content. **Asset Filter**: Applied to a specific asset. Lets you define start/end times or filter by track type (video only, specific audio language, etc.) for that individual asset. **Account Filter**: Applied at the account level and reusable across multiple assets. Enforces consistent delivery rules across your entire library without configuring each asset individually. Filters are specified by name when creating a streaming locator, and can be combined (asset filter + account filter). See [Create an asset filter](/mkio/how-to/content-management/create-an-asset-filter) for step-by-step instructions. ## See also [Reference existing cloud storage](/mkio/how-to/content-management/add-an-asset-in-mkio/reference-existing-storage) Point MK.IO at content already in Azure or S3 and avoid common empty-asset issues. [Add assets into MK.IO](/mkio/how-to/content-management/add-an-asset-in-mkio) Overview of all the ways to create assets in MK.IO. # Content Keys MK.IO lets you deliver video content to end-consumers in a controlled and secure manner. MK.IO’s streaming endpoints can deliver content using AES-128 (Advanced Encryption Standard) or any of the three major studio-approved digital rights management systems: Microsoft PlayReady, Google Widevine, and Apple FairPlay. ## Content protection concepts ### Clear Key protection Clear Key protection with AES-128 encryption is used to protect content on all devices.

AES-128 does not provide the same level of security as the three DRM systems listed below.

### Digital Rights Management systems (DRM) - **Apple FairPlay**: DRM for iOS, tvOS, iPadOS, Safari, and macOS devices. - **Google Widevine**: DRM for Google Chrome, Firefox, Android, Android TV, and many other streaming devices. - **Microsoft PlayReady**: DRM for Microsoft Edge, Xbox, and other streaming video platforms. ### JWT tokens A common use case for applying content protection is ensuring that users have the correct entitlement to access the video content. This is achieved by requiring an HTTP Header in the DRM license request and asking the MK.IO system to validate the values inside the **Issuer** and **Audience** fields in the JWT token. ## Content Keys Both AES-128 and DRM (Widevine, FairPlay, PlayReady) are supported on the platform for both live and file-based streaming. The **Content Key Policy** is used to configure how the content key (secure access to your assets) is delivered to end clients. You need to set the requirements (restrictions) on the Content Key Policy that must be met in order for keys with the specified configuration to be delivered to clients.

A Content Key Policy is not needed for clear streaming.

In most cases, the Content Key Policy is associated with the [Streaming Locator](/mkio/understanding/core-concepts/locators). When creating a custom streaming policy for advanced scenarios, you can specify the content key policy inside of a Streaming Policy. Each content policy can be assigned one or more DRMs. MK.IO also provides a service for delivering FairPlay, PlayReady, and Widevine licenses. ## Token restriction

It is not recommended to add Clear Key to a policy that is targeted for DRM as it reduces the security effectiveness.

For each DRM added, you can configure the token restriction: - **No token restriction**: Only recommended for testing purposes. - **Token validation**: Enforce access to the key with a SWT or JWT token. In this case, you must provide the **Issuer**, **Audience**, and **Primary Verification Key**. ## DRM Specific Configurations ### Widevine By default, the license configuration can be left empty and a default license configuration will be generated internally. It is possible to add a custom JSON configuration to define specific license parameters such as the persistency and validity of the license. The format of the JSON payload follows the policy overrides and license configuration syntax from the Widevine specification. **Example JSON Configuration:** ```json { "policy_overrides": { "can_play": true, "can_renew": false, "can_persist": true, "playback_duration_seconds": 10800, "license_duration_seconds": 604800 } } ``` For more information about this configuration syntax, contact [MK.IO support](https://support.mk.io). ### FairPlay FairPlay DRM requires a specific section to configure the FairPlay Certificate. You will be asked to provide the **certificate value**, the certificate **password**, and the **secret**. By default, licenses are non-persistent (lasting only as long as the playback session). You can enable offline usage by making them persistent with three options: - **No limit**: License is not limited in time. - **Limited**: A **Rental duration** can be specified. - **Offline rental**: Both **Playback duration** and **Storage duration** can be defined. ### PlayReady By default, licenses are non-persistent. You can enable offline usage with the following options: - **Start time**: When the license becomes valid. - **End time**: When the license expires (absolute or relative). - **First play expiration**: Duration the license remains valid after the first playback starts. - **Grace period**: Extra time after expiry (ignored in PlayReady 3.0+ clients). PlayReady configuration also allows setting the minimum **Security Level Policy**: - **SL150**: No protection against unauthorized use (Testing only). - **SL2000**: Software or Hardware protection for commercial content. Finally, you can define one or more **advanced output protection settings**. More information can be found in the [PlayReady documentation](https://learn.microsoft.com/en-us/playready/overview/license-and-policies). # Streaming endpoints A **streaming endpoint** is a dynamic, or just-in-time, packaging and origin service. It formats and delivers live and on-demand content to compatible players through HTTP Live Streaming (HLS) or Dynamic Adaptive Streaming over HTTP (DASH). The endpoint supplies the hostname used with streaming-locator paths. It can also apply dynamic encryption for supported Digital Rights Management (DRM) systems. ![streamingendpoints1](/images/streamingendpoints1.png) To start streaming videos, you need to start the Streaming endpoint from which you want to stream the video. ## Streaming endpoint type Choose one of three endpoint types: - **Shared**: Access up to 600 Mbps as part of a shared infrastructure within your streaming [region](/mkio/reference/cloud-region-support). - **Dedicated**: Choose the number of **Streaming Units** for the number of dedicated 200 Mbps units. - **CDN**: The best choice for production traffic. Using a CDN improves the user experience by caching the content and thus delivering it with a lower latency. CDN is backed by the dedicated streaming endpoint capacity. Choose the type based on the required capacity, delivery model, and level of guarantee. You can add and scale your endpoints based on the throughput of traffic that needs to be delivered. Scale is controlled through `scaleUnits` on the streaming endpoint resource: a value of `0` provisions a **Standard** SKU, and any value greater than `0` provisions **Premium** SKUs. ## Endpoint state A streaming endpoint has a `resourceState`, set by the system, that reflects what it is currently doing:
State Meaning
Creating The endpoint is being provisioned.
Starting The endpoint is coming online.
Running The endpoint is serving traffic.
Scaling The endpoint is changing capacity.
Updating Configuration changes are being applied.
Restarting The endpoint is restarting.
Stopping The endpoint is shutting down.
Stopped The endpoint exists but is not serving traffic.
Deleting The endpoint is being removed.
Deleted The endpoint no longer exists.
A streaming locator cannot deliver content while its streaming endpoint is anywhere other than `Running`. This is the most common reason a correctly published asset returns errors instead of playing. ## Hostname and access control Each streaming endpoint gets an auto-generated fully qualified hostname. Custom hostnames are not currently supported. By default, a streaming endpoint accepts requests from any IP address (`0.0.0.0/0`). You can restrict this with an IP allow list to limit which clients can reach the endpoint directly. ## CDN behavior and constraints An integrated Content Delivery Network (CDN) endpoint supports live and on-demand delivery with HTTP Live Streaming (HLS) using Common Media Application Format (CMAF), and Dynamic Adaptive Streaming over HTTP (DASH). You can also configure an external CDN to use a standard MK.IO streaming endpoint as its origin. The CDN caches content separately for each representation, streaming protocol, and encryption or Digital Rights Management (DRM) configuration when common encryption is not used. A change that invalidates many cached objects at once, such as a broad account-filter change, can cause a temporary increase in traffic to the streaming endpoint. CDN delivery reduces origin traffic, but the streaming endpoint still needs enough capacity to serve cache misses. Integrated CDN delivery uses dedicated endpoint capacity.

If you need help in deciding the right type of streaming endpoint, or calculating the number of units required, contact our support channels for help.

## See also [Publish content for streaming](/mkio/how-to/content-delivery-publishing/stream-content) Step-by-step guide to creating streaming endpoints and locators. [Streaming Locators](/mkio/understanding/core-concepts/locators) How locators attach to assets and generate playback URLs. # Live events **Live events** receive content that is streamed continuously with Real-Time Messaging Protocol (RTMP), encrypted RTMP (RTMPS), or Secure Reliable Transport (SRT). Choose passthrough when the source is already prepared for delivery, or live encoding when MK.IO should create adaptive bitrate (ABR) output.

Live Event Concept

## Live Encoding For live content, a **Live Event** creates an endpoint for input, an endpoint for preview, and an encoder. Live Events provide a persistent DNS name through which content can be streamed for encoding. The DNS name remains available while the service is alive, though its configuration is removed when a stream is stopped. MK.IO provides two encoding presets: - A **standard version** up to 720p at 30fps. - An **advanced version** up to 1080p at 30fps. Both versions support live-to-VOD workflows and archive windows of up to 30 days. For archive windows longer than 25 hours, the default manifest presents a rolling 25-hour window. See [Extended archive window](/mkio/how-to/live-streaming/extended-archive-window) for access to earlier content. A live event also has a `streamOptions` setting of `Default` or `LowLatency`, set at creation and not changeable afterward. ### Preset Lineup Summary
Built-in preset name Video Audio
Live Encoding 720p (Foundations) 340x192 @ 30fps / 200kbps
384x216 @ 30fps / 550kbps
512x288 @30 fps / 850kbps
704x396 @ 30fps / 1350kbps
960x540 @ 30fps / 2200kbps
1280x720 @ 30fps / 3500kbps
96 kbps / 48kHz
Live Encoding 1080p (Advanced) 320x180 @ 30fps / 200kbps
480x270 @ 30fps / 400kbps
640x360 @ 30fps / 800kbps
960x540 @ 30fps / 1600kbps
1280x720 @ 30fps / 3000kbps
1920x1080 @ 30fps / 5500kbps
96 kbps / 48kHz
## Live Passthrough Live Passthrough comes in two versions: - **Standard**: Capped at 5 Mbps ingest. - **Advanced**: Supports up to 60 Mbps ingest. For Live passthrough, MK.IO supports **RTMP** and **RTMPS** transport protocols. Additionally, for Live encoding, it is possible to receive streams using the **SRT** protocol. ## Live Outputs In order for content to be presented in a playable rendition, a **Live Output** is required. Live Outputs manage a timeshift buffer (or DVR) that persists to an asset in storage as the content is being streamed. A Live Event on its own will encode video but will not write that video to a permanent location. This is what Live Outputs achieve. You can create multiple outputs for a live event. For example, you can use a 6-hour timeshift buffer for later review and a 3-minute buffer for live playback. You can add or remove live outputs through the portal or API, including while the event is running. A Live Output writes to an Asset, but that Asset is not watchable on its own. To get a playback URL, create a [Streaming Locator](/mkio/understanding/core-concepts/locators) for the output Asset, and make sure a [Streaming Endpoint](/mkio/understanding/core-concepts/endpoints) is `Running`. VOD assets use the same relationship. ## Live event state A live event has a `resourceState`, set by the system:
State Meaning
Stopped The event exists but is not accepting input.
Starting The event is coming online.
Running The event is accepting input and encoding or passing it through.
Stopping The event is shutting down.
Deleting The event is being removed.
A live event's ingest endpoint only accepts a source stream while the event is `Running`. ## See also [Set up a live streaming event](/mkio/how-to/live-streaming/set-up-a-live-streaming-event) Step-by-step guide to creating and starting a live event. [Live streaming workflows](/mkio/getting-started/live-streaming-workflows) End-to-end overview of a live streaming workflow in MK.IO. # Streaming locators A **streaming locator** publishes the files in an asset under a selected streaming policy. The policy controls available protocols, downloads, and encryption, while optional filters can modify the generated manifest. A locator provides the path that a [streaming endpoint](/mkio/understanding/core-concepts/endpoints) uses to deliver an asset or live recording. The final URL pattern for your video will be a concatenation of the Streaming Endpoint domain name and the Streaming Locator that links to your asset. The names you assign to each resource will determine the path URL of your video.

To make video assets available to clients for playback, you must create a Streaming Locator and then build streaming URLs once you have a functional Streaming Endpoint.

By default, a streaming locator is valid immediately and remains valid until it or its asset is deleted. You can set an expiry and other properties to control when and how clients access the content. When creating a Streaming Locator, you must specify an Asset name and a Streaming Policy name. The Streaming Policy can optionally point to a Content Key Policy for encryption. See [Content Keys](/mkio/understanding/core-concepts/content-protection) for more information. A [Streaming Endpoint](/mkio/understanding/core-concepts/endpoints) must exist to play your Streaming Locator and enable you to scale your output based on viewer concurrency.

Streaming Locator Concept

Streaming Locators can have a many-to-one relationship with a Streaming Policy, allowing different Streaming Locators to provide different start times and connection types to different clients while all using the same permission and duration settings. ## Locator state A streaming locator has a `resourceState`, set by the system:
State Meaning
Creating The locator is being provisioned.
Created The locator is provisioned and available for playback (subject to its start/end time and any suppression).
Updating Changes to the locator are being applied.
Deleting The locator is being removed.
Deleted The locator no longer exists.
Error The locator failed to provision or update.
## Streaming formats and encryption modes The following combinations of streaming formats, DRMs, and encryption modes are currently supported in MK.IO:
DRM HLS (CMAF) DASH (CMAF)
ClearKey cbc cbc & cenc
Widevine cenc cenc
PlayReady cenc cenc
FairPlay cbcs-aapl n/a
## Streaming Policies Streaming Policies enable you to define streaming protocols and encryption options for your Streaming Locators. With MK.IO, you get several predefined Streaming Policies out of the gate for trial or production use.
Streaming Policy Description
Predefined_ClearStreamingOnly Clear streaming only
Predefined_ClearKey Enable HLS/DASH encrypted with envelopeEncryption with MK.IO issuing the content key.
Predefined_MultiDrmCencStreaming Enable streaming with DASH encrypted with commonEncryptionCenc with MK.IO issuing the PlayReady and Widevine license
Predefined_MultiDrmStreaming Enable streaming with DASH encrypted with commonEncryptionCenc with MK.IO issuing the PlayReady and Widevine licenses, or for allowing streaming with HLS encrypted with commonEncryptionCbcs with MK.IO issuing the FairPlay license.
Predefined_DownloadOnly Download only
Predefined_DownloadAndClearStreaming Download and clear streaming
You can also create your own Streaming Policies if the predefined policies do not meet your needs. ## Streaming URLs The URLs for streaming content may be obtained either from the UI or by calling the **listPaths** endpoint on the streaming locator API resource. The overall structure of the streaming URL is: `//.ism/manifest()` **The supported options are:** - `format=m3u8-cmaf` for HLS with CMAF segments - `format=mpd-time-cmaf` for DASH with CMAF segments - `filter=...` with a semicolon-separated list of Asset Filters or Account Filters to be applied - `encryption=cbc` for AES-128 encryption scheme (AES CBC full-segment encryption) - `encryption=cbcs-aapl` for CBCS encryption scheme (AES CBC sample-based encryption) - `encryption=cenc` for CENC encryption scheme (AES CTR sample-based encryption) - `start=...` specifying the start of playback in a live event or recording (ISO8601 UTC) - `end=...` specifying the end of playback in a live event or recording (ISO8601 UTC) - `vbegin=...` specifying the start of playback in a VOD asset (ISO8601 duration) - `vend=...` specifying the end of playback in a VOD asset (ISO8601 duration) **For example:** `/fecebb23-46f6-490d-8b70-203e86b0df58/bigbuckbunny.ism/manifest(format=m3u8-cmaf,encryption=cbcs-aapl,filter=myAccountFilter;myAssetFilter)` ## Download URLs The URLs for download content can be obtained either from the UI or by calling **listPaths** on the Streaming Locator resource in the API. Use a download policy when a client needs direct access to files in an asset. Common uses include moving content into an editing or post-production workflow, downloading generated thumbnails or subtitles, and supporting compatible progressive-download clients. The download URL has a simpler structure with no options: `//filename` **For example:** `/fecebb23-46f6-490d-8b70-203e86b0df58/Thumbnail1_000001.png` ## Playback availability window The availability of the Streaming Locator for playback can be constrained to a specific time window using the `startTime` and `endTime` fields in the Streaming Locator resource via the API or the `Expiration time` field in the UI. - If a request is made for the Streaming Locator **before** the start time, the Streaming Endpoint will respond `404 Not Found`. - If a request is made for the Streaming Locator **after** the end time, the Streaming Endpoint will respond `410 Gone`. ## Suppressing a locator A Streaming Locator can be suppressed instead of deleted. A suppressed locator returns `404 Not Found` for every request, the same response as a locator whose start time has not yet been reached. Use this to temporarily pull content from playback without losing the locator's configuration. The Streaming Policy can be configured to return a different status code instead of `404` for this case; ask MediaKind support if you need this. ## See also [Publish content for streaming](/mkio/how-to/content-delivery-publishing/stream-content) Step-by-step guide to creating locators and applying them to assets. [Streaming Endpoints](/mkio/understanding/core-concepts/endpoints) How endpoints serve content to players and CDNs. # Transforms & Jobs Offerings are differentiated based on input type. There are two main input types: **Transforms** (file-based / VOD processing) and **Live Events** (live ingest and processing). ## Transforms **Transforms** are for static (file-based / VOD) content stored in your connected cloud storage (for example, Azure Blob Storage containers or Amazon S3 buckets). For on-demand content, a **Transform** acts as a template for the tasks to be performed, and a **Job** connects a Transform to input content (for example, an Asset or an HTTPS URL) and produces an output **Asset**. A **Transform** is like a recipe. It helps you create the recipe once (Step 1), and submit Jobs using that recipe (Step 2). **You can:** 1. Create a Transform. 2. Submit Jobs under that Transform. 3. List Transforms. 4. Delete a Transform, if you are not planning to use it in the future.

Use Transforms to configure common tasks for processing video or audio files (for example encoding, thumbnail generation, track insertion, asset conversion, or AI processing).

A Transform currently produces one output. Each output has a `preset` that defines the processing to perform, and a `relativePriority` (`High`, `Low`, or `Normal`) that MK.IO uses to order work across multiple Transform outputs. ## Jobs A **Job** is the actual request to apply the Transform to a given input video or audio content. Once the Transform has been created, you can create Jobs in the **Video Processing** page or [using the API](/api-reference/media-api). A Job specifies information such as the location of the input content and the destination for the output. You can specify the input content two ways: - **An existing Asset**, optionally trimmed to a specific `start` and `end` point on the source timeline. - **An HTTPS URL**, including a SAS URL, with an optional base URI that gets concatenated with the file names you provide. Each Job also has a `priority` (`High`, `Low`, or `Normal`, default `Normal`) that determines its place in the processing queue relative to other Jobs, and optional `correlationData`: key/value pairs you provide that are echoed back in the Job's state events, useful for tying a Job back to something in your own system. ## Job state A Job moves through the following states, tracked by the system:
State Meaning
Scheduled The Job has been accepted and is waiting to start.
Queued The Job is queued for processing.
Processing The Job is actively running.
Finished The Job completed and produced its output Asset.
Error The Job failed.
Canceling A cancellation request is being applied.
Canceled The Job was canceled before it finished.
Poll the Job resource or subscribe to webhooks to know when a Job reaches `Finished` or `Error`. The output Asset is not ready to use until then. # Video Processing Re-encode, transform, or enhance your video assets MK.IO’s Video-on-Demand (VOD) encoding allows you to process video files into various formats and bitrates, ensuring optimal playback quality and compatibility across different devices and networks. ## Concepts MK.IO’s video processing is built on two primary components: **Transforms** and **Jobs**. #### Transforms A **Transform** defines the specific processing instructions that will be applied to your media. There are several categories of transforms available: - **[Encoding Transform](/mkio/reference/encoding-transform-presets/encoding-transform)**: Single-bitrate and multi-bitrate transforms that transcode your video into H.264 or H.265 content, with resolutions ranging from SD to 4K. - **[AI pipeline transform](/mkio/understanding/core-concepts/vod-processing/ai-workflows)**: Runs an AI pipeline against your content, covering transcription, translation, and dubbed-audio generation. - **[Asset Conversion Transform](/mkio/reference/encoding-transform-presets/asset-conversion-transform)**: Enables format conversion from various live event or VOD assets into the latest MP4 format supported by MK.IO. - **[Thumbnail generation transform](/mkio/reference/encoding-transform-presets/how-to-generate-thumbnails)**: Generates individual thumbnails, sets of thumbnails, or sprite files for video assets. - **[Track insertion transform](/mkio/reference/encoding-transform-presets/add-a-track-to-a-vod-asset)**: Adds new tracks to a VOD asset and automatically updates the client and server manifests. These are the only transform types available. A Transform's output is limited to one of these preset types per output. #### Jobs A **Job** is the actual request to apply a specific Transform to an input asset. The Job processes the input data and outputs the results to a specified destination asset. See [Transforms & Jobs](/mkio/understanding/core-concepts/transforms-and-jobs) for job states, input types, and priority. # AI workflows MK.IO processing workflows can generate transcription, translation, and dubbed-audio outputs for on-demand media. These workflows use transforms and jobs alongside the assets in your project. ## AI pipelines and models An **AI pipeline** is a collection of operations that MK.IO performs against the content. It identifies the model to run, where to write the generated output, and the arguments required by that workflow, such as a source language or expected phrases. A **model** describes a supported operation, including its input formats, output formats, and configurable arguments. ## Transcription and translation Transcription and translation transforms generate subtitle outputs from an audio track. The transform defines the source language and up to 25 target languages, while a job selects the input content and output asset. - Use [VOD transcription and translation](/mkio/how-to/ai-features/vod-transcription-and-translation-transforms) for the workflow. - Use [Audio speech transcription](/mkio/reference/encoding-transform-presets/audio-speech-transcription) to look up supported locales and transform properties. ## VOD dubbing The VOD dubbing workflow generates alternate-language audio, then uses track insertion transforms to add those files to the encoded video asset. - Use [Multi-language VOD dubbing](/mkio/how-to/ai-features/multi-language-vod-dubbing) for the end-to-end workflow. - If the source asset uses the legacy HSS format, first [convert the asset to MP4v4](/mkio/how-to/ai-features/convert-hss-for-vod-dubbing). - Use [Track insertion transforms](/mkio/reference/encoding-transform-presets/add-a-track-to-a-vod-asset) to look up track insertion behavior. ## API automation The portal guides link to the relevant Media API requests where a workflow requires API configuration. For transform and job operations, also use the [Transforms and jobs API Guide](/mkio/api-guides/how-to/media/transforms-and-jobs) and the [Media API Reference](/api-reference/media-api). - [Organizations, projects and teams](/mkio/understanding/fundamentals/orgsandteams): Understand how organizations, payment methods, projects, teams, roles, and scopes structure MK.IO access. - [Pricing](/mkio/understanding/fundamentals/pricing): Find current MK.IO rates and learn where to review metered usage for your organization. # Organizations, projects and teams Organizations, payment methods, projects, and teams define how MK.IO groups resources, billing, and access. Understand these relationships before you redeem a direct sale, create projects, or assign access. ## Organizations An **organization** is the highest-level MK.IO container. Users, payment methods, and projects are associated with an organization. A user can belong to multiple organizations, but each payment method and project belongs to one organization. ## Payment methods A **payment method** defines how you pay MediaKind for MK.IO services. Payment methods can come from a cloud marketplace or a direct sale, and an organization can have more than one. For example, an organization can use a direct payment method for MK.IO Beam contribution channels and a marketplace payment method for cloud-committed streaming usage. ## Projects A **project** contains media resources such as assets, live events, transforms, and devices. Each project has one assigned payment method and a cloud region for its MK.IO services. Organization administrators can change the payment method assigned to a project within the same organization. ## Teams and access MK.IO uses role-based access control (RBAC) to grant project access through teams. Users can belong to multiple teams, and each team can receive access to one or more projects. Every organization includes two predefined teams: - **Administrators** have full project and organization-level access, including billing visibility. - **Everyone** automatically includes all users. Administrators can set its default project access to User, Reader, or no access. For administration steps, see [Access, users and teams](/mkio/how-to/managing-your-organization/access-users-and-teams). ## Roles, scopes, and rights A **role** is a collection of capabilities. A **scope** identifies the projects, locations, or resources where those capabilities apply. A rights assignment combines a team, role, and scope to grant access. Use the [Users and teams API Guide](/mkio/api-guides/how-to/management/users-and-teams) when you need to inspect or automate the underlying access model. # MK.IO pricing MK.IO meters usage for media processing and delivery resources. Rates can change, so use the current pricing table instead of relying on figures copied into workflow guides. Review the [MK.IO pricing table](https://mediakind.com/mkio/pricing/) for current rates and calculation methods. Cloud-provider storage, networking, and egress charges are billed separately through the provider. ## Actions and usage The following actions do not generate MK.IO usage charges by themselves: - Signing up and creating a subscription. - Connecting storage and importing assets. - Creating a streaming endpoint while leaving it stopped. - Creating streaming locators. - Using and integrating MKPlayer. Usage charges apply when you run services or process and deliver content. Chargeable activity includes running streaming endpoints, live passthrough or encoding events, VOD transcoding, and network delivery. Check the current pricing table before estimating a workload. Use [Billing and usage](/mkio/how-to/managing-your-organization/billing) to review usage by project and manage payment methods for an organization. # MK.IO concepts Learn how MK.IO resources relate before you configure a workflow. Start with the media resource model, then use the focused concept pages when you need more detail. ## Media resources [Media resource model](/mkio/understanding/core-concepts) Follow the resources used to organize, process, protect, and deliver media. [Assets and asset filters](/mkio/understanding/core-concepts/assets) Understand how assets reference cloud storage and how filters modify manifests. [Transforms and jobs](/mkio/understanding/core-concepts/transforms-and-jobs) Understand reusable processing definitions and the jobs that run them. [Live events](/mkio/understanding/core-concepts/live-event) Learn how live inputs, processing modes, outputs, and archives relate. [Streaming endpoints](/mkio/understanding/core-concepts/endpoints) Understand the origin services used to package and deliver content. [Streaming locators](/mkio/understanding/core-concepts/locators) Learn how locators expose assets and apply streaming policies. [Content protection](/mkio/understanding/core-concepts/content-protection) Understand content key policies, encryption, and DRM configuration. ## Platform concepts [Organizations and teams](/mkio/understanding/fundamentals/orgsandteams) Understand organizations, projects, team membership, and project access. [API concepts](/mkio/understanding/core-concepts/api-concepts) Learn the API resource patterns used to automate MK.IO. [Resource states](/mkio/reference/resource-states) Look up resource and provisioning states returned by MK.IO APIs. [Latency](/mkio/understanding/advanced-concepts/latency) Understand latency across live ingest, processing, packaging, and playback. [Edge devices](/mkio/understanding/advanced-concepts/devices) Learn how edge devices connect to MK.IO projects. [Pricing](/mkio/understanding/fundamentals/pricing) Find the pricing model and the resources that contribute to usage. For task-based instructions, use the [MK.IO guides](/mkio/how-to/overview). For automation, use the [API Guides](/mkio/api-guides).