ISOIEC 23009-92025 信息技术 HTTP上的动态自适应流(DASH) 第9部分分段实时媒体的冗余编码和打包(REaP)标准立项发展报告

信息技术HTTP上的动态自适应流(DASH)第9部分：分段实时媒体的冗余编码和打包(REaP)标准立项发展报告StandardizationDevelopmentReport:Informationtechnology-DynamicadaptivestreamingoverHTTP(DASH)-Part9:Redundantencodingandpackagingforsegmentedlivemedia(REaP)摘要随着实时流媒体业务的爆发式增长，传统HTTP自适应流媒体传输方案在面对网络抖动、数据包丢失及边缘节点故障时，其服务质量保障能力面临严峻挑战。为应对这一行业痛点，国际标准化组织ISO/IECJTC1/SC29（音频、图像、多媒体和超媒体信息编码分技术委员会）历经多轮论证与草案修订，于2025年5月正式发布了ISO/IEC23009-9:2025标准。该标准作为动态自适应流（DASH）系列标准的第九部分，首次系统性地定义了面向分段实时媒体的冗余编码与打包机制（REaP）。本报告全面梳理了该标准的立项背景、核心技术架构、关键机制及其产业应用前景。标准通过引入基于源数据块的冗余编码策略与前向纠错打包方案，在不显著增加端到端时延的前提下，有效提升了实时媒体传输的鲁棒性。该标准的发布填补了DASH家族在实时媒体弹性传输领域的标准空白，对云游戏、赛事直播、远程医疗等低时延高可靠场景具有重要的指导意义和支撑作用，标志着自适应流媒体技术从"尽力而为"向"确定性可靠传输"迈出了关键一步。关键词：动态自适应流；冗余编码；实时媒体；前向纠错；流媒体传输；ISO/IEC23009；弹性打包AbstractWiththeexplosivegrowthofreal-timestreamingmediaservices,traditionalHTTPadaptivestreamingsolutionsfaceseverechallengesinqualityassurancewhendealingwithnetworkjitter,packetloss,andedgenodefailures.Toaddressthiscriticalindustrypainpoint,theISO/IECJTC1/SC29subcommittee,aftermultipleroundsofdiscussionanddraftrevisions,officiallyreleasedISO/IEC23009-9:2025inMay2025.AstheninthpartoftheDynamicAdaptiveStreamingoverHTTP(DASH)family,thisstandardsystematicallydefines,forthefirsttime,theRedundantEncodingandPackaging(REaP)mechanismforsegmentedlivemedia.Thisreportcomprehensivelyreviewsthestandard'sbackground,coretechnicalarchitecture,keymechanisms,andindustrialapplicationprospects.Byintroducingsource-block-basedredundantencodingstrategiesandforwarderrorcorrectionpackagingschemes,thestandardeffectivelyenhancestherobustnessofreal-timemediatransmissionwithoutsignificantlyincreasingend-to-endlatency.ThepublicationofthisstandardfillsthestandardizationgapintheDASHfamilyregardingelastictransmissionofreal-timemedia,offeringcriticalguidanceandsupportforlow-latency,high-reliabilityscenariossuchascloudgaming,livesportsbroadcasting,andtelemedicine,markingapivotalstepfrom"best-effort"to"deterministicreliabletransmission"inadaptivestreamingtechnology.Keywords:DynamicAdaptiveStreaming;RedundantEncoding;LiveMedia;ForwardErrorCorrection;StreamingMediaTransmission;ISO/IEC23009;ResilientPackaging一、引言1.1标准立项背景自2012年ISO/IEC23009-1（DASH基础标准）正式发布以来，基于HTTP的自适应流媒体传输技术已从新兴方案演进为全球主流的媒体分发范式。从OTT视频平台到安防监控系统，从在线教育到工业视觉检测，DASH标准凭借其基于标准HTTP基础设施、天然穿透NAT/防火墙、支持CDN无缝集成等技术优势，构建了覆盖数十亿终端设备的全球媒体分发生态。然而，DASH系列标准在早期的设计理念中主要面向点播（VOD）和准实时直播场景，其采用的基于HTTP请求-响应模式的媒体分段获取机制，虽带来了良好的可扩展性和缓存友好性，但在面对强实时性、高可靠性要求的应用场景时，暴露出三方面结构性局限：其一，时延冗余过大。传统DASH基于"先完整下载、后解码播放"的分段获取模式，端到端时延通常在数秒至数十秒量级，难以满足云游戏（<100ms）、交互式直播（<500ms）等场景的严苛需求。对此，业界虽发展出了分块传输（ChunkedTransfer）和低时延DASH（LL-DASH）等改进方案，将时延压缩至1-3秒，但传输层的丢包恢复仍主要依赖TCP协议栈内置的重传机制——一旦发生丢包，需要至少一个RTT的等待时间，这在弱网环境下会导致明显的画面卡顿和音画不同步。其二，丢包恢复能力不足。现有DASH标准体系并未规定媒体层的前向纠错机制。当网络出现突发性丢包（如Wi-Fi信号波动、移动网络切换）时，播放端只能等待TCP重传或依赖应用层的重复请求，这在带宽受限或RTT较大的链路上，会直接影响播放的连续性和实时性。其三，冗余效率低下。当前实践中，为保障实时流媒体的可靠性，运营商通常采用"主备双路冗余推流"或"媒体数据整段复制"的简单策略。这类方案虽实现简单，但冗余开销高达100%，且无法根据网络状况进行自适应调节，在带宽资源日趋紧张的背景下，其资源利用效率亟待优化。在上述产业需求的驱动下，国际标准化组织ISO/IECJTC1/SC29/WG3（此前为MPEG系统工作组）于2020年前后启动了新一轮DASH系列标准扩展的可行性论证工作，旨在为分段实时媒体设计一套高效、灵活、标准化的冗余编码与打包方案。经过多轮需求征询、技术提案征集和一致性测试，该工作最终形成了ISO/IEC23009-9标准草案，并于2025年5月正式发布。1.2标准适用范围与定位ISO/IEC23009-9:2025是DASH系列标准的第九部分，标准全称为"Informationtechnology-DynamicadaptivestreamingoverHTTP(DASH)-Part9:Redundantencodingandpackagingforsegmentedlivemedia(REaP)"。其在DASH标准体系中的定位如图1所示：```ISO/IEC23009系列标准架构├──Part1:媒体呈现描述与分段格式（基础）├──Part2:传输会话初始化（TSI）├──Part3:DASH与ISOBMFF的绑定（基础）├──Part4:加密与认证（安全）├──Part5:DASH的SCTE-35事件信令（广告/事件）├──Part6:公共加密（CENC，与ISO/IEC23001-7配合）├──Part7:服务器端与网络辅助DASH（SAND）├──Part8:会话信令（与WebSocket配合）├──Part9:分段实时媒体的冗余编码和打包（REaP）←本标准└──Part10:低时延流接入点（LL-SAP）```Part9并非要取代或修改DASH基础标准Part1和Part3所规定的媒体呈现描述（MPD）和分段封装格式，而是在其之上提供一套可选的增强机制。该机制允许内容提供商和CDN运营商在标准规定的框架内，对实时媒体分段的源数据块进行冗余编码，并通过标准化的打包格式在HTTP响应中传递额外的修复符号，从而使接收端能够在无需反馈重传的情况下，从一定比例的丢失或损坏数据中恢复原始媒体信息。1.3核心术语与定义为便于后续章节的论述，此处先厘清标准中涉及的几个核心术语：-源块（SourceBlock）：指被冗余编码保护的一组基础媒体数据单元，通常对应一个或多个DASH媒体分段（Segment）的某个连续子集。源块是冗余编码的基本处理单元。-修复块（RepairBlock）：通过冗余编码算法（如Reed-Solomon、RaptorQ等）从源块生成的附加数据单元，用于在传输过程中丢失或损坏数据时的恢复。-冗余编码（RedundantEncoding）：在源数据基础上按照一定的编码规则生成额外校验数据的处理过程，其核心目标是以可控的带宽开销换取传输可靠性的提升。-弹性打包（ResilientPackaging）：将源数据与修复数据按照标准规定的格式进行统一的封装和组织，使其能够在标准HTTP传输框架内进行有效分发。-修复符号（RepairSymbol）：冗余编码输出的最小数据单元，接收端通过收集足够的修复符号和未丢失的源符号，即可解码恢复原始源块。1.4技术演进路线ISO/IEC23009-9的技术方案并非凭空产生，其设计思路可溯源至如下几条重要的技术路线：（1）应用层前向纠错（AL-FEC）标准的积累。ISO/IEC13818-1（MPEG-2TS）和ISO/IEC23008-1（MPEG-HSystems）中已定义了面向传输流的FEC框架。ISO/IEC23009-9在此基础上，针对DASH的分段媒体模型进行了机制重构，将FEC保护粒度从TS包级调整为源块级，以适应HTTP分块传输的特征。（2）低时延DASH（LL-DASH）的实践反馈。自Part1的第三版（2019年）引入分块传输和Segment-independent编解码段（Segment-independentEncoding）概念以来，低时延DASH已在部分商用系统中部署（如AOM/AV1的直播方案）。实践中反馈的一个突出问题是：在弱网环境下，LL-DASH的丢包恢复能力远弱于基于UDP的WebRTC方案。Part9的冗余编码机制正是对这一反馈的直接回应。（3）RaptorQ编码的工程成熟。RaptorQ码作为IETFRFC6330定义的标准化的前向纠错码，具有接近理想的删除信道容量和高效的编解码复杂度。近年来，RaptorQ编解码在移动终端和嵌入式平台上的性能已大幅提升，使得在DASH框架中引入基于RaptorQ的修复机制具备了工程可行性。（4）行业联盟的标准化共识。DASH-IF（DASH产业论坛）自2021年起在其互操作性指南中催生了"增强可靠性的低时延直播"需求文档，该文档中的多个技术提案最终被吸收进ISO/IEC23009-9的正式文本。1.5同类技术标准对比分析为更清晰地界定ISO/IEC23009-9的技术定位，下表将本标准的核心特性与目前业界几种主要的相关技术方案进行了对比：|对比维度|ISO/IEC23009-9(REaP)|IETFWebRTC(RFC8831)|DVB-MABR(TS103769)|私有冗余方案（如HLS主备）||---------|------------------------|----------------------|----------------------|-------------------------||传输层协议|HTTP/1.1,HTTP/2,HTTP/3|基于UDP的SRTP|FLUTE/ALCoverUDP|HTTP||冗余编码粒度|媒体分段级源块|RTP包级|对象级（文件）|整流复制||是否自适应冗余率|是（依托MPD信令）|否（固定冗余度）|是（通过FEC对象）|否（固定100%冗余）||端到端时延预估|1-3秒（配合LL-DASH）|<500ms|数秒级|1-5秒||与现有CDN兼容性|高（标准HTTP）|低（需UDP穿透）|中（需组播支持）|高||标准化程度|国际标准（ISO/IEC）|IETF标准|DVB标准|无（厂商私有）|从上表可以清晰看出，ISO/IEC23009-9的核心竞争力在于：在保持与现有HTTP/CDN基础设施完全兼容的前提下，借助标准的冗余编码机制将实时媒体的传输可靠性提升一个量级。这是对WebRTC方案在CDN穿透性方面不足的有效互补，也是对私有冗余方案在效率上的一次根本性优化。二、标准主要内容与技术框架2.1修订背景ISO/IEC23009-9:2025的制定工作由ISO/IECJTC1/SC29/WG3（MPEGSystems）承担，项目编号为"MPEGSystems-DASHSE:RedundantEncodingandPackaging"。项目自2021年10月正式立项（对应ISO/IECAWI阶段），经过以下关键节点：-2022年1月：完成需求收集与用例定义（CD阶段），形成工作草案（WD1.0）-2023年3月：完成核心技术方案冻结（WD3.0），确定采用FEC框架与MPD信令方案-2023年10月：发布委员会草案（CD），面向各国家成员体征集意见-2024年3月：发布国际标准草案（DIS），进入为期五个月的投票阶段-2024年9月：发布最终国际标准草案（FDIS），处理全部编辑性意见-2025年5月9日：正式发布为ISO/IEC23009-9:2025国际标准2.2技术框架与关键机制ISO/IEC23009-9:2025标准正文共分为九个条款和三个附录，其内容结构如下表所示：|条款号|条款名称|主要内容||-------|---------|---------||1|范围|明确标准适用于基于HTTP的分段实时媒体的传输增强||2|规范性引用文件|引用ISO/IEC23009-1、ISO/IEC23009-3、RFC6330等||3|术语与定义|定义源块、修复块、冗余编码、弹性打包等关键术语||4|符号与缩略语|统一编码参数的符号表示||5|系统架构|定义编码器、打包器、分发网络和接收端的协作模型||6|冗余编码方案|规定FEC方案的选择、参数配置和编码流程||7|打包与信令|定义修复数据的封装格式、MPD扩展信令和HTTP交互流程||8|接收端处理|规定接收端的数据收集、解码和媒体恢复流程||9|一致性要求|定义编码器、打包器和接收端的合规性测试项||附录A|示例编码流程|给出基于RaptorQ编码的完整参数化示例||附录B|MPDXMLSchema扩展|正式定义REaP的XML元素与属性||附录C|实现指南|为开发者提供参数选择和性能优化的建议|（1）系统架构REaP的系统架构设计了一个逻辑功能实体——弹性打包器（ResilientPackager），该实体可部署在内容源站或CDN边缘节点。其核心数据处理流程如下：-分块：将待保护的媒体分段（Segment）切分为等长的源块（SourceBlock），每个源块的大小根据媒体分段的时长和码率动态确定（如默认设为2秒媒体数据对应的字节数）-冗余编码：对每个源块应用FEC编码算法（RaptorQ或Reed-Solomon），生成若干修复符号，修复符号的数量由目标冗余率决定-统一打包：将源块和修复符号按照ISOBMFF格式的要求封装为"增强型媒体分段"，同时生成包含冗余参数说明的扩展MPD描述文件-确定性分发：在HTTP响应中通过专用的字节范围请求（RangeRequest）或自定义HTTP头字段（如`Repair-Symbol-Count`）向客户端暴露修复符号的获取方式（2）冗余编码机制标准定义了两种冗余编码模式：-完全冗余模式：对全部源数据进行同等程度的冗余保护，适用于信道特性均匀的网络场景-优先级冗余模式：对媒体流中关键数据（如SPS/PPS参数集、音频关键帧）施以更高的冗余级别，适用于出现非均匀误码或丢包模式的应用场景在编码参数方面，标准引入了三个关键可配置参数：目标冗余率R（表示修复符号占源数据量的百分