技术解码 | DASH协议直播应用

2021-11-01 09:40:38 浏览数 (1)

导语 | 本文介绍了DASH协议，并分享了腾讯云直播系统在DASH协议功能实现和灰度验证中积累的经验、遇到的问题以及解决的思路。

- 协议介绍 -

在对海外各大OTT流媒体平台的调研中，我们可以了解到海外流媒体常用的协议有Facebook、Twitch等平台使用的、由Apple提出的HLS协议，微软在其名下各个平台上使用的、由其制定的MSS协议以及Adobe为各大企业提供媒体服务支持时使用的、其制定的HDS协议等等。

因此在海外音视频领域的流媒体协议应用中，各种协议五花八门。而为了在互联网上形成单一格式的流媒体并提供高效与高质量服务的统一方案，解决多种传输方案(HLS、MSS、HDS)并存情况下导致的存储与服务能力的浪费、更高的运营成本与复杂度、系统间互操作弱等问题。在2011年底MPEG和ISO共同制定了MPEG-DASH标准，并于2014年成为首个基于HTTP协议的自适应流媒体技术的国际标准。DASH全称是Dynamic Adaptive Streaming over HTTP，即基于HTTP的动态自适应的比特率流。

DASH和HLS协议类似，都是将音视频流分割成小块，通过HTTP协议进行传输，客户端得到之后进行播放。不同的是DASH支持MPEG-2 TS、MP4等多种媒体格式，有良好的扩展性。

如今MPEG-DASH在Android上已经可原生使用，各品牌电视机皆已支持，如三星智能电视2012 、LG智能电视2012 、索尼电视2012 等等。而各大视频网站如YouTube和Netflix也已经支持MPEG-DASH，并且发展出了多种MPEG-DASH播放器。

下面我们来对DASH协议及其工作流程进行分析。

- 协议分析 -

DASH协议的核心都在其Manifest文件，如果能知悉其Manifest文件内容，则相当于对DASH协议已经有了一定了解。

DASH的Manifest文件名为Media Presentation Descrption(MPD)，使用XML格式，对音视频流作了多个维度的划分，下面我们对其结构和内容做一个分析。

如上图所示，MPD文件的结构由外向内分别是Period（周期）->AdaptationSet（自适应子集）->Representation（码流）→Segment（片段）。

  • Period（周期）：一个Period代表一个时间段，在直播中一般只使用一个Period，多Period只有在一些特殊场景下才会使用。
  • Adaptation Set（自适应子集）：一个Period由一个或者多个Adaptationset组成，一组可供切换的不同码率的码流组合成一个自适应子集。
  • Representation（码流）：每个Adaptation Set包含了一个或者多个Representation，每个Representation代表一路音频流或视频流。同一个Adaptation Set的多个Representation之间代表他们由同一路源流产生的不同的码率、分辨率、帧率等等的码流。
  • Segment（片段）：每个Representation包含多个Segment。与HLS类似，每个Segment代表一小段音频或视频数据，其中DASH Segment常用的载体是使用fmp4格式。

- 内容分析 -

MPD文件内容如下，其结构已经说明过了，但其中还有着许许多多的参数，有用于描述该DASH流特点的字段参数，如maxSegmentDuration、minBufferTime、minimumUpdatePeriod、publishTime、type等等。也有用于描述视频流信息的字段参数，如bandwidth、codecs、width、height等等。

代码语言：javascript复制
<?xml version="1.0" encoding="utf-8"?><MPD xmlns="urn:mpeg:dash:schema:mpd:2011" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns:xlink="http://www.w3.org/1999/xlink" xsi:schemaLocation="urn:mpeg:dash:schema:mpd:2011 DASH-MPD.xsd" xmlns:cenc="urn:mpeg:cenc:2013" profiles="urn:mpeg:dash:profile:isoff-on-demand:2011" availabilityStartTime="1970-01-01T00:00:00Z" id="Config part of url maybe?" maxSegmentDuration="PT8.334S" minBufferTime="PT4S" minimumUpdatePeriod="PT2S" publishTime="2021-10-14T16:15:30Z" type="dynamic" ><ProgramInformation><Title>Media Presentation Description from DASHI-IF live simulator</Title></ProgramInformation><Period id="p0" start="PT0S"><AdaptationSet contentType="video" mimeType="video/mp4" segmentAlignment="true" startWithSAP="1"><Representation bandwidth="1400000" codecs="avc1.42c016" id="dashTest_1400-video" width="1280" height="720" ><SegmentTemplate initialization="$RepresentationID$_init.m4s" media="$RepresentationID$_t$Time$.m4s" timescale="90000"><SegmentTimeline><S d="750060" t="147080528761140" /><S d="749970" t="147080529511200" /><S d="749970" t="147080530261170" /></SegmentTimeline></SegmentTemplate></Representation><Representation bandwidth="500000" codecs="avc1.42c016" id="dashTest_500-video" width="654" height="368" ><SegmentTemplate initialization="$RepresentationID$_init.m4s" media="$RepresentationID$_t$Time$.m4s" timescale="90000"><SegmentTimeline><S d="750060" t="147080528761140" /><S d="749970" t="147080529511200" /><S d="749970" t="147080530261170" /></SegmentTimeline></SegmentTemplate></Representation></AdaptationSet><AdaptationSet contentType="audio" lang="eng" mimeType="audio/mp4" segmentAlignment="true" startWithSAP="1"><Role schemeIdUri="urn:mpeg:dash:role:2011" value="main" /><Representation audioSamplingRate="48000" bandwidth="315057" codecs="mp4a.40.2" id="dashTest_500-audio"><SegmentTemplate initialization="$RepresentationID$_init.m4s" media="$RepresentationID$_t$Time$.m4s" timescale="48000" ><SegmentTimeline><S d="400032" t="78442948673280" /><S d="399984" t="78442949072640" /><S d="399984" t="78442949473008" /></SegmentTimeline></SegmentTemplate></Representation></AdaptationSet></Period></MPD>

这些字段参数众多，但是其中有两个较为关键的参数，用于控制播放器的行为，分别是minimumUpdatePeriod、minBufferTime。

  • minimumUpdatePeriod（MPD最低限度更新时间）：告诉播放器MPD内容更新间隔，播放器会根据此值来控制MPD轮询更新时间，其值过大会导致内容更新不及时导致卡顿。
  • minBufferTime（最小缓存时间）：播放器最小的缓存音视频时长，其值需要为最小的segment时长。@minBufferTime * @Representation.bandwidth表示能够持续播放的最少数据。（播放器会根据@minBufferTime * @Representation.bandwidth计算出起播的最小缓冲数据，当缓冲的数据大于@minBufferTime * @Representation.bandwidth才开始播放。）
Segment格式

Segment有三个XML格式，分别是BaseURL（单段表示）、SegmentList（段列表）和SegmentTemplate（段模板），其中BaseURL和SegmentList由于其设计的格式不适用于直播，所以直播一般只用SegmentTemplate。

SegmentTemplate支持两种模式，一种是$Number$模式，一种是$Time$模式，其中$Number$要求播放器的系统时钟和服务器系统时钟一致，如果不一致，将会导致播放失败或者内容延迟过大，因此常用的模式是$Time$模式。

SegmentTemplate的$Numbe$模式
代码语言：javascript复制
<MPD  availabilityStartTime="2021-10-01T00:00:00Z" ……省略><Period ……省略><AdaptationSet ……省略><Representation ……省略><SegmentTemplate timescale="90000" duration="180000" initialization="$RepresentationID$/init.mp4" media="$RepresentationID$/$Number$.m4s" startNumber="0"/></Representation></AdaptationSet>……省略</Period></MPD>

$Number$模式的格式如上所示，为了计算Segment的$Number$值，依赖播放器端当前系统时间以及availabilityStartTime、timescale、duration、startNumber字段，$Number$当前值计算规则为：((播放器端当前系统时间 - availabilityStartTime)/(duration/timescale)) startNumber。

根据计算规则可以了解到，如果播放器端系统时间和服务器存在过小/略小/过大会分别会导致无法计算/请求的不是最新分片/请求的是未来的分片等等问题。

SegmentTemplate的$Time$模式
代码语言：javascript复制
<MPD ……省略><Period ……省略><AdaptationSet ……省略><Representation ……省略><SegmentTemplate initialization="$RepresentationID$_init.m4s" media="$RepresentationID$_t$Time$.m4s" timescale="90000"><SegmentTimeline><S d="178470" t="147060849589200" /><S d="178470" t="147060849767670" /><S d="178380" t="147060849946140" /></SegmentTimeline></Representation></AdaptationSet>……省略</Period></MPD>

$Time$模式的格式如上所示，SegmentTimeline下每个S对应一个Segment。其分片的$Time$值就是S中的t值。不仅简单，且只需根据MPD内容即可算出每个分片文件名，不需要依赖播放器段系统时钟，因此$Time$模式更为常用。

- 协议工作流程 -

上面分析了DASH协议，接下来我们对该协议工作流程也做一个说明，主要是播放器针对DASH协议下载播放流程及其特性自适应多码率切换逻辑。

下载播放流程

由于DASH协议设计较为复杂，将音频流和视频流分成两路流，并且还将元信息独立出一个Initialization分片，所以播放器的下载播放流程比HLS复杂得多。我将其下载播放流程分为四步：

  1. 下载MPD文件，解析DASH相关信息；
  2. 下载视频的Initialization Segment和音频的Initialization Segment；
  3. 下载视频的第一个分片，下载音频的第一个分片；
  4. 当视频和音频的第一个分片都下载完，播放器内部再进行一些相关处理后，就可以开始播放出画面。后续就是不断轮询更新MPD文件和下载后续的音频和视频分片。

从播放器下载流程也可以发现，其需要5次HTTP请求下载，才能开始播放，对比FLV协议（1次HTTP请求）、HLS协议（2~3次HTTP请求）来说，有更多的下载次数，也导致其首帧耗时更长。

自适应多码率切换逻辑

上面分析了DASH协议的播放器下载流程，接下来我们继续分析一下DASH的自适应多码率切换逻辑。

DASH播放器会根据网络环境自动切换播放的码率，其码率的切换则是在同一个Adaptation Set不同Representation之间进行不断切换。当播放器根据分片下载耗时判断网络变好/变差时，会选取更高/更低的码率进行播放，并且重新下载其init分片。

为了保证播放器能够在不同码率之间平滑切换，同一个Adaptation Set不同Representation之间，同一位置Segment之间必须是相同起始时间和相同时长。

下面图分别在网络环境变差时由高码率切到低码率，和在网络环境变好时由低码率切到高码率的下载图。

↑网络环境变差时由高码率切到低码率↑

↑网络环境变差时由低码率切到高码率↑

下面介绍腾讯云直播系统关于DASH协议的功能实现以及在灰度验证中遇到的一些坑。

- 功能实现 -

在DASH协议的功能实现中，最重要的便是其多码率实现支持。另外腾讯云侧还支持其他一些特性，如DRM加密和SCTE35插入等等。

分布式转码多码率实现方案

由于转码对机器资源消耗较高，而多码率自适应需要对同一路流同时起多路不同码率的转码任务。为了保证转码资源能够更好均衡负载，则需要将不同的转码任务分配到不同转码机器上，即分布式转码。

针对分布式转码有两个关键问题需要解决。第一个是不同转码任务之间的切片位置对齐，第二个则是将多个转码任务合并为一个多码率的Manifest文件。

切片位置对齐

多码率自适应流分成多个转码任务调度到不同转码机器后，由于每个转码机器启动时间、获取到流的位置会有偏差，导致不同码率的流切出来的每个分片的起始位置是不对齐的，因此需要通过某种方式实现分布式转码之间切片位置对齐。

腾讯云实现的分布式转码对齐的方法则是通过在收流服务器针对原始流每隔一段时间打一个标记。当转码遇到该标记时就切一次片，从而实现分布式转码之间的切片位置对齐。

合并生成多码率的Manifest文件

由于每个转码都在各个的转码机器上进行切片，因此也无法直接生成一个多码率的Manifest索引文件。

我们的解决办法则是再创建一个转封装任务。该任务不需要转码，只需要将多个转码任务生成的单码率DASH流聚合，重新合并为一个多码率Manifest索引文件，因此该任务的资源消耗是很低的。

其他特性支持

腾讯云在实现DASH协议同时，也支持了DASH协议的一些特性，如DRM加密和SCTE35插入等等，下面我们也对这些特性做简单的介绍。

DRM加密

DRM加密是对音视频数据的主要保护手段。通过DRM将音视频内容进行加密，让音视频数据即使在网络上传输或客户端播放时被保存了下来，也会因为没有解密秘钥，而无法进行解密播放。

主要的DRM加密协议有Fairplay、Widevine和PlayReady。其中DASH协议支持Widevine和PlayReady，而Fairplay是仅用于Apple设备上针对HLS协议的DRM加密方式。

DRM加密逻辑大致是通过对音视频流进行DRM加密，再在DASH的MPD描述文件上标记上DRM加密信息，从而生成DASH的DRM加密音视频文件。

在播放时先通过播放证书请求地址，请求播放证书获取到其中的解密秘钥，系统再进行解密播放。其中解密秘钥由系统进行保护，因此无法被盗取。且系统判断当前处于录制状态时，视频内容还会变成黑屏，无法进行有效录制。

SCTE-35广告插入

DASH协议还支持通过SCTE-35来实现广告插入。其中一种实现方式是客户在推流时采用RTP等推流协议，在MPEG-TS源流中添加SCTE标记。

当DASH转码服务器遇到SCTE-35标记时，会解析其内容并利用DASH的多Period特性，根据广告开始时间和结束时间单独分割出一个Period，并在该Period填上SCTE-35信息。当播放器在播放过程中解析SCTE-35标记后，会根据SCTE-35信息跳转播放广告，从而实现广告插入。

灰度验证

在DASH协议的播放灰度验证中，由于DASH对比FLV、HLS来说其发展时间相对较短，在多个DASH播放器之间也存在着一些兼容性问题。

DASH常用的播放器有dash.js（Web端）、Shaka Player（Web端）、Exo Player（Android端）等等。我们在各个播放器都遇到了不少播放异常问题，这里主要介绍一下在Shaka Player和Exo Player播放器中踩过的一些坑。

Shaka Player兼容问题

在使用web端Shaka player播放器进行长时间播放测试时，经常不定时出现卡住的现象，且出现卡住间隔不固定，需要重载播放器才能恢复。而在其他播放器中没有该现象，从而确认这是针对Shaka player播放器的一个兼容性问题。

导致卡住的可能性有很多，但其中更多的和音视频dts/pts相关。根据对MPD文件内容、播放器日志和播放器源码，以及视频流和音视频流之间的dts/pts计算对比测试分析，最终定位到导致卡住的问题。

DASH协议对比其他播放协议有一个不同点，音频流和视频流需要单独分成两路流进行切片和下载，播放器再将同时间段的视频分片和音频分片进行时钟对齐与播放。由于视频流和音频流是两路单独的流，其dts/pts也是无法完全一致的。而shaka player对同时间段的视频分片和音频分片之间起始dts/pts有着较为严格的间隔控制，要求其间隔在20ms以内（实际测试最好在10ms以内）。否则就有可能出现卡住现象。

触发该现象的原因是因为大多数直播流推上来的视频流和音频流数据并不是相互交织的，是一小段视频数据、一小段音频数据、一小段视频数据、一小段音频数据这样推上来。从而导致切片在同一个位置切出来的视频分片和音频分片之间的起始dts/pts存在较大的偏差。

解决办法就是在进行视频和音频单独切片之前，先对音视频流进行交织处理，让dts/pts有序排列起来，从而达到在同一个位置切出来的视频分片和音频分片之间的dts/pts间隔极小（10ms以内）。

Exo Player兼容问题

在使用andorid端Exo Player播放器进行播放时，也出现过一个奇怪的现象，就是在播放过程中会出现花屏并不可恢复，同样也是重载播放器后就正常，其他播放器中没有该现象，确认这是针对Exo Player播放器的一个兼容性问题。

出现花屏代表播放器解码异常了，但由于其他播放器是正常的，说明视频源本身没有问题。一开始根据MPD文件内容、播放器日志和播放器源码，以及视频元信息对比测试分析，并没有找到导致花屏的原因。

继而尝试进行抓包分析MPD，在出现花屏的时候对比两个MPD的内容发现此刻不同码率的Representation顺序变换了。因此在此基础上尝试固定Representation顺序，花屏现象没有再复现，从而确认是Representation顺序变化导致。

实际上每个Representation有各自的唯一标记，即使Representation顺序变化了，也不应该出现花屏，这个是Exo Player一个解析异常问题。

技术的实现最重要的是能将其应用在实际业务中。而在实际业务应用中，往往需要针对业务需求/客户需求做一定的优化。

对于客户来说，其关注点主要是QoS优化和成本优化。因此在实践中，主要也是在这两方面上进行优化与创新。

- QoS优化 -

在质量优化中，根据客户需求，我们优化点主要是集中在首帧耗时和内容质量上。

首帧耗时

在首帧耗时的优化上，我们经过多方面的优化，使得首帧平均耗时大大降低，由原来的600ms 降到了200ms 。其中的优化项总结了主要以下几点，分别是2分片起播、低码率优先、减少下载次数。

2分片起播

在主播推流后，假设配置的是3个分片数，每个分片2s。需要等待6s以上才能生成第一个MPD文件并下发，因此刚进来的观众需要等待主播推流6s以上才能播放。

针对该场景，我们调整了转码切片，两个分片后就生成MPD下发，并保持后续还是3个分片数，将6s 起播时间优化到4s 。

低码率优先

大部分播放器默认是选取Manifest文件（MPD）排在第一位的视频流，如果多码率的视频流的码率从高到低排序，则会导致播放器默认选取最高码率的流进行播放。

高码率的流意味着分片文件更大，下载耗时更长，从而导致首帧耗时更高。因此将视频流码率从低到高排序，让播放器初始选取低码率文件下载播放，可以降低首帧耗时。但这种做法也会导致每次起播的画面都是低清画面，对用户体验也会有一定的影响，因此需要在这其中做好权衡。

减少下载次数

针对DASH协议，其需要经过5次请求后才能开始播放，对首帧耗时有较大的影响。客户端虽然可以通过并发下载音视频的Initialization和音视频分片进行优化，减少网络IO等待耗时，但仍然需要5次HTTP请求后才能开始播放。

而在协议侧（服务端）有一个优化方式，去掉Initialize Segment（即使用Self Initialize Segment），将PPS/SPS等信息保存到每一个Segment中，则可以减少两次HTTP下载，有效优化首帧耗时。

内容质量

对于客户来说，视频内容质量是业务的关键指标之一。不过视频质量更多的是受其码率、帧率、分辨率、编码格式等影响，和转封装/传输协议关系不大。但是在实际应用中，受播放器等影响，也有需要优化的场景。

帧间隔平滑

在高帧率转低帧率的情况下，在播放体验对比中发现同样帧率的流，由高帧率转低帧率的流看起来会流畅性会差一些。

经过分析发现，常见的高帧率转低帧率其实是粗暴按一定比例丢弃一定帧数，所以导致每帧间隔有些偏大有些偏小。比如25帧转15帧的情况下，原本帧间隔是40ms，转码后成了部分是40ms，部分是80ms。对比平滑的15帧间隔66ms，两帧之间相差80ms导致看起来有更加明显的卡顿感。

因此在高帧率转低帧率的情况下另外做了一个优化，即平滑每个帧间隔，使得即使在高帧率转低帧率的情况下，每帧间隔是固定且最小，让低帧率流播放起来会更加流畅一些。

- 成本优化 -

成本是每个客户、厂商都会关注的一个重点，而DASH的成本主要集中在其转码成本中，因此转码的成本优化也是一个优化重点。

针对客户需求，我们做了几个优化调整，分别是多码率转码动态启停、动态转码档位、原画档位。

多码率转码动态启停

初期实现DASH转码时，由于设计上的限制，需要在推流时便启动多码率转码，并且即使无人观看时也需要保持转码。这种在一些流数较少且需要低首帧耗时的场景下是有利的。但在流数量较多且更注重成本的场景下，这种方式是无法接受的。

针对这个情况，我们实现了在拉流时才启动多码率转码并在无人观看时停止转码。但由于转码是分布式的，且无法单独开始/停止某一个DASH转码任务，否则会将影响到多码率DASH的生成。需要将每个转码任务统一开始/停止。

实现统一开始较为简单，在有用户拉流时则触发全部转码任务的启动即可。但统一停止则需要一个契机，这里利用了上面多码率合并中的转封装任务。当一段时间无人请求触发转封装任务，便认为需要停止转码，通知所有转码任务停止转码，实现了每一个转码任务的统一停止。

动态转码档位

在实现初期，多码率DASH在转码启动时需要将全部转码任务启动。

假设有高清、标清、流畅三种转码档位。即使推流端推的是标清流，也会产生高清、标清、流畅三种转码任务。但由于源流是标清，即使转为高清也不会有任何画质上的优化。因此设计了根据推流端的码率大小，动态启动多种转码流，从而实现不会启动高于源流的转码任务，节省了转码成本。

原画档位

在转码成本优化上，还有一个更加强硬的优化手段，则是将原画当做DASH多码率其中一路流。但这里是一个比较复杂优化。由于DASH多码率需要每个分片的起始位置保持一致，因此需要在同一个位置切片。但又因为原画不能进行转码，所以对齐问题便是一个难点。

其实解决思路也不难，就是将标记切片位置打在原画的每一个I帧上。这样原画不进行转码也能够分片，而低码率的转码任务也能和原画在同一个位置进行切片。但在实现中遇到了一些问题，一开始我们采用DTS作为分片序号，发现原画带B帧的情况下，原画和转码流的DTS是无法进行对齐的，从而调整了PTS作为分片序号。

当然，原画档位还是有一些使用限制的，如推流需要保证I帧间隔相差不大并且每个I帧间隔大小需要适中等等。否则前者会导致部分播放器的兼容性问题，后者则是会导致每个分片时长过小或者过大。

下面是最终优化后的MPD文件内容以及直播效果截图。

  • 推了一路3000码率、30帧、1920x1080分辨率的原画流，输出DASH多码率为原画和1500码率档位（25帧、1280x720分辨率）；
  • 包含了许多优化效果。如DASH多码率分别是原画 1500码率转码流、码率顺序从低到高、拉流才启动转码、2分片起播等等；
  • 在实际播放体验中，30帧转25帧经过帧间隔平滑后，1500码率档位播放效果也有较好的流畅度体验。
代码语言：javascript复制
<?xml version="1.0" encoding="utf-8"?><MPD xmlns="urn:mpeg:dash:schema:mpd:2011" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns:xlink="http://www.w3.org/1999/xlink" xsi:schemaLocation="urn:mpeg:dash:schema:mpd:2011 DASH-MPD.xsd" xmlns:cenc="urn:mpeg:cenc:2013" profiles="urn:mpeg:dash:profile:isoff-on-demand:2011" availabilityStartTime="1970-01-01T00:00:00Z" id="Config part of url maybe?" maxSegmentDuration="PT2S" minBufferTime="PT4S" minimumUpdatePeriod="PT2S" publishTime="2021-10-21T14:39:42Z" type="dynamic" ><ProgramInformation><Title>Media Presentation Description from DASHI-IF live simulator</Title></ProgramInformation><Period id="p0" start="PT0S"><AdaptationSet contentType="video" mimeType="video/mp4" segmentAlignment="true" startWithSAP="1"><Representation bandwidth="1500000" codecs="avc1.42c016" id="dashTest_1500-video" width="1280" height="720" ><SegmentTemplate media="$RepresentationID$_t$Time$.m4s" timescale="90000"><SegmentTimeline><S d="180000" t="147134445524100" /><S d="140940" t="147134445704100" /><S d="180000" t="147134445845040" /></SegmentTimeline></SegmentTemplate></Representation><Representation bandwidth="3000000" codecs="avc1.42c016" id="dashTest_3000-video" width="1920" height="1080" ><SegmentTemplate media="$RepresentationID$_t$Time$.m4s" timescale="90000"><SegmentTimeline><S d="180000" t="147134445524100" /><S d="140940" t="147134445704100" /><S d="180000" t="147134445845040" /></SegmentTimeline></SegmentTemplate></Representation></AdaptationSet><AdaptationSet contentType="audio" lang="eng" mimeType="audio/mp4" segmentAlignment="true" startWithSAP="1"><Role schemeIdUri="urn:mpeg:dash:role:2011" value="main" /><Representation audioSamplingRate="44100" bandwidth="155248" codecs="mp4a.40.2" id="dashTest_1500-audio"><SegmentTemplate media="$RepresentationID$_t$Time$.m4s" timescale="44100" ><SegmentTimeline><S d="88200" t="72095878307647" /><S d="69061" t="72095878395715" /><S d="88200" t="72095878464290" /></SegmentTimeline></SegmentTemplate></Representation></AdaptationSet></Period></MPD>

目前，腾讯云海外主打OTT行业的Stream系列产品已全面支持DASH协议，并在实践和应用中获得了不错的反馈。

Stream系列是腾讯云海外主打OTT行业或者PGC生态的产品，比如StreamLive聚焦于视频输入、转码、转封装、DRM等视频处理能力，视频处理、支持协议/格式等能力相较标准直播更丰富，并特别针对海外客户新增了DASH协议支持，在使用上更符合海外用户的习惯。而且StreamLive专门针对OTT行业设计，做了大量的处理优化工作，支持7*24小时的稳定直播实时处理。

StreamLive对标AWS的MediaLive。您可以独立使用MediaLive，也可以配套其他腾讯云媒体服务产品联合使用，比如通过MediaLive MediaPackage CDN的方式，也可以实现标准直播的一体化方案，方式更加灵活。

腾讯云音视频在音视频领域已有超过21年的技术积累，持续支持国内90%的音视频客户实现云上创新，独家具备 RT-ONE™ 全球网络，在此基础上，构建了业界最完整的 PaaS 产品家族，并以 All in One SDK 的创新方式为客户服务。腾讯云音视频为全真互联网时代，提供坚实的数字化助力。

http 视频处理

0 人点赞