John Peel, Centre for Creative Arts: an example of a virtual view on the BBC archive

In my role as the BBC's Chief Technical Architect I try to ensure that we can make the best possible use of the latest digital tools and technologies in order to serve our audiences.

That means working with both programme-makers and programmers on internal systems that may never be seen by members of the public, but which are key to our activities - such as the Development Platform or the Digital Media Initiative.

It’s a privileged position, as it lets me see how all aspects of the BBC operate, and offers a unique insight into the creative processes that result in the amazing television and radio shows and online services that audiences treasure.

One of those resources is the BBC’s own archive, which I see used in so many programmes and websites. It is an enormous collection of building blocks for creativity , and it has been used for many years by programme makers inside and outside the BBC to provide inspiration and material.

For some time now I’ve been part of the team driving a move to digital storage and distribution for the archive, and I can see clearly that this creates entirely new opportunities for making the BBC’s history more widely available – where we have the rights to do so – as well as new ways to use it for public benefit.

What is the archive?

If you think about the archive at all you probably think of it as something like a library, with a well-ordered collection of polished and finished works that has every episode of Dr.Who, every Prom and the DVD Box set of Frozen Planet.

While the BBC does indeed have ranks of videocassettes and DVDs all carefully catalogued and kept on shelves in our Perivale Archive Centre, and even has shops both on-line and at some physical sites, the archive is far more than that.

For one thing, it’s a lot more than just television and radio. The BBC archive has twice as many pieces of sheet music and twice as many photographs than we've got pieces of video and film. That is because my colleagues and I in the BBC Archive team believe that one of the archive’s main functions is to help people create new things.

If you want to make something new then you don’t want access to finished, polished and shrink wrapped DVDs.

Instead you want the gory details, the scripts, the original notes or score of some music, unique clips never used. You want basic building materials; the sound of a train passing, an aerial shot of the Pen-y-fan, a shot of a late 19th century gas light being lit. You want the raw building blocks, and as more and more artists get comfortable with digital technology offering the ability to merge footage and to recreate scenes in 3D, this need only increases.

Today the BBC supplies raw materials like these to anyone in the industry through Motion Gallery, which works well for large professional outfits who are primarily focused on creating what those working in the broadcasting world call "linear content" - traditional TV consisting of a single piece of continuous video played to large well defined audiences.

Digital technology and the Internet is changing that.

How demands on the BBC Archive are changing

Experiences on-line and in games are no longer linear.

Augmented reality and modern films call for access to information at a much more granular level.

And the stories told with these resources are not necessarily aimed at an entire well defined audience anymore, as the internet both fragments viewing and creates new opportunities to bring people together.

This poses a lot of challenges, not least when it comes to providing easy access for this sort of volume of material. We don’t want to go about creating the on-line equivalent of a 'tape' (where we pre- and post-fix the video with 90 seconds of black, two frames of pure white, a nice countdown timer, colour bars, test-tones and what not [PDF]) even though that is how it has been done for television clips in the past.

How do we deal with rights, when agreements almost always have assumed you would 'air' an entire episode to a nation?

And, most of all, how do you deal with provenance, so you can later recognise that the period castle used as the background three minutes 'in' was in fact derived from something else?

At the BBC the Archive Development team has been thinking about this for a long time, and I’ve been lucky enough to be part of their discussions. Some of the work has led to the idea of a Digital Public Space, while my colleagues in the BBC Archive and I have started on the cataloguing and provenance too, as without having proper names and labels for things it is hard to even 'think' about these building blocks.

More recently we've been trying to see what happens if you do this for real, collaborating with Arts Council England to create The Space, a new platform for all types of digital art.

But like most people in the BBC I tend to look at and learn from large organisations, from people used to processes such as 'commissioning' and who by and large produce, or have produced, a 'single final product' like a programme or a website. Their concerns and understanding can be very different from a small game developer, someone with a wonderful business idea for a smartphone app, or a remix artist.

At this year’s Turing Festival in Edinburgh I’m going to spend some time talking with smaller businesses to explore and discuss what new technologies and new business ideas could be fuelled by the archives of the BBC and other cultural institutions.

First on Friday, in a panel titled ‘Mashing up the BBC, Slicing and Dicing UCL’, and then with a more hands on design-jam session on Saturday.

It’s part of a broader BBC initiative, captured in projects like the Connected Studio, for me and my colleagues to understand what is needed in terms of interfaces and catalogues, to explore a path through rights issues and, perhaps most of all, to understand how creators and innovators would like to work with the BBC.

With the help of the new digital tools BBC Future Media can start to think about the archive in a different way, as a collection of assets that can be made available to creators from any sector and any size of company. These are early days, and we are all at the very start of a long journey – so I welcome your comments and contributions

Dirk-Willem van Gulik is the Chief Technical Architect, BBC Future Media

Now the BBC is a very special place to work. And one of the main things which makes it so special is "Quality". At the BBC it is a currency, it is a goal, it is a culture - and as an engineer, it is something you are tasked to deliver.

One of our roles in FM&T is to provide our creative colleagues with tools. The tools they need for broadcast and to create high quality video. This includes tools for "non linear editing" - taking short clips, cutting them to the right length, stringing them together, adding some voice overs and graphics - and then endlessly tuning the resulting video so that it tells a story perfectly.

Usually we shoot hundreds of hours of video, import it onto an editing server, painstakingly tagging or "logging" the content on the way, and then edit each clip into something that makes sense. Because the original video files are so huge (especially in HD), we actually edit low resolution "proxy" versions of each file, and we store edit decisions using timecodes rather than actually mashing up the real video all the time. Then everything can be synced up and "conformed" using the original high-quality versions later on.

Throughout all of this, timecodes play a major role. They are the key 'link' to get right. They ensure that recipes done on the proxy give identical (albeit at a higher resolution) results when repeated on the raw high resolution footage at the end. They ensure that the audio tracks are perfectly synchronized with the clips, that transitions start and end at exactly the right time (and there is not some extra black frame due to a rounding error). They are also important in the creative process - as they let us communicate. We can ask each other to look at a specific frame - or discuss whether we move a cut by a few frames to achieve a particular effect.

If this sounds a bit overly perfectionistic and artistic - then consider this - a cut every 3 seconds or so is quite normal. So if you are off by 1 frame either way - then we're already talking errors of over 2%! Even a very pragmatic engineer would have to agree that that matters!

So timecodes using exact frame references are important. Really important. And the dirty little secret is that the internet has none. NONE! None of today's open standard technologies, or even the dominant proprietary ones, do timecodes right. They are off by one; they round to the nearest half second, they jump to the nearest previous I-frame. Whatever. (In all fairness - there are highly specialist products one can buy and install, usually with special browser plugins, which are accurate, often provided they are used with specially prepared material and within a single LAN. But none of those are conductive to the 'internet' network effect by facilitating collaboration between creative people across organisational barriers.)

Because the first thing a professional needs is a rock solid way to reference each and every individual frame accurately. So they can talk about it. For us - 'video on the web' is a bit as in James May's programme - today the internet feels like that plastic 1:1 model of a spitfire[9]. It looks like one - but it sure does not fly.

Now over the past two months that landscape has started to radically change. A few of us[1] have been working with the various open standard and open source HTML5 communities. And as of this week, after 120 emails, the bleeding edge development versions of several HTML5 implementations (as used in Safari, Chrome, Mozilla and many others) are now fully frame accurate.

First was WebKit (the basis for Safari, Chrome and several dozen other browsers), which as of revision r77919 has frame accurate playback!

Really. Frame Accurate. Actually even more accurate than just a frame (which is important for audio). You can jump to any point in the video (i.e. 1 hour, 3 minutes, 6 seconds and 5 frames, or to frame 178127) - and it will be exactly at that frame. Not at the nearest i-frame, rounded down to the nearest second, or off by one. No it will be exactly at that very frame.

So today, the HTML5 community has opened a door for us. Which will allow creative people to collaborate and edit professional video on the web.

Do know though that, while key, this is just a first step. There is a lot to still build, so we'll need many hyper creative companies and internet engineers working together to make this work. We need to create a new breed of web based production tools which can interact at the quality levels professionals and the BBC expect. And we still have issues around UMIDs (unique global references for video) to crack. And even some very basic things (like did you know that a pixel in the video world is actually rectangular, rather than square?!) will need to universally understood between the broadcasting and internet engineers. But boy, getting timecodes, that is a big step!

Again - a big thank you to the open source folks of WebKit and Mozilla. IE9 is not quite there - (progress is tracked at https://connect.microsoft.com/IE/feedback/details/636755) but Microsoft has let us know that we "can expect the video-frame-accurate seeking be available when IE9 is final"!

[1] To give credit where credit is due: within the BBC, Raymond Le Gué (programme director at BBC) insisted on having frame accurate playback in the browser. Rob Coenen went on and beyond his call of duty to make this happen, filing bugs - patiently working with the wider developer community, explaining what SMPTE frame counts are, why film and television production cannot live without it, proving that it was not working in browsers and helping the developers to fix it. He got help from Bas Schouten (at Mozilla), Andy Armstrong and Dirk-Willem van Gulik (both at the BBC).

But most credit should go to the open standards and open source communities around Webkit, Chrome and Mozilla which made it happen: Andrew Scherkus and the Chromium team get credit for being the first to understand the significance. The actual fixes where ultimately created by Jer Noble, Eric Carlson (both at Apple) and Chrome developer Andrew Scherkus; while Matthew Gregan and Anthony Hughes did the job for Mozilla.

Dirk-Willem van Gulik is Chief Architect, BBC Future Media & Tecnology

SMPTE timecode based and frame accurate metadata logging is now possible over the web with HTML5. The image above is a made up screen shot of what a prototype tool to do this might look like.