I’ve finally finished implementing the rest of the features required for interframes: motion estimation, previous or golden frame selection (along with golden frame itself), four motion vectors per macroblock are finally supported. How I implemented fast motion search deserves a separate post that I hope to write at the weekend, the rest of things should be in this post.
Read the rest of this entry »
VP6 — interframe encoder done, what’s next?
September 23rd, 2021VP6 — simple interframe encoder done
September 18th, 2021As I said in the previous post detailing the roadmap, there’s a lot to do for an interframe encoder. Now I have the basics implemented but there’s a lot more to do.
Read the rest of this entry »
VP6 — interframe encoder roadmap
September 11th, 2021Before I start working on I’d like to summarise things that should be done for interframe encoding.
Read the rest of this entry »
VP6 — simple intraframe encoder, part 2
September 10th, 2021At last I have a working intraframe VP6 encoder. And the encoded data is decoded fine by the reference decoder as well as by open-source ones. So here I’ll describe what I had to do in order to achieve that result.
Read the rest of this entry »
VP6 — simple intraframe encoder, part 1
September 5th, 2021I admit that I haven’t spent much time on writing encoder but I still have some progress to report.
Read the rest of this entry »
VP6 — bool coder
August 29th, 2021Today I’ll try to tell the principles behind bool coder in VP6 (actually VP5-VP9) and how it all should work in the encoder. As usual, let’s start with the theory.
Read the rest of this entry »
VP6 encoding — DCT
August 27th, 2021Transform is one of the essential parts of typical video codec, lots of them can be described as e.g. “DCT-based video codec using X coding [and additional features like …]”. That is why I’m starting with it.
Read the rest of this entry »
Starting work on VP6 encoder
August 26th, 2021It is no secret (not even to me) that I suck at writing encoders. But with NihAV being developed exactly for trying new things and concepts, why not go ahead and try writing an encoder? It is not for having an encoder per se but rather a way to learn how things work (the best way to learn things is to try them yourself after all).
There are several reasons why I picked VP6:
- it is complex enough to have different concept of encoding to try on it;
- in the same time it’s not that complex (just DCT, MC, bool coder and no B-frames, complex block partitioning or complex context-adaptive coding);
- there’s no opensource encoders for it;
- there’s a decoder for it in
NihAValready; - this is not a toy format so it may be of some use for me later.
Of course I’m aware of other attempts to bring us an opensource VP6 encoder and that they all failed, but nothing prevents me from failing at it myself and documenting my path so others might fail at it faster and better.
Speaking of documenting, here’s a roadmap of things I want to play with (or played with already) and report how it went:
- DCT;
- bool coder;
- simple intraframe coding;
- motion estimation (including fast search and subpixel precision);
- rate distortion optimisation;
- rate control.
Hopefully the post about DCT will come tomorrow.
P.S. Why I declare this in public? So that I won’t chicken out immediately.
PACo done!
August 24th, 2021As I said in the previous post, I was looking at PACo format with an enhanced RLE compression. It turned out to be even more curious than I expected.
Beside the normal RLE mode it has pair and quad RLE (where you repeat two or four pixels) and long operation mode where you can do single/pair/quad RLE, copy or skip using 12-bit number. But it turns out it also has a compact RLE mode that works on a single line using a set of 16 colours and putting operation code, length and colour index into a single nibble instead of a byte (and it also has its own long mode where lengths are using a whole byte!).
That’s the variety I miss in modern video codecs.
Looking at PACo
August 23rd, 2021I was asked to look at this format used at least in Iron Helix game and it’s a somewhat interesting format.
It turned out to come from Macintosh. There are two small signs hinting on it: big-endian numbers inside the file and the fact it uses default QuickTime palette.
The container is simple but functional: there’s a header containing frame sizes among other thing, frame consisting of several records (usually it’s just video data and frame data end marker; the first frame has initalisation data chunk as well). Frames can have one of two compression methods and coded area size and offset.
Compression is just a slightly advanced RLE: codes 0x01–0x7F mean copying data, codes 0x80–0xFD are used to signal runs, code 0x00 is used to code long operations, code 0xFE is used to signal skips, code 0xFF is used for either runs of pairs or quads of pixels (depending on the run length). Each line is coded independently (i.e. runs or copies can’t go past the current line end). So what’s the tricky part there?
That’s compression method 1 and it works quite well. Compression method 2 is essentially the same but it codes lines in interlaced manner for which I haven’t managed to get a good picture in all cases yet (it seems to code more lines than declared sometimes and interlacing seems to be dependent on both decoded are position and height). But hopefully it won’t take long and I can document it in The Wiki.