×

Announcing: Slashdot Deals - Explore geek apps, games, gadgets and more. (what is this?)

Thank you!

We are sorry to see you leave - Beta is different and we value the time you took to try it out. Before you decide to go, please take a look at some value-adds for Beta and learn more about it. Thank you for reading Slashdot, and for making the site better!

FFmpeg's VP9 Decoder Faster Than Google's

timothy posted about 10 months ago | from the healthy-competition dept.

Google 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."

Sorry! There are no comments related to the filter you selected.

Faster is not necessarily better: Quality matters. (2, Interesting)

MROD (101561) | about 10 months ago | (#46315273)

So, is the quality of the output equivalent or has it suffered due to compromises due to the speed increase?

Re: Faster is not necessarily better: Quality matt (4, Informative)

K. S. Kyosuke (729550) | about 10 months ago | (#46315299)

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.

Re: Faster is not necessarily better: Quality matt (0)

CastrTroy (595695) | about 10 months ago | (#46315393)

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.

Re: Faster is not necessarily better: Quality mat (2)

K. S. Kyosuke (729550) | about 10 months ago | (#46315411)

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.

Re: Faster is not necessarily better: Quality mat (2)

jones_supa (887896) | about 10 months ago | (#46315541)

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.

Re: Faster is not necessarily better: Quality mat (0)

Anonymous Coward | about 10 months ago | (#46315551)

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.

Re: Faster is not necessarily better: Quality matt (1)

Anonymous Coward | about 10 months ago | (#46315457)

Nothing supports VP9 decoding in hardware. That's why it's already a massive fail.

Re: Faster is not necessarily better: Quality matt (3, Interesting)

Bengie (1121981) | about 10 months ago | (#46315485)

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!

Re: Faster is not necessarily better: Quality matt (-1)

Anonymous Coward | about 10 months ago | (#46315645)

h.264 had hardware support from day one, everything supports it and it provides markedly superior compression quality.

VP9 is a fucking joke and only a complete and utter worthless loser like you would ever give it a second look.

Re: Faster is not necessarily better: Quality matt (0)

Anonymous Coward | about 10 months ago | (#46315853)

I'm sure that intel, nvidia etc were all prescient and implemented h264 support before the standard was even finished.

Re: Faster is not necessarily better: Quality matt (-1)

Anonymous Coward | about 10 months ago | (#46315929)

They implemented it before anyone started using h.264, so yes.

You're not very bright, are you?

Re: Faster is not necessarily better: Quality matt (0)

Anonymous Coward | about 10 months ago | (#46319205)

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

Re: Faster is not necessarily better: Quality matt (2, Informative)

Anonymous Coward | about 10 months ago | (#46316135)

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: Faster is not necessarily better: Quality matt (-1)

Anonymous Coward | about 10 months ago | (#46316795)

You're smoking crack. h.264 is superior to VP9 in every single way. Better compression, better video quality, better support. Go look up any comparison and VP9 loses at all. VP9 is a fucking joke and so are you, faggot.

Re: Faster is not necessarily better: Quality matt (0)

Anonymous Coward | about 10 months ago | (#46316843)

Trolling is not a good way to get your message across.

Pass the crack pipe.

The true believer mods-up "Informative" (1)

westlake (615356) | about 10 months ago | (#46319117)

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.

Re: Faster is not necessarily better: Quality matt (1)

KingMotley (944240) | about 10 months ago | (#46319531)

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.

Re: Faster is not necessarily better: Quality matt (1)

Luckyo (1726890) | about 10 months ago | (#46320585)

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.

Re: Faster is not necessarily better: Quality matt (0)

Anonymous Coward | about 10 months ago | (#46316155)

What if you could have had software encoders/decoders available 2 years before h.264 hardware implementations? Would you have said "no"?

Re: Faster is not necessarily better: Quality matt (2)

Kjella (173770) | about 10 months ago | (#46315779)

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 [androidos.in] now [hdtvtest.co.uk] . 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.

Re: Faster is not necessarily better: Quality matt (1)

evilviper (135110) | about 10 months ago | (#46318989)

Unless they get really serious about pushing VP9 in hardware and very soon, history will repeat itself with HEVC/VP9.

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... [design-reuse.com]

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.

Re: Faster is not necessarily better: Quality matt (1)

Luckyo (1726890) | about 10 months ago | (#46320593)

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.

Re: Faster is not necessarily better: Quality matt (1)

evilviper (135110) | about 10 months ago | (#46320941)

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.

Re: Faster is not necessarily better: Quality matt (1)

Luckyo (1726890) | about 10 months ago | (#46322279)

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.

Re: Faster is not necessarily better: Quality matt (1)

evilviper (135110) | about 10 months ago | (#46322759)

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.

Re: Faster is not necessarily better: Quality matt (1)

Luckyo (1726890) | about 10 months ago | (#46327911)

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?

Re: Faster is not necessarily better: Quality matt (1)

tepples (727027) | about 10 months ago | (#46317803)

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?

Re: Faster is not necessarily better: Quality matt (1)

Luckyo (1726890) | about 10 months ago | (#46320605)

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.

Re: Faster is not necessarily better: Quality matt (5, Insightful)

Zuriel (1760072) | about 10 months ago | (#46315627)

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.

Screen is the limiting factor (1)

tepples (727027) | about 10 months ago | (#46317809)

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".

Re:Screen is the limiting factor (0)

Anonymous Coward | about 10 months ago | (#46319169)

Yes, CPU power is definitely significant. Leaving your laptop screen at full brightness certainly has a large effect on your battery life, but so does pegging your CPU the whole time you are using your laptop.

Re:Screen is the limiting factor (1)

default luser (529332) | about 10 months ago | (#46325323)

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".

Yes it is, if you were paying attention Intel's Haswell managed to increase "light use" battery life (spends most of the time idle) by 50% just by reducing the idle power drawn by the processor and platform.

If the processor had that much battery life impact when doing NOTHING, you can imagine it's of major importance to keep it idle as much as humanly possible.

Re: Faster is not necessarily better: Quality mat (0)

Anonymous Coward | about 10 months ago | (#46317207)

So you haven't tried to play 4k videos yet?

Re: Faster is not necessarily better: Quality matt (0)

Anonymous Coward | about 10 months ago | (#46318801)

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.

Re: Faster is not necessarily better: Quality matt (1)

Gavagai80 (1275204) | about 10 months ago | (#46319373)

Congrats on being rich. My desktop (purchased in late 2012) is incapable of playing 480p video without dropping frames.

Re: Faster is not necessarily better: Quality matt (0)

Anonymous Coward | about 10 months ago | (#46320853)

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.

Re: Faster is not necessarily better: Quality matt (1)

KingMotley (944240) | about 10 months ago | (#46319517)

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.

Re: Faster is not necessarily better: Quality matt (1)

Luckyo (1726890) | about 10 months ago | (#46320533)

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 decoder that is usable for end user (i.e. not choke full of critical bugs or weird artefacts of various types and that is fast enough for real time decode). Still, it's definitely a more elegant solution that brute forcing the math on CPU, which chokes the CPU in many cases, or shoving dedicated hardware that isn't capable of rendering anything out of its exact capability range and as a result is not future proof.

Re: Faster is not necessarily better: Quality matt (1)

gl4ss (559668) | about 10 months ago | (#46315507)

...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....

Re: Faster is not necessarily better: Quality matt (1)

Anonymous Coward | about 10 months ago | (#46315529)

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.)

Re: Faster is not necessarily better: Quality matt (1)

tepples (727027) | about 10 months ago | (#46317825)

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.

Re: Faster is not necessarily better: Quality matt (1)

Blaskowicz (634489) | about 10 months ago | (#46319115)

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.

Re: Faster is not necessarily better: Quality mat (0)

Anonymous Coward | about 10 months ago | (#46319847)

Artifacts are not the only consequence of poor quality....

Re:Faster is not necessarily better: Quality matte (2, Funny)

Hognoxious (631665) | about 10 months ago | (#46315303)

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.

Re:Faster is not necessarily better: Quality matte (2)

peragrin (659227) | about 10 months ago | (#46315363)

Why are you watching the justin bieber movie again?

Re:Faster is not necessarily better: Quality matte (1)

ls671 (1122017) | about 10 months ago | (#46315395)

he made a movie?

Re:Faster is not necessarily better: Quality matte (1)

peragrin (659227) | about 10 months ago | (#46315925)

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.

Re:Faster is not necessarily better: Quality matte (4, Funny)

pr0nbot (313417) | about 10 months ago | (#46315471)

Stop pulling examples out of your ass.

Re: Faster is not necessarily better: Quality matt (1)

K. S. Kyosuke (729550) | about 10 months ago | (#46315701)

Yeah, no shameless plugs here.

Re:Faster is not necessarily better: Quality matte (1)

mwvdlee (775178) | about 10 months ago | (#46315707)

Now that's what you call an "analogy"!

Re:Faster is not necessarily better: Quality matte (2, Informative)

Anonymous Coward | about 10 months ago | (#46315409)

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 (-1)

Anonymous Coward | about 10 months ago | (#46315543)

They're talking about decoding, where the output is either correct or it's not.

That is only true until the encoding step involves lossy compression - which video compression generally does. You can get a correct decoding by simply showing what you got and this may fit the requirements of mathematical correctness, however it will look wrong/ugly to a human viewer. Better decoders add filters to reduce compression artefacts or even make assumptions based on prior frames, content of the frames, movement etc. .

Also performance could hinge on the amount of iterations used to refine a result, some mathematical operations can be done in one to n steps where each additional step adds a small decreasing improvement to the precision, if ffmpeg uses less and the result looks like shit as a result then the performance gain is irrelevant.

source: some guy who had to spend way too much time dealing with rendering artefacts and workarounds implemented in both software and hardware.

Re:Faster is not necessarily better: Quality matte (5, Informative)

marcansoft (727665) | about 10 months ago | (#46315575)

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.

Please read before commenting (0)

Anonymous Coward | about 10 months ago | (#46316807)

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.

Re:Please read before commenting (1)

Ginger Unicorn (952287) | about 10 months ago | (#46317999)

there's a post in between these two that slashdot hid because the rating was too low.

Re:Faster is not necessarily better: Quality matte (1)

tepples (727027) | about 10 months ago | (#46317845)

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.

Re:Faster is not necessarily better: Quality matte (1)

loufoque (1400831) | about 10 months ago | (#46319585)

That's only true when you have a constant bitstream.
Recovering from dropped or badly ordered packets is usually different between decoders.

Re: Faster is not necessarily better: Quality matt (0)

Anonymous Coward | about 10 months ago | (#46315431)

Your celeron 333 may have noticeable issues

Re: Faster is not necessarily better: Quality matt (-1)

Anonymous Coward | about 10 months ago | (#46315451)

Your nigger mother may have noticeable issues, faggot.

Re: Faster is not necessarily better: Quality matt (0)

Anonymous Coward | about 10 months ago | (#46315615)

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.

Re: Faster is not necessarily better: Quality matt (0)

wolrahnaes (632574) | about 10 months ago | (#46316435)

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.

Re: Faster is not necessarily better: Quality matt (2)

Blaskowicz (634489) | about 10 months ago | (#46319185)

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)

Re: Faster is not necessarily better: Quality matt (0)

Anonymous Coward | about 10 months ago | (#46316521)

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.

Re: Faster is not necessarily better: Quality matt (1)

Blaskowicz (634489) | about 10 months ago | (#46319227)

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.

Re:Faster is not necessarily better: Quality matte (-1)

Anonymous Coward | about 10 months ago | (#46315443)

The Orientals need to learn this.

Re:Faster is not necessarily better: Quality matte (5, Informative)

rbultje (3548279) | about 10 months ago | (#46315463)

The output is equivalent to what libvpx produces (as measured by MD5 on each output frame) on all files in the VP9 conformance suite.

Re:Faster is not necessarily better: Quality matte (0)

Anonymous Coward | about 10 months ago | (#46316131)

Equivalent or identical?

Re:Faster is not necessarily better: Quality matte (2)

cheesybagel (670288) | about 10 months ago | (#46316375)

Dude. It has the same hash value. What do you think?

Re:Faster is not necessarily better: Quality matte (1)

Anonymous Coward | about 10 months ago | (#46316735)

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.

Re:Faster is not necessarily better: Quality matte (0)

Anonymous Coward | about 10 months ago | (#46317361)

That isn't plausible at all. While collisions are possible, they are still highly unlikely unless you are trying to get a collision.

Re:Faster is not necessarily better: Quality matte (1)

Anonymous Coward | about 10 months ago | (#46317535)

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.

Re:Faster is not necessarily better: Quality matte (1)

Tapewolf (1639955) | about 10 months ago | (#46315557)

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.

Re:Faster is not necessarily better: Quality matte (2, Informative)

Anonymous Coward | about 10 months ago | (#46315589)

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.

Quality? (0)

Anonymous Coward | about 10 months ago | (#46317135)

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?

Video decoders offer filters to hide artifacts (1)

tepples (727027) | about 10 months ago | (#46317879)

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.

Re:Faster is not necessarily better: Quality matte (1)

StripedCow (776465) | about 10 months ago | (#46317525)

Also, how often does it crash?
The winner of the current crash-record on my computer is ffmpeg.

Re:Faster is not necessarily better: Quality matte (1)

steveha (103154) | about 10 months ago | (#46327255)

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 [ietf.org]

Whoo-hoo! (1)

Anonymous Coward | about 10 months ago | (#46315309)

Ever faster porn!

Re:Whoo-hoo! (1)

Z80a (971949) | about 10 months ago | (#46315317)

Or less fan noise while watching porn.

Re:Whoo-hoo! (2, Insightful)

Anonymous Coward | about 10 months ago | (#46315487)

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.

Re:Whoo-hoo! (1)

Blaskowicz (634489) | about 10 months ago | (#46319271)

We're on a site traditionally slanted towards linux and FLOSS. Even when we have decoding hardware, it's not supported most time. There's even recent news about Ubuntu 14.04 specifically not supporting some of it!, depending on your hardware and drivers.

Re:Whoo-hoo! (0)

Anonymous Coward | about 10 months ago | (#46320989)

So you agree it should be in GIF, yeah?

Is that a feature or a bug? (2)

Two99Point80 (542678) | about 10 months ago | (#46315671)

Fan noise would mask any user panting...

Re:Whoo-hoo! (0)

Anonymous Coward | about 10 months ago | (#46316137)

You watch your porn in a stadium?

Exploitable (0)

Anonymous Coward | about 10 months ago | (#46315319)

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 !

Good, Fast and Cheap... Pick Any Two (0)

mykro76 (1137341) | about 10 months ago | (#46315441)

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).

Re:Good, Fast and Cheap... Pick Any Two (5, Insightful)

Cesare Ferrari (667973) | about 10 months ago | (#46315481)

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.

Re:Good, Fast and Cheap... Pick Any Two (4, Informative)

Anonymous Coward | about 10 months ago | (#46315513)

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.

"De Facto"? (1)

DMiax (915735) | about 10 months ago | (#46315465)

What is a "de facto" decoder? Something that is not supposet to decode VP9 but can be tricked/misused to do so?

Re:"De Facto"? (-1)

Anonymous Coward | about 10 months ago | (#46315539)

Welcome to slashdot! Summaries are a lot like portapotties:

Breathe deep the gathering gloom
Watch light fade from every room
Bedsitter people look back and lament
Another day's useless image is spent
Impassioned lovers wrestle as one
Lonely man cries for love and has none
New mother picks up and suckles her son
Senior citizens wish they were young
Cold-hearted orb that rules the night
Removes the colors from our sight
Red is grey and yellow white
But we decide which is right
And which is an illusion

The life of a slashdot reader.

Re:"De Facto"? (1)

jones_supa (887896) | about 10 months ago | (#46315631)

"De facto" here means that it happens to be used by default by Chrome, but it isn't an industry standard reference decoder.

Re:"De Facto"? (0)

Anonymous Coward | about 10 months ago | (#46316177)

That may be what it is meant to mean, but that is not what that word actually means, nor does it make sense even if that word meant that.

Re:"De Facto"? (1)

jones_supa (887896) | about 10 months ago | (#46316217)

You are correct. Technically the phrase de facto is used a bit incorrectly in the summary.

decoding may be faster, but encoding is still drea (3, Insightful)

tota (139982) | about 10 months ago | (#46315811)

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

Re:decoding may be faster, but encoding is still d (1)

swillden (191260) | about 10 months ago | (#46316099)

I don't see any problem with that. It makes perfect sense to used different codecs in different contexts.

Re:decoding may be faster, but encoding is still d (3, Informative)

Mashdar (876825) | about 10 months ago | (#46316139)

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.

ffmpeg/Google? (2)

jez9999 (618189) | about 10 months ago | (#46317415)

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?

Re:ffmpeg/Google? (0)

Anonymous Coward | about 10 months ago | (#46321001)

Insightful but lacking evidence.

Go ffmpeg! (1)

cboslin (1532787) | about 10 months ago | (#46330867)

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. [oblong.com] were responsible for the visuals in the 2002 movie the Minority Report [imdb.com] . 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. [google.com] 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 [oblong.com] 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.

Load More Comments
Slashdot Login

Need an Account?

Forgot your password?