当开发者评估低延迟视频传输方案时,关于 SRT 与 MOQT 的比较问题经常被提及。本文将为你介绍SRT 与 MOQT 两者的区别。若你希望快速了解要点,请阅读“关键要点”部分。若你希望进行更深入的技术对比,请继续阅读下文。

关键要点
SRT 是一种成熟可靠的视频传输协议,提供严格的端到端延迟控制。然而,其丢包方式与有效载荷无关,在严重拥塞的情况下可能导致播放不稳定;此外,其单流架构仍可能出现队头阻塞现象,限制了其在现代 SVC 工作流程中的应用。
MOQT 将灵活的流媒体格式映射到独立的 QUIC 流,在提供等效延迟控制的同时,还能实现精细的、基于有效载荷的数据处理和丢弃策略。它利用并行流、独立的丢包恢复和基于优先级的传输机制,可以安全地丢弃延迟数据,并原生支持 SVC 自适应。该协议的架构针对弹性、低延迟、高带宽的媒体分发进行了高度优化。
比较基准
在比较安全可靠传输协议 ( SRT ) 和基于 QUIC 的媒体传输协议 ( MOQT ) 时,建立等效的架构层至关重要。从技术角度来看,SRT 是一种与有效载荷无关的传输协议。然而,在标准的广播和流媒体工作流程中,它主要用于承载复用的 MPEG-TS(传输流)有效载荷。
MOQT 是一种端到端媒体传输协议,旨在与各种应用层流媒体格式协同工作(目前的草案定义了MOQT 流媒体格式 (MSF)和CMAF MSF (CMSF))。流媒体格式及其相关的容器结构提供了必要的媒体元数据,包括时间戳。因此,视频传输的功能比较最好概括为SRT + MPEG-TS与MOQT + MSF/CMSF 的对比。
注意:值得一提的是,MOQT 占据了不同的用例空间,重叠主要体现在贡献方面。SRT 通常不考虑大规模分发给最终消费者。
SRT + MPEG-TS 与 MOQT + MSF/CMSF 流媒体对比表:
| 类别 | SRT + MPEG-TS | MOQT + MSF/CMSF |
| 主要职责 | 主要用于编码器、转码器和广播基础设施之间的数据贡献工作流程 | 它被设计成一种端到端的媒体传输协议,既支持贡献式架构,也支持可扩展的分发架构。 |
| 延迟比较 | 根据配置的延迟缓冲区和网络稳定性,延迟时间约为 125 毫秒或更长。 | 根据流媒体格式配置和拥塞情况,延迟时间约为 200 毫秒至 500 毫秒。 |
| 架构 | 单个UDP连接承载多路复用的MPEG-TS流 | 基于QUIC架构,具有多个独立流 |
| 有效载荷感知 | 与有效载荷无关。传输层不了解介质结构或数据包的重要性。 | 可与提供时间戳和元数据的流媒体格式协同工作,从而实现有效载荷感知处理。 |
| 数据包调度 | 主要采用单连接上的先进先出 (FIFO) 调度 | 基于优先级的跨多个流的调度 |
| 拥堵处理 | 如果没有应用层逻辑,就无法区分关键媒体和增强数据。 | 当带宽受限时,中继服务器可以优先处理或丢弃优先级较低的数据流。 |
| 丢包恢复 | 使用 ARQ 重传,但所有数据包共享同一传输管道。 | 使用 QUIC ARQ,每个流均可独立恢复 |
| 队伍首位阻挡 | 有可能。丢失的数据包会延迟后续数据包的传输,直到重新传输或丢弃。 | 避免使用此功能,因为音频、视频和其他组件可以通过单独的 QUIC 流传输。 |
| 处理延迟数据 | 过晚丢包(TLPKTDROP)会丢弃超出延迟缓冲区的包。 | 应用程序评估演示时间戳,并指示传输过程干净利落地丢弃延迟帧。 |
| 数据丢弃方法 | 丢包会导致部分媒体帧丢失,并可能造成解码器失真。 | 使用 STOP_SENDING 和 RESET_STREAM 删除语义媒体单元 |
| SVC 支持 | 由于基础层和增强层共享同一个传输队列,因此效果有限。 | 通过独立流对不同的 SVC 层提供原生支持 |
| ABR适应 | 通常在 SRT 流之外处理或通过切换信号源进行处理。 | 客户端可以切换轨道,继电器可以丢弃优先级较低的层。 |
| 拥堵期间的行为 | 整个数据流受到丢包或重传延迟的影响 | 选择性降级,例如在保留基本播放效果的同时去除增强层。 |
| 转码工作流程 | 处理前需要对整个MPEG-TS流进行完整的摄取和解复用。 | 转码器可以有选择地仅摄取所需的音轨或图层。 |
| 生态系统成熟度 | 非常成熟,对编码器、FFmpeg 工作流程和广播系统均有广泛的支持。 | 新兴生态系统,但专为现代可扩展媒体架构而设计 |
数据包调度和复用
在网络拥塞的情况下,传输协议必须管理数据如何在受限带宽内排队和传输。
- SRT调度: SRT主要通过单个UDP连接,以先进先出(FIFO)顺序处理数据包。由于它本身不检查有效载荷,因此如果没有自定义的应用层复用,它无法区分关键媒体(例如基础视频层或音频)和辅助媒体(例如视频增强层)。
- MOQT调度: MOQT采用优先级模型,为每个数据流设置不同的优先级参数。这使得发送方和中间中继能够识别不同媒体组件的相对重要性。在带宽受限的情况下,MOQT中继可以利用此逻辑选择性地延迟或丢弃低优先级数据流,以确保高优先级数据流的及时传输。
丢包恢复和队头阻塞
SRT 和 MOQT(通过 QUIC)都使用自动重传请求 (ARQ) 来恢复丢失的数据包。当数据包被网络丢弃时,接收方会请求发送方重新发送该数据包。两者操作上的区别在于,这种恢复操作对正在传输的其他数据的影响方式不同。
- SRT(队头阻塞): SRT 通过单个连接按顺序传输有效载荷。如果数据包丢失,接收方必须将所有后续数据包保留在缓冲区中,直到丢失的数据包重传并成功到达。但是,如果重传延迟超过设定的延迟缓冲区,SRT 将完全丢弃该数据包,从而使流继续传输,而不是无限期地等待。这就产生了队头 (HoL) 阻塞。由于所有媒体(音频、视频基础层、视频增强层)共享此单个管道,因此单个网络数据包的丢失会导致整个传输流的传输停滞,从而全面增加延迟。同样,这种停滞只会持续到延迟缓冲区内,而不是永久停滞。
- MOQT(独立流恢复): MOQT 依赖于 QUIC 的多路复用流架构。由于不同的媒体组件(例如音频和视频)被映射到独立的 QUIC 流,因此丢包会被隔离。如果包含视频数据的数据包丢失,则只有该视频流会等待重传。音频流运行在并行的 QUIC 流上,可以继续不间断地向应用程序传输数据。这可以防止单个网络丢包导致整个媒体播放中断。
拥塞情况下的延迟数据处理
当网络延迟导致数据到达时间超过预期播放截止时间时,这两种协议使用不同的机制来丢弃该数据。
- SRT(网络级丢包): SRT 使用配置的延迟缓冲区。如果数据包无法在此时间范围内送达,SRT 的过晚丢包 (TLPKTDROP) 机制会将其丢弃。由于 SRT 在网络数据包级别丢包,且不感知有效载荷,这可能导致部分媒体帧的交付。在 MPEG-TS 工作流程中,这种碎片化可能导致解码器错误或视觉瑕疵,并且可能持续到下一个关键帧。
- MOQT(应用感知丢弃): MOQT 依赖于应用层流格式和 QUIC 传输层之间的反馈回路。应用层评估呈现时间戳 (PTS);如果帧超过其播放截止时间,则指示传输层发出 QUIC STOP_SENDING 帧。然后,MOQT 通过 RESET_STREAM 操作丢弃完整的语义媒体单元。这可以保持剩余视频流的结构完整性,并避免损坏解码器。
支持视频自适应(ABR 和 SVC)
现代视频传输依靠自适应比特率 (ABR) 和可扩展视频编码 (SVC) 来适应不断变化的网络状况。
- SRT 和 SVC:由于 SRT 通常承载单个复用的 MPEG-TS 流,所有 SVC 层(基本分辨率层和增强细节层)共享同一个传输队列。如果网络在成功传输增强层数据包的同时丢弃了一个基本层数据包,则增强数据将无法解码,从而限制了 SVC 在标准 SRT 链路上的实际应用效果。
- MOQT 和 SVC/ABR 集成: MOQT 将 SVC 层映射到独立的 QUIC 流(子组),从而促进两种类型的适应:
- 层丢弃(SVC):在网络短暂中断期间,MOQT 中继器会自动丢弃低优先级增强子组。播放器会暂时降低音质,但仍能保持不间断播放。
- 音轨切换(ABR):当网络容量持续变化时,客户端可以发出 SUBSCRIBE 命令来订阅较低比特率的 MOQT 音轨。MOQT 会在定义的组边界(关键帧)处处理这些切换,从而实现不同质量层级之间的平滑过渡。
与转码工作流程集成
将这些协议集成到转码流程中需要在当前生态系统支持和架构效率之间做出权衡。
- SRT生态系统成熟度: SRT与MPEG-TS相结合,已成为一个成熟且被广泛采用的标准。它对传统硬件编码器、软件转码器(例如FFmpeg)以及现有的云广播基础设施均有广泛的支持。
- MOQT 处理效率: SRT 的单体有效载荷要求转码器在处理前摄取、解复用并解码整个传输流。相比之下,MOQT 的架构将媒体分离成独立的轨道和子组。这使得现代转码器能够选择性地摄取所需的流(例如,处理 1080p 基础层,同时主动忽略更高分辨率的流),随着软件生态系统的成熟,这将提供更高效的计算流程。
结论
总而言之,SRT 与 MOQT 的对比突显了两种协议之间的差异:一种是基于单一传输流构建的成熟传输协议,另一种是专为多路复用、媒体感知型传输而设计的新型架构。SRT 仍然被广泛使用且可靠,而 MOQT 则引入了传输层功能,使其更符合现代可扩展视频工作流程和自适应流媒体模型。
本文来自作者投稿,版权归原作者所有。如需转载,请注明出处:https://www.nxrte.com/jishu/yinshipin/66596.html