CN107071506A - 一种推送弹幕的方法和系统 - Google Patents

Abstract

本发明提供一种推送弹幕的方法和系统，方法包括：接收终端发送的弹幕获取请求，所述弹幕获取请求包括终端上一次显示的最后一条弹幕的生成时刻；以及根据所述弹幕获取请求，向终端发送所述生成时刻之后的弹幕。本发明根据终端发送的终端上一次最后显示的弹幕的生成时刻，向终端发送在所述生成时刻后的弹幕，不同于现有技术中向终端发送播放时间点的弹幕，从而避免了在弹幕较多时用户错过部分弹幕的问题。

Description

一种推送弹幕的方法和系统

技术领域

本发明涉及发送弹幕技术，更具体地，涉及一种推送弹幕的方法和系统。

背景技术

弹幕是一种在观看视频时，以字幕形式呈现的评论与视频同在一个画面中的现象，在视频中大量飘过的评论如密集的炮弹一样，故得名弹幕。弹幕会随着视频的播放在视频画面上实时呈现，这样观看者在观看视频时，能够通过弹幕看到其他观看者和自己对当前播放的视频内容的评论，每一条弹幕都有自己的生成时刻。

在视频的播放过程中，各用户通过终端输入弹幕信息，并由服务器获取，然后服务器将各用户对该视频发表的弹幕信息添加至视频中进行显示。

现有技术的推送弹幕方法，当用户打开直播网页时，终端向服务器发送弹幕获取请求，该弹幕获取请求包括的是视频标识和播放时间点，服务器查询与该视频标识对应，且与播放时间点对应的弹幕反馈给终端。这样就存在几个问题：

1、播放时间点对应的弹幕数量较少，导致直播网页上显示的弹幕数量较少，显得直播间十分冷清。

2、播放时间点对应的弹幕数量较多，导致服务器需要推送的弹幕数量太大，加重了服务器的负担。

对于第二个问题，现有技术采用了设置弹幕数量阈值的方法，简而言之，就是假设播放时间点对应的弹幕数量有1000个，设置弹幕数量的阈值为800个，那么服务器向终端推送800个弹幕，剩余的200的弹幕不再推送，这样虽然减轻了服务器的负担，但用户并没有观看到那200条弹幕，既浪费了弹幕，也导致用户可能错过重要的弹幕。

发明内容

本发明提供一种克服上述问题或者至少部分地解决上述问题的推送弹幕的方法和系统。

根据本发明的一个方面，提供一种推送弹幕的方法，包括：

S1、接收终端发送的弹幕获取请求，所述弹幕获取请求包括终端上一次显示的最后一条弹幕的生成时刻；以及

S2、根据所述弹幕获取请求，向终端发送所述生成时刻之后的弹幕。

优选地，所述步骤S1之前还包括：

S0、接收所述终端在加载直播页面后第一次发送的弹幕获取请求，并记录接收时刻，向所述终端发送所述接收时刻之前一段时间的弹幕。

优选地，弹幕获取请求还包括终端本次计划显示的弹幕条数；

其中，所述步骤S0中向所述终端发送所述接收时刻之前一段时间的弹幕，进一步包括：

基于所述弹幕条数和所述接收时刻，获取第一次要发送的弹幕；以及

向终端发送所述第一次要发送的弹幕。

优选地，所述步骤S2向终端发送所述生成时刻之后的弹幕，进一步包括：

基于所述弹幕条数和所述生成时刻，获取本次要发送的弹幕；以及

向终端发送所述本次要发送的弹幕。

优选地，弹幕获取请求还包括直播页面的标识信息；

其中，所述步骤S0中记录接收时刻之前还包括：

根据所述直播页面的标识信息，识别所述直播页面合法且正在直播。

优选地，基于所述弹幕条数和所述接收时刻，获取第一次要发送的弹幕，进一步包括：

按照弹幕的生成时刻相对于所述接收时刻由远至近的顺序，选取在所述接收时刻之前一段时间内生成的、与所述弹幕条数相等条数的弹幕。

优选地，所述基于所述弹幕条数和所述生成时刻，获取本次要发送的弹幕，进一步包括：

按照弹幕的生成时刻相对于所述生成时刻由近至远的顺序，选取在所述生成时刻之后生成的、与所述弹幕条数相等条数的弹幕。

优选地，所述步骤S1中接收终端发送的弹幕获取请求，进一步包括：定期接收所述终端发送的弹幕获取请求。

根据本发明的另一个方面，还提供一种推送弹幕的系统，包括：

接收请求装置，用于接收终端发送的弹幕获取请求，所述弹幕获取请求包括终端上一次显示的最后一条弹幕的生成时刻；以及

发送弹幕装置，用于根据所述弹幕获取请求，向终端发送所述生成时刻之后的弹幕。

优选地，所述系统还包括：

首次发送弹幕装置，用于接收所述终端在加载直播页面后第一次发送的弹幕获取请求，并记录接收时刻，向所述终端发送所述接收时刻之后的弹幕。

本申请提出了一种推送弹幕的方法和系统，根据终端发送的终端上一次最后显示的弹幕的生成时刻，向终端发送在所述生成时刻后的弹幕，不同于现有技术中向终端发送播放时间点的弹幕，从而避免了在弹幕较多时用户错过部分弹幕的问题。

附图说明

图1为本发明实施例的一种推送弹幕的方法的流程图；

图2为本发明实施例的另一种推送弹幕的方法的流程图；

图3为本发明第三个实施例的推送弹幕的方法的流程图；

图4为本发明实施例的一种推送弹幕的系统的结构框图；

图5为本发明实施例的另一种推送弹幕的系统的结构框图。

具体实施方式

下面结合附图和实施例，对本发明的具体实施方式作进一步详细描述。以下实施例用于说明本发明，但不用来限制本发明的范围。

为了克服现有技术中在弹幕数量过大时，服务器处于自身负荷考虑只能将部分弹幕推送至终端，导致的用户无法观看全部弹幕的问题，本发明提供了一种推送弹幕的方法和系统。

图1示出了本发明实施例的一种推送弹幕的方法流程图，包括：

S1、接收终端发送的弹幕获取请求，所述弹幕获取请求包括终端上一次显示的最后一条弹幕的生成时刻；以及

S2、根据所述弹幕获取请求，向终端发送所述生成时刻之后的弹幕。

例如，终端上一次显示的最后一条弹幕的生成时刻是10点10分，那么像终端发送的弹幕即为10点10分后生成的弹幕，根据终端发送的终端上一次最后显示的弹幕的生成时刻，向终端发送在所述生成时刻后的弹幕，不同于现有技术中向终端发送播放时间点的弹幕，从而避免了在弹幕较多时用户错过部分弹幕的问题。

一般情况下，直播节目的弹幕并不会太多，因此当用户刚进入直播界面时，看到的弹幕也不会太多，就会给用户带来直播节目冷清，没有人气的感觉，因此，为了解决这个问题，图2示出了本发明实施例的另一种推送弹幕的方法的流程图，如图可知，本方法包括：

S0、接收所述终端在加载直播页面后第一次发送的弹幕获取请求，并记录接收时刻，向所述终端发送所述接收时刻之前一段时间的弹幕；

S1、接收终端发送的弹幕获取请求，所述弹幕获取请求包括终端上一次显示的最后一条弹幕的生成时刻；以及

S2、根据所述弹幕获取请求，向终端发送所述生成时刻之后的弹幕。在本实施例中，当终端第一次发送弹幕获取请求时，由于此时并不存在上一次显示的弹幕，因此，根据接收到弹幕获取请求的时间，例如接收时间为10点10分，选取接收时刻之前一段时间的弹幕，比如可以选择10点5分至10点10分这一时间段的弹幕发送给终端，因此用户看到的弹幕是过去一个时间段的弹幕，显然这样看到的弹幕数量要比实时推送的弹幕数量更多，用户也会感觉到直播间很活跃，增强用户的使用粘度。

在一个可选实施例中，弹幕获取请求还包括终端本次计划显示的弹幕条数；

其中，所述步骤S0中向所述终端发送所述接收时刻之前一段时间的弹幕，进一步包括：基于所述弹幕条数和所述接收时刻，获取第一次要发送的弹幕；向终端发送所述第一次要发送的弹幕。

通过综合考虑弹幕条数和接收时刻两个因素来获取第一次要发送的弹幕，能够更灵活地控制弹幕的数量，保证第一次要发送的弹幕的数量不超过服务器的负荷。

同理，在一个可选实施例中，所述步骤S2向终端发送所述生成时刻之后的弹幕，进一步包括：基于所述弹幕条数和所述生成时刻，获取本次要发送的弹幕；向终端发送所述本次要发送的弹幕。

在一个可选实施例中，弹幕条数并不是由终端发送的，而是根据时间段内的总弹幕数生成的，例如，服务器中10点10分至10点11分的弹幕数量共有1000条，但10点11分至10点12分的弹幕数量只有200条，终端每30秒发送一次弹幕获取请求，也即每30秒接收一次弹幕，那么可以将推送的弹幕数量设为较低值，例如200条，使原本2分钟就播放完的弹幕延长至3分钟播放完，延长了弹幕的展示时间，使用户感觉直播更加热闹。当然，即使仍由终端向服务器发送弹幕数量，也可以达到上述的效果，但是由于终端并不清楚服务器存储的不同时间的弹幕数量，只能选取经验值或猜测的弹幕数量，而采用服务器根据不同时间段的总弹幕数量动态调整推送的弹幕数量，显然更利于用户接收到活跃度更长的弹幕。

在一个事实例中，弹幕获取请求还包括直播页面的标识信息；

其中，所述步骤S0中记录接收时刻，之前还包括：

根据所述直播页面的标识信息，识别所述直播页面合法且正在直播。如果识别直播页面不合法或没在直播，则向终端返回错误报告，提醒终端当前直播页面不合法或者没在直播。

在一个可选实施例中，基于所述弹幕条数和所述接收时刻，获取第一次要发送的弹幕，进一步包括：

按照弹幕的生成时刻相对于所述接收时刻由远至近的顺序，选取在所述接收时刻之前一段时间内生成的与所述弹幕条数相等条数的弹幕。

在一个可选实施例中，所述基于所述弹幕条数和所述生成时刻，获取本次要发送的弹幕，进一步包括：

按照弹幕的生成时刻相对于所述生成时刻由近至远的顺序，选取在所述生成时刻之后生成的、与所述弹幕条数相等条数的弹幕。例如，终端上一次显示的最后一条弹幕的生成时刻是10点10分0秒，则选取在10点10分0秒之后生成的弹幕，同时按照时间上由近至远的顺序选择，依次选取10点10分1秒，10点10分2秒、…直到选取的弹幕数量满足弹幕获取请求中的弹幕数量。

在一个可选实施例中，如果弹幕获取请求中的弹幕数量大于服务器中保存的可推送的弹幕数量，则按照可推送的弹幕数量进行推送，例如，弹幕获取请求中的弹幕数量为100条，但服务器中保存的可推送的弹幕数量只有80条，那么就向终端推送80条弹幕。

在一个可选实施例中，所述步骤S1中接收终端发送的弹幕获取请求，进一步包括：定期接收所述终端发送的弹幕获取请求。这样设置的好处在于不会对服务器造成突然的负荷，有利于服务器的安全。

为了更好地阐述本发明的设计思路，下面结合具体实施例进行描述，图3示出了本发明第三个实施例的流程示意图，如图可知，包括：

步骤1、进入直播页面，终端每隔5秒请求服务器的弹幕接口，请求参数包括：roomid(直播页面的标识信息)、count(弹幕条数)以及page context(终端上一次显示的最后一条弹幕的生成时刻)；

步骤2、根据参数roomid判断房间是否存在，防止恶意请求弹幕接口，如果不存在，则通过JSON的方式返回“房间不存在”给终端，若存在，则进行步骤3；

步骤3、根据参数roomid判断房间是否开播，防止恶意请求弹幕接口，如果房间没有播，则通过JSON的方式返回“房间未开播”给终端，若存在，则进行步骤4；

步骤4、判断参数page_context是否存在，若不存在，则进行步骤5，若存在，则跳转至步骤6；

步骤5、向终端以JSON的方式推送5分钟之前的弹幕，随后结束本次推送过程；

步骤6、查询参数page_context携带的终端上一次最后显示的弹幕的生成时刻，向终端以JSON方式推送生成时刻之后的弹幕，随后结束本次推送过程。

具体地，步骤1包括：在getDanmu方法中，异步去请求服务器的弹幕接口getDanMuList，请求参数roomid(房间id)、count(一次取弹幕条数)、page_context。

具体地，步骤2包括：根据参数roomid去服务器缓存数据库中查询房间信息，如果房间信息不存在则说明用户请求的roomid是非法的，这样有效的防止恶意请求弹幕接口。如果房间信息不存在，则通过JSON的方式返回”房间不存在”给终端。

具体地，步骤3包括：根据参数roomid去服务器缓存数据库中查询房间的开播状态，如果房间是未开播的，则不需要返回给用户弹幕列表，这样有效的防止恶意请求弹幕接口。如果房间没有开播，则通过JSON的方式返回”房间未开播”给终端。

具体地，步骤5包括：根据弹幕获取请求的接收时间找到今天的弹幕数据库，根据roomid去今天的弹幕数据库中找到对应的房间弹幕集合，最后取出大于5分钟前的时间戳的count条弹幕数据，然后通过JSON方式返回弹幕数据给终端。

具体地，步骤6包括：。根据当前时间戳找到今天的弹幕数据库，根据roomid去今天的弹幕数据库中找到对应的房间弹幕集合，最后取出大于page_context之后的时间戳的count条弹幕数据，然后通过JSON方式返回弹幕数据给终端。

因为是HTML5形式的终端发出的请求，该请求消化本地资源，占用服务器资源低，避免了用WebSocket增加服务器资源的问题。

同时，保护针对移动端HTML5获取弹幕通过JS+PHP后端技术，开发周期短、开发效率高，如果用WebSocket开发开发周期很长。

图4示出了本发明实施例提供的一种推送弹幕的系统的结构框图，包括：

接收请求装置，用于接收终端发送的弹幕获取请求，所述弹幕获取请求包括终端上一次最后显示的弹幕的生成时刻；以及

发送弹幕装置，用于根据所述弹幕获取请求，向终端发送所述生成时刻之后的弹幕。

图5示出了本发明实施例的另一种推送弹幕的系统的结构框图，除了接收请求装置和发到弹幕装置之外，还包括：

首次发送弹幕装置，用于接收所述终端在加载直播页面后第一次发送的弹幕获取请求，并记录接收时刻，向所述终端发送所述接收时刻之后的弹幕。

在一个可选实施例中，弹幕获取请求还包括终端本次显示的弹幕条数；

首次发生弹幕装置还用于：基于所述弹幕条数和所述接收时刻，获取第一次要发送的弹幕；以及

向终端发送所述第一次要发送的弹幕。

同理，发送弹幕装置还用于：基于所述弹幕条数和所述生成时刻，获取本次要发送的弹幕；以及

向终端发送所述本次要发送的弹幕。

在一个可选实施例中，弹幕获取请求还包括直播页面的标识信息；

首次发生弹幕装置还用于：根据所述直播页面的标识信息，识别所述直播页面合法且正在直播。

在一个可选实施例中，首次发生弹幕装置具体用于：按照弹幕的生成时刻相对于所述接收时刻由远至近的顺序，选取在所述接收时刻之前一段时间内生成的与所述弹幕条数相等条数的弹幕。

在一个可选实施例中，发送弹幕装置具体用于：按照弹幕的生成时刻相对于所述生成时刻由近至远的顺序，选取在所述生成时刻之后生成的与所述弹幕条数相等条数的弹幕。

最后，本申请的方法仅为较佳的实施方案，并非用于限定本发明的保护范围。凡在本发明的精神和原则之内，所作的任何修改、等同替换、改进等，均应包含在本发明的保护范围之内。

Claims (10)

1.一种推送弹幕的方法，其特征在于，包括：

S1、接收终端发送的弹幕获取请求，所述弹幕获取请求包括终端上一次显示的最后一条弹幕的生成时刻；以及

S2、根据所述弹幕获取请求，向终端发送所述生成时刻之后的弹幕。

2.如权利要求1所述的方法，其特征在于，所述步骤S1之前还包括：

S0、接收所述终端在加载直播页面后第一次发送的弹幕获取请求，并记录接收时刻，向所述终端发送所述接收时刻之前一段时间的弹幕。

3.如权利要求2所述的方法，其特征在于，弹幕获取请求还包括终端本次计划显示的弹幕条数；

其中，所述步骤S0中向所述终端发送所述接收时刻之前一段时间的弹幕，进一步包括：

基于所述弹幕条数和所述接收时刻，获取第一次要发送的弹幕；以及

向终端发送所述第一次要发送的弹幕。

4.如权利要求3所述的方法，其特征在于，所述步骤S2向终端发送所述生成时刻之后的弹幕，进一步包括：

基于所述弹幕条数和所述生成时刻，获取本次要发送的弹幕；以及

向终端发送所述本次要发送的弹幕。

5.如权利要求2所述的方法，其特征在于，弹幕获取请求还包括直播页面的标识信息；

其中，所述步骤S0中记录接收时刻之前还包括：

根据所述直播页面的标识信息，识别所述直播页面合法且正在直播。

6.如权利要求3所述的方法，其特征在于，基于所述弹幕条数和所述接收时刻，获取第一次要发送的弹幕，进一步包括：

按照弹幕的生成时刻相对于所述接收时刻由远至近的顺序，选取在所述接收时刻之前一段时间内生成的、与所述弹幕条数相等条数的弹幕。

7.如权利要求4所述的方法，其特征在于，所述基于所述弹幕条数和所述生成时刻，获取本次要发送的弹幕，进一步包括：

按照弹幕的生成时刻相对于所述生成时刻由近至远的顺序，选取在所述生成时刻之后生成的、与所述弹幕条数相等条数的弹幕。

8.如权利要求1所述的方法，其特征在于，所述步骤S1中接收终端发送的弹幕获取请求，进一步包括：定期接收所述终端发送的弹幕获取请求。

9.一种推送弹幕的系统，其特征在于，包括：

接收请求装置，用于接收终端发送的弹幕获取请求，所述弹幕获取请求包括终端上一次显示的最后一条弹幕的生成时刻；以及

发送弹幕装置，用于根据所述弹幕获取请求，向终端发送所述生成时刻之后的弹幕。

10.如权利要求9所述的系统，其特征在于，包括：

首次发送弹幕装置，用于接收所述终端在加载直播页面后第一次发送的弹幕获取请求，并记录接收时刻，向所述终端发送所述接收时刻之后的弹幕。