CN108574877B - 直播方法、主播端、观众端、设备、系统及存储介质 - Google Patents

Abstract

本发明提供了直播方法、主播端、观众端及直播系统，涉及网络直播领域。本申请提供的直播方法，采用将播放关键信息从直播数据流中分离出的方式，将下发直播数据流的工作交由应用服务器进行，使得观众端不需要等待其接收到直播数据流后才能够初始化播放器，而是可以向应用服务器请求获取播放关键信息，进而，某种程度上，可以做到对观众端的播放器进行预先初始化，使得播放器播放直播数据流的速度提高了。

Description

直播方法、主播端、观众端、设备、系统及存储介质

技术领域

本发明涉及网络直播领域，具体而言，涉及直播方法、主播端、观众端、直播系统及存储介质。

背景技术

网络直播是指可以同时透过网络系统在不同的交流平台观看视频数据的播放方式。视频数据主要包括实时直播游戏，电影，或电视剧等。

网络直播由于吸取和延续了互联网的优势，利用视讯方式进行网上现场直播，可以将产品展示、相关会议、背景介绍、方案测评、网上调查、对话访谈、在线培训等内容现场发布到互联网上，利用互联网的直观、快速，表现形式好、内容丰富、交互性强、地域不受限制、受众可划分等特点，可以加强活动现场的推广效果。

在进行直播时，通常首先由主播端向服务器推送视频流，而后，服务器在接收到观众端的点播请求后，将接收到的视频流向观众端推送。

发明内容

本申请的目的在于提供直播方法、主播端、观众端及直播系统。

第一方面，本发明实施例提供了一种直播方法，包括：

观众端向应用服务器发出获取请求，以确定直播数据流的播放关键信息和播放地址；

观众端向播放地址所对应的多媒体服务器发出观看请求，以确定直播数据流；

观众端使用播放关键信息初始化播放器；

观众端使用初始化完成的播放器播放直播数据流。

第二方面，本发明实施例提供了一种用于直播的观众端，包括：

第一发送模块，用于向应用服务器发出获取请求，以确定直播数据流的播放关键信息和播放地址；

第二发送模块，用于向播放地址所对应的多媒体服务器发出观看请求，以确定直播数据流；

初始化模块，用于观众端使用播放关键信息初始化播放器；

播放模块，用于观众端使用初始化完成的播放器播放直播数据流。

第三方面，本发明实施例还提供了一种直播方法，包括：

主播端生成播放关键信息和直播数据流；

主播端将播放关键信息向应用服务器发送，以及主播端将直播数据流向多媒体服务器发送。

第四方面，本发明实施例还提供了一种用于直播的主播端，包括：

生成模块，用于生成播放关键信息和直播数据流；

第三发送模块，用于分别将播放关键信息向应用服务器发送，以及主播端将直播数据流向多媒体服务器发送。

第五方面，本发明实施例还提供了一种直播系统，包括：应用服务器、多媒体服务器、观众端和主播端，观众端分别能与应用服务器和多媒体服务器连接；主播端分别能与应用服务器和多媒体服务器连接。：

主播端，用于按照如第三方面所述的方法执行相应的操作；

观众端，用于按照如第一方面所述的方法执行相应的操作；

应用服务器和多媒体服务器，均用于根据主播端和观众端所发出的请求进行相应的操作。

第六方面，本发明实施例还提供了一种观众端设备，包括：存储器、通信总线以及处理器，其中，所述存储器用于存储程序代码，所述处理器用于调用所述程序代码，执行如第一方面所述的方法。

第七方面，本发明实施例还提供了一种主播端设备，包括：存储器、通信总线以及处理器，其中，所述存储器用于存储程序代码，所述处理器用于调用所述程序代码，执行如第二方面的方法。

第八方面，本发明实施例还提供了一种具有处理器可执行的非易失的程序代码的计算机可读介质，所述程序代码使所述处理器执行第一方面的方法。

第九方面，本发明实施例还提供了另一种具有处理器可执行的非易失的程序代码的计算机可读介质，所述程序代码使所述处理器执行第二方面的方法。

本申请实施例提供的直播方法，与相关技术中，观众端先要从应用服务器获取多媒体服务器的播放地址，再从播放地址所对应的多媒体服务器中获取到播放关键信息，而后才能够初始化相比。本方案采用由观众端向应用服务器发出获取请求，来获取直播数据流的播放关键信息和多媒体服务器的播放地址，进而观众端可以直接利用播放关键信息直接对播放器进行初始化，以及向播放地址所对应的多媒体服务器请求直播数据流，而后再利用初始化完成的播放器播放直播数据流。由于观众端能够直接从应用服务器处得到播放关键信息，不再需要等应用服务器返回播放地址后才能够从播放地址所对应的多媒体服务器处得到播放关键信息，进而，某种程度上，观众端能够更早的对播放器进行预先初始化，使得播放器播放直播数据流的速度提高了。

为使本发明的上述目的、特征和优点能更明显易懂，下文特举较佳实施例，并配合所附附图，作详细说明如下。

附图说明

为了更清楚地说明本发明实施例的技术方案，下面将对实施例中所需要使用的附图作简单地介绍，应当理解，下述附图仅示出了本发明的某些实施例，因此不应被看作是对范围的限定，对于本领域普通技术人员来讲，在不付出创造性劳动的前提下，还可以根据这些附图获得其他相关的附图。

图1示出了相关技术中进行网络直播的系统工作时序图；

图2示出了相关技术中进行网络直播的过程中，观众端的部分细节工作流程示意图；

图3示出了本发明所提供的网络直播系统的架构图；

图4示出了本发明所提供的直播方法的基本流程图；

图5示出了本发明所提供的直播方法的细节优化流程图；

图6示出了本发明所提供的网络直播系统的工作时序图；

图7示出了本发明所提供的网络直播方法中，观众端的部分细节工作流程示意图；

图8示出了本发明所提供的观众端设备结构示意图；

图9示出了本发明所提供的主播端设备结构示意图。

具体实施方式

下面将结合本发明实施例中附图，对本发明实施例中的技术方案进行清楚、完整地描述，显然，所描述的实施例仅仅是本发明一部分实施例，而不是全部的实施例。通常在此处附图中描述和示出的本发明实施例的组件可以以各种不同的配置来布置和设计。因此，以下对在附图中提供的本发明的实施例的详细描述并非旨在限制要求保护的本发明的范围，而是仅仅表示本发明的选定实施例。基于本发明的实施例，本领域技术人员在没有做出创造性劳动的前提下所获得的所有其他实施例，都属于本发明保护的范围。

随着互联网技术的发展，网络直播已经融入到了普通人的日常生活中。网络直播至少需要有三端构成，分别是主播端、服务器和观众端，主播端的主要作用是录制与主播人员相关的音视频(如主播所唱的歌曲、主播所玩游戏的过程)，并将录制好的视频以数据流的形式实时上传至服务器中。服务器的主要作用是接收主播端所发出的视频流，并将视频流向指定的观众端推送。观众端的主要作用是通过接收观众的操作，来向服务器发起观看直播的请求，并接收服务器所发出的数据流(由主播端所上传的数据流)，而后，根据该数据流输出相应的音视频来让观众观看。

如图1所示，示出了相关技术中进行网络直播的系统工作时序图。由图1可以了解到，相关技术中进行网络直播可以分为如下步骤：

步骤1，主播端向应用服务器发出推流地址获取请求；

步骤2，应用服务器向主播端返回推流地址信息；

步骤3，主播端将播放关键信息和与编码后的音视频数据(录制与主播人员相关的音视频数据)打包在一个直播数据流中，并将该直播数据流推送至多媒体服务器；

步骤4，多媒体服务器在接收到直播数据流后，向主播端返回成功接收的信息；

步骤5，主播端在接收到成功接收的信息后，向应用服务器发送上传成功的信息；

步骤6，应用服务器在接收到上传成功的信息后，向主播端返回表示成功的信息，并在相应的界面中显示对应的基本信息；

步骤7，观众端在观众的控制下，向应用服务器发出获取播放地址请求；

步骤8，应用服务器向观众端返回与获取播放地址请求相对应的播放地址(播放地址与推流地址相对应)；

步骤9，观众端向播放地址所对应的多媒体服务器发出观看请求；

步骤10，多媒体服务器向观众端返回直播数据流；

步骤11，观众端解析直播数据流，获取到播放关键信息和音视频数据；

步骤12，观众端利用播放关键信息初始化播放器，并使用完成初始化的播放器播放音视频数据。

上述流程中，播放关键信息主要指的是音视频播放所需要的信息，如分辨率等。其中，播放关键信息的具体内容主要是与相应的视频编码规则、音频编码规则有关，一般的视频编码规则如H.264/AVC 和H.265/HEVC，一般的音频编码规则如AAC(Advanced AudioCoding)。

如图2所示，反映了相关技术中，步骤9在执行的相关具体细节，上述步骤9执行前，观众端在得到了播放地址后，通常需要将播放地址中的域名进行DNS解析，来得到对应的多媒体服务器的IP，之后，步骤9中，观众端向该IP所对应的多媒体服务器发出观看请求，进而同时获取到三个数据，分别是播放关键信息、音频数据和视频数据，相关技术中，这三个数据均是携带在直播数据流中的。

本申请发明人在工作中发现，上述网络直播技术并不理想，主要是体现在观众在观看直播时系统响应缓慢。具体而言，上述流程中，观众端是预先知晓应用服务器的网络地址的，但不清楚多媒体服务器的播放地址，因此需要由应用服务器给观众端分配对应的多媒体服务器的播放地址，观众端才能够从播放地址所对应的多媒体服务器处获取到直播数据流，进而，观众端才能够从直播数据流中提取到播放关键信息，进而利用解析到的播放关键信息对播放器进行初始化，进而，在初始化完成后，才能够使用播放器播放直播数据流。可见，相关技术中，观众端在播放直播视频前需要经过多个步骤的处理，耗时较长，影响用户体验。

针对该种情况，本申请发明人认为，可以采用将播放关键信息和音视频数据相分离的方式，不再让观众端从直播数据流中获取到播放关键信息，而是让观众端直接从应用服务器获取播放关键信息，某种情况下，使得用户可以将获取播放关键信息的时机提前，这样用户可以先利用播放关键信息进行初始化，而后，观众端在接收到音视频数据后就可以更快的进行播放了(由于观众端是预先知晓应用服务器的网络地址的，因此，可以随时从应用服务器处获取播放关键信息)。进而，本申请相对应的提供了一种直播方法，该直播方法应用于网络直播系统，如图2所示，该网络直播系统包括应用服务器、多媒体服务器和观众端，其中，观众端分别能与应用服务器和多媒体服务器连接(通常是长连接)，某种情况下，该网络直播系统还包括主播端，该主播端分别能与应用服务器和多媒体服务器连接(通常是长连接)。本申请所提供的直播方法如图3所示，包括如下步骤：

步骤S101，观众端向应用服务器发出获取请求，以确定直播数据流的播放关键信息和播放地址；

步骤S102，观众端向播放地址所对应的多媒体服务器发出观看请求，以确定直播数据流；

步骤S103，观众端使用播放关键信息初始化播放器；

步骤S104，观众端使用初始化完成的播放器播放直播数据流。

上述步骤中，步骤S102和步骤S103是并行的关系，这两个步骤之间并无绝对的先后关系，也就是，步骤S102的执行条件是确定了播放地址，步骤S103的执行条件是确定了播放关键信息。即，在步骤S101执行完毕后，就可以执行步骤S103，而不是等步骤S102 执行完毕后，再执行步骤S103。

同时，不限定步骤S102和步骤S103的绝对执行顺序，这也是本方案的核心内容，采用这种方式能够使得观众端在从应用服务器处拿到播放关键信息后，直接进行播放器初始化，而不是如相关技术中那样，观众端只有等拿到直播流数据后，从直播数据流中解析出播放关键信息，而后才能够使用解析出的播放关键信息对播放器进行初始化。

采用本方案的这种工作方式，观众端在接收到用户的选择指令后 (如点击观看A主播的直播视频)，由于观众端是预先知晓应用服务器的网络地址的，因此可以直接向应用服务器发出获取请求来获取播放关键信息，并利用获取到的播放关键信息进行初始化，某种情况下，将播放器初始化完成的时间提前了。进而，可以使得播放器能够更早的播放直播数据流。

下面对本方案实现的具体过程和细节进行介绍。

上述步骤S101中，目的是使观众端能够获取到播放关键信息和播放地址。实际操作中，观众端获取播放关键信息和播放地址的方式有两种，下面分别进行说明：

第一种观众端获取播放关键信息和播放地址的方式，即步骤 S101可以由如下步骤构成：

观众端向应用服务器分别发送获取播放关键信息请求和获取播放地址请求，以使应用服务器根据获取播放关键信息请求返回相应的播放关键信息，以及，使应用服务器根据获取播放地址请求返回相应的播放地址。

也就是，观众端可以通过分别发送两个不同的请求的方式来获取到获取播放关键信息和播放地址。这两个请求的发送时机可以是同时 (如观众端在接收到观众的操作后，同时发送这获取播放关键信息请求和获取播放地址请求)，也可以是某一个先发送，另一个后发送(如观众端可以在发送获取播放关键信息请求后的X秒后发送获取播放地址请求)，也可以是受到用户的操作来发送这两个请求(如，观众端收到用户的第一个操作指令时，向应用服务器发送获取播放关键信息请求，以及，观众端在收到用户的第二个操作指令时，向应用服务器发送获取播放地址请求)。

具体的，使用时，应用服务器可以是一个，也可以是两个，当应用服务器是一个的时候，播放关键信息和播放地址均存储在该应用服务器中，获取播放关键信息请求和获取播放地址请求均是向这一个应用服务器发送的。当应用服务器是两个(第一应用服务器和第二应用服务器)的时候，第一应用服务器中存储有播放关键信息，第二应用服务器中存储有播放地址，进而步骤S101可以按照如下方式执行：

观众端向应用服务器分别向第一应用服务器发送获取播放关键信息请求，以及向第二应用服务器发送获取播放地址请求，以使第一应用服务器根据获取播放关键信息请求返回相应的播放关键信息，以及，使第二应用服务器根据获取播放地址请求返回相应的播放地址。其中，第一应用服务器中存储有播放关键信息，第二应用服务器中存储有播放地址。

使用两个应用服务器的这种方式，从某个角度看，一定程度上能够保证数据的安全性。

第二种观众端获取播放关键信息和播放地址的方式，即步骤 S101可以由如下步骤构成：

观众端向应用服务器发出获取请求，以使应用服务器根据获取播放关键信息请求返回相应的播放关键信息，以及，使应用服务器根据获取播放地址请求返回相应的播放地址；获取请求中携带有获取播放关键信息请求和获取播放地址请求。

在第二种方式中，观众端只通过发送一个获取请求就可以使得应用服务器返回播放地址和播放关键信息(某种情况下，可以认为是将获取播放关键信息请求和获取播放地址请求的代码写到了一个请求中)。和第一种方式相比，减少了发送请求的次数，并且避免了获取播放关键信息请求和获取播放地址请求中，某一个请求发送失败而导致观众端无法观看直播的问题。

上述两种方式在具体执行时，是通过应用服务器直接返回播放关键信息的方式来使得观众端确定播放关键信息，具体执行时，应用服务器还可以不返回播放关键信息的具体内容，而是返回播放关键信息所对应的编码，进而使观众端依据代码查找对应的播放关键信息的具体内容，此种方式在后文中会进行说明。

步骤S101的执行实际有两种情况，分别是受用户触发和受时间触发。

受用户触发指的是，本申请所提供的方法还包括：

若观众端检测到用户的操作指令，则触发步骤S101执行。

其中，用户的操作指令如用户操作鼠标或键盘向观众端所下达的指令。

受时间触发指的是，本申请所提供的方法还包括：

若观众端检测到当前时间符合预设的时间要求，则触发步骤 S101执行。

受时间触发有两种情况，分别是到达指定的时刻(如中午12点、下午2点)时触发步骤S101执行；以及，在计时到达预定的时间长度时触发步骤S101执行(如观众端在开机后进行计时，当计时达到两个小时后，触发步骤S101执行)。

需要说明的是，上述步骤S102和步骤S103之间并没有必然的先后关系，步骤S102的执行条件是观众端得到播放地址，步骤S103 的执行条件是观众端得到播放关键信息。步骤S102和步骤S103可以是并行的。

播放关键信息指的是播放器播放音视频数据所需要的参数(如视频源的宽高)或者是能够换算得出这些参数的编码，这些参数受到编码规则的影响。具体的，播放关键信息有两种，分别是视频关键信息和音频关键信息，视频关键信息的具体参数内容如下：

使用H.264/AVC编码规则时，视频关键信息通常是指：序列参数集SPS(SequenceParameter Sets)和图像参数集PPS(Picture Parameter Sets)。H.264/AVC标准定义了多个NAL(Network Abstraction Layer)Unit，用于传输编码之后的数据，SPS/PPS是其中的两类。

使用H.265/HEVC编码时，视频关键信息是指：序列参数集 SPS(SequenceParameter Sets)、图像参数集PPS(Picture Parameter Sets) 和视频参数集VPS(VideoParameter Sets)。

音频关键信息所涉及的内容如下：

使用AAC编码规则时，音频关键信息是指：音频数据传输流 ADTS(Audio DataTransport Stream)。

上述关于视频关键信息和音频关键信息的距离仅仅是示例性的，如果使用其他编码规则，音视频关键信息还可以进行相应的调整。当然，播放关键信息除了上述这些明文的音视关键信息的具体编码，还可以是能够解析出这些音视频编码规则的代码(如能够换算出这些具体参数的编号)，如使用关键信息编号能够解析出音视频编码规则，则关键信息编号本身也可以被视为播放关键信息，如，使用某些解密算法、换算算法能够从关键信息密码中解析出音视频编码规则，则关键信息编号本身也可以被视为播放关键信息。

步骤S101执行时，应用服务器必然已经知晓播放关键信息，从数据来源的角度来看，播放关键信息是由主播端产生的，也就是主播端在生成包含有音视频数据(如录制主播的跳舞过程，游戏过程)的直播数据流的时候，也会同时生成播放关键信息，并且，是按照如下步骤发出的：

步骤A，主播端生成播放关键信息和直播数据流；

步骤B，主播端将播放关键信息向应用服务器发送，以及主播端将直播数据流向多媒体服务器发送。

其中，步骤B有两种实现方式，一种是直接发送，即，主播端将播放关键信息直接发送给应用服务器，另一种是间接发送，即主播端将播放关键信息经过其他网络端(如多媒体服务器)发送给应用服务器。进而，应用服务器(或者是第一应用服务器)获取播放关键信息的途径有两个，下面分别对这两个途径进行介绍。

途径1(直接发送)：

播放关键信息是由主播端生成，并直接向应用服务器发送的。即，步骤B，包括如下步骤：

主播端将播放关键信息直接向应用服务器发送；

途径2(间接发送)：

播放关键信息是由主播端生成后，由主播端采用将播放关键信息加载到直播数据流内的方式，将播放关键信息向多媒体服务器发送，并由多媒体服务器从直播数据流中提取出播放关键信息，并将播放关键信息向应用服务器发送的。

即，途径2可以按照如下过程执行：

步骤201，主播端以将播放关键信息加载在直播数据流中的方式，将播放关键信息向多媒体服务器发送；

步骤202，多媒体服务器从直播数据流中提取播放关键信息；

步骤203，多媒体服务器将播放关键信息向应用服务器发送。

上述途径1和途径2相比，各有优缺点。相较而言，途径1的方式，播放关键信息是不经过多媒体服务器的，这样，多媒体服务器就不需要进行改造，只需要对主播端进行改造(相对于某些相关技术而言)，并且，某种情况下，可以使得多媒体服务器不会知晓播放关键信息，信息安全有一定保障。途径2的方式，对主播端没有改造需要进行改造，但需要对多媒体服务器进行改造，即增加多媒体服务器的工作(相对于某些相关技术而言)。需要说明的是，如果是对主播端进行改造，则需要采用客户端批量升级的方式进行，如果对多媒体服务器进行改造，则可能涉及在线升级或者是离线升级的方式。具体采用途径1的方式，还是途径2的方式应当考虑具体的使用场景和需求，本申请发明人在综合考虑了使用场景的特殊性后，认为采用途径1 的方式更为合理。需要说明的是，途径2中，多媒体服务器向应用服务器发送了数据，则多媒体服务器和应用服务器必然能够建立连接。

一般情况下下，发送播放关键信息或直播数据流之间是不需要限定先后顺序的，但为了保证用户的感受度，应当先执行主播端将直播数据流向多媒体服务器发送的步骤，再执行主播端将播放关键信息向应用服务器发送的步骤。

具体的，实际操作中，为了更好的保证用户感受度，步骤B应当按照如下步骤执行：

步骤B1，主播端向应用服务器发出获取推流地址请求，以获取推流地址；

步骤B2，主播端向推流地址所对应的多媒体服务器推送直播数据流；

步骤B3，若主播端接收到多媒体服务器返回的推流成功信息，则执行步骤主播端将播放关键信息向应用服务器发送。

一般情况下，应用服务器在接收到关键信息编号或播放关键信息后，就会直接在网页或指定的链接中显示直播封面和简介，观众就可以操作观众端直接点击封面或某个进入按钮来请求多媒体服务器的直播数据流了，此时，如果多媒体服务器没有成功接收到直播数据流，则多媒体无服务器是无法向观众端提供视频流的，此时会造成观众的感受度下降，因此，应当限制步骤之间的执行顺序，以使用户在请求直播数据流的时候能够第一时间获取到。

一般情况下，观众端并不是只具有观看直播的这一个功能，还有可能需要进行实时通信，实时通话或者是进行其他紧急的操作，此时，则应当尽量保证网络流量是被合理的使用，进而，步骤S103后还包括：

步骤301，观众端判断初始化播放器是否成功；

若观众端判断初始化播放器成功，则执行步骤S102；若观众端判断初始化播放器不成功，则观众端输出错误消息，和/或重新执行步骤S103，和/或终止当前流程。

也就是，只有初始化播放器成功之后，观众端才开始向多媒体服务器发出观看请求，以使应用服务器在接收到获取请求后，返回直播数据流。以此来保证获取直播数据流的网络流量没有被浪费。此时，必然先执行步骤S103，而后，再有选择性的执行步骤S102。输出端的错误消息可以有很多种，比如向指定服务器所发送的报警消息，又或者是在观众端的显示屏上显示提示信息，以告知观众。

优选的，为了更准确的利用网络流量，还可以按照如下方式实现，即，在步骤S103后还包括：

步骤302，观众端获取当前的网络负载值；

步骤303，观众端判断网络负载值是否超过了预定的阈值，若观众端判断网络负载值超过预定的阈值，则执行步骤301，或观众端等待播放器初始化成功后，执行步骤S102，和/或输出错误消息，和/ 或终止当前流程；若观众端判断网络负载值未超过预定的阈值，则直接执行步骤S102。

也就是，步骤303在执行后，如果判断为否，则可以执行步骤 301或者是观众端等待播放器初始化完成后，执行步骤S102，不论是执行步骤301还是观众端等待播放器初始化完成后，执行步骤S102，都可以同时执行输出错误消息，和/或执行终止当前流程。

其中，网络负载值有多种确认的方式，下面仅列举几种常见的方式：方式1，根据观众端其他网络交互程序的网络速率确定；方式2，根据观众端当前信号强度确定；方式3，根据观众端在指定时间段(通常是当前时间段)从多媒体服务器中获取直播数据流的网络速率确定。当然，网络负载值可以综合上述几种中的一种或多种来综合确定，也就是，网络负载值是根据以下的一种或多种参数确定：观众端上所运行的其他利用网络进行数据交互的程序的网络速率、观众端当前信号强度和观众端在指定时间段(通常是当前时间段)从多媒体服务器中获取直播数据流的网络速率。

上述内容中，观众端上所运行的其他利用网络进行数据交互的程序的网络速率指的是观众端运行的其他程序(除直播程序以外的其他程序，如视频下载程序、网络聊天程序)的下载、上传速率。观众端的信号强度多见于移动端，观众端作为智能终端，必然可能通过测速的方式来确定其自身的信号强度。观众端在指定时间段从多媒体服务器中获取直播数据流的网络速率指的是当前，或之前某一段时间内，观众端获取直播数据流的速率(比如观众端可能同时缓存两个直播数据流，没有被观看的一个直播数据流的网络传输速率，或者是刚刚看完的直播的网络传输速率)。

如前文中的说明，某种情况下，为了降低传输的播放关键信息的数据量，可以预先为不同的播放关键信息设定对应的编号，进而建立播放关键信息对照表，并且将该对照表预存在应用服务器(或第一应用服务器)和观众端中，进而观众端在向应用服务器请求播放关键信息时，应用服务器可以只返回播放关键信息所对应的编号，而不返回具体的播放关键信息的内容，这样能够一定程度上保证播放关键信息的安全性，并且，还可以通过设立独立的验证机制来进一步使得播放关键信息不会被恶意获取，从而使得非授权的终端无法正常播放直播数据。

具体而言，如图4所示，步骤S101包括：

步骤S1011，观众端向应用服务器发出获取请求，以获取直播数据流的关键信息编号；

步骤S1012，观众端根据关键信息编号，在存储在观众端内的本地对照表中查找所述关键信息编号所对应的播放关键信息。

执行步骤S1011和步骤S1012的前提是应用服务器预先知晓关键信息编号。当然，应当在观众端中预存关键信息编号和播放关键信息的对照表。

某种情况下，当应用服务器中预存有对照表时，应用服务器会对对照表进行更新，此时则应当通知观众端也对对照表进行更新。

即，步骤S101还可以包括如下步骤：

步骤1013，观众端向应用服务器发出本地对照表，以确定本地对照表的是否正确；

步骤1041，若获取到表示本地对照表为正确的信息，则执行步骤S1012；

若获取到新对照表，则使用新对照表对本地对照表进行更新，并执行步骤S1012。

其中，步骤S1013可以与步骤S1011同时执行，即在发出获取请求时，也发出本地对照表(比如可以将本地对照表携带在获取请求中)。这样，如果收到表示本地对照表为正确的信息，则说明对照表是最新的，就可以直接使用了，如果收到服务器所发出的新的对照表，则需要对本地对照表进行更新，而后，在利用关键信息编号查找对应的播放关键信息。这样，能够保证查找到的播放关键信息是正确的。

但如果观众端更新失败(或者是没有接收到更新的指令，或者是没有接收到新对照表)，则观众端的播放会造成错误，进而观众端在播放的时候还应当进行如下操作，即步骤S104后还包括：

观众端检测当前的播放状态；

若播放状态为正常，则观众端不作处理；

若播放状态为异常，则观众端向应用服务器发出更新对照表的请求，以获取应用服务器所发出的参考对照表；

观众端使用参考对照表对本地对照表进行更新，并重新执行步骤 S1012。

当播放出现异常的时候还可以按照如下方式处理，即步骤S104 后还包括：

观众端检测当前的播放状态；

若播放状态为正常，则观众端不作处理；

若播放状态为异常，则观众端向应用服务器发出直接获取播放关键信息请求；

观众端在接收到应用服务器所返回的播放关键信息后重新执行步骤S103。

其中，播放状态是否为异常，可以根据图像/声音是否被正常解码，图像大小的是否与观众端显示器的大小相匹配来判断，又或者可以根据是否接收到网络直播数据来判断。

具体的，应用服务器知晓编号的方式有两种，下面分别进行介绍：

第一种应用服务器知晓编号的方式，可以在应用服务器中预存关键信息编号和播放关键信息的对照表(主播端中可以存储，也可以不存储关键信息编号和播放关键信息的对照表)，进而在观众端发出获取请求后，应用服务器通过查表的方式来找到对应的关键信息编号，并将该编号发送给观众端；

第二种应用服务器知晓编号的方式，可以是主播端中预存有预存关键信息编号和播放关键信息的对照表(应用服务器中不存储关键信息编号和播放关键信息的对照表)，而主播端只将关键信息编号上传给应用服务器，并且由应用服务器将关键信息编号转发给观众端。

上述第一种方式，使用较为方便，在需要的时候(如每隔预定的时间)，应用服务器和观众端可以直接同步关键信息编号和播放关键信息的对照表。第二种方式，应用服务器则不会知晓具体的播放关键信息，而是只知道关键信息编号，这样一定程度上能够保证数据安全。

第一种应用服务器知晓编号的方式，即，步骤主播端将播放关键信息向应用服务器发送可以按照如下步骤实现：

步骤401，主播端将播放关键信息直接向应用服务器发送，以使应用服务器根据预存在应用服务器中的对照表，确定播放关键信息所对应的关键信息编号。

其中，具体执行时，主播端可以将播放关键信息直接向应用服务器发送，也可以通过其他的中转端(如多媒体服务器)向应用服务器发送。这种方式中，应用服务器中是存储有对照表的。一般情况下，应用服务器中预存的对照表和观众端中的对照表是相同的。

第二种应用服务器知晓编号的方式，即，步骤B可以按照如下步骤实现：

步骤501，主播端根据主播端中预存的对照表，查找播放关键信息所对应的关键信息编号；

步骤502，主播端将关键信息编号向应用服务器发送，以使应用服务器记录关键信息编号。

其中，一般情况下，主播端中预存的对照表和观众端中的对照表是相同的。

具体的，对照表的形式可以是如下表1所示：

表1

序号	播放关键信息内容	关键信息编号
			1	VVVVVVVV	ABC
2	WWWWWWWW	ACD
			3	XXXXXXXX	ABE
4	YYYYYYYY	BCD
			5	ZZZZZZZZ	BFA

从表1可见，应用服务器只需要向关键信息编号(如ABC、ACD) 向观众端发送，而后，观众端依据其内部存储的对照表就可以解读出相应的播放关键信息的内容了。

下面以2个具体的实例来说明本申请所提供的方法。

实例1(如图6所示)：

步骤1001，主播端向应用服务器发出推流地址获取请求；

步骤1002，应用服务器向主播端返回推流地址信息；

步骤1003，主播端将编码后的音视频数据(录制与主播人员相关的音视频数据)打包在一个直播数据流中，并将该直播数据流推送至多媒体服务器；

步骤1004，多媒体服务器在接收到直播数据流后，向主播端返回成功接收的信息；

步骤1005，主播端在接收到成功接收的信息后，向应用服务器发送上传成功的信息和播放关键信息发送至应用服务器；

步骤1006，应用服务器在接收到上传成功的信息后，向主播端返回表示成功的信息，并在相应的界面中显示对应的基本信息；

步骤1007，观众端在观众的控制下，向应用服务器发出获取播放地址请求；

步骤1008，应用服务器向观众端返回与获取播放地址请求相对应的播放地址(播放地址与推流地址相对应)和播放关键信息，并在获取到播放关键信息后执行步骤1009，和在获取到播放地址后执行步骤1010；

步骤1009，观众端使用播放关键信息初始化播放器；

步骤1010，观众端向播放地址所对应的多媒体服务器发出观看请求；

步骤1011，多媒体服务器向观众端返回直播数据流；

步骤1012，观众端解析直播数据流，获取到音视频数据；

步骤1013，观众端使用完成初始化的播放器播放音视频数据。

如图7所示，观众端在得到了播放地址和播放关键信息后，并行处理了两个流程，分别是对播放地址进行DNS解析,来得到对应的多媒体服务器的IP，之后，步骤1010中观众端向该IP所对应的多媒体服务器发出观看请求，进而在步骤1011获取到了直播数据流。

上述步骤在执行时，步骤1010和步骤1009并无绝对的先后顺序，这两个步骤可以同时执行；也可以是在获取到播放关键信息后直接执行步骤1009，和在获取到播放地址后直接执行步骤1010。

实例2：

步骤2001，主播端向应用服务器发出推流地址获取请求；

步骤2002，应用服务器向主播端返回推流地址信息；

步骤2003，主播端将编码后的音视频数据(录制与主播人员相关的音视频数据)打包在一个直播数据流中，并将该直播数据流推送至多媒体服务器；

步骤2004，多媒体服务器在接收到直播数据流后，向主播端返回成功接收的信息；

步骤2005，主播端在接收到成功接收的信息后，向应用服务器发送上传成功的信息和播放关键信息所对应的关键信息编号发送至应用服务器；

步骤2006，应用服务器在接收到上传成功的信息后，向主播端返回表示成功的信息，并在相应的界面中显示对应的基本信息；

步骤2007，观众端在观众的控制下，向应用服务器发出获取播放地址请求；

步骤2008，应用服务器向观众端返回与获取播放地址请求相对应的播放地址(播放地址与推流地址相对应)和关键信息编号，并执行步骤2009和步骤2010；

步骤2009，观众端使用关键信息编号在本地查找对应的播放关键信息，并使用查找到的播放关键信息初始化播放器；

步骤2010，观众端获取当前网络负载值；

步骤2011，观众端判断当前网络负载值是否超过预设的数值，若观众端判断当前网络负载值超过预设的数值，则执行步骤2012，若观众端判断当前网络负载值未超过预设的数值，则执行步骤2013；

步骤2012，观众端判断播放器是否初始化完成，若观众端判断播放器初始化完成，则执行步骤2013，若观众端判断播放器未初始化完成，则在预定时间后重新执行步骤2012；

步骤2013，观众端向播放地址所对应的多媒体服务器发出观看请求；

步骤2014，多媒体服务器向观众端返回直播数据流；

步骤2015，观众端解析直播数据流，获取到音视频数据；

步骤2016，观众端使用完成初始化的播放器播放音视频数据。

上述步骤2009和步骤2010的执行并没有必然的前后顺序的要求，这两个步骤的前后关系可以是同步也可以是异步。

上述内容中，分别公开了以主播端为主体的直播方法和以观众端为主体的直播方法，本申请结合上述公开内容，还公开了网络直播系统，该网络直播系统包括应用服务器、多媒体服务器和观众端，其中，观众端分别能与应用服务器和多媒体服务器连接(通常是长连接)，该网络直播系统还包括主播端，该主播端分别能与应用服务器和多媒体服务器连接(通常是长连接)；

主播端和观众端用于按照上述相应的工作方式执行相应的操作；

应用服务器和多媒体服务器，均用于根据主播端和观众端所发出的请求进行相应的操作。

与上述方法相对应的，本申请还提供了一种用于直播的观众端，包括：

第一发送模块，用于向应用服务器发出获取请求，以确定直播数据流的播放关键信息和播放地址；

第二发送模块，用于向播放地址所对应的多媒体服务器发出观看请求，以确定直播数据流；

初始化模块，用于观众端使用播放关键信息初始化播放器；

播放模块，用于观众端使用初始化完成的播放器播放直播数据流。

优选的，播放关键信息是由主播端生成，并直接向应用服务器发送的；

或，播放关键信息是由主播端生成后，由主播端采用将播放关键信息加载到直播数据流内的方式，将播放关键信息向多媒体服务器发送，并由多媒体服务器从直播数据流中提取出播放关键信息，并将播放关键信息向应用服务器发送的。

优选的，观众端还包括：

第一判断模块，用于判断初始化播放器是否成功，若初始化播放器成功，则驱动第二发送模块工作。

优选的，观众端还包括：

第一获取模块，用于获取当前的网络负载值；

第二判断模块，用于判断网络负载值是否超过了预定的阈值，若网络负载值超过预定的阈值，则观众端等待播放器初始化成功后，驱动第二发送模块工作；若网络负载值未超过预定的阈值，则直接驱动第二发送模块工作。

优选的，网络负载值是根据以下的一种或多种参数确定：观众端其他网络交互程序的网络速率、观众端当前信号强度和观众端在指定时间段从多媒体服务器中获取直播数据流的网络速率确定。

优选的，第一发送模块包括：

第一发送单元，用于向应用服务器发出获取请求，以获取直播数据流的关键信息编号；

查找单元，用于根据关键信息编号，在存储在观众端内的本地对照表中查找所述关键信息编号所对应的播放关键信息。

优选的，观众端还包括：

第一检测模块，用于检测当前的播放状态；

第四发送模块，用于当播放状态为异常时，则向应用服务器发出更新对照表的请求，以获取应用服务器所发出的参考对照表；

更新模块，用于使用参考对照表对本地对照表进行更新，并驱动查找单元工作；

或，

第二检测模块，用于检测当前的播放状态；

第五发送模块，用于当播放状态为异常时，向应用服务器发出直接获取播放关键信息请求；

驱动模块，用于在接收到应用服务器所返回的播放关键信息后，驱动初始化模块重新工作。

与上述方法相对应的，本申请还提供了一种用于直播的主播端，包括：

生成模块，用于生成播放关键信息和直播数据流；

第三发送模块，用于分别将播放关键信息向应用服务器发送，以及主播端将直播数据流向多媒体服务器发送。

优选的，第三发送模块包括：

第二发送单元，用于将直播数据流向多媒体服务器发送的步骤；

第三发送单元，用于将播放关键信息向应用服务器发送的步骤；

所述第二发送单元先于第三发送单元工作。

优选的，第三发送模块包括：

第四发送单元，用于向应用服务器发出获取推流地址请求，以获取推流地址；

推送单元，用于向推流地址所对应的多媒体服务器推送直播数据流；

第五发送单元，用于当接收到多媒体服务器返回的推流成功信息，则将播放关键信息向应用服务器发送。

优选的，第五发送单元进一步用于：

将播放关键信息直接向应用服务器发送，以使应用服务器根据预存在应用服务器中的对照表，确定播放关键信息所对应的关键信息编号；

或，

第五发送单元进一步用于：根据主播端中预存的对照表，查找播放关键信息所对应的关键信息编号，以及将关键信息编号向应用服务器发送，以使应用服务器记录关键信息编号。

如图8所示，为本申请另一实施例所提供的观众端设备示意图，该观众端设备80包括：处理器81、存储器82和总线83，存储器82 存储有执行指令，当装置运行时，处理器81与存储器82之间通过总线83通信，处理器81执行存储器82中存储的如下执行指令：

观众端向应用服务器发出获取请求，以确定直播数据流的播放关键信息和播放地址；

观众端向播放地址所对应的多媒体服务器发出观看请求，以确定直播数据流；

观众端使用播放关键信息初始化播放器；

观众端使用初始化完成的播放器播放直播数据流。

处理器81具体工作流程可以参照前文中所公开的方法。

如图9所示，为本申请另一实施例所提供的观众端设备示意图，该观众端设备90包括：处理器91、存储器92和总线93，存储器92 存储有执行指令，当装置运行时，处理器91与存储器92之间通过总线93通信，处理器91执行存储器92中存储的如下执行指令：

主播端生成播放关键信息和直播数据流；

主播端将播放关键信息向应用服务器发送，以及主播端将直播数据流向多媒体服务器发送。

处理器91具体工作流程可以参照前文中所公开的方法。

本申请还提供了一种具有处理器可执行的非易失的程序代码的计算机可读介质，其特征在于，所述程序代码使所述处理器执行以观众端，和/或主播端为执行主体的直播方法。

所属领域的技术人员可以清楚地了解到，为描述的方便和简洁，上述描述的系统、装置和单元的具体工作过程，可以参考前述方法实施例中的对应过程，在此不再赘述。

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

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

Claims (14)

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

观众端向应用服务器发出获取请求，以确定直播数据流的播放关键信息和播放地址；

所述观众端向所述播放地址所对应的多媒体服务器发出观看请求，以确定直播数据流；

所述观众端使用所述播放关键信息初始化播放器；

所述观众端使用所述初始化完成的播放器播放所述直播数据流；

步骤观众端向应用服务器发出获取请求，以确定直播数据流的播放关键信息和播放地址包括：

所述观众端向所述应用服务器发出获取请求，以获取所述直播数据流的关键信息编号；

观众端根据所述关键信息编号，在存储在观众端内的本地对照表中查找所述关键信息编号所对应的所述播放关键信息；

所述方法还包括：

所述观众端检测当前的播放状态；

若所述播放状态为异常，则所述观众端向应用服务器发出更新对照表的请求，以获取应用服务器所发出的参考对照表；

观众端使用所述参考对照表对本地对照表进行更新，并重新执行步骤观众端根据关键信息编号，在本地对照表中查找所述关键信息编号所对应的播放关键信息；

或，

观众端检测当前的播放状态；

若所述播放状态为异常，则所述观众端向所述应用服务器发出直接获取所述播放关键信息请求；

所述观众端在接收到所述应用服务器所返回的所述播放关键信息后重新执行步骤观众端使用播放关键信息初始化播放器。

2.根据权利要求1所述方法，其特征在于，

所述播放关键信息是由主播端生成，并直接向所述应用服务器发送的；

或，播放关键信息是由主播端生成后，由所述主播端采用将所述播放关键信息加载到所述直播数据流内的方式，将所述播放关键信息向所述多媒体服务器发送，并由所述多媒体服务器从所述直播数据流中提取出所述播放关键信息，并将所述播放关键信息向应用服务器发送的。

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

所述观众端判断所述初始化播放器是否成功；

若所述观众端判断初始化播放器成功，则执行步骤观众端向播放地址所对应的多媒体服务器发出观看请求。

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

所述观众端获取当前的网络负载值；

所述观众端判断所述网络负载值是否超过了预定的阈值，若所述观众端判断网络负载值超过预定的阈值，则所述观众端等待播放器初始化成功后，执行步骤观众端向播放地址所对应的多媒体服务器发出观看请求；若所述观众端判断网络负载值未超过预定的阈值，则直接执行步骤观众端向播放地址所对应的多媒体服务器发出观看请求。

5.根据权利要求4所述方法，其特征在于，所述网络负载值是根据以下的一种或多种参数确定：观众端其他网络交互程序的网络速率、观众端当前信号强度和观众端在指定时间段从多媒体服务器中获取直播数据流的网络速率确定。

6.一种用于直播的观众端，其特征在于，包括：

第一发送模块，用于向应用服务器发出获取请求，以确定直播数据流的播放关键信息和播放地址；

第二发送模块，用于向播放地址所对应的多媒体服务器发出观看请求，以确定直播数据流；

初始化模块，用于使用所述播放关键信息初始化播放器；

播放模块，用于使用所述初始化完成的播放器播放所述直播数据流；

第一发送模块包括：

第一发送单元，用于向应用服务器发出获取请求，以获取直播数据流的关键信息编号；

查找单元，用于根据关键信息编号，在存储在观众端内的本地对照表中查找所述关键信息编号所对应的播放关键信息；

观众端还包括：

第一检测模块，用于检测当前的播放状态；

第四发送模块，用于当播放状态为异常时，则向应用服务器发出更新对照表的请求，以获取应用服务器所发出的参考对照表；

更新模块，用于使用参考对照表对本地对照表进行更新，并驱动查找单元工作；

或，

第二检测模块，用于检测当前的播放状态；

第五发送模块，用于当播放状态为异常时，向应用服务器发出直接获取播放关键信息请求；

驱动模块，用于在接收到应用服务器所返回的播放关键信息后，驱动初始化模块重新工作。

7.一种直播方法，与权利要求1所提供的方法相对应，其特征在于，包括：

主播端生成播放关键信息和直播数据流；

所述主播端将所述播放关键信息向应用服务器发送，以及所述主播端将所述直播数据流向多媒体服务器发送；

步骤主播端将播放关键信息向应用服务器发送，以及主播端将直播数据流向多媒体服务器发送包括：

所述主播端向所述应用服务器发出获取推流地址请求，以获取推流地址；

所述主播端向推流地址所对应的多媒体服务器推送所述直播数据流；

若所述主播端接收到所述多媒体服务器返回的推流成功信息，则主播端将所述播放关键信息向应用服务器发送；

步骤主播端将播放关键信息向应用服务器发送包括：

所述主播端将所述播放关键信息直接向所述应用服务器发送，以使所述应用服务器根据预存在所述应用服务器中的对照表，确定所述播放关键信息所对应的关键信息编号；

或，

所述主播端根据所述主播端中预存的对照表，查找所述播放关键信息所对应的关键信息编号；

所述主播端将所述关键信息编号向所述应用服务器发送，以使所述应用服务器记录所述关键信息编号。

8.根据权利要求7所述方法，其特征在于，步骤主播端将播放关键信息向应用服务器发送，以及主播端将直播数据流向多媒体服务器发送包括：

先执行主播端将直播数据流向多媒体服务器发送的步骤，再执行主播端将播放关键信息向应用服务器发送的步骤。

9.一种用于直播的主播端，其特征在于，包括：

生成模块，用于生成播放关键信息和直播数据流；

第三发送模块，用于分别将所述播放关键信息向应用服务器发送，以及主播端将所述直播数据流向多媒体服务器发送；

第三发送模块包括：

第四发送单元，用于向应用服务器发出获取推流地址请求，以获取推流地址；

推送单元，用于向推流地址所对应的多媒体服务器推送直播数据流；

第五发送单元，用于当接收到多媒体服务器返回的推流成功信息，则将播放关键信息向应用服务器发送；

优选的，第五发送单元进一步用于：

将播放关键信息直接向应用服务器发送，以使应用服务器根据预存在应用服务器中的对照表，确定播放关键信息所对应的关键信息编号；

或，

第五发送单元进一步用于：根据主播端中预存的对照表，查找播放关键信息所对应的关键信息编号，以及将关键信息编号向应用服务器发送，以使应用服务器记录关键信息编号。

10.一种直播系统，包括：应用服务器、多媒体服务器、观众端和主播端，所述观众端分别能与所述应用服务器和所述多媒体服务器连接；主播端分别能与所述应用服务器和所述多媒体服务器连接；

所述主播端，用于按照如权利要求7-8任一项所述的方法执行相应的操作；

所述观众端，用于按照如权利要求1-5任一项所述的方法执行相应的操作；

所述应用服务器和多媒体服务器，均用于根据主播端和观众端所发出的请求进行相应的操作。

11.一种观众端设备，其特征在于，包括：存储器、通信总线以及处理器，其中，所述存储器用于存储程序代码，所述处理器用于调用所述程序代码，执行如权利要求1-5任一项所述的方法。

12.一种主播端设备，其特征在于，包括：存储器、通信总线以及处理器，其中，所述存储器用于存储程序代码，所述处理器用于调用所述程序代码，执行如权利要求7-8任一项所述的方法。

13.一种具有处理器可执行的非易失的程序代码的计算机可读介质，其特征在于，所述程序代码使所述处理器执行所述权利要求1-5任一项所述方法。

14.一种具有处理器可执行的非易失的程序代码的计算机可读介质，其特征在于，所述程序代码使所述处理器执行所述权利要求7-8任一项所述方法。

Images