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

Quoting: einherjar

Quoting: Dribbleondo

Quoting: Breizh

QuoteThe 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.

Quoting: DrMcCoy

Quoting: EikeWhy 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.

Quoting: MordragI 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.

Quoting: DrMcCoy2) 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).

Quoting: DrMcCoyOf 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?

Quoting: natis1As 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

Quoting: DribbleondoWhy 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?