[0001] 本发明涉及传媒领域，具体说涉及一种针对实时视频的分布式加密方法。

[0002] 在计算机数据处理应用中，视频加密是一种较常见的数据处理应用。由于视频数据的数据量较大，通常视频加密操作需要消耗大量的计算资源。

[0003] 随着分布式系统技术的不断发展，愈来愈多的技术领域利用分布式数据处理技术来降低单台处理系统的数据处理压力。分布式数据处理技术也被应用到视频加密领域。

[0004] 在现有技术中，通常使用原生并行计算框架(映射-归约MapReduce)对视频进行分布式加密。利用MapReduce进行视频加密，在MapReduce任务内部，为了防止归约(Reduce)任务的失败，映射(Map)通常会把结果存储在磁盘上。通常一些查询在翻译到MapReduce任务的时候，往往会产生多个阶段(stage)，而这些串联的stage则又依赖于底层文件系统(如分布式文件系统HDFS)来存储每一个stage的输出结果。冗余的磁盘读写开销和多次资源申请过程，使得基于MapReduce的算法实现存在严重的性能问题。同时，Reduce任务需要等待所有Map任务都完成后才可以开始，也造成了较大程度的时间开销。

[0005] 由于性能和处理速度上的制约，基于磁盘读写机制的MapReduce框架先天上不具备实时性较强的处理能力。进一步的，MapReduce框架主要用于大规模的批处理运算，对于实时性要求较强的流式处理，没有提供针对流式处理的数据接收接口。上述问题最终导致利用MapReduce框架不能很好的处理实时任务，严重限制了分布式加密方法的应用范围。

[0006] 因此，为了进一步提高分布式加密系统的性能，提高系统对实时任务的处理能力，需要一种针对实时视频的分布式加密方法。

[0037] 以下将结合附图及实施例来详细说明本发明的实施方式，借此本发明的实施人员可以充分理解本发明如何应用技术手段来解决技术问题，并达成技术效果的实现过程并依据上述实现过程具体实施本发明。需要说明的是，只要不构成冲突，本发明中的各个实施例以及各实施例中的各个特征可以相互结合，所形成的技术方案均在本发明的保护范围之内。

[0038] 在视频业务形态中，最常见的主要有两种：直播(实时视频)和点播(离线视频)，两种业务形态视频的存在方式不同造成了对视频加密的需求也不相同。直播业务对视频加密的实时性是首要考虑的，而在点播类业务中较高效率的处理大数据的能力是其核心要考虑的问题。

[0039] 在现有技术中，由于性能和处理速度上的制约，基于磁盘读写机制的MapReduce框架先天上不具备实时性较强的处理能力。进一步的，MapReduce框架主要用于大规模的批处理运算，对于实时性要求较强的流式处理，没有提供针对流式处理的数据接收接口。上述问题最终导致利用MapReduce框架不能很好的处理实时任务，严重限制了分布式加密方法的应用范围。

[0040] 为了进一步提高分布式加密系统的性能，提高系统对实时任务的处理能力，本发明提出了一种针对实时视频的分布式加密方法。根据本发明的方法，针对实时视频源进行了系统优化，使得系统具备了对实时流媒体的加密功能。

[0041] 接下来基于附图描述根据本发明具体实施例的方法的执行过程，附图的流程图中示出的步骤可以在包含诸如一组计算机可执行指令的计算机系统中执行。虽然在流程图中示出了各步骤的逻辑顺序，但是在某些情况下，可以以不同于此处的顺序执行所示出或描述的步骤。

[0042] 如图1所示，本发明的方法的主要步骤包括：

[0043] 接收实时视频流数据(S100)

[0044] 将视频流数据分割以生成视频分片数据(S110)；

[0045] 根据视频分片数据构建弹性分布式数据集(S120)，弹性分布式数据集中的每个元素为一个视频分片数据；

[0046] 将弹性分布式数据集中的各个元素分发给各个节点工作站(S130)；

[0047] 节点工作站对视频分片数据进行加密处理并输出加密结果(S140)。

[0048] 当用户需要播放视频时，可以按照视频分片在完整视频中的时间先后顺序一边解密一边播放；也可以将所有的视频分片数据解密后统合成完整的视频数据再播放。

[0049] 进一步的，为了便于用户播放视频，在根据本发明一实施例中，在步骤S140之后，对加密后的视频分片数据进行统一整理。将加密后的视频分片数据保存到存储服务器以便之后视频下载到客户端播放或者将加密后的视频单元传输给分发网络进行内容的分发。在本发明一实施例中，采用分布式文件系统保存加密后的视频分片数据。

[0050] 另外，在根据本发明另一实施例中，也可以不保存加密后的视频分片数据。而是在视频分片数据被加密后直接发送到客户端播放或者传输给分发网络进行内容的分发。

[0051] 由于实时业务的要求，以效率作为优先，最优的解决办法之一是减少在整个加密集群中的存储和读取的环节。为了减少存储和读取的环节，在本发明一实施例中，主要基于通用并行框架(Spark)构造任务分发系统，利用Spark基于内存的协同算法，最优化各个代理节点的协同工作效率。本说明书中的其他具体实施例也是基于Spark框架构造。在这里需要指出的是，本发明的具体实现方式并不限于Spark框架。本领域的技术人员可以采用其他框架构造任务分发系统。

[0052] 在本发明一实施例中，基于Spark的分布式加密系统结构如图2所示。系统主要包括以下四个部分：视频分片模块210、分片分发模块220、加密模块以及视频分片整理模块240。在这里，为便于描绘，仅描绘分别构造在工作节点201、202、203、204上的加密模块231、
232、233、234这4个加密模块。在实际运行中，加密模块的数量并不限于4个。

[0053] 视频分片模块210任务是将来自实时视频源200的整个的视频文件切割成较小的视频单元，便于后续的任务处理和传输；分片分发模块220任务是将任务单元分发到各个工作节点上的加密模块执行；加密模块部署在工作节点上，任务是对分发到节点的视频单元进行加密，输出加密后的视频分片；视频分片整理模块240的任务是接收并整理加密后的视频分片数据。

[0054] 在一实施例中，视频分片整理模块240将整理后的视频分片数据保存到存储服务器(分布式文件系统)。在另一实施例中，视频分片整理模块240直接将视频分片输出给用户或分发网络进行内容的分发。

[0055] 根据本发明的方法，在最初分割视频生成视频分片数据后就确定了需要分发的加密任务数目(一个视频分片数据对应一个加密任务)。使得任务的分发以及节点工作站的调配更加简单，大大提高了加密操作的执行效率。由于避免了不必要的磁盘读写开销和多次资源申请过程，降低了整个加密操作的计算需求，缩短了加密操作的执行时间。

[0056] 进一步的，分布式文件系统HDFS的数据块默认是64M，若一个文件大于64M，通过将大文件分解得到若干个数据块；若一个文件小于64M，则按它的实际大小组块存储。海量的小文件需要主节点存储较多的元数据信息记录块的位置。如果访问大量小文件，需要不断的从一个子节点跳到另一个子节点，严重影响性能。

[0057] 在现有技术中，当视频文件分片尺寸在64MB时，MapReduce分布式视频加密的性能达到最优，当视频分片尺寸过大或过小时，加密性能大大降低。如果分片太大以至于一个分片要跨越多个HDFS块，则一个Map任务必须要由多个块通过网络传输，读写开销和网络传输开销大大增加。因此，在现有技术中，为了保证处理性能，视频分片大小的上限是HDFS块的大小。

[0058] 根据本发明的方法，对视频分片尺寸不敏感，能够适应不同分片尺寸的加密需求。因此相较于现有技术，本发明的加密方法的应用灵活度大大增强。

[0059] 进一步的，在实时业务的内容保护框架中，实时性是作为内容加密的首要考量，吞吐量的需求并不作为加密的首要考量因素。因此，在本发明一实施例中，在将视频分割成视频分片数据的过程中，直接接收实时流媒体，在接收的同时对实时流媒体进行以时间为基准的切分，每一个时间分片对应一个视频分片数据。然后根据视频分片数据构建弹性分布式数据集，其中，按照预设的时间间隔生成弹性分布式数据集，弹性分布式数据集对应时间间隔内接收到的所有视频分片数据。

[0060] 为了实现实时视频数据的接收以及以时间为基准的视频分片，在本发明一实施例中，采用了实时计算(Streaming)框架。基于Streaming的加密框架如图3所示。基于实时视频的内容保护系统主要由四部分构成，流媒体接收分片模块330(Streaming框架)、分布式计算框架310(Master)、选择性加密模块(节点工作站321、322、323以及324，Worker)以及存储服务器350。

[0061] 进一步的，在本发明一实施例中，利用Streaming框架配合Spark框架完成加密批处理。在接收实时流的时候，采用Streaming提供的接口监听端口处传来的数据，避免了与HDFS交互的I/O环节产生较多的时间消耗。具体的，选择Spark的针对流式处理的Spark streaming框架作为构建实时流分布式数据集的框架。Spark Streaming是一种构建在Spark上的实时计算框架，它扩展了Spark处理大规模流式数据的能力。相较现有技术的框架结构，Spark streaming框架具备更好的流处理能力。

[0062] 在本发明一实施例中，Spark streaming框架下，实时业务的分布式加密流程如下：

[0063] (1)实例化StreamingContext并且指定好分片的切分时间。

[0064] (2)创建ImageReceiver类，继承自Receiver类，重新定义了Receiver方法，可以按照指定端口获取数据构建DStream。

[0065] (3)利用Spark  streaming对实时流媒体进行以时间为基准的切分，SparkStreaming将DStream操作构建DStream Graph，然后每一个时间分片都会依照DStream Graph形成RDD Graph。JobGenerator内部有个定时器，定期生成Job，通过DStream的id，把ReceiverTracker接收到的Block信息从BlockManager上抓取下来进行处理，这个间隔时间是实例化StreamingContext的时候传进去的时间。

[0066] (4)如同离线的分布式架构一样，DStream也需要转换为键值对的形式，需要调用DStream的map方法完成键值对的转换。

[0067] (5)转换完成后，每一个视频分片作为一个任务实时的交由Spark核心进行批处理。

[0068] (6)Spark中的Master通过基于共享内存的代理节点协同算法，将分布式数据集中的各个元素根据节点性能和使用情况分发给各个节点Worker进行数据处理，视频分片的加密处理在Worker中完成。视频分片的加密处理同样由在Worker中的Executor上完成。

[0069] (7)加密完成后，各Worker将加密后的元素返回到Master中，并保存在HDFS中。

[0070] (8)HDFS中保存的加密分片通过流化模块把分片文件整合成流媒体文件输出。

[0071] Streaming支持Socket套接字进行数据传输，TCP连接和UDP连接分别应对两种处理情况。若服务器策发送到Streaming接收端的是视频分片的形式，则采用TCP的方式先建立链接然后接收数据的方式。实时流本身传输的过程中采用UDP的面向无连接的方式来保证业务的实时性。若服务器发送的是UDP的视频流，则采用的是UDP的连接方式，直接获取数据进行处理。两种连接方式各有自己的应用场景，TCP连接保证了数据传输和网络链接的安全性，但是实时性很难保证，适用于与连续小文件的传输。UDP在实时性方面能够取得良好的表现，但是视频传输难免出现丢包和误码，数据传输的安全性和准确率方面不如TCP连接方式。

[0072] 在UDP连接方式的Streaming处理中，自定义了ImageReceiver类用来接收UDP连接方式传输来的数据。ImageReceiver继承自Streaming的Receiver类，Receiver类任务是将接收自网络的数据转化为可供Spark处理的RDD。Receiver类中提供了初始化端口、地址、接收方式、存储方式和资源释放的支持，通过onStart和onStop方法完成数据的接收和停止，但是onStart和onStop方法需要在子类ImageReceiver中按需完成定义。在onStart方法中，定义receive方法用来实现对UDP连接的数据接收。receive方法中流程是：通过DatagramSocket类创建UDP的Socket实例，DatagramPacket类接收报文，并通过getData方法将报文拆解为字节数组，最后通过Receiver类的store方法保存在Spark的内存中构建能够交由Spark核心框架处理的RDD。

[0073] 与UDP的方式不同，TCP的连接的接收对象并不是流媒体数据，TCP的数据接收更加倾向于对实时性要求较高的小文件数据集。使用Streaming框架接收TCP连接数据时，同样需要定义继承自Receiver类的接收类，通过定义onStart方法中的receive方法来实现TCP的数据接收。在receive方法中，需要按照TCPSocket的数据传递方法完成数据传递。

[0074] 在Socket开发中，Streaming侧作为客户端接收数据，基本流程是：

[0075] (1)初始化Socket实例

[0076] (2)向服务器端发送连接请求

[0077] (3)连接确认后传递数据

[0078] (4)关闭Socket。

[0079] 为了完整的仿真数据接收，编写了服务器侧的Socket。为保证业务的实时性要求，服务器端部署的是连续的数据集文件。在本系统中以连续时间分片的方式存在，因此需要在一个视频分片发送完成后继续下一个视频的发送，方法是通过编写Java提供的网络地址实现类InetSocketAddress，实现不改变网络地址和端口的情况下连续发送视频分片。连接建立后，数据传输通过Socket实例的getInputStream方法完成，分片数据传输完成后关闭实例，启动下一个连接。

[0080] 进一步的，在本发明一实施例中，考虑到视频分片数据在加密、传输和整合过程中可能会遇到的问题，定义了的视频分片数据的格式。整体来看，视频分片数据的格式为“包头+内容”的模式。包头为视频分片的标识符，描述了该视频分片的基本信息，如所属的流媒体内容、包序号、时间戳、加密方式等。视频分片内容为加密后的流媒体内容，终端根据包头的信息和DRM授权，将获得的视频分片内容解密、解封装，将流媒体内容在在用户终端上呈现。

[0081] 分片格式如表1所示

[0082]

[0083] 表1

[0084] 由于详细定义了视频分片中包头的格式，也为整个系统中内容的分发和整合做好了准备。包头结构中的各字段描述如表2所示：

[0085]

[0086] 表2

[0087] Spark框架在进行分布式计算的时候，视频分片数据的加密任务分发到各个节点上，必不可少的会遇到任务和加密模块(节点工作站)之间的通信和调度问题。

[0088] 在Linux的进程间通信通常采用管道的方式。管道本身分为匿名管道和命名管道FIFO(first in first out),两者不同之处在于匿名管道只允许两个具有亲缘关系的进程之间进行通信，而每个FIFO有一个路径名与之关联，从而允许无亲缘关系的进程访问同一个FIFO。在本发明一实施例中，利用命名管道进行与节点工作站的数据传输。

[0089] 为了避免管道两侧数据传递不同步的情况，在本发明一实施例中，在进行数据传输的过程中采用数据长度校验。即在数据的写入和读出时设计了一个数据长度校验的机制。

[0090] 如图4所示，在数据发送侧写入内容到管道之前，首先将要写入内容的内容长度先写入管道(S401)，然后写入要写入的内容(S402)。数据接收侧读取内容时先读取出管道中内容的长度(S411)，然后依照内容的长度读取内容(S412)，从而保证了管道内数据传递的完整性，不会造成管道阻塞和数据覆盖的问题。

[0091] 加密模块读取被加密数据后进行相关的选择性加密，加密后的数据通过输出管道写入数据传递给任务侧(Java程序)。输出管道的数据交换方法与输入管道的方法相同，首先将数据内容长度写入管道，然后写入数据内容。程序侧读取时也先将长度数据读取，然后读取内容，从而保证数据完整性。

[0092] 由于FIFO的文件属性，因此在对FIFO管道以文件方式进行读写之前，FIFO管道必须已经存在，进程只能对FIFO管道进行打开、关闭、读写等操作。因此，在数据传输之前，利用键值对中的K值作为标识创建管道，对每个K值创建一对管道分别为输入管道inputPipe和输出管道outputPipe。输入管道用来传递程序侧到加密测的数据，输出管道用来传递加密后的数据到程序侧。

[0093] 程序侧与加密侧的管道写入策略是这样的，在写入内容到输入管道之前，首先将要写入内容的内容长度先写入管道，然后写入要写入的内容。读取内容时先读取出管道中内容的长度，然后依照内容的长度读取内容，从而保证了管道内数据传递的完整性，不会造成管道阻塞和数据覆盖的问题。加密模块读取被加密数据后进行相关的选择性加密，加密后的数据通过输出管道写入数据传递给任务侧(Java程序)。输出管道的数据交换方法与输入管道的方法相同，首先将数据内容长度写入管道，然后写入数据内容。程序侧读取时也先将长度数据读取，然后读取内容，从而保证数据完整性。

[0094] 进一步的，在本发明一实施例中，针对分布式系统特点，在视频加密算法、密钥的层次和密钥的随机性等方面进行了相关性的设计。

[0095] 视频分片的加密算法选择，采用了高级密钥加密算法AES，密钥长度为128bit，加密轮数设定为10轮。一方面在视频的安全性方面有了良好的保障，另一方面视频的加密效率也得到了较好的权衡。由于AES加密算法在发布以来的成熟应用以及其良好的跨平台性，最重要的是AES加密密钥不存在DES加密算法中出现的弱密钥和半弱密钥的情况。

[0096] 进一步的，在加密密钥生成的过程中，在视频加密的过程中引入了业务密钥SK，即在本发明一实施例中存在两种密钥，业务密钥SK以及加密密钥CW，其中：

[0097] 加密密钥CW用于加密视频分片数据的内容；

[0098] 业务密钥SK用来对加密密钥CW的加密控制字进行加密，保护加密密钥CW的安全性和安全传输。

[0099] 在加密过程中，首先利用加密密钥对内容进行加密，然后利用业务密钥对加密密钥CW的加密控制字进行加密并存入包头中；

[0100] 在解密过程中，首先利用与业务密钥对应的解密密钥解密加密密钥CW的加密控制字，然后利用加密密钥CW的加密控制字解密内容。

[0101] 进一步的，视频分片数据与加密密钥一一对应，不同的视频分片数据采用不同的加密密钥，每个加密密钥都是由生成规则随机产生的。这样就增加了视频的破解难度，即使单一加密密钥也漏也能保证视频数据整体的安全。

[0102] 同时，从属于同一视频的不同视频分片数据对应同一业务密钥。这样，客户终端只需要一把业务密钥就可以完成解密操作，降低了解密过程中密钥分发操作的复杂程度。

[0103] 在本发明一实施例中，整个密钥管理及分发的流程如图5所示：需要对视频分片数据加密时，密钥管理系统500将业务密钥和加密密钥分发给节点工作站(501、502、503)，每个节点工作站均收到业务密钥和加密密钥。加密密钥与节点工作站对应，业务密钥与视频分片所属的视频对应。不同的节点工作站接收到的加密密钥不同，针对同一视频的节点工作站接收到的业务密钥相同。

[0104] 当客户端410需要对视频分片数据进行解密时，密钥管理系统500只需要将该视频对应的业务密钥的解密密钥发送给客户端510即可。

[0105] 综上，根据本发明的方法，利用基于内存的分布式处理框架SparkStreaming作为实时流分布数据集的框架，解决了MapReduce框架中遇到的加密效率不高、数据块尺寸影响加密时间、不支持流式处理等问题。同时本发明还解决了分布式环境下密钥的传递和分发问题。

[0106] 虽然本发明所公开的实施方式如上，但所述的内容只是为了便于理解本发明而采用的实施方式，并非用以限定本发明。本发明所述的方法还可有其他多种实施例。在不背离本发明实质的情况下，熟悉本领域的技术人员当可根据本发明作出各种相应的改变或变形，但这些相应的改变或变形都应属于本发明的权利要求的保护范围。