首页> 科技

童谣在2020全球智博会AI双创论坛主题演讲：超低延迟实时流媒体传输技术

2020-08-20 16:10:00 来源：消费日报网

　　2020全球智博会AI双创分论坛暨新形势下的人工智能创新创业论坛于2020年8月15日成功举办。本次论坛由中国人工智能学会、创新中国战略联盟、中国电子商会跨境电商工作委员会主办。随着5G技术的发展、中国新基建政策机遇的来临，我国将进入以科技为核心驱动的中国新经济时代。来自一线的企业家、投资人、产业孵化服务专家分享了在2020年新形势下，人工智能创新创业公司的应对策略及实际案例。

　　中国流媒体技术专家童谣在2020全球智博会AI双创论坛发表主题演讲《超低延迟实时流媒体传输技术》，分享流媒体技术在人工智能领域和跨境电商直播领域的最新研究成果和应用，他对超低延迟传输技术从传输协议的设计选择到流控算法做了精彩的分析，本次主题演讲进行了线上直播，累计在线观看人数达到创纪录的829053，本文摘取童谣的部分演讲实录，以飨读者。

　　主题演讲者/童谣

　　整理/刘生娥

　　由于有了YouTube和Netflix这样的视频服务，我们都希望在观看点播视频时获得超快的下载时间和流畅的播放体验。可能不太明显的是，无论我们是否意识到，这种期望都正在慢慢地向实时音频通信和超高清直播应用转移，所以超低延迟实时流媒体传输技术的需求应用场景会越来越多。类似超高清直播这一类场景是实时视频传输领域中最难的场景，今天我主要分享一下我这两年在超高清直播场景上的研究成果。

　　有些时候，我们的终端并不是直接连接互联网，而是要经过几个网络层，比如NAT、防火墙或者代理。为了解决这些问题，WebRTC允许你使用ICE（Interactive Connectivity Establishment，交互连接建立）协议，该协议可以帮助你找到让两台机器通信的最直接路径，并穿过不同的网络层。为此，需要STUN/TURN服务器来获取用户的外部地址并在无法直接连接时负责通信数据转发。在大部分的WebRTC生产环境中，WebRTC协议需要（除了它自身的多媒体服务器基础设施之外）一组STUN/TURN服务器支持高质量通信。

　　WebRTC协议要求端与端之间所有通信数据必须加密（音频、视频和数据应用），因此它会内嵌一些安全协议填补使用UDP协议时的空白。WebRTC使用SDP（Session Description Protocol，会话描述协议）显示P2P连接的一些属性，如交换的媒体类型及其相关编码器、传输网络和一些带宽信息。

　　这其中也涉及DTLS（Datagram Transport Layer Security，数据包传输层安全协议）、SRTP（Secure Real-Time Transport，安全实时传输协议）、SCTP（Stream Control Transport Protocol，流控制传输协议），其中DTLS用于生成自签名证书来进行加密信息的协商（用于peer之间加密媒体数据以及应用数据的安全传输）。SRTP用于音频和视频的加密传输。SCTP用于应用数据的加密传输。

　　DASH是Dynamic Adaptive Streaming over HTTP的简称，它是一种自适应流媒体传输协议。DASH于2012年4月由MPEG推出，目的是在HLS协议（由Apple拥有）之外，开发一个行业标准。它的工作原理与HLS类似：都是基于不同质量水平的内容准备，将清单文件中索引的视频切分成小块，然后再对其使用ABR技术编码。DASH还支持通过CENC（Common Encryption standard，通用加密标准）加密的内容保护，这使它能够与所有常见DRM系统兼容。LL-HLS和LL-DASH的主要区别是LL-DASH适用于各类编解码器。但遗憾的是，如果使用一些特殊的编码器，LL-DASH将无法与依赖iOS的Apple设备兼容（包括AppleTV）。

　　2019年，我对LL-DASH标准化协议进行了必要的修改，将延迟降低到了2秒。背后，它所依赖的正是CMAF（Common Media Application Format，通用媒体应用格式）。CMAF使LL-DASH能够使用一些有用的HTTP特性，从而显著降低延迟。这两个特性分别是“分块编码（Chunked Encoding）”和“分块传输编码（Chunked Transfer Encoding）”，它们都是HTTP1.1的一部分（而在HTTP/2中禁止使用）。分块编码先将视频切片分割成几毫秒的视频块，这些视频块一旦被编码，就会被发送到分发层；接下来由分块传输编码将这些视频块快速分发。然而，要完成这样的传输过程，整个分发栈从源站开始一直到CDN都必须支持分块传输编码这一特性。

　　HESP（High Efficiency Stream Protocol，高效流媒体协议）是另一个基于ABR HTTP的流媒体传输协议，也是最新推出的协议。它是由THEOPlayer公司通过HESP联盟（主要任务是致力于HESP协议的标准化和发展）进行标准化的。

　　开发HESP的目的是解决其他HTTP流媒体协议的局限性，它的目标是：

　　在确保可扩展性（指依然可以与主流CDN厂商合作）的同时达到超低延迟（低于500毫秒）。

　　在传输时减少所需带宽消耗。

　　减少切换次数（zapping times），zapping是指各种视频流之间切换（可以想象成在观看有线电视时切换频道）的次数。

　　这三个性能指标对于直播观众的用户体验具有直接的影响。由于HESP的极低延迟，它也可以成为WebRTC的替代方案。HESP最主要的缺陷是，它是专有的商业协议，商用的话，价格非常高。

　　让我们来简单看下它的工作原理。

　　与其他低延迟协议相比，HESP最大的区别是它依赖两个（而非一个）视频流。在了解HESP如何帮助我们达到次秒级延迟之前，让我们先来聊聊视频流传输所使用到的不同类型的帧。在视频压缩中，要用到以下几种帧：

　　IDR帧（也称为关键帧）

　　I帧

　　P帧

　　B帧

　　让我们先从I帧开始，理解了I帧，你才能更好地理解其他帧。I帧包含全部图像，并且在编码时除自身外无需参考其他任何帧。

　　关键帧（或IDR帧）是一种特殊的I帧，关键帧之后的帧无法参考到它之前的帧。也就是说，所有IDR帧都是I帧，但反过来却不是如此。任何播放器都能使用关键帧开始播放视频。

　　P帧只保存当前图像与前一张图像间的变化。B帧所保存的是当前帧与其前后帧之间的变化。

　　现在你已经知道了构成视频的不同帧之间的作用，让我们回到组成HESP协议的视频流：

　　第一个视频流被称为初始流（Initialization Stream），仅包含关键帧。

　　第二个视频流被称为延续流（Continuation Stream），它类似于普通的编码流，意味着它能够包含所有类型的帧（取决于实现最大性能或者最大兼容的编码参数和定义的配置文件）。

　　初始流只用于播放开始时或者当你为了更改播放位置而滑动视频时间线时。由于它仅包含关键帧，播放器背后的解码器能够快速解码该帧，然后才开始（或重新开始）播放直播事件。一旦第一个视频流中的第一帧被获取并解码，播放器就会自动切换到第二个视频流，并继续播放视频。这是因为关键帧是完整的图像，所以它的带宽成本很高。通过切换到第二个视频流，播放器会回退到常规的实时视频流带宽占用，这将提高CDN的并发性能（CDN可以扩展观众并降低到源站的负载）。同DASH/LL-DASH一样，HESP也使用CMAF-CTE进行视频打包和分发。它继承了DASH/LL-DASH的所有的特性，比如加密、支持DRM、字幕（以及听力障碍人士所使用的字幕）、广告等。

　　HESP看起来很厉害（理论上），是吧？它确实解决了许多问题。但是同其他协议一样，它也不是完美的。它也有自身的缺点和局限性。第一个缺点就是，它使用两个同步编码的视频流，其编码和存储成本要高于其他基于HTTP的流媒体协议。

　　第二个缺点是，即使它依靠CMAF-CTE进行打包和分发，在编码和分发阶段，打包器必须进行更新才能处理两个（而非一个）视频流。

　　除此之外，和打包器一起，为了能够使用HESP协议播放视频并处理所有的字幕，播放器也必须进行更新。最后一点也很重要，你必须支付专利费用才能商用HESP，这无疑限制了它的普及推广。

　　所以哪种协议最好？

　　简洁的回答是没有最好的协议。这个答案似乎对做出选择没什么帮助。更完整的答案是协议的选择主要依赖于其所针对的使用场景、资源投入（包括资金和人力）、时间成本等。

　　如果你需要向用户和观众提供合理延迟范围内（6秒～15秒）的实时视频传输能力，同时保持成本效益，我们会推荐你使用HLS和（或）DASH，因为它们可以轻松将视频传输给数百万观众。你可以找到许多已经很好地实现了这两个协议的开源库和流媒体平台。我们更倾向于选择HLS，因为它在采用率以及浏览器和设备的支持率方面都是最高的。几乎在任何地方都可以使用它。

　　如果延迟对你的业务而言非常重要，你应该了解一下低延迟和超低延迟协议，如果你只需要延迟在2秒左右（适用于体育赛事、音乐会和在线课堂）的单向实时视频传输性能，而又没有太多的预算，你应该了解一下HLS和（或）LL-DASH协议。

　　对于其他不能接受延迟超过1秒的应用场景，你没有太多选择：WebRTC或者HESP。如果你们是一家非盈利组织，但是需要服务大量观众或者不想构建极其复杂的基础设施且没有太多预算，不妨考虑一下HESP协议。

　　如果你需要双向视频通信，WebRTC已经证明了它的实力。但如果构建内部基础设施并不是你的核心业务，你很可能需要依赖已经成功构建了基础设施（已实现规模化）的提供商。

　　最后，如果资金不是问题，我们会选择HESP，因为与实现WebRTC相比，它要简单得多，并且与各类设备和浏览器兼容。

　　我非常相信，基于HTTP的低延迟或超低延迟流媒体传输协议将在最后赢得这场“战斗”。原因非常简单，这些协议在相对陈旧的基础设施中更容易实现，并从更多设备和浏览器的支持中获益，同时它比WebRTC更容易扩展，而且由于它们并没有收取高昂的许可费用，所以大量公司都可以采用。

　　这就是我基于HLS构建端到端边缘视频基础设施的原因。我有信心，HLS在不久的未来会成为唯一满足各类音视频应用场景的传输协议。

　　作者：刘生娥

童谣在2020全球智博会AI双创论坛主题演讲：超低延迟实时流媒体传输技术

推荐

助力乡村振兴，用5G消息打造“老稻种博物馆”

娱乐

《独行月球》票房破10亿笑中带泪的宇宙级浪漫

旅游

贵州黄平县野洞河漂流景区成功举办爽爽漂峡洞瀑布漂流音乐节

房产

澳思柏恩OSB板满足个性化需求，享受ENF级品质生活

美食

拓展文明互鉴新境界，谱写美美与共新篇章

合作伙伴

贵州网