Phil Cluff Archives – The Broadcast Knowledge

Server-Side AD Insertion sounds like a sure-fire way to insert ads without ad-blockers noticing, but it’s not without problems – particularly on OTT devices plugged into the living room TV. As people are used to watching broadcast television on the TV, some of those expectations of broadcast TV are associated with whatever they watch on TV. The quick channel changing, low latency and constant quality are expected even if the viewer is watching a mini OTT streaming device plugged into HDMI input 2.

Phil Cluff from Mux looks at the challenges that devices other than computers throw up when using SSAI at this talk from Mile High Video. In general, OTT devices don’t have much memory or CPU power which renders Client-Side ad insertion impractical. SSAI can be achieved by manipulating the manifest or by rewriting timestamps on video segments. The latter damages the ability to cache chunks, so Phil explores the challenges of the former technique. On the surface, just swapping out some chunks by changing the manifest sounds simple looking at games consoles, smart TVs, streaming boxes and set-top boxes. Unsurprisingly streaming boxes like Apple TV and Roku boxes support the features needed to pull off SSAI fairly well. TVs fair less well, but those relying on Android tend to have workable solutions, explains Phil. The biggest hurdle is getting things working on set-top boxes of which there are thousands of variations, few of which support DRM and DASH well.

Phil examines the rollout of smart TVs finding that most are more than 3 years old which typically means they are on old firmware supporting features that existed when the TV was released but nothing more recent…such as supporting manifest manipulation. With this bleak picture, Phil attempts to ground us saying that we don’t need to deliver ads on all devices. Most services are able to find a core set of devices which form 80% or more of their viewership which means that supporting ads on devices outside of that core is unlikely ever to be profitable. And if it’s not profitable, is there any need to ever show ads on that device? Initially, it doesn’t feel right to deliver without ads to some devices, but if you look at the numbers, you may well find that your development time will never be paid back. An alternative solution is to deliver ads to these people by getting them to watch on Chromecasts you provide instead of on their STB which is a more common option than you may expect.

Phil finishes his talk looking at the future which includes a HbbTV spec specifically aimed around SSAI and a continued battle to find a reliable way to delivering and recording beacons for SSAI.

Watch now!
Speaker

Phil Cluff
Streaming Architect,
Mux

There are plenty of videos detailing the latest streaming protocols, but not many which teach you how to literally put one together let alone ones that build it during the talk. Being a system of many components, there are countless permutations of how you could go about building a system, so how can you work out which ones you need and is there an easier way?

MUX’s Phil Cluff presents this talk for WeAreDevelopers to explain streaming and implement it as we watch. He begins by helping us think through exactly what we’re looking to get out of our service and using the budget we have to steer us towards, or way from, free services like YouTube and Twitch. The alternatives being OVPs such as Brightcove or aides supporting your self-sufficiency.

With motivations out of the way, Phil examines the whole chain starting with ‘Capture’. Whilst you’ll need a camera, he recommends the open-source project OBS to provide easy web page integration and a system which can be for general operation or for emergencies. Next is processing which typically includes dealing with old films/negatives. For distribution, Phil spends a couple of minutes describing the CDN in use.

Phil looks at why simply using the ‘video’ entity in HTML isn’t a solution for most streaming applications quickly moving on to discuss the large amount of ingest which still happens via RTMP, explaining the information needed to ensure the RTMP stream can connect. Phil next discusses ABR (Adaptive Bitrate Streaming) showing how it works with different resolutions and chunks. We then look further afield to MPEG-DASH to see how that delivers ‘MPEG Dynamic Adaptive Streaming over HTTP’ and look at the internals of manifest files.

In the next part of the talk, Phil shows us how to put together a page which delivers ABR streaming from an OBS camera which he also sets up and adds graphics to. Streaming into the cloud using RTMP we see the way Phil sets up OBS and configures it with a Stream Key. He then shows us how to create a player with HLS.js by prototyping a page, as we watch, in codesandbox.io. Finally he looks at some of the more advanced things you can do such as watermarking, getting credentials for social media simulcasts before fielding questions from the audience such as how to stream from the browser, realtime engagement APIs, Low Latency delivery (including Apple LL-HLS) and data privacy.

Watch now!
Speakers

	Phil Cluff Streaming Architect, MUX
	Moderator: Stefan Steinbauer Director, Developer Experience WeAreDevelopers GmbH

APIs underpin our modern internet and particularly our online streaming services which all. An API is a way for two different programs or services to communicate with each other; allowing access, sharing locations of videos, providing recommendations etc.

Phil Cluff from Mux, takes a look at the evolution of these APIs, showing the simple ones, the complex and how they have changed as time has gone on, culminating in advice to the APIs writers of today and tomorrow.

Security is a big deal and increasingly is in focus for video companies. Whilst the API itself is usually sent over secure means, the service still needs to authenticate users and the use of DRM needs to be considered. Phil talks about this and ultimately the question comes down to what you are trying to protect and your attack surface.

APIs tend to come in two types, explains Phil, Video Platform vs ‘Encoding’ APIs. Encoding APIs a more than pure encoding APIs, there is transcoding, packaging, file transfer and other features built in to most ‘encoding’ services. Video Platform APIs are typically for a whole platform so also include CDN, Analytics, Cataloguing, playback and much more

In terms of advice, Phil explains that APIs can enable ‘normal’ coders – meaning people who aren’t interested specifically in video – to use video in their programs. This can be done through well thought out APIs which make good decisions behind the scenes and use sensible defaults.

API is so important, asserts Phil, that it should be considered as part of the product so treated with similar care. It should be planned, resourced properly, be created as part of a dialogue with customers and, most importantly, revisited later to be upgraded and improved.

Phil finishes the talk with a number of other pieces of advice and answers questions from the floor.

Watch Now!

Speaker

Phil Cluff
Streaming Specialist,
Mux

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