NihAV: even more Bink2 support!

After managing to decode the first frame of KB2g variant I had three options: try to decode the other frames, try to decode other variants or do nothing. While the third option is the most appealing and the first option is the most logical, I stuck with the second one. So now I can decode the first frame of KB2f variant of Bink2 as well. Unfortunately the only (partial) KB2a sample I know is not supported, probably it’s a beta version that was tried on one game like Bink version b. Beside a small surprise in one place bitstream decoding was rather simple. Inter-frame support should not be that hard but it might get messy because of the DC and MV prediction.

And while talking about REing Bink I should mention that I’ve tried Ghidra while doing KB2f work. It is a nice tool that sucks in some places (not having a good highlight for variables, decompiling SIMD code results in very questionable output, the system being Java-based and requiring recent JDK—that’s the worst issue really) it works and produces decent results (including the decompiler). Also since it has 16-bit decompiler support maybe I’ll manage to figure out how those clips in Monty Python & the Quest for the Holy Grail are stored.

I should start documenting it too.

Insignificant update: okay, now it decodes inter-frame data correctly too and the only thing left is to make it reconstruct them correctly. Also I’ve updated codec information on Multimedia Wiki. Actually now it works quite okay so I’m not going to pursue it further. I have no real interest in Bink2 decoding after all.

4 Responses to “NihAV: even more Bink2 support!”

  1. Paul says:

    There is decompiler for 16-bit? Great! Looks like it have some issues with ARBC.DRV, some functions are unreachable.
    Decompiler output is “better” (more readable) than other alternatives, except in points you mentioned.
    I failed to find all issues in old bink2 parsing code (maybe I really suck at this), so I’m awaiting new updates on wiki.

  2. Kostya says:

    The decompiler works for all kinds of instructions including 16-bit (I tested it on some 16-bit decoder to check). It sucks on switch analysis a lot though (but IDA does too).

    As for Bink2f, it reads additional bits for DCs of the top left block (since it’s done after other cases it’s not surprising I missed that after glancing through other prediction cases). Again, I’ll try to document it (maybe even this weekend).

  3. Peter says:

    Awesome work. On Ghidra, how is the struct editor working for you?

  4. Kostya says:

    It works (either by auto-defining structure in decompiler or adding it in data type manager) but I had no reason to add anything but bit reader context. Also the interface reminds me of old RDBMS.