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.
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
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.
I want better video quality, but in the sense that I'd like to see higher 720P quality at lower bitrates.
#DeleteFacebook
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.
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?
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).
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
The compression ratios are too great to ignore. Raw HD images would be on the order of 4096 x 3192 x 16 bits x 3 channels x 60 frames second for up to 4 hours. Just by eliminating duplicate frames saves memory. Then only updating those parts of frame saves more memory. Between frames, some regions of the screen simply move sideways. That saves even more memory. Using various block compression methods like sine waves saves even more memory. Every time memory is saved, higher resolutions or longer movies can be made. It might require more expensive servers to find the optimum compression, but it's worth doing.
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.
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.
Don't the compressions just need to run once per show? Not every time you stream. Yea, up to 500x more, but only once. Seems like there really isn't much of a problem.
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.
but but.. we need to charge 500x more to stream this content each time you view it.
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.
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.
It's bitztream
The autism-hating, custom EpiPen-hating, Musk-hating, Qualcomm-hating, Firefox tabs-hating Slashdot troll!
No, because you have to encode in different bitrates in order to have a seamless playback on multitude of devices and bandwidth. Today's streaming techniques don't encode one video file in entirety but instead break the video down into multiple short videos that are stitched together by the player using a playlist. This allows the video to start almost instantly at a lower quality then seamlessly play higher qualities a few seconds later, and drop down to lower qualities when you experience congestion in the pipe. The idea is to reduce buffering, so no it isn't just one time but more like 5 times per video.
How's life in the hypocrite lane?
No, because you have to encode in different bitrates in order to have a seamless playback on multitude of devices and bandwidth. Today's streaming techniques don't encode one video file in entirety but instead break the video down into multiple short videos that are stitched together by the player using a playlist.
The short (or sometimes not-so-short) video that precedes every Apple TV viewing event, you know, the one with the spinner and the word "Buffering", seems to be encoded at a pretty decent resolution, Maybe it's built into the device for quick access every time?
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.
Meanwhile, in their latest bold move, Apple has abandoned multiple frames per second in favor of 1 frame per second for all content.
When asked about this disruptive move, an apple representatives stated that: "Eliminating frames in favor of the best one provides a substantial benefit for all of those involved, there is less bandwidth involved for the streaming companies, and our customers get the predetermined best movie at the best resolution with more time to enjoy each frame."
Try this AV1 demo with Firefox Nightly. 720p video at 500kbps.
Not really. Bitmovin has already done demos of live streaming with AV1.
I'm not going to install Firefox just to see that, sorry.
#DeleteFacebook
Your loss. The quality's impressive for the bitrate.