← 返回 PaperDaily 视觉与图像

代尔夫特理工新作：MoMQ让实时视频多路径传输延迟直降70.3%

多路径传输一直在“盲人摸象”——调度器只看字节，不懂视频帧的关键程度。代尔夫特理工这篇MoMQ，首次把MoQT的元数据变成路径调度规则，在Starlink+WiFi真实测试床上把P99.9延迟从384.7ms砍到114.1ms，实时视频终于能跑进150ms交互预算。想法巧妙，实验扎实，值得一读。

龙哥读论文 阅读 9 查看原文
#视频编码 #模型架构 #人工智能
代尔夫特理工新作：MoMQ让实时视频多路径传输延迟直降70.3%
原论文信息如下：
论文标题:
Media-over-Multipath-QUIC for Realtime Video Applications
发表日期:
2026年8月
发表单位:
代尔夫特理工大学（Delft University of Technology）
原文链接:
https://arxiv.org/pdf/2608.10741v1.pdf

引言

想象一个实时视频通话的场景：画面必须从摄像头捕捉到对方屏幕，全程跑进150毫秒。这个预算里，任何一次网络抖动、一次丢包、一次排队，都会让一帧画面迟到。迟到意味着什么？播放卡顿、画面冻结、用户骂人。
而今天大多数人的设备，其实同时握着好几张网：WiFi、蜂窝网络，甚至还有低轨卫星。Starlink这样的卫星网络和地面WiFi的故障模式几乎互不相关——一条断了，另一条还活着。听起来多路径传输是天然的解法？把多个网络捆绑成一个连接，让数据哪条快走哪条。可惜，真实情况远没有那么美好。
问题出在调度器上。MPTCP、MPQUIC这些多路径协议里的调度器，只能看到“字节”——它不知道一个包是I帧（完整画面，丢了整秒视频就废了）还是P帧（只包含差异，丢了只损失一帧画面）。一个I帧的大小约是P帧的23倍，却要穿越多个拥塞窗口周期才能发完，期间所有依赖它的P帧全在排队。与此同时，Starlink卫星每15秒就会发生一次网络重配置，恰好撞上I帧传输的概率不低，一撞就是几百毫秒的延迟。
那么问题来了：能否让调度器“看懂”视频？
代尔夫特理工大学这篇论文给出的答案，叫MoMQ。它的切入点很妙：视频行业正在标准化一种叫MoQT（Media over QUIC Transport）的协议，Cloudflare已经在自己全球CDN的每一台服务器上部署了MoQT中继。MoQT天然把视频封装成带元数据的命名对象，每个对象都标着“我是I帧”“我依赖哪个帧”这类信息。MoMQ做的，就是在MoQT和MPQUIC之间加一个兼容层，把这些中继本来就会转发的元数据，翻译成路径调度决策。
实验效果相当亮眼：在Starlink+WiFi真实测试床上，四条声明式规则把帧完成时间的P99.9从384.7毫秒压到114.1毫秒，是目前唯一能满足150毫秒交互延迟目标的多路径方案，同时还把计费备份路径的流量占比压到11.3%。
这不是“多一条路就快一倍”的简单故事，而是关于“传输层缺一双眼睛”的深刻修补。下面龙哥带大家拆开看看。

问题背景及相关工作

先聊聊SVC（可伸缩视频编码）。SVC把视频流编码成多层：基础层单独可解码，增强层在基础层之上叠画质。Google Meet和Jitsi Meet这样的生产级会议平台已经在实际使用SVC。每个画面组（GOP）以I帧开头，它携带完整画面；后面跟着一堆P帧，每个P帧只编码与参考帧的差异。I帧大概230KB，P帧最大也就15KB，前者需要跨越多个拥塞窗口周期才能发完，后者一个周期就能搞定。
这种天生的不平等，落在只认字节的多路径调度器眼里，就引发两类典型故障，看下图。
图1：通过MoQT边缘中继进行SVC传输。左侧显示一个GOP的时间分层，箭头表示帧间参考关系。（1）P帧在单路径上排队在多轮IDR传输之后。（2）依赖帧被拆分到两条路径上，到达顺序与解码顺序不一致。
图1：通过MoQT边缘中继进行SVC传输。左侧显示一个GOP的时间分层，箭头表示帧间参考关系。（1）P帧在单路径上排队在多轮IDR传输之后。（2）依赖帧被拆分到两条路径上，到达顺序与解码顺序不一致。
第一种是护航队效应（Convoy Effect）：I帧要多个传输轮次才能发完，期间产生的P帧全部排队等I帧走完，每个P帧白白多等好几个RTT。第二种是依赖违背（Dependency Violation）：多路径调度器把互相依赖的帧拆到两条延迟不对称的路径上，先到的帧必须等在缓冲区里，等慢路径上的参考帧赶过来。
这两种故障的根因是同一个：帧之间的关键差异只存在于传输层之上的语义层。线上跑的字节流里，I帧和P帧长得一模一样。以往的MPTCP/MPQUIC调度器，从Round-Robin、MinRTT到BLEST，全都只能靠RTT和丢包猜测，没有一个能真正“理解”自己在调度什么。
图5：MoMQ与单路径和纯传输多路径基线的对比。(a) 最小播放缓冲，150ms交互目标已标出。(b) 所有配置的帧完成时间，以中位数、P99和P99.9表示。

实时视频的多路径困境：传输层为何"看不见"视频帧

引言已经提到，SVC编码下的I帧和P帧在字节流层面完全无法区分。那么这种"看不见"到底到了什么程度？论文给出了非常直观的数据：在1080p、50fps、三层可伸缩视频编码（SVC，即Scalable Video Coding）配置下，各层帧的字节数差异悬殊。
表4：1080p、50fps、基于QP分层（层0/1/2的QP为18/26/42）的SVC典型帧大小。
I帧（即IDR帧，Instantaneous Decoder Refresh，瞬时解码刷新帧）平均超过200KB，而底层P帧只有几KB到十几KB，两者相差约23倍。一个I帧要跨越多个拥塞窗口周期才能发完，期间产生的P帧全部堵在后面。更关键的是，传输层的调度器面对这些包，看到的都是"无差别的字节"——Round-Robin按序轮询，MinRTT挑最低延迟路径，BLEST根据传输信号猜阻塞风险，它们在判断时依赖的所有信号（RTT、丢包、拥塞窗口）里，没有任何一个能表达"这个帧丢了整秒画面就没了"这种语义。
卫星链路让这种盲目雪上加霜。论文在Starlink链路上做了30分钟的1ms粒度探测，抓到了103次卫星重配置事件（Figure 9）。每次重配置持续几十到数百毫秒，在传输层看来就像一次随机丢包——重传、等待、窗口收缩，调度器完全不知道这是可以预测的周期性事件。
图9：Starlink重配置事件的持续时间，来自30分钟内1ms粒度的探测，共检测到103个事件。
如果重配置恰好撞上I帧传输，结果就是"重配置碰撞"——I帧的完成时间直接飙到几百毫秒甚至超过1秒。论文用Figure 4把这种效应量化得很清楚：距离I帧越近的帧，延迟概率越高，而且延迟帧的分布与卫星重配置事件高度吻合。
图4：Starlink上的延迟帧分析。(a) 超过200ms的帧完成时间与发送端感知RTT轨迹叠加，重配置事件已标记，超过400ms的延迟绘制为更大标记。(b) 距离I帧不同帧间隔的延迟帧比例，统计了100个画面组。
结论已经很清晰：瓶颈不是路径多样性不足，而是传输层与视频语义之间隔着一道看不见的墙。调度器面对一帧帧视频，脑子里装的却是"这包有多大、RTT多少、拥塞窗口还剩多少"——完全在另一个维度上盲猜。这不是多设计几个传输启发式算法能解决的问题，而是需要在传输层之上找到一扇窗。

MoMQ核心设计：声明式规则桥接应用语义与传输调度

MoMQ的切入点很聪明：视频行业正在标准化的MoQT（Media over QUIC Transport，QUIC媒体传输协议）协议，天然就把视频封装成携带元数据的命名对象（Object）。这些对象在发布者、中继、订阅者之间流转，每个对象都带着"我是I帧""我依赖哪个帧""我属于哪个时间层"这类标签。MoMQ做的，就是在MoQT和MPQUIC之间加一个兼容层，把中继本来就会转发的元数据翻译成路径调度决策。
图2：MoMQ在端到端MoQT传输的最后一跳。订阅者通过MoQT会话安装规则和路径标签注解，边缘中继将每个对象的元数据与规则匹配，合并动作生成逐对象调度指令，交给MPQUIC调度器作为建议而非命令。上游跳保持标准MoQT不变。
MoMQ只工作在最后一跳：边缘中继到订阅者之间的MPQUIC连接。上游的MoQT中继树完全不变。为什么是最后一跳？因为只有订阅者自己最清楚每条接入网的成本、容量和故障特性。中继作为多路径连接的发送端，持有全部视频对象，也掌握每条路径的实时状态——决策和执行都在同一个点上完成，不需要跨节点协调。
为了让中继在不理解视频编码的情况下也能做出合理调度，MoMQ采用了一套声明式规则系统，规则包含匹配项和动作项。匹配项只支持两个操作符（Table 6）：EQUALS做逐字节比较，EXISTS检查某个元数据键是否存在。多个匹配项之间是AND关系，不支持取反和数值区间，规则之间用优先级排序。
表6：两种匹配操作符。
表7：表达交付偏好的动作类型。
动作项有四种类型（Table 7）：PRIORITY调整发送优先级，BALANCING控制是否允许一个对象的包跨路径拆分（默认不拆），PATH_PREFERENCE表达对带某标签路径的软偏好，PATH_AFFINITY则把当前对象绑定到与另一个对象相同的路径。这四种动作组合起来，能表达"I帧优先、P帧不跨路径、计费路径少用"这类完整策略。
对象的元数据放在MoQT对象头部和负载之间（Figure 8），中继只转发不解析。由于MoQT协议本身就对应用自定义元数据做透传，MoMQ没有打破这一安全边界。应用自定义的键值对走的是MoQT预留的应用元数据区间，中继根本不知道这些键代表什么含义。
图8：携带MoMQ元数据的MoQT对象布局，元数据块位于未改动的对象头部和负载之间。
协议设计上，MoMQ只添加了五个线级元素（Table 5），全部集中在控制面：握手时交换ENABLE_MOMQ，中继随后报告PATH_STATE_REPORT，订阅者回以PATH_LABEL_UPDATE安装路径标签，再通过PATH_MAPPING_RULE安装规则，PATH_MAPPING_RESULT确认接收。数据面不携带任何MoMQ信令，如果某一方不支持该扩展，整个会话自动回退到标准MoQT。
表5：MoMQ向MoQT新增的五个线级元素。
图3：从握手到稳态的MoMQ会话流程。阴影部分为MoMQ的增量协议元素，全部位于控制面。
还有一个容易被忽略但非常重要的设计：路径标签。MoMQ的规则不直接引用路径ID，而是引用描述路径属性的标签。中继从自身配置或观测中打上link_type=satellite这样的物理标签，订阅者补充自己独有的认知，比如cost_class=meter（按量计费）。当路径增删时，规则无需修改，只需要重新打标签。一个用户从WiFi+蜂窝切换到WiFi+卫星，策略自动适配，不需要重写任何规则。
表8：MoMQ中继的推荐每会话资源限制。
为了防止规则成为拒绝服务攻击的入口，MoMQ对规则数量、匹配项数量、键值长度、安装速率都设了上限（Table 8）。规则评估是纯粹的字节比较，计算成本有上界，不可能通过精心构造的超长谓词来拖垮中继。

四规则策略：从拥塞效应到重配置碰撞的精准打击

规则系统本身是通用的，但论文基于真实测量，为SVC会议场景提炼了四条具体规则（Table 1），每条规则对应解决引言中描述的一种具体故障。
表1：SVC会议场景的四条MoMQ规则（按优先级降序排列）。每条规则解决引言中描述的一种交付故障。
第一条规则匹配I帧（frame_type=I），设置最高发送优先级，并用路径亲和性绑定自己的对象ID。这一条解决的是护航队效应：I帧作为画面组的"根基"，必须优先发送，并且它所在的路径就是后续所有依赖它的P帧应该走的路径。
第二条规则匹配所有携带依赖声明的P帧，用PATH_AFFINITY绑定到其参考帧所在路径。这是对依赖违背的直接回应：互相依赖的帧必须保证到达顺序和编解码顺序一致，不能因为跨路径拆分发散而乱序。
但这里有个微妙的问题：如果I帧太大，一直在路径上传输，P帧全部堵在后面，延迟也一样爆炸。MoMQ的应对是给I帧设置一个可容忍的超额传输预算（B_budget），计算公式如下：
预算计算公式：B_budget为I帧超出保守拥塞窗口（cwnd_cons）的字节预算，S_I为I帧大小。
简单理解：I帧大小S_I除以保守拥塞窗口cwnd_cons，向上取整得到I帧需要跨越的窗口轮次数，再乘以cwnd_cons并减去S_I，得到的就是最后一个窗口里"剩余"的字节数。P帧只能在这个预算范围内超越I帧——既不会永远被压在后面，也不会把I帧无限期堵住。这个预算值随拥塞窗口动态变化，规则本身不需要修改。
第三条规则针对增强层帧（temporal_layer>=1），降低其紧急度——丢了不致命的帧可以后发。第四条规则是成本控制的关键：只有I帧或关键帧才允许使用cost_class=meter的计费路径，普通帧全部留在免费的卫星路径。这一条直接回应了"延迟导向调度器把90%到100%流量都赶到按量计费路径"的问题。
这四条规则的精妙之处在于：中继不识别视频编码，只是机械地执行匹配和动作。"为什么I帧应该优先"这条知识完全由应用的声明承载，中继只负责执行。这正是论文所说的"机械地执行动作，却不包含任何视频逻辑"。

真实Starlink+WiFi测试床：70%尾延迟削减的实证

论文的实验环境非常硬核：在德国法兰克福部署MoQT中继，荷兰和加拿大的订阅者各自同时持有Starlink终端和地面WiFi，构成真实的双路径接入。视频流为1080p、三层SVC、50fps，交互延迟目标150ms。每个配置跑250次，累计约75万帧数据。
表2：通过德国中继测试的七种配置的帧完成时间、播放缓冲和备用路径使用率。
七种配置包括：单路径（Starlink-only与WiFi-only，各带保守QoS）、Round-Robin轮询、MinRTT（最低往返时间优先）、BLEST（考虑队头阻塞的最小RTT调度器）、Redundant（两条路径全量复制）和MoMQ四规则策略。论文没有只挑软柿子捏，MinRTT和BLEST都是业界认可度很高的多路径调度器。
关键结果直接用数字说话：MoMQ的P99.9帧完成时间压下到114.1ms，相比之下，最好的纯传输调度器（BLEST）要384.7ms，两者相差超过70%。在整个对比区间里，MoMQ是唯一低于150ms交互预算的方案。播放缓冲需求也比最优传输调度器低了61.5%——这意味着用户可以更快开播、更少卡顿。同时，MoMQ对计费备份路径的流量占比只有11.3%，而MinRTT和BLEST这种延迟导向的调度器把90%到100%的流量都挤到了这条按量计费路径上。
这个结果和Figure 4的延迟帧分析完全对上：当调度器对帧类型一无所知时，I帧撞上卫星重配置的尾部延迟肉眼可见。而MoMQ的规则让I帧在重配置窗口期间主动切到地面路径，P帧留在卫星路径排队，各得其所。
论文还做了增量规则激活实验（Table 9），逐步添加规则来拆解每条规则的贡献。结果发现规则1（I帧优先）对尾延迟改善贡献最大，规则4（计费路径控制）对成本控制最关键。四条规则各有分工，缺一不可，但权重并不相同。
表9：在真实测试床上的增量规则激活结果。
图6：增量规则激活下的帧完成时间（每种配置250次运行，约75万帧）。(a) 所有帧（P97放大）。(b) I帧FCT。(c) P帧FCT。
泛化能力测试同样关键。论文将中继移到芬兰，订阅者到中继的距离变为原来的2.5倍，四条规则完全不做修改直接部署（Table 3、Figure 13）。在芬兰拓扑中，MoMQ的优势依然保持，虽然绝对延迟有所上升，但P99.9仍然显著优于所有传输层基线，这验证了路径标签设计方案的核心承诺——规则与具体路径解耦。
表3：中继位于芬兰（2.5倍中继距离）时的基线对比。P帧和I帧中位数以毫秒为单位。
图7：MoMQ与BLEST在不同中继和订阅者距离上的对比。(a) 各位置的播放缓冲中位数，150ms交互目标已标出。(b) 芬兰和加拿大拓扑下的全帧FCT分布，颜色表示位置，线型表示配置。

路径多样性的边界：何时MoMQ失效？

MoMQ的成功有一个关键前提：两条路径必须真的互相独立。论文特地对加拿大订阅者的Starlink和地面路径做了逐跳traceroute对齐分析（Table 11），确认了两条路径在最后一跳之前保持分离。
表11：来自加拿大订阅者的Starlink和地面traceroute跳对齐情况。
一旦两条路径汇聚到同一骨干网，MoMQ的优势就会迅速消失。论文专门测试了路径汇聚场景，所有多路径方案的性能都回归到单路径水平——因为无论调度器把帧分给哪条路，最终都要挤同一个出口，路径多样性实际上并不存在。
另一个边界是MoMQ只作用于最后一跳。如果问题出在CDN中继树的上游——比如跨大洲的骨干拥塞——MoMQ帮不上忙。此外，规则语言不支持数字区间和取反，某些更细粒度的策略需要通过规则组合来近似表达，这在实际部署中需要一定的设计功力。

龙迷三问

下面是龙哥对于大家可能的一些问题的解答：
这篇论文到底在解决什么问题？MoMQ是首个面向MoQT的多路径QUIC扩展，让边缘中继通过声明式规则按视频对象元数据调度路径。
这篇工作最值得看的点是什么？MoMQ将P99.9帧完成时间从最佳传输层调度器的384.7ms降至114.1ms，是唯一满足150ms交互延迟目标的配置，同时将计量路径使用率从90-100%降至11.3%。
这篇工作的边界或风险在哪里？优点：1) 设计优雅，通过声明式规则将应用语义传递给传输层，保持中继对媒体格式的不可知性；2) 规则基于路径标签而非路径标识符，具有良好的可移植性和适应性；3) 实验在真实Starlink和WiFi测试床上进行，结果可信。缺点：1) 仅在最后一跳生效，假设两条路径汇聚于单个中继；2) 依赖路径多样性，当路径共享骨干网时优势消失；3) 规则集需要人工设计，缺乏自动生成机制。
如果你还有哪些想要了解的，欢迎在评论区留言或者讨论~

龙哥点评

论文创新性分数：★★★★☆

提出MoMQ，一种MoQT扩展，通过在边缘中继上安装声明式规则，将对象元数据映射到路径标签，使MPQUIC调度器能够感知视频语义进行路径选择。

实验合理度：★★★☆☆

现有材料未完整覆盖数据划分、基线公平性和统计显著性，因此按中性评价处理。

学术研究价值：★★★★☆

提出MoMQ，一种MoQT扩展，通过在边缘中继上安装声明式规则，将对象元数据映射到路径标签，使MPQUIC调度器能够感知视频语义进行路径选择；更关键的是问题定义是否可复用到同类任务。

稳定性：★★★☆☆

现有材料未提供充分的极端条件、重复运行或扰动测试，稳定性暂按中性评价。

适应性以及泛化能力：★★★☆☆

现有材料未完整展示跨数据集、跨场景或分布外实验，泛化能力仍需进一步验证。

硬件需求及成本：★★★☆☆

规则评估成本受限于已安装规则数量，每个匹配操作简化为字节比较，评估开销有界

复现难度：★★★☆☆

现有材料未确认完整代码、配置、数据处理脚本和权重是否齐备，复现难度暂按中性评价。

产品化成熟度：★★★☆☆

论文验证以研究实验为主，真实部署中的时延、成本、维护和异常场景仍需补充验证。

可能的问题：1) 仅在最后一跳生效，假设两条路径汇聚于单个中继；2) 依赖路径多样性，当路径共享骨干网时优势消失；

主要参考文献

[1] Tanya Shreedhar, Nitinder Mohan, Zuji Zhou, Fernando Kuipers. Media-over-Multipath-QUIC for Realtime Video Applications. arXiv:2608.10741v1, 2026.

*本文仅代表个人理解及观点，不构成任何论文审核或者项目落地推荐意见，具体以相关组织评审结果为准。欢迎就论文内容交流探讨，理性发言哦～ 想了解更多原文细节的小伙伴，可以点击"阅读原文"，查看更多原论文细节哦！       

end
实时视频想快，传输层却"看不见"关键帧？MoMQ告诉我们：不是路径不够多，是调度器缺一双"看懂视频"的眼睛。🚀
欢迎加入龙哥读论文粉丝群，扫描下方二维码或者添加龙哥助手微信号加群：kangjinlonghelper。一定要备注：研究方向+地点+学校/公司+昵称（如 视频传输+北京+字节跳动+阿飞），根据格式备注，可更快被通过且邀请进群。
『龙哥读论文』微信群目前包含：图像处理、大模型及智能体、自动驾驶及机器人、AI医疗及AI金融5个群。快来和同行一起讨论传输调度、视频编码、多路径QUIC这些硬核话题吧！
wechat_helper dianzan

转发文章 微博 X LinkedIn Facebook
龙哥读论文 · PaperDaily

本文基于龙哥读论文 PaperDaily 数据库整理，结合论文原文与工程视角进行解读。