Search
Close this search box.

Resources

Gain Insight into Expert Perspectives, Client Experiences, Market Trends, and Cutting-Edge Innovations

OTT Workflow Monitoring: Best Practices

Share:

Effective monitoring across the OTT workflow is essential for maintaining high-quality content delivery. This involves establishing strategic monitoring setups at various stages of the delivery chain, from content acquisition to DRM/metadata to include the whole end-to-end infrastructure. This guide provides best practices for setting up a monitoring system at each critical point in the workflow, ensuring issues are promptly identified and resolved to maintain content integrity and service quality.

TAG OTT Best practices 1

Content Acquisition and Playout System

  • What to Monitor: Source content acquisition, live feeds, and playout system
  • Why Are We Monitoring: Ensures the integrity of the original content and checks for issues in live feeds
  • Probing Point Actions: Real-time monitoring for signal integrity, frame rate, and resolution

 


Configure monitoring at the Content Acquisition and Playout System to ensure the quality of source feeds. Implement real-time monitoring to assess signal integrity, frame rate, and resolution. This stage is crucial for maintaining the quality of the content at the start of the workflow.

TAG OTT Best practices 2

Thresholds/Alarms

 

  • We recommend monitoring video, audio, subtitles, and possibly SCTE markers to make sure originally received stream is good quality and complies with all internal relevant requirements. For example, ensuring the stream includes audio tracks for all of the different available languages for the specific programming and associated subtitles. 

  • The major thresholds are relevant to video: black video, video freeze, blocking, bars and no video.
  • For audio we will most importantly monitor silence/no audio and then additional thresholds based on type (i.e dolby) and if it was uncompressed also audio phasing.
  • This monitoring allows us even to troubleshoot the workflow because, obviously, if the source is bad, it will be bad throughout. 

Encoders

  • What to Monitor: Encoding process for format conversion and compression
  • Why Are We Monitoring: Verifies proper encoding to avoid quality degradation and format incompatibility
  • Probing Point Actions: Check for compression artifacts and conformity to specified codecs and resolutions

 

Set up the monitoring system to scrutinize the encoding process, focusing on compression and format conversion. Include checks for compression artifacts and verify codec compliance and resolution accuracy. Proper monitoring at this stage prevents quality degradation and format incompatibility.

There are two common formats of Packager created wrapping of compressed sources: DVB (Digital Video Broadcasting – European Consortium) and ATSC (Advanced Television Systems Committee – American set).

DVB is often used for satellite and fiber feeds of signals, there are recommended set of thresholds for SDT, BAT, EIT, NIT, AIT, TDT tables used in this standard.

  • Starting off the recommended SDT (Service Description Table), and BAT (Bouquet Association Table) Thresholds, all alarms on these sub-tables of DVB are either Critical or Major.
    The DVB’s EIT (Event Information Table) is an optional table, but if it is enabled ‘after scan’ we recommend these alarms.
  • DVB’s NIT (Network Information Table) gives information on organization of multiplexes carried via network.
  • DVB’s AIT (Application Information Table) gives full information on the data broadcast and the required state of applications used.
  • Finally, the last DVB Table we have alarms on is the TDT (Time and Date Table) time signals are required for smooth playback of DVB streams

In North America, a simpler wrapping is used by packagers, especially if OTT streams originated in over-the-air broadcasts; that wrapping standard is ATSC (Advanced Television Systems Committee – American set). Here are thresholds for MGT, VCT, STT, and RTT tables used in this standard.

  • ATSC’s MGT (Master Guide Table) is the primary description of the stream, and we recommend these thresholds.
  • ATSC’s VCT (Virtual Channel Table) contains a list of attributes for the channels within the stream, most probed element of this table are critical.
  • ATSC’s SST (System Time Table) and RRT (Rating Region Table) are either for packet timing or ratings for multiple geographical regions.

Transcoders (if applicable)

  • What to Monitor: Transcoding operations for multiple formats and bitrates
  • Why Are We Monitoring: Ensures availability of content in formats suitable for various devices
  • Probing Point Actions: Monitor for successful creation of all required profiles and bitrates

For transcoding operations, extend monitoring to oversee the creation of multiple-format profiles and bitrates. Ensure all required profiles are generated accurately and bitrates align with specified standards. This monitoring ensures content compatibility across various devices and network conditions.
Transcoded OTT signals into HLS and other formats can have numerous errors; the number of these OTT thresholds and alerts is such a large group that three screens are needed to show all the settings, with TAG’s recommendation on Critical and Major levels highlighted.

ISPs or Final Delivery to Customers


Subtitles, Teletext or Closed Captions not only assist hearing-impaired persons, but also OTT streams being monitored with audio turned down in waiting rooms and the like.

Then, we probe the primary content of the OTT streams and recommend these threshold settings, including mismatches of signals to the reference in the stream.

Packagers

 

  • What to Monitor: Segmenting and packaging content for adaptive streaming
    (eg, HLS, DASH)
  • Why Are We Monitoring: Critical for smooth adaptive bitrate streaming, crucial for
    different network conditions
  • Probing Point Actions: Validate segment availability, integrity, and compliance with streaming protocols

 

TAG MCM has many thresholds for things like expired DASH certificates that we have developed over the years with input from our clients to catch common errors with packagers.

Content Delivery Networks (CDNs)

 

  • What to Monitor: CDN performance, including edge servers
  • Why Are We Monitoring: Affects content delivery speed and buffering; key for global distribution
  • Probing Point Actions: Monitor latency, packet loss, and throughput at
    various geographic locations
  •  

If a CDN server gets overwhelmed with clients but has not yet failed, it will often increase the inter-packet timing, and the MCM has an alarm threshold to report that change.

Origin Servers

 

These servers are usually the last point before CDN servers, where video is stored or composed.

  • What to Monitor: Server performance and content availability
  • Why Are We Monitoring: Ensures content is readily available for distribution to CDNs
  • Probing Point Actions: Check server health, load, and response times


Many clients use TAG MCMs to confirm high-quality audio, video, and metadata in all streams from Origin Servers. An example would be our video blocking level alerts, where the compression blocks are evident to the viewer.

Cloud Computing Resources (if used)

  • What to Monitor: Cloud infrastructure and services
  • Why Are We Monitoring: Cloud failures can impact content availability and delivery
  • Probing Point Actions: Monitor cloud resource utilization, scalability, and redundancy


Most cloud providers provide monitoring services, but the TAG MCS software just shows the health of the cloud instances where MCM is running.

Edge Devices (Set-top boxes, Sticks like Chromecast, Roku, and Amazon Fire Stick)

  • What to Monitor: Final content delivery and playback on consumer devices
  • Why Are We Monitoring: Directly impacts viewer experience, crucial for QoE
  • Probing Point Actions: Collect data on playback issues, buffering, app crashes, and device compatibility


Some non-TAG software products monitor devices; we can only monitor one of these devices if its output is converted to an IP stream by a third-party converter and sent back to an MCM.

Metadata and DRM Systems

  • What to Monitor: Metadata accuracy and DRM (Digital Rights Management) functionality
  • Why Are We Monitoring: Ensures content discoverability and compliance with licensing agreements
  • Probing Point Actions: Validate metadata integrity and DRM effectiveness


TAG MCMs have several thresholds for OTT certificate errors, and DVB Conditional access specific data to help monitor DRM before being sent to the end customer. It is also common for the DRM vendors to also have monitoring tools in this area.

Network Infrastructure

  • What to Monitor: Internal and external network performance
  • Why Are We Monitoring: Network issues can lead to delivery failures or degraded quality
  • Probing Point Actions: Continuous monitoring of network health, bandwidth,
    and connectivity

Many MCMs alert thresholds can be used to detect network issues, like continuity errors or even an increase in Inter Packet Timing.