添加标注、引用文档说明

wangwei1237 · Nov 4, 2019 · 102e9d7 · 102e9d7
1 parent c228b19
commit 102e9d7
Show file tree

Hide file tree

Showing 7 changed files with 31 additions and 30 deletions.
diff --git a/docs/3_1_2_H261.md b/docs/3_1_2_H261.md
@@ -1,6 +1,6 @@
 # H.261标准
 
-H.261是业界采用的第一个重要且实用的数字视频编码标准。它是p×64kbps视听服务的视频编码标准（其中p = 1，...，30），旨在通过ISDN提供视频电话和视频会议服务，并将此类应用视频传输的各个方面统一到同一标准上。目标包括以最小的延迟实时传输视频（通常是15-30fps，延迟小于150ms）。尽管作为一个成功的数字视频编码标准，其提供了全行业的互操作性、通用格式和压缩技术，但是H.261已过时，且如今已经很少使用了。
+H.261是业界采用的第一个重要且实用的数字视频编码标准。它是p×64kbps视听服务的视频编码标准（其中p = 1，...，30），旨在通过ISDN提供视频电话和视频会议服务，并将此类应用视频传输的各个方面统一到同一标准上[^1]。目标包括以最小的延迟实时传输视频（通常是15-30fps，延迟小于150ms）。尽管作为一个成功的数字视频编码标准，其提供了全行业的互操作性、通用格式和压缩技术，但是H.261已过时，且如今已经很少使用了。
 
 在H.261标准中，所有编解码器必须以四分之一公共中间格式（Quarter Common Intermediate Format，QCIF）的视频格式进行操作，而CIF的使用是可选的。由于CIF和QCIF在29.97fps下的未压缩视频比特率分别为26.45 Mbps和9.12 Mbps，因此在提供正常的视频质量的同时，使用ISDN通道传输这些视频信号非常困难。为了实现此目标，H.261将视频划分为分层的块结构，该结构包括图片，块组（GOB），宏块（MB）和块。一个宏块由四个8×8亮度块和两个8×8色度块组成；3×11的宏块阵列又构成一个块组。一个QCIF图片具有三个块组，而一个CIF图片则有12个。分层数据结构如图3-2所示。
 
@@ -16,20 +16,7 @@ H.261源编码算法是帧内和帧间编码的混合，利用了空间和时间
 
 **图3-3.**ITU-T H.261源编码器框图
 
-
-
-
-
-
-
-
-
-
-
-
-
-
-
+[^1]: M. L. Liou, “Overview of the px64 kbit/s Video Coding Standard,” Communications of the ACM 34, no. 4 (April 1991): 60–63.
 
 
 

diff --git a/docs/3_1_7_AVC.md b/docs/3_1_7_AVC.md
@@ -34,7 +34,7 @@ AVC视频编码标准与之前的MPEG-4 Part 2，MPEG-2，H.263，MPEG-1和H.261
 
 除了上述配置之外，可伸缩视频编码（SVC）扩展定义了另外五个可伸缩配置：可伸缩受约束基准配置、可伸缩基准配置、可伸缩高级配置、可伸缩受约束高级配置和可伸缩高级内部配置。同时，多视图编码（MVC）扩展为三维视频添加了三个配置，即“立体声高级配置”，“多视图高级配置”和“多视图深度高级配置”。此外，为专业编辑应用程序定义了四个帧内配置：高级10帧内配置，高级4:2:2帧内配置，高级4:4:4帧内配置和CAVLC 4:4:4帧内配置。
 
-级别是用于指定配置所需的解码器性能程度的约束；例如，一个级别指定解码器必须遵守的最大图片分辨率、比特率、帧速率等。表3-2给出了一些级别限制的示例。有关完整说明，请参见标准规范。
+级别是用于指定配置所需的解码器性能程度的约束；例如，一个级别指定解码器必须遵守的最大图片分辨率、比特率、帧速率等。表3-2给出了一些级别限制的示例。有关完整说明，请参见标准规范[^2]。
 
 **表3-2.**AVC级别限制示例
 
@@ -183,7 +183,7 @@ AVC提供了增强信道错误恢复能力的功能，其中包括NAL单元、
 
 * 冗余切片（RS）：这是AVC中的错误恢复功能，允许编码器发送切片数据的额外表示形式，通常以较低的保真度发送。万一主要数据片因通道错误而丢失或损坏，可以使用此表示形式。
 
-
+[^2]: ITU-T Rec. H.264: Advanced Video Coding for Generic Audiovisual Services (Geneva, Switzerland: International Telecommunications Union, 2007).
 
 
 

diff --git a/docs/3_1_8_HEVC.md b/docs/3_1_8_HEVC.md
@@ -24,7 +24,7 @@ HEVC简化了编码，并且不支持任何隔行扫描工具，因为隔行扫
 
 ## 配置文件和级别
 
-HEVC定义了三个配置文件：“主要”配置文件，“主要10”配置文件和“静态图片”配置文件，其中“主”是目前最常用的配置文件。它需要4:2:0的颜色格式，并施加了一些限制；例如，位深度应为8，形成矩形图块的LCU组必须至少为256×64，依此类推（在本章的稍后部分中，将对并行处理工具进行详细说明）。HEVC指定了许多级别，范围从1到6.2。6.2级别比特流在120fps时可支持8192×4320的高分辨率。
+HEVC定义了三个配置文件：“主要”配置文件，“主要10”配置文件和“静态图片”配置文件，其中“主”是目前最常用的配置文件。它需要4:2:0的颜色格式，并施加了一些限制；例如，位深度应为8，形成矩形图块的LCU组必须至少为256×64，依此类推（在本章的稍后部分中，将对并行处理工具进行详细说明）。HEVC指定了许多级别，范围从1到6.2。6.2级别比特流在120fps时可支持8192×4320的高分辨率[^3]。
 
 ## 帧内预测
 
@@ -80,3 +80,5 @@ HEVC标准中具有三个新功能，以支持增强的并行处理能力或出
 
 编码树块的序列称为切片。构成视频帧的图片可以分为任意数量的切片，或者整个图片可以只是一个切片。依次地，每个切片被分成一个或多个切片段，每个切片段以其自己的NAL单元。切片中只有第一个切片片段包含完整的切片标头，其余片段称为从属切片片段。这样，解码器必须能够访问第一切片片段以成功解码。切片的这种划分允许图片的低延迟传输，而无需支付由于许多切片头而原本会引起的任何编码效率损失。例如，摄像机可以发出属于第一CTB行的切片片段，以便网络另一侧的播放设备可以在摄像机发出下一CTB行之前开始解码。这在诸如视频会议之类的低延迟应用中很有用。
 
+[^3]: ITU-T Rec. H.265: High Efficiency Video Coding (Geneva, Switzerland: International Telecommunications Union, 2013).
+
diff --git a/docs/3_1_9_InternationalStandardsForVideoQuality.md b/docs/3_1_9_InternationalStandardsForVideoQuality.md
@@ -8,11 +8,11 @@
 
  VQEG采用了一种系统化的验证测试方法，通常包括几个视频数据库，需要使用这些视频数据库来预测主观视觉质量的客观模型，并且他们定义了执行客观模型验证的测试计划和程序。最初的标准由ITU-T第9研究组于2000年作为J.144建议书发布，但是所研究的各种方法都没有优于众所周知的峰值信噪比（PSNR）。2003年，发布了J.144的更新版本，其中推荐了四个客观模型用于有线电视服务。ITU-R第6研究组的镜像标准作为ITU-RBT.1683建议书发布，用于基带电视服务。
 
-针对数字视频和多媒体应用的最新研究（称为多媒体第一阶段（MM-I）于2008年完成。MM-I测试集用于验证全参考（FR）、简化参考（ RR）、无参考（NR）客观模型（将在第4章中详细讨论这些模型）。使用单刺激呈现方法和绝对类别评分（ACR）等级对主观视频质量进行评估。无需识别视频，对包含源视频的视频序列进行一次主观评估，并且根据国际电联五级质量等级，进行独立评估。计算平均意见分数（MOS）和差异平均意见分数（DMOS），其中DMOS是已处理视频的分数与源视频的分数相比的算术差异的平均值，以便删除任何隐藏的内容。用于控制和运行VQEG多媒体测试的软件称为AcrVQWin。（主观质量评估方法和技术的详细信息已收录在ITU-T建议书P.910，P.912等，并在第4章将会进行讨论）
+针对数字视频和多媒体应用的最新研究（称为多媒体第一阶段（MM-I）于2008年完成。MM-I测试集用于验证全参考（FR）、简化参考（ RR）、无参考（NR）客观模型（将在第4章中详细讨论这些模型）。使用单刺激呈现方法和绝对类别评分（ACR）等级对主观视频质量进行评估。无需识别视频，对包含源视频的视频序列进行一次主观评估，并且根据国际电联五级质量等级，进行独立评估。计算平均意见分数（MOS）和差异平均意见分数（DMOS），其中DMOS是已处理视频的分数与源视频的分数相比的算术差异的平均值，以便删除任何隐藏的内容。用于控制和运行VQEG多媒体测试的软件称为AcrVQWin[^4]。（主观质量评估方法和技术的详细信息已收录在ITU-T建议书P.910，P.912等，并在第4章将会进行讨论）
 
 ## IEEE标准1180-1990
 
-主要用于可视电话和类似应用中，重构环路使用了8x8逆离散余弦逆变换（IDCT）的结果。IEEE标准1180-19905指定了8x8IDCT的数字特性。这些规范确保了IDCT的不同实现之间的兼容性。来自不同制造商的编码器和解码器中不同的IDCT实现可能会导致失配错误；由于系统中的重建循环，失配误差可能会在视频持续时间内传播。IEEE标准不是将所有制造商限制在一个严格的实施范围内，而是允许在特定时间段内出现小的失配，同时使用帧内编码帧定期刷新视频，例如，对于ITU-T可视电话应用，持续时间是132帧。
+主要用于可视电话和类似应用中，重构环路使用了8x8逆离散余弦逆变换（IDCT）的结果。IEEE标准1180-19905[^5]指定了8x8IDCT的数字特性。这些规范确保了IDCT的不同实现之间的兼容性。来自不同制造商的编码器和解码器中不同的IDCT实现可能会导致失配错误；由于系统中的重建循环，失配误差可能会在视频持续时间内传播。IEEE标准不是将所有制造商限制在一个严格的实施范围内，而是允许在特定时间段内出现小的失配，同时使用帧内编码帧定期刷新视频，例如，对于ITU-T可视电话应用，持续时间是132帧。
 
 标准规定失配误差应满足以下要求：
 
@@ -28,7 +28,7 @@
 
 * 对于全零输入，建议的IDCT将生成全零输出。
 
+[^4]: K. Brunnstrom, D. Hands, F. Speranza, and A. Webster, “VQEG Validation and ITU Standardization of Objective Perceptual Video Quality Metrics,” IEEE Signal Processing (May 2009):96-101; software available at www.acreo.se/acrvqwin.
 
-
-
+[^5]: The IEEE Standard Board, IEEE Standard Specifications for the Implementations of 8x8 Inverse Discrete Cosine Transform (New York, USA: Institute of Electrical and Electronics Engineers, 1991).
 
diff --git a/docs/3_2_2_VP8.md b/docs/3_2_2_VP8.md
@@ -1,16 +1,18 @@
 # VP8视频压缩技术
 
-通过收购On2科技公司，Google成为VP8视频压缩格式的所有者。2011年11月，国际工程任务组（IETF）将VP8数据格式和解码指南发布为RFC 63866。谷歌还根据BSD许可证发布了VP8编解码器库软件libvpx。Opera，FireFox和Chrome浏览器以及各种基于硬件和软件的视频编解码器（包括Intel集成处理器图形硬件）目前支持VP8。
+通过收购On2科技公司，Google成为VP8视频压缩格式的所有者。2011年11月，国际工程任务组（IETF）将VP8数据格式和解码指南发布为RFC 63866[^6]。谷歌还根据BSD许可证发布了VP8编解码器库软件libvpx。Opera，FireFox和Chrome浏览器以及各种基于硬件和软件的视频编解码器（包括Intel集成处理器图形硬件）目前支持VP8。
 
 像许多现代视频压缩方案一样，VP8的基础是将帧分解为像素的方形子块，使用先前构造的块对此类子块进行预测，并使用离散余弦变换（DCT）调整这种预测，或者在一种特殊情况下，Walsh-Hadamard变换（WHT）。该系统旨在通过指定前一帧的视觉相似部分的位置来利用视频信号的时间相干性来降低数据速率，并利用DCT和WHT提供的频率隔离以及信号的容忍度来降低空间相干性。为了减轻保真度编解码器的损失，人类视觉系统使用三种不同的参考帧进行帧间预测：前序帧，黄金帧和altref帧，以提供时间可伸缩性。
 
 VP8编解码器将数据分区应用于编码数据。每个编码的VP8帧分为两个或多个分区，包括未压缩部分，后跟压缩头信息和每个宏块信息，这些信息指定如何预测每个宏块。第一分区包含所有宏块的预测模式参数和运动矢量。其余分区均包含残差的量化DCT或WHT系数。每帧可以有一个，两个，四个或八个DCT/WHT分区，具体取决于编码器设置。可以在RFC 6386中找到该算法的详细信息。
 
-Google提出了适用于传输使用VP8视频编解码器编码的视频流的RTP有效负载规范。RTP有效载荷格式可用于低比特率对等和高比特率视频会议应用程序中。RTP有效负载格式考虑了帧分区边界，以提高针对丢包的鲁棒性并促进错误隐藏。它还使用高级参考帧结构来实现有效的错误恢复和时间可伸缩性。此外，标记非参考帧是为了使服务器或支持媒体的网络能够根据需要丢弃适当的数据。
-
-用于浏览器应用程序编程接口（API）的IETF国际草案标准，称为Web实时通信（WebRTC），指定如果支持VP8，则使用双线性过滤器和无重建过滤器，帧速率至少为10帧每秒，并且必须支持从320×240到1280×720的分辨率。谷歌Chrome、Mozilla，FireFox和Opera浏览器支持WebRTC API，旨在用于基于浏览器的应用程序，包括视频聊天。谷歌Chrome操作系统也支持WebRTC。
+谷歌提出了适用于传输使用VP8视频编解码器编码的视频流的RTP有效负载规范[^7]。RTP有效载荷格式可用于低比特率对等和高比特率视频会议应用程序中。RTP有效负载格式考虑了帧分区边界，以提高针对丢包的鲁棒性并促进错误隐藏。它还使用高级参考帧结构来实现有效的错误恢复和时间可伸缩性。此外，标记非参考帧是为了使服务器或支持媒体的网络能够根据需要丢弃适当的数据。
 
+用于浏览器应用程序编程接口（API）的IETF国际草案标准，称为Web实时通信（WebRTC）[^8]，指定如果支持VP8，则使用双线性过滤器和无重建过滤器，帧速率至少为10帧每秒，并且必须支持从320×240到1280×720的分辨率。谷歌Chrome、Mozilla，FireFox和Opera浏览器支持WebRTC API，旨在用于基于浏览器的应用程序，包括视频聊天。谷歌Chrome操作系统也支持WebRTC。
 
+[^6]: J. Bankoski, J. Koleszar, L. Quillio, J. Salonen, P. Wilkins, and Y. Xu, “VP8 Data Format and Coding Guide, RFC 6386,” November 2011, retrieved from http://datatracker.ietf.org/doc/rfc6386/.
 
+[^7]: P. Westin, H. Lundin, M. Glover, J. Uberti, and F. Galligan, “RTP Payload Format for VP8 Video,” Internet draft, February 2014, retrieved from http://tools.ietf.org/html/draft-ietf-payload-vp8-11.
 
+[^8]: C. Bran, C. Jennings, J. M.Valin, “WebRTC Codec and Media Processing Requirement,” Internet draft, March 2012, retrieved from http://tools.ietf.org/html/draft-cbran-rtcweb-codec-02.