3 ms·
Codecs are complicated and mathy and optimized for speed. So you might find a line of code that says something like: val = SHOW_UBITS(re, gb, bits) - (1 <
by beej71 15y ago
Codecs are complicated and mathy and optimized for speed. So you might find a line of code that says something like:
val = SHOW_UBITS(re, gb, bits) - (1 << exp_order) + (switch_bits + 1) << rice_order);
and you just don't have a clue what it really means (I don't--even though I can easily read the line of code) because the answer is buried in the details of the codec design.
But trust me--if you go through a complicated spec and implement it yourself, you'll end up with a lot of similar stuff as this guy did, with his mighty-fine-looking piece of work.
- daeken 15y agoThis is especially true when you're reversing a codec. I helped out reversing ALAC (Apple's answer to FLAC), and I didn't know what 99.9% of the code did, I just knew how it needed to do it. Certain things fit common patterns with simple changes (e.g. modified Rice coding), but most of the time you're just matching code behavior directly. I will say, building an encoder based solely on the reverse-engineered decoder (didn't want to reverse out the encoder as well -- total mess) is a really fun challenge. Good way to dive into codec work.
- kierank 15y agoHaving done the same thing I would agree entirely. There are lots of similar patterns in decoders from a similar family.
- baddox 15y agoWould it be possible to write the same code to make it more readable without incurring a performance penalty? If not, then I guess it's okay, since these people have decided that performance is more important than readability (although there should be comments).