CN1777274A - 基于运动音视频标准文件格式的流媒体内容保护方法 - Google Patents
基于运动音视频标准文件格式的流媒体内容保护方法 Download PDFInfo
- Publication number
- CN1777274A CN1777274A CN 200510122606 CN200510122606A CN1777274A CN 1777274 A CN1777274 A CN 1777274A CN 200510122606 CN200510122606 CN 200510122606 CN 200510122606 A CN200510122606 A CN 200510122606A CN 1777274 A CN1777274 A CN 1777274A
- Authority
- CN
- China
- Prior art keywords
- file
- video
- data
- encryption
- content
- Prior art date
- Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
- Pending
Links
Images
Landscapes
- Two-Way Televisions, Distribution Of Moving Picture Or The Like (AREA)
Abstract
基于运动音视频标准文件格式的流媒体内容保护方法涉及流媒体服务技术,适用于流媒体文件分发传送过程中的内容保护,步骤包括:保留媒体数据描述信息和负载数据封装索引,根据实时传输协议报文负载数据的来源,从运动音视频标准文件获得所有的负载数据,利用加密算法,对实时传输协议报文负载数据进行等长的加密变换,再按照负载数据的原始来源,回填到运动音视频标准文件的相应位置,以实时传输协议报文头部负载类型字段作为加密和授权标记。客户端播放器在接收到实时传输协议报文后,检查负载类型字段,若发现其负载数据经过加密,则先对负载进行解密变换,再送入解码模块解码播放。该方法从流化过程出发,对实时传输协议报文负载数据离线加密。
Description
技术领域
本发明属于多媒体技术领域,涉及流媒体服务技术,适用于流媒体文件分发传送过程中的内容保护。
背景技术
近年来,随着互联网(Internet)技术的飞速进步,多媒体应用得到了极大的发展,流媒体即是多媒体应用一个重要分支。流媒体服务器采用实时流式传输方式向用户提供基于时间的多媒体信息服务(如视频点播、远程教学、视频会议)。相对于传统的媒体文件下载服务,流媒体服务的优点在于用户不需要等到媒体数据全部下载到客户端再欣赏节目,缩短了等待时间,降低了客户端的存储空间要求,增强了媒体服务的实时性。实时流式传输依赖于特定的流媒体服务器、流式传输协议和特定的文件格式以及相应的客户端软硬件支持。
实时传输协议(RTP,Real-Time Transport Protocol,RFC3550)是广泛用于流媒体数据传输的标准协议,定义了流媒体数据传送的报文格式,以标记流媒体传输的时间信息,实现音视频流同步。在文件格式方面,运动音视频标准文件格式(MP4,MPEG4 File Format,以下简称mp4文件)是移动影像专家组MPEG(Moving Picture Experts Group)制定的音视频编码标准MPEG-4标准中定义的数据存储文件格式。MP4文件是一种容器文件格式,包含音频、视频、文本等多媒体信息。这种格式可以很方便的实现流化传输,较好的解决了视频和音频之间的同步问题,对编码方式没有限制,易于扩展。
流媒体服务面临一个重要的课题,是流媒体文件分发传输过程中的内容保护问题。制作流媒体文件的内容提供商希望自己的产品(电影音视频文件),在分发到各级缓冲服务器和面向用户的边缘流媒体服务器的过程,以及流媒体服务器向用户提供流化传输服务的过程中,不被未经授权的用户享用,因此需要对文件进行加密。用户必须在经过授权后,获得与解密相关的信息,才能享用媒体信息服务,否则即便拥有流媒体文件也不能观看。视频编码标准,如MPEG系列标准,本身并不提供数据加密的解决方案。目前的视频图像加密方法,多数与视频编码密切相关,加密与编码、解密与解码步骤混合在一起,实现较为复杂,加密手段相对固定,不能灵活改变,容易对编解码过程造成不良影响。基于流媒体数据传输协议(如RTP)的加密方法,包括修改RTP报文结构和对完整的RTP报文进行加密的方式,需要流媒体服务器在流化过程中实时的进行加密,给原本就对资源要求很高的服务器增加了更多的负担,而且这种在线的加密方法只对流媒体服务器向用户提供流化传输服务的过程有效,而无法对各个服务器间的分发传输过程中传送的流媒体文件进行保护。
发明内容
技术问题:本发明的目的是从MP4文件格式和服务器流化传输过程的角度考虑内容保护问题,提出一种基于运动音视频标准文件格式的流媒体内容保护方法,该方法的加密解密过程与视频编码解码过程相互独立,不致产生过多的干扰,普通的播放器在收到未经过加密的RTP报文也可以顺利播放,只有当未经授权的用户企图用播放器播放经过加密的音视频数据时,才会无法正常进行。
技术方案:本发明的保护方法包括内容保护和内容还原两个过程。
内容保护,主要是加密过程,在内容提供商制作音视频节目流程的最后阶段,增加加密步骤。内容保护系统分三个模块:文件操作模块负责对MP4文件结构和内容进行分析,获取必要的信息,进行读写文件操作;加密模块负责对数据进行加密处理;文件管理模块负责加密后的MP4文件、密钥文件和负载类型(RTPpayload type)对应关系的维护和数据库管理。具体步骤如下:
1)工作人员设定加密所需参数,参数包括待加密的媒体文件,加密内容相应时间段,加密强度参数,加密算法,加密方式,负载类型对应关系。加密模块进行参数检查,如果有问题,则加密失败,对某一文件的内容保护过程结束;
2)文件操作模块打开待加密的文件,获得媒体文件基本信息,判断其中有多少个音视频数据流,音视频数据流所对应的RTP报文封装线索(RTP hinttrack)是哪些。如果出现异常,比如该文件没有RTP报文封装线索(这种文件只能本地播放,不能被流化传输),则加密失败,对某一文件的内容保护过程结束;
3)加密模块做加密算法准备工作,设定加密算法所需密钥,并以文件的形式保存起来;
4)文件操作模块根据设定的加密内容起始位置(以媒体的播放时间作为标记),找到相应的RTP报文封装线索,开始循环进行;
5)文件操作模块根据加密强度参数,判断当前读取的某一RTP报文封装线索所描述的负载数据,是否需要加密,如果不需要,则获得下一个RTP报文的封装线索,重复第5步;如果需要,则进行第6步;
6)文件操作模块分析RTP报文封装线索的内容,了解该封装线索所包含的封装数据信息,所描述的RTP报文的负载数据分成多少部分,每个部分源自MP4文件的具体位置和数据长度,从相应的位置提取每一部分,组成RTP报文的负载数据;
7)加密模块根据加密原则,利用加密算法对负载数据进行等长加密变换。如果加密失败,则由文件操作模块获得下一个RTP报文的封装线索,跳到第5步,失败的加密过程,不对文件做出任何修改;
8)如果加密成功,则文件操作模块把加密后的负载数据按原始来源填回MP4文件各处;
9)文件操作模块从RTP报文的封装线索中获得原始的负载类型,按照负载类型的映射关系,重新设定封装线索中的该字段;
10)重复5至9步骤,直到所有需要加密的负载数据加密完成;
11)文件管理模块将加密结果、生成的密钥文件、加密前后MP4文件、负载类型对应关系等信息存入解密信息数据库;
内容还原,主要是解密过程,由客户端服务软件和解密信息数据库共同完成,在客户端服务软件中增加解密模块,对于需要解密的数据进行处理。具体步骤如下:
12)用户点播某部影片,通过认证,客户端软件从解密信息数据库获得点播影片相应的密钥以及负载类型对应关系;
13)客户端播放器从流媒体服务器接收RTP数据报文,解析RTP报文头部,获得RTP负载类型字段,根据负载类型对应表,判断该RTP报文的负载数据是否经过加密;如果是加密数据,则解密模块采用相应的解密算法和密钥进行等长解密变换,并还原负载类型字段;
14)客户端播放器解码模块对负载数据进行解码并播放。
本发明的工作原理:
在MP4文件中,媒体描述信息和媒体数据是分别存储的。媒体描述信息包括音视频压缩格式、时间信息以及媒体数据存储位置的索引等,媒体数据包括视频压缩数据、音频采样数据等。另外,为方便流媒体服务器提供流化传输服务,MP4文件加入了服务器流化过程中需要的、与封装媒体数据相关的描述信息(如音视频数据的流化方式及时间同步关系),这些描述信息,称为封装线索(RTP hinttrack)。
流媒体服务器对于MP4文件的流化服务过程包括:用户发送点播请求,并与流媒体服务器进行一系列的交互,获得媒体文件的基本信息(这些过程中涉及MP4文件中的媒体内容描述信息),服务器根据用户点播的起始时间,找到将音视频数据封装成RTP数据报文的相应封装线索,解析其中内容,获得封装RTP报文数据的来源及相应的RTP头信息(包括RTP负载类型,即payload type,用于说明所封装的RTP报文的数据类型),将音视频数据封装成RTP报文,传送到客户端指定的接收端口,客户端播放器在接收到RTP报文后,解析RTP报文的头部负载类型信息(RTP报文头部格式,参见RFC 3550,附图1给出了结构示意图),了解媒体数据类型,再将数据送到相应的解码模块解码播放,用户就欣赏到了丰富多彩的媒体信息。
由MP4文件格式和流化过程可知,流媒体服务器需要MP4文件中特定的媒体描述信息和RTP报文封装线索才能够正常工作,因此加密MP4文件必须以不破坏这些信息为前提,即加密只能针对将被封装到RTP报文里的负载内容,也就是音视频媒体数据进行。
本发明提出的方法是:对于MP4文件的加密,只针对将被封装到RTP报文中的负载数据进行,保留媒体描述信息和封装线索。根据RTP报文负载数据的来源,从MP4文件中获得所有的负载数据(相当于进行一次虚拟的流化服务),利用加密算法(加密算法可以任选,取决于内容提供商的加密要求,但加密算法的选择可能影响用户客户端播放软件的解密播放效率),对RTP报文负载数据进行等长的加密变换,再按照负载数据的原始来源,填回到MP4文件中。客户端播放器在接收到RTP报文后,检查负载类型字段,若发现其负载数据经过加密,则先对负载进行解密变换,再送入解码模块解码播放。
除加密负载数据外,加密过程中另一重要步骤就是标记某个RTP报文中的负载数据是否经过加密处理,以及采用何种算法进行加密,本发明的方法是,重新设定RTP报文的负载类型字段,并填入原文件相应的位置,流媒体服务器在进行流化处理时,直接将MP4文件中的该字段复制到RTP报文当中,不做任何修改。客户端播放软件在接收数据播放影片前,应先从解密信息数据库获得负载类型对应表,解密模块根据负载类型字段,区分RTP报文中的负载数据的类型。
MP4文件保存了媒体数据对应的流化播放时间,据此可以对特定时间范围内的数据进行加密;MP4文件记录了负载数据的类型,如某一视频数据是I帧、P帧或是B帧,据此可以在一定程度上控制加密数据的强度,如仅对视频或者仅对音频数据加密;仅对视频中的I帧加密等方式。不同的加密级别,会在一定程度上影响客户端解密的工作负担以及播放效果。
有益效果:从流化过程出发,与通常采用的加密与视频编码相结合的方式有所不同,使得加密解密过程与视频编码解码过程相互独立,不致产生过多的干扰,逻辑上更为清晰,加密过程不影响编码过程,防止了因需要对加密信息进行标记而对编码产生的不良影响,加密算法可以动态变化,也提供了对音频数据进行加密的机会。
加密与流化过程也相互独立,不会破坏原MP4文件的负载数据封装线索和媒体描述信息,进而影响流化过程。加密过程作为制作文件的最后一步离线完成,没有给流媒体服务器增加额外的实时加密负担,这对于资源需求极大的流媒体服务器是非常有利的。与对完整的RTP数据报文进行加密的方法和修改RTP报文格式、增加加密内容的方法相比,不改变RTP数据报文格式,对现有的客户端软件数据接收模块的影响较小,只是给RTP报文头部信息的负载类型字段赋予了更丰富的含义,普通的播放器在收到未经过加密的RTP报文也可以顺利播放,只有当未经授权的用户企图用播放器播放经过加密的音视频数据时,才会无法正常进行。经过本方法保护的文件,在媒体文件分发传送到各级缓冲服务器和流媒体服务器的过程中也是安全的。
通过负载类型来区分负载数据的加密信息,使得加密方式更加灵活多样,负载类型可以区分负载数据加密与否,采用的加密算法。通过动态更新负载类型映射表,更可以控制用户的欣赏影片授权分配,如不同的负载类型标记某一用户可以观看的权限,客户端播放器发现播放内容与用户授权级别不符,则做出丢弃之类的相应处理,由此,这种方式也可以很方便的融入数字版权管理(DRM)的框架中。
附图说明
图1是RTP报文头部格式。
每个RTP报文,都有标准的头部格式,其中前12个字节是必须的,存放协议版本号(V,version,2位)、填充标志位(P,padding,1位)、扩展标志位(X,extension,1位)、作用源个数(CC,CSRC count,4位)、标志位(M,marker,1位)、负载类型(PT,payload type,7位)、序列号(sequencenumber,16位)、时间戳(timestamp,32位)、同步源标识(SSRC,synchronization source identifier,32位)、作用源(CSRC,contrubutingsource identifiers,CC项,每项32位)等必要信息,与本发明相关的是负载类型,即PT字段;
图2是内容保护流程图。
图3是内容还原流程图。
具体实施方法
本发明提出的基于MP4文件格式和流化过程的流媒体内容保护方法结合附图及其实施例说明如下:
图1是RTP报文头部格式,每个RTP报文,都有标准的头部格式,其中前12个字节是必须的,存放协议版本号(V,version,2位)、填充标志位(P,padding,1位)、扩展标志位(X,extension,1位)、作用源个数(CC,CSRC count,4位)、标志位(M,marker,1位)、负载类型(PT,payload type,7位)、序列号(sequence number,16位)、时间戳(timestamp,32位)、同步源标识(SSRC,synchronization source identifier,32位)、作用源(CSRC,contrubutingsource identifiers,CC项,每项32位)等必要信息,与本发明相关的是负载类型,即PT字段;
内容保护过程实现方法如附图3所示,包括以下步骤:
1)工作人员设定加密所需参数,参数包括待加密的媒体文件,加密内容相应时间段,加密强度参数,加密算法,加密方式,负载类型对应关系。加密模块进行参数检查,如果有问题,则加密失败,对该文件的内容保护过程结束;
取加密文件为Apple公司提供的示例MP4文件:sample_300kbit.mp4,文件播放时间70秒钟,该文件可以从Apple公司的主页,http://www.apple.com/获得;
加密内容时间段:从第20秒到第40秒;
加密强度参数:对所有的视频数据加密,不对音频数据加密;
加密算法:
仅为示意考虑,采用简单的对每一个字节加固定偏移的算法,以偏移量作为密钥;
加密方式:
对奇数个RTP报文的负载数据取正偏移量,对偶数个RTP报文的负载数据取负偏移量,例如负载数据中某字节原始内容为0x15,取密钥为0x3,若该字节属于奇数个RTP报文,则加密后该字节内容变为0x18,若该字节属于偶数个RTP报文,则加密后该字节内容变为0x12,解密时做相反操作即可;负载类型对应关系:
原MP4文件的视频数据负载类型为96;
加密后,奇数个视频数据的RTP报文的负载类型设为122,偶数个视频数据RTP报文的负载类型设为123,即第1、3、5、7…个视频数据RTP报文的负载类型为122,第2、4、6、8…个视频数据RTP报文的负载类型为123;
2)文件操作模块打开待加密的文件,获得媒体文件基本信息,判断其中有多少个音视频流,音视频流所对应的RTP报文封装线索(RTP hint track)是哪些。如果出现异常,比如该文件没有RTP报文封装线索(这种文件只能本地播放,不能被流化传输),则加密失败,对该文件的内容保护过程结束;sample_300kbit.mp4文件包含音频视频流各1条,各对应1组封装线索;
3)加密模块做加密算法准备工作,生成密钥;
取密钥为0x3;
4)文件操作模块根据设定的加密内容起始位置(以媒体的播放时间作为标记),找到相应的RTP报文封装线索,开始循环进行;
找到第20秒视频数据所对应的封装线索;
5)文件操作模块根据加密强度参数,判断当前读取的某一RTP报文封装线索所描述的负载数据,是否需要加密,如果不需要,则获得下一个RTP报文的封装线索,重复第5步;如果需要,则进行第6步;
如果该RTP报文封装线索所描述的负载数据,属于20至40秒之间的视频数据,则进行加密,否则不加密;
6)文件操作模块分析RTP报文封装线索的内容,了解该封装线索所包含的封装数据信息,其描述的RTP报文的负载数据分成多少部分,每个部分源自MP4文件的具体位置和数据长度,从相应的位置提取每一部分,组成RTP报文的负载数据,封装信息结构如下:
struct posArrayInEachRTPPacket
{
UInt16 RTPHeaderInfo; 该RTP报文的头信息字段
UInt16 dataEntryCount;组成RTP报文负载内容的数据块的个数
UInt16 curPos; 当前在posArray数组中存放的数据块个
数
UInt64 RTPHeaderInfoPos;某RTP报文的头信息在MP4文件中的
偏移位置
UInt64 RTPSampleOffset; 某RTP报文封装索引在文件中的偏
移位置
struct posEntry posArray[MAXENTRIES];
最大长度为MAXENTRIES的数组
每一项对应组成RTP报文的一个数据来源信息
}
struct posEntry结构定义了组成RTP报文的每一部分数据的相关信息
{
UInt64 offset; 某一部分数据在文件中的偏移位置
UInt32 payloadLength;在加上该部分数据后,RTP中负载的
总长度
UInt16 length; 该部分数据的长度
char dataSource; 该部分数据的来源类型
}
7)加密模块根据加密原则,利用加密算法对负载数据进行等长加密变换。如果加密失败,则由文件操作模块获得下一个RTP报文的封装线索,跳到第5步,失败的加密过程,不对文件做出任何修改;
判断当前处理的RTP报文,如果是第1、3、5、7…个,则将负载内容每个字节加0x3,如果是第2、4、6、8…个,则将负载内容每个字节减0x3;
8)如果加密成功,则文件操作模块把加密后的负载数据按原始来源写入MP4文件各处;
9)文件操作模块从RTP报文的封装线索中获得原始的负载类型,按照负载类型的映射关系,重新设定封装线索中的该字段;
根据情况分别填入122或123;
10)重复5至9步骤,直到所有需要加密的负载数据加密完成;
11)文件操作模块将加密结果、生成的密钥文件、加密前后MP4文件、负载类型对应关系等信息存入解密信息数据库。
内容还原实现方法如附图4所示,包括以下步骤:
12)用户点播某部影片,通过认证,客户端软件从解密信息数据库获得点播影片相应的密钥以及负载类型对应关系;
获得负载类型对应关系,122和123都应还原为96,但两者解密方式不同,前者应将负载数据减去密钥,而后者应加上密钥;
13)客户端播放器从流媒体服务器接收RTP数据报文,解析RTP报文头部,获得RTP负载类型字段,根据第1步获得的负载类型对应表,判断该RTP报文的负载数据是否经过加密;如果是加密数据,则加密模块采用相应的解密算法和密钥进行等长解密变换,并还原负载类型字段;
14)解码模块对负载数据进行解码并播放。
经过上述方法保护后的文件,若采用普通播放器,在本地播放,从0到20秒时间段正常,到第20秒时,播放器无法播放出视频图像;播放器从流媒体服务器接收流化传输的RTP报文后播放,从0到20秒正常,到第20秒,图像凝滞,声音继续正常播放,到40秒,图像也恢复正常;若采用增加了解密模块的播放器,在通过认证获得负载类型对应表后,播放从流媒体服务器接收的RTP报文,图像和声音可以顺畅的播放到结尾。
实验运行条件:
流媒体服务器硬件配置及操作系统
CPU:Intel Xeon 2.4GHz双CPU
内存:4GB
网卡:1000M
操作系统:Debian GNU/Linux
客户端硬件配置及操作系统
CPU:Intel PIII 700MHz
内存:256MB
网卡:10/100M自适应
操作系统:Windows2000 Professional
本实例证明了本方法的可行性。
Claims (7)
1.一种基于运动音视频标准文件格式的流媒体内容保护方法,其特征在于该方法包括内容保护和内容还原两个过程,其中,内容保护,即加密过程,在内容提供商制作音视频节目流程的最后阶段,增加加密步骤;内容还原,即解密过程,由客户端服务软件和解密信息数据库共同完成,在客户端服务软件中增加解密模块,对于需要解密的负载数据进行处理。
2.根据权利要求1所述的基于运动音视频标准文件格式的流媒体内容保护方法,其特征在于内容保护分三个模块:文件操作模块负责对运动音视频标准文件结构和内容进行分析,获取封装音视频数据方式的信息,进行读写文件操作;加密模块负责对数据进行加密处理;文件管理模块负责加密后的运动音视频标准文件、密钥文件和负载类型对应关系的维护和数据库管理,内容保护过程具体步骤如下:
1)工作人员设定加密所需参数,参数包括待加密的媒体文件,加密内容相应时间段,加密强度参数,加密算法,加密方式,负载类型对应关系;加密模块进行参数检查,如果有问题,则加密失败,对某一文件的内容保护过程结束;
2)文件操作模块打开待加密的文件,获得媒体文件基本信息,判断其中有多少个音视频流、音视频流所对应的实时传输协议报文封装线索是哪些;如果出现异常,则加密失败,对某一文件的内容保护过程结束;
3)加密模块做加密算法准备工作,设定加密算法所需密钥,并以文件的形式保存起来;
4)文件操作模块根据设定的加密内容起始位置,即以媒体的播放时间作为标记,找到相应的实时传输协议报文封装线索,开始循环进行;
5)文件操作模块根据加密强度参数,判断当前读取的封装线索所描述的负载数据,是否需要加密,如果不需要加密,则获得下一个封装线索,重复此第5步;如果需要加密,则进行下一步;
6)文件操作模块分析实时传输协议报文封装线索的内容,了解该封装线索所包含的封装数据信息,所描述的负载数据分成多少部分,每个部分源自MP4文件的具体位置和数据长度,从相应的位置提取每一部分,组成负载数据;
7)加密模块根据加密原则,利用加密算法对负载数据进行等长加密变换,如果加密失败,则由文件操作模块获得下一个封装线索,跳到以上第5步,失败的加密过程,不对文件做出任何修改;
8)如果加密成功,则由文件操作模块把加密后的负载数据按原始来源填回原运动音视频标准文件各处;
9)文件操作模块从实时传输协议报文的封装线索中获得原始的负载类型,按照负载类型的映射关系,重新设定封装线索中的该字段;
10)重复以上第5至第9步骤,直到所有需要加密的负载数据加密完成;
11)文件管理模块将加密结果、生成的密钥文件、加密前后运动音视频标准文件、负载类型对应关系等信息存入解密信息数据库;对某一文件的内容保护过程结束。
3.根据权利要求2所述的基于运动音视频标准文件格式的流媒体内容保护方法,其特征在于加密过程保留运动音视频标准文件中媒体描述信息和实时传输协议报文封装线索,只对实时传输协议报文的负载数据进行加密保护。
4.根据权利要求1所述的基于运动音视频标准文件格式的流媒体内容保护方法,其特征在于内容还原的解密过程由客户端软件和解密信息数据库共同完成,在客户端服务软件中增加解密模块,对需要解密的数据进行处理,内容还原过程步骤如下:
1)用户点播某部影片,通过认证,客户端软件从解密信息数据库获得点播影片相应的密钥以及负载类型对应关系;
2)客户端播放器从流媒体服务器接收实时传输协议数据报文,解析报文头部,获得负载类型字段,判断报文的负载数据是否经过加密;如果是加密数据,则解密模块采用解密算法和密钥进行等长解密变换,并还原报文头部负载类型字段;
3)客户端播放器的解码模块对负载数据进行解码并播放。
5.根据权利要求2和4所述的基于运动音视频标准文件格式的流媒体内容保护方法,其特征在于加密和解密过程以实时传输协议报文头部负载类型字段作为加解密和授权的标记,灵活控制内容保护方式和强度,加密工作与编码工作,解密工作与解码工作相互独立。
6.根据权利要求5所述的基于运动音视频标准文件格式的流媒体内容保护方法,其特征在于加密工作和编码工作独立,加密工作和编码工作无前后相关性。
7.根据权利要求5所述的基于运动音视频标准文件格式的流媒体内容保护方法,其特征在于解密工作和解码工作独立,解密工作和解码工作无前后相关性。
Priority Applications (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| CN 200510122606 CN1777274A (zh) | 2005-11-29 | 2005-11-29 | 基于运动音视频标准文件格式的流媒体内容保护方法 |
Applications Claiming Priority (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| CN 200510122606 CN1777274A (zh) | 2005-11-29 | 2005-11-29 | 基于运动音视频标准文件格式的流媒体内容保护方法 |
Publications (1)
| Publication Number | Publication Date |
|---|---|
| CN1777274A true CN1777274A (zh) | 2006-05-24 |
Family
ID=36766537
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| CN 200510122606 Pending CN1777274A (zh) | 2005-11-29 | 2005-11-29 | 基于运动音视频标准文件格式的流媒体内容保护方法 |
Country Status (1)
| Country | Link |
|---|---|
| CN (1) | CN1777274A (zh) |
Cited By (14)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN101159579B (zh) * | 2007-11-06 | 2010-08-11 | 北京创毅视讯科技有限公司 | 接收基于网络传输协议的流媒体数据的方法及终端 |
| CN101312531B (zh) * | 2007-11-02 | 2010-11-17 | 北京创毅视讯科技有限公司 | 一种广播系统中的流媒体业务传输方法及流媒体帧封装器 |
| CN102036102A (zh) * | 2009-09-25 | 2011-04-27 | 腾讯科技(深圳)有限公司 | 多媒体转码系统、方法及播放多媒体的系统、方法 |
| CN102075287A (zh) * | 2010-11-22 | 2011-05-25 | 浪潮(北京)电子信息产业有限公司 | 一种数据处理方法及装置 |
| CN101325480B (zh) * | 2007-06-13 | 2012-05-23 | 中兴通讯股份有限公司 | 基于复用子帧的加扰控制方法及装置 |
| CN101742229B (zh) * | 2008-11-25 | 2013-10-16 | 北京中星微电子有限公司 | 提高监控数据安全性的方法、系统及装置 |
| CN104683825A (zh) * | 2015-02-12 | 2015-06-03 | 央广视讯传媒股份有限公司 | 一种ts流加密传输及其解码处理的方法 |
| CN101783793B (zh) * | 2009-01-14 | 2015-09-02 | 北京中星微电子有限公司 | 提高监控数据安全性的方法、系统及装置 |
| CN108337566A (zh) * | 2017-01-20 | 2018-07-27 | 创盛视联数码科技(北京)有限公司 | 一种基于mp4格式文件的加密方法 |
| CN112954404A (zh) * | 2021-01-25 | 2021-06-11 | 世纪龙信息网络有限责任公司 | 一种mpeg-2 ps视频文件的加密存储方法和装置 |
| CN113726760A (zh) * | 2021-08-27 | 2021-11-30 | 珠海市鸿瑞信息技术股份有限公司 | 一种基于负载均衡的工业控制通信加密系统及方法 |
| CN114863741A (zh) * | 2022-05-20 | 2022-08-05 | 安徽文香科技有限公司 | 一种用于线上教学的设备通信方法及系统 |
| CN115567749A (zh) * | 2022-08-19 | 2023-01-03 | 深圳市酷开网络科技股份有限公司 | 复合音视频投屏方法、装置及投屏设备 |
| CN115767134A (zh) * | 2022-11-11 | 2023-03-07 | 深圳市洲明科技股份有限公司 | 音视频的处理方法、装置、计算机设备和存储介质 |
-
2005
- 2005-11-29 CN CN 200510122606 patent/CN1777274A/zh active Pending
Cited By (15)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN101325480B (zh) * | 2007-06-13 | 2012-05-23 | 中兴通讯股份有限公司 | 基于复用子帧的加扰控制方法及装置 |
| CN101312531B (zh) * | 2007-11-02 | 2010-11-17 | 北京创毅视讯科技有限公司 | 一种广播系统中的流媒体业务传输方法及流媒体帧封装器 |
| CN101159579B (zh) * | 2007-11-06 | 2010-08-11 | 北京创毅视讯科技有限公司 | 接收基于网络传输协议的流媒体数据的方法及终端 |
| CN101742229B (zh) * | 2008-11-25 | 2013-10-16 | 北京中星微电子有限公司 | 提高监控数据安全性的方法、系统及装置 |
| CN101783793B (zh) * | 2009-01-14 | 2015-09-02 | 北京中星微电子有限公司 | 提高监控数据安全性的方法、系统及装置 |
| CN102036102A (zh) * | 2009-09-25 | 2011-04-27 | 腾讯科技(深圳)有限公司 | 多媒体转码系统、方法及播放多媒体的系统、方法 |
| CN102075287A (zh) * | 2010-11-22 | 2011-05-25 | 浪潮(北京)电子信息产业有限公司 | 一种数据处理方法及装置 |
| CN104683825A (zh) * | 2015-02-12 | 2015-06-03 | 央广视讯传媒股份有限公司 | 一种ts流加密传输及其解码处理的方法 |
| CN108337566A (zh) * | 2017-01-20 | 2018-07-27 | 创盛视联数码科技(北京)有限公司 | 一种基于mp4格式文件的加密方法 |
| CN108337566B (zh) * | 2017-01-20 | 2021-06-29 | 创盛视联数码科技(北京)有限公司 | 一种基于mp4格式文件的加密方法 |
| CN112954404A (zh) * | 2021-01-25 | 2021-06-11 | 世纪龙信息网络有限责任公司 | 一种mpeg-2 ps视频文件的加密存储方法和装置 |
| CN113726760A (zh) * | 2021-08-27 | 2021-11-30 | 珠海市鸿瑞信息技术股份有限公司 | 一种基于负载均衡的工业控制通信加密系统及方法 |
| CN114863741A (zh) * | 2022-05-20 | 2022-08-05 | 安徽文香科技有限公司 | 一种用于线上教学的设备通信方法及系统 |
| CN115567749A (zh) * | 2022-08-19 | 2023-01-03 | 深圳市酷开网络科技股份有限公司 | 复合音视频投屏方法、装置及投屏设备 |
| CN115767134A (zh) * | 2022-11-11 | 2023-03-07 | 深圳市洲明科技股份有限公司 | 音视频的处理方法、装置、计算机设备和存储介质 |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| JP6914381B2 (ja) | 独立的に符号化されたタイルを組み込む基本ビットストリームを保護するためのシステムおよび方法 | |
| US10045093B2 (en) | Systems and methods for securing content delivered using a playlist | |
| CN1228981C (zh) | 用于分配加密的压缩图像数据的流化系统及其流化方法 | |
| CN1287595C (zh) | 内容的传递及保护的方法及装置 | |
| CN102292931B (zh) | 在单个容器文件中支持多个保护系统的方法和装置 | |
| US8243924B2 (en) | Progressive download or streaming of digital media securely through a localized container and communication protocol proxy | |
| CN1685659A (zh) | 流处理系统和流处理方法 | |
| CN1918561A (zh) | 运动画面文件加密方法及其数字权限管理方法 | |
| CN1339223A (zh) | 用于数据流处理的系统 | |
| CN1777274A (zh) | 基于运动音视频标准文件格式的流媒体内容保护方法 | |
| CN1780361A (zh) | 管理音频/视频数据的单元和所述数据的访问控制方法 | |
| CN104735457A (zh) | 一种基于h.264编码的视频加解密方法 | |
| CN1463517A (zh) | 多媒体信息提供及保护用的灵活通用ipmp系统的装置及方法 | |
| CN1613228A (zh) | 对多媒体的多播传输的接收机唯一的水印的产生 | |
| CN1767032A (zh) | 使用暂时存储介质的多流设备和多流方法 | |
| CN1852432A (zh) | 一种对直播流媒体数据进行加密和解密的方法 | |
| US20200275142A1 (en) | A method for delivering digital content to at least one client device | |
| CN105187912A (zh) | 密文视频播放器及播放方法 | |
| CN101064813A (zh) | 视频加解密装置以及加解密方法 | |
| CN118573955B (zh) | 一种基于hls协议的加密方法及系统 | |
| US20250287051A1 (en) | Increasing security of streaming media by converting a secure media format into a streaming media format without introducing lag | |
| CN1558585A (zh) | 网络与可录媒体加密解密方法 | |
| CN1946175A (zh) | 内容的传递及保护的方法及装置 | |
| CN1812581A (zh) | 一种基于内容的节目流加密算法 | |
| CN1831832A (zh) | 一种保护内容的方法及装置 |
Legal Events
| Date | Code | Title | Description |
|---|---|---|---|
| C06 | Publication | ||
| PB01 | Publication | ||
| C10 | Entry into substantive examination | ||
| SE01 | Entry into force of request for substantive examination | ||
| C02 | Deemed withdrawal of patent application after publication (patent law 2001) | ||
| WD01 | Invention patent application deemed withdrawn after publication |
Open date: 20060524 |