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

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

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

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

https://img-blog.csdnimg.cn/20200221225905185.png?x-oss-process=image/watermark,type_ZmFuZ3poZW5naGVpdGk,shadow_10,text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3F1ZXdubGVl,size_16,color_FFFFFF,t_70

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

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

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

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

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

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

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

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

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

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