如果是gradfun3/dfttest处理就有保留16bit输出的必要，这时遇到一个问题16bit应该如何dither到10bit 也就是说我们利用dither系列工具输出伪16bit交给x264编码，应该采用何种dither方式？ 我觉得这和我们输出的16bit数据的定义有关，16bit数据并不代表数值范围一定是0 ~ (2^16-1)，就像我们可以不使用100分制，而使用偏门的90分制 如果我们假定“x264里左移8位再加上原数值，将8bit转换到16bit”是正确的，正如aki巨巨说的“1. 你看清楚，我说的是8->16没有问题。”，那么按照一般的dither方法进行16bit到10bi...

也就是说按照BT.601和BT.709正确的做法就是左移2位？ dst[k] = ((src[k] << 8) + src[k]) >> shift; 应该改成 dst[k] = ( src[k] << 8 ) >> shift;或者dst[k] = src[k] << 2; 如果是这样的话，我觉得dither算法里面 errors[x] = err = src[x*pitch] - (dst[x*pitch] << lshift) - (dst[x*pitch] >> rshift); 应该改成 errors[x] = err = src[x*pitch] - (dst[x*pitch] <...

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问题，本身的问题...

如果我们利用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. ” 如...

错了，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=...

这样对于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 = sr...

SAPikachu 写了：可能确实是这样，不过没有官方标准的话也很难说哪个公式是正确的吧

确实只能说，写这段代码的人可能是这样考虑的

不过按照BT.709标准的话，这样做似乎是错误的
片源本身就不是full range的

所幸的是如果使用dither系列工具输出16bit交给x264 10bit编码，似乎就不会产生这么大的误差
但是x264/filters/video/depth.c里面的dither算法需要改一下

如果对色彩不是很敏感，个人感觉还是别纠结这个问题了吧

能否这样解释

8bit下数值范围是0-255

16bit下数值范围是0-65535

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

或者说如果采用左移8位转换，原先8bit下0-255的范围转换到16bit则是0-65280？！

tc2mp4是一个perl脚本 源代码： http://forum.doom9.org/showthread.php?p=838384#post838384 基本原理： http://forum.doom9.org/showthread.php?p=839062#post839062 其中第234行，parseTimecodeV1函数中利用正则表达式获取tc v1每行的信息 next unless /(\d+),(\d+),([\d.]+)/; 改成 next unless /(\d+)\s*?,\s*?(\d+)\s*?,\s*?([\d.]+)/; 应该就能识别带有空格的tc v1了 pe...

<Dark_Shikari> stop doing this tp7 <tp7> what? <Dark_Shikari> making 1+ GB 10-bit encodes of 24 minute anime episodes. <tp7> and why should I do that? *Daemon404 readies this flame barrier <Daemon404> his8 <Dark_Shikari> Because the entire point of 10-bit is to improve compression so that people do...