14 ms·

YouTube is now building its own video-transcoding chips

259 points by beambot 6y ago

sidcool 6y ago
For YouTube's scale it makes sense, since a small saving or efficiency boost would accumulate at their scale.
- kevingadd 6y ago
  Not just cost reduction or efficiency, the faster encodes you can get through dedicated hardware mean they can potentially reduce the delay between a video being uploaded and a video being available to the public (right now even if you don't spend time waiting in the processing queue, it takes a bit for your videos to get encoded) You can handle larger volumes of incoming video by spinning up more encoder machines, but the only solution for lowering latency is faster encodes, and with the way the CPU and GPU markets are these days a dedicated encoder chip is probably your best bet.
  - Dylan16807 6y ago
    You can split a video up across cores or even across servers. Encoding speed does not need to have a significant impact on publishing latency.
Traubenfuchs 6y ago
The dangerous case of custom hardware making a software business significantly more efficient: This makes disruption and competition even harder.
- azurezyq 6y ago
  It's inevitable, and this applies to other kinds of optimizations as well. This place is too mature, disruption might be easier elsewhere.
- c7DJTLrn 6y ago
  What is there to compete for? Video hosting is a money-losing business unless you have exclusives, like Floatplane.
  - endless1234 6y ago
    What is floatplane, never heard of it? Seemingly an yt competitor by a somewhat popular youtuber. App on Android has "10k+" installs. Isn't it _way_ too early to say it wouldn't be a money losing business?
    - oblio 6y ago
      My guess is that the commenter is either a Floatplane insider or possibly just optimistic :-)
    - throwaway3699 6y ago
      Think of Floatplane as more of a Patreon competitor with a video component, than a YouTube competitor.
    - bobsmooth 6y ago
      Linus' goal for Floatplane is "If it doesn't fly, it'll at least float." There's only 20 creators on it and it's intended to compliment YouTube, not replace it.
  - human_error 6y ago
    What's floatplane? Hadn't heard of it. The website doesn't say much.
    - pcmill 6y ago
      Floatplane is a video service built by the people behind the popular Youtube channel LinusTechTips. It is not a direct competitor to Youtube though. The platform makes it easier to let paying fans get videos earlier but it is not meant to build an audience.
- fancyfredbot 6y ago
  This will keep costs down but I am not sure cost of transcoding is the major barrier to entry? I think the network effect (everyone is on YouTube) had already made disruption pretty difficult!
  - NicoJuicy 6y ago
    Depends how you look at it. There could be someone making these chips and then a competitor with lower startup costs than before.
  - londons_explore 6y ago
    Things like youtube run on super-thin margins. Bandwidth and storage costs are massive, compute costs quite big, and ad revenue really quite low. A competitor would need either a different model to keep costs low (limit video length/quality, the vimeo model of forcing creators to pay, or go for the netflix-like model of having a very limited library), or very deep pockets to run at a loss until they reach youtube-scale. I'm still mystified how tiktok apparently manage to turn a profit. I have a feeling they are using the 'deep pockets' approach, although the short video format might also bring in more ad revenue per hour of video stored/transcoded/served.
- Traster 6y ago
  To be honest I suspect it isn't actually a differentiator. It's good for Google that they can produce this chip and trim their hardware costs by some percentage, but it's not going to give them a competitive advantage in the market of video sharing. Especially in a business like youtube with network effects, getting the audience is the difficult bit, the technical solutions are interesting but you're not going to beat google by having 5% cheaper encoding costs.
- ant6n 6y ago
  Perhaps. But the big issues for YouTube right now isnt efficiency per se, but copyright, monetization, ai-tagging, social clout. If a YouTube competitor can get the content creators and offer them viewers, competition could perhaps work. This fight is probably not fought at the margins of hardware optimization.
- mrtksn 6y ago
  It's like crystallisation of the software. When you decide that this is the best version of an algorithm, you make a hardware that is extremely efficient in running that algorithm. It probably means that, unless you have a groundbreaking algorithm on something that is available as hardware, you simply do software on something that is not "perfected". It trims marginal improvements.
- CyberRabbi 6y ago
  Usually competition for a general platform like YouTube comes in the form of unbundling and in that case these last mile optimizations will matter little.
  - narrator 6y ago
    The main competitors to YouTube are the sites that have non-illegal content that YouTube won't host. e.g: Porn and controversial political stuff.
    - CyberRabbi 6y ago
      That might be true but I think sites like odyssey are more popular than controversial political video sites.
- wishysgb 6y ago
  as long as you can buy the parts or have the HDL to deploy it on an FPGA you should be fine
- blihp 6y ago
  It's the seemingly infinite bandwidth that Google throws at YouTube that make competition hard. Then there's the inability to monetize. Transcoding is probably about 20th on the list of issues.
- yuhong 5y ago
  I wonder what the WMF will do when the H.264 patents expire and all these videos needs to be transcoded.
pizza234 6y ago
A couple of interesting bits: - without dedicated processors, VP9's encoding is roughly 4.5x as slow as H.264, while with the VPUs, the two formats perform the same; this is a big win for the open format(s) - sad extract: "Google has aggressively fought to keep the site's cost down, often reinventing Internet infrastructure and copyright in order to make it happen" (emphasis mine)
- sillysaurusx 6y ago
  Why is that sad? No company in Google's position could've done better, probably. Youtube was about to be sued into oblivion till Google purchased it.
  - serf 6y ago
    >Why is that sad? because the wholesale destruction and minimization of knowledge, education, and information to appease (often arbitrary) intellectual protectionism laws is sad, regardless of who perpetrates it. non-Google example : What.cd was a site centered around music piracy, but that potentially illegal market created a huge amount of original labels and music that still exists now in the legal sphere. No one would defend the legal right for what.cd to continue operating, it was obviously illegal; but the unique, novel, and creative works that came from the existence of this illegal enterprise would be sad to destroy. Swinging back to the Google example : YouTube systematically destroys creations that they feel (often wrongly) infringe upon IP. This is often not even the case, Google routinely makes wrong decisions erring on the side of the legal team. This destruction of creative work is sad, in my opinion it's more sad than the un-permitted use of work. Of course, Google as a corporation should act that way, but it's sad in certain human aspects.
    - nolok 6y ago
      It's not just google as a corporation, it's google as a legal entity. Have your own site in your own individual name with no corporate entity nor search for profit offering to host people's videos for free, and I guarantee you that within 24h you are dealing with things ranging from pedophilia to copyright violations and the like. And if you don't clear them out, you're the one responsible. Google is acting the way society has decided they should act through the laws it voted. Could they act another, more expensive, way in order to save a bit more of content that get caught by mistake ? Definitely, but why would they as a company when the laws says any mistake or delay is their fault. Source: like many people, I once made a free image hosting thingy. It was overrun by pedos within a week to my absolute horror and shock. Copyright infringement is obviously not the same at all, BUT the way the law act toward the host is not that different "ensure there is none and be proactive in cleaning, or else ...".
CyberRabbi 6y ago
Wow 33x throughput improvement for vp9 for the same hardware cost. That seems excessive but their benchmark is using ffmpeg. Is ffmpeg known to have the theoretically highest throughput possible state of the art vp9 encoder algorithms? Or is there any way of knowing if their hardware IP block is structured equivalently to the ffmpeg software algorithm? I know that custom hardware will always beat general hardware but 33x is a very large improvement. Contemporary core counts coupled with very wide simd makes CPUs functionally similar to ASIC/fpga in many cases.
- brigade 6y ago
  The only OSS VP9 encoder is Google’s own libvpx, which is what ffmpeg uses.
  - rndgermandude 6y ago
    By now Intel has released an open source encoder (BSD-2 + patent grants), tuned for their Xeons: https://github.com/OpenVisualCloud/SVT-VP9 https://github.com/OpenVisualCloud/SVT-VP9
- bumbada 6y ago
  That doesn't look so excessive to me. We get hundred or thousand times more efficiency and performance regularly using custom electronics for things like 3d or audio recognition. But programming fixed electronics in parallel is also way harder than flexible CPUs. "Contemporary core counts coupled with very wide simd makes CPUs functionally similar to ASIC/fpga in many cases." I don't think so. For things that have a way to be solved in parallel, you can get at least a 100x advantage easily. There are lots of problems that you could solve in the CPU(serially) that you just can't solve in parallel(because they have inter dependencies). Today CPUs delegate the video load to video coprocessors of one type or another.
  - bumbada 6y ago
    BTW: Multiple CPUs cores are not parallel programming in the sense fpgas or ASICS (or even GPUs) are. Multiple cores work like multiple machines, but parallel units work choreographically in sync at lower speeds(with quadratic energy consumption). They could share everything and have only the needed electronics that do the job.
colonwqbang 6y ago
If anything it's just strange that such a part didn't exist before (if it really didn't). Accelerated encoding is hugely more power efficient than software encoding.
- wishysgb 6y ago
  well I do believe video transcoding chips have been there forever. But I think those chips should be tailored to their exact application making them more efficient
- fireattack 6y ago
  The complement of "building its own video-transcoding chips " isn't just software encoding though. Google/Youtube could have already been using hardware encodings, just with generic GPUs or whatever existing hardware.
- izacus 6y ago
  I've worked on a IPTV broadcasting system and this isn't as obvious as you'd think. The big issue here is quality - most hardware encoders hugely lag behind software encoders. By quality I mean visual quality per bytes/s. Which means that using a quality software encoder like x264 will save you massive amount of money in bandwidth costs because you can simply go significantly lower in bitrate than you can with a hardware encoding block. At the time, our comparisons showed that you could get away with as low as 1.2MBps for 720p stream where with an enterprise HW encoder you'd have to do about 2-3MBps to have the same picture quality. That's one consideration. The other consideration is density - at the time most hardware encoders could do up to about 4 streams per 1U rack unit. Those rack units cost about half the price of a fully loaded 24+ core server. Even GPUs like nVidia at the time could do at most 2 encoding sessions with any kind of performance. On CPU, we could encode 720p on about 2 Xeon cores which means that a fully loaded server box with 36+ cores could easily do 15-20 sessions of SD and HD and we could scale the load as necessary. And the last consideration was price - all HW encoders were significantly more expensive than buying large core count rack-mount servers. Funny enough, many of those "HW specialised encoding" boxes were running x86 cores internally too so they weren't even more power efficient. So in the end the calculation was simple - software encodes saved a ton of money on bandwidth, it allowed better quality product because we could deliver high quality video to people with poor internet connectivity, it made procuring hardware simple, it made the solution more scalable and all that at the cost of some power consumption. Easy trade. Of course the computation is a bit different with modern formats like VP9 and H.265/HEVC - the software encoders are still very CPU intensive so it might make sense to buy cards these days. Of course, we weren't Google and couldn't design and manufacture our own hardware. But seeing the list of codecs YouTube uses, there's also one more consideration: flexibility. HW encoding blocks are usually very limited at what they can do - most of them will do H.264, some of them will stretch to H.265 and maaaaaybe VP9. CPUs will encode into everything. Even when a new format is needed, you just deploy new software, not a whole chip.
spuz 6y ago
> Google probably only provides stats about growth (like "500 hours of video are uploaded to YouTube every minute") because the total number of videos is so large, it's an unknowable amount. I suppose you could sample random YouTube urls to find out how many of them link to public videos. Given the total number of possible URLs, it would give you an idea of what percentage of them have been used and therefore how many videos YouTube has in total. It would not tell you how many private videos or Google Drive / Photos videos exist of course.
- warent 6y ago
  It doesn't seem like this would work. I think you could sample trillions of YouTube IDs with a high likelihood of all of them being unused. They're supposed to be unique after all
  - chrisseaton 6y ago
    What do you mean 'supposed to be unique'? How can an ID not be unique?
    - zakki 6y ago
      Maybe when they reach 62^11 + 1?
  - rococode 6y ago
    Clicked into a couple random videos, looks like all of their video IDs are 11 characters, alphanumeric with cases. So 26+26+10 = 62 choices for each char, 62^11 = 5.2e+19 = 52 quintillion unique IDs (52 million trillions). So, yeah, sampling would be a mostly futile effort since you're looking to estimate about 8 to 10 decimal digits of precision. Though it's technically still possible since you'd expect about 1 in every 50 million - 5 billion IDs to work (assuming somewhere between a trillion and 10 billion videos). My statistics knowledge is rusty, but I guess if you could sample, say, 50 billion urls you could actually make a very coarse estimate with a reasonable confidence level. That's a lot but, ignoring rate limits, well within the range of usual web-scale stuff.
samwestdev 6y ago
Why don’t they encode on the uploader machine?
- pta2002 6y ago
  Can't trust user input, you'd have to spend quite a bit of energy just checking to see if it's good. You also want to transcode multiple resolutions, it'd end up being quite slow if it's done using JS.
  - amelius 6y ago
    Verification is simpler than encoding, I suppose.
  - londons_explore 6y ago
    Checking the result is good shouldn't be too hard - a simple spot check of a few frames should be sufficient, and it isn't like the uploader gets a massive advantage for uploading corrupt files. The CPU and bandwidth costs of transcoding to 40+ different audio and video formats would be massive though. I could imagine a 5 minute video taking more than 24 hours to transcode on a phone.
    - simcop2387 6y ago
      > Checking the result is good shouldn't be too hard - a simple spot check of a few frames should be sufficient, and it isn't like the uploader gets a massive advantage for uploading corrupt files. Uploading corrupt files could allow the uploader to execute code on future client machines. You must check every frame and the full encoding of the video.
      - kevincox 6y ago
        Must is a strong word. In theory browsers and other clients treat all video stream as untrusted and it is safe to watch an arbitrary video. However complex formats like videos are a huge attack surface. So yes, for the bigger names like Google this is an unacceptable risk. They will generally avoid serving any user-generated complex format like video, images or audio to users directly. Everything is transcoded to reduce the likelihood that an exploit was included.
8K832d7tNmiQ 6y ago
The real news here is that They still use GPU to transcode their videos whilst other service such as search engine already use TPU for almost a decade now. I thought they've already use custom chip for transcoding for decades.
- baybal2 6y ago
  They were actually transcoding on CPUs before, not GPUs
- rland 6y ago
  GPUs have specialized hardware for video transcoding, no? So this actually makes sense. The product was already made (although, perhaps not up to Youtube's standard) by GPU manufacturers.
  - numlock86 6y ago
    The specialized hardware in GPUs is targeted at encoding content on the fly. While you could use this to encode a video for later playback it has a couple of drawbacks when it comes to size and quality, namely h264, keyframes, static frame allocations, no multipass encoding, etc. ... This is why video production software that supports GPU encoding usually marks this option as "create a preview, fast!". It's fast but that's it. If you want a good quality/size ratio you would use something like VP9 for example. Because of missing specialized hardware and internals of the codec itself currently this is very slow. Add multipass encoding, something like 4k at 60 frames, adaptive codec bitrates and suddenly encoding a second takes a over two minutes ... the result is the need for specialized hardware.
    - rland 5y ago
      That is interesting, I didn't know that. I thought that doing computation on the GPU sped up encoding for even the high quality presets.
- jng 6y ago
  Is there any solid information about Google using TPU for the search engine, or is this an assumption you're making?
pengaru 6y ago
How long before the ads are realtime encoded into the video streams such that even youtube-dl can't bypass them without a premium login? I've been surprised this wasn't already the case, but assumed it was just an encoding overhead issue vs. just serving pre-encoded videos for both the content and ads with necessarily well-defined stream boundaries separating them.
- martin-adams 6y ago
  I suspect doing personalised ads obliterates any caching method on cheaper hardware than transcoding servers. Interesting problem to solve though.
  - amelius 6y ago
    > Interesting problem to solve though. Ah, smart people and ads ...
  - jwandborg 6y ago
    The ads are not part of the encoded video AFAICT, they are probably served as a separate stream which the client requests alongside the regular video stream, this means that videos and ads can be cached using traditional techniques.
- garblegarble 6y ago
  You wouldn't even need to do real-time encoding for that, you can simply mux them in at any GOP boundary (other services already do real-time ad insertion in MPEG-DASH manifests) Example: https://www.youtube.com/watch?v=LFHEko3vC98 https://www.youtube.com/watch?v=LFHEko3vC98
  - elithrar 6y ago
    Right, using DAI means you don’t have to actually touch the original video (good!) but doesn’t stop a smart enough client (youtube-dl) from pattern matching and ignoring those segments when stitching the final video together. I am not, however, suggesting that encoding ads into the final stream is appropriate or scalable, though!
bradfa 6y ago
The paper linked in the ARS article (https://dl.acm.org/doi/abs/10.1145/3445814.3446723 https://dl.acm.org/doi/abs/10.1145/3445814.3446723) seems to be how they developed it. I find it interesting that they went from C++ to hardware in order to optimize the development and verification time. In my past experience working with FPGA designers, I was always told that any C-to-H(ardware) tooling was always quicker to develop but often had significant performance implications for the resulting design in that it would consume many more gates and run significantly slower. But, if you have a huge project to undertake and your video codec is only likely to be useful for a few years, you need to get an improvement (any improvement!) as quick as possible and so the tradeoff was likely worth it for Google. Or possibly the C-to-H tooling has gotten significantly better recently? Anyone aware of what the state of the art is now with this to shed some light on it?
- pclmulqdq 6y ago
  It has not, and the type of design they show in the paper has a lot of room to improve (FIFOs everywhere, inefficient blocks, etc). However, video transcoding is suited to that approach since the operations you do are so wide that you can't avoid a speedup compared to software.
rurban 6y ago
"now" being 2015. They are talking about the new 2nd generation chip here, which is a bit faster.
gigatexal 6y ago
Honestly I’m surprised they didn’t do this earlier
qwertox 6y ago
I wonder how YouTube's power consumption in transcoding the most useless / harmful videos relates to Bitcoin's power consumption. Maybe even every video should be included in the calculation, since Bitcoin also has its positive aspects. I've never heard about how much power YouTube's transcoding is consuming, but transcoding has always been one of those very CPU-intensive tasks (hence it was one of the first tasks to be moved over to the GPU).
mauricio 6y ago
Impressive. I wonder if Google will sell servers with these cards via Google Cloud. Seems like it could be pretty competitive in the transcoding space and also help them push AV1 adoption.
- jankeymeulen 6y ago
  You can transcode as a service on Google Cloud: https://cloud.google.com/transcoder/docs https://cloud.google.com/transcoder/docs
kevincox 6y ago
> Google's warehouse-scale computing system. That is quite the understatement. Google's computing system is dozens of connected "warehouses" around the world.
vhiremath4 6y ago
I'm just always blown away that Google transcodes into as many formats as they do upfront. I wonder if they do a mix of just in time transcoding on top of queue-based.
- sgarland 6y ago
  For VP9/x264, almost certainly not. If you jump on a newly-uploaded video, you'll see that higher resolution comes later. It's common to see 720p nearly immediately, then 1080p, then 4K. For pre-x264, they probably could, but between the relatively small sizes required for the low resolution those codecs would be supporting, and the cost difference between compute and storage, I'd bet everything is encoded beforehand.
justinzollars 6y ago
Youtube blog post on this topic: https://blog.youtube/inside-youtube/new-era-video-infrastructure https://blog.youtube/inside-youtube/new-era-video-infrastruc...
gigel82 6y ago
I'm wondering if this is related to the recent Roku argument; perhaps YouTube is trying to force Roku to incorporate a hardware decoding chip (maybe with an increased cost) in future products as a condition to stay on the platform.
- conk 6y ago
  I don’t think YouTube cares if you use hardware of software decoding. I also don’t think they care if you use their hardware decoder or someone else’s. The issue with roku is they don’t want to include any extra hardware to support vp9, and they use such cheap/low spec hardware they can’t reliably decode in software.
imwillofficial 6y ago
This is intense. ASICS making a comeback again. It’s weird how the computer market is so cyclical with regard to trends.
tibbydudeza 5y ago
I wonder how much storage Youtube currently uses ???.

259 points by beambot 6y ago

sidcool 6y ago

For YouTube's scale it makes sense, since a small saving or efficiency boost would accumulate at their scale.

kevingadd 6y ago
Not just cost reduction or efficiency, the faster encodes you can get through dedicated hardware mean they can potentially reduce the delay between a video being uploaded and a video being available to the public (right now even if you don't spend time waiting in the processing queue, it takes a bit for your videos to get encoded) You can handle larger volumes of incoming video by spinning up more encoder machines, but the only solution for lowering latency is faster encodes, and with the way the CPU and GPU markets are these days a dedicated encoder chip is probably your best bet.
- Dylan16807 6y ago
  You can split a video up across cores or even across servers. Encoding speed does not need to have a significant impact on publishing latency.

Traubenfuchs 6y ago

The dangerous case of custom hardware making a software business significantly more efficient: This makes disruption and competition even harder.

azurezyq 6y ago
It's inevitable, and this applies to other kinds of optimizations as well. This place is too mature, disruption might be easier elsewhere.
c7DJTLrn 6y ago
What is there to compete for? Video hosting is a money-losing business unless you have exclusives, like Floatplane.
- endless1234 6y ago
  What is floatplane, never heard of it? Seemingly an yt competitor by a somewhat popular youtuber. App on Android has "10k+" installs. Isn't it _way_ too early to say it wouldn't be a money losing business?
  - oblio 6y ago
    My guess is that the commenter is either a Floatplane insider or possibly just optimistic :-)
  - throwaway3699 6y ago
    Think of Floatplane as more of a Patreon competitor with a video component, than a YouTube competitor.
  - bobsmooth 6y ago
    Linus' goal for Floatplane is "If it doesn't fly, it'll at least float." There's only 20 creators on it and it's intended to compliment YouTube, not replace it.
- human_error 6y ago
  What's floatplane? Hadn't heard of it. The website doesn't say much.
  - pcmill 6y ago
    Floatplane is a video service built by the people behind the popular Youtube channel LinusTechTips. It is not a direct competitor to Youtube though. The platform makes it easier to let paying fans get videos earlier but it is not meant to build an audience.
fancyfredbot 6y ago
This will keep costs down but I am not sure cost of transcoding is the major barrier to entry? I think the network effect (everyone is on YouTube) had already made disruption pretty difficult!
- NicoJuicy 6y ago
  Depends how you look at it. There could be someone making these chips and then a competitor with lower startup costs than before.
- londons_explore 6y ago
  Things like youtube run on super-thin margins. Bandwidth and storage costs are massive, compute costs quite big, and ad revenue really quite low. A competitor would need either a different model to keep costs low (limit video length/quality, the vimeo model of forcing creators to pay, or go for the netflix-like model of having a very limited library), or very deep pockets to run at a loss until they reach youtube-scale. I'm still mystified how tiktok apparently manage to turn a profit. I have a feeling they are using the 'deep pockets' approach, although the short video format might also bring in more ad revenue per hour of video stored/transcoded/served.
Traster 6y ago
To be honest I suspect it isn't actually a differentiator. It's good for Google that they can produce this chip and trim their hardware costs by some percentage, but it's not going to give them a competitive advantage in the market of video sharing. Especially in a business like youtube with network effects, getting the audience is the difficult bit, the technical solutions are interesting but you're not going to beat google by having 5% cheaper encoding costs.
ant6n 6y ago
Perhaps. But the big issues for YouTube right now isnt efficiency per se, but copyright, monetization, ai-tagging, social clout. If a YouTube competitor can get the content creators and offer them viewers, competition could perhaps work. This fight is probably not fought at the margins of hardware optimization.
mrtksn 6y ago
It's like crystallisation of the software. When you decide that this is the best version of an algorithm, you make a hardware that is extremely efficient in running that algorithm. It probably means that, unless you have a groundbreaking algorithm on something that is available as hardware, you simply do software on something that is not "perfected". It trims marginal improvements.
CyberRabbi 6y ago
Usually competition for a general platform like YouTube comes in the form of unbundling and in that case these last mile optimizations will matter little.
- narrator 6y ago
  The main competitors to YouTube are the sites that have non-illegal content that YouTube won't host. e.g: Porn and controversial political stuff.
  - CyberRabbi 6y ago
    That might be true but I think sites like odyssey are more popular than controversial political video sites.
wishysgb 6y ago
as long as you can buy the parts or have the HDL to deploy it on an FPGA you should be fine
blihp 6y ago
It's the seemingly infinite bandwidth that Google throws at YouTube that make competition hard. Then there's the inability to monetize. Transcoding is probably about 20th on the list of issues.
yuhong 5y ago
I wonder what the WMF will do when the H.264 patents expire and all these videos needs to be transcoded.

pizza234 6y ago

A couple of interesting bits: - without dedicated processors, VP9's encoding is roughly 4.5x as slow as H.264, while with the VPUs, the two formats perform the same; this is a big win for the open format(s) - sad extract: "Google has aggressively fought to keep the site's cost down, often reinventing Internet infrastructure and copyright in order to make it happen" (emphasis mine)

sillysaurusx 6y ago
Why is that sad? No company in Google's position could've done better, probably. Youtube was about to be sued into oblivion till Google purchased it.
- serf 6y ago
  >Why is that sad? because the wholesale destruction and minimization of knowledge, education, and information to appease (often arbitrary) intellectual protectionism laws is sad, regardless of who perpetrates it. non-Google example : What.cd was a site centered around music piracy, but that potentially illegal market created a huge amount of original labels and music that still exists now in the legal sphere. No one would defend the legal right for what.cd to continue operating, it was obviously illegal; but the unique, novel, and creative works that came from the existence of this illegal enterprise would be sad to destroy. Swinging back to the Google example : YouTube systematically destroys creations that they feel (often wrongly) infringe upon IP. This is often not even the case, Google routinely makes wrong decisions erring on the side of the legal team. This destruction of creative work is sad, in my opinion it's more sad than the un-permitted use of work. Of course, Google as a corporation should act that way, but it's sad in certain human aspects.
  - nolok 6y ago
    It's not just google as a corporation, it's google as a legal entity. Have your own site in your own individual name with no corporate entity nor search for profit offering to host people's videos for free, and I guarantee you that within 24h you are dealing with things ranging from pedophilia to copyright violations and the like. And if you don't clear them out, you're the one responsible. Google is acting the way society has decided they should act through the laws it voted. Could they act another, more expensive, way in order to save a bit more of content that get caught by mistake ? Definitely, but why would they as a company when the laws says any mistake or delay is their fault. Source: like many people, I once made a free image hosting thingy. It was overrun by pedos within a week to my absolute horror and shock. Copyright infringement is obviously not the same at all, BUT the way the law act toward the host is not that different "ensure there is none and be proactive in cleaning, or else ...".

CyberRabbi 6y ago

Wow 33x throughput improvement for vp9 for the same hardware cost. That seems excessive but their benchmark is using ffmpeg. Is ffmpeg known to have the theoretically highest throughput possible state of the art vp9 encoder algorithms? Or is there any way of knowing if their hardware IP block is structured equivalently to the ffmpeg software algorithm? I know that custom hardware will always beat general hardware but 33x is a very large improvement. Contemporary core counts coupled with very wide simd makes CPUs functionally similar to ASIC/fpga in many cases.

brigade 6y ago
The only OSS VP9 encoder is Google’s own libvpx, which is what ffmpeg uses.
- rndgermandude 6y ago
  By now Intel has released an open source encoder (BSD-2 + patent grants), tuned for their Xeons: https://github.com/OpenVisualCloud/SVT-VP9 https://github.com/OpenVisualCloud/SVT-VP9
bumbada 6y ago
That doesn't look so excessive to me. We get hundred or thousand times more efficiency and performance regularly using custom electronics for things like 3d or audio recognition. But programming fixed electronics in parallel is also way harder than flexible CPUs. "Contemporary core counts coupled with very wide simd makes CPUs functionally similar to ASIC/fpga in many cases." I don't think so. For things that have a way to be solved in parallel, you can get at least a 100x advantage easily. There are lots of problems that you could solve in the CPU(serially) that you just can't solve in parallel(because they have inter dependencies). Today CPUs delegate the video load to video coprocessors of one type or another.
- bumbada 6y ago
  BTW: Multiple CPUs cores are not parallel programming in the sense fpgas or ASICS (or even GPUs) are. Multiple cores work like multiple machines, but parallel units work choreographically in sync at lower speeds(with quadratic energy consumption). They could share everything and have only the needed electronics that do the job.

colonwqbang 6y ago

If anything it's just strange that such a part didn't exist before (if it really didn't). Accelerated encoding is hugely more power efficient than software encoding.

wishysgb 6y ago
well I do believe video transcoding chips have been there forever. But I think those chips should be tailored to their exact application making them more efficient
fireattack 6y ago
The complement of "building its own video-transcoding chips " isn't just software encoding though. Google/Youtube could have already been using hardware encodings, just with generic GPUs or whatever existing hardware.
izacus 6y ago
I've worked on a IPTV broadcasting system and this isn't as obvious as you'd think. The big issue here is quality - most hardware encoders hugely lag behind software encoders. By quality I mean visual quality per bytes/s. Which means that using a quality software encoder like x264 will save you massive amount of money in bandwidth costs because you can simply go significantly lower in bitrate than you can with a hardware encoding block. At the time, our comparisons showed that you could get away with as low as 1.2MBps for 720p stream where with an enterprise HW encoder you'd have to do about 2-3MBps to have the same picture quality. That's one consideration. The other consideration is density - at the time most hardware encoders could do up to about 4 streams per 1U rack unit. Those rack units cost about half the price of a fully loaded 24+ core server. Even GPUs like nVidia at the time could do at most 2 encoding sessions with any kind of performance. On CPU, we could encode 720p on about 2 Xeon cores which means that a fully loaded server box with 36+ cores could easily do 15-20 sessions of SD and HD and we could scale the load as necessary. And the last consideration was price - all HW encoders were significantly more expensive than buying large core count rack-mount servers. Funny enough, many of those "HW specialised encoding" boxes were running x86 cores internally too so they weren't even more power efficient. So in the end the calculation was simple - software encodes saved a ton of money on bandwidth, it allowed better quality product because we could deliver high quality video to people with poor internet connectivity, it made procuring hardware simple, it made the solution more scalable and all that at the cost of some power consumption. Easy trade. Of course the computation is a bit different with modern formats like VP9 and H.265/HEVC - the software encoders are still very CPU intensive so it might make sense to buy cards these days. Of course, we weren't Google and couldn't design and manufacture our own hardware. But seeing the list of codecs YouTube uses, there's also one more consideration: flexibility. HW encoding blocks are usually very limited at what they can do - most of them will do H.264, some of them will stretch to H.265 and maaaaaybe VP9. CPUs will encode into everything. Even when a new format is needed, you just deploy new software, not a whole chip.

spuz 6y ago

> Google probably only provides stats about growth (like "500 hours of video are uploaded to YouTube every minute") because the total number of videos is so large, it's an unknowable amount. I suppose you could sample random YouTube urls to find out how many of them link to public videos. Given the total number of possible URLs, it would give you an idea of what percentage of them have been used and therefore how many videos YouTube has in total. It would not tell you how many private videos or Google Drive / Photos videos exist of course.

warent 6y ago
It doesn't seem like this would work. I think you could sample trillions of YouTube IDs with a high likelihood of all of them being unused. They're supposed to be unique after all
- chrisseaton 6y ago
  What do you mean 'supposed to be unique'? How can an ID not be unique?
  - zakki 6y ago
    Maybe when they reach 62^11 + 1?
- rococode 6y ago
  Clicked into a couple random videos, looks like all of their video IDs are 11 characters, alphanumeric with cases. So 26+26+10 = 62 choices for each char, 62^11 = 5.2e+19 = 52 quintillion unique IDs (52 million trillions). So, yeah, sampling would be a mostly futile effort since you're looking to estimate about 8 to 10 decimal digits of precision. Though it's technically still possible since you'd expect about 1 in every 50 million - 5 billion IDs to work (assuming somewhere between a trillion and 10 billion videos). My statistics knowledge is rusty, but I guess if you could sample, say, 50 billion urls you could actually make a very coarse estimate with a reasonable confidence level. That's a lot but, ignoring rate limits, well within the range of usual web-scale stuff.

samwestdev 6y ago

Why don’t they encode on the uploader machine?

pta2002 6y ago
Can't trust user input, you'd have to spend quite a bit of energy just checking to see if it's good. You also want to transcode multiple resolutions, it'd end up being quite slow if it's done using JS.
- amelius 6y ago
  Verification is simpler than encoding, I suppose.
- londons_explore 6y ago
  Checking the result is good shouldn't be too hard - a simple spot check of a few frames should be sufficient, and it isn't like the uploader gets a massive advantage for uploading corrupt files. The CPU and bandwidth costs of transcoding to 40+ different audio and video formats would be massive though. I could imagine a 5 minute video taking more than 24 hours to transcode on a phone.
  - simcop2387 6y ago
    > Checking the result is good shouldn't be too hard - a simple spot check of a few frames should be sufficient, and it isn't like the uploader gets a massive advantage for uploading corrupt files. Uploading corrupt files could allow the uploader to execute code on future client machines. You must check every frame and the full encoding of the video.
    - kevincox 6y ago
      Must is a strong word. In theory browsers and other clients treat all video stream as untrusted and it is safe to watch an arbitrary video. However complex formats like videos are a huge attack surface. So yes, for the bigger names like Google this is an unacceptable risk. They will generally avoid serving any user-generated complex format like video, images or audio to users directly. Everything is transcoded to reduce the likelihood that an exploit was included.

8K832d7tNmiQ 6y ago

The real news here is that They still use GPU to transcode their videos whilst other service such as search engine already use TPU for almost a decade now. I thought they've already use custom chip for transcoding for decades.

baybal2 6y ago
They were actually transcoding on CPUs before, not GPUs
rland 6y ago
GPUs have specialized hardware for video transcoding, no? So this actually makes sense. The product was already made (although, perhaps not up to Youtube's standard) by GPU manufacturers.
- numlock86 6y ago
  The specialized hardware in GPUs is targeted at encoding content on the fly. While you could use this to encode a video for later playback it has a couple of drawbacks when it comes to size and quality, namely h264, keyframes, static frame allocations, no multipass encoding, etc. ... This is why video production software that supports GPU encoding usually marks this option as "create a preview, fast!". It's fast but that's it. If you want a good quality/size ratio you would use something like VP9 for example. Because of missing specialized hardware and internals of the codec itself currently this is very slow. Add multipass encoding, something like 4k at 60 frames, adaptive codec bitrates and suddenly encoding a second takes a over two minutes ... the result is the need for specialized hardware.
  - rland 5y ago
    That is interesting, I didn't know that. I thought that doing computation on the GPU sped up encoding for even the high quality presets.
jng 6y ago
Is there any solid information about Google using TPU for the search engine, or is this an assumption you're making?

pengaru 6y ago

How long before the ads are realtime encoded into the video streams such that even youtube-dl can't bypass them without a premium login? I've been surprised this wasn't already the case, but assumed it was just an encoding overhead issue vs. just serving pre-encoded videos for both the content and ads with necessarily well-defined stream boundaries separating them.

martin-adams 6y ago
I suspect doing personalised ads obliterates any caching method on cheaper hardware than transcoding servers. Interesting problem to solve though.
- amelius 6y ago
  > Interesting problem to solve though. Ah, smart people and ads ...
- jwandborg 6y ago
  The ads are not part of the encoded video AFAICT, they are probably served as a separate stream which the client requests alongside the regular video stream, this means that videos and ads can be cached using traditional techniques.
garblegarble 6y ago
You wouldn't even need to do real-time encoding for that, you can simply mux them in at any GOP boundary (other services already do real-time ad insertion in MPEG-DASH manifests) Example: https://www.youtube.com/watch?v=LFHEko3vC98 https://www.youtube.com/watch?v=LFHEko3vC98
- elithrar 6y ago
  Right, using DAI means you don’t have to actually touch the original video (good!) but doesn’t stop a smart enough client (youtube-dl) from pattern matching and ignoring those segments when stitching the final video together. I am not, however, suggesting that encoding ads into the final stream is appropriate or scalable, though!

bradfa 6y ago

The paper linked in the ARS article (https://dl.acm.org/doi/abs/10.1145/3445814.3446723 https://dl.acm.org/doi/abs/10.1145/3445814.3446723) seems to be how they developed it. I find it interesting that they went from C++ to hardware in order to optimize the development and verification time. In my past experience working with FPGA designers, I was always told that any C-to-H(ardware) tooling was always quicker to develop but often had significant performance implications for the resulting design in that it would consume many more gates and run significantly slower. But, if you have a huge project to undertake and your video codec is only likely to be useful for a few years, you need to get an improvement (any improvement!) as quick as possible and so the tradeoff was likely worth it for Google. Or possibly the C-to-H tooling has gotten significantly better recently? Anyone aware of what the state of the art is now with this to shed some light on it?

pclmulqdq 6y ago
It has not, and the type of design they show in the paper has a lot of room to improve (FIFOs everywhere, inefficient blocks, etc). However, video transcoding is suited to that approach since the operations you do are so wide that you can't avoid a speedup compared to software.

rurban 6y ago

"now" being 2015. They are talking about the new 2nd generation chip here, which is a bit faster.

gigatexal 6y ago

Honestly I’m surprised they didn’t do this earlier

qwertox 6y ago

I wonder how YouTube's power consumption in transcoding the most useless / harmful videos relates to Bitcoin's power consumption. Maybe even every video should be included in the calculation, since Bitcoin also has its positive aspects. I've never heard about how much power YouTube's transcoding is consuming, but transcoding has always been one of those very CPU-intensive tasks (hence it was one of the first tasks to be moved over to the GPU).

mauricio 6y ago

Impressive. I wonder if Google will sell servers with these cards via Google Cloud. Seems like it could be pretty competitive in the transcoding space and also help them push AV1 adoption.

jankeymeulen 6y ago
You can transcode as a service on Google Cloud: https://cloud.google.com/transcoder/docs https://cloud.google.com/transcoder/docs

kevincox 6y ago

> Google's warehouse-scale computing system. That is quite the understatement. Google's computing system is dozens of connected "warehouses" around the world.

vhiremath4 6y ago

I'm just always blown away that Google transcodes into as many formats as they do upfront. I wonder if they do a mix of just in time transcoding on top of queue-based.

sgarland 6y ago
For VP9/x264, almost certainly not. If you jump on a newly-uploaded video, you'll see that higher resolution comes later. It's common to see 720p nearly immediately, then 1080p, then 4K. For pre-x264, they probably could, but between the relatively small sizes required for the low resolution those codecs would be supporting, and the cost difference between compute and storage, I'd bet everything is encoded beforehand.

justinzollars 6y ago

Youtube blog post on this topic: https://blog.youtube/inside-youtube/new-era-video-infrastructure https://blog.youtube/inside-youtube/new-era-video-infrastruc...

gigel82 6y ago

I'm wondering if this is related to the recent Roku argument; perhaps YouTube is trying to force Roku to incorporate a hardware decoding chip (maybe with an increased cost) in future products as a condition to stay on the platform.

conk 6y ago
I don’t think YouTube cares if you use hardware of software decoding. I also don’t think they care if you use their hardware decoder or someone else’s. The issue with roku is they don’t want to include any extra hardware to support vp9, and they use such cheap/low spec hardware they can’t reliably decode in software.

imwillofficial 6y ago

This is intense. ASICS making a comeback again. It’s weird how the computer market is so cyclical with regard to trends.

tibbydudeza 5y ago

I wonder how much storage Youtube currently uses ???.