B站标称的原画60FPS看起来远没twitch那么平滑
感觉现在主播的硬件水平应该支持144Hz以上的刷新率了，但是看B站就像不到60帧的样子
论带宽占用B站和twitch的都差不多，都是1.5-2M/s左右
Twitch最平滑，但是也有些是直播卡卡的，但是很多都很平顺
B站的直播没有一个平滑的，都像没到60帧的样子
Youtube的直播比B站稍微好点，但也不够顺
码率被压缩了
1 Like
感觉码率压缩应该只是影响清晰度，如果不是压的太过头不太会影响到平滑度，如果是144帧压到60帧，也不至于卡的像40帧啊。。。
不负责任猜测一下，会不会是同帧重复利用？比如源30帧，每帧重复用2次，到用户这就是60帧了，肉眼看去相当于30帧。
主播硬件设备就算很好，上传速率不一定达标，因带宽限制推流时说不定有很多丢帧。到达B站服务器这里，为了使观看端达到60帧，可能使用了补帧的措施，所有丢失帧使用最近的正常帧补上。
看了下B站直播用的直播姬，说不定这软件有问题，或者纯粹是主播没设置好。
也有可能没有补帧，纯粹是丢帧了，虽然显示的60帧，但其中有丢帧，丢掉的帧没有内容直接显示最近的正常帧，直到下一个正常帧到来。
1 Like
补帧可以实现但是应该不太可能，因为要保持用户设备都有所需的算力很难。而且补帧的看起来不如原生的平滑。
用大会员看B站上的所谓4k视频（1080 60FPS的上位版），真能实现流畅的都是些搬运Youtube的4k风景视频，国内自制的到目前还没见过一个真正流畅60帧的，一个都没有。
当然也可能那些效果最好的视频上传时是超60帧的
单纯因为B站带宽问题压缩码率太厉害了，720P高码率也比1080低码率看着更加流畅舒服。
你在B站直播，测试一下原画、蓝光、超清、高清几个画面选项，你会发现除了分辨率降低，视频的流畅度也会降低。
1 Like
我的意思是B站在服务器上处理完才传出来，所以在用户端数据上看上去是60帧，观感上却没有那么高。用户这里一个web浏览器只负责解码播放而已。
国内商用带宽那么贵，不限制码率成本控制不住呀。就算码率那么低了，各大视频站还要用PCDN偷用户的上传带宽来降低网络成本，网络这块的支出可想而知了。
并不是，那些从油管搬运的视频有的能保持高帧率，比如你对比一下4k挪威和4k中国，前者是搬运来的，B站这些4K视频的码率一点也不低，并不怎么省带宽
【【4k】挪威 - 绝美风景休闲放松影片】
https://www.bilibili.com/video/BV1nt4y17729
【4K超清 60fps HDR 中国 大好河山 最美中华 赶紧看看有没有自己的家乡】
https://www.bilibili.com/video/BV1qH4y1r7bY
也可能是B站的视频压缩技术太烂了？或者是国内的摄影技术或者设备不行？
很惭愧，B站我一直是不登录使用，清晰度也是用脚本偷的最高1080/30。
不过你这两个视频很明显，即使在30帧的情况下，中国这个影片明显不流畅。
就单这两个视频来说，不流畅基本可以确定是原片源导致的。
用这个脚本一帧一帧看这两个视频，即使在30帧的情况下，中国的视频在卡顿处有很多的相邻两帧甚至三帧是一模一样的，而挪威的视频很少有这个情况。
顺便说一句对于YouTube，这个脚本在Chrome上失效了，Firefox上还正常。
1 Like
你这个图上不是很清楚吗。。。
t台1080p的码率都破万了，b站非直播的视频1080p你都估计找不到这个码率的
1 Like
b站用h264，twitch用vp9，编码效率差一大截，同码率下必输。不过你的电脑可能也有问题，asaki的直播最高画质用的应该是h265
1 Like
直播好像没有选项，不过B站的视频播放都是用h265
先说结论，降本增笑弄的。
破站直播这个给你的码流大概二压过的，也就是服务器那边给转码过的，然后破站日常降本增笑，dddd，而且，他们的转码服务器不靠谱的，现在日常都在说卡就切原画（都有五六年历史了），然后像你举的这个热门主播，他的原画是“原画画质”不是“原始画质”（应该有三年历史了）（我更愿意称之为假原画），因为这种主播要是给真原画的话，宽带花销就起飞了，同时采用了大量的pcdn（三四年历史），还有自建的cdn（两年，但从录播反馈来看似乎比pcdn更差），这下就更加爆炸了。。。
然后我看到有人提h265，额，这个问题就更好玩了。
rtmp（flv）原生是不支持hevc的，国内 很早（可能有八年以上了(引用1)） 就做了一套rtmp推h265的协议（很简单粗暴，就是在rtmp协议号后面顺着编排），然而国际上并未能接受这套扩展，理由是rtmp官方(adobe)没承认(这玩意作为flash的副产物，自然是归他的)，就一直无法全面推开普及，OBS要用也只能装插件（当年我找过也用过，现在这个插件想找到都是难度满分），但这套协议在国内的各个云服务商是有一定的部署和落地的，这是个伏笔。
现在(好像就这两年的事，(引用2))国际上那边终于受不了，搞了套Enhanced RTMP v1（已经在搞v2了），但这套实现和国内那套实现是另一种玩法（扩展了消息并加入四字编码标识，一口气把hvc1 vp9 av1全支持了），但国内这些云服务商因为已经搞了自己的一套，外加降本增笑，就更加没动力去做这个支持了。。。
这样一弄下来，就变成从主播侧无法推流hevc，只能靠破站的破烂服务器去二压，然后破站也不愿意给足够的算力去编码，只能给一个凑合的，刚好合格的画质了。。。
当然，现在你走srt推hevc上去也可以，但是播放侧api对于这路流的标识是h264(阴间)，也不会触发相关的兼容逻辑，如wasm解码。
（口述历史，事情存在，但时间节点不保证正确，仅作参考）
总结下目前 B 站的状态：
- 主播侧仅支持h264，h265/hevc依靠服务器转码
- 转码服务器破烂，特别是高峰期
- “原画画质”
- 优先提供自建CDN及PCDN，大型云服务商的优质CDN能少用就少用
来自2025年的补充和修改：
当年的人还是挺像做事的人，至少还是有些文档的。
引用：
- Document/Reference/video_file_format_spec_v10_1_ksyun_20170615.doc at master · CDN-Union/Document · GitHub
- GitHub - veovera/enhanced-rtmp: This industry-sanctioned project introduces significant enhancements to the RTMP and FLV specifications, outlining advanced features aimed at revitalizing and modernizing the RTMP solution.
1 Like
多谢大佬讲解，真是个精彩又悲伤的故事 