CN111526374B - 基于直播的弹幕处理方法、拉流的方法及装置 - Google Patents

Abstract

本申请公开了一种基于直播的弹幕处理方法、拉流的方法及装置，当方法应用于服务器中时，所述方法包括：对接收的直播视频流进行切割，并将切割得到的视频数据分片存储在第一容器内；对接收的针对直播视频流的弹幕数据流进行切割，并将切割得到的弹幕数据分片存储在第二容器内；判断第一容器或第二容器内存储的数据是否触发其对应的预设容器深度阈值；若是，则获取第一容器内视频数据分片进行分组后得到的N个视频分组，以及第二容器内弹幕数据分片进行分组后得到的M个弹幕分组；将N个视频分组以及M个弹幕分组进行处理，得到目标数据包，并将目标数据包以目标数据流的形式发送至下层设备中。本申请可以实现对视频数据以及弹幕数据的合并传输。

Description

基于直播的弹幕处理方法、拉流的方法及装置

技术领域

本申请涉及直播领域，尤其涉及基于直播的弹幕处理方法、拉流的方法及装置。

背景技术

随着网络技术的发展，网络直播越来越普及，各式各样的社会活动都可以借助网络直播方式进行传播。

用户在观看直播时，通常会发表个人观点，由此会产生相应的弹幕。除此之外，很多用户会给主播送礼物，以表示对主播的支持，同样可以产生弹幕。对于一些特殊类型的用户，为了增加这些用户的曝光度，这些特殊类型的用户进入直播间时也可以产生弹幕。目前，直播弹幕需要独立于音视频数据进行独立通道传输，弹幕无法和音视频数据进行合并传输，灵活性较低。

发明内容

有鉴于此，本申请提供一种基于直播的弹幕处理方法、拉流的方法及装置。

根据本申请实施例的第一方面，提供一种基于直播的弹幕处理方法，所述方法应用于服务器中，所述方法包括：

对接收的直播视频流进行切割，并将切割得到的视频数据分片存储在第一容器内；

对接收的针对所述直播视频流的弹幕数据流进行切割，并将切割得到的弹幕数据分片存储在第二容器内；

判断所述第一容器或所述第二容器内存储的数据是否触发其对应的预设容器深度阈值；

若是，则获取所述第一容器内所述视频数据分片进行分组后得到的N个视频分组，以及所述第二容器内所述弹幕数据分片进行分组后得到的M个弹幕分组；

将所述N个视频分组以及所述M个弹幕分组进行处理，得到目标数据包，并将所述目标数据包以目标数据流的形式发送至下层设备中，其中，所述目标数据包中包括N个视频分组以及M个弹幕分组。

优选地，所述将所述N个视频分组以及所述M个弹幕分组进行处理，得到目标数据包，包括：

将所述N个视频分组以及所述M个弹幕分组进行对齐；

将对齐后的所述N个视频分组以及所述M个弹幕分组封装成目标数据包。

优选地，所述将所述N个视频分组以及所述M个弹幕分组进行对齐，包括：

将所述N个视频分组包含的视频数据分片与所述M个弹幕分组包含的弹幕数据分片按照时间轴的顺序进行对齐；

若某个视频数据分片不存在与之对齐的弹幕数据分片，则将空数据作为与该视频数据分片对齐的弹幕数据分片。

优选地，所述判断所述第一容器或所述第二容器内存储的数据是否触发其对应的预设容器深度阈值，包括：

针对各视频分组，获取该视频分组中包含的视频数据切片的第一数量，并将最大的第一数量作为所述第一容器的第一深度；

针对各弹幕分组，获取该弹幕分组中包含的弹幕数据切片的第二数量，并将最大的第二数量作为所述第二容器的第二深度；

若所述第一深度达到预设容器深度阈值，则判定所述第一容器内存储的数据触发预设容器深度阈值；

若所述第二深度达到预设容器深度阈值，则判定所述第二容器内存储的数据触发预设容器深度阈值。

优选地，各视频数据分片在所述第一容器内具有对应的第一分片编号，各弹幕数据分片在所述第二容器内具有对应的第二分片编号；

所述视频分组或弹幕分组采用如下方式确定：

将各第一分片编号与视频分组数量N进行求余运算，并将余数相同的视频数据分片分类在同一视频分组中，其中，所述视频分组数量N根据所述直播视频流的码率确定；

将各第二分片编号与弹幕分组数量M进行求余运算，并将余数相同的弹幕数据分片分类在同一弹幕分组中，其中，所述弹幕分组数量M根据所述弹幕数据流的码率确定。

优选地，所述下层设备包括CDN服务器、具有上行能力的智能盒子。

根据本申请实施例的第二方面，提供了一种拉流的方法，所述方法应用于拉流设备中，所述方法包括：

从上层设备中获取当前开播的主播的目标数据流，其中，所述目标数据流包括目标数据包，所述目标数据包中包括N个视频分组以及M个弹幕分组，各视频分组中包括若干视频数据分片，各弹幕分组中包括若干弹幕数据分片，所述视频数据分片为对直播视频流分割而成，所述弹幕数据分片为对所述直播视频流的弹幕数据流分割而成；

将所述N个视频分组中的视频数据分片合并成直播视频数据；

将所述M个弹幕分组中的弹幕数据分片合并成弹幕数据；

通过显示设备播放所述直播视频数据以及所述弹幕数据。

优选地，所述方法还包括：

将所述目标数据包下发至下层设备中。

优选地，所述拉流设备至少包括CDN服务器、具有上行能力的智能盒子。

根据本申请实施例的第三方面，提供了一种基于直播的弹幕处理装置，所述装置应用于服务器中，所述装置包括：

第一切割模块，用于对接收的直播视频流进行切割，并将切割得到的视频数据分片存储在第一容器内；

第二切割模块，用于对接收的针对所述直播视频流的弹幕数据流进行切割，并将切割得到的弹幕数据分片存储在第二容器内；

深度判断模块，用于判断所述第一容器或所述第二容器内存储的数据是否触发其对应的预设容器深度阈值；若是，则调用分组获取模块；

分组获取模块，用于获取所述第一容器内所述视频数据分片进行分组后得到的N个视频分组，以及所述第二容器内所述弹幕数据分片进行分组后得到的M个弹幕分组；

分组处理模块，用于将所述N个视频分组以及所述M个弹幕分组进行处理，得到目标数据包，并将所述目标数据包以目标数据流的形式发送至下层设备中，其中，所述目标数据包中包括N个视频分组以及M个弹幕分组。

根据本申请实施例的第四方面，提供了一种拉流装置，所述装置应用于拉流设备中，所述装置包括：

拉流模块，用于从上层设备中获取当前开播的主播的目标数据流，其中，所述目标数据流包括目标数据包，所述目标数据包中包括N个视频分组以及M个弹幕分组，各视频分组中包括若干视频数据分片，各弹幕分组中包括若干弹幕数据分片，所述视频数据分片为对直播视频流分割而成，所述弹幕数据分片为对所述直播视频流的弹幕数据流分割而成；

视频分片合并模块，用于将所述N个视频分组中的视频数据分片合并成直播视频数据；

弹幕分片合并模块，用于将所述M个弹幕分组中的弹幕数据分片合并成弹幕数据；

播放模块，用于通过显示设备播放所述直播视频数据以及所述弹幕数据。

根据本申请实施例的第五方面，提供了一种计算机可读存储介质，其上存储有计算机程序，所述程序被处理器执行时实现上述方法的步骤。

根据本申请实施例的第六方面，提供了一种计算机设备，包括存储器、处理器及存储在存储器上并可在处理器上运行的计算机程序，所述处理器执行所述程序时实现上述方法的步骤。

本申请实施例提供的技术方案可以包括以下有益效果：

在本申请实施例中，服务器通过对接收的直播视频流以及弹幕数据流进行切割，可以得到对应的视频数据分片以及弹幕数据分片，然后将视频数据分片存入第一容器，将弹幕数据分片存入第二容器，当任一容器触发其对应的预设容器深度阈值时，则获取第一容器内视频数据分片进行分组后得到的N个视频分组以及第二容器内弹幕数据分片进行分组后得到的M个弹幕分组，并通过将该N个视频分组以及M个弹幕分组的处理得到用于传输的目标数据包，从而实现对视频数据以及弹幕数据的合并传输，提高传输的效率，提升传输灵活性。

附图说明

图1是本申请一示例性实施例示出的一种基于直播的弹幕处理方法实施例的步骤流程图；

图2是本申请一示例性实施例示出的一种拉流的方法实施例的步骤流程图；

图3是本申请的装置所在设备的一种硬件结构图；

图4是本申请一示例性实施例示出的一种基于直播的弹幕处理装置实施例的结构框图；

图5是本申请一示例性实施例示出的一种拉流装置实施例的结构框图。

具体实施方式

这里将详细地对示例性实施例进行说明，其示例表示在附图中。下面的描述涉及附图时，除非另有表示，不同附图中的相同数字表示相同或相似的要素。以下示例性实施例中所描述的实施方式并不代表与本申请相一致的所有实施方式。相反，它们仅是与如所附权利要求书中所详述的、本申请的一些方面相一致的装置和方法的例子。

在本申请使用的术语是仅仅出于描述特定实施例的目的，而非旨在限制本申请。在本申请和所附权利要求书中所使用的单数形式的“一种”、“所述”和“该”也旨在包括多数形式，除非上下文清楚地表示其他含义。还应当理解，本文中使用的术语“和/或”是指并包含一个或多个相关联的列出项目的任何或所有可能组合。

应当理解，尽管在本申请可能采用术语第一、第二、第三等来描述各种信息，但这些信息不应限于这些术语。这些术语仅用来将同一类型的信息彼此区分开。例如，在不脱离本申请范围的情况下，第一信息也可以被称为第二信息，类似地，第二信息也可以被称为第一信息。取决于语境，如在此所使用的词语“如果”可以被解释成为“在……时”或“当……时”或“响应于确定”。

参考图1，示出了本申请一示例性实施例示出的一种基于直播的弹幕处理方法实施例的步骤流程图，本申请实施例可以应用于服务器中，具体可以包括如下步骤：

步骤101，对接收的直播视频流进行切割，并将切割得到的视频数据分片存储在第一容器内；

在具体实现中，服务器可以通过主播侧的主播网络服务器获取主播在开播后上传的直播视频流。具体的，主播端可以通过RTMP(Real Time Messaging Protocol，实时消息传输协议)或者UDP(User Datagram Protocol，用户数据包协议)向主播侧CDN服务器推流，各地的CDN服务器将收到的直播视频流发到同一个主播网络服务器中，主播网络服务器会对接收到的直播视频流进行处理，然后将处理后的直播视频流发送至本实施例的服务器中。

其中，直播视频流以直播视频流标识作为唯一的流标识，除了直播视频流标识以外，直播视频流中还可以携带主播标识UID。服务器接收到直播视频流以后，可以记录直播视频流标识以及主播标识UID的映射关系在映射表中。

针对接收的直播视频流，服务器可以进行切割处理，得到视频数据分片。在具体实现中，当接收的直播视频流的数据量达到预设大小(例如，1k)时，则可以将该预设大小的直播视频流按照约定的格式封装成视频数据分片，即一个视频数据分片的大小为预设大小。

然后可以将切割得到的视频数据分片存储在第一容器内，其中，各视频数据分片在第一容器内具有对应的第一分片编号，该第一分片编号与切割的顺序相关。

在将视频数据分片存入第一容器时，还可以对该视频数据分片进行分组处理，以将该视频数据分片划分到对应的视频分组中。在一种实施方式中，其中一种确定视频分组的方式可以为：将各第一分片编号与视频分组数量N进行求余运算，并将余数相同的视频数据分片分类在同一视频分组中。其中，视频分组数量N可以根据直播视频流的码率确定。

例如，一个时间段内的直播视频流被切割成第一分片编号分别为1-240的视频数据分片，假设N＝8，分别用每个第一分片编号对8进行求余，例如第一分片编号为1时，1/8的余数是1，余数为1的视频数据分片属于0号视频分组，第一分片编号为1时，2/8的余数是2，余数为2的视频数据分片属于1号视频分组，以此类推，可以确定各视频数据分片的分组情况。在实际中，每个视频分组的视频数据分片相当于一路视频子流，例如0号视频分组属于0号子流，以此类推。

步骤102，对接收的针对所述直播视频流的弹幕数据流进行切割，并将切割得到的弹幕数据分片存储在第二容器内；

在具体实现中，服务器可以通过业务服务器获取弹幕数据流。具体的，当主播开播以后，业务服务器可以获取针对该主播播放的视频的弹幕数据，并将弹幕数据以弹幕数据流的形式发送给本申请实施例的服务器中，其中，该弹幕数据流携带主播标识UID。

服务器接收到弹幕数据流以后，可以在映射表中查找该主播标识UID，以确定该弹幕数据流对应的直播视频流标识。

针对接收的弹幕数据流，服务器可以进行切割处理，得到弹幕数据分片。在具体实现中，当接收的弹幕数据流的数据量达到预设大小(例如，1k)时，则可以将该预设大小的弹幕数据流按照约定的格式封装成弹幕数据分片，即一个弹幕数据分片的大小为预设大小。

然后可以将切割得到的弹幕数据分片存储在第二容器内，其中，各弹幕数据分片在第二容器内具有对应的第二分片编号，该第二分片编号与切割的顺序相关。

在将弹幕数据分片存入第二容器时，还可以对该弹幕数据分片进行分组处理，以将该弹幕数据分片划分到对应的弹幕分组中。

在一种实施方式中，其中一种确定弹幕分组的方式可以为：将各第二分片编号与弹幕分组数量M进行求余运算，并将余数相同的弹幕数据分片分类在同一弹幕分组中，其中，弹幕分组数量M可以根据弹幕数据流的码率确定。例如，一个时间段内的弹幕数据流被切割成第二分片编号分别为1-40的视频数据分片，假设M＝2，分别用每个第二分片编号对2进行求余，例如第二分片编号为1时，1/2的余数是1，余数为1的弹幕数据分片属于0号弹幕分组，第二分片编号为2时，2/2的余数是0，余数为0的弹幕数据分片属于1号弹幕分组，以此类推，可以确定各弹幕数据分片的分组情况。在实际中，每个弹幕分组的弹幕数据分片相当于一路弹幕子流，例如0号弹幕分组属于0号弹幕子流，1号弹幕分组属于1号弹幕子流。

步骤103，判断所述第一容器或所述第二容器内存储的数据是否触发其对应的预设容器深度阈值；若是，则执行步骤104；若否，则继续执行步骤101及步骤102；

在具体实现中，第一容器以及第二容器均有其对应的预设容器深度阈值，两者的预设容器深度阈值可以相同也可以不同，本实施例对此不作限制。该预设容器深度阈值用于限定第一容器或第二容器所能容纳的数据量。

只要第一容器或第二容器任一方触发其对应的预设容器深度阈值，则暂停往两个容器中存数据，并执行步骤104以及步骤105，直到步骤105执行完毕后再继续往两个容器中存数据。

在本申请实施例的一种优选实施例中，步骤103进一步可以包括如下子步骤：

子步骤S11，针对各视频分组，获取该视频分组中包含的视频数据切片的第一数量，并将最大的第一数量作为所述第一容器的第一深度；

子步骤S12，针对各弹幕分组，获取该弹幕分组中包含的弹幕数据切片的第二数量，并将最大的第二数量作为所述第二容器的第二深度；

子步骤S13，若所述第一深度达到预设容器深度阈值，则判定所述第一容器内存储的数据触发预设容器深度阈值；

子步骤S14，若所述第二深度达到预设容器深度阈值，则判定所述第二容器内存储的数据触发预设容器深度阈值。

具体的，服务器每次往容器内存放数据后就获取该容器实时存储的数据的深度，并根据该获取的深度与预设容器深度阈值的比较结果判断该容器是否到达指定深度。

在具体实现中，每一个分组(视频分组或弹幕分组)中包含的数据分片(视频数据分片或弹幕数据分片)的数量可以作为该分组的深度，汇总容器内所有分组的深度以后，可将最大的深度作为该容器的深度。例如，在第一容器中，共有0-7号视频分组，其中，前6号分组的深度均为30，第7号分组的深度为29，则可以确定第一容器的深度为30。又如，在第二容器中，共有0-1号视频分组，其中，第0号分组的深度为20，第1号分组的深度为19，则可以确定第二容器的深度为20。

为了更好地理解本实施例中的分组和深度的概念，可以将容器空间划分为纵轴和横轴，其中，每个分组按纵轴排列，每个数据分片按照其分片编号以横轴的时间轴顺序排列，则容器中的列数表示其分组数量，容器中的行数表示其深度。当任一容器的深度达到预设容器深度阈值时，则执行步骤104和步骤105。例如，假设预设容器深度阈值为30行，当第一容器或第二容器的深度首先达到30行时(即使另一容器的深度没有达到30行)，则可以执行步骤104和步骤105。当然，上述的描述不应当理解成对本实施例的限制。

步骤104，获取所述第一容器内所述视频数据分片进行分组后得到的N个视频分组，以及所述第二容器内所述弹幕数据分片进行分组后得到的M个弹幕分组；

步骤105，将所述N个视频分组以及所述M个弹幕分组进行处理，得到目标数据包，并将所述目标数据包以目标数据流的形式发送至下层设备中。

当第一容器或第二容器中任一容器触发其对应的预设容器深度阈值时，则触发对视频分组和弹幕分组的合并处理，以得到目标数据包，其中，该目标视频包中包含N个视频分组以及M个弹幕分组。

在本申请实施例的一种优选实施例中，步骤105进一步可以包括如下子步骤：

子步骤S21，将所述N个视频分组以及所述M个弹幕分组进行对齐；

在具体实现中，由于N个视频分组内包含的视频数据分片与M个弹幕分组内包含的弹幕数据分片的数量可能并不一定相同，两者也可能不是完整对齐的，因此需要对两者进行对齐。

在本申请实施例的一种优选实施例中，子步骤S21进一步可以包括如下子步骤：

将所述N个视频分组包含的视频数据分片与所述M个弹幕分组包含的弹幕数据分片按照时间轴的顺序进行对齐；若某个视频数据分片不存在与之对齐的弹幕数据分片，则将空数据作为与该视频数据分片对齐的弹幕数据分片。

例如，N个视频分组包含第一分片编号分别为0-9的视频数据分片，M个弹幕分组包含第二分片编号分别为0-4的弹幕数据分片，该第二分片编号分别为0-4的弹幕数据分片分别与第一分片编号为1、3、4、7、9的视频数据分片对齐，则对于第一分片编号为0、2、5、6、8的视频数据分片，可以将其对齐的弹幕数据分片的位置填充为空数据，以此实现N个视频分组与M个弹幕分组的对齐。

子步骤S22，将对齐后的所述N个视频分组以及所述M个弹幕分组封装成目标数据包。

当将N个视频分组与M个弹幕分组对齐以后，则可以将该N个视频分组与M个弹幕分组封装成一个目标数据包，该目标数据包以目标数据流的形式传输至下层设备。

在该目标数据包中共有(N+M)个分组，其中，N个视频分组占用0-(N-1)号分组，M个弹幕分组占用N-(N+M-1)号分组。例如，目标数据包内共有10个分组，其中，视频分组为8个，弹幕分组为2个，则视频分组可以占用0-7号分组，弹幕分组则占用8-9号分组。

在实际中，本申请实施例的服务器充当切片服务器的功能，则作为一种示例，下层设备可以包括CDN服务器、具有上行能力的智能盒子等。其中，智能盒子又可以称为电视盒子，是一种小型的计算终端设备，当其通过HDMI或色差线等技术与显示设备连接以后，就可以在盒子上实现网页浏览、网络视频播放、应用程序安装等。在本实施例中，智能盒子还可以具有直播视频数据的录播能力、视频数据上传或共享的上行能力等，上行能力较好的智能盒子可以从切片服务器中拉流。

在本申请实施例中，服务器通过对接收的直播视频流以及弹幕数据流进行切割，可以得到对应的视频数据分片以及弹幕数据分片，然后将视频数据分片存入第一容器，将弹幕数据分片存入第二容器，当任一容器触发其对应的预设容器深度阈值时，则获取第一容器内视频数据分片进行分组后得到的N个视频分组以及第二容器内弹幕数据分片进行分组后得到的M个弹幕分组，并通过将该N个视频分组以及M个弹幕分组的处理得到用于传输的目标数据包，从而实现对视频数据以及弹幕数据的合并传输，提高传输的效率，提升传输灵活性。

参考图2，示出了本申请一示例性实施例示出的一种拉流的方法实施例的步骤流程图，本申请实施例可以应用于拉流设备中，其中，拉流设备为从切片服务器中拉流的设备，作为一种示例，拉流设备至少可以包括CDN服务器、具有上行能力的智能盒子等。

在本实施例中，智能盒子可以充当CDN节点的角色，其可以接收下一级智能盒子的拉流，也可以从上一级智能盒子中拉取视频流。多个智能盒子之间可以组成P2P网络，P2P网络中的智能盒子可以向其他智能盒子发送同步信息，以相互进行信息同步，其中，作为一种示例，同步信息至少可以包括本智能盒子已有的视频流信息、本智能盒子的树长度等。本实施例的智能盒子在进行网络收发数据时，使用的是用户的空闲带宽资源，使得用户的空闲资源可以有效利用，并可以节省服务器的资源。

具体的，当用户安装智能盒子以后，可以将智能盒子接入网络，例如，接入家庭局域网。随后，用户可以通过登录信息登录该智能盒子，其中，登录信息可以根据不同的业务场景确定，例如，在直播场景中，登录信息可以为用户在直播应用中注册的登录信息。在其他场景中，登录信息可以为用户在相应应用程序中注册的登录信息。

完成登录后，智能盒子则可以定时向调度服务器上报盒子信息。作为一种示例，盒子信息可以包括但不限于：地理位置信息、运营商信息、上行带宽评估值、已用带宽、可用带宽等。

在一种实施方式中，智能盒子可以采用如下方式获取自身的上行带宽评估值：

1、使用SDK将若干交互数据包(包括但不限于心跳包、视频包等)分成一组，同一组交互数据包会同时发送出去；

2、假设同一分组连续两个视频包分别为p1、p2，对应的发送时间戳分别为s1、s2，接收时间戳分别为r1，r2，p2的大小size为p2Size；

则当前带宽值curBw可以通过以下公式估算：

curBw＝p2Size/((r2–r1)–(s2–s1))；

而由于s2等于s1，则

curBw＝p2Size/(r2–r1)；

3、curBw为上行带宽评估值estBw的一个样本点，可以通过以下公式来平滑得出estBw：

estBw＝estBw(hist)*a+curBw*(1–a)；

其中，estBw(hist)为上一次获得的上行带宽评估值；a为经验值，例如，a可以取15/16。

当智能盒子向调度服务器上报盒子信息以后，调度服务器可以根据各智能盒子的登录信息，从已生成的数据库中获取各登录信息的订阅关系，并最终确定订阅当前开播的主播的智能盒子，作为候选智能盒子。然后根据候选智能盒子的地理位置信息以及运营商信息，将各候选智能盒子划分到与其地理位置信息以及运营商信息匹配的分区中，并针对各分区，按照上行带宽评估值将该分区中的候选智能盒子进行降序排序，从该分区中选取上行带宽评估值最大的N个候选智能盒子作为目标智能盒子，选择出目标智能盒子以后，调度服务器可以为该目标智能盒子分配当前开播的主播的拉流任务，其中，该拉流任务可以包括直播视频流标识。

其中，指定的多个分区可以根据地区信息以及运营商信息进行划分，例如，地区信息可以包括但不限于华东、华南、华北、西南等，运营商信息可以包括但不限于电信、联通、移动等，则分区可以包括上述的地区信息以及运营商信息的组合，如华南移动、西南联通等等。

基于上述的拉流设备，本申请实施例具体可以包括如下步骤：

步骤201，从上层设备中获取当前开播的主播的目标数据流，其中，所述目标数据流包括目标数据包，所述目标数据包中包括N个视频分组以及M个弹幕分组，各视频分组中包括若干视频数据分片，各弹幕分组中包括若干弹幕数据分片，所述视频数据分片为对直播视频流分割而成，所述弹幕数据分片为对所述直播视频流的弹幕数据流分割而成；

在实际中，拉流设备拉取目标视频流的情形可以包括如下两种情形：

第一种是拉流设备接收到下层设备发送的拉流请求，根据该拉流请求获取当前开播的主播的目标数据流。在一种实施例中，针对智能盒子而言，调度服务器为智能盒子分配拉流任务以后，该智能盒子暂时不从上层设备中拉取当前开播的主播的直播视频流，直到有下层观看该主播时才开始从上层设备中拉流。在调度服务器侧，当调度服务器接收到下层设备针对当前开播的主播的拉流请求以后，可以首先根据该下层设备所属的地区以及运营商信息确定该下层设备所属的目标分区，然后将该目标分区中的目标智能盒子具有的拉流任务与拉流请求携带的目标主播流标识进行匹配，将匹配该目标主播流标识的拉流任务对应的目标智能盒子作为匹配目标智能盒子，并获取该匹配目标智能盒子的连接地址，然后将获得的连接地址返回下层设备，这样下层设备就可以根据该连接地址直接向对应的目标智能盒子请求拉流。

第二种是拉流设备主动获取当前开播的主播的目标数据流。针对这种情况，用户可以预先配置需要主动拉流的主播信息，然后拉流设备接收到订阅的主播的开播通知以后，可以直接拉取该主播的直播视频流。

在本实施例中，拉流设备获得的目标数据流以后，可以对该目标视频流进行解析，获得对应的目标数据包，其中，该目标数据包中可以包括N个视频分组以及M个弹幕分组，进一步地，各视频分组中可以包括若干视频数据分片，各弹幕分组中可以包括若干弹幕数据分片，而该视频数据分片为对直播视频流分割而成，该弹幕数据分片为对直播视频流的弹幕数据流分割而成。

步骤202，将所述N个视频分组中的视频数据分片合并成直播视频数据；

在具体实现中，当拉流设备获得N个视频分组以后，可以从该N个视频分组中解析出视频数据分片，其中，该视频数据分片可以有多个，各视频数据分片具有对应的第一分片编号，可以按照第一分片编号的顺序将多个视频数据分片合并成直播视频数据。

步骤203，将所述M个弹幕分组中的弹幕数据分片合并成弹幕数据；

在具体实现中，当拉流设备获得M个弹幕分组以后，可以从该M个弹幕分组中解析出弹幕数据分片，其中，该弹幕数据分片可以有多个，各弹幕数据分片具有对应的第二分片编号，可以按照第二分片编号的顺序将多个弹幕数据分片合并成弹幕数据。

在实际中，对弹幕分组进行解析时还会解析出空数据，可以直接将解析出的空数据丢弃。

步骤204，通过显示设备播放所述直播视频数据以及所述弹幕数据。

当拉流设备获得直播视频数据以及弹幕数据以后，可以在本地保存该直播视频数据以及弹幕数据。当检测到用户需要观看时，可以通过显示设备播放该直播视频数据以及弹幕数据。例如，通过手机播放该直播视频数据以及对应的弹幕数据，或者，通过智能盒子连接的显示设备播放该直播视频数据以及对应的弹幕数据。

在本申请实施例的一种优选实施例中，还可以包括如下步骤：

将所述目标数据包下发至下层设备中。

在具体实现中，针对步骤201描述的两种拉取目标视频流的情形，在第一种中当拉流设备获得目标数据包以后，可以直接将目标数据包以目标数据流的形式返回请求的下层设备。在第二种中当拉流设备获得目标数据包以后，可以确定P2P网络中订阅同一主播的设备，并将该获得的目标数据包以目标数据流的形式共享至上述设备中。

在本申请实施例中，拉流设备从上层设备中获得的当前开播的主播的目标数据包中包括N个视频分组以及M个弹幕分组，使得拉流设备可以一次性获取视频数据以及弹幕数据，节省了拉流设备的带宽资源以及提高了拉流设备的拉流效率。

与前述方法的实施例相对应，本申请还提供了一种基于直播的弹幕处理装置实施例以及一种拉流装置实施例。

本申请基于直播的弹幕处理装置实施例可以应用在服务器上，拉流装置实施例可以应用在拉流设备上。上述两种装置实施例可以通过软件实现，也可以通过硬件或者软硬件结合的方式实现。以软件实现为例，作为一个逻辑意义上的装置，是通过其所在设备(服务器或拉流设备)的处理器将非易失性存储器中对应的计算机程序指令读取到内存中运行形成的。从硬件层面而言，如图3所示，为本申请的装置所在设备的一种硬件结构图，除了图3所示的处理器、内存、网络接口、以及非易失性存储器之外，实施例中装置所在的设备通常根据该装置的实际功能，还可以包括其他硬件，对此不再赘述。

请参考图4，示出了本申请一示例性实施例示出的一种基于直播的弹幕处理装置实施例的结构框图，所述装置应用于服务器中，所述装置包括如下模块：

第一切割模块401，用于对接收的直播视频流进行切割，并将切割得到的视频数据分片存储在第一容器内；

第二切割模块402，用于对接收的针对所述直播视频流的弹幕数据流进行切割，并将切割得到的弹幕数据分片存储在第二容器内；

深度判断模块403，用于判断所述第一容器或所述第二容器内存储的数据是否触发其对应的预设容器深度阈值；若是，则调用分组获取模块；

分组获取模块404，用于获取所述第一容器内所述视频数据分片进行分组后得到的N个视频分组，以及所述第二容器内所述弹幕数据分片进行分组后得到的M个弹幕分组；

分组处理模块405，用于将所述N个视频分组以及所述M个弹幕分组进行处理，得到目标数据包，并将所述目标数据包以目标数据流的形式发送至下层设备中，其中，所述目标数据包中包括N个视频分组以及M个弹幕分组。

在本申请实施例的一种优选实施例中，所述分组处理模块405进一步可以包括如下子模块：

对齐子模块，用于将所述N个视频分组以及所述M个弹幕分组进行对齐；

封装子模块，用于将对齐后的所述N个视频分组以及所述M个弹幕分组封装成目标数据包。

在本申请实施例的一种优选实施例中，所述对齐子模块具体用于：

将所述N个视频分组包含的视频数据分片与所述M个弹幕分组包含的弹幕数据分片按照时间轴的顺序进行对齐；

若某个视频数据分片不存在与之对齐的弹幕数据分片，则将空数据作为与该视频数据分片对齐的弹幕数据分片。

在本申请实施例的一种优选实施例中，所述深度判断模块403进一步可以包括如下子模块：

第一深度确定子模块，用于针对各视频分组，获取该视频分组中包含的视频数据切片的第一数量，并将最大的第一数量作为所述第一容器的第一深度；

第二深度确定子模块，用于针对各弹幕分组，获取该弹幕分组中包含的弹幕数据切片的第二数量，并将最大的第二数量作为所述第二容器的第二深度；

第一判定子模块，用于若所述第一深度达到预设容器深度阈值，则判定所述第一容器内存储的数据触发预设容器深度阈值；

第二判定子模块，用于若所述第二深度达到预设容器深度阈值，则判定所述第二容器内存储的数据触发预设容器深度阈值。

在本申请实施例的一种优选实施例中，各视频数据分片在所述第一容器内具有对应的第一分片编号，各弹幕数据分片在所述第二容器内具有对应的第二分片编号；

所述视频分组或弹幕分组采用如下方式确定：

将各第一分片编号与视频分组数量N进行求余运算，并将余数相同的视频数据分片分类在同一视频分组中，其中，所述视频分组数量N根据所述直播视频流的码率确定；

将各第二分片编号与弹幕分组数量M进行求余运算，并将余数相同的弹幕数据分片分类在同一弹幕分组中，其中，所述弹幕分组数量M根据所述弹幕数据流的码率确定。

在本申请实施例的一种优选实施例中，所述下层设备包括CDN服务器、具有上行能力的智能盒子。

请参考图5，示出了本申请一示例性实施例示出的一种拉流装置实施例的结构框图，所述装置应用于拉流设备中，所述装置包括如下模块：

拉流模块501，用于从上层设备中获取当前开播的主播的目标数据流，其中，所述目标数据流包括目标数据包，所述目标数据包中包括N个视频分组以及M个弹幕分组，各视频分组中包括若干视频数据分片，各弹幕分组中包括若干弹幕数据分片，所述视频数据分片为对直播视频流分割而成，所述弹幕数据分片为对所述直播视频流的弹幕数据流分割而成；

视频分片合并模块502，用于将所述N个视频分组中的视频数据分片合并成直播视频数据；

弹幕分片合并模块503，用于将所述M个弹幕分组中的弹幕数据分片合并成弹幕数据；

播放模块504，用于通过显示设备播放所述直播视频数据以及所述弹幕数据。

在本申请实施例的一种优选实施例中，所述装置还可以包括如下模块：

目标数据包下发模块，用于将所述目标数据包下发至下层设备中。

在本申请实施例的一种优选实施例中，所述拉流设备至少包括CDN服务器、具有上行能力的智能盒子。

对于图4及图5的装置实施例而言，由于其基本对应于图1及图2的方法实施例，所以相关之处参见方法实施例的部分说明即可。

以上所描述的装置实施例仅仅是示意性的，其中所述作为分离部件说明的单元可以是或者也可以不是物理上分开的，作为单元显示的部件可以是或者也可以不是物理单元，即可以位于一个地方，或者也可以分布到多个网络单元上。可以根据实际的需要选择其中的部分或者全部模块来实现本申请方案的目的。本领域普通技术人员在不付出创造性劳动的情况下，即可以理解并实施。

本申请还提供了一种计算机可读存储介质，其上存储有计算机程序，所述程序被处理器执行时实现上述方法实施例的步骤。

本申请还提供了一种计算机设备，包括存储器、处理器及存储在存储器上并可在处理器上运行的计算机程序，所述处理器执行所述程序时实现上述方法实施例的步骤。

本说明书中描述的主题及功能操作的实施例可以在以下中实现：数字电子电路、有形体现的计算机软件或固件、包括本说明书中公开的结构及其结构性等同物的计算机硬件、或者它们中的一个或多个的组合。本说明书中描述的主题的实施例可以实现为一个或多个计算机程序，即编码在有形非暂时性程序载体上以被数据处理装置执行或控制数据处理装置的操作的计算机程序指令中的一个或多个模块。可替代地或附加地，程序指令可以被编码在人工生成的传播信号上，例如机器生成的电、光或电磁信号，该信号被生成以将信息编码并传输到合适的接收机装置以由数据处理装置执行。计算机存储介质可以是机器可读存储设备、机器可读存储基板、随机或串行存取存储器设备、或它们中的一个或多个的组合。

本说明书中描述的处理及逻辑流程可以由执行一个或多个计算机程序的一个或多个可编程计算机执行，以通过根据输入数据进行操作并生成输出来执行相应的功能。所述处理及逻辑流程还可以由专用逻辑电路—例如FPGA(现场可编程门阵列)或ASIC(专用集成电路)来执行，并且装置也可以实现为专用逻辑电路。

适合用于执行计算机程序的计算机包括，例如通用和/或专用微处理器，或任何其他类型的中央处理单元。通常，中央处理单元将从只读存储器和/或随机存取存储器接收指令和数据。计算机的基本组件包括用于实施或执行指令的中央处理单元以及用于存储指令和数据的一个或多个存储器设备。通常，计算机还将包括用于存储数据的一个或多个大容量存储设备，例如磁盘、磁光盘或光盘等，或者计算机将可操作地与此大容量存储设备耦接以从其接收数据或向其传送数据，抑或两种情况兼而有之。然而，计算机不是必须具有这样的设备。此外，计算机可以嵌入在另一设备中，例如车载终端、移动电话、个人数字助理(PDA)、移动音频或视频播放器、游戏操纵台、全球定位系统(GPS)接收机、或例如通用串行总线(USB)闪存驱动器的便携式存储设备，仅举几例。

适合于存储计算机程序指令和数据的计算机可读介质包括所有形式的非易失性存储器、媒介和存储器设备，例如包括半导体存储器设备(例如EPROM、EEPROM和闪存设备)、磁盘(例如内部硬盘或可移动盘)、磁光盘以及CD ROM和DVD-ROM盘。处理器和存储器可由专用逻辑电路补充或并入专用逻辑电路中。

虽然本说明书包含许多具体实施细节，但是这些不应被解释为限制任何发明的范围或所要求保护的范围，而是主要用于描述特定发明的具体实施例的特征。本说明书内在多个实施例中描述的某些特征也可以在单个实施例中被组合实施。另一方面，在单个实施例中描述的各种特征也可以在多个实施例中分开实施或以任何合适的子组合来实施。此外，虽然特征可以如上所述在某些组合中起作用并且甚至最初如此要求保护，但是来自所要求保护的组合中的一个或多个特征在一些情况下可以从该组合中去除，并且所要求保护的组合可以指向子组合或子组合的变型。

类似地，虽然在附图中以特定顺序描绘了操作，但是这不应被理解为要求这些操作以所示的特定顺序执行或顺次执行、或者要求所有例示的操作被执行，以实现期望的结果。在某些情况下，多任务和并行处理可能是有利的。此外，上述实施例中的各种系统模块和组件的分离不应被理解为在所有实施例中均需要这样的分离，并且应当理解，所描述的程序组件和系统通常可以一起集成在单个软件产品中，或者封装成多个软件产品。

由此，主题的特定实施例已被描述。其他实施例在所附权利要求书的范围以内。在某些情况下，权利要求书中记载的动作可以以不同的顺序执行并且仍实现期望的结果。此外，附图中描绘的处理并非必需所示的特定顺序或顺次顺序，以实现期望的结果。在某些实现中，多任务和并行处理可能是有利的。

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

Claims (11)

1.一种基于直播的弹幕处理方法，其特征在于，所述方法应用于服务器中，所述方法包括：

对接收的直播视频流进行切割，并将切割得到的视频数据分片存储在第一容器内；

对接收的针对所述直播视频流的弹幕数据流进行切割，并将切割得到的弹幕数据分片存储在第二容器内；

判断所述第一容器或所述第二容器内存储的数据是否触发其对应的预设容器深度阈值；

若是，则获取所述第一容器内所述视频数据分片进行分组后得到的N个视频分组，以及所述第二容器内所述弹幕数据分片进行分组后得到的M个弹幕分组；

将所述N个视频分组包含的视频数据分片与所述M个弹幕分组包含的弹幕数据分片按照时间轴的顺序进行对齐，若某个视频数据分片不存在与之对齐的弹幕数据分片，则将空数据作为与该视频数据分片对齐的弹幕数据分片，将对齐后的所述N个视频分组以及所述M个弹幕分组封装成目标数据包，并将所述目标数据包以目标数据流的形式发送至下层设备中，其中，所述目标数据包中包括N个视频分组以及M个弹幕分组。

2.根据权利要求1所述的方法，其特征在于，所述判断所述第一容器或所述第二容器内存储的数据是否触发其对应的预设容器深度阈值，包括：

针对各视频分组，获取该视频分组中包含的视频数据切片的第一数量，并将最大的第一数量作为所述第一容器的第一深度；

针对各弹幕分组，获取该弹幕分组中包含的弹幕数据切片的第二数量，并将最大的第二数量作为所述第二容器的第二深度；

若所述第一深度达到预设容器深度阈值，则判定所述第一容器内存储的数据触发预设容器深度阈值；

若所述第二深度达到预设容器深度阈值，则判定所述第二容器内存储的数据触发预设容器深度阈值。

3.根据权利要求1所述的方法，其特征在于，各视频数据分片在所述第一容器内具有对应的第一分片编号，各弹幕数据分片在所述第二容器内具有对应的第二分片编号；

所述视频分组或弹幕分组采用如下方式确定：

将各第一分片编号与视频分组数量N进行求余运算，并将余数相同的视频数据分片分类在同一视频分组中，其中，所述视频分组数量N根据所述直播视频流的码率确定；

将各第二分片编号与弹幕分组数量M进行求余运算，并将余数相同的弹幕数据分片分类在同一弹幕分组中，其中，所述弹幕分组数量M根据所述弹幕数据流的码率确定。

4.根据权利要求1或2或3所述的方法，其特征在于，所述下层设备包括CDN服务器、具有上行能力的智能盒子。

5.一种拉流的方法，其特征在于，所述方法应用于拉流设备中，所述方法包括：

从上层设备中获取当前开播的主播的目标数据流，其中，所述目标数据流包括目标数据包，所述目标数据包中包括对齐的N个视频分组以及M个弹幕分组，各视频分组中包括若干视频数据分片，各弹幕分组中包括若干弹幕数据分片，所述N个视频分组包含的视频数据分片与以及所述M个弹幕分组包含的弹幕数据分片按照时间轴的顺序对齐，若某个视频数据分片不存在与之对齐的弹幕数据分片，则与该视频数据分片对齐的为空数据，所述视频数据分片为对直播视频流分割而成，所述弹幕数据分片为对所述直播视频流的弹幕数据流分割而成；

将所述N个视频分组中的视频数据分片合并成直播视频数据；

将所述M个弹幕分组中的弹幕数据分片合并成弹幕数据；

通过显示设备播放所述直播视频数据以及所述弹幕数据。

6.根据权利要求5所述的方法，其特征在于，还包括：

将所述目标数据包下发至下层设备中。

7.根据权利要求5或6所述的方法，其特征在于，所述拉流设备至少包括CDN服务器、具有上行能力的智能盒子。

8.一种基于直播的弹幕处理装置，其特征在于，所述装置应用于服务器中，所述装置包括：

第一切割模块，用于对接收的直播视频流进行切割，并将切割得到的视频数据分片存储在第一容器内；

第二切割模块，用于对接收的针对所述直播视频流的弹幕数据流进行切割，并将切割得到的弹幕数据分片存储在第二容器内；

深度判断模块，用于判断所述第一容器或所述第二容器内存储的数据是否触发其对应的预设容器深度阈值；若是，则调用分组获取模块；

分组获取模块，用于获取所述第一容器内所述视频数据分片进行分组后得到的N个视频分组，以及所述第二容器内所述弹幕数据分片进行分组后得到的M个弹幕分组；

分组处理模块，用于将所述N个视频分组包含的视频数据分片与所述M个弹幕分组包含的弹幕数据分片按照时间轴的顺序进行对齐进行处理，若某个视频数据分片不存在与之对齐的弹幕数据分片，则将空数据作为与该视频数据分片对齐的弹幕数据分片，将对齐后的所述N个视频分组以及所述M个弹幕分组封装成目标数据包，并将所述目标数据包以目标数据流的形式发送至下层设备中，其中，所述目标数据包中包括N个视频分组以及M个弹幕分组。

9.一种拉流装置，其特征在于，所述装置应用于拉流设备中，所述装置包括：

拉流模块，用于从上层设备中获取当前开播的主播的目标数据流，其中，所述目标数据流包括目标数据包，所述目标数据包中包括对齐的N个视频分组以及M个弹幕分组，各视频分组中包括若干视频数据分片，各弹幕分组中包括若干弹幕数据分片，所述N个视频分组包含的视频数据分片与以及所述M个弹幕分组包含的弹幕数据分片按照时间轴的顺序对齐，若某个视频数据分片不存在与之对齐的弹幕数据分片，则与该视频数据分片对齐的为空数据，所述视频数据分片为对直播视频流分割而成，所述弹幕数据分片为对所述直播视频流的弹幕数据流分割而成；

视频分片合并模块，用于将所述N个视频分组中的视频数据分片合并成直播视频数据；

弹幕分片合并模块，用于将所述M个弹幕分组中的弹幕数据分片合并成弹幕数据；

播放模块，用于通过显示设备播放所述直播视频数据以及所述弹幕数据。

10.一种计算机可读存储介质，其上存储有计算机程序，其特征在于，所述程序被处理器执行时实现权利要求1-4和/或5-7任一项所述方法的步骤。

11.一种计算机设备，包括存储器、处理器及存储在存储器上并可在处理器上运行的计算机程序，其特征在于，所述处理器执行所述程序时实现权利要求1-4和/或5-7任一项所述方法的步骤。

Images