akiduki
核心会员
核心会员
帖子: 32
注册时间: 2010-09-19 22:32

Re: x264 10bit编码推广讨论

histamine 写了:能否这样解释

8bit下数值范围是0-255

16bit下数值范围是0-65535

如果采用左移8位转换,8bit下的255直接左移8位,那么就是65280
于是16bit下65281-65535这段就没有对应的8bit数值了?!

或者说如果采用左移8位转换,原先8bit下0-255的范围转换到16bit则是0-65280?!
x264的做法是左移8+原来的数
a_16 = a_8<<8 + a_8.
所以x264的做法是对的。

不太清楚的是,为什么要做一个error-diffusion的dithering。
然后BT.709的标准:
http://www.itu.int/dms_pubrec/itu-r/rec ... !PDF-E.pdf
histamine
帖子: 85
注册时间: 2010-09-23 20:07

Re: x264 10bit编码推广讨论

这样对于full range的片源转换是正确的

对于limited range的片源:
如果按照x264目前的方法8bit转换到16bit的话(左移8位再加原数值),8bit下Nominal peak对应数值235转换到16bit是60395,再转换到10bit的话是943,不符合BT.709标准中20页上10bit对应Nominal peak 940

如果按照左移8位的转换(如果我没弄错的话,dither系列工具直接输出伪16bit不做其他处理,就等同于左移8位),将8bit转换到16bit,再利用depth.c里面的dither算法转换到10bit

代码: 全选

errors[x] = err = src[x*pitch] - (dst[x*pitch] << lshift) - (dst[x*pitch] >> rshift); \
个人认为应该改成

代码: 全选

errors[x] = err = src[x*pitch] - (dst[x*pitch] << lshift); \
才对

Edit:
之前的发言可能没有表达好,只说了一半
histamine 写了:能否这样解释

8bit下数值范围是0-255

16bit下数值范围是0-65535

如果采用左移8位转换,8bit下的255直接左移8位,那么就是65280
于是16bit下65281-65535这段就没有对应的8bit数值了?!

或者说如果采用左移8位转换,原先8bit下0-255的范围转换到16bit则是0-65280?!
如果采用左移8位再加原数值的转换,8bit下的255直接左移8位再加上255,那么就是65535,与16bit数值上限相等
如果采用左移8位再加原数值的转换,原先8bit下0-255的范围转换到16bit则是0-65535,与16bit数值范围相等

但是这里我忘了一个前提,这是full range的情况
akiduki
核心会员
核心会员
帖子: 32
注册时间: 2010-09-19 22:32

Re: x264 10bit编码推广讨论

错了,940-943出现的地方不是这,是在上面做upconv时候:

代码: 全选

dst[k] = ((src[k] << 8) + src[k]) >> shift;
shift是16-bitdepth,所以是6。
histamine
帖子: 85
注册时间: 2010-09-23 20:07

Re: x264 10bit编码推广讨论

akiduki 写了:错了,940-943出现的地方不是这,是在上面做upconv时候:

代码: 全选

dst[k] = ((src[k] << 8) + src[k]) >> shift;
shift是16-bitdepth,所以是6。
这里我看到了,8bit->16bit->10bit转换就是发生在这里的(我又让巨巨您误会了 {:cat_18}
对于full range时这样转换正确,limited range时这样转换不符合BT.709标准的看法,不知您有什么意见
(关于940-943的问题DS估计也知道了,见http://forum.doom9.org/showthread.php?t=161915&page=3

我所说要改动的地方涉及到16bit->10bit的dither
如果是按照左移8位的方法将8bit转换到16bit(使用dither输出伪16bit交给x264编码),那么16bit->10bit精度转换时,量化前后的误差应该按照(量化前数值-量化后数值左移6位)计算
目前x264的16bit->10bit的dither方法是假定之前8bit->16bit转换是按照左移8位然后加上原数值的方法,所以用了
errors[x] = err = src[x*pitch] - (dst[x*pitch] << lshift) - (dst[x*pitch] >> rshift)的计算方法。

算了,懒得纠结了,不管用哪种方法,产生的误差,我肉眼都察觉不到。
头像
mawen1250
核心会员
核心会员
帖子: 670
注册时间: 2011-07-24 20:33

Re: x264 10bit编码推广讨论

sunyata 写了:http://share.dmhy.org/topics/view/21824 ... -bits.html
出来了出来了,支持一下

--------
有两个问题
一是在妇联那边看到有提到x264 10bit转换颜色错误(http://flsnow.net/bbs/thread-28959-1-1.html,9楼),查了一下还就是几天前提出的,不知道这个问题有没有解决,还是说用顶楼脚本没有影响?
二是10bit下编码质量怎么看?我用顶楼的脚本crf21尝试压了一小段,输出的qp是39,33,37,有点搞不明白
话说妇联那贴,蛇大什么时候插到9楼来了?我之前都没看到过这贴,是我失忆了么?
akiduki
核心会员
核心会员
帖子: 32
注册时间: 2010-09-19 22:32

Re: x264 10bit编码推广讨论

我的意思是,当config成10-bit模式时,我贴的那行直接做的就是8bit->10bit的转换,没有8->16再从16->10这样两步。而那行做的8->10的转换,会让转换出来的nominal peak不符合709的标准。

Update:好吧,我是说不存在涉及到两个函数完成8->10的过程这个问题。那句确实先转成了16然后砍掉最后6bits。

madshi也说了,直接<<2就完事了。
另外,10bit的full range其实完全不存在-_-大部分的YUV色域视频都是limited range的,所以保证full range正确等于0。

那个dither_plane的函数,在输出为10-bit必须要dither down的时候没什么用。
histamine
帖子: 85
注册时间: 2010-09-23 20:07

Re: x264 10bit编码推广讨论

如果我们利用gradfun3输出16bit给x264编码,16bit->10bit的精度转换需要dither时应该采用何种dither方式?
(还是说直接右移6位,损失精度也没关系?
(dither_plane的一个注释是“It has been written in such a way so that if the source has been upconverted using the same algorithm as used in scale_image, dithering down to the source bit depth again is lossless. ”


如果单纯左移8位到16bit(dither系列工具)交给x264编码,16bit->10bit dither转换确实没必要

大大也认为x264目前的8bit->10bit不太妥当?
(不考虑8bit->10bit到底是几步,但确实有不符合标准之处

既然full range 10bit不存在,那么写那段代码的人是否考虑错了?
(scale_image函数,因为注释里写着“This effectively keeps the full color range while also being fast.”
(我很困惑,因为在第8页顶端,您却说“x264的做法是对的”?

对于8bit->10bit的问题,DS似乎也察觉到不对的地方了:
http://forum.doom9.org/showthread.php?t=161915&page=4
这帖子里madshi还指出了即使对于full range,x264目前8bit->10bit转换方式也有不妥当的地方,会产生banding {:cat_18}
上次由 histamine 在 2011-08-06 8:45,总共编辑 6 次。
头像
upyzl
帖子: 446
注册时间: 2010-12-25 18:44
来自: 湘/京
联系: 网站

Re: x264 10bit编码推广讨论

菜鸟想问下

后面的讨论是不是说8bit不经任何avs处理(到16bit),直接扔给10bit的x264编码也没有什么问题?
akiduki
核心会员
核心会员
帖子: 32
注册时间: 2010-09-19 22:32

Re: x264 10bit编码推广讨论

1. 你看清楚,我说的是8->16没有问题。
2. 8->10的转换确实有问题,但和dither_plane没有关系。请你再读一遍dither_plane里面你应用的那句注释。
3. 我不知道avs变相输出16-bit给x264会是什么样的路径,看上去会走dither_plane吧。avs输出16-bit的那个trick我没仔细研究过。再者,16-bit的limited range YUV是什么样的nominal peak可没标准定义。所以这里本身就是个问号。
4. madshi用的是full range RGB,不是YUV,别看错了。
5. madshi提出的banding问题,本身的问题提出就是错的。而且在他推崇的直接左移两位的方法(也是MSDN的方法)中也存在,你自己算下就知道了。
这不奇怪,原本8-bit的unit(1) value差,转换成>8bit后差值应该大于1,而大于1并不等于出现了gradient的增加(banding)。8bit原有的dynamic,提高bitdepth后应该保持(不可能增加,这样就违背信息论了。dithering另当别论。)才对。
就像你考试得了10分中的9分,我得了8.5分;换成百分制后你是90我是85,那你能说换了百分制后我和你之间的分差增大了么?
头像
upyzl
帖子: 446
注册时间: 2010-12-25 18:44
来自: 湘/京
联系: 网站

Re: x264 10bit编码推广讨论

了解了
等libswscale更新好了

目前还是8bit->16bit->10bit相对靠谱些,我用眼睛看到的也没发现什么异常

回到 “视频编码器 / Video encoder discussion”