Iβm Gareth Jones, a software engineer at ΒιΆΉΤΌΕΔ TV and Mobile Platforms.
At the end of November last year the ΒιΆΉΤΌΕΔ 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 player in action
Xenon is a brand new embedded media player that was developed specifically for embedded devices such as , to be used by applications like iPlayer, News, Sport and any other such applications that the ΒιΆΉΤΌΕΔ develops in future.
The development of a new player was actually driven by . 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.
as it was known had been built years before to a different set of requirements and for a different platform, and really wasnβt optimised for this environment. If we were going to stand a chance of meeting CRBβs performance requirements then weβd need to build a new player from scratch.
A new beginning
Xenon is based on an with separate services performing the important tasks of reading playlists, parsing server 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 an AS2 framework of ours: the benefit of the latter being that the host application can then take advantage of the frameworkβs underlying automated behavioural testing functionality.
Inbound communications are provided by an 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 the server and the start of playback.
It turns out that EMP would make multiple connection requests to its chosen location using different β 1935, 80 and 443 β the standard Flash Media Server (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 and sends another single connection request to that on the same port. If the user is unable to connect to a single CDN then either their internet connection is down or they have bigger problems because each CDN has a lot of failover and redundancy.
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 EMP 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 CDNs are supported
β’Β Dynamic CDN switching and ABR1 bitrate downswitching are both supported
β’Β Dynamic connection weighting and prioritisation is supported
The new player also provides a number of benefits for our development teams:
β’Β A²Τ 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 seems to have gone down well with the public with highlighting improved speed and reliability.
If you have any questions about Xenon please leave a comment below.
Gareth Jones is a software engineer in the TV Platforms team, Programmes and On Demand, ΒιΆΉΤΌΕΔ Future Media