At the end of November last year the BBC launched the Connected Red Button service on Virgin TiVo, along with updated versions of the iPlayer, News and Sport apps. This package also consisted of a fifth release: an application that is both integral and vital to each of the above apps, yet few are even aware of its existence!
Xenon is a brand new embedded media player that was developed specifically for AS2 embedded devices such as Virgin’s TiVo, to be used by applications like iPlayer, News, Sport and any other such applications that the BBC develops in future.
The development of a new player was actually driven by Connected Red Button. The CRB project was subject to some aggressive performance requirements that were going to be difficult to achieve even with an ideal setup on the modest TiVo hardware, but impossible with the existing media player which had been built years before to a different set of requirements. If we were going to stand a chance of meeting CRB’s performance requirements then we’d need to build a new player specifically for this purpose.
A new beginning
Xenon is based on an MVCS pattern with separate services performing the important tasks of reading playlists, parsing Media Selector responses, loading subtitles and streaming the media itself, while dedicated views handle the presentation to the user. It can be used both by standalone applications and those that are based on our AS2 Krypton Framework: the benefit of the latter being that the host application can then take advantage of the framework’s underlying BDD functionality for automated tests.
Inbound communications are provided by an API that the host application (i.e. iPlayer) can use to control everything from the desired media bitrate to subtitle preferences in real-time, while an events system to which the host can subscribe is used for all outbound communications. This events system provides the host application with around 70 different events, though only 20 of them are required for “normal” use: the others are either used for debugging, were included in order to support possible future requirements or are there simply to provide the host with more specific information on given scenarios.
The project is covered by around 200 unit tests which not only provide confidence in the existing code but will also provide future engineers with a means to test any additions or refactors.
So what’s new?
Viewers should notice a significant improvement in performance, some of which are covered by the following statistics:
- Media load times have been halved
- Video scrub times are now 3-4 times faster
- Toggling between SD and HD is now 3-4 times faster
- Subtitles load times are improved tenfold down from 30-40 seconds to just 3-4 seconds.
In order to achieve this kind of performance we had to employ a number of tricks!
One of the things we looked at was the process by which the old player would select and then connect to a server. We were interested in improving this because we’d noticed that there was a noticeable delay between getting the list of stream locations from Media Selector and the start of playback.
It turns out that the old player would make multiple connection requests to its chosen location using different ports – 1935, 80 and 443 – which of course are the standard FMS ports. When one connection responded favourably the other two were closed and the stream was requested from the open one.
Trying to avoid the delays associated with working through a list of ports in series by trying them all in parallel would be worthwhile if each port had a shared chance of success, and on a platform like the PC which operates on different types of networks with different routers and firewalls that’s most probably the case.
On TiVo however, unless there’s a serious problem with the chosen content delivery network (CDN) the 1935 connection will work 100% of the time and if it doesn’t work then we’re better off trying a different CDN than the same one again on a different port.
So that’s what Xenon does: if the single connection request on port 1935 to its first CDN fails to connect then it moves on to the next CDN and sends another single connection request to that on the same port. Since each CDN has a lots fail-over and redundancy, if the user is unable to connect to a single CDN then either their internet connection is down or they have bigger problems!
This approach means the box only has to allocate enough resources to create and connect a single NetConnection which means more resources are available elsewhere to help deliver a more responsive user experience.
Another thing we looked at was subtitles. The old player took 40-60 seconds to resume playback after subtitles were enabled and we really wanted to bring this figure down.
When we looked at how subtitles were being handled in the old player we discovered that typed objects with verified data were being created as soon as the file was downloaded and parsed. A 60-minute program with lots of talking might contain hundreds of lines of subtitles which would require a fair amount of work to get through. Again such an approach makes sense on a PC but not so much on a set top box.
The way we got round this in Xenon was to download and parse the XML file as before, but to create only basic reference objects at first without typing or validation and to defer such calculations until the reference object was relevant to the stream based on the current playback position. At this point the object’s data is verified and converted into a more usable format before the subtitle is displayed on-screen.
This approach means a little more work is done by the player for each individual subtitle as playback progresses, but it also means we can spread the necessary calculations over the duration of the program rather than doing them all up-front which allows us to resume playback in just 3-4 seconds.
What it means for us
Some specifications and supported features are as follows:
- The project weighs in at around 6,000 lines
- Both audio and video streams are supported, both live and on-demand
- Akamai, Limelight and Level3 content delivery networks (CDNs) are supported
- Dynamic CDN switching and ABR1 bitrate downswitching are both supported
- Dynamic weighting and prioritisation is supported, with appropriate data supplied by Media Selector 5
The new player also provides a number of benefits for our development teams:
- An API that allows direct control of every aspect of the player at runtime
- A comprehensive and consistent events system which makes debugging quick and easy
- A complimentary example application that both provides new teams with an implementation template and a convenient way for us to diagnose issues with the live service
- The codebase is extensively covered by tests which provides confidence in the robustness of the code.
Although invisible to the average user, Xenon has received favourable feedback from the public with comments such as:
I have found since BBC released the Connected Red Button on TiVo, BBC iPlayer has worked perfectly. I have watched loads on there over Christmas mainly in HD and I’ve no stuttering of the picture or any exiting from the program. Also it pauses and restarts without exiting back to menu. And if you press the forward arrow slowly between each press you can jump in 1 minute segments when fast forwarding so it is pretty easy to get to a certain part of the program. Now that the resume works with SD and HD programmes you can also leave and come back to where you left off earlier. I used to have all the problems like what most others have reported but now I can use BBC iPlayer at any time (including peak time) with no problems.
– spj20016, Digital Spy Forum
I managed to watch the whole of Supersized Earth in HD last night on Tivo iPlayer without a single blip, stutter or buffering. Something has improved.
– m0j00, Virgin Media Support Forum
Even the pause button works without it throwing you back to the beginning.
– Markynotts, Digital Spy Forum