Last year at IBC, we showed some early work on personalising broadcasts using existing tools in the HbbTV standard. This year we are improving the seamlessness of the experience. We have shared example materials with the industry and are seeing their progress towards implementing these capabilities on our platforms in the UK.
The idea of personalising a broadcast service (by having some of the content replaced with IP-delivered content) has obvious applications for targeted advertising. It is currently of great interest to commercial broadcasters and has driven work in industry groups such as and where it is known as dynamic ad substitution (DAS).
However, the main interests for the Βι¶ΉΤΌΕΔ are the non-commercial use cases, which we call dynamic content substitution. This is all about the ability to personalise our broadcast services so that what you see better matches your tastes or is relevant to your local area. There is an obvious overlap with the underlying technology that enables DAS, so we are working to ensure that these use cases are not forgotten.
in the UK is pioneering the deployment of HbbTV 2 capable TVs. It currently plans to adopt the functionality needed to enable content substitution in TVs to support both commercial (DAS) and non-commercial uses. We have worked to support them in doing this. For example, in June and HbbTV application that will assist TV manufacturers and others in their development and testing work.
This year we are already seeing support on a wider range of devices and middleware. At IBC 2018 we are showing our content substitution demonstrators running on a range of these - come and see us in the Future Zone. You can also see our demonstrator on the stand and our example stream on the stand, running on their HbbTV solutions. Encouraging adoption and implementation by the industry in an important step towards being able to use these technologies to benefit our audiences.
Our approach uses the Media Synchronisation features of HbbTV 2. An MPEG TEMI timeline is read from the broadcast and used to time when the switch from broadcast to an IP delivered DASH stream takes place. The DASH stream is pre-buffered in the seconds leading up to the switch so it is ready to begin playing.
The switch from broadcast to the DASH stream takes, typically, no more than 250ms. However, the transition back to broadcast typically takes several seconds. This is because a TV must wait until it has received a block of data corresponding to a complete codec group of pictures (GOP) before it can start decoding and displaying frames of video.
Our audience is accustomed to the highly polished presentation of our broadcast services, particularly our flagship channels, where every programme, trailer, sting or ident flows seamlessly from one to the next. Several seconds of a black screen are therefore not acceptable. It also creates the practical challenge that the trailer must be designed to be a few seconds shorter than the gap it is intended to fill. In our previous work, the HbbTV application addressed this by displaying a full screen simple graphic during the transition back to broadcast:
This transition can also be shortened by decreasing the duration of a GOP on the broadcast service but this does not entirely solve the problem. It also comes at a cost of either picture quality or bitrate consumed.
Another approach is to include extra decoding hardware in a TV. This would enable a truly seamless transition, but it comes with additional complexity and cost for TV manufacturers.
We have therefore been experimenting with other ways to tackle this challenge. We realised that the final few seconds of many of our trailers consists of a nearly static image:
What if the HbbTV application can render that image instead of it being part of the DASH video? This would free up the limited video decoding resources in the TV so that it can begin the process of decoding the broadcast video a few seconds earlier. The TV will therefore be ready to immediately begin presenting broadcast audio and video as soon as the trailer ends.
But what about the audio for the trailer? We remove this from the DASH video and instead play it as a separate audio file using the WebAudio API. HbbTV 2 supports doing this without interfering with the presentation of the main broadcast or IP-delivered audio and video. The trailer audio keeps playing after the trailer video ends and while the static slide is being shown.
This is very much an experiment for us and it pushes the boundaries of what is possible with HbbTV 2. HbbTV applications cannot schedule the WebAudio API to play audio with sample level timing precision relative to audio coming from DASH or broadcast. A perfect transition from one to the other is therefore impractical. This is why the entire audio of the trailer is played via the WebAudio API. The memory available in a TV therefore limits this approach to short content such as trailers only. However the end of a longer piece of content such as a whole programme is a more natural moment of pause, where a few seconds of silence is more acceptable.
-
Broadcast and Connected Systems section
Broadcast & Connected Systems primarily focuses on how Βι¶ΉΤΌΕΔ content reaches our viewers through broadcast and Internet delivery. This involves the whole broadcast chain from playout, through coding and distribution to consumption on the end-user's device. Our work typically covers a period from now through to 3 years out from deployment.