公告：youtube加观看量--油管买播放量网站
前段时间丹尼尔对折两条博客，文本大体说的是 B 站为的是省频宽，私自在 Web 端迈入了 HEVC 代码音频播映，引致他们在用应用程序看 B 站音频的这时候，笔记本电脑很难就会处于一类高阻抗的运转状况。
许多网民看见这条博客后，也是争相在文章区回帖说 难怪我一看 B 站笔记本电脑散热器就Balrog过载还贼快 、 我说呢，看 B 站音频不时尚普托原本是事实胜于雄辩 、 看 B 站能源消耗掉泵三倍的电 。。。
虽然 B 站非官方而后撰文则表示 HEVC 代码方式并并非强制性采用，多于电子设备满足用户很大操控性才会迈入：
但仍然却是有许多网民不在意。
讲真，在没看见这条博客前，丹尼尔以后还真没是并非注意到那个事，但是在介绍确切 HEVC 到底是甚么后，我真的此次许多人可能将大发雷霆 B 站了。
最少在采用 HEVC 代码音频播映整件事上，B 站那么做并没错，反倒是应用程序拖了 B 站的大树枝。
为甚么那么说呢？这就要从音频压缩的必要性开始说起了。
许多人可能将不知道，无论是他们用手机拍出来的音频，却是别人发在网上的音频，其实都经过了压缩，如果音频没压缩，原始文件就会变得非常大。
就拿一段 1080P 60 帧的音频来说吧。
音频每一帧有 200 万像素（ 1920*1080 ），每个像素算占 3 个字节（ R、G、B 各一个），这意味着一帧画面就要消耗 5.7MB，60 帧就是 342 MB：
如果不压缩，一台 256G 的手机，满打满算也只能拍 766.5 秒 1080P 60 帧音频，换你你能接受？
另外要是你想在线观赏完全没压缩过的1080P 60 帧音频，没 3000 兆以上的宽带提供网速支持，音频来不及加载也就根本没法流畅播映好吧。。。
所以为的是方便音频的保存和传播，他们肯定有必要对它进行压缩。
压缩音频的原理讲起来有点儿复杂，但要是往简单的说主要就是干了三件事 ——跳帧、划块、抽色。
比如说在前期把相似的画面只保留一帧，后期再通过预测还原；
又或者把一块颜色相同的区域当做一个大色块处理；
再或者偷偷砍掉人眼不难察觉的颜色，毕竟现在的音频甚至能装十亿种色彩，人眼基本分辨不出那么多。
总之效率越高压缩代码技术，往往可以在保证不损失画质的前提下，尽可能将地把音频体积压缩到更小。
而 HEVC 就是一类高效的音频压缩代码技术，它通常也被叫作 H.265。
根据非官方给出的说法，HEVC 相比传统的 AVC 也就是 H.264 压缩代码技术，可以在保证相同音频画质的前提下，减少约 50% 左右的数据量。
简单来说就是同等规格的音频，采用 HEVC 代码所需要的空间大概是 AVC 的一半甚至更少，而且 HEVC 最高甚至支持对 8K 超高清音频进行代码。
这样一来经过 HEVC 代码压缩后的音频，体积还可以进一步减小，他们也只需更低的频宽就能实现高清音频在线播映或者直播推流。
也正是基于 HEVC 这种更高效的代码，早在 2017 年，苹果就开始让自家 iOS 11 支持 HEVC，并且首个支持 HEVC 的应用就是它自带的相机 App。
而安卓而后也是很快就跟上了，到如今基本上每台手机都能拍摄并且播映 HEVC 代码格式的音频：
另外像是 AMD、NVIDIA、英特尔等厂商，也早就在硬件上开放了对 HEVC 编解码的支持。
而对画质有追求的 B 站呢，也是从 2019 年就上线了 HEVC 代码，算是国内一众音频中文网站中最早支持 HEVC 的那一批，它那么做也算是在紧跟潮流。
之所以他们看 B 站音频会引致笔记本电脑卡顿或者发热严重，要怪就怪 Chrome 和那些采用 Chromium 内核的应用程序到现在都不支持 GPU 硬解 HEVC。
应用程序不支持 GPU 硬解 HEVC 会引致一个问题，那就是它在播映音频时只能通过 CPU 来实现软解码，这对 CPU 的运算操控性要求非常高。
丹尼尔实测，用 Chrome 看 B 站高画质的音频。
如果你在设置里选了 优先采用 HEVC 代码音频播映 ，你会发现它对 CPU 的占用率非常高，都快飙到 100 了，而对 GPU 的占用率却一直都很低：
而一旦你把音频切换成 Chrome 支持硬解的 AVC 代码播映，应用程序对 CPU 的占用率立马就会降下去，GPU 的占用率虽然有所上升，但并不算高：
这是因为 GPU 拥有专门的解码模块，在硬解对应代码音频这时候的解码效率非常高，不但能减轻 CPU 的负担，还有着功耗低、发热少的特点。
遗憾的是，丹尼尔特意去搜了下，目前除了苹果端的 Safari 应用程序，包括 Chrome、Edge 在内的其它几个主流应用程序均不支持硬解 HEVC。。。
这些应用程序不支持硬件 HEVC 的原因倒并非因为技术受限，而是因为想要获得 HEVC 相关组织的授权，所需要支付的授权费一点都不低。
目前负责 HEVC 授权的组织一共有三家，就拿其中相对比较厚道的 MPEG LA 来说。
想要获得它家的 HEVC 授权，厂商每年头十万台终端免费，后每台终端就要花费 0.20 美元，但是每年封顶 2500 万美元，但也是笔不小的数目。
那个费用在手机厂商看来可能将没啥，毕竟成本分摊到每台手机上也就是两块不到的事，但对于可以免费下载到多台电子设备的应用程序来说就很恐怖了。
所以以后谷歌也搞了一套叫做 VP9 的代码方式，操控性和 H.265 差不多，但其他厂商不乐意啊！
一方面是因为 Chrome 的市占率太大，要是大家选了这套方案，谷歌肯定一家独大，甚至可能将垄断音频代码市场。
另一方面，则是因为 VP 系列代码是参考 H.26x 开发，对于这代码是否侵犯专利还真说不确切，万一真出事了，那些用了 VP9 的厂商，可能将也会有麻烦。
到这时候出事了谷歌可不会对此负责~
所以现在谷歌、微软、亚马逊、Facebook、Netflix 等几大互联网公司联合推出了开源免费的 AV1 压缩代码技术。
它的音频压缩效率不比 HEVC 低，既然有免费的这些应用程序当然会优先考虑支持它。
之所以要那么干，也是因为天天给别人交专利费，心里不爽，有那个技术条件，搞个更好用的出来，岂不美哉？
只但是由于在音频编解码方面，为那个代码格式提供硬件解码的厂商目前比较少，现在多于各大芯片厂商以及最新的显卡比如 RTX 系列才能支持。
所以日后 AV1 能不能成为一类主流音频代码格式却是个问题。
回到 B 站推 HEVC 整件事上。
B 站作为国内少有能提供 8K 以及 HDR 10 文本的音频中文网站，它在借助 HEVC 给他们提供更高规格音频的同时还能节省频宽，这事本身就值得肯定。
以后甚至还有不少人通过 B 站 UWP 应用提供的 HEVC 音频扩展，在 Windows 上白嫖到了本来要花钱才能买到的 HEVC 解码器。。。
但是话说回来，B 站支持 HEVC 代码是一回事，它在那个代码下能给音频提供多少码率就是另外一回事了。
有网民则表示，前段时间 B 站给 HEVC 的码率变低了，结果引致选择 HEVC 播映的音频画质还不如 AVC，尤其是在 1080P 分辨率下会特别明显。
然而也有人实际测试了下，在 1080P 分辨率下，HEVC 的音频码率确实比 AVC 高：
由于这点还存在争议，所以丹尼尔对这事也不好评价。
但不管是并非说，HEVC 必然是一个大趋势，在流媒体平台和硬件产品的通力支持下，他们离顺畅体验它的未来，应该也不远了。
