# MediaKind Docs
> Developer documentation for MediaKind products, APIs, and workflows.

Markdown versions are available for each linked documentation page.

<!-- source: /api-guides.md -->

# API Guides

Explore the MediaKind API guides to learn how to integrate MediaKind's services into your workflows.

## Getting Started

Prepare your environment, authenticate your API calls, and learn how the platform represents resources.

- [Quick Start & Authentication](/api-guides/getting-started/authentication): Get your API credentials, authenticate your requests, and make your first API call.

  - [Shared Concepts](/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](/api-guides/how-to/media/vod-pipeline): A complete recipe from upload through encoding and packaging to playout.

- [Storage](/api-guides/how-to/media/storage): Configure input and output storage containers.

  - [Assets](/api-guides/how-to/media/assets): Upload media files and track asset lifecycles.

  - [Transforms & Jobs](/api-guides/how-to/media/transforms-and-jobs): Define transcode settings and submit transcode jobs.

  - [Live Streaming](/api-guides/how-to/media/live-streaming): Configure live events, inputs, outputs, and streaming channels.

  - [Publishing & Delivery](/api-guides/how-to/media/publishing): Create streaming locators and construct playback URLs.

  - [Content Protection](/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](/api-guides/how-to/management/org-provisioning): Bootstrap organizations, structure projects, and define team memberships.

- [Tokens](/api-guides/how-to/management/tokens): Create and rotate personal access tokens.

  - [Webhook Rules](/api-guides/how-to/management/webhooks): Configure HTTP callbacks to receive event-driven notifications.

  - [Usage & Billing](/api-guides/how-to/management/usage-and-billing): Query billing telemetry and track resource consumption.

## 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](/api-guides/how-to/fleets/device-management): Register devices, configure settings, and monitor edge appliance health.

- [Backups & Restores](/api-guides/how-to/fleets/backups-and-restores): Backup device configurations and restore edge states.

  - [Software & Updates](/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](/api-guides/how-to/infrastructure/networks-and-sites): Provision network configuration and link sites.

<!-- source: /api-guides/getting-started.md -->

# 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](/api-guides/getting-started/which-api): Match your workflow to the Media, Management, Fleets, or Infrastructure API.

  - [Authentication and tokens](/api-guides/getting-started/authentication): Create a personal API token and send it with your requests.

  - [Your first API call](/api-guides/getting-started/first-api-call): Make one authenticated request to confirm your token and project access.

<!-- source: /api-guides/getting-started/authentication.md -->

# 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 <YOUR_TOKEN>
```

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/<PROJECT_NAME>/media/assets" \
  -H "Authorization: Bearer <YOUR_TOKEN>" \
  -H "Accept: application/json"
```

Replace `<PROJECT_NAME>` with the project you want to query and `<YOUR_TOKEN>` 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/<PROJECT_NAME>/media/assets
```

## A practical local setup

When you work from the command line, export the values you reuse:

```bash

```

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](/api-guides/how-to/management/tokens) for the Management API workflow.

## Next steps

- [Your first API call](/api-guides/getting-started/first-api-call): confirm that your token and project access work.
- [Tokens](/api-guides/how-to/management/tokens): create, inspect, and revoke tokens through the Management API.
- [Which API to use](/api-guides/getting-started/which-api): choose the API that owns the resources in your workflow.

<!-- source: /api-guides/getting-started/first-api-call.md -->

# 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](/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

```

## 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](/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](/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](/api-guides/getting-started/which-api): choose the API that owns your workflow.
- [API overview](/api-guides/understanding/overview): the patterns shared across the APIs.
- [Build with the Media API](/api-guides/how-to/media): move into storage, assets, transforms, jobs, and publishing.

<!-- source: /api-guides/getting-started/which-api.md -->

# 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 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... |
| :--- | :--- |
| Storage registration, assets, transforms, jobs, live events, streaming locators, streaming endpoints, streaming policies, or content key policies | [Media API](/api-reference/media-api) |
| Organizations, projects, users, teams, tokens, payment methods, usage reports, metrics, or webhook rules | [Management API](/api-reference/management-api) |
| Beam device registration, backups, restores, software rollouts, or support packages | [Fleets API](/api-reference/fleets-api) |
| Networks and sites for Beam deployments | [Infrastructure API](/api-reference/infrastructure-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.
4. Use the **Infrastructure API** to define sites and networks for a Beam deployment.
5. Use the **Fleets API** to onboard and operate the Beam devices in those sites.

A complete platform integration typically uses the Management API for setup, then the Media, Fleets, or Infrastructure 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.

## 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.

## Fleets API

The Fleets API is the project-scoped operational API for MK.IO Beam, the on-premises product. Reach for it to register devices, protect device state with backups, restore configurations, manage software versions, and collect support packages. Its resources include device inventory and registration, backups and restores, software selection and preload behaviour, and support packages and diagnostics.

## Infrastructure API

The Infrastructure API defines where Beam devices live and which networks are available to them, so it is usually used before or alongside the Fleets API. Its resources include networks, sites, routes from sites to networks, and label-driven filtering of network and site resources.

## Common combinations

| Workflow | APIs involved |
| :--- | :--- |
| 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 |
| Define sites and networks, then register Beam devices to them | Infrastructure API, then Fleets 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](/api-guides/getting-started/first-api-call) is the quickest way to confirm that your base URL, token, and project access are correct.

<!-- source: /api-guides/how-to.md -->

# API workflow guides

Choose a workflow area to find task-focused guides for building with the MK.IO APIs.

- [Media API](/api-guides/how-to/media): Build VOD, live, publishing, storage, and content-protection workflows.

  - [Management API](/api-guides/how-to/management): Provision projects, manage access, issue tokens, configure webhooks, and report usage.

  - [Fleets API](/api-guides/how-to/fleets): Register Beam devices, manage software, protect configurations, and collect diagnostics.

  - [Infrastructure API](/api-guides/how-to/infrastructure): Create networks and sites for Beam device operations.

<!-- source: /api-guides/how-to/channels.md -->

# 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.

> **warning:** 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>/ui/connectors/channels-api/latest` |
| Scope | A single Beam device |
| Authentication | None beyond network access to the device |
| Reference | [Channels API reference](/api-reference/channels-api) |

The base URL is the device itself, not `api.mk.io`. Every other MK.IO API is project-scoped and bearer authenticated, so if you already integrate with the Media or Fleets API, treat this as a separate integration. See [Connect to a Beam device](/api-guides/how-to/channels/connect-to-a-device) for how to build the address and connect to your Beam device.

## 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

<!-- non-renderable component stripped: WorkflowCards -->

## Guides

- [How Beam channels work](/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](/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](/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](/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](/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.

<!-- source: /api-guides/how-to/channels/connect-to-a-device.md -->

# Connect to a Beam device

The Channels API is served by the Beam device, so there is no central endpoint and no token exchange. You address the device directly, on the same host and port you already use to reach its web interface.

## Build the base URL

Take the address you use for the device web interface and append the API path:

```text
<DEVICE_ADDRESS>/ui/connectors/channels-api/latest
```

`<DEVICE_ADDRESS>` is the scheme, host, and port of the device, for example `http://10.0.0.10:8080`. Whether you need a port, and which one, depends on how the device is deployed and secured. [Connect to the Controller](/beam/web-interface/connection) lists the access URL forms, including the ports used for containerized solutions and for HTTPS.

A full request URL therefore looks like this:

```bash
curl http://10.0.0.10:8080/ui/connectors/channels-api/latest/channels/
```

## Try it on the device first

The device serves an interactive Swagger page for its own build of the API. Open it in a browser at:

```text
<DEVICE_ADDRESS>/ui/connectors/channels-api/latest/docs/
```

This is the fastest way to see the endpoints, and you can execute requests against the device from the page itself. Use it to confirm connectivity before you write any integration code. The [Channels API reference](/api-reference/channels-api) documents the same API on this site, so use whichever suits you.

## Authentication

There is currently no authentication on the Channels API beyond network access to the device. Any client that can reach the device address can read and change its channels.

> **warning:** Treat network access as the only control you have. Keep Beam devices on a management network that is not reachable from untrusted clients, and do not expose the device address publicly.

## 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 <DEVICE_ADDRESS>/ui/connectors/channels-api/latest/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 also confirms your base URL is correct, which makes it a useful first call.

## 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 /deployment/eligibility/` reports whether the API can take over the device:

```bash
curl <DEVICE_ADDRESS>/ui/connectors/channels-api/latest/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.

## 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](/api-guides/how-to/channels/manage-channels).

<!-- source: /api-guides/how-to/channels/how-channels-work.md -->

# 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 /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 /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. |
| `FieldError` | One or more fields could not be applied. |

`status.syncError` is a list of strings that carries the detail behind the failure states. Poll `GET /channels/{channel_id}/` after any write and treat `syncState` as the real result of your request, not the status code.

## 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](/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`.

<!-- source: /api-guides/how-to/channels/import-and-export.md -->

# 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](/api-guides/how-to/channels/manage-channels).

## Export a configuration

`POST /export/` takes a body, even when you want everything. Omit `channels` to export every channel on the device:

```bash
curl -X POST <BASE_URL>/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 <BASE_URL>/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 <BASE_URL>/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 /import/` takes an `ExportPayload` under `payload`, along with the import mode. Send the payload you saved from the export step:

```bash
curl -X POST <BASE_URL>/import/ \
  -H "Content-Type: application/json" \
  -d '{
    "payload": <EXPORT_PAYLOAD>,
    "mode": "merge"
  }'
```

`<EXPORT_PAYLOAD>` 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. |

> **warning:** `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 /channels/{channel_id}/` for each imported channel and read `status.syncState` to see how it finished. See [How Beam channels work](/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 /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.

<!-- source: /api-guides/how-to/channels/manage-channels.md -->

# Create and manage channels

Channels are created with `PUT /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](/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 <BASE_URL>/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": []
}
```

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, different port counts, and different groups, 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.

Read the groups you need by key and ignore the rest, rather than assuming a fixed set. The groups a device returns can differ from the ones documented 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 <BASE_URL>/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 <BASE_URL>/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 <BASE_URL>/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 join the multicast group on. Set `unicast` to `true` if the source is a unicast stream.

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>"
  }
}
```

`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 /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 <BASE_URL>/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 <BASE_URL>/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 <BASE_URL>/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](/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.

<!-- source: /api-guides/how-to/channels/monitor-channels.md -->

# 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 <BASE_URL>/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 note that it comes back as a relative path with the `$` characters percent-encoded.

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 <BASE_URL>/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 <BASE_URL>/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](/api-guides/how-to/channels/how-channels-work) for the values.

## 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 <BASE_URL>/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": "<ALARM_ID>",
        "name": "<ALARM_NAME>",
        "displayName": "<ALARM_DISPLAY_NAME>",
        "objectId": "<OBJECT_ID>",
        "channelName": "news-contribution",
        "created": "2026-07-01T09:31:12Z"
      },
      "status": {
        "severity": "Critical",
        "additionalInfo": "<DETAIL>"
      }
    }
  ],
  "supplemental": {
    "kind": "AlarmList",
    "count": 1,
    "operation": "list",
    "pagination": { "start": 0, "end": 1, "records": 1, "total": 1 }
  }
}
```

`<ALARM_ID>` is a UUID, and `<ALARM_NAME>` is the device's machine name for the fault, with `<ALARM_DISPLAY_NAME>` its readable form. `<OBJECT_ID>` identifies the part of the channel that raised it. `<DETAIL>` 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 <BASE_URL>/channels/<CHANNEL_NAME>/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 `<!-- non-renderable component stripped: image -->` tag straight at it.

## Query device metrics

For a point-in-time reading of the device itself:

```bash
curl <BASE_URL>/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 <BASE_URL>/metrics/current/ \
  --data-urlencode "\$select=cpuUtilizationPercent,temperatureCelsius"
```

For a history rather than a snapshot, `GET /metrics/cpu/` and `GET /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 <BASE_URL>/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 /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.

<!-- source: /api-guides/how-to/fleets.md -->

# 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](/api-reference/fleets-api) |

## 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

<!-- non-renderable component stripped: WorkflowCards -->

## Guides

- [Manage devices](/api-guides/how-to/fleets/device-management): Register devices, inspect state, and work through the core day-to-day operations.

- [Backups and restores](/api-guides/how-to/fleets/backups-and-restores): Create backups before changes, inspect stored backup metadata, and restore safely.

- [Software and updates](/api-guides/how-to/fleets/software-and-updates): Control desired and preloaded software versions and collect support packages for diagnostics.

<!-- source: /api-guides/how-to/fleets/backups-and-restores.md -->

# 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/<PROJECT_NAME>/fleet/devices/my-device/backup" \
  -H "Authorization: Bearer <YOUR_TOKEN>" \
  -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/<PROJECT_NAME>/fleet/backups" \
  -H "Authorization: Bearer <YOUR_TOKEN>"

curl -X GET "https://app.mk.io/api/v1/projects/<PROJECT_NAME>/fleet/backups/<BACKUP_ID>" \
  -H "Authorization: Bearer <YOUR_TOKEN>"
```

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/<PROJECT_NAME>/fleet/devices/my-device/restore" \
  -H "Authorization: Bearer <YOUR_TOKEN>" \
  -H "Content-Type: application/json" \
  -d '{
    "metadata": { "displayName": "Restore pre-update snapshot" },
    "spec": {
      "restoreFilePath": "my-device/<BACKUP_ID>/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/<PROJECT_NAME>/fleet/uploadBackup" \
  -H "Authorization: Bearer <YOUR_TOKEN>" \
  -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](/api-guides/how-to/fleets/software-and-updates): take a backup before changing software state.
- [Manage devices](/api-guides/how-to/fleets/device-management): return to the device once protection is in place.

<!-- source: /api-guides/how-to/fleets/device-management.md -->

# 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/<PROJECT_NAME>/fleet/devices/beam-encoder-01" \
  -H "Authorization: Bearer <YOUR_TOKEN>" \
  -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](/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/<PROJECT_NAME>/fleet/devices/beam-encoder-01" \
  -H "Authorization: Bearer <YOUR_TOKEN>"
```

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/<PROJECT_NAME>/fleet/devices/beam-encoder-01" \
  -H "Authorization: Bearer <YOUR_TOKEN>" \
  -H "Content-Type: application/json" \
  -d '{ "spec": { "autoPreloadLatestSoftware": true } }'
```

The software-related fields (`desiredSoftwareVersion`, `preloadSoftwareVersion`, `autoPreloadLatestSoftware`) are covered in [Software and updates](/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/<PROJECT_NAME>/fleet/devices/beam-encoder-01" \
  -H "Authorization: Bearer <YOUR_TOKEN>"
```

## What comes next

- [Backups and restores](/api-guides/how-to/fleets/backups-and-restores): protect device state before major changes.
- [Software and updates](/api-guides/how-to/fleets/software-and-updates): control desired and preloaded software versions.

<!-- source: /api-guides/how-to/fleets/software-and-updates.md -->

# 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/<PROJECT_NAME>/fleet/devices/my-device/software" \
  -H "Authorization: Bearer <YOUR_TOKEN>"
```

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/<PROJECT_NAME>/fleet/devices/my-device" \
  -H "Authorization: Bearer <YOUR_TOKEN>" \
  -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/<PROJECT_NAME>/fleet/devices/my-device/supportPackages" \
  -H "Authorization: Bearer <YOUR_TOKEN>"
```

```bash
curl -X POST "https://app.mk.io/api/v1/projects/<PROJECT_NAME>/fleet/devices/my-device/supportPackages" \
  -H "Authorization: Bearer <YOUR_TOKEN>" \
  -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/<PROJECT_NAME>/fleet/devices/my-device/removeServices" \
  -H "Authorization: Bearer <YOUR_TOKEN>" \
  -H "Content-Type: application/json" \
  -d '{
    "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](/api-guides/how-to/fleets/backups-and-restores): create the rollback point before a software change.
- [Manage devices](/api-guides/how-to/fleets/device-management): return to the device resource and its site and network settings.

<!-- source: /api-guides/how-to/infrastructure.md -->

# 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](/api-reference/infrastructure-api) |

## 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

<!-- non-renderable component stripped: WorkflowCards -->

## Guide

- [Set up networks and sites](/api-guides/how-to/infrastructure/networks-and-sites): Follow the recommended order for creating and maintaining infrastructure resources.

<!-- source: /api-guides/how-to/infrastructure/networks-and-sites.md -->

# 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](/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/<PROJECT_NAME>/infra/networks/production-network" \
  -H "Authorization: Bearer <YOUR_TOKEN>" \
  -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/<PROJECT_NAME>/infra/sites/headquarters" \
  -H "Authorization: Bearer <YOUR_TOKEN>" \
  -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/<PROJECT_NAME>/infra/sites/headquarters" \
  -H "Authorization: Bearer <YOUR_TOKEN>" \
  -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](/api-guides/how-to/fleets/device-management): register Beam devices against the sites you created.

<!-- source: /api-guides/how-to/management.md -->

# 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](/api-reference/management-api) |

## 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

<!-- non-renderable component stripped: WorkflowCards -->

## Guides

- [Users and teams](/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](/api-guides/how-to/management/tokens): Create full-access or restricted tokens, inspect token metadata, and revoke user or organization tokens.

- [Organizations and invites](/api-guides/how-to/management/organizations-and-invites): Inspect accessible organizations, accept pending invitations, and leave or decline organization access cleanly.

- [Webhook rules](/api-guides/how-to/management/webhooks): Register webhook destinations, choose events, and inspect event delivery status for each rule.

- [Usage and billing](/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](/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.

<!-- source: /api-guides/how-to/management/org-provisioning.md -->

# 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 <YOUR_TOKEN>"
```

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 <YOUR_TOKEN>" \
  -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 <YOUR_TOKEN>"
```

If the chosen method requires terms acceptance, accept them before assigning it:

```bash
curl -X POST "https://app.mk.io/api/v1/organization/paymentMethods/<PAYMENT_METHOD_ID>/acceptTermsAndConditions" \
  -H "Authorization: Bearer <YOUR_TOKEN>"
```

## 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 <YOUR_TOKEN>" \
  -H "Content-Type: application/json" \
  -d '{
    "displayName": "Production Media",
    "locationName": "westeurope",
    "paymentMethodId": "<PAYMENT_METHOD_ID>"
  }'
```

Assigning a payment method also activates the project. You can read or replace the assignment later through `/projects/<PROJECT_NAME>/paymentMethod`; see [Usage and billing](/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 <YOUR_TOKEN>"

curl -X GET "https://app.mk.io/api/v1/organization/roles" \
  -H "Authorization: Bearer <YOUR_TOKEN>"

curl -X GET "https://app.mk.io/api/v1/organization/scopes" \
  -H "Authorization: Bearer <YOUR_TOKEN>"
```

Then create a team that grants roles under a scope. See [Users and teams](/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 <YOUR_TOKEN>" \
  -H "Content-Type: application/json" \
  -d '{
    "spec": {
      "description": "Team for day-to-day project operations",
      "members": {},
      "scopes": {
        "<SCOPE_NAME>": { "roles": ["<ROLE_NAME>"] }
      }
    }
  }'
```

## 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](/api-guides/how-to/management/tokens).

```bash
curl -X POST "https://app.mk.io/api/v1/user/tokens" \
  -H "Authorization: Bearer <YOUR_TOKEN>" \
  -H "Content-Type: application/json" \
  -d '{
    "type": "restricted",
    "description": "Project automation token",
    "organizationId": "<ORG_ID>",
    "permissions": {}
  }'
```

## Step 6: Add webhook rules early

If the project will run jobs or live workflows, add [webhook rules](/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](/api-guides/how-to/management/users-and-teams): roles, scopes, and JSON Patch in detail.
- [Tokens](/api-guides/how-to/management/tokens): choose token types and inspect token metadata.
- [Build with the Media API](/api-guides/how-to/media): move from setup into media workflows.

<!-- source: /api-guides/how-to/management/organizations-and-invites.md -->

# 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 <YOUR_TOKEN>" \
  -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 <YOUR_TOKEN>"

curl -X DELETE "https://app.mk.io/api/v1/organization/invites/<INVITE_ID>" \
  -H "Authorization: Bearer <YOUR_TOKEN>"
```

## 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 <YOUR_TOKEN>"
```

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/<ORGANIZATION_ID>" \
  -H "Authorization: Bearer <YOUR_TOKEN>" \
  -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/<ORGANIZATION_ID>" \
  -H "Authorization: Bearer <YOUR_TOKEN>"
```

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](/api-guides/how-to/management/users-and-teams): the team, role, and scope model new members are granted access through.
- [Provision org and users](/api-guides/how-to/management/org-provisioning): the full setup sequence from organization to access.

<!-- source: /api-guides/how-to/management/tokens.md -->

# 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 <YOUR_TOKEN>" \
  -H "Content-Type: application/json" \
  -d '{
    "type": "full-access",
    "description": "CI deployment token",
    "organizationId": "<ORG_ID>",
    "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 <YOUR_TOKEN>"
```

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 <YOUR_TOKEN>" \
  -H "Content-Type: application/json" \
  -d '{
    "type": "restricted",
    "description": "Asset automation, one project",
    "organizationId": "<ORG_ID>",
    "expireDate": "2027-01-01T00:00:00Z",
    "permissions": {
      "core.project": {
        "<PROJECT_ID>": {
          "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 <YOUR_TOKEN>"
```

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/<TOKEN_ID>" \
  -H "Authorization: Bearer <YOUR_TOKEN>"
```

```bash
curl -X DELETE "https://app.mk.io/api/v1/user/tokens" \
  -H "Authorization: Bearer <YOUR_TOKEN>"
```

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 <YOUR_TOKEN>"

curl -X DELETE "https://app.mk.io/api/v1/organization/tokens/<TOKEN_ID>" \
  -H "Authorization: Bearer <YOUR_TOKEN>"
```

## 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](/api-guides/how-to/management/users-and-teams): the access model a token's permissions draw from.
- [Authentication and tokens](/api-guides/getting-started/authentication): bearer-auth basics and UI-based personal token creation.

<!-- source: /api-guides/how-to/management/usage-and-billing.md -->

# 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/<PROJECT_NAME>/usage" \
  -H "Authorization: Bearer <YOUR_TOKEN>"
```

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 <YOUR_TOKEN>" \
  -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 <YOUR_TOKEN>" \
  -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 <YOUR_TOKEN>"

curl -X GET "https://app.mk.io/api/v1/organization/paymentMethods/<PAYMENT_METHOD_ID>/rateCard" \
  -H "Authorization: Bearer <YOUR_TOKEN>"
```

Read or replace the method assigned to a project:

```bash
curl -X GET "https://app.mk.io/api/v1/projects/<PROJECT_NAME>/paymentMethod" \
  -H "Authorization: Bearer <YOUR_TOKEN>"

curl -X POST "https://app.mk.io/api/v1/projects/<PROJECT_NAME>/paymentMethod" \
  -H "Authorization: Bearer <YOUR_TOKEN>" \
  -H "Content-Type: application/json" \
  -d '{ "paymentMethodId": "<PAYMENT_METHOD_ID>" }'
```

## Enable metrics export

Turn on the project metrics endpoint with a `PATCH`. When enabled, the read response returns the connection details (`url`, `username`, `password`) for scraping metrics.

```bash
curl -X PATCH "https://app.mk.io/api/v1/projects/<PROJECT_NAME>/metricsEndpoint" \
  -H "Authorization: Bearer <YOUR_TOKEN>" \
  -H "Content-Type: application/json" \
  -d '{ "spec": { "enabled": true } }'
```

## 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](/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.

<!-- source: /api-guides/how-to/management/users-and-teams.md -->

# 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 <YOUR_TOKEN>"
```

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 <YOUR_TOKEN>"

curl -X GET "https://app.mk.io/api/v1/organization/scopes" \
  -H "Authorization: Bearer <YOUR_TOKEN>"
```

## 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 <YOUR_TOKEN>" \
  -H "Content-Type: application/json" \
  -d '{
    "spec": {
      "description": "Team for media workflow operations",
      "members": {
        "<USER_ID>": { "isTeamAdmin": true }
      },
      "scopes": {
        "<SCOPE_NAME>": { "roles": ["<ROLE_NAME>"] }
      }
    }
  }'
```

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 <YOUR_TOKEN>" \
  -H "Content-Type: application/json" \
  -d '[
    { "op": "add", "path": "/spec/members/<USER_ID>", "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 <YOUR_TOKEN>" \
  -H "Content-Type: application/json" \
  -d '[
    { "op": "add", "path": "/spec/scopes/<SCOPE_NAME>/roles/-", "value": "<ROLE_NAME>" }
  ]'
```

Remove a member:

```bash
curl -X PATCH "https://app.mk.io/api/v1/organization/teams/video-engineering" \
  -H "Authorization: Bearer <YOUR_TOKEN>" \
  -H "Content-Type: application/json" \
  -d '[
    { "op": "remove", "path": "/spec/members/<USER_ID>" }
  ]'
```

The same `op` values (`add`, `replace`, `remove`) work for scopes and roles. Use `replace` on `/spec/members/<USER_ID>/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 <YOUR_TOKEN>"
```

## 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](/api-guides/how-to/management/tokens).

## What comes next

- [Organizations and invites](/api-guides/how-to/management/organizations-and-invites): the invitation lifecycle for adding new users.
- [Tokens](/api-guides/how-to/management/tokens): create restricted automation tokens against this access model.

<!-- source: /api-guides/how-to/management/webhooks.md -->

# 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](/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/<PROJECT_NAME>/webhook/rules/job-notifications" \
  -H "Authorization: Bearer <YOUR_TOKEN>" \
  -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": "<SHARED_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/<PROJECT_NAME>/webhook/rules" \
  -H "Authorization: Bearer <YOUR_TOKEN>"

curl -X GET "https://app.mk.io/api/v1/projects/<PROJECT_NAME>/webhook/rules/job-notifications" \
  -H "Authorization: Bearer <YOUR_TOKEN>"
```

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/<PROJECT_NAME>/webhook/rules/job-notifications/events" \
  -H "Authorization: Bearer <YOUR_TOKEN>"
```

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/<PROJECT_NAME>/webhook/rules/job-notifications" \
  -H "Authorization: Bearer <YOUR_TOKEN>"
```

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](/api-guides/understanding/webhooks).

## What comes next

- [Webhooks](/api-guides/understanding/webhooks): the payload model, supported events, and handler design.
- [Transforms and jobs](/api-guides/how-to/media/transforms-and-jobs): pair job workflows with completion events.

<!-- source: /api-guides/how-to/media.md -->

# 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](/api-reference/media-api) |

## 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.

## Common workflow patterns

<!-- non-renderable component stripped: WorkflowCards -->

## Guides

- [Storage](/api-guides/how-to/media/storage): Register Azure, AWS, or Google storage and manage the credentials MK.IO uses to access it.

- [Assets](/api-guides/how-to/media/assets): Create assets, inspect tracks, request file access information, organize content with labels, and apply filters.

- [Download asset files](/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](/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](/api-guides/how-to/media/transforms-and-jobs): Define reusable processing profiles and run them against assets.

- [Live streaming](/api-guides/how-to/media/live-streaming): Create live events, connect encoders, archive with live outputs, and publish live playback.

- [Streaming and publishing](/api-guides/how-to/media/publishing): Create streaming endpoints, locators, and policies, then retrieve playback URLs.

- [Content protection](/api-guides/how-to/media/content-protection): Add DRM and key-delivery configuration to published assets.

## Workflow guide

- [Automate a VOD pipeline](/api-guides/how-to/media/vod-pipeline): Follow an end-to-end flow from source asset through transform job to published playback.

<!-- source: /api-guides/how-to/media/assets.md -->

# 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/<PROJECT_NAME>/media/assets/source-video" \
  -H "Authorization: Bearer <YOUR_TOKEN>" \
  -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/<PROJECT_NAME>/media/assets/source-video" \
  -H "Authorization: Bearer <YOUR_TOKEN>"
```

When you only need readiness in a polling loop, read the lightweight state endpoint instead of the full object. See [Resource states](/api-guides/understanding/resource-states) for the asset state values.

```bash
curl -X GET "https://app.mk.io/api/v1/projects/<PROJECT_NAME>/media/assets/source-video/state" \
  -H "Authorization: Bearer <YOUR_TOKEN>"
```

## 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/<PROJECT_NAME>/media/assets/source-video/storage/" \
  -H "Authorization: Bearer <YOUR_TOKEN>"
```

Request the information needed to read files directly from the underlying storage:

```bash
curl -X POST "https://app.mk.io/api/v1/projects/<PROJECT_NAME>/media/assets/source-video/getFileAccessInfo" \
  -H "Authorization: Bearer <YOUR_TOKEN>"
```

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](/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/<PROJECT_NAME>/media/assets?\$label=series=my-show" \
  -H "Authorization: Bearer <YOUR_TOKEN>"
```

Or require the presence of several keys at once:

```bash
curl -X GET "https://app.mk.io/api/v1/projects/<PROJECT_NAME>/media/assets?\$label_key=series&\$label_key=region" \
  -H "Authorization: Bearer <YOUR_TOKEN>"
```

The asset list also supports `$top`, `$skiptoken`, `$orderby`, and `$filter`. See [Pagination and filtering](/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/<PROJECT_NAME>/media/assets/source-video/listStreamingLocators" \
  -H "Authorization: Bearer <YOUR_TOKEN>"
```

## 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.
- **`getFileAccessInfo` fails after a credential expires.** The most common cause is an expired storage credential. Rotate it first; see [Storage](/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/<PROJECT_NAME>/media/assets/source-video" \
  -H "Authorization: Bearer <YOUR_TOKEN>"
```

## What comes next

- [Transforms and jobs](/api-guides/how-to/media/transforms-and-jobs): process assets through reusable transforms.
- [Playback filters](/api-guides/how-to/media/playback-filters): publish a shaped subset of an asset.
- [Streaming and publishing](/api-guides/how-to/media/publishing): publish assets for playback.

<!-- source: /api-guides/how-to/media/content-protection.md -->

# 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 `<PROJECT_NAME>` and the verification key with your own values.

```bash
curl -X PUT "https://app.mk.io/api/v1/projects/<PROJECT_NAME>/media/contentKeyPolicies/multi-drm-policy" \
  -H "Authorization: Bearer <YOUR_TOKEN>" \
  -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": "<BASE64_HMAC_SECRET>"
            }
          }
        },
        {
          "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": "<BASE64_HMAC_SECRET>"
            }
          }
        }
      ]
    }
  }'
```

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 certificate (`fairPlayPfx`), its password (`fairPlayPfxPassword`), and an application secret key (`ask`), all Base64-encoded. 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/<PROJECT_NAME>/media/streamingLocators/protected-locator" \
  -H "Authorization: Bearer <YOUR_TOKEN>" \
  -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/<PROJECT_NAME>/media/contentKeyPolicies" \
  -H "Authorization: Bearer <YOUR_TOKEN>"
```

Retrieve a single policy:

```bash
curl -X GET "https://app.mk.io/api/v1/projects/<PROJECT_NAME>/media/contentKeyPolicies/multi-drm-policy" \
  -H "Authorization: Bearer <YOUR_TOKEN>"
```

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/<PROJECT_NAME>/media/contentKeyPolicies/multi-drm-policy/getPolicyPropertiesWithSecrets" \
  -H "Authorization: Bearer <YOUR_TOKEN>"
```

## 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](/api-guides/how-to/media/publishing): connect the policy to locators and live playback.

<!-- source: /api-guides/how-to/media/download-asset-files.md -->

# Download asset files

MK.IO does not proxy file transfers. To read a file from an asset, you call `getFileAccessInfo` to get access details for the asset's underlying cloud storage, then talk to Azure Blob Storage or AWS S3 directly. Uploads work the same way: you write to your own storage, because there is no upload endpoint on the asset.

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/<PROJECT_NAME>/media/assets/<ASSET_NAME>/getFileAccessInfo" \
  -H "Authorization: Bearer <YOUR_TOKEN>"
```

The response carries everything needed to reach the storage directly:

```json
{
  "storageAccountName": "mystorageaccount",
  "containerName": "mycontainer",
  "jwt": "<access_token>",
  "url": "<container_url>",
  "subPath": "incoming"
}
```

| Field | Description |
| :--- | :--- |
| `url` | Base URL of the storage container. |
| `jwt` | Token to authenticate the follow-up request. |
| `storageAccountName` | The registered storage account or S3 bucket name. |
| `containerName` | The container or bucket holding the asset files. |
| `subPath` | Optional path prefix. Include it when building the file path. |

## 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

Use the returned `url` as the base, append the file path, and pass the `jwt` as the bearer token:

```bash
curl -X GET "<url>/<subPath>/<fileName>" \
  -H "Authorization: Bearer <jwt>" \
  --output <fileName>
```

This follows the standard [Azure Blob Storage Get Blob](https://learn.microsoft.com/en-us/rest/api/storageservices/get-blob) pattern for Azure-backed assets.

For S3-backed assets, inspect the returned `url`. If it is a presigned URL (it contains query parameters such as `X-Amz-Signature`), the auth is embedded and you do not pass a separate token:

```bash
curl -X GET "<url>" --output <fileName>
```

If it is a plain bucket URL, pass the `jwt` as the bearer token as in the Azure example.

## Upload files

There is no MK.IO endpoint for uploading into an asset container, and `getFileAccessInfo` returns read-scoped access intended for download. To upload, write directly to your cloud storage with the credentials on your registered storage instance:

- **Azure**: use the [Put Blob REST API](https://learn.microsoft.com/en-us/rest/api/storageservices/put-blob) or the Azure Storage SDK with the SAS token configured on the storage instance.
- **AWS S3**: use the [PutObject API](https://docs.aws.amazon.com/AmazonS3/latest/API/API_PutObject.html) or the AWS SDK with the credentials configured on the storage instance.

## What goes wrong

- **`getFileAccessInfo` fails.** The most common cause is an expired storage credential. Rotate it; see [Storage](/api-guides/how-to/media/storage).
- **Using the access token to upload.** The returned access is read-scoped. Use your own storage credentials for writes.

## What comes next

- [Assets](/api-guides/how-to/media/assets): manage the assets these files belong to.
- [Storage](/api-guides/how-to/media/storage): rotate credentials if access stops working.

<!-- source: /api-guides/how-to/media/live-streaming.md -->

# 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.

## 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/<PROJECT_NAME>/media/liveEvents/main-stage" \
  -H "Authorization: Bearer <YOUR_TOKEN>" \
  -H "Content-Type: application/json" \
  -d '{
    "tags": {},
    "properties": {
      "useStaticHostname": false,
      "streamOptions": ["Default"],
      "encoding": {
        "encodingType": "PassthroughBasic"
      },
      "input": {
        "streamingProtocol": "RTMP",
        "accessControl": { "ip": { "allow": [] } },
        "accessToken": "<INGEST_ACCESS_TOKEN>",
        "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/<PROJECT_NAME>/media/liveEvents/main-stage/start" \
  -H "Authorization: Bearer <YOUR_TOKEN>"
```

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/<PROJECT_NAME>/media/liveEvents/main-stage" \
  -H "Authorization: Bearer <YOUR_TOKEN>"
```

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/<PROJECT_NAME>/media/liveEvents/main-stage/liveOutputs/main-archive" \
  -H "Authorization: Bearer <YOUR_TOKEN>" \
  -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/<PROJECT_NAME>/media/streamingLocators/main-stage-live" \
  -H "Authorization: Bearer <YOUR_TOKEN>" \
  -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](/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/<PROJECT_NAME>/media/liveEvents/main-stage/stop" \
  -H "Authorization: Bearer <YOUR_TOKEN>"
```

`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/<PROJECT_NAME>/media/liveEvents/main-stage/liveOutputs/main-archive" \
  -H "Authorization: Bearer <YOUR_TOKEN>"

curl -X DELETE "https://app.mk.io/api/v1/projects/<PROJECT_NAME>/media/liveEvents/main-stage" \
  -H "Authorization: Bearer <YOUR_TOKEN>"
```

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. Stop both when the broadcast ends, and delete assets you no longer need.
- **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](/api-guides/how-to/media/publishing): locators, policies, endpoints, and playback URLs.
- [Webhooks](/api-guides/understanding/webhooks): react to `MediaKind.ChannelInstanceStarted`, `ChannelInstanceStopped`, and `ChannelInstanceError` without polling.

<!-- source: /api-guides/how-to/media/playback-filters.md -->

# 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/<PROJECT_NAME>/media/assets/source-video/assetFilters/highlights" \
  -H "Authorization: Bearer <YOUR_TOKEN>" \
  -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/<PROJECT_NAME>/media/accountFilters/non-english-mid-bitrate" \
  -H "Authorization: Bearer <YOUR_TOKEN>" \
  -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/<PROJECT_NAME>/media/accountFilters/high-start-quality" \
  -H "Authorization: Bearer <YOUR_TOKEN>" \
  -H "Content-Type: application/json" \
  -d '{
    "properties": {
      "firstQuality": { "bitrate": 5000000 }
    }
  }'
```

## Apply the filter

A filter does nothing until a streaming locator references it by name in the `filters` list. The list accepts both asset and account filters.

```bash
curl -X PUT "https://app.mk.io/api/v1/projects/<PROJECT_NAME>/media/streamingLocators/highlights-locator" \
  -H "Authorization: Bearer <YOUR_TOKEN>" \
  -H "Content-Type: application/json" \
  -d '{
    "properties": {
      "assetName": "source-video",
      "streamingPolicyName": "Predefined_ClearStreamingOnly",
      "filters": ["highlights"]
    }
  }'
```

## What goes wrong

- **The filter has no effect.** A filter only applies when a locator lists it in `filters`. Creating the filter alone changes nothing.
- **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/<PROJECT_NAME>/media/assets/source-video/assetFilters/highlights" \
  -H "Authorization: Bearer <YOUR_TOKEN>"
```

## What comes next

- [Streaming and publishing](/api-guides/how-to/media/publishing): apply filters at publication time.
- [Assets](/api-guides/how-to/media/assets): use an asset filter when the rule belongs to one asset.

<!-- source: /api-guides/how-to/media/publishing.md -->

# 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/<PROJECT_NAME>/media/streamingEndpoints/default" \
  -H "Authorization: Bearer <YOUR_TOKEN>" \
  -H "Content-Type: application/json" \
  -d '{
    "location": "<PROJECT_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/<PROJECT_NAME>/media/streamingEndpoints/default/start" \
  -H "Authorization: Bearer <YOUR_TOKEN>"

curl -X GET "https://app.mk.io/api/v1/projects/<PROJECT_NAME>/media/streamingEndpoints/default/state" \
  -H "Authorization: Bearer <YOUR_TOKEN>"
```

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.

## 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/<PROJECT_NAME>/media/streamingLocators/my-locator" \
  -H "Authorization: Bearer <YOUR_TOKEN>" \
  -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](/api-guides/how-to/media/playback-filters), `defaultContentKeyPolicyName` for [content protection](/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](/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/<PROJECT_NAME>/media/streamingLocators/my-locator/listPaths" \
  -H "Authorization: Bearer <YOUR_TOKEN>"
```

The response groups paths by protocol and encryption under `streamingPaths`, and lists any `downloadPaths`. A playback URL is the endpoint hostname (plus `cdnBasePath` if CDN is enabled) followed by a path:

```text
https://<hostName><cdnBasePath><path_from_listPaths>
```

The manifest path takes format and encryption options in parentheses. For example, an HLS manifest with Apple sample encryption and two filters applied:

```text
https://<hostName>/<streamingLocatorId>/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.

## 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](/api-guides/how-to/media/content-protection).

## What comes next

- [Content protection](/api-guides/how-to/media/content-protection): add DRM and key delivery.
- [Automate a VOD pipeline](/api-guides/how-to/media/vod-pipeline): see publishing in an end-to-end workflow.

<!-- source: /api-guides/how-to/media/storage.md -->

# 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/<PROJECT_NAME>/media/storage/primary-azure" \
  -H "Authorization: Bearer <YOUR_TOKEN>" \
  -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=<REDACTED>"
      }
    }
  }'
```

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/<PROJECT_NAME>/media/storage/primary-s3" \
  -H "Authorization: Bearer <YOUR_TOKEN>" \
  -H "Content-Type: application/json" \
  -d '{
    "spec": {
      "type": "AWS.S3",
      "bucketName": "my-media-bucket",
      "description": "Input media files for processing.",
      "credential": {
        "accessKeyId": "<AWS_ACCESS_KEY_ID>",
        "secretAccessKey": "<AWS_SECRET_ACCESS_KEY>"
      }
    }
  }'
```

## 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/<PROJECT_NAME>/media/storage/primary-azure/credentials" \
  -H "Authorization: Bearer <YOUR_TOKEN>" \
  -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=<REDACTED>"
      }
    }
  }'
```

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/<PROJECT_NAME>/media/assets/source-video/getFileAccessInfo" \
  -H "Authorization: Bearer <YOUR_TOKEN>"
```

3. Delete the old credential once the new one is working:

```bash
curl -X DELETE "https://app.mk.io/api/v1/projects/<PROJECT_NAME>/media/storage/primary-azure/credentials/<CREDENTIAL_ID>" \
  -H "Authorization: Bearer <YOUR_TOKEN>"
```

## 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. Check for dependent assets first:

```bash
curl -X DELETE "https://app.mk.io/api/v1/projects/<PROJECT_NAME>/media/storage/primary-azure" \
  -H "Authorization: Bearer <YOUR_TOKEN>"
```

## What comes next

- [Assets](/api-guides/how-to/media/assets): create assets that point to content in this storage.
- [Automate a VOD pipeline](/api-guides/how-to/media/vod-pipeline): see how storage feeds the rest of a workflow.

<!-- source: /api-guides/how-to/media/transforms-and-jobs.md -->

# 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/<PROJECT_NAME>/media/transforms/abr-720p" \
  -H "Authorization: Bearer <YOUR_TOKEN>" \
  -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/<PROJECT_NAME>/media/transforms/abr-720p/jobs/job-001" \
  -H "Authorization: Bearer <YOUR_TOKEN>" \
  -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/<PROJECT_NAME>/media/transforms/abr-720p/jobs/clip-job" \
  -H "Authorization: Bearer <YOUR_TOKEN>" \
  -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/<PROJECT_NAME>/media/transforms/abr-720p/jobs/job-001/state" \
  -H "Authorization: Bearer <YOUR_TOKEN>"
```

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](/api-guides/understanding/webhooks) instead of polling.

## Manage a running job

Raise the priority of a queued job:

```bash
curl -X PATCH "https://app.mk.io/api/v1/projects/<PROJECT_NAME>/media/transforms/abr-720p/jobs/job-001" \
  -H "Authorization: Bearer <YOUR_TOKEN>" \
  -H "Content-Type: application/json" \
  -d '{ "properties": { "priority": "High" } }'
```

Cancel a job that is no longer needed:

```bash
curl -X POST "https://app.mk.io/api/v1/projects/<PROJECT_NAME>/media/transforms/abr-720p/jobs/job-001/cancelJob" \
  -H "Authorization: Bearer <YOUR_TOKEN>"
```

## 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](/api-guides/how-to/media/vod-pipeline): transforms and jobs in a full publishing workflow.
- [Streaming and publishing](/api-guides/how-to/media/publishing): publish the job output for playback.
- [Webhooks](/api-guides/understanding/webhooks): replace status polling with events.

<!-- source: /api-guides/how-to/media/vod-pipeline.md -->

# 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/<PROJECT_NAME>/media/assets/input-video-001" \
  -H "Authorization: Bearer <YOUR_TOKEN>" \
  -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](/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/<PROJECT_NAME>/media/transforms/standard-encoding" \
  -H "Authorization: Bearer <YOUR_TOKEN>" \
  -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](/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/<PROJECT_NAME>/media/transforms/standard-encoding/jobs/job-001" \
  -H "Authorization: Bearer <YOUR_TOKEN>" \
  -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/<PROJECT_NAME>/media/transforms/standard-encoding/jobs/job-001/state" \
  -H "Authorization: Bearer <YOUR_TOKEN>"
```

For background automation, subscribe to the `MediaKind.JobStarted` and `MediaKind.JobFinished` [webhooks](/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/<PROJECT_NAME>/media/streamingLocators/locator-001" \
  -H "Authorization: Bearer <YOUR_TOKEN>" \
  -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/<PROJECT_NAME>/media/streamingEndpoints/default/start" \
  -H "Authorization: Bearer <YOUR_TOKEN>"

curl -X POST "https://app.mk.io/api/v1/projects/<PROJECT_NAME>/media/streamingLocators/locator-001/listPaths" \
  -H "Authorization: Bearer <YOUR_TOKEN>"
```

Combine each path with the endpoint `hostName` to build the playback URLs. See [Streaming and publishing](/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](/api-guides/how-to/media/transforms-and-jobs): deeper detail on jobs and presets.
- [Content protection](/api-guides/how-to/media/content-protection): add DRM to the published output.
- [Webhooks](/api-guides/understanding/webhooks): replace polling with event-driven completion.

<!-- source: /api-guides/understanding.md -->

# 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](/api-guides/understanding/overview): Learn the shared base URL, authentication, list responses, and resource states.

  - [Pagination](/api-guides/understanding/pagination): Understand how list responses expose pages of resources.

  - [Rate limits](/api-guides/understanding/rate-limits): Learn how the APIs communicate request limits.

  - [Error handling](/api-guides/understanding/error-handling): Interpret API errors and handle failed requests.

  - [Resource states](/api-guides/understanding/resource-states): Track the state of resources and long-running operations.

  - [Webhooks](/api-guides/understanding/webhooks): Understand event notifications from the platform.

<!-- source: /api-guides/understanding/error-handling.md -->

# 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": "<error_code>",
    "detail": "<error_message>",
    "extraDetail": {}
  },
  "status": 400,
  "ref": "<request_reference>"
}
```

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](/api-guides/understanding/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 <YOUR_TOKEN>" \
  -H "Accept: application/json" \
  -w "\nHTTP Status: %{http_code}\n" \
  "https://app.mk.io/api/v1/projects/<PROJECT_NAME>/media/assets/nonexistent"
```

<!-- source: /api-guides/understanding/overview.md -->

# API overview

The MK.IO APIs are separated by product area, but they share one operating model. 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

All MK.IO APIs share the same 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 |
| Management API | `/api/v1/` | Organization and project |
| Fleets API | `/api/v1/projects/{project_name}/fleet/` | Project |
| Infrastructure API | `/api/v1/projects/{project_name}/infra/` | 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 APIs use bearer authentication:

```http
Authorization: Bearer <YOUR_TOKEN>
```

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](/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`.

That shared shape gives you one client pattern for every collection: read `value`, then use `supplemental.pagination` to decide whether to request the next page. See [Pagination and filtering](/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 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](/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 **live event** is created, then started, then paired with one or more live outputs.
- 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](/api-guides/understanding/webhooks).

## Where to go next

- [Authentication](/api-guides/getting-started/authentication): create a token and make your first call.
- [Error handling](/api-guides/understanding/error-handling): the shared error body and status codes.
- [Pagination and filtering](/api-guides/understanding/pagination): page and narrow list responses.
- [Resource states](/api-guides/understanding/resource-states): read lifecycle state and design around it.

<!-- source: /api-guides/understanding/pagination.md -->

# 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 endpoint returns two top-level fields:

- `value`: the array of resources on the current page.
- `supplemental`: metadata about the result set, including pagination counts.

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
    }
  }
}
```

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. Comparing them tells you whether more pages remain.

## 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/<PROJECT_NAME>/media/assets?\$top=10" \
  -H "Authorization: Bearer <YOUR_TOKEN>"
```

The `$` is escaped as `\$` in these examples so that your shell does not treat the parameter as a variable.

## Page through results with $skiptoken

`$skiptoken` sets the start offset for the next page. Use it to walk a collection one page at a time.

```bash
curl -X GET "https://app.mk.io/api/v1/projects/<PROJECT_NAME>/media/assets?\$top=10&\$skiptoken=<SKIPTOKEN>" \
  -H "Authorization: Bearer <YOUR_TOKEN>"
```

Do not construct `$skiptoken` values by hand. Take the value from the previous response.

To page until the end, request pages until `supplemental.pagination.records` is smaller than your `$top`, or until the running total of returned records reaches `supplemental.pagination.total`.

## 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/<PROJECT_NAME>/media/assets?\$orderby=properties/created%20desc" \
  -H "Authorization: Bearer <YOUR_TOKEN>"
```

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/<PROJECT_NAME>/media/assets?\$filter=name%20eq%20'my-asset'" \
  -H "Authorization: Bearer <YOUR_TOKEN>"
```

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/<PROJECT_NAME>/media/assets?\$label_key=studio" \
  -H "Authorization: Bearer <YOUR_TOKEN>"
```

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/<PROJECT_NAME>/media/assets?\$label=studio=paravalley" \
  -H "Authorization: Bearer <YOUR_TOKEN>"
```

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/<PROJECT_NAME>/media/assets?\$top=10&\$orderby=properties/created%20desc&\$label=studio=paravalley" \
  -H "Authorization: Bearer <YOUR_TOKEN>"
```

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. Page with `$skiptoken` until no further records remain.

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](/api-guides/understanding/rate-limits).

## Related reading

- [API overview](/api-guides/understanding/overview): the request and response conventions these endpoints share.
- [Rate limits](/api-guides/understanding/rate-limits): why server-side filtering matters for request volume.

<!-- source: /api-guides/understanding/rate-limits.md -->

# 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": "<error_code>",
    "detail": "<error_message>",
    "extraDetail": {}
  },
  "status": 429,
  "ref": "<request_reference>"
}
```

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](/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](/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/<PROJECT_NAME>/media/assets?\$top=20&\$label=studio=paravalley" \
  -H "Authorization: Bearer <YOUR_TOKEN>"
```

This returns far fewer items than listing everything and filtering locally. See [Pagination and filtering](/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.

<!-- source: /api-guides/understanding/resource-states.md -->

# 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.

## 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/<PROJECT_NAME>/media/transforms/<TRANSFORM_NAME>/jobs/<JOB_NAME>/state" \
  -H "Authorization: Bearer <YOUR_TOKEN>"
```

```json
{
  "status": {
    "state": "Processing"
  }
}
```

## The states each resource reports

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.
- Wait for a live event to reach `Running` before you expect ingest to work.
- 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](/api-guides/understanding/rate-limits). At that scale, [webhooks](/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](/api-guides/understanding/webhooks): replace repeated polling with event delivery.
- [Transforms and jobs](/api-guides/how-to/media/transforms-and-jobs): see how job state fits a VOD workflow.
- [Live streaming](/api-guides/how-to/media/live-streaming): see how live-event state affects ingest and publishing.

<!-- source: /api-guides/understanding/webhooks.md -->

# 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](/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": "<unique_id>",
  "type": "<event_type>",
  "source": "<object_url>",
  "time": "<event_time>",
  "datacontenttype": "application/json",
  "data": {
    "projectName": "<project_name>",
    "previousState": "<state before this event>",
    "state": "<new 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](/api-guides/understanding/resource-states): the state values these events report.
- [Rate limits](/api-guides/understanding/rate-limits): why event delivery scales better than polling.

<!-- source: /beam.md -->

# 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.

  - [Web Interface Overview](/beam/web-interface): Get familiar with the Advanced web interface.

<div style={{ marginTop: '1.5rem', width: '100%' }}>
  <div style={{ position: 'relative', width: '100%', paddingBottom: '56.25%' }}>
    <iframe
      src="https://www.youtube-nocookie.com/embed/19jWBoH6Ilk?rel=0&controls=1&modestbranding=1&iv_load_policy=3&disablekb=1&fs=0&playsinline=1&loop=1&playlist=19jWBoH6Ilk"
      title="MK.IO Beam overview video"
      frameBorder="0"
      allow="accelerometer; autoplay; clipboard-write; encrypted-media; gyroscope; picture-in-picture; web-share"
      referrerPolicy="strict-origin-when-cross-origin"
      allowFullScreen
      style={{ position: 'absolute', top: 0, left: 0, width: '100%', height: '100%' }}
    />
  </div>
</div>

## Solutions

- [Contribution](/beam/contribution): **For sending high-quality feeds from the field to the studio.** <br />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.** <br />Find guides on configuring satellite demodulation, IP turnaround, professional decoding, and more.

  - [Headends](/beam/headends): **For processing channels for distribution (Cable, IPTV, OTT).** <br />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)

<!-- source: /beam/connect-to-mkio.md -->

# 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.

## 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](/api-guides/how-to/fleets/device-management).

<!-- source: /beam/contribution.md -->

# Contribution

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 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/ADI 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 sattelite modulator](/beam/contribution/configure-feed-components/satellite-modulator): How to configure the satellite modulator

<br />

<!-- source: /beam/contribution/configure-feed-components.md -->

# 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](./configure-feed-components/live-encoder)
-   optionally [the Multiplexer service](/beam/multiplexer)
-   optionally [the Satellite Modulator](./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](./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.

<!-- source: /beam/contribution/configure-feed-components/live-encoder.md -->

# 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 <!-- non-renderable component stripped: EditIcon --> 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**](#sdi-input)
    -   or [**SMPTE ST 2110**](#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 <!-- non-renderable component stripped: EditIcon --> 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-ce1)
[Setup the PTP for ST 2110](/beam/contribution/how-to/setup-smpte-2110-input#setup-the-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 <!-- non-renderable component stripped: EditIcon --> 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 <!-- non-renderable component stripped: EditIcon -->.

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 <!-- non-renderable component stripped: EditIcon --> 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.

<!-- source: /beam/contribution/configure-feed-components/mux.md -->

# Configure the Multiplexer service

For detailed information on the Multiplexer service, refer to the [Multiplexer documentation](/beam/multiplexer).

<!-- source: /beam/contribution/configure-feed-components/reliable-transport.md -->

# Configure a Reliable Transport service

> **info:** 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*

<!-- source: /beam/contribution/configure-feed-components/satellite-modulator.md -->

# 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.

> **info:** 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 <!-- non-renderable component stripped: EditIcon --> 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:<br/>
Username: `admin`<br/>
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.

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

<!-- source: /beam/contribution/how-to/configure-jpegxs.md -->

# 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.

> **info:** 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.

> **warning:** 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.

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

<!-- source: /beam/contribution/how-to/configure-nmos.md -->

# 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:<br/>
    -   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

<!-- source: /beam/contribution/how-to/drop-output-on-input-loss.md -->

## 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 <!-- non-renderable component stripped: EditIcon --> next to the **LIVE ENCODER** component within the feed.

    2. Click the **Output** tab then click <!-- non-renderable component stripped: EditIcon --> 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 <!-- non-renderable component stripped: EditIcon --> 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)

<!-- source: /beam/contribution/how-to/lpcm-and-dolby-e-passthrough.md -->

# 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.

<!-- source: /beam/contribution/how-to/minimize-end-to-end-delay.md -->

# 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.

<!-- source: /beam/contribution/how-to/output-synchronization-with-pts.md -->

# 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](#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)

> **warning:** 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**<br/>
[Synchronize two services](/beam/live-encoder/configure#synchronize-two-services)

<!-- source: /beam/contribution/how-to/setup-smpte-2110-input.md -->

# 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: [https://datatracker.ietf.org/doc/html/rfc3550\#section-5.3.1](https://datatracker.ietf.org/doc/html/rfc3550#section-5.3.1).

-   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](../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

> **info:** 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** <!-- non-renderable component stripped: ViewIcon --> 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
```

<!-- source: /beam/contribution/tech-specs.md -->

# Technical specifications

## Input / Output cards

### Baseband input

> **info:** Optional hardware required

- **SDI over IP (SMPTE ST 2022-6)**

### Combined SDI and ASI input/output

> **info:** 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

> **info:** 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

<!-- source: /beam/essentials.md -->

# 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).

> **warning:** 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 supports channel creation for contribution, streaming, and distribution, alongside a monitoring dashboard. For reception and gateway use cases, please see the advanced guide pages. Additional functionality will be introduced in upcoming software updates.

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](/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 [Web 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.

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](./essentials/images/essentials-welcome-modal.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).

![Essentials dashboard showing the channel grid, status panel, and active alarms panel](./essentials/images/essentials-dashboard-overview.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](./essentials/images/essentials-status-alarms-panel.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](./essentials/images/essentials-channel-card-anatomy.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](./essentials/images/essentials-channel-detail.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](./essentials/images/essentials-channel-settings.png)

<!-- source: /beam/essentials/create-a-channel.md -->

# 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](./images/wizard-name.png)

### Choose the workflow

Select the workflow type for the channel, then select **Next**. For our current device configuration, we can see **Encoding (Streaming)**, **Encoding (Distribution)**, **Encoding (Contribution)**, **Reception (Decoding)**, and **Reception (Gateway)** workflows to choose from.

Availability depends on the device. See [Contribution](/beam/contribution), [Reception](/beam/reception), and [Headends](/beam/headends) for the workflows behind each type.

![Create a new channel: the Workflow step, listing the encoding and reception workflow types](./images/wizard-workflow.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](./images/wizard-input.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](./images/wizard-video.png)

> **info:** 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](./images/wizard-audio.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](./images/wizard-output.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](./images/wizard-review.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.

<!-- source: /beam/headends.md -->

# 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.

> **info:** 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.

<!-- source: /beam/headends/high-availability.md -->

# 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.

<!-- source: /beam/headends/server-pair.md -->

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.

<!-- source: /beam/headends/single-server.md -->

# 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.

<!-- source: /beam/headends/tech-specs.md -->

## 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

> **info:** 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

<!-- source: /beam/live-encoder.md -->

# 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](./live-encoder/images/EL_FunctionalView.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).

<!-- source: /beam/live-encoder/configure.md -->

# 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

> **info:** See [General parameters](#configure-general-parameters) for more details.

2.  You can activate automation mode and [configure the associated parameters](./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](#synchronize-two-services) and [Split one OTT service on the same server](#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](#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

> **info:** **External SDI Genlock clock** is only visible if you set the [advanced parameter](./configure/advanced-parameters) `enableExternalGenlockClock` to `true`.

> **info:** When using the external NTP, it is not possible to enable the service synchronization feature (see [Synchronize two services](#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](./parameters/general#synchronization-of-services).

3.  From the **Output** tab, click <!-- non-renderable component stripped: EditIcon --> 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](./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](#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.

        ![](./images/el_split_services.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 <!-- non-renderable component stripped: EditIcon --> 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](./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](./images/EL_dual_output_prevention_diagram.png)

> **info:** 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.|

> **info:** 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](./images/EL_dual_output_prevention_stats.png)

**See also**<br/>
[Dual-output prevention parameters](./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 <!-- non-renderable component stripped: EditIcon --> to edit the [**Server tags**](./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](./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](./configure/output/configure-output#link-an-output-stream-to-a-predefined-subset).

<!-- source: /beam/live-encoder/configure/advanced-parameters.md -->

# 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.

<!-- source: /beam/live-encoder/configure/encoding.md -->

# Configure the general encoding parameters

Before configuring the input stream general parameters, you must select the export type.<br/>
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.

<!-- source: /beam/live-encoder/configure/encoding/audio-encoding.md -->

{ /* 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 <!-- non-renderable component stripped: EditIcon --> 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.

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

3.  Enter the appropriate value for [audio encoding parameters](../../parameters/encoding/audio).

4.  Click **Save and continue** or **Save and exit** to save your changes.

<!-- source: /beam/live-encoder/configure/encoding/blackout-encoding.md -->

{ /* 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.<br/>
SCTE-35 metadata can be:

-   either [in-band](../input/inband-metadata)
-   or [out-of-band](../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 <!-- non-renderable component stripped: EditIcon --> 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**](../../parameters/encoding/audio#mpeg-1-layer-ii-dolby-digital-dolby-digital-plus-dolby-ac-4-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](#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, <!-- non-renderable component stripped: EditIcon --> 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 <!-- non-renderable component stripped: EditIcon --> 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 <!-- non-renderable component stripped: ChartIcon --> to view statistics.

2.  Ensure that blackout configurations display as expected in the **Monitoring** section of the **Statistics** page.

    ![screen stats blackout mfvp el](./images/screen_stats_blackout_mfvp-el.png)

### Activate blackout
You can [Manually activate or deactivate a blackout](#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](#create-a-scheduled-blackout-configuration).
2.  [Apply a blackout configuration to video encodings](#apply-a-blackout-configuration-to-video-encodings).
3.  [Apply a blackout configuration to audio encodings](#apply-a-blackout-configuration-to-audio-encodings).
4.  [Check blackout configurations](#check-blackout-configurations).

### Create a scheduled blackout configuration

Live Encoder can blackout a program and replace the video with a still image. <br/>
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.

> **info:** Audio plays during blackout, unless you configure the blackout to mute audio.

1.  Display services.

2.  Click <!-- non-renderable component stripped: EditIcon --> 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.

> **info:** 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](./images/screen_encoding_blackout_configuration_mfvp-el.png)

> **info:** If no **SCTE-35 Input** options display in the list, then [reconfigure inputs](../encoding/metadata-encoding).

    ![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](#apply-a-blackout-configuration-to-video-encodings) and/or [audio](#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.

> **info:** Blackout is **not supported in Pass-through**.

1.  Display services.

2.  Click <!-- non-renderable component stripped: EditIcon --> to edit the service.

3.  Open the **Encoding** tab, then click <!-- non-renderable component stripped: EditIcon --> 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](./images/screen_video_encoding_table_blackout_mfvp-el.png)

6.  [Apply the blackout configuration to audio](#apply-a-blackout-configuration-to-audio-encodings) streams.

7.  [Add encodings to output](../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](#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.

> **info:** Blackout is **not supported in Pass-through**.

1.  Display services.

2.  Click <!-- non-renderable component stripped: EditIcon --> to edit the service.

3.  Open the **Encoding** tab, then click <!-- non-renderable component stripped: EditIcon --> 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](./images/screen_blackout_configuration_parameter_audio_selection_mfvp-el.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](./images/screen_audio_encoding_table_blackout_mfvp-el.png)

7.  [Add encodings to output](../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 <!-- non-renderable component stripped: EditIcon --> 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](./images/screen_blackout_configuration_list_mfvp-el.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](./images/screen_output_stream_list_blackout_mfvp-el.png)

6.  Return to the list of services, or edit any parameters and then save.

7.  From the list of services, click <!-- non-renderable component stripped: ChartIcon --> to view statistics.

8.  Ensure that blackout configurations display as expected in the **Statistics** page.

    ![screen stats blackout mfvp el](./images/screen_stats_blackout_mfvp-el.png)

### Activate blackout
You can [Manually activate or deactivate a blackout](#manually-activate-or-deactivate-a-blackout).

## Manually activate or deactivate a blackout

Once you have configured a [manual](#configure-a-manual-blackout) or an [automated blackout](#configure-an-automated-blackout) and started a service, you can manually activate or deactivate it.

> **info:** Manual blackout activation/deactivation is only available if **Trigger** parameter is set to **spliceOutSpliceIn**.

![EL encoding metadata cfig blackout splice cut](./images/EL_encoding_metadata_cfig_blackout_splice_cut.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.

<!-- source: /beam/live-encoder/configure/encoding/logo-insertion.md -->

{ /* 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](../../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.

<!-- source: /beam/live-encoder/configure/encoding/metadata-encoding.md -->

{ /* 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](../input/inband-metadata) or [Configure out-of-band metadata input stream](../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 <!-- non-renderable component stripped: EditIcon --> 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<br/>SCTE-35 OOB<br/>Cuetones  | **Pass-through** or **Conditioning**<br/>    -   Select **Pass-through** to forward SCTE-35 information in dedicated output metadata track without video conditioning. For Automation (<!-- non-renderable component stripped: ClockIcon -->), metadata must be **Pass-through**.<br/>    -   **Conditioning** allows video stream conditioning and lets you define a POIS server. It can also be used in [Blackout](../encoding/blackout-encoding).|
    |AIT<br/>EBIF<br/>EISS                 | **Pass-through**                |
    |SMPTE-2038                            | **Pass-through**, **Timecode ID3**, or **Tissot clock metadata ID3**<br/>In Pass-through mode, you can specify the **Max Bitrate** on output. If the bitrate target is exceeded, an alarm is raised.<br/>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](#convert-smpte-2038-to-id3)).|

4.  For **SMPTE-2038** input metadata, if you selected [**Timecode ID3**](../../parameters/encoding/metadata#timecode-id3-parameters), or [**Tissot clock metadata ID3**](../../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](../../parameters/encoding/metadata#pois-parameters).

5.  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**](../../parameters/encoding/metadata) checkbox.

6.  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**](../../parameters/encoding/metadata) checkbox.

7.  Click **OK** to validate.

8.  Click **Save and continue** or **Save and exit** to save your changes.

9.  You can specify the conditioned metadata in the [video stream parameters](../../parameters/encoding/video#stream-metadata-settings).

10. You can add the conditioned metadata in the [output stream](../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. <br/>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.

> **info:** 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](../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](./images/el_encoding_metadata_smpte2038_to_id3.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, <!-- non-renderable component stripped: EditIcon --> in the **Actions** column.

    2.  Select the video stream that you configured in Step \#3.

        ![EL output stream metadata id3](./images/EL_output_stream_metadata_id3.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 <!-- non-renderable component stripped: ChartIcon --> to display service details and monitor the service:

    -   **Media info** tab shows the SMPTE-30 metadata at input.

        ![EL stats media info metadata smpte2038](./images/EL_stats_media_info_metadata_smpte2038.png)

    -   **Output** tab shows ID-3 metadata at output.

        ![EL stats output metadata id3](./images/EL_stats_output_metadata_id3.png)

<!-- source: /beam/live-encoder/configure/encoding/scte-104-oob-metadata.md -->

{ /* 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](./images/EL_SCTE104_adsmart.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](../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 <!-- non-renderable component stripped: EditIcon --> 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#general).

        ![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 <!-- non-renderable component stripped: EditIcon --> in the **Actions** column.

    3.  For each video stream, tick the associated [**Stream Conditioning**](/beam/live-encoder/configure/encoding#general).

        ![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.

<!-- source: /beam/live-encoder/configure/encoding/subtitle-burnin-encoding.md -->

# 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](../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 <!-- non-renderable component stripped: EditIcon --> 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 <!-- non-renderable component stripped: EditIcon --> then go to the **Subtitle settings** section and select a subtitle burn-in that you just created.

        ![el cfig encoding video subtitle burnin](./images/el_cfig_encoding_video_subtitle_burnin.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)](../output/configure-output#define-the-output-stream-composition).

<!-- source: /beam/live-encoder/configure/encoding/subtitles-encoding.md -->

# Configure subtitle encoding

Before you start: ensure you have configured a [subtitle input stream](../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 <!-- non-renderable component stripped: EditIcon --> 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)

> **info:** Possible values depend on [subtitle type](../../parameters/input/subtitle).

4.  Depending on the selected codec, [specific parameters](../../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](../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](../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](./images/EL_encoding_video_subtitle_CC_CEA608.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](./images/EL_encoding_video_metadata_settings_CC.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 <!-- non-renderable component stripped: EditIcon --> 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](./images/EL_output_stream_video_CC.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](../../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 <!-- non-renderable component stripped: EditIcon --> 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](../../parameters/encoding/subtitle#dvb-ttml).

4.  Click **Ok** once done. You should get the following:

    ![el ttml encoding](./images/el_ttml_encoding.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, <!-- non-renderable component stripped: EditIcon --> 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](./images/el_ttml_output.png)

## Convert ARIB B24 to DVB-Teletext

> **info:** 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](./images/el_arib_input.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 <!-- non-renderable component stripped: EditIcon --> to edit the subtitle encoding.

3.  Select the codec used to convert the subtitles, **DVB-Teletext**. You should get the following:

    ![el arib encoding](./images/el_arib_encoding.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, <!-- non-renderable component stripped: EditIcon --> 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](./images/el_arib_output.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](../../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](../../parameters/encoding/subtitle#dvb-ttml-with-cea-608cea-708-closed-captions-input) or [DASHIF-TTML](../../parameters/encoding/subtitle#dash-if-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, <!-- non-renderable component stripped: EditIcon --> 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

> **info:** 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](./images/el_arib_input.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 <!-- non-renderable component stripped: EditIcon --> to edit the subtitle encoding.

3.  Select the codec used to convert the subtitles, **DVB-Teletext**. You should get the following:

    ![el arib encoding](./images/el_arib_encoding.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, <!-- non-renderable component stripped: EditIcon --> 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](./images/el_arib_output.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

> **info:** 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](./images/el_dvbsub_input.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 <!-- non-renderable component stripped: EditIcon --> to edit the subtitle encoding.

> **info:** 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](./images/el_dvbsub_encoding.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, <!-- non-renderable component stripped: EditIcon --> 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](./images/el_dvbsub_output.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.

<!-- source: /beam/live-encoder/configure/encoding/video-encoding.md -->

{ /* 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 <!-- non-renderable component stripped: EditIcon --> 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](#create-a-child-encoding-factorization).

13.  You can configure [HDR signaling conversion (HEVC)](#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 <!-- non-renderable component stripped: ForkIcon --> 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).

> **info:** Child stream bitrates must be more than half of the parent bitrate.

    ![MFVP EL video encoding factorization](./images/MFVP-EL_video_encoding_factorization.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 <!-- non-renderable component stripped: EditIcon --> 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](./images/encoding_video_hevc10_el.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

> **info:** 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 <!-- non-renderable component stripped: ClockIcon --> 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.

> **default:** 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.

<!-- source: /beam/live-encoder/configure/input.md -->

# Configure the input

1. From the **services** page, click <!-- non-renderable component stripped: EditIcon --> to edit the service. The **General parameters** display.

2. Select **Input** tab to display parameters.

3. Enter the appropriate value for each [parameter](../parameters/input/general).

> **info:** 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.

<!-- source: /beam/live-encoder/configure/input/audio-stream.md -->

{ /* TODO: update links (especially ./parameters/) once MD files are created */}

# Configure the audio input stream

1. Display services.

2. Click <!-- non-renderable component stripped: EditIcon --> 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 <!-- non-renderable component stripped: EditIcon --> to edit an existing one.

5. Enter the appropriate value for each [audio stream parameter](../../parameters/input/video-and-audio#audio).

> **info:** 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.

<!-- source: /beam/live-encoder/configure/input/cross-stream-prevention.md -->

{ /* 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](../../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](../output/configure-output#define-the-output-stream-composition)).

<!-- source: /beam/live-encoder/configure/input/inband-metadata.md -->

{ /* 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:

> **info:** 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](./images/view_add_input_metadata_el.png)

2.  Select a [**Type**](../../parameters/input/metadata#in-band-metadata).

    ![view metadata selection type](./images/view_metadata_selection_type.png)

3.  Enter or select the following information depending on the selected type:

    1.  Enter a [**PID**](../../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](../encoding/metadata-encoding).
-   You can [add the metadata to the output stream](../output/configure-output#define-the-output-stream-composition).

<!-- source: /beam/live-encoder/configure/input/input-stream-source.md -->

{ /* 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.

> **info:** For more information on SDI/IP redundancy, see [Configure an SDI/IP redundancy](#configure-an-sdiip-redundancy).

1. Display services.

2. Click <!-- non-renderable component stripped: EditIcon --> 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)](./video-stream)
    -   [audio input(s)](./audio-stream)
    -   [subtitles input(s)](./subtitle),
    -   [VANC data input(s)](./vanc-data) *(SMPTE ST 2110 input only)*
    -   [in-band metadata input(s)](./inband-metadata)
    -   [out-of-band metadata](./outofband-metadata)
    -   [cross stream prevention](./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](../../parameters/input/general).

3.  Complete the [parameters](../../parameters/input/source#sdiip) in the **Primary** and **Secondary** tabs:

    -   Network interface
    -   Stream address
    -   Protocol
    -   IGMPv3 source filtering

## Configure SMPTE ST 2110 input

> **info:** 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.
<br/>You can optionally configure the input to use SMPTE ST 2022-7 (see [Configure SMPTE ST 2110 input with ST 2022-7 redundancy](#configure-smpte-st-2110-input-with-st-2022-7-redundancy)).

You can configure the SMPTE ST 2110 input either:

-   [by specifying an SDP file](#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](#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

> **info:** 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

> **info:** 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](../encoding/video-encoding)

### [Configure the audio encoding parameters](../encoding/audio-encoding)

### [Configure the output parameters](../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 <!-- non-renderable component stripped: DownloadIcon --> 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.

> **info:** 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](../../parameters/input/source#smtpe-st-2110)

## SMPTE ST 2110 SDP file

> **info:** 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

> **info:** 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
```

<!-- source: /beam/live-encoder/configure/input/outofband-metadata.md -->

{ /* 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:

> **info:** 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**](../../parameters/input/metadata#out-of-band-metadata).

    ![view metadata oob selection type](./images/view_metadata_oob_selection_type.png)
    *Example of  configuration for SCTE-35 OOB metadata*

> **info:** **SCTE-35 OOB** can be used for automation (<!-- non-renderable component stripped: ClockIcon -->) or when there is no SCTE-35 in the input.

3.  Enter the appropriate values for the following [parameter](../../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.

> **info:** 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](../encoding/metadata-encoding) and [add the metadata to the output stream](../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://<controller.ip>:8080/api/esam/LiveEncodings/<network_name>`
<br/>where:

-   `controller.ip` is the [IP address used to connect to the Controller](/beam/web-interface/connection#connect-to-the-controller).
-   `network_name` is the unique acquisition point network name corresponding to the Live Encoder configuration to the input stream metadata.oob you create.

> **info:** -   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**](../../parameters/input/metadata#scte-35-oob) 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**](../../parameters/input/metadata#scte-35-oob) parameter.

## Configure SCTE-35 out-of-band metadata input stream

To configure SCTE-35 out-of-band metadata input stream, follow these steps:

> **info:** 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**](../../parameters/input/metadata#out-of-band-metadata) to **SCTE-35 OOB**.

    ![view metadata oob selection type](./images/view_metadata_oob_selection_type.png)
    *Example of configuration for SCTE-35 OOB metadata*

> **info:** **SCTE-35 OOB** can be used for automation ( <!-- non-renderable component stripped: ClockIcon --> ) or when there is no SCTE-35 in the input.

3.  Enter the appropriate value for the following [parameters](../../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.

> **info:** 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](../encoding/metadata-encoding) and [add the metadata to the output stream](../output/configure-output#define-the-output-stream-composition).

**Related information**
[Configure blackout](../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:

> **info:** 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**](../../parameters/input/metadata#out-of-band-metadata) to **SCTE-104 / IP OOB**.

    ![view metadata oob SCTE104 selection type](./images/view_metadata_oob_SCTE104_selection_type.png)
    *Example of configuration for SCTE-104/IP out-of-band metadata*

3.  Enter the appropriate value for the following [parameters](../../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](../encoding/metadata-encoding) and [add the metadata to the output stream](../output/configure-output#define-the-output-stream-composition).

<!-- source: /beam/live-encoder/configure/input/source-error-management.md -->

# 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](#configure-switch-on-es-data-loss) to backup the source if video or audio input is lost.
-   [Configure a slate (replacement image)](#configure-a-slate) that will be displayed if the input is not detected at start.
-   [Activate the fast recovery](#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)).

> **info:** Works both in Active/Active and in Active/Passive redundancy mode.

1.  Display services.

2.  Click <!-- non-renderable component stripped: EditIcon --> 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](./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 <!-- non-renderable component stripped: EditIcon --> 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.

> **info:** 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 <!-- non-renderable component stripped: EditIcon --> 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.

<!-- source: /beam/live-encoder/configure/input/subtitle.md -->

{ /* 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 <!-- non-renderable component stripped: EditIcon --> 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](../encoding/subtitles-encoding).
-   You can [configure subtitle burn-in](../encoding/subtitle-burnin-encoding).
-   You can [add subtitles to output streams](../output/configure-output#define-the-output-stream-composition).

<!-- source: /beam/live-encoder/configure/input/vanc-data.md -->

{ /* 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:

> **info:** Only available with **SMPTE ST 2110** input type.

1. Display services.

2. Click <!-- non-renderable component stripped: EditIcon --> 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 <!-- non-renderable component stripped: EditIcon --> 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.

<!-- source: /beam/live-encoder/configure/input/video-stream.md -->

{ /* 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 <!-- non-renderable component stripped: EditIcon --> 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](../../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](../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.

<!-- source: /beam/live-encoder/configure/media-processing/audio-processing.md -->

{ /* 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**](#audio-watermarking).

4.  You can [configure **DTMF extraction**](#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 <!-- non-renderable component stripped: EditIcon -->.

3.  Activate **Insertion** and/or **Extraction** by ticking **Enable**.

4.  [Set the appropriate value for each parameter](../../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 <!-- non-renderable component stripped: ChartIcon --> to display service details and to monitor the service. Specific cue tones statistics are displayed.

<!-- source: /beam/live-encoder/configure/media-processing/true-motion.md -->

# 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.

<!-- source: /beam/live-encoder/configure/media-processing/video-processing.md -->

# 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](../../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](../../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](../../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](../../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](../../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](../../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.

<!-- source: /beam/live-encoder/configure/output/configure-output.md -->

{ /* 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 <!-- non-renderable component stripped: EditIcon --> to edit the output parameters. The Output parameters display.

5.  Configure the [**General parameters**](../../parameters/output#general).

6.  With MPEG-2 TS output, configure the [associated parameters](../../parameters/output#general-mpeg-2-ts-parameters).

7.  With DASH-IF CMAF Ingest, configure the [associated parameters](../../parameters/output#general-dash-if-cmaf-ingest-parameters).

8.  Configure the [output streams](../../parameters/output#output-stream-parameters).

9.  Click **Save and continue** or **Save and exit** to save your changes.

### Activate EBP on audio output

1.  From the **Output** tab, click <!-- non-renderable component stripped: EditIcon --> 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](./images/screen_output_parameters_ebp_on_audio_mfvp-el.png)

4.  Tick the checkbox to activate **EBP on audio**, then click **OK**.

    ![screen output parameters ebp on audio box mfvp el](./images/screen_output_parameters_ebp_on_audio_box_mfvp-el.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 <!-- non-renderable component stripped: EditIcon --> 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](../../parameters/output#mpeg-2-ts-common-parameters).

4.  You can [specify the streams that will be included in the output stream](#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 <!-- non-renderable component stripped: EditIcon --> to edit the output.

4.  Go to the **Output streams** section then click the **Add** button. Output stream parameters are displayed.

    ![screen output parameters blank mfvp el](./images/screen_output_parameters_blank_mfvp-el.png)

5.  Configure settings and select streams.

6.  [Activate FEC](#activate-fec-on-existing-output-streams) to display additional FEC options.

7.  [Link the output to a predefined subset](#link-an-output-stream-to-a-predefined-subset) to synchronize streams or to distribute the streams across multiple servers.

8.  Select any video, audio or subtitle [streams to add to the output](#define-the-output-stream-composition).

9.  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 <!-- non-renderable component stripped: EditIcon --> to edit the output.

2.  Go to the **Output streams** section then click <!-- non-renderable component stripped: EditIcon --> to edit the output stream.

    ![screen output parameters blank mfvp el](./images/screen_output_parameters_blank_mfvp-el.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.

> **info:** By default, one transport stream is defined using the first video stream and the first audio stream.

7.  Click **Ok** to confirm. The output stream configuration is displayed in the output stream IP address and stream composition.

8.  Click **Save and continue** or **Save and exit** to save your changes.

### Activate FEC on existing output streams

> **info:** Only available with MPEG-2 TS/RTP transport protocol.

1.  From the **Output** tab, click <!-- non-renderable component stripped: EditIcon --> to edit the output.

2.  Go to the **Output streams** section then click <!-- non-renderable component stripped: EditIcon --> to edit the output stream.

3.  Tick the **FEC** checkbox to activate. Additional FEC parameters display.

3.  Enter [FEC parameters](../../parameters/output#output-stream-parameters)

4.  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](../../configure#create-subset-variants) are created.

1.  From the **Output** tab, click <!-- non-renderable component stripped: EditIcon --> to edit the output.

2.  Go to the **Output streams** section then click <!-- non-renderable component stripped: EditIcon --> to edit the output stream.

5.  For the **Subset** parameter select an existing preset in the drop-down list. The output stream is linked to the selected subset.

6.  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](../../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](../../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](../../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](../../parameters/output#tracks).

    - In the **Output groups** section, select the tracks to be added in the output (see [Defining the output stream composition](#define-the-output-stream-composition)).

<!-- source: /beam/live-encoder/configure/output/manage-output.md -->

# Manage the output

## Add an output

You can create several outputs.
To create an output you can either:

-   [Create a new one](#create-a-new-output-from-scratch).
-   [Duplicate an existing one](#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](#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 <!-- non-renderable component stripped: CloneIcon --> 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](#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](#add-an-output).

1.  From the **Output** tab, click **Output** to open the tab and display outputs.

2.  Click <!-- non-renderable component stripped: EditIcon --> to display parameters and edit the output. The output parameters display.

> **info:** Depending on your configuration type and settings, additional parameters may display.

3.  [Edit the general parameters](./configure-output#configure-the-output-stream-mpeg-2-ts-parameters).

4.  [Configure the MPEG-2 TS parameters](./configure-output#configure-the-output-stream-mpeg-2-ts-parameters).

5.  [Select the streams to include in the 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

> **info:** If deleted, the stream is automatically removed from any outputs.

From the **Output** tab, click <!-- non-renderable component stripped: DeleteIcon --> in the top right corner of the selected output stream. A message asks you to confirm the deletion.

<!-- source: /beam/live-encoder/create-service.md -->

# 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](#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))

> **info:** 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.

<!-- source: /beam/live-encoder/leaky-bucket.md -->

# 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](./images/leaky_bucket.jpg)
*Leaky bucket algorithm*

<!-- source: /beam/live-encoder/monitor-statistics.md -->

{ /* TODO: update links (especially ./parameters/) once MD files are created */}

# Monitor service statistics

You can retrieve and monitor detailed statistics information on a service.

> **info:** The <!-- non-renderable component stripped: ChartIcon --> 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 <!-- non-renderable component stripped: ChartIcon --> icon. The **Statistics** page displays.

2.  You can navigate between three tabs:
-   [**Media info**](#media-info)
-   [**Input monitoring**](#input-monitoring)
-   [**Outputs**](#outputs).

> **info:** 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](./images/MFVP-EL-service-statistics-mediainfo.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](./images/MFVP-EL-service-statistics-input.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](./images/MFVP-EL-service-statistics-output.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](./configure/encoding/blackout-encoding#manually-activate-or-deactivate-a-blackout).
-   Once you have activated and configured the [Switch to CBR option](./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](./images/EL-service-statistics-output-switch_to_CBR.png)
    *Example of Service Statistics>Outputs with Switch to CBR option activated*

<!-- source: /beam/live-encoder/parameters/encoding/audio.md -->

# 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.<br/>**Note:** If you activate this option, associated monitoring statistics are available from the [Service statistics](/beam/live-encoder/monitor-statistics) (see example below).|
|Glitch supression|Only available if **Insert audio frames on signal loss** is checked.<br/>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.<br/>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.<br/>**Note:** Applies to both use cases where Live Encoder is configured either with SDI or as IP input.|

![el encoding audio passthrough silence stats](../../../live-encoder/images/el_encoding_audio_passthrough-silence_stats.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.<br/>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.<br/>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)

<!-- source: /beam/live-encoder/parameters/encoding/blackout.md -->

# Blackout parameters

## General parameters

|Parameter              |Description     |
|:----------------------|:---------------|
|Tracks SCTE-35|Select tracks to trigger blackout.<br/>**Note:** Options for this parameter depend on metadata configured in **Input**.|
|Trigger|Select the command to trigger blackout.<br/>Possible values:<br/>-   **spliceOut/SpliceIn**: blackout triggered on reception of an SCTE 35 splice out, end of blackout on splice in.<br/>-   **webDeliveryAllowedFlag**: blackout triggered on reception of an SCTE 35 containing a web delivery flag set to false.<br/>-   **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.<br/>**Note:** If no "alternate content off" command is received, the blackout will be removed at the end of this timeout.<br/>Range: From 0 to 60000 ms|

## Specific webDeliveryAllowedFlag & spliceOutSpliceIn parameters

|Parameter              |Description     |
|:----------------------|:---------------|
|Image URL|**Note:**<br/>-   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`).<br/>-   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.<br/>**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.<br/>**Note:**<br/>-   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).<br/>-   Authorized file types are .gif, .png or.jpg.|

<!-- source: /beam/live-encoder/parameters/encoding/general.md -->

# General parameters

|Parameter              |Description     |
|:----------------------|:---------------|
|Export type|Select either IP TV or Internet TV export type.|

<!-- source: /beam/live-encoder/parameters/encoding/logo-insertion.md -->

# 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.<br/>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.|

<!-- source: /beam/live-encoder/parameters/encoding/metadata.md -->

# Metadata encoding parameters

|Parameter              |Description     |
|:----------------------|:---------------|
|Codec|Select the codec used to refine the stream object type.|
|Use POIS|Only available with **Conditioning**.<br/>Tick this checkbox if you want to define a POIS server.|
|PTS insertion compensation|Only available with **Conditioning**.<br/>Enable pts insertion compensation.<br/>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:<br/>![pts insertion compensation](../../../live-encoder/images/pts_insertion_compensation.png)<br/>**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.<br/>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.<br/>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.<br/>Possible values: From 0 to 65535 ms|

<!-- source: /beam/live-encoder/parameters/encoding/subtitle.md -->

# 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

> **info:** 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.<br/>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

> **info:** 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.<br/>Format: 3 alphanumeric characters|

### DASH-IF-TTML with Teletext subtitles input

> **info:** 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.<br/>Format: 3 alphanumeric characters|

### DVB-TTML with CEA-608/CEA-708 Closed Captions input

> **info:** 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.<br/>Format: 3 alphanumeric characters|
|Closed caption service|Specify the CEA608 or CEA708 service number.<br/>Possible values for CEA-608: cc_1, cc_2, cc_3 and cc_4.<br/>Possible values for CEA-708: service_1, service _2, service _3 and service _4|

### DASHIF-TTML with CEA-608/CEA-708 Closed Captions input

> **info:** 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.<br/>Format: 3 alphanumeric characters|
|Closed caption service|Specify the CEA608 or CEA708 service number.<br/>Possible values for CEA-608: cc_1, cc_2, cc_3 and cc_4.<br/>Possible values for CEA-708: service_1, service _2, service _3 and service _4|

### Closed caption CEA 608

> **info:** 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.<br/>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](#selected-stream-arib-b24-subtitles-input-only): Selection of the stream to encode in the input subtitle. One subtitle encoding section must be defined per language.
-   [Teletext encoding](#teletext-descriptor): Configuration of the encoding of the teletext stream.
-   [Teletext descriptor](#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)

<!-- source: /beam/live-encoder/parameters/encoding/video.md -->

# 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**.<br/> -   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.<br/>-   For more information on **Statmux**, see [Statmux, Statistical rate control](/beam/live-encoder/rate-control#statmux-statistical-rate-control).<br/> **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.<br/>**Note:** If activated, **Buffer duration** in [**Codec settings**](#codec-settings) section is limited to **Short** and **Custom** values.|
|CVQ mode|Only available with **CVQ** rate control.<br/>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.<br/>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.<br/>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.<br/>In statmux each stream is encoded in VBR. Minimum bit rate defines the lowest bit rate limit.<br/>**Note:** This bit rate can be changed on-the-fly.|
|Maximum bit rate|Only available with **Statmux** or **VBR** rate control.<br/>In statmux, VBR or CVQ mode, each stream is encoded with variable bitrate. Maximum bit rate defines the highest bit rate limit.<br/>**Note:** This bit rate can be changed on-the-fly.|
|Target bit rate|Bandwidth used to encode the video stream.<br/>Possible values: From 100 to 60000 kbps<br/>**Note:**<br/>-   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\).<br/>-   This bit rate can be changed on-the-fly.|
|Resolution|Define the output size of each image (length x height).<br/>**Note:** Resolutions are sorted by the total number of pixels per frame.<br/> 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).<br/>**Note:**<br/>-   The list of available video quality modes depends on codec, rate control, export type and resolutions values.<br/>-   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.<br/>**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](../../../live-encoder/images/chunking_distribute.png )<br/>*Chunking policy: Distribute*![chunking merge](../../../live-encoder/images/chunking_merge.png)<br/>*Chunking policy: Merge*|

### Switch to CBR parameters

> **info:** 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.<br/>If enabled and configured, when you start the service new buttons are available in the [Services \> Statistics \> Outputs](/beam/live-encoder/monitor-statistics#outputs) menu:<br/>-   **Switch to CBR** to manually switch from Statmux to CBR.<br/>-   **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.<br/>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.<br/>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.<br/>**Note:** The video buffer is the standard VBV ([Video Buffering Verifier](/beam/live-encoder/leaky-bucket)), it guarantees the encoded stream doesn't overflow or underflow the decoder's buffer.<br/>Possible values: **Short**, **Standard**, **Long**, or **Custom**<br/>-   If **Low delay encoding** is activated, **Short** = 500 ms (for both Internet TV and IP TV)<br/>-   If **Low delay encoding** is not activated,<br/>**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.<br/>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.<br/>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.<br/>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.<br/>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).<br/>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.<br/>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.<br/>-   **Open** mode provides the best video quality.<br/>-   **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.<br/>Possible values for IPTV: 500 to 10000<br/>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.<br/>Possible values:<br/>-   **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<br/>-   **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<br/>-   **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**.<br/>Specify the cropping value in % of video from Top, Bottom, Right and Left.|
|Output aspect ratio|Only available with **Letterbox** and **Stretching**.<br/>Targeted output aspect ratio.|
|Zoom adjustment|Only available with **Letterbox**.<br/>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**.<br/>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.

> **info:** 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](../../../live-encoder/images/out_43_43.jpg)|4:3 Full|None|![out 43 43](../../../live-encoder/images/out_43_43.jpg)|
|![in 149 full](../../../live-encoder/images/in_149_full.jpg)|14:9 FullOnly available in PAL|Restore PAR and fit in letterbox|![out 149 43](../../../live-encoder/images/out_149_43.jpg)|
|![out 169 169](../../../live-encoder/images/out_169_169.jpg)|16:9 Full|Restore PAR and fit in letterbox|![out 43 169](../../../live-encoder/images/out_43_169.jpg)|
|![in 149 letterbox](../../../live-encoder/images/in_149_letterbox.jpg)|14:9 Letterbox (center)<br/>Only available in PAL|None|![out 149 43](../../../live-encoder/images/out_149_43.jpg)|
|![out 43 169LBC](../../../live-encoder/images/out_43_169LBC.jpg)|16:9 Letterbox (center)<br/>Only available in PAL|None|![out 43 169LBC](../../../live-encoder/images/out_43_169LBC.jpg)|
|![out 43 209LBC](../../../live-encoder/images/out_43_209LBC.jpg)|16:9 Letterbox (center)<br/>Only available in PAL|None|![out 43 209LBC](../../../live-encoder/images/out_43_209LBC.jpg)|
|![in 149 letterbox top](../../../live-encoder/images/in_149_letterbox_top.jpg)|14:9 Letterbox (top)<br/>Only available in PAL|None|![in 149 letterbox top](../../../live-encoder/images/in_149_letterbox_top.jpg)|
|Image Removed|16:9 Letterbox (top)<br/>Only available in PAL|None|Image Removed|
|![out 43 43](../../../live-encoder/images/out_43_43.jpg)|4:3 Full|None|![out 169 43](../../../live-encoder/images/out_169_43.jpg)|
|![in 149 full](../../../live-encoder/images/in_149_full.jpg)|14:9 Full Only available in PAL|Restore PAR and fit in letterbox|![out 149full 169](../../../live-encoder/images/out_149full_169.jpg)|
|![out 169 169](../../../live-encoder/images/out_169_169.jpg)|16:9 Full|Restore PAR and fit in letterbox|![out 169 169](../../../live-encoder/images/out_169_169.jpg)|
|![in 149 letterbox](../../../live-encoder/images/in_149_letterbox.jpg)|14:9 Letterbox (center)<br/>Only available in PAL|None|![out 169 169](../../../live-encoder/images/out_169_169.jpg)|
|![out 43 209LBC](../../../live-encoder/images/out_43_209LBC.jpg)|16:9 Letterbox (center)<br/>Only available in PAL|None|![out 169 209LBC](../../../live-encoder/images/out_169_209LBC.jpg)|
|![in 149 letterbox top](../../../live-encoder/images/in_149_letterbox_top.jpg)|16:9 Letterbox (center)<br/>Only available in PAL|None|![out 149letterboxtop 169](../../../live-encoder/images/out_149letterboxtop_169.jpg)|
|![in 149 letterbox top](../../../live-encoder/images/in_149_letterbox_top.jpg)|14:9 Letterbox (top)<br/>Only available in PAL|None|![out 149letterboxtop 169](../../../live-encoder/images/out_149letterboxtop_169.jpg)|

### 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](../../../live-encoder/images/in_crop_C_L_R_T.png)|![C4 iphone cropping dyn out](../../../live-encoder/images/C4-iphone-cropping-dyn-out.png)|
|Letter Boxing|Adaptation of input 16:9 to output 4:3 zoom level 0%|![out 169 169](../../../live-encoder/images/out_169_169.jpg)|![out 43 169](../../../live-encoder/images/out_43_169.jpg)|
|Letter Boxing|Adaptation of input 16:9 to output 4:3 zoom level 50%|![out 169 169](../../../live-encoder/images/out_169_169.jpg)|![C4 iphone cropping lbox out](../../../live-encoder/images/C4-iphone-cropping-lbox-out.png)|
|Stretch to fit|Crop Left, Right, Top, Bottom and Stretch|![in crop C L R T](../../../live-encoder/images/in_crop_C_L_R_T.png)|![C4 iphone cropping stretch out](../../../live-encoder/images/C4-iphone-cropping-stretch-out.png)|

## 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).<br/>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.<br/>Compliant with the EIA-608 standard.|
|Burn-in|This caption burnin configuration will be applied to the related video stream.<br/>Possible values: subtitle(s) burn-in defined in **Encoding** \> **Subtitle burn-in configuration** section (see [Configure subtitle burn-in](/beam/live-encoder/configure/encoding/subtitle-burnin-encoding)).|

## 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](#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.<br/>**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.<br/>**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](../../configure/encoding/video-encoding)

<!-- source: /beam/live-encoder/parameters/general.md -->

# 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: <br/>- *None*: Default mode, no hardware acceleration. <br/>- *Fully accelerated service*:  It corresponds to the legacy Hardware acceleration mode. <br/>- *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. <br/>- *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. <br/>**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.<br/>**Note:** To configure the ESAM out-of-band, go to the [**Input**](../configure/input/outofband-metadata) 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**.<br/>URL for the POIS (Placement Opportunity Information Service) (if any).|
|POIS network name|Only available with **ESAM**.<br/>ID shared with the POIS for the current channel.|
|POIS zone identity|Only available with **ESAM**.<br/>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<br/> -   **Multicast** is recommended for on-prem deployments.<br/> -   **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.<br/>**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.|

<!-- source: /beam/live-encoder/parameters/input/cross-stream-prevention.md -->

# 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.

> **info:** 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](../../../live-encoder/configure/input/cross-stream-prevention)

<!-- source: /beam/live-encoder/parameters/input/general.md -->

# 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.<br/>As for SDI, video and audio are extracted from the input stream.<br/>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.<br/>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<br/>**Note:** See [router configuration](/beam/system-admin/network/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.<br/>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.<br/>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.<br/>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.<br/>**Note:** Thanks to the Mellanox card connectX-6 Dx, Live Encoder benefits from the Rivermax library for ST 2110 ingest. It supports:<br/>-   ST 2110-20: HD Video-only<br/>-   ST 2110-30, ST 2110-31: Audio<br/>-   ST 2110-40: Data<br/>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.<br/>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)

<!-- source: /beam/live-encoder/parameters/input/live-and-file-source-management.md -->

# Live source & File source management

> **info:** 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.{/* NEEDS REVISION} To select an existing ID, you can either: set the focus on the empty input field then click to open the dropdown list, or type the first characters to get the matching IDs. */}|
|Default frame rate|Default frame rate used when live input is not yet detected.<br/>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.

<!-- source: /beam/live-encoder/parameters/input/metadata.md -->

# Metadata

## In-band metadata

|Parameter              |Description     |
|:----------------------|:---------------|
|Type|Input metadata expected format.{ /* TODO **Note:** {metadata_subtype.recommendations} */}|

### 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.<br/>Possible values: From 16 to 8190 or "auto"|
|Delay|If metadata stream is SCTE35, a delay adjusts the trigger time value.<br/>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.<br/>Possible values: From 0 to 65535|
|Delay|If metadata stream is SCTE35, a delay adjusts the trigger time value.<br/>Possible values: From 30000 to 60.000 ms|

**Related information**
[Configure in-band metadata in input stream](../../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.<br/>If **POIS** is selected, you have to enter the **POIS URL** and the **POIS network interface** name.<br/>**Note:** Configuration of POIS to recover is mandatory if:<br/>-   live service is restarted during EAS,<br/>-   or input dual source redundancy.<br/>-   or live service failover.<br/>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.<br/>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.<br/>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.<br/>Possible values: From 400 to 3600000|

**Related information**
[Configure out-of-band metadata in input stream](../../configure/input/outofband-metadata)
[Configure the input](../../configure/input)

<!-- source: /beam/live-encoder/parameters/input/source.md -->

# 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<br/>Only defined source addresses can be used to retrieve the multicast stream.|
|Port|Port used to capture the input stream<br/>Example: **1234**|
|IGMPv3 source filtering|IGMP source IP address. List of addresses allowed in IGMPv3 using a comma to separate.<br/>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.<br/>-   In dual FEC modes, statistics are displayed for both the column and row.<br/>![el stats dual fec mode](../../../live-encoder/images/el_stats_dual_fec-mode.png)|
|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.<br/>Possible values: From 1 to 65535|
|Major channel|The major channel number present in the VCT<br/>Possible values: From 1 to 99|
|Minor channel|The minor channel number present in the VCT<br/>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.<br/>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<br/>Only defined source addresses can be used to retrieve the multicast stream.|
|Port|Port used to capture the input stream<br/>Example: **1234**|
|IGMPv3 source filtering|IGMP source IP address. List of addresses allowed in IGMPv3 using a comma to separate.<br/>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: /beam/live-encoder/parameters/input/source-error-management.md -->

# 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.<br/>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&gt;Freeze frame management section (Media Processing tab).|
|Default frame rate|Default frame rate used when live input is not yet detected.<br/>Needs to be defined if **Slate if no source at start** is activated.|

<!-- source: /beam/live-encoder/parameters/input/subtitle.md -->

# 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<br/>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.<br/>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.<br/>Range: From 1 to 65535|

## ARIB B24

|Parameter              |Description     |
|:----------------------|:---------------|
|PID|Numerical identifier for subtitles track.<br/>Range: From 1 to 65535|

**Related information**
[Configure subtitle in input stream](/beam/live-encoder/configure/input/subtitle)

<!-- source: /beam/live-encoder/parameters/input/vanc.md -->

# VANC

> **info:** 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.<br/>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.<br/>Specifies the index to the DPI PID which will carry the resulting splice_info_sections.|
|Delay|Only available with **STCE-104** data type.<br/>If metadata stream is SCTE35, a delay adjusts the trigger time value.<br/>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)

<!-- source: /beam/live-encoder/parameters/input/video-and-audio.md -->

# 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.<br/>**Restriction:** PID is only configurable if **Input synchronization mode** is set to **PidLocked** mode.<br/>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.<br/>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.<br/>Select the stereo audio pair (Group/Pair).|
|Audio format|Only available with **Audio** type.<br/>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.<br/>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.<br/>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).<br/>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.<br/>Possible values: See [table below](#dolby-e-program-values).|
|Mode|Only available with **Aggregated audio** type.<br/>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.<br/>You can aggregate multiple SDI audio pairs to have up to 5.1 streams.<br/>Associate the Group/pairs **SDI (Gn Pn)** with **Left** and **Right** as needed by scrolling the menus.![Live SDI aggregated audio](../../../live-encoder/images/Live_SDI_aggregated_audio.png)|

#### 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.<br/>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).<br/>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.<br/>Possible values: See [table above](#dolby-e-program-values).|

### 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.<br/>Possible values: M, DM, ST, LtRt, 51, 71, 222, SGRP [See table below.](#channel-order-values)<br/>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](../../../live-encoder/images/el_input_audio_st2110_channelorder.png)|

#### 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.|

> **info:** -   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)

<!-- source: /beam/live-encoder/parameters/lineup.md -->

# 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<br/>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.<br/>**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.<br/>Possible values: From 1 to 1000|
|SDP File Location|Location of SDP file describing the input stream. Either a URL or a file location.<br/>**Note:** The **SDP File Location** must be specified when Live Encoder service is configured with [MediaComposer input type and an SMPTE ST 2110 source](/beam/live-encoder/configure/input/input-stream-source#configure-an-smpte-st-2110-input-with-sdp-files), but [if you are using NMOS](/beam/live-encoder/configure/input/input-stream-source#configure-an-smpte-st-2110-input-with-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.<br/>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.<br/>Possible values: From 1 to 65535|
|Stream Index|Index of stream within the SDP file. 1 is the first stream.<br/>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.<br/>Possible values: From 0 to 65535|
|Stream Index|Index of stream within the SDP file. 1 is the first stream.<br/>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.<br/>Possible values: From 1 to 1000|
|SDP File Location|Location of SDP file describing the input stream. Either a URL or a file location.****|

<!-- source: /beam/live-encoder/parameters/media-processing/audio-processing.md -->

# 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.<br/>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](#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<br/>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.<br/>Only available with NAES watermarking.|
|CBET SID|Linear watermarking insertion CBET source ID<br/>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.<br/>Only available with NAES watermarking.|
|CBET Check digits|Only available with CBET watermarking.<br/>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.<br/>Activate the CBET stepaside mode.<br/>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<br/>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<br/>Specifies whether the watermark engine overwrites existing NAES audio watermarks of the same type as the watermark that is currently proposed for insertion.<br/>-   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.<br/>-   If the mode is set to **Overwrite**, then the watermark engine replaces the original watermarks with the new one.<br/>|Only available with NAES watermarking.

#### 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.<br/>**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.<br/>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.<br/>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](../../configure/media-processing/audio-processing)

<!-- source: /beam/live-encoder/parameters/media-processing/video-processing.md -->

# Video processing

## Video prefiltering

|Parameter              |Description     |
|:----------------------|:---------------|
|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.<br/>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: {spatial_denoising_filter.range}|
|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: {diamond_denoising_filter.range}|
|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: {motion_compensated_temporal_filter.range}|

**Related information**
[Configure the video prefiltering](../../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.<br/>Possible values: **Auto**, **Force 16/9**, **Force 4/3**<br/>**Note:** See [Picture aspect ratio handling (Auto)](../encoding/video#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)<br/>Possible values: From 0 to 6 for SD, from 0 to 14 for HD<br/>**Note:** 0 means no adjustment.|

**Related information**
[Configure the video adjustment parameters](../../configure/media-processing/video-processing#video-adjustment)
[Output aspect ratio and cropping](../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](../../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`<br/>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](../../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&gt;Stream metadata settings). Choose Passthrough for the input stream timecode.|

**Related information**
[Configure video metadata](../../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](../../configure/media-processing/video-processing#video-watermarking)

<!-- source: /beam/live-encoder/parameters/output.md -->

# 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.<br/>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.<br/>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<br/>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](#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](#dash-if-cmaf-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.<br/>**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.<br/>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.<br/>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.<br/>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<br/>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.<br/>Port used to transport FEC information<br/>Range: From 1 to 65535|
|Column count|Only available if FEC is activated.<br/>Defines the horizontal size of the FEC matrix.<br/>Range: From 1 to 20|
|Row count|Only available if FEC is activated.<br/>Defines the vertical size of the FEC matrix.<br/>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.|

<!-- source: /beam/live-encoder/rate-control.md -->

{ /* 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](./images/Bitrate_cbr.jpg)
*CBR mode*

**Example**<br/>
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.

> **info:** 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**<br/>
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](./images/Bitrate_statmux.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**<br/>
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**<br/>
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](./images/Bitrate_Statmux_benefits.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.

> **info:** 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).

> **info:** 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](./parameters/encoding/video)

<!-- source: /beam/live-encoder/setup-sdi-card.md -->

# 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
    ```

> **info:** 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
    ```

<!-- source: /beam/multiplexer.md -->

# 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).

<!-- source: /beam/multiplexer/asi-card.md -->

# 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 <controller_vip>`

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 `[[[[<domain>]:]<bus>]:][<slot>][.[<func>]]`. The domain is optional, or only shown if various domains are present.

> **info:** 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](#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.

<!-- source: /beam/multiplexer/configure/bandwidth-policy-group.md -->

## 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](../images/view_output_stream_add_service_ts_sp.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](../images/view_output_stream_add_component_to_service.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](../monitor#bandwidth-policing) by clicking the <!-- non-renderable component stripped: PieChartIcon --> button on the Services page.

<!-- source: /beam/multiplexer/configure/descriptor.md -->

## Configuring a service descriptor

1.  Display services.

2.  Click <!-- non-renderable component stripped: EditIcon --> 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](../images/view_ts_service_descriptor_properties_sp.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 <!-- non-renderable component stripped: EditIcon -->. The transport stream parameters display.

3.  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](../images/view_ts_custom_descriptor_properties_sp.png)

<!-- source: /beam/multiplexer/configure/input.md -->

# 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.

> **info:** 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](../images/view_input_health_sp.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](../images/view_input_health_sp_button_highlight.png)

3.  Hover the mouse over the status for a source to display information.

    ![view input health details sp](../images/view_input_health_details_sp.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 <!-- non-renderable component stripped: LeftRightIcon --> to switch to the other input source.

    ![view manually switch input source sp](../images/view_manually_switch_input_source_sp.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](../images/view_switch_input_source_config_sp.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 <!-- non-renderable component stripped: LeftRightIcon --> 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](../images/view_auto_switch_input_source_config_sp.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 <!-- non-renderable component stripped: LeftRightIcon --> 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](../images/mux_input_content_panel.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](../images/mux_input_content_panel_plus.png)

2.  Fill the fields.

> **info:** 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](../images/mux_input_content_add.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](../images/new_input_loading.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](../images/mux_input_content_expanded.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](../images/mux_input_content_list_of_existing_sources.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](../images/mux_input_content_shared_source.png)

### Drag & Drop

> **info:** 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](../images/mux_input_content_drag_drop_1.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](../images/mux_input_content_drag_drop_2.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](../images/manage_inputs.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.

> **info:** Once loaded, the input-extracted information does not refresh automatically.

You can delete inputs:

-   by selecting **Delete Input**;
-   by clicking the **trash can** button.

> **info:** 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](../images/input_content_cant_delete.png)

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

<!-- source: /beam/multiplexer/configure/output.md -->

## Configuring a video output

A video output stream exists in the transport stream configuration. See [Configuring output transport stream elements](./transport-stream#configuring-output-transport-stream-elements) for more information.

1.  Display services.

2.  Click <!-- non-renderable component stripped: EditIcon --> 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](../images/view_ts_video_properties_sp.png)

## Configuring an audio output

1.  Display services.

2.  Click <!-- non-renderable component stripped: EditIcon --> 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](../images/view_ts_video_properties_sp.png)

<!-- source: /beam/multiplexer/configure/regional-statmux.md -->

# 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.

<!-- source: /beam/multiplexer/configure/remux.md -->

## Configuring Remux ECMs

1.  Display the services.

2.  Click <!-- non-renderable component stripped: EditIcon --> 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.

> **info:** 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](../images/move-remux-ecms.jpg)

    ![remux ecm properties](../images/remux-ecm-properties.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](../images/remux-by-cas.jpg)

    -   **Remux By PID**: Enter the incoming **Input PID** of the ECM to remux.

        ![remux by pid](../images/remux-by-pid.jpg)

    -   **Remux By Position**: Enter the **CA Descriptor position** of the incoming ECM to remux.<br/>
        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](../images/remux-by-position.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](../images/remux-ecm-private-data.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](../images/remux-ecm-alarm-settings.jpg)

14. Select the incoming source that contains the ECM to be remuxed.

    ![remux ecm source input](../images/remux-ecm-source-input.jpg)

<!-- source: /beam/multiplexer/configure/statmux-pool.md -->

## 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](../images/statmux-pools_running.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](../images/statmux-pools_tick-button-location.jpg)

    Both pools appear “active” on the second server.

    ![statmux pools active](../images/statmux-pools_active.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](../images/statmux-pools_single-pool.jpg)

The pool appears “active” on the first server.

![statmux pools active2](../images/statmux-pools_active2.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\).

<!-- source: /beam/multiplexer/configure/transport-stream.md -->

## Create an output transport stream (mux)

1.  Display services.

2.  Click **Add service** > **Multiplexing**.

    ![view add multiplexing new sp](../images/view_add_multiplexing_new_sp.png)

## Configure output transport stream elements

1.  Display services.

2.  Click <!-- non-renderable component stripped: EditIcon --> 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.

> **info:** Parameters, properties and options vary depending on the selected transport stream item.

    ![view configure ts sp](../images/view_configure_ts_sp.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](../images/view_output_stream_ts_sp.png)

> **info:** 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 <!-- non-renderable component stripped: EditIcon --> 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](../images/view_ts_actions_buttons_add_delete_filter_sp.png)

## Delete an element from the transport stream

1.  Display services.

2.  Click <!-- non-renderable component stripped: EditIcon --> to edit the service and display parameters. The transport stream parameters display.

3.  Click <!-- non-renderable component stripped: DeleteIcon --> to delete the item.

    ![view ts actions buttons add delete filter sp](../images/view_ts_actions_buttons_add_delete_filter_sp.png)

## Configure a service in the transport stream

1.  Display services.

2.  Click <!-- non-renderable component stripped: EditIcon --> 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](../images/view_output_conf_sp.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](../images/view_output_stream_ts_sp.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](../images/stream_processing_External_EIS_config.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](../images/view_scrambling_tab_sp.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](../images/view_scrambling_groups_sp.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](../images/view_scrambling_groups_configuration_sp.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](../images/view_scrambling_vendors_configuration_sp.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](../images/view_scrambling_groups_properties_sp.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](../images/view_scrambling_groups2_sp.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](../images/view_scrambling_groups2bis_sp.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](../images/view_scrambling_group_properties_ecm.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](../images/view_scrambling_add_emm_sp.png)

        The EMM stream is created.

        ![view output stream emm sp](../images/view_output_stream_emm_sp.png)

    2.  Add the EMMG vendor using the **Scrambling Vendors** tab in the EMM properties.

> **info:** 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](../images/view_scrambling_tab_sp.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](../images/view_scrambling_groups_sp.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](../images/view_scrambling_groups_configuration_fixedkey_sp.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](../images/view_scrambling_groups2_sp.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](../images/view_scrambling_groups2bis_sp.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](../images/view_scrambling_tab_sp.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](../images/view_scrambling_groups_sp.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](../images/view_scrambling_groups_configuration_biss-ca_sp.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

> **info:** 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](../images/view_scrambling_groups2_sp.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](../images/view_scrambling_groups2bis_sp.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.

> **info:** 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.

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

    ![view properties mux sp](../images/view_properties_mux_sp.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](../images/view_properties_output_sp.png)

4.  Configure **Tables** in the **PSI/SI** tab.

    ![view properties psi si sp](../images/view_properties_psi_si_sp.png)

5.  Add a TOT descriptor to the output service.

    ![view tot descriptor local time offset ts sp](../images/view_tot_descriptor_local_time_offset_ts_sp.png)

6.  Click **Add output** and configure components for **Service 1**.

    1.  Set the **Regenerate Descriptor** to **On**.

> **info:** 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](../images/view_input_conf_sp.png)

    ![view input conf sp sources](../images/view_input_conf_sp_sources.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](../images/view_input_pid_conf_sp.png)

    ![view output pid conf sp](../images/view_output_pid_conf_sp.png)

8.  Click **Add output** and configure components for **Service 3**.

> **info:** 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](../images/view_input_selection_mode_tag_sp.png)

    2.  Configure the **Audio Language** using the example parameters from the table above.

        ![view audio input selection mode tag sp](../images/view_audio_input_selection_mode_tag_sp.png)

    3.  Add a service descriptor to replace the existing descriptor with the new service type.

        ![view service descriptor sp](../images/view_service_descriptor_sp.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](../images/view_ts_sp.png)

        Changes are applied when saved.

9.  Click **Save and exit** to apply changes.

10. Assign a server to the service.

11. Click <!-- non-renderable component stripped: PlayIcon --> to start the transport stream.

The Status column shows **started**.

![view mux server selection sp](../images/view_mux_server_selection_sp.png)

<!-- source: /beam/multiplexer/configure/transport-stream-mode-for-outputs.md -->

# 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.

> **info:** 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](/beam/multiplexer/parameters/stream-processing) 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

> **info:** {/* Beam version 1.12 uses Multiplexer version 23.1. */}
    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](#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.

> **info:** 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.

<!-- source: /beam/multiplexer/configure/virtual-component.md -->

## 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 <!-- non-renderable component stripped: EditIcon --> 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](../images/view_ts_virtual_component_sp.png)

4.  You can then add a component descriptor as per any other service output.

<!-- source: /beam/multiplexer/interact.md -->

# 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: [https://kubernetes.io/docs/reference/kubectl/](https://kubernetes.io/docs/reference/kubectl/)

-   For more details about the usage of the k9s tool, please refer to the official documentation available here: [https://k9scli.io](https://k9scli.io)

## 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

<!-- non-renderable component stripped: TabItem -->
<!-- non-renderable component stripped: TabItem -->

## 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`

<!-- non-renderable component stripped: TabItem -->
<!-- non-renderable component stripped: TabItem -->

## 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

<!-- non-renderable component stripped: TabItem -->
<!-- non-renderable component stripped: TabItem -->

## 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.

> **info:** 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.

<!-- non-renderable component stripped: TabItem -->
<!-- non-renderable component stripped: TabItem -->

## 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 <microservice> -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
    ```

<!-- source: /beam/multiplexer/monitor.md -->

# 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 <!-- non-renderable component stripped: AlarmIcon --> icon in the **info** column.

    Depending on the severity of the alarm, the <!-- non-renderable component stripped: AlarmIcon --> 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](./images/Services-multiplexer-alarms.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

> **info:** 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 <!-- non-renderable component stripped: PieChartIcon --> icon in the **Stats** column.

> **info:** The <!-- non-renderable component stripped: PieChartIcon --> 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](./images/MFVP-SP-service-statistics-mux-graphs.png)

### Statistical bit rate allocation

> **info:** 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 <!-- non-renderable component stripped: PlayIcon --> 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](./images/MFVP-SP-service-statistics-statmux.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](./images/SparkSE-Stats-input.png "Service Statistics - Input page")

**Tip:** You can refresh the statistics displayed by clicking the ![Stats AutoRefresh button](./images/Stats-AutoRefresh-button.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](./images/MFVP-SP-BPC-stat_graph2.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](./images/MFVP-SP-BPC-stat_table.png)

**Tip:** You can refresh the statistics displayed by clicking the ![Stats AutoRefresh button](./images/Stats-AutoRefresh-button.png) button.

<!-- source: /beam/multiplexer/parameters.md -->

# 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.

<!-- source: /beam/multiplexer/parameters/scrambling.md -->

# Scrambling Tab

This tab allows to enable scrambling via external Eis.

By default, scrambling via Eis is disabled for multiplexing services.

![Mux Scrambling Tab](../images/Mux_Scrambling-Tab.png)

To enable scrambling via External Eis tick the corresponding box.

> **info:** 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](../images/Mux_Scrambling-Tab_scrambling-group.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](../images/Mux_Scrambling-Tab_scrambling-vendors.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](../images/Mux_Scrambling-Tab_scrambling-vendors_ECMG.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](../images/Mux_Scrambling-Tab_scrambling-vendors_ECMG_advanced.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](../images/Mux_Scrambling-Tab_scrambling-vendors_EMMG.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](../images/Mux_Scrambling-Tab_scrambling-vendors_EMMG_stream_config.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](../images/Mux_Scrambling-Tab_scrambling-vendors_EMMG_advanced.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](../images/Mux_Scrambling-Tab_scrambling-vendors_ECMG_override.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 start*and *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 start*and *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](../images/Mux_Scrambling-Tab_scrambling-vendors_PDG.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](../images/Mux_Scrambling-Tab_scrambling-vendors_PDG_stream_config.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|

<!-- source: /beam/multiplexer/parameters/statmux.md -->

# 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](../images/Mux_Statmux-Tab.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](../images/Mux_Statmux-Tab_advanced.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|

> **info:** For encoding live service names to be showed in the statmux statistics page, tick the [**Service name in profile name**](../../live-encoder/parameters/encoding/video#general-parameters) 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|

<!-- source: /beam/multiplexer/parameters/stream-processing.md -->

# Stream Processing tab

## Transport Stream properties

### Mux Parameters

![Mux SP Tab Transport Stream Properties Mux](../images/Mux_SP-Tab_Transport-Stream-Properties_Mux.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.<br/>Note that a VBR TS will be invalid if it contains multiple referenced PCR PIDs.<br/>The TS mode for ASI outputs is always CBR.<br/>See [Configuring the transport stream mode for IP outputs](/beam/multiplexer/configure/transport-stream-mode-for-outputs/#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.<br/>See [Controlling latency for VBR TS IP outputs](/beam/multiplexer/configure/transport-stream-mode-for-outputs/#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.<br/>See [Controlling latency for VBR TS IP outputs](/beam/multiplexer/configure/transport-stream-mode-for-outputs/#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](../images/Mux_SP-Tab_Transport-Stream-Properties_Output.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.<br/>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.<br/>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](../images/Mux_SP-Tab_Transport-Stream-Properties_Output_ASI.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](../asi-card#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](../images/Mux_SP-Tab_Transport-Stream-Properties_Output_RIST.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](../images/Mux_SP-Tab_Transport-Stream-Properties_PSI-SI.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](../images/Mux_SP-Tab_Transport-Stream-Properties_BP.png)

Use the **Add Group** button to add as many groups as needed.

Use the <!-- non-renderable component stripped: DeleteIcon --> 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](../images/Mux_SP-Tab_TOT.png)

### NIT

![Mux SP Tab NIT](../images/Mux_SP-Tab_NIT.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](../images/Mux_SP-Tab_services_output.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).<br/>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](../images/Mux_SP-Tab_services_output_passthrough.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.

> **info:** 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](../images/Mux_SP-Tab_services_output_sources.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|

> **info:** Configuration of RIST inputs is only available via the **Properties** panel.

<!-- source: /beam/packager.md -->

# 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).

<!-- source: /beam/packager/advanced-parameters.md -->

# 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" : "https://mk-cr8-poc.s3.us-east.cloud-object-storage.appdomain.cloud", "accessKeyId" : "e45d9e87d91421f2f3c69fca4c", "secretAccessKey":"236e8cc37c9ccc355b9ffb17fe8"} ]
```

#### 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" : "https://mk-cr8-poc.s3.us-east.cloud-object-storage.appdomain.cloud", "accessKeyId" : "e45d9e87d91421f2f3c69fca4c", "secretAccessKey":"236e8cc37c9ccc355b9ffb17fe8"}
  ]
```

### 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.

> **info:** The selected credentials configuration is logged into the high-level logs of the job.

<!-- source: /beam/packager/catalog.md -->

# 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

> **warning:** 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.

<!-- source: /beam/packager/enable-packager.md -->

# 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 <!-- non-renderable component stripped: ViewIcon --> 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.

<!-- source: /beam/packager/hls-dash-over-cmaf-output.md -->

# 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](./parameters/hls-or-dash-over-cmaf)
-   [DASH Manifests](./parameters/hls-or-dash-over-cmaf#dash)
-   [HLS Playlists](./parameters/hls-or-dash-over-cmaf#hls)
-   [Delivery](./parameters/hls-or-dash-over-cmaf#delivery)
-   [Encryption](./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](./images/MFVP_stream_char_filtering_bitrate.png)

-   Codec (H.264 or HEVC) - for the Video streams filter.

    ![MFVP stream char filtering codec](./images/MFVP_stream_char_filtering_codec.png)

-   Language (H.264 or HEVC) - for the audio streams filter.

    ![MFVP stream char filtering language](./images/MFVP_stream_char_filtering_language.png)

-   Width (pixels) or Height (pixels) for the Thumbnail streams filter.

    ![MFVP stream char filtering thumbnail](./images/MFVP_stream_char_filtering_thumbnail.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](./images/MFVP_stream_char_filtering_bitrate.png)

-   Codec (H.264 or HEVC) - for the Video streams filter.

    ![MFVP stream char filtering codec](./images/MFVP_stream_char_filtering_codec.png)

-   Language (H.264 or HEVC) - for the audio streams filter.

    ![MFVP stream char filtering language](./images/MFVP_stream_char_filtering_language.png)

-   Width (pixels) or Height (pixels) for the Thumbnail streams filter.

    ![MFVP stream char filtering thumbnail](./images/MFVP_stream_char_filtering_thumbnail.png)

## Delivery

You can define **Access URL** for playlist, manifests and segments.

For more details, see [Delivery](./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](./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.

<!-- source: /beam/packager/hls-output.md -->

# 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](./parameters/hls-over-ts#general)
-   [HLS playlists](./parameters/hls-over-ts#hls)
-   [Delivery](./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](./images/MFVP_stream_char_filtering_bitrate.png)

-   Codec (H.264 or HEVC) - for the Video streams filter.

    ![MFVP stream char filtering codec](./images/MFVP_stream_char_filtering_codec.png)

-   Language (H.264 or HEVC) - for the audio streams filter.

    ![MFVP stream char filtering language](./images/MFVP_stream_char_filtering_language.png)

-   Width (pixels) or Height (pixels) for the Thumbnail streams filter.

    ![MFVP stream char filtering thumbnail](./images/MFVP_stream_char_filtering_thumbnail.png)

## Delivery

You can define **Access URL**.

For more details, see [Delivery](./parameters/hls-over-ts#delivery).

## Content replacement

This feature is not currently used in MK.IO Beam.

<!-- source: /beam/packager/https-output.md -->

# 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#enable-customer-signed-ssl-certificates).

You can access packaged HTTPS output on port 8443 with the same URL path as used for HTTP access.

<!-- source: /beam/packager/live-packaging-service.md -->

# 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](./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](./catalog#adding-an-output-to-a-catalog)).
-   A Live Packaging service that:
    -   contains at least one source and a publishing point ([DVR](./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 <!-- non-renderable component stripped: PlayOutlineIcon --> 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

> **warning:** 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 <!-- non-renderable component stripped: StopOutlineIcon --> 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 <!-- non-renderable component stripped: DeleteIcon --> in the **Actions** column has different behaviors and results.

> **warning:** A Live Packaging service with the <!-- non-renderable component stripped: PlayOutlineIcon --> (started) status cannot be deleted. Click the <!-- non-renderable component stripped: StopOutlineIcon --> 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.

<!-- source: /beam/packager/monitor-packager.md -->

# 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 <!-- non-renderable component stripped: AlarmIcon --> icon in the **info** column.

    Depending on the severity of the alarm, the <!-- non-renderable component stripped: AlarmIcon --> will appear in different colors and will display the most severe color alarm in case of multiple alarms.

    - <!-- non-renderable component stripped: AlarmRedIcon -->: critical alarm
    - <!-- non-renderable component stripped: AlarmYellowIcon -->: major alarm
    - <!-- non-renderable component stripped: AlarmGreenIcon -->: minor alarm

The following page displays.

![Services liveencoding alarms](./images/Services-liveencoding-alarms.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.

> **info:** 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.

<!-- source: /beam/packager/parameters/hls-or-dash-over-cmaf.md -->

# HLS or DASH over CMAF

Below are the parameters accessed in the **HLS or DASH over CMAF** output.

## General

### General

|Parameter       |Description     |
|:---------------|:---------------|
|{tooltips["Cat_table_output-name"].label}|{tooltips["Cat_table_output-name"].description}. The name you want to use for the output.|
|{tooltips["Cat_adv-param_naming-scheme"].label}|{tooltips["Cat_adv-param_naming-scheme"].description}|
|{tooltips["Cat_adv-param_trunv1"].label}|{tooltips["Cat_adv-param_trunv1"].description}|
|Enable thumbnails|Enable thumbnails generation|

**Related information**
[HLS or DASH over CMAF output configuration](../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. { /* Your comment here Default value is **Recommendation:** If a filtering has been applied to the manifest/playlist, it is recommended to use a name that clearly identifies the defined filtering.*/ }<br/>**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|

## 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).<br/>**Recommendation:** If a filtering has been applied to the manifest/playlist, it is recommended to use a name that clearly identifies the defined filtering.|{ /* Name of the manifest/playlist generated for the current output.  */ }|

**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     |
|:---------------|:---------------|
|{tooltips["Cat_publishing_access-url"].label}|{tooltips["Cat_publishing_access-url"].description} <br/>Prefer URI unreserved characters (alphanumerical characters plus (, ), -, \_, .). Declaring a subpath (a/b) is possible but may impact performance.<br/>Example: `https://[Server IP or FQDN]/packaging/[Output Access URL]/[Live Packaging Service Access URL]/[index.m3u8 OR manifest OR manifest.mpd]`{ /* Replace when Recommendation will be ok **Recommendation:** {tooltips["Cat_publishing_access-url"].recommendations}*/ }|

## Common encryption (CENC)

###  Fixed key generation mode

|Parameter       |Description     |
|:---------------|:---------------|
|{tooltips["Cat_scramb_encryp_key"].label}|{tooltips["Cat_scramb_encryp_key"].description}|
|{tooltips["Cat_scramb_encryp_key-id"].label}|{tooltips["Cat_scramb_encryp_key-id"].description}|
|{tooltips["Cat_scramb_encryp_enable-playready"].label}|{tooltips["Cat_scramb_encryp_enable-playready"].description}|
|{tooltips["Cat_scramb_encryp_enable-widevine"].label}|{tooltips["Cat_scramb_encryp_enable-widevine"].description}|
|{tooltips["Cat_scramb_encryp_enable-fairplay"].label}|{tooltips["Cat_scramb_encryp_enable-fairplay"].description}|

PlayReady mode enabled:
|Parameter       |Description     |
|:---------------|:---------------|
|{tooltips["Cat_scramb_encryp_lic-acq-url"].label}|{tooltips["Cat_scramb_encryp_lic-acq-url"].description}|
|{tooltips["Cat_scramb_encryp_lic-ui-url"].label}|{tooltips["Cat_scramb_encryp_lic-ui-url"].description}|
|{tooltips["Cat_scramb_encryp_domain-service-id"].label}|{tooltips["Cat_scramb_encryp_domain-service-id"].description}|

Widevine mode enabled:
|Parameter       |Description     |
|:---------------|:---------------|
|{tooltips["Cat_scramb_encryp_provider"].label}|{tooltips["Cat_scramb_encryp_provider"].description}|
|{tooltips["Cat_scramb_encryp_policy"].label}|{tooltips["Cat_scramb_encryp_policy"].description}|

### Compatible CPIX ext. key

|Parameter       |Description     |
|:---------------|:---------------|
|{tooltips["Cat_scramb_encryp_key-server-url"].label}|{tooltips["Cat_scramb_encryp_key-server-url"].description}|
|{tooltips["Cat_scramb_encryp_enable-playready"].label}|{tooltips["Cat_scramb_encryp_enable-playready"].description}|
|{tooltips["Cat_scramb_encryp_enable-widevine"].label}|{tooltips["Cat_scramb_encryp_enable-widevine"].description}|
|{tooltips["Cat_scramb_encryp_enable-fairplay"].label}|{tooltips["Cat_scramb_encryp_enable-fairplay"].description}|
|{tooltips["Cat_scramb_encryp_enable-mediaroom"].label}|{tooltips["Cat_scramb_encryp_enable-mediaroom"].description}|
|Clearkey|Enables Clearkey encryption.|

**Key usage rules**
|Parameter       |Description     |
|:---------------|:---------------|
|{tooltips["Cat_track_filters_table_header"].label}/{tooltips["Cat_track_filtering_dialog"].label}|{tooltips["Cat_track_filtering_dialog"].description}|
|{tooltips["Cat_track_type_dialog"].label}|{tooltips["Cat_track_type_dialog"].description}|
|{tooltips["Cat_track_labels_dialog"].label}|{tooltips["Cat_track_labels_dialog"].description}|
|{tooltips["Cat_encryption_disable_audio_encryption"].label}|{tooltips["Cat_encryption_disable_audio_encryption"].description}|

## Common encryption (CBCS)

### Fixed key generation mode

|Parameter       |Description     |
|:---------------|:---------------|
|{tooltips["Cat_scramb_encryp_key"].label}|{tooltips["Cat_scramb_encryp_key"].description} Unit: hexadecimal.|
|{tooltips["Cat_scramb_encryp_iv"].label}|{tooltips["Cat_scramb_encryp_iv"].description}|
|{tooltips["Cat_scramb_encryp_key-id"].label}|{tooltips["Cat_scramb_encryp_key-id"].description}|
|{tooltips["Cat_scramb_encryp_enable-playready"].label}|{tooltips["Cat_scramb_encryp_enable-playready"].description}|
|{tooltips["Cat_scramb_encryp_enable-widevine"].label}|{tooltips["Cat_scramb_encryp_enable-widevine"].description}|
|Fairplay|{tooltips["Cat_scramb_encryp_enable-fairplay"].description}|

PlayReady mode enabled:
|Parameter       |Description     |
|:---------------|:---------------|
|{tooltips["Cat_scramb_encryp_lic-acq-url"].label}|{tooltips["Cat_scramb_encryp_lic-acq-url"].description}|
|{tooltips["Cat_scramb_encryp_lic-ui-url"].label}|{tooltips["Cat_scramb_encryp_lic-ui-url"].description}|
|{tooltips["Cat_scramb_encryp_domain-service-id"].label}|{tooltips["Cat_scramb_encryp_domain-service-id"].description}|

Widevine mode enabled:
|Parameter       |Description     |
|:---------------|:---------------|
|{tooltips["Cat_scramb_encryp_provider"].label}|{tooltips["Cat_scramb_encryp_provider"].description}|
|{tooltips["Cat_scramb_encryp_policy"].label}|{tooltips["Cat_scramb_encryp_policy"].description}|

Fairplay mode enabled:
|Parameter       |Description     |
|:---------------|:---------------|
|{tooltips["Cat_scramb_encryp_lic-acquisit-url"].label}|{tooltips["Cat_scramb_encryp_lic-acquisit-url"].description}|
|{tooltips["Cat_scramb_encryp_key-format"].label}|{tooltips["Cat_scramb_encryp_key-format"].description}|

**Key usage rules**
|Parameter       |Description     |
|:---------------|:---------------|
|{tooltips["Cat_encryption_disable_audio_encryption"].label}|{tooltips["Cat_encryption_disable_audio_encryption"].description}|

### Compatible CPIX ext. key

|Parameter       |Description     |
|:---------------|:---------------|
|{tooltips["Cat_scramb_encryp_key-serv-url"].label}|{tooltips["Cat_scramb_encryp_key-serv-url"].description}|
|{tooltips["Cat_scramb_encryp_enable-playready"].label}|{tooltips["Cat_scramb_encryp_enable-playready"].description}|
|{tooltips["Cat_scramb_encryp_enable-widevine"].label}|{tooltips["Cat_scramb_encryp_enable-widevine"].description}|
|Fairplay|Enables Fairplay encryption.|
|{tooltips["Cat_scramb_encryp_enable-mediaroom"].label}|{tooltips["Cat_scramb_encryp_enable-mediaroom"].description}|
|Clearkey|Enables Clearkey encryption.|

**Key usage rules**
|Parameter       |Description     |
|:---------------|:---------------|
|{tooltips["Cat_track_filters_table_header"].label}/{tooltips["Cat_track_filtering_dialog"].label}|{tooltips["Cat_track_filtering_dialog"].description}|
|{tooltips["Cat_track_type_dialog"].label}|{tooltips["Cat_track_type_dialog"].description}|
|{tooltips["Cat_track_labels_dialog"].label}|{tooltips["Cat_track_labels_dialog"].description}|
|{tooltips["Cat_encryption_disable_audio_encryption"].label}|{tooltips["Cat_encryption_disable_audio_encryption"].description}|

**Related information**
[HLS or DASH over CMAF output configuration](../hls-dash-over-cmaf-output)
[HLS over TS output configuration](../hls-output)

<!-- source: /beam/packager/parameters/hls-over-ts.md -->

# HLS over TS

Below are the parameters accessed in the **HLS over TS** output:
## General

|Parameter       |Description     |
|:---------------|:---------------|
|{tooltips["Cat_table_output-name"].label}|{tooltips["Cat_table_output-name"].description}. The name you want to use for the output.|
|{tooltips["Cat_adv-param_naming-scheme"].label}|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. { /* Your comment here Default value is **Recommendation:** If a filtering has been applied to the manifest/playlist, it is recommended to use a name that clearly identifies the defined filtering.*/ }<br/>**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     |
|:---------------|:---------------|
|{tooltips["Cat_publishing_access-url"].label}|{tooltips["Cat_publishing_access-url"].description} <br/>Prefer URI unreserved characters (alphanumerical characters plus (, ), -, \_, .). Declaring a subpath (a/b) is possible but may impact performance.<br/>Example: `https://[Server IP or FQDN]/packaging/[Output Access URL]/[Live Packaging Service Access URL]/[index.m3u8 OR manifest OR manifest.mpd]`{ /* Replace when Recommendation will be ok **Recommendation:** {tooltips["Cat_publishing_access-url"].recommendations}*/ }|

**Related information**
[HLS or DASH over CMAF output configuration](../hls-dash-over-cmaf-output)
[HLS over TS output configuration](../hls-output)

<!-- source: /beam/packager/parameters/live.md -->

#  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.|
|{tooltips["Cat_publishing_access-url"].label}|{tooltips["Cat_publishing_access-url"].description}<br/>Prefer URI unreserved characters (alphanumerical characters plus (, ), -, _, .). Declaring a subpath (a/b) is possible but may impact performances.{ /* TODO: remove comment with recommendations will be imported) **Recommendation:** {tooltips["Cat_publishing_access-url"].Recommendations}*/ }|

**Related information**
[Live Packaging configuration](../live-packaging-service)

<!-- source: /beam/packager/parameters/settings.md -->

# Packager settings

Below are the parameters accessed in the Packager settings.

## Credentials

### User type

|Parameter              |Description     |
|:----------------------|:---------------|
|{tooltips["Set_credential_url"].label}|{tooltips["Set_credential_url"].description}|
|{tooltips["Set_credential_username"].label}|{tooltips["Set_credential_username"].description}|
|{tooltips["Set_credential_passw"].label}|{tooltips["Set_credential_passw"].description}|

### Crypto type

|Parameter              |Description     |
|:----------------------|:---------------|
|{tooltips["Set_credential_url"].label}|{tooltips["Set_credential_url"].description}|
|{tooltips["Set_credential_key_seed"].label}|{tooltips["Set_credential_key_seed"].description}|

<!-- source: /beam/packager/thumbnails.md -->

# 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](./hls-dash-over-cmaf-output).

    - You can also configure the thumbnail streams filtering for your manifests for [DASH](./hls-dash-over-cmaf-output) and [HLS](./hls-output) outputs.

<!-- source: /beam/quick-start.md -->

# Quick start

> **warning:** 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

> **info:** 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

> **info:** 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://<Control-IP-Address>`, where `<Control-IP-Address>` 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).

<!-- source: /beam/receiver.md -->

# Receiving and Decoding

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](/beam/receiver/output/ts-passthrough). |
|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 <!-- non-renderable component stripped: EditIcon --> 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).

<!-- source: /beam/receiver/decoding.md -->

# 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 <!-- non-renderable component stripped: EditIcon --> 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.

> **info:** It may be necessary to configure the correct [Configuration Type](/beam/receiver/#receiver-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** <!-- non-renderable component stripped: EditIcon --> page or by viewing the **Stats**
<!-- non-renderable component stripped: ChartIcon --> 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](#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

> **info:** 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](#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](#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](#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 <!-- non-renderable component stripped: DeleteIcon --> icon on the audio decode entry.

### Decode All Input Audio

To add audio entries for all detected audio components in the configured [Service Selection](#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](#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](#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](#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.

> **info:** 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

> **info:** 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](#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](#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](#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 <!-- non-renderable component stripped: DeleteIcon --> icon on the data decode entry.

### Decode All Input Data

To add data entries for all detected data components in the configured [Service Selection](#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](#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.

<!-- source: /beam/receiver/decoding/paa.md -->

# 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

> **info:** Automatic selection of PAA components for a configured [Service Selection](/beam/receiver/decoding/#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](#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.

<!-- source: /beam/receiver/decryption.md -->

# 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)

<!-- source: /beam/receiver/decryption/biss-ca-decryption.md -->

{ /* TODO: update links (contact information once MD files are created */}

# BISS-CA Decryption

> **warning:** 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](#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 <!-- non-renderable component stripped: Fa --> **Appliance** section from the Beam web UI (see [Display BISS-CA key pairs table](#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 <!-- non-renderable component stripped: Fa --> **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.](#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](#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](#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

> **warning:** 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](./biss-ca-entitlements)).

To remove a stored key pair, follow these steps:

1.  [Display BISS-CA Key Pairs Table.](#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

### 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 <!-- non-renderable component stripped: Fa --> **Home** page, select the RECEIVER item from the required feed then click <!-- non-renderable component stripped: EditIcon --> 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 <!-- non-renderable component stripped: Fa --> **Home** page, select the RECEIVER item from the required feed then click <!-- non-renderable component stripped: EditIcon --> 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.

<!-- source: /beam/receiver/decryption/biss-ca-entitlements.md -->

# 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](./biss-ca-decryption#managing-biss-ca-keys).

To get the correct entitlements, follow these steps:

<!-- non-renderable component stripped: WorkflowCards -->

## 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

<!-- non-renderable component stripped: TabItem -->
<!-- non-renderable component stripped: TabItem -->

## Step #3 - Check authorization

1.  [Enable BISS-CA decryption for service decode](./biss-ca-decryption#enable-biss-ca-decryption-for-service-decode).

2.  From the <!-- non-renderable component stripped: Fa --> **Services** page, click <!-- non-renderable component stripped: AlarmIcon --> 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.

> **info:** It may be necessary to refer to the EKID value, see [Managing BISS-CA keys](./biss-ca-decryption#managing-biss-ca-keys).

<!-- source: /beam/receiver/decryption/biss-decryption-modes.md -->

# 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<br/>Mode E                      |DVB-CSA             |48 bits    |
|BISS2                 |Mode 1<br/>Mode E<br/>Mode CA (BISS-CA)|DVB-CISSA           |128 bits   |

For details on BISS-CA, refer to the [BISS-CA 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

> **info:** 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 <!-- non-renderable component stripped: EditIcon --> to edit

2.  Select the **Decrypt** tab in the **Parameters** window.

3.  Select **Mode 1** for [**BISS mode**](../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

> **info:** 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 <!-- non-renderable component stripped: EditIcon --> to edit

2.  Select the **Decrypt** tab in the **Parameters** window.

3.  Select **Mode E** for [**BISS mode**](../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.

5.  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.

<!-- source: /beam/receiver/decryption/common-interface-module.md -->

# 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.

> **info:** 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.

> **info:** 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 <!-- non-renderable component stripped: EditIcon --> 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 <!-- non-renderable component stripped: EditIcon --> 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.

> **info:** 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](#explore-cam-information) and [resetting the CAM](#reset-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 <!-- non-renderable component stripped: EditIcon --> 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):

        <!-- non-renderable component stripped: TabItem -->
            <!-- non-renderable component stripped: TabItem -->

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.

> **warning:** 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.

1.  From the **Home** page, select the RECEIVER item from the required feed then click <!-- non-renderable component stripped: EditIcon --> to edit

2.  From the **Parameters** window, select the **Decrypt** tab.

3.  Click the **DVB-CI** tab.

5.  Select the required CAM according to the [Receiver Configuration Type](/beam/receiver/#receiver-configuration-type):

        <!-- non-renderable component stripped: TabItem -->
            <!-- non-renderable component stripped: TabItem -->

6.  Click the **Reset CAM in Slot** button to reset the CAM

<!-- source: /beam/receiver/decryption/director.md -->

# 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](#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)

> **warning:** 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 <!-- non-renderable component stripped: EditIcon --> 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 <!-- non-renderable component stripped: EditIcon --> 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 <!-- non-renderable component stripped: EditIcon --> 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.

<!-- source: /beam/receiver/decryption/over-air-control.md -->

# 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.

> **info:** 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](/beam/receiver/decryption/director#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.

> **info:** 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 <!-- non-renderable component stripped: EditIcon --> 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.

> **info:** A receiver service in a **running** state must be assigned a **unique Director hardware ID**.

> **info:** 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 <!-- non-renderable component stripped: EditIcon --> 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.

<!-- source: /beam/receiver/input.md -->

# 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 <!-- non-renderable component stripped: EditIcon -->.

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:

    <!-- non-renderable component stripped: TabItem -->
        <!-- non-renderable component stripped: TabItem -->

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 <!-- non-renderable component stripped: Fa --> **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 <!-- non-renderable component stripped: EditIcon --> 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 <!-- non-renderable component stripped: EditIcon --> 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 <!-- non-renderable component stripped: EditIcon --> 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)

> **info:** 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).

<!-- source: /beam/receiver/input/input-redundancy.md -->

# 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 <!-- non-renderable component stripped: EditIcon -->
    to edit.

2.  Select the **Input** tab under the *Parameters* section.

3.  Select the desired **Redundancy mode** [option](#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.

> **info:** 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**.

> **info:** 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 <!-- non-renderable component stripped: EditIcon -->
    to edit (or click <!-- non-renderable component stripped: ChartIcon --> to view the Statistics page).

2.  Locate the **Input Status** section of the page and click the **Switch Input**
    icon <!-- non-renderable component stripped: LeftRightIcon -->.

    ![Click Switch Input button](/rx1-img/receiver-input-redundancy-switch-input.png )

<!-- source: /beam/receiver/output.md -->

# 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:<br/>- SDI output (all video formats)<br/>- SMPTE ST 2022-6 output (all video formats)<br/>- SMPTE ST 2110 output (SD/HD video formats)|Recommended|
|SMPTE ST 2110 UHD Output |Mandatory for:<br/>- 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 <!-- non-renderable component stripped: Fa --> **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.

<!-- source: /beam/receiver/output/3g-sdi.md -->

# 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.

> **info:** 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 <!-- non-renderable component stripped: EditIcon --> 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.

<!-- source: /beam/receiver/output/audio.md -->

# 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.

1.  Select the **RECEIVER** item from the required feed then click <!-- non-renderable component stripped: EditIcon -->.

2.  From the **Parameters** section, select **Output** to display options.

3.  Go to the **Audio** tab to open the tab and display options then select **Add component**. An audio component displays.

4.  Configure audio output parameters.

> **info:** 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 <!-- non-renderable component stripped: EditIcon -->.

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 <!-- non-renderable component stripped: EditIcon -->.

2.  From the **Parameters** section, select **Output** to display options.

3.  Go to the **Audio** tab then click <!-- non-renderable component stripped: DeleteIcon --> 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 <!-- non-renderable component stripped: EditIcon -->.

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 <!-- non-renderable component stripped: EditIcon -->.

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.

> **info:** -   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   |

<!-- source: /beam/receiver/output/clock.md -->

# 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.

> **warning:** 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 <!-- non-renderable component stripped: EditIcon -->.

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).

> **info:** For further information on options, see [SDI output parameters and status](../parameters#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.

> **info:** **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 <!-- non-renderable component stripped: EditIcon -->.

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.

<!-- source: /beam/receiver/output/data.md -->

# 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

> **info:** See [output parameters](../parameters#sdi-output-parameters-and-status) 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 <!-- non-renderable component stripped: EditIcon -->.

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.

> **info:** 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 <!-- non-renderable component stripped: EditIcon -->.

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.

<!-- source: /beam/receiver/output/hd-downconvert.md -->

# 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.

> **info:** 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 <!-- non-renderable component stripped: EditIcon --> 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.

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

<!-- source: /beam/receiver/output/hdr-sdr.md -->

# 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 <!-- non-renderable component stripped: EditIcon -->.

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](./images/receiver-decoding-video-hdr-to-sdr.png)

5.  Click **Save and continue** to save your changes.

> **info:** -   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](#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 <!-- non-renderable component stripped: Fa --> **Appliance** from the left-hand side menu.

2.  Click the **HDR > SDR Conversion** tab.

    ![hdr sdr conversion tab](./images/hdr-sdr-conversion-tab.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:<br/>-  **Update**: Any modifications must be saved by using this button<br/>-  **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 <!-- non-renderable component stripped: Fa --> **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](#configuring-hdr-to-sdr-conversion) section for more information.

### Uploading Custom LUTs

To upload additional LUTs, follow these steps:

1.  Select <!-- non-renderable component stripped: Fa --> **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.

4.  Click the **Description** testbox to add a unique description of the LUT so that it can be easily
    referenced when enabling *Dynamic Range Conversion*.

5.  Enable or disable the **Input Full Range** setting as required.

6.  Enable or disable the **Output Full Range** setting as required.

5.  Once the settings are complete, click the **Upload** button to store the custom LUT on the device.

    ![hdr sdr conversion tab](./images/hdr-sdr-conversion-tab-upload.png)

<!-- source: /beam/receiver/output/multiple-outputs.md -->

# 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 <!-- non-renderable component stripped: EditIcon -->.

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`.

<!-- source: /beam/receiver/output/scte35-to-scte104.md -->

# 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.

> **info:** 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.<br/>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 <!-- non-renderable component stripped: EditIcon --> 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](#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.

<!-- non-renderable component stripped: Accordion -->

### Configuring Event ID filtering

To configure the Event ID filter:

1.  Enable Splicing by following [Configuring SCTE-104 output](#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.

<!-- source: /beam/receiver/output/sdi.md -->

# 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 <!-- non-renderable component stripped: Fa --> **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 <!-- non-renderable component stripped: Fa --> **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.

> **warning:** 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 <!-- non-renderable component stripped: EditIcon -->.

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 <!-- non-renderable component stripped: AddIcon --> 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

3.  Select the **SDI port** required from the drop down menu.

    ![rx1 receiver output sdi](/rx1-img/rx1_receiver_output_sdi.png)

4.  Select any required video options as detailed in the
    [SDI output parameters](../parameters#sdi-output-parameters-and-status) section

> **info:** 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](#configuring-asisdi-mode)** section to update the setting.

<!-- source: /beam/receiver/output/sdr-hdr.md -->

# 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.

> **info:** 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<br/>signalled on the output | Color standard<br/>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 |

> **info:** 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](/beam/receiver/output/hdr-sdr)
    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 <!-- non-renderable component stripped: EditIcon --> 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](#dynamic-range-signalling-settings)**
    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.

<!-- source: /beam/receiver/output/smpte-st-2022-6.md -->

# 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 <!-- non-renderable component stripped: EditIcon -->.
1. Check that the **Configuration type** is **SD/HD.**
1. In the **Parameters** window, select the **Output** tab.
1. 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.

> **info:** See [video](/beam/receiver/parameters#smpte-st-2022-6-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.

> **info:** 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.
1. 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).
1. 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.

> **info:** A single embedded channel is required to output stereo audio.

### Remove an audio component

Click the <!-- non-renderable component stripped: DeleteIcon --> 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.
1. Set the line number from the drop down menu for each data type.
1. 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.

> **info:** 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.
1. Apply the configuration values based on the information in the [SCTE-35 to SCTE-104](/beam/receiver/output/scte35-to-scte104) section.

> **info:** See [SCTE 104 Splicing](/beam/receiver/parameters/#scte-104-splicing) descriptions for additional information.

## Configure the primary stream

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

> **info:** See [streams](/beam/receiver/parameters#smpte-st-2022-6-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.
1. Follow the same instructions as for the primary stream to configure the secondary stream.

<!-- source: /beam/receiver/output/smpte-st-2110.md -->

# 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](../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.

<!-- non-renderable component stripped: Accordion -->

## 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 <!-- non-renderable component stripped: EditIcon -->.

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 <!-- non-renderable component stripped: AddIcon --> 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 <!-- non-renderable component stripped: RemoveIcon --> button on the tab if not required to maintain optimal performance.

6.  Configure each Media Type such as [Video](#video-output), [PCM Digital Audio](#pcm-digital-audio-output),
    [AES3 Audio](#aes3-audio-output) and [Ancillary Data](#data-output) to create the necessary essence streams.

5.  When two or more outputs exist, they can be deleted by using the <!-- non-renderable component stripped: RemoveIcon --> button on the
    associated tab.

> **info:** 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](#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](../parameters#smpte-st-2110-output-parameters) section

3.  Check the [Essence](#configure-essence-output) settings.

### PCM Digital Audio Output

> **info:** Audio **[Auto Select](/beam/receiver/decoding/#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](#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
    <!-- non-renderable component stripped: AddIcon --> in the Essence section. For example, <!-- non-renderable component stripped: AddIcon --> 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](../parameters#smpte-st-2110-output-parameters) section

7.  Check the [Essence](#configure-essence-output) settings.

### AES3 Audio Output

> **info:** Audio **[Auto Select](/beam/receiver/decoding/#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](#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 <!-- non-renderable component stripped: AddIcon --> 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
    <!-- non-renderable component stripped: AddIcon --> in the Essence section. For example, <!-- non-renderable component stripped: AddIcon --> 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](../parameters#smpte-st-2110-output-parameters) section

7.  Check the [Essence](#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](../parameters#smpte-st-2110-output-parameters) section.

3.  Check the [Essence](#configure-essence-output) settings.

### Configure Essence Output

> **info:** 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.

3.  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.

4.  Repeat the above steps for each **Essence** tab introduced.

5.  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 <!-- non-renderable component stripped: AddIcon --> 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.

> **warning:** 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 <!-- non-renderable component stripped: DownloadIcon --> in the **Output status** section. This appears on the **Stats** <!-- non-renderable component stripped: ChartIcon --> page and on the **Edit** <!-- non-renderable component stripped: EditIcon --> page for the Output.

> **info:** 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.

> **info:** 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.

> **warning:** 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 <!-- non-renderable component stripped: Fa --> **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.|

<!-- source: /beam/receiver/output/ts-passthrough.md -->

# 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 <!-- non-renderable component stripped: Fa --> **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 <!-- non-renderable component stripped: Fa --> **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 <!-- non-renderable component stripped: Fa --> **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**.

<!-- source: /beam/receiver/output/uhd.md -->

# 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)

> **info:** The **Link Mode** options available will depend on the [SDI output option card](/beam/reception/tech-specs/#sdi-output)
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 <!-- non-renderable component stripped: EditIcon --> 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**](../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)

<!-- source: /beam/receiver/parameters.md -->

# 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](/beam/receiver/#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](/beam/receiver/input/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.<br/>**Note:** The Max skew setting increases the receiver buffer delay and therefore contributes to overall system latency. This may impact [Delay Modes](/beam/reception/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<br/>**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:<br/>-   13v (Vertical polarization)<br/>-   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).<br/>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](/beam/reception/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](/beam/receiver/decoding/#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](/beam/receiver/decoding/#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](/beam/receiver/decoding/#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<br/>*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<br/>*Example:* 4:3 or 16:9|
|Frame rate|Frame rate of the video being decoded*<br/>*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,<br/>- **Mode 1** for BISS1-1 and BISS2-1<br/>- **Mode E** for BISS1-E or BISS2-E<br/>- **None** to disable BISS decryption|
|BISS Key|The BISS key (hexadecimal characters only) for decrypting the service according to the **BISS Mode** selection:<br/>- Mode 1 requires 12 characters for BISS1, or 32 characters for BISS2<br/>- 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.<br/>**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.<br/>**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:<br/>- **Quadrant** (Quad‑Link 3G‑SDI, ST 425‑5 Annex B — Square Division)<br/>- **Interleaved** (Quad‑Link 3G‑SDI, ST 425-5 Two Sample Interleave)<br/>- **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](/beam/receiver/output/hd-downconvert) page.|
|Dynamic Range Conversion|Configure the Dynamic Range Conversion for the output video. For details, see the [HDR to SDR](/beam/receiver/output/hdr-sdr) page.|
|Dynamic range signalling|Configure the transfer characteristics and colorimetry signalled on the output video. For details, see the [SDR/HDR signalling](/beam/receiver/output/sdr-hdr) page.|
|Clock reference|Clock reference of the SDI output.<br/>-   **Free running** uses an internally generated reference clock.<br/>-   **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.<br/>See [SCTE 104 Splicing](#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

### <a name="smpte-st-2022-6-video"></a>Video

|Parameter              |Description     |
|:----------------------|:---------------|
|Video Scaling|Configure up-conversion / down‑conversion for the output video. For details, see the [Video Conversion](/beam/receiver/output/hd-downconvert) page.|
|Dynamic Range Conversion|Configure the Dynamic Range Conversion for the output video. For details, see the [HDR to SDR](/beam/receiver/output/hdr-sdr) page.|
|Dynamic range signalling|Configure the transfer characteristics and colorimetry signalled on the output video. For details, see the [SDR/HDR signalling](/beam/receiver/output/sdr-hdr) page.|
|Video failure mode|Defines the behavior of the output when the video decode fails<br/>Possible values: **Freeze frame**, **Black**|

### <a name="smpte-st-2022-6-audio"></a>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|

### <a name="smpte-st-2022-6-data"></a>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.<br/>See [SCTE 104 Splicing](#scte-104-splicing) for additional settings.|

### <a name="smpte-st-2022-6-streams"></a>Primary and Secondary Streams

|Parameter              |Description     |
|:----------------------|:---------------|
|Output enable|Enable the output|
|Destination IP address|Output multicast IPv4 address|
|Destination port|Output UDP port<br/>Possible values: from 1024 to 65535|
|Network interface|Name of the network interface used for the output stream|
|Source IP address|Source IPv4 address<br/>**Note:** Set to **Auto** to automatically use the network interface address|
|Source port|Source UDP port<br/>Possible values: from 1024 to 65535<br/>**Note:** Set to **Auto** to automatically allocate a value|
|TTL|TTL (time to live) on each RTP output packet<br/>Possible values: from 0 to 255|

### <a name="smpte-st-2022-6-status"></a>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](/beam/receiver/output/hd-downconvert) page.|
|Dynamic Range Conversion|Configure the Dynamic Range Conversion for the output video. For details, see the [HDR to SDR](/beam/receiver/output/hdr-sdr) page.|
|Dynamic range signalling|Configure the transfer characteristics and colorimetry signalled on the output video. For details, see the [SDR/HDR signalling](/beam/receiver/output/sdr-hdr) page.|
|Video failure mode|Defines the behavior of the SMPTE ST 2110 output when video decode fails<br/>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.<br/>See [SCTE 104 Splicing](#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.<br/>Applicable to [PCM Audio](/beam/receiver/output/smpte-st-2110#pcm-digital-audio-output) and [AES3 Audio](/beam/receiver/output/smpte-st-2110#aes3-audio-output) 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.<br/>**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](/beam/receiver/output/ts-passthrough#output-smoothing) for more details.|

## Backup parameters

|Parameter              |Description     |
|:----------------------|:---------------|
|Host|Remote server Hostname or IP address.<br/>Possible values: 32 characters max|
|Port|IP Port for the secure FTP or FTPS connection.<br/>Possible values: 1 to 65535<br/>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. <br/>Possible values: 128 characters max|
|Username|For the secure FTP connection. Must be a valid secure FTP or FTPS server user. <br/>Possible values: 16 characters max|
|Password|Allows the configured username to connect to the secure FTP server.<br/>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)

<!-- source: /beam/reception.md -->

# Reception

**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.

<br />

<!-- source: /beam/reception/configure-feed-components.md -->

# 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](./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.

<!-- source: /beam/reception/configure-feed-components/live-encoder.md -->

# Configure the Live Encoder service

For detailed information on the Live Encoder service, refer to the [Live Encoder documentation](/beam/live-encoder/configure).

<!-- source: /beam/reception/configure-feed-components/mux.md -->

# Configure the Multiplexer service

For detailed information on the Multiplexer service, refer to the [Multiplexer documentation](/beam/multiplexer).

<!-- source: /beam/reception/configure-feed-components/receiver.md -->

# Configure the Receiver service

For detailed information on the Receiver service, refer to the [Receiver documentation](/beam/receiver).

<!-- source: /beam/reception/configure-feed-components/reliable-transport.md -->

# Configure a Reliable Transport service

> **info:** 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.

<!-- source: /beam/reception/delay-modes.md -->

# 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.

> **info:** 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 <!-- non-renderable component stripped: EditIcon -->.

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.

<!-- source: /beam/reception/tech-specs.md -->

## 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

<!-- non-renderable component stripped: Accordion -->

<!-- non-renderable component stripped: Accordion -->

### Satellite input

- **Standards:** DVB-S, DVB-S2, DVB-S2X
- **Hardware requirements:** Requires one or more of the following cards

<!-- non-renderable component stripped: Accordion -->

<!-- non-renderable component stripped: Accordion -->

> **warning:** 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

<!-- non-renderable component stripped: Accordion -->

<!-- non-renderable component stripped: Accordion -->

### 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)

<!-- non-renderable component stripped: Accordion -->

<!-- non-renderable component stripped: Accordion -->

<!-- non-renderable component stripped: Accordion -->

<!-- non-renderable component stripped: Accordion -->

<!-- non-renderable component stripped: Accordion -->

## 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

<!-- non-renderable component stripped: Accordion -->

<!-- non-renderable component stripped: Accordion -->

## 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

<!-- non-renderable component stripped: Accordion -->

<!-- non-renderable component stripped: Accordion -->

<!-- non-renderable component stripped: Accordion -->

### 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

<!-- non-renderable component stripped: Accordion -->

<!-- non-renderable component stripped: Accordion -->

<!-- non-renderable component stripped: Accordion -->

> **warning:** 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

<!-- non-renderable component stripped: Accordion -->

<!-- non-renderable component stripped: Accordion -->

<!-- non-renderable component stripped: Accordion -->

<!-- non-renderable component stripped: Accordion -->

> **warning:** 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

<!-- non-renderable component stripped: Accordion -->

<!-- source: /beam/reception/use-cases.md -->

# 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.

<!-- source: /beam/release-notes.md -->

# MK.IO Beam Release Notes

## 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.

<!-- source: /beam/reliable-transport.md -->

# 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).

<!-- source: /beam/reliable-transport/monitoring.md -->

# 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 (<!-- non-renderable component stripped: AlarmIcon -->) 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 (<!-- non-renderable component stripped: AlarmIcon -->) 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 <!-- non-renderable component stripped: AlarmIcon --> icon in the **Alarm** column.

![rt view alarms](./images/rt_view_alarms.png)

Depending on the severity of the alarm, the <!-- non-renderable component stripped: AlarmIcon --> will appear in different colors and will display the most severe color alarm in case of multiple alarms.

- <!-- non-renderable component stripped: AlarmRedIcon --> (critical alarm): the service is not running as expected, customer operations are affected.
- <!-- non-renderable component stripped: AlarmYellowIcon --> (major alarm): issues are affecting the service which may result in it not running as expected and could affect customer operations.
- <!-- non-renderable component stripped: AlarmGreenIcon --> (minor alarm): minor issues are affecting the service, but it is running as expected and customer operations are not affected.
- <!-- non-renderable component stripped: AlarmIcon --> (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

|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](./images/rt_alarms_example.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 <!-- non-renderable component stripped: PieChartIcon --> icon in the **Stats** column.

> **info:** The <!-- non-renderable component stripped: PieChartIcon --> is only accessible when an service configuration is associated to a server and then running.

![rt view alarms](./images/rt_view_alarms.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](./images/rt_stats_udp_srt_listener.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.|

> **info:** 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.|

> **info:** 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.

<!-- source: /beam/reliable-transport/service-interaction.md -->

# 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 <!-- non-renderable component stripped: PlayOutlineIcon --> to launch the service. The service Status changes to **starting** and then to **started**. The <!-- non-renderable component stripped: PlayOutlineIcon --> action button changes to <!-- non-renderable component stripped: StopOutlineIcon -->.

## 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 <!-- non-renderable component stripped: StopOutlineIcon --> 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 <!-- non-renderable component stripped: StopOutlineIcon --> action button changes to <!-- non-renderable component stripped: PlayOutlineIcon -->.

## 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 <!-- non-renderable component stripped: EditIcon --> 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 <!-- non-renderable component stripped: DeleteIcon --> to delete the service.

2.  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.

<!-- source: /beam/reliable-transport/service-management.md -->

# 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.

> **info:** You can import files retrieved from [a service exported from a different server](/beam/web-interface/services#export-service-configurations).

2.  Click **Import service...** and follow the instructions to [import Reliable Transport configurations](/beam/web-interface/services#import-services).

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](./images/Services-add-rt-new-v2.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](#srt-or-rist-connection-configuration)
    -   [Zixi connection configuration](#zixi-connection-configuration)
    -   [RIST connection configuration](#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](./images/rt_srt_rist_multi_output_configuration_example.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**

> **info:** 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](./images/RT_Zixi_workflow.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](./images/rt_select_input.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](./images/rt_select_output.png)

3.  Complete the **Input** and **Output** parameters that come with the selected mode:

    -   [UDP configuration](#udp-configuration)
    -   [SRT Caller configuration](#srt-caller-configuration)
    -   [SRT Listener configuration](#srt-listener-configuration)
    -   [Zixi Feeder configuration](#zixi-feeder-configuration)
    -   [Zixi Receiver configuration](#zixi-receiver-configuration)
    -   [RIST configuration](#rist-configuration)
    -   [RTMP Caller configuration](#rtmp-caller-configuration)
    -   [RTMP Listener configuration](#rtmp-listener-configuration)

### UDP configuration

![rt config udp](./images/rt_config_udp.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](./images/rt_config_srt_caller_v2.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](./images/rt_config_srt_listener.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](#predicted-worst-case-link-characteristics) above.

### Zixi Feeder configuration

![rt config zixi feeder](./images/rt_config_zixi_feeder.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](./images/rt_config_zixi_receiver.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](./images/rt_config_rist.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](./images/rt_config_rtmp_caller.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](./images/rt_config_rtmp_listener.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|

<!-- source: /beam/stream-conditioning.md -->

# 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).

<!-- source: /beam/stream-conditioning/connections.md -->

# Configure connections

MK.IO Beam implements industry-standard communication interface, namely:

-   [CableLabs ESAM communication (ESAM-SCC)](#esam-configuration)
-   [SCTE-104/30](#scte-10430-configuration)
-   [SCTE-30/30](#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:<br/>- **URL**: URL to which the Signal Processing System endPoint can reach the Signal Acquisition System endPoint (such as encoder, TS processor).<br/> - **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.<br/>Default value: listening path = `/`, *Example*: listening path = `/encoder1`<br/>**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).<br/>*Example*: name = **VIRD**, value= **NY**|

    ![EndPoint configuration](./images/prisma_sc_esam_cfig.png)

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

> **info:** 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.<br/>- **SCTE-104 port**: communication port used for SCTE-104 communication.<br/>- **SCTE-30 port**: communication port used for SCTE-30 communication.<br/>**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).<br/>*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.<br/>- **SCTE-30 port**: communication port used for SCTE-30 communication.<br/>**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).<br/>*Example*: name = **VIRD**, value= **NY**|

<!-- source: /beam/stream-conditioning/inputs.md -->

# 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.<br/>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 `<asset>` 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](#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:<br/>- **Policy begin:** operation triggered when the policy is applied (SCTE-224 `<Apply>` tag from the media point element).<br/>- **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:<br/>- **Auto (follow SCTE-224):** This mode allows triggering an operation:<br/>- based on time (if only at least one of the following attribute is present: @matchTime, @effective, @expires),<br/>- based on incoming signal only (if only @matchSignal is present),<br/>- or based on @matchSignal with a time-based fallback.<br/>- **Time-Based:** operation can be forced to be exclusively time-based (even if the media point contains @matchSignal).<br/>- **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.<br/>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](./images/Prisma_sc_alternate_content.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](#operation-all-scheduling-configuration)
-   [Operation: ESAM properties](#operation-esam-properties)
-   [Operation: Fallback operation](#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).

> **info:** 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](./images/Prisma_sc_alternate_content_operation_scte35.png)

> **info:** 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**.

> **info:** 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](./images/Prisma_sc_alternate_content_scte35_insertion.png)

> **info:** 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](./images/Prisma_sc_alternate_content_scte35_insertion_seg.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](./images/Prisma_sc_alternate_content_scte35_rewriting.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](./images/Prisma_sc_alternate_content_scte35_rewriting_manual.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](./images/Prisma_sc_alternate_content_scte35_rewriting_manual_modifier_remove.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](./images/Prisma_sc_alternate_content_scte35_rewriting_manual_modifier_rewrite.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](./images/Prisma_sc_alternate_content_scte35_rewriting_manual_additional.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.<br/>Up to 8 layers can be managed (7 images overlaying).<br/>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.<br/>Example: **This is my crawling text**|
    |`SWF_SPEED`|Crawling speed. Configured value ranges from 1 to n (number of point per frame).<br/>Default value is **4**.|
    |`SWF_BACK_ALPHA`|Background transparency. Value range: [0..1].<br/>Default value is **0.6**.|
    |`SWF_COLOR_BACK`|Background color of the crawler, using RGB color system. *Example*: **55A9B0**.<br/>Default value is **no background**.|
    |`SWF_COLOR`|Text color using RBG system. *Example*: **55A9B0**.<br/>Default value is **FFFFFF**.|

    ![Animation configuration](./images/Prisma_sc_op_anim.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](./images/Prisma_sc_op_slate.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.

> **info:** 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.<br/>Default value is **0**, meaning the video clip will start from the beginning.|

    ![Prisma sc op clip](./images/Prisma_sc_op_clip.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](#operation-all-scheduling-configuration)
-   [Operation: ESAM properties](#operation-esam-properties)
-   [Operation: Fallback operation](#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.<br/>**Note:** This configuration is optional, and reserved for advanced workflow.|
    |Define stop condition|Define the condition for canceling the ongoing operation (started by startcondition).<br/>**Restriction:** This parameter is only displayed is you selected an **ESAM (advanced)** operation (see [advanced operations table](#advanced-operations)).|
    |Enable priority|Define the priority at which the signal-based operations should be applied:<br/>- 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.<br/>- 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.<br/>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:<br/>- **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”.<br/>- **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.<br/>- **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.<br/>- **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).<br/>- **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.<br/>**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](./#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:<br/>- **Absolute** start and end UTC times,<br/>- **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**.<br/>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**.<br/>Optional time to stop broadcasting the data as a UTC date and time.|
    |Start offset| **Note:** Available when scheduling type is set to **Relative**.<br/>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**.<br/>Optional time to stop broadcasting the data as a duration from the associated/related signal.|

    ![ESAM Properties](./images/Prisma_sc_esam_properties_disable.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](./images/Prisma_sc_op_fallback_custom.png)

<!-- source: /beam/stream-conditioning/notifications.md -->

# 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.

<!-- source: /beam/stream-conditioning/scheduling-view.md -->

# 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.

> **info:** 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](./images/Prisma-timeline_icon_top_right_corner.png)

    2.  or click on the timeline button from the **Actions** list of configured service.

        ![Prisma timeline icon service actions](./images/Prisma-timeline_icon_service_actions.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](./images/Prisma-sc_timings_timeline.png)

<!-- source: /beam/stream-conditioning/timing.md -->

# 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](./images/Prisma-sc_timings.png)

<!-- source: /beam/stream-conditioning/variables.md -->

# 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](./images/Prisma_sc_variables_factory.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](./images/Prisma_sc_settings_variables_collection_add.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](./images/Prisma_sc_settings_variables_add.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](./images/Prisma_sc_context_variables.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.

<!-- source: /beam/system-admin.md -->

# 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.

<br />

<!-- source: /beam/system-admin/iso-installation.md -->

# 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.

### BIOS configuration

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

> **warning:** 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.

> **warning:** 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
1. Run Rufus and connect the target USB drive to the Windows PC
1. Check that the USB drive is detected and shown in the user interface:
![ISO install USB 000](/beam-img/ISO-install-USB-000.png)
1. Click the Select button and browse to the ISO file:
![ISO install USB 001](/beam-img/ISO-install-USB-001.png)
1. Leave all configuration settings at their defaults and click the Start button:
![ISO install USB 002](/beam-img/ISO-install-USB-002.png)
1. 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)
1. If prompted to download the Syslinux installation files, click Yes:
![ISO install USB 004](/beam-img/ISO-install-USB-004.png)
1. Check that the correct USB drive is being written to and click OK:
![ISO install USB 005](/beam-img/ISO-install-USB-005.png)
1. 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)
1. 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)
1. 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)
1. When prompted to install the bundle, click **OK** to continue the installation:
![ISO install 003](/beam-img/ISO-install-003.png)
1. 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.

1. Once the install process has completed, the server will reboot:
![ISO install 005](/beam-img/ISO-install-005.png)
1. The MediaKind Boot Manager will start:
![ISO install 006](/beam-img/ISO-install-006.png)
1. Then the AlmaLinux boot screen will be displayed:
![ISO install 007](/beam-img/ISO-install-007.png)
1. When prompted to login, MK.IO Beam is installed on the server.

<!-- source: /beam/system-admin/iso-installation/g8-g9-servers.md -->

# 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.
1. Density should be roughly similar to Aquila, but if in doubt, contact Product Management for guidance.
1. 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.
1. 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
1. 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

<!-- source: /beam/system-admin/iso-installation/troubleshooting.md -->

# 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.

<!-- source: /beam/system-admin/maintenance/alarms-events.md -->

# 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
    - <!-- non-renderable component stripped: AlarmRedIcon --> critical
    - <!-- non-renderable component stripped: AlarmYellowIcon --> major
    - <!-- non-renderable component stripped: AlarmGreenIcon --> minor
    - <!-- non-renderable component stripped: AlarmIcon --> 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](/beam/system-admin/servers/failover#display-failover-groups)|
    |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 <!-- non-renderable component stripped: GearIcon --> 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.

> **info:** See the [Service alarms page](#service-alarms-page) or the [Failover alarms page](#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](../images/view_active_alarms_menu.png)

-  Click **Services** on the left-side menu then click <!-- non-renderable component stripped: AlarmIcon --> 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](../images/view_alarm_shortcut_header.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.

> **info:** 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.

> **info:** 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 <!-- non-renderable component stripped: GearIcon --> 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](../images/view_snmp_trap_destination_table_list_mfmms.png)

### Add a new SNMP destination

1.  Click <!-- non-renderable component stripped: GearIcon --> 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.

> **info:** 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 <!-- non-renderable component stripped: GearIcon --> in the upper right corner of the window then select **Settings**.
2.  From the **SNMP notifications** tab, click <!-- non-renderable component stripped: EditIcon --> to display SNMP destination parameters.
3.  Edit the [SNMP parameters](/beam/system-admin/maintenance/parameters#snmp-parameters-settings-menu) and save.

> **info:** The parameters that display to edit SNMP destinations depend on the SNMP version.

![view snmp v3 parameters](../images/view_snmp_v3_parameters.png)
*Example of SNMP v3 configuration*

### Activate/deactivate SNMP notifications

1.  Click <!-- non-renderable component stripped: GearIcon --> 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 <!-- non-renderable component stripped: EditIcon --> and tick the **Activate** checkbox at the top of the SNMP parameters.

### Delete an SNMP destination server

1.  Click <!-- non-renderable component stripped: GearIcon --> in the upper right corner of the window then select **Settings**.
3.  From the **SNMP notifications** tab, click <!-- non-renderable component stripped: DeleteIcon --> to delete the SNMP destination configuration. You are prompted to confirm and delete.

## Alarm overrides

> **info:** 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.

> **info:** 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.

> **warning:** 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](../images/view_alarm_overides_controller.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](../images/view_current_severity_button_alarm_override_controller.png)

4.  Select a severity from the list. The **Current severity** changes.

> **info:** 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.

> **warning:** 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.

> **info:** 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](../images/view_active_alarms_menu_table.png)

<!-- source: /beam/system-admin/maintenance/backup-restore.md -->

# 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.)

> **info:** 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.

> **warning:** 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 <!-- non-renderable component stripped: GearIcon --> 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](#display-backup-mediakind-database-options). **Local Backup** is selected by default.

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

> **info:** The **Host**, **Port** and **Path** are only required for a [remote backup](#restore-configurations-from-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](#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.

> **info:** FTPS is also authorized.

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

> **warning:** 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](#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).

> **info:** 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](#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.

> **info:** 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](../images/view_download_file_db_remote_mfvp_controller.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.

> **warning:** 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 <!-- non-renderable component stripped: GearIcon --> 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](#display-restore-options).
2.  Select **Remote Backup**.
3.  Select a **Year** > **Month** > **Backup**.

> **info:** 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](#display-restore-options). **Local Backup** is selected by default.

    ![view restore mfvp controller](../images/view_restore_mfvp_controller.png)

2.  Expand the **Backup** drop-down list to display available backups, then select a backup to restore.

> **info:** 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.

<!-- source: /beam/system-admin/maintenance/generate-support-package.md -->

# 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.

> **info:** Downloading a Support Package from the **Servers** page is not supported using [Access remote UI](/mkio/how-to/managing-edge-devices/access-the-remote-device-ui). To generate a Support Package through MK.IO, use [Collect device logs](/mkio/how-to/managing-edge-devices/support-packages).

## Generate a Support Package from the server UI

1.  Go to **Servers** and select a server.
2.  In the **Actions** column, click <!-- non-renderable component stripped: PackageIcon --> 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.

> **info:** 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

> **info:** 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.

> **info:** 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 <path>`: 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@<server-ip>:/tmp/dell_supportassist.zip .
```

Adjust the source path if you used `--output-file`. You can then attach the zip file to your support case.

<!-- source: /beam/system-admin/maintenance/health-monitoring.md -->

# 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 <!-- non-renderable component stripped: GearIcon --> 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.

> **warning:** 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 <string>` defines the username for the endpoint of the Grafana instance.
- `-–password <string>` defines the password for the endpoint of the Grafana instance.
- `-–remoteurl <string>` defines the URL for the endpoint of the Grafana instance.
- `-–env <string>` defines the name of the node/machine. If not specified, the hostname is used.
- `-–zone <string>` defines the location zone for the node/machine.

> **info:** 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 <string>` defines the username for the endpoint of the Grafana instance.
- `-–password <string>` 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://<GRAFANA_HOST>/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`

<!-- source: /beam/system-admin/maintenance/manage-alarms.md -->

# 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)

> **info:** 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 <!-- non-renderable component stripped: GearIcon --> 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)

<!-- source: /beam/system-admin/maintenance/parameters.md -->

# Configuration parameters

## Backup parameters

|Parameter|Description              |
|:---     |:---                     |
|Host     |Remote server hostname or IP address.
|Port     |IP Port for the secure FTP or FTPS connection.<br/>Possible values: 1 to 65535<br/>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. <br/>Possible values: 128 characters max|
|Username |For the secure FTP connection. Must be a valid secure FTP or FTPS server user. <br/>Possible values: 16 characters max|
|Password |Allows the configured username to connect to the secure FTP server.<br/>Possible values: 16 characters max|

**Related information**
[Backup and restore configurations](../backup-restore#backup-and-restore-configurations)

## 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](../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).<br/>Example: 192.168.1.1|
|Port             |Port used to send SNMP notifications.<br/>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. <br/>Options:<br/>-   `authNoPriv` (authentication but no encryption)<br/>-   `noAuthNoPriv` (no authentication and no encryption)<br/>-   `authPriv` (authentication and encryption)<br/>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.<br/>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)](../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.<br/>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. <br/>**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.<br/>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](../network/router-configuration)

<!-- source: /beam/system-admin/maintenance/processing-types.md -->

# 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** <!-- non-renderable component stripped: ViewIcon --> 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.

<!-- source: /beam/system-admin/maintenance/service-settings.md -->

# 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.

## Packager menus

-   [HTTP Headers](#add-an-http-header)

## Stream Conditioning menus

-   Stream Conditioning variables

## Live Encoder menus

-   [Nielsen archiving](#enable-nielsen-log-archiving) (only available in container mode)
-   [Live service lineup](#live-service-lineup)

## Add an HTTP header

1.  Click **Settings** <!-- non-renderable component stripped: ThreeGearsIcon --> to expand menu options.
2.  Select **HTTP Headers**. The following page is displayed:

    ![services http headers](../images/services-http-headers.png)

3.  Edit the existing header, or click **Add** to create a new header.
4.  Check that required values are correct:
    - URL pattern
    - Headers
5.  Select a **Save** option to save changes.

## 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** > **<!-- non-renderable component stripped: EditIcon -->** > **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.

> **info:** 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"](../images/live_servicelineup_view_channel1.png "Example of an MPEG-2 TS/UDP lineup file configuration")

    ![live servicelineup view st2110](../images/live_servicelineup_view_st2110.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 <!-- non-renderable component stripped: EditIcon --> 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.

<!-- source: /beam/system-admin/maintenance/setup-sdi-asi-card.md -->

# 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.

<!-- source: /beam/system-admin/network/bonded-interfaces.md -->

# 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

> **info:** Firewall zone for bonded interfaces can be set on the UI in Beam 1.9 and later. See [Configure network interfaces](/beam/system-admin/network/configure-nics).

- 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.

<!-- source: /beam/system-admin/network/configure-nics.md -->

# 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** <!-- non-renderable component stripped: ViewIcon --> button to open the server information.
3. Go to the **System Settings** tab.

> **warning:** 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** <!-- non-renderable component stripped: EditIcon --> 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.

> **warning:** 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

> **info:** 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** <!-- non-renderable component stripped: EditIcon --> 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** <!-- non-renderable component stripped: EditIcon --> button next to it.
    -   To **delete** a route, click the **Delete** <!-- non-renderable component stripped: DeleteIcon --> 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** <!-- non-renderable component stripped: EditIcon --> 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).

<!-- source: /beam/system-admin/network/control-interface-wizard.md -->

# 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.

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

<!-- source: /beam/system-admin/network/jumbo-frames.md -->

# 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.

> **info:** 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

> **info:** 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** <!-- non-renderable component stripped: EditIcon --> 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
```

<!-- source: /beam/system-admin/network/router-configuration.md -->

# 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 <!-- non-renderable component stripped: GearIcon --> to display the system center menu.
2.  Click **Settings** > **Router settings**. The **Router settings** display.

    ![router display](../images/router_display.png)

## Add a new router configuration

1.  Click <!-- non-renderable component stripped: GearIcon --> 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.

> **info:** For more details on the parameters below, see [Router parameters](/beam/system-admin/maintenance/parameters#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 <!-- non-renderable component stripped: GearIcon --> to display the system center menu.
2.  Click **Settings** > **Router settings**. The **Router settings** display.
3.  Click <!-- non-renderable component stripped: EditIcon --> to edit the router configuration.

> **info:** For more details on the parameters below, see [Router parameters](/beam/system-admin/maintenance/parameters#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 <!-- non-renderable component stripped: GearIcon --> 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](../images/import_router.png)

4.  Click **Select file**.
5.  Select the required file then click **Open**. The file appears in the **Import Router** window.

    ![import router json](../images/import_router_json.png)

6.  Click **Import**. The imported file displays in the list in the **Router settings** tab.

## Export a router configuration

1.  Click <!-- non-renderable component stripped: GearIcon --> to display the system center menu.
2.  Click **Settings** > **Router settings**. The **Router settings** display.
3.  Click <!-- non-renderable component stripped: DownloadIcon -->. 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 <!-- non-renderable component stripped: GearIcon --> to display the system center menu.
2.  Click **Settings** > **Router settings**. The **Router settings** display.
3.  Click <!-- non-renderable component stripped: ViewIcon -->. 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](../images/router_crosspoints.png)

6.  Click **Back** to return to **Router settings** tab.

<!-- source: /beam/system-admin/network/system-clock.md -->

# 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

> **info:** 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** <!-- non-renderable component stripped: EditIcon --> 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)

<!-- source: /beam/system-admin/network/vlan-interfaces.md -->

# 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.

> **info:** 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.

> **info:** 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** <!-- non-renderable component stripped: DeleteIcon --> 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
```

<!-- source: /beam/system-admin/security/ldap-management.md -->

# 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 <!-- non-renderable component stripped: GearIcon --> 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](../images/menu_system_settings_ldap.png)

> **warning:** 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.

> **info:** 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`|`Controller 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.

<!-- source: /beam/system-admin/security/ssl-certificates.md -->

# 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 <action>
```

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).

<!-- source: /beam/system-admin/security/user-management.md -->

# 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.

> **info:** 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.

> **info:** 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.

> **info:** 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

> **info:** 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 <!-- non-renderable component stripped: GearIcon --> 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 <!-- non-renderable component stripped: GearIcon --> 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](../images/add_new_group.png)

6.  Select a **Save** option. The new **Group** appears in the list of groups.

![group list](../images/group_list.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](#displaying-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](#assign-a-user-to-a-group) to manage user access [rights and permissions](#user-group-permissions). By default, new users are assigned to the **Monitoring** group.

> **info:** 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](#displaying-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](../images/view_permissions_arrows_user_mgt_controller.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.

> **info:** 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](./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](#editing-user-information) to [manage permissions](#user-group-permissions) and access rights.

### Editing user information

1.  [Display users](#displaying-the-list-of-users).
2.  Select a **User**.
3.  Edit the user information:

    - **Username**
    - **Password**
    - **Personal information**
    - [Permissions](#user-group-permissions)

4.  Select a save option to continue or exit.

> **info:** 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](#displaying-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](../images/view_user_management_mfvp_controller_change_password.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.|

<!-- source: /beam/system-admin/servers/failover.md -->

# 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*

> **info:** 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](#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](../images/view_failover_groups_list_mfvp.png)

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

2.  Click <!-- non-renderable component stripped: ViewIcon --> in the **Actions** column to display details.

> **info:** 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](../images/view_table_failover_summary_mfvp_mc.png)

> **info:** All time stamps are in **Universal Time (UTC)**.

3.  Click <!-- non-renderable component stripped: ViewIcon --> in the **Actions** column to display details.

## Create a failover group

1.  [Display failover groups](#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).

> **info:** 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.

> **info:** 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](#display-failover-groups).

2.  Click <!-- non-renderable component stripped: EditIcon -->. The **failover setup** page displays.

> **info:** 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](#create-a-failover-group) configuration.

> **info:** - **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](#create-a-failover-group).

> **warning:** User permissions are required to request a failover or a revert. If the server has no services assigned, then [default user rights for failover](/beam/system-admin/security/user-management#user-group-permissions) apply.

1.  [Display failover groups](#display-failover-groups).

2.  Click <!-- non-renderable component stripped: ViewIcon --> to display details.

3.  Click <!-- non-renderable component stripped: LeftRightIcon --> 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).

> **info:** 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.

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

1.  From the **Services** page, click <!-- non-renderable component stripped: EllipsisIcon --> to show more actions on the service you want to failover or revert.

2.  Click on the <!-- non-renderable component stripped: ServiceFailoverIcon --> (failover) or <!-- non-renderable component stripped: ServiceRevertIcon --> (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.

> **info:** 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.

> **warning:** 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](../images/view_alarm_overides_controller.png)

3.  Select a response for **Trigger failover**.

    ![view alarm override failover trigger controller](../images/view_alarm_override_failover_trigger_controller.png)

<!-- source: /beam/system-admin/servers/servers.md -->

# Manage servers

The **Servers** view displays system information to monitor and manage servers. The statuses indicate server availability: **connected** or **connection lost**.

## Server Status

> **info:** The actions available are dependent on the installation type, server type and the user role.

-   Administrators can click the **Delete** <!-- non-renderable component stripped: DeleteIcon --> button to remove a server that is no longer in use in the system.
-   You can use the **Reboot** <!-- non-renderable component stripped: ReloadIcon --> button to restart the server by clicking **Yes** at the displayed **Are you sure?** confirmation message.
-   Click the **Details** <!-- non-renderable component stripped: ViewIcon --> button to display the server information ([Display server information (system)](servers#displaying-server-information-system)).
-   Click the **Stats** <!-- non-renderable component stripped: ChartIcon --> button to view server statistics, such as CPU, memory, disk usage, and network statistics.
-   Click the **Support package** <!-- non-renderable component stripped: PackageIcon --> 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 <!-- non-renderable component stripped: ViewIcon --> 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**

<!-- source: /beam/system-admin/system-administration.md -->

# 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, <!-- non-renderable component stripped: GearIcon -->.

![menu mfvp system settings](./images/menu_mfvp_system_settings.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#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 <!-- non-renderable component stripped: GearIcon --> 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.

<!-- source: /beam/system-admin/third-party-software.md -->

# 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 <file>.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/<filename>`.

## 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.

> **warning:** 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.

<!-- source: /beam/ts-splicer.md -->

# 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.

<!-- source: /beam/ts-splicer/advanced-parameters.md -->

# Configure advanced parameters

> **warning:** 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.

<!-- source: /beam/ts-splicer/alternate-content-source-configuration.md -->

# 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
<esam:SignalProcessingNotification
    xmlns:common="urn:cablelabs:iptvservices:esam:xsd:common:1"
    xmIns:esam="urn:cablelabs:iptvservices:esam:xsd:signal:1"
    xmIns:md="urn:cablelabs:md:sd:signaling:3.0"
    signalProcessingIdentity="">
  <common:StatusCode classCode="0"/>
  <sesam:ResponseSignal acquisitionPointIdentity="GAMEHD0100_Z1"
                        acquisitionSignalID="70a20£66-bc00-405-a77b-944ee9£3b6b8"
                        signalPointID="" action="create">
    <md:UTCPoint utcPoint="2020-03-11T23:17:08.600Z"/>
    <esam:AlternateContent altContentIdentity="ECE-SLATE" zoneIdentity="zonel"/>
  </esam:Responsesignal>
</esam:SignalProcessingNotification>
```

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](./images/alternateContentSource_MPEG-TS.png)

<!-- source: /beam/ts-splicer/general-configuration.md -->

# 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](./images/dualOutputPrevention_image.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.

<!-- source: /beam/ts-splicer/input-configuration.md -->

# 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.

<!-- source: /beam/ts-splicer/monitoring.md -->

# 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:
- <!-- non-renderable component stripped: AlarmRedIcon -->: critical alarm
- <!-- non-renderable component stripped: AlarmYellowIcon -->: major alarm
- <!-- non-renderable component stripped: AlarmGreenIcon -->: minor alarm

<!-- source: /beam/ts-splicer/output-configuration.md -->

# 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.

<!-- source: /beam/ts-splicer/placement.md -->

# 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.
1. Click **+Add placement rule.**
1. 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](./images/Placement_BO_routing.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://<hostname>:<port>/api/esam/TsSplicer/<network_name>`




## 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 <mediaFiles> 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 <MediaFile> elements of the VAST response (one <MediaFile> 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.

<!-- source: /beam/web-interface.md -->

# Web interface overview

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](#create-a-feed-using-default-configurations). When creating a feed for the first time, use this method.
    -   [Reuse a saved configuration](#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.](#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 <!-- non-renderable component stripped: EllipsisIcon --> 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**.

> **info:** 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 <!-- non-renderable component stripped: EllipsisIcon --> 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.](#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.

> **info:** 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 <!-- non-renderable component stripped: EllipsisIcon --> then select the **Delete feed** option.

<!-- source: /beam/web-interface/connection.md -->

# 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:**<br/>`http://[IP-Address]:8080`<br/>or `http://[IP-Address]:30020` for containerized solutions.
    - **HTTPS example:**<br/>`https://[IP-address]:8443`<br/>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.

> **warning:** 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.

<!-- source: /beam/web-interface/navigation.md -->

# 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.

> **info:** You can click the Health indicator or the **Health** left menu to display an embedded Grafana page showing an overview of [Controller health](#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 <!-- non-renderable component stripped: GearIcon --> 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](./images/view_rows_per_page_mfvp_unified_ui.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](./images/view_search_bar_table_small_mfvp_controller.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.

> **info:** 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](./images/menu_failover.png)

> **info:** -   All timestamps are in Universal Time (UTC) but you can customize them (see [Alarm display time](/beam/system-admin/maintenance/alarms-events#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.

> **info:** 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](./images/controller-health.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.

<!-- source: /beam/web-interface/services.md -->

# 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 <!-- non-renderable component stripped: EllipsisIcon --> 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](/beam/web-interface/navigation#service-processing-types). 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](#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](#start-a-service) or [stop](#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.

> **info:** For failover configurations:
- [Failover](/beam/system-admin/servers/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.

2.  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.

2.  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.

> **info:** 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).

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

From the **Services** page, click <!-- non-renderable component stripped: EllipsisIcon --> in the **Actions** column then click <!-- non-renderable component stripped: DownloadIcon --> to export. A file will download in your browser's default location.

> **info:** 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](#bulk-actions) section). The services selected do not need to all be of the same type.  Once you have selected your services click  <!-- non-renderable component stripped: EllipsisIcon --> in the **Actions** column of any service then click <!-- non-renderable component stripped: DownloadIcon --> to export.  This will download a tar.gz file containing all the configurations of the selected services.

> **info:** 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     |

> **info:** 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](#export-a-service-configuration) section)

> **warning:** 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.

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

> **warning:** 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 <!-- non-renderable component stripped: PlayOutlineIcon -->  in the **Actions** column to launch the service. The **Status** changes to **started**.

> **info:** If an alarm is raised, click <!-- non-renderable component stripped: AlarmIcon --> 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.

> **warning:** Stopping a service cancels any jobs in progress.

1.  From the **Services** page, click <!-- non-renderable component stripped: StopOutlineIcon --> 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 <!-- non-renderable component stripped: EllipsisIcon --> in the **Actions** column then select <!-- non-renderable component stripped: CloneIcon --> to copy the service. A "-copy" suffix is added to the name of the duplicated service.

> **info:** You can simultaneously select and copy several services at once (see [Bulk actions](#bulk-actions)).

## Delete a service

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

> **info:** For detailed information regarding a Live Packaging service deletion, see [Deleting a Live Packaging service and managing DVR](../packager/live-packaging-service#deleting-a-live-packaging-service-and-managing-dvr).

1.  From the **Services** page, click <!-- non-renderable component stripped: EllipsisIcon --> in the **Actions** column then select <!-- non-renderable component stripped: DeleteIcon --> 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.

> **info:** 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.

<!-- source: /beam/web-interface/system-architecture.md -->

# 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](./images/schema_architecture_controller.png)

> **info:** 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](./navigation#service-processing-types) (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](./images/schema_active_active_controller.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).

<!-- source: /beam/web-interface/templates.md -->

# 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.<br/>
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.

> **info:** 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](./images/view_templates_home_controller.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 <!-- non-renderable component stripped: EditIcon --> 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](#display-templates).

6.  You can [create a new service from the template](#create-a-new-service-from-a-template).

## Delete a template

> **info:** **Deleting a template** has no impact on services created from that template.

To delete a template, follow these steps:

1.  Display templates.

2.  Click <!-- non-renderable component stripped: DeleteIcon --> 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.

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

Before you start, [ensure a template already exists](#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 <!-- non-renderable component stripped: EditIcon --> 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](#display-templates).

2.  Click ![button export template mfvp controller](./images/button_export_template_mfvp_controller.png) to export. The file is downloaded in relation to your web browser download settings.

> **warning:** 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](#display-templates).

2.  Click ![button export form template mfvp controller](./images/button_export_form_template_mfvp_controller.png) to export. A .csv file is downloaded in relation to your web browser download settings.

> **warning:** 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](#display-templates).

2.  Click **Actions**.

3.  Select **Import template**.

    ![button actions import template mfvp controller](./images/button_actions_import_template_mfvp_controller.png)

4.  Click **Select file** to choose a file, then click **Import**.

    ![view import service mfvp controller](./images/view_import_service_mfvp_controller.png)

    The template is uploaded and available in the **Templates** table.

> **warning:** -   Template names must be unique.
    -   You are unable to import a template if the template with the same name already exists on this Controller.

<!-- source: /mkio.md -->

# 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](/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](/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)

<!-- source: /mkio/changelog.md -->

# Changelog

## 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.

## 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.

## 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.

## 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.

## 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.

## 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.

## 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.

<!-- source: /mkio/faq.md -->

# 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

<!-- non-renderable component stripped: Accordion -->

<!-- non-renderable component stripped: Accordion -->

<!-- non-renderable component stripped: Accordion -->

<!-- non-renderable component stripped: Accordion -->

<!-- non-renderable component stripped: Accordion -->

## Storage and assets

<!-- non-renderable component stripped: Accordion -->

<!-- non-renderable component stripped: Accordion -->

<!-- non-renderable component stripped: Accordion -->

<!-- non-renderable component stripped: Accordion -->

## Playback and delivery

<!-- non-renderable component stripped: Accordion -->

<!-- non-renderable component stripped: Accordion -->

<!-- non-renderable component stripped: Accordion -->

## Workflows and APIs

<!-- non-renderable component stripped: Accordion -->

<!-- non-renderable component stripped: Accordion -->

<!-- non-renderable component stripped: Accordion -->

<!-- non-renderable component stripped: Accordion -->

<!-- non-renderable component stripped: Accordion -->

<!-- non-renderable component stripped: Accordion -->

<!-- non-renderable component stripped: Accordion -->

## Accounts and billing

<!-- non-renderable component stripped: Accordion -->

<!-- non-renderable component stripped: Accordion -->

<!-- non-renderable component stripped: Accordion -->

<!-- non-renderable component stripped: Accordion -->

## Support and availability

<!-- non-renderable component stripped: Accordion -->

<!-- non-renderable component stripped: Accordion -->

<!-- source: /mkio/getting-started.md -->

# 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](/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](/api-guides/getting-started/first-api-call) to verify API access.
- [Use the Media API](/api-guides/how-to/media) for automated media workflows.
- [Open the API Reference](/api-reference) for endpoint and schema lookup.

## Video overview

<div style={{ marginTop: '1.5rem', width: '100%' }}>
  <div style={{ position: 'relative', width: '100%', paddingBottom: '56.25%' }}>
    <iframe
      src="https://www.youtube-nocookie.com/embed/qe6piYt5hyM?start=3&rel=0&controls=1&modestbranding=1&iv_load_policy=3&disablekb=1&fs=0&playsinline=1&loop=1&playlist=qe6piYt5hyM"
      title="YouTube video player"
      frameBorder="0"
      allow="accelerometer; autoplay; clipboard-write; encrypted-media; gyroscope; picture-in-picture; web-share"
      referrerPolicy="strict-origin-when-cross-origin"
      allowFullScreen
      style={{ position: 'absolute', top: 0, left: 0, width: '100%', height: '100%' }}
    />
  </div>
</div>

<!-- source: /mkio/getting-started/account-setup-and-first-steps.md -->

# 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).

> **warning:** 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

<div style={{ marginTop: '1.5rem', width: '100%' }}>
  <div style={{ position: 'relative', width: '100%', paddingBottom: '56.25%' }}>
    <iframe
      src="https://www.youtube-nocookie.com/embed/6j5Ymrlif5M?start=4&rel=0&controls=1&modestbranding=1&iv_load_policy=3&disablekb=1&fs=0&playsinline=1&loop=1&playlist=6j5Ymrlif5M"
      title="Account setup and first steps video"
      frameBorder="0"
      allow="accelerometer; autoplay; clipboard-write; encrypted-media; gyroscope; picture-in-picture; web-share"
      referrerPolicy="strict-origin-when-cross-origin"
      allowFullScreen
      style={{ position: 'absolute', top: 0, left: 0, width: '100%', height: '100%' }}
    />
  </div>
</div>

<!-- source: /mkio/getting-started/connect-cloud-storage.md -->

# 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](/api-guides/how-to/media/storage).

<div style={{ marginTop: '1.5rem', width: '100%' }}>
  <div style={{ position: 'relative', width: '100%', paddingBottom: '56.25%' }}>
    <iframe
      src="https://www.youtube-nocookie.com/embed/mDjZLtmqYcE?rel=0&controls=1&modestbranding=1&iv_load_policy=3&disablekb=1&fs=0&playsinline=1&loop=1&playlist=mDjZLtmqYcE"
      title="Video on-demand workflows video"
      frameBorder="0"
      allow="accelerometer; autoplay; clipboard-write; encrypted-media; gyroscope; picture-in-picture; web-share"
      referrerPolicy="strict-origin-when-cross-origin"
      allowFullScreen
      style={{ position: 'absolute', top: 0, left: 0, width: '100%', height: '100%' }}
    />
  </div>
</div>

<br />

<!-- non-renderable component stripped: TabItem -->

<!-- non-renderable component stripped: TabItem -->

<!-- source: /mkio/getting-started/live-stream-in-five-minutes.md -->

# Live stream in five minutes

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.

> **warning:** 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)

> **info:** 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**

> **warning:** 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](/api-guides/how-to/media/live-streaming).

<!-- source: /mkio/getting-started/live-streaming-workflows.md -->

# 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

[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

<!-- non-renderable component stripped: WorkflowCards -->

### 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](/api-guides/how-to/media/live-streaming).

<!-- source: /mkio/getting-started/live-streaming-workflows/advanced-features.md -->

# Advanced live streaming features

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).

> **info:** Live transcription is billed as an additional service. See [MK.IO pricing](https://mediakind.com/mkio/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: 7 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).

<!-- source: /mkio/getting-started/platform-navigation-and-key-features.md -->

# 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](/api-guides/how-to/media/storage).

## Create video workflows

The **Create** group contains live and file-based processing resources.

- **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).
- **MK Player**: 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 and 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).
- **Edge 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](/api-guides) when you need to automate a portal workflow. The [Media API Guide](/api-guides/how-to/media) covers media resources, while the [Management API Guide](/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](/api-guides/getting-started/authentication).

## Video walkthrough

<div style={{ marginTop: '1.5rem', width: '100%' }}>
  <div style={{ position: 'relative', width: '100%', paddingBottom: '56.25%' }}>
    <iframe
      src="https://www.youtube-nocookie.com/embed/q3cttJVWIjo?rel=0&controls=1&modestbranding=1&iv_load_policy=3&disablekb=1&fs=0&playsinline=1&loop=1&playlist=q3cttJVWIjo"
      title="Platform navigation and key features video"
      frameBorder="0"
      allow="accelerometer; autoplay; clipboard-write; encrypted-media; gyroscope; picture-in-picture; web-share"
      referrerPolicy="strict-origin-when-cross-origin"
      allowFullScreen
      style={{ position: 'absolute', top: 0, left: 0, width: '100%', height: '100%' }}
    />
  </div>
</div>

<!-- source: /mkio/getting-started/video-on-demand-vod-workflows.md -->

# 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](/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.

<!-- source: /mkio/getting-started/what-is-mkio.md -->

# 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](/api-guides/getting-started/which-api) when you are ready to automate a workflow.

<!-- source: /mkio/how-to/ai-features.md -->

# 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](/api-guides/how-to/media/transforms-and-jobs).

<!-- source: /mkio/how-to/ai-features/convert-hss-for-vod-dubbing.md -->

# 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.

> **info:** 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.

<!-- source: /mkio/how-to/ai-features/multi-language-vod-dubbing.md -->

# 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  ).

> **warning:** **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](/mkio/how-to/ai-features/convert-hss-for-vod-dubbing) guide, then return here. For supported languages and specifications, see the [AI workflows documentation](/mkio/understanding/core-concepts/vod-processing/ai-workflows).

## 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](#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**.

> **info:** **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 |

<!-- non-renderable component stripped: TabItem -->
  <!-- non-renderable component stripped: TabItem -->

**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

<!-- non-renderable component stripped: TabItem -->
  <!-- non-renderable component stripped: TabItem -->

**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

> **info:** 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:**

<ApiEndpoint
  method="PUT"
  baseUrl="https://app.mk.io/api/v1/projects/"
  path="<YOUR_PROJECT_NAME>/media/transforms/<TRANSFORM_NAME>"
  parameters={[
    { name: 'YOUR_PROJECT_NAME', description: 'Your unique project identifier' },
    { name: 'TRANSFORM_NAME', description: 'Transform name (for example, spanish-insert)' }
  ]}
  body={{
    "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.

<!-- non-renderable component stripped: TabItem -->
  <!-- non-renderable component stripped: TabItem -->

**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.

<!-- source: /mkio/how-to/ai-features/vod-dubbing-automation-multi-lang.md -->

# 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

> **warn:** **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](/mkio/how-to/ai-features/multi-language-vod-dubbing#step-1-upload-and-encode-source-video) 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

> **info:** **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=<YOUR_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.

    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)

> **info:** 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 <WEBHOOK_SECRET>"
      }
    },
    "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`
* `<YOUR_WEBHOOK_SECRET>` 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)

<!-- non-renderable component stripped: image --> Jobs" src="/images/mkio-vod-dubbing-multi-lang-2.png" />

#### 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.

<!-- source: /mkio/how-to/ai-features/vod-transcription-and-translation-transforms.md -->

# 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).

> **info:** 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/<project_name>/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/<project_name>/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.

<!-- source: /mkio/how-to/content-delivery-publishing.md -->

# 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](/api-guides/how-to/media/publishing) to automate endpoints and locators. Use the [Download asset files API Guide](/api-guides/how-to/media/download-asset-files) when you need direct access to asset files.

<!-- source: /mkio/how-to/content-delivery-publishing/integrating-amazon-cloudfront.md -->

# 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, `<endpoint-name>.<region>.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 `<id>.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://<endpoint-name>.<region>.streaming.mediakind.com/<locator-id>/...
```

**After (via CloudFront):**
```text
https://<id>.cloudfront.net/<locator-id>/...
```

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).

<!-- source: /mkio/how-to/content-delivery-publishing/stream-content.md -->

# 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**.

> **warning:** 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](https://mediakind.com/mkio/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**.

> **info:** 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://<endpoint-name>.<region>.streaming.mediakind.com/<locator-id>/<manifest-name>.ism/manifest(format=m3u8-cmaf)
https://<endpoint-name>.<region>.streaming.mediakind.com/<locator-id>/<manifest-name>.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](/api-guides/how-to/media/publishing) to automate streaming endpoints and locators through the Media API.

<!-- source: /mkio/how-to/content-management.md -->

# 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](/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](/api-guides/how-to/media/assets) and [Playback filters API Guide](/api-guides/how-to/media/playback-filters).

<!-- source: /mkio/how-to/content-management/add-an-asset-in-mkio.md -->

# 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.

> **info:** You need at least one storage account connected before creating assets. See [Connect cloud storage](/mkio/getting-started/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.

> **warning:** 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](/mkio/how-to/content-management/verify-your-assets-in-mkio) 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](/api-guides/how-to/media/assets) to create assets, reference source files, retrieve tracks, and manage asset lifecycle operations through the Media API.

<!-- source: /mkio/how-to/content-management/add-an-asset-in-mkio/bulk-asset-migration-from-ams-storage.md -->

# 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.

> **info:** Need some help with your bulk migration from AMS to MK.IO? Take a look at this [tutorial ](https://support.mk.io/portal/en/kb/articles/how-to-migrate-all-your-content-from-ams-into-mk-io)in our support portal or visit the [MediaKind support center](https://support.mediakind.com).

<!-- source: /mkio/how-to/content-management/add-an-asset-in-mkio/import-files-from-your-device.md -->

# 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).

> **info:** You need at least one storage account connected to your MK.IO project before uploading. See [Connect cloud storage](/mkio/getting-started/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).

<!-- source: /mkio/how-to/content-management/add-an-asset-in-mkio/import-your-ams-assets.md -->

# 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.

> **info:** 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.

> **success:** 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:

<!-- non-renderable component stripped: Table -->

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: [https://github.com/Azure/Azure-Media-Services-Explorer](https://github.com/Azure/Azure-Media-Services-Explorer)

This version of the Azure Media Services Explorer supports creating assets in MK.IO from existing AMS assets.

<!-- source: /mkio/how-to/content-management/add-an-asset-in-mkio/reference-existing-storage.md -->

# 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.

> **info:** 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](/mkio/getting-started/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.

> **warning:** **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?](#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).

<!-- source: /mkio/how-to/content-management/add-files-to-an-existing-asset.md -->

# 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.

> **info:** 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](/mkio/reference/encoding-transform-presets/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).

<!-- source: /mkio/how-to/content-management/create-an-asset-filter.md -->

# 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.

> **info:** 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.

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.

<!-- non-renderable component stripped: Table -->

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).

## Configure filters with the API

Use the [Playback filters API Guide](/api-guides/how-to/media/playback-filters) to create asset or account filters and apply them when publishing content.

<!-- source: /mkio/how-to/content-management/playback-your-migrated-assets.md -->

# 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.

> **warning:** 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).

<!-- source: /mkio/how-to/content-management/verify-your-assets-in-mkio.md -->

# 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).

> **default:** If you have checked the above and still cannot see your assets, visit the [MK.IO support portal](https://support.mk.io) for further help.

<!-- source: /mkio/how-to/drm-content-protection.md -->

# 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. |

> **warning:** 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](/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.

<!-- source: /mkio/how-to/drm-content-protection/clearkey-encryption.md -->

# 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 <your-jwt-token>"}
```

6. Select **Play**.

<!-- source: /mkio/how-to/drm-content-protection/create-content-key-policy.md -->

# 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` |

> **info:** 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.

> **warning:** 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.

<!-- source: /mkio/how-to/drm-content-protection/custom-claims.md -->

# 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 <YOUR_MKIO_JWT>' \
     --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.

<!-- source: /mkio/how-to/drm-content-protection/explicit-content-keys.md -->

# 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 <YOUR_MKIO_JWT>' \
     --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.

<!-- source: /mkio/how-to/drm-content-protection/external-playready-license-url.md -->

# 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 <YOUR_MKIO_JWT>' \
     --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.

<!-- source: /mkio/how-to/drm-content-protection/jwt-token-authentication.md -->

# 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": "<your-issuer>",
  "aud": "<your-audience>"
}
```

To add an expiry, include the `exp` and optionally `nbf` claims:

```json
{
  "iss": "<your-issuer>",
  "aud": "<your-audience>",
  "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 <your-jwt-token>"}
```

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.

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

<!-- source: /mkio/how-to/drm-content-protection/multi-drm-encryption.md -->

# 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. |

> **info:** 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**.

<!-- source: /mkio/how-to/drm-content-protection/openid-verification-key.md -->

# 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 <YOUR_MKIO_JWT>' \
     --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.

<!-- source: /mkio/how-to/drm-content-protection/rsa-key-for-token-validation.md -->

# 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 <YOUR_MKIO_TOKEN>' \
     --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.

<!-- source: /mkio/how-to/drm-content-protection/test-drm-playback.md -->

# 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 <your-jwt-token>"}
```

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](/mkio/how-to/drm-content-protection#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 <jwtToken>"
      }
    },
    // For Chrome, Edge browsers
    widevine: {
      LA_URL: "Widevine License URL as copied from the Assets page",
      headers: {
        "Authorization": "Bearer <jwtToken>"
      }
    },
    // For Edge (Windows) browser
    playready: {
      LA_URL: "PlayReady License URL as copied from the Assets page",
      headers: {
        "Authorization": "Bearer <jwtToken>"
      }
    }
  }
};
```

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.

<!-- source: /mkio/how-to/live-streaming.md -->

# Live events

Live events receive a continuous source for passthrough or encoding, write the output to an asset, and make the stream available for publishing. Start with the short workflow or choose a focused guide below.

## Start a live stream

- [Live stream in five minutes](/mkio/getting-started/live-stream-in-five-minutes) for a first RTMP test.
- [Configure a live event](/mkio/how-to/live-streaming/set-up-a-live-streaming-event) for passthrough, encoding, 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 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](/api-guides/how-to/media/live-streaming).

<!-- source: /mkio/how-to/live-streaming/extended-archive-window.md -->

# 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 7 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 7 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 7 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](#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://<hostname>/<asset>/index.qfm/manifest(format=m3u8-cmaf,start=<ISO8601>)
```

To return a manifest ending at a specific time:

```http
https://<hostname>/<asset>/index.qfm/manifest(format=m3u8-cmaf,end=<ISO8601>)
```

To return a manifest for a specific time range:

```http
https://<hostname>/<asset>/index.qfm/manifest(format=m3u8-cmaf,start=<ISO8601>,end=<ISO8601>)
```

Replace `<ISO8601>` 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://<hostname>/<asset>/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` |

<!-- source: /mkio/how-to/live-streaming/set-up-a-live-streaming-event.md -->

# 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 |

> **info:** 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.

> **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 7 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.

> **warning:** 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](/api-guides/how-to/media/live-streaming) to create and control live events and outputs through the Media API.

<!-- source: /mkio/how-to/live-streaming/set-up-the-source-stream-using-ffmpeg.md -->

# 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](/mkio/how-to/live-streaming/set-up-a-live-streaming-event#configure-a-live-event).                                                                                                            |
| `-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](/mkio/how-to/live-streaming/set-up-a-live-streaming-event#start-streaming).                                                                                                                                                                                                                      |

## 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
```

<br />

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

<!-- source: /mkio/how-to/live-streaming/set-up-the-source-stream-using-gstreamer.md -->

# Set up the source stream using GStreamer

Use GStreamer, a command-line tool to configure your source stream.

> **info:** 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://<rtmp-server-ip-or-url>/<path>"
```

## 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](/mkio/how-to/live-streaming/set-up-a-live-streaming-event#configure-a-live-event). `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](/mkio/how-to/live-streaming/set-up-a-live-streaming-event#start-streaming). |

<!-- source: /mkio/how-to/live-streaming/set-up-the-source-stream-using-obs.md -->

# 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)

<!-- source: /mkio/how-to/managing-edge-devices.md -->

# 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](/api-guides/how-to/fleets) for device management, backups and restores, and software update automation.

<!-- source: /mkio/how-to/managing-edge-devices/access-the-remote-device-ui.md -->

# 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.

<!-- source: /mkio/how-to/managing-edge-devices/configuration-backups.md -->

# 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 <!-- non-renderable component stripped: EllipsisIcon --> 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**.

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

5. Click **Create**.

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

> **info:** 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
2. Click <!-- non-renderable component stripped: EllipsisIcon --> on the backup you want to restore
3. Click **Restore** in the menu.
4. To restore the Asset Management service configuration, check **Restore asset file** (only applies if the backup includes it).
5. Click **Restore** to confirm.

> **warning:** 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 <!-- non-renderable component stripped: EllipsisIcon --> 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 <!-- non-renderable component stripped: EllipsisIcon -->
2. Click **Rename backup**.
3. Enter a new **Backup Name**.
4. Click **Save**.

## Download a backup

1. On a backup row, click <!-- non-renderable component stripped: EllipsisIcon -->
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 <!-- non-renderable component stripped: EllipsisIcon -->
2. Click **Delete backup**.
3. Click **Delete** to confirm.

> **warning:** Deletion is permanent. There is no recovery mechanism.

<!-- source: /mkio/how-to/managing-edge-devices/display-device-information.md -->

# 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.

<!-- source: /mkio/how-to/managing-edge-devices/on-board-fleet-devices.md -->

# 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](/api-guides/how-to/fleets/device-management) to register, inspect, update, or remove devices through the Fleet API.

<!-- source: /mkio/how-to/managing-edge-devices/on-board-fleet-devices/api-onboarding.md -->

# 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](/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](#add-the-device-using-the-mkio-api).

Once registered, the device is available for monitoring and control through MK.IO.

> **info:** **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).

> **warning:** 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](../update-device-software).

<!-- source: /mkio/how-to/managing-edge-devices/on-board-fleet-devices/common-workflow.md -->

# 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://<Control-IP-Address>`, where `<Control-IP-Address>` 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](#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](#add-the-device-using-the-mkio-ui).

Once registered, the device is available for monitoring and control through MK.IO.

> **info:** **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://<Control-IP-Address>`.
2. Go to **Appliance** > **Fleet**.
3. Select <!-- non-renderable component stripped: GearIcon --> 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://<Control-IP-Address>`.
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 <!-- non-renderable component stripped: WrenchIcon --> 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.

> **warning:** 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](../update-device-software).

<!-- source: /mkio/how-to/managing-edge-devices/on-board-fleet-devices/remove-device.md -->

# 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 <!-- non-renderable component stripped: EllipsisIcon --> 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=<reason>&notes=<notes>
```

| 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. |

<!-- source: /mkio/how-to/managing-edge-devices/on-board-fleet-devices/terminal-only.md -->

# 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](#add-the-device-using-the-mkio-ui).

Once registered, the device is available for monitoring and control through MK.IO, including its web UI.

> **info:** **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

> **warning:** The device must have connected to MK.IO before you can register it. If the device cannot reach MK.IO, see [Troubleshooting on-boarding](./troubleshooting).

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](../update-device-software).

<!-- source: /mkio/how-to/managing-edge-devices/on-board-fleet-devices/troubleshooting.md -->

# 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](./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://<Control-IP-Address>`.
2. Go to **Appliance** > **Fleet**. After a few seconds, additional information appears.
3. Click <!-- non-renderable component stripped: WrenchIcon --> 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**.

<!-- source: /mkio/how-to/managing-edge-devices/support-packages.md -->

# 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 <!-- non-renderable component stripped: EllipsisIcon --> on the device.
3. Select **Collect device logs**.

> **info:** **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.

> **info:** 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.

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

<!-- source: /mkio/how-to/managing-edge-devices/update-device-software.md -->

# 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](/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.

> **info:** **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.

<!-- source: /mkio/how-to/managing-your-organization.md -->

# 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](/api-guides/how-to/management) to automate users, teams, tokens, organizations, webhooks, usage, and billing workflows.

<!-- source: /mkio/how-to/managing-your-organization/accept-an-azure-marketplace-private-offer.md -->

# 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).

> **info:** 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.](./images/private-offer-management-ready-for-purchase.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.](./images/subscribe-to-mkio-basics-tab.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.](./images/subscribe-to-mkio-configure-account-now.png)

> **warning:** 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, or ask MediaKind to assign your existing projects to it.

## 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)

<!-- source: /mkio/how-to/managing-your-organization/access-users-and-teams.md -->

# 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)

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

> **info:** 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

> **info:** 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

> **info:** 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

> **info:** 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](/api-guides/how-to/management/users-and-teams) to manage organization membership and team access through the Management API.

<!-- source: /mkio/how-to/managing-your-organization/api-tokens.md -->

# 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](/api-guides/how-to/management/tokens) for token endpoints, authentication headers, and revocation workflows.

<!-- source: /mkio/how-to/managing-your-organization/billing.md -->

# Billing

Use the **Billing** view within **Organization settings** to see your entitlements, review your spend, and understand your usage.

> **info:** 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).

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.

## 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.

> **info:** 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**.

> **warning:** 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.

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

<!-- source: /mkio/how-to/managing-your-organization/invite-users-to-organization.md -->

# 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.

> **info:** 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.

> **info:** 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.

<!-- source: /mkio/how-to/managing-your-organization/restricted-access-tokens.md -->

# 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.

<!-- source: /mkio/how-to/managing-your-organization/subscribe-through-aws-marketplace.md -->

# 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.

<!-- source: /mkio/how-to/managing-your-organization/webhooks.md -->

# 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}
    }
  }
}
```

> **info:** 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

> **info:** 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](/api-guides/how-to/management/webhooks) for the rule lifecycle and a complete create, list, and delete workflow.

<!-- source: /mkio/how-to/migrate-from-azure-media-services.md -->

# 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.

<!-- source: /mkio/how-to/monitor-your-services.md -->

# 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.

> **default:** Metrics publishing is a chargeable service and is not enabled by default. Check [MK.IO pricing](https://mediakind.com/mkio/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.

> **default:** You can also enable metrics through the [Management API](/api-reference/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://<URL provided by MK.IO>`.
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**.

<br />

<!-- non-renderable component stripped: TabItem -->

  <!-- non-renderable component stripped: TabItem -->

  <!-- non-renderable component stripped: TabItem -->

  <!-- non-renderable component stripped: TabItem -->

<br />

<!-- source: /mkio/how-to/overview.md -->

# 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](/api-guides) organize the same platform capabilities for automation. Start with the [Media API Guide](/api-guides/how-to/media) for assets, transforms, jobs, live events, and publishing, or the [Management API Guide](/api-guides/how-to/management) for organization workflows.

<!-- source: /mkio/how-to/security-access-control/private-storage-link.md -->

# 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](/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=<redacted>"
    },
    "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](/api-guides/how-to/media/storage#update-behaviour) for the update behavior.

<!-- source: /mkio/how-to/video-processing-encoding.md -->

# 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](/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.

<!-- source: /mkio/how-to/video-processing-encoding/configure-transformations.md -->

# 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. |

> **info:** Additional transform types (for example, thumbnail generation and track insertion) are available through the [MK.IO API](/api-reference/media-api) but not in the portal. See [Reference: transform presets](/mkio/reference/encoding-transform-presets/encoding-transform) 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](/api-guides/how-to/media/transforms-and-jobs) to create and manage transforms through the Media API.

<!-- source: /mkio/how-to/video-processing-encoding/playout-of-a-vod-asset-with-thumbnail-seeking.md -->

# 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).

<!-- source: /mkio/how-to/video-processing-encoding/run-vod-transcode-jobs.md -->

# 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)

## 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.

> **default:** 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](/api-guides/how-to/media/transforms-and-jobs) to submit, monitor, cancel, and delete jobs through the Media API.

<!-- source: /mkio/how-to/video-processing-encoding/vod-processing-job-with-input-clipping.md -->

# 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"

            }
        ]
    }
}
'
```

<!-- source: /mkio/reference/cloud-region-support.md -->

# 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 [sales@mediakind.com](mailto:sales@mediakind.com).

## 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   |              |                      |                |               |

<!-- source: /mkio/reference/encoding-transform-presets/add-a-track-to-a-vod-asset.md -->

# 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.

> **default:** 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.

> **default:** 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:

<!-- non-renderable component stripped: Table -->

### HLS specific settings

<!-- non-renderable component stripped: Table -->

### DASH settings for audio tracks

<!-- non-renderable component stripped: Table -->

## 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"
								}
            }
          ]
        }
      }
    ]
  }
}
'
```

<!-- source: /mkio/reference/encoding-transform-presets/asset-conversion-transform.md -->

# 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.

> **info:** **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](/mkio/how-to/ai-features/convert-hss-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.

<!-- source: /mkio/reference/encoding-transform-presets/audio-speech-transcription.md -->

# 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)

> **info:** 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.

<!-- source: /mkio/reference/encoding-transform-presets/encoding-transform.md -->

# 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:

<!-- non-renderable component stripped: Table -->

> **info:** Audio streams are encoded in stereo with HE-AAC audio codec.

If you require a different encoding ladder, contact [MK.IO support](https://support.mk.io).

## 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

<!-- non-renderable component stripped: Table -->

## 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                                       |

<!-- source: /mkio/reference/encoding-transform-presets/how-to-generate-thumbnails.md -->

# 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.

> **warning:** 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:

<!-- non-renderable component stripped: Table -->

## 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.

<!-- source: /mkio/reference/encoding-transform-presets/transcription-and-translation-transforms.md -->

# 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).

> **info:** 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 (Mandarin, Simplified) | zh-CN |
| Chinese (Jilu Mandarin, Simplified) | zh-CN-shandong || Chinese (Jilu Mandarin, Simplified) | zh-CN-shandong |
| Chinese (Southwestern Mandarin, Simplified) | zh-CN-sichuan || 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.

<!-- source: /mkio/reference/platform-availability.md -->

# 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)

<!-- source: /mkio/reference/player-customization.md -->

# 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)

<!-- source: /mkio/reference/player-customization/css-customization.md -->

# 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)

<!-- source: /mkio/reference/player-customization/installation-and-initialization.md -->

# 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.

<!-- source: /mkio/reference/player-customization/mkcustomui-api.md -->

# 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.

<!-- source: /mkio/reference/player-customization/ui-configuration-and-variants.md -->

# 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`

<div style={{ maxWidth: '500px', width: '100%', margin: '40px auto' }}>

![customUi with basic controls](./img/customUI-preview.png)

</div>

```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`
<div style={{ maxWidth: '500px', width: '100%', margin: '40px auto' }}>

![responsive UI](./img/responsive-preview.png)

</div>
```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:

<div style={{ maxWidth: '500px', width: '100%', margin: '40px auto' }}>

![default UI](./img/responsive-factory.png)

</div>

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

<div style={{ maxWidth: '500px', width: '100%', margin: '40px auto' }}>

![default small screen UI](./img/buildDefaultSmallScreenUI.png)

</div>

- `buildModernTvUI`: modern TV playback UI layout:

<div style={{ maxWidth: '500px', width: '100%', margin: '40px auto' }}>

![default TV UI](./img/ModernTvUI.png)

</div>

<!-- source: /mkio/reference/player-sdk.md -->

# 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 [https://www.npmjs.com/package/@mediakind/mkplayer](https://www.npmjs.com/package/@mediakind/mkplayer).

Start with [Install and initialize MKPlayer](/mkio/reference/player-sdk/setup).

<!-- source: /mkio/reference/player-sdk/drm.md -->

# 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.

<!-- source: /mkio/reference/player-sdk/events.md -->

# 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.

<!-- source: /mkio/reference/player-sdk/playback.md -->

# 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](/mkio/reference/player-sdk/drm). |
| `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();
```

<!-- source: /mkio/reference/player-sdk/setup.md -->

# 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

> **warning:** 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 `<head>` of your HTML page:

```html
<head>
  <title>My Video Player</title>
  <meta charset="utf-8">
  <meta name="viewport" content="width=device-width, initial-scale=1">
  <script type="text/javascript" src="./node_modules/@mediakind/mkplayer/mkplayer.js"></script>
  <link rel="stylesheet" href="./node_modules/@mediakind/mkplayer/mkplayer-ui.css">
</head>
```

### Add a video container element

Add a `<div>` to your page `<body>`. MKPlayer uses this element as the playback container:

```html
<body>
  <div id="video-container"></div>
</body>
```

### 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.

<!-- source: /mkio/reference/player-sdk/subtitles.md -->

# 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.

<!-- source: /mkio/reference/player-sdk/walkthrough.md -->

# 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 `<head>`, and add a container `<div>` and a few controls in `<body>`:

```html
<!DOCTYPE html>
<html lang="en">
<head>
  <meta charset="utf-8">
  <meta name="viewport" content="width=device-width, initial-scale=1">
  <title>MKPlayer Example</title>
  <script type="text/javascript" src="./node_modules/@mediakind/mkplayer/mkplayer.js"></script>
  <link rel="stylesheet" href="./node_modules/@mediakind/mkplayer/mkplayer-ui.css">
  <style>
    #player-container { width: 100%; max-width: 960px; aspect-ratio: 16/9; background: #000; }
    #status { margin-top: 8px; font-family: monospace; font-size: 14px; color: #c00; min-height: 20px; }
  </style>
</head>
<body>
  <div id="player-container"></div>
  <p id="status"></p>

  <script src="./player.js"></script>
</body>
</html>
```

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);
});
```

> **info:** 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.

<!-- source: /mkio/reference/reference.md -->

# 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](/api-guides): Follow task-based guidance for Media, Management, Fleet, and Infrastructure APIs.

<!-- source: /mkio/reference/resource-states.md -->

# 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   |                                      |

<!-- source: /mkio/understanding/advanced-concepts/devices.md -->

# 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.

<div className="flex justify-center my-8">
  ![Devices Overview](/images/devices1.png)
</div>

## 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).

<!-- source: /mkio/understanding/advanced-concepts/latency.md -->

# 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.

<div className="flex flex-col items-center my-8">
  ![End-to-end latency in a live video workflow](/images/latency1.png)
  <p className="text-sm text-slate-500 mt-2 italic">End-to-end latency in a live video workflow</p>
</div>

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.

### Delay in the encoder

The delay in the Live Encoder is the sum of the delay necessary for decoding, encoding, and output.

<div className="flex flex-col items-center my-8">
  ![Latency overview in the encoder](/images/latency2.png)
  <p className="text-sm text-slate-500 mt-2 italic">Latency overview in the encoder</p>
</div>

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

<div className="flex flex-col items-center my-8">
  ![Latency overview in the packager](/images/latency3.png)
  <p className="text-sm text-slate-500 mt-2 italic">Latency overview in the packager</p>
</div>

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

<div className="flex flex-col items-center my-8">
  ![Latency overview in the player](/images/latency4.png)
  <p className="text-sm text-slate-500 mt-2 italic">Latency overview in the player</p>
</div>

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.

<!-- source: /mkio/understanding/core-concepts.md -->

# 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.

<div className="flex justify-center my-8">
  ![MK.IO media resources for live and on-demand workflows](/images/assetsunderstand.png)
</div>

## 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](/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](/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](/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](/api-guides/how-to/media/content-protection) for API-based workflows.

<!-- source: /mkio/understanding/core-concepts/api-concepts.md -->

# API Concepts

Use these API concepts and data models when building MK.IO video workflows.

<div className="flex flex-col items-center my-8">
  ![Four building blocks of the API](/images/apicon1.png)
  <p className="text-sm text-slate-500 mt-2 italic">Four building blocks of the API</p>
</div>

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.

> **info:** Every Streaming Locator you create is available at every Streaming Endpoint within your project.

## 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.

<div className="flex flex-col items-center my-8">
  ![Data Model](/images/apicon2.png)
  <p className="text-sm text-slate-500 mt-2 italic">MK.IO Data Model Overview</p>
</div>

<!-- source: /mkio/understanding/core-concepts/assets.md -->

# 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)

<div className="flex justify-center my-8">
  ![Assets Overview](/images/assetfilters.png)
</div>

## 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.

> **warning:** Deleting an asset in MK.IO may also delete the underlying files in your cloud storage, depending on the deletion behaviour set when the asset was created. 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.

<!-- source: /mkio/understanding/core-concepts/content-protection.md -->

# 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.

> **warning:** 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.

> **info:** 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

> **warning:** 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).

<!-- source: /mkio/understanding/core-concepts/endpoints.md -->

# 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.

## 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.

> **default:** 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](https://support.mk.io).

## 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.

<!-- source: /mkio/understanding/core-concepts/live-event.md -->

# 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.

<div className="flex justify-center my-8">
  ![Live Event Concept](/images/understandliveevent.png)
</div>

## 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 7 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.

### Preset Lineup Summary

| Built-in preset name | Video | Audio |
| :--- | :--- | :--- |
| **Live Encoding 720p (Foundations)** | 340x192 @ 30fps / 200kbps <br/> 384x216 @ 30fps / 550kbps <br/> 512x288 @30 fps / 850kbps <br/> 704x396 @ 30fps / 1350kbps <br/> 960x540 @ 30fps / 2200kbps <br/> 1280x720 @ 30fps / 3500kbps | 96 kbps / 48kHz |
| **Live Encoding 1080p (Advanced)** | 320x180 @ 30fps / 200kbps <br/> 480x270 @ 30fps / 400kbps <br/> 640x360 @ 30fps / 800kbps <br/> 960x540 @ 30fps / 1600kbps <br/> 1280x720 @ 30fps / 3000kbps <br/> 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.

## 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.

<!-- source: /mkio/understanding/core-concepts/locators.md -->

# 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.

> **info:** 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.

<div className="flex justify-center my-8">
  ![Streaming Locator Concept](/images/undestandlocator.png)
</div>

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.

## 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:

`/<streamingLocatorID>/<serverManifestName>.ism/manifest(<options>)`

**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:

`/<streamingLocatorID>/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`.

## 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.

<!-- source: /mkio/understanding/core-concepts/transforms-and-jobs.md -->

# 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.

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

## 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 using HTTPS URLs (including SAS URLs), or existing Assets.

<!-- source: /mkio/understanding/core-concepts/vod-processing.md -->

# 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 Transform**: Leverages AI to generate WebVTT transcription files for your media assets.
*   **[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.

#### 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.

<!-- source: /mkio/understanding/core-concepts/vod-processing/ai-workflows.md -->

# 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](/api-guides/how-to/media/transforms-and-jobs) and the [Media API Reference](/api-reference/media-api).

<!-- source: /mkio/understanding/fundamentals/orgsandteams.md -->

# 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](/api-guides/how-to/management/users-and-teams) when you need to inspect or automate the underlying access model.

<!-- source: /mkio/understanding/fundamentals/pricing.md -->

# 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.

<!-- source: /mkio/understanding/overview-understanding.md -->

# 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](/api-guides).