[L33THAK0R]

Originally Posted by elit

I dont know if this is known already, but someone released bink 2 encoder on github:
https://github.com/marcussacana/Bink2
Here are the files:
Attachment 31912

and here is proof of concept I just tested:

Attachment 31913

Also read this:
https://github.com/marcussacana/Bink2/issues/1

PS(You don't need those dll's to encode, only for game to play, but only 32bit were provided.)

Firstly the "n" revision of the Bink2 encoder has been available for a while now

Unfortunately the current encoding suite isn't all that useful (for now) for re-encoding FMVs in titles that utilise older Bink 2 revisions, since the "i" iteration (by far the most common revision) and older revisions, uses a substantially different video codec (v2.0 - v2.2), compared to the "j", and current revision "n", making re-coding a given input with the current revision ("n") and switching out the 0x04 byte for a revision code-letter (that predates the "j" revision) a fruitless endeavor as decoding will fail in a spectacular fashion (seriously make sure to turn down your volume and avoid if prone to seizures from flashing lights).

Currently we're only able to successfully re-code videos for titles that utilise the "j" or "n" revision, OR in some cases update the ".dll" to accept the newer encoded outputs.

This is currently limited to engines/titles that don't require custom functions to be called, and I've only had limited success so far with a handful of Unity titles.

This may not be a permanent hurdle however, as if someone who is well-versed enough in reverse-engineering and modifying ".dll" libraries comes along we may be able to have a higher rate of compatibility.

I do know of a handful of individuals who may know of a means to process and encode videos natively under the "i" revision, however due to a series of factors, including my over-excitement at having found such a case, as well as a challenging of these users' egos', further communication, at least with myself, is not possible. As I was not able to form a substantial correspondence it's still unclear if a legitimate methodology has been figured out, if an earlier leaked build of the encoder was obtained, or if something else entirely had happened.

The only real leaked version of the SDK I've been able to find is the 1.9c version, but as you may have guessed this isn't too useful given it's not a 2.0 or 2.2 release (attached below for the curious).