CN113285947B - 一种hls直播和组播直播接续的方法和装置 - Google Patents

Abstract

本发明涉及网络视频领域，特别是涉及一种HLS直播和组播直播接续的方法和装置。主要包括：发送端由HLS直播源获取距当前直播时间点最近的ts分片；发送端将获取到的ts分片按照组播直播要求生成组播包发出；接收端获取组播包，建立本地索引文件，将组播包还原为本地ts分片；播放终端使用还原后的本地ts分片进行直播。本发明不修改或扩展HLS规范，仅有的扩展信息在发送端和接收端之间进行数据拆分和整合，使用现有组播传输中常用手段，对HLS直播源和播放终端的兼容性好。同时也解决了现有技术HLS直播转组播直播后，组播直播一旦因故障出现异常，无法再次切换回HLS直播，导致直播中断的问题。

Description

一种HLS直播和组播直播接续的方法和装置

【技术领域】

本发明涉及网络视频领域，特别是涉及一种HLS直播和组播直播接续的方法和装置。

【背景技术】

内容分发网络(Content Delivery Network，简写为CDN)是构建在现有网络基础之上的智能虚拟网络，依靠部署在各地的边缘服务器，通过平台的负载均衡、内容分发、调度等功能模块，使用户就近获取所需内容，降低网络拥塞，提高用户访问响应速度和命中率。CDN本身并不对视频内容进行修改。原有的CDN视频提供直播服务时，用户数据报协议(User Datagram Protocol，简写为UDP)组播发送是最常见的形式之一，广泛适用于机顶盒、PC等各类型终端。

基于HTTP的自适应码率流媒体传输协议(HTTP Live Streaming，简写为HLS)是Apple的动态码率自适应技术。主要用于PC和Apple终端的音视频服务。包括一个m3u8格式的HLS索引文件和ts(Transport Stream)媒体分片文件，在需要加密的从场合，还包含key加密串文件。

组播直播是传统数字视频广播(Digital Video Broadcasting，简写为DVB)视频直播的传输形式，传输内容为ts视频流，通常用实时传输协议(Real-time TransportProtocol,简写为RTP)封装，并由发送端控制视频速率通过组播方式，向终端侧广播发送直播。

随着视频业务需求的不断增长，HLS直播随着OTT(Over The Top)业务的普及，HLS直播采用单播传输总体带宽的开销相对于组播劣势十分明显。HLS直播与组播直播由于设计要求的不同，现有技术实现两者的切换要么面临过大的起播延迟，要么需要扩展HLS协议，同时现有方案都没有妥善处理组播直播异常包括断流、抖动时，由组播直播切换回HLS直播的情况。本发明就是基于CDN视频技术，通过CDN边缘节点与HLS直播源配合，实现一种HLS直播和组播直播之间可以无缝切换接续的方法。

鉴于此，如何克服现有技术所存在的缺陷，解决HLS直播和组播间切换的接续问题，是本技术领域待解决的问题。

【发明内容】

针对现有技术的以上缺陷或改进需求，本发明解决了现有HLS和组播切换时起播慢、兼容性差、无法双向切换等问题。

本发明实施例采用如下技术方案：

第一方面，本发明提供了一种HLS直播和组播直播接续的方法，具体为：发送端由HLS直播源获取距当前直播时间点最近的ts分片；发送端将获取到的ts分片按照组播直播要求生成组播包发出；接收端获取组播包，建立本地索引文件，将组播包还原为本地ts分片；播放终端使用还原后的本地ts分片进行直播。

优选的，发送端将ts分片按照组播直播要求生成组播包发出，具体包括：将ts分片按照ts文件格式要求分割为ts包；将至少一个ts包封装为RTP包；在封装后的RTP包中添加与ts分片相关的扩展信息，生成组播包，其中，扩展信息包括ts分片文件名称、ts分片文件大小和每个ts包在原ts分片文件中对应的位置；使用组播RTP形式发送封装后的组播包。

优选的，接收端将组播包还原为本地ts分片，具体包括：由HLS直播源首次被播放终端访问开始，接收端持续从组播直播接收封装后的组播包；根据组播包中封装的扩展信息，将组播包还原为对应名称的ts分片；直至不再有终端访问该直播为止。

优选的，当需要使用ts分片中的数据，但还原过程未完成时，根据原始索引文件中的ts分片URL信息主动从直播源通过单播拉取ts分片。

优选的，建立本地索引文件，具体包括：获取直播源中的原始索引文件，将原始索引文件的本地副本作为本地索引文件；按照组播包中的扩展信息，向本地索引文件中加入组播数据；根据组播包的扩展信息中的ts分片文件名称查找对应的ts分片，将查找到的ts分片的前一个ts分片或当前ts分片作为定位ts分片；根据定位ts分片修改本地索引文件的ts分片列表；当原始索引文件中ts分片的URL包含一级域名时，将ts分片的URL修改为接收端地址。

优选的，建立本地索引文件，还包括：若未找到与扩展信息中ts分片文件名称一致的ts分片，或ts分片为本地索引文件中ts分片列表中的首个分片，将本地索引文件中最末尾的分片作为定位ts分片。

优选的，建立本地索引文件，还包括：确定本地索引文件更新等待时长，获取当前时间与本地索引文件上次更新的时间差；获取本地索引文件首次创建信息或上次更新信息；从本地索引文件中的定位ts分片向下查找ts分片，直至ts分片时长总和大于时间差，将查找到的最后一个ts分片作为新的定位ts分片。

优选的，确定本地索引文件更新等待时长，具体包括：首次更新前，根据本地索引文件中指定最大的媒体段时间长和指定每个媒体段的持续时间获取更新等待时长；每次更新后，根据本地索引文件中指定最大的媒体段时间长和查找到的ts分片总时长获取更新等待时长。

优选的，从本地索引文件中的定位ts分片向下查找ts分片，还包括：若定位ts分片丢失，根据当前组播直播携带的扩展信息中的定位ts分片的文件名称，在本地索引文件的ts分片列表中查找与定位ts分片的文件名称相同的ts分片；若查找到了同名的ts分片，将该分片作为定位ts分片；若未找到同名的ts分片，将本地索引文件ts分片列表末尾的ts分片作为定位ts分片。

另一方面，本发明提供了一种HLS直播和组播直播接续的装置，具体为：包括发送设备1和接收设备2；发送设备1接近HLS直播源3，接收设备2接近播放终端4，发送设备1、接收设备2、HLS直播源3和播放终端4之间分别通过网络信号连接；发送设备1和接收设备2分别包括至少一个处理器和存储器，所述至少一个处理器和存储器之间通过数据总线连接，所述存储器存储能被所述至少一个处理器执行的指令，所述指令在被所述处理器执行后，用于完成第一方面提供的HLS直播和组播直播接续的方法

与现有技术相比，本发明实施例的有益效果在于：本发明通过将ts分片封装为组播包，并在接收端通过保存在接收端的本地索引文件重新恢复ts分片，不修改或扩展HLS规范，仅有的扩展信息在发送端和接收端之间进行数据拆分和整合，使用现有组播传输中常用手段，对HLS直播源和播放终端的兼容性好。同时，本发明组播直播和HLS直播之间可以无缝接续，从而解决了现有技术组播直播转HLS直播在起播阶段需较长时间缓冲的问题，同时也解决了现有技术HLS直播转组播直播后，组播直播一旦因故障出现异常，无法再次切换回HLS直播，导致直播中断的问题。

【附图说明】

为了更清楚地说明本发明实施例的技术方案，下面将对本发明实施例中所需要使用的附图作简单地介绍。显而易见地，下面所描述的附图仅仅是本发明的一些实施例，对于本领域普通技术人员来讲，在不付出创造性劳动的前提下，还可以根据这些附图获得其他的附图。

图1为本发明实施例提供的一种HLS直播和组播直播接续的方法流程图；

图2为本发明实施例提供的另一种HLS直播和组播直播接续的方法流程图；

图3为本发明实施例提供的另一种HLS直播和组播直播接续的方法流程图；

图4为本发明实施例提供的另一种HLS直播和组播直播接续的方法流程图；

图5为本发明实施例提供的一种HLS直播和组播直播接续的装置结构示意图；

图6为本发明实施例提供的另一种HLS直播和组播直播接续的装置结构示意图；

其中，附图标记如下：

21：处理器；22：存储器。

【具体实施方式】

为了使本发明的目的、技术方案及优点更加清楚明白，以下结合附图及实施例，对本发明进行进一步详细说明。应当理解，此处所描述的具体实施例仅用以解释本发明，并不用于限定本发明。

本发明是一种特定功能系统的体系结构，因此在具体实施例中主要说明各结构模组的功能逻辑关系，并不对具体软件和硬件实施方式做限定。

此外，下面所描述的本发明各个实施方式中所涉及到的技术特征只要彼此之间未构成冲突就可以相互组合。下面就参考附图和实施例结合来详细说明本发明。

实施例1：

现有的HLS直播和组播的切换方案中，采用单纯协议转换组播发送，终端侧还原数据方法。组播数据在临近终端侧重新依据影片切片，切片分割位置不同，无法支持平滑接续。另一方面，组播还原为HLS直播的功能多布设在视频终端侧，而视频终端侧多为移动设备或嵌入式设备，性能和资源有限，无法支持全部直播频道的提前缓存。而组播兼顾公平性对所有终端流速一致，纯粹组播数据无法满足单路HLS协议起播缓冲的要求，起播非常迟缓。通过，现有的HLS直播中，ts分片以“.ts”格式的文件(本实施例中简称为ts文件)进行保存和使用，ts文件按关键帧的周期切片，每个ts分片的时长不均匀，还会因为组播传输抖动等原因易造成数据还原不及时，不同终端缓冲抗抖动能力不同，单纯组播还原HLS数据易出现卡顿。在本实施例中，为了解决上述问题，提供了一种支持平滑接续，可依靠单播回源的高速率保障直播平稳。在本实施例提供的实施方式中，ts分片可以直接由HLS直播源传输至接收端，也可以经由发送端封装为RTP包再由组播通道传输至接收端，为了充分利用组播通道的带宽优势，接收端首选使用组播通道传输的ts分片，在组播通道的ts分片无法满足使用时，则直接由HLS直播源获取需要的ts分片。

如图1所示，本发明实施例提供的HLS直播和组播直播接续的方法具体步骤如下：

步骤101：发送端由直播源获取最近的HLS直播源最末尾的ts分片。

在HLS直播中，视频文件以ts分片的形式传输及播放，在组播直播中，视频文件以RTP包的形式传输。为了使HLS能够和组播互相转换，接收HLS直播流转发为组播直播时，由直播源获得的数据，不直接按照HLS直播默认要求缓冲几个分片(HLS规范推荐为3个分片)，而是直接选择最末尾ts分片开始，将该文件按组播直播要求分包发出。

为了支持HLS回源，在HLS直播源的发送端必须布设有HLS直播回源服务器对HLS直播源进行回源管理。具体的，若直播的内容源本身就是HLS直播源，可直接选择内容源作为HLS直播回源服务器。若内容源非HLS源，则需布设HLS直播回源服务器，通过HLS直播回源服务器进行内容转换，将原内容源的转换为HLS直播源。

进一步的，按照HLS规范，在起播之前，需要缓冲3个ts分片。在现有的HLS直播应用中，为了保证稳定性，一般缓冲7-11个ts分片。本实施例的方案中，由于传输延时、RTP包的解析和ts分片的还原需要消耗一定时间，还可能需要对ts分片列表进行裁剪，还需要有至少2个ts分片的冗余。在本实施例中，为了确保HLS直播源能够提供足够的缓冲，若HLS直播源中原始索引文件提供的ts分片列表小于5个分片长度，也需要另外布设HLS直播回源服务器，回源服务器能够作为代理缓存提供更多的缓冲ts分片。在设置了HLS直播回源服务器的情况下，发送端直接从HLS直播回源服务器获取数据，在组播通道无法及时获取数据的情况下，接收端也直接从HLS直播回源服务器获取数据。

步骤102：将ts分片按照组播直播要求生成组播包发出。

获取直播源的ts分片后，需要将ts分片按照组播视频源的要求，分割并封装

具体的，如图2所示，可以使用以下步骤将ts分片生成组播包。

步骤201：将ts分片按照ts文件格式要求分割为ts包。

由HLS直播源获取到ts分片后，由于ts分片内容较大，而每个RTP包的容量有限，因此不能直接进行封包传输，而是需要先将每个ts分片分割为一个或多个ts包，再分别进行封包传输。具体的，将ts分片通过URL进行下载，按ts文件头中的特征字符同步定位后，按照ts文件的格式要求将文件分割为标准大小的ts包。

步骤202：将至少一个ts包封装为RTP包。

将ts分片分割为ts包后，即可按照RTP协议的要求进行封装。每个RTP包中封装的ts包数量受RTP包头和组播传输最大传输单元值限制，通常数量为6-7个。

步骤203：在封装后的RTP包中添加与ts分片文件相关的扩展信息，生成组播包。

播放终端进行直播时，需要使用完整的ts分片，而本实施例中，为了通过组播通道对ts分片进行传输，将ts分片被分割为ts包，并封装为RTP包，因此，在接收端接收到RTP包后，还需要将RTP包进行解封，取出其中的ts包，还原为ts分片。为了进行RTP传输，并能够在接收端对ts分片进行还原，还需要在RTP包中添加与ts分片还原相关的扩展信息。具体的，扩展信息中包含的特征字段有：ts分片文件名称，ts分片文件大小，每个ts包在原ts分片文件中对应的位置(即当前ts包的文件头相对于原ts分片文件头的偏移量)。扩展信息可以根据需要，选择在RTP包中的携带方式，例如：写入RTP包头的扩展字段，后添加ts无效包(PID＝0x1FFF)。为了便于进行解析，优选使用RTP报头的扩展字段进行携带。

步骤204：使用组播RTP形式发送封装后的组播包。

对ts分片分割并封装为RTP组播包后，HLS直播源的数据即可直接使用组播的方式进行传输，扩展部分全部在组播数据中，仅仅是借用组播通道传递信息，扩展信息仅在系统内部使用，不会对终端产生影响。

通过步骤201-步骤204，可以方便的将HLS直播使用的ts分片数据转换为组播使用的RTP组播包，使得HLS直播源能够直接扩展支持组播，通过组播减少带宽占用，而且在播放终端可以直接使用ts分片进行播放，不需要额外的设备或转换模块，多终端支持性能更好。

步骤103：获取组播包，建立本地索引文件，将组播包还原为本地ts分片。

使用组播方式对直播源数据进行传输后，直播源的ts文件被分割为ts分片，在进行播放时，还需要将ts分片按照原ts文件中的顺序进行还原，以保证播放顺序正确。

为了保证用户观看时能够持续接收到直播源的数据，需要持续发送和接收组播包数据。由HLS直播源首次被播放终端访问开始，持续从组播直播接收封装后的组播包；根据组播包中封装的扩展信息，将组播包还原为对应名称的ts分片；直至不再有终端访问该直播为止。在现有的技术方案中，需要先缓冲30-40秒数据。在本实施例中，播放终端可以直接使用接收端还原得到的ts分片进行播放，因此可以按需请求服务，当播放终端用户请求时才创建服务，用户结束请求即停止服务，减少了硬件资源和带宽的占用。

另一方面，在本实施例的方案中，接收端一般通过发送端提供的RTP包还原出需要播放的ts分片，在组播通道获取的ts分片无法满足播放需要时，接收端还需要从HLS直播源直接获取ts分片。根据HLS直播的机制，需要使用HLS索引文件管理ts分片的播放。在本实施例中，需要根据ts分片接收情况，将由发送端和HLS直播源获取到的ts分片都使用HLS索引文件的ts分片列表进行管理，HLS索引文件通常以m3u8格式存放。为了方便接收端使用，需要将HLS直播源上的原始索引文件拉取至接收端本地，并根据ts分片的接收情况生成本地索引文件进行使用。具体的，如图3所示，可以根据以下步骤生成本地索引文件。

步骤301：获取直播源中的原始索引文件，将原始索引文件的本地副本作为本地索引文件。

在有用户请求该频道直播时，若接收端不存在本地索引文件，从HLS直播回源服务器通过HTTP方式拉取原始索引文件。在后续步骤中，还需要按照频道对应信息，在拉取到的原始索引文件中加入组播获取发送端推送的组播数据等信息，并进行定位查找等操作。本实施例中，为了便于播放端使用对HLS索引文件进行使用，获取到直播源中的原始索引文件后，先在播放端本地建立原始索引文件的副本作为本地索引文件，再在后续步骤中进一步进行修改和使用。

步骤302：按照组播包中的扩展信息，向本地索引文件中加入组播数据。

解析通过HTTP获取的原始索引文件，并解析通过组播获取的组播包中的扩展信息。组播包中的扩展信息即上述步骤203中向组播包中添加的ts分片还原相关的特征字段，根据特征字段的值将ts分片加入ts分片列表中。

步骤303：根据组播包的扩展信息中的文件名称获取对应的定位ts分片。

本实施例中，接收端可以直接由HLS直播源获取ts分片，也可以通过组播RTP包的方式获取ts分片，由于HLS传输和组播传输的速率不一致，因此，由两种方式获取到的ts分片在时间轴上无法保证完全同步，为了确保播放终端能够获取到时间正确的ts分片，本实施例中将与当前直播点时间最近的前一个ts分片作为定位ts分片，通过定位ts分片进行时间定位。获得ts分片的特征字段后，可以根据特征字段中ts分片的文件名称，在本地索引文件中查找组播包扩展信息对应的文件名称对应的ts分片文件名称，以及ts分片的对应位置对索引文件中的ts分片列表进行查找，以确定ts定位分片在本地索引文件的ts分片列表中的位置。

在本实施例使用时的不同场景中，需要根据具体情况确定定位ts分片的位置。

(1)场景一：在正常的使用场景中，由于ts分片在组播通道中以ts包的形式发送，当某个ts分片对应的ts包未全部接收，或ts分片未还原完毕时，本地索引文件的ts分片列表中包含ts分片文件名称对应的ts分片，且该ts分片不在ts分片列表的首部和尾部。此时，由于特征字段中的ts文件名称对应的ts分片未还原完毕，播放终端无法使用，因此，选择文件名称对应的ts分片前面的ts分片作为定位ts分片。

(2)场景二：在另一种正常的使用场景中，某个ts分片对应的ts包全部接收完毕且已还原为完整的ts分片，或接收端直接由HLS直播源获取ts分片，本地索引文件中包含ts分片文件名称对应的ts分片，且该ts分片在ts分片列表尾部。此时，可以使用定位ts文件名称对应的ts分片进行播放，则将该ts分片文件本身作为定位ts分片。

(3)场景三：当HLS直播源发生通信延迟或故障，HLS直播源无法向发送端或接收端传输ts分片，本地索引文件的ts分片列表中包含ts分片文件名称对应的ts分片，且该ts分片在ts分片列表的首部，使用ts分片列表最末尾的ts分片作为定位ts分片，使播放终端使用的ts分片与HLS直播源能够提供过的ts分片保持一致。

(4)场景四：当组播通道发送通信延迟或故障，接收端无法收到组播通道提供的RTP包，因此无法在更新本地索引文件时向ts分片列表中写入ts文件名称，本地索引文件中不存在对应ts分片名称。此时，仅能使用直接由HLS直播源获取到的ts分片，使用ts分片列表尾的ts分片为定位ts分片，在组播通道恢复后能够完成接续。

在不同的场景中，使用不同位置的ts分片作为定位ts分片，可以准确的定位播放终端需要使用的ts分片，避免因为HLS直播源和组播通道获取的ts分片不同步导致的播放错误。

步骤304：根据定位ts分片修改本地索引文件的ts分片列表。

获取到定位ts分片后，还需要裁剪修改原始索引文件内容，删除存储定位ts分片之后的ts分片列表信息。当定位ts分片为原始索引文件中最末尾的分片时，后续无分片，无需修改信息。

步骤305：当原始索引文件中ts分片的URL包含一级域名时，将ts分片的URL修改为接收端地址。

若原始索引文件中ts分片URL含一级域名，则需要同步修改为接收端的地址。进行裁剪和修改后，输出修改后的原始索引文件内容，作为本地索引文件。

通过步骤301-步骤305，可以在视频播放的接收端建立起保存在本地的原始HLS索引文件副本，并获取到播放端需使用的ts分片的在ts分片列表中的定位信息，后续步骤中，播放端可以根据索引和定位信息对ts文件进行本地还原，完成HLS直播。建立本地索引文件后，还需要将当前时间记录为本地索引时间首次更新时间，以便于后续更新时使用。

进一步的，在整个直播过程中，直播使用的ts分片会根据时间不断变化，并会不断通过组播包获取新的ts分片，因此，还需要对本地索引文件进行及时更新。具体的，如图4所示，可以通过以下步骤对本地索引文件进行更新。

步骤401：确定本地索引文件更新等待时长，获取当前时间与本地索引文件上次更新的时间差。

本地索引文件根据组播包中的扩展信息进行建立和更新，播放下一个组播包之前，需要根据新的组播包信息进行更新。在具体实施时，可以根据本地索引文件中的字段特征值获取等待时长D。

首次更新前，根据本地索引文件中指定最大的媒体段时间长和指定每个媒体段的持续时间获取更新等待时长。一个媒体段一般是一个ts分片，若ts分片的大小不均匀，也可能包含多个ts分片，媒体段的时间长需要固定且尽量均匀。本地索引文件根据指定媒体段时间长刷新进行。最大的媒体段时间长通过本地索引文件中的EXT-X-TARGETDURATION字段值获取，媒体段的持续时间由定位ts分片对应的EXTINF字段获取。EXT-X-TARGETDURATION值记作D1，存储定位ts分片对应的EXTINF时间值记作H，则本地索引文件更新等待时长为D＝MIN(D1，H)。

每次更新后，根据索引文件中指定最大的媒体段时间长和查找到的ts分片总时长获取更新等待时长。获取当前时间与本地索引文件前一次更新的时间差值，记作T。从定位ts分片向后，获取ts分片列表中所有分片时长之和SUM，直到分片时长大于等于T，或ts分片列表中所有ts分片的时长都已求和完成。设置新的本地索引文件更新等待时长D＝MIN(D1，SUM)。

步骤402：获取本地索引文件首次创建信息或上次更新信息。

ts分片播放更新时，需要再次由HLS直播回源服务器通过HTTP方式拉取原始索引文件，基于新的索引文件重新生成本地索引文件。解析新拉取的原始索引文件内容作，并根据新拉取的索引文件中的内容对ts分片进行索引。

步骤403：从本地索引文件中的定位ts分片向下查找ts分片，直至ts分片时长总和大于时间差，将查找到的最后一个ts分片作为新的定位ts分片。

获取更新等待时长后，将最后一个参与求和的ts分片记作新的定位ts分片，以便于下一次更新后使用，避免重复计算。本实施例提供的方案中，以媒体段时间长和待播放的ts分片时长总和之间较小的值作为更新时长，能够确保更新时长小于当前本地索引文件的ts分片列表中ts分片的总时长。同时，由于本地索引文件的ts分片列表中每一个ts分片都能获取到相应的分片时长，因此可以通过更新时间计算播放终端需要使用的ts分片，从而确定定位ts分片。根据本方案确定的定位ts分片，其之前有数个ts分片可以提供给播放终端使用，因此在更新前充分时间通过组播通道获取之后播放的ts分片，以保证播放的流畅性。

进一步的，对根据更新等待时长对索引文件进行刷新时，可能会出现因关键帧周期变化或HLS直播回源服务器延迟，导致在需要进行刷新时原始索引文件未更新的情况。此时，为了及时获取原始索引文件的最近更新内容对本地索引文件进行及时更新，需要减少等待时长，提高刷新频率。具体的，可以在将等待时长均分为多段，在每段均分后的等待时长到时间后进行一次刷新。刷新到原始索引文件更新后，停止刷新，恢复正常刷新频率。若超出正常更新等待时长后仍未刷新到原始索引文件的更新，需要进一步对为刷新到的原因进行判断，并根据具体情况进行异常处理或告警。

通过步骤401-步骤403，通过新的本地索引文件内容，对本地索引文件中的定位ts文件和更新时间进行了更新，使其符合当前的ts分片播放情况，能够确保ts分片播放流畅。

在本实施例的某些场景中，上述查找ts分片的过程中，可能出现ts分片丢失的情况。若未查找到与需要的ts分片文件名称相同的ts分片，表明需要的ts分片还未通过组播包传输至播放端，或组播数据未能及时还原ts分片。此时，接收端需要根据原始索引文件中的信息，获得需要的ts分片URL信息，并主动从HLS直播源通过单播快速拉取需要的ts分片，以避免ts分片不存在导致的播放卡顿或播放错误。

进一步的，若丢失的ts分片为定位ts分片，还需要进行进一步的重定位处理。

步骤501：根据当前组播直播携带的扩展信息中的定位文件名称，在本地索引文件的ts分片列表中查找与定位ts文件名称同名的ts分片。

对ts分片进行查找时，需要根据索引文件中的ts分片列表进行定位，在重定位时，也需要在ts分片列表中重新查找定位ts分片。

步骤502：若查找到了同名的ts分片，将该分片作为定位ts分片。

若当前ts分片文件名称在源本地索引文件中的ts分片列表中能查找到，则依照步骤303中相同的方法，根据扩展信息中的ts文件名称确定新的定位ts分片。

步骤503：若未找到同名的ts分片，将本地索引文件ts分片列表末尾的ts分片作为定位分片。

若ts分片文件名称在本地索引文件中的ts分片列表中未查找到，则不适用组播数据，由HLS直播源获取数据，并更新定位ts分片为本地索引文件ts分片列表末尾ts的ts分片。

通过步骤501-步骤503，完成了定位ts分片的重新查找，避免了定位ts分片丢失导致的播放错误。

步骤104：使用还原后的本地ts分片进行直播。

通过步骤101-步骤103，完成了对直播源ts文件的分片、组播传输和还原，通过组播方式对ts文件进行了传输，并在播放端根据索引文件生成了与直播源相同的ts文件播放源，完成上述过程后，即可使用还原后的本地ts文件作为直播源进行直播。

在某些具体场景中，由于传输速率、文件还原效率等原因，可能存在需要使用ts分片，但还原过程未完成的情况。此时，需要根据原始索引文件中的ts分片URL信息，主动从直播源通过单播拉取ts分片，并直接解析使用该ts分片进行播放，避免产生卡顿或播放错误。在具体实施中，由于，存在主动拉取ts分片的方案，因此会存在两种ts分片的获取途径：第一种是根据组播包进行还原的ts本地文件，第二种是单播HTTP从发送端回源的数据。面向播放器请求时，播放端优先提供组播经过还原的本地ts文件数据，仅在组播数据丢失或抖动延迟，造成临时访问不及时从源站HTTP拉取。

本实施例中提供的步骤101-步骤104中的技术方案，通过ts分片及封装，使ts分片从名称到实际内容100％确保回源，保证直播源与终端播放侧的ts文件保持一致，通过这种方式支持HLS播放中随时回源。技术方案中直接使用从直播源获取原始索引文件为基础，修改形成本地索引文件，对ts分片进行还原，未对HLS标准中m3u8索引规则做任何扩展，因此不需要额外的终端适配。扩展部分全部使用RTP扩展报头或RTP数据包封装在组播数据中，扩展字段少，仅涉及ts分片数据信息，且无需变更扩展HLS协议字段，仅仅是借用组播通道传递信息，扩展信息仅在系统内部使用，不会对终端产生影响。因此，本技术方案不需要HLS扩展支持组播，多终端支持性能更好，使用组播和回源双通道，在组播节约大量带宽的同时，保障播放抗抖动能力更强，并支持组播和单播双通道的相互切换。同时，还通过优选方案中单独拉取ts分片的方式，支持了终端侧索引文件的流速变化，可以在切换为组播数据后在组播异常时仍能无缝向单播回源。本实施例中的方案，在接收到首个组播包时即可开始播放，解决组播数据在转换为HLS直播时起播缓慢的问题。

实施例2：

在上述实施例1提供的HLS直播和组播直播接续的方法的基础上，本发明还提供了一种可用于实现上述方法的HLS直播和组播直播接续的装置，如图5所示，是本发明实施例的装置架构示意图。

装置主要包括发送设备1和接收设备2，发送设备1主要完成实施例1中步骤101-步骤102中的数据分割打包处理和发送任务，实施例1中的发送端功能可以由发送设备1提供，接收设备2主要完成实施例2中步骤103-步骤104中的数据接收还原和播放任务，实施例1中的接收端功能可以由接收设备2提供。发送设备1接近HLS直播源3，接收设备2接近播放终端4，发送设备1、接收设备2、HLS直播源3和播放终端4之间分别通过网络信号连接。在本实施例中，接近的含义是指网络拓扑上的近，使用该种网络拓扑结构，在网络传输上额外开销最小。

如图5所示，在本实施例的一个具体实施场景中，初始内容源为HLS直播，在网络拓扑接近直播源部署本发明发送端设备1，通过RTP封装形式的HLS转组播直播提供服务，网络拓扑边缘部署接收设备2接收组播直播。当组播数据断流时，切换回HLS直播为终端提供服务。该场景中，发送设备1位于CDN核心节点，靠近HLS直播源3。接收设备2位于CDN边缘节点，靠近用户播放终端4。

接收到用户终端的直播请求时，发送设备1首先根据步骤101，按HLS协议标准中提供的播放访问方式，获取原始索引文件。选择原始索引文件中ts分片列表最末尾的ts分片获取相应的ts文件。

然后根据步骤102，发送设备1将ts分片通过URL下载到内存，并将ts文件按ts文件头中的特征值同步定位后，分割为ts包。再将数个ts包进行RTP封装，ts包封装数量受RTP包头和组播传输MTU值限制，通常数量为6-7个。每个RTP包头部在其扩展字节部分，添加扩展信息。扩展信息包括当前RTP包中封装的ts包所归属的ts分片文件名称、ts分片文件大小、当前RTP包中的首个数据在ts分片文件中对应的位置等用于ts文件还原的信息。扩展信息的长度或无效包的个数可以在遵循RTP头拓展要求的前提下进行调整，使其长度足够存放所需扩展信息。例如，在某个实际场景中，某个RTP包的扩展信息如下：(1)ts分片文件大小(4字节)值为4027148，表示当前RTP包中封装的ts分片文件的大小；(2)偏移量(4字节)值为4026960，表示当前RTP包中的首个数据在ts分片文件中对应的位置用于ts文件还原的信息；(3)ts分片文件名称(40字节)：如文件名为“1600624780_0000126480_00000000190000000018.ts”的ts文件，在该字段中值为“1600624780000012648000000000190000000018”，该字段用于对ts分片文件进行查找。将ts分片封装为组播包后，发送设备1将最新的ts分片文件内容及扩展信息用组播RTP形式发送出去，发送过程遵循标准组播直播传输要求，如ISO/IEC TR13818系列,TR101190，传输要求包括且不限于流速控制、传输时延等通信规则，以保证组播包可以通过组播方式正确传输。

为了向接收设备2持续提供ts分片，发送设备1发送完最新的ts分片文件内容后，遵循HLS协议标准中直播访问的步骤，继续查询HLS直播源3是否有ts分片文件更新，并持续向接收设备2发送更新的ts文件。由发送设备1封装的组播包，还需要通过根据步骤103和步骤104，由接收设备2进行接收和还原。接收设备2进行接收时，首先需要按照一般的HLS直播和组播的需求进行配置。在实际使用时，接收设备2的配置过程可通过TR069协议客户端等外部程序，或管理员手动配置。配置内容主要包括HLS直播频道URL首次访问地址、HLS直播对应的组播直播的组播地址和端口等。通过配置，用户的播放终端访问HLS直播时，会被重定向到接收设备2上，获取到通过接收设备2还原后的ts文件进行播放。具体的，重定向过程可通过DNS重定向，或HTTP的301/302重定向实现，重定向后，播放终端4访问的HLS直播源地址，由原HLS直播源3，变化为了接收设备2的服务地址。

接收设备2接收到HLS直播请求后，立即加入组播直播，并根据步骤103获取组播包，同时从HLS直播源3获取原始索引文件，建立HLS索引文件的本地索引文件，根据本地索引文件将组播包中的ts分片还原为ts文件，并用还原后的ts文件响应播放终端4的HLS请求。在后续的直播过程中，接收设备2还需要持续接收组播包，并完成本地索引文件的更新和ts文件的还原，直至没有播放终端4请求直播。

在实际的直播过程中，由于发送设备1要从HLS直播源3拉取内容发送组播，并且组播时延普遍大于单播，因此，索引文件ts分片列表中保存的ts分片，可能与当前组播使用的视频时间不一致，需要对索引文件ts分片列表进行调整，使ts分片列表中当前需要播放的ts分片文件与组播当前需要播放的资源时间轴一致。因此，接收设备2收到的组播数据扩展信息后，还需要根据步骤301-步骤304，对本地索引文件中的ts分片列表进行修改，使本地索引文件ts分片列表缩短到与组播数据进度同步。

根据步骤104，播放终端4依照HLS规则请求ts文件时，首先根据本地索引文件判断需要播放的ts分配是否存在。若请求的ts文件存在于m3u8格式的本地索引文件的ts分片列表中，直接通过接收设备2将最新的本地索引文件响应给播放终端4，使用HLS规则调取需要的ts文件进行播放。若请求的ts文件不存在于本地索引文件的ts分片列表中，需要直接通过HTTP拉取组播包中的ts分片。拉取ts分片后，接收设备2还需判断对应内容的数据是否已经由组播包中的扩展数据还原成本地ts文件。若还原过程完成，则使用已恢复的本地ts分片反馈给播放终端4；若未还原完成，则立即使用HTTP方式从HLS直播源3拉取ts分片，并同时向播放终端4发送数据，以确保ts分片数据获取的及时性。在直接从HLS直播源3获取数据的情况下，接收设备2会停止将获取到的ts分片从组播包中还原，并丢弃未还原的部分，以避免重复获取。

通过本实施例提供的装置的上述工作过程，即可在不影响播放终端4的HLS访问逻辑的前提下，使用组播在骨干网传输HLS直播数据，从而节约直播的总体带宽消耗。

在本实施例的另一个实施场景中，原始直播为组播直播，为了使不支持组播直播的终端播放器能够观看HLS直播源的相关节目，可在网络拓扑接近HLS直播源3的位置部署发送设备1。此时，为了确保能够完成步骤101和步骤102中HLS规则要求的ts分割和封装，还需要在中心额外部署ffmpeg+nginx等外部组播切片工具辅助作为HLS直播源3使用。该场景下，可以通过简单的额外设备部署和配置，实现组播直播转HLS直播的切片和m3u8原始索引文件的创建。进行上述部署和配置后，在网络拓扑边缘部署的接收装置2即根据步骤103接收组播直播，再根据步骤104将接收到的组播包还原为HLS直播数据，为播放终端4提供服务。

本实施例中的发送设备1和接收设备2都包括一个或多个处理器21以及存储器22。其中，图6中以一个处理器21为例。处理器21和存储器22可以通过总线或者其他方式连接，图6中以通过总线连接为例。存储器22作为一种HLS直播和组播直播接续方法非易失性计算机可读存储介质，可用于存储非易失性软件程序、非易失性计算机可执行程序以及模块，如实施例1中的HLS直播和组播直播接续方法。处理器21通过运行存储在存储器22中的非易失性软件程序、指令以及模块，从而执行各种功能应用以及数据处理，即实现实施例1的HLS直播和组播直播接续的方法。存储器22可以包括高速随机存取存储器，还可以包括非易失性存储器，例如至少一个磁盘存储器件、闪存器件、或其他非易失性固态存储器件。在一些实施例中，存储器22可选包括相对于处理器21远程设置的存储器，这些远程存储器可以通过网络连接至处理器21。上述网络的实例包括但不限于互联网、企业内部网、局域网、移动通信网及其组合。程序指令/模块存储在存储器22中，当被一个或者多个处理器21执行时，执行上述实施例1中的HLS直播和组播直播接续的方法，例如，执行以上描述的图1-图4所示的各个步骤。本领域普通技术人员可以理解实施例的各种方法中的全部或部分步骤是可以通过程序来指令相关的硬件来完成，该程序可以存储于一计算机可读存储介质中，存储介质可以包括：只读存储器(Read Only Memory，简写为：ROM)、随机存取存储器(Random AccessMemory，简写为：RAM)、磁盘或光盘等。

通过实际测试可知，本实施例提供的HLS直播和组播直播接续的装置，在具体实施中，可以稳定平滑的衔接HLS直播和组播直播，并且可以在HLS直播和组播直播两个方向进行平滑衔接双向切换。首先，在播放终端4上，HLS直播流程的控制方式无变化，播放终端4无需专门进行适配，终端适应性更强，使用更方便。其次，使用本装置的情况下，HLS直播和组播直播切换时，可以直接根据索引文件中的定位ts分片查找到需要播放的ts分片，对接收到的ts分片进行即时播放，而不需要如现有技术方案中提前将ts分片组合为原始ts文件后再进行播放，因此不需要提前启动接收端转换，不会在无用户访问前就产生开销，故而接收端不需同时支持全部直播频道，进而可以不需使用服务器类的强性能硬件，而可以换用如路由器或家庭网关等低成本嵌入式设备，在用户访问时支持当前频道即可，大大节约硬件成本。再次，使用本实施例提供的装置，无需预先对播放数据进行转换，因此无需任何额外起播等待，根据实际测试结果，使用本装置的情况下，起播时延为0.5-1秒左右，与直接播放HLS直播源的起播时延接近，优于现有HLS直播转组播方案中1-2秒的起播时延值。另外的，本实施例提供的装置，在组播ts分片接收到发送阶段的时延，相较于直接播放HLS直播源增加1个分片时长，按通常分片长度10秒为例，发送阶段延时的试验结果在11秒以内，而采用现有HLS直播转组播的技术方案时，若提前启动接收端转换，时延也需增加一个分片，试验统计值也在11秒以内，但若未提前启动接收端，需要按照HLS规范缓存要求数量的ts分片，则需延迟40秒以上，因此本实施例提供的装置发送阶段延时优于现有技术方案。综上几点，本实施例提供的装置，总体上能在保障效果的同时，无需终端的额外适配，降低了硬件成本和部署成本。

以上所述仅为本发明的较佳实施例而已，并不用以限制本发明，凡在本发明的精神和原则之内所作的任何修改、等同替换和改进等，均应包含在本发明的保护范围之内。

Claims (9)

1.一种HLS直播和组播直播接续的方法，其特征在于：

发送端由HLS直播源获取距当前直播时间点最近的ts分片；

发送端将获取到的ts分片按照组播直播要求生成组播包发出；

接收端获取组播包，并获取直播源中的原始索引文件，将原始索引文件的本地副本作为本地索引文件，按照组播包中的扩展信息，向本地索引文件中加入组播数据；

根据组播包的扩展信息中的ts分片文件名称查找对应的ts分片，将查找到的ts分片的前一个ts分片或当前ts分片作为定位ts分片，根据定位ts分片修改本地索引文件的ts分片列表，当原始索引文件中ts分片的URL包含一级域名时，将ts分片的URL修改为接收端地址；

将组播包还原为本地ts分片；

播放终端使用还原后的本地ts分片进行直播。

2.根据权利要求1所述的HLS直播和组播直播接续的方法，其特征在于，所述发送端将获取到的ts分片按照组播直播要求生成组播包发出，具体包括：将ts分片按照ts文件格式要求分割为ts包；

将至少一个ts包封装为RTP包；

在封装后的RTP包中添加与ts分片相关的扩展信息，生成组播包，其中，所述扩展信息包括ts分片文件名称、ts分片文件大小和每个ts包在原ts分片文件中对应的位置；

使用组播RTP形式发送封装后的组播包。

3.根据权利要求1所述的HLS直播和组播直播接续的方法，其特征在于，所述将组播包还原为本地ts分片，具体包括：

由HLS直播源首次被播放终端访问开始，接收端持续从组播直播接收封装后的组播包；

根据组播包中封装的扩展信息，将组播包还原为对应名称的ts分片；

直至不再有终端访问该直播为止。

4.根据权利要求3所述的HLS直播和组播直播接续的方法，其特征在于，还包括：

当需要使用ts分片中的数据，但还原过程未完成时，根据原始索引文件中的ts分片URL信息主动从直播源通过单播拉取ts分片。

5.根据权利要求1所述的HLS直播和组播直播接续的方法，其特征在于，还包括：

若未找到与扩展信息中ts分片文件名称一致的ts分片，或ts分片为本地索引文件中ts分片列表中的首个分片，将本地索引文件中最末尾的分片作为定位ts分片。

6.根据权利要求1所述的HLS直播和组播直播接续的方法，其特征在于，还包括：

确定本地索引文件更新等待时长，获取当前时间与本地索引文件上次更新的时间差；

获取本地索引文件首次创建信息或上次更新信息；

从本地索引文件中的定位ts分片向下查找ts分片，直至ts分片时长总和大于时间差，将查找到的最后一个ts分片作为新的定位ts分片。

7.根据权利要求6所述的HLS直播和组播直播接续的方法，其特征在于，所述确定本地索引文件更新等待时长，具体包括：

首次更新前，根据本地索引文件中指定最大的媒体段时间长和指定每个媒体段的持续时间获取更新等待时长；

每次更新后，根据本地索引文件中指定最大的媒体段时间长和查找到的ts分片总时长获取更新等待时长。

8.根据权利要求6所述的HLS直播和组播直播接续的方法，其特征在于，所述从本地索引文件中的定位ts分片向下查找ts分片，还包括：

若定位ts分片丢失，根据当前组播直播携带的扩展信息中的定位ts分片的文件名称，在本地索引文件的ts分片列表中查找与定位ts分片的文件名称相同的ts分片；

若查找到了同名的ts分片，将该分片作为定位ts分片；

若未找到同名的ts分片，将本地索引文件ts分片列表末尾的ts分片作为定位ts分片。

9.一种HLS直播和组播直播接续的装置，其特征在于：

包括发送设备(1)和接收设备(2)；

发送设备(1)接近HLS直播源(3)，接收设备(2)接近播放终端(4)，发送设备(1)、接收设备(2)、HLS直播源(3)和播放终端(4)之间分别通过网络信号连接；

发送设备(1)和接收设备(2)分别包括至少一个处理器和存储器，所述至少一个处理器和存储器之间通过数据总线连接，所述存储器存储能被所述至少一个处理器执行的指令，所述指令在被所述处理器执行后，用于完成权利要求1-8中任一项所述的HLS直播和组播直播接续的方法。

Images