Netflix Finds x265 20% More Efficient Than VP9 (streamingmedia.com)

← Back to Stories (view on slashdot.org)

Netflix Finds x265 20% More Efficient Than VP9 (streamingmedia.com)

Posted by msmash on Tuesday September 6, 2016 @03:21AM from the affinity-for-best-media-codec dept.

Reader StreamingEagle writes (edited): Netflix conducted a large-scale study comparing x264, x265 and libvpx (Google-owned VP9), under real-world conditions, and found that x265 encodes used 35.4% to 53.3% fewer bits than x264, and between 21.8% fewer bits than libvpx, when measured with Netflix's advanced VMAF assessment tool. This was the first large-scale study to use real-world encoder implementations, and a large sample size of high quality, professional content.A Netflix spokesperson explained why they did the test in the first place; "We wanted to understand the current state of the x265 and libvpx codec implementations when used to generate non-realtime encodes optimized for OTT use case. It was important to see how the codecs performed when testing on a diverse set of premium content from our catalog. This test can help us find areas of improvement for the different codecs."

178 comments

Min score:

Reason:

Sort:

Mostly... by johnsmithperson123 · 2016-09-06 03:23 · Score: 2

I just want websites to use the HTML5 video player as opposed to Flash. x265 is not very important except for 4K content and mobile phones. It will, though, eventually become the standard.
1. Re:Mostly... by Black.Shuck · 2016-09-06 03:29 · Score: 5, Insightful
  
  x265 is not very important except for 4K content and mobile phones
  I think a 20% overall reduction in bandwidth for an in-demand and still-growing medium is *very* significant no matter what the resolution or device is.
2. Re:Mostly... by geek · 2016-09-06 03:44 · Score: 5, Informative
  
  x265 is not very important except for 4K content and mobile phones
  I think a 20% overall reduction in bandwidth for an in-demand and still-growing medium is *very* significant no matter what the resolution or device is.
  The real number is 34-53%. The 20% is just over VP9. The 34-53% is over their current streaming codec.
3. Re:Mostly... by Luthair · 2016-09-06 03:46 · Score: 5, Funny
  
  Clearly though, the image produced by mpeg2 is much superior to h265 much like records sound better than CDs.
4. Re:Mostly... by danbob999 · 2016-09-06 03:54 · Score: 1
  
  not if you use the same bit rate.
5. Re:Mostly... by Rockoon · 2016-09-06 03:57 · Score: 4, Funny
  
  mpeg2 uses gold bits, while h265 uses copper and aluminum.
  
  --
  "His name was James Damore."
6. Re:Mostly... by Anonymous Coward · 2016-09-06 03:58 · Score: 0
  
  Well um... if you have the bit rate mpeg-2 actually is better. But the use case of transferring over the internet so you won't have the necessary bit rate to make it look that good.
7. Re:Mostly... by Anonymous Coward · 2016-09-06 04:18 · Score: 0
  
  x265 is not very important except for 4K content and mobile phones
  I think a 20% overall reduction in bandwidth for an in-demand and still-growing medium is *very* significant no matter what the resolution or device is.
  So is the cost (as in RTFA). HEVC or h.265 is not free. VP9 and x264 are.
8. Re:Mostly... by Matt.Battey · 2016-09-06 04:42 · Score: 3, Funny
  
  Yes but Capacitance Electronic Discs have a much warmer picture, especially when paired with new old-stock cathode ray tube amplifiers.
9. Re:Mostly... by StreamingEagle · 2016-09-06 04:51 · Score: 2
  
  The only thing preventing HEVC/H.265 from being supported natively in browsers is the patent license terms. The developers of x265 have made a proposal to fix this situation. See http://x265.org/proposal-accel...
10. Re:Mostly... by Anonymous Coward · 2016-09-06 04:52 · Score: 1
  
  It will, though, eventually become the standard.
  I don't think so. Not for Internet video applications. The patent licensing for H.265 is a mess and the x265 guys are pleading with the industry to get the their act together.
  Meanwhile, VP9 is royalty-free and VP9's successor, AV1, will also be royalty-free. So why pay patent royalties on video encoding, decoding, and the mere distribution of video content when you don't have to?
11. Re:Mostly... by MachineShedFred · 2016-09-06 05:09 · Score: 1
  
  So why pay patent royalties on [...] when you don't have to?
  Good question.
  Signed,
  DisplayPort vs. HDMI
  
  --
  Slashdot still doesnâ(TM)t support Unicode after it was added to the HTML standard in 1997.
12. Re:Mostly... by barc0001 · 2016-09-06 05:16 · Score: 2
  
  > x265 is not very important except for 4K content and mobile phones.
  This is exactly the mindset that leads to waste, inefficiency and bloat. If you can save even 5% on bandwidth, which is a limited resource, WHY NOT DO IT? And this is way more than 5%.
13. Re:Mostly... by K.+S.+Kyosuke · 2016-09-06 05:19 · Score: 1
  
  Elsewhere, I saw something about x265 not being so good (comparatively) at higher bandwidth anyway. So the question also is if this was a low bandwidth or high bandwidth test.
  
  --
  Ezekiel 23:20
14. Re:Mostly... by Black.Shuck · 2016-09-06 05:25 · Score: 1
  
  x265 is not very important except for 4K content and mobile phones
  I think a 20% overall reduction in bandwidth for an in-demand and still-growing medium is *very* significant no matter what the resolution or device is.
  So is the cost (as in RTFA). HEVC or h.265 is not free. VP9 and x264 are.
  Bandwidth and storage is a fixed quantity. A terabyte is a terabyte wherever you store it.
  Processor speeds improve year over year.
15. Re:Mostly... by Anonymous Coward · 2016-09-06 05:26 · Score: 1
  
  So is the cost (as in RTFA). HEVC or h.265 is not free. VP9 and x264 are.
  x265 is "free" like x264 is "free". It's open source software but you may have to pay for the patents.
16. Re:Mostly... by Anonymous Coward · 2016-09-06 05:27 · Score: 0
  
  If you have the bitrate, raw uncompressed video yields the highest quality. Luckily nobody has a patent on raw video (yet)
17. Re:Mostly... by Bengie · 2016-09-06 05:31 · Score: 1
  
  Bandwidth is rarely limited, only more expensive then choosing your encoding. Spend an extra $5k once in electricity encoding using a better codec, save $50k/month in bandwidth. But I do agree with your statement, why not save if you can?
18. Re:Mostly... by FithisUX · 2016-09-06 05:34 · Score: 1
  
  Where is the Eve encoder comparison?
19. Re:Mostly... by Anonymous+Brave+Guy · 2016-09-06 05:39 · Score: 2
  
  x264 isn't really free if you live or work anywhere that the patents on the underlying technologies are valid.
  
  --
  If you disagree, post your argument. (-1, Overrated) isn't your personal censorship tool for views you don't like.
20. Re:Mostly... by Luthair · 2016-09-06 05:41 · Score: 1
  
  Jokes aside, mpeg2 is still lossy so I'm not sure that is the case.
21. Re:Mostly... by barc0001 · 2016-09-06 05:41 · Score: 1
  
  The problem is it's the mindset and everyone seems to have it these days. "Oh, bandwidth isn't limited" "processors are more powerful" etc. You get a program built with 10 pieces of separate code that everyone failed to optimize and suddenly it's sucking 3x the bandwidth and 5x the processing power that it would have if everyone involved actually thought about optimization.
  Where I work we go back and refactor a lot of our code and queries when we have opportunities to do so and in some cases it's horrifying the waste that's been put up with. A SQL query that "works" but takes 30 seconds gets rewritten properly and now takes .3 seconds. Back when that was the only app on that server it ran faster so it was "no big deal" but now it saves hours of batch processing time per day. And this is EVERYWHERE. People wonder why their octa-core phones run barely faster than phones from 3 years ago? Shitloads of wasteful coding in those app design tools is my guess.
22. Re:Mostly... by Anonymous Coward · 2016-09-06 05:44 · Score: 0
  
  Yeah, it was last week IIRC, a Netflix blog post about a different test regarding codecs on different resolutions...
23. Re:Mostly... by donaldm · 2016-09-06 05:51 · Score: 1
  
  Clearly though, the image produced by mpeg2 is much superior to h265 much like records sound better than CDs.
  Have you ever done an intercomparison?
  If you take a 600MB plus H264 8bit anime or movie and use Handbrake to convert it to H265 8bit you will get a 55% to 65% reduction in size without reducing the quality of the file. If you convert from 8bit to 10bit you may get a 5% reduction and if you convert from 8bit to 12 bit you may get a 7% reduction although it usually is not worth converting to 12bit since you limit the video players you can use and it usually takes two to three times as long to do the conversion.
  Note: VLC for Linux will play many different codecs as well as 10bit, however it won't play 12bit so you can use "mpv Music Player" also for Linux which does not have the pretty front end of VLC but it does work quite well.
  BTW. Comparing records (I assume you mean vinyl) to CD's is rather pointless. Since CD's are digital and are easier to keep in good condition because the reader does not contact the media. Vinyl, on the other hand is analogue and as such requires a stylus contact to read the grooves which will eventually wear out the media. As for which is better, that depends on the person who's listening and the equipment used to play the particular media. Even on the best equipment most people can't tell the difference although they will be able to pick up a worn stylus or record.
  If you want to discuss lossless formats how about flac which is patent free, unlike mpeg2 which is patent encumbered till next year at the latest (yes it is confusing).
  
  --
  There ain't no such thing as proprietary standards only proprietary formats. Standards are by definition open.
24. Re:Mostly... by Anonymous Coward · 2016-09-06 05:58 · Score: 0
  
  Vinyl, on the other hand is analogue and as such requires a stylus contact to read the grooves which will eventually wear out the media.
  Not true, in the latter days of vinyl, they developed a laser stylus now commercially available which doesn't touch the media
25. Re:Mostly... by donaldm · 2016-09-06 06:22 · Score: 2
  
  The only thing preventing HEVC/H.265 from being supported natively in browsers is the patent license terms. The developers of x265 have made a proposal to fix this situation. See http://x265.org/proposal-accel...
  
  The Edge browser does support H265 but surprise surprise it does not support many open formats. If you go to this site and do an intercomparison between Chrome, Firefox, Edge and your preferred browser, with particular emphasis on the Video and Audio support you can see this.
  BTW. That link was an interesting read although I don't think patents are really going to stop the home user from using the particular codecs. It is surprisingly easy using tools like Handbrake (it really does hammer your PC though) to convert from one codec to another as well as converting 8bit to 10bit or even 12bit. The main reason to convert H264 to H265 is the fact that you can get a reduction in file size from 55% to 65% and in some cases much better than that, especially if you convert to 10 to 12 bits as well.
  
  --
  There ain't no such thing as proprietary standards only proprietary formats. Standards are by definition open.
26. Re:Mostly... by Anonymous Coward · 2016-09-06 06:31 · Score: 0
  
  The developers of x265 have made a proposal to fix this situation.
  I don't see that there's much point to the proposal. VP9 is royalty-free today, AV1 will be royalty-free as well and royalty-free formats are future for online video. H.265 can't compete with that. The patent licensing business model around H.265 doesn't allow it to be competitive.
27. Re:Mostly... by Anonymous Coward · 2016-09-06 06:35 · Score: 0
  
  Just because you aren't seeing a reduction in quality when converting from AVC to HEVC doesn't mean there isn't one. I guarantee you're losing detail.
28. Re:Mostly... by nmb3000 · 2016-09-06 06:56 · Score: 1
  
  Vinyl, on the other hand is analogue and as such requires a stylus contact to read the grooves which will eventually wear out the media.
  Not true, in the latter days of vinyl, they developed a laser stylus now commercially available which doesn't touch the media
  I was skeptical, assuming that this would largely negate the claimed advantage of analog vinyl over digital CDs, even with an absurd sampling rate, but following the link farm page to the real article suggests otherwise:
  
  One of its biggest appeals for audiophiles is the fact that its electronics are entirely analogue – the signal is not digitised as part of the signalling and playback process.
  [...]
  The LT player's five lasers – one on each channel to track the sides of the groove, one on each channel to pick up the sound (just below the tracking beams), and a fifth to track the surface of the record and keep the pickup at a constant height
  Sounds fancy. Whether that's worth $20,000, well, YMMV.
  
  --
  "What do you despise? By this are you truly known." --Princess Irulan, Manual of Muad'Dib
  /)
29. Re:Mostly... by Anonymous Coward · 2016-09-06 07:01 · Score: 0
  
  > x265 is not very important except for 4K content and mobile phones.
  This is exactly the mindset that leads to waste, inefficiency and bloat. If you can save even 5% on bandwidth, which is a limited resource, WHY NOT DO IT? And this is way more than 5%.
  This is often offset by higher computational cost. If you're on a desktop then it might not matter, but if you're on a mobile device then you may want to preserve you batteries.
  Most people aren't worry about 5% of their bandwidth allotment.
30. Re:Mostly... by Kjella · 2016-09-06 07:18 · Score: 2
  
  It is surprisingly easy using tools like Handbrake (it really does hammer your PC though) to convert from one codec to another as well as converting 8bit to 10bit or even 12bit. The main reason to convert H264 to H265 is the fact that you can get a reduction in file size from 55% to 65%
  transcoding from one loss codec to another -> *facepalm 1*
  8 bit source -> 10/12 bit destination *facepalm 2*
  55-65% and in some cases much better than that -> *facepalm 3*
  Sometimes, even Picard and Riker is not enough...
  
  --
  Live today, because you never know what tomorrow brings
31. Re:Mostly... by Bengie · 2016-09-06 07:24 · Score: 1
  
  I wonder if the lost reduction going from 8bit to 10bit is most data isn't actually sourced as 10bit and those extra bits are just noise, bloating the end size.
32. Re:Mostly... by Luthair · 2016-09-06 07:38 · Score: 1
  
  The Joke
  Your Head
33. Re:Mostly... by Luthair · 2016-09-06 07:38 · Score: 1
  
  Yup, re-encoding something that is lossy will almost always lose information.
34. Re:Mostly... by organgtool · 2016-09-06 07:48 · Score: 1
  
  This is exactly the mindset that leads to waste, inefficiency and bloat. If you can save even 5% on bandwidth, which is a limited resource, WHY NOT DO IT? And this is way more than 5%.
  Because h.265 requires hardware decoding to be even moderately watchable and the vast majority of devices that people currently own are not capable of decoding the latest h.265 videos. Netflix could force people to upgrade which would cause them to buy new decoding hardware and the waste you mention would shift from wasted bits on a network connection to wasted hardware in landfills. Unless, of course, there is a standardized way of querying hardware to determine which codecs and maximum resolutions/bitrates are supported by hardware decoders but I'm not aware of such a feature.
35. Re:Mostly... by KozmoStevnNaut · 2016-09-06 07:50 · Score: 2
  
  No, it's pretty much crap.
  The records have to be absolutely 100% completely free of dust or any other particles, otherwise the laser will read them as if they were the actual groove, leading to a lot of unwanted noise. A normal pickup pushes aside most of the dust.
  It's a neat idea, but it's much worse than a decent pickup on a normal turntable.
  
  --
  Eat the rich.
36. Re:Mostly... by Anonymous Coward · 2016-09-06 07:58 · Score: 0
  
  H.265 is pretty much universally 1/2 the file size of H.264, regardless of quality setting.
37. Re:Mostly... by Bengie · 2016-09-06 07:58 · Score: 1
  
  I've had queries that took 3 minutes and got them down to under 10 seconds, for a nightly job that no one cared about. Until some large dataset came along and made that 3 minute run go for 24+ hours before a DBA killed it. At which point I tossed my version in and it ran in less than a minute.
  
  In my experience, good code not only runs much faster, but scales linearly, while bad code scales exponentially. All of those scrubs and their "micro benchmarks" showing that their code is fast enough, then you throw it into prod and it blows up a few weeks later and takes days of debugging to nail down the cause.
38. Re:Mostly... by Anonymous Coward · 2016-09-06 08:09 · Score: 0
  
  but what's the processing overhead?
  I know on my system when I try to use x265 it is much much slower.
39. Re:Mostly... by flargleblarg · 2016-09-06 08:14 · Score: 0
  
  transcoding from one loss codec to another -> *facepalm 1*
  I don't know why you would facepalm that. You can take H.264 video that was encoded with RF18 and re-encode it as H.265, also at RF18, and the results are indistinguishable.
40. Re:Mostly... by doom · 2016-09-06 08:57 · Score: 1
  
  But for best results, you need to run a green magic marker around the rim.
  Seriously, if you want to compare to the vinyl wars, the real take-away is human beings like what ever they like, and it's possible to do something that's technically "better" that nevertheless has a negative subjective-impact... (myself, I couldn't care less if the "warm" sound I think I hear on vinyl is just surface noise effects-- if I like noisey better than clean, give me noisey).
  One hopes that they've got this covered in their tests, by using subjective response data to calibrate their techniques...
41. Re:Mostly... by doom · 2016-09-06 09:03 · Score: 1
  
  sssh...
  They're having fun.
42. Re:Mostly... by sexconker · 2016-09-06 09:13 · Score: 1
  
  If your encoder is more efficient when outputting 10 bpc data than 8 bpc data when given 8 bpc data as a source then your encoder is broken.
  Hint: Your 10-bit mode using higher-precision internal calculations than the 8-bit mode is broken.
  Anime people do this because it effectively acts like a low pass filter when you stretch your shit to 10 bits then encode at a bitrate low enough such that the 2 LSB get ignored 99% of the time. This works on traditional animation because of the reduced color palette and large, flat surfaces so you typically don't notice the quality loss.
  However, a decently-tuned noise filter would achieve the same result on an 8-bit encode, be more efficient, and maintain higher quality (whether you see it or not). Plus every damn device in existence accelerates 8-bit decoding (and encoding) and will work with it. Alternatively, start with a clean source
  Of course, when you only have a OTA/cable/sat feed, crunchyroll, or even a BluRay/DVD as your source, you're going to need to denoise first. Or, do like the clowns do and run it in 10-bit mode and let the encoder chop 99% of it back to 8-bit, but have overhead and wasted bits when keeping slight noise or gradients at 10-bit. Oh, and continue the asshattery and pipe it all out at 4:2:0 chroma subraping!
  Kids today don't even verify every field/frame by hand and don't know the horrors of variable frame rate, variable field order, telecine, etc. Get off my lawn, etc.
43. Re:Mostly... by CaptSlaq · 2016-09-06 09:19 · Score: 1
  
  The problem is it's the mindset and everyone seems to have it these days. "Oh, bandwidth isn't limited" "processors are more powerful" etc. You get a program built with 10 pieces of separate code that everyone failed to optimize and suddenly it's sucking 3x the bandwidth and 5x the processing power that it would have if everyone involved actually thought about optimization.
  Where I work we go back and refactor a lot of our code and queries when we have opportunities to do so and in some cases it's horrifying the waste that's been put up with. A SQL query that "works" but takes 30 seconds gets rewritten properly and now takes .3 seconds. Back when that was the only app on that server it ran faster so it was "no big deal" but now it saves hours of batch processing time per day. And this is EVERYWHERE. People wonder why their octa-core phones run barely faster than phones from 3 years ago? Shitloads of wasteful coding in those app design tools is my guess.
  That SQL query that "works" was effective for the time. If the (then) future hadn't gone the way that it did, that 30 seconds may have continued to be completely acceptable. Judging code on CURRENT use case misses the point of skipping premature optimization (and using that time saved on something else) when it's not needed.
  That said, there often comes a time when it's required. That's when you do the optimization. Which sounds like it's exactly what you've done.
  Working as intended.
44. Re:Mostly... by sexconker · 2016-09-06 09:26 · Score: 2
  
  If you care about storage space more than you care about quality, encoding to h265 is fine. Please use the cleanest source, though, unless you're a dumbass and you don't care about generational loss.
  10-bit encoding of 8-bit sources is retarded. But it's a thing they do, however, especially the anime kiddos. It effectively acts a variable denoise filter which is useful when they're ripping from crunchyroll, OTA/cable/satellite, or even BluRay. 99% of the time the content gets quantized back the same (or slightly worse) as with 8-bit, but when dealing with noise or a gradient it can rely on just using a higher precision.
  x264 also seems to perform some intermediary calculations at a higher precision when you run in 10-bit mode for some reason, reducing internal rounding/truncating/fuckating. Or at least it did. Not sure about x265.
  Of course, your decoder has to deal with fucking that back out to 8 bpc for display, and that process isn't defined in the standard, so good luck!
  With an 8-bit source, staying in 8-bit and properly tuning a denoise filter would yield better results.
45. Re: Mostly... by Malc · 2016-09-06 09:34 · Score: 1
  
  How many people have a 10-bit display? For most people, their renderer will convert it back to 8-bit and lose more quality in the process. By all means use 10-bit and the BT.2020 colourspace if your source material uses this, but otherwise don't waste your time.
46. Re:Mostly... by Greyfox · 2016-09-06 09:43 · Score: 1
  
  I was looking last month and couldn't find an encoding standard that all browsers support. Google wants you to drink their kool aid, and seems to only support VP8 and 9 and ogg audio formats. IIRC, Firefox and IE both support h.264 and AAC. None of the browsers seem to support UDP streaming at all.
  If I want to do zero-latency live streaming to just a few endpoints outside the browser, I found that mpeg2video and aac streaming over UDP encodes and transmits with the least amount of lag. Near as I can tell, it's pretty much instantaneous, over the fast LAN I'm working on. In theory, I could play that with the VLC plugin in-browser, on browsers that still support it. But so far I haven't seen that actually work.
  I have to admit that I didn't play around with flash all that much. It does seem like it's pretty much universal. Perhaps I should take another look at it...
  
  --
  I'm trying to teach myself to set people on fire with my mind... Is it hot in here?
47. Re:Mostly... by jdschulteis · 2016-09-06 10:28 · Score: 1
  
  The records have to be absolutely 100% completely free of dust or any other particles, otherwise the laser will read them as if they were the actual groove, leading to a lot of unwanted noise. A normal pickup pushes aside most of the dust.
  It's a neat idea, but it's much worse than a decent pickup on a normal turntable.
  Five lasers, but no vacuum to suck dust particles off the surface just before it passes under them?
48. Re:Mostly... by jedidiah · 2016-09-06 10:29 · Score: 1
  
  Converting is not free.
  Neither is replacing all of the decoders out there that can't decode the new format yet. Some of these decoders may be embedded in devices that consumers have no intention of replacing.
  Dumping a real standard on a whim is a bit of a bitch.
  
  --
  A Pirate and a Puritan look the same on a balance sheet.
49. Re:Mostly... by Anonymous Coward · 2016-09-06 11:05 · Score: 0
  
  The Edge browser does support H265 but surprise surprise it does not support many open formats.
  
  Edge supports VP9. By default, Edge disables VP9 if hardware accelerated decoding isn't present but you can override that behaviour in about:flags to enable it.
50. Re:Mostly... by Zaelath · 2016-09-06 12:40 · Score: 1
  
  I'm surprised the various players don't have a "vinyl" mode; all you'd need to do is add some hiss and the occasional pop.
51. Re:Mostly... by Anonymous Coward · 2016-09-06 12:49 · Score: 0
  
  in my experience bandwidth is _always_ limited.
  My phone has shitty bandwidth. (70 megabits LTE if uncongested, 2 megabits LTE when at lunch in the city)
  My home has shitty bandwidth (5-10 megabit DSL)
  My parents have shitty bandwidth (buy the cheapest plan with the most contention).
  Sure; it may be *possible* to get better bandwidth in every single one of these circumstances (except maybe the phone one - I'm with the "premium" carrier already and they really do have the least congestion).
  Bandwidth is always constrained at the edges.
52. Re:Mostly... by Anonymous Coward · 2016-09-06 12:56 · Score: 0
  
  The problem is the optimisation at the time of implementation could have been 15 - 20 minutes at the time of implementation, since you are working with the code at the time, theres no ramp-up speed where you try to figure out the actual use of the code before making your optimisations.
  As soon as you've spent 3 nights of DBA time hacking away at "why does this query take 24 hours+ to run I've cancelled it three times! raising a ticket"
  then another couple hours for the developer to eventually turn his mind back to the code he wrote (or worse yet; a colleague wrote) and finally fix it up. Hopefully he fully understood all the edge cases of the code he was optimising (because he had to learn it all again and pray the documentation was flawless - when have you seen that?).
  So you've wasted 3+ hours of DBA time identifying the issue, 2+ hours of developer time all of which _ALWAYS_ comes at a time when you are trying to do something else (remember; you only just started running this shitty code on some new dataset, which means you have a new project dumping this data out, which means you are busy with other shit and you really don't need to be wasting your time debugging this instead of the new stuff you are doing).
  Its a huge waste; when you could have spent 30 minutes 12 months ago to attempt to optimise all this shit.
  Sure; if its going to take you half a day to clean up the code you wrote perhaps you shouldn't spend the whole time there, but an extra half hour to an hour of developer time isn't going to kill a project (doubly so when your query runs in 3 minutes when it could run in 10 seconds).
53. Re:Mostly... by Bengie · 2016-09-07 00:37 · Score: 1
  
  If the (then) future hadn't gone the way that it did
  If there is anything that I have learned is if something can go wrong it WILL go wrong. Don't let it go wrong in the first place. Spend the extra 1 second and think about your code before you vomit your crap code into production.
  
  It isn't "premature optimization" until it makes it some degree harder to understand than the non-optimized version. Most of what people call "premature optimization" is really just writing correct code. Should I use String.EndsWith or String.Contains to find if a string has a certain suffix? Should I use an explicit cross join and filter in the WHERE clause or use inner joins? These are examples of the level of boneheadedness that most people write code. Don't get me started on multi-threading. If you don't find it intuitive, please don't do it.
  
  Most of the time I can make someone's code several factors faster with virtually zero effort while making it easier to read. And when I say "faster" I don't mean as in micro-benchmarking the code in simplistic situations, I mean production where the entirety of the code is being called many times on many threads. Sure, your "read the entire file into memory and write it back out" works fine in your simple tests, but throw it in production and the 400MiB files put massive pressure on memory when there are hundreds of jobs running at the same time all trying to load the entirety of files into memory before writing them out. STREAM the files.
  
  Then you have the issue of many times good code runs slower in synthetic benchmarks but runs faster in production. Everyone focuses on empirical evidence, but then compare apples and oranges when thinking their dev boxes or servers are the same as prod in that the computers are only running their code in tight loops
54. Re:Mostly... by Falos · 2016-09-07 03:24 · Score: 0
  
  Linda! Get the lawyers on teleconference! Tell them it's an emergency!
55. Re:Mostly... by Shirley+Marquez · 2016-09-07 04:34 · Score: 2
  
  They are comparing the bit rate of the streams at comparable image quality. They're not using MPEG2 now, that would be even less efficient than their current H.264 encoding.
  One problem is that few computers and streaming boxes have H.265 hardware decoding support. That means that the decoding has to be done in software. (The latest generation of video cards DOES include H.265 decode support.) At best that means higher power consumption; at worse it means degraded playback because the CPU isn't up to the task. (Decoding H.265 requires a lot more processing power than H.264, which in turn needs more than MPEG2.) So it's unlikely that Netflix will switch to H.265 for 1080p streams and lower. They'll reserve it for 4K content, because the players for that should be capable of the decoding.
  That big a reduction in bit rate is good all around. Fewer delays while streaming, less network congestion for everybody, and lower ISP bills for Netflix.
56. Re:Mostly... by Shirley+Marquez · 2016-09-07 04:41 · Score: 1
  
  Netflix isn't going to take the existing H.264 files and re-encode them with H.265; that would indeed look worse because of additional generation loss by non-lossless codecs. They will go back a generation and re-encode whatever the source was that they made the H.264 files from. For recent films that's likely to be either the DCP file used for theatrical presentation or a UHD master that was made for disc release. The latter will be in some high-bandwidth codec such as ProRes, which is then converted (and if necessary downsampled) for DVD, Blu-Ray, and Ultra Blu-Ray release.
57. Re:Mostly... by MercTech · 2016-09-07 09:18 · Score: 1
  
  Um, having sold high end audio back in the day I can attest that the "laser" stylus did not use the laser for pickup from the grooves but to accurately automate tracking. A laser tracking tangential tone arm where there was no stylus pressure to track a tone arm actually did make a noticeable improvement in sound quality and a huge decrease in record wear.
  But, dang, how many people in the late 70s or early 80s could pony up a grand and a half for a turntable. Not for a system; just the turntable. ... thinking of the Thorens and Bang & Olufsen units.
  Now that ELP unit cited, which isn't from the old days of vinyl, uses laser diffraction at a high sample rate to give a rather low loss digital signal for processing. http://elpj.com/
  Not exactly analog but quite damned close.
  I have to think that the price in current dollars of $15,000.00 is quite the equivalent to the $1500.00 for the laser tracking turntables of the late 1970s. (Inflation. I new Mercedes was $10K back then. Yes, inflation has been that bad.)
  
  --
  NRRPT/RCT
58. Re:Mostly... by SivDotnet · 2016-09-07 20:46 · Score: 1
  
  Off topic, but related.
  Unlike me you sound knowledgeable on this subject, can you explain to me why it is in the 21st century we still have issues with lip synch on streamed video and movies on DVD and Blu-Ray players. The amount of times I watch a video and the video is either ahead or behind the action on screen drives me mad. I would have thought by now there was a codec that could constantly check some kind of time marker in the video file that keeps the video and audio together.
  Is it the codec, the video players we have on PCs or just video encoding techniques that are just not very good?
  Siv
  
  --
  Martley, Near Worcester UK.
59. Re:Mostly... by Fringe · 2016-09-10 11:22 · Score: 1
  
  Umm... no. The real number is about 25%. Real world tests. But you have to do REAL world tests.
  A few years ago I was at the VP8 conference. Google was touting how much bandwidth VP8 could save over H.264. They said they could give identical quality with a 5Mbps VP8 1080p stream as with a 10Mbps H.264 stream. Well, yes... you get about the same quality with a 4Mbps H.264 stream at 1080p as with the 10Mbps. But they did freeze when asked if they would pit the quality of VP8 doing a 1.2Mbps stream against H.264 doing a 2.4Mbps stream.
  You've got to know the context. For our tested real world content, same quality, against optimized H.264, it's about 25%, pretty consistently.
60. Re:Mostly... by Luthair · 2016-09-11 08:50 · Score: 1
  
  Did you even read this thread? Its in response to someone specifically talking about re-encoding from a lossy format.
61. Re:Mostly... by CaptSlaq · 2016-09-13 09:24 · Score: 1
  
  If the (then) future hadn't gone the way that it did
  If there is anything that I have learned is if something can go wrong it WILL go wrong. Don't let it go wrong in the first place. Spend the extra 1 second and think about your code before you vomit your crap code into production. It isn't "premature optimization" until it makes it some degree harder to understand than the non-optimized version. Most of what people call "premature optimization" is really just writing correct code. Should I use String.EndsWith or String.Contains to find if a string has a certain suffix? Should I use an explicit cross join and filter in the WHERE clause or use inner joins? These are examples of the level of boneheadedness that most people write code. Don't get me started on multi-threading. If you don't find it intuitive, please don't do it. Most of the time I can make someone's code several factors faster with virtually zero effort while making it easier to read. And when I say "faster" I don't mean as in micro-benchmarking the code in simplistic situations, I mean production where the entirety of the code is being called many times on many threads. Sure, your "read the entire file into memory and write it back out" works fine in your simple tests, but throw it in production and the 400MiB files put massive pressure on memory when there are hundreds of jobs running at the same time all trying to load the entirety of files into memory before writing them out. STREAM the files. Then you have the issue of many times good code runs slower in synthetic benchmarks but runs faster in production. Everyone focuses on empirical evidence, but then compare apples and oranges when thinking their dev boxes or servers are the same as prod in that the computers are only running their code in tight loops
  Bad code and bad coders exist. The bell curve suggests that some 50% of developers and code fall on the wrong side of that. I may be one of them, who knows.
  I don't disagree with your assessment. As I've learned in my years of working as a sysadmin and developer, there's precious little code that can't have some sort work done on it for readability and/or performance's sake. Many (myself included) have lost sight of the forest for the trees time to time. Sometimes you get people doing things that they've never had to do before. Sometimes you wind up with a problem out of your league that has to be solved. It happens. Problems still have to get solved/code written though.
  The other thing I've learned is that "Delivered puts food on the table. Perfect is the enemy of delivered." I always try to push the best code I can out the door, but sometimes I just don't have the experience or knowledge to write the perfect solution to everything I work on. I think everyone runs up on this from time to time. Anyone who claims otherwise is either lying or has stagnated in their career/work.
  The best way I know to AVOID pushing crap out the door is to have a peer review done, preferably by a peer who is better than you. Many eyes and all. For many years, I had no peers to review and see the potential problems, working as a 1 man code shop.
  That said, to address your example, slurping an entire file into RAM is a pretty dumb idea, if it's able to be processed in a window. I'm sure many people have horror stories of "wow, that's a dumb idea" that they can impart, myself included. Fix the problem, move on. If the dev who wrote the offending code is available, ask them what they were trying to do. Make it a teachable moment. Make the world better. [insert something about sunshine and rainbows here].
  Or not. I'm just another user account on Slashdot.
so what? by Anonymous Coward · 2016-09-06 03:26 · Score: 0

wasn't that a whole point for comin up with x265 in a first place?
1. Re:so what? by Anonymous Coward · 2016-09-06 03:36 · Score: 0
  
  No, the point of a new standard is to replace old, expiring patents with fresh new ones, so the intellectual property gravy train keeps rolling on.
2. Re:so what? by GuB-42 · 2016-09-06 04:13 · Score: 3, Interesting
  
  This is not the case of video codecs.
  Video is a huge bandwidth hog and small improvements can really make a difference. This is why we still use JPEG and MP3 but video benefits from the latest technologies. It is also why Vorbis (audio) is much more successful than Theora (video). Both are patent-free formats from xiph.org.
  Additionally, with hardware improving, more advanced compression algorithms can be used. For example entropy coders are mostly a performance/ratio tradeoff and newer standards tend to use more advanced schemes. Not that these couldn't have been used before, but the hardware requirement were too steep at that time. And you can't really put "insert preferred encoding scheme here" in your standard to make it future proof, because it wouldn't be a standard. All parts have to work together. You don't want to specify a super duper filter that melts CPUs and botch the job with a crappy entropy coder, you have to balance each part to get the best of your target hardware.
3. Re:so what? by phorm · 2016-09-06 05:11 · Score: 1
  
  Even with JPEG and non-video compression, there's a lot of optimising that can be done that often isn't. I've seen and managed tons of sites that seem to think that every has big internet pipes, so it's perfectly OK to use a 2MB un-optimized image as the main backdrop for your site (or worse, a 2MB 4k resolution image that is reality scaled down when actually used). Throw that together with ever-increasing web libraries/toolkits and sometimes you're several megs in just to load a single page. Yes, there's often a somewhat optimized "mobile" version but often it doesn't load automatically on all devices, looks like ass, or is missing functionality. Enabling an optimised compression profile does help this somewhat.
  Seriously though, web-devs, you shouldn't need a sysadmin to tell you that your 2MB banners and several megabytes of javascript libraries, plus a brick-ton of 3rd-party libs is *not* making for a good web experience.
4. Re:so what? by NotInHere · 2016-09-06 05:27 · Score: 1
  
  This is why we still use JPEG and MP3 but video benefits from the latest technologies.
  They also remain because of the same reason ipv4 remains: noone wants to move first. There are better codecs for still images (webp) and for audio (AAC or opus), but nobody uses them as the original formats weren't available. Heck, its hard enough for us to get rid of gifs for animated images.
5. Re:so what? by Luthair · 2016-09-06 05:43 · Score: 1
  
  The tyranny of backwards compatibility dictates we can never use anything new because some nitwit is using 10-year old software, of course they will never bother to upgrade unless things start breaking so....
6. Re:so what? by Anonymous Coward · 2016-09-06 06:10 · Score: 0
  
  The old Windows mindset dooms us forever.
7. Re:so what? by thegarbz · 2016-09-06 07:19 · Score: 2
  
  It's also a tyranny of "good enough". Seriously when a 40mpxl image comes down as a 10MB JPEG and look identical to any better format it really doesn't make much of a difference. Doubly so that most images are not 40mpxl.
  Video on the other hand is not yet good enough.
8. Re:so what? by epyT-R · 2016-09-06 08:24 · Score: 1
  
  ..and sometimes the old stuff is actually better, eg: pre 2005 desktop interfaces vs post 2005..
9. Re:so what? by dave420 · 2016-09-06 19:49 · Score: 1
  
  The incredibly arbitrary nature of your claim should be some indication that it is factually incorrect.
10. Re:so what? by Anonymous Coward · 2016-09-13 19:38 · Score: 0
  
  Claiming the oposite is equally arbitrary.
Another Google Project Not Worth The Hype by alternative_right · 2016-09-06 03:28 · Score: 1

There seem to be a lot of these lately. Why is it that as companies get bigger, they get less competent, despite having hired more of the competent people?

--
Alternative Right.
1. Re:Another Google Project Not Worth The Hype by mrclevesque · 2016-09-06 03:45 · Score: 2
  
  "Why is it that as companies get bigger, they get less competent, despite having hired more of the competent people?"
  Maybe it's the increased number of levels of management and the inherent increase in distance between any two levels of management.
2. Re:Another Google Project Not Worth The Hype by Anonymous Coward · 2016-09-06 03:48 · Score: 0
  
  Because the useless people get pushed into management roles that the nerds don't want to deal with. Unfortunately, that comes back to bite the nerds on the ass.
3. Re:Another Google Project Not Worth The Hype by TigerTime · 2016-09-06 04:15 · Score: 5, Informative
  
  You realize we're comparing a FREE option vs a PAID option. As a business trying to save money here/there, I'd rather go with the free one to be honest.
  Additionally, the title of this post is a bit misleading for what Netflix actually found. h.265 was better than VP9 in 4K content, but when it came down to 1080p and lower resolutions, VP9 did just as good or better than h.265. 1080p will STILL rule the streaming market for the foreseeable future, so VP9 is definitely relevant here.
  Quote from Netflix on their blog regarding this:
  
  Here’s a snapshot: x265 and libvpx demonstrate superior compression performance compared to x264, with bitrate savings reaching up to 50% especially at the higher resolutions. x265 outperforms libvpx for almost all resolutions and quality metrics, but the performance gap narrows (or even reverses) at 1080p.
  http://techblog.netflix.com/20...
4. Re:Another Google Project Not Worth The Hype by OneHundredAndTen · 2016-09-06 04:31 · Score: 1
  
  It's the levels of management. Management does very little of use, and so do managers. They are of course aware of that, and they have to create tasks the purpose of which is nothing but justify their jobs. They also want more management, for there is strength in numbers: it is very easy to find out what management position(s) are entirely useless when you have few of them; when you have many, it becomes a much more difficult issue.
5. Re: Another Google Project Not Worth The Hype by Anonymous Coward · 2016-09-06 04:57 · Score: 0
  
  That's actually not correct. 1080p was the highest tested resolution, and was the resolution where they performed almost identically. There was no testing of 4K content. H265 (x265 specifically, because the specific encoder implementation of a standard often matters much more than what tools that standard gives it to work with) significantly outperformed all other standards at the SD and 720p resolutions regardless of bitrate target or quality metric.
6. Re:Another Google Project Not Worth The Hype by StreamingEagle · 2016-09-06 05:00 · Score: 1
  
  It's true that the H.265 format (like H.264) is patent-encumbered, and that device manufacturers need to pay patent license royalties. But these aren't the only costs. Don't ignore the cost of bandwidth and storage, which can easily exceed the cost of a one-time patent license royalty. How about the quality of experience? If you're in the movie streaming business, QoE is paramount. By the way, Netflix didn't test 4K content. The tests that seemed to show that VP9 was as good or better than x265 were not valid results. The most valid results (VMAF comparing visual-quality tuned encodes) showed x265 was ~20% more efficient than VP9. From the article above "I asked Netflix which set of results they felt was most significant. Their response was, “We believe that VMAF results will have the best correlation to user perception of quality. We use this metric, and sanity-check against other metrics (PSNR, SSIM, VIF, etc.) internally.” In other words, according to Netflix, the results shown in Figure 1 were the most relevant of the three."
7. Re:Another Google Project Not Worth The Hype by freeze128 · 2016-09-06 05:06 · Score: 2
  
  You realize we're comparing a FREE option vs a PAID option. As a business trying to save money here/there, I'd rather go with the free one to be honest.
  That's pretty shortsighted, even for a business. If you factor in the bandwidth costs of delivering 20% more data, using the paid CODEC might actually make better financial sense.
8. Re:Another Google Project Not Worth The Hype by Anonymous Coward · 2016-09-06 05:10 · Score: 0
  
  Most making comments here don't seem to realize this, h.265 licensing issues is what is hindering its adoption. h.265 was made for the main reason to make money. If someone is willing to pay for licenses to use h.265 then that is all fine and dandy, but that is not likely to happen in web browsers so that is why we use VP9 and other free alternatives.
9. Re:Another Google Project Not Worth The Hype by Anonymous Coward · 2016-09-06 05:12 · Score: 0
  
  Where is your data to back up your statements?
10. Re:Another Google Project Not Worth The Hype by MachineShedFred · 2016-09-06 05:15 · Score: 1
  
  H.265 may be paid, but if the bandwidth saved per annum by using H.265 saves more money than the cost of licensing, then you come out ahead.
  
  --
  Slashdot still doesnâ(TM)t support Unicode after it was added to the HTML standard in 1997.
11. Re: Another Google Project Not Worth The Hype by Billly+Gates · 2016-09-06 05:32 · Score: 1
  
  Also in 5 years everyone will have data caps whether we like it or not as their is too much money to be made. So this is important to us too.
  Unless we live in these so called civilized counties that are not bought out that I hear about
  
  --
  http://saveie6.com/
12. Re:Another Google Project Not Worth The Hype by nine-times · 2016-09-06 05:37 · Score: 1
  
  You realize we're comparing a FREE option vs a PAID option. As a business trying to save money here/there, I'd rather go with the free one to be honest.
  Sounds like a sloppy way to try to save money. The smart thing would be to compare the cost of the paid option to the cost of the extra bandwidth needed for the less efficient free version, as well as any other problems the "free" version might cause. "Free" only saves money if when it's not causing you to incur greater costs elsewhere.
13. Re:Another Google Project Not Worth The Hype by StreamingEagle · 2016-09-06 05:48 · Score: 1
  
  In the article... http://www.streamingmedia.com/...
14. Re:Another Google Project Not Worth The Hype by Anonymous Coward · 2016-09-06 06:47 · Score: 0
  
  This is very important information that the top post lacks. The vast majority of content is still 1080p or lower, so that actually makes it sound like VP9 is probably the one to pick right now. A lot of content still isn't even full 1080p, so it's likely to be quite a few years before 4k is really a huge percentage of streaming media. Sure, maybe by then x265 beats VP9 at lower resolutions, but it's also possible that by then VP9 beats x265 at 4k.
  Seriously, which one makes sense to pick? The one that's likely to be best for the vast majority of content now, or the one that is best for possible 40% of content in 10 years.
15. Re:Another Google Project Not Worth The Hype by Bengie · 2016-09-06 07:01 · Score: 1
  
  Bandwidth is pretty cheap. It only represents a few pennies on your $10/m Netflix bill. H.265 would not only have to save money, but save enough money to make the red-tape of licensing worth it. And once you become dependent on it, they may raise the fees, uncertainty. The cost of raw bandwidth drops nearly 50% year over year. Saving 20% on bandwidth is like waiting 1/2 a year and getting your new bandwidth prices.
16. Re:Another Google Project Not Worth The Hype by bloodhawk · 2016-09-06 09:07 · Score: 1
  
  Given Netflix is a business the option is clearly h.265 as a 20% reduction in streaming bandwidth for the fastest growing content medium is pretty freakin massive.
17. Re:Another Google Project Not Worth The Hype by bloodhawk · 2016-09-06 09:09 · Score: 1
  
  for Netflix bandwidth is a MASSIVE cost. given the relatively tiny cost of licensing H.265 it is a no brainer and the end user gets the benefit of saving a few bucks on bandwidth too (though as you say that part is relatively insignificant).
18. Re:Another Google Project Not Worth The Hype by Anonymous Coward · 2016-09-07 03:34 · Score: 0
  
  They think they hire the best people, but in reality, they don't. End of story.
19. Re:Another Google Project Not Worth The Hype by Bengie · 2016-09-07 14:01 · Score: 1
  
  A "massive" cost that is a small percentage of their over all costs. I think it was Nasdaq that had a report breaking down Netflix' costs that showed bandwidth was pennies on the dollar before then went Open Connect. Most of Netflix' costs have to do with content licensing. Reducing bandwidth is more of a scalability issue and opportunity cost issue, since customers have crap connections and unhappy customers will not be customers for long. You also have the whole "cool factor" from the tech side of things and when you're consuming 1/3rd of the Internet, it's your duty.
h.265 can be less lossy by cozytom · 2016-09-06 03:33 · Score: 1

As long as folks don't just re-encode h.264 content. Record things in with an x265 encoder, at the beginning, and have more actual bits in the B and P frames.
1. Re:h.265 can be less lossy by Tx · 2016-09-06 03:42 · Score: 1
  
  That depends on the bitrate of the source video. For example, it would certainly be reasonable to compress h.264 video from a BluRay disc to h.265, since people already compress that to h.264 with what are generally considered to be acceptable results.
  
  --
  Oh no... it's the future.
Yeah... by Anonymous Coward · 2016-09-06 03:34 · Score: 0

20% less bandwidth, but always more blurry.
Re:Frosty piss by greenfruitsalad · 2016-09-06 03:42 · Score: 0

a well mastered upscaled DVD will easily have better picture than bitstarved x265 off teh l337 torr3ntz
What about VP10? by SirMasterboy · 2016-09-06 03:44 · Score: 1

I thought VP10 was supposed to be the real competitor to HEVC.
1. Re:What about VP10? by Merk42 · 2016-09-06 03:49 · Score: 3, Informative
  
  I don't quite understand the situation, but I'm guessing it won't exist?
  
  However, Google decided to incorporate VP10 into AOMedia Video 1 (AV1). The AV1 codec will use elements of VP10 as well as the experimental formats Daala (Xiph/Mozilla) and Thor (Cisco).[72][73] Accordingly, Google has stated that they will not deploy VP10 internally or officially release it, making VP9 the last of the VPx-based codecs to be released by Google.[74]
2. Re:What about VP10? by NotInHere · 2016-09-06 04:20 · Score: 3, Informative
  
  Well that AV1 codec will have a much higher chance for success as more industry partners are involved, and it will get better hardware decoding support (both by the vendors, and by the codec itself being designed in a way with hardware decoding in mind). Netflix is part of AOM as well. The only bigger company of significance which is _not_ member of AOM is apple, who suprise suprise sits at the MPEG table and makes bucks with their H.265 patents.
3. Re:What about VP10? by TigerTime · 2016-09-06 04:32 · Score: 1
  
  Correct. It's the foundation for the new format, but will be enhanced further using Daala, Thor, and Opus.
  Considering members of the new OpenAlliance consist of just about all browser manufactures (Microsoft, Google, Mozilla), chip manufacturers (Intel, AMD, ARM, Nvidia), and major content providers (Netflix, Amazon, Google), it's going to be widely supported/adopted quickly.
  h.265 might have an advantage right now with the current iteration, VP9, but if the industry has put their weight behind this free Open Source version, you won't see as much of the proprietary encoding.
Advanced VMAF assessment tool by Anonymous Coward · 2016-09-06 03:48 · Score: 0

Why do you need an advanced tool to measure this? Just count the bits. Done.
1. Re:Advanced VMAF assessment tool by Anonymous Coward · 2016-09-06 04:34 · Score: 0
  
  Why do you need an advanced tool to measure this? Just count the bits. Done.
  one word: Quality
2. Re:Advanced VMAF assessment tool by UnknownSoldier · 2016-09-06 04:54 · Score: 1
  
  > Just count the bits. Done.
  That is naive. Perception is *not* uniform, that is non-linear, and I'm not even talking about gamma correction.
  Can you tell the difference in quality between:
  * These 2 grays? 0xFFFFFF and 0xFEFEFE ?
  * What about 0xFFFFFF and 0xFDFDFD
  * Or between 0xFFFFFF and 0xFCFCFC
  It is possible to encode these in the same number of bit but yet one will be more accurate then the other(s).
Bits... by Anonymous Coward · 2016-09-06 03:49 · Score: 0

Here's my super compressed video:
1
Patent pending!
But last week they said. by Anonymous Coward · 2016-09-06 04:03 · Score: 0

Just last week the news was the opposite at 1080p video. So who is believe any of this? I personally don't use VP9 but I don't see the savings in my encodings under 265. While only one of my devices (TVs) supports 265 I'm not using it because, as I said, I don't see any savings.
1. Re:But last week they said. by StreamingEagle · 2016-09-06 04:23 · Score: 2
  
  You must be referring to an article on Toms Hardware. The journalist was referring to the same Netflix study, but he was confused by the results, and he jumped the gun. He changed his title the next day. In the Netflix study they used x264 and x265 settings that are optimized for visual quality, and they also did test encodes with settings optimized for PSNR measurement. But then Netflix actually published results of PSNR measurements using the visual quality optimized encodes, which are not meaningful results. On these results, for 1080P content, VP9 appeared to be slightly better than x265. What matters most with video encoders is the actual visual quality they can produce at any target bit rate. Objective measurements like PSNR and SSIM don't correlate strongly with human subjective visual quality testing. Netflix sponsored development of a new visual quality tool, VMAF, which correlates with human subjective testing much more strongly. With VMAF, Netflix showed that x265 produces identical quality to VP9 at ~ 20% lower bit rates.
2. Re:But last week they said. by Lennie · 2016-09-06 04:30 · Score: 1
  
  This is still true:
  "Quote from Netflix on their blog regarding this:
  Here’s a snapshot: x265 and libvpx demonstrate superior compression performance compared to x264, with bitrate savings reaching up to 50% especially at the higher resolutions. x265 outperforms libvpx for almost all resolutions and quality metrics, but the performance gap narrows (or even reverses) at 1080p."
  https://entertainment.slashdot...
  
  --
  New things are always on the horizon
3. Re:But last week they said. by StreamingEagle · 2016-09-06 05:03 · Score: 1
  
  The only results that showed VP9 matching x265 were with PSNR measurements of Visual Quality optimized encodes. These are not valid measurements (if you want to measure PSNR of x264 or x265, you need to use --tune psnr, which Netflix did for a different set of encodes). And here's a quote from the article above... "I asked Netflix which set of results they felt was most significant. Their response was, “We believe that VMAF results will have the best correlation to user perception of quality. We use this metric, and sanity-check against other metrics (PSNR, SSIM, VIF, etc.) internally.” In other words, according to Netflix, the results shown in Figure 1 were the most relevant of the three."
Re:Frosty piss by Guillermito · 2016-09-06 04:16 · Score: 1

In my totally subjective and anecdotal experience the perceived quality of different mediums and resolutions goes like this:
4K Blu-ray > Upscaled HD Blu-Ray > 4K Netflix/Amazon streaming = Native resolution HD Blu-ray > Upscaled HD streaming > Native resolution HD streaming > Anything DVD
VP9 Equal or Better at 1080p and Up by Anonymous Coward · 2016-09-06 04:20 · Score: 0

Interesting spin.
Netflix also found that for resolutions of 1080p and higher, VP9 was equal or better than h265.
http://www.tomshardware.com/ne...
Which is totally believable because h265 was intentionally engineered for low resolution, low bitrate applications while VP9 was not.
1. Re: VP9 Equal or Better at 1080p and Up by Anonymous Coward · 2016-09-06 05:14 · Score: 0
  
  1) 1080p was the highest resolution they tested, so you clearly haven't looked that closely at the results.
  2) The H265 standard was designed to be more efficient at super high resolutions. That's why it has much larger possible coding units than H264, and why work was also done with the motion vector analysis.
  In short, RTFS and stop spreading FUD.
Also significant is CPU burden by Kludge · 2016-09-06 04:25 · Score: 2

I have noticed that x265 requires much more CPU for encoding AND decoding than x264. For example, my slightly aged laptop will not handle playing my 1080p x265 streams.
1. Re:Also significant is CPU burden by jandrese · 2016-09-06 04:28 · Score: 3, Informative
  
  The intention is that the decoding is handed off to the GPU. Doing x265 on the CPU is inefficient, and completely impractical on devices like phones and tablets.
  
  --
  
  I read the internet for the articles.
2. Re:Also significant is CPU burden by Anonymous Coward · 2016-09-06 04:28 · Score: 0
  
  This is always something to be chased. Yes, devices from today will need software decode. Kaby Lake processors include decode for this - so it gets better. But you are correct that it will be more demanding for existing devices.
3. Re:Also significant is CPU burden by squiggleslash · 2016-09-06 04:50 · Score: 5, Informative
  
  Your slightly aged laptop probably has a built-in H.264 decoder, which will skew the results somewhat. Most graphic chipsets for the last eight years have included the functionality.
  
  --
  You are not alone. This is not normal. None of this is normal.
4. Re:Also significant is CPU burden by Bengie · 2016-09-06 05:28 · Score: 1
  
  Of course you did. Nearly all CPUs and GPU support accelerating x264, but not x265.
5. Re:Also significant is CPU burden by Anonymous Coward · 2016-09-06 05:31 · Score: 0
  
  A bit of a shame really. Here we could have something pushing the envelope of CPU performance. Instead we get a chunk of silicon that can't be used for anything except x265, which I'm sure will have Windows drivers and be supported in Flash player, and maybe will get experimental Linux support 2 years after. And to make it worse, who is going to bother with optimising the software decoder then?
6. Re:Also significant is CPU burden by Bengie · 2016-09-06 07:40 · Score: 2
  
  The fixed function ASIC is magnitudes faster, more efficient, so few transistors, it's practically free to add. It's almost like saying that dedicated floating-point is "a shame" because they could just make the CPU faster and just emulate it. This is just one of those cases were ASICs can beat the crap out of any generalized implementation, even SIMD.
7. Re:Also significant is CPU burden by jedidiah · 2016-09-06 10:23 · Score: 1
  
  GPU video decoding support has been available for Linux for quite a long time now. That includes x265 too.
  Some vendors are better than others of course, but even the worst sand baggers have finally managed Linux support.
  Optimizing the software decoder like anything else will depend on motivation. Although the ffmpeg guys seem to be highly motivated and pretty much everyone depends on them (including Windows users).
  
  --
  A Pirate and a Puritan look the same on a balance sheet.
8. Re:Also significant is CPU burden by jedidiah · 2016-09-06 10:25 · Score: 1
  
  > Of course you did. Nearly all CPUs and GPU support accelerating x264, but not x265.
  Even without GPU decoding, most CPUs have gotten powerful enough to decode h264 without any special help.
  h264 just got OLD, much like mpeg2 did.
  Now we have the new shiny shiny that's almost gauranteed to choke general purpose processors just like it's predecessors used to.
  
  --
  A Pirate and a Puritan look the same on a balance sheet.
9. Re:Also significant is CPU burden by TeknoHog · 2016-09-06 10:59 · Score: 1
  
  we get a chunk of silicon that can't be used for anything except x265, which I'm sure will have Windows drivers and be supported in Flash player, and maybe will get experimental Linux support 2 years after.
  I watch H.265 videos with MPlayer on Linux, using an Nvidia GPU for the decoding. Admittedly, it's with the closed Nvidia drivers, but apparently the free drivers also handle the video decoder. It's dead easy since the VDPAU interface is fully open -- doing the same on Intel or AMD GPUs needs some extra work, and the results are not as nice. Of course, not all GPUs have the decoders in the first place.
  
  --
  Escher was the first MC and Giger invented the HR department.
10. Re:Also significant is CPU burden by Shirley+Marquez · 2016-09-07 04:50 · Score: 1
  
  The latest generation of desktop and laptop CPUs does, including NVidia GTX 10x0, ATI RX4x0, and the integrated GPUs in new Intel and AMD CPUs. But there is a lot of installed base that lacks H.265 hardware decoding. Over on the mobile side, the Snapdragon 820 has it but I doubt the previous generation does.
What the hell is the VMAF assessment tool? by Solandri · 2016-09-06 04:34 · Score: 4, Informative

All these codecs allow you to choose the bitrate, so efficiency is meaningless without a common basis for comparison. In this case it turns out they mean efficiency at the same video quality. But video quality is a completely subjective thing - how can you compare it in a reproducible manner? So I dug into how Netflix is deterministically measuring something subjective. That in itself is a pretty fascinating read.

tl;dr - they took subjective test results from showing video samples to people, then used machine learning to develop an algorithm which produced similar results.
1. Re:What the hell is the VMAF assessment tool? by Maury+Markowitz · 2016-09-06 04:54 · Score: 2
  
  "how can you compare it in a reproducible manner"
  If you bother to look it up, you'll see exactly how this is done.
  It's widely used and there are numerous automated benchmarking systems.
2. Re:What the hell is the VMAF assessment tool? by Anonymous Coward · 2016-09-06 05:52 · Score: 0
  
  "how can you compare it in a reproducible manner"
  If you bother to look it up, you'll see exactly how this is done.
  WTF? In the very next sentence after what you quoted, the poster DID state that they looked it up, and in fact provided a link to an article, which was described as "fascinating".
  Don't post angry.
3. Re:What the hell is the VMAF assessment tool? by Anonymous Coward · 2016-09-06 05:59 · Score: 0
  
  he did look it up, even posted a link. did you even read the whole post?
4. Re:What the hell is the VMAF assessment tool? by Anonymous Coward · 2016-09-06 06:42 · Score: 0
  
  Do you completely lack reading comprehension?
5. Re:What the hell is the VMAF assessment tool? by Anonymous Coward · 2016-09-06 06:45 · Score: 0
  
  Did you... read the post you're replying to?
6. Re:What the hell is the VMAF assessment tool? by doom · 2016-09-06 08:51 · Score: 1
  
  If you bother to look it up ...
  
  And if you'd bothered to finish reading the post, you would see that he did look it up, and gave us a link, and a one-sentence summary.
  Accusing someone for being lazy when you can't read four sentences may be a new low in internet history.
Is that all? by Maury+Markowitz · 2016-09-06 04:54 · Score: 1

"The 20% is just over VP9."
So, basically, VP9 offers little to no advantage over 264, while even 265 is somewhat limited.
That strikes me as somewhat sad, considering all the verbiage wasted by Google on the licensing issue.
1. Re:Is that all? by Anonymous Coward · 2016-09-06 05:36 · Score: 1
  
  VP9 is advertised as competing with H.265, but on specs it is really just a half generation ahead of H.264. It beats H.264 significantly in some areas and slightly in others, but the licensing is vastly cheaper for encoding of VP9 (free) versus H.264 (2 cents per video sales, or for streaming an average of about 5 cents per subscriber)
  I'd use H.265 over VP9. But I wouldn't use H.264 over VP9. (I wouldn't use VP8 at all in this day and age)
2. Re:Is that all? by StreamingEagle · 2016-09-06 05:52 · Score: 1
  
  Read the article. x265 is roughly TWICE as efficient as x264. That means that video bandwidth can be cut in half. Given that more than 70% of all bits crossing IP networks (private and public) are video, that is an astounding amount of bandwidth that could be freed up for better purposes.
3. Re:Is that all? by Bengie · 2016-09-06 07:14 · Score: 1
  
  Umm, no. If you click on the link and look at the first graph, it clearly shows VP9 is about 17% better than 264 at 360p, 32% better at 720p, and 43% better at 1080p. VP9 would be a win over 264, but 265 is an additional 20% more.
FTFY: Another FOSS project not worth the hype by Anonymous Coward · 2016-09-06 05:09 · Score: 0

Free and Open Source software has been hyped for decades now as supposedly a "better way to make software" but there are an almost endless number of examples of this simply not being the case. Linux on the desktop, Firefox as a browser, GIMP for image editing, openoffice for word processing, the list goes on and on. I think we need to move past the "open source is a better way to make software" since that claim clearly does not stand up to critical examination. open source in fact appears to be a significantly worse way of developing good software. The only people it seems to help are those companies who like having a huge amount of freely usable code harvestable from github to add to their proprietary projects.
1. Re:FTFY: Another FOSS project not worth the hype by Anonymous Coward · 2016-09-06 05:46 · Score: 0
  
  You realize all three encoders tested (x265, libvpx, x264) are open-source?
2. Re:FTFY: Another FOSS project not worth the hype by Anonymous Coward · 2016-09-06 06:03 · Score: 0
  
  All of those things you mention are actually really nice for the money....
AV1 will change that by Anonymous Coward · 2016-09-06 05:15 · Score: 0

once it's finalized, and very importantly, once there's common hardware support for it. It could take a year, or several, and AFAIK we're still using software decoding for VP8, VP9, H264 etc.
1. Re:AV1 will change that by Anonymous Coward · 2016-09-06 05:30 · Score: 0
  
  > It could take a year, or several, and AFAIK we're still using software decoding for VP8, VP9, H264 etc.
  Lol no, pretty much every STB, RPi, HTPC hardware decodes H264.
2. Re:AV1 will change that by NotInHere · 2016-09-06 05:31 · Score: 1
  
  VP9 and H264 have hardware decoders already. You only have to buy recent hardware :). Even H265 has, in the iphone 6.
  As all graphics chip makers (Intel, AMD, nvidia) are sitting on the AV1 table, hardware support for it will be almost guaranteed.
HTML5 - Video by DrYak · 2016-09-06 05:15 · Score: 5, Informative

Speaking of which (HTML5 Video and Netflix):
The IETF has a working group to produce a new gen video codec "NetVC" (Designed to be easy for wide adoptions, as the previous efforts of the IETF like Opus for audio).
The main candidate is by a group called "AOMedia" (association for openmedia), working on AV1 (AOMedia's Video codec 1).
The association includes:
- Google (of Youtube fame) : They are using their current development as a base for AV1 (what would have become VP10 if there wasn't this whole NetVC story).
- Xiph (of Vorbis and Opus fame, with also contributions toward Flac, Speex, etc.) : They are developing a very interesting project called Daala, and they ended up also contributing the innovation done for Daala into AV1.
- Cisco : They gave what they have developed for their Thor codec also into AV1.
Netflix has also joined the AOMedia and they are investing resources into it.
Same with several browser makers (including Mozilla).
With all the people involved:
- you know there's some interesting performance coming (given the brains involved here, given past successes like Opus, and given the promising results of research projects like Daala).
- given that 2 top content providers like Google (Youtube) and Netflix are on board, there's a high chance of seeing deployment of the new codec.
- given that browser makers like Google (chrome), Mozilla, and Microsoft (Edge) are on board, there's a high chance of seeing browser support for the new codec.
- given that hardware chip maker like ARM, Intel, AMD, Nvidia, etc. are on board there's going to be hardware decoding support.
(Adobe is on board too, so browser support is guaranteed for the Widevine DRM plug-in required by Netflix' licensors. Not that it matters that much, because that part of HTML5 Video is already defined and deployed everywhere, except maybe with Firefox on Linux which is a bit delayed)
But you know that this looks promision,
and maybe same time next year, we'd be reading summaries along the lines of "Netflix and Google find AV1 20% more efficient than HEVC/H.265" "And also cheaper, royalty-free and widely supported"

--
"Sufficiently advanced satire is indistinguishable from reality." - [Tips: 1DrYakQDKCQ6y52z6QbnkxHXAocMZJE61o ]
1. Re:HTML5 - Video by swillden · 2016-09-06 15:35 · Score: 1
  
  Adobe is on board too, so browser support is guaranteed for the Widevine DRM plug-in required by Netflix' licensors.
  Google owns Widevine, not Adobe. Did you mean Primetime?
  
  --
  Note to ACs: I usually delete AC replies without reading them. If you want to talk to me, log in.
It's all in the cables by Anonymous Coward · 2016-09-06 05:17 · Score: 0

Monster, man! Do my eyes see the difference in gold versus copper!
Solid gold all the way. 1000 bucks per inch.
Audio codec (Vorbis, AAC, Opus) by DrYak · 2016-09-06 05:29 · Score: 1

It is also why Vorbis (audio) is much more successful than Theora (video). Both are patent-free formats from xiph.org.
That's 1 of the reason.
But other reasons are in play:
- Vorbis was released back at a time when music decoding was still an important task for low-power embed devices.
And MP3-hardware decoding cheap where available for cheap.
By the time most PDA/Smartphones/Tablet had enough power to decode audio on CPU without any difficulties, other better competitor were starting to appear: things like AAC (which are not free and patent encumbered).
Meaning Vorbis wasn't competitive anymore.
Vorbis still saw quite some use as a audio/soundtrack codec for video games. (It just simply did attract much attention the role it played into this position).
- Vorbis itself has been superseeded.
Opus is the successor, partly developped by the same Xiph guys, partly developped based on technology donated by Skype.
The result is a codec that beats the crap out of anything else (except for some very special corner cases at a tiny bandwidth that isn't relevant on the internet).
Including out of AAC.
It's royalty free, not patent encumbered with available opensource code.
It's established as an official standard for web audio by IETF.
This it is widely use by tons of modern applications: Skype (obviously), WhatsApp, etc.
So the main reason that Vorbis isn't successful these days, is because Opus is.
Now keep in mind that IETF has a video codec work group called NetVC,
and that AOMedia (Alliance for Openmedia) is working to provide them with codec AV1
ant that alliance includes the same Xiph guys, but also other codec makes (Google [VP10], Cisco [Thor]), browser makers (Google, Mozilla, Microsoft) content providers (Google [Youtube], Netflix) and hardware makers (ARM, Intel, AMD, Nvidia)
There's a high chance that the same will happen in the video world, with AV1 taking everything just like Opus for the audio.

--
"Sufficiently advanced satire is indistinguishable from reality." - [Tips: 1DrYakQDKCQ6y52z6QbnkxHXAocMZJE61o ]
Apple by DrYak · 2016-09-06 05:34 · Score: 1

The only bigger company of significance which is _not_ member of AOM is apple, who suprise suprise sits at the MPEG table and makes bucks with their H.265 patents.
Which also explain why they insist of using AAC for everything audio,
despite the tremendous success and performance of Opus - the previous similar success story of company collaboration (Xiph and Skype) to provide a standard to the IETF.
(Opus is currently used by Skype, WhatsApp, etc. - basically if it's on the web today, it probably uses Opus as an audio codec).
(I really wish IETF and AOMedia similar succes for their NetVC initiative/AV1 codec.

--
"Sufficiently advanced satire is indistinguishable from reality." - [Tips: 1DrYakQDKCQ6y52z6QbnkxHXAocMZJE61o ]
VP9 is here to rule them all by FithisUX · 2016-09-06 05:37 · Score: 1

Throw away proprietary FPGA implementations, Google makes the real stuff Free and Open Source, software/hardware. I would never ever attempt to use x265 proprietary cruft. It is time every one make VP9 available in hardware by default.
1. Re:VP9 is here to rule them all by StreamingEagle · 2016-09-06 05:53 · Score: 1
  
  x265 is open source software, not an FPGA implementation. Why are you calling it proprietary cruft?
Is this why a lot of NetFlix content is so bad? by Anonymous Coward · 2016-09-06 06:04 · Score: 0

We have noticed recently that NetFlix video quality is worse that it has been. Could this be the reason?
1. Re:Is this why a lot of NetFlix content is so bad? by Bengie · 2016-09-06 08:31 · Score: 1
  
  Your connection to them is probably choking and down-grading the resolution.
Incorrect by SuperKendall · 2016-09-06 06:18 · Score: 1

Instead we get a chunk of silicon that can't be used for anything except x265
That is not at all the case, for instance all of Apples advanced math libraries (under the umbrella "Accelerate") will make use of a GPU if one is present and faster than at the CPU. They handle things like linear algebra stuff (linpack) and all sorts of vector operations, including FFT...

--
"There is more worth loving than we have strength to love." - Brian Jay Stanley
1. Re:Incorrect by martinX · 2016-09-06 10:43 · Score: 1
  
  H.264 compression on the Mac can happen using Intel's QuickSync which is on the CPU. If you try and encode in a way that doesn't invoke QuickSync (for example, two pass encoding), it uses software compression on the CPU. QuickSync is very fast and a big improvement over what came before it.
  http://macperformanceguide.com...
  
  --
  When they came for the communists, I said "He's next door. Take him away. Goddam commies."
2. Re:Incorrect by TeknoHog · 2016-09-06 11:08 · Score: 1
  
  Instead we get a chunk of silicon that can't be used for anything except x265
  That is not at all the case, for instance all of Apples advanced math libraries (under the umbrella "Accelerate") will make use of a GPU if one is present and faster than at the CPU. They handle things like linear algebra stuff (linpack) and all sorts of vector operations, including FFT...
  This sounds very much like OpenCL or CUDA, or whatever the Applets call when you do general computing on GPU shaders. The video decoding bit is a different ASIC altogether.
  That said, it would be nice to do more of these common operations like video decoding in GPGPU software instead of all these different bits for different purposes. I understand that some of the open-source GPU drivers already do some video decoding in the shaders, but that's about it. I guess something like ffmpeg/libva in OpenCL is too much to ask, since many people already have strong enough CPUs for those things, and there are no obvious efficiency gains compared to dedicated decoding hardware.
  
  --
  Escher was the first MC and Giger invented the HR department.
Computer power usage by Zardoz · 2016-09-06 06:45 · Score: 1

Assuming the video encode is a one time thing... wouldn't there be an energy cost if one codec takes a lot more computation on the decode end? I assume there would be an energy savings on the datacenter and bandwidth end... That would be an interesting benchmark.
1. Re:Computer power usage by Anonymous Coward · 2016-09-06 11:16 · Score: 0
  
  I don't have the numbers, but the settings they used for x265 are completely absurd regarding the amount of computation. Even on a fairly beefy system, it would take nearly forever to finish an entire movie or (especially) a tv series. The obviously either don't care about the time and energy it takes, or are gaming the test.
I did a similar test at home by ryanmc1 · 2016-09-06 06:55 · Score: 1

I noticed that my favorite bluray ripper started supporting h.265, previously I had been using h.264, so I decided to give it a try. I took about twice a long to encode, and was a bit smaller in size, but 2 of my home computers could not playback the video. H.265 requires quite a bit more CPU/GPU processing power for both encoding and decoding. I personally will stick with h.254 because the cost of upgrading those machines is more than the cost of hard drive space.

If netflix switches they may find that a lot of home users can no longer use the service.
1. Re:I did a similar test at home by corychristison · 2016-09-06 07:55 · Score: 1
  
  I've noticed this as well.
  My HTPC struggles with 1080p encoded x.265 video, so I don't believe there is any real benefit to the consumers if we need to upgrade our equipment.
  For the record, my HTPC has an AMD Athlon 5370 APU.
2. Re:I did a similar test at home by TeknoHog · 2016-09-06 11:16 · Score: 1
  
  2 of my home computers could not playback the video. H.265 requires quite a bit more CPU/GPU processing power for both encoding and decoding.
  Your GPU probably has a hardware decoder for H.264, but not for H.265.
  
  --
  Escher was the first MC and Giger invented the HR department.
Mathematics by quenda · 2016-09-06 07:29 · Score: 3, Interesting

A small nitpick, but sad to see a common but serious maths error in a technical article.
20% fewer bits is not equivalent to 20% more efficient, but 25% more .
Efficiency would be the reciprocal of the bitrate. A ratio of 4:5 becomes 5:4 when looked at the other way around.
If you were to halve the bitrate, it would be twice as efficient, not 50% more.
Or to put it in simple money terms, its like if two items are $100, one gets a 20% discount to $80, the other is now 25% more expensive.
1. Re:Mathematics by Anonymous Coward · 2016-09-06 12:02 · Score: 0
  
  If it's zero degrees today and the forecast says it will be TWICE as cold tomorrow, how cold will it be?
2. Re:Mathematics by quenda · 2016-09-06 14:47 · Score: 1
  
  Ratio comparisons make no sense on a scale with an arbitrary zero-point.
  If you mean Kelvins, the universe has reached heat-death, so tomorrow will be the same.
VP9 Costs 100% Less by BrendaEM · 2016-09-06 07:35 · Score: 1

VP9 is free, as in beer. There's something to be said for that.
Or, do you want to keep sticking your head in nooses?

--
https://www.youtube.com/c/BrendaEM
1. Re:VP9 Costs 100% Less by ArtemaOne · 2016-09-07 09:21 · Score: 1
  
  That is assuming that bandwidth is free. It is not, thus no.
10 bit encoding by justthinkit · 2016-09-06 07:44 · Score: 2

I didn't know about this, so researched and found this page that explains "10-Bit H.264".

I offer it here so that someone can complain that I am karma whoring.

--
I come here for the love
1. Re:10 bit encoding by UnknownSoldier · 2016-09-06 07:52 · Score: 1
  
  Freudian slip on Line #71 ?
  
  And what does this all mean for my precious fagsubs?
  Shouldn't that be: fan subs ? :-)
2. Re:10 bit encoding by Falos · 2016-09-07 03:51 · Score: 1
  
  Those communities get a lot of mileage out of "fag". It can still be used for gays, but is such an exceedingly prevalent catchall it even becomes affectionate or respectful in some contexts. Not most. Usually it's negative, serving as the same generic disapproval appendage Matt & Trey decided the town of South Park employs.
  
  You can issue reprimands about how it harms gay culture or whatever, but it only furthers their bemused fascination. Today, it's a casual sardonic remark on their own fringe culture; any scorn they might see coming from Normals is dwarfed by their own quasi-serious hatred (fag this, fag that, stfu fag) for each other, only briefly shelved when needing to cattleprod the casual Narutard tier into maintaining a better, presentable impression to a stereotype-dependent society.
  
  Oops, my Eleven is showing. Anyway, this assumes an internal member; l4n9th4n9 handles as "Henjin". If s/he turns out to be writing from somewhere less inside and more adjacent, the remark may be more contemptuous.
  
  tldr it's deliberate
Re:Frosty piss by epyT-R · 2016-09-06 08:21 · Score: 1

not a chance.. There's no way 720x480 has a shot at conveying the same information as HD, upscaled and edge sharpened or not..
Until Raspberry Pi's support it in HW, I'll pass. by Anonymous Coward · 2016-09-06 09:01 · Score: 0

Until Raspberry Pi's support it in HW, Not Interested.
Any vcodec not supported in HW for a nominal $0 cost by a raspberry pi is not interesting to me at all.
The R-Pi v2 has h.264 support in HW for $0. Plays 1080p content with less than 20% CPU. Plex transcodes from mpeg2 --> h.264 on-the-fly easily.
Codec doesn't matter nexflix app's suck by Anonymous Coward · 2016-09-06 09:19 · Score: 0

The codec is irrelevant since the netflix app on my STB, Fire TV, etc don't work worth a crap. If they create a stable app, maybe they could consider optimizing their streaming. Till then they are wasting time and money.
Re:Frosty piss by jedidiah · 2016-09-06 10:35 · Score: 1

Strangely enough your own comment supports the idea that Netflix is inferior to the original media.
If DVD represents the native resolution of the original, Netflix isn't going to be any better. Plus you won't have to worry about Netflix doing anything stupid with the original like cropping or zooming it.

--
A Pirate and a Puritan look the same on a balance sheet.
Help by Anonymous Coward · 2016-09-06 11:39 · Score: 0

Netflix and Hulu needs to help Google with the next iteration of VP9.
Re:Frosty piss by jedidiah · 2016-09-06 11:58 · Score: 1

It all depends on how bad the "HD" encode is. Some of them can be quite horrible. It's quite easy to be stingy on the bitrate and end up with a disaster.

--
A Pirate and a Puritan look the same on a balance sheet.
Re:Frosty piss by epyT-R · 2016-09-06 12:12 · Score: 1

This is true..
HEVC is only available by Anonymous Coward · 2016-09-06 12:37 · Score: 0

in Microsoft Edge, so who gives a fuck? Also, libvpx just came out with an improved version in July. Which version was used? This study doesn't say.
This is a near-useless comparison. A good idea, but poorly executed and it could be better documented.
Misleading Title by randallman · 2016-09-07 02:11 · Score: 1

The title is misleading.

We sampled 5000 12-second clips from our catalog, covering a wide range of genres and signal characteristics. With 3 codecs, 2 configurations, 3 resolutions (480p, 720p and 1080p) and 8 quality levels per configuration-resolution pair
and then

x265 and libvpx demonstrate superior compression performance compared to x264, with bitrate savings reaching up to 50% especially at the higher resolutions. x265 outperforms libvpx for almost all resolutions and quality metrics, but the performance gap narrows (or even reverses) at 1080p.
So the highest resolution they tested was 1080p and performance between the 2 codecs was very close with libvpx beating out x265 in some cases. As far as bandwidth goes, saving at 1080p and above is more valuable than saving at 480p. Practically everything we watch at home is streamed 1080p. I don't see that x265 is the winner here. And where are the 4k tests?
Quality by almitydave · 2016-09-07 06:26 · Score: 1

Hey, that's great Netflix. Nice to see progress on the horizon in video encoding tech. Now would you please add an option to buffer the start of shows so they don't look like pixelated crap for the first 30 seconds or more on my HDTV? Maybe a checkbox somewhere? Even my wife notices, and she's not usually picky about these things. Thanks.

--
my, your, his/her/its, our, your, their
I'm, you're, he's/she's/it's, we're, you're, they're
My mistake by DrYak · 2016-09-07 22:15 · Score: 1

Google owns Widevine, not Adobe. Did you mean Primetime?
Ooops. My mistake. I confused the DRM plug-ins.
Thank you for rectifying
(Tells you how often I use DRM in my day-to-day life)

--
"Sufficiently advanced satire is indistinguishable from reality." - [Tips: 1DrYakQDKCQ6y52z6QbnkxHXAocMZJE61o ]