Skip to content
The methodOpen data
Back to the collection

Warehouse-scale video acceleration: co-design and deployment in the wild

Parthasarathy Ranganathan, Daniel Stodolsky, Jeff Calow

Show all 52 authors

Jeremy Dorfman, Marisabel Guevara, Clinton Wills Smullen IV, Aki Kuusela, Raghu Balasubramanian, Sandeep Bhatia, Prakash Chauhan, Anna Cheung, In Suk Chong, Niranjani Dasharathi, Jia Feng, Brian Fosco, Samuel Foss, Ben Gelb, Sara J. Gwin, Yoshiaki Hase, Da-ke He, C. Richard Ho, Roy W. Huffman Jr., Elisha Indupalli, Indira Jayaram, Poonacha Kongetira, Cho Mon Kyaw, Aaron Laursen, Yuan Li, Fong Lou, Kyle A. Lucke, JP Maaninen, Ramon Macias, Maire Mahony, David Alexander Munday, Srikanth Muroor, Narayana Penukonda, Eric Perkins-Argueta, Devin Persaud, Alex Ramirez, Ville-Mikko Rautio, Yolanda Ripley, Amir Salek, Sathish Sekar, Sergey N. Sokolov, Rob Springer, Don Stark, Mercedes Tan, Mark S. Wachsler, Andrew C. Walton, David A. Wickeraad, Alvin Wijaya, Hon Kwan Wu

2021 · Proceedings of the 26th ACM International Conference on Architectural Support for Programming Languages and Operating Systems

Other research
Read the paper
HN score
0
Mentions
4
Readers
4
Months
4
What’s in a score?

In the conversation

Original HN comments, with labels from simple text rules. A label describes the whole comment and may miss context or irony. Read the discussion to make up your own mind. About the labels

4 selected excerpts · 4 total mentions

r3013
Neutral mention · rule
The actual papers are very detailed. https://ieeexplore.ieee.org/document/9567040 https://dl.acm.org/doi/abs/10.1145/3445814.3446723 They basically have computing per energy as an efficiency spec and then they show how that spec increased by 20-33x compared to an "Intel Skylake" machine. Google also added some features, like a custom speed vs quality tuning thing, and single and multi-output transcoding. What was interesting to me is the video core was made with "Catapult, a C++ HLS flow from Siemens".
Original comment The end of Moore's Law forced YouTube to make its own video chip
bradfa
Neutral mention · rule
The paper linked in the ARS article (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?
Original comment YouTube is now building its own video-transcoding chips
photojosh
Neutral mention · rule
I was most curious about how they parallelise the encoding for the multiple resolutions. The juicy bits from the paper are [1] "MOT [multiple-output transcoding] is an alternative approach where a single transcoding task produces the desired combination of resolutions and formats for a given chunk (Figure 2b). The input chunk is read and decoded once, and then downscaled and encoded to all output variants in parallel. This reduces the decoding overheads and allows efficient sharing of control parameters obtained by analysis of the source (e.g., detection of fades/flashes). MOT is generally preferred to SOT, as it avoids redundant decodes for the same group of outputs,…
Read the full comment
but SOT may be used when memory or latency needs mandate it." "Multiple-output transcoding (MOT) was considered foundational for encoder utilization because of the benefits discussed in Section 2. The efficiency of decoding once, scaling, and encoding an entire MOT graph on a single VCU simplifies scheduling and reduces resource consumption at the data center level. The typical structure of a multi-output transcode is a single-decode and then the set of conventional 16:9 outputs (e.g. for 1080p inputs: 1080p, 720p, 480p, 360p, 240p, and 144p are encoded). This scales down the decode needs of the VCU by the number of outputs and generally only doubles the encoding requirements. Few videos require an entire VCU for their MOT, so we designed our VCUs to perform multiple MOTs and SOTs in parallel to boost encoder and VCU utilization" "In fact, our production workload is largely MOT, which was not supported on our GPU baseline. Prior to VCU, the production workload used multiple SOTs instead of running MOT on CPU given the high latency. MOT throughput is 1.2-1.3x higher than SOT (976 Mpix/s on H.264 and 927 Mpix/s on VP9), stemming from the single decode that is reused to produce all the output resolutions." I grabbed the list of formats for a current popular video too [0] just to give me an idea. 160 mp4 256x128 144p 64k , mp4_dash container, avc1.4d400c@ 64k, 30fps, video only, 5.28MiB 278 webm 256x128 144p 68k , webm_dash container, vp9@ 68k, 30fps, video only, 5.59MiB 242 webm 426x214 240p 113k , webm_dash container, vp9@ 113k, 30fps, video only, 9.27MiB 133 mp4 426x214 240p 145k , mp4_dash container, avc1.4d400d@ 145k, 30fps, video only, 11.90MiB 243 webm 640x320 360p 209k , webm_dash container, vp9@ 209k, 30fps, video only, 17.12MiB 134 mp4 640x320 360p 253k , mp4_dash container, avc1.4d401e@ 253k, 30fps, video only, 20.71MiB 244 webm 854x428 480p 347k , webm_dash container, vp9@ 347k, 30fps, video only, 28.40MiB 135 mp4 854x428 480p 482k , mp4_dash container, avc1.4d401f@ 482k, 30fps, video only, 39.45MiB 247 webm 1280x640 720p 630k , webm_dash container, vp9@ 630k, 30fps, video only, 51.52MiB 136 mp4 1280x640 720p 834k , mp4_dash container, avc1.64001f@ 834k, 30fps, video only, 68.17MiB 248 webm 1920x960 1080p 1103k , webm_dash container, vp9@1103k, 30fps, video only, 90.18MiB 137 mp4 1920x960 1080p 1507k , mp4_dash container, avc1.640028@1507k, 30fps, video only, 123.22MiB 271 webm 2560x1280 1440p 2608k , webm_dash container, vp9@2608k, 30fps, video only, 213.13MiB 313 webm 3840x1920 2160p 7953k , webm_dash container, vp9@7953k, 30fps, video only, 649.98MiB 18 mp4 640x320 360p 395k , avc1.42001E, 30fps, mp4a.40.2 (44100Hz), 32.35MiB 22 mp4 1280x640 720p 962k , avc1.64001F, 30fps, mp4a.40.2 (44100Hz) (best) [0] https://www.youtube.com/watch?v=ehv3zQAa9zM [1] https://dl.acm.org/doi/abs/10.1145/3445814.3446723
Original comment YouTube is now building its own video-transcoding chips

Keep following the thread.

More in Other research

More from the same topics.