Slashdot Mirror
Apple's Adoption Of HEVC Will Drive A Massive Increase In Encoding Costs Requiring Cloud Hardware Acceleration (streamingmedia.com)
An anonymous reader shares a report: For the last 10 years, H.264/AVC has been the dominant video codec used for streaming but with Apple adopting H.265/HEVC in iOS 11 and Google heavily supporting VP9 in Android, a change is on the horizon. Next year the Alliance for Open Media will release their AV1 codec which will again improve video compression efficiency even further. But the end result is that the codec market is about to get very fragmented, with content owners soon having to decide if they need to support three codecs (H.264, H.265, and VP9) instead of just H.264 and with AV1 expected to be released in 2019. As a result of what's take place in the codec market, and with better quality video being demanded by consumers, content owners, broadcasters and OTT providers are starting to see a massive increase in encoding costs. New codecs like H.265 and VP9 need 5x the servers costs because of their complexity. Currently, AV1 needs over 20x the server costs. The mix of SD, HD and UHD continues to move to better quality: e.g. HDR, 10-bit and higher frame rates. Server encoding cost to move from 1080p SDR to 4K HDR is 5x. 360 and Facebook's 6DoF video are also growing in consumption by consumers which again increases encoding costs by at least 4x. If you add up all these variables, it's not hard to do the math and see that for some, encoding costs could increase by 500x over the next few years as new codecs, higher quality video, 360 video and general demand increases.
At some point, it must be easier to upgrade everyone to fiber and just stream the content natively.
Isn't that kind of the point? You optimize once and you save more on the other end since each playback device isn't wasting battery and bandwidth playing the less efficient version.
The patent situation on h.265 is a total mess. Why even bother with it?
purpose built chips will make your "times X" arguments irrelevant, and they'll support any needed coding system
Apple means paying customers, so they have a huge weight on CODEC decision for the market.
But there is one company much bigger than Apple when talking about video and that is of course Netflix. Whatever Netflix decides, companies will have to follow.
#DeleteFacebook
Wait... wut? Does anyone think that really might be true? Or is it obvious bullshit planted by someone who sells encoders?
More efficient codecs are bitchin', but let's not pretend that users are yelling for it.
I think it's far more likely that this would drive Google to add an FPGA on a card to some of their boxes if they don't already have one on the motherboard. That would allow them to adapt to any new codec out there. Crisis averted!
Anons need not reply. Questions end with a question mark.
Witness BitZtream getting pwned!... twice.....three times!
New codecs like H.265 and VP9 need 5x the servers costs because of their complexity.
H.265 encode and decode is baked into all hardware produced by the big three video card manufacturers.
HEVC compresses nicely, but the results don't look as good as what can be achieved with AVC with the proper settings in less time for only a small amount more data.
The price difference isn't ridiculous because it's still a relatively small number. You're right - it'll be on anything and everything. H.264 used to be crazy impossible to decode way back when. I remember Microsoft distributing some form of MPEG-4 (may have been AVC1) video clip with surfing in 1080p. It played so choppy I couldn't even really view it except as practically a slideshow. I wish I could remember more, but I remember how I felt when my computer couldn't play it.
You can still buy brand new phones that don't have hardware acceleration for H.265. That's a 4 year old codec.
VP9 is even less well supported in hardware. It's 5 years old.
So, how long until a large chunk people have devices with hardware acceleration for a codec that isn't even public yet?
Really? 4x, 5x, 20x, 500x?
This is extremely well-worn territory. The current size of the problem isn't the future size of the problem. First they work on the codecs to make them more efficient on an IPC basis. Next they make the algorithms parallel because we have an ever-expanding resource of processor cores available to us, with vast memory pools. Finally, if the function can be made consistent and highly standardized, you find CPU instruction sets enhanced to perform certain key functions in hardware.
Next thing you know, the 4x estimated resource ask is just 1.4x. The 500x estimated resource requirement is 30.2x or something. But the whole 500x resource estimate was probably bogus all along.
You know how you get resource growth levels of 500x in the real world? Make a YouTube, or a Vimeo or something. It's the growth in the business itself where you see those levels of resource demands. And in those cases you have a revenue stream to fund the growth so it's not that big of a deal.
"costs are skyrocketing! There is no avoiding it!" ...
"Hey, have you heard this new FPGA thing? Sounds like it might be the solution!"
Just trying to sell more FPGA cloud cycles....
This is honestly to be expected. However, while encoding times have heavily increased and may eventually be a barrier for further optimizations, I don't expect that to occur until the drawbacks of said encoding times outweigh the benefits. In this case, massive savings in bandwidth (around 50% for hevc/vp9. Maybe a bit more for AV1). That would definitely be the biggest cost for a company like Netflix and other providers that deliver large amounts of data over a small set of files.
Eventually I think AV1 will win out over HEVC and VP9. In the case of HEVC, the patent mess has hindered adoption. In the case of VP9, the somewhat poor spec has done the same. Since AV1 seems to be a good attempt at fixing both along with the mass of companies that back it, there is a good chance that things will move quickly to just this one format. Google, Mozilla and Microsoft can simply ship updated browsers and add support for the format within a short period of time. Youtube will then slowly drop VP9 just like it dropped VP8 and h.264 (no 4k encodes in this case anymore).
Bandwidth caps have really put the kibosh on extremely large videos. (You might think real-time broadcasters would use it, but I don't think I have any 4K television channels here in a tech-oriented city.)
However, by the time the bandwidth costs decrease one way or another, encoding costs will probably have dropped as well.
Yeah, remember that meeting we all had last Spring? We all got together with our pitchforks and torches, rammed down the door to the codec people's house, and said, "Enough with H.264, already! Give us something better, dammit." That was a helluva time.
sig: sauer
video is really bad for watching pr0n.
So what does this do to all existing video that is in H264? Will providers (youtube) keep streaming them in the native format they were uploaded as? Will they get reencoded into these newer codecs generating more artifacts and reducing the quality?
We already know there is a quality loss from when you upload a video you have produced onto youtube and it gets reencoded before streamed, so will all the existing videos in their library get reencoded once again to the next new format of the season?
If they want to go off on their own and only naively support some patent embroiled codec that the rest of the industry isnt going towards, let them build their own trans coding layer between their phones and the rest of the world and chew up resources in their own data centers to support it
The story summary talks all about the costs and nothing about the benefits. Less data to be served for high quality output could very well be worth the higher encoding cost.
They'll make up any money lost on encoding by having to stream less otherwise they wouldn't care.
Most manufacturers now make barebones servers specifically designed to cram in GPUs. Amazon AWS, Google Cloud and Microsoft Azure all offer virtual servers with multiple dedicated GPU's as well. Yes, your run of the mill server is still headless with an ASpeed IPMI but you can get absolutely crazy with GPU server platforms.
That costs less and then the other platforms have to support it, which has zero cost for them, unlike if you chose one of the royalty-bearing ones, making the free and open codec a less onerous choice than a paid competitor.
Apparently the people that wrote this article think you'll be encoding media assets per request, instead of once per millions... otherwise what they are saying makes even less sense...
"There is more worth loving than we have strength to love." - Brian Jay Stanley
This is nothing but good news for AWS.
Let's go over these multipliers one by one, shall we?
5x number of minutes to be encoded over today - has nothing to do with Apple's adoption of HEVC
5x the encoding costs for new codecs like VP9 and HEVC over H.264 - potentially accurate, depending on your encoder settings, but this will be offset by much lower bandwidth costs, which are often the dominant cost for a video service, and/or a higher quality of experience, which is what drives business results (market share, brand value, subscriber growth, lower churn, higher average selling price, etc.).
5x as more video is in higher resolution, higher frame rate, HDR (e.g. 1080p60 SDR vs 4Kp60 HDR is 5x pixels) - Increasing the pixel resolution, bit depth or frame rate of a video experience affects costs independent of "adoption of HEVC". Of course, if you DO want to massively improve the quality of your video experience, without a linear increase in the cost to deliver that higher quality experience, upgrade to HEVC, which won't require 5x the bandwidth as you upgrade to provide a competitive video service.
2x as now you have to support two codecs (H.264 & HEVC or VP9) - Wrong again. The cost of AVC encoding stays the same. So if you believe that HEVC encoding is 5x the cost of AVC, you don't multiply by 2 here, you multiply by 1.2 (adding back in the cost of AVC encoding, which is, by your calculations, 20% of HEVC).
2x if you have to support 360 video and Facebook’s 6DoF - Again, choosing to upgrade the depth or quality of the video experience you're offering is independent to the decision to support HEVC. In order to deliver a high quality 360 degree video experience, a codec that is twice as efficient as H.264 is essential.
So, if HEVC is 5x more computationally expensive to encode, adding HEVC content to your service (in addition to AVC/H.264 content) increases your encoding expense by a factor of 6 (1 + 5).... not 500. But you save in bandwidth for all those HEVC streams, and HEVC also lets you upgrade the quality of your video service to support higher resolution, high dynamic range, wider color gamut, greater color depth, and higher frame rates without your Internet bandwidth bill going through the roof. If your competitor (Apple, etc.) is delivering a massively better quality of video experience by taking advantage of a codec that is twice as efficient as H.264, you can either keep pace, or you can fall behind.
At some point, it must be easier to upgrade everyone to fibre and just stream the content natively.
Unlikely. What both you and the OP has forgotten about is that the increased cost of the servers needed to encode the video once is going to be offset by the reduced storage and bandwidth requirements. The video will be streamed thousands, if not millions, of times which not only requires huge amount of bandwidth but also means the file will be stored in multiple locations on multiple disks. This means that the savings in bandwidth and storage are magnified by the number of uses and will almost certainly offset the increase in cost of one encoding.
Then Apple, then Microsoft users.
A nice shiny expensive new mac will get the job done just as well as your previous computer. Sure no ulterior motives there.
As moores law comes to an end technology companies need new ways to invent sales. One is renting software. The other is making standards require more expensive versions of their products
http://saveie6.com/
I remember in the 1990s when this new picture format called JPEG was being tested. I downloaded it and tried it out. It took a minute to decode a 640x480 picture in 24-bit color on my PC, compared to about 2 seconds for a GIF of the same resolution (albeit 8-bit). It took way too long on computers at the time, but the picture was beautiful and I knew computers would become fast enough that this was the future.
Same thing with encryption. Old encryption standards typically aren't retired because they've been cracked. They're retired because a brute force attack against them used to take centuries or millenia, but computers have become fast enough that a brute force attack now takes only days or hours.
MPEG2 with its horrible compression ratio became the standard for DVDs because at the time MPEG4 took too much processing power to be economically added to every DVD player. The same is going to be true for these newer video codecs. Initially they'll be computationally expensive, but within a few years they'll be tolerable. And after a decade it'll be trivial and we'll be looking towards replacing them with a new codec which takes advantage of more powerful modern hardware.
New codecs like H.265 and VP9 need 5x the servers costs because of their complexity. Currently, AV1 needs over 20x the server costs.
You encode the file once (which may well take 5 or 20 times the processor power) and upload to the server which will then save bandwidth and storage costs because of the smaller file size.
This Balkanization of codecs is a mess. Consumers, and developers, just want it to work. Let's see... I've got enough old DVDs and VHSs to watch for a decade... Maybe time to sit out this fight.
Chips that came after the Haswell timeframe (3 years ago) were already ready to support optimized HEVC encoding / decoding.
Plus, there are known OpenCL implementations available that speed up HEVC decoding on older hardware;
http://hgpu.org/?p=13189
This kind of false news is dangerous for a site with a decent technical reputation like Slashdot. Stop spreading it.
It's bitztream
The autism-hating, custom EpiPen-hating, Musk-hating, Qualcomm-hating, Firefox tabs-hating Slashdot troll!
The 2013 Moto G has hardware h265 decoding support... a sub US$ 200 phone, in 2013.
Pretty sure most phones today have it.
This model assumes a stagnant server model as well...why wouldn't server architecture evolve to support the "one time" encoding? Duh?
How's life in the hypocrite lane?
Let's for the moment pretend I know what I'm talking about regarding video technology.
The author of this story seems to think that there's a correlation behind business and encoding complexity.
Let's start with this. While H.264 and H.265 and AV1, etc... are all really cool, large scale content delivery systems tend to profit far greater from better use of core components of a codec than from improvements to core components of the codec.
Let's consider things like improved motion search. Depending whether you're implementing the function in ASIC, FPGA (there's a difference regarding memory access), CPU instructions or GPU instructions, there are multiple approaches to handling this well. A circuit in a complex enough ASIC or FPGA could perform a single clock motion search within a given range, however the cost of this is generally very high and therefore inefficient financially. So, an iterative or progress approach is taken. One great method is to use the previous frame's motion vectors and predict a pattern which would continue motion in the same general directions within the same general regions of the field.
Of course, this sounds highly intelligent and simple and logical, consider making an elongated diamond search pattern with an affinity to the direction of the previous motion vector. Motion search is logical and intelligent only when thinking in terms of one frame after the next. However, H.264 introduced the ability to encode every single macroblock as I,P or B (and some subtypes) and there's no specific requirement for I-frames in video which is great since for bit distribution in broadcast, when combined with spatial scalability mechanisms, it's possible to achieve constant bit rate at far lower rates
I supposed I'm about to write a dissertation on video encoding here and there's a few friends of mine in the field who probably started reading this comment laughing at how I'm trying to solve all the encoding problems of the world in a single Slashdot posting.
Let's say it this way.... currently there are two main types of OTT distributors
1) The kind that encode a hundred films a year, a hundred different ways and the cost of CPU cycles to do it is absolutely irrelevant.
2) The kind that encodes 900,000 videos a second to spam to everywhere. To these guys CPUs are very important.
Most of these guys start off working on code in their moms basements and eventually turn it into something cloud based... very nice, very sweet. I remember before Google bought YouTube and YouTube was running their service by automatically linking to free file sharing websites. It was funny.
Here's the thing though... these guys optimize the ever living heck out of their encoders. Some might use vanilla x264 and if you're small enough... why not? It's absolutely amazing stuff. It has OpenCL optimized code and therefore can scale to an FPGA very easily today as Altera (and other companies) have adopted OpenCL as their future direction of encoding support. This is a nightmare because people will start using FPGAs with OpenCL and other people will laugh because simply recompiling OpenCL to run on FPGA is not cost or power efficient. It's far better to use the OpenCL compiler extensions to manage copying memory to the FPGA and to prototype the function and then have a real VHDL/Verilog guy sit down and write the functions which are needed.
One place where FPGA can save millions on encoding costs is in entropy coding. Hmm... well not the entropy coding itself (though it would make sense logically to just move the whole thing) but bit packing. x264 and others spend amazingly large amounts of their time simply calling the function 'PushBits()' because there's no efficient method of bit streaming in an x86 CPU.
If Apple makes use of H.265, and people start streaming video to YouTube as H.265... here's what happens.... YouTube converts the video to either H.264 or VP9. No... YouTube won't rush to use H.265 just because it's there.
Consider an Intel proce
Nice clickbait-y headline, Dan. Despite the fact that the FIRST SENTENCE says "with Apple adopting H.265/HEVC in iOS 11 and [emphasis mine] Google heavily supporting VP9 in Android", the headline only mentions Apple. Gee, I wonder why that is?
Hey, remember how happy we all were when Android overtook Apple in market share, and now they're several times larger? So wouldn't a more ACCURATE headline put the bulk of the blame on Google? Who, by the way, is ALSO a strong driver of video codec change via YouTube?
As other posts are pointing out, this isn't even a big problem. Still, nice to see that waving the Apple flag is alive and well.
Dear Slashdot: next time you want to mess with the site, add a rich-text editor for comments.
This is going to require dedicated high end hardware encoders and these are costly with high end prices.
Not really. Bitmovin has already done demos of live streaming with AV1.