Slashdot Mirror
FFmpeg's VP9 Decoder Faster Than Google's
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."
So, is the quality of the output equivalent or has it suffered due to compromises due to the speed increase?
Agrajag: "Oh no, not again!"
I'm not an expert, but I'd say that when decoding video, frame drops caused by CPU overload sort of tend to be more noticable than a few decoding artifacts. At least that's how I always perceived it.
Ezekiel 23:20
The difference is because it doesn't send every twentieth frame to the mothership so they can target you with ads for buttplugs.
Or whatever else prominently features in the movie you're watching. Obviously. Just an example.
Confucius say, "Find worm in apple - bad. Find half a worm - worse."
Why are you watching the justin bieber movie again?
i thought once I was found, but it was only a dream.
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'.
Well, if you have CPU cycles to waste, just use the Google implementation, then! Not everyone is so fortunate in this imperfect world of ours.
Ezekiel 23:20
The output is equivalent to what libvpx produces (as measured by MD5 on each output frame) on all files in the VP9 conformance suite.
Stop pulling examples out of your ass.
My understanding is that there is no room for decode artifacts in this - you either do it right, or it's not a proper decoder. This is a proper decoder, so will produce identical output to the google standard one. I believe there are test streams with md5s for the test frames, and this decoder passes the tests.
So, it's free, and it's correct, and it's fast. I think you have pre-conceived prejudices which are in this case wrong ;-)
From my perspective, faster is good for low power devices, so if this helps spread decent video codecs to more devices, that's a win.
100 years ago, nothing supports H.264 in hardware either, yet here it is. I know, lets waste money making hardware for codecs that are not standards yet!
Or less fan noise while watching porn.
If you want less fan noise you should go with a format your system have hardware decode support for. That would not be VP9.
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.
Exactly. Having luxurious amounts of CPU power is not an excuse to do things badly anyway. Besides, you will save more battery on a laptop the less the CPU is being tasked.
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.
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.
I haven't seen dropped frames in video in longer than that... on my desktop. My AMD E-350 based netbook, on the other hand... when it runs into something incompatible and can't do hardware decoding, it gets bad.
Besides, even if you have a decently powerful laptop, each second your CPU spends in higher performance states costs you battery runtime. Faster code gives you less heat and longer battery life for free.
Fan noise would mask any user panting...
100 years ago, nothing supports H.264 in hardware either, yet here it is. I know, lets waste money making hardware for codecs that are not standards yet!
Well HEVC decoding does have hardware support and is rolling out to consumer devices right now. The shift to 4K which requires new hardware for everybody is probably the only chance at making a new standard, otherwise you'll have a non-trivial number of consumers with non-VP9 devices which means HEVC will be the de facto standard. Google has made a lot of bluster about their codec before, but YouTube still serves up video in H264. Unless they get really serious about pushing VP9 in hardware and very soon, history will repeat itself with HEVC/VP9.
Live today, because you never know what tomorrow brings
Just how slow am I talking about? As per the link, often about 50 times slower than x264.
This may be OK for google, which encodes a video once and then sends it to many many customers (youtube), the bandwidth savings pay for the increased CPU cost.
But for most users, that's just not acceptable. Until they get the speed up to a reasonable, we'll keep using what works: x264 or vp8
TODO: 753) write sig.
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.
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.
Dude. It has the same hash value. What do you think?
Google use ffmpeg quite a lot through Youtube. I wouldn't be surprised if they'd contributed quite a lot to the ffmpeg codebase, fixing bugs and performance issues. How much of this did Google's staff actually write?
== Jez ==
Do you miss Firefox? Try Pale Moon.
Fuck you. Windows 7 32bit is needed for all those Athlon XP and Pentium 4 machines still around. Enough of them will be turned into botnets in a couple of monthes already.
Businesses would have got all pissy anyway without the 32bit version, which allows to run Windows 3.1 software or 32bit software with random silly issues (and Windows 2000/XP drivers too)