Video: The Future of SSAI on OTT Devices

Whether it’s to thwart ad blockers or to compensate for unreliable players, server-side ad insertion (SSAI) has an important role for many ad-based services. Phil Cluff is here to look at today’s difficulties and to look into the future.

Talking at the August Seattle Video Tech meet up, Phil looks at how we got where we are and why SSAI came about in the first place. He then looks at the manifest-manipulation method of doing this before seeing how well OTT devices actually support it showing inconsistent support for DRM in DASH and HLS. Smart TVs are a big problem delivering consistent viewing with all being different and even the new ones being delivered into the market now are few compared to the older, 5+ year-old TVs.

One solution to levelling the playing field is to distribute Chromecasts which works fairly well in allowing any device to be come a streaming device. Another option is to use server-side sitting SSAI meaning the video stream itself has the advert in it. One problem with this approach is the impracticality to target individual users. HbbTV and ATSC 3.0 are other ways to deliver adverts to the television.

Beacons are a way of players singling back to the ad networks that adverts were actually shown so Phil takes a look at how these will change as time moves on before opening up to questions from the floor.

Watch now!
Speakers

Phil Cuff Phil Cluff
Streaming Specialist,
Mux

Video: The Evaluation Process of Ultra Low-Latency Solutions

Patrick Debois summarises the world of low-latency players from his perspective of wanting to deploy his own solution.

Low- and ultra low-latency is an emerging market in the sense that there are few standards and getting the solutions working at scale and across all platforms is difficult and is a ‘work in progress’. As such, selecting a player is a compromise and there are many issues at play.

Patrick covers the following aspects:

  • DIY vs ‘as a service’ models
  • Different methods of ingest (replacing RTMP?)
    Platform support & SDK size
  • Synchronised play.
  • Ad support
  • Hangouts
  • Stream protection
  • Redundancy & Load testing
  • Load testing
  • Streaming costs & pricing models
  • Network compatibility of non-HTTP-based solutions
  • ABR support
  • Debug options and detecting stream failure
  • Quality analytics & monitoring support
  • Support

Watch now!
Speakers

Patrick Debois Patrick Debois
CTO & Co-founder,
Zender

Video: Red and Blue, or Purple; Your IP Media Network, Your Way


Leaf & spine networks have started taking over data centres in the last few years. It’s no secret that people prefer scale-out over scale-up solutions and you can see a similar approach in ST 2110 networks, when large monolithic video switches are replaced with smaller leaf and spine switches.

Leaf and spine refers to networks where a number of main, high throughput switches link to a number of smaller switches. These smaller switches tend to be aggregators and offer the promise of cheaper ports delivered closer to your equipment. The alternative to leaf & spine is monolithic switches which do have their merits, but are certainly not always the right choice.

To provide non-blocking switching in leaf & spine networks you need an SDN controller that orchestrates media flows. Advances in SDN capabilities have led to the emergence of “Purple” network architectures. In this video Gerard Phillips from Arista shows how it differs from a “Red/Blue” architecture, how path diversity is maintained and how ST 2110 IP live production or playout applications could benefit from it.

It’s important to be aware of the different uses of Layer 2 vs Layer 3:

    • Layer 2 devices are typically used for audio networks like Dante and RAVENNA. A layer 2 network is a simple, scalable and affordable choice for audio flows where there are no challenges in terms of bandwidth. However, this type of network doesn’t really work for high bit rate live production video multicast since all multicasts need to be delivered to the IGMP querier which isn’t scalable.

    • Layer 3 have distributed IGMP management since PIM is used on each router to route multicast traffic, so there is no more flooding network with unnecessary traffic. This type of network works well with high bit rate video multicasts, but as IGMP is not bandwidth aware, it’s best to use an SDN system for flow orchestration.

Gerard then looks at resilience:

  • Using 2022-7 seamless switching (plus a robust monitoring system that can provide quick, accurate information to resolve the issue)
  • Choosing quality components (switches, NOS, fibres etc.)
  • Providing redundancy (redundant PSU, fans, fabric modules etc., redundant links between switches, ensuring that routing protocol or SDN can use these “spares”)
  • Dividing up failure domains
  • Using leaf and spine architecture (routing around failed components with SDN)
  • Using resilient IP protocols (BGP, ECMP)

The talk finishes up discussing the pros and cons of the different architectures available:

  • Monolithic systems which are non-blocking, but have a wide failure domain
  • Monolithic – expansion toward spine and leaf with SDN for non-blocking switching
  • Leaf & spine with air-gapped Red and Blue networks
  • Leaf & spine hybrid with Purple switches connected to both Red and Blue spines to support single homed devices
  • Leaf & spine Purple. Here, red and blue flows are connected to physically separate switches, but the switches are not identified as red and blue anymore. This is a converged network and an SDN controller is required to provide diverse paths flows to go to two different spines.

You can download the slides from here.

Watch now!

Speaker

Gerard Phillips Gerard Phillips
Systems Engineer
Arista Networks

Video: Microservices & Media: Are we there yet?

Microservices split large applications into many small, simple, autonomous sections. This can be a boon, but this simplicity hides complexity. Chris Lennon looks at both sides to find the true value in microservices.

By splitting up a program/service into many small blocks, each of those blocks become simpler so testing each block becomes simpler. Updating one block hardly affects the system as a whole leading to quicker and more agile development and deployment. In fact, using microservices has many success stories attributed to it. Less vocal are those who have failures or increased operational problems due to their use.

Like any technology, there are ‘right’ and ‘wrong’ times and places to deploy it. Chris, from MediAnswers, explains where he sees the break-even line between non-deploying and deploying microservices and explains his reasons which include hidden comlexity, your teams’ ability to deal with these many services and covers some of the fallacies at play which tend to act against you.

A group has started up within SMPTE who want to reduce the friction in implementing microservices which include general interoperability and also interoperability across OSes. This should reduce the work needed to get microservices from different vendors working together as one.

Chris explains the work to date and the plans for the future for this working group.

Watch now!
Speakers

Chris Lennon Chris Lennon
President & CEO,
MediAnswers