CN105306966B - 一种直播视频数据处理方法、装置及系统 - Google Patents

Abstract

本申请提供了一种直播视频数据处理方法，包括：服务器中基于Linux平台的HTTP服务器响应客户端发送的携带有视频码率和直播节目源的第一直播请求，向所述客户端发送与所述视频码率和所述直播节目源对应的m3u8文件；以及，响应客户端发送的携带有从所述m3u8文件中获取到的视频索引名称的第二直播请求，从预设哈希表中获取与所述视频索引名称对应的TS片段的内存地址；以及，从所述TS片段的内存地址对应的内存中获取TS片段；以及向发送所述第二直播请求的客户端发送所述TS片段。因此，本申请节约了磁盘空间，提高了响应用户请求的效率，改善了用户体验性。

Description

一种直播视频数据处理方法、装置及系统

技术领域

本申请涉及互联网流媒体直播领域，特别涉及一种直播视频数据处理方法、装置及系统。

背景技术

随着21世纪计算机领域相关技术的飞速发展，音视频编解码技术的提高，宽带网络的普及以及其成本不断降低，3G、4G等技术的成熟及无线宽带网络接入能力的不断提升，促使越来越多的用户喜欢在互联网上收看直播节目。

针对用户在互联网上收看直播节目的需求，微软提供了基于HLS(HTTP LiveStreaming)协议的直播方案，具体为将分段的TS(Transport Stream)文件是存储在磁盘上，服务器在响应用户请求时，需要从磁盘上读取分段的TS文件到内存中，然后再发送到用户请求对应的播放设备。此直播方案浪费了磁盘空间，而且由于增大了磁盘的读写开销，使响应用户请求的效率也随之下降，导致用户体验性差。

发明内容

为解决上述技术问题，本申请实施例提供一种直播视频数据处理方法、装置及系统，以达到节约磁盘空间，提高响应用户请求的效率，改善用户体验性的目的，技术方案如下：

一种直播视频数据处理方法，包括：

服务器中基于Linux平台的超文本传输协议HTTP服务器响应客户端发送的携带有视频码率和直播节目源的第一直播请求，向所述客户端发送与所述视频码率和所述直播节目源对应的m3u8文件；以及，

响应客户端发送的携带有从所述m3u8文件中获取到的视频索引名称的第二直播请求，从预设哈希表中获取与所述视频索引名称对应的TS片段的内存地址；以及，

从所述TS片段的内存地址对应的内存中获取TS片段；以及，

向发送所述第二直播请求的客户端发送所述TS片段。

优选的，所述TS片段的生成过程包括：

所述HTTP服务器的Apache模块接收平滑流Smooth Streaming流；以及，

从所述Smooth Streaming流中获取公用音频流和多个视频流，其中所述公用音频流包括音频类型的多个连续的ISMV片段，各个视频流各自对应不同的分辨率和码率，每个视频流包括视频类型的多个ISMV片段，同一个视频流包括的各个ISMV片段的分辨率相同且码率相同；以及，

将音频类型的每个ISMV片段分别和与所述音频类型的ISMV片段时间戳相对应的视频类型的各个ISMV片段重新打包为TS片段。

优选的，所述Smooth Streaming流的生成过程，包括：

所述服务器的编码器按照Smooth Streaming协议，对原始媒体数据进行多码率编码，得到Smooth Streaming流。

优选的，所述原始媒体数据由所述服务器的信号采集卡通过高清晰度多媒体接口HDMI接口采集。

优选的，所述服务器的编码器按照Smooth Streaming协议，对原始媒体数据进行多码率编码的过程包括：

所述服务器的Windows Media Encoder SDK编码器按照Smooth Streaming协议，对原始媒体数据进行多码率编码。

一种直播视频数据处理装置，包括：

第一发送模块，用于响应客户端发送的携带有视频码率和直播节目源的第一直播请求，向所述客户端发送与所述视频码率和所述直播节目源对应的m3u8文件；

第一获取模块，用于响应客户端发送的携带有从所述m3u8文件中获取到的视频索引名称的第二直播请求，从预设哈希表中获取与所述视频索引名称对应的TS片段的内存地址；

第二获取模块，用于从所述TS片段的内存地址对应的内存中获取TS片段；

第二发送模块，用于向发送所述第二直播请求的客户端发送所述TS片段。

优选的，还包括：Apache模块，其中所述Apache模块包括：

接收单元，用于接收Smooth Streaming流；

获取单元，用于从所述Smooth Streaming流中获取公用音频流和多个视频流，其中所述公用音频流包括音频类型的多个连续的ISMV片段，各个视频流各自对应不同的分辨率和码率，每个视频流包括视频类型的多个ISMV片段，同一个视频流包括的各个ISMV片段的分辨率相同且码率相同；

打包单元，用于将音频类型的每个ISMV片段分别和与所述音频类型的ISMV片段时间戳相对应的视频类型的各个ISMV片段重新打包为TS片段。

一种直播视频数据处理系统，包括所述直播视频数据处理装置和编码装置，其中：

所述编码装置，用于按照Smooth Streaming协议，对原始媒体数据进行多码率编码，得到Smooth Streaming流。

优选的，还包括：

信号采集装置，用于通过HDMI接口采集所述原始媒体数据。

优选的，所述编码装置包括：Windows Media Encoder SDK编码装置。

与现有技术相比，本申请的有益效果为：

在本申请中，将TS片段直接存储在内存中，不再占用磁盘空间，节约了磁盘空间。由于客户端在发送直播请求后，基于Linux平台的HTTP服务器通过从预设哈希表中获取对应的TS片段的内存地址，从所述TS片段的内存地址对应的内存中获取TS片段，可见，无需再从磁盘空间中读取TS片段，避免了磁盘的读写开销，提高了响应用户请求的效率，改善了+用户体验性。

附图说明

为了更清楚地说明本申请实施例中的技术方案，下面将对实施例描述中所需要使用的附图作简单地介绍，显而易见地，下面描述中的附图仅仅是本申请的一些实施例，对于本领域普通技术人员来讲，在不付出创造性劳动性的前提下，还可以根据这些附图获得其他的附图。

图1是本申请提供的一种直播视频数据处理方法的一种流程图；

图2是本申请提供的直播视频数据处理方法的一种子流程图；

图3是本申请提供的直播视频数据处理方法的另一种流程图；

图4是本申请提供的直播视频数据处理装置的一种结构示意图；

图5是本申请提供的直播视频数据处理装置的另一种结构示意图；

图6是本申请提供的Apache模块的一种结构示意图；

图7是本申请提供的直播视频数据处理系统的一种结构示意图；

图8是本申请提供的直播视频数据处理系统的另一种结构示意图。

具体实施方式

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

实施例一

请参见图1，其示出了本申请提供的一种直播视频数据处理方法的一种流程图，需要说明的是，本申请提供的直播视频数据处理方法基于HLS协议，可以包括以下步骤：

步骤S11：服务器中基于Linux平台的HTTP(超文本传输协议，HTTP-Hypertexttransfer protocol)服务器响应客户端发送携带有视频码率和直播节目源的第一直播请求，向所述客户端发送与所述视频码率和所述直播节目源对应的m3u8文件。

客户端在接收到用户输入的观看直播节目的命令后，向基于Linux平台的HTTP服务器发送用户所指定的直播节目源对应的第一直播请求，基于Linux平台的HTTP服务器根据客户端发送的携带有视频码率和直播节目源的第一直播请求，确定客户端所请求的直播节目源及客户端所要求的视频码率，获取客户端所请求的直播节目源和视频码率对应的m3u8文件，并向所述客户端发送与所述第一直播请求对应的m3u8文件。

需要说明的是，一个直播节目源对应有多个m3u8文件，每个m3u8文件记录有TS片段和TS片段对应的视频索引名称。各个m3u8文件对应的视频码率各不相同即各个m3u8文件记录的TS片段的视频码率各不相同，但是同一个m3u8文件中的TS片段的视频码率相同。

当然，基于Linux平台的HTTP服务器维护多个直播节目源的直播过程，在每个直播节目源的直播过程中，不断更新相应直播节目源对应的TS片段和m3u8文件。

在本申请中，直播节目源对应的TS片段存储在基于Linux平台的HTTP服务器的内存中。

步骤S12：基于Linux平台的HTTP服务器响应客户端发送的携带有从所述m3u8文件中获取到的视频索引名称的第二直播请求，从预设哈希表中获取与所述视频索引名称对应的TS片段的内存地址。

在本实施例中，预设哈希表的每个表项记录的是视频索引名称和视频索引名称对应的TS片段的内存地址。各个表项记录的内容各不相同。预设哈希表的表项记录的视频索引名称从m3u8文件中获取，预设哈希表中的视频索引名称和视频索引名称对应的TS片段根据m3u8文件确定。

由于基于Linux平台的HTTP服务器在直播节目源的直播过程中，不断更新相应直播节目源对应的TS片段和m3u8文件，因此预设哈希表中的表项也随更新的TS片段和m3u8文件而更新。

步骤S13：基于Linux平台的HTTP服务器从所述TS片段的内存地址对应的内存中获取TS片段。

基于Linux平台的HTTP服务器获取到的TS片段的码率与客户端发送的第一直播请求携带的视频码率相同。

步骤S14：基于Linux平台的HTTP服务器向发送所述第二直播请求的客户端发送所述TS片段。

需要说明的是，在直播节目源直播过程中，步骤S11至步骤S14是不断执行的，每当客户端向HTTP服务器发送第一直播请求，上述步骤S11至步骤S14执行一次。

在直播节目源直播过程中，客户端是实时的向HTTP服务器发送第一直播请求，在直播节目源直播过程中，客户端可以根据实际网络环境动态的切换视频码率，即客户端可以向HTTP服务器发送携带有不同视频码率的第一直播请求，继而请求到相应视频码率的视频。

在本申请中，将TS片段直接存储在内存中，不再占用磁盘空间，节约了磁盘空间。由于客户端在发送直播请求后，基于Linux平台的HTTP服务器通过从预设哈希表中获取对应的TS片段的内存地址，从所述TS片段的内存地址对应的内存中获取TS片段，可见，无需再从磁盘空间中读取TS片段，避免了磁盘的读写开销，提高了响应用户请求的效率，改善了用户体验性。

进一步的，虽然目前微软也对HLS协议提供了选择性的支持，但是只能运行在不开放的Windows系统和IIS Web服务器上，从扩展性和可移植性来说都受到了很多限制，而本申请通过基于Linux平台的HTTP服务器，实现了视频直播数据处理，由于Linux平台是开放的，因此相对于将HLS协议运行在不开放的Windows系统和IIS Web服务器上，开放性得到提高。且Linux平台具有安全性、扩展性和稳定性的优势。

在本实施例中，基于Linux平台的HTTP服务器的内存中存储的TS片段的生成由基于Linux平台的HTTP服务器中的Apache模块实现，具体生成过程请参见图2，图2示出了本申请提供的直播视频数据处理方法的一种子流程图，可以包括以下步骤：

步骤S21：所述HTTP服务器的Apache模块接收平滑流Smooth Streaming流。

在本实施例中，HTTP服务器的Apache模块接收到的Smooth Streaming流包括一个公用音频流和多个视频流。

Smooth Streaming流包括一路公用的音频流和多路分辨率、码率不同的视频流，多路分辨率、码率不同的视频流分别使用Smooth Streaming流中的公用音频流。

公用音频流包括音频类型的多个连续的ISMV片段。各个视频流各自对应不同的分辨率和码率即各个视频流的分辨率各不相同、码率各不相同，每个视频流包括视频类型的多个ISMV片段，同一个视频流包括的各个ISMV片段的分辨率相同且码率相同。

音频类型的每个ISMV片段是一组连续的音频采样数据，每个视频类型的ISMV片段是一个GOP(一组连续的视频画面，Group of Pictures)，每个GOP都是以IDR帧开始的，可以单独放在播放器上播放。

在本实施例中，Apache模块从服务器的编码器接收Smooth Streaming流，其中，Smooth Streaming流的生成过程为：服务器的编码器按照Smooth Streaming协议，对原始媒体数据进行多码率编码，得到Smooth Streaming流。

具体的，Smooth Streaming流由服务器的Windows Media Encoder SDK编码器按照Smooth Streaming协议，对原始媒体数据进行多码率编码而得到。

采用Windows Media Encoder SDK编码出来的Smooth Streaming流严格遵守不同码率视频时间戳对齐的原则，这样在播放器切换码率的时候，播放效果会非常流畅，不会出现花屏和卡顿的现象。且采用Windows Media Encoder SDK编码满足广播级的需要，可以减少编码器的使用数量，以缩减编码器成本。

需要说明的是，原始媒体数据由所述服务器的信号采集卡通过HDMI(高清晰度多媒体接口，High Definition Multimedia Interface)接口采集。

步骤S22：所述HTTP服务器的Apache模块从所述Smooth Streaming流中获取公用音频流和多个视频流，其中所述公用音频流包括音频类型的多个连续的ISMV片段，各个视频流各自对应的分辨率、码率不同，每个视频流包括视频类型的多个ISMV片段，同一个视频流包括的各个ISMV片段的分辨率相同且码率相同。

步骤S23：所述HTTP服务器的Apache模块将音频类型的每个ISMV片段分别和与所述音频类型的ISMV片段时间戳相对应的视频类型的各个ISMV片段重新打包为TS片段。

由于各个视频流共用一个公用音频流，因此各个视频流中均存在与音频类型的每个ISMV片段的时间戳相对应的视频类型的ISMV片段。

将音频类型的每个ISMV片段分别和与所述音频类型的ISMV片段时间戳相对应的视频类型的各个ISMV片段重新打包为TS片段即将音频类型的每个ISMV片段分别和与所述音频类型的ISMV片段时间戳相对应的视频类型的各个ISMV片段重新组合，组合后的ISMV片段转换为TS格式，得到TS片段，得到的TS片段的起始帧均是IDR帧。

由于TS片段是对一对时间戳相对应的音频类型的ISMV片段和视频类型的ISMV片段进行重新打包得到的，且得到的TS片段的起始帧为IDR帧，因此在直播过程中不会出现花屏现象。

在将音频类型的每个ISMV片段分别和与所述音频类型的ISMV片段时间戳相对应的视频类型的各个ISMV片段重新打包为TS片段后，码率相同的TS片段组成一个TS流。

实施例二

在本实施例中，提供了不同于图1示出的直播视频数据处理方法的另一种直播视频数据处理方法，请参见图3，图3示出了本申请提供的直播视频数据处理方法的另一种流程图，可以包括以下步骤：

步骤S31：服务器的信号采集卡通过HDMI接口采集原始媒体数据。

步骤S32：所述服务器的编码器按照Smooth Streaming协议，对原始媒体数据进行多码率编码，得到Smooth Streaming流。

在本实施例中，所述服务器的编码器按照Smooth Streaming协议，对原始媒体数据进行多码率编码，得到Smooth Streaming流具体可以为：所述服务器的Windows MediaEncoder SDK编码器按照Smooth Streaming协议，对原始媒体数据进行多码率编码，得到Smooth Streaming流。

步骤S33：所述服务器中基于Linux平台的HTTP服务器的Apache模块接收SmoothStreaming流，生成TS片段，并存储在所述HTTP服务器的内存中。

由于服务器的信号采集卡采集到的原始媒体数据是不断变化的，因此存储在HTTP服务器的内存中的TS片段也是随之变化的。

由于存储的TS片段不断变化，因此m3u8文件也相应的发生变化，Apache模块维护的哈希表也相应的发生变化。

生成TS片段的过程请参见实施例一中的图2示出的TS片段的生成过程，在此不再赘述。

步骤S34：HTTP服务器响应客户端发送的携带有视频码率和直播节目源的第一直播请求，向所述客户端发送与所述视频码率和所述直播节目源对应的m3u8文件。

步骤S35：HTTP服务器响应客户端发送的携带有从所述m3u8文件中获取到的视频索引名称的第二直播请求，从预设哈希表中获取与所述视频索引名称对应的TS片段的内存地址。

步骤S36：HTTP服务器从所述TS片段的内存地址对应的内存中获取TS片段。

步骤S37：HTTP服务器向发送所述第二直播请求的客户端发送所述TS片段。

步骤S34、步骤S35、步骤S36和步骤S37与图1示出的直播视频数据处理方法中的步骤S11、步骤S12、步骤S13和步骤S14相同，在此不再赘述。

对于前述的各方法实施例，为了简单描述，故将其都表述为一系列的动作组合，但是本领域技术人员应该知悉，本申请并不受所描述的动作顺序的限制，因为依据本申请，某些步骤可以采用其他顺序或者同时进行。其次，本领域技术人员也应该知悉，说明书中所描述的实施例均属于优选实施例，所涉及的动作和模块并不一定是本申请所必须的。

实施例三

在本实施例中，示出了本申请提供的一种直播视频数据处理装置，请参见图4，其示出了本申请提供的直播视频数据处理装置的一种结构示意图，直播视频数据处理装置包括：第一发送模块41、第一获取模块42、第二获取模块43和第二发送模块44。

第一发送模块41，用于响应客户端发送的携带有视频码率和直播节目源的第一直播请求，向所述客户端发送与所述视频码率和所述直播节目源对应的m3u8文件。

第一获取模块42，用于响应客户端发送的携带有从所述m3u8文件中获取到的视频索引名称的第二直播请求，从预设哈希表中获取与所述视频索引名称对应的TS片段的内存地址。

第二获取模块43，用于从所述TS片段的内存地址对应的内存中获取TS片段。

第二发送模块44，用于向发送所述第二直播请求的客户端发送所述TS片段。

在本实施例中，直播视频数据处理装置可以由HTTP服务器实现。

本实施例在图4示出的直播视频数据处理装置的基础上扩展出另外一种直播视频数据处理装置，请参见图5，其示出了本申请提供的直播视频数据处理装置的另一种结构示意图，在图4示出的直播视频数据处理装置的基础上还包括：Apache模块51。

其中，Apache模块51的具体结构请参见图6，图6示出了本申请提供的Apache模块的一种结构示意图，Apache模块包括：接收单元511、获取单元512和打包单元513。

接收单元511，用于接收Smooth Streaming流。

获取单元512，用于从所述Smooth Streaming流中获取公用音频流和多个视频流，其中所述公用音频流包括音频类型的多个连续的ISMV片段，各个视频流各自对应不同的分辨率和码率，每个视频流包括视频类型的多个ISMV片段，同一个视频流包括的各个ISMV片段的分辨率相同且码率相同。

打包单元513，用于将音频类型的每个ISMV片段分别和与所述音频类型的ISMV片段时间戳相对应的视频类型的各个ISMV片段重新打包为TS片段。

实施例四

在本实施例中，示出了本申请提供的服务器的一种结构示意图，请参见图7，图7示出了本申请提供的服务器的一种结构示意图，直播视频数据处理系统包括：直播视频数据处理装置71和编码装置72。

直播视频数据处理装置71的具体结构请参见实施例三示出的直播视频数据处理装置，在此不再赘述。

编码装置72，用于按照Smooth Streaming协议，对原始媒体数据进行多码率编码，得到Smooth Streaming流。

编码装置72具体可以由编码器实现。

编码装置72包括：Windows Media Encoder SDK编码装置。Windows MediaEncoder SDK编码装置具体可由Windows Media Encoder SDK编码器实现。

本实施例在图7示出的直播视频数据处理系统的基础上扩展出另外一种直播视频数据处理系统，请参见图8，其示出了本申请提供的直播视频数据处理系统的另一种结构示意图，在图7示出的直播视频数据处理系统的基础上还包括：信号采集装置81，用于通过HDMI接口采集所述原始媒体数据。

信号采集装置81具体可有信号采集卡实现。

在本实施例中，直播视频数据处理系统运行在服务器上。

需要说明的是，本说明书中的各个实施例均采用递进的方式描述，每个实施例重点说明的都是与其他实施例的不同之处，各个实施例之间相同相似的部分互相参见即可。对于装置类实施例而言，由于其与方法实施例基本相似，所以描述的比较简单，相关之处参见方法实施例的部分说明即可。

最后，还需要说明的是，在本文中，诸如第一和第二等之类的关系术语仅仅用来将一个实体或者操作与另一个实体或操作区分开来，而不一定要求或者暗示这些实体或操作之间存在任何这种实际的关系或者顺序。而且，术语“包括”、“包含”或者其任何其他变体意在涵盖非排他性的包含，从而使得包括一系列要素的过程、方法、物品或者设备不仅包括那些要素，而且还包括没有明确列出的其他要素，或者是还包括为这种过程、方法、物品或者设备所固有的要素。在没有更多限制的情况下，由语句“包括一个……”限定的要素，并不排除在包括所述要素的过程、方法、物品或者设备中还存在另外的相同要素。

为了描述的方便，描述以上装置时以功能分为各种单元分别描述。当然，在实施本申请时可以把各单元的功能在同一个或多个软件和/或硬件中实现。

通过以上的实施方式的描述可知，本领域的技术人员可以清楚地了解到本申请可借助软件加必需的通用硬件平台的方式来实现。基于这样的理解，本申请的技术方案本质上或者说对现有技术做出贡献的部分可以以软件产品的形式体现出来，该计算机软件产品可以存储在存储介质中，如ROM/RAM、磁碟、光盘等，包括若干指令用以使得一台计算机设备(可以是个人计算机，服务器，或者网络设备等)执行本申请各个实施例或者实施例的某些部分所述的方法。

以上对本申请所提供的一种直播视频数据处理方法、装置及系统进行了详细介绍，本文中应用了具体个例对本申请的原理及实施方式进行了阐述，以上实施例的说明只是用于帮助理解本申请的方法及其核心思想；同时，对于本领域的一般技术人员，依据本申请的思想，在具体实施方式及应用范围上均会有改变之处，综上所述，本说明书内容不应理解为对本申请的限制。

Claims (10)

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

服务器中基于Linux平台的超文本传输协议HTTP服务器响应客户端发送的携带有视频码率和直播节目源的第一直播请求，向所述客户端发送与所述视频码率和所述直播节目源对应的m3u8文件；以及，

响应客户端发送的携带有从所述m3u8文件中获取到的视频索引名称的第二直播请求，从预设哈希表中获取与所述视频索引名称对应的TS片段的内存地址，所述预设哈希表中的表项随更新的TS片段和m3u8文件而更新；以及，

从所述TS片段的内存地址对应的内存中获取TS片段；以及，

向发送所述第二直播请求的客户端发送所述TS片段。

2.根据权利要求1所述的方法，其特征在于，所述TS片段的生成过程包括：

所述HTTP服务器的Apache模块接收平滑流Smooth Streaming流；以及，

从所述Smooth Streaming流中获取公用音频流和多个视频流，其中所述公用音频流包括音频类型的多个连续的ISMV片段，各个视频流各自对应不同的分辨率和码率，每个视频流包括视频类型的多个ISMV片段，同一个视频流包括的各个ISMV片段的分辨率相同且码率相同；以及，

将音频类型的每个ISMV片段分别和与所述音频类型的ISMV片段时间戳相对应的视频类型的各个ISMV片段重新打包为TS片段。

3.根据权利要求2所述的方法，其特征在于，所述Smooth Streaming流的生成过程，包括：

所述服务器的编码器按照Smooth Streaming协议，对原始媒体数据进行多码率编码，得到Smooth Streaming流。

4.根据权利要求3所述的方法，其特征在于，所述原始媒体数据由所述服务器的信号采集卡通过高清晰度多媒体接口HDMI接口采集。

5.根据权利要求3所述的方法，其特征在于，所述服务器的编码器按照SmoothStreaming协议，对原始媒体数据进行多码率编码的过程包括：

所述服务器的Windows Media Encoder SDK编码器按照Smooth Streaming协议，对原始媒体数据进行多码率编码。

6.一种直播视频数据处理装置，其特征在于，包括：

第一发送模块，用于响应客户端发送的携带有视频码率和直播节目源的第一直播请求，向所述客户端发送与所述视频码率和所述直播节目源对应的m3u8文件；

第一获取模块，用于响应客户端发送的携带有从所述m3u8文件中获取到的视频索引名称的第二直播请求，从预设哈希表中获取与所述视频索引名称对应的TS片段的内存地址，所述预设哈希表中的表项随更新的TS片段和m3u8文件而更新；

第二获取模块，用于从所述TS片段的内存地址对应的内存中获取TS片段；

第二发送模块，用于向发送所述第二直播请求的客户端发送所述TS片段。

7.根据权利要求6所述的装置，其特征在于，还包括：Apache模块，其中所述Apache模块包括：

接收单元，用于接收Smooth Streaming流；

获取单元，用于从所述Smooth Streaming流中获取公用音频流和多个视频流，其中所述公用音频流包括音频类型的多个连续的ISMV片段，各个视频流各自对应不同的分辨率和码率，每个视频流包括视频类型的多个ISMV片段，同一个视频流包括的各个ISMV片段的分辨率相同且码率相同；

打包单元，用于将音频类型的每个ISMV片段分别和与所述音频类型的ISMV片段时间戳相对应的视频类型的各个ISMV片段重新打包为TS片段。

8.一种直播视频数据处理系统，其特征在于，包括编码装置和如权利要求6或7所述的直播视频数据处理装置，其中：

所述编码装置，用于按照Smooth Streaming协议，对原始媒体数据进行多码率编码，得到Smooth Streaming流。

9.根据权利要求8所述的直播视频数据处理系统，其特征在于，还包括：

信号采集装置，用于通过HDMI接口采集所述原始媒体数据。

10.根据权利要求8所述的直播视频数据处理系统，其特征在于，所述编码装置包括：Windows Media Encoder SDK编码装置。