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."
Ever faster porn!
So how many Buffer overflows in either of them?
Which one, either google's or VP's has the most eploitable code?
That one will become standard, so the NSA GCHQ, MAFFIA, etc.... can use it to their best advantage.
nJoy !
Why are you watching the justin bieber movie again?
i thought once I was found, but it was only a dream.
I haven't looked at vp9, but I haven't known dropped frames due to a slow CPU to be a problem for at least 5 year, if not a decade. Perhaps on mobile devices, but we should be using hardware decoders in that use case. I'm not sure why more desktops and notebooks don't have hardware decoders for most of the popular formats.
Anthropic principle: We see the universe the way it is because if it were different we would not be here to see it.
he made a movie?
Everything I write is lies, read between the lines.
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
Your celeron 333 may have noticeable issues
This trusty rule of thumb still applies, even here. One codec may be faster, but the other may be good (fewer artifacts) and cheap (fewer cpu cycles).
Nothing supports VP9 decoding in hardware. That's why it's already a massive fail.
The output is equivalent to what libvpx produces (as measured by MD5 on each output frame) on all files in the VP9 conformance suite.
What is a "de facto" decoder? Something that is not supposet to decode VP9 but can be tricked/misused to do so?
Stop pulling examples out of your ass.
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!
...yeah but when did you run out of cpu when decoding stuff last time? (counting on that you didn't do it on a raspberry..)
however, since this is sw we're talking about it's entirely plausable that googles version looks crappier too....
world was created 5 seconds before this post as it is.
Agreed. And am I the only person in the world who still laments the transition to digital broadcast TV because analogue degraded far more gracefully? It was always worse picture rather than jerky/stalled picture, and worse sound rather than broken up sound.
And, no, watching TV over the Internet is not better at all: it's an utterly inefficient waste of bandwidth, and not subject to the lack-of-decent-QoS of the Internet: e-m waves OTA don't suffer congestion!
All that before the problem of having 400 crap channels rather than 4 good ones. Although I am in the UK, where we once had a world-beating state-owned broadcasting system. (Actually, we probably still do, but only because media standards have fallen so far globally.)
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.
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.
You probably let billions of CPU cycles go to waste just while typing that message. I know I did.
So, is the quality of the output equivalent or has it suffered due to compromises due to the speed increase?
It probably just means the reference implementation wasn't optimized very much.
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.
Well, we geeks have a respect towards older hardware too. Sure, a 333MHz Celeron is obviously too crusty for a modern desktop, but for example Core 1 Duo machines are perfectly usable if the software is just written sanely.
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...
Yeah, no shameless plugs here.
Ezekiel 23:20
Now that's what you call an "analogy"!
Slashdot social media options: AIM, ICQ, Yahoo, Jabber and Mobile Text. Why no MySpace?
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.
I'm sure that intel, nvidia etc were all prescient and implemented h264 support before the standard was even finished.
yea It was on amazon's instant video service for a while(still might be but has moved farther away from the movies I want to watch) that I don't care enough to look for it.
i thought once I was found, but it was only a dream.
I don't see any problem with that. It makes perfect sense to used different codecs in different contexts.
Note to ACs: I usually delete AC replies without reading them. If you want to talk to me, log in.
Equivalent or identical?
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.
What if you could have had software encoders/decoders available 2 years before h.264 hardware implementations? Would you have said "no"?
Dude. It has the same hash value. What do you think?
Core 1 Duo machines are perfectly usable if the software is just written sanely.
Bad choice of example. Core 1 machines are pretty much garbage thanks to one stupid choice by Intel, the return to 32 bit. 64 bit was already standard at that point. We could have had Windows 7 as a 64 bit exclusive if it weren't for the fucking Core 1 and similar timeframe Atoms meaning there were 32 bit only systems still under warranty.
Fuck Intel for releasing those things.
I used to get high on life, but I developed a tolerance. Now I need something stronger.
Sure, a 333MHz Celeron is obviously too crusty for a modern desktop
A bit sad really, since the only things I do that should require more performance is the higher quality video output and gaming. But booting the OS and editing a spreadsheet is still sluggish, all thanks to bloat.
I don't know. MD5 is no longer considered a collision free hash. It is entirely plausible that the VP9 implementation will output only same MD5, but not same output for a few frames. They should really upgrade to SHA-256 or stronger.
His:
They're talking about decoding, where the output is either correct or it's not.
Yours:
This is false. Decoding for modern video formats is strictly defined, and all decoders must produce bit-perfect output.
Except for the 'This is false' part, you agree with him completely.
Trolling is not a good way to get your message across.
Pass the crack pipe.
I'm under the impression that an encoder can produce different output but the decoders should always produce the same raw output. Honestly asking, is this different in the video compression world than in the file compression world?
So you haven't tried to play 4k videos yet?
That isn't plausible at all. While collisions are possible, they are still highly unlikely unless you are trying to get a collision.
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.
Also, how often does it crash?
The winner of the current crash-record on my computer is ffmpeg.
If Pandora's box is destined to be opened, *I* want to be the one to open it.
I don't know. MD5 is no longer considered a collision free hash. It is entirely plausible that the VP9 implementation will output only same MD5, but not same output for a few frames.
Really? I think you do not know what you are talking about. There is a higher chance of the sun going nova tomorrow than code output producing same MD5 hashes, by accident.
100 years ago, nothing supports H.264 in hardware either, yet here it is.
100 years ago, there were no 3G phones. H.264 has been in hardware since the first 3G phones came out. To overcome this installed base, a streaming service that relies on VP9 would have to ship all-new phones to subscribers who happen to have purchased a phone before VP9 hardware support became common. How would it make a profit?
even if you have a decently powerful laptop, each second your CPU spends in higher performance states costs you battery runtime.
Yes, but is it significant? I thought the screen was the limiting factor, and the help file for that just says "reduce the backlight brightness".
e-m waves OTA don't suffer congestion!
That's because the FCC or foreign counterpart has limited the selection of available programs to ease congestion.
All that before the problem of having 400 crap channels rather than 4 good ones.
What you define as a crap channel doesn't necessarily match what someone else defines as a crap channel.
Better decoders add filters to reduce compression artefacts
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.
Let me rephrase: Subjectively better decoders aren't pure decoders at all. They're combinations of a (possibly hardware-accelerated) decoder with an (also possibly hardware-accelerated) additional post-processing filter that enhances subjective video quality. All video player front-ends using this decoder-plus-filter component benefit from the filter's enhancement.
The difference from file compression is that file compression is lossless, while video compression is lossy, producing visible manifestations of roundoff error that an encoder-decoder-filter chain has to hide somehow. Each decoder for a particular format produces the same raw output, just as each unzip tool produces the same files. But because video encoding itself is lossy, subjectively "better" decoder implementations have options to enable post-processing filters that come after the decoder proper, tuned to hide a particular codec's most common artifacts.
It is a pretty noticeable problem when you have video which stresses your system. I have a video that's 2k resolution with incredibly crisp and clear fidelity, so much so I can see strands off a brush stuck in the paint of a painting in the background of a scene. On all of the systems in my house it drops frames here and there to keep up with the audio. The systems are no pushovers: Core 2 Quad Q9450 overclocked to 3.6Ghz, first gen i7 over clocked to 3.2Ghz and an AMD factory clocked at 4Ghz.
In order to watch the video I transcoded it into h.264 10-bit color at 1080 resolution. The color banding in darker areas of the frame are preferable to jerky animation from dropped frames. At least those can be made up for with post-process image enhancements.
VP8 didn't have a chance, because H.264 was long established and popular YEARS before VP8/WebM was even released. H.264 had 7 years of no competition, so yeah, it caught on, and VP8 didn't.
This time, though, VP9 was released head-to-head with H.265. Things could be very different. While companies start coming up with H.265 decoders, VP9 will be right there next to it, completely free to implement without paying the fees they do for h.265, and with a big company like Google encouraging them, and even offering to help.
Google, and On2 before them, have always encouraged development of hardware VPx decoders. And VP9 is no exception:
http://www.design-reuse.com/ne...
Like that design, I wouldn't be surprised at all to see most H.265 chips just incidentally also supporting VP9 on equal footing. After all, why NOT provide both, when the latter is free?
There's no guarantee that VP9 will catch on, just as there's no guarantee that anybody will use H.265... it might get basically passed-over by everyone, like H.263 did... but this time around, VP9 has a solid chance to actually compete, rather than being too late to the party.
Slashdot gets worse every day... Pipedot: News for nerds, without the corporate slant
I have given up on TV when analog OTA was switched off (in the country that used SECAM). Switching to digital should have made great sense because of the spectrum savings, but the 10 or 15 or so new channels are mostly garbage, the equivalent of shovelware. So the spectrum was polluted back anyway.
You have to buy a flimsy digital tuner piece of shit to get TV on an old TV instead of using nothing, and live with two remotes instead of one (and taking up a scarce SCART input). The quality went down, because you get compression artifacts where there wen't any (unless you buy a HD TV and/or tuner to get HD OTA, maybe, but not all channels are HD). Digital tuners don't have a RF modulator so you can't use the TV's antenna input to get signal, thus really old TVs can't get used.
Also you can't track the schedules of so many channels anyway. Gone is the social aspect of talking about yesterday's movie or program, when something significant was aired : this is probably the biggest issue, there was a cultural aspect common to nearly everyone in the nation with the six channels but now everyone is doing their own watching (or don't watch anything). There was already the downloading of movies and TV shows before : first eMule, then megaupload and shady streaming sites, then torrents and "illegal" copyrighted movies and shows straight from youtube itself. The end of analog OTA put the nail in the coffin.
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.
No links = No proof.
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)
h.265 is like Microsoft in the mobile space, and if Microsoft were to cut h.265 out of it operating system it would save money, and be good for its shareholders
I'm sure you can run bleeding edge linux with LXDE and gnumeric on that Celeron 333, and edit spreadsheets just fine. That Celeron is better than a Raspberry Pi : it has about the same CPU performance, and better disk and networking I/O (done over a PCI bus whereas Pi does all on a single USB port). If we could buy a cheap ass H264 etc. PCI decoding card, the Celeron would be suprisingly current.
Congrats on being rich. My desktop (purchased in late 2012) is incapable of playing 480p video without dropping frames.
This space intentionally left blank
I'm not sure why more desktops and notebooks don't have hardware decoders for most of the popular formats.
They do. Most desktops, notebook, and smartphones have hardware decoders for the most popular format. VP8/9 isn't it.
VP9 is *almost* as good as h.264, not h.265. h.265 is much much better than both. You need to recheck your facts.
That's only true when you have a constant bitstream.
Recovering from dropped or badly ordered packets is usually different between decoders.
Artifacts are not the only consequence of poor quality....
Not entirely sure what CPUs you were using this decade, but unless you have always been on a very powerful server/gaming grade machine, or only decoded stuff that is packed with older codecs, you are presenting an impossible scenario.
CPU power is very much behind the curve even today and has been so for last two decades at the very least when it comes to real time decoding of cutting edge video compression technology. It remains one of the barriers preventing widespread adoption of h.265 - in fact much of the development was basically stalled until CPUs would become powerful enough even though base algorithms were ready for a while. Same thing happened with h.264 and with divx - it took them a while to get adopted because when they were invented/researched, only a handful of machines in the world could decode them in real time at decent resolutions. Even today, better implementations of h.264 such as hi10p tend to have pretty heavy CPU requirements. We simply do not have the power to decode h.265 on the fly at higher resolutions without dedicated hardware support even today without a very powerful CPU. It's that CPU intensive. The math you have to crunch through is mindboggingly complex.
So the only way I can see your statement to be true is if you always stuck to hardware decoding (meaning no cutting edge) or you had a very powerful CPU at your disposal at all times. And if you didn't then you definitely had all the same problems that pretty much everyone else had. One of which was figuring out just how high of resolution you could decode before your CPU choked decoding the video in real-time.
For the rest of people, h.264 HiP still chokes on slower CPUs today when ran at 1080p. I have a lower end laptop that is less than two years old that cannot decode h.264 Hi10P in software at more than 720p (and sometimes chokes even on that in spite of me looking for an optimized codec that wouldn't for a long time - fastest I could find was a certain ffmpeg implementation) and struggles with HiP in 1080p, resulting in dropped frames. Very recent builds finally added proper GPU decoder that isn't exceptionally crashy and actually features support for more than just h264 MP and HiP, so I could actually decode these at 1080p in some cases. But that has been created over last year or so. And the implementation still has its share of bugs. That's for h.264, the biggest mainstream of them all. More exotic codecs like VP9 need all the help they can get and then some in this department.
My desktop has no such problems, but it's a gaming desktop with heavily overclocked CPU. All in all, we desperately need faster decoders for all modern codecs. Just because a small subset of users like you and myself has access to extreme high end hardware at all times, doesn't mean that the rest of people have the same privilege. And I still would like to not have to transcode my stuff to view it on my laptop.
And to answer your last question: dedicated hardware decoders are exceptionally bad for generalist machines like PCs, because they are extremely limited in what they can do. Even minor deviation from what they support renders hardware in question utterly useless. For example, a lot of hardware decoders in older mobile phones only support h.264 MP. Feed it HiP and it will just show you an error. Newer decoders support HiP, but feed them Hi10P and bam, nothing comes out again. As far as I know, there are few Hi10P capable hardware decoders out in the wild even today (feel free to correct me here, my information is dated on this particular subject).
And this stuff is old, the spec for all High profiles came out in 2005! We're talking about VP9 which is much newer. That spec was only established in 2012.
GPU decoders are the modern way of handling this problem, which are essentially a software implementation but designed to run on programmable GPU, allowing it to run almost as well as on dedicated hardware. But this has problems of optimizations and general bugginess - and tends to take time to produce a decod
Factually false. VP9 is approximately on par with h.264 by design. The goal of VP9 is not to improve quality over h.264, but to shrink the amount data needed. It's end goal is to get less data intensive than h.265.
As such, it's strictly inferior to h.265 which aims to improve quality while reducing data requirements. The current implementation, as far as I know, is inferior to HEVC in all areas. Of course, both implementations are very much a work in progress at this stage.
Because developing software for it, as well as possibly dedicated silicon (if you're not talking about GPU decoding but actual dedicated hardware as is done in mobile in many cases today) is far from free.
That's only partially true. Some parts of h.264 decoding were indeed in the phones, but early ones were cripplingly limited. I have an older 3G phone that can only decode h.264 MP at 180p. Anything more than that and it will not decode. Installing a player with software decoder will enable ability to decode more, but at hilarious speeds of fractions of a frame per second.
Weird Ive seen about a 7 year old cheapo laptop (when it was bought) with 1.7ghz celeron with built in intel graphics running xp do 720p h264 using vlc and 1080 h264 using mpchc with no problems so a lot has to do with software and other crap running in the background. If you are streaming the video instead of playing a file on you computer that might be the problem.
The software will be there. Google already requires Android devices be able to decode WebM, and I would expect them to update that to include VP9/Opus sometime in the future. Not to mention they provide a built-in media player to handle the formats.
Slashdot gets worse every day... Pipedot: News for nerds, without the corporate slant
I don't think you quite understand the complexity of the task at hand. Just because a huge company supports it doesn't mean that it will be there. Google itself is not exactly awesome with video players today (one of the big reasons to buy samsung for example is their vastly superior media player to that of google's own which lacks support for a lot of formats).
Specialists who actually can do necessary software design and programming in the field are rare, and most of them are already employed under very good terms, or exceptionally idealistic and do not want to help the large megacorp known as google become even bigger and more powerful (ffmpeg crowd). This is not a problem you can throw money at and expect it to be solved.
As one of those specialists, and part of the ffmpeg crowd, I can safely say you're utterly wrong on just about every count.
Slashdot gets worse every day... Pipedot: News for nerds, without the corporate slant
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".
http://tools.ietf.org/html/draft-grange-vp9-bitstream-00
lf(1): it's like ls(1) but sorts filenames by extension, tersely
Okay.
I guess then we'll be seeing tens and hundreds of ffmpeg-like encoders available for both free (as in beer), free (of bugs), and actually functional and with functional GUI front ends.
Makes me wonder why we haven't seen that back in divx days or h.264 days going right now if you are indeed correct and I'm wrong. What's holding all these people back?
I love H.264. I do not love that its proprietary, nor do I believe it should be. x.264? I hope someone can create a free codec equivalent to or superior to H.264 so I give props to Google for giving it a go with VP8 and VP9.
The founders of Oblong Industries, Inc. were responsible for the visuals in the 2002 movie the Minority Report. Their company started shortly after that movie and has been in the black for more than 10 years.
These images show the technology as conveyed in the movie. The video in the next paragraph showcases it at oblong and is very much worth a watch, enjoy.
No I do not work for Oblong Industries, not that fortunate.
Oblong Industries, Inc. g-speak uses their internally developed software SDK, optical cameras (a bit more expensive right now, but cheaper every year and multiple optical inputs produce less interference than multiple infrared inputs when generating 3-D images and manipulating those images in real time. Thanks to optical, the quality is much better. Imagine 20+ optical cameras, mulitple screens and you can since the data requirements and why they had to develop it internally. They use data pools in memory in order to move massive amounts of data over the network from say your database to your tablet, to your laptop, to a desktop (some at the same time) without stutters, pausing or visible buffering...I am sure you get the idea.
Too bad their current video does not show the gloves as the input device instead of the wand, suppose they are a work in progress.
I wonder if a codec like VP9 could use the concept of data pools to not only compress more efficiently, but to play back using less bandwidth, memory and CPU more efficiently.
Regardless the end goal of an open source, proprietary free, video/audio codec is exactly what ffmpeg is all about. Smart and powerful, if it does not get there today, who knows about tomorrow! You guys rock.
We will likely see an increase of client-side encoding VP9 through WebRTC.
Let others debate the extent of use, but browser-based video chat and screencasting will likely increase. This should pop many I've-never-encoded-a-video-before cherries.
The usage of VP9 will not be solely for 4k videos.