Epic Games has acquired RAD Game Tools so they now own Bink video and more

The good news is that Epic will not be locking it down to their systems

for now.*

I don't think Bink has bright future. Open codecs will eventually replace it, especially with increased effort to support AV1 by all hardware makers.


Last edited by Shmerl on 8 January 2021 at 9:56 am UTC

The good news is that Epic will not be locking it down to their systems

for now.*

Why would they? If EAC and other acquisitions are to go by, they have no interest in locking SDK's and services pertinent to other game engines to their platform because if anything, it helps them. They indirectly benefit from contracts made by RAD and others.

The good news is that Epic will not be locking it down to their systems

for now.*

Yes clearly. Just see what they did with Rocket League : first they dropped Linux support, and then removed the game from Steam...

What I wanted to ask for decades now: Why are game makers using Bink video that much, instead of say MPEG-2 (or whatever was/is available at the respective time)?


Last edited by Eike on 8 January 2021 at 5:40 pm UTC

The good news is that Epic will not be locking it down to their systems

for now.*

I'll give it 6 months. That's how long it took Epic to murder Rocket League IIRC.


Last edited by ElectricPrism on 8 January 2021 at 11:04 am UTC

Why are game makers using Bink video that much, instead of say MPEG-23 (or whatever was/is available at the respective time)?

There's two things that make Bink a prime candidate for video games:

1) The API reportedly very easy and comfortable to use for games. It is, after all, specifically written for games. That alone is already a very good selling point. If you can just drop the library in and hook it up to your rendering code without having to rewrite your own engine, that kind of friction-less support is worth a lot

2) Bink (*) has several optimizations and block types to specifically support videos found in video games. Namely, hard edges you'll find in animated or 3D-rendered graphics. Other general video formats are tuned for real life video captured by a camera, where hard edges and wide stretches of the exact same color are scarce, but gradients and noise that needs to be filtered are frequent

To elaborate point two a bit, you might be familiar with how screenshots, webcomics, etc. shouldn't be saved as JPEGs. The hard edges, also around text, produce artifacts, weird block-like things. That's because JPEG is meant for photographs, not drawings. The same is true for most general video codecs, including the MPEG families.

Of course, newer codecs are more complex with more features, so this isn't that pronounced anymore, but with Bink, drawn and rendered sequences are a main focus, not a distant consideration.


(*) At least Bink 1, which I have read the RE'd ffmpeg sources for. Bink 2 isn't yet in ffmpeg, but it has been RE'd, however I haven't looked at that yet. Too much to do, too little time. But I do expect this point is also true for Bink 2


EDIT: To make it clear, I don't work for RAD nor is this supposed to be an advertisment for them, and they don't pay me. :P


Last edited by DrMcCoy on 8 January 2021 at 11:21 am UTC

So they are building up a monopoly.

Everyone knows what companies like this do, when they have enough power/marketshare. They lock up things to erase competition.

So I consider this bad new not only for Linux gamers.

But in fact it will harm us the most. Openess and freedom are the first things to go down the drain.

The good news is that Epic will not be locking it down to their systems

for now.*

Why would they? If EAC and other acquisitions are to go by, they have no interest in locking SDK's and services pertinent to other game engines to their platform because if anything, it helps them. They indirectly benefit from contracts made by RAD and others.

It looks to me like they are building up an ecosystem, to then lock it down:

1. All tools/assets needed to develop games with big market share are being bought. Or at least influenced as much as possible.

2. Include them in an ecosystem (Unreal Engine as base)

3. Lock it down to Epic Games Store or at least make it hard and expensive to publish somewhere else.

Linux gamers will of course only be collateral damage.

The good news is that Epic will not be locking it down to their systems

for now.*

Why would they? If EAC and other acquisitions are to go by, they have no interest in locking SDK's and services pertinent to other game engines to their platform because if anything, it helps them. They indirectly benefit from contracts made by RAD and others.

It looks to me like they are building up an ecosystem, to then lock it down:

1. All tools/assets needed to develop games with big market share are being bought. Or at least influenced as much as possible.

2. Include them in an ecosystem (Unreal Engine as base)

3. Lock it down to Epic Games Store or at least make it hard and expensive to publish somewhere else.

Linux gamers will of course only be collateral damage.

How would Linux games be collateral, exactly? EAC was (and still does) work on Linux, and there's nothing to suggest otherwise; meanwhile EGS isn't Linux native anyway, so no collateral there either. If anything, they've given Lutris grants to support EGS via their frontend. And Bink Video is so widespread that it'd be financial suicide to keep it locked onto one ecosystem; something they are actively against doing anyway (see their ongoing lawsuit with apple to free up the apple ecosystem). Even Unreal Engine 4/5 is freely useable between launchers, because if it weren't, developers would riot and it would tank the one bit of reputation they seem to care for; their ability to make a good game engine.

Basically, it's not their style to hoard and lockdown developer tools.


Last edited by Dribbleondo on 8 January 2021 at 11:53 am UTC

The good news is that Epic will not be locking it down to their systems

for now.*

Why would they? If EAC and other acquisitions are to go by, they have no interest in locking SDK's and services pertinent to other game engines to their platform because if anything, it helps them. They indirectly benefit from contracts made by RAD and others.

It looks to me like they are building up an ecosystem, to then lock it down:

1. All tools/assets needed to develop games with big market share are being bought. Or at least influenced as much as possible.

2. Include them in an ecosystem (Unreal Engine as base)

3. Lock it down to Epic Games Store or at least make it hard and expensive to publish somewhere else.

Linux gamers will of course only be collateral damage.

In the long long run i think you might be right, but i am also pretty sure that developers using other engines then unreal will be looking for alternatives so in the long long run rad will be forgotten and unreal engine will have it incorperated and other engines will have something else.

I kinda disagree with the mentality that epic games are the 'evil'. Sure you don't have to agree with their business practices, but the truth they are a profit based company like valve, cd project red(gog), etc. And while i hated the decision to remove linux support from rocket league, too. I am sure that the decision was not soley based upon epic games hating linux. Contrary they support many open source projects and give game developers a fair share. Sure thing that's not because they are so generous. And there are many companys (hello valve) i really like because their continuos investment in linux. Doesn't mean we have to start the hate train.

Why are game makers using Bink video that much, instead of say MPEG-23 (or whatever was/is available at the respective time)?

There's two things that make Bink a prime candidate for video games:

1) The API reportedly very easy and comfortable to use for games. It is, after all, specifically written for games. That alone is already a very good selling point. If you can just drop the library in and hook it up to your rendering code without having to rewrite your own engine, that kind of friction-less support is worth a lot

2) Bink (*) has several optimizations and block types to specifically support videos found in video games. Namely, hard edges you'll find in animated or 3D-rendered graphics. Other general video formats are tuned for real life video captured by a camera, where hard edges and wide stretches of the exact same color are scarce, but gradients and noise that needs to be filtered are frequent

To elaborate point two a bit, you might be familiar with how screenshots, webcomics, etc. shouldn't be saved as JPEGs. The hard edges, also around text, produce artifacts, weird block-like things. That's because JPEG is meant for photographs, not drawings. The same is true for most general video codecs, including the MPEG families.

Of course, newer codecs are more complex with more features, so this isn't that pronounced anymore, but with Bink, drawn and rendered sequences are a main focus, not a distant consideration.


(*) At least Bink 1, which I have read the RE'd ffmpeg sources for. Bink 2 isn't yet in ffmpeg, but it has been RE'd, however I haven't looked at that yet. Too much to do, too little time. But I do expect this point is also true for Bink 2


EDIT: To make it clear, I don't work for RAD nor is this supposed to be an advertisment for them, and they don't pay me. :P

Interesting, thank you for the insights. I've also read that Bink video worked really well on processor constrained consoles and that they were able to render video on PS1 with very little CPU usage. I guess its less of an issue today.

I can't say anything about their original SDK. But I follow RAD Game Tools employees on Twitter and they do take pride in optimizing their code very well, low-level, down to optimal CPU pipeline usage, vectorization, etc.

So yeah, that's probably another good point, yes.

That's also one area where the Bink code in ffmpeg is very likely left way behind, just by the nature of specialized decoder for one format vs. broad framework for all kind of codecs. Even moreso for the code I pulled into xoreos from ffmpeg: for once, my bitstream reader and Huffman decoder is not optimized down to that level for the layout Bink uses and I reorganized a lot of it to be readable (I wanted to understand how it works).

"Compulsive buying disorder is frequently comorbid with mood, anxiety, substance abuse and eating disorders. Companies who score highly on compulsive buying scales tend to understand their feelings poorly and have low tolerance for unpleasant psychological states such as negative moods"

Take care Epic. We worry about you.

I am sure that the decision was not soley based upon epic games hating linux.

Hating is not the reason for sure. Perhaps just not caring much.
After all the real money are at Windows and even more Consoles.

2) Bink (*) has several optimizations and block types to specifically support videos found in video games. Namely, hard edges you'll find in animated or 3D-rendered graphics. Other general video formats are tuned for real life video captured by a camera, where hard edges and wide stretches of the exact same color are scarce, but gradients and noise that needs to be filtered are frequent.

As someone who has done quite a bit of work with av1 that codec absolutely excels with 3d renders and animated content. Ofc it’s often limited by the source using yuv420p which makes it literally impossible to create sharp edges that change color, but overall it’s a good way to distribute video if you can be sure your users have a good enough cpu for it (like at least a 4 core ryzen or intel cpu).

Of course, newer codecs are more complex with more features, so this isn't that pronounced anymore, but with Bink, drawn and rendered sequences are a main focus, not a distant consideration.

Do you know if AV1 and whatever they are working on as its successor can address this for games sufficiently good?

As someone who has done quite a bit of work with av1 that codec absolutely excels with 3d renders and animated content. Ofc it’s often limited by the source using yuv420p which makes it literally impossible to create sharp edges that change color, but overall it’s a good way to distribute video if you can be sure your users have a good enough cpu for it (like at least a 4 core ryzen or intel cpu).

Oh, just noticed your response. That answers my question above :) I've seen arguments like "hey, you need Bink because it's so much better and because consoles don't support modern codecs". But I think it's not a good argument if AV1 can handle the same use case and because AOM are pushing for hardware support for it, so I expect even incumbent consoles will have hardware decoding for AV1 (at least eventually).


Last edited by Shmerl on 8 January 2021 at 6:21 pm UTC

Why would they? If EAC and other acquisitions are to go by, they have no interest in locking SDK's and services pertinent to other game engines to their platform because if anything, it helps them. They indirectly benefit from contracts made by RAD and others.

You mean like rocket league?