While it’s summer and I’d rather travel around (or suffer from heat when I can’t), there has been some progress on NihAV. Now I can decode VP5 and VP6 files. Reconstruction still sucks because it takes a lot of effort to make perfect reconstruction and I’m too lazy to do that when simple demonstration that the decoder works would suffice.
Anyway, now I can decode both VP5 and VP6 files including interlaced ones. Interlacing in VP5/6 is done in very simple way like many other codecs: there’s a bit for each macroblock telling whether macroblock should be output in interlaced form or not.
Of course this being VPx family, they had to do it with some creativity. First you decode base interlaced bit probability, which is stored as 8-bit value while all other bit probabilities are stored in 7 bits. Then you derive actual probability for interlaced bit and decode it before any other macroblock information (including macroblock type—it’s that important). Probability is derived by companding base probability depending on whether last macroblock was interlaced (then probability is halved) or not (then it’s remapped to fit 128-255 range)—except for the first macroblock in a row which would use the base probability without modifications. And for VP6 you also have to use different starting scan order (band assignment for each coefficient, now it’s shuffled). This is so trivial that one would wonder why this has not been done in libavcodec decoder yet.
There are three possible things to do next: polish current implementation, move to AVC (On2 AVC that is) or move to AVC (Duck VP7 which is AVC ripoff). But probably I’ll simply keep doing nothing instead.
You should send patch.
Had I cared, I’d do that.
say, have you ever imagined implementing MDEC as a decode-only video codec on NihAV?
Not yet since I have no interest in that codec (or consoles in general). It still might happen though.
Much like Paul, I hope someday you can share this hard work with those who truly appreciate it.
The VP7 interlacing routines, with their massive switch statements, were painful to even look at. I quickly gave up, deleted my VM due to carelessness, and have held regrets ever since. Good luck with it.
I don’t consider this to be hard work at all, I just had to match decompiled code against known sources and interlaced bit was really simple and I described it in a sentence or two: after coefficient model updates read 8-bit probability; set “MB interlaced” flag to 0; before each macroblock header read current “MB interlaced” flag using
probformb_x=0,prob + ((256-prob)>>1)for flag being zero,prob - (prob >> 1)otherwise.Scan table for the reference:
0, 1, 0, 1, 1, 2, 5, 3,
2, 2, 2, 2, 4, 7, 8, 10,
9, 7, 5, 4, 2, 3, 5, 6,
8, 9, 11, 12, 13, 12, 11, 10,
9, 7, 5, 4, 6, 7, 9, 11,
12, 12, 13, 13, 14, 12, 11, 9,
7, 9, 11, 12, 14, 14, 14, 15,
13, 11, 13, 15, 15, 15, 15, 15
If VP7 is that complex then I’ll document it at the usual place as I did with other codecs. And of course it’ll be in the sources that I hope to publish in full next year.
What is your opinion about CEmpeg leader MN and his fuzz patches?
First, he’s not a leader as he declared that himself (would you believe his actions over his words?!).
Second, it’s not the kind of patches I like to look at and study but overall to me it seems like a proper thing for modern times when you care more about code being “secure” and fixing automatically produced fault cases and not those insignificant things like code clarity, good design or streamlined common case.
I’m glad though that I don’t have anything to do with that or care much about such things in NihAV.