【杂谈日记】如何让投稿更清晰一些——一些胡思乱想(上)

本文包括以下内容：

1、视频投稿相关设置（针对不同类型内容），如何拯救画质（B限）

2、消费级计算机硬件常见误区集锦，以及相关建议

主要是在B站闲逛看视频的时候得到的感想，已经积攒到不得不吐槽一遍的程度，想了想，动态难检索（甚至可以说迄今为止，B站动态搜索功能的可用性无限接近于零），还是发个专栏吧。

补充：本篇只有第一部分。

首先是视频投稿的相关设置问题：

一、画面比例：

画面比例这个问题好像没多少人探讨过，但是 LTT 专门出过一期视频讲他们使用的视频比例。

LTT 的视频是 3840×1920 的，也即是 18:9 的画面比例（描述画面比例时，基于16:9相关延伸的描述，长短边一般不进行约分）。

18:9 是一个看上去比较奇怪的比例，但这个比例其实是综合为传统宽屏和手机常用的全面屏设计综合考虑的一个结果。

要明白这个原因，就要先了解一下不同观看设备的分辨率比例：

传统宽屏显示器——使用 16:9 的分辨率比例：

最传统的分辨率比例，中规中矩

※HD = 720p = 1280×720 分辨率，老旧宽屏显示器的分辨率
※                      1366×768 分辨率，老旧小尺寸笔记本屏幕分辨率
※FHD = 1080p = 1k = 1920×1080 分辨率，目前最常见的电脑屏幕分辨率
※QHD = 1440p = 2k = 2560×1440 分辨率，即将成为主流的电脑屏幕分辨率
※UHD = 2160p = 4k = 3840×2160 分辨率，目前主流消费级的高端屏幕分辨率

宽屏加高显示器——使用 16:10 的分辨率比例：

相比传统宽屏有加高，对于浏览网页或者文档编辑有一定优势（因为相应软件的内容是纵向的，可视比例由宽度决定），而对于笔记本而言，可以有效减少屏幕边框的宽度。

※1680×1050 = 低端办公显示器常见分辨率
※1920×1200 = 入门级轻薄本常见分辨率
※2560×1600 = 中端笔记本常用 2k 屏（为了减少屏幕“下巴”）

特殊屏幕比例：3120×2080 等，常见于笔记本定制屏幕

除此之外，平板电脑也会倾向于使用 3:2 甚至更方的屏幕，这是使用性质决定的（握持状态下很多时候会纵向使用）

桌面带鱼屏：

这一分辨率与电影宽荧幕常用的分辨率一致，但动画电影一般不会采用这个比例制作。

※3440×1440 = 21.5:9

还有一种两倍屏宽的带鱼屏，分辨率等同于 2 块 2k屏幕横向叠加：

※5120×1440 = 32:9

目前好像我印象中三星有做，这种屏幕一般来说核显就无法解决了，因为大多数核显的支持分辨率上限是4096x4096。

手机全面屏——一般使用最低 19:9 上至 21:9 的加宽宽屏

这类屏幕一般以短边定边，衍生出 1k 屏和 2k 屏两种常见选择，4k 屏因为无法突破长边限制，大多数时候并无实际意义，所以很少有厂商会选择。

常见比例可能是：
2400×1080 = 20:9 = 1k （RedMi K30 5G）
2480×1116 = 20:9 = 1k+ （红魔8pro）
3840×1644 = 21:9 = 4k- （只有索尼做4k手机）
3164×1440 = 19.8:9 = 2k （OPPO Find X6）

4k 长边的理论上限（指硬件解码器）虽然大多数时候并不是 3840，而是 4096，但绝大多数情况下都是以长边上限为 3840 进行“切割”。

因此，1080p 的 FHD 全面屏，可以 1:1 像素播放 1080p FHD 的视频内容，2k 的 QHD 全面屏，也可以 1:1 播放 2k QHD 的视频内容，但是 4k 全面屏，是无法 1:1 播放 4k UHD 内容的，要么缩小，要么裁切，这也是手机 4k 是鸡肋的核心原因之一。

全面屏手机选择加宽，而非加高，核心原因是，在增加屏幕面积的前提下，不增加握持难度，只能从纵向入手，更长的手机可以显示更多的信息流。

手机制造厂商不选择 4K 是因为长边一般不会考虑超过 3840 的分辨率，因此实际上手机上的 4K，和电脑上的 4K 相比，是有明显的像素缺失的。所以手机实际上能被正常采用的分辨率是2k+

另外一个 4k 无意义的核心原因在于，本质上用户对清晰度的感知对比实际上是对比 ppi × 观看距离 的一个乘积，这个乘积和同样视角宽度下的有效像素宽度是等效的。（ppi：pixel per inch，每英寸像素点密度）

举个例子，我用一个150ppi 的屏幕在 50 厘米外使用（自用 27寸 16:9 4k屏），和用一个 500ppi 的屏幕在 15 厘米外使用的观感是基本一致的（当然，受到具体屏幕次像素排列方式影响，不会完全一致），而后者的一个典型例子就是 6.82英寸的 3164×1440 的 2k 屏幕，已经有 510ppi 的像素密度了。

然后——上述内容对于苹果系产品不完全适用，苹果系显示采用另一套逻辑，具体请寻找相关内容进行了解。

那么，屏幕分辨率对我们视频选择分辨率有什么影响呢？

对比PC常见的屏幕和手机屏幕，你会发现第一个大问题，就是不管你选择怎样的分辨率，都不可能做到兼顾双方画面的完全填充。

那么现在的核心问题就是，电脑端用户和移动端用户如何取舍。

LTT做的决定是，优先考虑移动端用户的体验，所以他们选择了18:9的分辨率。

虽然手机屏幕的分辨率普遍是 19:9 以上，但我们实际制作视频内容的时候是不能做这么宽的，核心原因就在于，目前绝大多数手机屏幕都不是“直屏”，而是“圆角屏”，屏幕的上下两端，设计是用于展示任务栏和按键的，所以并不是完整的，四角存在圆弧缺失，所以视频内容要规避这个区域，那么 18:9 就会是一个比较合理的分辨率了。

18:9 下，伪 4k 的选择就是 3840×1920的分辨率了，1080p 的选择就是 2160×1080 或 1920×960，前者对移动端显示有优势，后者对桌面端显示有优势，而 2k 对应是 2880×1440 —— 哦，这个选择在 B 站没有意义，B 站好高骛远地并没有设置 1440p 这一个档位的分辨率，我个人认为这也是导致 B 站流量负担入不敷出的重要原因之一。

18:9 的画面尺寸在传统宽屏显示器中播放时，上下会有少量黑边，但是通过简单计算可得，5.56%的黑边对观感的影响并不算太大，如果采用 CC 字幕的形式，这个空间正好可以用于填充字幕，而且其实在网页端不全屏的话影响就更小了。

更传统更省事的方式当然是做成 16:9，16:9 在相对传统的显示器上表现效果会更好，同时，还有另一个优势，就是移动端，非全屏观看时（竖屏/小窗/分屏），有效信息量会更多一些。

但是这些都是针对非纯游戏画面的，包含复杂情形画面的视频而言的，对于游戏视频，则又有另外的考虑因素。

比如明日方舟，其地图框架是基于 16:9 摄像机画面进行拓展的，GUI 也是根据 16:9 框架进行拓展设计的。

这意味着什么呢？

对更高的画面比例，GUI 场景下，上下非边缘贴靠的部分会出现明显的空白留白；对作战场景，则会展示站场地图上下的额外空间，动作操作按键和待部署区的 GUI 也会往上下进行分别退让。因此，平板打图，战场被遮挡的情形会更少，显示会更清晰。

对更宽的画面比例，GUI 场景下，单侧对齐的有限元素会在另一侧出现留白，单侧对齐的无限制元素则会显示更多的内容（比如基建选人，黄绿橙票商店等），这对于玩家日常游戏会更有利；但对于作战场景，因为部署状态下的摄像机倾斜展示，地图顶部的部分干员会出现难以操作的情况，不过也不是纯弊端，因为更宽的空间，让待部署区的 GUI 能容下更多元素而不失效。因此，手机操作日常，关闭全面屏优化的情况下，操作会更便利。

综合来看，对于这一类纯游戏画面的视频，很显然最理想的比例是16:9，原因很简单，更高的画面比例虽然对画面遮挡更少，但是在PC端和移动端都会出现两侧的黑边，对于观看者的观感而言是明显不利的。而更宽的画面比例虽然有前述的，移动端全屏观感更好的考虑在内，但是GUI本身就会对游戏画面造成遮挡。

当然，更理想的方式有没有？

有，加高分辨率录制，然后再切去GUI部分，后期通过手工添加 GUI 覆层，在追求精致的游戏记录视频中，这样的做法确实可以获得一个比较好的观感，但后期剪辑的工作量实在略大。

顺带一提，明日方舟的游戏作战记录视频，理论上最理想的制作方式是，录制时仅录制音效，背景音乐与干员语音均不开启，然后在后期制作的时候再手动添加背景音乐和干员语音。这样子做的优点是对视频变速和时间轴小范围裁切的操作并不会明显影响音轨的连贯性，但缺点就是操作量极大，这也是为什么明日方舟一份高质量的作战记录视频后期需要很长的时间。

综合来说，关于横屏视频分辨率的选择，有以下建议：

1、如果希望照顾移动端全屏，18:9 的分辨率是最理想的选择，这一比例下的建议分辨率有两个：3840×1920、2160×1080 / 1920×960，且仅有这两组。

2、如果游戏画面本身的拓展逻辑是基于 16:9 为核心拓展，那么视频的比例就应该是 16:9，而不是其他的比例，同样的，有且仅有两个可用分辨率：3840×2160、1920×1080。

3、如果你不想思考，就所有视频基于 16:9 的两个分辨率进行制作。

上述两个分辨率会被正常识别为 4k 视频和 1080p 视频，B 站不存在中间分辨率的视频。

如果你的视频长边和短边过短，则有可能会被 B 站识别为 720p，并被强制二压为 720p，使用比较特殊的比例录制相关视频的需要注意一下。

此外，如果视频的长边和短边任意一边分别短于 2562 和 1442，则会被强制识别为 1080p，同理，使用特殊比例录制的也需要注意。

举个例子，iPad Pro 11寸版本的分辨率是 2388×1668 的 4:3 分辨率，如果以该分辨率录制的话（实际苹果渲染分辨率和显示分辨率不是一个东西，录制和截图功能应该使用的是渲染分辨率，这里仅仅是假设），就会被 B 站强制二压为 1920×1342 的分辨率，应用 1080p 的码率档次，相比 4k，画面质量会有比较大的损失。想要解决这一问题其实也不麻烦，随便找个视频编辑软件，将画布拉伸到 2670×1668(16:10) 或者 2966×1668(16:9)，让长边和短边都超过“4k线”，将画面放中间，然后复制一条时间轴放大填充虚化作为背景，再导出并发布就可以绕开这个强制分辨率限制。

二、码率限制与强制压制

以前，B 站有一个词叫“二压”，指的是 B 站会对用户上传的视频进行二次压制，相应的，也有一个名词叫“免二压”，意为规避 B 站的二次压制。

这涉及到 B 站的发展历史。

最早，B 站是一个“寄生”于其他平台的同好者视频交流网站，用户需要将视频上传到其他平台，然后在投稿后台将视频链接添加到投稿之中，B 站才能显示相关的视频内容并实现弹幕与评论功能。但这样的操作在 B 站开始盈利之后显然不可能继续下去，于是 B 站开始自己开放的本地视频素材库，接受用户的上传。

在 B 站开放用户上传之前，用户想要投稿，则需要“战渣浪”，意为通过各种手段，绕过微博视频的码率限制，避免微博二次压制自己的视频，从而在有限的码率内，通过各种操作为观看者提供更良好的观看体验，因为微博视频的码率限制很低，所以这基本是当初投稿者的必修课。

到了 B 站时代，B 站同样会对视频的码率进行限制，这个限制核心在于下发给观看者的视频流存在一个码率限制，因为在国内，商业宽带的上行带宽价格是非常高昂的，同时，宽带也属于 2B 补贴 2C 模式，也即是商用定价补贴民用定价，这就导致不可能无限制地开放上行带宽。

但在这个时候，B 站依旧仅对超出限制的视频进行处理，不超出码率限制的视频则不处理。这时候就可以通过在本地将码率控制在限制范围内，避免 B 站的二次处理，这就是所谓的“免二压”，因为平台的二压实在是……不敢恭维。

然后现在是全面二压时代，也即是“免二压”时代的经验全部不适用了。

所谓全面二压，是指所有被上传的视频都会经过压制处理，将一些低复杂度的视频降低码率，实现和高复杂度视频相近的清晰度，节省视频带宽的一种做法。

也就是说，不管用户上传的是什么内容，都会被压缩一遍，那么用户也就不用考虑二压啥的，直接上传源内容就行了……吗？

如果你抱有这种天真的想法，那么你的视频就有可能真的成为一坨不可名状的马赛克了。

根据 B 站自己发布于微信公众号“哔哩哔哩技术”上的文章《画质可控的场景自适应转码系统》

https://mp.weixin.qq.com/s/WtL1SUespFw4bcL3-JlhSQ

我们可以知道，B 站对视频采用的编码逻辑是：

1、根据目标码率猜 crf 参数

2、根据视频动态程度，为每一个段设置不同的码率上限，加权后的平均码率符合目标码率的要求

3、根据 操作2 的结果迭代并调整每一个段具体的 crf 参数

4、对【用户感兴趣】的区域进行额外保护

这里我们不需要知道专业术语是什么意思，我们只要知道它们大概代表什么意思就行。

crf 是视频压制的一个指标，你可以理解为同等有效信息量的压缩率，这个参数越大，同等信息量能被分配到的视频体积就越小。crf 参数越高，压制出来的视频，被抛弃掉的次要信息就越多。

原始视频码率高，不代表信息量大，因为所有的视频本质上都是经过压缩的。

举个简单点的例子，一个 8bit 的颜色深度的视频，一个像素点需要占用 24bit 的原始信息，那么一个 1080p 视频的一帧，原始信息就有 49,766,400bit 的大小，也就是 Windows系统下标记的 6075KB，或者 5.93MB，一段长度为 1 分钟，每秒 30 帧的视频，占用的空间约为 10.43GB，码率高达 1423.83Mbps，是B站对该档次视频允许码率上限的 500 倍。很显然这个占用很离谱。

但事实上，用户本地存储的视频并不会占用那么大的空间，这其中有很多因素，首先是颜色方面，视频编码中，并不会为每个像素单独保留颜色，而是每 2×2 像素为一组，每组中有部分像素的不那么敏感的颜色信息会被舍弃掉，单这一操作，根据选择 422 或者 420 颜色编码形式的不同，可以节省三分之一到一半的空间。另外一个常见操作则涉及高数了，利用 FFT 对图像的频域进行操作，可以直接舍弃掉一部分不重要的图像信息，具体可以看 3Blue1Brown 的相关介绍视频（也可能是真理元素的，不记得是谁的了，反正 B 站里就有），这里又压了一大坨，然后就是，视频是连续的画面，但是每一帧相比前一帧并不一定是完全的修改，所以这里就会有一个关键帧的概念，非关键帧就主要记录变化的部分，这样的话，视频的体积又可以被大幅度地压缩。

我举这么多例子，其实想说的是，视频的有效信息量，也就是决定观看体验的“动态”的部分，是被不超过视频实际码率的一个值所定义的，这个值可以比视频的码率小得多得多，但不会大于视频的码率。

这也是有损压缩的关键定义——你无法恢复出比压缩后的文件更多的有效信息量，信息量的差值被舍弃了。

而之所以要介绍这个，是因为，B 站的压缩逻辑会导致视频压制的一个很大的问题。

低分辨率的码率上限是很低的，不一定能容纳的下能合理表达视频内容的信息量，而低分辨率视频，通过合理的手段提升分辨率，是基本不会损失视频内容的有效信息的。

所以在这里我们就需要做一个博弈——如果B站该档次视频的码率不足以支持所需求的视频内容，那么上传者就有必要通过提升视频分辨率的手段，来避免视频内容的丢失。

或者，自己通过更加优秀的方式，主动重编码，降低视频中的有效信息含量，避免二压过程中被这个并不够智能的“智能系统”给误判，丢失掉视频的关键信息。

尤其是游戏类的Up必须要注意这一点，这是智能二压系统的重灾区。

我来分别解释一下上述两种操作的原理：

1、提高视频被划分的码率档次。

因为信息是无法凭空产生的，你无论是提升分辨率也好，还是增加帧率也罢，增加的码率本质上都是填充“主要信息”画面的“次要信息”，也就是在 crf 压制过程中，基本属于被优先舍去的部分。

举个简单的例子，1080p60fps，目前我观测到的码率上限大约为 5500kbps 左右（保守点 5000kbps 肯定有），而 720p60fps 和 1080p30fps 均只有这个码率限制的一半。

假如我有一个 720p60fps 的原始游戏视频，crf23 的出来的码率大概是 4000kbps，那么上传之后，就超出了该档位视频画质的限制，而这个智能二压系统对于游戏画面的识别就是一坨不可名状之物，它为了将码率限制到 2500kbps 左右，结果会造成动态画面出现巨量的马赛克。

那想要解决这个问题有什么办法呢？

我们将视频重新编码为 1080p60fps，我这边假设你的编码质量非常糟糕吧，损失了大概 10% 的画面细节，那么有效信息量还剩大约还相当于 3600kbps 左右，这个时候再上传，被这个二压系统压制之后，这个核心的大约相当 3600kbps 的画质信息被抛弃的优先级是低于后面提升分辨率补上去的那些“细节”的，假设再损失 10%，剩下的相当 3240kbps 的信息量也比原本按 720p60fps 的 2500kbps 的上限要高不少。

对于明日方舟录制完直接投稿的游戏内容，倒不用考虑太多，只要录制的时候是 1080p60fps 就基本不会有内容丢失了，因为本身的“核心信息量”不大，只要是 1080p60fps，crf23 跑出来的结果就基本会落在 3000~4000kbps 的区间，尚未达到该档位视频的码率限制，智能系统预分析的结果基本不会进入第二步分段重设 crf 参数，最终结果也就是普通的硬件二压水平（弱于软件压制，但不至于太烂，除非 B 站用的老 A 卡，但不可能）。

对于手机录制的需要注意调整录屏设置，有的手机为了节约空间，录屏默认性能给得很少，需要手动将码率调到 6000 以上，分辨率调到 1080p，帧率调到 60，才能正常录出能用的结果，部分机型还需要打开扬声器或插入耳机调大手机音量才能正常收录音量。

对于电脑模拟器录制的，需要注意的是显卡直录的是【模拟器实际窗口画面大小】，而不是你设置的模拟器分辨率，如果不确定你的模拟器窗口大小是多少，那么先录个1秒看看分辨率是多少，再手动调整一下。还有另一个办法就是，绝大多数模拟器支持窗口状态保存，这个窗口状态是记录在一个配置文件里的，如果你有一定的电脑常识，也可以直接去改这个配置文件，然后重启模拟器，也可以得到一个合适的窗口大小。

使用 OBS 之类的录制软件则最好尽量对齐实际窗口分辨率和录制画布的分辨率，这时候也要注意模拟器实际窗口大小避免出现像素拉伸，可以通过打开【游戏源】的属性，重置后，会实时显示窗口的大小。

但是这里存在一个恶心人的悖论，就是窗口化的模拟器不存在无边框设置，也就是边框至少占用2~4个像素，但是全屏之后的模拟器在录制上又有很多不方便的地方，因此，1080p的显示器录不了完整的 1080p 模拟器画面，最多只能录出来 1916×1078（编码要求分辨率必须是偶数），同理 4k 的显示器也录不到 3840×2160，甚至录不到 3840×1920，你得用 5k 显示器，也就是 5120×2880 的分辨率，但价格嘛……

对于这种情况，如果用 OBS 录制的话，在两侧适当留丁点灰边填充成标准分辨率，也是可以考虑的一种做法。如果是用 N 卡的回放直录，那么也可以考虑直接全屏之后录制，但设置画面的分辨率比例一定要与屏幕的比例匹配，否则录制可能会出现异常。

截图不受影响，截图截的是渲染分辨率，也就是模拟器里设置的那个，不是输出分辨率。

只要录制参数是对的，直接投稿就行，基本没影响，用 OBS 录制的需要注意，输出分辨率才是实际分辨率，画布分辨率不是，二者对齐即可。

2、手动降低视频的有效信息量

这个操作是针对一些本身复杂度就比较高的游戏视频的，比如特效特别多的游戏视频。

这类视频在 1080p60fps 下，采用高画质录制，得到的有效信息量远超视频支持的码率上限 5500kbps 左右，可能会去到 10000+ 甚至 2w+，这个时候怎么办呢？

手动压制，先将码率限制在 5000kbps 以内，手动软件压制（CPU压制）的时候，被抛弃的细节是可控的，基本可以确认是相对最不重要的细节，不会将更有用的部分给扔了。

等到再从 B 站的“自适应转码”系统走一趟的时候，它就不可能扔掉本来就不存在的东西，整体码率合格，复杂度合格，它就不会做太多余的事情，虽然肯定还会有损失，但是损失肯定会小得多。

这就相当于，你手动将 20000 的码率压制到 5000，因为优先抛弃的较低优先级的细节，整体的画面质量可能还能保持 90% 之多，即便再被自适应系统弄丢 5% 的画质细节，你的整体观感还能有原始视频的 85% 左右。

但如果你将 crf23 下仍有 20000 码率的视频直接丢给自适应压制系统，那么它胡乱分析一通之后，你的画质可能就只剩 70% 甚至 60% 或更低了。

这个方法对于存在频繁画面动态变换的游戏视频非常有效，在游戏中希望降低负载，又没有采集卡，没有 Intel 核显，只能退而求其次使用 NVENC 录制高画质回放的用户来说，是非常有用的一个操作，因为 NVENC 本身的编码有效率就低，碰上这个自适应系统，很容易被压成一坨浆糊。

对于一般用户而言，就是下个小丸工具箱，试参数压成最终码率 5000 以内，或者直接 2pass 5000 码率走起，基本都能有一个差不多可以接受的结果。如果还是无法接受，那就结合方法一，先将分辨率上到 4k，然后按 4k 的阈值压一遍，再投稿。

如果有更高的画质追求，那么就可能需要研究一下更深一步的 FFmpeg 命令行参数了，至少我暂时是用不上的。