Comment Re:Faster is not necessarily better: Quality matte (Score 1) 101
I'm not a video expert, but I did write an H.261 codec once.
I don't think it's practical in a VP9 decoder to save time by cutting quality. The Huffman decoding stuff all needs to be bit-exact. The DCT is pretty standard; you would just get a fast implementation of DCT and use that.
I suppose you could sleaze the mixing and filtering steps but the results would probably be so horrible that nobody would want to see it... part of how video decoding works is to refer back to previously-decoded images. The way "motion compensation" works is to say "this block is like this other block over here, but moved over by x pixels horizontally and y pixels vertically and with a few pixels updated". This means that if you sleaze the decode, it can have an effect on later frames.
(H.261 could only do motion compensation that referenced the previous frame. VP9 has 8 different reference buffers and any one frame can encode references to up to three of them! And they'd all better contain properly decoded images.)
So, my guess is that they just did a great job of tuning their code and the quality is good.
Also, the spec says that VP9 was deliberately designed to enable parallel decoding; maybe the FFMPEG implementation takes advantage of that. See section 3.2.1, "Frame-Level Parallelism".