CN116249981A - 视频编解码中的图像分割 - Google Patents

视频编解码中的图像分割 Download PDF

Info

Publication number
CN116249981A
CN116249981A CN202180067097.6A CN202180067097A CN116249981A CN 116249981 A CN116249981 A CN 116249981A CN 202180067097 A CN202180067097 A CN 202180067097A CN 116249981 A CN116249981 A CN 116249981A
Authority
CN
China
Prior art keywords
video
media
bitstream
region
public key
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
Application number
CN202180067097.6A
Other languages
English (en)
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.)
ByteDance Inc
Original Assignee
ByteDance Inc
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 ByteDance Inc filed Critical ByteDance Inc
Publication of CN116249981A publication Critical patent/CN116249981A/zh
Pending legal-status Critical Current

Links

Images

Classifications

    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L9/00Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
    • H04L9/30Public key, i.e. encryption algorithm being computationally infeasible to invert or user's encryption keys not requiring secrecy
    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06FELECTRIC DIGITAL DATA PROCESSING
    • G06F21/00Security arrangements for protecting computers, components thereof, programs or data against unauthorised activity
    • G06F21/60Protecting data
    • G06F21/62Protecting access to data via a platform, e.g. using keys or access control rules
    • G06F21/6209Protecting access to data via a platform, e.g. using keys or access control rules to a single file or object, e.g. in a secure envelope, encrypted and accessed using a key, or with access control rules appended to the object itself
    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06FELECTRIC DIGITAL DATA PROCESSING
    • G06F21/00Security arrangements for protecting computers, components thereof, programs or data against unauthorised activity
    • G06F21/70Protecting specific internal or peripheral components, in which the protection of a component leads to protection of the entire computer
    • G06F21/82Protecting input, output or interconnection devices
    • G06F21/84Protecting input, output or interconnection devices output devices, e.g. displays or monitors
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L9/00Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
    • H04L9/06Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols the encryption apparatus using shift registers or memories for block-wise or stream coding, e.g. DES systems or RC4; Hash functions; Pseudorandom sequence generators
    • H04L9/0643Hash functions, e.g. MD5, SHA, HMAC or f9 MAC
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04NPICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N21/00Selective content distribution, e.g. interactive television or video on demand [VOD]
    • H04N21/20Servers specifically adapted for the distribution of content, e.g. VOD servers; Operations thereof
    • H04N21/23Processing of content or additional data; Elementary server operations; Server middleware
    • H04N21/234Processing of video elementary streams, e.g. splicing of video streams or manipulating encoded video stream scene graphs
    • H04N21/2347Processing of video elementary streams, e.g. splicing of video streams or manipulating encoded video stream scene graphs involving video stream encryption
    • 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/80Generation or processing of content or additional data by content creator independently of the distribution process; Content per se
    • H04N21/83Generation or processing of protective or descriptive data associated with content; Content structuring
    • H04N21/835Generation of protective data, e.g. certificates
    • H04N21/8358Generation of protective data, e.g. certificates involving watermark

Landscapes

  • Engineering & Computer Science (AREA)
  • Signal Processing (AREA)
  • Computer Security & Cryptography (AREA)
  • Theoretical Computer Science (AREA)
  • Multimedia (AREA)
  • Computer Hardware Design (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • General Physics & Mathematics (AREA)
  • General Engineering & Computer Science (AREA)
  • Physics & Mathematics (AREA)
  • Software Systems (AREA)
  • Computing Systems (AREA)
  • Power Engineering (AREA)
  • Health & Medical Sciences (AREA)
  • Bioethics (AREA)
  • General Health & Medical Sciences (AREA)
  • Compression Or Coding Systems Of Tv Signals (AREA)
  • Two-Way Televisions, Distribution Of Moving Picture Or The Like (AREA)

Abstract

描述了用于媒体处理的方法、系统和设备。一种处理数字媒体的示例方法包括执行媒体片段和媒体片段的比特流之间的转换,该转换符合格式规则和加密规则,并且该格式规则规定在比特流中信令通知媒体片段的部分的完整性的指示。在一个示例中,媒体片段是视频片段、音频片段或图像。

Description

视频编解码中的图像分割
相关申请的交叉参考
根据适用专利法和/或依据巴黎公约的规则,本申请要求于2020年9月30日提交的第US 63/085,906号美国临时专利申请的优先权和权益。出于法律上的所有目的,上述申请的全部公开内容通过参考并入作为本申请公开内容的部分。
技术领域
本专利文档涉及数字媒体编码和解码。
背景技术
数字视频占互联网和其他数字通信网络上的最大带宽使用。随着能够接收和显示视频的连接用户设备的数量的增加,预期数字视频使用的带宽需求将继续增长。
发明内容
本文档公开了可由图像、音频或视频编码器和解码器用来确保编码操作、解码操作和编码的数字媒体片段的完整性的技术。
在一个示例方面,公开了一种数字媒体处理方法。该方法包括:执行媒体片段和媒体片段的比特流之间的转换,转换符合格式规则和加密规则,并且格式规则规定在比特流中信令通知媒体片段的部分的完整性的指示。
在又一示例方面,公开了一种媒体处理装置。该装置包括被配置为实现上述方法的处理器。
在又一示例方面,公开了一种其上存储有代码的计算机可读介质。该代码以处理器可执行代码的形式体现了在此描述的方法之一。
这些以及其他特征将在本文档中描述。
附图说明
图1示出了基于区域的图像验证的示例。
图2示出了安全哈希值的数字签名的示例。
图3示出了可信时间戳的示例。
图4是示例视频处理系统的框图。
图5是视频处理装置的框图。
图6是示出了根据本公开的一些实施例的视频编解码系统的框图。
图7是示出了根据本公开的一些实施例的编码器的框图。
图8是示出了根据本公开的一些实施例的解码器的框图。
图9是数字媒体处理的示例方法的流程图。
具体实施方式
在本文档中使用章节标题是为了易于理解,而不是将每个章节中公开的技术和实施例的适用性仅限制于该章节。此外,在一些描述中使用H.266术语仅仅是为了易于理解,而不是为了限制所公开技术的范围。因此,在此描述的技术也适用于其他视频编解码器协议和设计。
1.概述
该专利文档涉及图像/视频系统和编解码技术。具体地,它提供了一种验证图像/视频完整性的方法,即图像/视频是否从其认证的来源被修改过。它可以应用于未来的图像/视频编解码和/或系统标准。它还可以作为核心技术应用于可信图像/视频应用的一般服务中,例如远程医疗、来源认证广播。
2.初步讨论
视频编解码标准主要通过众所周知的ITU-T和ISO/IEC标准的发展而演进。ITU-T制定了H.261和H.263,ISO/IEC制定了MPEG-1和MPEG-4Visual,这两个组织联合制定了H.262/MPEG-2视频和H.264/MPEG-4高级视频编解码(AVC)和H.265/HEVC标准。自H.262以来,视频编解码标准基于其中利用了时域预测加变换编解码的混合视频编解码结构。为了探索HEVC以外的未来视频编解码技术,VCEG和MPEG于2015年联合成立了联合视频探索小组(JVET)。此后,JVET采用了许多新方法,并将其输入到名为联合探索模型(JointExploration Model,JEM)的参考软件中。2018年4月,VCEG(Q6/16)和ISO/IEC JTC1 SC29/WG11(MPEG)成立了联合视频专家小组(JVET),致力于VVC标准,目标是与HEVC相比将比特率降低50%。
VVC草案的最新版本,即通用视频编解码(草案8)可在http://phenix.int-evry.fr/jvet/doc_end_user/documents/17_Brussels/wg11/JVET-Q 2001-v13.zip以下网址找到。
而最新的测试模型软件可以在https://vcgit.hhi.fraunhofer.de/jvet/VVCSoftware_VTM/-/archive/VTM-8.0/VVC Software_VTM-VTM-8.0.zip找到。
此外,相应的系统标准也在开发中。视频可用性信息和补充增强信息是相关的,其中传达了解码器可能不需要的各种信息。SEI消息的最新草案文件可在http://phenix.int-evry.fr/jvet/doc_end_user/documents/17_Brussels/wg11/JVET-Q 2007-v5.zip上找到。
2.1.图像/视频篡改(tempering)和深度伪造(deepfake)
图像/视频文件包含用于重建的必要信息,并且相关标准可以保证图像/视频可以被无任何歧义地重建。然而,它不能判断图像/视频是否被篡改过。随着深度神经网络的发展,图像/视频篡改更难被辨别。下面的定义引自https://en.wikipedia.org/wiki/Deepfake。
“深度伪造(“深度学习”和“伪造”的组合)是一种媒体,它利用人工神经网络将现有图像或视频中的一个人替换为另一个人的肖像。他们经常使用被称为自动编码器和生成对抗网络(generative adversarial network,GAN)的机器学习技术将现有媒体组合和叠加到来源媒体上。深度伪造因其在名人色情视频、复仇色情、假新闻、恶作剧和金融欺诈中的使用而获得了广泛关注。这引起了工业界和政府对检测和限制它们的使用的反应”。
2.2.需要验证的图像/视频应用
可能需要验证的应用程序包括
1.远程医疗。出于安全原因,希望能够验证相关的医学图像/视频,例如,是否其来自认证的来源。
2.具有法律效力或法律强制力的图像/视频记录。一旦记录了图像/视频,就可以知道原始图像/视频是否已经被篡改。因此,任何显示法律效力的图像/视频都应该通过测试,以辨别视频是否是原创的。
2.3.安全哈希算法
安全哈希算法是由美国国家标准与技术研究所(NIST)作为美国联邦信息处理标准(FIPS)发布的一系列加密哈希函数,包括:
SHA-0:应用于1993年以名称“SHA”发布的160位哈希函数的原始版本的返璞词。由于一个未公开的“重大缺陷”,它在出版后不久就被撤回,并被稍加修改的版本《SHA-1》所取代。
SHA-1:一种160位的哈希函数,类似于早期的MD5算法。这是美国国家安全局(NSA)设计的数字签名算法的一部分。SHA-1发现了加密弱点,2010年后,该标准不再被批准用于大多数加密用途。
SHA-2:两个相似的哈希函数的家族,具有不同的块尺寸,被称为SHA-256和SHA-512。它们在字长上不同;SHA-256使用32字节的字,而SHA-512使用64字节的字。每种标准也有删节版,称为SHA-224、SHA-384、SHA-512/224和SHA-512/256。这些也是NSA设计的。
SHA-3:以前被称为Keccak的哈希函数,在2012年非NSA设计师之间的公开竞争后被选中。它支持与SHA-2相同的哈希长度,并且其内部结构与SHA系列的其他产品有很大不同。
相应的标准有FIPS PUB 180(原始SHA)、FIPS PUB 180-1(SHA-1)、FIPS PUB 180-2(SHA-1、SHA-256、SHA-384和SHA-512)。NIST已经更新了FIPS第202号出版物草案,SHA-3标准与安全哈希标准(SHS)分开。
2.4.文件验证
文件验证是使用算法来验证计算机文件完整性的过程。这可以通过逐位比较两个文件来完成,但是需要相同文件的两个副本,并且可能错过两个文件都可能发生的系统损坏。更流行的方法是生成复制文件的哈希,并将其与原始文件的哈希进行比较。
验证过程可以包括完整性验证和真实性验证。文件完整性可能会受到损害,通常称为文件损坏。文件损坏的方式多种多样:存储介质故障、传输错误、复制或移动过程中的写入错误、软件错误等等。基于哈希的验证通过将文件的哈希值与之前计算的值进行比较,确保文件未被损坏。如果这些值匹配,则认为该文件未被修改。由于哈希函数的性质,哈希冲突可能会导致误报,但对于随机损坏,冲突的可能性通常可以忽略不计。通常需要验证文件在传输或存储过程中未被不可信方修改,例如,未被修改为包括诸如病毒或后门程序之类的恶意代码。为了验证真实性,传统的哈希函数是不够的,因为它们没有被设计成抗冲突的;对于攻击者来说,引起故意的哈希冲突使得文件中的恶意改变不被哈希比较检测到在计算上是容易的。在密码学中,这种攻击被称为原像攻击。通常使用加密哈希函数来解决这个问题。只要哈希值不能被篡改,例如,如果它们是通过安全通道传输的,就可以认为文件是完整的。或者,可以使用数字签名来确保防篡改性。
某些文件格式可以支持文件验证,例如校验和文件。校验和文件是一个包含其他文件校验和的小文件。有几种众所周知的校验和文件格式。一些实用程序,如md5deep,可以使用这样的校验和文件在一次操作中自动验证整个文件目录。所使用的特定哈希算法通常由校验和文件的文件扩展名来指示。“.sha1”文件扩展名指示包含sha1sum格式的160位SHA-1哈希的校验和文件。“.md5”文件扩展名或名为“MD5SUMS”的文件指示包含md5sum格式的128位MD5哈希的校验和文件。“.sfv”文件扩展名指示包含简单文件验证格式的32位CRC32校验和的校验和文件。“crc.list”文件指示包含brik格式的32位CRC校验和的校验和文件。截至2012年,最佳做法建议是使用SHA-2或SHA-3生成新的文件完整性摘要;如果没有更强的摘要,则接受MD5和SHA1摘要以实现向后兼容。理论上较弱的SHA1、较弱的MD5或弱得多的CRC以前通常用于文件完整性检查。CRC校验和不能用于验证文件的真实性,因为CRC32不是一个抗冲突的哈希函数——即使哈希和文件没有被篡改,攻击者用与原始文件相同的CRC摘要替换文件在计算上也是容易的,这意味着文件中的恶意改变不会被CRC比较检测到。
2.5.HEVC和VVC的无损编解码
在VVC,无损编解码技术也被研究。然而,虽然会有编解码技术支持无损编解码,但目前没有办法保证视频是无损编解码的。
为了提供无损编解码,VVC的操作配置,即用于无损、接近无损和混合有损/无损编解码的JVET通用测试条件和软件参考配置,可以在以下位置找到:
http://phenix.int-evry.fr/jvet/doc_end_user/current_document.php?id=9683
2.6.VUI/SEI
在HEVC/VVC,定义了一种称为解码图片哈希SEI消息的SEI消息来验证解码的视频是否正确。
2.6.1.解码图片哈希SEI消息语法
Figure BDA0004152833010000061
2.6.2.解码的图片哈希SEI消息语义
该消息为当前解码图片的每个颜色分量提供哈希。
使用此SEI消息需要定义以下参数:
–以亮度样点为单位的图片宽度和图片高度,此处表示为pic_width_in_luma_samples和pic_height_in_luma_samples。
–色度格式指示符,本文用chroma_format_idc表示。
–亮度分量样点的位深度,本文用BitDepthY表示,当chroma_format_idc不等于0时,两个相关色度分量样点的位深度,本文用BitDepthC表示。
–对于每个颜色分量cIdx,以二进制补码表示的解码样点值的光栅扫描顺序排列的数组分量[cIdx][i]
在计算哈希之前,解码的图片数据被排列成一个或三个字节串,称为长度为dataLen[cIdx]的pictureData[cIdx],如下所示:
Figure BDA0004152833010000062
Figure BDA0004152833010000071
其中,组件[cIdx][i]是以二进制补码表示的解码样点值的光栅扫描中的数组。
hash_type指示用于计算校验和的方法,如表9中规定的。表9中未列出的hash_type值由ITU-T|ISO/IEC保留供将来使用,不应出现在符合本规范该版本的有效载荷数据中。解码器应忽略包含hash_type的保留值的解码图片哈希SEI消息。
表9–哈希类型的解释
hash_type 方法
0 MD5(IETF RFC 1321)
1 CRC
2 校验和
picture_md5[cIdx][i]是解码图片的第cIdx个颜色分量的16字节MD5哈希。使用IETF RFC 1321中定义的MD5函数,picture_md5[cIdx][i]的值应等于如下获得的digestVal[cIdx]的值:
MD5Init(context)
MD5Update(context,pictureData[cIdx],dataLen[cIdx])
MD5Final(digestVal[cIdx],context)
picture_crc[cIdx]是解码图片的颜色分量cIdx的循环冗余校验(CRC)。picture_crc[cIdx]的值应等于crcVal[cIdx]的值,如下地求得:
Figure BDA0004152833010000081
注-Rec.ITU-T H.271中有相同的CRC规范。
picture_checksum[cIdx]是解码图片的颜色分量cIdx的校验和。picture_checksum[cIdx]的值应等于checksumVal[cIdx]的值,如下地求得:
Figure BDA0004152833010000082
虽然SEI消息可以用来检测解码的图片是否与相应的编码图片匹配,但是由于MD5、CRC和校验和很容易被破解,所以它的安全性很弱。
3.由公开的技术方案解决的现有技术问题
1.没有具体的方案来验证图像/视频(部分或全部)是否来自认证的源/编码器。
2.没有具体的方案来验证图像/视频(部分或全部)是否已经被篡改。
3.没有具体的方案来验证图像/视频(部分或全部)是否被无损编码,以及相对于什么是无损的。
4.当前解码的图片哈希SEI消息不够安全,并且不是针对视频的一部分。
5.没有具体的方案来验证音频是否来自认证的源/编码器。
4.技术和实施例的示例列表
本公开的一个方面是提供一种安全机制来指示图像/视频/音频的特定部分或全部是否是由认证的源或编码器在特定时间生成的。与文件验证不同,如果特定部分的重建匹配,则认为两个信号匹配。因此,验证独立于特定的图像/视频/音频表示/编解码标准。此外,所提出的方法也适用于文本表示。
所列项目应被视为解释一般概念的示例,而不应被狭义地解释。此外,这些项目可以单独应用或以任何方式组合应用。
1.可以信令通知图像/视频/音频的一个或多个安全哈希值,例如SHA-2、SHA-3,以指示内容的完整性。
a.只要重建值的安全哈希值相同,两个图像/视频/音频可以被认为是相同的。
b.只要重建值的安全哈希值不同,两个图像/视频/音频就可以被认为是不同的。
2.可以信令通知图像/视频/音频区域的一个或多个安全哈希值,例如SHA-2、SHA-3,以指示内容的完整性。
a.该区域可以是条带、子图片、片、CTU行或CTU。
b.此外,可选择地,可以进一步信令通知图像/视频/音频的区域的指示。
i.在一个示例中,该区域可以由该区域内相对于图片的特定位置的坐标来表示,诸如该区域的左上位置和右下位置。
ii.在一个示例中,该区域可以由该区域内特定位置的单元坐标来表示,诸如该区域的左上位置和右下位置。
1.在一个示例中,该单元被定义为CTU/CTB。并且单元坐标是用CTU/CTB表示的位置坐标。
iii.在一个示例中,该区域可以是子图片,并且该区域的指示可以由子图片的索引来表示。
c.图1中示出了一个示例,其中,(x0,y0)到(x1,y1)定义了要保护的图像区域。为了保护区域,计算并发送该区域内按光栅扫描顺序的所有像素的安全哈希值,即SHA-3(p[x0,y0],p[x0+1,y0],...,p[x1,y0],p[x0,y0+1],p[x0+1,y0+1],…,p[x1,y0+1],…,p[x1,y0],p[x1,y0+1],…,p[x1,y1]),以指示图像的内容。
d.在另一个示例中,区域的安全哈希值可以按顺序信令通知。
i.例如,该顺序可以是光栅扫描顺序。
ii.例如,该顺序可以是解码顺序。
iii.例如,该顺序可以是区域的索引的升序或降序,诸如子图片索引、或片索引、或条带索引、或CTU索引。
e.在一个示例中,视频内的多个图片(例如,所有图片)的相同区域可以用于检查内容的完整性。
i.例如,对于多个图片,区域的指示可以被信令通知一次,例如,由左上/右下坐标表示。
f.可选择地,视频内的多个图片(例如,所有图片)的不同区域可以用于检查内容的完整性。
i.此外,可选择地,对于多个图片,可以多次信令通知区域的指示,例如,由特定图片内的左上/右下坐标来表示。
1.此外,可选择地,可以进一步信令通知(例如,由POC值指示的)图片的指示。
g.为了判断被保护区域是否已经被篡改,可以应用SHA-3()值的直接比较。
h.在一个示例中,可以应用MD5/SHA-0/SHA-1。
3.安全哈希值的私钥加密消息可以与图像/视频/音频一起发送以指示来源。
a.在一个示例中,使用图2中所示的数字签名系统。
b.可选择地,私钥加密可以直接应用于图像/视频/音频信号。
c.可选择地,私钥加密可以应用于图像/视频/音频的MD5/CRC/校验和。
4.可信时间戳消息可以与安全哈希值一起发送。
a.图3示出了一个示例。编码器将编码后的信号(部分或全部)的安全哈希值发送到第三方时间戳机构(TSA),然后TSA用时间戳信息对哈希值进行签名,并将签名的信息发回。为了验证信号是否在特定时间被编码,解码器可以使用TSA的公钥来解密哈希值,并验证它是否与内容匹配。
5.对于图像,可以发送特定区域的安全哈希值或其加密版本来指示完整性和/或来源。
a.在一个示例中,区域可以被定义为具有起始点、区域宽度和区域高度的矩形框。
b.在一个示例中,区域可以被定义为起始点和预定义的闭合形状。
6.对于以上示例,要发送/信令通知的信息可以存在于特定的SEI消息中。
a.此外,可选择地,当特定编解码工具(例如,参考图片重采样)被启用时,符合标准的比特流应当满足特定SEI不存在于比特流中。
7.符合标准的图像解码器可以遵守以下约束。
a.在一个示例中,符合标准的图像解码器应该输出该区域是否匹配安全哈希值。
b.在一个示例中,符合标准的图像解码器应该输出该区域是否匹配安全哈希值,不管该区域的起始点如何。
8.对于音频信号,可以发送特定连续片段的安全哈希值或其加密版本来指示完整性和/或来源。
a.在一个示例中,可以通过信号的开始时间和持续时间来定义片段。
9.符合标准的音频解码器可以遵守以下约束。
a.在一个示例中,符合标准的音频解码器应该输出该片段是否匹配安全哈希值。
b.在一个示例中,符合标准的音频解码器应该输出该片段是否匹配安全哈希值,不管该片段的起始点如何。
10.符合标准的音频播放器可以遵守以下约束。
a.在一个示例中,除非检测到人类的交互,否则播放器应该按顺序播放认证的音频。
b.在一个示例中,播放器应该以与来源速度相比在特定精度内的速度播放认证的音频。
11.对于视频,可以发送特定片段的安全哈希值或其加密版本来指示完整性和/或来源。
a.在一个示例中,视频片段可以被定义为按显示顺序的一组连续图片。
b.此外,可选择地,对于每个图片,可以规定预定义的区域。
12.符合标准的视频解码器可以遵守以下约束。
a.在一个示例中,符合标准的视频解码器应该输出该片段是否匹配安全哈希值。
b.在一个示例中,符合标准的视频解码器应该输出不管起始点如何,该片段是否匹配安全哈希值。
c.在一个示例中,符合标准的视频解码器应该输出该片段是否与安全哈希值匹配,而不管该片段的起始点和每个区域的起始点。
13.符合标准的视频播放器可以遵守以下约束。
a.在一个示例中,符合标准的视频播放器应该按照显示顺序播放认证的视频。
b.在一个示例中,符合标准的视频播放器应该辨别视频是否被认证,如果是,哪个部分被认证。
c.在一个示例中,符合标准的视频播放器应该以与来源速度相比在特定精度内的速度播放认证的视频。
14.安全哈希函数可以应用于二进制比特流。
a.在一个示例中,安全哈希函数可以应用于NAL单元。
b.在一个示例中,安全哈希函数可以应用于视频编解码层NAL单元。
c.在一个示例中,安全哈希函数可以应用于多个NAL单元。
15.DSA/RSA/ECDSA可以应用于二进制比特流。
a.在一个示例中,DSA/RSA/ECDSA可以应用于NAL单元。
b.在一个示例中,DSA/RSA/ECDSA可以应用于视频编解码层NAL单元。
c.在一个示例中,DSA/RSA/ECDSA可以应用于多个NAL单元。
16.FIPS 180-4和FIPS 202中的安全哈希可以应用于视频序列的一部分。
a.在一个示例中,在FIPS 180-4和FIPS 202中列出的安全哈希可以被应用于图片区域的重建。
b.在一个示例中,在FIPS 180-4和FIPS 202中列出的安全哈希可以被应用于图片区域的重建。
17.DSA/RSA/ECDSA可以应用于一个或多个图片的相同区域的重建。
a.在一个示例中,DSA/RSA/ECDSA可以应用于一个或多个图片的相同区域的重建,直到SEI消息中的取消标志为真。
b.在一个示例中,DSA/RSA/ECDSA可以应用于一个或多个图片的相同区域的重建。
18.区域定义可以具有约束。
a.在一个示例中,区域左上点的水平分量和垂直分量应该总是非负整数。
i.此外,可选择地,该区域左上点的水平分量应该小于图片/子图片宽度。
ii.此外,可选择地,该区域左上点的垂直分量应该小于图片/子图片的高度。
b.在一个示例中,该区域不应该在图片或子图片之外。
c.在一个示例中,可以以色度单元或亮度单元来度量该区域。
i.在一个示例中,是以色度单位还是亮度单位来测量区域可以取决于颜色格式。
1.在一个示例中,对于4:0:0的情况,以亮度单位来测量区域。
2.在一个示例中,对于非4:0:0的情况,以色度单位来测量区域。
d.在一个示例中,区域定义可以包括左上位置的起点(在x和/或y方向上)、宽度和高度。
e.在一个示例中,区域定义可以包括左上位置的起点(在x和/或y方向上)和右下位置的终点(在x和/或y方向上)。
f.在一个示例中,宽度和/或高度可以信令通知为(实际宽度和/或高度减去K(K是整数值,例如K=1))。
i.可选择地,可以添加宽度和/或高度应该大于0的约束。
g.在以上示例中,图片/子图片可以由其他视频单元(例如,视图/层/条带/片/多个CTU)代替。
19.一个或多个公钥可以包含在视频比特流中。
a.在一个示例中,一个公钥可以包含在SEI消息中。
b.在一个示例中,当(一个或多个)公钥不同于解码器从可信来源获得的公钥时,解码器可以拒绝签名。
20.DSA/ECDSA中的一个或多个域参数可以包含在视频比特流中。
a.在一个示例中,DSA/ECDSA中的一个或多个域参数可以包含在SEI消息中。
b.在一个示例中,当域参数不同于解码器从可信来源获得的域参数时,解码器可以拒绝签名。
21.对于RSA签名,以下内容可以适用
a.RSA签名可以以大端(big-endian)方式二进制化。
b.RSA签名可以以小端(little-endian)方式二进制化。
22.对于DSA/ECDSA,设r和s为数字签名,则适用以下情况
a.r和s可以以大端方式二进制化。
b.r和s可以以小端方式二进制化。
c.r可以在s之前被二进制化。
d.r可以在s之后二进制化。
e.r可以在s之后立即被二进制化。
f.s可以在s之后立即被二进制化。
23.数字签名可以在比特流中字节对准。
a.在一个示例中,数字签名在SEI中可以是字节对准的。
24.后量子密码术可以应用于该系统。
a.在一个示例中,可以应用扩展的Merkle签名方案(eXtended Merkle SignatureScheme,XMSS)。
b.在一个示例中,可以应用Leighton-Micali签名(Leighton-MicaliSignatures,LMS)。
c.在一个示例中,可以应用基于代码的密码术。
i.在一个例子中,可以应用McEliece公钥加密系统。
ii.在一个示例中,可以应用Niederreiter加密算法之一。
25.公钥指纹或其较短期术语(shorter term)可以与视频/音频/图像/文本比特流一起发送。
a.在一个示例中,可以使用128位MD5/SHA-1指纹。
b.在一个示例中,可以使用160位MD5/SHA-1指纹。
c.在一个示例中,指纹信息可以包括用户(认证)信息。
26.公钥或其较短期术语可以与视频/音频/图像/文本比特流一起发送。
27.一个或多个可信服务器可以用于分发公钥。
28.可以在SEI消息中信令通知颜色分量的数量/颜色格式/单色图片/建议SEI消息对一个或多个颜色分量的使用的指示。
a.在一个示例中,该指示可以由1位标志来表示。
b.在一个示例中,可以添加指示应当等于(ChromaFormatIdc==0)或(sps_chroma_format_idc==0)的约束。
5.实施例
5.1.实施例#1:一个图片的安全哈希SEI
解码图片安全哈希SEI消息语法
Figure BDA0004152833010000161
解码图片安全哈希SEI消息语义
该消息为当前解码图片的矩形区域提供安全哈希。
使用此SEI消息需要定义以下变量:
–矩形区域,在此分别由region_start_x、region_start_y、region_width和region_height定义。
–样点的位深度,在此用BitDepthY表示亮度,用BitDepthC表示色度。
–对于每个颜色分量cIdx,数组ComponentSamples[cIdx][i][j]解码的样点值。
在计算哈希之前,解码的图片数据被排列成一个或三个字节串,称为长度为dataLen的regionData[cIdx],如下所示:
Figure BDA0004152833010000162
Figure BDA0004152833010000171
secure_hash_type指示用于计算安全哈希值的方法。如果secure_hash_type等于0,则使用SHA-3(256,256)。
SHA-3(256,256)是由NIST标准https://nvlpubs.nist.gov/nistpubs/FIPS/NIST.FIPS.202.pdf定义的。
5.2.实施例#2:数字签名SEI消息
数字签名SEI消息语法
Figure BDA0004152833010000172
Figure BDA0004152833010000181
数字签名SEI消息语义
该消息为相关解码图片的矩形区域提供了安全哈希。
使用此SEI消息需要定义以下变量:
–以亮度样点为单位的图片宽度和图片高度,在此分别用PicWidthInLumaSamples和PicHeightInLumaSamples表示。
–色度格式指示器,在此用ChromaFormatIdc表示,如JVET-R2007-v2的条款7.2中所述。
–亮度分量样点的位深度,在此用BitDepthY表示,当ChromaFormatIdc不等于0时,两个相关色度分量样点的位深度,在此用BitDepthC表示。
–对于每个颜色分量cIdx,数组ComponentSamples[cIdx][i]以二进制补码表示的解码样点值的光栅扫描顺序排列。
ds_cancel_flag等于1指示SEI消息取消了解码顺序中任何先前数字签名SEI消息的持久性。ds_cancel_flag等于0指示后面是数字签名信息。
ds_persistence_flag规定当前层的数字签名SEI消息的持久性。
ds_persistence_flag等于0的规定数字签名SEI消息仅应用于当前解码的图片。
ds_persistence_flag等于1规定数字签名SEI消息应用于当前解码的图片,并且按照输出顺序持续用于当前层的所有后续图片,直到以下一个或多个条件为真:
–当前层的新CLVS开始。
–比特流结束。
–与数字签名SEI消息相关联的AU中当前层的图片按照解码顺序位于当前图片之后。
设与ds_cancel_flag等于0的数字签名SEI消息相关联的解码图片的数量为numAssociatedPics。
在计算哈希之前,解码的图像数据被排列成一个或三个字节串,称为长度为dataLen的regionData[cIdx],如下所示:
Figure BDA0004152833010000191
Figure BDA0004152833010000201
ds_reserved_zero_bit应该等于0。ds_reserved_zero_bit的值1是为ITU-T|ISO/IEC将来使用而保留的。
ds_type指示下表中规定的用于计算数字签名的方法。表中未列出的ds_type值由ITU-T|ISO/IEC保留供将来使用,并且不应存在于符合本规范本版本的有效载荷数据中。解码器应该忽略包含ds_type的保留值的数字签名SEI消息。
digital_signature_type 方法
0 DSA(2048,256)(FIPS 186-4)
1 RSA
2 ECDSA
ds_secure_hash_type指示下表中规定的用于计算哈希值的方法。表中未列出的ds_secure_hash_type值由ITU-T|ISO/IEC保留供将来使用,不应存在于符合本规范本版本的有效载荷数据中。解码器应忽略包含ds_secure_hash_type的保留值的安全图片哈希SEI消息。
secure_hash_type 方法
0 SHA-512/256(FIPS 180-4)
1 SHA-512/224(FIPS 180-4)
ds_single_component_flag等于1规定与数字信号SEI消息相关联的图片包含单一颜色分量。ds_single_component_flag等于0规定与数字信号SEI消息相关联的图片包含三个颜色分量。ds_single_component_flag的值应等于(ChromaFormatIdc==0)。
ds_region_params_present_flag等于1规定存在ds_region_start_left、ds_region_start_top、ds_region_width和ds_region_height。ds_region_params_present_flag等于0规定不存在ds_region_start_left、ds_region_start_top、ds_region_width和ds_region_height。
如果SEI消息包含在sn_subpic_flag等于1的可缩放嵌套SEI消息中,则将变量subpicFlag设置为等于1。否则(SEI消息不包含在sn_subpic_flag等于1的可缩放嵌套SEI消息中),subpicFlag等于0。
ds_region_start_left和ds_region_start_top规定区域左上角相对于解码图片(当subpicFlag等于0时)或解码子图片(当subpicFlag等于1时)的左上角的以色度样点为单位的左右偏移。当ds_region_params_present_flag等于0时,ds_region_start_left和ds_region_start_top的值都被推断为等于0。
ds_region_width和ds_region_height分别规定区域的以色度样点为单位的宽度和高度。当ds_region_params_present_flag等于0时,ds_region_width和ds_region_height的值分别被推断为解码图片(当subpicFlag等于0时)或解码子图片(当subpicFlag等于1时)的以色度样点为单位的宽度和高度。
要求的是,当存在时,ds_region_width和ds_region_height都应大于或等于1。
(ds_region_start_left+ds_region_width)的值应小于或等于解码图片(当subpicFlag等于0时)或解码子图片(当subpicFlag等于1时)的以色度样点为单位的宽度。
(ds_region_start_top+ds_region_height)的值应小于或等于解码图片(当subpicFlag等于0时)或解码子图片(当subpicFlag等于1时)的以色度样点为单位的高度。
digital_signature规定了包括多个字节的信息,用于验证受保护区域的完整性。
对于DSA(2048,256),数字签名包含两个整数r和s,它们都是256位。语法元素是64字节,具有如下定义的值dsVal:
dsVal=0
for(i=248;i>=0;i-=8)
dsVal+=r>>i&0xFF
dsVal=dsVal<<256
for(i=248;i>=0;i-=8)
dsVal+=s>>i&0xFF
5.3.实施例#3:数字签名SEI消息的另一种选择
数字签名SEI消息语法
Figure BDA0004152833010000221
数字签名SEI消息语义
该消息为相关解码图片的矩形区域提供了安全哈希。
使用此SEI消息需要定义以下变量:
–以亮度样点为单位的图片宽度和图片高度,在此分别用PicWidthInLumaSamples和PicHeightInLumaSamples表示。
–色度格式指示器,在此用ChromaFormatIdc表示,如JVET-R2007-v2的条款7.2中所述。
–亮度分量样点的位深度,在此用BitDepthY表示,当ChromaFormatIdc不等于0时,两个相关色度分量样点的位深度,在此用BitDepthC表示。
–对于每个颜色分量cIdx,数组ComponentSamples[cIdx][i]以二进制补码表示的解码样点值的光栅扫描顺序排列。
ds_cancel_flag等于1指示SEI消息取消了解码顺序中任何先前数字签名SEI消息的持久性。ds_cancel_flag等于0指示后面是数字签名信息。
ds_persistence_flag规定当前层的数字签名SEI消息的持久性。
ds_persistence_flag等于0的规定数字签名SEI消息仅应用于当前解码的图片。
ds_persistence_flag等于1规定数字签名SEI消息应用于当前解码的图片,并且按照输出顺序持续用于当前层的所有后续图片,直到以下一个或多个条件为真:
–当前层的新CLVS开始。
–比特流结束。
–与数字签名SEI消息相关联的AU中当前层的图片按照解码顺序位于当前图片之后。
设与ds_cancel_flag等于0的数字签名SEI消息相关联的解码图片的数量为numAssociatedPics。
在计算哈希之前,解码的图像数据被排列成一个或三个字节串,称为长度为dataLen的regionData[cIdx],如下所示:
Figure BDA0004152833010000231
Figure BDA0004152833010000241
ds_reserved_zero_bit应该等于0。ds_reserved_zero_bit的值1是为ITU-T|ISO/IEC将来使用而保留的。
ds_type指示下表中规定的用于计算数字签名的方法。表中未列出的ds_type值由ITU-T|ISO/IEC保留供将来使用,并且不应存在于符合本规范本版本的有效载荷数据中。解码器应该忽略包含ds_type的保留值的数字签名SEI消息。
digital_signature_type 方法
0 DSA(2048,256)(FIPS 186-4)
1 RSA
2 ECDSA
ds_secure_hash_type指示下表中规定的用于计算哈希值的方法。表中未列出的ds_secure_hash_type值由ITU-T|ISO/IEC保留供将来使用,不应存在于符合本规范本版本的有效载荷数据中。解码器应忽略包含ds_secure_hash_type的保留值的安全图片哈希SEI消息。
secure_hash_type 方法
0 SHA-512/256(FIPS 180-4)
1 SHA-512/224(FIPS 180-4)
ds_single_component_flag等于1规定与数字信号SEI消息相关联的图片包含单一颜色分量。ds_single_component_flag等于0规定与数字信号SEI消息相关联的图片包含三个颜色分量。ds_single_component_flag的值应等于(ChromaFormatIdc==0)。
ds_region_params_present_flag等于1规定存在ds_region_start_left、ds_region_start_top、ds_region_width和ds_region_height。ds_region_params_present_flag等于0规定不存在ds_region_start_left、ds_region_start_top、ds_region_width和ds_region_height。
如果SEI消息包含在sn_subpic_flag等于1的可缩放嵌套SEI消息中,则将变量subpicFlag设置为等于1。否则(SEI消息不包含在sn_subpic_flag等于1的可缩放嵌套SEI消息中),subpicFlag等于0。
ds_region_start_left和ds_region_start_top规定区域左上角相对于解码图片(当subpicFlag等于0时)或解码子图片(当subpicFlag等于1时)的左上角的以色度样点为单位的左右偏移。当ds_region_params_present_flag等于0时,ds_region_start_left和ds_region_start_top的值都被推断为等于0。
对于4:0:0格式,在亮度样点中规定偏移。
ds_region_width和ds_region_height分别规定区域的以色度样点为单位的宽度和高度。当ds_region_params_present_flag等于0时,ds_region_width和ds_region_height的值分别被推断为解码图片(当subpicFlag等于0时)或解码子图片(当subpicFlag等于1时)的以色度样点为单位的宽度和高度。
对于4:0:0格式,在亮度样点中规定偏移。
(ds_region_start_left+ds_region_width)的值应小于或等于解码图片(当subpicFlag等于0时)或解码子图片(当subpicFlag等于1时)的以色度样点为单位的宽度。
(ds_region_start_top+ds_region_height)的值应小于或等于解码图片(当subpicFlag等于0时)或解码子图片(当subpicFlag等于1时)的以色度样点为单位的高度。
ds_fingerprint规定了可用于认证更大的公钥的信息。在语法上是128位或160位。
digital_signature规定了包括多个字节的信息,用于验证受保护区域的完整性。
对于DSA(2048,256),数字签名包含两个整数r和s,它们都是256位。语法元素是64字节,具有如下定义的值dsVal:
dsVal=0
for(i=248;i>=0;i-=8)
dsVal+=r>>i&0xFF
dsVal=dsVal<<256
for(i=248;i>=0;i-=8)
dsVal+=s>>i&0xFF
图4是示出示例视频处理系统4000的框图,其中,可以实现本文公开的各种技术。各种实现可以包括系统4000的部分或全部组件。系统4000可以包括用于接收视频内容的输入4002。视频内容可以以原始或未压缩格式(例如,8位或10位多分量像素值)接收,或者可以以压缩或编码格式接收。输入4002可以表示网络接口、外围总线接口或存储接口。网络接口的示例包括有线接口(例如,以太网、无源光学网络(PON)等),以及无线接口(例如,Wi-Fi或蜂窝接口)。
系统4000可以包括编解码组件4004,其可以实现本文档中描述的各种编解码或编码方法。编解码组件4004可以将视频的平均比特率从输入4002降低到编解码组件4004的输出,以产生视频的编解码表示。因此,编解码技术有时被称为视频压缩或视频转码技术。编解码组件4004的输出可以被存储,或者经由由组件4006表示的连接的通信来传输。在输入4002处接收的视频的存储的或传送的比特流(或编解码的)表示可以由组件4008用于生成发送到显示接口4010的像素值或可显示视频。根据比特流生成用户可观看视频的过程有时被称为视频解压缩。此外,尽管某些视频处理操作被称为“编解码”操作或工具,但将理解的是,在编码器处使用编解码工具或操作,并且反转编解码结果的对应的解码工具或操作将由解码器执行。
外围总线接口或显示接口的示例可能包括通用串行总线(USB)或高清多媒体接口(HDMI)或Displayport等。存储接口的示例包括SATA(串行高级技术附件)、PCI、IDE接口等。本文档中描述的技术可以体现在各种电子设备中,例如移动电话、膝上型计算机、智能手机或能够执行数字数据处理和/或视频显示的其它设备。
图5是视频处理装置5000的框图。装置5000可以用于实现本文所描述的一种或多种方法。装置5000可以体现在智能手机、平板电脑、计算机、物联网(IoT)接收器等中。装置5000可以包括一个或多个处理器5002、一个或多个存储器5004和视频处理硬件5006。(多个)处理器5002可以被配置为实现本文档中描述的一个或多个方法。一个或多个存储器5004可以用于存储用于实现本文所描述的方法和技术的数据和代码。视频处理硬件5006可以用于在硬件电路中实现本文档中描述的一些技术。在一些实施例中,硬件5006可以部分或全部在一个或多个处理器5002(例如,图形处理器)中。
图6是示出可以利用本公开技术的示例视频编解码系统100的框图。
如图6所示,视频编解码系统100可以包括源设备110和目的地设备120。源设备110生成可以被称为视频编码设备的编码视频数据。目的地设备120可以对源设备110生成的编码视频数据进行解码,源设备110可以被称为视频解码设备。
源设备110可以包括视频源112、视频编码器114和输入/输出(I/O)接口116。
视频源112可以包括诸如视频捕获设备之类的源、从视频内容提供商接收视频数据的接口和/或用于生成视频数据的计算机图形系统,或这些源的组合。视频数据可以包括一个或多个图片。视频编码器114对来自视频源112的视频数据进行编码以生成比特流。比特流可以包括形成视频数据的编解码表示的比特序列。比特流可以包括编解码图片和相关联数据。编解码图片是图片的编解码表示。相关联的数据可以包括序列参数集、图片参数集和其它语法结构。I/O接口116可以包括调制器/解调器(调制解调器)和/或发射器。编码的视频数据可以通过网络130a经由I/O接口116直接发送到目的地设备120。编码的视频数据还可以存储在存储介质/服务器130b上,以供目的地设备120访问。
目的地设备120可以包括I/O接口126、视频解码器124和显示设备122。
I/O接口126可以包括接收器和/或调制解调器。I/O接口126可以从源设备110或存储介质/服务器130b获取编码的视频数据。视频解码器124可以对编码的视频数据进行解码。显示设备122可以向用户显示解码的视频数据。显示设备122可以与目的地设备120集合,或者可以位于目的地设备120的外部,目的地设备120被配置为与外部显示设备接合。
视频编码器114和视频解码器124可以根据视频压缩标准(例如高效视频编解码(HEVC)标准、通用视频编解码(VVC)标准和其它当前和/或进一步的标准)操作。
图7是示出视频编码器200的示例的框图,视频编码器200可以是图6所示的系统100中的视频编码器114。
视频编码器200可以被配置为执行本公开的任何或所有技术。在图7的示例中,视频编码器200包括多个功能组件。本公开中描述的技术可以在视频编码器200的各个组件之间共享。在一些示例中,处理器可以被配置为执行本公开中描述的任何或所有技术。
视频编码器200的功能组件可以包括分割单元201、可以包括模式选择单元203的预测单元202、运动估计单元204、运动补偿单元205和帧内预测单元206、残差生成单元207、变换单元208、量化单元209、反量化单元210、反变换单元211,重建单元212、缓冲器213和熵编码单元214。
在其它示例中,视频编码器200可以包括更多、更少或不同的功能组件。在一个示例中,预测单元202可以包括帧内块复制(IBC)单元。IBC单元可以在IBC模式下执行预测,其中至少一个参考图片是当前视频块所在的图片。
此外,一些组件(例如运动估计单元204和运动补偿单元205)可以是高度集合的,但是出于解释的目的,在图7的示例中分别表示。
分割单元201可以将图片分割成一个或多个视频块。视频编码器200和视频解码器300可以支持各种视频块尺寸。
模式选择单元203可以例如基于错误结果选择编解码模式中的一种(帧内或帧间),并将得到的帧内或帧间编解码块提供给残差生成单元207以生成残差块数据,以及提供给重建单元212以重建编码块以用作参考图片。在一些示例中,模式选择单元203可以选择帧内预测和帧间预测(CIIP)模式的组合,其中预测基于帧间预测信号和帧内预测信号。模式选择单元203还可以在帧间预测的情况下为块选择运动向量的分辨率(例如,子像素精度或整数像素精度)。
为了对当前视频块执行帧间预测,运动估计单元204可以通过将来自缓冲器213的一个或多个参考帧与当前视频块进行比较来生成当前视频块的运动信息。运动补偿单元205可以基于来自缓冲器213的、与当前视频块相关联的图片以外的图片的运动信息和解码样点来确定当前视频块的预测视频块。
例如,运动估计单元204和运动补偿单元205可以对当前视频块执行不同的操作,这取决于当前视频块是在I条带、P条带还是B条带中。
在一些示例中,运动估计单元204可以对当前视频块执行单向预测,并且运动估计单元204可以在列表0或列表1的参考图片中搜索当前视频块的参考视频块。然后,运动估计单元204可以生成参考索引,该索引指示包含参考视频块的列表0或列表1中的参考图片,以及指示当前视频块和参考视频块之间的空域位移的运动向量。运动估计单元204可以输出参考索引、预测方向指示符和运动向量作为当前视频块的运动信息。运动补偿单元205可以基于由当前视频块的运动信息指示的参考视频块来生成当前块的预测视频块。
在其它示例中,运动估计单元204可以对当前视频块执行双向预测,运动估计单元204可以在列表0中的参考图片中搜索当前视频块的参考视频块,还可以在列表1中的参考图片中搜索当前视频块的另一个参考视频块。然后,运动估计单元204可以生成指示包含参考视频块的列表0和列表1中的参考图片的参考索引,以及指示参考视频块和当前视频块之间的空域位移的运动向量。运动估计单元204可以输出当前视频块的参考索引和运动向量作为当前视频块的运动信息。运动补偿单元205可以基于由当前视频块的运动信息指示的参考视频块来生成当前视频块的预测视频块。
在一些示例中,运动估计单元204可以输出用于解码器的解码处理的完整运动信息集合。
在一些示例中,运动估计单元204可能不输出当前视频的完整运动信息集合。相反,运动估计单元204可以参考另一个视频块的运动信息来信令通知当前视频块的运动信息。例如,运动估计单元204可以确定当前视频块的运动信息与邻近视频块的运动信息足够相似。
在一个示例中,运动估计单元204可以在与当前视频块相关联的语法结构中,指示向视频解码器300指示当前视频块具有与另一个视频块相同的运动信息的值。
在另一个示例中,运动估计单元204可以在与当前视频块相关联的语法结构中识别另一个视频块和运动向量差(MVD)。运动向量差指示当前视频块的运动向量与所指示视频块的运动向量之间的差。视频解码器300可以使用所指示视频块的运动向量和运动向量差来确定当前视频块的运动向量。
如上所讨论的,视频编码器200可以预测地信令通知运动向量。可以由视频编码器200实现的预测信令技术的两个示例包括高级运动矢量预测(AMVP)和merge模式信令。
帧内预测单元206可以对当前视频块执行帧内预测。当帧内预测单元206对当前视频块执行帧内预测时,帧内预测单元206可以基于同一图片中的其它视频块的解码样点生成当前视频块的预测数据。当前视频块的预测数据可以包括预测视频块和各种语法元素。
残差生成单元207可以通过从当前视频块减去(例如,用减号表示)当前视频块的预测视频块来生成当前视频块的残差数据。当前视频块的残余数据可以包括对应于当前视频块中的样点的不同样点分量的残余视频块。
在其它示例中,对于当前视频块,可能没有当前视频块的残差数据,例如在跳过模式下,残差生成单元207可能不执行减法操作。
变换处理单元208可以通过将一个或多个变换应用于与当前视频块相关联的残差视频块,来为当前视频块生成一个或多个变换系数视频块。
在变换处理单元208生成与当前视频块相关联的变换系数视频块之后,量化单元209可以基于与当前视频块相关联的一个或多个量化参数(QP)值,来对与当前视频块相关联的变换系数视频块进行量化。
反量化单元210和反变换单元211可以分别对变换系数视频块应用反量化和反变换,以根据变换系数视频块重建残差视频块。重建单元212可以将重建的残差视频块添加到来自预测单元202生成的一个或多个预测视频块的对应样点中,以产生与当前块相关联的重建视频块,以存储在缓冲器213中。
在重建单元212重建视频块之后,可以执行环路滤波操作以减少视频块中的视频块伪像。
熵编码单元214可以从视频编码器200的其它功能组件接收数据。当熵编码单元214接收到数据时,熵编码单元214可以执行一个或多个熵编码操作以生成熵编码数据,并输出包括熵编码数据的比特流。
图8是示出视频解码器300的示例的框图,视频解码器300可以是图6所示的系统100中的视频解码器114。
视频解码器300可以被配置为执行本公开的任何或所有技术。在图8的示例中,视频解码器300包括多个功能组件。本公开中描述的技术可以在视频解码器300的各个组件之间共享。在一些示例中,处理器可以被配置为执行本公开中描述的任何或所有技术。
在图8的示例中,视频解码器300包括熵解码单元301、运动补偿单元302、帧内预测单元303、反量化单元304、反变换单元305、重建单元306和缓冲器307。在一些示例中,视频解码器300可以执行通常与关于视频编码器200描述的编码遍次(图7)相反的解码遍次。
熵解码单元301可以取回编码比特流。编码比特流可以包括熵编码的视频数据(例如,视频数据的编码块)。熵解码单元301可以对熵编码的视频数据进行解码,并且运动补偿单元302可以根据熵解码的视频数据确定运动信息,该运动信息包括运动向量、运动向量精度、参考图片列表索引以及其它运动信息。例如,运动补偿单元302可以通过执行AMVP和merge模式来确定这种信息。
运动补偿单元302可以产生运动补偿块,可能基于插值滤波器执行插值。语法元素中可以包括用于以子像素精度使用的插值滤波器的标识符。
运动补偿单元302可以使用视频编码器200在视频块编码期间使用的插值滤波器来计算参考块的子整数像素的插值。运动补偿单元302可以根据接收到的语法信息确定视频编码器200使用的插值滤波器,并使用插值滤波器来产生预测块。
运动补偿单元302可以使用一些语法信息来确定用于对编码视频序列的帧和/或条带进行编码的块的尺寸,描述如何对编码视频序列的图片的每个宏块进行分割的分割信息,指示如何对每个分区进行编码的模式,用于每个帧间编码块的一个或多个参考帧(和参考帧列表),以及用于对编码视频序列进行解码的其它信息。
帧内预测单元303可以使用例如在比特流中接收的帧内预测模式来根据空域上邻近的块形成预测块。反量化单元303对比特流中提供并由熵解码单元301解码的量化视频块系数进行反量化(即,去量化)。反变换单元303应用反变换。
重建单元306可以将残差块与由运动补偿单元202或帧内预测单元303生成的对应预测块相加,以形成解码块。如果需要,还可以应用去方块滤波器来对解码块进行滤波,以便移除块性伪像。解码视频块然后被存储在缓冲器307中,缓冲器307为后续运动补偿/帧内预测提供参考块,并且还产生解码视频以在显示设备上呈现。
图9示出了可以在例如图4至图8中所示的实施例中实现上述技术解决方案的示例方法。
图9示出了视频处理的示例方法900的流程图。方法900包括,在操作910,执行在媒体片段与媒体片段的比特流之间的转换,该转换符合格式规则和加密规则,并且格式规则规定在比特流中信令通知媒体片段的部分的完整性的指示。
接下来提供一些实施例优选的解决方案列表。
A1.一种处理数字媒体的方法,包括:执行媒体片段和媒体片段的比特流之间的转换,其中转换符合格式规则和加密规则,其中格式规则规定在比特流中信令通知媒体片段的部分的完整性的指示。
A2.解决方案A1的方法,其中,加密规则规定将消息摘要算法5(MD5)、安全哈希算法0(SHA-0)或安全哈希算法1(SHA-1)中的至少一个应用于媒体片段的部分。
A3.解决方案A1的方法,其中,格式规则规定媒体片段的区域受到约束,并且其中格式规则还规定基于媒体片段的颜色格式,使用色度单位或亮度单位来测量区域。
A4.解决方案A3的方法,其中,由于媒体片段的颜色格式为400,所以使用亮度单位来测量区域。
A5.解决方案A3的方法,其中,由于媒体片段的颜色格式不同于400,所以使用色度单位来测量区域。
A6.解决方案A1的方法,其中加密规则规定将后量子密码术方法应用于媒体片段的部分。
A7.解决方案A6的方法,其中后量子密码术方法是扩展的Merkle签名方案(XMSS)。
A8.解决方案A6的方法,其中后量子密码术方法是Leighton-Micali签名(LMS)。
A9.解决方案A6的方法,其中后量子密码术方法包括基于代码的密码术。
A10.解决方案A9的方法,其中基于代码的密码术包括McEliece公钥加密系统。
A11.解决方案A9的方法,其中,基于代码的密码术包括Niederreiter加密算法。
A12.解决方案A1的方法,其中比特流还包括公钥指纹或短期公钥指纹。
A13.解决方案A12的方法,其中公钥指纹包括128位消息摘要算法5(MD5)指纹或12位安全哈希算法1(SHA-1)指纹。
A14.解决方案A12的方法,其中公钥指纹包括160位消息摘要算法5(MD5)指纹或12位安全哈希算法1(SHA-1)指纹。
A15.解决方案A12的方法,其中与公钥指纹相关联的信息包括用户认证信息。
A16.解决方案A1的方法,其中比特流还包括公钥或短期公钥。
A17.解决方案A16的方法,其中使用一个或多个可信服务器来分发公钥。
A18.解决方案A16的方法,其中公钥在补充增强信息(SEI)消息中发送,并且其中在SEI消息中信令通知颜色分量、颜色格式、单色图片或SEI消息的使用的指示。
A19.解决方案A18的方法,其中指示是1位指示。
A20.解决方案A18的方法,其中指示等于(ChromaFormatIdc==0)或(sps_chroma_format_idc==0)。
A21.解决方案A1至A20中任一项的方法,其中转换包括从比特流解码媒体片段。
A22.解决方案A1至A20中任一项的方法,其中转换包括将媒体片段编码成比特流。
A23.一种将表示媒体片段的比特流存储到计算机可读记录介质的方法,包括:
根据解决方案A1至A20中任一项或多项的方法从媒体片段生成比特流;和
将比特流存储在计算机可读记录介质中。
A24.一种视频处理装置,包括被配置为实现解决方案A1至A23中任一项或多项的方法的处理器。
A25.一种其上存储有指令的计算机可读介质,指令在被执行时使处理器实现解决方案A1至A23中的一项或多项的方法。
A26.一种存储根据解决方案A1至A23中任一项或多项生成的比特流的计算机可读介质。
A27.一种用于存储比特流的视频处理装置,其中数字媒体处理装置被配置为实现解决方案A1至A23中任一项或多项的方法。
接下来提供了一些实施例优选的解决方案的另一列表。
P1.一种数字媒体处理方法,包括通过处理媒体片段的部分来执行媒体片段的编码表示的完整性的验证;以及根据验证的结果呈现媒体片段的编码表示的解码版本。
P2.解决方案P1的方法,其中执行验证包括将该部分的解码版本的安全哈希值与包括在编码表示中的安全哈希值进行比较。
P3.解决方案P1的方法,其中执行验证包括认证媒体片段和/或媒体片段的部分的编码表示的数字签名。
P4.解决方案P1的方法,其中媒体段的编码表示包括时间戳,并且执行验证包括通过从可信源获得安全信息并验证安全信息与时间戳匹配来验证时间戳的完整性。
P5.解决方案P1至P4中任一个的方法,其中编码表示携带指示媒体片段的部分的语法元素。
P6.解决方案P5的方法,其中语法元素包括补充增强信息(SEI)。
P7.解决方案P1至P6中任一项的方法,其中媒体片段包括包含一个或多个图片的视频,并且其中媒体片段的部分对应于一个或多个条带、子图片、片、编解码树单元或编解码树单元行。
P8.解决方案P7的方法,其中媒体片段的部分包括视频图片的内部部分,并且其中执行验证包括按顺序计算内部部分中所有像素的像素值的哈希。
P9.解决方案P8的方法,其中在编码表示中规定顺序。
P10.解决方案P8的方法,其中该顺序是预先规定的,并且是锯齿形顺序或光栅扫描顺序。
P11.解决方案P1至P10中任一项的方法,其中处理媒体片段的部分包括解码媒体片段。
P12.解决方案P1至P11中任一项的方法,其中呈现解码版本包括仅呈现通过验证的编码表示的部分。
P13.解决方案P1至P11中任一项的方法,其中呈现解码版本包括从呈现中省略验证结果为不肯定的媒体片段的部分。
P14.解决方案P1至P11中任一项的方法,其中呈现解码版本包括呈现媒体片段和验证结果的指示。
P15.一种数字媒体处理方法,包括生成媒体片段的编码表示;为媒体片段的启用验证媒体片段的编码表示的完整性的部分生成验证信息;以及提供编码表示和验证信息,用于媒体解码器对媒体片段的验证和呈现。
P16.解决方案P15的方法,其中该验证包括将该部分的解码版本的安全哈希值与编码表示中包括的安全哈希值进行比较。
P17.解决方案P15的方法,其中验证包括认证媒体片段和/或媒体片段的部分的编码表示的数字签名。
P18.解决方案P15的方法,其中媒体片段的编码表示包括时间戳,并且通过从可信源获得安全信息并验证安全信息与时间戳匹配来验证时间戳的完整性,从而执行验证。
P19.解决方案P15至P18中任一项的方法,其中编码表示携带指示媒体片段的部分的语法元素。
P20.解决方案P19的方法,其中语法元素包括补充增强信息(SEI)。
P21.解决方案P15至P20中任一项的方法,其中媒体片段包括包含一个或多个图片的视频,并且其中媒体片段的部分对应于一个或多个条带、子图片、片、编解码树单元或编解码树单元行。
P22.解决方案P21的方法,其中媒体片段的部分包括视频图片的内部部分,并且其中执行验证包括按顺序计算内部部分中所有像素的像素值的哈希。
P23.解决方案P22的方法,其中在编码表示中规定顺序。
P24.解决方案P22的方法,其中该顺序是预先规定的,并且是锯齿形顺序或光栅扫描顺序。
P25.解决方案P15至P24中任一项的方法,其中处理媒体片段的部分包括解码媒体片段。
P26.解决方案P15至P25中任一项的方法,其中呈现解码版本包括仅呈现通过验证的编码表示的部分。
P27.解决方案P15至P26中任一项的方法,其中呈现解码版本包括从呈现中省略验证结果为不肯定的媒体片段的部分。
P28.解决方案P15至P26中任一项的方法,其中呈现解码版本包括呈现媒体片段和验证结果的指示。
P29.一种视频处理方法,包括在媒体片段与视频片段的比特流表示之间执行转换,其中该转换符合格式规则或加密规则。
P30.解决方案P29的方法,其中比特流包括媒体片段的安全哈希函数结果。
P31.解决方案P29至P30中任一项的方法,其中比特流包括基础编解码视频流的加密版本。
P32.解决方案P31的方法,其中加密版本基于DSA或RSA或ECDSA加密/解密协议。
P33.解决方案P1至P32中任一项的方法,其中媒体片段是视频的一个或多个网络抽象层(NAL)。
P34.解决方案P1至P32中任一项的方法,其中媒体片段对应于视频层。
P35.解决方案P1至P32中任一项的方法,其中媒体片段表示视频的区域。
P36.解决方案P1至P32中任一项的方法,其中媒体片段是视频。
P37.解决方案P1到P32的方法,其中媒体片段是音频。
P38.解决方案P1到P32的方法,其中媒体片段是图像。
P39.解决方案P1至P31中任一项的方法,其中媒体片段的部分包括媒体片段的空域部分。
P40.解决方案P1至P39中任一项的方法,其中媒体片段的部分包括媒体片段的时域部分。
P41.解决方案P1至P39中任一项的方法,其中媒体片段的部分包括少于整个媒体片段。
P42.解决方案P1至P39中任一项的方法,其中媒体片段的部分包括所有媒体片段。
P43.一种媒体处理装置,包括处理器,该处理器被配置成实现解决方案P1至P42中的任何一个或多个中所述的方法。
P44.一种计算机程序产品,包括其上存储有代码的计算机可读介质,该代码在由处理器执行时,使得处理器实现解决方案P1至P42中的任何一个或多个中所述的方法。
P45.本文档中描述的方法、装置或系统。
在本文档中,术语“媒体处理”可以指媒体编码、媒体解码、媒体压缩或媒体解压缩。术语媒体可以指视频、音频和图像。例如,在从视频的像素表示到对应的比特流的转换期间,可以应用视频压缩算法,反之亦然。如语法所定义,当前视频块的比特流可例如对应于并置或散布在比特流内不同位置的位。例如,可以根据经变换和编解码的误差残余值,并且还使用比特流中的标头和其他字段中的位,对宏块进行编码。此外,在转换期间,解码器可以基于如以上解决方案中所述的确定,在知道一些字段可能存在或不存在的情况下解析比特流。类似地,编码器可确定包括或不包括某些语法字段,并通过从编解码表示中包括或排除语法字段来相应地生成编解码表示。
本文档中描述的所公开的解决方案和其它解决方案、示例、实施例、模块和功能操作可以在以下各项中实现:数字电子电路,或计算机软件、固件或硬件,包括本文档中公开的结构及其结构等同物,或上述各项的一个或多个的组合。所公开的实施例和其它实施例可以被实现为一个或多个计算机程序产品,即,编码在计算机可读介质上的计算机程序指令的一个或多个模块,用于由数据处理装置执行或控制其操作。计算机可读介质可以是机器可读存储设备、机器可读存储基板、存储器设备、影响机器可读传播信号的物质的组合物,或者一个或多个它们的组合。术语“数据处理装置”包含用于处理数据的所有装置、设备和机器,例如包括可编程处理器、计算机或多个处理器或计算机。除了硬件之外,该装置还可以包括为所讨论的计算机程序创建执行环境的代码,例如,构成处理器固件、协议栈、数据库管理系统、操作系统或其中一个或多个的组合的代码。传播信号是人为生成的信号,例如,机器生成的电气、光学或电磁信号,其被生成以对信息进行编码以传输到合适的接收器装置。
计算机程序(也称为程序、软件、软件应用、脚本或代码)可以用任何形式的编程语言编写,包括编译或解释语言,并且其也可以以任何形式部署,包括作为独立程序或模块、组件、子例程或其它适合在计算环境中使用的单元。计算机程序不一定与文件系统中的文件相对应。程序可以被存储在保存其它程序或数据的文件部分(例如,标记语言文档中存储的一个或多个脚本)、专用于相关程序的单个文件或多个协调文件(例如,存储一个或多个模块、子程序或代码部分的文件)中。计算机程序可以被部署以在一台计算机上执行,或在位于一个站点或分布在多个站点并通过通信网络互连的多台计算机上执行。
本文档中描述的过程和逻辑流可以由一个或多个可编程处理器执行,这些计算机程序执行一个或多个计算机程序以通过对输入数据进行操作并生成输出来执行功能。过程和逻辑流还可以由专用逻辑电路执行,并且装置还可以实现为专用逻辑电路,例如FPGA(现场可编程门阵列)或ASIC(专用集成电路)。
例如,适合执行计算机程序的处理器包括通用和专用微处理器,以及任何类型的数字计算机的任何一个或多个处理器。通常,处理器将从只读存储器或随机存取存储器或两者中接收指令和数据。计算机的基本元件是用于执行指令的处理器和用于存储指令和数据的一个或多个存储器设备。通常,计算机还将包括或被操作地耦合以从一个或多个用于存储数据的大容量存储设备(例如,磁盘、磁光盘或光盘)接收数据或向其传输数据。然而,计算机不需要这样的设备。适于存储计算机程序指令和数据的计算机可读介质包括所有形式的非易失性存储器、介质和存储器设备,包括例如半导体存储器设备,例如EPROM、EEPROM和闪速存储器设备;磁盘,例如内部硬盘或可移动磁盘;磁光盘;以及CD-ROM和DVD-ROM光盘。处理器和存储器可以由专用逻辑电路补充或并入专用逻辑电路中。
尽管本专利文档包含许多细节,但这些细节不应当被解释为对任何主题或要求保护的内容的范围的限制,而应当被解释为对特定的技术的特定的实施例所特有的特征的描述。本专利文档中在单独实施例的上下文中描述的某些特征也可以在单个实施例中组合实现。相反地,在单个实施例的上下文中描述的各种特征也可以在多个实施例中单独地或在任何合适的子组合中实现。此外,尽管上述特征可以被描述为以特定组合起作用,甚至最初被声称为这样,但在一些情况下,可以从所要求保护的组合中删除一个或多个特征,并且所要求保护的组合可以指向子组合或子组合的变体。
类似地,尽管在附图中以特定的顺序描述这些操作,但这不应当被理解为要求按照所示的特定的顺序或序列顺序执行这样的操作,或要求所有示出的操作被执行,以获得理想的结果。此外,本专利文档中描述的实施例中的各种系统组件的分离不应当理解为在所有实施例中都要求这种分离。
仅描述了一些实现和示例,并且其它实现、增强和变体可以基于本专利文档中描述和说明的内容进行。

Claims (27)

1.一种处理数字媒体的方法,包括:
执行媒体片段和所述媒体片段的比特流之间的转换,
其中所述转换符合格式规则和加密规则,
其中所述格式规则规定在所述比特流中信令通知所述媒体片段的部分的完整性的指示。
2.根据权利要求1所述的方法,其中,所述加密规则规定将消息摘要算法5(MD5)、安全哈希算法0(SHA-0)或安全哈希算法1(SHA-1)中的至少一个应用于所述媒体片段的部分。
3.根据权利要求1所述的方法,其中,所述格式规则规定所述媒体片段的区域受到约束,并且其中所述格式规则还规定基于所述媒体片段的颜色格式,使用色度单位或亮度单位来测量所述区域。
4.根据权利要求3所述的方法,其中,由于所述媒体片段的颜色格式为4:0:0,所以使用所述亮度单位来测量所述区域。
5.根据权利要求3所述的方法,其中,由于所述媒体片段的颜色格式不同于4:0:0,所以使用所述色度单位来测量所述区域。
6.根据权利要求1所述的方法,其中,所述加密规则规定将后量子密码术方法应用于所述媒体片段的部分。
7.根据权利要求6所述的方法,其中,所述后量子密码术方法是扩展的Merkle签名方案(XMSS)。
8.根据权利要求6所述的方法,其中,所述后量子密码术方法是Leighton-Micali签名(LMS)。
9.根据权利要求6所述的方法,其中,所述后量子密码术方法包括基于代码的密码术。
10.根据权利要求9所述的方法,其中,所述基于代码的密码术包括McEliece公钥加密系统。
11.根据权利要求9所述的方法,其中,所述基于代码的密码术包括Niederreiter加密算法。
12.根据权利要求1所述的方法,其中,所述比特流还包括公钥指纹或短期公钥指纹。
13.根据权利要求12所述的方法,其中,所述公钥指纹包括128位消息摘要算法5(MD5)指纹或12位安全哈希算法1(SHA-1)指纹。
14.根据权利要求12所述的方法,其中,所述公钥指纹包括160位消息摘要算法5(MD5)指纹或12位安全哈希算法1(SHA-1)指纹。
15.根据权利要求12所述的方法,其中,与所述公钥指纹相关联的信息包括用户认证信息。
16.根据权利要求1所述的方法,其中,所述比特流还包括公钥或短期公钥。
17.根据权利要求16所述的方法,其中,使用一个或多个可信服务器来分发所述公钥。
18.根据权利要求16所述的方法,其中,所述公钥在补充增强信息(SEI)消息中发送,并且其中,在所述SEI消息中信令通知颜色分量、颜色格式、单色图片或所述SEI消息的使用的指示。
19.根据权利要求18所述的方法,其中,所述指示是1位指示。
20.根据权利要求18所述的方法,其中,所述指示等于(ChromaFormatIdc==0)或(sps_chroma_format_idc==0)。
21.根据权利要求1至20中任一项所述的方法,其中,所述转换包括从所述比特流解码所述媒体片段。
22.根据权利要求1至20中任一项所述的方法,其中,所述转换包括将所述媒体片段编码成所述比特流。
23.一种将表示媒体片段的比特流存储到计算机可读记录介质的方法,包括:
根据权利要求1至20中任一项或多项所述的方法从所述媒体片段生成所述比特流;和
将所述比特流存储在计所述算机可读记录介质中。
24.一种视频处理装置,包括被配置为实现权利要求1至23中任一项或多项所述的方法的处理器。
25.一种其上存储有指令的计算机可读介质,所述指令在被执行时使处理器实现权利要求1至23中的一项或多项所述的方法。
26.一种存储根据权利要求1至23中任一项或多项生成的比特流的计算机可读介质。
27.一种用于存储比特流的视频处理装置,其中数字媒体处理装置被配置为实现权利要求1至23中任一项或多项所述的方法。
CN202180067097.6A 2020-09-30 2021-09-30 视频编解码中的图像分割 Pending CN116249981A (zh)

Applications Claiming Priority (3)

Application Number Priority Date Filing Date Title
US202063085906P 2020-09-30 2020-09-30
US63/085,906 2020-09-30
PCT/US2021/053008 WO2022072723A1 (en) 2020-09-30 2021-09-30 Picture partitioning in video coding

Publications (1)

Publication Number Publication Date
CN116249981A true CN116249981A (zh) 2023-06-09

Family

ID=80951848

Family Applications (1)

Application Number Title Priority Date Filing Date
CN202180067097.6A Pending CN116249981A (zh) 2020-09-30 2021-09-30 视频编解码中的图像分割

Country Status (3)

Country Link
US (1) US20230246834A1 (zh)
CN (1) CN116249981A (zh)
WO (1) WO2022072723A1 (zh)

Family Cites Families (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
EA015549B1 (ru) * 2003-06-05 2011-08-30 Интертраст Текнолоджис Корпорейшн Переносимая система и способ для приложений одноранговой компоновки услуг
JP5996439B2 (ja) * 2010-02-19 2016-09-21 テレフオンアクチーボラゲット エルエム エリクソン(パブル) Httpストリーミングにおける表現切り替えのための方法及び装置
WO2015056182A2 (en) * 2013-10-15 2015-04-23 Nokia Technologies Oy Video encoding and decoding
US10747888B2 (en) * 2014-06-30 2020-08-18 Nicira, Inc. Method and apparatus for differently encrypting data messages for different logical networks
US20170214701A1 (en) * 2016-01-24 2017-07-27 Syed Kamran Hasan Computer security based on artificial intelligence

Also Published As

Publication number Publication date
WO2022072723A1 (en) 2022-04-07
US20230246834A1 (en) 2023-08-03

Similar Documents

Publication Publication Date Title
RU2584501C1 (ru) Способ и устройство для видеокодирования
EP1995965A1 (en) Method and apparatus for video frame marking
CN115280791B (zh) 一种数字媒体处理方法、装置及计算机可读介质
US9740886B2 (en) Enhanced security for hardware decoder accelerator
JP2022100261A (ja) 修飾されたビデオのエンコーディング
US20230246834A1 (en) Picture partitioning in video coding
US20230020655A1 (en) Indication of digital medial integrity
US20240171780A1 (en) General region-based hash
CN115278243A (zh) 对抗深度学习人脸攻击的实时视频加密方法及装置
EP4369725A1 (en) Transcodable signed video data
EP4369704B1 (en) Signing video for reduced bit rate
US20230179787A1 (en) Method and device for signing an encoded video sequence
US20240259580A1 (en) Transmitter, a receiver and methods therein for validation of a video sequence
US20240187582A1 (en) Method for verifying video data encoded in an encoder unit
CN116800446A (zh) 一种视频加密、解密方法及装置
CN118338045A (zh) 视频码流加密方法、视频码流解密方法及相关装置
CN117640958A (zh) 视频码流的认证方法、计算机设备及存储介质
CN117651146A (zh) 视频码流的认证方法、计算机设备及存储介质
Ramaswamy A video authentication scheme using Digital Signature Standard and Secure Hash algorithm for H. 264/AVC Main Profile
Chen et al. A Novel Stream Video Integrity Method.

Legal Events

Date Code Title Description
PB01 Publication
PB01 Publication
SE01 Entry into force of request for substantive examination
SE01 Entry into force of request for substantive examination