Included Use Cases

Introduction

The previous chapters have shown how Manifest Edit comes with a preinstalled Plugins Library and how these can be combined, by means of the Pipeline Configuration File, into pipelines.

We encourage users to think creatively about the possible different ways of combining plugins to realize specific functionalities they may need. However, we think it's very useful to provide a list of specific use cases that Unified Streaming has encountered and how they can be solved by Manifest Edit.

MPD Use Cases

UTC Timing Removal

This use case is based on the utc_remove plugin.

In this use case, the UTCTiming element is removed from a LIVE manifest. This is not recommended in general: best practices for LIVE streaming recommend to keep this element. However, in this particular use case the involved players were unable to reach the specified time server, triggering security alerts. This use case helped reducing noise and false warnings in the network monitoring application.

mpd:
- manifest_edit.plugins.mpd.utc_remove:
    - '*'

You can find a similar configuration in the provided utc_add.yaml file available in the example folder.

UTC Timing Format/Server Change

This use case is based on the utc_remove plugin and utc_add plugin.

In this use case, the customer wanted to use its own implementation of a time server, using the NTP protocol and related time format. At this purpose, both the format and value of the UTCTiming element needs to be changed. This can be accomplished by first removing the original element, then adding one in the desired format.

mpd:
- manifest_edit.plugins.mpd.utc_remove:
    - '*'

- manifest_edit.plugins.mpd.utc_add:
    ntp:
      https://myserver.mydomain/?ntp

You can find a similar configuration in the provided utc_change.yaml file available in the example folder.

Track Reordering

These use cases are based on the manifest_order plugin.

These use cases are all realized applying different configurations to the manifest_order plugin.

You can find other examples of similar configurations in the provided adaptation_sets_order.yaml, adaptation_sets_representations_order.yaml, representations_order.yaml files available in the example folder.

Set First Track

In this use case, a single Representation is selected from a "video" adaptation set and moved so it appears before all others. Specifically, this use case requires a track with a specific language to be the first.

mpd:
- manifest_edit.plugins.mpd.manifest_order:
    periods:
      - '*' : '.*'
        adaptationSets:
          plugin_config:
            manualOrder:
              - lang: 'en'
                contentType: 'video'

Order Tracks by language

In this use case, all adaptation sets are sorted by language, in ascending alphabetical order.

mpd:
- manifest_edit.plugins.mpd.manifest_order:
    periods:
      - '*' : '.*'
        adaptationSets:
          plugin_config:
            orderBy :      "lang"
            orderCriteria: "asc"

Order Tracks in order of descending bitrate

In this use case, all adaptation sets are sorted by bandwidth, in descending order.

mpd:
- manifest_edit.plugins.mpd.manifest_order:
    periods:
      - '*' : '.*'
        adaptationSets:
          plugin_config:
            orderBy :      "bandwidth"
            orderCriteria: "desc"

Low Latency

This use case is based on the descriptor_add plugin and the service_description_add plugin.

In this use case, DASH Low Latency parameters are added to a manifest for players that support this functionality. This is achieved by adding a Service Description to the MPD element and Supplemental Properties to each adaptation set.

This use case replicates the DVB-DASH Low Latency Mode provided by the Origin.

mpd:
# This is an example of how you can combine multiple plugins in a
#  multi-stage processing pipeline.
- manifest_edit.plugins.mpd.descriptor_add:
    # Low Latency needs this Supplemental Property for every adaptations set
    periods:
      - '*' : '.*'
        adaptationSets:
          - '*' : '.*'
            plugin_config:
              name: "SupplementalProperty"
              schemeIdUri : "urn:dvb:dash:lowlatency:critical:2019"
              value: "true"

- manifest_edit.plugins.mpd.service_description_add:
    # Low Latency requires to add a Service Description element to the
    #  mpd root. The "urn:dvb:dash:lowlatency:scope:2019" schemeIdUri is
    #  required. Latency and PlaybackRate are optional.
    - id: '1'
      Scope:
        - schemeIdUri: "urn:dvb:dash:lowlatency:scope:2019"
          # value: '' #optional
          # id: ''    #optional
      Latency:
        min: 1500
        max: 6000
        target: 3000
        #reference_id: 0 #optional
      PlaybackRate:
        - min: '0.5' # Etsi Real value, must be provided as strings
          max: '1.5' # Etsi Real value, must be provided as strings

If required, an Essential Property can be used instead of a Supplemental Property. In this case, the configuration would be the following:

mpd:
# This is an example of how you can combine multiple plugins in a
#  multi-stage processing pipeline.
- manifest_edit.plugins.mpd.descriptor_add:
    # Low Latency needs this Essential Property for every adaptations set
    periods:
      - '*' : '.*'
        adaptationSets:
          - '*' : '.*'
            plugin_config:
              name: "EssentialProperty"
              schemeIdUri : "urn:dvb:dash:lowlatency:critical:2019"
              value: "true"

- manifest_edit.plugins.mpd.service_description_add:
    # Low Latency requires to add a Service Description element to the
    #  mpd root. The "urn:dvb:dash:lowlatency:scope:2019" schemeIdUri is
    #  required. Latency and PlaybackRate are optional.
    - id: '1'
      Scope:
        - schemeIdUri: "urn:dvb:dash:lowlatency:scope:2019"
          # value: '' #optional
          # id: ''    #optional
      Latency:
        min: 1500
        max: 6000
        target: 3000
        #reference_id: 0 #optional
      PlaybackRate:
        - min: '0.5' # Etsi Real value, must be provided as strings
          max: '1.5' # Etsi Real value, must be provided as strings

You can find similar configurations in the provided low_latency.yaml and low_latency_with_essential_property.yaml files available in the example folder.

Adaptation Sets Switching

This use case is based on the descriptor_add plugin and the adaptation_sets_switching plugin.

In this use case, the customer wants to offer the same content with different encryption keys for different resolutions (HD and SD). The DASH implementation guidelines (Chapter 7) clearly states that in this case, two different adaptation sets must be created. This is the default behavior of Unified Origin.

For such scenarios, the separate adaptation sets can be added to a same Switching Set to enable seamless switching functionality in players supporting it.

The following example adds all the "video" adaptation sets of a manifest to the same Switching Set:

mpd:
- manifest_edit.plugins.mpd.adaptation_sets_switching:
    periods:
      - '*' : '.*'
        adaptationSets:
          - contentType: 'video'
            plugin_config:
              switching_set: '1'
              destination: 'supplemental_property'

- manifest_edit.plugins.mpd.descriptor_add:

You can find a similar configuration in the provided adaptation_sets_switching.yaml file available in the example folder.

Sidecar subtitles removal

This use case is based on the element_remove plugin.

The customer's toolchain may involve a third-party ad-insertion tool that does not support the presence of "sidecar" subtitles along with fragmented ones. The Origin's default behavior is instead to add by default such sidecar subtitles, which are carried in an adaptation set with contentType = 'text' and mimeType = 'text/vtt'. For such scenario, it is possible to remove with manifest-edit the unsupported adaptation set by means of the following configuration:

mpd:
- manifest_edit.plugins.mpd.element_remove:
    periods:
      - '*' : '.*'
        adaptationSets:
          - contentType : 'text'
            mimeType: 'text/vtt'
            plugin_config:
              remove: 'this'

You can find a similar configuration in the provided adaptation_sets_removal.yaml and representations_removal.yaml files available in the example folder.

Accessibility and Role manipulation

This use case is based on the descriptor_add plugin.

The customer's use case involved a specific device that would refuse to play captions unless signalled specifically as audio description for the hard of hearing.

This would correspond to appropriately settings the Accessibility and Role elements in those Adaptation Sets having a contentType set to text.

This is achievable by means of a combination of the descriptor_add and descriptor_remove plugins. The manifest in fact could already include Accessibility and Role elements, probably with different schemeIdUri and value content.

It is best to first remove the existing Accessibility and Role and then add the ones that are surely compatible with the device.

The resulting configuration is:

mpd:
  - manifest_edit.plugins.mpd.descriptor_remove:
      periods:
        - '*' : '.*'
          adaptationSets:
            - contentType :  "text"
              plugin_config:
                name: "Accessibility"
            - contentType :  "text"
              plugin_config:
                name: "Role"

  - manifest_edit.plugins.mpd.descriptor_add:
      periods:
        - '*' : '.*'
          adaptationSets:
            - contentType :  "text"
              plugin_config:
                name: "Accessibility"
                schemeIdUri: "urn:tva:metadata:cs:AudioPurposeCS:2007"
                value: "2"
            - contentType :  "text"
              plugin_config:
                name: "Role"
                schemeIdUri: "urn:mpeg:dash:role:2011"
                value: "main"

Adding a "value" attribute to EventStreams

This use case is based on the eventstream_value_add plugin.

The customer's use case involves a specific device that would crash if a "value" field is not present in EventStream elements.

Despite recognizing that "value" is an optional attribute and that this behaviour is clearly faulty on the device side, this plugin seems the easiest way forward to provide compatibility.

The specific content of the "value" element is not important, however this plugin allows to configure it. We will just use the string "1" in this example.

This is the resulting configuration:

mpd:
- manifest_edit.plugins.mpd.eventstream_value_add:
    value: "1"

HLS Use Cases

Default Subtitle/Audio Language

This use case is based on the default_language plugin.

The customer needs to serve several regions with different languages. They need players to automatically start playback of the audio track with the region's main language. Unfortunately the DEFAULT audio track is determined at packaging time and that implies having different manifest per region, which is undesirable.

With Manifest Edit, it is possible to change the manifest on the fly and have audio or subtitle tracks default to a specific language.

The solution is based on having one pipeline configuration file per language and the use query parameters to select the pipeline applying the desired one.

For audio tracks (but the same applies to the subtitle case, just use type: 'SUBTITLES'), if we suppose to support two languages, i.e. Swedish and Danish, the solution would involve creating two pipeline configuration files such as the following:

default_swedish.yaml:

m3u8_main:
  - manifest_edit.plugins.m3u8_main.default_language:
    - type: 'AUDIO'
      language: 'sv'
      default: 'YES'

default_danish.yaml:

m3u8_main:
  - manifest_edit.plugins.m3u8_main.default_language:
    - type: 'AUDIO'
      language: 'da'
      default: 'YES'

If your configuration reflects the one suggested in the installation manual ( see Enabling Manifest Edit), then you would use either one of the following URL to select the desired language:

http://my-origin.com/my-video.ism/.mpd?python_pipeline_config=default_swedish
http://my-origin.com/my-video.ism/.mpd?python_pipeline_config=default_danish