基于音视频格式的流媒体加密方法和模块与流程

文档序号:11960184阅读:389来源:国知局
基于音视频格式的流媒体加密方法和模块与流程

本申请涉及流媒体加密技术领域,特别是涉及基于音视频格式的流媒体加密方法和模块。



背景技术:

随着互联网技术的发展和网络带宽的持续增加,用户通过互联网观看视频已经成为一种具有取代传统观看电视的趋势的日常习惯。越来越多的用户选择从互联网的内容提供商处观看各种视频文件。尽管,内容提供商所提供了很多内容都是免费的,但为了内容提供商的自身经济利益的需求,还是有大量视频需要在向用户收取一定费用后才能被顺利观看。这种收费机制就涉及到对视频内容的版权保护。而在中国的互联网领域一直都缺乏完善的视频内容版权保护机制,因此,很容易对收费视频内容进行非法复制传播。

为了解决所述非法复制转播,特别是针对流媒体内容,现有的互联网也提供了一些利用加密/解密技术的版权保护机制,诸如MPEG、H26x、WMV都提供了相应的视频加密机制。但是,当前流媒体加密方案都比较复杂,对计算处理能力要求比较高。但随着通信技术的不断发展,越来越多的用户开始采用移动端设备,例如移动电话、智能手机、个人数字助理、平板等等来访问互联网上的视频内容。与个人计算机(例如台式机或笔记本)相比,这些移动设备处理能力对视频文件的计算处理能力有限,故而对流媒体加密和解密的复杂度不能太高。这也使得这些流媒体很容易被破解后免费传播,导致内容提供商利益受损。

而且,现有的加密/解密方案在对音视频文件进行加密后,破坏了音视频文件本身的结构,这就要求后续的网络传输环节能够兼容这种破坏后的结构。尤其是对内容分发网络(CDN)来说,由于经加密后的音视频文件结构遭到破坏,也就需要CDN能够重新解析这种格式以标识出其真实内容,这给CDN带来了许多不便,使得CDN的内容存储和分发的效率大大降低。同时也给整个加密/解密方案的推广带来了阻碍。

因此,需要提供一种新颖的加密/解密方案来解决现有技术中的上述诸多问题。



技术实现要素:

本申请的目的在于解决在流媒体内容的版权保护过程中使用的现有加密/解密方案中的各种不便利。

本申请是一种基于音视频格式的流媒体加密方法和系统。

在本申请的第一方面,提供了一种基于音视频格式的加密流媒体的方法,包括:接收需要加密的音视频文件和由用户所提供的用于加密的密钥;根据设定的加密级别,使用与所述加密级别相关联的加密算法来基于用户提供的所述密钥对所述音视频文件进行加密;输出经加密的音视频文件。

在本申请的第二方面,提供了一种观看根据权利要求1所述的方法所加密的流媒体的方法,包括:发起要播放加密的音视频文件的请求,所述请求包括存储了经加密的音视频文件的URL和用户提供的密钥;将所述请求发送给具有解密模块的播放器,并由所述播放器解析所述请求以获得所述URL和密钥;所述播放器基于所述URL向云服务计算机发起对经加密的音视频文件的下载请求;所述播放器一边从所述云服务计算机下载所述经加密的音视频文件的数据一边基于所述密钥对所下载的经加密的音视频文件的数据进行解密并同时将经解密的音视频文件的数据返回给用户以供播放。

在本申请的第三方面,提供了一种基于音视频格式的加密流媒体的加密模块,其特征在于,包括:输入端口,所述输入端口用于接收需要加密的音视频文件和由用户所提供的用于加密的密钥;加密级别端口,所述加密级别端口用于帮助用户设定加密级别,以便使用与所述加密级别相关联的加密算法来基于用户提供的所述密钥对所述音视频文件进行加密;输出端口,所述输出端口用于输出经加密的音视频文件。

附图说明

图1是根据本发明的实施例的系统运行环境的示意图。

图2是根据本发明的实施例的加密模块的工作示意图。

图3是根据本发明的实施例的用于加密音视频文件的方法的流程图。

图4是根据本发明的实施例的基于用户发起的观看加密的音视频文件的请求来为用户提供所请求的音视频文件的流程图。

具体实施方式

本申请主要解决视频的版权保护问题,具体而言,只有获得解密算法及密钥的用户才能解密观看经加密的视频。

当前流媒体加密方案都比较复杂,对设备的计算处理能力要求比较高,从而占用了较高的CPU负载。特别是在移动端播放时,由于设备资源有限,所述解密会导致视频播放有延时、卡顿或声音画面不同步等问题,这严重影响了用户观看体验。即使是在PC端,当PC执行消耗较多资源的多任务的操作时,所述复杂的解密方案也会影响用户的观看体验。另外,现有的加密方案对音视频文件进行加密后,破坏了音视频文件本身的结构,这就会给网络传输环节带来兼容性问题。特别是,当所述音视频文件是流媒体内容时,所述文件结构的破坏可能使得原本的流数据传输的先后顺序发生混乱,导致无法通过网络正常观看所述流媒体内容。

针对当前流媒体加密方案存在的两个主要问题,本申请提出了一种基于音视频格式的流媒体加密方法和系统。该方法和系统相对于现有方案提供了以下改进:

(1)在保障相同的音视频文件安全级别的前提下,最小化加密的复杂度。

(2)在不影响用户观看音视频文件的体验的前提下,最小化解密的复杂度。

(3)加密前后的文件大小保持一致,从而不增加上传、下载的流量。

(4)加密后不改变原有的音视频文件结构,减小网络传输环节带来的兼容性问题。

首先,如图1所示,公开了根据本发明的实施例的系统运行环境100的示意图。在所述系统运行环境100中,包括了通过网络130相连的云服务计算机110和客户源站120。所述云服务计算机110通过网络以按需、易扩展的方式为用户提供所需服务。例如,在本实施例中,云服务计算机110可以提供云存储服务和云加密服务。云存储服务可以接收来自客户源站120的需要加密的音视频文件,并将其保存在云服务计算机110中的云存储模块中,同时,将存储在云存储模块中的音视频文件的URL返回给客户源站120。云加密服务可以根据云服务计算机110接收到的来自客户源站120的加密音视频文件的请求来对云存储服务所存储的相应音视频文件进行加密后再存储到云存储模块,并将对应于存储在云存储模块中的经加密的音视频文件的URL返回给客户源站120。由于利用了“云”技术,在实施例中,音视频文件的存储和加密都可以由云服务计算机110来完成,因此,大大减少了客户源站的计算处理能力要求,使得,用户即使是使用具有有限处理能力的移动设备,例如智能电话,也能够实现良好的观看体验。

接着,在图2中,公开了根据本发明的实施例的加密模块200的工作示意图。加密模块200可以采用CPU、微处理器、协处理器等具有运算功能的单元来实现。具体而言,所述加密模块包括:输入端口,所述输入端口用于接收需要加密的音视频文件和由用户所提供的用于加密的密钥;加密级别端口,所述加密级别端口用于帮助用户设定加密级别,以便使用与所述加密级别相关联的加密算法来基于用户提供的所述密钥对所述音视频文件进行加密;以及输出端口,所述输出端口用于输出经加密的音视频文件。与现有技术中的仅仅提供了一种加密机制的加密方案所不同的是,本发明的加密模块根据用户不同的使用场景,提供了多种加密级别。

举例来说,在一个实施例中,如果仅仅是出于收费的目的而需要对音视频文件进行加密,则可以提供级别为0的加密级别。在该加密级别中,加密模块只对音视频文件中的某些关键信息进行加密,而不会破坏音视频帧数据的完整性。这样,在解密时,所花费的代价最小,所消耗的诸如CPU之类的处理资源几乎可以忽略不计。在具体实践中,此加密级别可被用来限制经加密的音视频文件被通用播放器播放。换句话说只有具有对应的解密功能的专用播放器才能播放此类级别的被加密的音视频文件。但所述专用播放器仅需要花费少许资源对音视频文件中的关键信息进行解密之后就能顺利播放整个音视频文件而无需从头到尾对整个文件进行解密。由于这种加密级别0具有消耗极少量资源的特点,因此,它非常适合被融入到针对具有有限处理资源的移动设备的视频应用中。许多为移动设备专门开发的媒体播放器可以采用这种加密级别以在保证音视频文件的足够的安全级别的前提下,通过减少加密/解密对移动设备的资源消耗来为用户提供良好的视频体验。另外,这种加密级别不会改变原有的音视频文件的结构,因而减小了网络传输环节带来的兼容性问题。

其次,在另一个实施例中,当音视频文件含有不能给其他人知道的重要内容的情况时,还可以提供级别为1的加密级别。在该级别下,增加了对音视频帧中的指定数据的加密,以达到破坏音视频帧数据文件的完整性的目的。由于在对文件进行加密的同时已破坏了该文件的完整性,因此,如果用户不具有对应的密钥,就无法从经加密的数据中完整还原出原始的音视频文件。而且,由于音视频文件的完整性破坏,因此,即使该用户仅仅想要得到音视频文件中的某段视频也是不可能的,这大大提高了音视频文件的安全级别,很好地保护了音视频文件中所含有的重要内容。但是,与级别0的加密方案相比,级别1的加密方案需要相对比较复杂,需要消耗更多的处理资源,因此,它比较适合由具有足够处理资源的云服务计算机来实现或者由网络上同样可以连接到云服务计算机的服务器来实现。

下面就可以实现所述级别0和级别1的加密算法进行具体说明。在所述说明中,以最常见的mp4视频文件作为示例来加以讨论。本领域的技术人员可以理解所述mp4视频文件仅仅是出于说明的目的而非要将本发明局限于此。实际上,任何其他视频和音频格式文件都适用于本发明的方案,例如RMVB、AVI、WMV、MKV、MPG等等视频格式和MP3、WAV、WMA、APE等等音频格式。

1.加密算法(当前举例mp4视频文件的加密),包括:

1.1修改Major brand的值为加密算法指定的值,该值指示了所述视频文件是不是加密的文件;

1.2修改Minor version的值以表示该视频文件的加密级别,例如,0表示级别0,1表示级别1,以此类推;

1.3修改Avc1 box、accC box、mp4a box、mp4v box的名称为加密算法指定的名称,由于普通播放器要解析此字段进行初始化,故破坏此字段的名称就可以导致所述普通播放器无法找到所述字段因而也就无法解析出这些字段的内容,以达到初步加密的效果;

1.4对1.3指定的各box的内容和客户提供的密钥进行自定义加密运算(比如位运算等),将所得到的加密内容替换原先的内容,其中在此加密中前后的字节数保持不变,故可以实现不改变视频文件的结构和大小的目的;

从1.1到1.4步骤属于加密级别0的加密算法,换句话说,如果用户选择对所述视频文件执行加密级别为0的加密,则所述加密过程到此结束。

而当用户选择了加密级别1的加密的话,除了包含上述这些加密步骤之外,所述加密算法还包括:

1.5对于视频关键帧的指定字节数的数据,执行下述操作:

使用客户提供的密钥对其进行AES(Advanced Encryption Standard)加密,AES加密是块加密,所以指定的字节数必须是16的整数倍。由于视频的非关键帧必须依赖于关键帧才能解码,故只需加密关键帧;以关键帧大小为10000多个字节的音视频文件为例,其视频所指定的字节数为128字节,而音频的指定字节数为64字节。在其他实施例中,例如对音视频文件中的音频帧指定字节数的数据进行AES加密的情况下,由于音频帧的解码不需要依赖相邻的音频帧,所以需对每帧音频帧都进行AES加密;由于AES加密不改变字节数大小,故也可以保证不改变视频文件的结构和大小;需要指出的是,虽然以AES加密技术进行说明,但所述示例仅仅是出于说明的目的,其他合适的加密技术也可以被应用于上述加密处理中。

1.6对于视频中的每个关键帧,依次循环执行对视频关键帧(在音频帧的情况下,则是对每个音频帧)的AES加密直到文件尾,到此级别1的加密过程完成。

需要指出的是,上述加密算法仅仅是出于说明的目的来进行描述,而非要对本发明的加密算法进行任何限制。其他合适的加密算法也可应用于本发明中。

应该理解,上述的级别0和级别1的加密级别仅仅是示例性的说明,而非要将本申请的方案局限于这两个级别。实际上,在其他实施例中,根据场景的安全性要求的不同,还可以提供更多的加密级别以实现不同的保密目的。例如,在某个加密级别中,当用户的密钥不对时,可以主动销毁音视频文件,甚至在某些加密级别中,当密钥不正确时,可以主动向对应的内容提供者或警方发出警报(例如通过通知、消息、链接等方式)以提醒有对音视频文件的非法访问等等。本领域技术人员可以根据具体的需求对其他级别的加密处理进行编程以实现例如上述附加的安全性要求。出于节省篇幅的目的,不再在此一一详述。

在上面的内容中介绍了本申请的加密模块所采用的多级别加密技术,所述多级别加密技术可以很好适用于各种设备资源和用户需求,从而提供了更加灵活的加密解决方案。

在了解了本申请的加密方案之后,现在参考图3来描述根据本发明的实施例的用于加密音视频文件的方法300的流程图。首先,在310,加密模块从客户源站的用户接收需要加密的音视频文件和该用户所提供的用于加密的相应的密钥。在步骤320,通过一个接口来向加密模块传递加密级别,例如通过向用户呈现一个用户界面以供用户选择需要的加密级别。需要注意的是,该步骤是可选的而不是必须的,因为加密模块可以具有默认的加密级别,而无需用户特别指定。只有当用户特定指定其他加密级别时,加密模块才会采用所指定加密级别来加密音视频文件。随后,在步骤330,加密模块根据用户选择的加密级别,使用与该加密级别相关联的加密算法来基于用户输入的密钥对音视频文件进行加密。根据与所选择的加密级别相关联的加密算法的复杂性和对处理资源的需求,所述加密可以由移动设备处的加密模块来执行,也可以由云服务计算机中的加密服务器来执行。接着,在步骤340,在完成对音视频文件的加密之后,加密模块将经加密的音视频文件输出以,例如,存储到云服务计算机的存储模块中。可选地,当在步骤340输出并存储完经加密的音视频文件之后,在步骤350,加密模块可以将指示完成加密和保存音视频文件的响应返回给用户以告知该用户所请求的加密任务已经完成。客户源站在收到加密成功的响应后,更新客户源站的文件列表以记录该加密任务的完成。

在另一个实施例中,除了从客户源站的用户接收需要加密的音视频文件以外,所述加密模块也可以从客户源站的用户接收一个与需要加密的音视频文件相关联的URL,并从该URL所指定的网络位置处下载需要加密的音视频文件,或者,客户源站的用户可以提前将需要加密的音视频文件存储到云服务计算机处的存储模块中,以便在云服务计算机处的加密模块的调用。

在又一个实施例中,当在云服务计算机处的加密模块执行所述加密任务并存储了经加密的音视频文件时,除了在步骤350处向客户源站返回成功响应之外,还可以将经加密的音视频文件的URL一同返回给客户源站。

接着,参考图4来描述根据本发明的实施例的基于用户发起的观看加密的音视频文件的请求来为用户提供所请求的音视频文件的流程图。首先,在步骤410,客户源站的用户在一应用(例如浏览器、文件管理器)中点击所述客户源站上的音视频文件的图标以发起视频播放请求。在步骤420,客户源站将所述视频播放请求发送到具有解密模块的播放器,所述请求包含了经加密的音视频文件的URL和用户提供的密钥。在步骤430,在接收到所述视频播放请求之后,播放器解析所述请求以获得其中的经加密的音视频文件的URL和密钥。在步骤440,播放器基于所述经加密的音视频文件的URL向云服务计算机发起对经加密的音视频文件的GET下载请求。在步骤450,云服务计算机根据接收到的GET下载请求,返回与所述URL相关联的经加密的音视频文件给播放器。在步骤460,播放器开始一边从云服务计算机下载音视频文件数据一边基于所述密钥对所下载的音视频文件数据进行解密并同时将经解密的音视频文件数据返回给用户以供播放。持续整个过程,直至整个音视频文件播放完成。在上述方案中,所述播放器被安装在客户源端。而在另一个实施例中,云服务计算机也可以具有所述解密模块。因为,当经加密的音视频文件是基于级别0被加密时,所述解密过程并不会消耗过多的客户源端的资源,也就不会对用户的观看体验造成任何影响,因此,客户源端的播放器有能力边解码边提供流畅的观看体验。但当所述经加密的音视频文件是基于级别1或更高的级别被加密时,则所述解密模块可以在云服务计算机处利用该云服务计算机强大的处理资源来完成所述经加密的音视频文件的比较复杂的解密过程,随后将经解密的音视频文件返回给客户源端的播放器,此时,所述播放器的解密模块无需再耗费大量有限资源对接收的音视频文件进行解密,而是由播放器直接播放所述经解密的音视频文件,从而也保证了流畅的观看体验。在下面的内容中,例举了一种具体的解密算法的过程。如上所述,所述解密过程还是以mp4视频文件作为示例来加以讨论,并且,其他合适的视频和音频格式文件也同样适用于本申请:

2.解密算法(当前举例mp4视频文件的解密),包括:

2.1恢复Major brand的值为加密前的原始值;

2.2解析Minor version得到加密的级别,恢复到加密前原始的值;

2.3恢复加密算法对Avc1 box、accC box、mp4a box、mp4v box名称的修改,使得其恢复到原始名称;

2.4根据用户提供的密钥解密上述box的加密内容以获得原始的内容,到此针对加密级别0的解密过程完成。

而如果用户是选择了加密级别1的加密来加密视频文件的话,除了包含上述这些解密步骤之外,所述解密算法还包括:

2.5根据用户提供的密钥继续解密视频关键帧(在音频帧的情况下则是每个音频帧)指定字节数的经加密数据以获得原始数据;

2.5循环执行对视频关键帧(在音频帧的情况下则是每个音频帧)的解密直到文件尾,到此解密过程完成。

如上所述,上述解密过程可以嵌入到播放器中执行。

需要指出的是,上述解密算法仅仅是出于说明的目的来进行描述,而非要对本发明的解密算法进行任何限制。其他合适的解密算法也可应用于本发明中。

通过结合上述附图所描述的各种实施例,本领域的技术人员可以理解,本发明可以存在下述益处:

(1)根据客户不同的使用场景,设置不同的加密级别,以实现数据安全性和播放体验的最佳折衷。

(2)加密的密钥由客户提供,不同客户之间不存在冲突,即一个客户不能观看使用另一个客户的音视频文件,以保障各个客户音视频文件的安全性。

(3)加密前后的文件大小一致,不增加客户及用户上传、下载的流量,保证客户及用户的利益。

(4)加密后不改变原有的音视频文件结构,减小网络传输环节带来的兼容性问题。

(5)最小化加密的复杂度,这样用户端解密代价最小,可提升用户的观看体验。

此处用细节来描述本申请的主题以满足法定要求。然而,该描述本身并非旨在限制本专利的范围。相反,发明人设想所要求保护的所针对的还可结合其他当前或未来技术按照其他方式来具体化,以包括不同的步骤或类似于本文中所描述的步骤的步骤组合。此外,尽管术语“步骤”和/或“框”可在此处用于指示所采用的方法的不同元素,但除非而且仅当明确描述了各个步骤的顺序时,该术语不应被解释为意味着此处公开的各个步骤之中或之间的任何特定顺序。

尽管用结构特征和/或方法动作专用的语言描述了本主题,但可以理解,所附权利要求书中定义的主题不必限于上述特征或动作或上述动作的次序。更具体而言,所描述的特征和动作是作为实现权利要求书的示例形式而公开的。本申请可具体化为其它具体形式而不背离其精神或本质特征。所描述的实施例在所有方面都应被认为仅是说明性而非限制性的。因此,本申请的范围由所附权利要求书而非前述描述指示。落入权利要求书的等效方案的含义和范围内的所有改变都被权利要求书的范围所涵盖。

当前第1页1 2 3 
网友询问留言 已有0条留言
  • 还没有人留言评论。精彩留言会获得点赞!
1