Frequently asked questions

Dirac was originally developed at BBC Research at Kingswood Warren in the UK. The BBC have specialists in compression technology, and have been working on digital television and its ramifications since the 1960s.

Within the BBC, the project leader is Tim Borer, and Thomas Davies is the guru who understands the algorithm in more depth than most. The software is managed by Anu Suraparaju. Today, Peter Bleackley and David Flynn are looking at some of the hardware aspects of the system. In the recent past, Andrew Kennedy, Michael Prior-Jones, Chris Bowley and others have all been involved in the project. Pete Shelswell was the senior line manager, and more recently acted as editor in chief for the documentation before his retirement.

BBC R&D has always been involved in video coding research as it's central to what the BBC does.

Thomas began experimenting with compression techniques in about 2001. The ideas were originally developed as part of an idea to deliver high definition services as a layered addition to conventional MPEG-2 broadcasts. As with most similar proposals, he did not manage to achieve any real benefit from linking the standard definition and high definition coding, but the algorithm he used was pretty efficient in isolation. It was the foundation of Dirac.

Dirac is named after the British physicist (of Swiss extraction) Paul Dirac, who was one of the great figures in modern physics. We've seen some good explanations on the 'net, suggesting that we chose the name because the Dirac delta function is fundamental to signal processing and that Dirac's work underpins wavelets. Sorry, but the stories aren't true. We thought of hundreds of names, most of them awful, some of them good, but most of the good ones had been used already. Tim suggested Dirac. It sounded good. It stuck. It was going to be called Camel, so maybe we had a lucky escape.

The BBC has always advocated open standards, and has tried to use them where possible. So far, streaming has been dominated by proprietary systems and existing licensing regimes for standards-based systems have not been as attractive as they might be for large-scale broadcasting, particularly for Public Service broadcasters.

Dirac is released under the Mozilla triple license (MPL). This is an Open Source license that allows both free and commercial use of the software. It also allows for relicensing under the GPL or the LGPL.

No. The terms of the MPL mean that as far as the BBC is concerned, there will be no charges or royalties for the Dirac software.

Yes. We have patent applications in train for some of the techniques involved in Dirac, and others that we intend to put into Dirac in the future. There has been some FUD about this, so we'll be clear: this does not affect the Open Source status of Dirac, nor does it affect its royalty-free status. The conditions of the MPL mean that we're licensing these patents for use within the Dirac software for free.

The short answer is that we don't know for certain, but we don't think so.

We haven't employed armies of lawyers to trawl through the tens of thousands of video compression techniques. That's not the way to invent a successful algorithm. Instead we've tried to use techniques of long standing in novel ways. Where we think we're novel, we're in the process of getting patent protection ourselves, which will invalidate others' claims of priority.

There are some areas that are more heavily patented than others. Arithmetic coding is one such, even though the technique itself has been around for 25 years. We're keeping an eye on the situation, and we'll adopt alternative techniques if we have to. Some of the recent changes in the algorithm have centred on the arithmetic coding - taking it away from some of the minefields of prior art that we have uncovered.

Code round them, first and foremost. There are many alternative techniques to each of the technologies used within Dirac.

Dirac is relatively modular (which is one reason why it's a conventional hybrid codec rather than, say, 3D wavelets) so removing or adding tools was relatively easy.

Now we are close to a version 1.0. and the bytestream and decoder functionality are fixed, we have to be a little more careful. Products are about to come to market and we want to ensure that they have a useful lifetime. Future changes are likely to be few and backwards compatible.

A good question. Now we are close to a version 1.0, the BBC has the opportunity to adopt Dirac for operational use. We have real-time decoding, integration with players, a bytestream spec and a choice of transport stream formats.

What we need to deliver next is hardware which can be used live for encoding - without that, there is a problem delivering streaming video at the volumes that the BBC would expect.

Broadcasting or multicasting over the web is likely to develop over the next few years, and the technology we use for this is likely to be the same as for standard streaming. There is no likelihood at all of replacing our existing Digital TV infrastructure, based on European DVB standards and using MPEG-2, with anything new - the installed base of millions of customers is too large.

Theora is coming on very nicely, and has an impressive, well-defined spec. We think we have much better compression performance, but you can't have too many free codecs. The Open Source community needs to continue to develop codecs with increasingly better performance. Theora has helped create a pool of Open Source compression experts, which is of benefit to everyone in the field.

We intend to pack the Dirac elementary stream into MXF, which has lots of useful features. That doesn't preclude it packing into Ogg (or Matroska, or anything else) as well, and it's probably a good idea to have a variety of packing formats. For this the elementary stream needs to be very well defined.

We chose wavelets for a number of reasons. They perform very well in still image compression, and can be said to be state of the art there. They also provide a degree of scalability, so a codec based on wavelets can perform well across a range of video standards. By scalability we don't mean embedded bitstreams or the ability to extract lower-resolution video from higher-resolution bitstreams - Dirac doesn't do this as it's very complex - only the flexibility to apply the same tools to a range of resolutions, perhaps with different parameters. Wavelet coding is also a well-studied and well-understood field.

Overlapped block motion compensation is used to reduce blockiness and ease the job of the wavelet transform in coding motion compensated differences. The wavelet transform may not be the best tool to do this, and we'd welcome other contributions, but it does have the benefit of simplicity in that the tools for all frame types are the same. Dirac supports more or less any block sizes for motion compensation and this again helps in scaling the algorithms as larger blocks can be used for higher resolution pictures and smaller ones for low resolution pictures.

We have a DirectShow filter which you can download, and a patch for MPlayer.

There are also software decoders - see the SourceForge and Schrödinger web sites.

You can use the encoder directly, using raw video in planar YUV format. Or you can download and install the patches for ffmpeg or transcode and use those.

There's still a lot to do. We need optimisation work for the encoder and decoder - the encoder in particular will always benefit from speeding up. We also need to integrate tools like global motion, and optimise other tools. Another thing we lack is a buffer model and constant bit-rate encoding.

It depends what you mean by ready.

We already have a specification that can be used for real. We can code in non-real time in software, and for many application real-time decoding is now feasible. What we have not yet delivered is real hardware coders for main-stream use. That is the next phase of the project.