[For later use] Content and sources (COPY)

✏️

This is a beta feature and may have incomplete functionality or bugs; breaking changes may be introduced.

Content and sources represent the ingress edge of the MK.IO system. flow inputs always reference content directly. Sources are selected automatically by the system to supply content to a flow.

Content and sources are part of the Flows API.

Content

Content resources represent media content such as a camera in a stadium for pre-production content or a TV channel in post-production content. Content is made up of one or more sources and is always referenced from a flow input. A content resource can be created with:

PUT https://api.mk.io/api/projects/myproject/v1/flow/content/sports1

{
    "metadata": {
        "displayName": "Sports 1"
    }
}

We recommend that content be linked to relatively static references such as a TV channel or a camera rather than frequently changing references like a specific TV show or a specific football game. This is not a hard rule, but it helps to reduce the number of API calls required for ongoing usage of a system.

Sources

Sources represent the streams of media flowing into the system that carry the content. The same content can be delivered, via multiple sources, to:

• Supply content in different formats (e.g. H.264, HEVC, JPEG-XS, etc.) to be distributed to multiple consumer populations with different kinds of end-user devices (set-top boxes, smart phones, etc.), or
• Supply content replicated over more than one network to support high availability.

As an example, a source representing an external SRT caller that needs to call into a SaaS media processing flow can be created with:

PUT https://api.mk.io/api/projects/myproject/v1/flow/sources/sports1-primary

{
    "metadata": {
        "displayName": "Sports 1 - Primary"
    },
    "spec": {
        "contentName": "sports1",
        "networkName": "internet",
        "transport": {
            "type": "SRTCaller",
            "port": 5000,
            "ipResource": {
                "type": "External"
            },
            "encryptionStandard": "AES128",
            "passPhrase": "chooseasecret"
        }
    }
}

Note that the spec.ipResource.type is External to indicate that a public URL will need to be reserved in the public cloud to allow the caller to reach the SRT listener that will be set up by MK.IO.

Sources can be used directly by more than one flow at a time if that source traffic can be replicated, e.g. SRT traffic can be replicated, SDI cannot (however the SDI source can be replicated on the output of a flow).

Sources contain transport information that specifies how to connect to the data stream and its format. There are two broad categories of sources:

• Networked
• Directly-connected

Networked sources are the most common and conventional source, they indicate that the source is delivered over an IP network. Source transport types (spec.transport.type) that work this way include SRTCaller, SRTListener and UDP. Networked sources exist on a network, so if a flow needs to be able to successfully resolve content to a source, the flow must be on a site that has a route to the source's network.

Directly-connected sources have a direct reference to a device interface in the source's transport information. For example "url": "sdi://device1/board_1_connector_1". SDI/ASI sources are directly-connected. Where content is delivered to a flow on a directly-connected source, that flow must be assigned to the device which hosts the source interface.

The spec.transport.url field follows a specific format:

sdi://<device_name>/board_<board_index>_connector_<connector_index>

The device_name creates a hard reference to a device; the board_index and connector_index create a hard reference to a device interface. This means that a flow that resolves the content on a flow input to the SDI source, must be assigned to the specified device and the specified SDI interface cannot be shared with other active flows.

🎓

Read Set up transports on sources and destinations to learn more about configuring the various kinds of transform.

📘

Transport direction

As mentioned, sources are a representation of the external content stream and the transport type in a source represents the external end of the connection. So if the content stream is being provided by an SRT caller, then we would use the SRTCaller transport type in the source. The configuration parameters for an SRT caller transport are therefore not what you would feed into a caller, they are the configuration parameters that MK.IO needs to configure an SRT listener inside the MK.IO system.

Resolving content

When content is referenced by a flow input, the system automatically tries to find a way to deliver the content to the flow input. There are two resources that can fulfil the content requirements of a flow input:

1. Sources
2. Internal flow outputs

If the system can find a source that can directly deliver the required content to the flow, then it will use the source. The source must be on a network that is accessible to the site that the flow will run on.

If the system cannot find a source to directly deliver the required content to the flow, then it starts looking for flows that output the required content with internal flow outputs. Again, the internal flow output, must be on a network that is accessible to the site that the flow will run on.

To be chosen, sources and internal flow outputs must meet a range of other compatibility criteria too. For example, for an on-prem site, a device must be found with network compatibility. Sources and internal flow outputs must also pass any refiners on the flow inputs, read the Flows page for details on which refiners are supported.