Posted by Matt Hammond on , last updated
We have been prototyping ways to customise and personalise broadcast TV using IP-delivered content and some of the new connected TV technology standards. Come see us at IBC 2017 where we will be showing a demonstration of this running on a real implementation from
Opera TV VEWD.
In the Companion Screens project we are continuing in our efforts to collaborate with industry to show what this technology can enable and to encourage adoption of industry standards.
At TV Connect in March, we demonstrated how companion devices (such as phones and tablets) can synchronise to your TV viewing and offer a range of enhanced experiences and useful features. This is enabled by the synchronisation features of the HbbTV 2 standard which is being adopted in the UK through Freeview Play and the DTG’s D-Book 9.
Since then we have also been experimenting with experiences that are purely on the TV, such as using HbbTV 2 to perform dynamic content insertion using IP into the broadcast viewing experience. This has been added to our demonstrator, using adaptive bitrate DVB DASH streams. This opens up the possibility of enhancing a broadcast channel with customised or personalised content:
- The trailers between programmes could be replaced with trailers that better match your interests. A link to your companion device could convey your preferences.
- Different programmes, or programme segments could be shown instead of the main broadcast at fixed slots in the broadcast schedule. For example, a news programme could be personalised by allowing you to select news for particular interests or local areas.
How have we made this work? Our prototype uses an HbbTV application that runs on the TV while you are watching a broadcast channel. The same HbbTV 2 “media synchronisation” features that supports companion screen synchronisation also allows the HbbTV application to monitor the current time position. It can therefore know when it is the right time to switch to the DASH stream. To make the switch as seamless as possible, it starts buffering the stream several seconds in advance. The insertion is scheduled to last a fixed amount of time, and so the HbbTV application switches back to broadcast when this time has expired.
Of course the TV must also behave as the user expects it to if they change channel. If the user changes to a channel where the insertion should have already begun, then the application attempts to join the DASH stream partway through. If the user changes channel during a period of IP insertion, then the DASH stream is cancelled and the TV returns to broadcast viewing.
Something worth noting is that we are now using MPEG TEMI (Timed External Media Information). This is a standardised way to carry a timeline inside a broadcast transport stream. Unlike the broadcast data carrying the electronic programme guide and date and time, this associated with the video and audio of a channel with frame-accuracy. TEMI is added when the video is encoded for broadcast and, importantly, is carried with it during later stages of processing in the broadcast chain. We have previously released test materials to help manufacturers test out TEMI.
Having proven this can work in a self-contained demonstration we are also looking at what is needed to deploy it for real. There are several challenges that need to be addressed:
- The broadcast systems need to generate TEMI and this must be related to the schedule of exactly when programmes and trailers are played.
- Data must be made available to the HbbTV application telling it when to make the switch, how long for and what stream to switch to.
- The DASH stream needs to be available sufficiently far in advance to be buffered and ready to play. This could be particularly challenging for content where liveness is important (such as live sports coverage) because the latencies of IP delivery are often much greater than for broadcast.
This post is part of the Broadcast and Connected Systems section