直播流数据处理方法及装置与流程

本申请属于计算机技术领域，具体地说，涉及一种直播流数据处理方法及装置。

背景技术：

在网络直播应用中，直播客户端可以从服务器端获取直播流数据并播放，用户通过直播客户端可以观看直播流数据，直播流数据可以是视频、音频等多媒体数据。而为了方便直播结束之后也可以观看直播流数据，可以将直播流数据进行保存，从而可以在直播结束之后随时观看直播流数据。

现有技术中，直播客户端接收到用户触发的直播观看请求之后，会打开对应的直播网页，直播客户端中的内核组件解析该直播网页并向服务端发送数据获取请求，请求与服务端建立数据通道以获取直播流数据并展示。若直播客户端接收到数据保存请求，直播客户端会通过请求与服务端建立一条新的数据通路，通过该新建立的数据通路获取直播流数据并保存。

由以上描述可知，由于现有技术需要建立新的数据通道以获取需要保存的直播流数据，导致占用较多带宽，增加通信负担，影响直播观看效果。

技术实现要素：

有鉴于此，本申请主要针对直播流数据处理方法进行了研究，以解决直播客户端在下载直播流数据时，带宽占用较多的问题。

为了解决上述技术问题，本申请提供了一种直播流数据处理方法，该方法包括：

拦截内核组件发送的第一数据获取请求；

根据所述第一数据获取请求，生成第二数据获取请求并发送至服务端；所述第一数据获取请求中与所述第二数据获取请求中的接收地址不同；

获取所述服务端提供的直播流数据；

根据所述直播流数据，获得数据相同的第一路数据和第二路数据；

将所述第一路数据返回至所述内核组件；

接收到直播流数据保存请求时，保存所述第二路数据。

优选地，所述拦截内核组件发送的第一数据获取请求包括：

调用内核接口拦截内核组件发送的第一数据获取请求。

优选地，所述第二路数据包括多个标签文件；所述接收到直播流数据保存请求时，保存所述第二路数据之前，所述方法还包括：

解析所述第二路数据，以确定当前接收的标签文件；

所述接收到直播流数据保存请求时，保存所述第二路数据包括：

接收到直播流数据保存请求时，从当前接收的标签文件的下一个标签文件开始保存所述第二路数据。

优选地，所述从当前接收的标签文件的下一个标签文件开始保存所述第二路数据之后，所述方法还包括：

更新第一个保存的标签文件的时间戳为零。

优选地，所述根据所述直播流数据，获得第一路数据和第二路数据包括：

复制所述直播流数据获得复制数据；

将所述直播流数据以及复制中的任一个作为第一路数据，另一个作为第二路数据。

本申请还提供了一种直播流数据处理装置，其特征在于，包括：

拦截模块，用于拦截内核组件发送的第一数据获取请求；

生成模块，用于根据所述第一数据获取请求，生成第二数据获取请求并发送至服务端；所述第一数据获取请求中与所述第二数据获取请求中的接收地址不同；

获取模块，用于获取所述服务端提供的直播流数据；

处理模块，用于根据所述直播流数据，获得数据相同的第一路数据和第二路数据；

返回模块，用于将所述第一路数据返回至所述内核组件；

保存模块，用于接收到直播流数据保存请求时，保存所述第二路数据。

优选地，所述拦截模块包括：

拦截单元，用于调用内核接口拦截内核组件发送的第一数据获取请求。

优选地，所述第二路数据包括多个标签文件；所述装置还包括：

解析模块，用于解析所述第二路数据，以确定当前接收的标签文件；

所述保存模块包括：

第一保存单元，用于接收到直播流数据保存请求时，从当前接收的标签文件的下一个标签文件开始保存所述第二路数据。

优选地，其特征在于，所述保存模块还包括：

第一更新单元，用于更新第一个保存的标签文件的时间戳为零。

优选地，所述处理模块包括：

复制单元，用于复制所述直播流数据获得复制数据；

设置单元，用于将所述直播流数据以及复制中的任一个作为第一路数据，另一个作为第二路数据。

与现有技术相比，本申请可以获得包括以下技术效果：

本申请的技术方案中，直播客户端将内核组件中的第一视频获取请求进行拦截，从而阻断了内核组件获取直播流数据的数据通路。之后，根据第一数据获取请求，生成一个第二数据获取请求，使直播客户端能够通过第二数据获取请求来获取直播流数据。之后，根据所述直播流数据得到了第一路数据和第二路数据，并将第一路数据返回至内核组件，以使所述内核组件加载所述第一路数据，为用户播放直播流数据。而在接收到直播流数据的保存请求时，直播客户端将所述第二路数据进行保存，也即实现了直播流数据的本地保存。从而仅使用一路数据通路获取直播流数据，使其即可以被播放又可以被保存，减少了带宽的占用。

附图说明

此处所说明的附图用来提供对本申请的进一步理解，构成本申请的一部分，本申请的示意性实施例及其说明用于解释本申请，并不构成对本申请的不当限定。在附图中：

图1是本申请实施例的直播流数据处理方法的一个实施例流程图；

图2是本申请实施例的直播流数据处理方法的又一个实施例流程图；

图3是本申请实施例的直播流数据处理装置的一个实施例结构示意图；

图4是本申请实施例的直播流数据处理装置的又一个实施例结构示意图。

具体实施方式

以下将配合附图及实施例来详细说明本申请的实施方式，藉此对本申请如何应用技术手段来解决技术问题并达成技术功效的实现过程能充分理解并据以实施。

本发明实施例主要应用于运行在计算机系统的直播客户端中，该直播客户端包括内核组件，用以在直播客户端中嵌入浏览器功能，以使得直播客户端可以通过页面渲染实现直播流数据的播放。因此，内核组件可以为嵌入式框架，如cef(chromiumembeddedframework，基于chromium的嵌入式框架)。

其中，直播流数据可以是音频、视频等多媒体数据。直播客户端通过向服务端发送直播流数据获取请求，以建立与服务端的数据通路，即可以从服务端获取直播流数据并播放。在一个实际应用中，本发明实施例的直播流数据可以是flv(flashvideo，流媒体格式)数据。

直播客户端检测到直播流数据保存请求时，可以对当前播放的直播流数据进行录制以保存直播流数据。但是，发明人发现，现有技术中一旦进行直播流数据的保存时，就会影响直播流数据的播放效果，出现播放卡顿、不流畅的问题。发明人经过进一步研究发现，直播客户端接收到直播流数据保存请求后，会与服务端建立一个新的数据通路，以获取直播流数据并保存。这就导致直播客户端中存在两条与服务端之间的数据通路。由于存在两条数据通路，必然会占用较多的带宽，造成系统通信的负担增加，从而影响播放效果。

为了减少直播客户端与服务端之间的带宽占用，发明人想到是否可以仅建立一条数据通路以节约带宽占用，使得即可以保存直播流数据，又不影响直播流数据的播放。据此，发明人提出本发明的技术方案。

本发明实施例中，通过拦截内核组件发送的第一数据获取请求，然后重写第一数据获取请求以生成第二数据获取请求并发送至服务端。这样，服务端提供的直播流数据并不会直播发送至内核组件，因此，可以首先根据获取的直播流数据获得数据相同的两路数据：第一路数据和第二路数据，第一路数据返回至内核组件；在接收到直播流数据的保存请求时，直接保存所述第二路数据。进而实现了只通过一条数据通路即可以实现直播流数据的获取以及保存，进而避免占用过多带宽，增加通信负担。

下面将结合附图对本发明的技术方案进行详细说明。

如图1所示，为本发明实施例提供的一种直播流数据处理方法的一个实施例的流程图，该方法可以包括以下几个步骤：

101：拦截内核组件发送的第一数据获取请求。

内核组件被封装在直播客户端中，其可以是嵌入式浏览器框架，可以将浏览器的功能嵌入到直播客户端，进而可以使得直播客户端能够完成直播页面的页面渲染。常用的内核组件可以包括chrome内核、ie内核等，在一个实际应用中，该内核组件可以为cef。直播页面可以是由html5语言等网页语言编写的网页页面。

其中，在直播客户端中可以创建一处理组件，由该处理组件拦截内核组件发送的第一数据获取请求。可以根据内核组件提供的拦截接口等封装的一个处理类，再根据该处理类创建一个可以调用所述处理类的处理接口的处理对象，所述处理对象即为该处理组件。

第一数据获取请求可以是内核组件响应于用户触发的直播观看请求生成并发送的。如果用户想要观看某一个直播流数据时，可以执行进入该直播内容所在的直播页面的操作，以触发直播观看请求。

内核组件根据直播观看请求，可以对相应的直播页面进行解析，获取直播流数据的链接。内核组件根据该直播流数据的链接，可以生成向服务端请求直播流数据的第一数据获取请求。服务端可以根据直播流数据的链接，提供链接对应的所述直播流数据。

而本发明实施例中，通过处理组件对该内核组件发送的第一数据获取请求进行了拦截，使得第一数据获取请求无法发送至服务端。

102：根据所述第一数据获取请求，生成第二数据获取请求并发送所述第二数据获取请求至服务端。

其中，所述第一数据获取请求中与所述第二数据获取请求中的接收地址不同。因此，服务端根据第二数据获取请求发送的直播流数据，将不再发送至内核组件。本发明实施例中是通过直播客户端中的处理组件对第一数据获取请求进行的拦截，并据此生成第二数据获取请求，因此，可以使得直播流数据可以直接提供给处理组件而非内核组件。

所述第一数据获取请求是根据所述直播流文件的链接获得的，并通过内核组件发送到服务端。生成第二数据获取请求之前需要根据第一数据获取请求得到直播流文件的链接，再根据直播流文件的链接生成第二数据获取请求。所述第二数据获取请求是由直播客户端生成的。

由于第一数据获取请求中包括直播流数据的链接，因此作为一种可能的实现方式，所述根据所述第一数据获取请求，生成第二数据获取请求并发送至服务器可以包括：

根据所述第一数据获取请求，得到所述直播流数据的链接；

根据所述直播流数据的链接生成第二数据获取请求。

103：获取所述服务端提供的直播流数据。

由于是处理组件发送的第二数据获取请求，根据第二数据获取请求中的接收地址，服务端提供的直播流数据即发送至处理组件。

104：根据所述直播流数据，获得数据相同的第一路数据和第二路数据。

其中，第一路数据与第二路数据的数据内容即为该直播流数据的数据内容。

作为一个种可能的实现方式，所述根据所述直播流数据，获得数据相同的第一路数据和第二路数据可以包括：

复制所述直播流数据获得复制数据；

将所述直播流数据以及复制中的任一个作为第一路数据，另一个作为第二路数据。

也即通过将直播流数据进行复制，即可以获得两路数据。

本发明实施例中，只限定所述第一路数据和所述第二路数据的数据相同，并不限定所述第一路数据与所述第二路数据是直播流数据还是复制数据。其中，所述第一路数据可以是直播流数据，这时所述第二路数据即为复制数据；所述第一路数据也可以是复制数据，这时所述第二路数据即为直播流数据。

105：将所述第一路数据返回至内核组件；

为保证正常的直播播放，本发明实施例中，将第一路数据返回至内核组件，以使所述内核组件播放所述第一路数据。

具体的，内核组件可以将所述第一路数据加载到直播网页上，以在直播网页上播放所述直播流数据。

106：接收到直播流数据保存请求时，保存所述第二路数据。

如果接受到直播流数据保存请求，即可以直播保存所述第二路数据，既不会影响第一路数据的播放，不会影响直播播放效果，且无需重新建立数据通路进行数据下载，可以节省带宽。

其中，所述直播流数据保存请求，可以是响应于用户针对录制控件的操作而生成的。作为一种可能的实现方式，所述保存所述第二路数据具体可以是将所述第二路数据写入一个数据文件中。

本发明实施例中，对内核组件发送的第一数据获取请求进行了拦截，使得第一数据获取请求无法发送至服务端。之后根据第一数据获取请求生成第二数据获取请求，从而可以根据获得的直播流数据得到数据相同的两路数据，一路返回内核组件，一路进行保存。从而仅用一个数据通路即可以实现播放以及保存，减少了带宽占用，避免增加通信负担。

作为又一个实施例，为了方便用户查找到保存的直播流数据，所述接收到直播流数据保存请求时，保存所述第二路数据可以包括：

接收到直播流数据保存请求时，为用户展示一个可供选择直播流数据保存路径的路径选择界面；

接收到用户选择的保存路径时，将所述第二路数据保存到所述用户选择的路径中。

作为又一个实施例，所述接收到直播流数据保存请求时，保存所述第二路数据可以包括：

接收到直播流数据保存请求时，将所述第二路数据保存到预设置的存储路径中。

其中，所述预设置的存储路径可以是直播客户端默认的存储路径，也可以是用户在其他任意时间设置的第二路数据的保存路径。

由于，内核组件可以提供内核接口，因此，作为一个实施例，为了提高拦截效率，所述拦截内核组件发送的第一数据获取请求可以包括：

调用内核接口拦截内核组件发送的第一数据获取请求。

其中，所述内核接口可以由内核组件提供。

内核接口是由内核组件提供的。内核接口也可以称之为内核控件。当处理组件访问该内核接口时，可以事先建立一个能够访问该接口的对象，通过该对象才能实现访问。

作为又一个实施例，为了确保内核接口的有效性，进一步提高拦截效率，所述调用内核接口拦截内核组件发送的第一数据获取请求可以包括：

监测到所述内核接口被实现时，调用内核接口拦截内核组件发送的第一数据获取请求。

所述内核接口被实现可以是后台人员通过参数设置使内核接口使能，以令所述内核接口能够被调用。

当所述内核接口未被实现时，则可以不拦截内核组件发送的第一数据获取请求，然后仍然通过原有的方式，由内核组件向服务端发送第一数据获取请求，以请求直播流数据行播放。

如图2所示为本发明提供的一种直播流数据处理方法的又一个实施例的流程图，该方法可以包括以下几个步骤：

201：拦截内核组件发送的第一数据获取请求。

202:根据所述第一数据获取请求，生成第二数据获取请求并发送所述第二数据获取请求至服务端。

203:获取所述服务端提供的直播流数据。

204:根据所述直播流数据，获得数据相同的第一路数据和第二路数据。

所述直播流数据通过复制得到复制数据。将所述直播流数据以及复制数据中的任一个作为第一路数据，另一个作为第二路数据。

由此，所述第一路数据与所述第二路数据的数据内容相同，从本质上讲均与直播流数据的数据内容相同。

205:将所述第一路数据返回至内核组件。

206：解析所述第二路数据，以确定当前接收的标签文件；

本实施例中，直播流数据可以为flv数据，其中，可以包括多个标签(tag)文件，每一个标签文件可以封装成一帧或者多帧音视频数据。直播流数据为flv数据时，包括header(头)部分以及body(身体)部分，header部分中记录了flv文件的类型、版本等信息，body由多个标签(tag)文件和标签头(tagheader)文件构成。

从服务端下载直播流数据时，是下载完成一个标签文件之后，再即系下载下一个标签文件。

因此，通过解析第二路数据，可以确定当前接收的标签文件，以及当前接收的标签文件的下载进度以确定是否完成下载等。

207：接收到直播流数据保存请求时，从当前接收的标签文件的下一个标签文件开始保存所述第二路数据。

所述第二路数据在接收时是以字节流的形式进行接收的。所述解析所述第二路数据可以是解析所述第二路数据的字节流。由于不能判断客户端何时能够接收到直播流数据保存请求，所以，一旦接收到第二路数据时，即对第二路数据进行解析，以确定当前接收的标签文件。第二路数据的接收是持续进行的，所述解析所述第二路数据也是持续进行的。

本发明实施例中，通过一个直播流数据的获取请求即实现了内核播放直播流数据和保存直播流数据两种功能，在保存直播流数据时，采用随时接收随时解析的方法，一旦获取到直播流数据保存请求，即可将解析的标签文件进行保存。进而在节约带宽的同时，还可以快速实现数据保存。

可选地，所述标签文件中可以包含该标签文件的时间戳。时间戳用于标识该标签文件在直播流数据的播放进度条上的播放时刻。直播流数据的播放进度条上到达此播放时刻时，即播放该标签文件。

由于接收到直播流数据保存请求后，从当前接收的标签文件的下一个标签文件开始保存所述第二路数据。所述下一个标签文件并不是直播流数据接收到的第一个标签文件，其时间戳为该标签文件在当前正在播放的直播流数据的播放进度条上的播放时刻。如果将该标签文件的时间戳直接进行保存，则在播放保存的第二路数据时，会造成从0开始一直到所述下一标签文件的时间戳标识的播放时刻之间没有任何内容，会影响用户观看。

因此，为了实现保存的第二路数据的正常播放，作为一种可能的实现方式，所述从当前接收的标签文件的下一个标签文件开始保存所述第二路数据之后，所述方法还可以包括：

更新第一个保存的标签文件的时间戳为零。

当然，为了使后续的标签文件也能够按照保存时间进行正常播放，所述方法还可以包括：

在更新第一个保存的标签文件的时间戳为零后，从零开始，按照保存时间先后顺序更新后续保存的标签文件中的时间戳。

由于所述第二路数据实际上多为视频数据、音频数据，但无论是视频数据还是视频数据，均存在头文件信息，以标识该文件的类型、版本等信息，进而保障数据的正常播放。本发明实施例中，从当前接收的标签文件的下一个标签文件开始保存所述第二路数据之前，所述方法还可以包括：

将所述第二路数据的头文件信息保存至当前保存所述第二路数据的文件。

所述第二路数据的头文件信息可以是在第一次接收到第二路数据时，通过解析第一次接收的第二路数据获得的。

如图3所示，为本申请实施例中直播流数据处理装置的一个实施例结构示意图，该装置可以包括：

拦截模块301，用于拦截内核组件发送的第一数据获取请求；

内核组件被封装在直播客户端中，其可以是嵌入式浏览器框架，可以将浏览器的功能嵌入到直播客户端，进而可以使得直播客户端能够完成直播页面的页面渲染。常用的内核组件可以包括chrome内核、ie内核等，在一个实际应用中，该内核组件可以为cef。直播页面可以是由html5语言等网页语言编写的网页页面。

第一数据获取请求可以是内核组件响应于用户触发的直播观看请求生成并发送的。如果用户想要观看某一个直播流数据时，可以执行进入该直播内容所在的直播页面的操作，以触发直播观看请求。

内核组件根据直播观看请求，可以对相应的直播页面进行解析，获取直播流数据的链接。内核组件根据该直播流数据的链接，可以生成向服务端请求直播流数据的第一数据获取请求。服务端可以根据直播流数据的链接，提供链接对应的所述直播流数据。而本发明实施例中，通过处理组件对该内核组件发送的第一数据获取请求进行了拦截，使得第一数据获取请求无法发送至服务端。

生成模块302，用于根据所述第一数据获取请求，生成第二数据获取请求并发送至服务端。

其中，所述第一数据获取请求中与所述第二数据获取请求中的接收地址不同。因此，服务端根据第二数据获取请求发送的直播流数据，将不再发送至内核组件。本发明实施例中是通过直播客户端中的处理组件对第一数据获取请求进行的拦截，并据此生成第二数据获取请求，因此，可以使得直播流数据可以直接提供给处理组件而非内核组件。

所述第一数据获取请求是根据所述直播流文件的链接获得的，并通过内核组件发送到服务端。生成第二数据获取请求之前需要根据第一数据获取请求得到直播流文件的链接，再根据直播流文件的链接生成第二数据获取请求。所述第二数据获取请求是由直播客户端生成的。

由于第一数据获取请求中包括直播流数据的链接，因此作为一种可能的实现方式，所述生成模块可以包括：

获取单元，用于根据所述第一数据获取请求，得到所述直播流数据的链接；

生成单元，用于根据所述直播流数据的链接生成第二数据获取请求。

获取模块303，用于获取所述服务端提供的直播流数据。

由于是处理组件发送的第二数据获取请求，根据第二数据获取请求中的接收地址，服务端提供的直播流数据即发送至处理组件。

处理模块304，用于根据所述直播流数据，获得数据相同的第一路数据和第二路数据。

其中，第一路数据与第二路数据的数据内容即为该直播流数据的数据内容。

作为一个种可能的实现方式，所述处理模块可以包括：

复制单元，用于复制所述直播流数据获得复制数据；

设置单元，用于将所述直播流数据以及复制中的任一个作为第一路数据，另一个作为第二路数据。

也即通过将直播流数据进行复制，即可以获得两路数据。

本发明实施例中，只限定所述第一路数据和所述第二路数据的数据相同，并不限定所述第一路数据与所述第二路数据是直播流数据还是复制数据。其中，所述第一路数据可以是直播流数据，这时所述第二路数据即为复制数据；所述第一路数据也可以是复制数据，这时所述第二路数据即为直播流数据。

返回模块305，用于将所述第一路数据返回至所述内核组件。

为保证正常的直播播放，本发明实施例中，将第一路数据返回至内核组件，以使所述内核组件播放所述第一路数据。

具体的，内核组件可以将所述第一路数据加载到直播网页上，以在直播网页上播放所述直播流数据。

保存模块306，用于接收到直播流数据保存请求时，保存所述第二路数据。

如果接受到直播流数据保存请求，即可以直播保存所述第二路数据，既不会影响第一路数据的播放，不会影响直播播放效果，且无需重新建立数据通路进行数据下载，可以节省带宽。

其中，所述直播流数据保存请求，可以是响应于用户针对录制控件的操作而生成的。

作为一种可能的实现方式，所述保存所述第二路数据具体可以是将所述第二路数据写入一个数据文件中。

本发明实施例中，对内核组件发送的第一数据获取请求进行了拦截，使得第一数据获取请求无法发送至服务端。之后根据第一数据获取请求生成第二数据获取请求，从而可以根据获得的直播流数据得到数据相同的两路数据，一路返回内核组件，一路进行保存。从而仅用一个数据通路即可以实现播放以及保存，减少了带宽占用，避免增加通信负担。

作为一个实施例，为了实现所述第二路数据的保存工作，方便用户查找到保存的直播流数据，所述保存模块可以包括：

页面展示单元，用于在接收到直播流数据保存请求时，为用户展示一个可供选择直播流数据保存路径的路径选择界面；

第二保存单元，用于在接收到用户选择的保存路径时，将所述第二路数据保存到所述用户选择的路径中。

作为又一个实施例，保存所述第二路数据时，为了不切断用户观看直播流数据，保障观看的流畅性，所述保存模块可以包括：

第三保存单元，用于在接收到直播流数据保存请求时，将所述第二路数据保存到预设置的存储路径中。

其中，所述预设置的存储路径可以是直播客户端默认的存储路径，也可以是用户在其他任意时间设置的第二路数据的保存路径。

由于，内核组件可以提供内核接口，因此，作为一个实施例，为了提高拦截效率，所述拦截模块包括：

拦截单元，用于调用内核接口拦截内核组件发送的第一数据获取请求。

其中，所述内核接口可以由内核组件提供。

内核接口是由内核组件提供的。内核接口也可以称之为内核控件。当处理组件访问该内核接口时，可以事先建立一个能够访问该接口的对象，通过该对象才能实现访问。

作为又一个实施例，为了确保内核接口的有效性，进一步提高拦截效率，所述拦截单元可以包括：

拦截子单元，用于在监测到所述内核接口被实现时，调用内核接口拦截内核组件发送的第一数据获取请求。

所述内核接口被实现可以是后台人员通过参数设置使内核接口使能，以令所述内核接口能够被调用。

当所述内核接口未被实现时，则可以不拦截内核组件发送的第一数据获取请求，然后仍然通过原有的方式，由内核组件向服务端发送第一数据获取请求，以请求直播流数据行播放。

如图4所示为本发明提供的一种直播流数据处理装置的又一个实施例的流程图，该装置可以包括以下几个模块：

拦截模块401：拦截内核组件发送的第一数据获取请求。

生成模块402:根据所述第一数据获取请求，生成第二数据获取请求并发送所述第二数据获取请求至服务端。

获取模块403:获取所述服务端提供的直播流数据。

处理模块404:根据所述直播流数据，获得数据相同的第一路数据和第二路数据。

所述直播流数据通过复制得到复制数据。将所述直播流数据以及复制数据中的任一个作为第一路数据，另一个作为第二路数据。

由此，所述第一路数据与所述第二路数据的数据内容相同，从本质上讲均与直播流数据的数据内容相同。

返回模块405:将所述第一路数据返回至内核组件。

解析模块406：用于解析所述第二路数据，以确实当前接收的标签文件；

所述保存模块407可以包括：

第一保存单元408：用于接收到直播流数据保存请求时，从当前接收的标签文件的下一个标签文件开始保存所述第二路数据。

本发明实施例中，通过一个直播流数据的获取请求即实现了内核播放直播流数据和保存直播流数据两种功能，在保存直播流数据时，采用随时接收随时解析的方法，一旦获取到直播流数据保存请求，即可将解析的标签文件进行保存。进而在节约带宽的同时，还可以快速实现数据保存。

可选地，所述标签文件中包含当前接收的标签文件的时间戳。时间戳用于标识该标签文件在直播流数据的播放进度条上的播放时刻。

由于接收到直播流数据保存请求后，从当前接收的标签文件的下一个标签文件开始保存所述第二路数据。所述下一个标签文件并不是直播流数据接收到的第一个标签文件，其时间戳为该标签文件在当前正在播放的直播流数据的播放进度条上的播放时刻。如果将该标签文件的时间戳直接进行保存，则在播放保存的第二路数据时，会造成从0开始一直到所述下一标签文件的时间戳标识的播放时刻之间没有任何内容，会影响用户观看。

因此，为了实现保存的第二路数据的正常播放，作为一种可能的实现方式，所述从当前接收的标签文件的下一个标签文件开始保存所述第二路数据之后，所述装置还可以包括：

第一更新模块，用于更新第一个保存的标签文件的时间戳为零。

当然，为了使后续的标签文件也能够按照保存时间进行正常播放，所述装置还可以包括：

第二更新模块，在更新第一个保存的标签文件的时间戳为零后，从零开始，按照保存时间先后顺序更新后续保存的标签文件中的时间戳。

由于所述第二路数据实际上多为视频数据、音频数据，但无论是视频数据还是视频数据，均存在头文件信息，以标识该文件的类型、版本等信息，进而保障数据的正常播放。本发明实施例中，从当前接收的标签文件的下一个标签文件开始保存所述第二路数据之前，所述保存模块还可以包括：

第四保存单元，用于将所述第二路数据的头文件信息保存至当前保存所述第二路数据的文件。

所述第二路数据的头文件信息可以是在第一次接收到第二路数据时，通过解析第一次接收的第二路数据获得的。

在一个典型的配置中，计算设备包括一个或多个处理器(cpu)、输入/输出接口、网络接口和内存。

内存可能包括计算机可读介质中的非永久性存储器，随机存取存储器(ram)和/或非易失性内存等形式，如只读存储器(rom)或闪存(flashram)。内存是计算机可读介质的示例。

计算机可读介质包括永久性和非永久性、可移动和非可移动媒体可以由任何方法或技术来实现信息存储。信息可以是计算机可读指令、数据结构、程序的模块或其他数据。计算机的存储介质的例子包括，但不限于相变内存(pram)、静态随机存取存储器(sram)、动态随机存取存储器(dram)、其他类型的随机存取存储器(ram)、只读存储器(rom)、电可擦除可编程只读存储器(eeprom)、快闪记忆体或其他内存技术、只读光盘只读存储器(cd-rom)、数字多功能光盘(dvd)或其他光学存储、磁盒式磁带，磁带磁磁盘存储或其他磁性存储设备或任何其他非传输介质，可用于存储可以被计算设备访问的信息。按照本文中的界定，计算机可读介质不包括非暂存电脑可读媒体(transitorymedia)，如调制的数据信号和载波。

如在说明书及权利要求当中使用了某些词汇来指称特定组件。本领域技术人员应可理解，硬件制造商可能会用不同名词来称呼同一个组件。本说明书及权利要求并不以名称的差异来作为区分组件的方式，而是以组件在功能上的差异来作为区分的准则。如在通篇说明书及权利要求当中所提及的“包含”为一开放式用语，故应解释成“包含但不限定于”。“大致”是指在可接收的误差范围内，本领域技术人员能够在一定误差范围内解决所述技术问题，基本达到所述技术效果。此外，“耦接”一词在此包含任何直接及间接的电性耦接手段。因此，若文中描述一第一装置耦接于一第二装置，则代表所述第一装置可直接电性耦接于所述第二装置，或通过其他装置或耦接手段间接地电性耦接至所述第二装置。说明书后续描述为实施本申请的较佳实施方式，然所述描述乃以说明本申请的一般原则为目的，并非用以限定本申请的范围。本申请的保护范围当视所附权利要求所界定者为准。

还需要说明的是，术语“包括”、“包含”或者其任何其他变体意在涵盖非排他性的包含，从而使得包括一系列要素的商品或者系统不仅包括那些要素，而且还包括没有明确列出的其他要素，或者是还包括为这种商品或者系统所固有的要素。在没有更多限制的情况下，由语句“包括一个……”限定的要素，并不排除在包括所述要素的商品或者系统中还存在另外的相同要素

上述说明示出并描述了本申请的若干优选实施例，但如前所述，应当理解本申请并非局限于本文所披露的形式，不应看作是对其他实施例的排除，而可用于各种其他组合、修改和环境，并能够在本文所述申请构想范围内，通过上述教导或相关领域的技术或知识进行改动。而本领域人员所进行的改动和变化不脱离本申请的精神和范围，则都应在本申请所附权利要求的保护范围内。