『漫游』酷论坛>『影音数码技术学习交流』>[请教]x264压制出来画 ..
qyqgpower@2008-06-09 16:35
MJPEG用的矩阵就是JPG的算法，所以不存在A和B不相同的情况
roozhou@2008-06-09 17:02
引用
我当然知道RGB<->RGB，YUV<->YUV不存在601/709的说法。一般不会这样做的吧
问题是在RGB<->YUV pixel_type是较交给解码器去做转换 而ConvertTo可以手动设定 但是解码器可以根据片源自动正确识别并且转换么？COREAVC那个AUTO是否起作用？
这里的情况 你的意思是用其他解码器 比如FFD？ 而不用系统自带的是么？
问题是你为什么要转RGB，大部分视频编码器不支持RGB。
FFD的MJPEG解码器支持YUV输出，如果场序错了avs里加一句SwapFields()就解决了。
引用
最初由 qyqgpower 发布
MJPEG用的矩阵就是JPG的算法，所以不存在A和B不相同的情况
但是我这里M$，MainConcept和PicVideo三种解码器输出RGB得到三种颜色。
kzhou@2008-06-09 17:21
引用
最初由 qyqgpower 发布
MJPEG用的矩阵就是JPG的算法，所以不存在A和B不相同的情况
应该是这样, 要不ms的解码器也不会选择输出RGB了
我这里看了
DirectShowSource("C:\ng1.grf",audio=false)
FFmpegSource("C:\ng1.avi")
ConvertToRGB32(matrix="PC.709")
FFmpegSource("C:\ng1.avi")
ConvertToRGB32(matrix="PC.601")
FFmpegSource是出来原始的YCbCr, 但用601和709变换都和ms解码的RGB看起来不一样. 所以这片必须YCbCr->RGB->YV12来压
ps:FFmpegSource出来的交错画面可以用什么滤镜解决么?
引用
最初由 roozhou 发布
问题是你为什么要转RGB，大部分视频编码器不支持RGB。
FFD的MJPEG解码器支持YUV输出，如果场序错了avs里加一句SwapFields()就解决了。
但是我这里M$，MainConcept和PicVideo三种解码器输出RGB得到三种颜色。
SwapFields() 赞~~
把MainConcept和PicVideo输出的RGB, 和我刚才说的FFmpegSource输出比比看?
qyqgpower@2008-06-09 17:50
roozhou还没有搞清楚
MJPEG里的YCbCr是JPG标准的，直接downsampling到YV12->x264的话，没有任何渲染器、解码器可以在回放时正确还原。
所以必须YCbCr->JPG变换->RGB->709变换->YV12
至于三个解码器输出的RGB颜色不一样，那肯定是有两个使用了错误的matrix变换了原始YCbCr，至于到底哪个正确，谁知道:D
superkidx@2008-06-09 17:59
引用
最初由 roozhou 发布
FFD的MJPEG解码器支持YUV输出
可是为什么 输出到渲染器的是UYVY 而不是YV12呢
roozhou@2008-06-09 18:02
M$ RGB输出
MainConcept RGB输出
PicVideo RGB输出
ffdshow YUV输出
directshowsource("ng1.avi",pixel_type="YUY2")
SwapFields()
ConvertToRGB32(matrix="PC.601")
ffdshow YUV输出
directshowsource("ng1.avi",pixel_type="YUY2")
SwapFields()
ConvertToRGB32(matrix="PC.709")
セイバー@2008-06-09 18:04
百度不能外链
su_xinling@2008-06-09 18:06
不同意ls的说法，我已经提到把jpeg压缩和颜色变换关联是错误的理解。YUV储存解码到YUV就是本色，解到RGB就要换换损失，而且转换还要考虑是709/601和pc/tv scale2个问题，但对直接编码转换没有任何意义。之前我提到要注意pc/tv scale，我对M$解出的RGB，做ConvertToYV12("PC.601")结果等同ffdshow的YUV输出，这说明了，M$的解码器，对源的YUV认定是的pc sclae，然后采601标准转换。
qyqgpower@2008-06-09 18:23
解码到YUV是本色……原来你在电脑屏幕上看到的JPEG图片都是YUV
233
你连JPG到底是怎么、用什么参数对RGB采样，转成Y'CbCr的都没弄清楚
还有，未downsampling的Y'CbCr与RGB之间是无损转换的
我再说一次
对于RGB空间的图像，JPEG编码时将RGB用
Y = 0.299 R + 0.587 G + 0.114 B
Cb = - 0.1687 R - 0.3313 G + 0.5 B + 128
Cr = 0.5 R - 0.4187 G - 0.0813 B + 128
转换为YCbCr (256 levels)
而这个YCbCr是不可以用视频的matrix转回去的
因为
1.视频的YCbCr的范围不是256
Y->16~235
CbCr->16~240
2.逆转换的公式不同
计算机回放视频时，最终都要经过渲染器把YCbCr转成RGB呈现到显示器上，请教哪个渲染器是用JPG matrix的
su_xinling@2008-06-09 18:49
[QUOTE]最初由 qyqgpower 发布
解码到YUV是本色……原来你在电脑屏幕上看到的JPEG图片都是YUV
233
你连JPG到底是怎么、用什么参数对RGB采样，转成Y'CbCr的都没弄清楚
还有，未downsampling的Y'CbCr与RGB之间是无损转换的
我再说一次
对于RGB空间的图像，JPEG编码时将RGB用
Y = 0.299 R + 0.587 G + 0.114 B
Cb = - 0.1687 R - 0.3313 G + 0.5 B + 128
Cr = 0.5 R - 0.4187 G - 0.0813 B + 128
转换为YCbCr (256 levels)
你上面所述就是错误的理解，RGB-〉YUV那是为了加大压缩力度，所以才先行采样成YUV，接着才是JPEG压缩算法，JPEG本身压缩不一定就非得YUV，只是YUV是视频领域采用格式。另外，如果是直接mjeg对YUV源转换，根本就没有RGB-〉YUV这步骤了。
PS：之前我已提到有pc/tv sclae2套，LZ的原决不是你说的256color，要不然M$出来的的就正确了。mjpeg编码器，也有pc/tv输出的开关选项，所以不是单行0-256标准，也有16-235这种，LZ的源就是。
qyqgpower@2008-06-09 19:07
第一：JPEG本身压缩
这是什么概念？
YCbCr->Downsampling->Block splitting->DCT->Quantization->Entropy coding
有哪一步脱离了YUV的基础了？很显然，JPEG的压缩流程与视频压缩是非常相似的
第二，直接对YUV转换的确可以直接从Downsampling这步开始，但你如何确定这个源是从什么格式转换过来的
kzhou@2008-06-09 19:12
引用
最初由 roozhou 发布
M$ RGB输出
MainConcept RGB输出
PicVideo RGB输出
FFDshow那两个和我这里FFmpegSource出来的一样，都是典型的
16-235，
但我的MS RGB输出是这样的。。。也是16-235
为啥你的会是那种介于16-235和0－255之间的一种颜色。。。orz
另外你的MainConcept和PicVideo输出的RGB真的很怪，唯一可以肯定的是0－255，做了YC伸张。其中MainConcept接近这个（为什么你不全截第1帧。。
FFmpegSource("C:\ng1.avi")
SwapFields()
ConvertToRGB32(matrix="rec601")
qyqgpower@2008-06-09 19:35
最终帧下方黑色区域色彩对比
MS （古怪结果）
RGB32
110F11 0F0D0F
PIC no Normalized （错误，过度伸张）
YUY2->VD(601RGB)
000000
PIC no Normalized （错误，过度伸张）
RGB32
000000
PIC assume Normalized （大致正确，matrix待定）
YUY2->VD(601RGB)
101010 0F0F0F
PIC assume Normalized （大致正确，matrix待定）
YUY2->ConvertToRGB32(matrix="rec709")
101010 0F0F0F
PIC assume Normalized （大致正确，matrix未知）
RGB32
101010 0F0F0F
ffdshow （错误，过度伸张）
YV12->VD(601RGB)
000000
ffdshow 601RGB （大致正确，matrix待定）
RGB32
101010 0F0F0F
ffdshow （用不扩张的matrix才能得到正确的RGB，错误）
YUY2->ConvertToRGB32("pc.709")
101010 0F0F0F
最奇怪的两点在于
MS解码器输出的色彩与其他的都不一样，因此完全错误的可能性大
ffdshow在输出YUV系时，与PIC no Normalized输出的色彩是一样的，但强制RGB后又与PIC assume Normalized相同，也就是YUV和RGB的输出策略是不同的
到这里，我感觉最安全的是
PIC assume Normalized输出YV12（这与输出YUY2的结果是一样的，省的再去ConvertToYV12）
su_xinling@2008-06-09 19:39
引用
最初由 qyqgpower 发布
第一：JPEG本身压缩
这是什么概念？
YCbCr->Downsampling->Block splitting->DCT->Quantization->Entropy coding
有哪一步脱离了YUV的基础了？很显然，JPEG的压缩流程与视频压缩是非常相似的
第二，直接对YUV转换的确可以直接从Downsampling这步开始，但你如何确定这个源是从什么格式转换过来的
源是什么格式，当然之前我提到实际实践压制过。譬如就用ffdshow来编码，输入一个YUY2，他不会动这些数据，直接压缩，如果是普通16-235 tv sclae源，这时候ffdshow解码YUV输出就正确，切换到RGB输出变灰=M$解码RGB输出，所以你如果要用后者解码必须用pc scale的YUV来压制。如果源是RGB，当然编码器就要RGB-〉YUV，这时ffdshow采用0-255 pc scale的方式（我是没注意有没有调节开关），所以解码的时候ffdshow rgb输出和M$的就正确，ffdshow的YUV输出伸张过度。另外，我也用picvideo压制，这个编码器有输出方面的pc/tv scale的设定，RGB的输入也可以16-235 tv sclae保存，所以解码的时候要看设置。
另外，注意到ffdshow对mjpeg有特殊处理，在rgb/yuv的输出表现不同，差异就是pc/tv sclae这种所谓yc扩张问题。这和处理mpeg/xvid/h264这些编码的效果不同，后者这些编码rgb输出应该等同YUV。
kzhou@2008-06-09 20:13
PIC no Normalized 和PIC assume Normalized是啥？
另，su xining你说 “FFD RGB输出变灰=M$解码RGB输出”没发现颜色有差别么，特别是刀把的红色
«7891011»共11页
| TOP