Watch the recording and dive into smooth advertisement playback on smart TVs with top-notch SSAI ad-insertion

Pieter-Jan: Okay, it looks like it's about five minutes past the hour. So those people who haven't joined yet, they can still dial in a bit later. I would say welcome everybody! We have today actually a very interesting conversation lined up topic. We've gotten a lot of questions about and it's actually about how can you actually do server-side ad insertion on Smart TV.

We're going to take a little bit of an atypical approach on this. This is a webinar, but we will be going through a lot of the questions that we've heard, a lot of the statements that we've heard over the past months. And we'll try to give some context, some answers to these. And of course, at the end of the session, we have reserved some time for a live Q&A session. If you have questions, you can already post them into the Q&A window. I see that our marketing team has already posted a message there. You can find that in the lower right corner.

So, yeah, let's start digging into it. For those of you who don't know me yet, well, I'm actually Pieter-Jan, PJ for short. Feel free to call me PJ. It's a lot easier in English. CTO of THEO Technologies. We're, of course, known for THEOplayer, with which we're trying to improve streaming for everyone one step at a time. And I'm actually very happy to have Matthew here with me, somebody with some proper server-side ad insertion knowledge.

Matthew: Yes, thanks, PJ., My name's Matt, I'm the engineering manager for our MediaTailor ad insertion team here at AWS Elemental. So, we focus pretty much exclusively on SSAI and SSAI workflows.

Pieter-Jan: Great. I would say let's get started and let's dig immediately into it. And of course, one of those first questions that we often hear is a very simple one: why is SSAI important, especially for smart TVs?

Well, a lot of people who have been following THEO Technologies, you know that we've talked a lot about smart TVs in the past. And it's quite clear that smart TVs are some of the biggest and most optimized screens that you can actually find to consume video. It's no surprise that people being confined in their homes for last year, in close proximity to these devices, that usage has gone up. Conviva has actually reported in their last state of streaming that it grew by no less than 115% in Q1 2021 compared to 2020. And that's even when you look at Q2, when a lot of countries went into hard lockdowns, there was even more growth. So, well, that's pretty significant! Definitely a lot of usage on big screens these days. But of course, when you think big screens, a lot of people are thinking broadcast experiences. Smooth quality of experience, seamless transitions between different pieces of content. And while playing content is one thing, but you also have to monetize it. A lot of people know the subscription-based models on smart TVs. But given that a family's total budget usually is limited, a very common approach is also using ads. Usually, in smart TVs it's linear ads, which give an impression-based ad revenue. And with server-side ad insertion, you can actually start simulating this broadcast experience, but you have the potential of targeting advertisements to specific groups of users. I don't know how you see this, Matthew, but monetizing, that's important for everybody. So, I think that this is a little bit of the obvious statement that this is something to keep in mind.

Matthew:  I think you're absolutely right. And I think a lot of it also comes down to the technology. And because you can look at this and think - well, that's great, PJ, that sounds like monetization is important for smart TVs, but I don't know why SSAI would be important specifically for smart TVs. And I think that gets into the next topic that we want to talk about, which is - what components exist in the SSAI solutions that you want to build. And why is it that we're promoting SSAI is the right way to monetize content, right? So, I think, why don't we move to that, and we can we can talk a little bit about like what goes into actually getting ad insertion to work for smart TVs. And I guess, SSAI in general.

Matthew: So, we've put together for this webinar a diagram that just outlines a very simple workflow for, in this case, this is a linear streaming workflow. But it can be modified very easily to support video on demand. And I would say that obviously you start with your content, wherever that content is originating from - if it's static content, you have a library of shows, of previously broadcasted material: movies, anything. You'll likely be hosting that in some format like S3 or some other content origin. For live content though, you'll need a live encoder and then something to package that content and provide DRM protection, etc. In this workflow, we've outlined a media live encoder that pushes content to media packager that can do repackaging to the various formats that your smart TVs might require. And also of course, any encryption that you might need or other kinds of content preparation you might want to do.

We sit sort of in the middle of the packager and the clients and intercept content. So, we would be media tailors, what's known as a stitcher in the industry. We are responsible for orchestrating the SSAI workflow and ensuring that ads can be served in line with the content. So why is this the right approach and why does this architecture make sense for us? I think we'll get into a little bit more of what some of the challenges are of doing SSAI on smart TVs. But effectively, this makes the point of integration with a smart TV pretty straightforward - your smart TV platform only has to know the address of whatever content is streaming, you don't have to sideload any content. PJ, I think has a lot to say about that and how smart TVs works, I'll let him jump in there in a second.

But effectively, you've got your encoder, you've got your packager, you have the stitcher that's responsible for bringing the ads together with that content. There's of course an ad decisioning server that is integrated with the stitcher. And then you need to store those ads somewhere so that they can be served in line with that content. And then of course we can't forget typically there is almost always a CDN. If you're doing anything at scale, you'll need somewhere to cache those video segments before they're served to clients, otherwise, you'll have latency problems or you'll tip over your origin. So, I think that's at a very high level the components we're dealing with that go into getting ad inserted or personalized content to a smart TV. PJ, is there anything we want to add about the architecture?

Pieter-Jan: From a client side, of course, we usually look at it from a client perspective as well. But I think, this is a great overview. It has all of the components that you would normally have in an SSAI overview. And as you mentioned, it's very important to really get your setup right. I think that's actually one of the most important things here. Server-side ad insertion, it is, as you already mentioned, a good fit for Smart TVs, why? Because, well, the Smart TV only has to know about that streaming URI. But even then, there's a lot of things that can actually go wrong. And of course, one of those questions that we also get quite often, I assume that it's the same for you. That's the question - doesn't server-side ad insertion influence the quality of experience in a negative way? And to me personally, this question makes a lot of sense. I've seen plenty of bad server-side ad insertion and client-side ad insertion implementations.

But if you really think about it, server-side ad insertion, it was actually designed to solve the QoE problem that a lot of people see with client-side ad insertion. With client-side ad insertion, a lot of the solutions, they use different assets, they require preloading by a player, especially, if you would try to do this on smart TVs, this is something which is very complex. Smart TVs - big devices, very nice, built for playing video, but not built for playing two videos at the same time, not built for preloading your client-side assets. With server-side ad insertion, you can actually avoid this because, let's be honest, the client is just playing one feed, it can be a broadcast feed, it looks like normal feed. Of course, there are still problems that can pop up. You can still have server-side ad insertion done the wrong way - you can have different sound levels, you can have different resolutions, different codecs, you can have a lot of things which go bad if you don't prepare your content well. I mean, with broadcast ads, all of this is tuned perfectly. There's a lot of time, a lot of effort going into this to really stage them frame accurately as well. And you can say a lot about liking or hating ads, but even if you hate ads, the way how you would want your ads is without spinners, frame accurately with high quality of experience. And well, if you don't get a good experience, in the end, you'll install an ad blocker and try to block it anyway, which is mostly a problem as well for client-side ad insertion.

But if you really look at it, server-side ad insertion, it should always improve your quality of experience. I don't know how you see that, Matthew, but for me at least, server-side ad insertion is usually the thing that you do to ensure that the quality becomes better compared to client-side ad insertion solutions.

Matthew: That's right. Done correctly, it gives you a lot more control. It gives you a lot more control over the quality of your assets, of the quality of the ads that you insert. If you're going to go with client-side ad insertion, it becomes very problematic because you simply don't control the ads that are going to be loaded by the player. And there are mechanisms to validate what encoding settings you might be using, but it's a lot more effort and you're delegating that control to someone else. And I think it can result in uncertain outcomes. And then in some cases, it's just a non-starter because you can't actually do client-side ad insertion on the platforms that you're trying to support. What we see, some of the broadcasters that we've worked with. They have to support legacy devices. There are many generations of smart TVs now, and there's many generations of TVs that can work with segmented ABR streaming formats, but they're not really designed to do anything fancy -  there's no reporting components, the players are limited in what they can and cannot do, and their platforms. And so SSAI provides really a very clean way to integrate against those systems, but you have to be careful about how you set up those streams and how you prepare your ads.

So, I think that dovetails really well into this next topic that we wanted to go on, which is what are the most common client problem root causes. So how are clients impacted by SSAI when stuff goes wrong? And the sentiment as well, smart TV clients don't like SSAI. That can happen when you have poorly prepared content or when the encoding parameters are quite different between your ad content and your primary content, whatever that is. And that's effectively putting you in the same position as client-side insertion, where you have two very different types of content. There was a quick question in the Q&A. Does MediaTailor require MediaLive, MediaPackage, and CloudFront to work? No, we integrate with anything that speaks HLS, DASH and VAST. So, you can send us VAST and DMAP from your ad server, and you have an HLS, DASH or CMAF stream, MediaTailor will interoperate with those systems. We can go into more questions about interoperability, but I'd like to hear from PJ about his thoughts on the most common client problems that we see.

Pieter-Jan: I think you actually mentioned one of the most important ones. I mean, there’s a lot of legacy devices, especially when you look at smart TVs. If you think about it, it's actually not very strange that these devices don't really support server-side ad insertion that well. The reason there is, think about the smart TV sitting in your living room. I don't know when you bought it, but let's say that you bought it like three years ago, but it wasn't the 2018 model because, the 2017 models were at that point in time a lot cheaper, they were still being sold. But that device that's three-year-old might in fact be four-year-old lineup, but that means five-year-old technology because the technology was developed the year before. And, let's be honest, server-side ad insertion, you know this as well as I do, Matt. - it hasn't been a requirement for a lot of big companies for a very long time. Five years ago, most companies were not doing server-side ad insertion. And these devices, this technology is not optimized for it.

Not optimized usually means that there will be a lot of issues. One of the big ones, I think, or one of the most important issues that I see at least with server-side ad insertion from a client perspective is misalignment with timestamps, segments that don't exactly match period boundaries when you're talking DASH, for example, differences in adaptation sets, all kinds of differences in encoding profiles, issues with time scales, with frame rates, with like B-frames being configured differently between content and ads. Usually, it's these pretty low level kind of things that can completely mess up a decoder on the client side. We've done a lot of optimizations, for example, in THEOplayer to really get these things right. It's a lot easier if you have a decent server-side ad insertion provider that can do all of these things for you. That, as you mentioned, Matthew, where you can really start leveling out all of these things, make it a lot easier to do the right preparation from the server side. It's not always possible. But to me at least, it really boils down to the right tools.

Pieter-Jan: One of those very big client issues that I see is DRM - DRM basically makes Servide-side ad insertion more complex, it's like changing your  encoding but this is really next level stuff. There are smart TVs that even have problems with changing a DRM decryption key. If you are going with DRM, your ads are going to be in clear, your content is going to be encrypted, because we are also talking about smart TVs here - usually  that means premium content, which means there is going to be a rights holder  that really wants you to put in some DRM, but this is not trivial in smart TVs in general, there are a lot of things that can go wrong with DRM just playing a plain stream without server-side ad insertion. But when you start doing DRM, server-side ad insertion, not just on smart TVs, but on any platform - you need the right tools. With the right player, you can make this completely smooth, with the right tool set, the right preparation. I've seen people really going crazy to try solve this problem. I've seen people going encrypting their ads. Horrible nightmare for them: they had to reuse the same encryption keys as for their main content. It was quite horrible! I don't know what your perspective is on this, Matthew, but for my perspective, make sure your ads can be clear. Your SSAI provider really shouldn't have to worry about this, you can't do this in a simple way.

Matthew: That's right. You need the right tools, you need the right client. And we've seen streams where broadcasters are trying to falsify the encryption for ads to show, to try to get around limitations in the player. There are legitimate difficulties with DRM that I don't think that there's a good industry solution for yet, around ad inserted content and how to mix clear ad inserted content with DRM protected content. Like for example, what happens when you have a growing manifest and you start just with clear content, like clear ads, there's some pre-roll or there's something that happens - the player has no way of knowing whether it's starting an encrypted session because there's no encryption keys in the content, they're in the content that's visible in the playlist at that point. And so, there are these questions that I'm not really sure that we have an industry answer for yet. And I know that there are certain players for which are able to handle when you see both kinds of content: you both see encrypted content and clear content in the same playlist. But I think there are certainly situations where you run into limitations of what information the player is getting at the time that it's starting the playback session.

Pieter-Jan: Yeah, it's about end-to-end integration at that point in time. For us, for example, we use what I call the naive approach - if you're configuring DRM, configuring license URIs, those kinds of things, we will assume that probably you will play DRM at one point in time. But it's indeed, there's no industry standard around this.

Matthew: But you hit the nail on the head. I think that you have to give clients and operators the option of telling you what the right thing to do is. Because in this world where you have mixed content, you can't necessarily trust the first manifest that you receive if it's going to change. And so, you need to give people an opportunity to declare that this is eventually going to be DRM protected content. I think that's absolutely the right approach. And it means - pick the right tools. Pick the right tools that actually can deal with these kinds of streams.

There was something else you mentioned actually earlier about the difficulties with actually stitching content. So, we talked a lot about preparing content, making sure that it's in the right state, and from my perspective, that typically means what happens before it's actually stitched together into a unified stream. But when we're talking about actually the composition of that stream that you're creating, whether it's your movie, your live event or whatever with that personalized content inserted into it, that insertion process is non-trivial. And especially for something like DASH, I think for HLS it's a little bit more simple, because there's a unified timeline - you have all of the wall clock time, and all of the segment time appears in line. And so, for a stitcher, it makes it actually fairly straightforward for our service to then be able to maintain the correct segment cadence without any strangeness in the timing that we're producing. For DASH, it gets quite complicated because you have this concept of a period that wraps a segment in line. And that period's timing per the DASH timing model doesn't have to line up perfectly with the segments underneath it. But depending on the client that you have, you may have more or less tolerance for overlaps and gaps around the edges of those periods.

And so, we try wherever and whenever we can, to make sure that when we produce a DASH manifest, that we align with those segment boundaries. And when you're creating DASH, when you're picking an origin -  a packager or an encoder that's preparing initial content, whether it's prepared in HLS and then repackaged to DASH or whether you're just preparing DASH content directly, picking an origin or a package or an encoder that actually gets the ad insertion points correct with the ad markers lined up with those segment boundaries is really important. Because otherwise we have to make compromises on where to start the ad break and where to put that content.

Picking those components, is super important. Because if we have to deal with content that, if we, as in the MediaTailor service, has to deal with content that is not well-prepared, then we have to make compromises. And whenever you have to make compromises with the position of ads in the stream, then that can get dangerous. You can get into situations where the quality of service suffers because the experience is wrong, because we had to shift the content in some way to make sure that it played back smoothly. And they're not questions you really want to have to answer. And so, I think, to PJ's point - pick the right components for the job and make sure that you do testing. So that comes down to like -  how do we approach this stuff? How do we approach these compatibility issues? How do we approach these difficult topics?

And I think testing is key, and not just testing of a single component, you must unit test your systems. That's important! But without any integration testing, without any end-to-end testing of the whole system, there will be issues that are discovered late. Scale testing is also important, ensuring that the components you select can actually perform when you have hundreds of thousands or millions of viewers? That's a huge risk that people face, that customers face when they want to put together a streaming platform. Will it actually support their audience? And you have to give yourself time to work through those problems and to come up with a test plan that actually validates the customer experience that you will be using. I'm super curious about PJ's experiences and especially on the client side, like what your approach is or what you advise broadcasters who use THEOplayer to do?

Pieter-Jan: I think you've mentioned the two most important things when you look at SSAI in general. On one side you have using the right tools, but it's as you mentioned, while you can have the best tools for the job, unifying them and bringing them all together, it's still non-trivial. Yes all of them will be tested, all of them will work in their own way, but there's a lot of preparation, there's a lot of other stuff that needs to happen, and that's indeed where that end-to-end testing  really comes in.

When I look at our experience from a player perspective, let's be honest, all industry vendors, all of their products work, otherwise they wouldn't be selling them. But even then, you bump into issues when you try to integrate them. And based on what I've seen, at least, that testing is really, really crucial. There are so many different platforms, especially on Smart TV World: you have the Tizens, which everybody knows, you have LG's WebOS, which is now being licensed to other vendors as well. So, there's a lot of different WebOS devices that you can bump into, you have Roku TVs, you have Fire TVs, you have the VIDAA U from Hisense and many others. There are so many different platforms, different types of platforms, and just trying to cover all of it and assuming that it will all work, with all of those different components and all of that complexity, that's a bit too naive.

We've made a lot of progress on smart TVs and on server-side ad insertion over the past year. The way how we did it was really through testing, making sure that we can run automated tests of integrated end-to-end pipelines with the click of a button, basically. We have a very big repository of all kinds of tests, and we can basically run them. We can configure them for a specific end-to-end setup. We configure them, and we can run it with one click of a button across all of the different devices. We can check, do they all behave consistently? Are there specific decoder glitches? Different ways how some platforms react to a difference in frame rate, to the different DRM setups, all of those things. Your entire end to end, in the end, needs to be tuned. It's going from all the way, as you mentioned, encoding, content preparation, packaging, stitching, all the way to playback and even the reporting step, having that step back, that loop back from the client, back to your ad servers, making sure that everything, is monetized correctly. Because even if your ad plays 100% seamlessly, when that impression is not getting counted, you're not getting paid, so that's probably one of the crucial things. The quality of experience (QoE) is extremely important, but also the reporting, it's really the end-to-end chain. And you can be working with AWS and with THEO and with the best vendors out there, but if it's not an end-to-end test chain, something that either the companies themselves have tested and validated and integrated, you'll always need to do some kind of validation because even your content can have a big impact - it's as you mentioned, Matthew, if you're preparing your content the wrong way and the ad decision server and the stitcher and they all come together and they need to make a decision where is this ad going to be spliced in and it has to be at the middle of a segment, I can almost guarantee you that there will be problems on some platforms. You can do a lot, but it's still a very complex ecosystem that we're operating in here. And I don't think that anybody wants to accept a mediocre experience. We all want the best for our viewers, for our customers' viewers, obviously. And that requires, well, rolling up your sleeves, let's say, and getting wet when it starts raining.

And for me, at least, if there's one thing that I would really want people to remember from this webinar, it's actually that - don't just use the right tool set, well definitely use the right tool set. But make sure that everything is done well. This is really about execution. The tools are there but you need to prepare everything well from content to the server side, optimize as much as you can, make sure that tools that you're using are optimized as much as you can. Because server-side ad insertion, it's one of those end-to-end things, you can't just throw a bunch of components together and hope that all of it works. It works in a lot of cases, especially if you look at web browsers, they're a lot more tolerant than some other devices. But if you go big screens, just throwing it together, it's way too big of a gamble for me. Every setup has its unique features, they all have quirks, way too many parameters to have everything tested by all the vendors end-to-end in every possible case. So, if there is the one nugget of wisdom, basically, really look at server-side ad insertion as an end-to-end exercise. Pick your right tools, but really test early and very extensively. I don't know if you agree or disagree, but for me at least, this is what really is for me the biggest thing to keep in mind when looking at server-side-out insertion.

Matthew: That's exactly correct! It is a holistic approach: you need to take a wide view of where your focus needs to be when constructing these systems. It's important to think systematically about the end-to-end workflow, eEverything from the signal acquisition and the signalling requirements, like what instructions are you giving the service, to how does this content play with your clients, and for a representative stream or a representative asset that you want to monetize, what does that actually do on the various platforms that you expect to support?

It's so critical to give yourselve time. It's important that these things are fully fleshed out and fully planned. It can end up in a very difficult situation if there's not sufficient planning for some of these workflows. And I think that includes everything from how the content was originally prepared and signalled or broadcast, all the way to what end user devices are doing, and what your device footprint looks like, and how that's tested. I think that's the best way to do it. That is the most important thing that I think folks need to think about when putting together these kinds of workflows.

Pieter-Jan: Yeah, great! I'm very happy that we agree! I'm also seeing that we have about 20 minutes left. So, if that's okay for you, Matthew, I would say let's dive into some live Q&A. That's always something which is very interesting, or at least I find it very interesting. So, let's see what kind of questions have already come up.

So, the first one, you've already tackled a little bit of it about the compatibility with MediaTailor.

Matthew: Yep, we just, we interoperate with anything that speaks HLS, DASH, CMAP, VAST and VMAP. So, we don't require a particular packager or encoder or CDN.

Pieter-Jan: I think I've actually played with it once, and I must admit I used some different components in the front and in the back. So, I'm sure that this works. You guys did it well.

Okay, let's look at the next question:“Which DRM solutions that you are aware of that proved more compatible with your SSAI solution?”

Well, I think we have two sides here. We probably have the MediaTailor side, of course we have the client side as well. I don't know if you want to take first cuts or if you would want me to do.

Matthew: Sure, let's talk about the client side first and then we can talk about server side.

Pieter-Jan: Yeah, for us from a client side perspective, as long as we support the DRM that's being used should be fine. So, in most cases, that's going to be either Widevine or PlayReady. Fair play if you're doing Apple TV, but let's assume that we were on the other Smart TVs. Usually, actually, we see something very interesting here. It really boils down to the Smart TV model - you have some models who are more optimized, for example, for PlayReady, and you have others who are way more optimized for Widevine. More recent devices, usually Widevine is better. But especially with the older ones, PlayReady often gets you higher frame rates, higher bitrates, so better playback as a whole.

The same can be said if you're looking at server-side ad insertion solutions. For us, it usually just means turning on or off the protected pipeline. But which pipeline we need to switch to - usually some of those pipelines are more performant than others. It doesn't matter which vendor you're using or if you're using multiple keys or those kinds of things. Yes, all of that matters, but purely for the functioning of the server-side ad insertion for us, at least from a client perspective, it doesn't matter. We've even seen customers, and I kid you not, they have WideVine on their content, and they have, for some reason, clear key protected their advertisements. Even that kind of setups work. I would definitely not recommend it, but those things are potentially possible as well, if you would be up for some very hardcore protection of your advertisements.

Matthew: Yeah, that makes complete sense to me. I think on the server side, we're very unopinionated about this, because for us it's just a pass through. We don't actually touch any content segments directly when MediaTailor processes manifests. And so, for us, it's strictly a pass-through operation. However, your content is prepared, we pass it through unaltered, to the end device. And so, it's much, much more important to talk about what PJ was describing, which is - What are your devices capable of? What is your client  going to be compatible with? From a manifest manipulation or a stitcher perspective, we don't have an opinion on it. It is a property of the manifest that we pass through and whatever is most optimal for your client devices is the right solution.

Pieter-Jan: Yeah, that's always good to hear. So, let's see, we have some more questions, and if you have other questions, please keep putting them into the chat, and we can pick them up as well.

So - “What's the requirement for a 24-7 livestream to implement SSAI? What do I need? Already have the HLS streaming server and ad decision server?''

This is a broad question. So, what do you need? Well, you will need quite a lot, I think. You can use some amazing tools like MediaTailor, you will definitely need a player as well. What I think is the most important thing, or one of the most important things, is the impression tracking as well. It's something that we didn't really talk about yet, but you have ad monitoring from both server side and client side. But I would actually start with making that architecture picture similar to what you built, Matthew, to really see what different components are, where you have already components in place, how they would work together, and where you are lacking things. And for me, that doesn't even differ, if it's a 24 seven service or not. I know that it differs a lot on the server side because there are some caveats there, I can imagine.

Matthew: Yeah, so when we talk about components or what requirements for a 24/7 live streaming service to implement SSAI, when I hear that, I think signalling requirements. So, how do you get SSAI to actually work on a live stream? So, on a live stream, we need to know when there are ad breaks. So, if you already have an HLS server, if you already have an ad decision server, you've got the components that you need in order to broadcast a live stream. I presume that the other things that PJ was talking about are in place, like the player, you have some sort of end-to-end test methodology. When you're integrating an SSAI Stitcher, the Stitcher needs directions. So, we don't just decide to insert content randomly over the live stream unless you're doing a live pre-roll where we are supposed to just insert an ad as soon as the customer joins the stream. But I presume that most of what this focus is on is on live content that's streaming and there are designated positions within that content for those breaks. So, you need an encoder that's capable of inserting ad markers where breaks are supposed to be, and that have some sort of non-zero time that corresponds or keeps track of the live stream. So, it's not sufficient simply to put a zero-duration marker or splice immediate marker into the stream, because what will happen is if MediaTailor gets an unbounded or like unplanned marker, you can end up over planning and the ad server won't necessarily know how many ads to insert. And that can be bad for forecasting, and you might have problems cutting back to the live stream because in the worst case, we might have to truncate an ad to come back or cut back when it ends. Typically, those early cutback situations only happen in live sports, when a planned break that was supposed to be like two minutes long only ends up being like a minute and 14 seconds or something like that, because they've got to cut back to the live feed.

So proper signaling is probably the most important thing there. You need to be able for your live stream, to indicate to the stitcher, where does the ad break start, where does it end and how long is it, so that the ad server can figure out how to fill that break.

Pieter-Jan: Yeah, you don't want to replace the actual content with ads, of course.

Matthew: So, this next question is “How do you manage introduced delay by inserting ads? For sports, this can be a problem.”

That's absolutely right. So, we manage it in a number of ways. Customers who use MediaTailor and also other add insertion components along the way, it matters how long that decisioning takes - so, if a customer is doing real-time decisioning of ad breaks, there's a couple different ways that can be controlled. The first way is just by relying on sane timeout values. So, at what point do you abandon personalization if it's taking too long? Because if you're doing real-time bidding or if you're doing any sort of programmatic ad insertion for sports, that can take seconds, depending on all of the different wrappers and redirects that you might have to follow to resolve that break. And so, by putting sane boundaries around how long that personalization can take, that can help reduce or eliminate any sort of delay in producing that personalized manifest for the live stream.

Broadcasters actually have at least the length of a segment to make a decision. If you have two-second or four-second or six-second segments for a livestream, it's fairly uncommon to have very long segments for live sports because you want to try to minimize the end-to-end latency that you have to realize. But the important thing to know is that you actually have basically as long as a segment's length to make a decision that won't compromise the player's buffer. As long as you get a response to the client in time for it to buffer another fragment. In theory, that should not impact the end-to-end latency, because you're just producing a manifest. And then once that manifest is produced, it can fill the rest of that time with, however many ads need to be inserted. And the client can continue playing without upsetting the buffer.

I'm actually really curious to hear from PJ on this one about what limitations or what some sane guardrails are for clients in general, in terms of response times.

Pieter-Jan: Well, there's two aspects of this, right? I mean, usually if you look at the traditional three segment buffer, as long as you can get the next segment within that three segment buffer and then hopefully build up again a buffer, you should be okay. If we keep in mind that most of these ads you'll know the entire ad at the same point in time. They're not live, so once you know which ad you will play, if you can download that first segment in time, then probably you can download the remainder of the ad in time as well. So yes, your buffer might temporarily get a hit, but it should be able to build up and potentially even build up a lot more than you would have in the normal live stream after that, which will then again, deplete, and while you're at the end of the ad, you can again, switch to the live part.

I think actually, one of the things that you mentioned is very important here, the segment size. There's a lot of talk, of course, in the industry about going low latency, low latency HLS, low latency DASH. Yes, those things can all be used to make sure that you can also reduce your end-to-end latency. Something that a lot of people forget when they talk low latency is actually server-side ad insertion. I know that at AWS, you guys are working on some very interesting stuff there as well. But a lot of server-side ad insertion solutions are not really ready for very short segments or for low latency HLS with parts or for progressive download, like with low latency DASH. There are a lot of things that the industry is still figuring out right now. From a player perspective and from especially an end to end perspective, I don't think we've seen the last of this yet. Every deployment, especially when low latency is at play, there are still some quirks that need to be addressed, but I don't think that server-side add insertion has to necessarily increase your latency or that this delay that's being introduced, that you cannot manage it. Definitely an interesting topic to talk about later, to dig in deeper at one point in time.

Matthew: Yeah, it deserves its own whole discussion. It's a good one.

Pieter-Jan: Yes, definitely! But it shouldn't be a problem, to be honest. If you work with the right components, if you have it properly integrated, you can definitely mitigate this.

Okay, let's see. We have - “How is ad impression implemented on the client side using the SSAI solution?”

I've seen two approaches. I don't know which approaches you have seen, Matthew, but for example, on the player side, we have a lot of integrations with what is usually called the client-side metrics or the client-side impression reporting libraries of server-side ad insertion providers. Usually there are, in some kind of metadata, it can be ID3, it can be eMessage, it can be in the manifest. Sometimes even entire VAST files are being provided towards the player with all of the tracking URIs in there. There's no standard on this, but if you use the right player, you can usually get this information out or this player, like we usually do, can already be pre-integrated. So, it can basically automatically detect this metadata from the streaming servers that you're using and the SSAI servers that you're using and automatically send back the beacon to either a proxy server of the SSAI provider or directly to the ad server itself.

I know that MediaTailor has this because we've been integrating that. I know that there's also a lot of SSAI services who actually do tracking from the server side. So that's something that I think MediaTailor also does, right?

Matthew: Yep, we'll do both. And they're both very common. So, it depends on the platform - if the platform is capable, or if you have an ability to integrate the client with our tracking information API, we store that for each playback session. And as a client is streaming an ad break, we make available all of the timing metadata tracking events and whatever through that endpoint so the client can make a call to that endpoint, get the metadata it needs to perform those tracking events.

You can even do interactivity. You can do VPAID advertisements with a MediaTailor stream for HLS. It's a great way to do that, it's possible to just, we will just hold time with a slate and provide the VAST JavaScript files so that the client can load those. The industry is moving away from VPAID, but you can absolutely do client-side tracking and client-side interactivity, click-throughs, all of that can be integrated with an SSAI solution.

Pieter-Jan: Yeah, genuine question from my side - has MediaTailor already implemented CIMIT, so the VAST replacement? I know it's not very popular yet within the industry, but I see the first people starting to use it, so it will become a question at this point in time, I think.

Matthew: Yeah, we've started talking to a few folks about this. Actually, it's not available today, but it is something that we're very interested in.

Pieter-Jan: Yeah, would be very cool, it will improve probably the security around the advertisements and address some of the biggest concerns that are there. That's definitely something that I would find very interesting.

I see that the marketing team is warning us that we're running up on the hour. So yeah, let's try to go through the last question. We also have a very quick question for everybody on the call to try and see if we can improve for webinars after this. But let's first answer the question and see. And I think this is going to be one for you, Matt:

“Does AWS have a stitching service for HLS and how do I implement SCETE markers into a live stream?”

Matthew: Yes - MediaTailor. So, you can use MediaTailor for HLS streams. And the second part of that question is a little bit more tricky. There are a few different ways - so, you could use an encoder like MediaLive, which has an API that lets you, with the click of a button, insert a SCETE 35 marker. You may or may not be able to do that in a way that's frame accurate. We allow you, or MediaLive allows operators to specify timings. But if you don't know those timings, that's going to be tricky. I would say that's definitely useful for testing. We do have customers who are integrated, we've worked with broadcasters who've integrated against the MediaLive APIs for inserting markers. But very commonly, there'll be some SCETE insertion hardware that sits upstream of the encoder that inserts like SCETE 104 or SCETE 35 ahead of the encoder that is then translated into SCETE 35 markers in the HLS output from the encoder. If there's SCETE 35 signalling in the stream that needs to be represented in a slightly different way, you can use products like Media Package that provide repackaging and some amount of filtering or manipulation of SCETE markers into the streams. But that's at a super high level a couple different options of how you get SCETE 35 markers into a live stream. They need to be in the manifest, and so you'll need an encoder or a packager that can ensure that those markers are in the manifest.

Pieter-Jan: And I know that that's a problem that a lot of people have struggled with. And I see we have one last question that popped up: “So that the best way is to use a play out software to ingest the ads into the livestream?”

I think there are some mixed possibilities here. I think it's definitely an option. But is it the best option? Personally, I know that. It's a tricky situation, to be honest.

Matthew: Yeah, I would go with an SSAI solution, a Playout server won't get you personalized ads. So, you can do it. It wouldn't result in any sort of targeting. Unless you were to run, I suppose, like many different live streams that were all played out differently. I feel like that would get really expensive.

Pieter-Jan: I think so as well, especially if you have a lot of different ad inventory that you want to make a bit diverse and especially if it's a 24/7 stream because how many cohorts would you need? So, it's going to be a very interesting solution.

Matthew:  You could do it! And I think I've talked to broadcasters who've done that, who've orchestrated different cohorts, like different live streams for every cohort, and it's pricey.

Pieter-Jan: Yeah, I can imagine.

Pieter-Jan: I see that we're slightly gone past the hour. So, I would propose that we start wrapping up. We do still have our short survey. We really like it that so many of you show up, and we want to make our content better for you. So please give us some feedback. And well, I hope you all enjoyed this webinar. Matthew, it was a pleasure to have this conversation with you. I hope that our audience also found it a very pleasant conversation. And if you can't get enough, who knows? Maybe we will actually see each other at IBC. I don't assume that you will be there, Matthew. I don't assume at this point in time that there will be an IBC..

Matthew: I'll be there in spirit, yes. Thank you so much! This has been an absolute pleasure. It's really fun to talk about this stuff.

Pieter-Jan: Likewise! So, I would say thank you to everybody, including all of our viewers. And well, I hope we all learned something. So, I would say take care, and we'll see you next time.