视频相关
B 帧在 MPEG-4 中有四种参考模式，如果是同时参考前后的画面压缩，
则记录的是 和 (前画面 pixel 值 + 后画面 pixel 值)/2 的差值，
也就是 和 「前后画面的平均」的差值。
所以记录的差值个数和 P 帧一样，只有一个，没有增加。
而因为 B 帧位于前后画面的中间，以「前后画面的平均」，也就是「前后画面的中间值」
来作为预测数值（预测 B 帧的 pixel 数值为多少？如果有误差，再记录差值），
这样这个预测数值会比单独使用前一个画面来预测，更接近目前真正的 B 帧的数值，
可想而知，如此所需要记录的差值就会很小甚至可以根本不用记录，
所以便可以省下很多的 bits，提高压缩率。
例如
亮度变化 ->
I B P
7 8 9
如果 B 只参考前一个画面压缩，则需记录差值 1。
如果以 (I + P)/2 压缩，则差值为 0，不需记录差值。
（虽然要记录两个矢量，不过矢量也可以再做进一步预测压缩，总的来说，
还是会比单独参考前一个画面压缩来得小很多）
如果画面不是这样变化怎么办？通常来讲画面都会是这样变化，
如果不是这样变化我们就不使用 B 帧
就算变化不是如此规则，换个方式想，B 帧可以参考的画面还是比 P 帧多，
再怎么找，也还是 B 帧可以找到误差更小的方块来使用的机率大
（因为可以选择、参考的对象较多），所以 B 帧还是比 P 帧的压缩率来得高。
（而且高很多，差距非常大）
除了压缩率以外，B 帧对画质的影响.....
是有的，因为 B 帧这种参考前后画面的特性，等于有内插（interpolation）的效果，所以可以减少噪讯。
MPEG-4 中的 B 帧，也是非常具有威力的，除了以前的三种参考模式，
还有 Direct Mode，连矢量的纪录都省了。
虽然 MPEG-4 之中有 4MV 的功能，可以记录四个矢量，不过编码器在压缩的时候会判断，
到底是使用 4MV 压出来的结果小，还是使用传统的方法压出来的结果小？
如果使用传统的方法压出来的结果小，便使用传统的方法记录，
如果使用 4MV 压出来的结果小，才使用 4MV 来记录。
（ps. 4MV 不会用在 backward 预测）
您可以观察 VirtualDub 压缩时画面上显示的蓝线，您会发现蓝线和蓝线之间通常会有很短的
蓝线插在中间，造成空隙，而且差距很大，这个就是夹在 P 之间的 B 在发挥压缩威力
如果是用 DivX 5 更明显，因为 DivX 5 只能够使用 IBPBPBPB... 这种一个 B 接一个 P 的形式，
所以画面上的蓝线就是「一长一短、一长一短」这样排列。
MPEG 储存的 YU(Cb)V(Cr) 格式是遵循 CCIR601，也就是 ITU-R BT.601 的规范，Y 亮度的范围是 16~235，UV(CbCr) 色度是以无色 =128 为中心，范围是 16~240。
一般民生消费产品使用的 MPEG 压缩，大都采用 YUV 4:2:0 的格式，也就是如果分办率是 720x576，则每个 Frame，Y 有 720x576 个点，U 只有 360x288 个点，V 也只有 360x288 个点。色度的信息只有亮度的 1/4。那么为什么不写 YUV 4:1:1（UV 和 Y 的比例是 1:4） 而要写 YUV 4:2:0？这是因为要区分取样的方式不同。YUV 4:1:1 是指水平 Y 取样四个点，UV 各只取样一个点，水平的 Y 和 UV 的取样比例是 4:1，也就是
Y Y Y Y 一个 U 一个 V ....
YUV 4:2:0 是指水平和垂直 Y 各取样两个点，UV 各只取样一个点，水平的取样比例是 2:1，重直的取样比例 2:1，也就是
Y Y
Y Y 一个 U 一个 V ....
和 YUV 4:1:1 一样，色度和亮度差 1/2 * 1/2 = 1/4，只是取样的方式不同。
而 MPEG 最常采用的 YUV 4:2:0 格式，其 UV 的取样位置，MPEG-1 和 MPEG-2 又不同（MPEG-4 是用和 MPEG-2 一样的取样位置）
MPEG-1
x 是 UV 的取样位置
MPEG-2
x 是 UV 的取样位置
了解了 YUV 4:2:0 以后，我们来看什么是 YV12，什么是 YUY2。
在个人计算机上，这些 YUV 读出来以后会以一些格式包装起来，送给软件或硬件处理。包装的方式分成两种，一种是 packed format，把 Y 和相对应的 UV 包在一起。另一种是 planar format，把 Y 和 U 和 V 三种分别包装，拆成三个 plane（平面）。
其中 YV12 和 YUY2 都是一种 YUV 的包装格式，而且两种都是 packed format。
YV12 和 YUY2 的不同，在于 YV12 是 YUV 4:2:0 格式，也就是 DVD/VCD 上原本储存的格式。YUY2 则是 YUV 4:2:2 格式，也就是
Y Y 一个 UV Y Y 一个 UV ....
水平取样比例是 1/2
重直取样比例是 1/1，也就是垂直 UV 和 Y 的个数一样多
以分辨率来讲，就是 Y 720x576 U 360x576 V 360x576。
至于详细的包装格式，这里就不画图了，请参考
http://www.fourcc.org/fccyuv.htm
http://msdn.microsoft.com/library/default.asp?url=/library/en-us/dnwmt/html/YUVFormats.asp
以 DVD/VCD 的播放来说，读出来的 YUV 4:2:0 包成 YV12 的格式，如果显示卡有支持 YV12 的 FourCC Codec，播放时就会直接走 DirectDraw YV12 Overlay，直接丢 YV12 的数据给显示卡处理，由显示卡去做 YUV 4:2:0 展开（内插补点）-> YUV 4:2:2 -> YUV 4:4:4 ->RGB32，也就是色彩空间转换的的工作。如果你的屏幕分辨率大于影片原始分办率，显示卡还要做 scaling，也就是放大画面的动作，将影片的分办率放大到和你的屏幕的分办率相同，例如 640x480 -> 1024x768。（内插补点，补出不足的点）
所以显示卡的 YUV 4:2:0 -> 4:4:4 内插补点的好坏第一个就影响 MPEG 的播放品质，如果显示卡的 interpolating filter 不好，色彩补得不够平滑，红色的部分（人眼对红色较敏感，特别容易看出）就会出现一格一格的锯齿状。
再来就是显示卡的 scaling filter，放大补点的好坏，放大补点不好，画面就容易出现锯齿或是变得模糊不够清晰。
YV12 是最多显示卡支持的格式，传输的资料只有 YUV 4:2:0，比 RGB32 少很多，速度最快，所以大部分的软件都用这种格式传送数据。然而这种格式在遇到 interlaced 场线交错的画面的时候，会发生色度译码错误的问题。这个问题说起来很复杂，再讲个这篇文章又会太长，有兴趣的人可以参考 DVD2AVI 作者的网页，他有详细的说明，这个译码错误的问题也是他撰写 DVD2AVI 这个软件的原因:
The decoding problem with interlaced frame of most software MPEG-2 decoders
http://arbor.ee.ntu.edu.tw/~jackei/dvd2avi/interlace/
另一种错误，发生在 progressive frame 上
http://www.hometheaterhifi.com/volume_8_2/dvd-benchmark-special-report-chroma-bug-4-2001.html
这个说起来太长，有机会我再解释。
另一种常见的格式，就是 YUY2，也有许多显示卡支持，PowerDVD 为了解决上述的交错线彩色信息译码错误的问题便是使用这种格式。YUY2 也就是 YUV 4:2:2 的一种包装形式，播放时软件会先自己做 YUV 4:2:0 -> YUV 4:2:2 的内插补点（upsampling），做好以后再将 YUV 4:2:2 包成 YUY2，走 DirectDraw YUY2 Overlay，直接丢资料给显示卡，由显示卡去做后续的 YUV 4:2:2 -> 4:4:4 -> RGB32 的工作。
我们再来看显示卡的 DirectDraw Overlay 什么时候会启动，这个很重要，因为由以上可知，如果不使用 DirectDraw Overlay，而走传统的 GDI（Graphic Display Interface）图形显示接口，显示速度会很慢
1. 无法使用 DirectDraw 硬件加速，无法使用硬件的内插补点和色彩空间转换，CPU 负担非常重
2. 直接传送 RGB32，数据量大。无法使用显示卡的 scaling/interpolating filter，放大到全屏幕，会锯齿方块一格一格的非常难看。
所以 DirectDraw Overlay 有没有启动非常重要，现在大部分的显示卡，即使在高分办率的时候，DirectDraw Overlay 还是会启动，尤其是 ATI 的显示卡，即使在超高分办率的时候还是可以启动。
但是大部分的显示卡都有一个限制，那就是影片的分办率，水平的点数必须能被 32 整除，这样才能使用 DirectDraw Overlay。所以 GKnot 的 resize 选项，水平部分会有一个 32 Mod（能被 32 整除）的限制，就是这个原因。由上述可知，720 的水平分办率不能被 32 整除，所以会有无法启动 DirectDraw Overlay 的危险，为了最大的兼容性，制作的影片水平分办率最好是能够被 32 整除。
附带一提，垂直高度最好是能够被 16 整除，因为 MPEG 压缩是以 16x16 的巨方块为单位压缩，不是 16 的倍数的高度会制造压缩困难，压缩后可能会出现压缩瑕疵。
最好是先做好 resize 再压缩，不要以原始的分办率 720x576 压缩，播放时才调整比例作实时 resize。
实时 resize 的效果无法和慢慢计算的高品质 resize 相比，画质会比较差，本来是想保留较多的原始讯息，结果播放时的 resize 不好，反而得不偿失。
提到 YV12，顺便聊一下最近引起热烈讨论的 Avisynth 2.5 alpha。
Avisynth 2.5 alpha 最大的特色，就是支持 YV12 直接处理。我们知道原始 MPEG 数据是 YUV 4:2:0，也就是 YV12 的格式，以前我们在做 DivX/XviD 压缩的时候，处理流程是：
DVD/VCD(YUV 4:2:0) -> DVD2AVI(YUV 4:2:0 -> YUV 4:2:2 -> YUV 4:4:4 -> RGB24) -> VFAPI(RGB24) -> TMPGEnc/AviUtl/VirtualDub(RGB24) -> DivX/XviD Codec(RGB24 -> YUV 4:2:0) -> MPEG-4(YUV 4:2:0)
ps. VFAPI 内部只能以 RGB24 传递数据，所以会转成 RGB24 输出
或是
DVD/VCD(YUV 4:2:0) -> MPG2DEC.DLL(YUV 4:2:0 -> YUV 4:2:2) -> Avisynth 2.0.x(只能用支援 YUV 4:2:2 的 filter，不能用 RGB24/32 的 filter) -> VirtualDub(YUV 4:2:2，不能使用 VD 的 filter，因为 VD 的 filetr 都是在 RGB32 上处理，压缩时要选 Fast recompress，才会直接原封不动的送 YUV 4:2:2，也就是 YUY2 的数据给 Codec 压缩) -> DivX/XviD Codec(YUV 4:2:2 -> YUV 4:2:0) -> MPEG-4(YUV 4:2:0)
所以以前的处理流程中间要经过好几次 YUV <-> RGB 的转换。这个转换是有损的，做得越多次，原始的色彩信息就损失的越严重。而且这个转换的计算又耗时。那么有人（Marc FD）就想到，反正最后转成 MPEG 都要存成 YUV 4:2:0 的格式，那么为什么不干脆一路到底，全程都以 YV12 处理，也就是所有的 filter 都改写成 YV12 的版本，直接在 YV12 上做调整色彩、滤噪讯、IVTC 等工作，这样
1. 处理的数据量少。（YV12 的资料，UV 比 YUY2 少一半，比 RGB 24/32 少更多）
2. 不用转换计算
所以速度快。再加上又可以避免 YUV <-> RGB 转换的损失，岂不是一举两得？
所以支持 YV12 的 Avisynth 2.5 就诞生了
但是目前 VirtualDub 还是不支持 YV12，即使选 Fast recompress，VD 还是会将 YV12 的输入转为 YUY2，所以要得到全程 YV12 处理的好处，必须使用 VirtualDubMod 这个软件才行，这个改版才有支持 YV12（一样要选 Fast recompress）。
不过因为我要用 TMPGEnc（只接受 RGB24/32），所以我还是没使用全程 YV12 的方法
因为前面提到了 YUV 的数值范围（Y: 16~235, UV: 16~240），之前 Doom9 上也有一篇 Lumi masking 的帖子在讨论这个，不过.....，所以我顺便转贴以前写的一篇文章给大家参考：
 引用 |
|
DVD/VCD/DV 等使用的 MPEG/MJPEG 压缩，记录的 YCbCr 格式，是遵循 ITU-R BT.601 的 规范，其数据范围（动态范围）为 Y（亮度）16~235，C（色度）以 128 为中心代表无色 ，范围 16~240。 做处理和显示的时候，YCbCr 要转为 RGB，其范围为 16~235。 但是计算机屏幕上，纯白的点，其 RGB 值为 (255,255,255)，纯黑的点， 其 RGB 为 (0,0,0)。所以 MPEG/MJPEG 所记录的纯白 (235,235,235) 在计算机屏幕上看起 来就不是纯白，纯黑 (16,16,16) 在计算机屏幕上看起来也不会是纯黑。 因此 DV 录下来的东西，拿到计算机上看，会觉得颜色变淡，好像照上了一层白纱。 同时因为数据范围（动态范围）缩小为 16~235，而不是全范围（Full Scale）0~255， 所以会觉得对比不足（最亮和最暗的差距缩小），不如在电视上看漂亮。 所以在计算机上看、编辑 DV AVI，必需要先做 Y/C 伸张，也就是将 Y/C 的动态由原来的 16~235 扩展到 0~255，然后转为 RGB 0~255，这样在计算机屏幕上看到的颜色才会是正确的 。以此为基准作颜色校正、各种滤镜处理，出来的结果才会是正确的。 经过 Y/C 伸张以后，然后才作各种的编辑。 最后要压成 DVD/VCD/DV 的时候，因为仍然是存成 MPEG/MJPEG 格式， 数据范围还是 16~235，所以已经做过 Y/C 伸张的影像在压缩之前，必须先做 Y/C 压缩， 把目前 RGB 0~255 的数据压缩为 16~235，然后转为 YCbCr 16~235，这样才会正确。 不然超过的数据在转为 YCbCr 16~235 的时候会被削掉（clipping）， 对比、颜色会完全错误。 如果没有编辑、修改画面的必要，只是要将 DV AVI 直接做成 DVD/VCD， 则可以不必做 Y/C 伸张，直接压缩为 DVD/VCD。 此时数据没有做过 Y/C 伸张，所以压缩的时候，不可以再做一次 Y/C 压缩然后压 MPEG， 否则做好的 DVD/VCD 即使在电视上播放，对比、颜色也会是错的。 总结： 原始数据以 MPEG/MJPEG 储存，为 Y/C 压缩过的数据， 修改编辑时需先做 Y/C 伸张之后再修改。 若做过 Y/C 伸张，压缩时需做 Y/C 压缩，出来的画面才是正确的。 若没做过 Y/C 伸张，压缩时不可以做 Y/C 压缩，出来的画面才是正确的。 以 TMPGEnc 这个压缩软件为例，压缩时预设是接收 0~255 的 RGB 数据， 先做 Y/C 压缩，然后才压 MPEG。 所以如果是 YCbCr 16~235 的数据要对画面做修改，必须使用 Descale CCIR601 这个滤镜 （CCIR601 就是 ITU-R BT.601，CCIR 是 ITU 以前的名字），把 Luminous, Chroma 两个 选项都推到 255（也就是做 Y/C 伸张），然后才做其它的编辑动作。 Descale CCIR601 的顺位要排第一位。 然后压缩时直接压缩便可以得到正确的结果。 如果没有要对画面做修改，则不必做 Y/C 伸张，但是压缩的时候必需要勾选 进阶设定--> 量子化行列（Quantize matrix）底下的 "Basic YCbCr ?出力" （Out YUV data as Basic YCbCr not CCIR601），这样 TMPGEnc 压缩时便不会 做 Y/C 压缩，压出来的颜色、对比才会正确。 总结： 如果原始数据是 YCbCr 16~235 有做 Y/C 伸张的话，压缩时直接压缩就好，不能勾选 "Basic YCbCr ?出力"。 没有做 Y/C 伸张的话，压缩时必须勾选 "Basic YCbCr ?出力"。 再以 Cinema Craft Encoder SP 这个压缩软件为例，设定选项的 "16 ??235" = TMPGEnc 不勾选 "Basic YCbCr ?出力" = 压缩时先做 Y/C 压缩 "0 ??255" = TMPGEnc 勾选 "Basic YCbCr ?出力" = 压缩时不做 Y/C 压缩 实际上 CCE SP 是用两个不同的 YUV <--> RGB 转换式，列在下面给有兴趣的人参考： "16 ??235" "0 ??255" 而 YC 伸张的计算式是（简略） Y' = (Y - 16) * 255 / (235 - 16) C' = C * 255 / (255 - (240-16)) 再来探讨两个问题，第一个是 DV Codec 在输出数据给压缩软件时，可能会输出两种格式 ，第一种是直接输出 YUV 4:1:1，由压缩软件自己去做 YUV --> RGB 的转换。 第二种是由 Codec 内部先做 YUV --> RGB 转换，再输出 RGB 给压缩软件。 如果 Codec 是输出 YUV 4:1:1，则转换后的 RGB 范围是 0~255（有做 Y/C 伸张） 还是 16~235（没做 Y/C 伸张），由执行转换的压缩软件决定。 如 TMPGEnc 的环境设定的选项中，有针对 Canopus DV Codec 做设定，提供你选择， YUV --> RGB 转换时，要用哪一种转换式。有三种，Basic YCbCr，CCIR601，YUV。 如果是由 Codec 做转换，输出 RGB，则是否做伸张由 Codec 决定。 不同 Codec 有不同作法，是否有做伸张必须要做实验才能确定。 如果 YUV --> RGB 时已经做过伸张，则 RGB 数据已经是 0~255 的范围， 就不可以再用 Descale CCIR601 滤镜，否则会有许多资料破表被削掉，切记。 第二个问题，压缩软件压缩时，是否会先做 Y/C 压缩？ 如 MS MPEG-4 Codec，DivX Codec，XviD Codec 这几个 Codec 都是假设收到的数据是 0~255，会先做 Y/C 压缩的动作。那么其它 Codec 和压缩软件呢？ 这个也必须要做实验确认才能确定。 唯有解压缩和压缩的转换式能正确搭配（做过 Y/C 伸张压缩时就必须做 Y/C 压缩， 没做 Y/C 伸张压缩时就不可以做 Y/C 压缩）最后压出来的成品才会是正确的。 |
补充一
DVD2AVI 的 Color Space 选 RGB/YUV 和 PC Scale/TV Scale 的差异
RGB 模式是输出 RGB24，YV12 (YUV 4:2:0) --> YUY2 (YUV 4:2:2) --> RGB24，
由 dvd2avi 做内插展开（4:2:0 -> 4:2:2）和转换的工作（YUV -> RGB）。
内插展开的算式作者的网站有写，相当于 6-tap 的 FIR Filter。
YUV 模式是输出 YUV 4:2:2（YUY2）。
输出 RGB 时，preview 显示会走传统的 GDI 图形显示接口，送 RGB24 的资料给显示卡，
此时计算机屏幕上看到的颜色正不正确，由 YUV -> RGB 这个选项决定。
（要选 PC Scale 看到的颜色才会正确）
输出 YUV 时，preview 显示会走 DirectDraw YUY2 Overlay，直接送 YUY2 的数据
给显示卡，由显示卡去做展开和色空间转换。显示卡用的都是 PC Scale
（会做 Y/C 伸张，扩展原来的 16~235 的数据为 0~255），所以您可以在屏幕上
看到正确的颜色。
（同理，DVD/VCD 播放时，播放软件会走 DirectDraw Overlay 丢 YUY2 或 YV12
的资料给显示卡，由显示卡来做展开、色空间转换、和放大（scaling filter）的工作。
由于显示卡用的是 PC Scale，会做 Y/C 伸张，所以您才可以在计算机屏幕上看到正确的
DVD/VCD 的颜色）
（前提是，做好的 DVD/VCD，其 YUV 4:2:0 的数据范围必须是 16~235，
经过显示卡 PC Scale 16~235 -> 0~255 才会正确。
如果 DVD/VCD 做错，压缩前没有先做 Y/C 压缩，储存的是 0~255 的 YUV 数据，
则显示时再经过显示卡的 Y/C 伸张，会发生 clipping（资料超过范围被削掉））
（而 16~235 的数据拿到电视上放，电视本来就吃 16~235 的资料，
所以显示也是正常的）
（所以结论，DVD/VCD 上的数据，必须遵照 CCIR601 的规范，维持 16~235 的范围）
至于输出，也是按照 YUV/RGB 的设定，分别输出 YUY2 和 RGB24。
但是如果您有用 vfapi，因为 vfapi 内部完全以 RGB24 传送数据，
所以如果你把 .d2v 转成 vfapi-ref-avi，即使 color space 选 YUV，
dvd2avi 也会做展开转换成 RGB24 输出。如果要用 dvd2avi 直接做 Y/C 伸张，
dvd2avi 的 YUV -> RGB 选项勾选 PC Scale 即可。
另外，如果用 TMPGEnc/AviUtl 直接开启 .d2v，因为这些软件还是以 RGB24
读取，所以 dvd2avi 也还是以 RGB24 输出。
那.... 倒底什么时候会用 YUY2 输出？
直接存 AVI 的时候... ^^;
所以如果您是用 vfapi 或用 TMPGEnc/AviUtl 读取，选 YUV 或 RGB 都没有差异。
附带一提 ^^; 如果 dvd2avi 输出时已经选了 PC Scale（有做 Y/C 伸张），
就不可以再用 TMPGEnc 的 Descale CCIR601 这个滤镜，也不可以用
AviUtl 的 "ITU-R BT.601 补正"，这两个作的事情是一样的，都是做 Y/C 伸张。
已经伸张过再做伸张，会有许多资料 clipping。
补充二
XviD 使用的 RGB -> YUV 算式
由 source code 可以得知，XviD 和大部分的软件一样是遵照这本书的标准转换式作的
http://www.video-demystified.com/book1/index.htm
算式为
Y = (0.257 * R) + (0.504 * G) + (0.098 * B) + 16
Cr = V = (0.439 * R) - (0.368 * G) - (0.071 * B) + 128
Cb = U = -(0.148 * R) - (0.291 * G) + (0.439 * B) + 128
此算式等于上述 CCE SP 的第一个算式，也就是假设收到的是 0~255 的 RGB 数据，会先做 Y/C 压缩，然后才压 MPEG。
我自己本来也不懂，后来是因为 DVD2AVI 的作者教我，我才明白其中的来龙去脉。
（当然，如果有错，也是我的理解有误，和 DVD2AVI 的作者无关 ）
（DVD2AVI 的作者实在非常非常非常的厉害，有许多道理都是他研究出来再教给大家的。譬如说 NTSC 4:3 的 DVD，720x480 的分办率，要先左右共削掉 16 个点，变成 704x480 再 resize 成 640x480/512x384 ... 才是正确的比例，这个道理便是他研究发现的，然后再教给 GKnot 的作者 TheWEF。GKnot 有个选项叫 "Follow ITU-R BT.601 Standard"，选了这个选项 GKnot 便可以遵照 ITU-R BT.601 的标准，做正确的 resize。唯有按照 ITU-R BT.601 的规范做 resize，resize 后的比例才是正确的，GKnot 变成唯一可以帮你计算正确 resize 方法的软件，其它软件的 resize 乱七八糟都是错的。而 GKnot 之所以知道正确的作法，就是因为 DVD2AVI 的作者 jackei 教的）
（PAL 同样要遵循 ITU-R BT.601 的规范，至于正确的作法我没有研究，有需要的人可以利用 GKnot 帮忙计算正确的 resize 作法）
（关于 ITU-R BT.601 和正确的比例如何计算的原理，说起来很复杂，有机会我再解释 有兴趣的人可以参考 http://www.uwasa.fi/~f76998/video/conversion/。
.....简单的说，因为 DVD 取样记录的时候，取样的点之间的长宽比，Pixel Aspect Ratio，也就是 PAR 不是 1:1。而我们个人计算机的屏幕上 Pixel 和 Pixel 之间的长宽间距都一样，也就是 PAR 是 1:1，也就是正方形的 Pixel，Square Pixel。所以 resize 的时候，不能直接从 DVD 的原始分办率 resize 至目标的比例，如 4:3 or 16:9，而要做一些处理。通常来讲，要左右削掉一些 Pixel，转换后的比例才正确。例如 NTSC 720x480 16:9 squeeze 的影片要 resize，正确的作法要左右共削掉 16 个点，变成 704x480 再 resize 至 704x396(16:9) 才是正确的比例。然而 704x396 的高度 396 不能被 16 整除，不利于 MPEG 压缩，所以我们再上下各补 2 个点，补上黑边，补成 704x400 之后再送进去压缩。因为 AVI 这种格式没有纪录 DAR，Display Aspect Ratio，播放时的比例的信息，所以播放软件播放时不知道正确的播放比例应该是多少，因此制作时就要先设计好正确的长宽比例，如上例中的 704x396(16:9)。您可能会疑惑可是最后我们为了压缩需要又补了四个点上去，变成 704x400，这样就不是 16:9 了啊。没错，704x400 不是 16:9，但是因为补上去的多余的点是黑边，所以即使放大到全屏幕，比例还是正确的 16:9，多出来的黑边不影响画面中央有影像部分的正确比例。有点抽象，要好好想一下才能明白其中的道理 ^^;）
糟糕，我又扯远了 
上述的那个网页，最后有一段问答，我觉得很有意思，转过来给大家看：
4.4 I have been doing digital video projects for the last 50 years. I know my stuff! If you were correct, everything I have done to process my precious video has always been wrong, aspect-ratio wise!
That may very well be the sad truth. Fortunately, even if you had used wrong methods for scaling/resampling the image, the difference between the correct aspect ratio and a wrong aspect ratio is often small enough to go unnoticed unless you really start looking for it.
4.9 This is really scary and nasty stuff. I thought digital video was simple! Now my head hurts!
But that's just the way video is. Fortunately, the conversions are not really that complicated once you practice them a little.
虽然道理很复杂，不过我觉得这很重要，所以才提出来和大家讨论。
譬如说当我看到 TMPGEnc vs. CCE SP 的压缩测试，测试说 TMPGEnc 压出来的颜色比较鲜艳，CCE SP 的颜色比较黯淡，我第一个就会想到，测试时 TMPGEnc 和 CCE SP 的 Y/C 伸张/压缩 的设定是什么？两者的设定是否相同？如果两者的设定不同，则出来的颜色表现不同是当然的。
或者说 TMPGEnc 的画面较模糊，CCE SP 的画面较清晰，我就会想到，TMPGEnc 的 resize 方法是用「平均像素法」，这种 resize 法的画面本来就较模糊，但是对低码率的 VCD 来说，这样比较好压。模糊是 resize 造成的结果，和压缩无关，如果真的要比压缩编码的效果，应该用别的软件先做好 resize，譬如说用 Avisynth 的 lanczos3 先做好 resize，再送进去给 TMPGEnc/CCE SP 压缩，这样比较才有意义。
所以知道这些原理还是有它的用处的。
至于采集卡，小弟使用的经验不多，所以无法提供建议 ^^;;
采集卡应该要遵循 ITU-R BT.601 的规范，YUV 的范围应该在 16~235 之间，所以必须做 Y/C 伸张。但是实际上各家的采集芯片不一定会完全依照 ITU-R BT.601，事实上 ITU-R BT.601 也没有强制 Y/C 一定要在 16~235 之间，超出一点是可以的，这个设计本来有很大的一个原因是因为 MPEG 压缩后数据不会和原来一样，可能会超出一点，事先规范压缩前的 YUV 在 16~235 之间可以预留一些空间（低于 16 和高于 235），给压缩后超出的数据使用。
譬如说新出的 SAA7134HL 和 CX23881 芯片，SAA7134HL 的 scale（范围）是 15~235，CX23881 则是 0~255，不用再作 Y/C 伸张。所以 CX23881 采集下来的画面看起来比 SAA7134HL 鲜艳非常多，不知道的人还以为 SAA7134HL 很烂，颜色很黯淡。
请看这个网页的比较图片
http://anipeg.yks.ne.jp/topic.html
一般来说要确认自己的采集卡的动态范围，好知道后续要做什么样的色调补正处理，必须从外部生成一个标准的 ColorBar，色彩条，也就是上述那个网页的第一个图，作为输入，看看采集后的颜色和原来相差多少，用 PhotoShop 或 AviUtl 之类的软件看 RGB 的数值。ColorBar 的每个色条有固定的 RGB 值，用 Avisynth 的 colorbar 指令便可以生成一个 ColorBar。
同样能量的光线人眼看起来 绿色亮度 > 红色亮度 > 蓝色亮度，
MPEG YUV 4:2:0 取样，Y 的情报量是 UV 的四倍。
Y 定为 Y = 0.299*R + 0.587*G + 0.114*B
绿色占的比重大，Y 的情报量又最多，所以绿色的分辨率比其它两种颜色好。
其次敏感的红色情报量不如绿色，所以一旦 YUV 4:2:0 -> 4:4:4 内插展开不够平滑，
人眼很容易就会看出瑕疵。
可以看繁体中文的话，参阅「红色的地方有锯齿」
http://bbs.irradiance.net/txtVersion/treasure/animation/M.935070924.A/1-15
Nandub 的 Anti shit，不是在增进画质，相反的，它是在减低画质。
我们知道，Quantizer 越高，画质越差；Quantizer 越低，画质越好。
Nandub 每压完一个 Frame，就会计算这个 Frame 的品质（PSNR，Peak Signal to Noise Ratio，比较压缩前的画面和压缩后的画面，两者之间的差异有多大，单位是 dB。PSNR 越高越好，代表差异越小），如果 PSNR 低于你设定的 Anti shit 的 dB 数，Nandub 就会提高 Quantizer 重新压缩这个 Frame，直到画质超过你设定的 PSNR 为止。（Nandub 把 Quantizer 称为 Compression Level，简称为 CL）
等等，不是说 Quantizer 越低画质越好吗？怎么 Nandub 反而是提高 Quantizer 重新压缩呢？这是因为 Nandub 压缩使用的 MS MPEG-4 V2/V3，也就是 DivX 3.11 Codec 有一个 bug，当 Quantizer = 2 or 3 的时候，画面上高反差的区域（亮度对比强烈的地方，譬如说黑白的交界处），会出现一种灰白色方块的压缩瑕疵，英文叫做 luma-inverted block（亮度颠倒的方块，原本黑色的部分变成白色，原本白色的部分变成黑色），看起来很明显，而且很丑。这在压缩一般的电影影片时可能还不太明显，但 是遇到色彩鲜艳、对比强烈的动画影片时，这个压缩瑕疵可以说是满天飞舞，让人根本看不下去。
这个瑕疵，Nandub 的作者把它称为 shit 
Anti shit 的作用就是在 Anti（反）这个瑕疵。
为了解决这个 bug，日本和欧美各自发展出不同的方法。日本用的工具叫做 M4C，它的方法是压缩的时候侦测画面上是否出现灰色方块，如果发现有灰色方块，就把那张画面重新压缩为 keyframe，这样就可以解决这个问题。（MPEG-4 V2/V3，DivX 3.11 的 keyframe 的默认值，最低只能用 Quantizer 4x，除非你用 Nandub 修改这个设定。所以改成 keyframe 压缩，等于提高 Quantizer，也就解决了这个灰色方块的 bug。但是缺点是会插入太多 keyframe 花费码率，而且 keyframe 的 Quantizer 只有 4x，品质很差，一插 keyframe，画面很容易都是晶格状的方块，看起来也很丑）
Nandub 用的方法则是，计算画面上品质最差的方块的 PSNR（不是整体的 PSNR，1st-pass 的时候 debug view 里面会显示 PSNR=43.38(30.46)，前面那个是整体的 PSNR，后面括号中的数字才是最差品质方块的 PSNR），当这个数值低于 Anti shit 设定的 dB 数时，Nandub 会认为代表画面出现 shit（灰色方块），Anti shit 便会启动，将这个 Frame 重新提高 Quantizer 压缩。提高 Quantizer 压缩，虽然画质会变差，但是因为 Quantizer 高于 2 or 3，可以解决灰色方块的问题。当提高 Quantizer 也无法解决问题时（最差品质方块的 PSNR 没有改善），Nandub 便会试着再将这个 Frame 重新压缩为 keyframe，并且继续提高 Quantizer 试试看。
您可以参考这个网页，搜寻 luma-inverted block 这个字符串，看看那一段的说明
http://www.undercut.org/Nandub_OnePass/
或是看 Nandub 附的 readme 说明档，搜寻 luma-inverted block 这个字符串，
里面作者都有详细解说这个选项是做什么用的。
所以 Anti shit 这个选项不是了提高画质，而是为了避免灰色方块这个 bug，所以不得以设计出来的机制，其实它是提高 Quantizer，反而会破坏画质。
至于 DivX5, XviD 都没有这种 bug，所以当然不用这种设计。它们会很自然的根据码率，决定这张画面要给多少品质。
Nandub 的这个 Anti shit 有一个 bug，那就是如果画面最差品质的方块，其 PSNR 低于 Anti shit 的 dB 值，原因不是因为灰色方块的关系，而是因为这个画面本来就很难压而压不好，那么 Nandub 即使提高 Quantizer 重新压缩，也无法解决这个问题，反而会因为 Quantizer 更高，画质更差，PSNR 更低，造成程序无穷循环，Nandub 反复不停地提高 Quantizer 重压，直到最高的 31x 为止。接着 Nandub 又会试着再把这个 Frame 重新压成 keyframe，但是这里 Nandub 的程序写错，造成 keyframe 的 PSNR 计算错误，这个 keyframe 又会反复一直提高 Quantizer 压缩，直到最高的 31x 为止才跳出循环，结果我们最后就会得到一张 Quantizer 31x 的 keyframe 
画面非常惨。
不是每个人都会遇到这种情况，如果你压的是动画，Anti shit 的值又设得很高（> 21dB），那么就很容易发生这种现象。这个在国外讨论区以前常有人问，大家都不明白这是为什么，不信您可以上 Doom9 讨论区搜寻 31x keyframe 等关键词，相信一定可以找到类似讨论。
所以结论就是，Nandub 的 Anti shit，真的是 shit ...
电影原本是 24fps 的，在胶卷过带（Telecine）的时候，NTSC 制会经过 3:2 pulldown 转为 30fps。
也就是原本 1 2 3 4 四个 Frame，拆成 1o 1e 2o 2e 3o 3e 4o 4e，每个 Frame 拆成奇数扫瞄线组成的奇数图场（Odd Field）和偶数扫瞄线组成的偶数图场（Even Field）。重新组合如下（以 Odd Field First 的顺序）
1o 1e - 2o 2e - 2o 3e - 3o 4e - 4o 4e
[ A ] - [ B ] - [ C ] - [ D ] - [ E ]
每两个 Field 再重新组合成一个 Frame，就变成 [A][B][C][D][E] 五张 Frame。这样由原本的 4 张变成 5 张，4*6 = 24 => 5*6 = 30，就能从 24fps 转为 30fps。
在电视上看，电视因为是交错显示，所以看不到交错线。但是在计算机上看，计算机屏幕是循序显示，所以中间的 2o 3e -3o 4e 这两张 Frame 中的 Field 分别来自不同的 Frame，一起显示的话就会看到交错的现象。
DVD 压缩的时候，母带是胶卷过带（Telecine）后的 30fps，但是我们知道，其实原本的影片是 24fps 的，这 30fps 其实是从 24fps 转出来的，中间有不必要重复的 Field。这些重复的 Field 会造成交错，使得每 5 个 Frame 中就有 2 个 Frame 交错（名言：每五张烂两张），这些交错的画面要压缩不但浪费空间，而且交错画面又难压缩，会使得压缩的效果很差。
所以先进的 DVD 压缩制程，在压缩时都会使用 IVTC（inverse telecine，反胶卷过带），将 30fps 转回 24fps，这样压缩的画面张数由 30fps 减少为 24fps，少了 20%，等于 Bitrate 增加 20%，而且画面无交错容易压缩，所以压出来的画质会好很多。
但是 IVTC 检出不一定能做到 100%，遇到无法检出、判断的部分，Encoder 还是会以原本的 30fps 来压缩。所以我们会看到有些 DVD，是 Film（24fps）和 NTSC（30fps）混合的 DVD，又叫做 Hybird（混合）的 DVD，这个意思就是说，这张 DVD 内的画面，是 24fps 无交错，和 30fps 有交错两种型态互相混合的。
通常 RC1 八大电影公司出的 DVD IVTC 率都很高，几乎都高达 99% 以上，但是其它的公司出的 DVD 就不一定有这么高的比例。IVTC 100% 的 DVD 代表这张 DVD 内完全以 24fps 压缩，那么在 30fps/60 field/s NTSC 制的电视机上要播放时，要怎么播放呢？这些 DVD 在压缩的时候，Encoder 会写入一个 Flag（旗标）的信息，叫做 Repeat First Field，简写为 RFF。根据这个 RFF，DVD 机播放的时候，就会知道哪些 Field 要重复输出，利用重复输出这些 Field，DVD 机就会再播放的时候，做上面提过的 3:2 pulldown 的动作，在播放的同时，将 24fps 转为 30fps 输出，这样就能在电视上正常收看了。
PAL 制则不一样，胶卷过带时是采用 2:2 pulldown，也就是仍然输出原本无交错的 Frame，但始将播放速度加快 4%，声音也一起加快 4%，提升为 25fps，所以理论上来说，PAL 很好处理，因为画面根本无交错，所以直接压缩即可。不过我在这里看到有朋友提到，PAL 的 DVD 还是有些是交错的，这点我就不明白是为什么了，可能是制作过程上有问题吧。（譬如说用 DV 去拍的影片，DV 大部分是交错式拍摄，张张都交错，是补不回来的）
DVD2AVI 的 Force Film，所作的处理，和 TMPGEnc 的 IVTC 不一样。TMPGEnc 的 IVTC 是跑一遍分析画面的信息，计算每一张画面的「奇数扫瞄线和偶数扫瞄线的差异」和「动态」这两个信息，藉由这些数据，推测出原本的 24fps 的顺序，将画面反转回原本的 24fps。因为需要分析、计算这些数据，所以跑第一遍的时候花的时间要比较久。而 DVD2AVI 则完全不一样，DVD2AVI 是根据上面提到的 RFF 这个旗标的信息，将重复的 Field 删除掉，直接原封不动的输出 DVD 内原本储存的 24fps 的 Frame。因为只是做这样的判断，所以速度很快，存 .d2v 档时一下子就存好了。所如果这部 DVD 在压缩时的 IVTC 率很高，Film 的比例高达 95% 以上，内部原本就是储存 24fps 的形式，这样才可勾选「Force Film」这个选项。如果该 DVD 的 IVTC 率很低，内部大部分是 30fps 的形式，选「Force Film」输出，你会得到乱七八糟的结果。所以在使用「Force Film」这个选项之前，必须先用 Preview 预览一次，让 DVD2AVI 跑一小段试试看，这部 DVD 的 IVTC 率究竟有多高，如果 Film 的比例很低，那么就不可以使用 Force Film 输出。
另外如果是 PAL 制的 DVD，更不可以开 Force Film，否则 DVD2AVI 会每五张砍掉一张，原本 25fps 会变成 20fps，画面会错得离谱。PAL 的画面就是原本电影无交错的画面，不需要做 IVTC，如果你的 PAL DVD 有怪异的交错，那么我猜测它的讯源一定是非""正规""的讯源（例如 DV），才会发生这种现象。遇到这种情况你应该作的是 Deinterlace，而不是 IVTC。
DVD2AVI 的 Force Film 和 TMPGEnc 的 IVTC，两者的作法和使用的时机都不同，使用者要自己判断该用哪一种方法。如果有人拿 Film 率很低的片子用「Force Film」输出，得到惨不忍睹的结果，然后怪 DVD2AVI 的 "IVTC" 烂，那真是冤枉了 DVD2AVI 的作者。这些观念在作者的网页上都讲得很清楚。
http://arbor.ee.ntu.edu.tw/~jackei/dvd2avi/doc/issue.html#videotype
节录当中的一段：
Forced FILM is based on RFF detection and frame decimation/duplication.
NTSC or PAL + Forced FILM ON -> garbage
FILM + Forced FILM ON -> synchronous 23.976 fps flawless FILM (equals to IVTC)
作者说，Force Film 是根据 RFF 旗标侦测和删除重复的 Frame。
NTSC（30fps）或者是 PAL 的讯源，如果开了 Force Film，得到的东西会是 garbage，垃圾。
Film 的讯源开 Force Film，才会是同步的 23.976fps，无错误的 Film 影像（equals to IVTC，等于做 IVTC）。
作者已经说得这么清楚了，就请大家要有正确的观念，不要再冤枉他了
帮 DVD2AVI 的作者申申冤
DVD2AVI 显示的 Frame Type = Interlaced 的信息，不是表示这张画面是否交错，DVD2AVI 根本不会去分析、判断画面上是否有交错。这个 Frame Type 的信息是根据储存在 DVD 内的一个旗标（Flag），叫做 progressive_frame 来显示。当 progressive_frame = 1 的时候，DVD2AVI 就会显示 Frame Type = Progressive。当 progressive_frame = 0 的时候，DVD2AVI 就会显示 Interlaced。这个旗标的作用是什么呢？这个旗标的作用是告诉 Decoder，目前的这张画面，是一个 Progressive Frame，还是由两个 Field 组合成的一个 Interlaced Frame。根据这个旗标，Decoder 才能知道要怎么做 YUV 4:2:0 upsampling 到 YUV 4:4:4，组合正确的播放顺序。
请参考下面附的图
1. YUV 4:4:4
Chroma（圈圈的记号）= 彩色像素，Luminance（叉叉的记号）= 亮度像素
2. YUV 4:2:0
3. YUV 4:2:0 Progressive Frame 的取样位置：chroma1 = (c1+c2)/2, chroma2 = (c3+c4)/2
4. Interlaced Frame 的取样位置：chroma1 = 0.75*c1 + 0.25*c3, chroma2 = 0.25*c2 + 0.75*c4
5. 播放时根据 progressive_frame 旗标判断画面是一个 Frame 还是由两个 Field 组成。
这张图有 3:2 pulldown，根据 RFF（repeat first field）旗标重复输出第一个 field，所以会看到重复的图场。
注意看 progressive_frame = 0 或 1 时 Chroma 的位置
由上面的这几张图，我们可以看出，YUV 4:2:0，垂直方向的彩色像素只有一半。当 progressive_frame = 1 的时候，彩色像素 Chroma 的位置是位在两个 Luminance 亮度像素的中间。所以取样的时候，chroma1 = (c1+c2)/2, chroma2 = (c3+c4)/2，用原本 YUV 4:4:4 的 c1 和 c2 求平均，得到位在中间的 chroma1 的值。
当 progressive_frame = 0 的时候，画面拆成两个 Field 取样，Chroma 在每个 Field 不是位于正中间，而是位在 3:1 的位置上，所以取样算式变成 chroma1 = 0.75*c1 + 0.25*c3, chroma2 = 0.25*c2 + 0.75*c4。注意交错画面是拿 c1 和 c3 取样 chroma1，因为 c1 和 c3 才是属于同一个 Field 画面（奇数扫瞄线组成的奇数图场），c2 和 c4 位在另一个 Field 上（偶数扫瞄线组成的偶数图场）。而循序画面则是拿 c1 和 c2 取样 chroma1，两者有很大的不同。
以前曾经有提过，现在有很多 DVD Player 有 chroma upsampling 的错误，那时说有机会再解释，现在解释。
Chroma Upsampling 错误就是，许多 DVD Player 不会判断 progressive_frame 这个旗标，当遇到交错画面时，chroma upsampling，由 YUV 4:2:0 -> YUV 4:4:4，要用交错画面的 upsampling 计算式，chroma1 要分给 c1 位置和 c3 位置来使用，不可以给 c1 和 c2 使用，因为交错画面当初取样时，是拿 c1, c3 算出 chroma1 的。
同理，当遇到循序画面时，要用循序画面的 chroma upsampling 计算式，chroma1 要分给 c1 和 c2 使用。
现在许多 DVD Player 不会分办这个旗标，upsampling 时只有一种计算法，譬如说软件 DVD Player 因为使用 YV12 Overlay，所以造成只能用循序画面的计算式，遇到交错画面，色彩像素就会解错，c2 会拿 chroma1 的像素来用。
这个软件译码的问题也就是 DVD2AVI 的作者当初写 DVD2AVI 这个软件的原因，因为他受不了 Chroma 错误译码之后的画面。想知道译码错误的画面长什么样子，请看 DVD2AVI 作者网页上的图片和说明
http://arbor.ee.ntu.edu.tw/~jackei/dvd2avi/interlace/
目前 PowerDVD 已经解决这个 Chroma 译码错误的问题，遇到交错画面先分别解出两个 Field 的 Chroma（c1 and c3, c2 and c4），再合并成一个 Frame。由于这样要自己先做 YUV 4:2:0 -> YUV 4:2:2，所以 PowerDVD 用的是 YUY2 Overlay。
另一个译码错误的问题，普遍发生在硬件的 DVD Player 上。硬件的 DVD player 一样不会分辨 progressive_frame 旗标，它们只有交错画面的 upsampling 计算式（刚好和软件 DVD Player 相反），所以遇到循序画面，就会解出错误的画面。想知道硬件 DVD Player 译码错误的画面长什么样子，请看 Home Theater HiFi 这本杂志做的测试，里面有详细的解说
http://www.hometheaterhifi.com/volu...bug-4-2001.html
还有列出目前市面上，有哪些 DVD Player 已经修正这个问题
http://www.hometheaterhifi.com/volu...-2001-list.html
多有趣对不对，原来我们看了这么久的 DVD，解碼画面竟然不正确!
回归原题，DVD2AVI 显示的 Frame Type 信息，只是根据 progressive_frame 这个旗标，代表的意义是这个 Frame 当初压缩时，是用 Progressive Frame 取样，还是 Interlaced Frame 取样，和实际上画面是否有交错无关。
当然正确的情况下，无交错的画面应该用 Progressive Frame 取样，有交错的画面应该用 Interlaced Frame 取样。但是愚蠢的 DVD 制作厂商不一定会做对，譬如说 csr2000 兄提到的他那张二区日本 DVD 全部是 100% Interlaced，这个就是一个做错的例子。这代表当初厂商在压缩时就做错，DVD2AVI 只是忠实反应这个错误。
我手上也有很多片子明明是循序画面却用 100% Interlaced Frame（譬如说日本二区的 Full Metal Panic NCOP），真是让人哭笑不得。
想想这些大厂都会犯错，连硬件 DVD Player 都会做错，那么压缩时搞错设定也就不是什么奇怪的事情了。
以上，一样是帮 DVD2AVI 申申冤
我比较常用 M4C + AviUtl 手动指定 keyframe。
先说明一下，以免大家不知道我们在讨论什么。
csr2000 兄说的「ベリノイズ」，英文叫做「luma-inverted block」指的是 MS MPEG-4/DivX 3.11 的一个 bug，当码率很高，也就是画质很好，quantizer 很低的时候，画面上高反差（对比强烈）的地方，譬如说黑色与白色的交界处，会出现一种灰色的方块，有时候看起来像黑水晶的色泽，油油亮亮的。这种瑕疵看起 来非常明显而且很难看，压色彩鲜艳、对比强烈的动画时特别容易出现，是当初用 MS MPEG-4/DivX 3.11 压动画的人的头号大敌。
解决这个问题的方法，一个是将出现方块的画面重新压缩为 keyframe，这样方块就会消失。M4C 这个 plugin 就是在做这件事，压缩的时候 1st pass 压一次，然后检查画面上是否有灰色方块，如果发现有灰色方块，就自动作 2nd pass 把该画面重新压缩为 keyframe。
另一个方法，是将该画面重新提高 quantizer 压缩，直到灰色方块消失为止。SBC 的 Antishit 就是在做这件事，Antishit 的 shit 指的是 luma-inverted block。如果提高 quantizer 压缩灰色方块还是没有消失，SBC 才会将该画面重新压缩为 keyframe，并且继续提高 quantizer 重试。
M4C 的缺点是会将画面重新压缩为 keyframe，而 MS MPEG-4/DivX 3.11 keyframe 的最小 quantizer 默认值是 4x，这是 codec 内定的。
quantizer 4x 的 keyframe 压某些画面时品质实在不太够，很容易出现晶格状，整个画面都是一块一块方块，看起来也很难看。
而 M4C 检查的方法是比较压缩后的画面和原始画面有多少 pixel 的亮度差异超过设定值，如果亮度相差超过一定程度，M4C 就会判断画面上出现了 luma-inverted block（亮度颠倒的方块）。不过有的时候亮度的差异是因为 MPEG 破坏性压缩后造成的差异，并不是因为画面上真的出现了 luma-inverted block。如果 M4C 这个判断的参数设得太低，M4C 会大量重新压缩画面为 keyframe，而刚刚说过，keyframe 的品质很差，最小 quantizer 也只能用 4x 而已。连续很多画面都是 keyframe 的话，画面也会都是晶格状，一块一块的方块，看起来一样难看。
所以为了避免 M4C 插入太多的 keyframe，我们会将检查的参数设得比较宽松，只有真正的 luma-inverted block 画面我们才重压为 keyframe。如果第一次压缩以后发现有画面有灰色方块没有检查出来，我们再用 AviUtl 手动指定那一张画面为 keyframe 重新压缩一次就可以解决了。
总之原则是尽量减少不必要的 keyframe，keyframe 越少越好，越少品质越高。
甚至连 Scene Change 的 plugin 都不要用。AviUtl 有一个 Scene Change 的 plugin，因为 MS MPEG-4/DivX 3.11 codec 很笨，它的 Scene Change 侦测、自动插入 keyframe 的功能要在码率低于 460kbps 以下时才会启动，所以必须使用额外的 Scene Change plugin 来做侦测的工作。当然如果 hack 过的版本，如 VKI 的版本，譬如说 DivX 3.22，就可以在任何码率下启动 Scene Change，不过这种版本的 codec 不能和 Nandub 一起用，会造成 Nandub 的混乱。然而如果要最高画质，则连 Scene Change 都不要用，就给它用 delta frame 压下去，虽然这样那个 delta frame 会很大，但是品质会比用 4x 的 keyframe 好。
以上是 M4C 的情况。用 M4C 压的时候，目标是高画质，所以一集二十多分钟的动画压的容量大小都是 250~350MB，很大。
如果要做 1 CD 的 DVD-RIP，quantizer 本来就高，出现 luma-inverted block 的机会比较少，或者你压缩的影片不是动画，对比没那么好，出现 luma-inverted block 的机会比较少，那么使用 SBC 我想是比较好的方法。
SBC 的缺点是，程序有 bug。SBC 检查灰色方块的方法是，压好一个画面以后和原来的画面比较，计算画面上品质最不好的方块的 PSNR。PSNR 是一种计算画面品质的方法，单位是 dB，越低代表和原来的画面差异越大，品质越差。当计算出来的 PSNR 低于设定值的时候，例如说只有 7dB，不到设定的 19dB，SBC 就会将该画面重新提高 quantizer 压缩。quantizer 越高画质越差，但同时也可以解决灰色方块的问题，当画质差到一定程度以后，灰色方块就会消失。
然而如果我们把设定值设得太高，例如设成 21dB，不到 21dB 的画面都要提高 quantizer 压缩，则可能会出现一种情况，那就是这个画面其实没有出现灰色方块，但它的品质很差，不到 21dB，结果被 SBC 误判为是 shit，重新提高 quantizer 压缩。当然，这样根本无济于事，不但无法提高 PSNR，反而会使 PSNR 更低（quantizer 更高了，品质更差）。SBC 发现提高 quantizer 一次没有办法使 PSNR 超过 21dB，它就会继续再提高 quantizer 重压一次试试看，结果程序就会反复不同地提高 quantizer、重压，直到最后最大的 quantizer 31x 才跳出执行的循环。而这时 PSNR 当然还是低于 21dB，所以 SBC 又把它重压为 keyframe 2x，此时程序又发生了一个致命的错误，计算出来的 PSNR 是错误的，所以 SBC 仍然误判 PSNR 低于 21dB，继续提高 quantizer 重压这个 keyframe，直到 31x keyframe 才跳出循环。
多么的愚蠢
结果我们最后就会得到一张 31x keyframe，惨不忍睹的破脆画面。
不是很多人遇过这种情况，这是因为
1. Antishit 的设定值没有设得太高，超过 21dB 通常会很危险，容易造成 SBC 误判，但有些 luma-inverted block 又会在 21~22dB 左右的时候出现，设得太低又无法检查出这些画面，所以左右为难
2. 压的影片对比没那么高，不容易出现 luma-inverted block。
3. 压的码率不高，quantizer 高，减少 luma-inverted block 出现的机会。
所以没遇过这种情况。不过如果你到 Doom9 的论坛上去搜寻 31x keyframe 这个字，你会发现以前有人提过他们遇到这个现象。
所以 SBC 还是有这个缺点，我以前就为了这件事情伤透脑筋 ^^;
另外，我以前还疯狂到要用 SBC 压无敌画质的动画 ^^;
因为 SBC 可以控制 Compression Level，简写为 CL，其实也就是我们现在比较熟悉的 quantizer，指的是同样的东西。我想到 M4C 的画质很好，可是还是不够好，因为它的 keyframe 只能 4x，遇到某些画面还是会有晶格状，看了很不舒服。
我想利用 SBC 控制 quantizer 的功能，把 keyframe 的 quantizer 也设为 2x（SBC 会覆盖掉原本内存内 codec 的默认值），这样就可以压出比 M4C 画质更高的东西了。
要达到这个目标，必须搭配 Nandub 的 .ecf 文件。ecf 是 Encoding Control File 的缩写，是纯文字文件，写好设定以后存盘为 .ecf，Nandub 压缩的时候可以读取这个文件，控制压缩的参数。里面可以设定每个 Frame 的型态，例如
@1-2000: K, CL=2
@2001: D, CL=2
的意思是控制 1 到 2000 个 Frame 全部都压成 keyframe，而且 CL 为 2x，2001 则压成 delta frame（P-frame）。
此外还可以设定每个 Frame 的 Motion 值，Gauge 值...等等。设定 Motion 值在这里有个作用，前面提过 SBC 可能会误判某些画面有 luma-inverted block，实际上没有，要如何解决这个问题呢？SBC 的 Antishit 还有一个参数叫做 Modulation，会随着 Motion 值的高低调整启动 Antishit 的 dB 值。Motion 越高，启动的 dB 会自动降低，例如从 21dB 降低为 19dB。这样我们只要在 .ecf 将那几个会被误判的画面的 Motion 值手动指定得很高，SBC 遇上这几个画面时 Antishit 便不会启动，这样就可以避免 SBC 误判了。
好复杂？确实很复杂，我以前手动调整反复压了十几遍，搞得累得半死，也仔细写过详细的做法教学，现在看起来真是没有意义，改用 DivX 5 或 XviD 压就不用那么麻烦了 ^^;
以上说的是要压超变态、超极限、超高画质、不计文件大小的情况，MS MPEG-4 因为先天有许多 bug，非常不适合。如果是压 1 CD, 2CD 这种的，就不在此限，这种情况 MS MPEG-4/DivX 3.11 是有它的优点。
PAL 格式的 DVD 不可以 Forced FILM，DVD2AVI 的 Forced FILM 会每五个画面删除掉一个画面，PAL 25fps 的 DVD Forced FILM 之后会变成错误的 20fps，画面会一顿一顿的，播放不流畅（因为中间的画面被删除了）。
FILM 100% 的 DVD 直接用 Forced FILM 输出即可。NTSC FILM 100% 的意思是，这张 NTSC 的 DVD，里面储存的是 24fps 的 progressive 画面，播放的时候会利用 RFF/TFF 这两个旗标（Flag）作 3:2 pulldown，将 24fps 转为 30fps 输出。转换的原理以前说过，或是上面那篇翻译文章中也有讲（不过写得好复杂 @_@），此处便不再赘述。此时 DVD2AVI Forced FILM 输出，会根据 RFF/TFF 旗标，每五张删除一张，30 -> 24fps 得到原本的 24fps progressive 画面。
这个动作的效果，等于做 IVTC。
NTSC/FILM 混杂的 DVD，又叫做 Hybird 的 DVD，必须做 IVTC。NTSC/FILM 混杂的意思是，这张 DVD 里面，有 NTSC（30fps）的 Frame，也有 FILM（24fps）的 Frame，两种混合在一起，所以叫做 Hybird。为什么会有这种 DVD 呢？这是因为原本的 24fps 电影胶卷，经过胶卷过带（Telecine）以后，变成 30fps 的母带，譬如说 D1，然后送进 MPEG-2 encoder 压缩。这样的 30fps 的画面是有 interlaced 的（交错、拉丝），而且是五张之中有两张交错。interlaced 的画面不好压缩，会使得压缩率下降，而且影片本来就是 24fps，压缩时压 30fps 浪费空间，还要每 24 张多压 6 张画面，等于码率多消耗 20%，十分浪费。
所以压 DVD 的时候，好一点的 encoder 同时会做 IVTC，将 30fps 转回 24fps 之后才压缩，储存 24fps progressive 画面，这样画质会比较好。这个也就是上面说的 FILM 的 DVD。
然而，不是所有的影片都是先剪接编辑完才做 Telecine，也就是 3:2 pulldown 的顺序不是单一的。剪接完才 Telelcine 的影片叫做 hard coded telecine，这种的做 IVTC 比较简单。其它不是只有单一顺序的影片做 IVTC 会比较困难。还有 encoder 的 IVTC 也无法 100% 地判断出还原的顺序，会受到噪声、「光学式 Telecine 造成的残影」、画面动态大小的影响，影响判断的正确性。所以能够判断、还原的画面 encoder 就会用 24fps（FILM）去压，遇到不能判断、还原的画面 encoder 还是只好用 30fps（NTSC）去压，所以最后压出来的 DVD 就会有 NTSC/FILM 两种形式混合。
遇到这种 DVD，如果 FILM 的比例不高，譬如说低于 95%，就不可以让 DVD2AVI 做 Forced FILM，会删除到错误的画面，出来的结果某些地方会停顿。遇到这种情况，你就必须真的自己去做 IVTC，来还原 24fps，不能依赖 DVD2AVI 的简单判断。
如果是纯 NTSC 30fps 的讯源，这个意思是这张 DVD 的画面是 30fps 张张都无交错，张张都是 progressive 的画面，那当然根本不需要、也不应该要、也不能要做 IVTC。IVTC 的意思是 inverse telecine，反-胶卷过带，当然是要有做过 telecine 的讯源，你才需要、才能够做 IVTC。没有经过 telecine 的讯源，做 IVTC 要干什么？
这种 30fps progressive 的讯源，例如计算机 CG 作画的电影、动画片，或 30fps 摄影机拍摄的特殊影片等等，会出现这种规格。
如果是纯 NTSC 60 fields per second 的讯源，这个意思是 60 fields，30fps 张张都交错的画面，张张都是 interlaced 的，遇到这种讯源，当然也不能做 IVTC，要做的是 de-interlace 去交错。这种讯源是交错是摄影机，DV 等拍下来的影片。
总结以上，也就是说只有当原本的讯号来源（讯源）是 FILM，原本就是 24fps 拍摄的影片，譬如说一般的电影，我们才需要做 IVTC。
DVD 压缩的时候，一个 Frame 被视为是两个场的组合，奇数的扫瞄线组合成奇数的图场，偶数的扫瞄线组合成偶数的图场。另外有一个旗标（Flag）会标示，这个 Frame 是 progressive 的，还是 interlaced 的。progressive frame 的意思是，这个 frame 当中的两个场，是同一时间点拍摄下来的画面，两个场组合城一个完整的画面。interlaced 的意思是，这个 Frame 当中的两个场，是在不同时间点拍摄下来的画面，两个场各自独立。
那么Silky兄，如何判断一张DVD是否是纯NTSC 30fps的呢？
怎么判断？用眼睛看
例如 NTSC 30fps interlaced 的讯源张张都交错，简写为 30i，也就是等于 60 fields per second。这种的用 preview 跑一遍看的话，会发现"每一张"画面都交错，没有一张是完整的画面。
NTSC 30fps progressive，简写 30p 的影片，你用 DVD2AVI 的 preview 跑一遍播放看看。用眼睛看画面，不要管 DVD2AVI 的 Frame Type 显示的讯息。你会发现画面张张无交错，每一张都是完整的画面，这就是纯 30fps progressive 的讯源。这种讯源通常出现在计算机 CG 作画的动画，或者是一些纯 30p 的动画，例如樱花大战 OVA2、BOYS BE 等等。有些动画的 OP 是 30p，本篇是 24p，例如 Azumanga 大王。有些动画是本篇 24p，但是遇到 CG 的画面，则变成 30p。有些动画是 30p/60p 混合，例如 SolBianca。有些动画是 24p/30p 混合，例如 Lain 的 OP、Kurumi 的 OP。还有 48p 的情况..... 做动画比较复杂 ^^;
电影的话就比较简单，绝大多数的电影都是 24p 拍摄的，一般我们看到的都是，没有例外。
如果是 24p 的讯源，telecine 的时候做 3:2 pulldown，例如原本是
A B C D
四个 Frame，拆成 [Ao Ae] [Bo Be] [Co Ce] [Do De]，每个 Frame 拆成奇（Odd，Ao Bo Co Do）偶（Even，Ae Be Ce De）两个图场，然后以 2-3-2-3 这样形式重复排列，变成
[Ao Ae] [Bo Be Bo] [Ce Co] [De Do De] 2 - 3 - 2 - 3
然后每两个图场重新组合为一个 Frame
[Ao Ae] [Bo Be] [Bo Ce] [Co De] [Do De]
就变成五张 Frame，原本四张变五张 4->5 => 4*6->5*6 => 24->30
24fps 就会变成 30fps。
因为是以 3:2 这样的比例排列，所以称为 3:2 pulldown。
我们观察可以发现：
1. 3:2 pulldown 24->30fps 并没有增加新的画面，多出来的 Frame 是原本的画面"重复"组合"出来的结果。
2. 3:2 pulldown 之后，原本张张 progressive 的画面，变成有 interlaced 的画面，而且是五张之中有两张交错，第三张的 [Bo Ce] 和第四张的 [Co De] 交错，下一组的五张画面也是第三和第四张的画面会交错，呈现一种周期性的现象。
所以遇到讯源是 24p，经过 telecine 3:2 pulldown 变成 30fps，encoder 压缩时没有做 IVTC，以 NTSC 30fps 压缩 这样的 DVD，DVD2AVI 就会显示 NTSC 100%。然而我们 preview 观察时，会发现 "每五张之中，只有两张是交错的，另外三张没有交错"。呈现这种周期，我们就可以知道，这个讯源是 24p 的，只是经过 3:2 pulldown 之后才变成 30fps 的，我们可以对它做 IVTC。
| 引用 |
|
如果用DVD2avi看到的信息是NTSC，是否意味着这张盘是模拟转录的盘呢？
|
不太明白您的意思 ^^;
| 引用 |
|
因为我自己手头有1区、3区、6区和全区的盘，似乎FILM的出现和是否是正版并无关系。 尤其是国内的正版DVD，包括6区和全区的，似乎都没有出现FILM字样，反而是几张D5的盗版碟是FILM 98%左右的。 |
出现 FILM，代表 DVD 的 encoder 压缩时有做 IVTC，先帮你转回 24p 了，所以你不用辛苦做 IVTC，直接用 DVD2AVI 的 Forced FILM 输出即可。
encoder 会不会做 IVTC 和是否正版无关。不过通常来讲，正版的品质较佳，1 区通常 FILM 率都很高。
| 引用 |
|
那么像这种情况，没有出现FILM的（是完全没有，而不是低于9x%），应该也不是Progressive的吧？我对这种盘一直是进行IVTC的，这种做 法是否正确？
|
没有出现 FILM，和讯源本身是 24p 或 30i 无关，FILM 只是 DVD 的 encoder 有做 IVTC，或者是数字讯源 24p 直入，如 StarWar II。完全 NTSC 的片子，还是有可能原本是 24p，经 3:2 pulldown 转为 30fps，可以还原回 24p。这种片子交错会呈现一规律周期，每五张烂两张，不是张张都交错。
其实，绝大部分的电影，都是 24p 的，不需要判断。
请问sillky，能不能讲讲.ecf文件对编码是如何控制的？对于用ND做1CD或者2CD影片，应如何编写ecf文件？侧重点有何不同？另外，哪里能 找到关于这方面知识的详细介绍？
这个写起来很复杂 ^^;
用 ecf 去控制每个 Frame 的压缩状态是一件很繁复的工作，一般不会有人去这么做，实在太辛苦了。我会用的原因是因为想压超变态的画质，而且我压的是动画的 OP/ED，只有一分半钟，所以可以这样慢慢搞。一般长篇的影片用这样手动设定调整的方式是非常耗费时间的。
我把简单的参数说一下，详细的原理（例如什么是 Motion，什么是 Gauge，调整之后会有什么作用）就不仔细说明了，因为现在 DivX 5/XviD 可以更轻易地做到相同的品质。
Nandub 压缩的时候可以读入一个 ecf 档来控制压缩的参数，
ecf 是 encoding control file 的简写，内容是文字文件，
指令的格式是 @: [=] [, [=] ]
可以控制的参数有五种：
K 强制某个 frame 为 keyframe
D 强制某个 frame 为 delta frame
R=nnnn 指定某个 frame 的 bitrate(0~6000)
CL=cc 指定某个 frame 的 Compression Level(=Quantizer, 2~31)
M=mmm 指定某个 frame 的 Motion(0~300)
G=gg 指定某个 frame 的 Gauge(%, 0~100)
譬如说我要指定从第 1 个 frmae 到 2000 个 frame 都用 keyframe 2x 压缩（疯了 ^^;
写法是这样：
@0-1999: K, CL=2
也可以分别指定不同的 frame：
@2000: R=1000, CL=31
@2001: R=3000, CL=3, M=300
@2002: R=6000, CL=2, G=70
Modulation % 设定会让 Nandub 根据 动态（Motion）值调整 Antishit
例如 Antishit 设为 21dB, Modulation 6%, 遇到 Motion 是 289 的画面，
Antishit 会自动降低变成
21dB * ( 1 - (289/300) * (6/100) ) = 17.3586dB ^^^^ ^^^^^^^ ^^^^^ AntiShit 动态比例 modulation 6%
Nandub 1st-pass 计算的动态（Motion）最大值是 300，我们可以故意指定
Motion 为 3000，这样会让这个 Frame 的 Antishit 启动值降低到不会启动。
关于这方面的介绍网站，我没有看过，也很少有人会提到 Nandub 有一个 ecf 文件可以做这种控制
有很多个 Frame 要控制的时候，GKnot 可以让你设定以后存盘为 .ecf 文件，用这个 ecf 再自行编辑修改会比较方便。
有个问题想问一下silky兄，因为我平时接触的DVD都是4区25fps的film，所以一直可以跳过反交错这个步骤不用理会，但是对于pal格式的interlaced类型，是否也只能是进行deinterlace?按理来说答案应该是“yes”，但 是decomb的telecide()有时却又可以在不改变fps的情况下完美恢复progressive frame，不知道原理如何，还望赐教。。
net1999 兄
赐教实在是万万不敢当，小弟对 PAL 制可以说是完全没有经验，您这么客气实在是令小弟万分惭愧。
PAL 25fps interlaced 的讯源（25fps 张张都交错的讯源）和 NTSC 30fps interlaced 的讯源一样，要做垂直分辨率 x576/x640 在计算机上播放的 AVI/RM/WMV... 只好做 de-interlace，将画面去交错。或者是做成 VCD 的话，垂直分辨率只有一半，PAL 是 x288，NTSC 是 x240，只有原本的一半图场，此时就可以不用去交错，直接单取奇或单取偶的图场即可。
这种讯源通常出现在电视节目上，或者是自行用摄影机拍摄下来的影片，他们是以 60 fields/50 fields per second 的速率拍摄，每一张 field 拍摄的时间点都不同，所以组合成 Frame 的时候张张都交错。但是现在也有越来越多的电视节目是以 24p 拍摄，所以完全交错的讯源比较少见。
而电影绝大部分是以 24p 拍摄，telecine 过带成 PAL 的母带时做的是 2:2 pulldown
[Ao Ae] [Bo Be] [Co Ce] [Do De] 2 - 2 - 2 - 2
如上所见，组合以后还是原本无交错的四张画面，但是播放的速度加快 4%，提升为 25fps，同时声音的部分也加快 4%，这样才能跟上同步。
所以理论上 PAL 的电影 DVD 应该是很好处理的，画面本来就没有交错，不像 NTSC 那么麻烦。
然而我注意到论坛上有朋友提过 PAL 的电影 DVD 还是有的有交错，我当时就觉得很奇怪，为什么会这样？我当时猜测可能这些 DVD 的母带是自行用交错式的摄影机去转拍的关系。（因为我没有实际碰过这种 PAL DVD 的经验 ^^;）
现在听您提起这种 DVD 可以用 decomb 的 telecine() 组合成无交错的画面，才让我恍然大悟这是怎么回事 ^_^
原来大家忘掉一件最重要的事情，叫做 Field Order。
Field Order 是指摄影机拍摄的时候拍摄的顺序和显示的时候显示的图场顺序。
如果是奇先（Top Field First），那么画面顺序就会是
奇 1 2 3 4 5 偶 1 2 3 4 5
第一张画面奇数图场先放，然后是第一张画面的偶数图场，接下来是第二张画面的奇数图场.... 依此类推。
如果是偶先（Bottom Field First）
奇 1 2 3 4 5 偶 1 2 3 4 5
NTSC 的讯源在做 IVTC 之前，开启档案读取的时候一定要先判断讯源是奇先还是偶先，例如大多数的讯源都是"奇数图场优先"，大多数的采集卡是"偶数图场优先"（日本的例外），大 多数的 DV 是奇先。
如果奇先偶先的顺序设错，则 IVTC 的时候怎么补都补不回来，怎么补画面都还是会交错。所以 DVD2AVI 的作者在他网页上写的 IVTC 的教学中强调，在做 IVTC 之前，一定要先判断讯源是奇先还是偶先。
前一篇文章列的那个 3:2 pulldown 的顺序叫做 Odd First 的 Telecine，我以前讲的时候有注明，前一篇说明的时候怕麻烦省略，现在看来是非讲不可了
[1o1e][2o2e][3o3e][4o4e] => Odd First Telecine => [1o1e][2o2e][2o3e][3o4e][4o4e]
如果是 Even First 的话
[1o1e][2o2e][3o3e][4o4e] => Even First Telecine => [1e1o][2e2o][2e3o][3e4o][4e4o]
一个奇先的画面把它用偶先顺序的组合（先取偶，后取奇）读取，会得到
奇 2 3 4 5 6
偶 1 2 3 4 5
张张画面都交错，顺序完全乱掉。
一个 Odd First 的 Telecine 把它用 Even First 的顺序去 IVTC，画面还是会交错，顺序完全乱掉。
所以在做 IVTC 之前，一定要先判断奇先偶先。
判断奇先偶先的方法，简单的步骤如下：
用 TMPGEnc 加载影片（我用的是英文版，不知道相对应的选项中文是怎么翻译的），Setting -> Advanced -> Deinterlace -> Method 选 "Even-odd field (field)"，点一下画面然后按左右方向键的右键，放看看画面的情形怎么样。如果画面中的物体移动不顺畅，会突然往后倒退，代表目前 TMPGEnc 在 Advanced 设定底下的 Field order 设反了，本来设 Top field first 就改成 Bottom field first，本来设 Bottom field first 就改成 Top field first。
设好正确的 Field Order 之后，才能用 TMPGEnc 做 IVTC。
或是参考 DVD2AVI 的作者 jackei 的网页，有详细的图文说明
http://arbor.ee.ntu.edu.tw/~jackei/dvd2avi/ivtc/
请一定要看一看，jackei 神样写的文章都是宝贝
如果可以看繁体中文，请看 jackei 神样写的其它文章
# DVD 是如何用 TFF/RFF 旗标作 24->30fps 输出
http://bbs.irradiance.net/txtVersion/treasure/animation/
M.928082084.A/M.940069311.A/M.971722833.A.html
http://bbs.irradiance.net/txtVersion/treasure/animation/
M.928082084.A/M.940069311.A/M.971722833.B.html
# TMPGEnc 是如何利用画面的「奇偶差异」和「动态」这两个数据判断，作 IVTC
http://bbs.irradiance.net/txtVersion/treasure/animation/
M.928082858.A/M.955422324.A/M.955422334.B.html
还有其它一大堆，精彩至极的文章，有兴趣研究者千万不可错过
回过头来讲 PAL ^^;
那种交错的 PAL 电影 DVD 是怎么回事呢？我猜大概是 Field Order 设反了。遇到这种张张都交错的 DVD，但是讯源是 24p，实在不可能有交错，您用 DVD2AVI，勾选 Video -> Field Operation -> Swap Field Order 试试看，看画面是不是就恢复正常了 ^_^
decomb 的 telecide() 会自动判断画面的奇先偶先顺序，帮你转回正确的 Field Order，所以经过 telecide() 之后画面也会正常。但是这样还要让 decomb 去做判断会拖慢速度，所以不如直接更改 .d2v 档案里的 Field Order 顺序，这样比较简单，而且迅速。
试试看，看是不是因为这个原因。如果猜错了.... ^^; 那我们再继续研究
显示 NTSC 百分之几或 FILM 百分之几，就是 Hybird 的 DVD（NTSC/FILM 混合），这种就是 24p -> telecine -> 30fps 的讯源。其中 NTSC 的部分就会是每五张烂两张。FILM 的部分是 DVD 压制的时候 encoder 有做 IVTC 还原。
如果显示纯 NTSC，但是 preview 时张张无交错 => NTSC 30fps progressive。
如果显示纯 NTSC，但是有些交错有些没交错 => 24p -> telecine -> 30fps 的讯源，encoder 压缩时没有做 IVTC。
如果显示纯 NTSC，但张张都交错 => NTSC 30fps interlaced。
如果显示太快分不清是 NTSC telecined 讯源还是 NTSC interlaced 讯源，可以用 VD/TMPGEnc/AviUtl 加载 .d2v 一张一张慢慢看。通常应该很容易辨认，电影的 DVD 只有 PAL/FILM/NTSC/Hybird，PAL 直接输出，FILM 选 Forced FILM 输出，NTSC 要做 IVTC，Hybird DVD 的 FILM 比例不高的话也要做 IVTC。30fps progressive 只出现在动画、特殊影片，一般不容易遇到。30fps interlaced 出现在 DV、电视台节目，这种的要做之前应该就很清楚讯源的类型是什么，例如是转自己拍摄的 DV 带。
判断 IVTC 是否成功，我想只能用眼睛看吧
如果眼睛看不出来，就当它是成功吧
我手动补正的时候也是这样，眼睛看不出来或没看到的部分，就算了 ^^;
是的，TMPGEnc 有 Interlace 压缩模式（Encode mode: 选 Interlace）。MPEG-2 的 Interlace 压缩会用 Field Picture 结构，Field/16x8 动作预测模式压缩，或者是用 Frame Picture 压缩，但是还是可以用 Field DCT，Field 动作预测模式。
Field Picture: 以 Field 为单位压缩，将奇数场、偶数场视为两个独立的画面分开压缩
DCT Type: Frame DCT
动作预测模式:
1. Field 预测
2. 16x8 预测
3. Dual Prime 预测（只有在没有 B-frame 的时候才能使用）
Frame Picture: 以 Frame 为单位压缩
DCT Type: Frame DCT，遇到交错画面时使用 Field DCT
动作预测模式:
1. Frame 预测
2. Field 预测
3. Dual Prime 预测（只有在没有 B-frame 的时候才能使用）
据研究，Frame Picture 的压缩效率较高，所以 MPEG-4 已经不用 Field Picture 的压缩结构。
TMPEGEnc 好像是以 Frame Picture 压缩（以前研究过，结果我忘了 ^^;），交错画面会使用 Interlace 的压缩工具（Field DCT... 等等），对交错画面直接压缩的压缩效率还是很好。
所以如果是要在电视上播放，不要去交错以 Interlace 模式压缩即可，TMPGEnc 对于场的画面处理还是不错。
如果要在计算机上观看，我想还是做去交错看起来舒服些
如果制作 VCD，垂直分辨率只有一半 x288/x240，我想单取奇数场或偶数场即可，也不用去交错。去交错后再 resize -> x288/x240，观看时会发现有重迭的画面。不去交错单取奇或偶，便看不到重迭的画面，但是画面会顿。
请Silky讲讲手动补正时，copy frame和ctrl+p的用法及其运用的条件，jackie讲得太简单，不太明白，尤其是如何判断telecine序列的问题
手动 24fps 补正，修正自动补正判断错误的画面，我转一段 jackei 在他的网页上教学文件里面写的说明：
「Misjudging frame correction is very tricky, so I suggest you forgetting it :-p
Actually, the accuracy of TMPGEnc/AviUtl IVTC is good enough.」
「If you understand Chinese, refer to http://bbs.irradiance.net/txtVersion/treasure/animation/M.928082858.A /M.955422324.A/」
手动补正错误的画面是非常困难的，所以我建议你忘掉它吧 :-p
事实上 TMPGEnc/AviUtl 的 IVTC 正确度已经很好了。
如果你懂中文的话，请参考 http://bbs.irradiance.net/txtVersion/treasure/animation/M.928082858.A/M.955422324.A/
连他老人家都这么说了...
要用文字说明手动补正的步骤是非常困难的 ^^;
我的建议是，先用 TMPGEnc 做自动补正，选「去交错优先」（Flicker prioritized）。跑第一遍的时候要计算画面的数据会比较慢，跑完以后数据会记录在 TMPGEnc/Cache 底下。按 Ctrl + 左右方向键移动，检查画面是否有交错。通常 TMPGEnc 会在场景切换的地方判断错误，所以我们只要移动到每个场景切换的地方，看看判断有没有出错，是否在切换场景之后画面就开始有交错，判断开始出错。如果自动 补正判断发生错误，我们便在开始交错的前一张，按鼠标右键，选「Enable automatic setting after this frame」，从这个 frame 之后再跑一次自动补正，注意自动补正是可以跑好几次的。第二次补正的时候速度会非常快，因为数据第一次补正的时候都已经算好了，所以第二次补正速度会很 快，一下子就选好了。通常第二次补正以后，原本选错的画面就会正确了，然后再移到下一个场景切换的地方检 查。
还有 TMPGEnc 经常在在交错量小的画面判断错误，例如动画人物开口说话的画面，此时画面上大部分区域都是静止的，只有嘴巴的部分是交错的，TMPGEnc 会在这种地方判断错误，此时可以手动一张一张选择。
另外也可以用眼睛观察画面的 telecine 周期，TMPGEnc 会将原本的五张画面拆成十张画面
0a 0b 1a 1b 2a 2b 3a 3b 4a 4b ... 1奇 2奇 2奇 3奇 3奇 4奇 4奇 5奇 5奇 6奇 ... 1偶 1偶 2偶 2偶 3偶 3偶 4偶 4偶 5偶 5偶 ...
你用眼睛看，这十张画面哪几张是交错的，拿一张纸记录打叉做记号。十张之中要挑选四张，两张一样的只选其中一张。例如下面的例子，假设 0b 交错 打叉。1a 和 1b 都无交错，画面相同，两张挑一张看起来比较好的，选 1a。1b 也打叉。2a 交错，2b 无交错打圈。3a 交错。3b 和 4a 都无交错，两张画面相同，挑 3b 打圈。4a 打叉... 结果如下
o x o x x o x o x x ... 0a 0b 1a 1b 2a 2b 3a 3b 4a 4b ... 1奇 2奇 2奇 3奇 3奇 4奇 4奇 5奇 5奇 6奇 ... 1偶 1偶 2偶 2偶 3偶 3偶 4偶 4偶 5偶 5偶 ...
然后按鼠标右键，选「Deal after this frame according to selected pattern」（或者是按 Ctrl + P），手动输入选择的画面，打圈的画面是要选的填 1，打叉的画面是不选的填 0，所以填入「10100」这样就可以了。有时候用眼睛观察很快，手动指定 pattern，注意切换场景的地方有没有换周期，一下子就补好了。
有时候补完以后还是有几张画面选错，这时手动挑选没有交错的画面即可，视情况可以增减挑选的画面。注意手动挑选或增减画面的时候会造成影音不同 步，TMPGEnc 小窗口中底下有两个数字，Estimated: xxxxx(24fps) 这个数字是估计 24fps 补正后这张画面应该是第几个 frame，Current: xxxxx(24fps) 这个数字是根据目前你补正的结果，这张画面会是第几个 frame。注意要让 Estimated 和 Current 的数字不可以相差超过 1，否则会明显的影音不同步。左边有个 Check 的按钮会帮你检查是否有影音不同步的情形发生。有增减画面时，例如有某张交错画面选了会交错，去交错又不好看，邻近画面又没有无交错的可以取代，干脆就不 选。这样就会少一张画面。如果有减少画面，后面就要想办法多补一张画面，例如挑一张静态的画面多补一张 ，以弥补前面少选一张画面的损失，否则缺少画面太多会造成影音不同步。补画面的动作最好在同一场景内完成，在那个场景内减少一张画面，就在那个场景内多补 一张画面弥补，最好不要拖到下一个场景才补。
要多选重复的静态画面时，Copy Frame 这个功能就很有用。按鼠标右键选 Copy Frame，目前的这个画面就会以前面的画面取代，变成和前面那张画面一样。有时候前后两张画面相同，但是后面那张有压缩瑕疵，选了很难看，不选又不行， 这时就可以使用 Copy Frame 的功能，复制一个画面。这样不但可以避免有瑕疵的画面，而且使用 Copy Frame 前后两张画面完全一样，压缩时压缩效率会非常高。encoder 甚至可以完全 skip 掉第二张画面不压缩，对压缩也非常有帮助。连续静态画面时，干脆通通设定为 Copy Frame。
TMPGEnc 还有一个超强的功能，可以手动指定 P/B copy frame。在 GOP structure 里面「Force picture type setting」，可以手动指定 Picture Type。按鼠标右键有个「P copy」和「B copy」，会复制前一张画面，TMPGEnc 压缩时会直接 skip 掉这些 copy frame 不压缩，显示时是直接拿前一张相同的画面来显示，不但压缩率高，而且静止画面会完全静止，不会有骚动感，画面非常漂亮，请看 jackei 写的
[秘技](T)MPEG(Enc)静止画面绝对静止法
http://bbs.irradiance.net/txtVersion/treasure/animation/M.928082858.A/M.959619674.A/
这个功能只在用 TMPGEnc 压 MPEG-1/MPEG-2 有用。
遇到画面有交错又不得不选的情况，只好用「单张去交错」，只对这张画面做去交错。按鼠标右键选「Deinterlace」就可以单张去交错，指定这个画面 去交错的方法。选一个看起来伤画面最小的方法。
写得好乱，我都不知道接下要讲什么.....
其实，补正这种东西，做久了就熟练了，自然会有很多心得。如果硬要条列式的说明的话，反而不知道该从何讲起
所谓动画职人，补久了以后，经验越多，补正的速度也就越快，靠直觉就知道哪里会交错
我看过朋友那种吓人的补正速度，你只看到他 AviUtl ins/del 按按按，按个没几下，两三分钟之后就说「好了，补完了」 ^^;;
看一遍检查一下，几乎没有补错 ^^;;;
在没练到那种超人的技巧之前，就偷懒吧
如同沈老大说的，要在 Encode mode 选 Interlace。
ProCoder 也有类似的选项。
有用 Interlace 的压缩工具的话，压缩交错画面的效率就不会太差。
先去交错以后再以 Progressive 模式压缩也可以，但是这样有缺点
1. 画面会模糊。
2. 动态差异大的画面，去交错以后会变成两个 Field 的影像重迭的画面，以 Frame 压缩一样不好压缩（复杂度大）。
既然是要在电视上观看，那么以 Interlace 模式压缩保留较多的原始讯息应该会比较好。
对了，
忘了说，XviD 的「Enable interlacing」选项就是启动 Interlace 压缩模式，会使用 MPEG-4 的 Interlace 压缩工具。不过 -h（一个人，常上 Doom9 的人应该不陌生）只有做到 Field DCT，没有把 Field 动作预测模式也写出来（因为他说太复杂了 ），所以 XviD 的 Interlace 模式只有部分的压缩工具，压缩效率不如 TMPGEnc。
TMPGEnc 的作者崛老实在太厉害了，他说想要写 MPEG-4 的编码器，我真是非常期待。
（MPEG-4 还有一堆工具 DivX/XviD/FFMPEG 目前都没有作出来，例如任意形状编码等等）
我想崛老做的 MPEG-4 编码器应该也会是最强的
Frame DCT 的意思是，做 DCT 转换的时候，一个 16x16 的 "Macroblock" 切成四等分，四个 8x8 的 "block" 分别做 DCT 转换。像下面这张图（图片来自 ISO MPEG-2 Standard 文件）
Figure 6-12 Luminance macroblock structure in frame DCT coding
Field DCT 的意思是，做 DCT 转换的时候，将 Macroblock 中的奇偶顺序重新排列，变成两个 16x8 的方块，一个方块是由奇数的扫瞄线组成，另一方块是由偶数的扫瞄线组成，然后再将这两个 16x8 的方块水平方向切成两半，最后一样变成四个 8x8 的方块，分别做 DCT 转换。
这样这四个方块中的系数，全部都来自同一个 Field，这样叫做 Field DCT。像下面这张图
Figure 6-13 Luminance macroblock structure in field DCT coding
以上是 Luminance 的作法。MPEG-2 规定，YUV 4:2:0 的时候，Chrominance 一律使用 Frame DCT，4:2:0 以上才可以使用不同的 DCT Type。
为什么交错画面使用 Field DCT 压缩效率较高呢？
这是因为在交错画面时，奇偶扫瞄线的像素分别来自两个不同时间点拍摄的 Field，差异很大，譬如说一奇一偶这样排列：
1
99
2
100
3
101
你可以看出奇数扫瞄线的像素彼此之间的的数值比较接近，而偶数扫瞄线的像素彼此之间的数值也较接近，一奇一偶交叉排列在一起的话，这个数值会有一个很快的 频率起伏变化
小
大
小
大
小
大
这样我们称为，这个方块有很高的空间频率成分。如果直接拿这样奇偶合并的方块去做 DCT 转换，DCT 这个转换就是把空间上的像素转换为以频率域上的系数来表示，以消除空间上像素彼此之间的关联性（冗余性），这样使用几个比较少的频率系数就可以代表本来的 讯号。当方块中有这样变化频繁（奇偶差异大，关联性小）的像素的时候，转换后能量就不会集中在少数几个 空间频率的系数上，当然这样就会造成压缩困难。
所以我们才会设计 Field DCT，将奇偶拆开分别做 DCT，以增进交错画面的压缩效率。
MPEG 压缩的时候会做 DCT 转换，这个转换是以 8x8 像素大小的方块（block）为单位，将方块内的 8x8 像素值转换为代表方块内的 8x8 空间频率的系数。因为自然影像通常不会在很小的区域范围内有很大的变化，相邻的像素点数值通常会很接近，也就是说不会有很复杂的空间频率系数，经过 DCT 转换以后，代表这张影像的能量会集中在几个空间频率的系数上，其它大部分的系数，尤其是高频的系数都会变成 0。这样我们就可以用比较少的，代表空间频率的几个数字，来描述原本的影像，而不用记录原本复杂的 8x8 = 64 个影像像素的灰阶值。这第一步就可以消除影像在空间上的冗余性，或者叫关联性，达到数据压缩的第一个目的。冗余性越高，也就是影像内像素的灰阶值彼此之间 越接近，越平均，经过 DCT 转换后的能量就越集中，非 0 的 DCT 系数就越少。数据的「冗余」的意思是，譬如我说 q 你大概就可以猜出后面会接 u，因为英文单字中 q 后面接 u 的机率很高。出现机率越高，代表这笔数据所包含的信息越少，冗余越多。这样我们要记录这些冗余实在很没有效率，所以我们换个描述、表达的方式，把冗余去除 掉，把信息用更简洁的方法表现出来。DCT 转换差不多就在做这样的事。（譬如说我讲一个故事花了 600 字，废话、赘字很多，你把它重新改写，只花了 300 字就讲完了..... 差不多就是这个意思 :P）
所以这个转换有没有效率，能不能让转换后大部分的系数都变成 0，让能量集中在少数几个系数上，要看原本方块内的像素彼此之间接不接近。如果关联性越高，转换的效率就越高。
所以前面举的例子，如果是交错的画面，奇偶差异大，垂直方向的关联性降低，这样转换效率就会下降。所以我们用 Field DCT，将奇偶拆开做 DCT 转换，譬如说假设现在垂直方向四个像素的灰阶值是
22
44
33
55
Field DCT 会把奇偶分开做 DCT 转换
22
33
44
55
你可以看出垂直方向的差异缩小，关联性提高，这样的 DCT 效率就会比较高。
注意 Frame DCT/Field DCT 可以以 Macroblock 为单位做切换，在 Progressive Frame 里面还是可以用 Field DCT，好的 Encoder 会自行判断用哪一种 DCT Type 压缩效率会比较高。
至于动作预测模式太复杂就不讲了
可是又出了个新问题，为什么同样是用Flicker prioritized跑一遍，有的片子每5张画面会有3张被红框选中(说明有3张画面被补过了)，而有的片子每5张画面却正好只有2张被选中呢？我猜这 是不是跟讯源的类型有什么关系？
TMPGEnc 会自动选择没有交错而且又能保持影音同步的画面，有些画面如果选了会有交错，TMPGEnc 就会自动选择其它没有交错的画面来取代，所以就可能会出现五张之中选了三张。
不过不用担心，TMPGEnc 一定会选则能保持影音同步的画面，不会不同步。
所以也有反过来的情况，有时候 TMPGEnc 很奇怪，明明画面有交错，但是不管自动补正重跑几次，TMPGEnc 还是会选有交错的那张画面，而不会选旁边没有交错的画面。
这是因为如果选了其它画面，就会影音不同步，非选那张有交错的画面不可，所以 TMPGEnc 才会执意要选那张有交错的画面。
其实有时候可以变通一下，如果在不是很注重影音同步的场合，例如不是在说话的画面，不需要很精确地对准，让说话的声音符合嘴形，那么我们可以手动选择会让 影音不同步但是没交错的画面来取代，只要播放时不会明显察觉到影音不同步就好。
| 引用 |
|
另外，telecine周期的确定应该跟被选定应用pattern模式的起始画面有关系吧，所选的起始画面不同，周期也会不同吧？
|
是的。
| 引用 |
|
记得在很久以前，那时好像VCD都还没有！应该是八十年代吧！ 看到过一篇关于电影胶片在电视上播放的知识性文章！ 那篇文章说的就是让24帧每秒的电影胶片以25帧每秒的速度播放，就可以录制成电视上可播放的节目了。所以那篇文章最后说在电视上观看的电影总要比在电影 院里观看短那么几分钟！ 那么现在的PAL制式的电影节目还是这么做的吗？ |
是的，还是一样的作法。
如同我前面说的，telecine 时做 2:2 pulldown，播放速度加快 4%，声音也跟着一起加快 4%。
TMPGEnc 环境设定底下，VFAPI Plug-in 有将 DirectShow Multimedia File Reader 的优先权（Priority）调高吗？
TMPGEnc 要藉由 DirectShow filter 来读取文件时，必须要将 DirectShow Reader 的优先权调高才能读取。例如使用 AC3Filter，就是一个 DirectShow filter（后缀是 .ax），要使用 AC3Filter 来解码，就必须要调高 DirectShow Reader 的优先权。
Windows Media Player 等播放软件预设会以 DirectShow 解码，所以能播放不代表 TMPGEnc 能解码，如同光有 ffdshow 这个 MPEG-4 的 DirectShow filter，却不能用 VirtualDub 等软件开启 MPEG-4 的文件，因为 VirtualDub 只能以 VFW Codec（Video for Windows Codec）来解碼（后缀是 .dll），不能用 DirectShow filter 解码，所以系统上有 ffdshow 也没用。
所以要用软件开启时，必须要注意该软件是用哪种方式来读取文件，安装相对应的解码器，并且调整设定。
试试看，说不定问题就解决了 
另外 Soft Encode 解碼的音质比较好，如果可以的话建议用 Soft Encode 解碼。
免费的 AC3 decoder 大部分是用 LibA52 来解碼，我听过的几个音质都很不好，甚至不如 DVD2AVI，所以建议用 iviaudio.ax（WinDVD）或 Soft Encode 解碼。
Soft Encode 解码时，如果是音乐类型的片子，不要选 RF mode，最好用 Line out mode（在 Options -> Decoding setting），这样子动态压缩不会那么厉害，音质会比较好。（我自己用甚至全部都选 Line out mode，不管哪一类型的影片。Line out mode 音量会比较小，再用 Normalize 放大即可）
原来试过老版本的普通的2:1滤镜的效果是很差的, 几乎与PR的RISIZE的数学方法是一样的. 但这次用下来一看惊若天人似乎比那个LANCZOS3还要好了. 高性能2:1的那个还是与原来的差不多BLEND的成份很重.
您说的普通 2:1 滤镜是指 2:1 reduction 吗？
我做了一点实验。
学术界在测试 filtering 效果时最常用的是 "circular zone plate" 这个图形，
这个图形是由好多个圆圈所组成，画面最中间的水平和垂直空间频率是 0，
越往外围，水平和垂直空间频率越高。
水平方向远离中心，离中心越远水平空间频率越高；垂直方向远离中心，
离中心越远垂直空间频率越高；四个角落是垂直和水平的空间频率最大的地方。
空间频率越高的意思，可以想象为画面上有一黑一白，黑白相间的线条，
黑白条纹越密集，也就是灰阶值由黑变白，再由白变黑的变化频率越快，
我们说这样这张图形的空间频率很高。
根据取样定理，我们知道取样频率必须是原始讯号频率的两倍，我们才能正确地记录原始讯号。
原本宽度 640 pixels 的图形（取样点是 640 个点），其所能记录的黑白相间的变化次数是 320 次
（一黑一白，占掉两个 pixel，我们所能见到的黑色线条是 320 条，白色线条是 320 条）。
当这个宽度 640 pixels 的图形 resize 为一半 320 pixels 时，只能表现出 160 条黑白相间的条纹
，无法表现出原本图形所记录的 320 条黑白相间这么高的频率，也就是这么密集的线条。
根据取样定理，我们必须把超过所能记录的范围的频率滤掉，否则转换后这些高频的讯号会被当成
低频的讯号，我们会得到错误的结果。
以声音讯号来举例，44.1KHz 转为 22KHz，必须把原本讯号中 11KHz 以上到 22KHz 的频率滤掉，
否则转换后原本该是高频的讯号，却会变成低频的讯号，变成低频的声音出现，你想这样还能听吗 :P
为什么降低取样频率之后，超出所能记录范围的高频会被当成低频讯号？请看下面这张图
蓝色的线是原本记录的高频讯号，线条成阶梯状，每一阶都是一个取样点，
图形中的 sine 波形有 11 个周期（重复 11 次）。
降低取样频率之后，新的取样点是红色的点，取样的点数变少。
我们注意到新的红色取样点连成一条线，得到的新讯号变成是一个低频的 sine 波形（仅一个周期），
而不是原本的高频讯号。这个低频讯号在原本的讯号中是不存在的，是错误的讯号。
这种现象我们称为 aliasing。
所以我们在转换之前，必须先把这种会引起 aliasing，超过转换后所能记录的频率范围的高频讯号
滤掉，以免发生 aliasing，得到错误的结果。
那么在影像讯号的处理上，也是一样，我们必须先把 resize 后不能正确记录的高频讯号滤掉，
不然一样会得到错误的画面，例如画面上会出现锯齿，波纹（moire）等等瑕疵。
这个事先滤掉高频的 filter，叫做 pre-filter。
不同 filter 的设计，滤除的效果不同，也有不同的副作用，我们以前曾经提过，lanczos3 resize
是一个拥有最佳 filter 效果的 resize 法。
下面我们用 circular zone plate 这个图形来测试 2:1 reduction 和 2:1 reduction (high quality)
的频率滤除特性。circular zone plate 的图形中央空间频率是 0，越往外围空间频率越高，
良好的 filter 应该要尽力保持中央部分的图形的线条清晰，而外围的图形则应该全部滤除，
外围若有留下来的线条则是 aliasing 的讯号。
原始 640x640 的 circular zone plate 图形
2:1 reduction resize 为 320x320
如何判断一些MPG压缩软件所接受的数据皮是4:2:0的还是其它什么的? 记得你说过TMPGENC接受的是RGB的
MPEG-4 都是以 YUV 4:2:0 储存，如果输入的影像格式不是 YUV 4:2:0，Codec 会自动转换，
转为 YUV 4:2:0 后再开始压缩。
不同 Codec 的转换式计算精确度、UV 取样时的方法不同，出来的品质（除去压缩的因素）
也大不相同。
大部分的 MPEG-4 Codec 都可以接受许多种格式的输入，例如 YV12/YUY2/RGB24/RGB32 等等。
TMPGEnc 是以 VFAPI 读取，VFAPI 以 RGB24 传递数据，所以...
同时 TMPGEnc 的滤镜也是在 RGB24 的色彩空间下工作。
当 TMPGEnc 压缩选项勾选 Highest quality 时，就是同时做 RGB 空间上的 MV 搜寻，
所以费时很久。
其它软件接收什么格式，试试看就知道了，不能吃的话文件就开不了。
CCE 好像可以接受 YUY2 输入，YV12 不行。
Helix 好像可以接受 YV12 输入。
不管可以接收何种格式输入，大部分最后都要转为 YUV 4:2:0。
感谢小嘴巴兄的教学
我也喜欢 MPEG-2，MPEG-4 有一堆限制和令人吐血的 bug，要上到高画质很困难。
ProCoder 对比颜色过强的问题是由于小弟以前提过的 YC 压缩、伸张的问题。
MPEG 储存的 YUV 范围必须是 CCIR 601 的 YUV，也就是 Y: 16~235 UV: 16~240 的范围。
当我们将 DVD 上的数据用 DVD2AVI 解码出来，如果选 PC Scale，则 DVD2AVI 在做 YUV -> RGB 的时候，会做 YC 伸张，将 YUV 的范围伸张为 16~255 的 RGB。
DVD(601 YUV) -> DVD2AVI(Basic YUV)
这样子的 RGB，再次压成 MPEG 的时候，不管是压成 MPEG-1/2/4，都要先经过 YC 压缩，将范围压为 16~235，然后才转回 CCIR 601 的 YUV 储存起来。
DVD2AVI(Basic YUV) -> MPEG(601 YUV)
TMPGEnc、CCE 都有控制这个要不要做 YC 压缩的选项。
如果来源有做过伸张，是 Basic YUV(0~255)，则压成 MPEG 前必须做 YC 压缩；如果来源没有做过伸张，是 CCIR 601 YUV(16~235)，则压成 MPEG 前不需先做 YC 伸张。
至于这两个软件的设定选项小弟以前的文章中有写。
而 ProCoder 的大问题就是，他没有控制要不要做 YC 压缩的选项，对任何输入的讯源，他都一律不做 YC 压缩。
这样子当讯源是 CCIR 601 的时候没有问题
讯源(601 YUV) -> MPEG(601 YUV)
但是遇到讯源是 Basic YUV(0~255) 时就发生大问题了，因为 ProCoder 没有做 YC 压缩，所以会变成
讯源(Basic YUV) -> MPEG(Basic YUV)
这样子当播放时，播放器会做 601 YUV -> Basic YUV 伸张的动作，而 ProCoder 的 MPEG 原本就是 Basic YUV，再被重复伸张一次，许多 YUV 资料会超出范围被削掉。不明白的人看了会以为，ProCoder 压缩的色彩好丰富，对比好鲜明，画质真好，但其实是已经损失了许多细节。
遇到原本对比不强烈、色彩较不饱和的影片，ProCoder 这么做有补偿的作用，会让人看起来觉得还不错。但是遇到原本色彩就很丰富、很饱和，对比很强烈的影片，用 ProCoder 压缩就完蛋了，画面色彩会整个崩溃，亮部会过份泛白，而暗部则是漆黑一遍，什么层次都没了，十分凄惨。
所以用 ProCoder 压 MPEG，讯源在送给 ProCoder 之前，必须先确认 YUV 范围必须保持为 CCIR 601 YUV。
MPEG2Dec.dll 解码时会按照 .d2v 文件的 PC/TV Scale 设定，决定要不要做伸张。Avisynth 2.5 也有一个 ColorYUV 的 filter，可以做 TV->PC（伸张）or PC->TV（压缩）的转换。Avisynth 2.0x 系列也有外挂的 plugin 可以做这种转换。在送给 ProCoder 压缩前，要先将输出调整为 TV Scale/CCIR 601 YUV 才可以。
如果 YUV 范围设定正确，则 ProCoder/CCE/TMPGEnc 三套软件压出来的颜色、对比都是差不多一样的。
MainConcept MPEG Encoder 也是没有选择伸张压缩的选项，它是一律都会做压缩，所以必须接收 Basic YUV 的数据。
我想知道PSNR的值是怎样算出来...
将压缩前和压缩后的画面，每个 Pixel 的值相减，将误差平方，加总，求平均。
这个算出来的值叫做 MSE。
然后和最大讯号值的平方相比，例如 Pixel 的值范围是 0~255，最大讯号值就是 255，
那么就是和 255 的平方相比。
求出来的值取 20*log，算出来就是 PSNR，单位是 dB。
PSNR = 20*log (255^2/MSE)
所以 PSNR 算的是「和原始画面的差距」。
MSE 算式可以看 berkeley 的网页
http://bmrc.berkeley.edu/courseware/cs294/fall97/assignment/psnr.html
～～我装了VobSub后怎么图象倒过来了啊～！救救我啊～！！
画面会颠倒是因为 YUV 和 RGB 格式，一个是由上到下的放置顺序，另一个则是由下到上的放置顺序。
做 YUV -> RGB 的转换后，必须要做 flip，上下反转，画面才会恢复正常。
不同程序可能会有不同的放置顺序，例如用 Avisynth 的 VFAPISource 读进 VFAPI 的 RGB 文件后，
画面会反转，后面必须接 flip() 才会恢复正常。
然而有些程序输出的放置顺序是错误的，例如 MS MPEG-4/DivX 3.x 的 mpg4ds32.ax 就有这样的 bug，
输出 RGB 画面会颠倒，所以接在它后面的 DirectVobSub 必须反转一次，画面才会恢复正常。
如果你用的是新版的 mpg4ds32.ax，新版的 mpg4ds32.ax 已经修正这个 bug，输出画面不会颠倒，
然而 VobSub 的程序代码无法区分判断，会以为这仍然是旧的 mpg4ds32.ax，所以还是只反转一次，
这样画面就会颠倒了。
还有不同的显示卡驱动程序，不同的解码 Codec，中间插入的不同的 DirectShow Filter，
输出的情况千奇百怪，各种可能都有，有的要反转有的不要反转，所以为了应付各种情况，
VobSub 设计了 flip 的选项让使用者来自行调整，以应付各种可能的情况。
如果您要问的是这个，这就是为什么图像会倒过来的原因
详细可以参考 MSDN
http://www.microsoft.com/whdc/hwdev/tech/stream/vidcap/biheight.mspx
也就是说，你的avi的在avisynth中的设置要跟计算psnr时mpeg2source的一样--包括所有的filters,plugins--所 留下的不同就完全是codecs所造成的，对不对？
我在写计算psnr的script时遇到了问题，能不能帮我看一下
编码时的script比如是
LoadPlugin("MPEG2Dec3.dll")
LoadPlugin("Decomb.dll")
LoadPlugin("Convolution3DYV12.dll")
mpeg2source("01.d2v")
Telecide()
Decimate()
vd1=trim(1000,2000).Crop(8,0,-8,0).LanczosResize(640,360).Crop(16,16,-16,-16).Convolution3d()
vd2=trim(51000,52000).Crop(8,0,-8,0).LanczosResize(640,360).Crop(16,16,-16,-16).Convolution3d()
return vd1+vd2
那么当计算psnr时，关于mpeg2source那段时怎么把上面那一串写在一起啊？
orig=vd1+vd2
PSNR 比较的时候，是比较「和原始影片的差距」，所以您用来比较的 orig，
必须和压缩时的原始影片相同才行，如果您压缩时原始影片是
MPEG2source("sample.d2v")
crop(8,54,704,368)
LanczosResize(640,368)
比较时的 orig 就必须是
orig=MPEG2source("sample.d2v").crop(8,54,704,368).LanczosResize(640,368)
至于为什么 MPEG2Dec3 输出需转为 YUY2，那是因为目前 compare function 的问题，
您可以先转为 YUY2 再转回 YV12，不会有误差，或者是直接在 YUY2 色空间比较。
比较时建议以 Y-PSNR 为主。
我自己计算 PSNR，因为我压的片子都需要经过 TMPGEnc 的 IVTC 处理，
所以最后都是转为 VFAPI，为了不同 Codec 比较时有相同基准点，
再用 Avisynth 加载这个 VFAPI AVI，统一由 Avisynth 转成 YV12 的原始影片
avisource("GateKeepers21_OP_aup_vfapi.avi").ConvertToYV12()
比较的时候
orig=avisource("GateKeepers21_OP_aup_vfapi.avi").ConvertToYV12()
encoded=avisource("GateKeepers21_OP_XviD.avi", false, "YV12")
compare(encoded, orig, "Y", "PSNR-XviD.LOG")
比较含有 B-frame 的 AVI，XviD 的 vfw Codec 开头会固定有一张延迟的 delayed frame，
要将它删除，删除以后就可以对齐比较了
encoded1=avisource("XviD.avi", false, "YV12").Trim(1,0)
删除以后，XviD 的末尾会少一张 Frame，所以若是要和其它 Codec 比较，例如 DivX 5.05，
DivX 5.05 就必须要删除最后一张 Frame，这样比较才会公平。
假设总共是 2001 张 Frame，0~2000
encoded2=avisource("DivX.avi", false, "YV12").Trim(0,1999)
PSNR4AVI 算出来的结果，我以前用，有一些怪怪的，可能是 RGB 转 YUV 的问题。
有 B-frame 的 AVI 一定要用 Avisynth 算，结果才会正确。
TMPGEnc 本身不能 decode MPEG-2 file，必须透过 DirectShow filter，使用系统上的 MPEG-2 decoder 来解码。
在 2.57 版以前，只要在环境设定中，VFAPI plug-in 设定底下，把 DirectShow Multimedia Filter Reader 的优先顺序调高，同时系统上有装 WinDVD, PowerDVD 等 MPEG-2 解码软件，就可以加载读取 MPEG-2 file。
2.57 版和 2.57 版以后，为了安定性，TMPGEnc 不再使用 DirectShow Multimedia Filter Reader 读取 MPEG-2 档案，即使把优先权调高也没用。
2.57 版以后，TMPGEnc 本身内建了三个 MPEG-2 decoder 的 VFAPI plug-in，优先顺序分别是 1.Sony 2.Ligos 3.CyberLink。
Sony 的 MPEG-2 decoder 在 Sony VAIO RX 系列的计算机上有装，Ligos 的 decoder 装 Ligos 的软件便可以取得，ProCoder 好像也是装 Ligos 的 MPEG-2 decoder，而 CyberLink 只要装 PowerDVD 即可。
装这三个 decoder 的任何一个，TMPGEnc 就可以使用内建的 VFAPI plug-in 读取 MPEG-2。
==
然而，PowerDVD 从 4.0 版的 1811 patch 以后，改成一定要强制使用 Overlay 输出，所以 TMPGEnc 便无法再使用 PowerDVD 的 DirectShow filter 来解码。
解决的办法
1. 安装 Ligos 的解码器
2. 使用旧版的 TMPGEnc，将 PowerDVD 的 DirectShow filter 优先权调低，将系统上的其它 MPEG-2 decoder 的优先权调高，例如将 WinDVD 的 DirectShow filter 优先权调高，就会使用 WinDVD 的 DirectShow filter 来解码。
调整 DirectShow filter 的优先权，例如你系统上装了很多个 MPEG-2 decoder，要选择要用哪一个 filter 来解码，这时候就会需要手动调整优先权的设定，有软件可以做这样的设定，请自行搜寻。
3. 以上的方法都不建议使用。事实上这些方法解码的品质都很差，而且有错误，比较好的作法：
a. 用 DVD2AVI 这个软件读取 MPEG-2 file，存成 .d2v，再用 TMPGEnc 开启这个 .d2v 文件。
b. 安装 MPEG-2 VIDEO VFAPI Plug-In，就可以直接用 TMPGEnc 开启 MPEG-1, MPEG-2, .vob文件了。而且 MPEG-2 VIDEO VFAPI Plug-In 解码的画质非常好。
建议使用 3 的做法，不要再用 PowerDVD 来做 MPEG-2 解码的工作了。
PowerDVD 的 DirectShow Filter 会做 Bob，也就是 blend，画面会较模糊。
m2v，也就是上面说的 MPEG-2 VIDEO VFAPI Plug-In，画质是最好的，它的 upsampling 比 DVD2AVI 还高阶，而且
1. 它的 chroma upsampling 和 DVD2AVI 一样是正确的，其它的 MPEG-2 DirectShow Filter，除了 PowerDVD 以外，WinDVD, Ligos 等我试过的都是错的
2. 它是目前唯一能正确解码 HDTV 的 MPEG-2 TS 的程序，解 HDTV 的 MPEG-2 TS，只有它解出来的颜色才是正确的，连 DVD2AVI 解的颜色都无法正确，这个说起起来又是一番长篇大论，我现在没时间慢慢写，有人知道 Doom9 上的 trbarry 写了一个 Avisynth 的 filter，叫做 BT709ToBT601 吗？那个 filter 处理的就是这个问题。等晚点我忙完了以后再上来详细说明，因为处理 HDTV 的人还很少，所以我从来没有公开地讲过这个问题。
DirectShow Filter，是播放的时候使用的，讲求的是实时解码，解码速度要快，画质很难讲究。
用 DVD2AVI，m2v 这种外挂解码，才能得到好的画质。
至于 DVD2AVI 解出来颜色颜色失真，偏淡，或者是 m2v 解出来颜色失真，偏淡，那是我从前提过的一个老问题，叫做 YC 伸张压缩的问题，我为了这个问题写过数万字，差不多和我写 resize 的问题差不多多次，我已经写到快无力了 :P
这是设定的问题，设定正确，就不会有颜色失真、偏淡的现象。
DVD2AVI 和 m2v 是是上两个最强的神人写出来的软件，怎么可能会比一个 DirectShow Filter 还要差？
详细的设定，我晚点在慢慢从头把来龙去脉重写一次。
我没有用power dvd codec
我知道
我前面贴的，第一篇是以前回答有人问「为什么安装新版的 PowerDVD 后 TMPGEnc 就开启不了 MPEG-2 文件」这个问题时写的文章。因为我回第一篇的时候很急，没有时间修改，所以是直接转贴以前写的文章，回答有点前言不对后语 ^^;
第二篇回答再提到 PowerDVD，是因为看到前面 net1999 兄提到，PowerDVD 解出来似乎较模糊，好像是因为 blend 的关系，所以我就顺便回答：「PowerDVD 的 DirectShow Filter 会做 Bob，也就是 blend，画面会较模糊。」
不过因为我回复第二篇的时候，还是很急，没有时间慢慢写，所以这里并没有讲得很详尽完善。
根据 MS 的文件，当初 MS 提 Bob 的时候，原意是指，遇到交错（Interlaced）讯源，例如 30fps 的交错讯源，将显示速率加倍，变成 60fps，一次只显示一个图场（Field），也就是一半的扫瞄线，剩下的一半扫瞄线，用内插补点补出来，这样叫做 Bob。
但是因为当时的硬件显然无法做到，能够实时运算补出另一半的扫瞄线，所以软件在实作 Bob 的时候，例如 WinDVD, PowerDVD 的 Bob 模式，其实是用 Blend 的方式，这和 Bob 的原意并不相同。
以我说话啰哩八嗦，喜欢长篇大论的习惯，我当时并没有对 Bob = Blend 多作解释，可见真的有多匆忙了 因此我当下面写到关于 m2v：「它是目前唯一能正确解码 HDTV 的 MPEG-2 TS 的程序，解 HDTV 的 MPEG-2 TS，只有它解出来的颜色才是正确的，连 DVD2AVI 解的颜色都无法正确」，我也没有时间对这句话多作解释。我说只有 m2v 能正确解码 HDTV 的 MPEG-2 TS，并不是说其它 Decoder 不能解 HDTV MPEG-2 TS。其它 Decoder 也能解 HDTV MPEG-2 TS，但是重点是后面那句「只有 m2v 解出来的颜色才是正确的」，所以我说的解码正确，指的是颜色是否解正确。
那么为什么我要一直强调 "HDTV" 的 MPEG-2 TS，会什么不简单地说 MPEG-2 TS 就好呢？因为是 "HDTV" 的 MPEG-2 TS 才有这个问题，一般的 MPEG-2 TS 也没有这个问题，所以我才会一直强调 "HDTV" 的 MPEG-2 TS。所以我后面才会说「等晚点我忙完了以后再上来详细说明，因为处理 HDTV 的人还很少，所以我从来没有公开地讲过这个问题。」
由此可知，我说的解码问题，并不在 MPEG-2 TS 上，和 MPEG-2 TS 的格式无关，问题是出在 HDTV 身上。
好了，推理分析完了，那么 HDTV 到底有什么问题？下面小弟会慢慢回答
| 引用 |
|
2 MPEG-2 VIDEO VFAPI Plug-In + elecard 测试出来色彩失真 |
关于这点，MPEG-2 VIDEO VFAPI Plug-In 是一个日本人，叫做 marumo，我都称他为「神样」，因为他太伟大了 :P 写的一个 MPEG Decoder。这个 Decoder 是一个独立运作的 Decoder，它自己就可以解码，就像 DVD2AVI 解码一样，不需要依附其它的 MPEG-2 Decoder。所以当你使用 m2v 解码，就是使用 m2v 自己本身在作解码，而不是连到其它 DirectShow Filter 来作解码，这是第一点要厘清的。
m2v 的解码画质，比 DVD2AVI 还要好。它用的 upsampling filter，比 DVD2AVI 品质还要好。
附带一提，当初 marumo 神样在开发 m2v 的时候，曾经收到 DVD2AVI 的作者 jackei 神样写给他的信，告诉他 m2v 有一个 bug，marumo 神样非常感激，但是也大伤脑筋，因为他的英文很破，不知道该怎么样用英文回感谢信 :P
以上是趣谈。
那么为什么您用 m2v 和 DVD2AVI 解出来，色彩都失真呢？
看了您下面贴的设定图，我猜测的没错，因为您刚好把两个软件的色彩转换设定都设错了 :P
所以看起来才会两个软件都失真。
那么正确的设定该怎么设？下面小弟会长篇大论地回答
我把以前写过的东西做一个整理，因为时间的关系，我没有办法把每一个细节都讲得非常的详细，不过我会把大概的原因，和处理的方法，尽量用很精简的方式，条 列整理出来。
如果对更深入的原理有兴趣，请搜寻过去零散的讨论。
一切都要从 ITU-R BT.601 这个"建议"开始说起。
现今的 DVD/VCD/DV 都是遵循 ITU-R BT.601 这个规格，这个规格规定了，模拟影像转数字时，取样的方式，储存的数据格式、数据范围等等。
当影像转为 MPEG 的时候，RGB 数据要转成 MPEG 使用的 YUV 格式。ITU-R BT.601 里面规定了这个 RGB <-> YUV 的转换式，数据范围 0~255 的 RGB 要转为 YUV 的时候，要先做数据范围的压缩，把范围压缩成 16~235，然后才转成 YUV 储存起来。然后 MPEG 解压缩的时候，解出来的 YUV，要做数据范围的扩张，将 Y: 16~235, UV: 16~240 的数据扩展为 0~255 的 RGB，也就是还原回原来的 RGB 数值，然后才能显示在显示器的屏幕上。
这个 0~255 RGB -> 16~235 YUV 的过程，就叫做 YC 压缩。
反过来 16~235 YUV -> 0~255 RGB 的过程就叫做 YC 伸张。
我们可以很清楚地看到，YC 伸张和压缩要互相搭配，最终显示出来的结果才正确。
如果：
A. 播放时
1. 转 MPEG 的时候没有做 YC 压缩，储存的是 0~255 的 YUV，播放时就不可以做 YC 伸张，否则 0~255 的资料再伸张一次，会变成 -19~278。
当然，8 bits 的数据储存范围只能是 0~255，数据超出的范围会被削掉（clipping），整个画面对比会过强，色彩会崩溃。
2. 转 MPEG 的时候有做 YC 压缩，储存的是 16~235 的 YUV，播放时就一定要做 YC 伸张，如果不做 YC 伸张，显示的是 16~235 YUV -> 16~235 RGB。
RGB [235,235,235] 在显示器上看起来不是纯白，而会有点灰灰的，[255,255,255] 才是纯白。
相同的，[16,16,16] 看起来也不会是纯黑，[0,0,0] 才是纯黑。
16~235 的 RGB，数据范围（动态范围）缩小，对比会变差，色彩黯淡，看上去好像蒙上了一层白纱。
显示卡的 DirectDraw Overlay，使用硬件的 YUV -> RGB 色彩空间转换，都会遵守 ITU-R BT.601 的建议，认为 MPEG 的 YUV 数据范围应该是 16~235，所以都会做 YC 伸张。
所以我们可以得到结论，当转成 MPEG 的时候，一定要确保 YUV 的数据范围是 16~235，这样在计算机上看、在电视上看，才会看到正确的色彩、对比表现。
所以
B. 压缩时
1. 如果输入的 RGB 数据范围是 0~255，转 MPEG-2 时就要先做 YC 压缩，转成 16~235 的 YUV，这样将来播放时显示才会正确。
2. 如果输入的 RGB 数据范围是 16~235，转 MPEG-2 时就不能做 YC 压缩，要直接转成 16~235 的 YUV，这样将来播放时显示才会正确。
如果输入的是 16~235 RGB，转 MPEG 时又再做一次 YC 压缩，数据范围会变成 30~218 YUV，这样即使将来播放时做 YC 伸张，还是只能伸张到 16~235 的 RGB，结果还是不对。
那么，重点就是
1. 怎么知道输入的讯源是 16~235 RGB，还是 0~255 RGB？
2. 怎么知道压缩的 MPEG 软件在转 RGB -> YUV 的时候会做 YC 压缩，还是不做 YC 压缩？
我们先看第一点，假设你的讯源是：
1. DivX/XviD 的 AVI，要转 DVD/SVCD/VCD
DivX 和 XviD 都遵循 ITU-R BT.601 规范，解码输出 RGB 时都会做 YC 伸张，所以以 DivX/XviD 的 AVI 作为讯源，都是 0~255 范围的 RGB。
2. 讯源是 DVD，或 HDTV 的 MPEG-2 TS，或其它 MPEG 文件
看你用来解码 MPEG，输出 RGB 的软件是哪一个，这个软件解码输出的设定为何。
例如：
2a. 解码软件是 DVD2AVI，在 RGB -> YUV 的设定底下有两个选项，一个叫做 PC Scale，另一个叫做 TV Scale。选 PC Scale，解码就会使用 PC Scale 的转换式，输出 0~255 的 RGB；选 TV Scale，解码就会输出 16~235 的 RGB。
由上述的说明，我们可以知道 DVD2AVI 的一个运用：
当我们不勾选 DVD2AVI -> Help -> DirectDraw Overlay 时，DVD2AVI 不会启动 DirectDraw Overlay，而是走传统的 GDI 显示方式，输出 RGB 给显示卡显示。此时画面上看到的色彩，会受 YUV -> RGB 选项底下设定的 PC/TV Scale 影响；选 TV Sclae，颜色黯淡；选 PC Scale，颜色正确。
当我们启动 DirectDraw Overlay，此时画面的显示，是由 DVD2AVI 直接输出 YUV，走 DirectDraw Overlay，丢给显示卡去做 YUV -> RGB 的色彩空间转换。此时画面上显示的颜色，由显示卡决定，PC/TV Scale 的设定完全不影响看到的画面。
而显示卡的色空间转换，如前所述，不乱搞的话，都是遵循 ITU-R BT.601，用 PC Scale。
在接下去说明之前，要先介绍两个名词：
0~255 的 RGB，又叫做 full-range RGB
16~235 的 RGB，又叫做 compressed-range RGB
更深入的介绍，有兴趣的人可以参考 SGI 网站上的这一篇好文章
Digital Media Programming Guide Chapter 2. Digital Media Essentials
知道这两个新名词后，接着往下看
2b. 解码软件是 m2v，在 m2v 的设定画面里，YUV Range 底下有两个选项让你选择，一个是 Full Range，另一个是 ITU-R BT.601 Range。怎么样，是不是觉得这两个名词很熟悉 
相信看过上面的解释，您应该可以猜到，选 Full Range 的意思是代表告诉 m2v，我的 YUV 数据范围已经是 0~255 的 YUV 了，不要再做伸张了唷。所以选 Full Range，m2v 就不会做伸张，而是直接转换。
相反的选 ITU-R BT.601 Range，就是告诉 m2v，我的 YUV 数据范围是 16~235，输出时请做 YC 伸张。
所以：
1) m2v 选 Full Range，等于 DVD2AVI 的 TV Scale，输出时不做 YC 伸张，16~235 YUV 输出的是 16~235 RGB。
2) m2v 选 ITU-R BT.601 Range，等于 DVD2AVI 的 PC Scale，输出时会做 YC 伸张，16~235 YUV 输出的是 0~255 的 RGB。
其它 MPEG Decoder，请自行实验其输出结果。
3. 如果讯源是 DV-AVI
看用来解码的 DV Codec 是哪一个。
如果是 Canopus DV Codec，不会伸张，16~235。
如果是 MS DV Codec, Panasonic DV Codec，会伸张，0~255。
4. 讯源是用 PhotoShop 等绘图软件，自制的计算机动画
无庸置疑，是 0~255 RGB。
OK，这样我们就知道讯源是 0~255 还是 16~235 了，接下来，第二点，MPEG 压缩软件会不会做 YC 压缩？
答案是，不同软件有不同做法。我试验过的几个：
1. 可以自由切换选择要不要做 YC 压缩
TMPGEnc, CCE SP
2. 一律做 YC 压缩，当成输入的都是 0~255 RGB
MainConcept MPEG Enocder, Panansonic MPEG2&1 Encoder
DivX, XviD
3. 一律不做 YC 压缩，当成输入的都是 16~235 RGB
MPEG Conversion Studio, ProCoder。
我们以 TMPGEnc 为例
TMGEnc 选择切换要不要做 YC 压缩的选项，叫做 "Output YUV data as Basic YCbCr ont CCIR601"。
名词解释时间
0~255 YUV = full-range YUV，TMPGEnc 叫做 Basic YUV (YCbCr)。
16~235 YUV = compressed-range YUV = ITU-R BT.601 YUV，TMPGEnc 叫做 CCIR601 YUV。
勾选 "Output YUV data as Basic YCbCr ont CCIR601" 这个选项，TMPGEnc 就会认为要输出的是 Basic YUV = 0~255 YUV，所以不做 YC 压缩，直接转换。
不勾选这个选项，TMPGEnc 会认为要输出的是 CCIR601 YUV = 16~235 YUV，所以会做 YC 压缩，转成 16~235 YUV。
会不会很复杂，开始头晕了？ ^^;
没关系，我最后会总结整理成一个很简单的列表，但是在此之前我必须先说明完原理，因为组合的情况有很多种，不同 Decoder 输出不一样，不同 MPEG 压缩软件的处理不一样，我不可能有时间一一去测试所有的组合情况，所以唯有您自行理解原理，了解吸收了以后，遇到不同的组合，您才能知道要怎么设定，而不 是只死记一种做法，这也是为什么我会不厌其烦地，再三地解释、说明这些令人头晕的道理 ^^;
那么会有哪些组合的情况呢？
在 TMPGEnc 的网站上曾经出现过一篇很精彩的讨论，参与讨论的有 TMPGEnc 的作者崛老，还有 m2v 的作者 marumo（那位署名 "茂木" 的即是 marumo）。
在这篇讨论中崛老提到，"Output YUV data as Basic YCbCr ont CCIR601" 选项做的事情，是当 RGB -> YUV 的时候，使用不同的转换式，不勾会做 YC 压缩，勾了就不做 YC 压缩。崛老还举出了所有可能的情况，我把他翻译过来给大家看：
http://www.pegasys-inc.co.jp/bbscgi/bbs/board.cgi?board=tmpgenc&cmd=topic&wparam=182
1. 当讯源不是 CCIR601 标准，也就是 (0~255) 时
不勾 ==> RGB(0~255) -> YUV(16~235) 正确 ^_^
勾 ==> RGB(0~255) -> YUV(0~255)
播放时会做伸张 YUV(0~255) -> RGB(-19~278) 超过 0 和 255 的数据都会被削掉，
画面色彩崩溃，错误 >_<
2. 当讯源是 CCIR601 标准，也就是 (16~235) 时
不勾 ==> RGB(16~235) -> YUV(30~218) 颜色变淡、对比变差，画面好像罩上了一层白雾 >_<
勾 ==> RGB(16~235) -> YUV(16~235) 正确 ^_^
然后崛老说像 Canopus DV Codec 这种 CCIR601 标准（不做伸张）的讯源，
要勾选才正确；反过来说，非 CCIR601 标准的讯源（做过伸张），不勾选才正确。
所以总结起来，如果讯源是 MPEG，用 DVD2AVI 解码，则正确的做法
DVD2AVI PC Scale -> 0~255 RGB -> TMPGEnc 不勾 "Output YUV data as Basic YCbCr ont CCIR601"
DVD2AVI TV Scale -> 16~235 RGB -> TMPGEnc 要勾 "Output YUV data as Basic YCbCr ont CCIR601"
同理，如果是 m2v 解码
m2v ITU-R BT.601 Range -> 0~255 RGB -> TMPGEnc 不勾
m2v Full Range -> 16~235 RGB -> TMPGEnc 要勾
如果用的是 CCE SP 来压 MPEG，CCE SP 切换的选项在 Video 里面，叫做 Luminance level，有两个选项
16-235 = 做 YC 压缩 = TMPGEnc 不勾 "Output YUV data as Basic YCbCr ont CCIR601"
0-255 = 不做 YC 压缩 = TMPGEnc 勾 "Output YUV data as Basic YCbCr ont CCIR601"
所以
DVD2AVI PC Scale -> 0~255 RGB -> CCE SP 选 "16-235"
DVD2AVI TV Scale -> 16~235 RGB -> CCE SP 选 "0-255"
m2v 的情况依此类推。
如果 MPEG 压缩软件不能切换 YC 压缩的选项，例如 ProCoder，那怎么办？
我以前写过一篇，转贴过来，省打字时间
==
ProCoder 1.5 版有个重要的更新，ITU-R BT.601 color correction 设定，
可以让你选择要不要做 YC 压缩，这是一个很重要的设定。
TMPGEnc 有这个设定，"Output YUV data as Basic YCbCr ont CCIR601"，
这个设定不是"改善"色深，而是做"正确"的选择，保持本来的颜色。
本来就应该要根据输入的讯源，正确的选择切换这个选项，才能得到正确的结果。
这个选项不是用来"改善"或者是"补强"用的，不要弄错了原本的意图。
其它 MPEG 压缩程序例如 CCE SP 也有相同的设定。
而 ProCoder v1.01.35 版没有这个设定，一律将 input 视为是 CCIR601 YUV
（颜色范围是 Y:16~235, UV:16~240），所以使用者无法根据使用的讯源做切换。
Canopus 本身的 DV Codec 便是输出 CCIR601 YUV，其 RGB 范围是 16~235，
刚好和 ProCoder 互相搭配。但是其它 DV Codec，例如 MS 的 DV Codec
Panasonic 的 DV Codec，输出的则是 Basic YUV。
这样压缩 CCIR601 讯源时没有问题，但是遇到 Basic YUV（颜色范围是 YUV:0~255，
例如自行用计算机绘图制作的 CG 动画，做过 YC 伸张的 DVD/VCD/DV 讯源... 等等），
ProCoder 就惨了，压出来的对比会过强，色彩会完全崩溃。
有时候 Basic YUV 的影片本身的对比、色彩并不是很强烈，经过 ProCoder 错误的压缩后，
反而会让人有"色彩变鲜艳了"的感觉，不过其实那反而不是原本的颜色。
如果影片本身的对比、色彩本来就很强烈，再经过错误压缩，就会发生凄惨的"色崩"现象。
由于这个后果不是我们能预期、控制的，所以如果真要调整颜色，还不如用正确的色彩压缩设定，
让所见即所得，然后另外用调整颜色的滤镜自行修改颜色，调整到我们需要的样子。
由于 ProCoder v1.01.35 没有提供切换 YC 压缩的设定，所以遇到 Basic YUV 讯源，
在送给 ProCoder 压缩之前，你需要先自行用其它软件，将 Basic YUV 转为 CCIR601 YUV，
再送给 ProCoder 压缩，色彩才会正确。
Avisynth, AviUtl 都有这个转换的功能。
==
也就是说如果要给 ProCoder 压缩，DVD2AVI 一定要选 TV Scale 输出，m2v 一定要选 Full Range 输出，如果是使用其它不能选择输出模式的 MPEG Decoder，只好用 AviUtl/Avisynth 的 filter 做后制处理。
OK，基本的讲完了 ^^;
接下来进阶讨论（我的手好酸 ><）...
1. 以上讲的是讯源都是 RGB，压 MPEG 时要做 RGB -> YUV，如果讯源是 YUV，则如何设定？
当讯源已经是 YUV 时，就不用去管 YC 伸张压缩的设定。
例如用 MainConcept MPEG Encoder 压 DV-AVI，用 Canopus DV Codec 解码，MainConcept MPEG Encoder RGB -> YUV 一律做 YC 压缩，照理说颜色会变淡。但是由于 MainConcept MPEG Encoder 可以接收 YUY2 输入，所以 Canopus DV Codec 会直接输出 16~235 YUY2 给 MainConcept MPEG Encoder，这样一来，就跳过了 RGB -> YUV 的步骤，当然也就没有 YC 压缩的问题，所以也就不会出现颜色不正确的情况。
然而如果是 TMPGEnc，以及有用到 VFAPI，因为 VFAPI 都要转成 RGB 处理，所以仍需注意 YC 伸张压缩的设定。
例如如果用 TMPGEnc 压 DV-AVI，一样用 Canopus DV Codec 解码，用默认值转换式，输出的是 16~235 RGB，所以便要勾 "Output YUV data as Basic YCbCr ont CCIR601"。
2. 解码时做 YC 伸张的优缺点？
a. 优点
1) 所见即所得，屏幕上见到的样子，就是将来压好 MPEG 解码输出的样子，这样做后制处理时，比较容易调整。
2) 大部分 MPEG Encoder 都是认为会接收 0~255 RGB 的输入，所以 RGB -> YUV 时都会作 YC 压缩，因此讯源在作解码时一定要作 YC 伸张，才会正确。
b. 缺点
1) 0~255，8 bits 的范围全用光了，没有留下运算时需要的 headroom。
2) Source (16~235 YUV) -> 0~255 RGB -> MPEG (16~235 YUV)
YC 伸张后再压缩，会有一点损失
YC 伸张计算式
Y' = (Y - 16) * 255 / (235 - 16)
C' = C * 255 / (255 - (240-16))
CCE SP 的说明书中，解释 16-235 和 0-255 选项的作用时，有列直接转换，和 YC 压缩转换所使用的不同的计算式
"16-235" --> YC 压缩转换
Rd = 219*R + 16*256
Gd = 219*G + 16*256
Bd = 219*B + 16*256
"0-255" --> 直接转换
如上列所见，这个转换式有小数点，需要舍弃进位，所以反复多次 YC 压缩伸张 RGB <-> YUV 变换，画质会有一点损失。
3. 其它 Codec 输出的情形怎么样？我用 PICVideo MJPEG Codec 采集电视节目，PICVideo MJPEG Codec 是用什么转换式？
PICVideo MJPEG Codec 用直接转换式
遇到其它 Codec，请自行实验，因为不同版本的 Codec 会有不同作法，例如 Panasonic DV Codec 不同版本输出的情形都不一样，作者不可能一一位大家测试完所有的软硬件组合。
可以用 PhotoShop 生成一张 RGB [235,235,235] 的 BMP，送给 Codec 压缩，看压缩后输出的画面，是纯白的 [255,255,255]，还是更灰的 [218,218,218]，以此判断。
还有不同采集卡、不同版本的 driver，采集下来的色域范围都不一样。例如 CONEXANT CX23881 芯片采集下来的色域范围是 0~255，不用再做伸张；Philips SAA7134HL 采集下来的范围则是 16~235，要再做 YC 伸张。请看这个网页的比较图
http://anipeg.yks.ne.jp/topic.html
所以 SAA7134HL 卡采集下来的颜色很黯淡，不如 CX23881 鲜艳，但是我们不可以说 SAA7134HL 就比 CX23881 烂，不是这样的。SAA7134HL 做完 YC 伸张后不见得比 CX23881 差，这是设定的问题， 不是硬件的问题。使用的人要明白原理，要知道根据讯源，自己切换调整设定。
拿到一张采集卡，拿到新的软件，首先要作的就是色彩校正，专业的 studio 会用 Vector Scope 来校正颜色。关于色彩校正，以前也写过很多，我转一点过来贴在下面，不过为了集中讨论主题，我只转贴部分，轻轻带过
==
色域范围是看 chip 的 ADC 设计，例如 Philips SAA7111A 8bit ADC，取样的时候 0 是同步讯号，而黑色 level 则是 60，白色 210。然后 chip 会利用 Brightness 和 Contrast 这两个参数调整（scaling）到 16~235 的标准 CCIR601 范围输出。
算式是
Y(out) = int[CONT/71 * (Y-128)] + BRIG
CbCr(out) = int[SATN/64 *(Cb, Cr -128)] + 128
所以 Philips SAA7111A 的解析能力只有 60~210。
[中略]
AviUtl 的 波形表示 Plugin 的用法，可以看 GNB神样 的说明
http://homepage2.nifty.com/GNB/tutorial/s_scope/s_scope.htm
他测试的是 I/O DATA GV-MPEG2/PCI 这张卡，用 VIDEO ESSENTIALS 这张测试用的 DVD 里面的 Colorbar 作测试，以 S6D 播放输入，GV-MPEG2 用 MPEG2 Max8Mbps VBR 的模板，默认值「Brightness: 121, Contrast: 65, Saturation: 65, Hue: 0」撷取压成 MPEG-2，然后用 marumo神样 的「MPEG-2 VIDEO VFAPI Plug-In」解码。MPEG-2 VIDEO VFAPI Plug-In 可以设定解码输出时要不要作 YC 伸张，选「换」（直接变换，英文版的选项是写 Full Range），也就是不作 YC 伸张，然后作测试调整。
首先先利用 Colorbar 下方的黑白 pattern 来测亮度范围，看波形显示
调整 Brightness 和 Contrast 把亮度（白色线）调整到对齐「100%辉度」（Y: 235）和「0%辉度」（Y: 16）那两条线
「Brightness: 131, Contrast: 63, Saturation: 65, Hue: 0」
参考上面列的 chip scaling 的算式。
接下看 Vector Scope，利用 Colorbar 上方那一排 Yl(黄)/Cy(蓝绿)/G(绿)/Mg(紫红)/R(红)/B(蓝) 的 pattern 调整颜色
顶点要落在十字的中心点上，距离代表 Saturation（饱和度），角度代表 Hue（色相）
调高 Saturation + 15
调低 Saturation - 15
调高 Hue + 10
调低 Hue - 10
最后调整结果「Brightness: 131, Contrast: 63, Saturation: 61, Hue: +2」
完毕。
以上图片均来自上面贴的 GNB神样 的网站，我只是转一点过来做简单的说明，网站上有更丰富更完整的使用步骤，请大家一定要去看一看。看完以后再看最前面提供的那几个网址应该就没有问题了。
专业的 Scope Vector 向量分析仪和测试 pattern 产生器非常贵，一般人只好用这种简陋的方法作调整。调整不良的结果就像黄疸少女一样，是个活生生血淋淋的教训 :P
关于黄疸少女、专业校色、Vector Scope Monitor，请看 jackei神样 的解说
http://www.myav.com.tw/vbb221/upload/showthread.php?s=&threadid=38766&perpage=12&pagenumber=17
==
以上是简略地介绍
更多采集卡校正的说明，请看下面的网页，小弟这里就不详述了 ^^;
http://cwaweb.bai.ne.jp/~icchan/Data/color/colorbar.htm
http://cwaweb.bai.ne.jp/~icchan/Data/color/CCIR601.htm
http://cwaweb.bai.ne.jp/~icchan/Data/color/SMPTE.htm
http://cwaweb.bai.ne.jp/~icchan/Data/iro.htm
4. 怎么讲到采集卡去了？前面提到 m2v/DVD2AVI 的 chroma upsampling 才是对的，其它 MPEG-2 Decoder 大部分都是错的，什么是 chroma upsampling error？
以前有很详细地说明。
chroma upsampling error 看起来像下面那样
正确应该是这样
简单的说
1. YUV 4:2:0（YV12）上下两行扫瞄线要共享一个 UV 取样，所以 720x576 的 DVD，Y 的像素点是 720x576 个，UV 各是 360x288 个，垂直少了一半的 UV。4:2:0 upsample 到 YUV 4:2:2（YUY2），上下两行就不共享一个，而是使用各自的 UV，所以 UV 就变成 360x576。当然 YUV 4:4:4 就是 720x576。
2. 循序（Progressive）画面，相邻的上下两行属于同一个画面，所以取样的时候会拿相邻的两行来取样一个 UV，也就是 chroma = (chroma1 + chroma2)/2
解压缩的时候，解出来的 chroma 要分给 line1 和 line2。
交错（Interlaced）画面，由奇、偶两个 Field 组成，相邻的两行不属于同一个 Field，要隔一行的扫瞄线，才是属于同一个 Field。所以取样的时候，要拿隔行的两条扫瞄线来取样
chroma = 0.75*chroma1 + 0.25*chroma3
解压缩的时候，解出来的 chroma 要分给 line1 和隔行的 line3。
3. 由上可知，MPEG-2 Decoder，必须要准备两种 upsampling 的计算式，循序画面用 chroma = (chroma1 + chroma2)/2，交错画面用 chroma = 0.75*chroma1 + 0.25*chroma3，如果只用一种转换式通吃所有情况，就会发生 chroma upsampling 错误。
我举 Doom9 过去的一个讨论做为例子
http://forum.doom9.org/showthread.php?s=&threadid=48163&perpage=20
首先是 kilg0r3 发现他做的 encoded 会发生"色阶"的现象，颜色会有很明显的阶梯状，尤其是红色特别明显。他反复实验了许多次，发现这个现象不论是 MPEGDecoder, MPEG2Dec3 做 YV12 输出的时候都有，但是用 DVD2AVI 却没有这个问题。
Avisynth 目前的开发者 sh0dan 对这个问题很感兴趣，他提供了一些解决的办法，不过都没有奏效。kilg0r3 继续寻找问题的根源..... 这时大家的结论是这是 YV12 格式的缺陷，因为 YV12 格式两行共享一个 chroma，很容易造成颜色呈阶梯状的现象。解决的办法是用比较好的 FIR filter 做 upsampling 到 YUY2/RGB，例如 DVD2AVI 用了 6-tap FIR filter，这样会使 chroma 变得模糊，但是可以解决明显的色阶现象。
OK, 事情至此似乎告一段落，不过写 MPEG3DEC 的 trbarry 大侠突然插进来，提供了一个连结
The Croma Upsampling Problem
相信这个连结大家应该看过很多次
这个连结里面说明了，部分硬件的 DVD Player 只有 Interlaced chroma upsampling 的方法，所以遇到 Progressive 的讯源，就会发生明显的色阶现象。这里面提到了两个重要的观念：
1. DVD 存的 Frame，有 Interlaced 和 Progressive 两种，由一个旗标叫做 progressive_frame 来指示
2. decoder 要根据这个旗标，切换 YV12 -> YUY2 的 upsampling 方法，upsampling 的结果才会正确
所以 DVD2AVI 能解决色阶现象，不只是因为它用了比较好的 FIR filter，更是因为它能根据 progressive_frame 旗标，做正确的 upsampling 解码。
The Croma Upsampling Problem 的网页上，往下拉，搜寻 "Toy Story" Menu 这一段，有提供范例图片。上下左右四张图，左边的那两张是有用正确 upsampling 解码的结果，上面是没有 filtering，下面是使用 6-tap FIR filter，画质最好。右边的那两张是错误的 upsampling 解码的结果，上面没有 filtering 的，色阶很明显，而下面用 6-tap FIR filter 处理的，色阶就比较没有那么明显，但是画质还是不如正确解码的结果。
看了这个连结之后，sh0dan 的结论是「I think the conclusion is "there is no better quality in YV12". Chroma is subsampled and in extreme cases like this it shows. The only thing that will help is smoothing chroma - even though what also has sideeffects.」。
smoothing chroma 的意思就是使用高 tap 数的 FIR filter 做 upsampling，能让 chroma 比较平滑，不会有那么明显的色阶。
于是最后 kilg0r3 就提了一个问题「how do you determine if a vob is interlaced/progressive on the chroma/luma plane?」。
这个问题问得不太对，luma 没有 Interlaced 的问题，只有 chroma 才有 Interlaced 的问题，不过就不管他了
trbarry 大侠的回答是「I guess if you have problem material and you don't know if it is coded progressive/interlaced (or it's mixed) then you could always use MPEG2DEC2. There is a version around somewhere here that even works with Avisynth 2.5.
But MPEG2DEC2 will return YUY2 that has been converted on a frame by frame basis looking at the MPEG-2 flags and deciding which type of conversion to do.」
由上可知，MPEG2DEC2 会一个 frame 一个 frame 地，根据 progressive_frame 这个 MPEG-2 旗标（flag），正确的切换 upsampling 计算式，输出 YUY2。
而大部分的软件 MPEG-2 Decoder，例如 WinDVD，只使用 Progressive 的 upsampling 计算式，所以遇到交错画面，凄凄惨惨，完全错误。
要用 m2v/DVD2AVI/MPEG2DEC2 等能正确解码交错画面的 Decoder，才能得到正确的结果。
下面是题外话，每次讲到这个我就要为 DVD2AVI 申冤
==
DVD 有两种储存的画面结构，一种是 Interlaced，一种是 Progressive，由 progressive_frame 这个旗标指示。
Interlaced 和 Progressive 只是表示这个画面当初在取样的时候，是以 Interlaced 的方式取样，还是以 Progressive 的方式取样。是将画面视为一个完整的 Frame，以 Progressive 取样，chroma = (c1+c2)/2，取样成 progressive chroma，还是将画面视为是由奇偶两个 Field 所组成，以 Interlaced 取样，chroma = 0.75*c1 + 0.25*c3，取样为 interlaced chroma。
所以这只是一个取样的方式，和画面上是否真的有交错的瑕疵无关，和这个画面是否真的是一个交错的画面无关。笨蛋的 encoder，即使是画面明明都无交错，每一张都是 Progressive Frame，encoder 还是可以以 Interlaced 的方式取样。
这时候 DVD2AVI 的 Frame Type 会显示这是 Interlaced Frame，但是画面上明明没有交错。
DVD2AVI 的 Frame Type，是根据 progressive_frame 这个旗标来显示，所以它显示的是这个 Frame 的原始取样方式。
不知道这个道理的人，就会说 DVD2AVI 的 Frame Type 显示是错的，明明画面没有交错，但是 DVD2AVI 会显示 Interlaced，所以许多人说 DVD2AVI 的显示是错的，不要相信。
例如 Doom9 讨论区，这种错误的说法一堆。
其实这是因为他们不懂真正的道理，DVD2AVI 并没有显示错误，Frame Type 显示的是取样方式，和画面是否真的有交错无关。DVD2AVI 从来没有去分析画面，去比较画面的奇偶差异，判断这个画面是否有交错。它只是很简单地读取 MPEG-2 stream 里面的 progressive_frame 旗标，按照旗标显示，指示这个 Frame 当初压缩时是用哪种取样方式，解压缩时要用哪种 upsampling 方法才会正确。
分析画面、比较画面奇偶、判断是否交错，那是 IVTC plugin 做的事情。
==
如果是这样的话，那么直接的用默认的limiter还错了，因为它已经将range clip到16~235, 交给XviD, XviD又会作一次yc压缩, busted....
而应该Limiter(clip, 0, 255, 0, 255)?
edit:
或者 limiter() 只是做 clipping, 并不是做yc压缩, 所以
limiter()和
Limiter(0, 255, 0, 255)
都是可以的. 因为到此还没有作yc压缩, 后面XviD会yc压缩一次, 播放解码时伸张一次.
Limiter()只是Limiter(0, 255, 0, 255)的子区间而已, 主要用于那些不做yc压缩的codec...
这样的话若做过一些色彩上的处理后打算交给XviD/DivX, 在avs最后要用Limiter(0, 255, 0, 255), 而且必须用.
或者哪个人直接对我说:" 你已经疯了!"
喔喔，您已经混乱了
如果是直接 YUV 的做法，也就是只用 avisynth，在 avisynth 内部做处理，输出 YUV 给 XviD/DivX 压缩，不用担心 YUV 范围的问题。
前面有提到，YC 伸张压缩的问题，只在有经过 YUV -> RGB, RGB-> YUV 转换的时候才会发生，如果是原始 YUV 数据，不用去动它，直接送给 XviD 即可，XviD 不会对 YUV 的输入做任何伸张或压缩的动作。
XviD 只有在输入是 RGB 的时候，RGB -> YUV 转换时才会顺便做 YC 压缩。
所以前面说，如果你没有用到 VFAPI(RGB24)，不经过 VFAPI 做中介，而是直接 YUV -> YUV，也就是一般人用 avisynth 的做法，不用考虑 YC 伸张压缩的问题。
而您提到的要不要用 limiter 做 clip，把 YUV 的 data 切到符合 BT.601 的标准，可以这么做。
有些 DVD 上的数据，YUV 的数据范围会超过 BT.601 的标准一点点，这是因为 MPEG 压缩造成误差的关系，原本 BT.601 保留 0~15/236~255 的设计就是多留一点空间作为缓冲，所以 DVD 上的 YUV 超出范围一点是正常的。
那我们需不需要把这些超出的数据切到 16/235 呢？是可以的，但是有没有必要，我就不清楚了
用 VFAPI 的方式加载，m2v 会输出 RGB。
但是用 Avisynth 的优点，就是不用经过 YUV -> RGB 的转换。
其实 m2v 除了是一个 VFAPI 的 plugin 以外，它同时也是一个 AviUtl 的 plugin，而 AviUtl 可以接收 YUY2 的输入，其内部工作以 YUV 处理，所以 m2v 当然也可以直接输出 YUY2。
把 m2v.vfp 更名为 m2v.aui，丢到 AviUtl 的目录下，开启 AviUtl，你会发现 AviUtl 多了一个 Input Plugin 叫做 m2v，用这个 m2v 解码，输入的就会是 YUY2，而不像以前用 m2v.vfp 输入的是 RGB。
而我们可以在 Avisynth 里面直接调用 AviUtl 的 Input Plugin，Avisynth 有一个外挂叫做 loadaui，就是专门在做加载 aui 的工作
# 加载 LoadPluginEx，这样下面才能加载 2.0.x 版的 loadaui plugin
LoadPlugin("c:/Program Files/AviSynth2/plugins/LoadPluginEx.dll")
# 加载 loadaui，让 Avisynth 可以加载任何 AviUtl 的 input plugin
LoadPlugin("c:/Program Files/AviSynth2/plugins/loadaui.dll")
# 载入 m2v.aui，并将这个 plugin 的 function 命名为 "MPEG2VIDEO"
LoadAviUtlInputPlugin("c:/AviUtl/98d/m2v.aui", "MPEG2VIDEO")
# 用 MPEG2VIDEO 解码
MPEG2VIDEO("source.m2v")
这样输出的就会是 YUY2。
另外 AviUtl 也可以直接开启 avs 文件，接收 YUY2 的输入。
所以许多软件都可以来个友情大合体
大家互相帮忙，截长补短
感谢 csr2000 兄帮忙补充，我太久没用了，还活在旧时代
刚好 winsen 兄贴出 m2v 的设定，小弟前曾提过，HDTV 的讯源要用 m2v 解码颜色才正确，那时没力继续解释下去，现在趁这个机会做个简短的补充
==
Aspect Ratio
要不要做 resize 成最接近的显示比例。
建议 Ignore，不要用 m2v 做 resize。
因为 m2v 做 resize 比例不正确，
且 resize 的大小不一定符合我们需要的大小，
例如 720x480 显示比例 4:3，m2v 会 resize -> 640x480，但是我们不一定要 640x480，说不定我们想做 512x384，这样还是要再自己 resize 一次，不如从头就 720x480 -> 704x480 -> 512x384。
Field Order
Field 奇先偶先顺序
iDCT Algorithm
iDCT 转换的算法
SIMD
支援的 SIMD
GOP List
.gl 的设定
Consecutive Numbered Files
连号文件读取设定
YUV Range
Full Range: YUV -> RGB 时，不要做 YC 伸张
ITU-R BT.601 Range: 做 YC 伸张
Default Matrix Coefficient
YUV -> RGB 转换时，要使用哪一种规格的转换式。
选 Auto(From Video Resolution)，如果 MPEG 檔有 sequence_display_extension header，里面有纪录 Matrix Coefficient，就用记录的 Matrix Coefficient 的转换式来做转换。如果 MPEG 文件没有纪录 Matrix Coefficient，m2v 自动利用 Video 的分辨率大小做判断，如果分辨率超过 720x576，自动用 HDTV 的 ITU-R BT.709 转换式转换；如果分辨率等于或小于 720x576，使用原本的 ITU-R BT.601 转换式转换。
两个转换式转出来色调会有一点差异，HDTV 是采用 709 规格，要用 709 转换式转出来色彩才会正确。
遇到 MPEG 档内的 Matrix Coefficient 不能信用时，例如明明是 SDTV 的讯源，却用 709 转换式，可能是电视台制作时旗标设错了，这时可以手动指定正确的转换式。
YUY2 Matrix(for m2v.aui)
m2v.vfp 同时是一个 AviUtl 的 plugin。
将 m2v.vfp 更名为 m2v.aui 即可当成一个 AviUtl 的 Input Plugin 来使用。
此时 m2v.aui 输出的是 YUY2，而不像原本的 VFAPI Plugin，输出的是 RGB，需要做 YUV -> RGB 转换。
如果现在讯源是 HDTV 的 709YC，直接输出 709YC 给 AviUtl 之后，就算中间的处理过程都不需要转成 RGB，最后压成 MPEG-4 时，储存的还是 709YC。
这样播放时，如果由 MPEG-4 decoder 输出 RGB，MPEG-4 decoder 都是用 601 转换式做 YUV -> RGB 的工作，所以 709YC ->(601 转换式) 错误的RGB
如果用 DirectDraw Overlay，走 YV12 或 YUY2 丢资料给显示卡去做 YUV -> RGB 的转换工作，显示卡的 YUV -> RGB 转换式还是一样使用 601 标准转，709YC ->(601 转换式) 错误的RGB
所以 m2v 设计了这个选项，当 m2v 直接输出 YUY2 的时候，如果讯源本身是 709YC，可以先将 709YC 转换为 601YC，这样以后处理或显示，都不会有问题。
YUY2 Matrix 选项就是在做这个设定，输出时要保留原本 YUV 的数据，还是转成其它规格的 YUV。
Avisynth 有个 BT709ToBT601 的 filter 就是在做同样的事情。
| 引用 |
|
引用 rain009 发表的贴子: 根据Silky的解释， S-Frame 是表示 sprite coding frame. 根据我的理解，主要用在背景相对不变，画面中主体移动的视频中。比如网球比赛。把临近的几帧结合起来得到一个整个场景的sprite frame, 而每一个帧都用这个sprite frame 来作参照压缩。 |
是的，您说的没错。
| 引用 |
|
这是我的理解，似乎和兄台解释的有出入。
|
没有啊，我上面也是这么解释的：
| 引用 |
|
S-VOP 代表 Sprite VOP，MPEG-4 可以将静态的背景画面单独切割出来，同一个场景， 好几个画面会用同一个背景，将背景切割出来，把好几个画面的背景连接起来，做一次压缩。 |
不过 XviD 和 DivX 都没有实作 sprite coding，这里说的 S-Frame，指的是 S(GMC)-VOP，所以我上面说：
| 引用 |
|
当动态旗标和 GMC 旗标都 == 1 时，这个 VOP 叫做 S(GMC)-VOP， 也就是利用 GMC 做压缩的 VOP。由于它和静态的 Sprite VOP 不同，所以我们特别在 S 后面 加上 (GMC) 来标示，这是一个有用到动态 GMC 的 VOP。 |
虽然都叫 S-VOP，但是当 GMC flag == 1 的时候，代表这个 VOP 是 S(GMC)-VOP，用的压缩方法是 GMC，这和原本静态的 Sprite VOP 不同喔。所以我们把这种 VOP 特别表记为 S(GMC)-VOP 以示区别。
GMC 的压缩原理在别的帖子里有简单的说明。
| 引用 |
|
虽然在MPEG4 中有video object plane 这样的定义，但是现在的MPEG4已经做到成熟的object encode 么？其中的object 是怎么分出来的？:rolleyes: 是用给出的mask么？
|
规格上只有告诉我们要切割，把每个 object 切出来，但是它没跟我们说要怎么切，反正不管怎么做，能切出来就对了，切割的 algorithm 没有规定，请我们自行研究
目前 DivX 和 XviD 都没有这个功能，其它 MPEG-4 软件，有些有做，例如 MS 的那个范例程序就有这个功能。不过范例程序当然是很阳春，并没有最佳化，只是示范，大致上是这样做.... 给我们做参考
| 引用 |
|
另外H.264也会用于视频压缩么？这个系列的目标是video conferencing 吧？
|
因为画质很好，所以有考虑用在一般多媒体媒体的视讯压缩上使用。
rrv 的部分是伟大的 skal 写的（ ）（skal 应该算是 XviD 之神了 ），我不太清楚他有没有做这样的判断，应该是有，不过可能没有仔细调整修改过，所以判断不一定是最佳的情况。
因为 rrv 只能用在 ARTS Profile，而 ARTS 不能合并使用 B-frame/Qpel/GMC 等功能，主要目的是网络实时视讯传输、低解码延迟使用，运用范围比较小，而当时 XviD 的主要目标是把 AS Profile 的功能实作完善完成，所以 skal 提出来没多久把程序码合并进去，就没有人再继续发展改良。
事实上这个功能很早就有了，去年就有了，但是 vfw 接口中一直没有把这个选项开启，第一个开启并且公开放出来的人，应该就是 cynix 大神
XviD 1.0 以后，接下来的目标是 Main Profile 和最高阶的 Studio Profile，所以大概也不会回头去改良 rrv。Studio Profile 支持超高分辨率，超高码率，取样由 4:2:0 扩展到 4:2:2~4:4:4，量化由 8bit 扩展到 10~12bit，是专业广播级、品质最高的 MPEG-4 压缩。
SONY 在今年 NAB 上发表的业务用新规格"HDCAM SR"，用的就是 Studio Profile 的 MPEG-4 压缩。
●HDCAM SRフォーマットの概要 (HDCAM SR 格式簡介)
圧縮方式； MPEG-4 studio profile
イメージフォーマット (圖像格式)； 1,920×1,080（CIF規格に準拠）または1,280×720
サンプリングレート (採樣率)/量子化bit数(映像)； RGB 4:4:4 またはYPbPr 4:2:2／10bit
サンプリングレート (採樣率)/量子化bit数(音声)； 48kHz／24bit（音声トラック (聲道數)；12ch）
対応フィールド/フレームレート (field/framerate)； 1,920×1,080…23.98P,24P,25P,29.97P,30P,50i,59.94i
1,280×720…59.94P
データレート（映像） (datarate)； 約440Mbps
http://www.sony.jp/CorporateCruise/Press/200303/03-0305B/
对了 alexheart 兄提到 rrv 让他想到 MipSmooth，MipSmooth 的 Mip 是从 3D 绘图的术语 MipMap 来的，那么什么是 MipMap 呢？
有一位非常非常了不起的 Hotball 大大曾写过有关 MipMap 的文章，我不会解释得比他更好（ ），有兴趣的人，可以看这篇非常值得一看的 MipMap 说明
http://www.csie.ntu.edu.tw/~r89004/hive/mipmap/page_1.html
网站上还有其它 Hotball 大大写精彩文章，例如 FSAA, Anti-aliasing 的理论，还有 CPU 的 cache 和 latency 等等，非常好看，推荐给大家
http://hotball.webhop.net/
LCD 有点和 CRT 屏幕不一样，LCD 是数字的，它上面的液晶分子的个数是有限个，也就是它能表现的分辨率受限于先天的物理限制，是有限的，我们叫做 LCD 的"原生"分辨率。譬如说现在 17" 的 LCD 的原生分辨率通常是 1280x1024 个 pixels。
当然 CRT 受限于荧光涂布的技术和模拟频宽，也有它的分辨率上限，但是和 LCD 不同的是，LCD 的每个分子都要对应到一个 pixel，譬如说现在桌面分辨率设为 1280x1024，直接每个 pixel 的数字数据送到 LCD 上，就直接对应它要显示的分子。所以如果今天我桌面分辨率设为 640x480，只有 640x480 个 pixels 的数字数据，送到 LCD 上要怎么显示呢？LCD 都有内建 scaler，做数字缩放的动作，640x480 的数据送进来，都要经过 scaler upsampling 到原生分辨率 1280x1024，然后才能显示。
所以注意到了没，这和 CRT 的模拟扫瞄显示方式是不一样的，CRT 接受 640x480 转成的模拟讯号，频宽多少就扫瞄多少，CRT 屏幕不需要内建 scaler。
而在 LCD 上，我们可以调整为 640x480 输出，这时显示的流程是这样：
系统内存 原始 640x480 -> 显示卡 frame buffer 640x480 数字输出 -> LCD scaling -> 1280x1024 显示
或者用 1280x1204 输出：
系统内存 原始 640x480 overlay -> 显示卡 scaling 1280x1024 数字输出 -> LCD 1280x1024 显示
所以在 LCD 屏幕上看影片，切换到 640x480 显示，可能有两种情况：
1. 画质变好。因为 LCD 内建的 scaler 比显示卡的 scaler 好。
2. 画质变差。因为 LCD 内建的 scaler 比显示卡的 scaler 差。
绝大部分的情况，都是 2.。
所以用 LCD 看影片反而建议用原生分辨率。
问题又来了，1280x1024 不是标准 4:3 呀，scaling 之后会变形。
这也是长久以来 LCD 一直为人所诟病的地方，我们一直搞不懂当初为什么要设计 1280x1024 这种诡异的比例。
有些 LCD 的设计比较优良，当桌面分辨率为 4:3 输入时，例如 1280x968，它不会 scaling 到全满造成画面变形，而会上下留黑边，维持 4:3 的显示比例。
买 LCD 时要留意有没有这个功能设计。
关于 LCD 和 CRT 屏幕孰优孰劣，我想各大显示器论坛已经讨论过许多次，两者各有优缺点，我不是这方面的专家，不过大家可以上网络找数据，什么 Plasma, LCD, CRT, DLP, ... 等等一堆显示技术，各自优缺点，以及怎么克服缺点所研发的新技术等等，很有趣，可以看一看
小弟做个补充，其实并不是 MPEG2Dec3 的 chroma upsampling 错误，而是只输出 yv12(YUV 4:2:0) 的话，要显示在屏幕上让我们看到，后续必须做 YUV 4:2:0 -> YUV 4:2:2 -> YUV 4:4:4 -> RGB 的转换才行。
而 MPEG2Dec3 只输出 yv12 的话，后续的工作是由系统上的 yv12 decoder 来做的，例如有装 DivX 5，便会由 DivX 5 来解码 yv12。
而 DivX 5 解码 yv12，他无法从原始的 MPEG-2 stream 中得知哪些画面是 interlaced 哪些画面是 progressive 的，avisynth 交给它的时候就已经是解码完毕的 yv12 数据了。所以 DivX 5 只好「盲目的」做 upsampling，DivX 会假设所有的画面都是已经经过去交错处理之后的 progressive 画面，一律用 progressive 的方法做 upsampling，这样交错画面就会发生 upsampling 的错误。
所以问题不在 MPEG2Dec3 上面，而是只要输出的是 yv12，就会有这个问题。
yv12 格式，上下两行会共享一组 UV
Y Y
Y Y + UV
如果我们让 MPEG2Dec3 输出 YUY2(YUV 4:2:2)，让 MPEG2Dec3 先自己 upsampling 到 4:2:2 格式，
YUY2 格式，上下两行不共享 UV，而是分别有自己的 UV
Y Y + UV
Y Y + UV
这样就不会有隔行、交错 UV 的问题，后面不管用什么 decoder 解输出的 YUY2，都不会有问题。
MPEG2Dec3 本身有一个指令叫做
YV12ToYUY2()
用这个指令就可以将 MPEG2Dec3 输出的 yv12 转为 yuy2，而且这个 yv12->yuy2 是根据 MPEG-2 stream 的旗标指示，做正确的 upsampling，这样就可以输出正确的结果。
所以其实 MPEG2Dec3 解码 chroma 是正确的，只是一定要用 yuy2 输出。
那么又有一个问题了，也就是说如果要 chroma 正确，一定要转为 yuy2 格式，那么就不能用全程 yv12 制程了？
是的，确实是如此。但是大部分的人在制作影片的时候不会直接就这样压缩交错的画面，他们会先做 IVTC 或去交错，把画面转为 progressive 之后再压缩，例如
1. MPEG2Dec3 输出 yv12 --> 经过 decomb IVTC --> decomb 会组合交错最小的画面，输出正确的 progressive 画面 --> 这样的 progressive 画面就不会有 chroma upsampling 的问题，至少在 progressive 画面中造成的影响不明显。
搭配 decomb 的时候建议喂给它 yv12 格式，decomb 在 yv12 格式下运作的效果比较好，如果要转为 yuy2，经过 decomb IVTC 之后再转为 yuy2
Mpeg2Source("source.d2v")
Telecide()
YV12ToYUY2()
2. 如果 decomb 组合失败，输出交错的 frame，这个 frame 一般我们也不会把它摆着，而会对它再做去交错，去交错之后，chroma upsampling 的影响也会减小。
所以如果不是很讲究，用 yv12 输出搭配 decomb，结果还是可以令人接受的，全程 yv12 制程还是有它的好处，速度快
所以不一定强求一定要用 M2V 做解码。
有些 DVD 做得很好，整片 Film 率 99%，而且所有画面都是 progressive picture（DVD2AVI 从头到尾都显示 "Progressive"），这种 DVD 用 MPEG2Dec3 解码也不会有任何问题。
总结以上，我们知道输出 yv12 遇到交错画面就一定会有问题，不管用什么解码器解码都一样，所以过去 WinDVD 解码是错误的，经过众人反应之后，WinDVD 5 的 chroma 解码已经变成正确的 ^_^，你注意观察它的输出格式会发现，过去 WinDVD 用的是 YV12 Overlay 输出，现在用的是 YUY2 Overlay 输出，就是以上这个原因。
以前 csr2000 兄有写过一个教程，和那个网页上差不多，大致上是
1. 用 FPSCHK 载入 .d2v 文件，扫瞄影片哪些部分是 24p，哪些部分是 30p，将结果存成一个 .idx 文件。
FPSCHK, Dec60, AVI60 在这里下载
http://www.geocities.co.jp/SiliconValley-Sunnyvale/3109/
FPSCHK 和 Dec60 在「过去的遗物」里面。
2. avisynth 的 script
LoadPlugin("MPEG2Dec3dg.dll")
LoadPlugin("decomb510.dll")
LoadPlugin("loadpluginex.dll")
LoadPluginEx("dec60.dll")
Mpeg2Source("120fps.d2v")
Telecide()
Dec60(idxfile="120fps.idx",deint=false)
由于 Dec60 是 Avisynth 2.0x 的 plugin，必须用 LoadPluginEx 才能在 2.5x 版加载。
loadpluginex.dll 在 warpsharp 的压缩包里面有附
http://www.geocities.co.jp/SiliconValley-PaloAlto/2382/
Telecide 是 Decomb 的指令，经过 Telecide 后，画面会还原回 30fps progressive 的画面，
其中 24p 的部分每五张会有一张重复的，30p 的部分则是每一张都是不同的画面。
本来 Telecide 之后我们会用 Decomb 的另外一个指令 Decimate(cycle=5)，把每五张重复的那一张删除，但是 24p/30p 混合的情况，我们要保留所有 30p 的画面，只有 24p 的部分才要删除重复画面，所以不能用 Decimate 删除，要改用 Dec60。
Dec60 会根据 FPSCHK 分析 .d2v 文件得到的 .idx 索引，删除 24p 部分重复的那一张，保留 30p 全部的画面。
3. 然后依照一般的程序送进去压缩。
4. 压好的 AVI 再送给 AVI60 去插 null frame，AVI60 会依照索引文件，24p 的部分每一张后面插入四张 null frame，30p 的部分每一张后面插入三张 null frame。
[A B C D] [E F G H I]
24p 30p
[A A A A A B B B B B C C C C C D D D D D
E E E E F F F F G G G G H H H H I I I I]
120p
重复的 Frame 标记为 Drop Frame，不必压缩
[A d d d d B d d d d C d d d d D d d d d
E d d d F d d d G d d d H d d d I d d d]
5. 大功告成。
进一步研究
1. FPSCHK 分析 .d2v 文件，判断的结果不十分正确，通常是不正确的。
因为 .d2v 的内容是原始 MPEG-2，交错的情况很复杂，MPEG-2 本身也许也有用到 IVTC，让判断更困难，所以很容易出错。
我们可以改成不要用 .d2v 来分析，改成分析 Telecide 之后的文件。
LoadPlugin("MPEG2Dec3dg.dll")
LoadPlugin("decomb510.dll")
LoadPlugin("loadpluginex.dll")
LoadPluginEx("dec60.dll")
Mpeg2Source("120fps.d2v")
Telecide()
把这个 .avs 用 ffvfw 的 makeAVIS 转成索引的 .avi 文件。
用 FPSCHK 加载这个 avi 文件，分析这个 avi 文件。
这样的正确率会提高非常多。
2. Dec60 删除 24p 的部分，有时会删除到不该删除的 frame，想要改正，但是在窗口中又无法修改。
可以直接从 .idx 文件中修改。
Field=0
NumFrames=42738
Total=42738
AvailFrames=34272
TargetFile=F:/STRATOS 4/stratos 4-109.avi
# 0 (00:00:00) - 2213 (00:01:13) 24fps ? 2214 (00:01:13)
# 2214 (00:01:13) - 2506 (00:01:23) 30fps ? 293 (00:00:09)
# 2507 (00:01:23) - 2598 (00:01:26) 24fps ? 92 (00:00:03)
# 2599 (00:01:26) - 2660 (00:01:28) 30fps ? 62 (00:00:02)
# 2661 (00:01:28) - 42738 (00:23:46) 24fps ? 40078 (00:22:17)
0,1
1,9
2,1
3,1
4,1
5,9
6,1
7,1
8,1
9,1
.....
第一个数字是 frame number，"," 后面 9 代表删除，1 代表保留。
将你想要删除的 frame 手动改成 9，将你想要保留的 frame 改成 1。
注意 24p 的部分每五张要删除一张，如上面所示。
3. 只能用 Decomb 做 IVTC，而 Decomb 做 IVTC，结果并不完美。
Decomb 5.10 版，很强，IVTC 很强，改用 Decomb 5.10 版，效果好很多。
Decomb 的 IVTC 不完美，可以手动指定 override 文件，覆盖 Decomb 的设定。
用 override，可以做出超完美的 IVTC。
像下面这样
LoadPlugin("MPEG2Dec3dg.dll")
LoadPlugin("decomb510.dll")
LoadPlugin("loadpluginex.dll")
LoadPluginEx("dec60.dll")
Mpeg2Source("120fps.d2v")
Telecide(order=1,post=3,vthresh=83,dthresh=7,blend=true,ovr="ovr.tel.avs")
ovr.tel.avs 的文件内容像下面这样
584 p
1410 p
1843,1845 -
1845 p
1846,1853 +
2515 +
2520 +
2525,2527 +
2530,2534 +
.....
28003,28010 ccnnc
28011,28025 pccnp
28105 p
28405,28449 cccnn
28450,28479 ccnnp
28628 p
.....
要知道 ovr.tel.avs 里面在做什么，必须先了解 Decomb 去交错的原理。
我把以前写的一篇文章转过来
==
1. progressive 和 interlaced 的分别
progressive: 奇数、偶数的扫瞄线是在同一个时间点拍摄的，奇数扫瞄线组成的奇数场（odd field）和偶数扫瞄线组成的偶数场（even field），两个图场合并起来是一个完整个画面，用眼睛看，画面上没有交错的线条。
interlaced: 奇数、偶数的扫瞄线是在不同时间点拍摄的，拍完一个图场接下去拍另一个，奇数扫瞄线组成的奇数场和偶数扫瞄线组成的偶数场，两个图场各自是一个独立的画 面，组合在一起，画面上会有交错的线条瑕疵。
有交错线条的画面是 interlaced，没有交错线条的画面是 progressive。
30p x480 progressive: 一个时间点的垂直分辨率是 480，清晰度佳，每秒 30 张画面
30i x480 interlaced = 60p x240 progressive: 一个时间点的分辨率 240，清晰度差，每秒 60 张画面，动感佳
2. 讯源的类型
a) 24fps, 23.976fps progressive, Film, 24p
有些影片，讯源是 24fps，拍摄的时候是以 24fps progressive 的方式拍摄的，每一张都没有交错，例如大部分的电影。为了要能在 NTSC 的电视上播放，电影胶卷过带（telecine）的时候必须转成 30fps，这个 24 -> 30fps 的过程叫做 3:2 pulldown。
1, 2, 3, 4 四张原始画面，1o 代表 1 的 odd field，1e 代表 1 的 even field
1 2 3 4 [1o 1e] [2o 2e] [3o 3e] [4o 4e] 3:2 pulldown (2:3 pulldown) ----> [1o 1e] [2o 2e 2o] [3e 3o] [4e 4o 4e] 2 - 3 - 2 - 3 <-- 呈现这样的排列，所以叫做 2:3 pulldown 1 2 3 4 5 [1o 1e] [2o 2e] [2o 3e] [3o 4e] [4o 4e]
上面 4 张 -> 5 张
4 * 6 = 24 张 -> 5 * 6 = 30 张
这样就可以把原本 24 张转成 30 张，在 NTSC 的电视上播放。
但是其中第三和第四张画面 [2o 3e] 和 [3o 4e]，是由两个不同画面的 field 组成，画面变成交错的。
每五张之中，有两张是交错的。
有这种型式的影片，我们知道，其原始画面其实是 24fps progressive 的，可以作 inverse telecine（IVTC），删除多余的画面，还原回原本的 24fps。
大部分的电影，无庸置疑，其讯源一定是 24fps progressive，可以作 IVTC。
电影（Film, 24fps progressive）转成 PAL（25fps）的时候，用的是 2:2 pulldown，画面还是 progressive，只是加快播放速度，变成每秒播放 25 张。不过有些 PAL 的 DVD 会 shift 一个 field，造成画面每一张都交错，这时只要 swap field order，就可以还原回无交错的画面。
还有一些 PAL DVD 非常奇怪，25 张之中会有重复的一张画面，这时就必须删除重复的那一张画面才能还原回 24p。
b) 30fps, 29.97fps interlaced, Video, 30i
拍摄的时候，是以 30fps interlaced 的方式拍摄的，每一张都是交错的。大部分的 NTSC 电视节目（连续剧、综艺节目、新闻报导...），交错式的 DV 都是这种讯源。
这种讯源要在计算机上看
1) 以 x480 30fps 播放，不做去交错 = x480 30i，这样静态画面的清晰度最好，但动态画面会有交错线
2) 以 x480 30fps 播放，做去交错 = x480 30p，画面会模糊
3) 以 x240 30fps 播放，这又有两种情况
a. x480 先做去交错之后再缩小画面
b. 直接舍弃一半的图场，只留下其中一个图场的 x240 扫瞄线
状况 a 等于 2) 的低分辨率版
状况 b 也是少掉一半的 field
4) 以 x240 60fps 播放，也就是抓 x480 30i，然后转成 x240 60p，这样就跟在电视上播放一样，是最顺畅的，没有丢掉任何一个 field
但是这样播放，画面会上下跳动。
所以有那种在做 30i->60p 的 filter，减少这种上下跳动的现象。
c) 30fps progressive, 30p
30fps 每一张都没有交错，例如计算机动画
这种讯源，当然什么处理都不用作。
d) Hybrid, Mixed 混合 24p/30p
在动画 DVD 上面常见，例如片头是 30fps progressive，每一张都没有交错，本篇却是 24fps progressive，五张之中有两张交错；或者是 CG 的部分 30p，其它部分 24p。
做成 AVI，AVI 只能用一种固定的 fps，所以可以分开做的话分开做，把 24p 和 30p 的部分分成两个 AVI，例如片头 30p 一个 AVI，本篇 24p 一个 AVI。如果不好分开，例如几乎都是 24p，只有中间 CG 的部分 30p，只好强制 24fps 做下去，这样 30p 的部分会顿，不过也没办法了。
如果做成 30fps，24p 的部分每四张要重复一张，也是会顿。
最好的做法是转成 120fps
120 是 24 和 30 的最小公倍数，做成 120fps，可以兼顾 24p 和 30p，不会顿，又不用牺牲画面。
或者放弃 AVI，改用 .mkv 等可以支持 变动 frame rate/VFR 的文件格式。
e) Hybrid clip, Mixed, 混合 24p/30i, 混合 24p/48i, 混合 xxx/xxx .....
例如部分 24fps progressive，五张之中有两张交错，部分 30fps interlaced，每一张都交错。
很难处理，大家各凭本事
f) Hybrid Frame
一个 Frame 之中，部分交错，部分没交错。
例如有些影片的字幕、工作人员名单是 telecine 之后才 overlay 上去的，造成背景画面没交错，前景字幕却是交错的。
做自适应去交错。
g) 其它乱七八糟的型式
例如错误的 DVD mastering，剪接的时候少掉一张，图场颠倒，enocder 的 IVTC 错误，造成 frame 画面补不回无交错的状态..... 等等。
八仙过海，各显神通
3. 什么是 blended field
blended，混合，当画面上有交错的时候，用奇偶平均的方法，混合奇偶两个图场，可以减少突兀的交错现象，是去交错的方法之一。副作用，一是画面变模 糊，清晰度下降，二是两张不同的画面混合在一起，看起来像是两个影像重迭在一起，会有残影，或者叫「鬼 影」的现象。
blended field，一个 field，是取自经过 blended 的 Frame，所以画面会有残影，包含了两个画面的影像。
例如对 x480 的交错讯源使用 TMPGEnc 的 Double 去交错，然后缩小至 x240 的 VCD 输出，画面上会有残影，包含了原本 x480 两个 field 的影像。
有些 PAL <-> NTSC 转换的机器会造成这种 blended field，部分或全部的 field 是 blended field，这种 field 会造成 IVTC 的判断非常困难。
或者，有些动画，为了要造成高速移动的假象，或者营造动作的流畅感，会故意使用 blended field。
怎么判断是否有 blended field
用 Avisynth 的 SeparateFields()，画面会显示单一个 field，看有没有 field 是混合了两个画面，有两个影像在上面。
TMPGEnc 的 Deinterlace --> Even-Odd field (field) 也可以看。
遇到这种现象，有时你会发现 blended field 主要出现在一个 Frame 的第二个 field（Bottom field），所以使用 Decomb 的时候，让 Decomb 使用 Top field 来做 matching 的动作（比对两个 field，看哪一种组合交错最少，也就是 奇偶的差异最小），可以帮助 Decomb 正确的判断。
4. Decomb 的比对方式
Decomb 预设的比对方法
1) 暂存三个 Frame，分别是现在的 Frame C，过去的 Frame P，和下一个 Frame N。
2) t 代表 Top field，b 代表 Bottom field，Decomb 会做三种 field 的组合，看哪一种交错的情形最少
Pt Cb <- 以 Cb 为基准不变，去和前（P）、后（N）、目前（C）的 Top field 做组合 Ct Cb Nt Cb
以 3:2 pulldown 的讯源为例
1 2 3 4 5 At Bt Bt Ct Dt Ab Bb Cb Db Db
第 3 个 Frame 经过 Decomb 重新组合，会变成
Bt Cb Bt Cb Ct Cb <- 中奖，这个组合奇偶差异最小
3) 输出差异最小的组合
如果用 reverse 参数，Decomb 会改成以 Ct 为基准不变，去和前、后、目前的 Bottom field 做组合
Ct <- 以 Ct 为基准不变，去和前（P）、后（N）、目前（C）的 Bottom field 做组合 Pb Ct Cb Ct Nb
所以 Doom9 的讨论中，neuron2 大大建议的作法
Telecide(post=false)
Telecide(reverse=true,post=true)
让 Telecide 正、反各跑一次，去 match 最适合的 field。
**附注**
上面的参数是 Decomb 4.xx 版的参数，这篇文章是以前写的，现在 5.10 版已经换了参数名称。
********
如果每一个 field 都是 blended field，那么无可能 IVTC，只有做去交错，把讯源当成是完全的 interlaced
FieldDeinterlace(full=true)
5. Deinterlacing -> Progressive 的方法
/** Video Mode **/
1. Intrafield Processing: Field 内的处理 (Bob)
a. Scan Line Duplication or Single-Field Duplication
在计算机上可以，舍弃其中一个图场，不足的一半扫瞄线用重复上一条扫瞄线的方式补上去，仍然维持 29.97fps x480。
或是
不舍弃图场，加倍显示速率，29.97fps x480 -> 59.94fps x480，每次显示原来的一个图场，不足的一半扫瞄线用重复上一条扫瞄线的方式补上去。
line1 = 1
line2 = line 1 = 1
line3 = 3
line4 = line 3 = 3
没有残影。
线条不平滑，锯齿感很严重。
b. Scan Line Interpolation or Single-Field Interpolation
在计算机上可以，舍弃其中一个图场，剩下的一半扫瞄线用内插补点（Interpolation）的方法补出来。
如 TMPGEnc 的 Even field/Odd field 去交错法。
或是
不舍弃图场，加倍显示速率，29.97fps x480 -> 59.94fps x480，每次显示原来的一个图场，剩下的一半扫瞄线用内插补点补出来。
如 TMPGEnc 的 Even-Odd field 去交错法。
line 1 = 1
line 2 = (line 1 + line 3)/2
line 3 = 3
line 4 = (line 3 + line 5)/2
上面举例的 linear interpolation 品质很差，实作会用品质较好的补点方法，例如 (sin x)/x ie. sinc interpolation
line n = 0.114*line(n-5) - 0.188*line(n-3) + 0.574*line(n-1) + 0.574*line(n+1) - 0.188*line(n+3) + 0.114*line(n+5)
这是微软当初提 Bob 的原意，但是当时的硬件没有办法做到及时补出另一半的扫瞄线，所以软件 DVD Player 实作 Bob 的时候，是用 Blend 取代 Bob。
所以现今 WinDVD, PowerDVD 的 Bob 选项，指的都是 Blend。
WinDVD 5 新增一个消除锯齿的方法 "Progressive"，便是加倍显示速率，内插补点的 Bob。
2. Interfield Processing: Field 和 Field 之间的处理
a. Field Merging
a-1. Field Combining (Weave)
合并两个 Field 一起显示。
如果画面动态不大，交错不会很明显。
好处是清晰度最高，坏处是动态大就会破功（会出现明显交错）。
在电视上是合并两两的 Field
[ 2 ] [ 4 ] [ 6 ] [ 8 ] 1o 1e 2o 2e 3o 3e 4o 4e 5o 5e <-- 输入 Field [ 1 ] [ 3 ] [ 5 ] [ 7 ] [ 9 ] <-- 输出 Frame
维持 59.94 的显示速率。
在计算机上没有这个限制，Weave 就是
1o 1e 2o 2e 3o 3e 4o 4e 5o 5e <-- 输入 Field [ 1 ] [ 2 ] [ 3 ] [ 4 ] [ 5 ] <-- 输出 Frame
29.97fps 输出。
那不是和原来一样？
所以计算机上的 Weave，还表示如果是 Film 讯源，可以 skip 3:2 pulldown 的旗标，还原、重组正确的 Progressive Frame，有这一层意思在。
[1o 1e] [2o 2e] [2o 3e] [3o 4e] [4o 4e]
x x <-- 删除重复的 Field
---->
[1o 1e] [2o 2e] [3o 3e] [4o 4e]
a-2. Vertical Filtering (Blend)
奇偶平均，混合两个 Field。
例如 TMPGEnc 的 Double 去交错法。
因为 Blend 之后，画面会出现两个重迭的影像（double image），所以叫做 Double 去交错法。
b. Motion Adaptive Deinterlacing
动态自适应去交错。
画面上静态没有物体移动的区域，用 Weave；画面上动态有移动的区域，用 interpolation。
这样人眼比较敏锐的静态区域可以维持高清晰度，人眼看不清楚细节的高动态区域可以减少明显的交错瑕疵。
c. Motion Compensated (Motion Vector Steered) Deinterlacing
做动作搜寻，计算每个 pixel 在 Field 间的移动量，内插计算新的 pixel 值。
这是非常复杂的去交错方法，只有在专业的 conversion 机器上才看得到。
Avisynth 有这种 deinterlacing 的 plugin，叫做 TomsMoComp，不过这个 plugin 对字体的 tracking 常常会产生杂点，必须要降低搜寻的精度，才能减少这种现象。
/** Film Mode **/
Inverse Telecine or IVTC or Inverse 3:2 Pulldown
例如
1. Decomb
做法上面已经说过
2. TMPGEnc
TMPGENc IVTC 的小窗口，按下面的 Field 组合
1 2 3 4 5 6 7 8 9 10 ... 1t 2t 2t 3t 3t 4t 4t 5t 5t 6t ... 1b 1b 2b 2b 3b 3b 4b 4b 5b 5b ...
以 Bottom Field 为基准，去和现在以及下一张 Frame 的 Top Field 组合
一张变两张
所以五张输入变十张
1 2 3 4 四张 Frame，3:2 pulldown 之后得到五张 Frame
1t 2t 2t 3t 4t
1b 2b 3b 4b 4b
代入 TMPGEnc 的小窗口
1 2 3 4 5 6 7 8 9 10 1t 2t 2t 2t 2t 3t 3t 4t 4t 5t 1b 1b 2b 2b 3b 3b 4b 4b 4b 4b ^^ ^^ ^^ ^^ ^^ ^^
有 ^^ 记号的代表无交错的画面，奇偶差异小
相同的画面挑一个就可以了
手动指定 pattern 的话，0 代表不选，1 代表选
上面输入 "10100" 或 "10010" 或 "1001010010" 都可以
3. AviUtl
1t 2t 2t 3t 4t
1b 2b 3b 4b 4b
^^ <-- 将第三张 Frame 的 Top Field 和前一张 Frame 的 Bottom Field 结合
^^ <-- 将第四张 Frame 的 Top Field 和前一张 Frame 的 Bottom Field 结合
-->
1t 2t 2t 3t 4t
1b 2b 2b 3b 4b
删除重复的第三张 Frame
-->
1t 2t 3t 4t
1b 2b 3b 4b
在电视上，还原出来的 24fps 要做 "3:2 pulldown progressive scan" 转成 60fps 显示
1 1 1 2 2 3 3 3 4 4 3 2 3 2
事实上后面的部分我已经写好了，而且也在别的地方贴过，不过我忘了上来 CCF 补充 ^^;;
我回家后会把后面的部分再贴上来。
我的做法其实是非常麻烦的，必须要很有耐心。
sswroom 兄的做法比较快速，如果你用 TMPGEnc 手动 IVTC 的功力很高的话，用 sswroom 兄的做法会如鱼得水，好用得不得了
再加上 sswroom 兄的做法可以很方便的手动 drop frame，提高画质和压缩率，所以我建议最好是学会如何用 TMPGEnc 手动 IVTC，然后搭配 TPRRead 和 AVIRead，这样会比 Decomb 手动指定 override 方便。
由于事忙，先写到这。
这个讯源是 29.97 1920x1080i，每一张都是交错的画面。
原始分辨率是 1920x1088，画面下方多出来的 8 条扫瞄线是没有用的，可以把它切掉。
为什么要多加这无用的 8 条扫瞄线？
因为 1088 才可以被 16 整除，讯源是用 MPEG-2 压缩，所以要补成可以被 16 整除的分辨率。
HDTV 是遵照 ITU-R BT.709 的标准制作，BT.709 和我们一般习惯的，DVD 在用的 BT.601 不同，首先是色空间转换式不同，这个以前在说明 M2V 解码 HDTV 的色彩才会正确时已经有提过了，此处不再赘述；另一个不同是 PAR 不同，BT.709 取样的形状是正方形，PAR 是 1:1，就是说 BT.709 不像 601 那么麻烦，resize 之前还要左右切边，不用，BT.709 直接 resize 成你想要的 16:9 比例就可以了，所以处理很简单
因为这个原始 tp 文件切成两段，用 DVD2AVIT3 连接加载好像会出问题，最好先用 HDTVtoMPEG2 把两段先接起来，然后再用 DVD2AVIdg 开启。
讯源是 30i 的讯源，张张都交错，所以我们就很简单的舍弃一半的图场，这样就可以了
LoadPlugin("c:/Program Files/AviSynth 2.5/plugins/MPEG2Dec3dg.dll")
Mpeg2Source("c:/jewelry.d2v")
# 舍弃 Odd Field
SeparateFields()
SelectEven()
# 这时画面剩下 1920x544p
LanczosResize(960,544)
BT709ToBT601()
因为我没有把底部的 8 条扫瞄线切掉，所以垂直分辨率是 544，如果切掉，就是 540。
因为交错画面 Chroma 取样的位置关系（以前提过，唤醒记忆 ），上面的做法会令 Chroma 有半个 pixel 的 delay，trbarry 有写一个专门在做长宽减半的 interlaced resize，叫做 InterlacedReduceBy2，如果用这个 resize，就只要一行
LoadPlugin("c:/Program Files/AviSynth 2.5/plugins/MPEG2Dec3dg.dll")
Mpeg2Source("c:/jewelry.d2v")
YV12InterlacedReduceBy2()
BT709ToBT601()
就可以了，但是这个 resizer 水平 resize 太简单，filter 太少，线条边缘会有锯齿，不好看，所以我还是习惯用 LanczosResize。
最后，BT709ToBT601() 也是 trbarry 写的一个 filter，这个是做什么用的呢？因为 Avisynth 都是在 YUV 色空间上处理，而 HDTV 解码出来的 709YC 在一般以 601YC 为标准的 Codec/显示卡 上会显示错误的颜色，所以在压成 AVI 之前，要先将原始的 709YC 转成 601YC，这样后续的显示色彩才会正常。详细以前说过，就不再重述。
trbarry 举了一个图片做为范例
http://mywebpages.comcast.net/trbarry/BT709ToBT601.2.jpg
左边是 709YC 不做处理，以 601YC 的转换式解码之后的结果，人脸变成粉红色，右边是经过 709YC->601YC 处理，以 601 转换式解码之后的结果，这样就正确了。
trbarry 是谁应该不用介绍？
而 M2V 这个解码软件会根据 MPEG-2 stream 里面的一个旗标，叫做 matrix_coefficient，如果有在用 MainConcept MPEG Encoder 的人应该会觉得这个字很眼熟
M2V 会根据这个旗标的信息，知道该 MPEG-2 使用的色空间是什么，而做正确的转换，所以我以前说解码 HDTV 只有 M2V 会正确。
但是有例外的情况。
譬如说日本 BSD 的 WOWOW 台，有时候它播放 SDTV 的节目，例如 Onegai Twins 这部我想很多人知道的动画，如果你去分析它的 bitstream，会很惊讶地发现，它的 bitstream 竟然说它使用的是 709YC。然而 Onegai Twins 只有 480i，并不是 HDTV 的节目。所以我们怀疑，他很有可能是标错了，因为 WOWOW 台内的同一台 MPEG-2 压缩机器，同时要压 HDTV 和 SDTV 的节目，在压缩时制作人员没有记得切换压缩的设定，改变旗标，所以 SDTV 的节目也沿用了 HDTV 的旗标。
然而实际上，这个节目是 601YC，要以 601YC 来解才正确。
我们将当初播放时的 MPEG-2 TS 和后来出的 RC2 DVD 的颜色作比对，果然要用 601 解码才正确，用 MPEG-2 TS 用 601 解码，才会得到和 DVD 一样的色彩。
所以当初在 BSD 上直接看播放时，大家看到的色彩都是错误的
（BSD 的 tuner 会根据旗标，切换转换式解码，旗标说是 709，tuner 就乖乖的用 709 解码，结果反而错误 :-.-: ）
这个时候，我们如果用 M2V 解码这种讯息不正确的 MPEG-2 TS，反而会得到错误的结果，用 DVD2AVI 这种不管三七二十一，一律用 601 解码的 decoder，反而正确 ^^;
幸好 M2V 可以强制 override 原先的设定，可以强制使用你设定的色彩转换式解码，所以如果你知道有这种问题，便会自己做判断，做正确的切换，得到正确的结果。
以上是当初要讲结果没时间详细讲完的内容
韩国的 SBS HD HDTV，画质不如日本的 BSD HDTV。日本的 BSD HDTV 码率可到 28Mbps，比 ITU-R BT.1211-1 所建议的 22Mbps 还要大 8M，而韩国的 SBS HD，例如上面举例的 jewelry.tp，码率只有 18.03M，所以方块满天飞舞.... >_<;
看 BSD 上播放的 1080i 的动画，几乎没有压缩瑕疵，看久了大概其它什么东西都看不下去
TMPGEnc 3 beta 已经出现啰
崛老，作者崛浩行，其实一点都不老，他写出 TMPGEnc 的时候还不到 19 岁，不过因为我们对他的尊敬，还是称他为崛老 ^^;
崛老把 filter 改成 YUV 处理，不像以前用 RGB，我朋友知道一定高兴死了，他以前最头疼的就是这个问题。改成 YUV 处理（有部分 filter 仍然是 RGB），还有新的动作搜寻，现在据说速度有提升，而且画质更好啰，大家可以期待等正式版推出
说到年轻有为，Nero Digital 的 AAC 编码的部分，作者我们大家知道是 Ivan，Ivan 之前是在 PsyTel 工作，Nero AAC 的前身就是 PsyTel AAC。Ivan 写 AAC 的时候是几岁大家知道吗？19 岁。他现在应该还是二十出头。
还有 MarcFD，写出 deen, edeen, MPEG2Dec3 的时候，他中学还没毕业....
VMOD直接读入DS源显示是4:2:2的?
HDTV 是 YUV 4:2:0，您会看到 dshow 输入显示 4:2:2，是因为您用 Elecard 的 MPEG2 Decoder 解码，Elecard MPEG2 Decoder 解码会输出 YUV 4:2:2，就如同用 MPEG2DEC 解码会输出 YUV 4:2:2 一样。
原始讯源和一般的 DVD 一样，都是 YUV 4:2:0。
| 引用 |
|
我看到这段SBS的HTDV 已是我见过的最好的HDTV了 没见到什么方块满天飞呀
|
可能是因为您的屏幕分辨率没有切换到 1920x1440 的关系，没有切换到 1920x1440，必需缩小画面显示，这些瑕疵经过缩小以后会比较不明显。
我把原图的画面撷取部分出来给您看
这些都是原始大小，1:1，没有放大或缩小，您可以看到画面上都是方块。
静态的画面还可以，但是一到有动作的画面，不用是很大的动态，只要是有动态，画面就出现这些方块。
这是因为交错画面非常难压缩，而这部的码率又不够的关系。
和 BSD 相比，BSD 几乎没有这种瑕疵。
1080i 的分办率，根据 ITU-R BT.1211-1 的实验，MPEG-2 码率必须到 22Mbps 以上，才符合 1211-1 要求的视觉水准，而这部显然不及格。
其实就算是 BSD，在魔人等级的眼中来看，也还是有许多是不及格的。虽然规格上 BSD 的 video 的码率可以到 24.6Mbps，但是 BSD 也是有许多 HD 节目用不到 21Mbps。例如大家知道 DVD2AVI 的作者是 jackei，jackei 很早就在他的网页中提出「BSD 真的是高画质、高音质吗？」这样的疑问。他把 BSD 放送的 MPEG-2 TS + AAC 抓下来解剖分析
请看
http://arbor.ee.ntu.edu.tw/~jackei/projectbsd/
连 BSD 都有人嫌了 ^^;
| 引用 |
|
如果直接读入DS源. 是不是不要做 709--->601的转换? |
我没有实验过用 Elecard MPEG2 Decoder 解码，所以不知道它有没有帮我们做 709->601 的转换，不过先不说转换这点，新版的 Elecard MPEG2 Decoder 的 Chroma upsampling 是错的，这个很严重，因为你解码的完全是 1080i 的交错画面，Chroma upsampling 不可以错的。而且 Elecard MPEG2 Decoder 输出的是 4:2:2，不是 YV12(4:2:0)，所以你事后根本补救不回来。
旧版的 Elecard MPEG2 Decoder 解码 Chroma upsampling 是对的不知道为什么新版的反而做错了。
建议用 DVD2AVIT3 这个可以直接读取 .ts/.tp 这种 MPEG-2 TS(Transport Stream) 的版本来处理 MPEG-2 TS，后面再加上 BT709ToBT601()。
您问的第一个问题我不知道该怎么回答
第二问题算式不同的原因是您写的算式是模拟 YCbCr 和模拟 RGB 的转换式，这是很多人会被弄迷糊的地方。
ITU-R BT.601 建议书里面记载了五种色彩变换式，分别是：
1. 模拟 RGB 讯号转为模拟 Y, (B-Y), (R-Y)
2. 模拟 (B-Y), (R-Y) 转为模拟 Cb, Cr
3. 模拟 YCbCr 数字化（取样、量化）成为数字 YCbCr
4. 模拟 RGB 数字化（取样、量化）成为数字 RGB
5. 数字 RGB 转为数字 YCbCr
1. 的变换式是
Y = 0.299 * R + 0.587 * G + 0.114 * B (R - Y) = R - 0.299 * R - 0.587 * G - 0.114 * B = 0.701 * R - 0.587 * G - 0.114 * B (B - Y) = B - 0.299 * R - 0.587 * G - 0.114 * B = - 0.299 * R - 0.587 * G + 886 * B
2. 的变换式是
Cr = 0.713 * (R - Y) = 0.500 * R - 0.419 * G - 0.081 * B Cb = 0.564 * (B - Y) = - 0.169 * R - 0.331 * G + 0.500 * B
就是你写的那个变换式。
上式 Y, R, G, B 的范围是 0.0~1.0，Cb, Cr 的范围是 0.5~-0.5。
模拟的 CbCr 通常表记为 PbPr。
由于这些表记的方法很乱，常有人会混合着用，所以写的时候最好注明是模拟还是数字，例如
3. 的模拟 YCbCr 数字化转换式
Y(d) = 219 * Y(a) + 16
Cb(d) = 224 * Cb(a) + 128
Cr(d) = 224 * Cr(a) + 128
Y(a) 代表 analog，Y(d) 代表 digital。
4. 的模拟 RGB 数字化转换式
R(d) = 219 * R(a) + 16
G(d) = 219 * G(a) + 16
B(d) = 219 * B(a) + 16
R(a), G(a), B(a) 的范围是 0.0~1.0，R(d), G(d), B(d) 的范围是 16~235。
加上 (a), (d)，这样表记就清楚多了。
5. 的数字 RGB 转为数字 YCbCr
Y = (77 * R(d) / 256) + (150 * G(d) / 256) + (29 * B(d) / 256)
Cb = - (44 * R(d) / 256) - (87 * G(d) / 256) + (131 * B(d) / 256) + 128
Cr = (131 * R(d) / 256) - (110 * G(d) / 256) - (21 * B(d) / 256) + 128
YCbCr: 16~235, RGB: 16~235
这个转换式是 straight 变换，没有 YC 伸张（Full-range，扩展 RGB: 0~255），有 YC 伸张的算式就是你提出的我以前写的那个算式。
这个表记法有点复杂，有的教科书在介绍亮度和色差的时候前面就先花了很多篇幅在定义表记的用法，例如我上面写的还是不及格，因为 BT.601 的 RGB 都要先经过 gamma correction，是 gamma 校正后的 RGB，要表记为 R'G'B' ^^;
还有那个 Y，是 BT.601 的 Y，所以 Y 的右下角要加上一个底字写 601，或者左上角要写 601，这样人家才知道你是 BT.601 定义的 Y，不是 BT.709 定义的 Y ^^;;
由于名词太多有点乱，许多人会混合着用，同样一个 YUV，有时候我们搞不清楚作者指的到底是数字的 YCbCr，还是模拟的 YPbPr，是 NTSC 的 YIQ，还是 PAL 的 YUV，是 601 的 YUV，还是 709 的 YUV，或者是 SMPTE 240M 的 YUV .... XD
有的时候作者在表记上没有明写，不过根据上下文意，我们可以猜出他说的是哪一个。
您看的那本书 有注明列的是 ITU-R recommendation BT.601 [1]的 YCbCr 转换式，所以是模拟转换式，不是 BT.601-5。
当然用比较通用的 PbPr 来表示模拟色差是比较清楚的写法。
ITU 的建议书（recommendation）只要登记成为会员，每年都可以免费下载三本，601, 709, H.263 ..等等都可以免费下载
http://www.itu.int/publications/bookshop/index.html