数字视频原理 课件 第11章 网络视频传输概述

1数字视频原理PrinciplesofDigitalVideo授课教师第11章网络视频传输概述211.1IPTV与OTT11.2ATSC3.011.3HbbTV11.45G广播11.5流媒体技术的演进11.5.1流媒体技术的早期发晨阶段11.5.2流媒体技术的现代进展与创新11.4.15G广播的演进11.4.25G广播帧结构11.4.35G广播与地面数字电视标准的性能比较3视频传输主要有传统的广播电视和网络视频两种方式：网络视频发展有四条主要路径：IPTV：在IP专网传送多类型内容，提供可管理的多媒体业务，含QoS（服务质量，解决网络问题）和QoE（体验质量，从用户角度衡量性能）。OTT：通过开放互联网提供视频等服务，绕开运营商直接面向用户，我国规定其以互联网为定向传输通道接入集成平台提供服务，集成平台负责多项管理。传统广播与互联网宽带结合：如美国的ATSC3.0和欧洲的HbbTV，提升信号质量，集成互联网功能，支持交互服务和数据广播。基于移动通信标准：如3GPPR14的LTE衍生技术及R16的5G地面广播，为地面广播带来新机遇。11.1IPTV与OTT4IPTV概述11.1IPTV与OTTIPTV经IP城域网传输，面向电视屏幕，依赖固定宽带且不跨运营商，国内需有线连接专用机顶盒。内容由牌照商提供，含直播、点播等，用户付费观看，直播稳定清晰但交互性有限，选择受限且不支持个性化推荐。采用基于IP的专网，不连互联网，播放质量稳定、网络安全风险低，但仍需防护。IPTV是集运营支撑、业务应用、承载及用户终端等多层面的综合系统，提供视频点播、电子商务等多样化服务，突破传统电视服务。IPTV核心技术涵盖视音频编解码、内容分发、服务质量、流媒体及数字版权保护等。因数据量大且实时性要求高，传统TCP协议不适用，IETF制定RTP、RTCP、RTSP等实时流媒体传输协议，RSVP协议也用于保障特殊服务质量。直播业务以基于UDP的组播流转发，减少带宽浪费并满足实时观看；点播/回放业务无实时性要求，采用基于UDP/RTP/RTSP的单播流技术为主52.IPTV体系架构63.OTT概述OTT是当前网络视频主流方式，借开放互联网传输内容，用户接入网络即可通过多种设备跨平台无缝观看，内容来源广泛，涵盖牌照商、视频网站及第三方提供商。费用灵活，部分免费部分需订阅，功能交互性强且支持个性化。但依赖公共互联网，播放质量易受网络影响，且面临网络安全挑战，需加强防护。国内OTT行业通过牌照制实现内容可管可控，七大牌照商持有牌照。截至2024年底，全国有线电视用户2.08亿户，IPTV用户超4亿户，OTT月活用户2.85亿户，互联网视频年度付费用户7.88亿户，短视频上传用户8.5亿户，全国高清及超高清电视频道数量可观，五大新媒体平台去重活跃用户规模达10.71亿，渗透率85.7%。711.2ATSC3.01.ATSC3.0概述美国高级电视制式委员会（ATSC）是非营利性全球组织，成员来自多行业，致力于数字电视标准研发。1995年发布A/53标准（即ATSC1.0），1996年被FCC采纳为美国国家标准，后不断完善升级。因技术演进和观众需求提升，ATSC于2018年1月发布ATSC3.0标准，ATSC2.0因提前过时，其更改均集成至ATSC3.0。ATSC3.0是先进数字电视广播技术标准，旨在性能、功能和效率上取得突破，后向不兼容ATSC1.0，能传输超高清服务，适用设备广泛，效率更高，采用全IP传输，具备个性化与交互功能，功能更丰富。82.ATSC3.0系统结构ATSC3.0广义系统分层物理层主要负责数据传输所需的链路创建，比如复用技术、星座映射、编码方式等；管理和协议层主要负责数据传输的协议控制以及各种业务的管理；应用层主要负责应用程序、播放器、UI、编解码器等的设计和开发。9一般物理层帧及前导符号结构ATSC3.0物理层以引导信号（Bootstrap）引领各帧，展现灵活性与可扩展性。引导符号信号鲁棒性强，能在恶劣射频条件下被捕获，除同步外，还传递物理层技术信息（含版本号以支持未来演进）、紧急报警、系统带宽、帧间隔及采样率等基础信息。通过利用调制、编码、纠错、星座映射等最新技术的改进，ATSC3.0物理层在BICM（比特交织、编码和调制）链路表现的性能非常接近香农极限理论。10ATSC3.0传输层采用IP封装传输数据流及媒体文件，区别于ATSC1.0的MPEG-2封装方式。ATSC3.0使广播融入互联网，助力运营商开发新服务，缩小与网络发展差距。如IP传输结合ISOBMFF文件格式，使接收端个性化植入广告变得简单可行。ATSC3.0系统协议栈采用全IP协议支广播服务，基于UDP/IP，用MMTP传媒体单元及信令、ROUTE传DASH段等交互式服务，基于TCP/IP非时序内容也可通过UDP直接传输为支持异构服务，ATSC3.0在宽带端采用MPEGDASH经HTTP/TCP/IP传输，并使用基于ISOBMFF的媒体文件实现传输、封装与同步11ATSC3.0系统协议栈123.ATSC3.0的特点（1）后向不兼容性：摒弃旧弊，不向后兼容，采用新技术提升性能，确保标准先进。

（2）技术先进性：

采用前沿技术，引领数字电视广播发展方向。

（3）技术开放性：

广泛征求意见，融合先进提案，结合互联网发展，以IP流传输为核心提升广播业务。

（4）发展可持续性：

预留扩展模式，便于未来新技术适配，保障持续发展。1311.3HbbTV广播宽带混合电视（HybridBroadcastingBroadbandTV，HbbTV）于2009年欧洲HbbTV协会成立时提出，首个HbbTV规范同年发布2015年发布的HbbTV2.0标准被欧洲电信标准协会（ETSI）采纳为国际技术标准，标志着其正式标准化。HbbTV基于多标准协议设计为混合方案，兼容DVB提供广播平台，支持视频点播、时移电视等多种联网应用。14HbbTV是集广播与互联网功能的电视平台，核心为混合终端（可连广播DVB网与宽带网）：网络连接与数据接收：可以连接到广播DVB网络，如DVB-T、DVB-S或DVB-C等，终端能够接收标准广播的线性音视频内容（传统按固定顺序播放的音视频）、非实时音视频内容、应用程序数据以及应用程序信令信息。具备宽带互联网连接能力2.运行时环境与内容处理：运行时环境含浏览器等组件，显示和执行交互应用；能处理线性（同标准DVB终端）与非线性音视频内容（经宽带转媒体播放器播放）。3.伴侣屏幕设备交互与同步：支持交互同步，通过接口发现设备，用WebSocket服务器通信，实现多设备内容共享同步。4.CIPlus接口：方便混合终端从条件接收模块请求应用数据，利于系统更新扩展。系统概述152.系统构成HbbTV基于OIPF、CEA-2014（CE-HTML）、W3C（HTML等）、DVB应用信令规范（ETSITS102809）和DASH等现有标准及Web技术：OIPF提供关键JavaScriptAPI，集成DRM技术；CEA-2014是专为消费电子设备设计的用户界面页面创建语言；W3C（HTML5）提供核心基础，含HTML标记语言等；DVB为HbbTV提供应用程序信号及传输方法；音频和视频格式由OIPF媒体格式规范定义。HbbTV与其他现有标准间关系1611.45G广播5G融合大塔广播与通信单播，结合大塔、小塔及有线网络优势，提供高效高质量视频及公共服务，广播单播互补，支持新型业务，且5G广播支持无SIM卡接入，利于公共服务。5G广播专为传统广播公司设计，与DVB-T有相同技术基础，但基于5G网络，采用先进无线通信技术，实现多频段、多通道、高码率传输。2002年3GPP启动多媒体广播多播业务MBMS研发，支持多媒体广播和组播，但无法满足手机电视业务需求。2009年3GPP发布eMBMS作为4G广播技术，2017年冻结Release14版本，形成FeMBMS标准，将大塔纳入移动通信标准，标志技术融合。FeMBMS及后续基于NR空口的标准统称“5G广播”，是实现广播电视与移动通信网络融合的重要契机。5G广播技术标准的形成是实现广播电视网络与移动通信网络融合的重要契机，形成广播与通信双赢的局面。1711.4.15G广播的演进5G广播标准化历经4阶段演进：MBMS（2G/3G时代）：2004年3GPP发布首个版本，规定网络结构等内容，提供点对多点服务，Release7提出MBSFN提升覆盖效率。eMBMS（4G时代）：基于4G核心网和LTE空口框架，改进系统架构，梳理MBSFN功能，规划两种小区模式，后经多版本提升效率和服务连续性，2015年前后有商用小高潮。FeMBMS（4G/5G时代）：2017年发布，增加ROM等新特性，确定MBMS-dedicatedCell模式，优化高塔参数；2020年Release16基本完成广播大塔标准制定；明确两条技术路线，地面广播模式面向广电，混合组播模式面向物联网等。NRMBS（5G时代）：2022年Release17标准冻结，侧重小区热点内容流量卸载，定义广播和组播模式；引入RAN增强功能，支持在广播UHF频段部署5G地面广播。1811.4.25G广播帧结构5G广播的帧结构MBSFN区域子帧可用多种SCS，∆f=7.5/2.5/1.25KHz时，MBSFN区域为1ms时隙；∆f≈0.37KHz时，MBSFN区域为3ms时隙。帧结构类型1用于除0.37KHzSCS外子载波，如1.25KHzSCS时隙长1ms帧结构类型2用于0.37KHzSCS子载波，CAS为用15KHzSCS参数的非MBSFN子帧。

19标准版本∆f/kHz每个子帧的正交频分复用符号

每个子帧的OFDM符号数持续时间/us有用OFDM符号持续时间站点间距/km开销%MBSFNRel9~Rel1315.00121216.766.7520MBSFNRel147.5024633.3133.310201.2514412008006020MBSFNRel16、Rel172.5072210040030200.374861/330027009010基于Release16的5G广播OFDM参数集选项2011.4.35G广播与地面数字电视标准的性能比较1.频谱带宽5G广播和地面数字电视标准的频谱带宽比较标准1.7MHz5MHz6MHz7MHz8MHz10MHz15MHz20MHzDVB-T2√√√√√√--ATSC3.0--√√√---DTMB-A--√√√---5G广播-√√√√√√√2.编码第二代地面数字电视标准（如DVB-T2）用LDPC+BCH编码，FeMBMS用Turbo编码，前者BICM频谱效率更优，ATSC3.0最新组合在AWGN信道下比FeMBMS增益约高1-2dB。3.时间交织器地面数字电视标准的时间交织器可将突发错误扩展为随机错误，在恶劣衰落环境性能优势显著；FeMBMS为减少延迟未设置时间交织器，因此在高速恶劣移动衰落信道需较高载噪比。214.层分复用ATSC3.0采用层分复用LDM技术，性能增益3-9dB，能充分利用发射功率、增大系统传输容量；但FeMBMS不支持，其灵活性和频谱效率不如ATSC3.0。5.站间距离Rel-16引入300μs循环前缀，解决大距离单频网覆盖等问题，增强接收机抗多径能力。DVB-T2和ATSC3.0提供不同保护间隔参数，长CP增加系统开销，需平衡利弊，二者在32K模式下可支持更大CP，站点间距大于5G广播。6.5GNR广播进展与优势2023年3月中国广电主导的5GNR广播进入TU标准程序，6月全面升级系统，7月完成端到端测试，实现首个5G应急广播专网商用。支持700MHz频段手机免流量收看直播，能同时支持多种数据传输方式，为新兴5G行业应用提供高效支撑。2025年，中国广电与中国移动在北京、上海、安徽、海南等省市开展5G广播现网试点2211.5流媒体技术的演进网络视频已经取代数字电视成为主流，其基于IP网络连续传输音视频（视频常泛指音视频），需经压缩编码等步骤，依赖流媒体技术。“流媒体”特指基于IP的网络媒体传输，边下载边播放，强调连续性。流媒体有流媒体系统和流媒体格式两种含义：流媒体系统（技术、方法及协议总称）流媒体格式（含时间同步信息）网络视频分三大场景：直播：实时传输，具实时性等特点点播：自主选择，具自主性等特点实时交互：多方实时互动，具即时性等特点2311.5.1流媒体技术的早期发展阶段1990年H.261标准推动视频通信发展，但ISDN难普及。流媒体技术源于解决互联网点到多点高效数据传输问题的IP组播技术。20世纪80年代中期斯坦福大学SteveDeering提出IP组播可能，后续发表相关论文、协议，奠定组播基础。SteveDeering等人开发多路广播骨干网MBone，1992年首次用于IETF会议音频广播实验，实现双向传输，随后MBone技术和规模快速发展。学者RonFrederick参与IP组播和MBone研究，1992年基于IP组播开发网络视频会议工具nv（networkvideo），同年11月发布并直播IETF会议，nv成互联网直播会议主要工具之一，还被NASA选中直播航天任务。1.

流媒体技术的早期探索与基础奠定242.

RTP协议的诞生Mbone、nv、CUSeeMe等音视频网络技术在一两年内涌现，标志流媒体时代开启。四位参与Mbone建设并开发工具的学者提出RTP协议，其基础源于互联网会议工具网络协议，经IETF标准化后发表并修订。RTP可传输多种实时数据流，应用广泛。为弥补其不足，RFC中规定了伴生协议RTCP，定期传输控制数据提供反馈，统计信息可助网络应用提升服务质量。3.图形浏览器的兴起与多媒体互动的萌芽1993年NCSA发布免费图形网页浏览器Mosaic，其界面简洁易懂、性能可靠、安装简便，还是首款支持“内联图形”的浏览器，能在文本中插入图片，点燃大众网络兴趣，促进90年代互联网繁荣，是互联网历史里程碑。254.流媒体技术的初步商业化1994年11月18日，滚石乐队借MBone举办网络在线演唱会，凸显其交互式媒体能力，MBone能动态构建分布树防拥塞。1995年2月，H.263问世，突破H.261局限，压缩效率提升超50%，加速流媒体发展。同年，RealAudio打破媒体文件需完整下载播放的常态，可实时传音频，对应多种文件格式，RealNetworks成流媒体市场先驱。5.

主要流媒体技术与产品的竞争1996年VivoSoftware发布基于H.263和G.723的VivoActive，整合音视频流，访问者下载插件或播放器即可观看。同年，Microsoft推出NetShow（1999年更名为WindowsMedia），使用ASF格式传输流媒体，灵活不受压缩编码限制，支持实时多播和点播流。1996年RTSP草案提交IETF，1998年成互联网标准，管理多媒体数据传输，双向且依托底层协议，充当“网络远程控制”，不传递媒体数据流。266.早期流媒体技术的成熟与广泛应用1997年，RealNetworks推出RealVideo及RealMedia系统，获50多家公司支持；同年，微软免费提供NetShow2.0测试版，后发布服务器并收购VXtreme，产品反响热烈。随后RealNetworks推出RealSystem5.0，支持多种流媒体业务模式。互联网发展导致网络拥塞，1998年麻省理工团队催生CDN，Akamai成首家运营商。1998年Apple展示QuickTime3，成为跨平台多媒体工具，1999年又相继发布新版本及服务器。7.早期流媒体技术的进一步发展与融合1998年，RealNetworks收购VivoSoftware并推出RealSystemG2，性能改进显著，支持多种特性及广泛数据格式，率先支持工业标准，胜过微软NetShow。1999年，Microsoft将Netshow更名为WindowsMedia，推出ASF流式媒体技术并提供SDK。2000年，微软推出支持多格式的WindowsMediaPlayer7.0；同年RealNetworks推出适应任何操作系统的RealSystem8.0，RealPlayer8支持多种内容类型。278.

Flash与RTMP协议的崛起20世纪90年代中期，MSN等大型网络公司用FutureSplash在因特网播放动画。1996年12月，FutureWave被Macromedia收购，FutureSplashAnimator更名MacromediaFlash。此后五年，Flash在网络上作为动画显示或游戏制作方式的使用显著增加，同年Macromedia开发RTMP协议，实现互联网最早实时流媒体播放之一，该协议成为近20年互联网多媒体流通用标准，随FlashPlayer普及成流媒体传输重要技术。2005年Adobe收购Macromedia，Flash融入Adobe产品系列。2012年Adobe开放RTMP规范，使其无需依赖Flash也能开发新传输方案，故2020年12月FlashPlayer被弃用后，RTMP协议仍在现代视频传输中发挥重要作用。289.三大平台的没落2000年前，互联网流媒体市场中，Real公司凭RM和RMVB格式占据重要地位，但因错失与“iPod”发明人合作、盈利模式单一，且在Flash技术和H.264编码兴起后技术优势被削弱，市场份额下滑。WindowsMedia初期与RealMedia竞争有力，后因竞争对手崛起、技术更新放缓及移动兼容性不足而没落。QuickTime作为苹果1991年推出的技术框架，曾应用广泛，后因竞品崛起、安全性及兼容性问题，使用范围缩减。2911.5.2流媒体技术的现代进展与创新1.RTP/RTSP21世纪初，宽带普及与多媒体需求增长相互促进，RTSP/RTP协议成高质量流媒体服务核心技术，被广泛用于构建视音频服务体系，在远程会议、网络电视等多个领域推动流媒体技术发展，铸就黄金时代。但RTP/RTSP存在缺陷，如RTP缺乏可靠传输保障、安全性弱，RTSP面临防火墙和NAT穿越困境等，制约了其应用。而RTMP稳定性强，能解决防火墙穿透等问题，在互联网流媒体领域应用广泛。302.渐进式流媒体技术21世纪10年代，优酷等主流视频网站广泛采用基于HTTP的渐进式下载技术，该技术基于承载于TCP协议之上的HTTP协议，客户端可边下载边播放。TCP采用慢启动算法，通过重传实现可靠传输，但在流媒体应用中，TCP难保重传数据按时抵达，渐进式下载仅适合点播，无法支持直播与实时交互。尽管有局限，渐进式下载仍因简单高效，在短视频、小型网站、个人博客及企业培训等多领域发挥不可替代作用，支撑视频传播分享。313.RTMP2010年前后，流媒体发展初期，AdobeFlash主导国外多媒体领域，RTMP因低延迟成网络直播首选，提升观众体验；国内网络滞后，RTMP应用规模和影响力远不及国外。2010-2016年，流媒体快速发展，RTMP迎新契机，国外成游戏直播等核心技术，推动在线教育发展；国内网络改善，RTMP在大型平台多领域发挥关键作用。2016年起，流媒体技术转型竞争，RTMP面临挑战，国外受HTML5及移动设备对Flash支持减少冲击，但在专业领域仍不可替代。行业探索新兴协议，RTMP受重视程度随技术变革有所波动，在特定场景中依然保有显著优势。324.HTTP-FLV虽先进流媒体技术众多，但抖音、TikTok等媒体巨头仍采用2008年Adobe提出的HTTP-FLV技术以获超低延迟，这在互动娱乐领域很关键。FLV格式简单高效获广泛应用，HTTP-FLV将其封装后经HTTP传输，提升兼容性，早期让用户可跨浏览器看视频，且连接稳定、传输流畅，初步应用于视频分享和简单直播场景。此外，HTTP-FLV实现简单、延迟低、部署容易，还能轻松穿越防火墙和代理服务器，便于在复杂网络环境应用。335.基于HTTP的自适应流媒体RTMP等流媒体技术均以恒定码率传输，与波动网络带宽存在矛盾。基于HTTP的自适应流传输（HTTPadaptivestreaming，HAS）技术：

HAS技术原理框图2006年起，MoveNetworks、Microsoft、Apple、Adobe陆续发布基于HTTP的自适应流媒体技术方案（MSS、HLS、HDS等），虽技术框架和80%内容相同，但彼此不兼容。2012年，3GPP与MPEG联合推出DASH国际标准，支持点播、直播，但因延时较大，主要用于点播。34早期流媒体技术复杂难用，1990年代SergeLachapelle尝试从浏览器视频通话并移植到Windows，后作为Marratech联合创始人开发群组视频会议软件。2007年Marratech被谷歌收购，Serge参与首个谷歌项目即未来的WebRTC，旨在打造基于浏览器的实时音视频通信系统。谷歌收购开源所需组件达成目标，2021年1月WebRTC成为官方标准，实现全球互联。WebRTC由JavaScriptAPI和通信协议构成，核心组件有MediaStream、RTCPeerConnection、RTCDataChannel等，具有实时、免插件、开源、跨平台等特性，采用多种协议保证传输安全、实现NAT穿越，还引入数据通道技术，为多种应用场景提供可能。6.WebRTC357.SRT视频流媒体业发展对高质量、低延迟传输需求大增。传统UDP协议速度快但不可靠，RTMP协议有连接长、拥塞控制不足等问题，移动端易卡顿延迟。美国Haivision联合Wowza基于数据传输协议（UDP-basedDataTransferProtocol，UDT）提出SRT协议，旨在通过不可靠公共网络实现高质量、低延迟且安全可靠的视频传输。遵循遵循LGPLv2.1开源许可协议。SRT采用多种先进技术，能在网络不佳时保持高质量传输。SRT已广泛应用于广播和流媒体业务，YouTube等流媒体平台已加入致力于推动低延迟流媒体协议通用标准化的SRT联盟。368.其他流媒体传输协议与技术ORTC是W3CORTCCG设计的API，由Hookflash创立，获微软等支持，微软将其用于Edge浏览器并创建开源项目。ORTC与WebRTC1.0兼容，采用更模块化方法，不使用SDP，简化了媒体流操作。解决公共网络上的丢包问题以及各厂商设备间的互操作性不足，可靠互联网流传输协议（ReliableInternetStreamTransport，RIST）小组于2017年成立，制定通用规范以应对弱网传输等挑战，2018-2021年陆续发布简单、主、高级配置协议，提升传输可靠性和安全性。针对视频监控设备互联互通问题，中国公安部2011年发布GB/T28181标准，经多次修订，采用RTP/RTCP、SIP等协议，规定音视频格式，并设计MANSRTSP扩展协议，提升系统灵活性、安全性与管理效率。379.QUICQUIC（QuickUDPInternetConnections）由Google提出，旨在替代TCP，在用户层实现TCP大部分优点并优化不足，其创新特性理论上可降低传输延迟。QUIC最早由Google于2013年开发发布，称gQUIC，它独立保障数据传输的可靠性与安全性，类似TCP+TLS，获主流浏览器及Google服务器、云服务支持。2013年末，IETF接管QUIC设计并发布iQUIC标准，iQUIC仅保障传输稳定性，安全性交由TLS1.3。TCP与gQUIC、iQUIC的架构对比38性能协议TCPQUIC部署内核空间用户空间连接时延3次握手1次或0次握手安全性保证TLS1.2（可选的）TLS1.3标识五元组连接ID序列号可重复的单调递增流量控制连接级连接级、流级拥塞控制算法固定的灵活可配置的应用级流单独的可复用的CPU占用1.0倍3.5倍TCP与QUIC的传输特性对比39TCP和QUIC的连接握手对比40QUIC协议有以下改进：连接握手：QUIC实现0-RTT（1-RTT）安全应用数据传输，缩短TCP“3次握手”2-RTT的连接建立延迟。序列号与重传：QUIC以单调递增报文号替代TCP可重复序列号，解决TCP重传歧义问题。流量控制：QUIC在流和连接级别启用类似TCP的流量控制，比TCP单一移动窗口式控制更精细。拥塞控制：QUIC默认用TCPCubic算法，也灵活支持多种算法，且易于在用户空间部署，单个应用不同连接算法可不同。连接标识：QUIC用灵活CID代替TCP五元组标识连接会话，网络环境改变无需重建连接，避免NAT重绑定问题。丢包处理：QUIC支持FEC功能，可通过冗余数据恢复丢失包，在丢包率高场景性能佳。多流交互：QUIC扩展多流抽象，各流有序且独立，解决TCP队头阻塞问题。41QUIC特性基于UDP实现但不依赖内核，特性可分解为插件，能按网络条件和需求定制，TCP无法做到。同等条件下，QUIC对主机CPU占用率