Summer 2021 offered a rich selection of events to sports enthusiasts: Euro 2020, Wimbledon and the Tokyo Olympics, to name but a few. An ever-increasing proportion of the BBC’s audience has been moving from traditional broadcast to online consumption - the Euro 2020 Final, where Italy played England, set a new record for BBC iPlayer, with 7.1 million viewers streaming the match online.

In comparison, the 2018 World Cup Quarter Final, where Sweden opposed England, only attracted 3.1 million online viewers, yet our systems at the time became overwhelmed, leading to a major outage. Luckily enough, this happened at the very end of the match when the outcome was already settled. However, this incident did not go unnoticed by our engineers and triggered a significant redesign of our workflows.

How did we scale our live streaming architecture to reliably deliver media and allow audience figures to reach new heights?

From pull to push

To answer that question, let’s first review what happened in 2018. Many streaming platforms, including iPlayer at the time, operate with what is commonly described as a pull model. The player on your TV, phone or computer requests the media from a third-party Content Distribution Network (CDN). This forwards the request to the BBC’s routing and caching servers, which in turn send it on to the packager. The role of this last system is to transform encoded media by wrapping the raw video and audio into container files that are suitable for distribution to a variety of client devices.

You can view things as a funnel: multiple layers of caching and routing are present along the way to collapse millions of player requests every second down to a trickle of requests back to the origin media packager, each layer pulling the media from the next layer up. All of this occurs while trying to keep as close to the live time of the event as possible.

Even though widely used, this pattern has some significant drawbacks, the best illustration being the major incident that hit the BBC during the 2018 World Cup quarter-final. Our routing component experienced a temporary wobble which had a knock-on effect and caused the CDN to fail to pull one piece of media content from our packager on time. The CDN increased its request load as part of its retry strategy, making the problem worse, and eventually disabled its internal caches, meaning that instead of collapsing player requests, it started forwarding millions of them directly to our packager. It wasn’t designed to serve several terabits of video data every second and was completely overwhelmed. Although we used more than one CDN, they all connected to the same packager servers, which led to us also being unable to serve the other CDNs. A couple of minutes into extra time, all our streams went down, and angry football fans were cursing the BBC across the country.

We did fix and mitigate the immediate performance issue. After running several long and deep root cause analysis sessions, we concluded that having our media servers exposed to a request load that was ultimately not in our control was not a safe position to be in.

We decided to re-architect the system by switching from a pull to a push model. The idea is quite simple: produce each piece of media once and publish it to a dedicated live origin storage service per CDN. From where we stand, the CDN acts as a pure ingest point and has no visibility on any of our servers. In other words, we alleviate any risk of the CDN overwhelming our systems: as more people view our streams, the load remains constant. We end up with a much cleaner separation of concerns, with the BBC accountable for producing all media in time and the CDN now solely responsible for caching it and making it available for download at scale.

Drilling down on the packager

Before they arrive at our packager, video and audio signals are encoded into formats appropriate for distribution to our audiences. The cloud-based encoder is also responsible for generating an adaptive bitrate set of outputs, in other words, a range of picture and sound qualities to cater for different network speeds and device capabilities.

The resulting encoded media is then sent to the packager. Its role is to prepare all the files which will be requested by devices to play a stream over an HTTP connection. The packager produces two types of streams:

- HLS streams: in our case, the encoded media is packaged in fragmented transport stream (TS) containers. Apple devices and some older TVs use these.
- DASH streams: in our case, the encoded media is packaged in fragmented ISO BMFF containers (MPEG-4 part 12), commonly referred to as fragmented MP4. All other devices use these.

At a high level, the revised workflow is composed of four main components, the repackager, the distributor, the manifest generator, and the conductor:

All four components are designed as load-balanced fleets of microservices to support the load of dozens of BBC streams continuously flowing through them. These streams correspond to all our linear TV channels and their many regional variants, half a dozen World Service streams, and a variable number of event streams. The workflow is run in two independent cloud regions to allow for additional resiliency. Let’s delve into the role of each component.

The repackager

The upstream encoder produces video using the H.264 standard and audio using the AAC standard. Both the video and audio are wrapped in TS containers, and the encoder continuously sends small container files which hold roughly 4s of content each. The repackager component receives these chunks of content via HTTP PUT requests. Conveniently, their format is suitable for HLS streaming: to make HLS available, the repackager can simply forward them untouched to the next component in the workflow, the distributor.

However, it additionally needs to transform the TS chunks in a format suitable for our DASH streams. The repackager’s task is to parse the TS container and extract the raw H.264/AAC data. Using information gathered by reading through this media data, it rewraps the pictures and sound in an MP4 container with all required metadata. The generated MP4 files are sent to the distributor alongside their TS counterparts.

The distributor

The distributor component receives the MP4 and TS chunks sent by the repackager over HTTP, and in turn, publishes them to CDN storage locations so that our audiences can access them. Depending on the stream, one file may be published to several CDN endpoints for additional redundancy. The distributor can essentially be viewed as a one-to-many mapper, handling all authentication and retry behaviour when interacting with a CDN.

Additionally, for every TS chunk it receives, the distributor sends an HTTP request to the manifest generator, triggering the generation of a manifest corresponding to that chunk.

The manifest generator

Manifests are text documents. Their primary goal is to guide the player to download the different media chunks within a given stream. When the play button is pressed, the player first downloads the manifest, and using the information it contains, keeps on requesting small media files containing 4s of content. The downloaded files are rendered one after the other, allowing viewers to have a continuous and seamless playback experience. HLS and DASH define different types of manifests, and the manifest generator component is responsible for creating these variants. Generated manifests are sent to the distributor component over HTTP to be published to the CDN alongside the media chunks.

The conductor

The conductor provides several REST API endpoints to configure the behaviour of the other components in the workflow. For example, it is responsible for driving the automatic scaling of the microservices when additional streams are started, adjusting the monitoring, keeping track of start and end time of events, filtering encoder inputs, and a variety of other management tasks.

Paving the way to the future

Driven by a cross-departmental effort involving several teams, our push packager workflow has been successfully running in production since February 2021. Initially trialled with the BBC Two HD channel, it now continuously carries over 40 streams, with additional event streams soon to be migrated. Over a million new files are produced every hour, and billions of media chunks have successfully been uploaded to CDN storages since its inception. Across all summer 2021 sporting events, the system allowed us to reach a record 253 million play requests on BBC iPlayer and BBC Sport.

Even though the numbers shared here fit well within the realm of hyper-scale when it comes to data produced and network traffic, it is worth noting that online streaming is a small proportion of the BBC’s audience coverage. Linear broadcast TV still makes up the lion’s share. However, online consumption is steadily increasing, reaching about a quarter of all viewers during the summer events, and an IP-only future is fast approaching. With these efforts, we will be better placed to move forward: our new packager gives us the flexibility to adapt our content to take full advantage of improvements in specifications and allows us to reliably and cost-effectively serve millions more online viewers in the coming years.

Want to see our system in action? Open BBC iPlayer and simply press play on one of our live streams!

• BBC R&D - Designing UHD HDR for Euro 2020
• BBC Media Centre - Record-breaking first half of 2020 on BBC iPlayer
• BBC R&D - Low Latency Live Streaming with MPEG DASH
• BBC R&D - Higher quality video streams and improving adaptive bitrate reliability

From today, we’re rolling out a new look for BBC iPlayer’s playback on TVs. It’s a cleaner, sleeker and more pared-back interface, with some changes to how things appear during playback and new, improved subtitles you can customise and control.

The first thing most viewers will notice is the playback bar along the bottom. You will now see a simple, elegant bar that shows how far through the programme you are.

Gone is the play/pause button - play and pause icons are now briefly displayed in the centre of the screen when pausing and resuming, whilst rewinding and fast-forwarding brings up visual stills from the programme, so you can easily see when to press play again.

All the extra controls for more episodes, subtitles and settings and the button to add a programme to your list to watch later have all been moved to the top left of the screen.

As part of these changes, we’ve also made significant improvements to the way viewers can control subtitles on iPlayer. The new position of the subtitles and settings menu makes it easier than ever to turn subtitles on or off, as well as making it easier to choose the audio described and signed versions where available; plus, we’ve also added the ability to change and control the size of the subtitles.

Previously subtitles on iPlayer were automatically displayed as a larger size than we use on broadcast, so as part of these changes, we’ve made the default setting a smaller size. For those who need larger or, indeed, even smaller text, they can now choose from a range of five options. That choice is remembered for other programmes they watch in the future.

These changes follow some other recent improvements we’ve made to subtitles on iPlayer on TV. Previously subtitles would appear as coloured sans serif text with a black outline, always at the bottom-middle of the screen. This was far from ideal as, for example, it could be difficult to read the white text if the video image behind it was also white or was patterned. And if the part of the video image behind the subtitles contained something that viewers needed to see to understand the programme – for example, the clues on Only Connect – they could only see it by switching subtitles off.

The improvements we’ve made recently mean when you’re watching iPlayer on a TV, subtitles are now clearly readable, in the BBC Reith Sans typeface, with a black background behind the text, and the correct colours to show who is talking. They are also now positioned to take account of what’s on-screen, so they will no longer be covering important information, and mean our viewers who use subtitles can play along with Only Connect and enjoy Victoria Coren-Mitchell’s witty and withering jokes at the same time.

Currently, the new size controls are only available on our on-demand content but will be coming to live channels on iPlayer in the coming weeks. Let us know your feedback on the new look playback interface, the new subtitle controls or anything else at bbc.co.uk/contact.

> BBC iPlayer - Accessibility

> BBC Technology + Creativity - Accessibility

> BBC R&D - Casualty - Accessible and enhanced audio trial

At BBC Research & Development, we are investigating how we evolve our current multimedia applications to move beyond video by using object-based media (OBM). OBM allows us to develop future audience experiences which are immersive, interactive and personalised.

There is an ever-increasing number and range of audience devices capable of playing back OBM experiences. The challenge we now face is universal access - How can we get all members of the audience to enjoy OBM experiences on any device, and how do we do this sustainably and at minimal cost?

Our Render Engine Broadcasting (REB) project is investigating new technologies that will allow the BBC to deliver these OBM experiences at scale to all of our audiences, no matter what device they use. Our ultimate goal is to deliver real-time and fully rendered experiences on any device or platform and write the software to do it only once. We have been investigating the use of WebAssembly as a cross-platform technology for this.

What is WebAssembly?

WebAssembly (wasm) is a Universal Binary format designed as a sandboxed environment and a portable compilation target, which means that the same wasm module can run securely on multiple platforms. A number of strongly typed languages such as C/C++, Rust or AssemblyScript can compile to WebAssembly, making it language agnostic. This makes it an attractive option for adoption in the industry as it enables developers to use languages they already know to produce wasm binaries.

When WebAssembly was first developed a few years ago, its target platform was the web. The aim was to compile fast and efficient system-level code and have it run in the browser. Compute intensive applications, such as real-time interactive rendered graphics, could be run in a web browser at near-native performance. This also enabled some native applications to be ported to the web, increasing their reach and usage. These include Google Earth, which renders 3D representations of satellite image in the browser, and AutoCad, which now offers a WebApp to create and edit CAD drawings.

In the last couple of years, WebAssembly outside of the browser has been gaining traction. A number of native wasm runtimes have been developed, which has enabled the use of WebAssembly for microservices and server applications. In 2018, the website security company Cloudflare announced the use of WebAssembly on their edge workers, allowing users to deploy secure and fast serverless code compiled to wasm. And the edge cloud platform provider Fastly offers new wasm-based edge computation using their native runtime Lucet.

The portability of WebAssembly across multiple platforms and its security model are the key reasons for BBC R&D’s interest in using this technology as a compilation target for media experiences. As a public service broadcaster, we need to deliver value to all of our audiences, regardless of the device they use. Where traditionally, a codebase for each target platform and a different team to maintain each codebase would be required, the use of WebAssembly potentially allows for a much more sustainable developer ecosystem. It enables media software applications to be created once, from a single codebase, compiled to WebAssembly and deployed on any client or server platform depending on the capabilities required. It also offers numerous advantages compared to previous multimedia or cross-platform technologies (such as Flash or Java Runtime Environment). Indeed, it is language agnostic, security-focused, has predictable performance, and works inside and outside the browser. WebAssembly is also an open standard, which encourages its adoption.

How have we used WebAssembly?

We wanted to demonstrate how we could use WebAssembly to deliver media experiences that can run on many target platforms built from a single codebase. To do that, we implemented an example media application written in C++, which we compile to WebAssembly, giving us a wasm module. We designed this application to look like a version of BBC iPlayer, allowing users to select content, watch video programmes, AND play OBM experiences. We call this application the Single Service Player (SSP).

To run our SSP wasm module, we needed a wasm runtime. The SSP makes use of some low-level media functionality, which isn’t scoped by the WebAssembly specification. To enable wasm modules to make use of these low-level multimedia capabilities, they need to be implemented in the runtime and made available to the wasm module through a set of imports. Examples of such capabilities include:

• Windowing and rendering — In most cases, a multimedia application will have some graphical elements to it, which requires things to be drawn in a window (such as video frames or a UI screen).
• User inputs — An interactive multimedia experience expects user inputs, such as keyboard or mouse events.
• Media encoding and decoding — To efficiently encode and decode media (such as video frames or audio packets), it is preferable to use the host’s hardware resources where possible.

As there is currently no WebAssembly runtime that offers these media capabilities, we've decided to create our own.

There are already some efforts in specifying ways a wasm module can talk to the host. WASI (the WebAssembly System Interface) proposes a set of standardised POSIX-like syscalls (the programmatic way in which a computer programme communicates with the host system) for libc functionality, mainly file handling and networking. These are called from the wasm module and implemented in the runtime.

We decided to use a similar approach to allow our SSP wasm module to communicate with the host, enabling it to have access to low-level media functionality. This involved identifying all the platform-specific media capabilities that could not be compiled to wasm and implementing them in the runtime. These capabilities were then made accessible to the wasm module through a set of platform-independent syscalls passed as imports.

This figure illustrates the whole process, from writing a media experience as software (such as the SSP) to running it as a wasm module on any device. The steps are detailed below.

The first step was to design the multimedia sys-call API behind which we would implement our cross-platform multimedia capabilities in the runtime. It needed careful consideration to ensure it was thread-safe and honoured the wasm security requirements around memory access. In the figure above, we use reb_decode_video() as an example syscall, which our SSP application can use to access low-level multimedia functionality, such as utilising the system’s hardware for video decoding.

Our SSP code was compiled to wasm using the clang compiler and the wasi-sdk toolchain, and the required syscalls are added as imports to the wasm module.

We then built the multimedia wasm runtime, consisting of two parts. The first one is the execution environment for wasm modules, which allows us to load and run a wasm module. For this, we embedded Wasmtime, a ByteCode alliance project based on Cranelift, which generates the machine code for the target platform from the wasm binary.

The second part of our runtime is the implementation of the low-level multimedia functionality. For this, we created a cross-platform C++ library with input detection, networking, windowing, graphical rendering, and media decoding, which sits behind our carefully designed syscall APIs. We compiled our library for several target platforms, such as Linux, macOS, Windows, Raspberry Pi and Android. We also wrote some glue code to connect the two parts.

Where do we go from here?

A wasm runtime capable of executing multimedia applications opens a lot of possibilities, principally around flexible compute. Flexible compute allows us to run computationally demanding applications by dividing up the workload between available resources. These resources could be located locally (a laptop, games console or phone in your house), in the edge, or the cloud.

As we move towards delivering fully rendered real-time interactive experiences, the flexible compute approach becomes an attractive solution to the computational demands of such applications. We could, for example, consider segmenting a rendered frame into several tiles or objects, each of those rendered on a separate available compute resource. Many systems approach this problem by running specific compute tasks in containers across the available devices and platforms. We hope to use our work and accrued knowledge in developing the wasm multimedia runtime to investigate a viable alternative to the container approach for distributed media applications. We are looking into using wasm modules to perform secure and fast computation on any remote compute nodes.

Our runtime, capable of performing media services such as rendering and decoding or encoding of rendered video frames, can be used to display the final experience to the user on a client device and to execute the remote computational tasks as wasm modules. Using WebAssembly combined with a flexible compute approach, we hope to develop technology that allows the audience to access any future experience, regardless of their devices at home.

Back then, iPlayer was a catch up service for the BBC: programmes would only be available on-demand for a limited period after they had been broadcast and recorded from terrestrial TV streams. Since then, iPlayer has evolved, allowing programmes to be made available before they are broadcast. This is made possible through our file-based delivery workflow which has been in place since 2013 and enables pre-recorded shows to become available on iPlayer as soon as or before they are broadcast on TV.

Unfortunately, as of 2018, audio described content was still living in the catch-up paradigm, where content was only made available on iPlayer after it had been broadcast. This meant that old shows, Doctor Who for example, made available again as box-sets on iPlayer, but not scheduled for the TV, did not have their audio described version made available.

This was a frustration for our viewers who could regularly access audio described content on iPlayer, but would find some programmes missing their audio described version even if it had been available in the past, or was to be broadcast in the near future.

With Killing Eve season 2 released on iPlayer as a box-set with all episodes available with an audio described version, I felt it was a good time to tell our side of the story. This blog post will cover some of the tech we used to make audio described content available on iPlayer.

The media files

To create audio described programmes we need two types of media.

Video file of a scheduled programme (MXF file)

We receive a video MXF file, from the production team who made the programme, in a very high quality, high-bitrate AS-11 DPP format. This is a format developed in conjunction with other UK broadcasters for file-based delivery workflows. The MXF file contains the video and the original programme audio without audio description and is used to create all the different formats needed to stream or download our content. It may be in stereo or surround sound, standard definition or HD. You will see that the audio described version of the programme is also created in the AS-11 DPP format with the same quality and features as the regular programme but with audio description dubbed in.

Audio Description Studio Signal (AD WAV file)

An audio description studio signal is produced and delivered to us by our partner Red Bee Media in a stereo WAV format. The left channel contains the audio described voice track, with no original programme audio and the right channel is control data, not something you’d want to listen to unless you find a fax machine weirdly soothing. The control channel is used to dip the original programme audio so as to ensure the audio description is audible over any background audio in the programme. This paper from BBC R&D has more detail on the audio description studio signal.

The media tools

To do the mixing we use the following tools.

Gstreamer

Gstreamer is an open source multimedia framework that we use with an audio description plugin developed by David Holroyd. The plugin only works on audio so the original programme audio must be extracted. It mixes the original programme audio and the audio described voice track, adjusting the gain of the original programme audio as signalled by the control track so that the audio description can be clearly heard. The output is a single mono track so this has to be run twice, once on the left audio channel and once on the right audio channel, for a stereo programme.

BMX

BMX is an open-source project from BBC R&D to read and write MXF file formats in common use at the BBC, written by Philip de Nier. It has had many uses in the BBC over the years, most recently as a widely-used engine for generating DPP files. We use the following utilities from BMX to create our audio described content:

• bmxtranswrap to extract the stereo audio channels from the MXF file and convert them to uncompressed WAV format.
• mxf2raw to extract the MXF metadata and raw essences, which are the video and audio elements.
• raw2bmx to assemble an MXF from the metadata and raw essences

The process

The following steps outline how we use the media files and tools to create an audio described version of a programme. These are the instructions implemented in our code that we deploy on EC2 instances in AWS.

Preparing the AD WAV file

We receive AD files in a mixture of 16 and 24 bits, so we normalise them all with Gstreamer to 16 bit. We now have:

Extracting the audio from the MXF file

First, we extract the left and right audio channels from the MXF and convert them into separate mono WAV formatted files.

Each audio channel starts with what is called a “handle” — a term for a sequence of tones used for broadcast timing. The video also includes a ticking clock during this handle period. We need to remove the handle from the audio before we can mix, as the AD file does not contain the handle stage.

So we extract the handle and store it for later. Finally, we extract the audio after the handle to give us just the original programme audio. The audio is now ready to be mixed.

Mixing the audio description with the original programme audio

The Gstreamer plugin then mixes the original programme’s left and right audio channels with the audio described track. The handle is then prepended to both channels so that they are now in sync with the video. This creates our final mixed audio described tracks ready for reassembling.

Extracting essences

We need to extract all the essences from the original MXF file to then insert the mixed audio described tracks. The essences will consist of the AS-11 metadata, one video essence — the main bulk of the MXF — and the audio essences. The essences look like:

• Metadata: as11-core.txt, as11-dpp.txt and as11-segments.txt
• Video: essence_v0.raw
• Audio: essence_a0.raw essence_a1.raw

Assembling the final MXF file

The mixed audio described tracks are used in place of the audio essences, but all other original extracted essences, video and metadata are used to construct the new audio described MXF. We now have our audio described MXF that is used in our file-based delivery workflow to create the compressed assets that can be played in iPlayer.

The quirks

Performance

Downloading, uploading, extracting and assembling media files is a slow process. This is due to the size of an MXF file. An hour-long HD MXF file will be around 60GB. Processing a file of that size takes considerable time. We took some steps to reduce the processing time by using an i3.large instance for its high network performance and high I/O performance with SSD storage.

With these features, an instance can still take over 40 minutes to complete one mix. This raises a problem for auto-scaling instances.

Auto Scaling

It is common for our components to scale out when work piles up in the form of messages on our instance’s input queue, similarly scaling in when work is low. We want to prevent scaling in from terminating an instance that is currently processing one of the messages and doing work.

Instance protection allows an instance to protect itself from a scale in event by requesting protection from the AutoScalingGroup API. When one of our components will have a long running process like creating audio described content it will protect itself when it starts processing a message, then removing that protection after the message and work has been completed.

Long-term storage means long-term costs

To reduce storage costs for the BBC, once a programme’s availability has expired on iPlayer, only the original MXF file is kept for long-term storage. All other versions of that programme are removed, including the audio described version. This is why in the past audio described content that was previously broadcast did not reappear on iPlayer when its original version was made available again.

This is no longer a problem, because the audio description studio signal is now kept in long-term storage. An audio described version of a programme is now recreated when ever the programme is rescheduled for the iPlayer. This is more cost effective than storing the audio described version.

Testing with Docker

The majority of our micro-services don’t manipulate media; that is done with on-site hardware or third party cloud transcoders. The audio description workflow is different. It relies on the tools mentioned above: tools that only a few of our developers have installed locally. We could have mocked the calls and just checked the functionality of the code, but we wanted something a bit more robust.

With Docker we are able to run our code and tools as if they’re running on an EC2 instance, thereby testing the whole audio description workflow locally and in our continuous integration workflow. We do this with a base image of our underlying EC2 instance’s OS and installing our project as an RPM. When testing, we overwrite the compiled jar on the image with a local copy to avoid rebuilding the image.

Interested in learning more?

• Audio described content on iPlayer
• Royal National Institute of Blind People
• “The Audio Describers”: A BBC Radio 4 programme about audio description

We turned on the back end services a month before the feature went visible to the public, so most programmes had thumbnails available at launch. We later ran a backfill job to generate thumbnails for extended availability content.

We initially launched the feature on desktop and tablets that use a responsive web player. We added the feature later to Sports Apps for mobile devices and recently IPTVs. Other Apps for mobile devices will follow.

The challenges

There were some challenges to address and consider when delivering the visual seeking feature to achieve high perceptible quality, low latency, efficient broadband use and supporting wide range of playback devices with different requirements.

The rest of the blog post will give you details of the solutions and the trade-offs that were considered.

Faster

One way to enable thumbnail scrubbing could be to download the entire video in low quality, then generate the correct frame by seeking the low quality video to the correct place. Decoding video in this way is a particularly CPU intensive process, so instead we opted to generate thumbnails as a collection of JPEGs ahead of time for the media player to consume.

Let’s say a video contains 500 thumbnails. To download these images, the player could make 500 separate requests for one thumbnail at a time. The problem with this is that each request has an overhead, a delay before data starts arriving. Poor network conditions make this delay significant, and browsers will limit the number of simultaneous requests that can be made, resulting in poor performance.

We can improve the efficiency of acquiring the images by packing the individual thumbnails into storyboards. A storyboard is a 5x5 arrangement of thumbnails packed into a single image file. This reduces the number of requests that the player needs to make by a factor of 25 rather than making 500 separate requests for images, the player only has to make 20. The player then treats this storyboard as a sprite sheet, displaying only one thumbnail at a time.

Efficiency

The player downloads storyboards ‘on demand’ to make efficient use of the broadband connection. When the user hovers over the scrub bar, only its related storyboard and two adjacent neighbours get downloaded. Because the storyboards are downloaded in this way, we can afford to produce a greater number of thumbnails for a video to enable a very fine level of scrubbing. Move your mouse one pixel to the right and you’ll get a new thumbnail. This helps to make seeking more precise, which is important for longer programmes.

Packing thumbnails into storyboards has some pitfalls of its own. The thumbnails themselves compress much better using the JPEG format rather than PNG or GIF. Given this, we decided to use JPEG as we get the same visual quality but for a smaller file. The JPEG format breaks the image into 8x8 pixel blocks, each of which are compressed separately. To provide good quality for the compression used, we needed to pick thumbnail sizes where the edges of the thumbnails fall on the boundaries of these blocks to limit 'bleeding' between adjacent thumbnails. BBC R&D recommended three different thumbnail sizes to cater for different screen sizes. The sizes were picked to reduce this bleeding as much as possible: joins between columns line up perfectly, but the joins between rows don't always align with the blocks. Where there is misalignment, the frames will be seen to have a fuzzy edge as seen in the example below.

Compare the fuzzy boundary between thumbnails 2 and 4 with the sharp boundary between thumbnails 3 and 4. The content of adjacent thumbnails affects the image where the 8x8 blocks do not align with the thumbnails.

Standardisation

Another big challenge was the absence of standardisation for media representation of the thumbnails for video in online video industry. BBC R&D provided us a library they developed which is based on streaming clips which is strategically better but not supported on TV version of iPlayer. Thus, we couldn’t use it. BBC R&D and Media Services collaborated on producing a form of media presentation description for the thumbnails of a video based on the MPEG-DASH industry standard. Being able to describe the thumbnails as media is particularly beneficial when used with the storyboards to structure the description of thousands of thumbnails for video.

The extension to the standard also allows us to describe and structure varying number, size and layout of the thumbnails for the same video. To do so, we preferred using separate adaptation sets for each storyboard with different characteristics to reduce the restrictions of the media description to build a future proof foundation.

The thumbnail media presentation description extension was communicated with the MPEG-DASH community, which led to recognition of thumbnail support in media presentation description hence became part of MPEG-DASH industry standard with DASHIF V4.1.

Another Brick in the Wall (of microservices)

Video Factory is the product that deals with the conversion of audio and video for publishing to the BBC sites including iPlayer, Sport and News. It is built using microservices - small pieces of software each with a single purpose, one step in the much larger workflow.

Using this architecture pattern, when we want to add a new feature we just need to create a new microservice and add it to the workflow. This is exactly what we've done for Visual Seeking.

We encode very high quality source video and produce a variety of different bitrates to support playback and streaming with over 1000 different devices, including PCs, phones, tablets, games consoles, and smart TVs. These individual bitrate videos are then distributed and published. We included the thumbnail feature by using the encoder output for a specific bitrate and creating thumbnail storyboards and media presentation description manifest file which are then distributed and published.

By adding the new feature in this way, we were able to make the change without affecting any of the original services. Thumbnail generation and the publication of videos work independently of each other, meaning that there is no extra delay in the videos being published; and if the thumbnail service were to fail, the videos would still appear on iPlayer.

The thumbnails are distributed through a high performance and resilient content delivery architectural solution that also provides authentication and content routing. Radix is a web cache that originates the BBC thumbnails as well as the BBC on-demand content that is distributed by CDNs.

It’s all about compromise

We had a number of design decisions to make, and ultimately they were decided by compromising between quality and efficiency. We made the decisions considering the trade-offs of each option after some measurements based on the following facts:

• Increasing the quality of the image leads to an increase in the storyboard file size
• The bigger the file, the longer it will take to download
• The perceived quality of a small image doesn’t change after a certain quality level.
• An increase in the number of thumbnails in a storyboard also increases the file size but reduces the number of requests that the player needs to make to be able to get thumbnails for video.

We made a target to produce storyboards at approximately 100KB each. Storyboards of this size can be downloaded very quickly on most connections, and they are of reasonable quality. Devices on slower connections will benefit from progressive JPEG loading, meaning that the full image may appear in low resolution before it has finished downloading.

Even though the frame on the left has only loaded 25% of the image data, the entire image is visible and the context is still discernible.

The file size requirement meant that there is a noticeable loss in image quality, but the effects have been reduced by picking thumbnail sizes that play nicely with the JPEG format.

Our microservice creates storyboards from an input video. We could have used the highest quality output from the encoder to produce storyboards, but using such a high quality input would require a powerful server and a lot of time. Instead we can produce essentially the same output with one of the lower quality videos from the encoder: this vastly reduces the amount of resources required (therefore smaller operating costs) for an almost imperceptible difference in quality. The bitrate we’ve chosen takes under 2 minutes to produce thumbnails for an hour-long video.

Spoilers?

The introduction of visual seeking could mean that people might accidentally see a key moment of an episode’s plot as they move their mouse towards the full screen button. This is why we have introduced a short delay between the user hovering over the scrub bar and the thumbnails appearing on our media player. We hope you find Visual Seeking useful. We welcome feedback and we’ll try to answer any questions you may have.

We are hiring!

Video Factory is one of the products that the Media Services team are working on at the BBC. There are new features and media technologies we use to improve our services. Visual Seeking is merely one of them. If you like the idea of working with video/audio encoding, publication and live and on-demand streaming services and want to play an important part in the future of online media, you can apply for the job openings here when available.

Whilst this feature is already available via Red Button+ and the BBC iPlayer app, we felt that it could be given more prominence by providing it where the audience needs it most: when they change channels. And we have made this as seamless as possible through the press of one button, the green colour button on the remote control.

When asked, users who hadn’t used our connected services before were delighted when we showed them the feature and said that it would be a key driver for using BBC iPlayer on their TV.

We found that our audiences tend to restart a programme at different times of the day and for different programmes, but the peaks were usually a few minutes into a programme. We also found that usage increases when we hit a so-called ‘schedule conflict’ - in other words where programmes don’t end at the traditional on-the-hour or half-past-the-hour junctures.

For example when the Great British Bake Off finished on Channel 4 and Doctor Foster on BBC One had started 15 minutes ago - we saw a huge peak in our audience launching BBC iPlayer to restart it. So with this knowledge we decided to display the trigger when the user turns to the BBC channel. That way we display the trigger when the user is most likely to need to restart. After 30 seconds the trigger clears from the screen, but the viewer can press green at any point whilst on the channel.

This feature works for Smart TVs that are connected to the internet and devices that can ‘seek’ to the start. We’ve built a ‘smart’ trigger that will only display if the device is capable of supporting the functionality. This covers many LG, Panasonic, Sony, Samsung, Vestel, Phillips, Hisense TVs along with Humax and Netgem set top boxes.

Whilst on the surface this is a simple and straightforward feature, under the hood we’ve had to contend with considerable complexity. Working at the BBC always means you’re building to scale and I love that about my role, but this time it came with a warning. “You might break the whole of BBC iPlayer”.

The challenge came on two fronts - both concerned with capacity. Firstly, there’s a finite number of simultaneous streams we can safely support and secondly there’s an upper limit to the speed at which we can provide them. First imagine that the entire audience of EastEnders decided they wanted to restart the programme. Second, imagine that they all decided they wanted to restart it within the same 5 second period.

These are unique, scaling problems at a national level and it’s inspiring to work with teams who try to solve them. Mitigating the risk of a reduced audience experience has taken the majority of our time on this project. We’ve built a monitoring service so that we can measure traffic in a more timely fashion, ensuring we protect and maintain quality for the current viewers in the stream. Alongside this we worked with our distribution and media services colleagues to trial the feature on BBC Two and BBC One regions to build a traffic profile.

Today we have launched our green button ‘watch from the start’ trigger on BBC One and Two along with their HD equivalents and BBC Four, and it’s available via this list of smart TV and set top boxes. We’ll be looking to learn from the data and provide the best quality experience we can, and hopefully, in the future, pressing the green button will become just as much a part of the TV viewing experience as pressing red has become.

Matthew Clark, Head of Architecture in BBC North, looked at The Nanoservices Architecture That Powers BBC Online. He described how the BBC’s website and apps, used around the world by millions who read, watch, and interact with a range of content, handle this scale with an innovative website platform, built on Amazon ElastiCache and Amazon EC2 and based on nanoservices.

Live Restart from broadcast

One of BBC iPlayer’s most valued features is the ability to jump back to watch the start of a programme whilst it’s still being broadcast, meaning you’re never late for a BBC programme again. We originally developed the feature for computers but have since rolled it out for mobiles, tablets and connected TV devices and it’s now used by over a million browsers every week. We want to make it as simple as possible to access Live Restart and have been working with TV platform providers to integrate links to Live Restart into their interfaces. First out of the blocks was Freesat, who integrated in July and we are working with other partners to provide easy access to this feature. We're also preparing to roll out one-button-access to Live Restart on capable, connected devices via on-screen triggers from our broadcast channels. Watch this space.

Boxsets

When BBC iPlayer first launched in 2007 it offered 7 days in which to catch up on programmes after they were broadcast on TV. Fast-forward to 2017 and there are over 6,500 episodes to enjoy at any given moment, including a growing number of boxsets, both brand new series like Snowfall, Motherland and Josh and gems from the archive like Louis Theroux’s Weird Weekends and Killing For Love. This Christmas, dozens more top draw BBC boxsets will be made available to watch on BBC iPlayer. To make it easier to discover this wealth of programming we’re updating the iPlayer Home screen to make it easier to browse. We’re also developing autoplay, which automatically cues up another episode when the credits start rolling (with the option to cancel/turn off).

Sign-in on TV

With so many programmes to choose from, it’s not always easy to keep track of the series you’re watching or to decide on what to watch next. Users of BBC iPlayer on computers, mobiles and tablets have been able to sign-in for a number of years now to resume part-watched series and episodes, add programmes to watch later and enjoy more relevant recommendations. This year we’ve been rolling that functionality out to connected TV devices. We’ve made it simple to sign-in on your TV – no need to input a lengthy email address or password using a remote control – just sign-in on a computer, tablet or smartphone and input the 8-character code shown on the TV screen. We’re also rolling out simple account switching, so multiple household members can all be signed-in on the same TV and easily toggle between their different accounts.

Device support

We put a lot of work into ensuring BBC iPlayer continues to work on older devices. Unfortunately, it is not always technically possible or economically viable to continue to support a device, especially when the manufacturer has discontinued support. In these circumstances then we aim to provide owners of those devices with as much advanced notice as possible and guidance as to how they can continue to enjoy BBC iPlayer without needing to buy a new TV set.

That’s all for now. Comments welcome although individual technical queries are best directed to BBC iPlayer Support (if you haven’t been able to find an answer to your question on the BBC iPlayer Help site).

In this blog I hope to provide some insight into our unique development environment and the problems we face in our day-to-day. The first of which is how our defect management has evolved over time to better serve the team, followed by details on our methodology changes to scripted testing and how this has improved our pre-release regression tests.

What we had

When I joined the team defects were not monitored or quantified, they were contained within a massive backlog in a ticket management system that was thousands upon thousands deep. It made providing a known issues list or giving a statement of quality to stakeholders difficult; even deciding the highest priority issues due for fixing proved confusing. Regression testing was brought up as a point of concern at all meetings - mainly due to the time it took to complete - but feedback from our testers was also extremely negative because of the amount of time they had to spend reading the same tests and flagging them as pass or fail.

Defect management - our first iteration

First of all, we consciously embraced the concept of defects as a part of the codebase and conveyed that managing them can radiate a clear visibility of state. We also wanted the team to understand how changes could negatively affect the various features within each App. Each discovery provided us with a better understanding of our quality status and enabled us to spot defect clusters that revealed any serious underlying problems that needed addressing.

Trying to dig through a digital backlog to pull out all relevant tickets was proving too time consuming and we needed something immediate that the entire team could use to manage defects. We decided to go with the simplest solution: a whiteboard. iPlayer Mobile already used a few of these to visualise its workload and allow collaboration but defects were often lost or forgotten. We cut our losses on existing defects and any new ones that were discovered were also created as physical tickets and sorted together by App platform and feature type.

Anything we discovered and didn’t fix as part of our current work was added to this board. These defects were prioritised according to severity and impact on the user; this is how we decide where to focus our efforts in maintaining iPlayer. Any of these issues that reached an age threshold were re-evaluated in a session where one of two decisions were made. We may have decided to close the defect if it could still be reproduced and we have not had complaints from the users regarding it or if it has been inadvertently fixed by other development work. We may have decided that the issue was still serious and made an enforced effort to get it fixed; these sessions were time consuming however, as we had more ageing defects and going over old ground wasn’t seen as the best use of time.

We discovered from this that the team was more aware of the quality status within the Apps, as anyone on the team (or any other team) could see all of our current defects at any time. We even saw developers attempting to clear tasks from the board when it was getting full, a type of engagement we’ve never had before. We were able to use this as our known issues list so that we could reference the tickets when engaging with audience complaints or another team if they were having similar issues.

However as time went on, the team grew in size and iPlayer spawned iPlayer Kids. Now with three squads and two Apps, the amount of tickets we were creating and the amount of changes that caused defects became too much. The overhead of keeping the board up to date was now a burden and due to the increased workload we were having little time to fit this in, a new solution was needed.

Defect management - what we have now

After reviewing what we needed for our day-to-day, we came up with the following requirements:

• Accessible to anyone who may need it.
• Easy to sort and pinpoint information.
• Needs minimal interaction to ‘just work’.
• Enable us to track metrics over time.

To do the above we switched to a digital dashboard, using filters and macros that read data from JIRA and output them into numbers. These can be selected to display the tickets related to the data or even turned into graphs allowing us to quickly make sense of large amounts of data. We house this on our wiki page system that’s used mainly for documentation.

As new defects are created they are automatically sorted. Although it may not be as technically advanced as some of our other tracking mechanisms, it is widely available - anyone in the company from any site can view it, allowing us to keep all of our stakeholders in the loop. As time goes on we can see that we raise more defects than we fix and end up closing more due to age. This tells us that we worry far too much about many small defects that we realistically will never get around to fixing. We lost the visibility that a physical board supplied, but as the team has matured it is not as necessary, as we are more aware that changes can cause unseen permutations throughout the Apps.

This may influence our next iteration, many agile teams implement a zero defect policy where errors are either fixed as they are found or they are forgotten about. I believe this will be difficult to introduce within our environment as we have large-scale accountability both to our audiences and the business, although we could make another step in that direction and hope to get there at some point.

Changing our test case and regression test methods

The Mobile iPlayer Apps are in product maturity and therefore suffer from problems commonly associated with this lifecycle stage; for test the classic example is bloated, over-documented tests, some of which are ancient due to creating them as we go through sprints or release cycles. This caused testing to drag on for longer than required for the scale of the changes. The planning, recording of results and then reviewing them became overly time-consuming and bottlenecks in testing became obvious quickly. This also doesn’t factor in the communal groan amongst the team once ‘regression testing’ was mentioned; it had become a piece of work everyone dreaded and no-one wanted to do - it needed to change.

After looking at test techniques both internally and externally we experimented with the idea of a fully exploratory method where testers are given no rails to follow (usually in the form of instructions or Given-When-Then style tests). Results were mixed as we received feedback concerning the lack of information supplied and a willingness to go back to a more traditional linear style. This came mainly from non-test disciplines that used the step-based tests as a rigid set of instructions; a habit we wanted to break however unpopular it was. Product was also concerned that the tests formed a repository of intended behaviour for the application that could be accessed quickly. This would be impossible without test cases that contained detail.

After this experiment ended we were left torn between serving the needs of iPlayer in terms of not losing information and keeping the tests accessible to all members of the team, but also reducing the upkeep and planning overheads that were causing bottlenecks at this point in the release cycle. We also had to maintain the bar Test has set within Mobile iPlayer by providing thorough quality assessments and a high device coverage. We decided to perform an overhaul of our test cases over the course of the following month with all the considerations we had gained throughout our experimentation phase.

Currently our manual tests take the form of a wiki style entry for individual features containing:

• High level UI information.
• Example images.
• Detailed descriptions for complex behaviours.
• No completion goals, these are set by the tester.

This method enables experienced testers to work with less structure while providing a reference tool for their observations; not dictating the paths and interactions a tester has with the application should provide more coverage. Inversely inexperienced testers or other disciplines can use the information supplied to get a better grasp on the mechanisms and interacting components within the software.

We also set a goal of reducing the number of tests to a tenth of their original amount and allowing more people access to them with the aim being:

• Reducing the overheads involved in maintaining a massive amount of tests.
• Allowing us to add tests for new features quickly.
• Easing the creation of a test plan.
• Opening up the test cases to team ownership.

When faced with the prospect of completing hundreds of tests to cover an application, a large amount of that time is spent filling in results or doing similar admin. This is now a secondary task against the actual testing. We remain fairly brutal about getting rid of tests we no longer need or diminishing ones that become too large, even more so about un-necessarily testing more than we need to. Although in the future we may scale this down to a truly non-documented exploratory system, like the defect management above this is perhaps a halfway iteration that the team can handle until it’s ready for further change.

Looking Back and Looking Forward

We discovered that sweeping changes are difficult while supporting a team that has an unrelenting schedule of new features and improvements. Getting the wider team to embrace change was perhaps even more difficult; for future changes it will be important to involve the team earlier and at all stages. Process changes and improvements proved to be jarring for some, if we were to attempt it again it would have been more beneficial to ease changes in over time and be able to explain our reasoning to the entire team when commencing change.

Empowered testers now work with developers to ensure we have no oversights while planning is undertaken. Since these changes have been implemented we’ve noticed less bottlenecks in the release process - at stages where we would normally be on red alert to create a test plan, we have it ready to start. The team now understands the resources a phase of testing will need and allocates an adequate amount of time to plan, extra bodies to swarm on testing and a communal review period where an assessment of quality will be made.

There aren’t many metrics we could use to track the mood of the team, but from the state we were in a year ago when regression testing was panicked, loathed and painstakingly slow, the team's mood now hardly alters as regression is just another part of our cycle. It's over a lot quicker on the whole, although mapping times isn’t fair as the size of releases can vary, as can the resources. I haven’t heard any complaining in months also, so that’s a good sign.

Potentially this is just a step towards a way of working where we don’t catalogue defects at all and testing is handled purely in very lightweight notations or mindmaps, ideally with the entire team stopping to swarm on a test task before any more progression is made. However this will take time and patience; iterating towards that goal and evaluating along the way will be much more effective due to the nature of our dependencies and the sheer size of the team.

iPlayer has evolved from an App that serves the TV shows that the user requests to a platform where you can create your own catalogue of programming, download it to watch later as well as being able to play purchased content from a back catalogue. Coupled with the then new iPlayer Kids that has personalisation at its core, this brought tough challenges concerning stability, user data and security. This will become more of a priority as iPlayer continues to become less static, instead it will look different for each user and surface vastly different content based on what they like, dislike and interact with on a regular basis.

For us this poses one large question: how do you test that? If all users get a different experience how do you ensure you represent them all, or if not all, then at least enough to give confidence in an extremely complex product’s ability to perform well within varied configurations including fragmented devices and network types. It’s one we need to be prepared to answer and then act upon sooner rather than later.

I hope you enjoyed this insight into Mobile iPlayer Test improvements and if you have any questions, comments or similar stories please add them to the comments section below.

First launched on computers in time for the London 2012 Olympics, Live Restart has proved to be a hugely popular feature, ensuring viewers need never miss the start of a BBC programme again. Last summer we rolled the feature out to connected TV devices, I am delighted to announce that we’ll shortly be rolling the feature out to our Android and iOS mobile and tablet apps. Our most recent app update introduced the ability to pause and rewind live TV and you’ll soon be able jump back to the start of a programme on your mobile or tablet with a single tap.

We’ve also recently made it easier to access BBC iPlayer’s Live Restart feature on connected TVs by adding access from the Red Button+ home screen. Red Button+ is available on a wide range of connected TV sets and via YouView and Virgin TiVo.

Live events

The summer is typically a quieter time of year for BBC iPlayer. Not this year. Live coverage of Glastonbury, Wimbledon, The Euros and The Olympics helped BBC iPlayer reach an average of 16 million unique browsers a week in June, July & August – up 37% on the same period last year. And this wasn’t just viewing of our broadcast channels on different devices – in May of this year we began streaming live events not broadcast on TV on iPlayer, enabling us to show live performances from six stages at Glastonbury and up to 24 live simultaneous streams from the Rio Olympics. The below chart, compiled from BARB TV Player Report data, shows the scale of live viewing in iPlayer over the summer months. In the week ending the 14th August, live accounted for 46% of total iPlayer viewing time.

HD by default

We want to deliver the best quality viewing experience we can based on the capabilities of the device you’re using to access iPlayer and the speed of your internet connection. Consequently, we’re making HD (720p 50fps) the default for on demand playback on computers and connected TVs which support Adaptive Bitrate (ABR), which enables the video quality to be automatically adjusted in response to how much bandwidth you have available at any given moment. Users with TV devices which don’t support ABR can still opt-in to HD via the button in the player. We’ve also recently made BBC One HD available to watch live on computers and connected TVs (it’s the default on connected TVs which support ABR and can be accessed on computers by selecting England, Scotland, Wales or Northern Ireland from the ‘Change location’ menu in the footer of the iPlayer website).

For users whose broadband isn’t up to HD streaming, don’t forget your can download programmes in higher quality to watch offline, either on your computer or your mobile or tablet.

Visual seeking

Whilst BBC iPlayer already takes care of remembering how far through a programme you are, automatically picking up where you left off, there are those occasions when you need to search for a particular moment within a programme. We’re just about to make that a whole heap easier with the introduction of visual seeking. Hover over the scrub bar and you’ll see images from the programme appear as thumbnails, enabling you to jump straight to the moment you’re looking for. And if you want to share a link to a specific moment, you can add #t=XXmXXs to the end of the URL (replacing XX with the number of minutes and seconds - e.g. http://www.bbc.co.uk/iplayer/episode/b00v1xk5/elsa-the-lioness#t=20m15s). Available very soon on the iPlayer website, we’re looking to roll visual seeking out to the iPlayer TV and mobile apps in the coming year.

Also in development

There are lots more enhancements to BBC iPlayer in the pipeline including the roll out of subtitles on our live channels (already available on computers as a ground-breaking trial), an archive category, enabling easier, cross-platform discovery of the 400+ archive programmes now available on BBC iPlayer (thanks to BBC Four Collections) and a raft of personalisation features to make it even easier for you to discover and enjoy great BBC TV.

We’re also continuously working with manufacturers to improve the performance of iPlayer on their devices. For example, we’re currently working closely with Google on improving the Google Cast experience in iPlayer, before rolling out the feature to the BBC iPlayer Kids app, which launched in April and has already been downloaded over half a million times.

That’s all for now. Comments welcome below although individual technical queries are best directed to BBC iPlayer Support (if you haven’t been able to find an answer to your question on the BBC iPlayer Help site).

Video Factory is designed as a collection of microservice components - small independent pieces of software each responsible for a particular step in the overall workflow of processing an item of content. The components communicate with each other asynchronously using messages sent to and read from queues. When a component receives a message, it will perform some task on the item which the message is about, then typically send new messages to other downstream components. In other words, components react when the workflow needs something done.

Deploying Video Factory to the cloud has allowed it to be reactive in other ways. Many workflows begin when a broadcast ends, and when several end at the same time the increased workload could previously have caused delays in content reaching iPlayer. Now, though, it’s easy to expand our computing infrastructure at these busy times and reduce it again when there’s less to do. This flexibility also means we can be resilient against any particular server or network connection breaking down.

Video Factory ingests raw content in several different ways, one of which is file-based delivery (FBD). When one of our suppliers uploads video files to the S3 storage service, S3 sends a notification message to a component known as Dipper. Dipper’s job is to check whether the file meets our criteria for ingest, extract DPP metadata from it (hence “DiPPer”), save that metadata for future use, and finally send a message downstream to the component responsible for actually ingesting the video. DPP - the Digital Production Partnership - is a joint effort by several UK broadcasters to define a set of standards, including ones for video metadata.

Within Dipper, the stages in its processing form a dependency tree, with each step using results from one or more earlier steps to provide its result. This led us to extend our “reactive” approach to encompass not only the way components communicate with each other but also the way an individual component works.

Our development of FBD coincided with AWS Lambda becoming available as a service. Lambda allows code to be run directly in response to a notification, without us having to boot-up and manage a server for the code to run on. While Lambda does now support Java, the language in which most of Video Factory has been written, at the time it required the use of NodeJS.

Often, programs boil down to a series of imperative instructions. In JS, though, all I/O operations are asynchronous, meaning that the result isn’t available straight away. To get the result, you have to register a callback — a function which is to be run when the operation completes. If you have several I/O operations to do, JS code can end up resembling the so-called Pyramid of Doom.

This quickly gets messy, especially if several steps actually depend on the same value.

Since Dipper does a lot of I/O, we want to avoid a nested callback design. Instead, we just want to define how each piece of data can be obtained, and what the data dependencies are between the various processing steps.

A NodeJS library called Q implements a feature called promises, which makes this possible. A promise is an object that represents the return value that a function (say, f1) will eventually provide. In JS, functions are also objects and can be attached to promises such that when the promise is “resolved” (i.e the return value becomes known) any attached functions will be invoked with that value. Moreover, attaching a function (f2) to a promise gives you a new promise: a promise of the return value of f2.

An example of parsing some XML might look like this:

We can attach as many functions to one promise as we need, and combine promises together into new ones (as with Q.all, above) where a function takes more than one input, like our parseXml function here. And so long as the dependencies are satisfied, we don’t care about the order in which steps are executed. When Lambda’s NodeJS interpreter runs the code, it can parallelise operations so one step doesn’t have to wait for an unrelated step to finish. The main module of Dipper’s code is solely concerned with the wiring-together of promises into a dependency tree. When the final promise in the tree is resolved, the whole job has been done. Other modules concern themselves with providing specific bits of data, like the contents of a downloaded file, or the response from a message queue.

When in the future we want to build workflows for new suppliers, it’s likely we’ll want to reuse some of the steps inside Dipper, perhaps adding or removing some others, or changing some dependencies. Having our code structured this way will help make that reuse a reality.

Links

http://www.reactivemanifesto.org/
https://github.com/kriskowal/q
https://gist.github.com/staltz/868e7e9bc2a7b8c1f754
https://en.wikipedia.org/wiki/Digital_Production_Partnership_(DPP)

One of the things we know is that people trust the BBC to pick out the best bits of our output for them, including new and established musicians and writers from all over the world. A key place we do this is on the radio station homepages. However, we also know that a lot of people who visit radio station homepages haven’t clicked on the bits that we’ve picked out. Part of this is to do with people often visiting radio homepages just to listen to live radio. However, we did some tests and found out that if we did a better job of showing some of the extra content we’d picked out we could double the number of people clicking on it.

So last summer we changed this and took the homepage sections with the extra content that were a bit hidden behind tabs and stacked them vertically on the page. As predicted by our research, this doubled the number of people clicking on that content.

Using Radio 2’s homepage as an example, it went from looking like this:

To looking like this:

We then asked ourselves what else we could do to make the network homepages even better at showing people all the great content we have for them. We came up with two things: the first was to design the sections of the homepage so that it’s a lot clearer what’s in them. If you’ve been watching closely you may have noticed that many of the homepage sections have already been changed to the new design. The second was to compress the top section where people click to listen live so that there’s more space to see the other things on offer.

The top section now includes a schedule which can be scrolled back to listen to a programme from earlier in the day or scrolled forward to see what is coming up. We tested this with some users and it went down well. All our radio stations have the same basic layout but our teams can now easily prioritise which sets of content they highlight on the page and in what order.

Again, looking at Radio 2, the top section has gone from looking like this:

To looking like this:

This new layout makes our pages more effective across the range of screen sizes and devices that people use.

The most significant changes are to the Radio 1 and 1Xtra homepages. They’ve been different from all the other radio stations since we launched their current homepages in late 2011. Those designs have served Radio 1 and 1Xtra well but after five years we have now found a better way to help users find all the amazing programmes, clips and videos that those two stations create.

Taking 1Xtra as the example, it will go from its current look:

To this new look:

We’re releasing this work in two parts. Firstly we changed the top section today on all radio stations apart from Radio 1 and 1Xtra. Once we’re happy that it’s worked well we’ll change the Radio 1 and 1Xtra homepages to their brand new layout.

As ever, we’d like to hear your feedback.

We knew from research and from developing the BBC iPlayer website for children that parents really value having a version of iPlayer that’s guaranteed to be free of programming aimed at adults and that kids love a version of iPlayer that’s designed specially with them in mind. We also knew that parents and kids alike wanted the great features of the BBC iPlayer mobile app in a child-friendly environment - features like downloads, the saviour of many a long car journey.

Rather than create separate BBC iPlayer apps for CBeebies (which is aimed at children aged 0-6) and CBBC (which is aimed at 6-12 year olds), we decided to create a single app that enables kids to tell the app their age and instantly be presented with content curated specially for their age group. So 6 year olds are able to enjoy a mix of CBeebies and CBBC programmes without having to switch between two different apps.

With support for up to four profiles, we’ve made it easy for siblings to use the app on a shared device, entering their name and picking a character to denote their profile.

In addition to the profile switcher and the age-curated home screen, there’s a Shows area with full A-Z lists of all CBeebies and CBBC programmes available to watch (1,700+ episodes at the time of writing).

And the all-important Downloads area, providing easy access to programmes downloaded to watch offline.

There’s also a search option for kids who know exactly what they’re looking for, which automatically filters out CBBC programmes for children under 5.

We’ve also invested in making BBC iPlayer Kids accessible, with universal subtitles and a new toggle on the episode page to make it easy to switch to and from signed and audio described versions where available.

As all programmes in BBC iPlayer Kids are suitable for children, there’s no need for a Parental Guidance Lock as found on grown-up BBC iPlayer, however all app Settings (e.g. disabling downloads, enabling higher quality downloads) and links out of the app, are tucked away behind a Safety Lock.

We’ve got lots more planned for the BBC iPlayer Kids app but couldn’t wait any longer to share it and start hearing your feedback.

BBC iPlayer Kids is available to download now for phones and tablets from the Amazon, Apple and Google Play app stores.

We know that more and more of you are coming to BBC iPlayer to browse and find something to watch, rather than with a specific programme in mind. The range of content to choose from has also expanded over time with BBC iPlayer Exclusives, a range of specially picked content from the archives and 30 day availability for most programmes.

In this context, when you stumble across something new that looks interesting or sounds like you might enjoy it, adding that to your 'Favourite' TV programmes can feel like quite a commitment. After all, you probably haven’t watched it yet. 'Adding' is a more casual activity; just a way to make a quick note of a show you fancy but maybe don’t have time to watch right now.

When you 'Add' a programme, we’ll pop it in your Added list in My Programmes with details of the latest episode and a quick link to all the available episodes. You can still Add shows you know and love (your Favourites) if you want so that you have them to hand; but you also can use it to flag new things you might want to try.

More people than ever have smartphones and tablets, so you’re watching iPlayer in more and more ways. To help with this we’ll be storing your list of Added programmes in the cloud, linked to your BBC iD. This means you’ll now need to be signed in to 'Add' shows or see your Added list in My Programmes, but when you do you get a single, synchronised list of programmes you’ve 'Added' across any computer, mobile and tablet.

Storing your Added list in the cloud against your BBC iD also allows us to simplify our codebases. Maintaining two ways of storing the data (locally in the web browser/app and against your BBC iD) meant we had two completely different mechanisms for adding, removing and listing favourites across code for web, iOS and Android - now we only have one per platform.

We’ve had a Favourites feature in BBC iPlayer since mid-2010 but it has always remained a niche area of the product with only 3% of weekly app users and under 0.5% of weekly web browsers visiting the Favourites page. And most users don’t have many favourites in their list: even including programmes no longer available, half of all the times the Favourites page is loaded there are 20 programmes or fewer in the users’ list.

We think the changes outlined above make it more useful for more people. But if you were one of our Favourites users before don’t worry – all your Favourites will still be there in your Added list. And if you’ve been using Favourites without a BBC iD account, just register (it only takes a moment) and we’ll migrate all your Favourites across to your account. And with other personalised features including the Watching list and personalised recommendations there are more reasons than ever to sign in to BBC iD.

Please try the new Added list and let me know how you find it in the comments below.