Interview: Bink 2

Before we tackle the intricacies of Bink 2 specifically, why do you think Bink has become such a standard in the realm of video codec for games? What is its appeal?
I think it’s a combination of things. The API is the right way to play video, so it’s not only easy to integrate, but easy to do crazy stuff with – like compressed textures or whatever. We like to say it feels like a codec that you wrote yourself.

But there are lots of other things that make it nice for games – it’s super fast, it’s self-contained in that you don’t need any other frameworks, and it’s super easy to licence.

And is there an overall theme or direction that shaped the way you designed and developed Bink 2?
Yes. The big direction in Bink to was to design a codec that is what I like to call ‘natively SIMD’. Nowadays, even my phone has powerful SIMD instructions, so we tried to build a codec that was built around this capability, instead of tacked on as an optimisation pass later.

One example would be that the pixel blocks themselves are swizzled inside Bink 2, so that we can decode multiple neighboring DCT blocks simultaneously, without having to re-arrange the data in any way first. Nicely, this not only gets you the ‘SIMD-ification’, but also allows you to convert way more code into SIMD, since you aren’t converting or optimising an algorithm.

Instead, you are just converting data types. As an example, our iDCT looks like a normal scalar iDCT – it just operates on SIMD data types instead of scalar ones.

The other big design goal was a video codec that could be pixel shader/computer shader accelerated. This will be coming over the next year – I’m really excited about it. Maybe we can talk again in six months.

Looking at the numbers Bink 2 is remarkably powerful compared to its predecessor. How will that impact the developers that use it?
Well, obviously, you are going to have much nicer looking video. But I think the bigger impact is going to be much higher video resolution. The new high-pixel density displays on PCs and Macs, and 3D video on the consoles are all going to demand a lot more pixels running through your video path.

Why was now the right time for a full update to Bink?
Well, we started about three years ago and really cranked on it through 2012 – the big thing that we wanted to be ready for was the next generation of consoles and tablets. Lots of pixels, lots of SIMD, lots of GPU – we wanted to take advantage of all of it.

Bink 2 was written with an SIMD design. What does that mean in terms of the impact it will have on games developers embracing Bink 2?
It should all be invisible to them technology-wise. Market share-wise, it shouldn’t have a big impact either. Certainly on the PC side, non-SIMD CPUs are pretty much non-existent nowadays. The early non-Neon iOS devices are somewhat of a bother, but most modern games don’t target them anyway, since they don’t have pixel shaders. There is one new console that has no SIMD, but it has a great GPU, so we’ll be able to use that.

Bink is famously fast and cheap on memory. How have you improved those attributes?
Memory use is the same as Bink 1 – one frame to decode into and one frame to motion compensate from. That compares to modern codecs that use up to 16 frames for mo-comp-ing. We actually would get a minor quality win by adding more frames, but in the end, we decided memory was just too valuable.

Bink 2 is usually two-to-three times faster than Bink 1, and in some extreme cases, up to eight times faster. This is just due to the fuller SIMD utilisation and our two core load balancing; Bink 1 was unbalanced – one CPU was usually much busier than the second.

What about Bink’s audio abilities. How have they been expanded for Bink 2?
Bink’s audio is the same for Bink 2 – multi-track, multilingual, 8-to-1 audio, etcetera.

Why is Bink’s two-core scaling particularly significant, again, from an end user point of view?
Well, the big thing is that developers can now use larger videos and stay on the 60 Hz path. Bink 2 won’t be the blocking factor even with high resolution and/or 3D video.

Users who find themselves having to push Bink 2 in favour of smaller file sizes are told they will find their images blur rather than become blocky. Could you give us a little more detail on the potential of the Bink 2 deblocker?
The Bink 2 deblocker is designed specifically for Bink’s encoder. So we use a lot of information about each block to determine how much to blur – or how much not to blur – to its neighbours.

If you are lightly compressed, then it barely runs at all. If you are highly compressed, then it blurs through each block boundary, smoothing each edge. So, perhaps if you are highly constrained – say, on something like the DVD of an Xbox 360 – then you are able to turn up the compressor without introducing blocks.

How multiplatform do you foresee Bink 2 becoming over time?
Right now, we’re on anything x86 or x64, PowerPC and Neon. That’s all of our existing platforms. One of the technologies we built for Bink 2 was a SIMD code generator, so that we can render the source code for different SIMD instruction sets without having to write it all by hand. Basically, what we do is write the algorithms in a scalar high-level fashion, and then generate the raw SIMD code for the various CPUs. This will let us jump to new instruction sets quickly.

Has any of the design of Bink 2 been implemented as a response to a changing games industry and the rise of the smaller studio? If so, how have you made Bink more accessible to such companies?
Not really. We’ve always worked with smaller teams on our licensing – we always try to find a licensing scheme that will work.

Rad Game Tools has already made Bink 2 available. For more information visit: www.radgametools.com

This feature originally appeared in Develop 136, March 2013