(推测)B站H.265（HEVC）编码的触发条件
上回，我测试了下B站全面开放的4K视频的一些指标。
其中，我提到有一点：所有投稿的4K视频都会被B站服务器二压，并且产生H265（HEVC）编码格式的视频流供移动端和win10 UWP客户端使用。
关于启用H.265格式，我并没有又找到公开的官方说明，只是坊间流传说在做灰度测试。
这里只找到一个比较“官方”的文章，原作者是B站视频云技术专家，负责视频编解码团队，开发自研hevc编码器。
启用H.265视频编码，目前我可以追溯到去年的8月份就开始了，但是没有官方的公开说明（其实这个大不必宣传，毕竟一般用户感知不强），使得最近看“知乎”与新4K相关回答的时候，看到有少部分人在吐槽B站上了4K却不上H.265。
其实之前，我也不知道，毕竟我自己主要是使用网页端比较多，UWP几乎不使用，APP看不了视频的参数信息（这好像有办法看的，有知道的麻烦告知一下）。之前调查B站初期4K视频的时候注意到了，就特别关注了下。除去4K，其他普通的视频也会有H.265，我想看看怎么产生H.265视频流，试过直接上传H.265编码，直接被转成H.264。想到之前看到的H.265视频都来自知名UP主，流量大的视频用H.265省流量合情合理。之前以为H.265视频是随着视频发布一并生成的，系统会因为是知名UP的视频预判它会流量较大转出H.265供现在B站的流量主体移动APP使用。
之后，我也没有深入下去。直到昨天，我发现我自己几周前上传的一个视频居然产生了H.265视频流。
之前还用它，讨论下B站疑似取消1080p60不二压取消的问题。其实初次发现这个源视频2Pass控制过码率却还是被压时，我想到是B站是不是全面启用了H.265统一压制视频了。但把网页的获取视频地址的api回复拉出来看，没有hevc。
这是现在的api回复：
获取：
这个是什么意思，这里不多涉及，它可以算是如何下载B站视频的一个核心点，以后讨论。
之前是怎么样的，我也没截图。我肯定这是后来产生的。
这个视频的特点就是，不知道因为切中什么点，播放量高了些，写作时754播放。
接着我查看了最近上传的非4K视频，没有H.265，排除全面启用。
之后查看我目前播放最高的视频：
此视频最高画质1080p60为不二压直传。1080p60和720p60画质档api获取上一如既往只回复单条视频下载地址（就是上面“video”组中只有对应画质id 1080p60对应116 720p60对应74，具体详见：CV5794140）。两个独立的60帧档位没有H.265，但是非大会员画质都有H.265了，这应该也是后来B站自己转码生成的。
获取：
再看之前有1200播放的视频（同样不二压），却没有产生。
这样看来，触发条件还是有点迷。不过播放量肯定是一个考量因素，但是之前1200播放的视频没有触发呢？
下面仅做个人推测：这个生成H.265的条件可能是最近才上线的，它评定的是近期视频稿件的播放增速。最近稿件的播放量涨速了比较高（可能一天100？）就会被认为可能是点击率高的稿件，追加转码出H.265格式视频。拆电脑的视频是近几周的还在推广期，增量大；播放之最本来是过了推广播放增量每天个位数，但之前转发了下蹭了点热度，导致播放一下又涨了200多。
手上样本不多，就两三个视频其实也说明不了什么，所以仅推测。
现在的B站的在线视频格式可以说是处于过渡阶段，积极启用H.265但又为了照顾浏览器兼容性还不得不要保留H.264。这导致同样的视频同画质要存储双份不同编码的视频。B站仅给潜在高播放视频转码H.265，我想这恰恰在反映一个系统设计的tradeoff取舍问题：转H.265可以节省流量带宽但要付出更高的服务器存储。高流量热门视频使用新编码节省的带宽成本大于存储成本，还能给用户带来更佳的观看体验（网速需求低了），而低播放的视频，由于新编码能带来的带宽成本的节省很少，就无需浪费存储生成H.265。
好了，就BB到这里。之后会就本文提到的api，分享下几个实用api调用方法，并借此通过python编程实现几个小功能。
本人非此方面大佬，只分享探索学习成果。
By ZHY
2020.6.9凌晨
头图pid：57874264
（(推测)B站H.265（HEVC）编码的触发条件）宝，都看到这里了你确定不收藏一下？？
