iBroadcast: An easy way to publish AV content for the BBC

I'm Matthew Browning and among other things I'm executive product manager for BBC Future Media's Media Tools group.

Among the millions of daily visitors to bbc.co.uk how many stop to consider where the programmes, news and live coverage they are enjoying actually come from? This is where my team come in.

At the end of 2009, perhaps a little jaded from having been a technical lead on the first two versions of BBC iPlayer, I began to look after a team of four who were experimenting on the edges of iPlayer publishing.

We wanted to figure out how BBC desktop users might publish their AV content (clips and videos) onto the bbc.co.uk platform outside of the automated systems that had swelled to support iPlayer.

Previously online video had meant sourcing and encoding content yourself to whatever format seemed appropriate and getting a handy local web developer to help add it to your site.

We pieced together a funky-looking web application we called 'iBroadcast' (like 'iPlayer' - get it?) that acted as a kind of 'YouTube for the BBC'. That is to say it published video content for streaming through the BBC's Embedded Media Player outside of the broadcast schedule.

We worked with the producers of the BBC Comedy and Nature sites both of which had a significant requirement to publish off-schedule video such as previews of the latest comedy talent or fascinating footage from the Natural History Unit.

I'm willing to confess that I did not at that stage predict just how useful or popular our little app would prove to be.

Word soon got around to various pockets of the BBC that you could now publish your video without encoding hassles or the need for a web developer and a year later iBroadcast had over a thousand internal users who were now able to add long-term value to their programmes’ online offering.

It wasn't long before radio editors wanted a piece of the action. We made some simple updates to include transcode of audio material while at the same time expanding our range of outputs to extend beyond the PC experience , for example into IPTV products.

We also started to use iBroadcast officially to fill-in areas of the iPlayer schedule missing from automated workflows notably our Welsh television content, hand-published by the scheduling team in Cardiff.

We figured out how to hook our content into BBC iStats giving editors the opportunity, for the first time, to track traffic or views of their stuff. We published availability of our stuff in XML feeds, allowing automatic updates of our users’ web sites.

iBroadcast was cool but it was not without its problems. It became clear as requirements came flooding in that in focusing on short-form publishing we'd excluded the possibility of using the platform for anything else.

With iBroadcast’s roots in prototyping and hackery it was pretty far off-strategy for the BBC technology-wise. The infrastructure that we'd begged, borrowed and stolen from other BBC products was starting to creak under the strain of the relentless punishment from our editorial colleagues.

It was time for a rethink. We knew we were working in a space that was only going to grow. With the help of a number of much cleverer people at the BBC I worked-up the strategy we live by today.

This meant, firstly, that our publishing tools should be developed with the same care and respect we would have for any other BBC product.

Secondly, a single supported platform should emerge to subsume all the existing, ad-hoc publishing solutions that had popped up around the organisation.

Finally, we were to broaden our vision to include all media-publishing requirements of the BBC.

The Autumn of 2011 saw the first release of iBroadcast 2. I yearned to change the corny name but the brand had so much approval among its users that it would have been madness to do so.

An engineer at heart, I'm deeply conscious of the second-system effect and I wanted to be sure that we weren't giving birth to a monster.

I did this by being ruthlessly clear that we were a media publishing solution, nothing else, and by espousing the principle of general utility in everything that we do before catering to the requirements of a specific BBC product.

iBroadcast 2.x was a re-think in terms of architecture as well as vision. We started to talk about building a product that was 'sexy' and after a while people stopped laughing at us.

We ensured a clear separation of concerns by delegating heavy-lifting and workflow management to a service layer capable of acting independently of the client.

The client itself is a PHP/Zend application mediating between service and user. While we've maintained a focus on accessibility for our users a modern-feeling usability is achieved through JQuery enhancements.

Our latest release is particularly exciting in that we address scalability and transcode speed by delegating our transcode and distribution to dedicated Cloud-based services.

This allows us to cope with more customers while dedicating computing power to the faster turn-around of submissions.

The multi-disciplinary Media Tools team of today has seats for twenty five people (we're hiring - get in touch if you want to join us) and maintains a product that manages all AV and image publishing at the BBC including catch-up.

We also provide tools to schedule and publish live events. If you watched any of the Olympic 2012 coverage you were enjoying our work.

We provided software that enabled the selection and scheduling of twenty four streams of live coverage as well as the editorial metadata needed to make sense of it.

Every BBC destination is now, to some extent, dependent on iBroadcast 2.x and we're a key ingredient for online propositions.

Matthew Browning is executive product manager for BBC Media Tools group, Future Media.