写在前面

本博客仅提供个人意见参考，不具备指导意义，仅供互相学习交流。

最近做直播时突然迸发出一些idea，想趁热记录下来，因时间仓促，所以本文可能有许多不严谨荒诞之处，加之作者太菜，对ffmpeg等认识较为肤浅，若有问题，欢迎评论批评斧正（￣▽￣）

*为了防止原创创意被恶意盗用标榜，下文中简称该潜在新协议为 "quewn协议" ~~不要在意细节⁄(⁄ ⁄•⁄ω⁄•⁄ ⁄)⁄~~

因为这个配置文件的功能和 HLS 的 m3u8文件很像，下文简称 "类m3u8文件"

请不要盗本文qwq 我就不打水印了萌新第一次写博，请轻喷qwq

核心改变

博主了解到的传统流媒体直播架构中，大多数直接将视频流推送到剪辑机，然后由后期人员实时直接处理视频流。

<img=传统2>

<img=传统直播1>

某种程度上，quewn标准可能在同时直播人数过多的情况下变得极其臃肿，这里以多虚拟主播一起同屏直播为示例情况，讲解这一潜在的新协议——quewn标准。

<img=关键帧新定义1>

图例为三名虚拟主播在合作直播的情景，每个直播源是一个主播，每个主播有2个视频轨(或更多，这里2个参考了一个facerig与一个桌面流) 有2个音频轨(参考1个桌面音频，一个麦克风)。

使用传统方式推流

每位主播的输出内容将一致，若想增加一个自定义输出流，将会显著增大编码机的编码负荷。
一旦编码服务器宕机，没有做其他措施的情况下，这一直播系统将崩溃。
大量带宽资源没有得到很好利用，用于传输不必要的，供备选的流。(内网也要考虑交换机，外网更是如此)
上一个问题同样造成一旦直播源数量增加，对于编码姬与带宽的压力上升的速度很快，很难做到大量人员一起同屏直播。

而这一潜在的新标准很好的规避了这一问题。

对比下的优点

quewn标准中，我们转移了渲染端，从单一主机(剪辑机)渲染，转变为每个直播源本地单独渲染他们的输出。并且紧急情况下，如某台直播源故障时，通过合理改变剪辑机发布的类m3u8文件(或用nginx反代)，转发某个端口的视频流，可以做到高可用。
quewn标准采用轨道作用声明的策略，使得不必再将全部的流推流到剪辑姬上进行处理，各端只需要依据剪辑机发布的类m3u8文件，在可信子网里拉取指定的其他直播源的流即可（剪辑机此处类似于种子网络中的tracker）实现了对于带宽的有效利用，大大增加了单位带宽可连接量的上限。(参考下文的新延时)
如果各位主播的机子很难做到实时渲染的需求，那我们依然可以使用传统的中心化网络，利用一台性能强劲的编码姬去承担全部的编码作业。（参考下文的集中渲染）(因为剪辑机只需要发布类m3u8去指导编码姬，所以后期工作人员的电脑不必特别好，理论上)
在标准的quewn协议下，每台主播的电脑都做为这一可信域的去中心化网络子节点存在，从依据类m3u8文件指出的网络映射，与其他节点建立必要的连接，传输流并本地渲染，使得每台主播机的利用效率被提升。

潜在的缺点

在初期制订这一标准时，我们曾担心过，网络延时可能会导致严重的问题。

<img=新延时>

让我们对比一下传统延时

<img=传统延时>

不难发现，新协议新增了一个存在于直播源与后期支持团队之间的延时，这一延时可能是十分影响观看效果的，我们可以用一个简单例子来看

假设A主播正在吃苹果，后期人员通过监听轨道看到时，迅速为她在苹果上添加了一个马赛克特效；在此埋下一个包袱，预期效果是观众看到主播吃带马赛克的苹果。可是这一操作指令更新到类m3u8文件里，再被直播源读取，执行，渲染生成最终画面时，主播早就放下了苹果！这就导致很尴尬的，屏幕莫名其妙的出现一块意义不明的马赛克，影响观看效果。

而传统方式就很难出现这种问题，因为在直播后期人员与视频流本体之间几乎没有延时。当然，我认为这种协议之所以没有被提出，很可能也是因为这一原因。

但是，我们看到了解决的希望：5G技术

5G技术将网速提升到另一个水平，甚至可以支持VR直播等"魔幻"的事情，使尽可能的减少这里的延迟到可以接受的范围成为可能。

这个协议还有其他衍生版本，不妨看看这个 "传统渲染Ⅱ版"——集中渲染

<img=集中渲染>

集中渲染模式中，仍然时中心化网络结构，由一台性能强大的渲染服务器提供全部的渲染。他与传统模式的而不同是他采用了quewn标准，使用类m3u8文件渲染他们独立的视频流为各个主播推流到指定账号上。

分组化管理

为了简化整体设置，我又加入了分组化管理，这使得控制多个流变得更为简单。如规定{直播源A的编号1视频轨,直播源B的编号1视频轨}为一组，只需要添加G1{A§V1,B§V1}到类m3u8。~~组目前因是*预定义(因为尚未构思好下面这个共识机制，暂不定义)的~~。由此可以设置一个源集合的必要配置，如分辨率,渲染策略,等。当然，对于全局的控制和单独的源的设置也毫无疑问应当支持。quewn标准下的配置间可覆盖，并且满足（单源设定 > 分组设定 > 全局设定）。

新直播源加入，直播源的A/V源改变等时的策略

这个比较繁琐，涉及类m3u8文件的 "类负反馈"(生物乱入)，改天专门写一篇，涉及到密钥对共识，DPOS(可能)，K8S或者swarm的通信机制什么，qwq...

范例

<img=目标帧>

最后附上我构想的范例类m3u8文件，它的作用是生成上面这一张 "关键帧" 。

//指定配置对象
G1
{
# 预申明这一组使用的直播源,[ <源ID> § <Vedio/Audio> <流ID> ; ].
Include{
A§V1 ;
A§V2 ;
B§V1 ;
A§A1 ;
B§A1 ;
}

# 关键帧的导向生成配置部分
Video{
build = [A§V1]{
x_start_at = (0px , 0px)
x_end_at = (32px , 32px)
y_start_at = (0px , 0px)
y_end_at = (32px , 32px)
target_fps = 30
Resolution = 640 * 480
Caching = false
}

build = [A§V2]{
x_start_at = (64px , 64px)
x_end_at = (128px , 128px)
y_start_at = (64px , 64px)
y_end_at = (128px , 128px)
target_fps = 30
Resolution = 1920 * 1080
Caching = 300ms
}

build = [B§V1]{
x_start_at = (0px , 0px)
x_end_at = (1920px , 1080px)
y_start_at = (0px , 0px)
y_end_at = (1920px , 1080px)
target_fps = 30
Resolution = 640 * 480
Caching = false
}

build = [A§A1]{
Sampling_Rate = 128
Caching = false
}

build = [B§A1]{
Sampling_Rate = 128
Caching = false
}

}
}

overall-conf
{

render-engine{
$1[Nvenc]
$2[Sqv]
$3[h264]
}

Vertical_sync = false
enableSSL = false
Anisotropic_filtering = false
FXAA = false
FMAA = false
process_num = 2
authport = 2333
session-life-period = 61440

}

感谢每一位看到这里的朋友，如果有任何的批评或意见，欢迎在下面的评论区指出斧正 ╮(￣▽￣)╭

留个企鹅群供讨论xwx~~ 671810905

D•Quewn

发布了1 篇原创文章 · 获赞 3 · 访问量 265

私信关注

重新定义关键帧 —— 探讨流媒体的新协议方向 (quewn协议)