First of all, I’d like to note that those names are taken from Bink code. In reality ‘lossy’ block is used as is and ‘lossless’ block is DCT coefficients.
And now, the differences:
- in ‘lossless’ mode coefficients are decoded until mask becomes zero, there’s no explicit number of coefficients
- coefficient bits are stored explicitly, not as several masks:
coef[x] = mask | get_bits(log2(mask)); - starting list somewhat differs
For those who for some unknown reason are interested in RE progress, I can say that my implementation is still far away from perfect. It crashes on 640×480 BIKi files and for those two files it plays (BIKf and BIKi) it gives barely recognisable image — I blame DCT and dequantisation (I haven’t looked at them yet).
What does “taken from Bink code” mean?
Obviously, I’ve looked how some functions are named in some Bink player. Should I ask RAD Software for sources and permission to relicense them to LGPL?
Well, this *is* Jeff from RAD Game Tools . I was just curious about your choice of terms. If you are REing from binaries, that’s fine. It was probably just poor phrasing that it sounded like you were taking it from source code. It is a bit cheap to be using symbols, though, since the x86 is all there to do it clean.
Engineers tend to be lazy, especially where you can ease your work.
And don’t worry, functions will be named after what they do. Your choosing of names is the same as for algorithms used – not obvious at the first glance.
BTW, why do you code block types as a lot of runs where single “fill with value” would do (and save some bits too)?
> functions will be named after what they do
They actually are named correctly, you just don’t quite understand what’s happening yet, grin.
> why do you code block types as a lot of runs
Not sure what you mean here – we predict most symbols from previously seen ones. This might be another case where you don’t quite have the details down yet.
You might also be looking at specific subformat (there are many BIKi subtypes, for example – 14 at last count). This is why it’s kind of pointless to RE this format, since I rev it almost monthly – you’ll just fail on the next build after this one.
I recommend people just use the converter to dump it into a more appropriate end user format for this reason.
Reminds me of Monkey’s Audio. Also I don’t care much about newest files but being able to decode old is still a great benefit for people who don’t use Windows or x86.
As for block coding – I meant the case with, say, black or skipped frame. You have all block types = 1 and 6 for 16×16 blocks. They are coded as runs of values while player code (binary) seems to accept it in a form “read 4 bits and fill all values for with it”. And that form takes less bits too.
> You have all block types = 1 and 6 for 16×16 blocks
Yeah, that means something a bit more complicated – you probably haven’t seen all possible files.
That said, runs of all 1 colors or skips, aren’t very important – they use almost no bandwidth regardless. The encoder probably just didn’t want to poison the huffman counts for following frames.
> but being able to decode old
Yeah, I just don’t envy you there – by my rough count I think you’d need about 62 different files of possible Bink files to know you have it right. I wouldn’t want to do it even with source.
> don’t use Windows or x86
So, they own Windows to play the game, but they don’t to convert…?
>> but being able to decode old
>
>Yeah, I just don’t envy you there – by my rough count I think you’d need about 62 different files of possible Bink files to know you have it right. I wouldn’t want to do it even with source.
I just hope you did it in more or less compatible way. After all, you seem to look at it from encoder point of view (and encoder is your strong point indeed) and I look at it from decoder PoV.
> So, they own Windows to play the game, but they don’t to convert…?
Engine reimplementations happen. For example, I’ve met Bink files in some Mac games too. And don’t forget about some companies doing trailer release in Bink format (I remember one for Half-Life 2).
> I just hope you did it in more or less compatible way
Unfortunately, not really. I don’t worry about forward or reverse compatibility for the most part. Bink is always optimized for the hardware of the moment, not for other arbitrary-for-a-game factors (like compatibility). That’s what other codecs are for.
> from encoder point of view
Quite the opposite – I only care about the runtime performance (decoder). That’s why the format changes so rapidly. We made some changes for iphone just a few days ago, for example. Most of the time these changes are context based (for example, keyed off a data rate or frame size rather than a format value).
> Engine reimplementations happen
Yeah, but you’d almost certainly re-encode in this case. Silly to use files that were optimized for another era’s cpus.
> I’ve met Bink files in some Mac games too
Sure, we’re in like 92% of all games on all platforms – but most of those files are slightly custom for each platform. The only thing that can decode everything is our converter program.
> some companies doing trailer release in Bink format
Which was transcoded in hours to every end-user format under the sun – that was kind of silly of Valve. The whole advantage of Bink is the performance and the API – if you are just going to stick a video out on the web for people, you don’t get either win.
>> Engine reimplementations happen
>
>Yeah, but you’d almost certainly re-encode in this case. Silly to use files that were optimized for another era’s cpus.
Using old data files is easier than make user convert them or download new version (especially for open-source engines – new app and old CD). And transcoding usually only hurts quality.
> The only thing that can decode everything is our converter program.
No, it’s FFmpeg that can decode everything 😉 At least we try to make it so.
It is a rather bad idea to challenge an ffmpeg developer to RE your code, Jeff, because he will win. 😉
Remember, if RAD Game Tools can decode any BINK video, so can ffmpeg–and ffmpeg will likely end up doing it faster and more reliably. That’s how it’s worked in the past, that’s how it works now, and that’s how it will keep working until people stop creating bizarre custom nonstandard formats to RE. 😉
> It is a rather bad idea to challenge an ffmpeg developer
I’m not challenging anyone – I just think it’s kind of pointless, since in two weeks it will be different. Bink is just different like that – that’s the whole reason it exists – to be efficient on the hardware of that specific time.
> until people stop creating bizarre custom
> nonstandard formats to RE
I don’t see that happening for game video – it’s just got a different set of constraints and ip issues than normal video.
Wow, that was weird…
Firefox went into full mega-post mode…
Firefox on a posting bender…
I think you deleted my last post that had a couple extra sentences in it – is it history?
My replies appear to have been eaten…
There are a lot fewer comments here today than yesterday. Someone named “Jeff” was going back and forth with Kostya. Where did those comments go?
Hmm, looks like after I deleted several duplicated posts by Jeff blog engine automagically moved all his posts to spam. Should be restored now.
Sorry, there was one line that was dropped in my final post (it looks like you deleted the last post rather than the earlier duplicated ones), that kind of missed my sentiment:
“I actually enjoy following the RE efforts, because it’s watching years of little decisions all summarized.” (grin)
In any case, I don’t mind that you are doing this – I just feel bad that it’s going to be a bit of grimble work to always keep it compatible, since I modify the format fairly often.
[…] Multimedia Research « Bink: ‘lossless’ block coding Bink: pattern-run blocks […]