『漫游』酷论坛>『影音数码技术学习交流』>[请教]DVDRIP的较色问题

tct66@2006-02-11 21:01

@紧箍咒
我沒說,他做了2次YC伸張

"M2V解码设定中指定了输出ITU-R BT.601 Range"
是做了YC伸張

另外aviutl有個插件可以看這2者的RGB
Full Range->不做YC伸張等同於dvd2avi的TV Scale
ITU-R BT.601 Range->YC伸張等同於dvd2avi的PC Scale

稍後貼圖吧
引用

tct66@2006-02-11 21:21

Full Range->不做YC伸張等同於dvd2avi的TV Scale

ITU-R BT.601 Range->YC伸張等同於dvd2avi的PC Scale
引用

大虾@2006-02-11 21:25

我在AU里面没开TV->PC。

不过我确实是搞错了，一直以为是601 range=16-235。那篇文章写错了，先删掉。

这才发现用片子来测试结果不准。我刚用AVS生成了一个彩条用TMPGEnc压成MPEG2，进行更详细的比较之后发上来。

这才发现我对一些问题的理解一直有问题，先去充电-0-
引用

紧箍咒@2006-02-11 21:43

引用
最初由 tct66 发布
（M2V -> RGB 時選 BT.601 Range 伸張一次
AviUtl 電視->電腦色調 修正又伸張一次
or
D2V -> RGB 時選 PC Scale 伸張一次
AviUtl 電視->電腦色調 修正又伸張一次
這樣會做二次 YC 伸張，都是錯誤的做法）


这句话你确实没说是谁做错了，我误会你了。

是啊，任何时候读入正确但是用滤镜做tv->pc都是错误的，但是选601和选pc scale然后rgb入都没错。

就象我前帖说的，以vfp读入的情况选601正确，而选full还要做伸张才行。aui读入完全无关，而tv scale和pc scale对于aviutl来说，直接读入d2v的结果几乎完全一样，它是根本不管你选什么scale的。

再说说你贴图的问题

你可能对au不够了解，au的“rgb”和“预览画面”都是模拟伸张后的，因为要让你看到放出来的大致样子，不要被骗了，选601才是正确的，601是伸张，但是是相对于“full range”的伸张，这个full range不是真的“直接转换”，而是yc压缩。

从你这个图来讲，rgb表示出的情况在模拟伸张后应该是0-255，而16-235是yc压缩的画面在模拟伸张后的情况，这个值是让你知道最终压好后的片子在播放时的情况，而不是目前的情况，这个值和内部的yc实际是不同的。实际上日本人对这个问题早在几年前就有过试验证明。

这个设定实际是au人性化的一个缩影，它就是让你所见即所得，有据可循，如果错误地理解了，反倒糟了。
引用

紧箍咒@2006-02-11 21:52

“結論:AviUtlのプレビューがキレイだったら読み込みは成功してるって事です。
内部処理はRGBが最初に入っているので微妙に違いますが。ということで、出力を考えてみましょう。
AviUtlの内部はYUVです。プレビューはPC画面に映る限りRGBです。

AviUtlの内部とプレビューが違うことを理解して、出力も考えてみます。
この2つの差を理解できれば、入出力で色伸張と色圧縮による間違えを防げませす。”

找了一下，这个是原话。而rgb和这个预览所用的是一样的，内部yc不一样。

那两张图，连rbg值都不用看，只要看那两个预览画面哪个才是真正的白就能知道哪个才对。“AviUtlのプレビューがキレイだったら読み込みは成功してるって事です。”言简意赅，常做rip的话看一眼预览就全明白了。
引用

大虾@2006-02-12 09:46

有没有一种方法使读入后即不伸张也不压缩，呈现MPEG2中颜色的本来面貌？
引用

大虾@2006-02-12 15:44

刚才看了M2V的readme才知道，m2vconf.exe里面YUV Range中Full Range指的是YUV [0:255] を RGB [0:255] に変換します，认为MPEG2中的是0~255的YUV，直接转换至RGB 0~255的颜色范围，不扩张也不压缩。而ITU-R BT.601 Range指的是ITU-R BT.601 から伸張，Y [16-235] UV [16-240] を RGB [0:255] に変換します，认为MPEG2中是ITU-R BT.601 的Y [16-235] UV [16-240]画面，在转换成RGB的时候，做YC伸张。

因为m2vconf.exe是英文的，我没理解清楚，以为是选择输出，而看了readme之后才发现是选择输入，天大的误会。
引用

tct66@2006-02-12 16:09

@ 紧箍咒
你說的是這篇嗎?還是看原文的吧...
貼圖的後3張和前2張對比有明顯的stairs..
http://jumper-x.hp.infoseek.co.jp/study/6/index.html
另外引用Silky的話
"MS MPEG-4 Codec，DivX Codec，XviD Codec 这几个 Codec 都是假设收到的数据是0~255，会先做 Y/C 压缩的动作。"

YUV(-1) 代表 Y: 16~235, UV: 16~240
YUV(0) 代表經過 YC 伸張 Y: 0~255, UV: 0~255
RGB(0) 代表 RGB: 0~255，在電腦上看，要顯示 RGB(0) 才是正常的顏色
RGB(-1) 代表 RGB: 16~235，經過壓縮後的 RGB

[DVD2AVI 解出的是] YUV(-1) [YC 伸張]--> YUV(0)--> [AviUtl 的視窗顯示的是] RGB(0) [壓縮前先經過 RGB 壓縮]--> RGB(-1) [然後]--> YUV(-1)

播放 YUV(-1) [顯示卡的色空間轉換或 MS MPEG4 Codec 都會做 PC Scale]--> YUV(0)--> RGB(0) 顯示正常

如果不做 ITU-R BT.601 補正
[DVD2AVI 解出的是] YUV(-1)--> [AviUtl 的視窗顯示的是] RGB(-1) [壓縮前先經過 RGB 壓縮]--> RGB(-2) [然後]--> YUV(-2)

則播放的時候 YUV(-2)--> YUV(-1)--> RGB(-1) 顯示錯誤

所以可以再補一次 ITU-R BT.601 補正 救回來
[做錯的] YUV(-2) [MS MPEG4 Codec 伸張]--> YUV(-1)--> [AviUtl 的視窗顯示的是] RGB(-1) [再伸張一次]--> RGB(0) [喔喔，正常了] [壓縮前先經過 RGB 壓縮]--> RGB(-1) [然後]--> YUV(-1)
引用

大虾@2006-02-12 16:18

做了一个标准彩条，只包含两帧，全都是I帧。
下载地址：http://www.dgwxx.cn/colorbar/colorbar.m2v 大小：48K
用于生成彩条的AVS：
复制代码
  1. #生成一个640*480、RGB（Y [16-235] UV [16-240]）、29.97fps的彩条信号
  2. ColorBars()
  3. #resize、加黑边，做成DVD一样的分辨率
  4. lanczosresize(711,480)
  5. addborders(4,0,5,0)
  6. #转换成YV12，ConvertToYV12()默认的情况下，转换后依然是Y [16-235] UV [16-240]的画面。
  7. ConvertToYV12()
  8. #删除ColorBars生成的音频
  9. killaudio()
  11. trim(0,1)


使用TMPGEnc编码成MPEG2，使用CQ100，使用Non-interlace、制定来源为progressive，使用了标准MPEG量化模板，选择了Output YUV data as Basic YCbCr not CCIR601（不做YC压缩），所以这段M2V里面的颜色依然是Y [16-235] UV [16-240]的视频。

在压制之前，先按照往常压DVDRIP一样载入这个M2V，测试彩条中的黑色和白色部分，既可知道当前的YC范围，是否经过YV伸张就一目了然了。
具体情况：
测试黑色和白色部分，如果RGB值分别为255,255,255和0,0,0，那么就是做过了YV伸张，如果是235,235,235和16,16,16那么就是没有做过YC伸张。


不知道这样的做法是够有错误，请指正。
引用

紧箍咒@2006-02-13 19:10

预览的过程：
DVD2AVI读入plugin解出的是RGB(-1)-->YUV(-1)-->滤镜处理-->AviUtl 的視窗顯示的是YC伸張到RGB(0)[伸张仅仅用于显示]

压缩的过程：
DVD2AVI读入plugin解出的是RGB(-1)-->YUV(-1)-->滤镜处理-->YUV(-1)[既无伸张也无压缩]

压缩的信号并非预览信号做yc压缩，这个过程是不存在的。只要是预览正确的，就正确了，没有其他那么多理由。au的d2v读入plugin是rgb，但是为了适应au的色空间肯定要转，m2v有yuy2的问题，也一样要转到au的色空间。
引用

tct66@2006-02-13 20:09

@紧箍咒
m2v的readme
--------------------------------------------------------------------------------
ストレート変換:YUV [0:255] を RGB [0:255] に変換します
ITU-R BT.601 から伸張：Y [16-235] UV [16-240] を RGB [0:255] に
　　　　　　　　　　　　　　変換します
--------------------------------------------------------------------------------
和你說的明顯完全不同...
--------------------------------------------------------------------------------
这个full range不是真的“直接转换”，而是yc压缩。
--------------------------------------------------------------------------------
引用

紧箍咒@2006-02-13 20:54

仔细想了一下，66是有道理的，不过有些问题按照这个道理还是不明：

[M2V vfp 直接变换解出的是] RGB(-1) [不伸張]--> YUV(-1)--> [AviUtl 的視窗顯示的是] RGB(-1)

[M2V vfp 601解出的是] RGB(0) [YC 伸張]--> YUV(0)--> [AviUtl 的視窗顯示的是] RGB(0)

如果这样的话，由于au的D2V reader读入时是RGB，但实际上不管之前选pc scale还是tv scale做出来的d2v，结果完全一样，都是显示RGB(0)，这样的话，d2v reader读入时到底做了什么？忽略pc和tv一律不伸张，还是忽略pc和tv一律伸张？如果按上面M2V的情况，就是应该一律伸张。否则不能显示RGB(0)。但实际上d2v reader有没有这样做？是第一个不明。

另一方面来说，au存在yuy2 filter mode，在这个模式中读入，和在默认模式中读入所见到的预览完全一样。这样的话只能是：

[D2V reader解出的是] RGB(0) [YC 伸張]-->YUY2(0)--> [AviUtl 的視窗顯示的是] RGB(0)

压缩时：

[D2V reader解出的是] RGB(0) [YC 伸張]-->YUY2(0)-->YC压缩(自动做)-->YUY2滤镜处理-->YUY2(-1)

或者是压缩时：

[D2V reader解出的是] RGB(0) [YC 伸張]-->YUY2(0)-->YUY2滤镜处理-->YC压缩(自动做)-->YUY2(-1)

既然YUY2模式的意义是kenkun开始尝试全过程YUY2处理，那么为什么要做不符合601的YUY2空间，增加中间的转换过程？

或者是这样的：

遇到任何RGB(0)自动YC压缩-->YUY2(-1)-->YUY2滤镜处理-->YUY2(-1)

还是非常诡异，但最可能的情况还是只存在YUY2(-1)，因为kenkun最可能希望的情况应该是：

YUY2读入[YUY2(-1)]-->YUY2(-1)空间-->YUY2滤镜处理-->YUY2(-1)输出

那么怎样解释这个时候的预览图？既然这个时候预览仍然显示RBG(0)，那么就必须在滤镜处理后对处理结果做伸张然后显示出来。

这样的话，又和你说的情况，即读入0，显示0，读入-1，显示-1不同，也就是说kenkun需要对两个模式的预览做两个流程，这种情况让人很在意，觉得奇怪。这是第二个不明。
引用

大虾@2006-02-14 00:21

引用
最初由 tct66 发布
@紧箍咒
m2v的readme
--------------------------------------------------------------------------------
ストレート変換:YUV [0:255] を RGB [0:255] に変換します
ITU-R BT.601 から伸張：Y [16-235] UV [16-240] を RGB [0:255] に
　　　　　　　　　　　　　　変換します
--------------------------------------------------------------------------------
和你說的明顯完全不同...
--------------------------------------------------------------------------------
这个full range不是真的“直接转换”，而是yc压缩。
--------------------------------------------------------------------------------


我最开始也认为过FULL RANGE是压缩，但是这样不是太奇怪了么？解码器要么压缩要么扩张，没有直接转换？一般都是编码器方面存在“直接转换、YC压缩”（比如TMPGEnc），解码器方面存在“直接转换、YC扩张”（M2V）。实验证明，16-235的彩条经由M2V的Full Range，还是16-235，而经过BT.601之后，被扩张到了0~255。

另外有两个疑问请教高人：
1.从我的观察来看，AU的クリップボードにコピー是不受插件的影响的，无论是否使用扩张色调补正、crop、resize，copy出来的都是原始画面。那么这个copy出来的不受插件影响的画面，是不是就是解码器喂给AU的原始画面（AU自行进行的RGB->YUY48不包括其中）？
2.AU的システムの設定->YUY2に変換時にY16-235 UV16-240の範囲に飽和这个选项是什么意思？
引用

紧箍咒@2006-02-14 21:15

这次回的比较长，分两个帖子写。

上网查了一下，发现这个话题以前有过类似的讨论，看了以后更明白了一点，但是也可以说更不明白了一些，因为似乎存在两种观点，第一种观点来自2ch上的一篇老帖（其中有junmperさん参与），第二种观点是一个au滤镜作者写的，两种说法有一定差别，目前很难断定哪种更有说服力。

第一种观点（2ch老帖）

讨论中有人做了一个试验，用0.16.235.255的bmp图在Premiere导入，然后分别用DivX，huffyuv，canopusDV三种编码输出avi

huffyuv DivX的情况：
压缩为avi时
RGB0-255->codec内部YUY16-235压缩->YUY16-235范围的AVI
AviUtl读入时
YUY读入: YUY16-235->以YUY16-235范围传递给AviUtl->AviUtl来做RGB0-255伸张的画面
RGB读入: YUY16-235->codec做RGB0-255伸张->直接输出RGB0-255的画面

canopusDVcodec的情况：
压缩为avi时
RGB0-255->直接转换至YUY0-255->YUY0-255范围的AVI
AviUtl读入时
YUY读入: YUY0-255->以YUY0-255范围传递给AviUtl->AviUtl来做RGB0以下，255以上的过度伸张画面
RGB读入: YUY0-255->直接转换RGB0-255->直接输出RGB0-255的画面

因为canopusDVcodec本身实际要求的源是RGB16-235，符合这个标准的话：
压缩为avi时
RGB16-235->直接转换至YUY16-235->YUY16-235范围的AVI
AviUtl读入时
YUY读入: YUY16-235->以YUY16-235范围传递给AviUtl->AviUtl来做RGB0-255的伸张画面
RGB读入: YUY16-235->直接转换RGB16-235->直接输出RGB16-235的画面

以下为猜想

因为是这样的结果，或许可以猜想M2V直接转换是类似于canopusDVcodec（解码不自动伸张），而D2V类似于DivX（解码自动伸张），两者性质不同，即：

M2V以直接转换RGB读入(16-235)->以YUY16-235范围传递给AviUtl->直接输出RGB16-235的画面->压缩为mpeg4时yc再压缩（错误）

M2V以601转换RGB读入(0-255)->以YUY0-255范围传递给AviUtl->直接输出RGB0-255的画面->压缩为mpeg4时yc压缩（正确）

D2V以RGB读入(解码伸张至0-255)->以YUY0-255范围传递给AviUtl->直接输出RGB0-255的画面->压缩为mpeg4时yc压缩（正确）

因此66的观点按这个解释是正确的。

但是也有问题存在，后面又有人指出预览画面和内部YUV并不同，所以具体是否如猜想，并不明确。

其中有人说到：

YUY2展开、压缩设定的意思是：
选中：由Aviutl来做压缩和伸张
不选：有codec按该codec内部规定的计算式来做RGB<->YUV转换（某些编码存在压缩和伸张问题）

又有人翻出以前的aviutl的log来：

输入输出由codec完成转换的时候（不选YUY2展开、压缩），输入输出为RGB
输入输出经过VFAPI的时候，输入输出为RGB
输入输出为RGB时，RGB24<>YUV的转换由aviutl来进行，RGB<>YUV时会产生误差不用说，数据精度还会由于运算过程而降低
早期的一部分内建滤镜（扩张色调补正？）是以RGB24来处理的

输入输出由Aviutl完成转换的时候（选YUY2展开、压缩），输入输出为YUY2
输入输出经过.aui的时候，输入输出为YUY2
输入输出为YUY2的时候，YUY2->YUV48的mapping由Aviutl来做，没有色彩变换误差，但是YUV48->YUY2 mapping的时候，数据精度会由于运算过程而降低
YUY2展开、压缩时，早期的一部分内建滤镜（扩张色调补正？）仍然是以RGB24来处理的

Aviutl的YUY2 filter mode，内部色彩空间变为YUY2，输入输出情况仍然遵从原来的默认空间情况

这两段比较有意思。
引用

紧箍咒@2006-02-14 21:31

第二种观点：

转换至内部YCbCr时，y从1-254转换至-256－4445，uv从1-254转换至cbcr -2341－2633，这样的话yuy2读入，y由16-235转换至内部0-4095，uv从16-240转换至内部 -2048－2047，但是rgb却不同，rgb读入时是0-255，但是转换完成后却同样是0－4095和 -2048－2047，实际上是相对压缩了。（这一段很有意思）

plugin的开发工具包内明确指出y在0－4095，cbcr在-2048－2047范围，因此如果不知道内部实际转换的规定的话，在开发滤镜的时候，会出现以为rgb读入转换至YCbCr后y会取负值的情况，是出问题的要因。

因此aviutl做RGB<->YCbCr相互转换时必定出现scale变化，内部为YCbCr处理，但用YCbCr伸张到RGB作为预览，RGB值也用YCbCr伸张来做。

aviutl内部为YCbCr处理，YUY2读入和保存时scale无变化，而RGB读入时做YC压缩，RGB保存时做YC伸张。

当选择YUY2展开、压缩时，选中时打开文件时向codec请求YUY2信息，不选中向codec请求RGB信息。当读入为RGB时，aviutl做yc压缩以适应内部YCbCr，期待解码器做压缩、伸张，并进行逆转换（这句着实诡异，但按上面的理论确实是和codec反着干），RGB输出保存的时候把伸张的东西给codec。

VFAPI的情况，aviutl->VFAPI为适应RGB做scale伸张，VFAPI->TMPEG由于同样是RGB，scale不变。

以下是推想

显示预览时：
以M2V做RGB读入->直接转换（RGB 16-235）->YCbCr（压缩）->内部处理（滤镜等）->伸张显示预览（RGB 16-235）
以M2V做RGB读入->601转换（RGB 0-255）->YCbCr（压缩）->内部处理（滤镜等）->伸张显示预览（RGB 0-255）
YUY2读入（YUY2 16-235）->YCbCr（不压缩）->内部处理（滤镜等）->伸张显示预览（RGB 0-255）

输出时：
YCbCr->不选择yuy2压缩->伸张到rgb->编码（部分编码做yc压缩）
YCbCr->选择yuy2压缩->不伸张直接转换为yuy2->编码（问题在这里）

这时候如果是m2v读入，使用Divx编码压制，不选择YUY2压缩，那么就是：
以M2V做RGB读入->601转换（RGB 0-255）->YCbCr（压缩）->内部处理（滤镜等）->不选择yuy2压缩->伸张到rgb->Divx编码（做yc压缩）

这样的话太恐怖了，要YC伸张两次，YC压缩两次，转换中的误差会叠加，所以按这个理论能YUY2就一定要YUY2。


然而，66帖中写到：

另外引用Silky的話
"MS MPEG-4 Codec，DivX Codec，XviD Codec 这几个 Codec 都是假设收到的数据是0~255，会先做 Y/C 压缩的动作。"

那么“YCbCr->选择yuy2压缩->不伸张直接转换为yuy2->编码”这个过程，如果编码收到yuy2和rgb都一样“假设收到的数据是0~255，会先做 Y/C 压缩的动作。"那么yuy2的就会在16-235基础上再压缩一次，就一定会压坏，但事实不是这样。那么如果要符合“都是假设收到的数据是0~255，会先做 Y/C 压缩的动作。”就必须是：

YCbCr->选择yuy2压缩->yuy2（aviutl做伸张到0-255）->编码（YC压缩）

这样就有了一个问题，如果要符合“都是假设收到的数据是0~255，会先做 Y/C 压缩的动作。”，那么用avs来做的东西，不管是转成RGB，YUY2,YV12，avs输出给编码的都必须是YC伸张的东西，否则编码假定收到的数据是0~255，会先做 Y/C 压缩的动作，就绝对压不出正常的东西来。这样的事情说实话很难理解。

那么是否只有收到RGB格式的东西才会假定为0-255？收到YUY2和YV12的东西不这样假定？这样的话比较靠近我平常理解的现象，但是事实是怎么样的，往往不一定符合我平常所理解的才是事实，这个部分（编码器是否对任何源都一样先做YC压缩）不能完全搞清楚的话，仍然不能解决是否yc伸张的这个基本问题。

不过我们也能得到一个明确的结论，不管是上面何种可能，M2V的问题大致是解决了，如果au以RGB读入M2V，必须选601变换；如果用avs读入m2v.vfp，选直接变换应该就够了（没试过，感觉是这样）
引用

«123»共3页

| TOP