ITV’s Journey with Server Side Ad Insertion


ITV is one of the biggest commercial broadcasters in the United Kingdom, and advertising is the core of our overall business. We offer a range of services starting from multiple DTT broadcast channels across different regions, over-the-top catch-up products like ITV Hub and bespoke SVOD service like BritBox.


As a broadcaster, our strength comes from being in a unique position to commission and produce our content and have an in-depth understanding of our viewers’ viewing habits. Over the years, we have invested a lot in enhancing technological capabilities for harvesting our viewer data, which gives us a competing edge and scientific tools necessary to do effective and efficient addressable advertising.


Our journey with server-side ad insertion started about four years ago when we started looking into potential technologies to replace the RTMP and FLASH based simulcast streaming on ITV Hub platform. Most of our vendors providing technology and support for RTMP had already started communicating end of life product dates. At the same time, we were cautiously observing the industry adoption of the more HTTP based packaging protocols like DASH & HLS. In the early stages, we realised that to take full advantage of the bespoke standards and get maximum horizontal coverage across the platforms; We will need to go through a very focused strategic selection of vendors for this project. We wanted to work with the companies which were as keen and participating as ITV in standard bodies and had a robust, proven engineering culture to create new technology from concepts and white-papers.


The First Big Step: The most challenging part for a complex integration project is always identifying where to start with, and correct kick-off could make the whole experience much more straightforward. In our case, we decided to focus first on the leg work in our broadcast chain & automation schedule and sketched a plan to light our most-watched channels first with SCTE104 markers. We also established the contracts to expose the scheduling & breaks data via APIs that could be consumed by the technical systems in our commercial domain. Commercial needed this data to do a proper forecast, plan appropriate campaigns and to be in the position to cash opportunities for Ad replacement in future. It took us a good six months to spec this out and a lot of back and forth with our playout partner to be in the position where the format of the SCTE104 could be deemed useful. What helped us the most during this phase was to stay focused on the task in hand ( which we had quantified by having only a few channels to start with) and have continuous discussions and a feedback loop with our transcoding vendors to validate the format of the SCTE104 messages to be conditioned to SCTE35. Like every other commercial broadcaster, we also had our semantics and instructions around content boundaries and segments that needed to have adhered. Continuous validation testing helped us a lot to keep it inline.


After this, the projects next phase was to start having a macro look into our transcoding set up and start the right conversations with our preferred packaging provider. It made our task more manageable to have dedicated labs set up between our transcoding and packaging provider. We did this to build and test tricky integrations as early as possible and uncover any unknowns in the project’s early phases only. We organised many syncs up meetings and established processes to continually validate our joined understanding of standards and specifications during this time. It’s worth noting that specifications and standard bodies sometimes leave some room for interpretation. The project Integration teams’ critical role is to ensure that everyone is working towards the same vision. It took us a few good few months before we can be confident about the streams’ output format and our transcoding and packaging vendors played a key role for us to reach there. Once we got sure that SCTE35s are present as CUE IN/OUT points in HLS and DASH EVENTS in DASH output MPDs, We were ready to move on to the next phase.


Now the focus for the next phase was more on delivery and architecture aspects of the end to end chain, and we went back on the whiteboards. We started talking about the more firm requirements, projects plans and considerations towards the functional, non-functional requirements and thinking about the overall architecture’s resilience. After some essential conversation with business and our vendors, we reached an agreement that we wanted to build the entire pipeline in the cloud with an OPEX option for the costs. It’s worth mentioning that we have few of our high profile shows like Love Island, which drives a considerable amount of viewing traffic onto the technical front end and back end service. It helped the entire project quantify and model the correct load profiles early enough and share them as part of the NFRs to all the vendors and the tech providers. We wanted to be sure that our content origins, DRM servers and Ad Servers could quickly scale to meet some of these too complicated use-cases.


But one can never fully prepare. Even after all the prep work and due diligence, we soon realised that some of our vendors worked with multiple clients/broadcasters influencing their individual release cycles. We couldn’t control everyone’s roadmap, So we decided to ring-fence the project development around some of the marked GA releases. This approach saved us a lot from doing rounds of regression testing. Once we had a release x.x for the packager and satisfied our business needs, it was expected to remain the same until we got the production. We uncovered some of the more delicate issues during this phase, tracked and flagged back to the respective vendors.


By now, we were almost two years in the project. Finally, our architecture and infrastructure were ready to roll-out the streams with proper DRM and Ad insertion. We have built the services to give us a lot of flexibility to turn Ad replacement on and off or switch between environments which gave us great operational control and options to do regular upgrade and maintenance without causing any downtime to the viewers. It was the time we started to think about the launch strategy, and any client-side work needed. We arranged many workshops between our player teams and our ad tech providers to have correct client-side SDKs integrated, followed by a lot of testing to ensure that impressions and overlays are working correctly.


All we needed now was to decide the target platform and a date to aim for the big-bang to happen. Our management and commercial teams came with an idea to focus on the big high profile event of the year “Football World Cup 2018”. All welcomed it, and as a platform, we decided on iOS & browsers to start with as they were most stable and quality of service was generally high on these. We chose ITV1 & ITV4 to be the first to be migrated to the new architecture to show most games. It was a big success for all of us, and we became one of the few first broadcasters who got the SSAI working with DASH. The whole process was templated and soon replicated on ITV2 and just in time for our biggest show LOVE Island.


At the time of writing this article, we are running a program dedicated to the future of broadcast and specifically focused upon IPTV & IP Streaming. We are also running active projects to launch SAAI on our Connected TV platforms and debating the merits of client-side and server sidetracking for Ads. Having run SSAI for a few years now and served millions of impressions, Our tech teams have gained a lot of learning and confidence in this area. I am personally very optimistic about the future and our roles in shaping the same. Our vision is to be in a position where any content offering on our OTT platforms could be addressable. The TV market is still uncharted territory, but they are getting more and more MSE/EME compliant and providing support for HTML5 browsers. All the ingredients needed for successful SSAI are already there. If I have to look back on the last few years and advise others from our journey, I would suggest focusing on the small wins first, getting right experts on your side to integrate early and test as much as possible, and work with the 3rd parties and vendors who understand what they are doing.
More philosophically, our journey has just started, and we are very confident about rolling out our tech to all the remaining platforms. None of this would have been possible without our marvellous vendors and suppliers tech teams who all played a crucial role in this project’s success; We worked with Redbee, AWS Elemental, Unified Streaming, Irdeto, Yo-Space, Akamai and BridgeTech.


By Vinay Gupta – Senior Architect – ITV Video Platform

Elevate Broadcast wi
EditShare upgrades t