CN109831675B - 一种直播平台的活动处理方法、服务器以及可读存储介质 - Google Patents

Abstract

本申请提供了一种直播平台的活动处理方法、服务器以及可读存储介质，用于提高赛事直播节目的用户活跃度以及用户流量。本申请提供的方法述方法应用于直播平台的服务器，包括：服务器接收第一UE发送的支持弹幕，支持弹幕用于指示用户通过赛事直播节目的弹幕助威活动发起的对各参赛方的支持；服务器根据第一UE发送的支持弹幕，统计各参赛方的支持结果；服务器根据各参赛方的支持结果，确定处于最低序列的目标参赛方；服务器向播放赛事直播节目的第二UE发送目标参赛方的支持结果，以使得第二UE在弹幕助威活动中加载目标参赛方的支持结果。

Description

一种直播平台的活动处理方法、服务器以及可读存储介质

技术领域

本申请涉及直播领域，尤其涉及一种直播平台的活动处理方法、服务器以及可读存储介质。

背景技术

近几年来，由于直播节目具有互动性强、观看方便的特点，直播产业蓬勃发展，用户通过用户设备(User Equipment，UE)，可观看直播平台提供的直播节目，在丰富人们的生活方式的同时，也带动了互联网公司的迅速发展。

而对于直播平台，可通过相关的变现手段将用户流量转化为现金收益，例如广告、销售、流量分成或者增值服务等流量变现手段，在变现手段一定的情况下，高用户流量对于直播平台来说，显然意味着可带来高收益，因此，用户流量直接影响着平台的发展。

也因此，如何提高用户流量，成为直播平台在公司发展决策中的一大重要环节。

发明内容

本申请提供了一种直播平台的活动处理方法、服务器以及可读存储介质，用于提高赛事直播节目的用户活跃度以及用户流量。

第一方面，本申请提供一种直播平台的活动处理方法，方法应用于直播平台的服务器，方法包括：

服务器接收第一UE发送的支持弹幕，支持弹幕用于指示用户通过赛事直播节目的弹幕助威活动发起的对各参赛方的支持；

服务器根据第一UE发送的支持弹幕，统计各参赛方的支持结果；

服务器根据各参赛方的支持结果，确定处于最低序列的目标参赛方；

服务器向播放赛事直播节目的第二UE发送目标参赛方的支持结果，以使得第二UE在弹幕助威活动中加载目标参赛方的支持结果。

可选的，服务器根据第一UE发送的支持弹幕，统计各参赛方的支持结果包括：

服务器根据第一UE发送的支持弹幕，以预设更新频率统计各参赛方的支持结果；

服务器向播放赛事直播节目的第二UE发送目标参赛方的支持结果包括：

服务器以预设更新频率向第二UE发送目标参赛方的支持结果。

可选的，预设更新频率为1秒更新1次。

可选的，服务器根据第一UE发送的支持弹幕，统计各参赛方的支持结果包括：

服务器确定第一UE发送的支持弹幕对应的弹幕解析协议；

服务器根据弹幕解析协议，从第一UE发送的支持弹幕中解析出各UE对应的支持结果；

服务器根据第一UE中各UE对应的支持结果，统计各参赛方的支持结果。

可选的，弹幕解析协议包括无状态传输隧道(Stateless Transport Tunneling，STT)解析协议、对象简谱(JavaScript Object Notation,JSON)解析协议以及协议缓冲器(Protocol Buffer，PB)解析协议中的任意一种。

可选的，当目标参赛方的支持结果为目标参赛方的支持率时，方法还包括：

服务器计算目标参赛方的实际支持票数与其他参赛方的实际支持票数的差值；

服务器根据差值、目标参赛方的实际支持票数以及其他参赛方的实际支持票数，确定目标参赛方的增长票数的第一加权系数以及其他参赛方的增长票数的第二加权系数；

服务器根据第一加权系数、第二加权系数以及支持率计算公式，计算目标参赛方的支持率，支持率计算公式为：

其中，A用于指示目标参赛方的实际支持票数，A'用于指示目标参赛方的增长票数，X用于指示第一加权系数，B_i用于指示其他参赛方的实际支持票数，B_i'用于指示其他参赛方的增长票数，Y_i用于指示第二加权系数，Q用于指示目标参赛方的支持率。

第二方面，本申请提供一种直播平台的服务器，服务器包括：

接收单元，用于接收第一UE发送的支持弹幕，支持弹幕用于指示用户通过赛事直播节目的弹幕助威活动发起的对各参赛方的支持；

统计单元，用于根据第一UE发送的支持弹幕，统计各参赛方的支持结果；

确定单元，用于根据各参赛方的支持结果，确定处于最低序列的目标参赛方；

发送单元，用于向播放赛事直播节目的第二UE发送目标参赛方的支持结果，以使得第二UE在弹幕助威活动中加载目标参赛方的支持结果。

可选的，统计单元具体用于：

根据第一UE发送的支持弹幕，以预设更新频率统计各参赛方的支持结果；

发送单元具体用于：

以预设更新频率向第二UE发送目标参赛方的支持结果。

可选的，预设更新频率为1秒更新1次。

可选的，统计单元具体用于：

确定第一UE发送的支持弹幕对应的弹幕解析协议；

根据弹幕解析协议，从第一UE发送的支持弹幕中解析出各UE对应的支持结果；

根据第一UE中各UE对应的支持结果，统计各参赛方的支持结果。

可选的，弹幕解析协议包括STT解析协议、JSON解析协议以及PB解析协议中的任意一种。

可选的，当目标参赛方的支持结果为目标参赛方的支持率时，服务器还包括：

计算单元，用于计算目标参赛方的实际支持票数与其他参赛方的实际支持票数的差值；

确定单元，还用于根据差值、目标参赛方的实际支持票数以及其他参赛方的实际支持票数，确定目标参赛方的增长票数的第一加权系数以及其他参赛方的增长票数的第二加权系数；

计算单元，还用于根据第一加权系数、第二加权系数以及支持率计算公式，计算目标参赛方的支持率，支持率计算公式为：

其中，A用于指示目标参赛方的实际支持票数，A'用于指示目标参赛方的增长票数，X用于指示第一加权系数，B_i用于指示其他参赛方的实际支持票数，B_i'用于指示其他参赛方的增长票数，Y_i用于指示第二加权系数，Q用于指示目标参赛方的支持率。

第三方面，本申请提供一种直播平台的服务器，包括处理器，处理器用于执行存储器中存储的计算机程序时实现如上述第一方面的直播平台的活动处理方法的任一步骤。

第四方面，本申请提供一种可读存储介质，其上存储有计算机程序，计算机程序被处理器执行时实现如上述第一方面的直播平台的活动处理方法的任一步骤。

从以上技术方案可以看出，本申请具有以下优点：

直播平台可在UE向用户发起赛事直播节目的弹幕助威活动，供用户为支持的参赛方发起支持弹幕，服务器在接收到第一UE发送的支持弹幕时，可统计得到各参赛方的支持结果，此时，服务器可从中确定处于最低序列的目标参赛方，再向播放赛事直播节目的第二UE发送该目标参赛方的支持结果，以使得第二UE在弹幕助威活动中加载弹幕助威活动中目标参赛方的支持结果，由于在弹幕助威活动中，直播平台以处于最低序列的参赛方为目标进行支持结果的更新的，从而，第二UE的用户更可直观地看到目标参赛方的最新活动情况，结合包括自己在内的用户所发起的支持结果，继续观看赛事直播节目，尤其是当看到自身喜欢的参赛方处于落后状态还会进一步地参与支持弹幕的发送，不仅便于用户的参与，且由于弹幕助威活动的弹幕特性，拉近了赛事直播节目与观众之间的距离，使得用户进一步地可获得参与感，在该弹幕助威活动的运营下，可大幅度调动用户的观众参与体验以及节目观看体验，从而提高赛事直播节目的用户活跃度以及用户流量，进而提高直播平台的用户活跃度以及用户流量。

附图说明

图1示出了本申请提供的直播平台的活动处理方法的一种流程示意图；

图2示出了本申请提供的直播平台的活动处理方法的又一种流程示意图；

图3示出了本申请提供的直播平台的活动处理方法的又一种流程示意图；

图4示出了本申请提供的直播平台的活动处理方法的又一种流程示意图；

图5示出了本申请提供的直播平台的服务器的一种结构示意图；

图6示出了本申请提供的直播平台的服务器的又一种结构示意图。

具体实施方式

本申请提供了一种直播平台的活动处理方法、服务器以及可读存储介质，用于提高赛事直播节目的用户活跃度以及用户流量。

下面将结合本申请实施例中的附图，对本申请实施例中的技术方案进行清楚、完整地描述，显然，所描述的实施例仅仅是本申请一部分实施例，而不是全部的实施例。基于本申请中的实施例，本领域技术人员在没有作出创造性劳动前提下所获得的所有其他实施例，都属于本申请保护的范围。

本申请的说明书和权利要求书及上述附图中的术语“第一”、“第二”等是用于区别类似的对象，而不必用于描述特定的顺序或先后次序。应该理解这样使用的数据在适当情况下可以互换，以便这里描述的实施例能够以除了在这里图示或描述的内容以外的顺序实施。此外，术语“包括”和“具有”以及他们的任何变形，意图在于覆盖不排他的包含，例如，包含了一系列步骤或模块的过程、方法、***、产品或设备不必限于清楚地列出的那些步骤或模块，而是可包括没有清楚地列出的或对于这些过程、方法、产品或设备固有的其它步骤或模块。在本申请中出现的对步骤进行的命名或者编号，并不意味着必须按照命名或者编号所指示的时间/逻辑先后顺序执行方法流程中的步骤，已经命名或者编号的流程步骤可以根据要实现的技术目的变更执行次序，只要能达到相同或者相类似的技术效果即可。

本申请中所出现的模块的划分，是一种逻辑上的划分，实际应用中实现时可以有另外的划分方式，例如多个模块可以结合成或集成在另一个***中，或一些特征可以忽略，或不执行，另外，所显示的或讨论的相互之间的耦合或直接耦合或通信连接可以是通过一些接口，模块之间的间接耦合或通信连接可以是电性或其他类似的形式，本申请中均不作限定。并且，作为分离部件说明的模块或子模块可以是也可以不是物理上的分离，可以是也可以不是物理模块，或者可以分布到多个电路模块中，可以根据实际的需要选择其中的部分或全部模块来实现本申请方案的目的。

首先，在介绍本申请之前，需要说明的是，本申请提供的直播平台的服务器，用于处理或者协助处理直播平台为用户提供的弹幕助威活动，其中，服务器通过应用本申请提供的活动处理方法，以进一步提高直播平台的用户流量。服务器具体可以为一台服务器设备，或者具体也可以为服务器设备集群，具体在此不做限定。

本申请提供的UE包括台式电脑、笔记本电脑、智能手机或者平板电脑等可访问直播平台的设备，UE包括显示屏、扬声器结构等结构，向用户显示直播节目，供用户观看。其中，UE可使用Mac OS、Windows、Android、IOS、Tizen、Ubuntu或者Windows Phone等不同类型的操作***，具体在此不做限定。

在本申请中，UE可通过网页(Web)应用、直播平台对应的客户端应用(Application，APP)、公众号应用或者小程序应用等方式访问直播平台，具体在此不做限定。

下面，则开始对本申请提供的直播平台的活动处理方法进行详细介绍。

参阅图1，图1示出了本申请提供的活动处理方法的一种流程示意图，具体的，本申请提供的直播平台的活动处理方法可包括如下步骤：

步骤S101，服务器接收第一UE发送的支持弹幕；

其中，支持弹幕用于指示用户通过赛事直播节目的弹幕助威活动发起的对各参赛方的支持。

容易理解，弹幕，为在视频节目的播放过程中在节目画面中弹出的评论性字幕，具有摆脱与节目画面独立的评论区的限制，以及可在不同时间又在同一节目画面中发送弹幕的特性，可给观众带来一种实时互动的参与感，提高视频节目的观看体验；而在直播节目中弹出的弹幕，由于其直播方式的特性，则为当前的节目观众所发出，因此在发射时间上具有更高的同步性。

当直播平台为用户提供赛事直播节目时，可引入本申请涉及的弹幕助威活动。直播平台，通过弹幕机制，在赛事直播节目的节目画面中***弹幕助威活动的内容，供用户便捷地选择自身喜欢的参赛方并发起对应的支持弹幕，参与弹幕助威活动。

直播平台后台的服务器，即可接收到多个用户通过UE发起的支持弹幕。

其中，参赛方，可以为参赛队伍，也可以为个人参赛者，具体在此不做限定。

步骤S102，服务器根据第一UE发送的支持弹幕，统计各参赛方的支持结果；

服务器在接收到多个用户通过UE发起的支持弹幕后，即可从支持弹幕中确定对应用户对参赛方的支持，并加以统计。

步骤S103，服务器根据各参赛方的支持结果，确定处于最低序列的目标参赛方；

在本申请中，为提高赛事直播节目的趣味性，弹幕助威活动以排序中处于最低序列的参赛方为目标，进行支持数据的更新。

从而，在统计得到各参赛方的支持结果后，服务器可根据各参赛方支持结果，对其进行排序，其中，可以以单位时间内支持弹幕的增长速度、总支持弹幕量、支持用户转变支持参赛方的累计次数或者删除同个用户的重复支持弹幕后的总支持弹幕量等作为排序规则的基础，确定排序中处于最低序列的参赛方为目标参赛方。

步骤S104，服务器向播放赛事直播节目的第二UE发送目标参赛方的支持结果，以使得多个UE在弹幕助威活动中加载目标参赛方的支持结果。

当确定处于最低序列的参赛方为目标参赛方后，服务器即可将目标参赛方的支持结果通过广播方式发送至播放赛事直播节目的UE，从而，接收到的UE即可在弹幕助威活动中加载该目标参赛方的支持结果，更新目标参赛方的支持情况。

观看赛事直播节目的用户(不仅包括通过第一UE发起支持弹幕的用户，也包括还未通过UE发起支持弹幕的用户)在看到目标参赛方在更新后的支持结果后，可更为直观地看到目标参赛方最新活动情况，结合包括自己在内的用户所发起的支持结果，继续观看赛事直播节目，尤其是当看到自身喜欢的参赛方处于落后状态，还可积极参与支持弹幕的发送，从而达到提高赛事直播节目的趣味性以及竞争效果的目的。

应当理解，在本申请中，赛事直播节目所对应的赛事，不仅可以为官方组织的竞技类游戏的赛事活动，也可以延伸至人为定义竞争元素的直播内容，例如线上游戏中主播与路人谁的游戏角色存活到最后、线下展会中哪个摊位更受青睐、美食投票等等，以此类推，具体在此不对赛事直播节目的具体节目以及赛事内容加以限制。

进一步的，对于在赛事直播节目引入弹幕助威活动，除了可由直播平台的工作人员触发，以通过弹幕运营机制提高赛事直播节目的用户活跃度以及用户流量外；或者，也可由节目主播触发；或者，还可根据当前赛事直播节目的所处板块、节目内容或者主播类型等元素，以实现服务器的自动触发，具体在此不做限定。

从上述可看出，直播平台可在UE向用户发起赛事直播节目的弹幕助威活动，供用户为支持的参赛方发起支持弹幕，服务器在接收到第一UE发送的支持弹幕时，可统计得到各参赛方的支持结果，此时，服务器可从中确定处于最低序列的目标参赛方，再向播放赛事直播节目的第二UE发送该目标参赛方的支持结果，以使得第二UE在弹幕助威活动中加载弹幕助威活动中目标参赛方的支持结果，由于在弹幕助威活动中，直播平台以处于最低序列的参赛方为目标进行支持结果的更新的，从而，第二UE的用户更可直观地看到目标参赛方的最新活动情况，结合包括自己在内的用户所发起的支持结果，继续观看赛事直播节目，尤其是当看到自身喜欢的参赛方处于落后状态还会进一步地参与支持弹幕的发送，不仅便于用户的参与，且由于弹幕助威活动的弹幕特性，拉近了赛事直播节目与观众之间的距离，使得用户进一步地可获得参与感，在该弹幕助威活动的运营下，可大幅度调动用户的观众参与体验以及节目观看体验，从而提高赛事直播节目的用户活跃度以及用户流量，进而提高直播平台的用户活跃度以及用户流量。

此外，在实际应用中，由于仅更新处于最低序列的参赛方的支持结果，因此，不仅服务器的数据处理量更加的精简化，服务器向UE发送的数据量也更小，UE也可更新更少的数据，减少UE的负担，从而可保证UE运行上的流畅性，这对于直播平台应用的用户使用体验来说，也是非常有利的。

可以理解，在实际应用中，本申请还可有进一步的优化，以便提高赛事直播节目的用户活跃度以及用户流量，例如：

参阅图2，图2示出了本申请提供的直播平台的活动处理方法的又一种流程示意图，具体的，本申请提供的直播平台的活动处理方法还可包括如下步骤：

步骤S201，用户向第一UE发起支持弹幕；

当直播平台为用户提供赛事直播节目时，可引入本申请涉及的弹幕助威活动，供用户便捷地选择自身喜欢的参赛方并发起对应的支持弹幕，参与弹幕助威活动。

步骤S202，第一UE向服务器发送支持弹幕；

第一UE在获取到支持弹幕后，可向服务器上报。

步骤S203，服务器根据第一UE发送的支持弹幕，以预设更新频率统计各参赛方的支持结果；

可以理解，在实际应用中，为便于简化处理流程，以及减轻负担，在接收到第一UE发送的支持弹幕后，服务器可进行存储，并引入预设更新频率，每隔一端时间再进行各参赛方的支持结果的统计、刷新。

其中，服务器可使用远程数据服务-哈希(Remote Dictionary Server-hash，Redis Hash)结构存储各参赛方的支持结果，例如：

Key	Field	Value
			support:$(rid)	$(team_id)	$(count)

$(rid)–直播间id；

$(team_id)–参赛队伍id；

$(count)–用户支持人数。

此外，为便于弹幕助威活动的应用，其涉及的支持弹幕，除了可使用与正常弹幕一样的格式，还可使用专门的格式，以便保证支持弹幕的信息独立性，更便于服务器的管理以及解析。

因此，参阅图3示出的本申请提供的直播平台的活动处理方法的又一种流程示意图，服务器根据第一UE发送的支持弹幕，统计各参赛方的支持结果具体还可包括：

步骤S301，服务器确定第一UE发送的支持弹幕对应的弹幕解析协议；

可以理解，支持弹幕的格式除了可以为与服务器事先约定的格式，或者也可当接收到支持弹幕时，由服务器进行解析，并确定其格式。

确定弹幕的格式时，服务器即可确定其对应的弹幕解析格式。

具体的，弹幕解析协议可以为无状态传输隧道(Stateless TransportTunneling，STT)协议、对象简谱(JavaScript Object Notation,JSON)协议以及协议缓冲器(Protocol Buffer，PB)协议(或者说protobuffer协议)，对应的，其支持弹幕关于支持结果的内容依次可通过下述内容表示：

当支持弹幕为STT格式时，服务器可通过字符串分隔的方式取出其中的每个字段，进行解析；

或者，当支持弹幕为JSON格式时，服务器可使用专门的JSON解析库进行解析；

或者，当支持弹幕为protobuffer格式时，服务器可使用protobuffer自带的解析函数进行解析。

当然，支持弹幕也可使用其他的数据格式，具体在此不做限定。

在解析支持弹幕的过程中，当服务器解析失败时，则可进行抛弃处理，并还可校验用户支持的参赛方是否正确，若错误也可进行抛弃处理。

步骤S302，服务器根据弹幕解析协议，从第一UE发送的支持弹幕中解析出各UE对应的支持结果；

确定弹幕解析协议后，服务器即可从接收到的支持弹幕中，解析得到各UE对应的支持结果。

步骤S303，服务器根据第一UE中各UE对应的支持结果，统计各参赛方的支持结果。

解析出各UE对应的支持结果后，服务器即可进行统计，得到各参赛方的支持结果。

步骤S204，服务器根据各参赛方的支持结果，确定处于最低序列的目标参赛方；

在统计得到各参赛方的支持结果后，服务器可进行排序，并从该排序中确定处于最低序列的参赛方为目标参赛方。

步骤S205，服务器以预设更新频率向第二UE发送目标参赛方的支持结果；

与上述更新各参赛方的支持结果对照的，服务器也以该预设更新频率向第二UE发送目标参赛方的支持结果，以便服务器与第二UE之间信令的发送成本。

在实际应用中，该预设更新频率，具体可以为0.5秒更新1次、1秒更新1次、1.5秒更新1次等频率，可随实际情况设置，具体在此不做限定。

其中，优选的为每1秒更新1次，可以理解，在实际应用中发现，目标参赛方的支持结果，以每1秒更新1次，不仅更加符合用户肉眼的观察情况，且在数据上的刷新上，也符合实际情况，较快或者较慢的刷新频率，也影响在数据上的呈现效果。

步骤S206，第二UE在弹幕助威活动中加载目标参赛方的支持结果。

第二UE接收到目标参赛方的支持结果后，即可在弹幕助威活动中加载该目标参赛方的支持结果，更新目标参赛方的支持情况。

其中，与上述第一UE发送出的支持弹幕类似的，服务器发送出的目标参赛方的支持结果也可使用同样的数据格式，从而可使用相同的数据解析格式进行解析，并在弹幕助威活动中加载该目标参赛方的支持结果。

具体的，目标参赛方的支持结果可包括目标参赛方的支持票数、目标参赛方的支持率、目标参赛方支持票数的增长票数以及目标参赛方的支持率的增长率中的至少一个，可随实际情况设置，具体在此不做限定。

以一组实例参数为例：

1、开始：队伍A、B的票数都为0；

2、第1秒时两队伍的支持结果：队伍A票数为10，队伍B票数为15；

3、第二UE在弹幕助威活动中，加载两队伍的实际票数；

4、第2秒时两队伍的支持结果：队伍A票数增加5，队伍B票数增加2；

5、服务器确定队伍A为目标队伍，第二UE在弹幕助威活动中，加载队伍A的实际票数15，保持队伍B的票数仍为第1秒的15…。

从而，第二UE在弹幕助威活动中，在初始加载两队伍的实际票数之后，后续只更新票数少的一方，不仅可防止两队伍的支持数据呈现一边倒的情况，也可调动各用户参与活动的积极性，提高赛事直播节目的趣味性以及竞争效果。

此外，在防止两队伍的支持数据呈现一边倒的情况的基础上，为便于在数据呈现上为用户营造更为紧张的比赛氛围，发送至第二UE向用户所呈现的目标参赛方的支持结果，还可进行放大式调节，以缩小目标参赛方和其他参赛方的差距。

在该放大式调节的过程中，为实现更为灵活的放大式调节，参阅图4示出的本申请提供的直播平台的活动处理方法的又一种流程示意图，以支持结果为支持率为例，具体的调节处理可包括如下步骤：

步骤S401，服务器计算目标参赛方的实际支持票数与其他参赛方的实际支持票数的差值；

可以理解，动态式调节其加权系数，可将目标参赛方的实际支持票数与其他参赛方的实际支持票数的差值作为放大式调节的基准。

步骤S402，服务器根据差值、目标参赛方的实际支持票数以及其他参赛方的实际支持票数，确定目标参赛方的增长票数的第一加权系数以及其他参赛方的增长票数的第二加权系数；

可以理解，加权系数可与差距程度成正比，为此，根据差值与目标参赛方的实际支持增长票数的比值，即可确定目标参赛方与其他参赛方的差距程度，再根据预设阶梯式或者预设线性式的放大规则，确定第一加权系数以及第二加权系数，其中，第一加权系数与第二加权系数随实际调节，具体在此不做限定。

以各参赛方的总支持弹幕量从大到小的排序规则为例，此时目标参赛方的支持票数小于其他参赛方的支持票数，第一加权系数可大于第二加权系数，差值与目标参赛方的实际支持票数的比值越大，则第一加权系数越大，第二加权系数越小，通过对两者进行不同程度的放大，从而为用户缩小目标参赛方和其他参赛方的差距。

类似的，若排序规则为各参赛方的总支持弹幕量从小到大进行排序，此时则目标参赛方的支持票数大于其他参赛方的支持票数，第一加权系数可小于第二加权系数，差值与目标参赛方的实际支持票数的比值越大，则第一加权系数越小，第二加权系数越大，通过对两者进行不同程度的放大，从而为用户缩小其他参赛方和目标参赛方的差距。

当然，在实际应用中，优选的，以排序中处于落后状态的参赛方作为目标参赛方，更有利于营造助于落后状态的目标参赛方的追赶场景，从而更便于调动用户的观众参与体验以及节目观看体验。

步骤S403，服务器根据第一加权系数、第二加权系数以及支持率计算公式，计算目标参赛方的支持率，支持率计算公式为：

其中，A用于指示目标参赛方的实际支持票数，A'用于指示目标参赛方的增长票数，X用于指示第一加权系数，B_i用于指示其他参赛方的实际支持票数，B_i'用于指示其他参赛方的增长票数，Y_i用于指示第二加权系数，Q用于指示目标参赛方的支持率。

在得到第一加权系数以及第二加权系数后，即可根据支持率计算公式完成放大式调节，计算得到可向用户呈现的目标参赛方的支持率。

从上述可看出，放大式调节针对的是单位时间内各参赛方的增长票数，即加权系数针对的是对应的参赛方的增长票数，而在实际应用中，加权系数也可直接针对各参赛方的总票数，以进行放大式调节。

此外，在上述中已提及第一加权系数大于第二加权系数的情况，因此，在A小于B_i的基础上，经过放大式调节后，(A+A'*X)还可能从小于(B_i+B_i'Y_i)，转变成等于或者大于(B_i+B_i'Y_i)。

当然，为减少最终支持率的数据变动范围，以及减少服务器的计算工作量，还可限定放大式调节的放大范围，以上述的支持率计算公式为例，还可将公式进一步优化为：

类似的，当第一加权系数小于第二加权系数时，在A大于Bi的基础上，经过放大式调节后，(A+A'*X)还可能从大于(B_i+B_i'Y_i)，转变成等于或者小于(B_i+B_i'Y_i)。

上述的支持率计算公式也可进一步优化为：

以上是对本申请提供的直播平台的活动处理方法的介绍，下面开始介绍本申请提供的直播平台的服务器。

参阅图5，图5示出了本申请提供的直播平台的服务器的一种结构示意图，具体的，本申请提供的直播平台的服务器可包括如下结构：

接收单元501，用于接收第一UE发送的支持弹幕；

其中，支持弹幕用于指示用户通过赛事直播节目的弹幕助威活动发起的对各参赛方的支持；

统计单元502，用于根据第一UE发送的支持弹幕，统计各参赛方的支持结果；

确定单元503，用于根据各参赛方的支持结果，确定处于最低序列的目标参赛方；

发送单元504，用于向播放赛事直播节目的第二UE发送目标参赛方的支持结果，以使得第二UE在弹幕助威活动中加载目标参赛方的支持结果。

可选的，统计单元502具体用于：

根据第一UE发送的支持弹幕，以预设更新频率统计各参赛方的支持结果；

发送单元504具体用于：

以预设更新频率向第二UE发送目标参赛方的支持结果。

可选的，预设更新频率为1秒更新1次。

可选的，统计单元502具体用于：

确定第一UE发送的支持弹幕对应的弹幕解析协议；

根据弹幕解析协议，从第一UE发送的支持弹幕中解析出各UE对应的支持结果；

根据第一UE中各UE对应的支持结果，统计各参赛方的支持结果。

可选的，弹幕解析协议包括STT解析协议、JSON解析协议以及PB解析协议中的任意一种。

可选的，当目标参赛方的支持结果为目标参赛方的支持率时，服务器还包括：

计算单元505，用于计算目标参赛方的实际支持票数与其他参赛方的实际支持票数的差值；

确定单元503，还用于根据差值、目标参赛方的实际支持票数以及其他参赛方的实际支持票数，确定目标参赛方的增长票数的第一加权系数以及其他参赛方的增长票数的第二加权系数；

计算单元505，还用于根据第一加权系数、第二加权系数以及支持率计算公式，计算目标参赛方的支持率，支持率计算公式为：

其中，A用于指示目标参赛方的实际支持票数，A'用于指示目标参赛方的增长票数，X用于指示第一加权系数，B_i用于指示其他参赛方的实际支持票数，B_i'用于指示其他参赛方的增长票数，Y_i用于指示第二加权系数，Q用于指示目标参赛方的支持率。

参阅图6，图6示出了本申请提供的直播平台的服务器的又一种结构示意图，具体的，本申请提供的直播平台的服务器包括处理器601，处理器601用于执行存储器602中存储的计算机程序时实现如图1至图4对应任意实施例中的直播平台的活动处理方法的各步骤；或者，处理器601用于执行存储器602中存储的计算机程序时实现如图5对应实施例中各单元的功能。

示例性的，计算机程序可以被分割成一个或多个模块/单元，一个或者多个模块/单元被存储在存储器602中，并由处理器601执行，以完成本申请。一个或多个模块/单元可以是能够完成特定功能的一系列计算机程序指令段，该指令段用于描述计算机程序在计算机装置中的执行过程。

直播平台的服务器可包括，但不仅限于处理器601、存储器602。本领域技术人员可以理解，所述示意仅仅是计算机装置的示例，并不构成对直播平台的服务器的限定，可以包括比图示更多或更少的部件，或者组合某些部件，或者不同的部件，例如直播平台的服务器还可以包括输入输出设备、网络接入设备、总线等，处理器601、存储器602、输入输出设备以及网络接入设备等通过总线相连。

处理器601可以是中央处理单元(Central Processing Unit，CPU)，还可以是其他通用处理器、数字信号处理器(Digital Signal Processor，DSP)、专用集成电路(Application Specific Integrated Circuit，ASIC)、现成可编程门阵列(Field-Programmable Gate Array，FPGA)或者其他可编程逻辑器件、分立门或者晶体管逻辑器件、分立硬件组件等。通用处理器可以是微处理器或者该处理器也可以是任何常规的处理器等，处理器是计算机装置的控制中心，利用各种接口和线路连接整个计算机装置的各个部分。

存储器602可用于存储计算机程序和/或模块，处理器601通过运行或执行存储在存储器602内的计算机程序和/或模块，以及调用存储在存储器602内的数据，实现计算机装置的各种功能。存储器602可主要包括存储程序区和存储数据区，其中，存储程序区可存储操作***、至少一个功能所需的应用程序(比如声音播放功能、图像播放功能等)等；存储数据区可存储根据手机的使用所创建的数据(比如音频数据、视频数据等)等。此外，存储器可以包括高速随机存取存储器，还可以包括非易失性存储器，例如硬盘、内存、插接式硬盘，智能存储卡(Smart Media Card，SMC)，安全数字(Secure Digital，SD)卡，闪存卡(FlashCard)、至少一个磁盘存储器件、闪存器件、或其他易失性固态存储器件。

本申请还提供一种可读存储介质，其上存储有计算机程序，计算机程序被处理器执行时实现如图1至图4对应任意实施例中的直播平台的活动处理方法。

可以理解，集成的单元如果以软件功能单元的形式实现并作为独立的产品销售或使用时，可以存储在一个计算机可读取存储介质中。基于这样的理解，本申请的技术方案本质上或者说对现有技术做出贡献的部分或者该技术方案的全部或部分可以以软件产品的形式体现出来，该计算机软件产品存储在一个存储介质中，包括若干指令用以使得一台计算机设备(可以是个人计算机，服务器，或者网络设备等)执行本申请各方法实施例的全部或部分步骤。而前述的存储介质包括：U盘、移动硬盘、只读存储器(Read-only Memory，ROM)、随机存取存储器(Random Access Memory，RAM)、磁碟或者光盘等各种可以存储程序代码的介质。

所属领域的技术人员可以清楚地了解到，为描述的方便和简洁，上述描述的直播平台的服务器及其单元的具体工作过程，可以参考图1至图4对应实施例中的直播平台的活动处理方法的说明，具体在此不再赘述。

综上所述，直播平台可在UE向用户发起赛事直播节目的弹幕助威活动，供用户为支持的参赛方发起支持弹幕，服务器在接收到第一UE发送的支持弹幕时，可统计得到各参赛方的支持结果，此时，服务器可从中确定处于最低序列的目标参赛方，再向播放赛事直播节目的第二UE发送该目标参赛方的支持结果，以使得第二UE在弹幕助威活动中加载弹幕助威活动中目标参赛方的支持结果，由于在弹幕助威活动中，直播平台以处于最低序列的参赛方为目标进行支持结果的更新的，从而，第二UE的用户更可直观地看到目标参赛方的最新活动情况，结合包括自己在内的用户所发起的支持结果，继续观看赛事直播节目，尤其是当看到自身喜欢的参赛方处于落后状态还会进一步地参与支持弹幕的发送，不仅便于用户的参与，且由于弹幕助威活动的弹幕特性，拉近了赛事直播节目与观众之间的距离，使得用户进一步地可获得参与感，在该弹幕助威活动的运营下，可大幅度调动用户的观众参与体验以及节目观看体验，从而提高赛事直播节目的用户活跃度以及用户流量，进而提高直播平台的用户活跃度以及用户流量。

在本申请所提供的几个实施例中，应该理解到，所揭露的直播平台的服务器及其单元，可以通过其它的方式实现。例如，以上所描述的装置实施例仅仅是示意性的，例如，所述单元的划分，仅仅为一种逻辑功能划分，实际实现时可以有另外的划分方式，例如多个单元或组件可以结合或者可以集成到另一个***，或一些特征可以忽略，或不执行。另一点，所显示或讨论的相互之间的耦合或直接耦合或通信连接可以是通过一些接口，装置或单元的间接耦合或通信连接，可以是电性，机械或其它的形式。

所述作为分离部件说明的单元可以是或者也可以不是物理上分开的，作为单元显示的部件可以是或者也可以不是物理单元，即可以位于一个地方，或者也可以分布到多个网络单元上。可以根据实际的需要选择其中的部分或者全部单元来实现本实施例方案的目的。

另外，在本申请各个实施例中的各功能单元可以集成在一个处理单元中，也可以是各个单元单独物理存在，也可以两个或两个以上单元集成在一个单元中。上述集成的单元既可以采用硬件的形式实现，也可以采用软件功能单元的形式实现。

以上所述，以上实施例仅用以说明本申请的技术方案，而非对其限制；尽管参照前述实施例对本申请进行了详细的说明，本领域的普通技术人员应当理解：其依然可以对前述各实施例所记载的技术方案进行修改，或者对其中部分技术特征进行等同替换；而这些修改或者替换，并不使相应技术方案的本质脱离本申请各实施例技术方案的精神和范围。

Claims (8)

1.一种直播平台的活动处理方法，其特征在于，所述方法应用于所述直播平台的服务器，所述方法包括：

所述服务器接收第一用户设备UE发送的支持弹幕，所述支持弹幕用于指示用户通过赛事直播节目的弹幕助威活动发起的对各参赛方的支持；

所述服务器根据所述第一UE发送的支持弹幕，统计所述各参赛方的支持结果；

所述服务器根据所述各参赛方的支持结果，确定处于最低序列的目标参赛方；

所述服务器向播放所述赛事直播节目的第二UE发送所述目标参赛方的支持结果，以使得所述第二UE在弹幕助威活动中加载所述目标参赛方的支持结果；

所述服务器根据所述第一UE发送的支持弹幕，统计所述各参赛方的支持结果包括：

所述服务器根据所述第一UE发送的支持弹幕，以预设更新频率统计所述各参赛方的支持结果；

所述服务器向播放所述赛事直播节目的第二UE发送所述目标参赛方的支持结果包括：

所述服务器以所述预设更新频率向所述第二UE发送所述目标参赛方的支持结果。

2.根据权利要求1所述的方法，其特征在于，所述预设更新频率为1秒更新1次。

3.根据权利要求1所述的方法，其特征在于，所述服务器根据所述第一UE发送的支持弹幕，统计所述各参赛方的支持结果包括：

所述服务器确定所述第一UE发送的支持弹幕对应的弹幕解析协议；

所述服务器根据所述弹幕解析协议，从所述第一UE发送的支持弹幕中解析出各UE对应的支持结果；

所述服务器根据所述第一UE中各UE对应的支持结果，统计所述各参赛方的支持结果。

4.根据权利要求3所述的方法，其特征在于，所述弹幕解析协议包括无状态传输隧道STT解析协议、对象简谱JSON解析协议以及协议缓冲器PB解析协议中的任意一种。

5.根据权利要求1所述的方法，其特征在于，当所述目标参赛方的支持结果为所述目标参赛方的支持率时，所述方法还包括：

所述服务器计算所述目标参赛方的实际支持票数与其他参赛方的实际支持票数的差值；

所述服务器根据所述差值、所述目标参赛方的实际支持票数以及所述其他参赛方的实际支持票数，确定所述目标参赛方的增长票数的第一加权系数以及所述其他参赛方的增长票数的第二加权系数；

所述服务器根据所述第一加权系数、所述第二加权系数以及支持率计算公式，计算所述目标参赛方的支持率，所述支持率计算公式为：

其中，所述A用于指示所述目标参赛方的实际支持票数，所述A'用于指示所述目标参赛方的增长票数，所述X用于指示所述第一加权系数，所述B_i用于指示所述其他参赛方的实际支持票数，所述B_i'用于指示所述其他参赛方的增长票数，所述Y_i用于指示所述第二加权系数，所述Q用于指示所述目标参赛方的支持率。

6.一种直播平台的服务器，其特征在于，所述服务器包括：

接收单元，用于接收第一用户设备UE发送的支持弹幕，所述支持弹幕用于指示用户通过赛事直播节目的弹幕助威活动发起的对各参赛方的支持；

统计单元，用于根据所述第一UE发送的支持弹幕，统计所述各参赛方的支持结果；

确定单元，用于根据所述各参赛方的支持结果，确定处于最低序列的目标参赛方；

发送单元，用于向播放所述赛事直播节目的第二UE发送所述目标参赛方的支持结果，以使得所述第二UE在弹幕助威活动中加载所述目标参赛方的支持结果；

所述统计单元具体用于：

根据所述第一UE发送的支持弹幕，以预设更新频率统计所述各参赛方的支持结果；

所述发送单元具体用于：

以所述预设更新频率向所述第二UE发送所述目标参赛方的支持结果。

7.一种服务器，其特征在于，包括处理器，所述处理器用于执行存储器中存储的计算机程序时实现如权利要求1～5中任一项所述的直播平台的活动处理方法。

8.一种可读存储介质，其上存储有计算机程序，其特征在于，所述计算机程序被处理器执行时实现如权利要求1～5中任一项所述的直播平台的活动处理方法。

Images