CN114025184A - 一种视频直播方法及电子设备 - Google Patents

Abstract

本申请提供了一种视频直播方法及电子设备，涉及计算机技术领域，可在直播中断后使用户能够在同一直播间继续本次直播，提高直播发起用户和直播观看用户的使用体验。该方法包括：服务器获取第一终端使用第一账号发送的直播请求；服务器确定第一账号下存在可续播状态的目标直播；服务器向第一终端发送目标直播的续播信息，以使得第一终端按照所述续播信息续播所述目标直播。

Description

一种视频直播方法及电子设备

技术领域

本申请涉及计算机技术领域，尤其涉及一种视频直播方法及电子设备。

背景技术

随时互联网技术的发展，用户可以采用网络直播的方式将自己录制的视频数据实时传递至互联网上，使观看者可以在互联网上实时收看。示例性的，用户A 可以在手机等电子设备上安装具有直播功能的应用(APP)。进而，当用户A打开应用中的直播功能后，电子设备可开始使用摄像头和麦克风等部件实时录制视频数据(即直播内容)，并将直播内容实时发送至服务器。这样，服务器可将用户A通过电子设备上传的直播内容发布在互联网上。此时，其他用户(例如用户B、用户C等)可通过自身的电子设备进入用户A的直播间，从服务器获取到用户A的直播内容进行实时观看。

在一些网络直播场景中，直播可能会发生异常中断的问题。例如，当发起直播的电子设备断网或者发起直播的应用意外关闭时，直播会异常中断，观看直播的用户也无法继续观看直播内容。此时，如果发起直播的用户需要继续本次直播，通常需要重新操作电子设备和应用创建新的直播间再次发起新的直播，操作较为繁琐、用户的使用体验不高。并且，之前观看直播的用户也需要更换直播间才能继续观看断播后的直播内容，使观看直播的用户的使用体验也不佳。

发明内容

本申请实施例提供了一种视频直播方法及电子设备，可在直播中断后方便用户在同一直播间继续本次直播，提高直播发起用户和直播观看用户的使用体验。

第一方面，提供一种视频直播方法，包括：

服务器获取第一终端使用第一账号发送的直播请求；进而，服务器可确定第一账号下是否存在可续播状态的目标直播；如果存在可续播状态的目标直播，则服务器可向第一终端发送目标直播的续播信息，以使得第一终端可以按照该续播信息续播目标直播，实现直播时断点续播的功能。这样，发起直播的用户可以在原有的直播间继续完成被异常中断的直播，并且，观看直播的用户也可以继续在原有的直播间中观看续播的直播，从而提高发起直播的用户和观看直播的用户的使用体验。

在一种可能的实现方式中，服务器确定第一账号下存在可续播状态的目标直播，包括：当服务器在预设时间内没有接收到与目标直播对应的心跳数据包时，服务器可确定上述目标直播为可续播状态。此时，服务器可将目标直播的直播间 ID标记为可续播状态。

在一种可能的实现方式中，在服务器确定第一账号下存在可续播状态的目标直播之后，还包括：服务器指示所述第一终端显示续播提示，该续播提示用于提示主播是否继续上述目标直播。主播可以在终端上手动选择是否续播。

在一种可能的实现方式中，服务器向第一终端发送目标直播的续播信息，包括：当服务器接收到第一终端发送的续播请求后，服务器向第一终端发送目标直播的续播信息。

在一种可能的实现方式中，上述续播信息可以包括上述目标直播的直播间 ID、开始时间、已直播的时间、客户端类型以及直播模式中的一个或多个。

第二方面，提供一种视频直播方法，包括：

服务器获取第一终端使用第一账号发送的直播请求；当第一账号下不存在可续播状态的直播时，说明本次直播为主播发起的新直播，服务器可为本次直播分配对应的直播间ID，并将分配的直播间ID发送至第一终端，由第一终端使用该直播间ID完成直播。

在一种可能的实现方式中，在服务器为本次直播分配对应的直播间ID之后，还包括：服务器将上述直播间ID与对应的直播预告绑定；进而服务器可向预约所述直播预告的直播用户发送直播推送消息，使得预约所述直播预告的直播用户能够及时获知直播开始的消息。

第三方面，提供一种视频直播方法，包括：

服务器接收第二终端发送的预告请求，该预告请求中包括第一直播预告的预告内容，第二终端与上述第一终端可以相同或不同(即发布直播预告的终端与实际直播的终端可以相同或不同)；服务器将第一直播预告的预告内容发布至社交平台，从而提高直播预告中相关直播的推广能力。

在一种可能的实现方式中，在服务器接收第二终端发送的预告请求之后，上述方法还包括：服务器接收第二终端发送的第一直播预告的预告修改请求；响应于预告修改请求，服务器可将所述第一直播预告的预告内容发送至第二终端，由第二终端展示该预告内容并接收主播的修改；当服务器接收到第二终端发送的修改后的第一直播预告后，可更新第一直播预告的预告内容。

在一种可能的实现方式中，在服务器接收第二终端发送的预告请求之后，还包括：服务器接收所述第二终端发送的所述第一直播预告的删除请求；响应于删除请求，服务器可删除第一直播预告的预告内容。

也就是说，在主播发布直播预告后，主播可以在第二终端上对已发布的直播预告进行修改、删除等管理操作。

第四方面，提供一种视频直播方法，包括：

当第一终端接收到主播输入发起直播的操作时，第一终端可向服务器发送直播请求；当本次直播为可续播状态时，第一终端可接收到服务器发送的目标直播的续播信息；进而，第一终端可按照所述续播信息续播该目标直播，实现断点续播功能。

在一种可能的实现方式中，上述续播信息可以包括目标直播的直播间ID、开始时间、已直播的时间、客户端类型以及直播模式中的一个或多个。

在一种可能的实现方式中，第一终端按照上述续播信息续播所述目标直播，包括：当续播信息中的客户端类型为移动终端，且第一终端的客户端类型也为移动终端时，第一终端按照所述续播信息中设置的直播模式续播所述目标直播；当续播信息中的客户端类型为非移动终端，且第一终端的客户端类型为移动终端时，第一终端可按照横屏模式续播所述目标直播；当续播信息中的客户端类型为移动终端，且第一终端的客户端类型为非移动终端时，第一终端可提示主播选择直播模式，并按照主播选择的直播模式续播所述目标直播。

这样一来，即使续播的客户端类型与上一次直播异常退出时客户端的类型不同时，续播的客户端也能够根据续播信息继续直播，不需要更换直播间，提高主播直播时的使用体验。同时，观看直播的直播用户也可以继续在原有的直播间中观看续播的直播，从而提高直播用户的使用体验。

在一种可能的实现方式中，在第一终端接收服务器发送的目标直播的续播信息之前，还包括：第一终端显示续播提示，该续播提示用于提示用户是否续播上一次异常退出的直播。

第五方面，提供一种视频直播方法，包括：

第一终端显示第一直播预告的第一设置界面；进而，第一终端可接收主播在第一设置界面中输入的预告内容，该预告内容可包括直播标题、直播时间、封面以及直播简介中的一项或多项；后续，第一终端可将主播输入的预告内容携带在预告请求中发送至服务器，请求服务器发布该直播预告。

在一种可能的实现方式中，在第一终端将预告内容携带在预告请求中发送至服务器之后，还包括：第一终端跳转至直播预告的管理页面，该管理页面包括已发布的一条或多条直播预告的管理列表。这样，在主播发布直播预告后，主播可以在管理页面上对已发布的直播预告进行修改、删除等管理操作。

在一种可能的实现方式中，在第一终端跳转至直播预告的管理页面之后，还包括：当接收到主播在上述管理页面对第一直播预告输入的修改操作时，第一终端显示第一直播预告的第二设置界面，第二设置界面中包括已填写的第一直播预告的预告内容；当接收到主播在第二设置界面输入的修改后，第一终端可向服务器发送修改请求，该修改请求中包括修改后的第一直播预告。

在一种可能的实现方式中，在第一终端跳转至直播预告的管理页面之后，还包括：当接收到主播在上述管理页面对第一直播预告输入的删除操作时，第一终端向服务器发送删除请求。

在一种可能的实现方式中，当第一终端接收到主播输入发起直播的操作时，第一终端向服务器发送直播请求，包括：当接收到主播在上述管理页面对第一直播预告输入的发起直播操作时，第一终端向服务器发送直播请求，即从直播预告的入口发起直播。

第六方面，提供一种服务器，包括：处理器和存储器，该存储器用于存储计算机程序，该处理器用于调用并运行该存储器中存储的计算机程序，执行如上述第一方面至第三方面中一项所述的方法。

第七方面，提供一种终端，包括：处理器和存储器，该存储器用于存储计算机程序，该处理器用于调用并运行该存储器中存储的计算机程序，执行如第四方面至第五方面中一项所述的方法。

第八方面，提供一种计算机可读存储介质，用于存储计算机程序，计算机程序使得计算机执行如上述任一方面或其各实现方式中的方法。

第九方面，提供一种计算机程序产品，包括计算机程序指令，该计算机程序指令使得计算机执行上述任一方面或其各实现方式中的方法。

第十方面，提供一种计算机程序，该计算机程序使得计算机执行如上述任一方面或其各实现方式中的方法。

可以理解地，上述各方面中提供的服务器、终端、计算机可读存储介质以及计算机程序产品均用于执行上文所提供的对应的方法，因此，其所能达到的有益效果可参考上文所提供的对应的方法中的有益效果，此处不再赘述。

附图说明

图1为本申请实施例提供的一种直播***的架构示意图；

图2为本申请实施例提供的一种视频直播方法的流程示意图；

图3为本申请实施例提供的另一种视频直播方法的流程示意图；

图4为本申请实施例提供的一种视频直播方法的应用场景示意图；

图5为本申请实施例提供的另一种视频直播方法的应用场景示意图；

图6为本申请实施例提供的另一种视频直播方法的应用场景示意图；

图7为本申请实施例提供的另一种视频直播方法的流程示意图；

图8为本申请实施例提供的另一种视频直播方法的应用场景示意图；

图9为本申请实施例提供的另一种视频直播方法的流程示意图；

图10为本申请实施例提供的另一种视频直播方法的应用场景示意图；

图11为本申请实施例提供的另一种视频直播方法的流程示意图；

图12为本申请实施例提供的另一种视频直播方法的应用场景示意图；

图13为本申请实施例提供的一种终端的结构示意图；

图14为本申请实施例提供的一种服务器的结构示意图；

图15为本申请实施例提供的另一种终端的结构示意图；

图16为本申请实施例提供的另一种服务器的结构示意图。

具体实施方式

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

本申请实施例提供了一种视频直播方法可应用于图1所示的直播***100。其中，直播***100可包括电子设备101和服务器102。电子设备101和服务器102可通过网络通信。

上述电子设备101可以是任一终端设备。例如，可以是智能手机、平板电脑、笔记本电脑、台式计算机、智能音箱、智能手表等，但并不局限于此。

上述服务器102可以是独立的物理服务器，也可以是多个物理服务器构成的服务器集群或者分布式***，还可以是提供云计算服务的云服务器。

电子设备101以及服务器102可以通过有线或无线通信方式进行直接或间接地连接。服务器102可以通过所连接的电子设备101接收用户的操作并生成指令，再由服务器102根据电子设备101的指令执行数据处理，本申请在此不做限制。

一般，在网络直播场景中，如图2所示，当电子设备101检测到用户输入发起直播的操作后，电子设备101可向服务器102发送直播请求。服务器102可响应该直播请求向电子设备101分配本次直播的直播间ID，进而，电子设备101 可使用服务器102分配的直播间ID开始录制本次直播内容，即电子设备101采集到的视频数据。后续，电子设备101可实时的将录制的直播内容以视频流的形式发送至服务器102。这样，服务器102可以上述直播间ID为索引将接收到的直播内容发布在互联网上，此时，其他用户可使用自身的电子设备进入对应的直播间观看实时发布的直播内容。

在上述直播过程中，仍如图2所示，电子设备101与服务器102之间可采用心跳机制的通信方法保证通信的有效性。例如，电子设备101获取到服务器102 分配的直播间ID后，可周期性(例如每5秒1次)的向服务器102发送心跳数据包。服务器102每次接收到电子设备101发来的心跳数据包后，可向电子设备 101发送心跳响应包，使得电子设备101获知当前能够与服务器102进行有效通信。

当用户结束直播或者直播过程中发生异常(例如断网等)时，电子设备101 不会再向服务器102发送心跳数据包。当服务器102在预设时间(例如30秒) 内没有接收到电子设备101发来的心跳数据包时，服务器102可释放上述直播间 ID以结束本次直播。

但是，当直播过程中因异常而中断后用户通常会有继续直播的需求，但此时服务器102已经释放了本次直播的直播间ID、结束本次直播。那么，用户需要使用电子设备101再次重复上述流程发起新的直播才能继续上次被中断的直播，而观看直播的用户也需要再次进入新的直播间继续观看，造成直播时的用户体验不佳。

在本申请实施例中，服务器102可识别电子设备101在直播过程中是否出现异常中断。如果出现异常中断，则服务器102可将本次直播标记为可续播状态。后续，如果服务器102接收到电子设备101发送的用户续播直播的指令，则服务器102可查询到对应的直播为可续播状态，进而继续使用原有的直播间ID与电子设备101交互，完成断点续播功能。这样，发起直播的用户可以在原有的直播间继续完成被异常中断的直播，并且，观看直播的用户也可以继续在原有的直播间中观看续播的直播，从而提高发起直播的用户和观看直播的用户的使用体验。

可选的，在本申请实施例中，当出现异常中断，服务器102将本次直播标记为可续播状态时，服务器102出现如下操作，预先开辟一个内存区，作为缓存区给缓存视频存储使用，在播放直播的过程中，获取因异常中断保留用户未查看的视频数据并存储在缓存区当中；当服务器102接收到电子设备101发送的用户续播直播的指令后，推送给用户可选项选择优先查看缓存区中的缓存视频或继续使用原有的直播间ID与电子设备101交互，完成断点续播功能。

具体的，为了提高数据处理效率，避免缓存空间浪费，在缓存区中划分出来的一块临时存储区域，用于暂时存储缓存数据。将缓存数据优先存入临时存储区域，缓存数据在临时存储区域中连续存储。

具体的，将临时存储区域中所有的缓存数据进行压缩后作为一个整体存入缓存区，临时存储区域中缓存数据可被清空，然后继续接收新的缓存数据。

具体的，设X为需要缓存的视频数据包大小；通过数据包大小的倒数X^-1来衡量数据包所占用的空间和数据复制时所用的消耗。Time_f为最近一次访问该数据的时间；Time_n为当前时间,通过两者之差的倒数来预测未来单位时间内的访问次数，即：(Time_f-Time_n)^-1；

Time_c为该数据包的创建时间；计算数据创建时长为：Time_c-Time_n；

Time_m为最近一次的数据更新时间，Time_c≠Time_a；

总存储次数为：

若Time_m与time_f的时间相同，则不缓存；

综上，通过以下公式计算目标数据包的等级系数：

预先设定等级阈值Q1，将得到的值与阈值进行比较，若：Q1<Q,将数据缓存于临时存储区域中；Q1≧Q将数据缓存于缓存区中。

后续为方便描述，可将发起直播的用户称为主播，将观看直播的用户称为直播用户(或粉丝等)。

在一些实施例中，手机等电子设备中可安装具有直播功能的应用，后续可称为直播APP。在发起直播前，主播可使用直播APP发布直播预告，以便吸引更多的直播用户关注或预约后续将发起的直播。

示例性的，以主播使用手机上的直播APP发布直播预告举例，如图3所示，本申请实施例提供了一种直播预告的发布方法，该方法包括：

S301、手机显示发布直播预告的第一设置界面。

示例性的，直播APP中可以设置发布直播预告的入口。例如，手机运行直播APP时，可在直播APP的显示界面中显示预告发布按钮。如果检查到主播点击预告发布按钮，则如图4所示，手机可显示发布直播预告的第一设置界面401。

在一些实施例中，仍如图4所示，第一设置界面401中可以包括直播标题 401a、直播时间401b、封面401c以及直播简介401d等一项或多项输入选项。这些输入选项中可以包括必填的输入选项也可以包括选填的输入选项，主播可以手动输入这些输入选项，完成预告内容的输入。

S302、手机接收主播在第一设置界面中输入的预告内容。

仍以上述第一设置界面401举例，手机显示发布直播预告的第一设置界面 401后，主播可在第一设置界面401中输入直播标题401a、直播时间401b、封面401c以及直播简介401d等一项或多项输入选项。手机可将主播在第一设置界面401中输入的各个输入选项的具体内容作为本次直播的预告内容。

示例性的，手机检测到主播在第一设置界面401中输入任一项输入选项时，可实时检测所有必填的输入选项是否已填写完成。如果所有必填的输入选项是否已填写完成，则手机可将第一设置界面401中直播预告的发布按钮404设置为可交互的状态；否则，手机可将第一设置界面401中直播预告的发布按钮404设置为不可交互的状态。

例如，如果检测到主播还没有填写封面401c中的内容，则手机可将发布按钮404显示为灰色，此时如果主播点击发布按钮404则手机不会响应主播的点击操作。如果检测到主播将直播标题401a、直播时间401b、封面401c均填写完成，则手机可将发布按钮404显示为红色，此时如果主播点击发布按钮404则手机可继续执行下述步骤S303，以发布本次直播的直播预告。

另外，手机检测到主播在第一设置界面401中输入直播时间401b这一输入选项时，还可以检测主播输入的直播时间是否合法。例如，当前的***时间为： 2021/10/12，16:10，如果当主播输入的直播时间401b为2021/10/12，10:10，则手机可提示主播当前输入的直播时间不合法，即主播输入的直播时间早于***时间时，手机可提示主播当前输入的直播时间不合法。

S303、手机将上述预告内容发送至服务器。

仍以上述第一设置界面401举例，当主播在第一设置界面401中完成预告内容的输入后，可点击第一设置界面401中的发布按钮404。进而，手机可响应主播点击发布按钮404的操作，将主播输入的预告内容携带在预告请求中发送给服务器，该预告请求用于请求服务器发布本次预告内容。

S304、服务器将上述预告内容发布至社交平台。

服务器接收到手机发来的预告请求后，可将预告请求中携带的预告内容存储在预设的数据库中进行维护。并且，服务器可将上述预告内容发布至直播APP 的社交平台中。例如，服务器可将主播输入的预告内容501以feed流的形式发布在直播APP的“牛牛圈”中。这样，如图5所示，其他用户在浏览“牛牛圈”时可以看到预告内容501，提高直播的推广能力。

在一些实施例中，仍如图5所示，服务器将预告内容501发布在直播APP 的“牛牛圈”后，还可以指示对应的电子设备在其他用户在浏览“牛牛圈”时显示预约按钮502。如果直播用户想要观看预告内容501中预告的直播，可点击预约按钮502。例如，检测到直播用户A点击预约按钮502后，其电子设备可向服务器发送订阅请求，触发服务器将直播用户A与预告内容501建立绑定关系。后续，当预告内容501中预告的直播开始后，服务器可根据已经建立的绑定关系提醒直播用户A观看直播。

S305、服务器向手机发送直播预告发布成功的响应消息。

当服务器将上述预告内容成功发布至社交平台后，服务器可向主播的手机发送直播预告发布成功的响应消息，以便手机获知本次直播预告已成功发布。示例性的，服务器发送的响应消息中可以包括与本次直播预告对应的预告ID。

在一些实施例中，如图6所示，手机接收到服务器发送的直播预告发布成功的响应消息后，可以跳转至直播预告的管理页面601中，并在管理页面601中显示本次直播预告发布成功的提示消息602，以便主播获知本次直播预告已成功发布。

在一些实施例中，仍如图6所示，直播预告的管理页面601中还可以包括已发布的直播预告的管理列表603。主播可以在管理列表603中对已发布的直播预告进行修改、删除等管理操作。

示例性的，仍以主播使用手机上的直播APP发布直播预告举例，如图7所示，本申请实施例提供了一种直播预告的管理方法，该方法包括：

S701、手机显示直播预告的管理页面。

如图6所示，当成功发布一条直播预告后，手机可自动跳转至直播预告的管理页面601。管理页面601中包括已发布的一条或多条直播预告的管理列表603。主播可以在管理列表603中对已发布的直播预告进行删除、修改等管理操作。当然，主播也可以通过其他入口进入上述直播预告的管理页面，本申请实施例对此不作任何限制。

S702、响应于主播对管理页面中第一直播预告输入的修改操作，手机从服务器获取第一直播预告的预告内容。

仍如图6所示，直播预告的管理列表603中可以包括已发布的第一直播预告 604。当主播需要修改第一直播预告604的预告内容时，可点击管理页面601中与第一直播预告604关联的修改按钮605。

如果检测到主播点击修改按钮605，说明主播对第一直播预告604输入修改操作，此时，手机可请求从服务器获取与第一直播预告604对应的预告内容。例如，手机可将第一直播预告604的预告ID携带在修改请求中发送给服务器，服务器可根据第一直播预告604的预告ID在预设的数据库中查找对应的预告内容，即第一直播预告604的预告内容(例如直播标题、封面等)。进而，服务器可将第一直播预告604的预告内容发送给手机。

在一些实施例中，服务器获取到手机发送的修改请求后，还可以进一步判断第一直播预告604是否允许修改。例如，服务器可以根据当前的***时间以及第一直播预告604中设置的直播时间确定是否允许修改第一直播预告604。如果当前的***时间早于第一直播预告604中设置的直播时间，则服务器可确定允许修改第一直播预告604，进而在预设字段(例如announce_modifiable_status字段) 中携带允许修改的标识。相应的，如果当前的***时间晚于第一直播预告604 中设置的直播时间，则服务器可确定不允许修改第一直播预告604，进而在预设字段(例如announce_modifiable_status字段)中携带不允许修改的标识。

这样，手机从服务器获取到第一直播预告604的预告内容后，可根据 announce_modifiable_status字段中携带的标识确定当前是否允许修改第一直播预告604。

如果手机确定当前不允许修改第一直播预告604，则手机可显示修改失败的提示消息给主播。或者，手机还可以将第一直播预告604的修改按钮605设置为不可交互的状态或者隐藏修改按钮605，本申请实施例对此不作任何限制。

相应的，如果手机确定当前允许修改第一直播预告604，则可继续执行下述步骤S703。

S703、手机按照第一直播预告的预告内容显示修改第一直播预告的第二设置界面。

仍以修改第一直播预告604举例，手机从服务器获取到第一直播预告604 的预告内容后，可按照第一直播预告604的预告内容显示修改第一直播预告604 的第二设置界面801。如图8所示，第二设置界面801与发布第一直播预告604 的第一设置界面类似，第二设置界面801中也可以包括直播标题801a、直播时间801b、封面801c以及直播简介801d等一项或多项输入选项。不同的是，第二设置界面801中已经按照第一直播预告604的预告内容填写好了上述输入选项，用户可以重新编辑上述各个输入选项。

S704、手机接收主播在第二设置界面中对预告内容的修改操作，得到修改后的第一直播预告。

与步骤S302类似的，在步骤S704中，手机可以接收主播在第二设置界面 801中对第一直播预告604的预告内容的修改操作。例如，主播可以重新编辑第一直播预告604的直播标题、直播时间、封面或者直播简介等预告内容。手机可将第二设置界面801中主播输入的预告内容作为修改后的第一直播预告604。

S705、手机将修改后的第一直播预告发送至服务器。

仍如图8所示，第二设置界面801中还可以设置发布按钮802。当主播在第二设置界面801中修改好第一直播预告604的预告内容后，可点击发布按钮802。此时，手机可响应主播点击发布按钮802的操作，将第二设置界面801中修改后的第一直播预告604的预告内容发送至服务器。进而，服务器可在预设的数据库中更新第一直播预告604的预告内容，完成本次直播预告的修改过程。

可选地，服务器更新完第一直播预告604的预告内容后还可以向手机发送修改成功的响应消息，使得手机获知本次直播预告的修改成功。此时，手机还可以显示第一直播预告604修改成功的提示消息，使得主播获知本次直播预告的修改成功。

在另一些实施例中，当手机显示出直播预告的管理页面(例如上述管理页面 601)后，除了修改已发布的直播预告外，主播还可以在管理页面601的管理列表603中删除已发布的直播预告。删除已发布直播预告的方法可参见下述步骤 S706-S707。

S706、响应于主播对管理页面中第一直播预告输入的删除操作，手机向服务器发送第一直播预告的删除请求。

仍以图6中管理列表603内的第一直播预告604举例，当主播希望删除已发布的第一直播预告604时，可点击管理页面601中与第一直播预告604关联的删除按钮606。

如果检测到主播点击删除按钮606，说明主播对第一直播预告604输入删除操作，此时，手机可向服务器发送第一直播预告604的删除请求。例如，手机可将第一直播预告604的预告ID携带在删除请求中发送给服务器。

S707、响应于上述删除请求，服务器删除第一直播预告。

服务器接收到手机发来的第一直播预告604的删除请求后，可根据删除请求中的预告ID在预设的数据库中删除对应的第一直播预告604的预告内容，完成本次直播预告的删除过程。

可选地，服务器删除第一直播预告604的预告内容后还可以向手机发送删除成功的响应消息，使得手机获知本次直播预告删除成功。此时，手机还可以显示第一直播预告604删除成功的提示消息，使得主播获知本次直播预告删除成功。

由于服务器在预设的数据库中删除了第一直播预告604，因此，后续主播在手机以及其他设备上登录直播APP时，均不会再获取到第一直播预告604的相关内容。

在一些实施例中，无论主播是否在直播APP上发布直播预告，均可使用直播APP的直播功能发起直播(也可称为视频直播)。示例性的，以主播使用手机上的直播APP发起直播举例，如图9所示，本申请实施例提供了一种视频直播方法，该方法包括：

S901、手机显示发起直播的第三设置界面。

示例性的，主播可以从已发布的直播预告的(例如上述管理列表603)中发起直播。例如，图6中管理列表603内设置有第一直播预告604的直播发起按钮 607。当主播想要发起与第一直播预告604对应的直播时，可点击直播发起按钮 607。也就是说，主播可将直播预告作为发起直播的入口开始直播。或者，主播也可以通过其他入口(例如主页中的直播按钮等)发起直播，本申请实施例对此不作任何限制。

以主播点击第一直播预告604的直播发起按钮607举例，手机检测到主播点击直播发起按钮607后，可从服务器获取第一直播预告604的预告内容(例如直播标题、封面等)。进而，如图10所示，手机可按照第一直播预告604的预告内容显示发起直播的第三设置界面1001。第三设置界面1001中可以包括直播标题、封面等与预告内容相同的选项。手机可按照第三设置界面1001自动填充这些选项。主播也可以在第三设置界面1001中手动修改这些选项，本申请实施例对此不作任何限制。

并且，仍如图10所示，发起直播的第三设置界面1001中还可以设置本次直播的相关参数，例如直播模式为横屏模式或竖屏模式等。

需要说明的是，手机获取到第一直播预告604的预告内容后，还可以根据当前的***时间判断是否允许发起本次直播。例如，如果当前的***时间早于预告内容中的直播时间，则手机可确定允许发起本次直播，并继续执行下述步骤S902。如果当前的***时间晚于预告内容中的直播时间，则手机可确定不允许发起本次直播，进而显示本次直播发起失败的提示消息。

S902、手机根据主播在第三设置界面中的设置向服务器发送本次直播的直播信息。

仍以发起直播的第三设置界面1001举例，主播在第三设置界面1001中设置了本次直播的相关参数后，可点击直播按钮1002开始直播。那么，手机检测到主播点击直播按钮1002后，可将本次直播的直播信息携带在直播请求中发送至服务器。其中，直播信息可以包括主播在第三设置界面1001中设置的直播标题、封面、直播模式等内容，还可以包括客户端的类型(例如手机)、型号、直播开始的时间(例如点击直播按钮1002的时间)、直播流地址等。

S903、手机从服务器获取与本次直播对应的直播间ID。

服务器获取到携带直播信息的直播请求后，可以为本次直播分配对应的直播间ID，从而建立直播间ID与直播信息之间的对应关系。后续服务器可使用直播间ID为索引维护本次直播的直播信息。并且，服务器可将为本次直播分配的直播间ID发送至客户端(即手机)，使手机获取到本次直播对应的直播间ID。

S904、手机使用上述直播间ID开始直播。

手机获取到本次直播的直播间ID后，可使用该直播间ID开始直播。此时，手机可跳转至直播界面实时显示当前录制的直播内容。例如，手机可将实时录制的视频数据(即直播内容)发送至服务器，由服务器将该直播内容实时发布在直播APP提供的网络平台上。

S905、服务器将上述直播间ID与对应的直播预告绑定。

在本申请实施例中，服务器为本次直播分配了对应的直播间ID后，还可以使用该直播间ID将本次直播与对应的直播预告绑定。例如，服务器可建立直播间ID与对应的预告ID之间的对应关系。

S906、服务器向预约上述直播预告的直播用户发送直播推送消息。

由于在发布直播预告(例如第一直播预告604)时可能已经有一个或多个直播用户预约了该直播，那么，当本次直播与对应的直播预告绑定后，服务器可向已经预约上述直播预告的直播用户发送直播开始的直播推送消息，以提示相关直播用户预约的直播已经开始。

在一些实施例中，服务器为本次直播分配了对应的直播间ID后，还可以指示手机删除对应的直播预告，保证直播预告列表中直播预告的实时性。

在另一些实施例中，手机在使用服务器分配的直播间ID进行直播的过程中，可以采用心跳机制的通信方法保证通信的有效性。如图11所示，手机开始直播后，可周期性的向服务器发送心跳数据包。服务器接收到手机发来的心跳数据包后可回复对应的心跳响应。

当直播过程中发生异常(例如断网，直播APP异常退出等)时，手机将退出本次直播，并且手机无法再向服务器发送心跳数据包。那么，如果服务器在第一预设时长(例如15s)内没有接收到手机发来的心跳数据包，则服务器可确定本次直播发生异常。此时，服务器可将本次直播的直播间ID标记为可续播状态，以便后续续播该直播。相应的，如果服务器在更长时间内，例如第二预设时长(例如600s)内还没有接收到手机发来的心跳数据包，则服务器可确定本次直播无需再维持，此时手机可结束本次直播。例如，手机可释放本次直播的直播间ID，使该直播间ID可分配可后续其他用户发起的直播。

在本申请实施例中，仍如图11所示，当直播发生异常中断后，可按照下述直播方法恢复直播，实现断点续播的功能。

S1101、手机(或其他客户端)向服务器发送直播请求。

当手机在上述直播过程中因异常而退出直播后，主播可继续使用手机或其他客户端(例如平板电脑、PC等)重新登录直播APP。以主播再次使用手机登录直播APP举例，主播进入直播APP后，如果检测道主播输入发起直播的操作，则手机可向服务器发送直播请求。示例性的，直播请求可以包括主播本次在直播 APP上登录的账号或用户名等信息。

S1102、服务器根据上述直播请求判断本次直播是否为可续播状态。

服务器接收到手机(或其他客户端)发送的直播请求后，可查询该账号下是否存在可续播状态的直播。

示例性的，如果服务器在一定时间内没有接收到与某一直播间ID对应的心跳数据包，则服务器可将对应账号下的直播间ID标记为可续播状态，即与该直播间ID对应的直播为可续播状态。此时，服务器可继续执行下述步骤S1103。

相应的，如果服务器查询到发送直播请求的账号下不存在可续播状态的直播，则服务器可按照上述发起新直播的流程指示手机开始新的直播。

S1103、若本次直播为可续播状态，则服务器指示手机(或其他客户端)显示续播提示。

如果服务器查询到主播本次登录的账号下存在可续播的直播，则服务器可将被标记为可续播状态的直播间ID发送给手机，此时，如图12所示，手机可显示对话框1201，在对话框1201中提示用户可以续播上一次异常退出的直播。对话框1201中的内容可称为续播提示。当然，手机还可以通过语音、动画等方式显示续播提示，本申请实施例对此不作任何限制。

S1104、若主播选择续播上一次异常退出的直播，手机(或其他客户端)从服务器获取上一次直播的续播信息。

示例性的，上述对话框1201中可以包括继续直播的按钮1202和发起新直播的按钮1203。如果检测到主播点击继续直播的按钮1202，说明主播选择续播上一次异常退出的直播，则手机可向服务器发送续播请求，该续播请求中包括上一次异常退出的直播的直播间ID，以请求服务器续播该直播。

进而，服务器接收到上述续播请求后，可将与续播请求中的直播间ID对应的续播信息发送给手机。其中，该续播信息可以包括上一次异常退出的直播的开始时间、已直播的时间、客户端类型以及直播模式(例如横屏模式或竖屏模式) 中的一个或多个。

示例性的，由于某一直播的续播信息一般为其直播信息的子集，因此，服务器可以将与上述直播间ID对应的直播信息发送给当前登录直播APP的客户端 (例如手机)，进而由手机从直播信息中获取本次续播所需的续播信息。或者，服务器也可以直接从直播信息中筛选出本次续播所需的续播信息，进而将续播信息发送给手机，本申请实施例对此不作任何限制。

S1105、手机(或其他客户端)根据上述续播信息使用上述直播间ID继续直播。

本次续播的客户端获取到上一次异常退出的直播的续播信息后，可根据该续播信息继续使用异常退出前的直播间ID进行直播，实现续播功能。

具体的，续播信息中记录了上一次直播异常退出时客户端的类型。如果续播信息中客户端的类型为移动终端(例如手机)，并且，本次续播的客户端的类型仍为移动终端(例如手机)，则手机可继续使用续播信息中的直播模式(例如横屏模式或竖屏模式)等参数进行续播。

或者，如果续播信息中客户端的类型为PC等非移动终端，并且，本次续播的客户端的类型为移动终端(例如手机)，则手机可默认按照横屏模式的直播模式进行续播。

又或者，如果续播信息中客户端的类型为移动终端(例如手机)，并且，本次续播的客户端的类型为非移动终端(例如PC)，则PC可以重新提示主播选择横屏或竖屏的直播模式，进而按照主播选择的直播模式进行续播。

这样一来，即使续播的客户端类型与上一次直播异常退出时客户端的类型不同时，续播的客户端也能够根据续播信息使用原始的直播间ID继续直播，不需要更换直播间，提高主播直播时的使用体验。同时，观看直播的直播用户也可以继续在原有的直播间中观看续播的直播，从而提高直播用户的使用体验。

上文结合图1至图12，详细描述了本申请的方法实施例，下文将详细描述本申请的装置实施例，应理解，装置实施例与方法实施例相互对应，类似的描述可以参照方法实施例。

图13示出了本申请实施例提供的一种终端的示意性框图。如图13所示，该终端可以包括：

发送单元1301，用于在接收到主播输入发起直播的操作时，向服务器发送直播请求；获取单元1302，用于接收所述服务器发送的目标直播的续播信息；直播单元1303，用于按照所述续播信息续播所述目标直播。

在一些实施例中，直播单元1303，具体用于：当所述续播信息中的客户端类型为移动终端，且所述第一终端的客户端类型也为移动终端时，按照所述续播信息中设置的直播模式续播所述目标直播；当所述续播信息中的客户端类型为非移动终端，且所述第一终端的客户端类型为移动终端时，按照横屏模式续播所述目标直播；当所述续播信息中的客户端类型为移动终端，且所述第一终端的客户端类型为非移动终端时，提示主播选择直播模式，并按照主播选择的直播模式续播所述目标直播。

在一些实施例中，上述终端还包括显示单元1304，用于显示续播提示，所述续播提示用于提示用户是否续播上一次异常退出的直播。

在一些实施例中，显示单元1304还用于：显示第一直播预告的第一设置界面；获取单元1302还用于：接收主播在所述第一设置界面中输入的预告内容，所述预告内容包括直播标题、直播时间、封面以及直播简介中的一项或多项；发送单元1301还用于：将所述预告内容携带在预告请求中发送至所述服务器。

在一些实施例中，显示单元1304还用于：跳转至直播预告的管理页面，所述管理页面包括已发布的一条或多条直播预告的管理列表。

在一些实施例中，显示单元1304还用于：当接收到主播在所述管理页面对第一直播预告输入的修改操作时，显示所述第一直播预告的第二设置界面，所述第二设置界面中包括已填写的第一直播预告的预告内容；发送单元1301还用于：当接收到主播在所述第二设置界面输入的修改后，向所述服务器发送修改请求，所述修改请求中包括修改后的第一直播预告。

在一些实施例中，发送单元1301还用于：当接收到主播在所述管理页面对第一直播预告输入的删除操作时，向所述服务器发送删除请求。

在一些实施例中，发送单元1301还用于：当接收到主播在所述管理页面对第一直播预告输入的发起直播操作时，向服务器发送直播请求。

图14示出了本申请实施例提供的一种服务器示意性框图。如图14所示，该服务器包括：

获取单元1401，用于：获取第一终端使用第一账号发送的直播请求；处理单元1402，用于：确定所述第一账号下存在可续播状态的目标直播；发送单元 1403，用于：向所述第一终端发送所述目标直播的续播信息，以使得所述第一终端按照所述续播信息续播所述目标直播。

在一些实施例中，处理单元1402具体用于：当所述服务器在预设时间内没有接收到与所述目标直播对应的心跳数据包时，确定所述目标直播为可续播状态。

在一些实施例中，处理单元1402还用于：指示所述第一终端显示续播提示，所述续播提示用于提示主播是否继续所述目标直播。

在一些实施例中，处理单元1402还用于：当所述第一账号下不存在可续播状态的直播时，为本次直播分配对应的直播间ID，并将所述直播间ID发送至所述第一终端。

在一些实施例中，处理单元1402还用于：将所述直播间ID与对应的直播预告绑定；向预约所述直播预告的直播用户发送直播推送消息。

在一些实施例中，获取单元1401还用于：接收第二终端发送的预告请求，所述预告请求中包括第一直播预告的预告内容，所述第二终端与所述第一终端相同或不同；处理单元1402还用于：将第一直播预告的预告内容发布至社交平台。

在一些实施例中，获取单元1401还用于：接收所述第二终端发送的所述第一直播预告的预告修改请求；发送单元1401还用于：响应于所述预告修改请求，将所述第一直播预告的预告内容发送至所述第二终端；处理单元1402还用于：接收到所述第二终端发送的修改后的第一直播预告后，更新所述第一直播预告的预告内容。

在一些实施例中，获取单元1401还用于：接收所述第二终端发送的所述第一直播预告的删除请求；处理单元1402还用于：响应于所述删除请求，删除所述第一直播预告的预告内容。

上述实施例提供的终端和服务器，可以执行上述方法实施例的技术方案，其实现原理和技术效果类似，此处不再赘述。

图15为本申请实施例提供的一种终端示意性结构图。如图15所示的终端设备包括处理器1510，处理器1510可以从存储器中调用并运行计算机程序，以实现本申请实施例中的方法。

可选地，如图15所示，终端设备还可以包括存储器1520。其中，处理器1510 可以从存储器1520中调用并运行计算机程序，以实现本申请实施例中的方法。

其中，存储器1520可以是独立于处理器1510的一个单独的器件，也可以集成在处理器1510中。

可选地，如图15所示，终端设备还可以包括收发器1530，处理器1510可以控制该收发器1530与其他设备进行通信，具体地，可以向其他设备发送信息或数据，或接收其他设备发送的信息或数据。

其中，收发器1530可以包括发射机和接收机。收发器1530还可以进一步包括天线，天线的数量可以为一个或多个。

可选地，如图15所示，终端设备还可以包括显示器1540，显示器1540可用于向用户输出文字、图片以及视频等内容。

图16为本申请实施例提供的一种服务器示意性结构图。如图16所示的服务器包括处理器1610，处理器1610可以从存储器中调用并运行计算机程序，以实现本申请实施例中的方法。

可选地，如图16所示，服务器还可以包括存储器1620。其中，处理器1610 可以从存储器1620中调用并运行计算机程序，以实现本申请实施例中的方法。

其中，存储器1620可以是独立于处理器1610的一个单独的器件，也可以集成在处理器1610中。

可选地，如图16所示，服务器还可以包括收发器1630，处理器1610可以控制该收发器1630与其他设备进行通信，具体地，可以向其他设备发送信息或数据，或接收其他设备发送的信息或数据。

其中，收发器1630可以包括发射机和接收机。收发器1630还可以进一步包括天线，天线的数量可以为一个或多个。

上述实施例提供的终端设备和服务器，可以执行上述方法实施例的技术方案，其实现原理和技术效果类似，此处不再赘述。

应理解，本申请实施例的处理器可能是一种集成电路芯片，具有信号的处理能力。在实现过程中，上述方法实施例的各步骤可以通过处理器中的硬件的集成逻辑电路或者软件形式的指令完成。

可以理解，本申请实施例中的存储器可以是易失性存储器或非易失性存储器，或可包括易失性和非易失性存储器两者。应注意，本文描述的***和方法的存储器旨在包括但不限于这些和任意其它适合类型的存储器。

本申请实施例还提供了一种计算机可读存储介质，用于存储计算机程序。

可选的，该计算机可读存储介质可应用于本申请实施例中的终端设备或服务器，并且该计算机程序使得计算机执行本申请实施例的各个方法中由的相应流程，为了简洁，在此不再赘述。

本申请实施例还提供了一种计算机程序产品，包括计算机程序指令。

可选的，该计算机程序产品可应用于本申请实施例中的终端设备或服务器，并且该计算机程序指令使得计算机执行本申请实施例的各个方法中的相应流程，为了简洁，在此不再赘述。

本申请实施例还提供了一种计算机程序。

可选的，该计算机程序可应用于本申请实施例中的终端设备或服务器，当该计算机程序在计算机上运行时，使得计算机执行本申请实施例的各个方法中的相应流程，为了简洁，在此不再赘述。

以上所述，仅为本申请的具体实施方式，但本申请的保护范围并不局限于此，任何熟悉本技术领域的技术人员在本申请揭露的技术范围内，可轻易想到变化或替换，都应涵盖在本申请的保护范围之内。因此，本申请的保护范围应所述以权利要求的保护范围为准。

Claims (14)

1.一种视频直播方法，其特征在于，包括：

服务器获取第一终端使用第一账号发送的直播请求；

所述服务器确定所述第一账号下存在可续播状态的目标直播；

所述服务器向所述第一终端发送所述目标直播的续播信息，以使得所述第一终端按照所述续播信息续播所述目标直播。

2.根据权利要求1所述的方法，其特征在于，所述服务器确定所述第一账号下存在可续播状态的目标直播，包括：

当所述服务器在预设时间内没有接收到与所述目标直播对应的心跳数据包时，所述服务器确定所述目标直播为可续播状态。

3.根据权利要求1所述的方法，其特征在于，在所述服务器确定所述第一账号下存在可续播状态的目标直播之后，还包括：

所述服务器指示所述第一终端显示续播提示，所述续播提示用于提示主播是否继续所述目标直播。

4.根据权利要求3所述的方法，其特征在于，所述服务器向所述第一终端发送所述目标直播的续播信息，包括：

当所述服务器接收到所述第一终端发送的续播请求后，所述服务器向所述第一终端发送所述目标直播的续播信息。

5.根据权利要求1-4中任一项所述的方法，其特征在于，在服务器获取第一终端使用第一账号发送的直播请求之后，还包括：

当所述第一账号下不存在可续播状态的直播时，所述服务器为本次直播分配对应的直播间ID，并将所述直播间ID发送至所述第一终端。

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

所述服务器接收第二终端发送的预告请求，所述预告请求中包括第一直播预告的预告内容，所述第二终端与所述第一终端相同或不同；

所述服务器将所述第一直播预告的预告内容发布至社交平台。

7.根据权利要求6所述的方法，其特征在于，在所述服务器接收第二终端发送的预告请求之后，还包括：

所述服务器接收所述第二终端发送的所述第一直播预告的预告修改请求；

响应于所述预告修改请求，所述服务器将所述第一直播预告的预告内容发送至所述第二终端；

所述服务器接收到所述第二终端发送的修改后的第一直播预告后，更新所述第一直播预告的预告内容。

8.一种视频直播方法，其特征在于，包括：

当第一终端接收到主播输入发起直播的操作时，所述第一终端向服务器发送直播请求；

所述第一终端接收所述服务器发送的目标直播的续播信息；

所述第一终端按照所述续播信息续播所述目标直播。

9.根据权利要求8所述的方法，其特征在于，所述第一终端按照所述续播信息续播所述目标直播，包括：

当所述续播信息中的客户端类型为移动终端，且所述第一终端的客户端类型也为移动终端时，所述第一终端按照所述续播信息中设置的直播模式续播所述目标直播；

当所述续播信息中的客户端类型为非移动终端，且所述第一终端的客户端类型为移动终端时，所述第一终端按照横屏模式续播所述目标直播；

当所述续播信息中的客户端类型为移动终端，且所述第一终端的客户端类型为非移动终端时，所述第一终端提示主播选择直播模式，并按照主播选择的直播模式续播所述目标直播。

10.根据权利要求8所述的方法，其特征在于，在所述第一终端向服务器发送直播请求之前，还包括：

所述第一终端显示第一直播预告的第一设置界面；

所述第一终端接收主播在所述第一设置界面中输入的预告内容，所述预告内容包括直播标题、直播时间、封面以及直播简介中的一项或多项；

所述第一终端将所述预告内容携带在预告请求中发送至所述服务器。

11.根据权利要求10所述的方法，其特征在于，在所述第一终端将所述预告内容携带在预告请求中发送至所述服务器之后，还包括：

所述第一终端跳转至直播预告的管理页面，所述管理页面包括已发布的一条或多条直播预告的管理列表。

12.一种服务器，其特征在于，包括：处理器和存储器，该存储器用于存储计算机程序，所述处理器用于调用并运行所述存储器中存储的计算机程序，以使得所述服务器执行如权利要求1-7中任一项所述的方法。

13.一种终端，其特征在于，包括：处理器和存储器，该存储器用于存储计算机程序，所述处理器用于调用并运行所述存储器中存储的计算机程序，以使得所述终端执行如权利要求8-11中任一项所述的方法。

14.一种计算机可读存储介质，其特征在于，用于存储计算机程序，所述计算机程序使得计算机执行如权利要求1-7或8-11中任一项所述的方法。

Images