BBC Global iPlayer Technical Architect on HTTP Streaming
•Transferir como PPTX, PDF•
0 gostou•477 visualizações
Chris Bowley is a technical architect at the BBC who works on the BBC Global iPlayer. The iPlayer uses HTTP streaming to deliver both live and on-demand video content from edge servers in a way that is cheap to deliver and highly cacheable. It uses adaptive streaming over HTTP and the MPEG-DASH standard to react to current network conditions.
Recomendados
Recomendados
Mais conteúdo relacionado
Mais de QITCOM
Mais de QITCOM (20)
BBC Global iPlayer Technical Architect on HTTP Streaming
- 1. Chris Bowley Technical Architect, BBC Global iPlayer BBC Worldwide
- 7. Video
- 8. HTTP Streaming Origin Edge servers
- 9. Live and on-demand Adaptive Streaming over HTTP Reacts to current conditions Cheap to deliver, highly cachable
- 12. MPEG-DASH
- 13. Origin Edge servers
- 14. Cloud Transcoding Origin Content delivery network
Notas do Editor
- Hello. I’m Chris Bowley from BBC Worldwide, Technical Architect for BBC Global iPlayer.I’m going to talk to you about the Global iPlayer video on demand pilot which launched last summer before looking at challenges we face as we look to roll out across multiple platforms.
- But first I’d like to give you some context about the BBC iPlayer in the United Kingdom.In the UK, BBC iPlayer is primarily a catch-up service, showing content from the last seven days of linear broadcasts on our TV channels and radio stations. It is still one of the leading examples of a broadcaster video on demand service anywhere in the world and it’s currently serving over 150 million requests a month for television and radio content.
- BBC public service is committed to reaching the widest possible audience and as such BBC iPlayeris free at the point of use and available across a wide range of devices including the web, mobile, connected TV and games consoles.I am here to talk to you about Global iPlayer, a commercial video on demand service for our international audience.
- Firstly, a very quick overview of what BBC Worldwide is and who we are. We are, put simply, the commercial arm of the BBC. We exist to generate profits to be reinvested back into the BBC in the UK on behalf of licence payers.We take the best of British television to the world through our channels, digital services, programme sales, DVD business and other outlets.We operate separately to the public service BBC and as such anything we do with the iPlayer brand would be developed and operated by BBC Worldwide.
- A couple of years ago, we began investigating bringing the BBC iPlayer brand to our international audience. This would provide us with a direct relationship with our customers and the ability to editorially curate content while adding value to the BBC.As such BBC Global iPlayer is a very different proposition to the UK public service iPlayer. Clearly, many of our TV channels don’t exist outside of the UK and so this approach wouldn’t have made sense. We were going to have to mine the BBC’s archive in a different way.
- In July 2011 we launched theBBC Global iPlayerpilot to test commercial viability. Initially oniPad and subsequently to iPhone and iPod touch in December.Global iPlayer is available throughout western Europe, Australia and Canada. We are the commercial arm of the BBC; we’re here to make money and so we weren’t going to give the product away for free. In this phase of the project the app itself is free to download. It does have some free content and we’re charging a monthly subscription to sign up for full access to a further 2000 hours plus of great BBC content.So that gives you a brief introduction to Global iPlayer. I’d now like to talk a little about one of the largest costs involved in launching our pilot: our video content and how we deliver it to our users.
- So this is how we get content to our users: they request to play it and we serve it to them. The costs associated with delivering our content can be broken down into three areas:Transcoding into the appropriate format supported by the clientStorage and delivery of the video filesOperational costs associated with managing this processUnfortunately, different devices support different forms of video streaming. We want to be able to minimise each of these costs while being able to serve the widest possible audience.
- As I have said, GlobaliPlayer is available on Apple’s iOS platform and in order for us to reach the greatest addressable market on iOS devices we need to provide video which can be watched over both wifi and the 3G cellular network. In order to get our app into the App Store we deliver video content using HTTP Live Streaming or HLS as dictated by Apple’s app review guidelines.I’m not going to talk about HLS directly but rather about streaming video over HTTP in general and what this looks like for us.Our video content is stored on our origin servers. We could deliver this directly to our users around the world but the network latency would mean anyone far from our origin server would not get a very good experience. HTTP streaming allows us to make use of cheap edge caches, physically located close to our users. These servers request the video from our origin once and store it so that the user gets a great experience.
- By transcoding video at several different bit rates we can use adaptive streaming which allows the client to choose which quality to use for the current network conditions. Not only does this mean we can give the user the best possible video experience but we can support different device families such as tablet and mobile phone by combining these layers into playlists.[CLICK] As it uses HTTP as the transport mechanism, standard web servers can be used to serve the playlist and video segments and it will not be blocked by firewalls. It allows us to serve and cache our video content in the same way we serve and cache our data feeds.[CLICK] HTTP streaming is suitable for live and on-demand content.[CLICK] The video stream adapts for optimum performance under current network conditions and by combining video layers in playlists we are able to serve devices with different capabilities.
- So here is our video, with a playlist and video segments at each bandwidth. In practice use 8 layers, ranging from an audio-only stream up to a 2 mb/s video stream.The master playlist tells the client which variants are available and we can provide a different master playlist for different devices or when the client is connected over wifi or the 3G cellular network. So here is one place we can reduce cost: delivery costs are often calculated in terms of bandwidth, and providing a video stream at a higher quality than the device requires is costing us money and giving no benefit to the user.
- So, I’ve looked at how we deliver our video to one platform. However, should we move to full service and as we identify additional devices we would like to roll out to, we need to drastically change our video delivery.Apple’s HTTP Live Streaming provides streaming to iOS devices. Adobe’s Dynamic HTTP Streaming supports Flash and Microsoft’s Smooth Streaming supports Windows for example.We can support all of these devices using a form of HTTP streaming. But, as Will Law the a principle architect at Akamai said recently: ‘these technologies are 80% the same but 100% incompatible’. Does that mean we need to transcode our video again for each platform? What are the solutions for multi-platform delivery?
- One solution is the adoption of a standard streaming protocol across all platforms.MPEG-DASH or ‘dynamic adaptive streaming over HTTP’ is a developing ISO standard. Stakeholders include vendors of the current major competing HTTP streaming standards: Apple, Adobe and Microsoft. This is encouraging and we will be closely observing what happens in this space.
- The alternative solution, and the one which we must currently implement if we want to support multiple platforms, is to provide the protocols required by each device and platform. Not only is this likely to increase our transcoding costs, but there is an additional operational cost in managing multiple versions of each video.Remember, each format of video is made up of several layers of segmented video files – that’s a lot of files and the potential for a lot of errors.
- Content delivery networks are already providing solutions to this problem, by moving the video transcoding function into the cloud. This means we need only store a single high quality source file and yet can provide streaming to devices using different technologies. In the future it is proposed that cloud transcoding will be able to happen on request, potentially reducing costs even further.
- Conclusions:So as we move from a single platform to multiple platforms we have to look again at our video delivery.If you want to deliver video content, choose your streaming technology to reduce costs but support as many devices and platforms as you can. Make use of standards if possible.Re-use video profiles through playlists and do not deliver higher quality than the client device can make use of.
- Thanks.