CN104717553B - 用于对压缩视频进行解码的设备和方法 - Google Patents

用于对压缩视频进行解码的设备和方法 Download PDF

Info

Publication number
CN104717553B
CN104717553B CN201410764391.4A CN201410764391A CN104717553B CN 104717553 B CN104717553 B CN 104717553B CN 201410764391 A CN201410764391 A CN 201410764391A CN 104717553 B CN104717553 B CN 104717553B
Authority
CN
China
Prior art keywords
video
scrambling
unit
compression
frame
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.)
Active
Application number
CN201410764391.4A
Other languages
English (en)
Other versions
CN104717553A (zh
Inventor
弗朗西斯科·马丁
刘孝波
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Sikaide European Limited by Share Ltd
Original Assignee
Sikaide European Ltd By Share Ltd
Priority date (The priority date 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 date listed.)
Filing date
Publication date
Application filed by Sikaide European Ltd By Share Ltd filed Critical Sikaide European Ltd By Share Ltd
Publication of CN104717553A publication Critical patent/CN104717553A/zh
Application granted granted Critical
Publication of CN104717553B publication Critical patent/CN104717553B/zh
Active legal-status Critical Current
Anticipated expiration legal-status Critical

Links

Classifications

    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04NPICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N19/00Methods or arrangements for coding, decoding, compressing or decompressing digital video signals
    • H04N19/85Methods or arrangements for coding, decoding, compressing or decompressing digital video signals using pre-processing or post-processing specially adapted for video compression
    • H04N19/88Methods or arrangements for coding, decoding, compressing or decompressing digital video signals using pre-processing or post-processing specially adapted for video compression involving rearrangement of data among different coding units, e.g. shuffling, interleaving, scrambling or permutation of pixel data or permutation of transform coefficient data among different blocks
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04NPICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N19/00Methods or arrangements for coding, decoding, compressing or decompressing digital video signals
    • H04N19/40Methods or arrangements for coding, decoding, compressing or decompressing digital video signals using video transcoding, i.e. partial or full decoding of a coded input stream followed by re-encoding of the decoded output stream
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04NPICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N19/00Methods or arrangements for coding, decoding, compressing or decompressing digital video signals
    • H04N19/46Embedding additional information in the video signal during the compression process
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04NPICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N19/00Methods or arrangements for coding, decoding, compressing or decompressing digital video signals
    • H04N19/48Methods or arrangements for coding, decoding, compressing or decompressing digital video signals using compressed domain processing techniques other than decoding, e.g. modification of transform coefficients, variable length coding [VLC] data or run-length data
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04NPICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N19/00Methods or arrangements for coding, decoding, compressing or decompressing digital video signals
    • H04N19/50Methods or arrangements for coding, decoding, compressing or decompressing digital video signals using predictive coding
    • H04N19/503Methods or arrangements for coding, decoding, compressing or decompressing digital video signals using predictive coding involving temporal prediction
    • H04N19/51Motion estimation or motion compensation
    • H04N19/513Processing of motion vectors
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04NPICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N19/00Methods or arrangements for coding, decoding, compressing or decompressing digital video signals
    • H04N19/70Methods or arrangements for coding, decoding, compressing or decompressing digital video signals characterised by syntax aspects related to video coding, e.g. related to compression standards
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04NPICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N19/00Methods or arrangements for coding, decoding, compressing or decompressing digital video signals
    • H04N19/85Methods or arrangements for coding, decoding, compressing or decompressing digital video signals using pre-processing or post-processing specially adapted for video compression
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04NPICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N21/00Selective content distribution, e.g. interactive television or video on demand [VOD]
    • H04N21/40Client devices specifically adapted for the reception of or interaction with content, e.g. set-top-box [STB]; Operations thereof
    • H04N21/41Structure of client; Structure of client peripherals
    • H04N21/426Internal components of the client ; Characteristics thereof
    • H04N21/42607Internal components of the client ; Characteristics thereof for processing the incoming bitstream
    • H04N21/42623Internal components of the client ; Characteristics thereof for processing the incoming bitstream involving specific decryption arrangements
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04NPICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N21/00Selective content distribution, e.g. interactive television or video on demand [VOD]
    • H04N21/40Client devices specifically adapted for the reception of or interaction with content, e.g. set-top-box [STB]; Operations thereof
    • H04N21/43Processing of content or additional data, e.g. demultiplexing additional data from a digital video stream; Elementary client operations, e.g. monitoring of home network or synchronising decoder's clock; Client middleware
    • H04N21/44Processing of video elementary streams, e.g. splicing a video clip retrieved from local storage with an incoming video stream or rendering scenes according to encoded video stream scene graphs
    • H04N21/4405Processing of video elementary streams, e.g. splicing a video clip retrieved from local storage with an incoming video stream or rendering scenes according to encoded video stream scene graphs involving video stream decryption
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04NPICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N21/00Selective content distribution, e.g. interactive television or video on demand [VOD]
    • H04N21/40Client devices specifically adapted for the reception of or interaction with content, e.g. set-top-box [STB]; Operations thereof
    • H04N21/43Processing of content or additional data, e.g. demultiplexing additional data from a digital video stream; Elementary client operations, e.g. monitoring of home network or synchronising decoder's clock; Client middleware
    • H04N21/44Processing of video elementary streams, e.g. splicing a video clip retrieved from local storage with an incoming video stream or rendering scenes according to encoded video stream scene graphs
    • H04N21/4408Processing of video elementary streams, e.g. splicing a video clip retrieved from local storage with an incoming video stream or rendering scenes according to encoded video stream scene graphs involving video stream encryption, e.g. re-encrypting a decrypted video stream for redistribution in a home network

Landscapes

  • Engineering & Computer Science (AREA)
  • Multimedia (AREA)
  • Signal Processing (AREA)
  • Compression Or Coding Systems Of Tv Signals (AREA)
  • Two-Way Televisions, Distribution Of Moving Picture Or The Like (AREA)

Abstract

公开了一种用于对压缩视频进行解码的方法和设备。所述方法包括对压缩视频进行加扰,以产生加扰压缩视频;将所述加扰压缩视频递送到解码器,以用于对所述加扰压缩视频进行解码,以产生加扰解压缩视频;从解码器接收所述加扰解压缩视频;以及对所述加扰解压缩视频进行解扰,以产生解扰解压缩视频。

Description

用于对压缩视频进行解码的设备和方法
技术领域
本发明涉及对压缩数字视频的解码。尤其与用于播放视频的软件应用有关,所述软件应用使用专用的硬件解码器设备执行解码(解压缩)。
背景技术
因特网上的视频分配(distribution)是一个快速增长的市场。所谓的“因特网电视”(OTT)内容可通过宽带因特网连接进行递送。通常,这一内容由第三方来支持,因特网服务提供商(ISP)只负责传输基础因特网协议(IP)分组。具体地,OTT服务代表了一个快速增长的市场。它们使得终端用户能够享受智能设备(比如智能手机和平板电脑)上的视频。近期,已经出现了许多能够通过OTT服务观看视频的软件应用。然而,大多数针对这些服务的内容在质量和分辨率方面是受限的——其通常是标清(SD)的而不是高清(HD)的。
许多智能设备基于开放操作系统(诸如安卓(Android))。这使得开发者能够快速制作针对设备的应用。然而,这些操作系统的开放本质可能成为内容提供商的顾虑,在没有用来保护所述内容不被未授权拷贝的适当措施的情况下,内容提供商可能不愿意在这种平台上提供高质量、高分辨率的内容。如果能够提供合适的内容保护,那么内容提供商可能会更加愿意分配高质量的HD内容。
一种已经提议的解决方案是使用“可信环境”,以便保护整个视频递送路径。这一方案的一个示例是由ARM Ltd研发的技术。这种方案能够解决内容保护的问题,但其实施却很麻烦。具体地,这种环境中对证书和其它强安全性机制的需要也为软件应用开发者带来了额外的负担,开发者可能需要在每次对软件应用进行更新时经历一次验证过程。
发明内容
根据本发明的一个方面,提供了一种用于对压缩视频进行解码的设备,所述设备包括:
视频加扰单元,适于接收压缩视频并对其进行加扰,以产生加扰压缩视频;
视频解码器,布置为接收来自加扰单元的所述加扰压缩视频并适于对其进行解码,以产生加扰解压缩视频;以及
视频解扰单元,布置为接收来自视频解码器的所述加扰解压缩视频并适于对其进行解扰,以产生解扰解压缩视频。
在这一设备中,以加扰的形式对视频进行解码(解压缩)。这能使得恶意用户更难拷贝视频,这是由于视频在视频解码器的输入端和输出端处都处于加扰形式。
视频加扰单元优选地适于通过以下方式对所述压缩视频进行加扰:不阻止视频解码器对视频进行解码;在解码后修改所述加扰解压缩视频的视觉内容;以及所述视频加扰单元是通过视频解扰单元可逆的,使得所述解扰解压缩视频与在所述压缩视频将在不进行加扰的情况下由视频解码器解码的条件下将产生的视频相同或实质相同。
优选地,对视觉内容的修改产生可察觉视觉扰动。这将使观看者观看加扰压缩视频产生烦躁(annoyance),由此使得恶意用户更难于制作视频的高质量非法拷贝。
从视频解扰单元可重构(精确地或至少近似地)在不进行任何加扰的情况下将产生的解压缩视频的意义上讲,所述加扰是系统性的。
优选地,不需要对视频解码器进行任何修改。这意味着压缩视频和加扰压缩视频两者都能由视频解码器采用相同方式解码。也就是说,加扰对于视频解码器是透明的。
可认为解扰解压缩视频与不进行加扰的相应解压缩视频是实质相同的,前提是其包含相同数量的帧并且这些帧中的大多数与未进行加扰的解压缩视频中的它们的对应部分相同。优选地,任何与它们的对应部分不相同的帧在视觉上与它们的对应部分在视觉上是相似的。
优选地,视频加扰单元适于产生描述由视频加扰单元执行的加扰操作的加扰元数据;以及视频解扰单元布置为接收来自加扰单元的所述加扰元数据,并且适于使用所述加扰元数据来对从视频解码器接收的加扰解压缩视频进行解扰。
优选地,不将所述加扰元数据提供给视频解码器。
由视频加扰单元执行的加扰包括在压缩视频的单独访问单元上执行的一个或多个操作。
也就是说,所述修改并不一致地对待所有访问单元。至少一些访问单元是被区别对待的——在一个访问单元上执行的操作与在至少一个其它访问单元上执行的操作不同。访问单元可包括对视频的单个帧或帧的一部分的编码表示。
由视频加扰单元执行的加扰可包括以下至少一项:改变访问单元在压缩视频中的排序;将一个或多个附加访问单元插入压缩视频;以及从压缩视频移除一个或多个访问单元。
优选地,改变访问单元的排序包括改变它们的呈现顺序而不改变它们被视频解码器解码的顺序。
可选地,视频加扰单元可适于检测在不对压缩视频进行进一步适应的情况下是否可对特定的访问单元进行插入、移除或重排序。如果进一步的适应是必须的,则视频加扰单元优选地适于执行这一进一步的适应。视频加扰单元还适于检测即使对压缩视频进行了进一步的适应是否也不能插入、移除或重排序访问单元。如果检测到这一点,则视频加扰单元可禁用针对相关访问单元的加扰。
控制视频加扰单元向视频的第一部分施加加扰而不对视频的第二部分施加加扰。
优选地,随机地或伪随机地选择所述第一部分和第二部分。
视频解码器可以包括硬件视频解码器。
硬件解码器通常是分离的电子设备(例如,分离的集成电路或“芯片”),其被特别地设计为对压缩视频流进行解码。
优选地,压缩视频和视频解码器符合预定的视频编码标准;以及视频加扰单元适于以使得按照加扰压缩视频符合相同的视频编码标准的方式来对压缩视频进行加扰。
也就是说,由视频加扰单元执行的加扰不破坏视频比特流与视频编码标准的符合性。从而,符合标准的视频解码器可用来对加扰压缩比特流进行解码。
视频解码器和压缩视频可符合H.264标准,以及所述加扰可包括修改H.264压缩视频中的多个访问单元中的图像顺序计数(POC)。
对POC的修改优选地包括以下中的至少一项:对访问单元的集合的POC值进行重排序;以及将访问单元的集合的POC值乘以整数。对POC值进行重排序具有改变访问单元的原始呈现顺序的效果。将POC值乘以整数使得在原始访问单元之间插入一个或多个附加访问单元。
如上所述,视频加扰单元可适于检测在不对压缩视频进行进一步适应的情况下是否可对特定的访问单元进行插入、移除或重排序。如果进一步的适应是必须的,则视频加扰单元优选地适于执行这一进一步的适应。在H.264标准的情况中,这一适应可包括在其它方面(除了修改访问单元的POC之外)修改压缩视频流的句法。
视频加扰单元可以适于:检测图像顺序计数隐式地编码在压缩视频中,以及作为响应:修改压缩视频的报头信息,以便表明对所述图像顺序计数进行显式编码;以及在压缩视频的每个访问单元中指派显式的图像顺序计数值。
在一些H.264视频流中,POC是隐式的。通过将这种流转换为对POC加以编码,显式地,通过修改POC来对视频进行加扰变为可能。
视频加扰单元可适于在压缩视频中检测要求视频解码器使用图像顺序计数对一个或多个访问单元进行解码的编码模式,并且作为响应:禁用所述加扰;或修改所述压缩视频,使得视频解码器不再需要使用图像顺序计数来对一个或多个访问单元进行解码。
一般来讲,在解码处理中不需要POC,POC只是在已经对帧进行解码之后确定帧的呈现(显示)顺序。然而,在某些编码模式中,对帧的解码取决于其POC。在这些模式中,通过修改POC来加扰可以导致解码误差——例如,经过解码的帧的视觉内容中的可察觉的改变。
检测这一模式可包括检测时间预测模式,其中运动向量取决于POC值(时间直接预测)。作为备选或补充,检测这一模式可包括检测加权预测模式,其中加权预测取决于POC值。
视频加扰单元可以适于:检测所述压缩视频是根据H.264标准的基线简档编码的,并且作为响应,修改所述压缩视频,以便将所述压缩视频转换到另一H.264简档。
也就是说,视频加扰单元可以适于修改压缩视频流的句法,以便将其从符合基线简档的比特流转换成符合不同简档(优选的,主简档)的比特流。在基线简档中,帧的呈现顺序通常与它们的解码顺序相同。因此,如果基线简档视频是通过修改某些帧的POC来加扰的,则恶意用户可能能够通过按照帧被解码的顺序呈现帧来对视频进行解扰。将视频转换成另一简档(具体的,主简档)可以有助于掩盖真实的呈现顺序与解码顺序相同这一事实。
还提供了一种便携电子设备,比如移动电话或平板计算设备,其中包括如上所述的设备。
本发明在这一设备中是尤其有益的,这是因为在这种设备上将视频播放器提供为软件应用是常见的。这一应用运行在通用微处理器或微控制器上。然而,使用硬件加速器(与通用处理器分离)来解码压缩视频也是常见的,这是因为通过处理器不具有足够的处理能力。即使视频播放器应用软件和硬件加速器设备是(单独)安全的,恶意用户也可能拦截软件应用(通用处理器)和硬件加速器之间的视频。根据本发明的一个实施例,应用软件在将压缩视频发送到硬件加速器之前控制通用处理器对压缩视频进行加扰,以及控制通用处理器对从硬件加速器接收的加扰解压缩视频进行解扰。也就是说,加扰单元和解扰单元的功能可由通用处理器在视频播放器应用软件的控制下执行。
根据本发明的另一方面,提供了一种对压缩视频进行解码的方法,包括:
对压缩视频进行加扰,以产生加扰压缩视频;
对加扰压缩视频进行解码,以产生加扰解压缩视频;以及
对加扰解压缩视频进行解扰,以产生解扰解压缩视频。
还提供了一种存储计算机程序的非瞬时计算机可读介质,计算机程序包括适于当在计算机上运行所述程序时执行如上所述的方法的所有步骤的计算机程序代码装置。
附图说明
现在参照附图通过示例的方式对本发明进行描述,其中:
图1示出了想象的传统视频播放器;
图2示出了根据本发明实施例的视频播放器;
图3更详细地示出了图2中的视频加扰单元;
图4更详细地示出了图2中的视频解扰单元;
图5示出了根据本发明实施例使用的不同帧类型;
图6是示出了通过重混排进行加扰的流程图;
图7是示出了通过AU插入进行加扰的流程图;
图8是示出了通过AU替代进行加扰的流程图;
图9是示出了解扰过程的流程图;
图10是示出了针对使用H.264编码的视频的加扰方法的初始步骤的伪码流程图;
图11是接续自图10的伪码流程图,其中示出了通过重混排进行加扰;
图12是接续自图11的伪码流程图,其中示出了通过帧插入进行加扰;以及
图13是示出了由图2的随机控制单元执行的方法的流程图。
具体实施方式
为了使用典型的智能设备上的高质量HD视频内容,希望使用智能设备中可用的硬件(HW)视频解码器。这是由于运行在智能设备中的通用处理器上的软件解码器可能不具有足够的处理能力来解码HD视频。典型的系统将具有软件(SW)视频播放器(通常集成在服务提供商的应用中),该SW视频播放器将采用平台的HW视频解码器来执行对压缩视频流的实际解码。
图1中示出了这一系统的示例。音频和视频的流从源100递送到软件视频播放器110。软件视频播放器110是软件应用,其运行于智能设备的通用处理器上。在软件视频播放器110中,通过不同的处理路径来处理音频和视频。由音频复原单元112对音频流进行复原并传送到音频解密单元114进行解密。由音频解码器116在将解密流传送到渲染器音频渲染器(renderer)118之前对其进行解码。其输出被递送到音频接收器(例如扩音器)的音频信号。由视频复原单元122对视频流进行复原,然后由视频解密单元124进行解密。软件视频播放器110从而将解密视频发送到硬件视频解码器130,以用于解码。将解密(未压缩的)视频从硬件视频解码器130发送回软件视频播放器110,并由视频渲染器128进行渲染。由视频渲染器128输出的视频信号被提供到视频接收器150(例如智能设备的显示屏)。本领域技术人员将理解的是,软件视频播放器110的组件112-128表示软件应用的功能单元,这些功能单元全部在通用处理器(未示出)上执行。然而,硬件视频解码器130是分离的硬件设备。
通常由软件安全性机制来保护软件视频播放器110,比如:代码模糊、防调试、防篡改以及防刷机。然而,在这一架构中的两个点处,恶意用户可以获得对内容的访问。首先,在视频解密单元124和硬件视频解码器130之间,在压缩域中,视频处于未加密的可用状态。其次,在硬件视频解码器130和视频渲染器128之间,视频在像素域中处于未加密的可用状态。
发明人已经认识到,免除对平台上的可信环境的需要但仍使得能够对高质量HD视频进行安全分配是期望的。根据本发明的实施例提供的方案将在压缩域实现视频加扰机制并在像素域中提供视频解扰机制。通过这一方式,如果恶意用户在上述弱点处获得所述内容,则由于加扰器所产生的视觉损害,所述内容更几乎是不可观看的。在一些实施例中,为了使系统对于恶意用户对加扰流的反向操纵更加鲁棒,使用随机控制机制,以便在任意时刻激活加扰机制。
图2示出了根据本发明实施例的软件视频播放器210。这是基于图1的架构。除非另外规定,共享的组件是相似的,并且将不再赘述。主要区别在于,软件视频播放器210包括视频加扰单元220、视频解扰单元230和随机控制单元240。视频加扰单元220在压缩域进行操作。视频加扰单元从视频解密单元124接收解密视频压缩基本流作为输入,并产生加扰视频压缩基本流作为输出。这一输出提供到硬件视频解码器130(其可以与图1的解码器相同)。视频解扰单元230操作于像素域。视频解扰单元获得从硬件视频解码器130接收的加扰解压缩视频,并基于加扰元数据产生解扰解压缩视频。加扰元数据在软件视频播放器210内部从视频加扰单元220提供到视频解扰单元230。视频解扰单元230的输出提供到视频渲染器128,以用于进行渲染。随机控制单元240控制视频加扰单元220随机地激活加扰处理。
视频加扰单元220和视频解扰单元230集成在软件视频播放器210中,并且能够被软件保护机制(其一些示例是本领域已知的)保护。
视频加扰单元220在压缩域处理访问单元(AU),并实现能够单独或合并执行的若干加扰机制。这些加扰机制包括:视频AU重排序(混排);视频AU插入;视频AU移除;以及视频AU替代。随机控制单元240和视频加扰单元220的功能将在图3中更详细的示出。控制单元240包括随机数发生器242。随机数发生器所产生的随机数用来控制对视频加扰单元220的四种加扰机制的激活。视频加扰单元220经由输入缓冲器310接收AU,所述输入缓冲器310从视频解密单元124接收所述AU。从这一缓冲器,AU被提供到分别实现对AU的重混排、插入、移除和替代的四个功能模块。然后将加扰AU输出到输出缓冲器330,由此加扰AU将被发送到硬件视频解码器130。在功能模块中产生与加扰有关的元数据。该加扰元数据描述已经应用到AU的操作(即,在加扰处理中如何对它们进行的修改)。这一加扰元数据输出到元数据缓冲器340。由此,将加扰元数据递送到视频解扰单元230,视频解扰单元230使用加扰元数据来准确地重构(解扰)未压缩的视频流。为了对AU进行插入和替代,需要提供附加的AU。这些附加AU存储在AU插入缓冲器222中。在本实施例中,所插入的AU是基本流中的其它AU的拷贝。
视频解扰单元230在像素域处理帧,并实现依赖于应用在视频加扰单元220处的加扰机制的若干解扰机制。这些解扰机制包括:帧重混排器;帧丢弃器;以及帧内插器。它们示出于图4中。帧输入缓冲器410从硬件视频解码器130接收解压缩加扰视频的帧。视频解扰单元230将来自该帧输入缓冲器410的帧和来自元数据缓冲器340的加扰元数据作为其输入。视频解扰单元适当地修改所述帧,以反转之前应用的压缩域加扰的效果。帧重混排撤销在视频加扰单元220中执行的AU重混排。帧移除撤销在视频加扰单元220中执行的AU插入。帧内插撤销在视频加扰单元220中执行的AU移除。内插根据近邻帧来重构丢失的帧(例如,使用运动内插的已知技术)。如此,所重构的帧可能与已经移除的AU中编码的帧不同。然而,假设差别很小,观看者并不能轻易对其察觉。
尽管四个操作中的任何操作都可以在视频加扰单元220处执行,但对视频进行解扰只需要三个功能单元。这是由于,视频加扰单元220处的AU替代可被看作帧移除和帧插入的合并。从而,可通过帧移除和真内插的组合来将其撤销。
如这里所使用的,“访问单元”(AU)意味着基本流的逻辑子结构。基本流是包含编码(即,压缩的)视频数据的二进制比特流。每个帧是相应访问单元的解码(解压缩)版本。
“压缩”视频数据意味着不包括适于在显示器上进行渲染的像素数据的视频表示。优选地是比原始像素数据更加紧凑的表示(根据需要用来表示视频的比特数)。压缩视频数据必须被解压,以便重构适于进行渲染的像素数据。在一些实施例中,使用基于块的运动补偿变换编码的压缩方法(比如本领域技术人员所熟悉的那些方法)来压缩视频。
现在描述详细的示例,其示出了如何使用H.264视频编解码器实现加扰和解扰操作。本领域技术人员将理解的是本发明不限于该编解码器的范围,并且通过理解以下公开的原理,可针对其它编解码器构造类似的示例。
以下描述的加扰方法取决于压缩域中的帧的类型。本领域技术人员熟悉在传统运动补偿编码方案中找到的压缩帧的通常类型。以下是对所述类型和它们的相关特性的简要概述。其示于图5中。
·内帧:(“I-帧”),这一类型的帧是在不参考任何过去或未来的帧的情况下编码的。I-帧的一个特殊类型是瞬时解码器刷新(IDR)帧。任何在IDR帧之后接收的帧都不能将在IDR帧之前的任何帧用作用于解码的参考帧。
·预测帧:(“P-帧”)参考过去的帧进行编码的帧。这一类型的帧还能被用作一个或多个后续解码帧的参考帧。
·双向预测帧:(“B-帧”)参考过去和/或将来的帧进行编码的帧。
能够在将在解码处理中用作参考帧的帧与将不会在解码处理器中用作参考帧的帧之间进行区分。在H.264的情况中,这一点大多数情况适用于B-帧,但偶尔也适用于P帧。我们能够在将用作对其它帧的编码的参考的B-帧(和P-帧)与将不会用作对其它帧的编码的参考的B-帧(和P-帧)之间进行区分。当需要时,为了简明,将前者称为“rB-帧”(相应的,“rP-帧”)而后者将被称为“nrB-帧”(相应的,“nrP-帧”)。
所述加扰方法使得从加扰机制得到的流与编码方案的句法保持一致。换言之,根据编解码器的定义,其保持为有效的编码比特流。这对于避免HW解码器中的误差来讲是期望的,并且从而解码器不需要修改。
加扰方法适用于压缩域,但在像素域是可逆的。执行所述加扰不需要对接收的帧进行解码——取而代之地,加扰操作于压缩视频流的更高级别的句法元素上。
图像顺序计数(POC)用于解码处理中,以便识别解码帧中的每一个的呈现(显示)顺序。由于使用了双向预测,解码帧顺序与显示顺序不同——针对B-帧的参考帧必须在B-帧自身之前被解码,即使B-帧出现在更早的呈现时刻也是如此。POC通常嵌入在编码帧的高级别句法中,并且用于解码处理的上一步骤中,以便根据帧的显示顺序恰当地对帧进行重排序。下文描述的加扰处理操纵多个帧的POC(可选地,除了其他修改之外)。
图6示出了通过重排序进行加扰。其原理是,通过改变嵌入在每个访问单元内的POC值来重新安排所述帧中的一些的呈现顺序。如果不进行补偿的话(在视频解扰单元230处),这将产生具有强烈抖动形式的视觉烦躁。视频内容中呈现的运动越多,所产生的烦躁也越多。相应的解扰处理对所述帧适当地重排序。一个限制适用于对参考帧进行编码的AU:如果经过重排序的AU用作参考,则将维持其参考索引,以使得在它们的解码处理中将其用作参考AU的AU被恰当地解码。
重混排过程开始于步骤610,其中视频加扰单元220检查随机控制单元240是否已经激活了重混排。如果是的话,则在步骤620中从输入缓冲器310读取下一个AU。接下来,在步骤630中,视频加扰单元220检查是否能够在不对AU进行附加修改的情况下改变POC。如果是的话,则方法进行到步骤660,并且POC值发生改变。如果在不对AU进行进一步适应的情况下不能改变POC,则所述方法进行到步骤640,并且加扰单元检查是否能够结合对AU的进一步适应改变POC。如果是的话,则方法进行到步骤650,并且执行对AU的必要附加适应。然后,所述方法继续进行到步骤660。在步骤660之后,在步骤670中将具有其修改的POC值的AU写入输出缓冲器330。在步骤610中,如果视频加扰单元220确定尚未激活重混排,则所述方法进行到步骤690。如果在步骤640中确定POC不能被改变(即使对AU进行附加适应),则所述方法也可以进行到步骤690。在步骤690中,视频加扰单元220检查是否由于在之前的AU上执行的加扰必须对POC进行更新。(对较早的AU的POC值进行的加扰可以对随后的AU的POC值具有连锁效果,即使这些随后的AU本身未被加扰也是如此)。在这种情况中,所述方法进行到步骤660,以更新POC值。否则,方法直接进行到步骤670,以便将AU写入到输出缓冲器330中。最后,在步骤680中,加扰元数据被写入到元数据缓冲器340中。针对每个访问单元重复所述过程。在最后的访问单元之后,重混排过程结束。
图7示出了通过AU插入进行加扰。其原理是,在压缩域中在存在的AU之间插入AU。如果所插入的AU的内容与邻近AU相对不相关,则其将产生强烈的视觉不连续,引起烦躁(如果不通过适当的解扰来移除的话)。内容中存在的运动越少,将产生的烦躁就越多。解扰处理包括移除附加的插入帧。优选地,所插入的AU将不会被轻易识别(对恶意用户来讲)。理想地,插入的AU将在每个插入处有所不同。一个限制是,所插入的AU将不会被用作用于对流中的原始编码帧进行解码的参考。如果将使用插入的帧作为参考帧对原始帧进行解码,则其解码处理将被破坏。为了在本实施例中避免这一情况,所述系统通过只使用流中存在的nrB或nrP AU来确保所插入的帧不进入参考缓冲器。作为备选或补充,所述系统可插入AU的连续集合,其解码是自我独立的。然而,在后一情况中,这只能紧接在IDR帧之前执行,下面将进行说明。
输入流结构是:
IDR P P P P P P B P B P IDR P B P B。
在将自我独立的图像群组(GOP)[IDR P P P]在第二IDR帧之前插入之后,输出流结构是:
IDR P P P P P P B P B P[IDR P P P]IDR P B P B。
由于GOP是紧接在IDR帧之前插入的,任何随后的帧都不会将所插入的GOP中的帧当做参考帧。为了使对所插入的GOP的解码是自我独立的,所插入的GOP本身同样以IDR帧开始。
参见图7,在步骤710中,插入处理开始,并且从输入缓冲器310读取AU。接下来,在步骤715中,视频加扰单元220检查随机控制单元240是否已经激活了AU插入。如果已经激活了AU插入,则所述方法进行到步骤720,并且视频加扰单元220检查是否能够在不对基本流进行附加适应的情况下插入AU。如果是的话,则所述方法进行到步骤735,并且从AU插入缓冲器222读取将要插入的AU。在步骤740中更新所插入的AU的POC。在此之后,所述方法进行到步骤760,并且加扰单元检查由于在之前的AU上执行的加扰是否必须对POC进行更新。如果是的话,则在步骤765中更新POC,并且所述方法进行到步骤745。如果否的话,则所述方法直接进行到步骤745。在步骤745中,如果已经插入了AU,则将所插入的AU写入到输出缓冲器330中。所述方法然后进行到步骤750,其中将原始AU(在步骤710中读取自输入缓冲器)写入到输出缓冲器330中。最终,在步骤755中,将加扰元数据写入到元数据缓冲器340中。在步骤715中,如果加扰单元确定尚未激活AU插入,则所述方法进行到步骤760。在步骤720中,如果加扰单元220确定不能在不对基本流进行附加适应的情况下插入AU,则所述方法进行到步骤725。在步骤725中,视频加扰单元220检查是否能够结合对比特流的附加适应插入AU。如果是的话,则在步骤730中执行必要的适应,并且所述方法进行到步骤735。如果即使在对流进行附加适应的情况下也不能插入AU,则所述方法从步骤725进行到步骤760。针对序列中的每个AU执行这一过程。当已经处理了所有AU时,所述过程结束。
加扰还能够包括移除AU,这是插入AU的逆,并且实现起来较直接。从输入缓冲器310读取AU并拷贝到输出缓冲器330(除非它们将被移除)。也就是说,只将未被移除的AU写入输出缓冲器330。一般地,不需要改变每个AU的POC值,除非作为应用到视频中的较早AU的加扰的结果需要对其进行更新。由于降低了内容的帧速率,所以产生了视觉烦躁。解扰处理包括借助于基于运动的帧内插在像素域中重构对应于丢失的AU的帧。由于通过内插进行的重构是不完美的,所以最终的进行渲染可能包含一些与重新内插处理有关的视觉人为痕迹。优选地,不会移除将用作用于对其它帧进行解码的参考帧的AU。也就是说,只移除nrB或nrP AU。
图8示出了通过AU替代进行加扰。其原理是,合并AU移除和AU插入。参见图8,当AU替代加扰处理开始时,在步骤805中,从输入缓冲器310读取AU。接下来,在步骤810中,视频加扰单元220检查是否已经由随机控制单元240激活了AU替代。如果是的话,则所述方法进行到步骤820。在步骤820中,视频加扰单元220检查是否能够在不对所述流进行附加适应的情况下替代该AU。如果是的话,所述方法进行到步骤835,并且从AU插入缓冲器222读取将要在当前AU的位置插入的AU。所述方法然后进行到步骤840。这里,对所插入的帧AU的POC进行更新。接下来,在步骤845中,将(插入的)AU写入输出缓冲器330中。最后,在步骤850中,将相应的加扰元数据写入元数据缓冲器340中。如果加扰单元在步骤820中确定不能在不对所述流进行附加适应的情况下替代AU,则所述方法进行到步骤825,并且加扰单元检查是否能够结合附加适应来替代AU。如果是的话,则所述方法进行到步骤830,并且执行必要的附加适应。在此之后,与之前一样,所述方法进行到步骤835。在步骤810中,如果尚未激活AU替代,则所述方法进行到步骤855,并且视频加扰单元220检查由于在之前的AU上执行的加扰是否需要对POC进行更新。如果是的话,则所述方法进行到步骤840以及步骤845。如果否的话,所述方法直接进行到步骤845,其中将(原始)AU写入输出缓冲器。在步骤825中,如果即使结合对所述流的附加适应也不能替代当前AU,则所述方法同样进行到步骤855。在针对每个AU执行了所述处理之后,所述处理结束。
图9示出了解扰处理。当解扰开始时,在步骤910中,视频解扰单元230从元数据缓冲器340读取加扰元数据。接下来,在步骤915中,视频解扰单元230(使用元数据)检查视频加扰单元220是否执行了POC重混排。如果POC重混排已经发生,则所述方法进行到步骤920,并且视频解扰单元230从帧输入缓冲器410读取正确的帧。所述方法从这里进行到步骤960,并且将所述帧写入到帧输出缓冲器420中。如果不存在任何POC重混排,则所述方法进行到步骤925,并且解扰单元检查是否已经插入了AU。如果是的话,所述方法进行到步骤930,丢弃帧输入缓冲器410中的下一帧。如果尚未插入任何AU,则所述方法取而代之地进行到步骤935,并且视频解扰单元230检查是否已经移除了AU。如果是的话,则在步骤940中,通过内插来重构丢失的帧。所述方法从这里进行到步骤960,并且将内插的帧写入到帧输出缓冲器420中。如果尚未移除AU,则所述方法取而代之地进行到步骤945,并且视频解扰单元230检查是否已经取代了AU。如果是的话,则所述方法进行到步骤950。丢弃帧输入缓冲器410中的下一帧,并且通过内插来重构丢失的帧。再次,所述方法进行到步骤960,并且将内插的帧写入到帧输出缓冲器420中。如果未有过任何AU替代,则所述方法从步骤945进行到步骤955。这意味着不在视频的这一部分上执行加扰。从帧输入缓冲器410读取下一帧,并且所述方法直接进行到步骤960,其中将该帧写入帧输出缓冲器420中。在所有帧在步骤930中被丢弃或在步骤960中被写入到输出缓冲器中之后,所述处理结束。
现在针对根据H.264标准编码的压缩视频对加扰处理的特定实现进行详细描述。具体地,给出关于如何针对H.264编码的流实现通过重混排的加扰和通过帧插入的加扰的示例。如果使用了没有在这里另外定义的变量,则假定该变量定义于H.264标准中并且存在于压缩视频比特流中。H.264标准定义于ITU-T推荐H.264“Advanced video coding forgeneric audiovisual services”中。这与ISO/IEC 14496-10“Information technology--Coding of audio-visual objects--Part 10:Advanced Video Coding”中定义的称为MPEG-4AVC的标准相同。在任何不清楚的情况中,对标准的引用应该认为是对本发明的优先权日时有效力的标准的版本、修订或版次的引用。然而,这些标准的后续版本通常与较早的版本向后兼容——后续版本对标准进行扩展,但保持较早版本的规范元素。因此,预期不会出现任何不清楚,且符合所述标准的任何未来版本的比特流同样符合在优先权日时有效力的版本。
一些预备知识对于理解如何实现加扰的细节是有帮助的。
图像顺序计数(POC)用于H.264解码处理中,用来识别每个解码帧的显示顺序(即,呈现顺序)。尤其是对于双向预测,帧被解码的顺序可以与对帧进行显示的顺序不同。用来表明对解码的帧的重混排的一种方式是修改编码的流内的POC。每个AU的POC要么在流中显式地编码(模式0)要么在解码处理期间隐式地确定(模式1和模式2)。由于加扰将改变流内的POC,所以如果解码是隐式的,则需要从隐式模式(模式1和模式2)之一转换到显式模式(模式0)。对于如何在H.264解码处理期间获取POC的进一步细节,读者可参见文件“H.264/AVC Frame and picture management”(Iain G.Richardson,2004年1月),该文件以下链接在线获取:www4.rgu.ac.uk/files/avc_picmanagement_draft1.pdf。这一信息是本领域技术人员所熟知的。
存在两种解码模式,其中由硬件视频解码器130执行的运动补偿步骤将取决于POC值。存在“时间直接预测”和“加权预测”模式。由于POC不只是用来确定呈现顺序,因此,在这些模式中,必须有视频加扰单元220检测它们的使用,以便针对POC的修改对它们加以考虑。
H.264基线简档是其中不存在任何双向预测的特定简档。在该情况中,编码视频流排他地包括I-帧和P-帧。解码顺序通常与显示顺序相同。从而,对于基线简档流来讲,恶意用户很容易检测到并撤销对解码帧的显示顺序的任何重混排。用来克服这一问题的一种方式是将基线简档流转换成主简档流。这可只通过改变流的高级别语义来改变——例如,修改报头信息。从基线简档转换到主简档不必对视频进行解码和重新编码。
现在描述加扰处理的实现。为了清楚简明,以下说明并不涉及由随机控制模块对加扰的激活和去激活。
如果POC信令是隐式的(模式1或模式2),则对压缩视频比特流进行修改,以使得信令变为显式的(模式0)。这可以分两步来执行。首先,在两个方面修改sequence_parameter_set数据结构:
pic_order_cnt_type=0
log2_max_pic_order_cnt_lsb_minus4=4
sequence_parameter_set(SPS)是H.264标准中定义的报头数据结构。为了读者方便,在下文的附录中对其进行了复述。该报头中的参数限定如何对流中的后续AU进行编码(直到sequence_parameter_set再次出现为止)。注意到,log2_max_pic_order_cnt_lsb_minus4的值位于0到12(含)的范围中。
其次,对于每个AU,修改slice_header数据结构,以在pic_order_cnt_lsb中指派显式的POC值。slice_header是H.264中定义的报头数据结构,其描述“片段”是如何被编码的。通常,针对每个AU存在一个片段,但是也能够将AU作为多个片段进行编码,其中每个片段表示视频帧的一部分。
为了执行加扰,一个接一个AU的对压缩视频流进行解析。加扰方法在相同类型的连续AU的群组上进行操作。每个这样的群组在这里被标示为“edit_gop”。edit_gop内的AU的POC值被操纵,且将帧插入edit_gop内。限制对相同类型的连续AU的群组的POC操纵有助于避免在解码处理中发生AU参考错误的参考AU的情况。在本实施例中,每个edit_gop的尺寸受限,以便包含最多8个连续的AU。这用来限制可通过加扰和解扰引入的处理延迟。如果在压缩流中连续出现多于8个相同类型的AU,则将它们再细分成若干个相同类型的连续edit_gop。
以下是一个示例。考虑以下流结构:
I nrB nrB P nrB nrB P P P B B
该流将被分成6个edit_gop:
Edit_gop_1:I
Edit_gop_2:nrB nrB
Edit_gop_3:P
Edit_gop_4:nrB nrB
Edit_gop_5:P P P
Edit_gop_6:B B
以下变量用于加扰处理的过程中:
·Edit_gop_type:指示edit_gop内的连续AU中的AU的类型(例如I、rP、nrP、rB、nrB)。
·Edit_gop_size:构成edit_gop的相同类型的连续AU的数量。
·Edit_gop_count:目前为止已处理的edit_gop的数量。这用于帧插入的情况中,以便刷新正在插入流中的nrB帧的来源(origin)。换言之,在已经处理了规定数量的edit_gop之后,来自压缩视频流的新的nrB AU将被拷贝到AU插入缓冲器222中。
·Get_nrb_to_insert:布尔变量(即,二进制变量,其能够具有值“真”或值“伪”)。当值为真时,这指示应将nrB帧拷贝到AU插入缓冲器222,以供随后用作插入的AU。
·First_AU_in_edit_gop:布尔变量,当为真时,指示当前处理的AU是edit_gop中的第一个AU。
·nextAU_type:指示当前正在处理的AU之后的流中的AU的类型。
·Direct_spatial_mv_pred_flag:流中存在的H.264参数,其定义运动预测中使用的直接预测的类型。对于其它解释,还可参见:http://wiki.multimedia.cx/index.php?title=Motion_Prediction。
·Nr_gop:指由非参考AU构成的edit_gop。
·Sub_edit_gop:edit_gop的子集,其中排除了edit_gop的第一个AU和最后一个AU(在一些情况中,优选地,不对分别位于edit_gop的开始和结尾处的AU进行加扰)。
·POC_list:构成sub_edit_gop的AU的所有POC值的列表。
·New_POC_list:其包含对POC列表的重混排。
·Poc_org:在POC_list内所参考的,AU的原始POC值。
·Poc_new:在New_POC_list内所参考的,AU的重混排POC值。
·Org_flag:指示当前AU是否位于原始流中的布尔值。其用来将所插入的AU与输出的加扰流中的原始AU进行区分。
图10是根据本实施例的示出了由视频加扰单元220执行的加扰处理的前几个阶段的伪码流程图。首先,在步骤1010中,对执行加扰所需的变量进行初始化。然后,在步骤1020中,使用经由输入缓冲器310按顺序接收的AU构造edit_gop。为了准备帧插入,将每个AU的POC值乘以2。所检测到的第一个nrB AU保存到AU插入缓冲器222中,以用于以后用作插入帧。对edit_gop的构造继续进行,直到达到最大尺寸(8个AU)或从输入缓冲器310获取不同类型的AU为止。
图11是示出了通过重混排对edit_gop进行加扰的伪码流程图。如果edit_gop只包含一个AU,则其不能被重混排。类似地,如果edit_gop中的所有AU使用时间直接预测(Direct_spatial_mv_pred_flag==1),则不执行任何重混排。如果edit_gop包括nrB或nrP帧(即,如果edit_gop是nr_gop),则可对edit_gop中的所有AU进行重混排。否则,将edit_gop的第一帧和最后一帧从重混排排除。在后一情况中,edit_gop必须包含多于3帧,以使得重混排成为可能。通过使new_POC_list成为POC_list中的POC值的随机排列来实现重混排。换言之,以随机顺序将POC值的原始集合重新指派到各个AU。将针对edit_gop中的每个AU的poc_org和poc_new的值写入元数据缓冲器340。针对每个AU,Org_flag被设为真且也将该变量写入元数据缓冲器340。
图12是示出了通过帧插入对edit_gop进行加扰伪码流程图。在步骤1210中执行帧插入,并且在步骤1220中,加扰单元为下一edit_gop做准备。
在步骤1210中,视频加扰单元220在AU的序列中随机选择将插入附加帧的位置。在每个所选位置处,将存储在AU插入缓冲器222中的nrB AU插入到序列中。备选地,将被插入的AU能够自动生成——也就是说,可以插入人造的AU,而不是插入来自相同流的另一AU的拷贝。使用正确的POC值对所插入的AU的POC值进行更新。将针对每个插入的AU的poc_org和poc_new的值写入元数据缓冲器340。针对每个插入的AU,Org_flag被设为伪且也将该变量写入元数据缓冲器340。
在步骤1220中,将edit_gop写入输出缓冲器330。视频加扰单元220检查是否将要处理更多的AU。如果否的话,则处理终结。如果仍将处理更多的AU,则对在加扰时使用的变量重新初始化。如果自上次刷新AU插入缓冲器的内容以来已经处理了20个edit_gop,则将flag get_nrB_to_insert设为真。所述处理然后返回到图10中的步骤1020。
在某些情况中,应采用特殊措施,以避免干扰对加扰压缩视频的解码。
在第一示例中,当处理加入了时间预测的流时采用特殊措施。H.264参数direct_spatial_mv_pred_flag按如下来规定在解码处理中使用的用来导出针对相互预测的运动向量(MV)和参考索引的方法:
·如果direct_spatial_mv_pred_flag等于1,则针对B_Skip、B_Direct_16x16和B_Direct_8x8的亮度(luma)运动向量的导出处理应使用空间直接模式预测。在这种情况中,直接预测是空间的,且不依赖于AU POC值。这意味着POC重混排是可能的而且帧插入是可能的。
·其它情况——即,如果direct_spatial_mv_pred_flag等于0——当宏块(MB)类型是以下中的一个时在计算MV值的处理中涉及两个参考列表(List0和List1)中的第一参考帧的POC值和B帧的POC值:B_Skip、B_Direct_16x16和B_Direct_8x8。(参考列表是按照H.264标准的规定用于解码处理的参考帧的列表。)在这种情况中,直接预测是暂时的且运动向量计算中涉及AU POC值。这意味着在某些情况中POC重混排是可能的,并且在所有POC值在最初乘以2的情况下,帧插入是可能的。
具体地,对于时间直接预测的情况(即,当direct_spatial_mv_pred_flag等于0时)中的POC重混排:
·针对由nrB帧组成的nr_gop,不应对POC值进行重混排;
·针对由B帧组成的r_gop,不应对POC值进行重混排;
·针对由I/IDR/P帧组成的r_gop,在原理上,POC修改算法仍可应用到edit_gop中的一些AU,这是由于在解码器中只有edit_gop中的第一个和最后一个AU可在计算MV值的处理中涉及。然而,direct_spatial_mv_pred_flag的值存在于slice_header中,从而其能够针对edit_gop内的每个片段发生改变。在原理上,能够对这种edit_gop中的POC值进行重混排,但这将需要针对每个片段检查direct_spatial_mv_pred_flag的值并且恰当地计算POC的重混排。因此,为了避免将过度延迟引入到系统中,如果edit_gop中的任何片段都具有等于1的direct_spatial_mv_pred_flag,则当前方法不对POC值进行重混排。
针对帧插入,不管direct_spatial_mv_pred_flag的值是多少,应用单一过程。针对direct_spatial_mv_pred_flag的任何值以及针对任何类型的edit_gop,将每个帧的POC值乘以2,这使得加扰单元220能够在不影响解码器中的运动向量计算的情况下插入帧。
在第二示例中,当处理加入了加权预测的流时需要采用特殊措施。H.264标准中定义了加权预测的三种可能模式。weighted_bipred_idc的值应为0、1或2。这些模式定义如下:
·weighted_bipred_idc等于0规定应向B片段片段应用默认加权预测。
·weighted_bipred_idc等于1规定应向B片段应用显式加权预测。
·weighted_bipred_idc等于2规定应向B片段应用隐式加权预测。
在前两种情况(0和1)中,预测不依赖于其它帧的POC值且能够执行POC重混排和帧插入。
针对第三种情况中的POC-重混排,当weighted_bipred_idc等于2时,在不进行附加适应的情况下改变POC值将引起图像被不正确地解码。为了避免这一情况,对比特流执行附加适应。具体地,对压缩流的报头信息进行修改,其中将加权预测模式从隐式模式转换为显式模式。这通过以下步骤来完成:
·通过将weighted_bipred_flag设为1来修改图像参数集(PPS),
·针对每个帧计算weighted_table,并将其插入流中,
·修改slice_header,并指示其将针对加权预测参考哪个计算的weighted_table。
针对帧插入,不管weighted_bipred_idc的值是多少,应用单一过程。针对weighted_bipred_idc的任何值以及针对任何类型的edit_gop,将每个帧的POC值乘以2,这使得加扰单元220能够在不影响解码的情况下插入帧。
优选地,当处理基线简档流时也应采取特殊措施。为了对基线简档流进行加扰,加扰单元对所述流的高级别句法进行修改,以使得其变为有效的主简档流。这一修改包括以下步骤:
·修改SPS,以便将基线简档流掩饰为主简档流;以及
·将一些P帧改变成B帧。
在基线简档中,不存在任何B-帧,并且一般地,POC将涉及递增方式。这与主简档中的情况不同,主简档中的情况中,由于针对AU的解码和帧的呈现使用不同的排序,所以POC在帧之间不是递增的。结果,在基线简档流的情况中,如果加扰单元只修改POC,则恶意用户容易检测到这一点,并撤销所述加扰。可在不进行重新编码并且只进行高级别句法修改的情况下,将基线简档流中的P-帧转换为看起来像主简档流中的B-帧一样。一旦在这种方式中已经适应了流的句法,则可像上文已经描述的一样应用加扰处理。可对流中的AU的POC值进行修改,使得恶意用户仅通过获得对硬件视频解码器130的输出的接入便能够识别并反转加扰处理的可能性降低。
为了使得能够在进行渲染之前在视频解扰单元230中对解码的流进行正确解扰,在加扰处理(在上文的详细示例中,POC-重混排或帧插入)期间生成元数据的集合。对于进入到输出缓冲器330中的每个AU,视频加扰单元220提供以下相关联的元数据:
·poc_org:整数,其被设为原始POC值(针对现有AU)或被设为-1(针对插入的帧)
·poc_new:整数,其是在应用加扰处理之后的修改的POC值
·org_flag:布尔值(由整数表示)。当其被设为0时,标示针对进行渲染应被丢弃的插入的帧。当设为1时,其标示应被进行渲染的原始帧。
由于解扰处理只是简单地反转上文已详细描述的加扰处理,所以将不会详细描述解扰处理。在此阶段,本领域技术人员将容易理解如何实现相应的解扰处理。
前述描述关注的是用来实现加扰的流级别的修改。在一些情况中,还需要系统级别的修改。例如,在一些已知的视频解码器中,到解码器的输入除了AU之外还包括复合时间戳(CTS)。复合时间戳是指示将在显示器上呈现解码帧的时刻的时间参考。(在MPEG-2系统中,其也被称为呈现时间戳:PTS。)CTS通常提供于对所述流进行封装的系统层。在理想系统中,CTS和POC在时间上相关联。如果解码器除了AU之外使用CTS来解码视频,则在加扰处理中应修改CTS,以使得其与每个AU的POC值一致。这将避免解码器中由于CTS和POC值的不一致而导致的误差。
在这种情况中,使用以下两个变量(每个都是long int类型的变量)来扩展针对每个AU的加扰元数据,以确保恰当地解扰:
·cts_org:原始CTS值,或-1(针对插入的帧)
·cts_new:在应用了加扰处理后的修改的CTS值。
如上所述,对上文中加扰处理的描述没有考虑对随机控制单元240(其在随机的时刻激活和去激活加扰)的使用。然而,当使用随机控制单元240时,加扰的关键细节是相同的。当加扰被去激活时,针对给定AU,poc_new值将等于poc_org值,以及org_flag将等于1。
现在将参照图13的流程图描述由随机控制单元240执行的示例性方法。随机控制单元可操作为随机地激活和去激活所述加扰。图13示出了针对一种加扰方法的激活/去激活处理。为每种加扰方法复制该处理。所述方法开始,以及随机控制单元240在0到255之间(排除0和255)随机地选择8-比特数N。该8-比特数由随机控制单元240的随机数发生器242生成。接下来,在步骤1315中,所述单元启动具有粒度T0的定时器T。在步骤1320中,随机控制单元读取数N的最低有效位b。在步骤1325中,其检查b是否等于1。如果是的话,则在步骤1330中,激活加扰。如果否(即,b等于0)的话,则在步骤1335中,去激活加扰。在任一情况中,所述方法然后进行到步骤1340,并且在进行到步骤1345之前等待T0秒。在这一步骤中,将T0添加到定时器变量T。随机控制单元然后在步骤1350中检查T是否大于255倍的T0。如果是的话,则所述方法移动到步骤1310,并且随机选择新的数N。如果否的话,则所述方法移动到步骤1355,并且现有的数N向右移位一个比特。所述方法从步骤1355返回到步骤1320。
将T0选为具有秒的量级,从而可在加扰再次被去激活之前以有意义的方式来应用加扰。可选地,还可对T0随机化,以使得恶意用户更难于检测加扰的激活和去激活。为了相同的目标,可以可选地从0到255之间的包含不多于两个相邻相同比特(通过N的二进制形式)的整数的子集选择数N。例如,0b00101101是允许的,而0b11100100则是不允许的。这有助于避免加扰设备在很长的连续时段期间保持激活或去激活。
虽然本发明已经详细示出并描述了附图和前述描述,但这种示出和描述将被认为是说明性的或示例性的,而不是限制性的;本发明并不限于所公开的实施例。
例如,在上述实施例中,视频播放器的大多数功能单元被实现为运行在通用处理器上的软件,但视频解码由分离的硬件处理器执行。这不是必要的。例如,可在硬件或软件中实现诸如加扰单元和解扰单元的功能单元。类似地,视频解码器是定制的硬件视频处理器这一点也不是必要的。在其它实施例中,其可由运行在通用处理器(其与运行视频播放器应用的通用处理器相同或不同)上的软件来实现。
在上述实施例中,当由AU-插入执行加扰时,所插入的AU是相同视频流中的另一AU的拷贝。另一可能性是合成人工AU。例如,加扰单元能够生成表示具有随机运动向量并且不具有任何纹理(即,运动补偿帧差信号是零)的nrB帧的AU。可以基于流的高级别特性(比如宽度、高度等)自动生成这种帧。由于其只是使用运动向量编码的,所以在已经解码之后,所合成的帧的每个块将是任意参考帧的一部分的(随机选择的)拷贝。这种方法能够提供与简单地插入整个AU的拷贝相比更大的视觉烦躁。
所公开的实施例的其它变化能够被理解,并且能够由本领域技术人员通过对附图、公开和所附权利要求的学习在实践所要求保护的发明时实现。在权利要求中,词语“包括”不排除其它元素或步骤的存在,并且“一”、“一个”不排除多个。单一处理器或其它单元可实现权利要求中所述的若干项目的功能。虽然在不同的从属权利要求中描述了某些措施,但这并不意味着不能使用这些措施的组合来获利。计算机程序可存储和/或分布在适当介质上,比如与其它硬件一起提供或作为其它硬件的一部分提供的光存储介质或固态介质,但还可通过其它形式分布,比如经由因特网或其它有线或无线电信系统。权利要求中的任何参考符号不应被理解为限制范围。
附录–H.264数据结构
如前文所述,在具体示例的上下文中,通过在若干方面修改比特流来对H.264压缩视频流进行加扰。为了完整性和方便参照,下面重复对H.264标准的相关数据结构的定义。
每个表中的右侧栏指示每个数据字段的尺寸。括号中的数字是尺寸,单位为比特;“v”指示尺寸可变的字段。在H.264标准中(第7.2节)定义了以下类型:
·u(n):使用n个比特的无符号整数。当n在句法表中是“v”时,比特数根据其它句法元素的值发生变化。针对这一描述符的解析处理由函数read_bits(n)的返回值规定,其被解译为无符号整数的二进制表示(首先写入最高有效位)。
·ue(v):无符号整数Exp-Golomb-coded句法元素,先是左边的比特。
·se(v):有符号整数Exp-Golomb-coded句法元素,先是左边的比特。
序列参数集(SPS)
在每个视频流中至少出现一次SPS。然而,与每视频一次相比,SPS可以更频繁地出现。具体地,对于广播视频,终端用户能够在任何时刻加入会话;或在自适应定流的情况中,序列参数能够根据网络状况发生改变。SPS中找到的参数适用于所有后续的AU,直到在流中找到新的SPS为止。
图像参数集(PPS)
在每个视频流中至少出现一次PPS。然而,与每视频一次相比,PPS可以更频繁地出现。具体地,对于广播视频,终端用户能够在任何时刻加入会话;或在自适应定流的情况中,序列参数能够根据网络状况发生改变。PPS中找到的参数适用于所有后续的AU,直到在流中找到新的PPS为止。SPS和PPS通常在流中是先后插入的。
片段报头句法
通常每AU存在一个片段,该片段表示视频帧。然而,标准并不阻止编码器每AU创建许多片段,每个片段表示视频帧的一部分。对于每个片段,在比特流中存在片段报头。

Claims (14)

1.一种用于对压缩视频进行解码的设备,所述设备包括:
视频加扰单元,适于接收压缩视频并对其进行加扰,以产生加扰压缩视频,其中在所述压缩视频的访问单元上执行一个或多个操作,所述一个或多个操作包括对访问单元重排序,插入一个或多个访问单元,移除一个或多个访问单元和替代一个或多个访问单元;
视频解码器,布置为接收来自加扰单元的所述加扰压缩视频并适于对其进行解码,以产生加扰解压缩视频;以及
视频解扰单元,布置为接收来自视频解码器的所述加扰解压缩视频并适于对其进行解扰,以产生解扰解压缩视频。
2.根据权利要求1所述的设备,其中视频加扰单元适于通过以下方式对所述压缩视频进行加扰:
不阻止视频解码器对视频进行解码;
在解码后修改所述加扰解压缩视频的视觉内容;以及
所述视频加扰单元是通过视频解扰单元可逆的,使得所述解扰解压缩视频与在所述压缩视频将在不进行加扰的情况下由视频解码器解码的条件下产生的视频相同或实质相同。
3.根据权利要求1所述的设备,其中:
视频加扰单元适于产生描述由视频加扰单元执行的加扰操作的加扰元数据;以及
视频解扰单元布置为接收来自视频加扰单元的所述加扰元数据,并且适于使用所述加扰元数据来对从视频解码器接收的加扰解压缩视频进行解扰。
4.根据权利要求1所述的设备,其中每个帧是相应访问单元的解码版本。
5.根据权利要求1所述的设备,其中控制视频加扰单元向视频的第一部分施加加扰而不对视频的第二部分施加加扰。
6.根据权利要求5所述的设备,其中随机地或伪随机地选择所述第一部分和第二部分。
7.根据权利要求1所述的设备,其中视频解码器是硬件视频解码器。
8.根据权利要求1所述的设备,其中压缩视频和视频解码器符合预定的视频编码标准;以及视频加扰单元适于以使得按照加扰压缩视频符合相同的视频编码标准的方式来对压缩视频进行加扰。
9.根据权利要求8所述的设备,其中视频解码器和压缩视频符合H.264标准,并且所述加扰包括修改H.264压缩视频中的多个访问单元中的图像顺序计数。
10.根据权利要求9所述的设备,其中视频加扰单元适于:
检测将图像顺序计数隐式地编码在压缩视频中,以及作为响应:
修改压缩视频的报头信息,以便表明对所述图像顺序计数进行显式编码;以及
在压缩视频的每个访问单元中指派显式的图像顺序计数值。
11.根据权利要求9所述的设备,其中视频加扰单元适于在压缩视频中检测要求视频解码器使用图像顺序计数来对一个或多个访问单元进行解码的编码模式,并且作为响应:
禁用所述加扰;或
修改所述压缩视频,使得视频解码器不需要使用图像顺序计数来对一个或多个访问单元进行解码。
12.根据权利要求10所述的设备,其中视频加扰单元适于:
检测所述压缩视频是根据H.264标准的基线简档编码的,并且作为响应,
修改所述压缩视频,以便将所述压缩视频转换到另一H.264简档。
13.一种对压缩视频进行解码的方法,其由根据权利要求1所述的用于对压缩视频进行解码的设备实施,包括:
对压缩视频进行加扰,以产生加扰压缩视频;
将所述加扰压缩视频递送到视频解码器,用于对所述加扰压缩视频进行解码,以产生加扰解压缩视频;
从视频解码器接收所述加扰解压缩视频;以及
对所述加扰解压缩视频进行解扰,以产生解扰解压缩视频。
14.一种存储计算机程序的非瞬时计算机可读介质,所述计算机程序适于当在计算机上运行时执行权利要求13的所有步骤。
CN201410764391.4A 2013-12-11 2014-12-11 用于对压缩视频进行解码的设备和方法 Active CN104717553B (zh)

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
EP13290312.1 2013-12-11
EP13290312.1A EP2884748B1 (en) 2013-12-11 2013-12-11 Apparatus and method for decoding compressed video

Publications (2)

Publication Number Publication Date
CN104717553A CN104717553A (zh) 2015-06-17
CN104717553B true CN104717553B (zh) 2018-09-25

Family

ID=49918495

Family Applications (1)

Application Number Title Priority Date Filing Date
CN201410764391.4A Active CN104717553B (zh) 2013-12-11 2014-12-11 用于对压缩视频进行解码的设备和方法

Country Status (5)

Country Link
US (1) US9781451B2 (zh)
EP (1) EP2884748B1 (zh)
CN (1) CN104717553B (zh)
ES (1) ES2611160T3 (zh)
PL (1) PL2884748T3 (zh)

Families Citing this family (10)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN105578265B (zh) * 2015-12-10 2019-03-05 杭州当虹科技有限公司 一种基于h264、h265视频分析的时间戳补偿或修正的方法
FR3050090B1 (fr) * 2016-04-08 2018-03-23 Squadeo Extraction de flux video
CN108206930A (zh) * 2016-12-16 2018-06-26 杭州海康威视数字技术股份有限公司 基于隐私遮蔽显示图像的方法及装置
US10841621B2 (en) * 2017-03-01 2020-11-17 Wyse Technology L.L.C. Fault recovery of video bitstream in remote sessions
CN109391846B (zh) 2017-08-07 2020-09-01 浙江宇视科技有限公司 一种自适应模式选择的视频加扰方法及装置
EP3467697A1 (en) 2017-10-06 2019-04-10 Nagravision S.A. Masking technique
EP3468207A1 (en) 2017-10-06 2019-04-10 Nagravision S.A. Masking technique
WO2019068353A1 (en) 2017-10-06 2019-04-11 Nagravision Sa MASKING TECHNIQUE
US11356698B2 (en) 2019-12-30 2022-06-07 Tencent America LLC Method for parameter set reference constraints in coded video stream
CN112765027B (zh) * 2021-01-22 2022-05-17 北京航空航天大学 一种检测应用程序执行过程中冗余零的方法

Citations (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US6956948B1 (en) * 1999-09-22 2005-10-18 Samsung Electronics Co., Ltd. Apparatus and method for generating multiple scrambling codes in asynchronous mobile communication system
CN102883167A (zh) * 2012-09-19 2013-01-16 旗瀚科技有限公司 一种视频图像数据处理方法及系统

Family Cites Families (12)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP4083302B2 (ja) * 1998-08-12 2008-04-30 株式会社東芝 動画像スクランブル/デスクランブル装置
FR2835141B1 (fr) * 2002-01-18 2004-02-20 Daniel Lecomte Dispositif pour securiser la transmission, l'enregistrement et la visualisation de programmes audiovisuels
US20030204718A1 (en) * 2002-04-29 2003-10-30 The Boeing Company Architecture containing embedded compression and encryption algorithms within a data file
AU2003243217A1 (en) * 2002-05-21 2003-12-31 Thomson Licensing S.A. Key transport tamper protection
FR2854530B1 (fr) * 2003-05-02 2005-07-22 Medialive Procede et dispositif pour securiser la transmission, l'enregistrement et la visualisation de flux empaquetes audiovisuels numeriques
CN101286678A (zh) * 2007-04-10 2008-10-15 桂林吉星电子等平衡动力有限公司 嵌套式永磁同步电机伺服系统及其控制运行方法
CN101821973B (zh) * 2007-06-25 2014-03-12 熵敏通讯公司 用于多通道、多流、复用的传输流处理的多格式流再复用器
KR100973657B1 (ko) * 2007-11-01 2010-08-02 경희대학교 산학협력단 디블록킹 필터링을 포함하는 코덱 사이의 트랜스코딩 방법 및 장치
EP2659676A4 (en) * 2010-12-27 2018-01-03 Telefonaktiebolaget LM Ericsson (publ) Method and arrangement for processing of encoded video
US9143306B2 (en) * 2011-10-12 2015-09-22 Nxp B.V. Device and method for encoding bits to symbols for a communication system
US9332269B2 (en) * 2012-06-27 2016-05-03 Broadcom Corporation Slice overhead coding
US10182038B2 (en) * 2013-07-29 2019-01-15 Mobitv, Inc. Efficient common storage of partially encrypted content

Patent Citations (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US6956948B1 (en) * 1999-09-22 2005-10-18 Samsung Electronics Co., Ltd. Apparatus and method for generating multiple scrambling codes in asynchronous mobile communication system
CN102883167A (zh) * 2012-09-19 2013-01-16 旗瀚科技有限公司 一种视频图像数据处理方法及系统

Also Published As

Publication number Publication date
CN104717553A (zh) 2015-06-17
US9781451B2 (en) 2017-10-03
ES2611160T3 (es) 2017-05-05
EP2884748A1 (en) 2015-06-17
PL2884748T3 (pl) 2017-05-31
US20150163520A1 (en) 2015-06-11
EP2884748B1 (en) 2016-10-19

Similar Documents

Publication Publication Date Title
CN104717553B (zh) 用于对压缩视频进行解码的设备和方法
US8995711B2 (en) Efficient watermarking approaches of compressed media
JP4564753B2 (ja) ビットストリームの変更方法及び装置
CN102804766B (zh) 使用可变块大小参数的局部加密
JP7418533B2 (ja) 独立的に符号化されたタイルを組み込む基本ビットストリームを保護するためのシステムおよび方法
JPH11284843A (ja) ウォ―タマ―クをディジタル画像シ―ケンスのビットストリ―ム表現に組み込むための方法及び装置
CN114930835A (zh) 变换系数为水印提供嵌入式信令的用途
US20180302690A1 (en) A system for inserting a mark into a video content
US20140105392A1 (en) Method for selectively scrambling bit-streams
US10200692B2 (en) Compressed domain data channel for watermarking, scrambling and steganography
US10848777B2 (en) Interleaved watermarking
JP7342261B2 (ja) 符号化されたビデオビットストリームを復号化する方法、装置及びコンピュータプログラム
Jenisch et al. A detailed evaluation of format-compliant encryption methods for JPEG XR-compressed images
US10958989B2 (en) Framework for embedding data in encoded video
CN113825024A (zh) 视频处理方法和装置、电子设备、计算机可读存储介质
US10554976B2 (en) Framework for embedding data in encoded video
Yüksel Partial encryption of video for communication and storage
KR20020096207A (ko) 헤더 정보 암호화에 의한 멀티미디어 컨텐츠 보호 방법

Legal Events

Date Code Title Description
C06 Publication
PB01 Publication
C10 Entry into substantive examination
SE01 Entry into force of request for substantive examination
TA01 Transfer of patent application right
TA01 Transfer of patent application right

Effective date of registration: 20170714

Address after: French Marta Leroy

Applicant after: Sikaide European Limited by Share Ltd

Address before: Holland Ian Deho Finn

Applicant before: NXP BV

GR01 Patent grant
GR01 Patent grant