麻豆约拍

Following on from James East’s recent announcement of a  allowing users to access content on 麻豆约拍 iPlayer, Software Engineer Lloyd Wallis provides some more technical details about the player, and explains what his team hopes to get out of the trial.

The 麻豆约拍 has been providing media content online for almost 20 years. We started with Real Media and evolved through Windows Media, progressive downloads, and RTMP in Flash - they were all the right choice when we shipped them.

Times change though, and new lower cost and better performance options arrive. For example, RTMP, Real Media and Windows Media all require dedicated servers, and progressive downloads can’t adapt to network conditions, which leads to users downloading more than they need or being interrupted by buffering.

Chunked HTTP

The distribution method prefered today is chunked HTTP delivery. This involves splitting up the content into multiple small files - each a few seconds in length - and downloading them one at a time. We have used this to deliver our live streams since the 2012 Olympic Games and when and in-house packaging, chunked HTTP delivery replaced RTMP to become the primary way to deliver content on iPlayer.

It provides several advantages over previous methods:

• Adaptive Bitrate (ABR) - for each chunk of content, the client can decide that the bitrate should be changed. For example, if an 8 second chunk took 10 seconds to download, the client can choose to switch down to a lower bitrate, to reduce the need to buffer.

• Caching - by using HTTP to deliver, only standard servers are needed to serve the content, so CDNs and ISP corporate caches can all help to distribute the load, and browsers can cache the chunks.

• Seeking - progressive streams have some capability of seeking if the content is encoded right and the server distributing it understands and handles Content-Range HTTP headers which are often not cacheable. With chunked streaming, the client just needs to download the chunk for the appropriate time, thus making seeking faster and more reliable.

• Live rewind - without servers having to negotiate times and maintain connections, it’s easy to provide a rewind window. We provide two hours of rewind for video simulcast, and three hours for audio simulcast.

History of the Standard Media Player (SMP)

SMP was born as part of the 麻豆约拍’s post-Olympics plan. For London 2012, the was created where you could watch up to 24 live streams from the Games. After the Olympics, we reused the core playback component and added a new user interface that met the needs of all our products across the entire 麻豆约拍 website. You can read more about the in a previous post.

The key goal for Standard Media Player has been to ensure that 麻豆约拍 product teams such as iPlayer and News don’t need to think about where and how media can be played, but to ask the SMP to play a piece of content, and SMP plays it. Simply put, all production teams need to do is upload their finished file into one of the 麻豆约拍’s media publishing tools which will generate a content identifier. Then, product developers can just pass in the identifier of the programme that they want to play, and SMP will do the rest - pick the right player, and provide the most appropriate experience.

As well as the technology required for playback, we also have a huge range of different user desires and use cases to support. For example, some of our users never watch the video of a TV show, but just have it playing away in a background tab in their browser to enjoy the sound. Delivering HD video in this scenario just doesn’t make sense - it would be a big waste of distribution costs and bandwidth - so here we deliver the lowest quality video available whilst the tab is inactive.

Some users watch content in small windows in the corner of their screen as they work, some have an HD TV connected to their computer for a lean back experience. Others have a cap on their bandwidth and want to limit the amount they download. There are also those users with an old computer, or even a new computer with poor video drivers, or just one that’s busy doing other things.

People’s internet connections also differ considerably, and increasingly we know that connections are shared out between multiple connected devices in the home, with each device competing for the bandwidth required to get the content they want. Reliable playback without seeing the dreaded buffer spinner is our biggest goal, but this needs to be balanced with giving the best possible quality.

Why MPEG-DASH?

MPEG-DASH is an international standard created in conjunction with a range of broadcasters and internet organisations, including . By having a single streaming method that we can play back across computers, mobile devices, TVs, consoles and even fridges, we can reduce the variations of content that we have to produce, store and distribute, all of which saves money and allows us to improve quality.

Content in MPEG-DASH can also have a concept of “Adaptation Sets”, which can include multiple audio and video streams, so we have the ability to provide videos with different languages, channel configurations (surround sound anyone?) or accessibility data all using just one video stream, further improving the caching potential of our content. You could also have multiple video streams tagged with different roles - a football match could have goal-side cameras that the user can choose to switch to without the audio being interrupted.

These separate streams also allow us to apply different ABR rules to the audio and video. If you’re watching a set from 麻豆约拍 Radio 1’s Big Weekend, but the browser window is in the background, then we could switch to a lower bitrate for the video, while still providing very high quality audio - something we can’t currently offer with other formats.

The HTML5 Player beta

As you likely know, we’ve opened our HTML5 player out to get useful feedback from your experiences when we deliver DASH content. Whilst you are watching content, the player “phones home” with anonymous info events, just like our Flash player does, so that we can compare performance, which when combined with CDN logs, give us an insight into how our player is performing in various conditions.

When developing the player, we have a tool called DIETER (affectionately named after our Project Manager, or Dynamic Indicative Exploratory Tool for Experience Reporting if you prefer), which provides a visual representation of the experience the player is delivering. But stats don’t tell us as much as we’d like - there’s a lot of things you can’t see without actually watching the content.

Another complexity we face is the huge variety of devices and runtimes now decoding and playing back video and audio content. Before, we only had to worry about the Flash runtime, so we had a pretty good idea what would happen on any machine, and didn’t have to worry about whether that would change if you used a different browser. Now that we’re moving to a HTML5 space, it’s a much more complicated world for us to manage.

Here’s some questions that might help guide your feedback, but we’re interested in anything you want to tell us about your experience:

• Does the video stutter, jump, tear? What are the differences to watching with the Flash player if you watch the same content - do you get the same quality? You can right click or three finger tap the video to see what bitrate we are offering.

• Is the audio staying in sync with the video? Do you hear any pops or squeaks?

• Are you able to seek around the content smoothly, and watch it all the way through without much buffering or the player failing? Do you notice the quality of the stream constantly getting better or worse, or does it stay the same?

• Was there a way you interacted with the player that caused it to respond in a way that you didn’t expect?

If you do get in touch, please tell us as much about your device as possible, and at least the versions of your operating system and browser. You can either comment on this post, or send your feedback to mediaplayer@bbc.co.uk - although we may not respond to all comments, we do value every comment sent.

Are you planning to add support for Safari on Mac OS X?

Safari on Mac OS X doesn’t support AVC3 via its Media Source Extensions implementation. It does, however, support HLS, and whilst we could offer HLS streams to Mac OS X Safari users (some of you have noticed that you can pretend to be an iPad and you get a working player) we’ve deliberately not enabled it during the trial. Why?

Well, we already know how to distribute and play HLS, as we do it today for iOS, BlackBerry, Windows Mobile and some TVs. However we can’t support options such as “Watch in HD”, “Lower Bandwidth” or other bandwidth saving features via HLS without a big investment - if at all - and ongoing increased costs just for one OS/browser combination is not something we want to do. When we make live streams available for testing, Safari’s HLS is further limited as it doesn’t currently support Live Rewind, a killer feature for many of our users.

To remove those options from Safari for the trial would have required the iPlayer team to disable some functionality on their website that is available with our existing streams or DASH. Our other alternative would have been having to delay the trial even longer, meaning it would take longer before we could get your feedback, and longer before we can move to HTML5 by default.

Firefox

We’ve also seen some feedback about support for Firefox on operating systems other than Windows and Mac OS X. Some features that we require are disabled by default for Firefox on these operating systems, primarily due to there being no decoder for our streams available for Firefox to use; on Windows and Mac OS X the H.264 and AAC decoders are provided by the operating system. We hope that will change in future, but until then our trial will not work out of the box in these environments.

This is just the start

Building a reliable player that offers the best possible playback quality is not an easy thing to do. The ever-changing landscape of browser support makes this even more challenging.

Right now we’re focusing on getting feedback about how our DASH streams are performing in real-world scenarios across the wide range of browsers and devices that we know you use. We’ll use this knowledge to refine the playback experience.

Having this insight will allow us to make the most appropriate improvements, for example:

• Improving the ABR rules to reduce buffering

• Improving the delay before we start playing, the time we take to get to the best quality, the delay between different items

• More seamless recovery from errors, or network problems

• Working closely with 麻豆约拍 R&D to offer enhanced subtitles that truly make the most of today’s technology (our current subtitles implementation is largely still based around the restrictions from TVs when subtitles were first broadcast in 1979)

As well as improving core playback, we’ll be working to enhance existing features and introduce new functionality. As ever, we welcome your feedback through comments on this blog post or at mediaplayer@bbc.co.uk.