FFmpeg's VP9 Decoder Faster Than Google's 101
An anonymous reader writes "A VP9 video decoder written for FFmpeg, FFvp9, now holds the title of being the world's fastest VP9 video decoder. FFvp9 is faster than Google's de facto VP9 decoder found in libvpx, but this doesn't come as too much of a surprise given that FFmpeg also produced a faster VP8 video decoder than Google a few years back with both single and multi-threaded performance."
Re: Faster is not necessarily better: Quality matt (Score:5, Informative)
Re:Faster is not necessarily better: Quality matte (Score:2, Informative)
They're talking about decoding, where the output is either correct or it's not. Unlike encoding, where you can trade speed for quality and where a bad implementation can achieve little of either and still be 'correct'.
Re:Faster is not necessarily better: Quality matte (Score:5, Informative)
Re:Good, Fast and Cheap... Pick Any Two (Score:4, Informative)
A decoder is indeed normally specified with bit level output requirements. Two different decoders thus generate exactly the same decoded bitstream. Some hardware decoders do generate 'wrong' output, but it is either that or 3-4 times as much battery drain. It is also not so important when watching a fullHD movie on a 320x480 screen wether all 18 bits of output are right.
Re:Faster is not necessarily better: Quality matte (Score:5, Informative)
This is false. Decoding for modern video formats is strictly defined, and all decoders must produce bit-perfect output. You can add as many filters as you want after that, but that's a postprocessing step in the video player and has nothing to do with the decoder. Things like in-loop filters are strictly defined as part of the decoding process and must be there for the decoder to be considered correct.
Re:Faster is not necessarily better: Quality matte (Score:2, Informative)
Todays formats are different from the MPEG2 and DivX ;-) of yore and generally require decoding to be a bit-exact process. There is only one correct way to decode a frame. If a decoder gives a different result, it doesn't just have "bad quality", it's wrong. This has obvious benefits, when compared to the days where you had to be lucky and hope that your decoder uses the same way to implement a DCT as the encoder that was used, or suffer suboptimal results. However, since this fact isn't very well known yet among users, the question of "decoder quality" (in a way not referring to speed and bug-free-ness) still pops up from time to time.
Re: Faster is not necessarily better: Quality matt (Score:2, Informative)
If you were talking about VP8 you might have a point, but VP9 is widely superior to h.264 in a number of areas and competetive with h.265.
In short, before you write about what a loser someone is, should have sound idea of what you are babbling about.
Re:decoding may be faster, but encoding is still d (Score:4, Informative)
Most users never encode a single video in their life. (Except for cameras on devices, and who is doing 4k video on thier phone these days?)
And if encoding takes 50x longer, that's 50x the resources Google needs to keep up with the work flow.
So you have it totally backwards.
Not to mention that we are talking about 4k-targetted codecs, so you should be comparing to H.265, not H.264. The additional computations for encoding H.265/VP9 are to reduce bandwidth requirements. If you don't care about bandwidth, feel free to generate a 5GB H.264 video.