libswscale里的swscale_unscaled.c也要改一下 有问题的代码应该是下面这几行 470 } else if (src_depth == 8) { 471 for (i = 0; i < height; i++) { 472 if(isBE(c->dstFormat)){ 473 for (j = 0; j < length; j++) 474 AV_WB16(&dstPtr2[j], (srcPtr[j]<<(dst_depth-8)) | 475 (srcPtr[j]>>(2*8-dst_depth))); 476 } else { 477 for (j = 0...

LoadPlugin("D:\MeGUI_2028_x86\tools\ffms\ffms2.dll") FFVideoSource("G:\Downloads2\[ANK-Raws] Ao no Exorcist - Vol.1 (BDrip 1920x1080 x264 FLAC)\[ANK-Raws] Ao no Exorcist - 02 (BDrip 1920x1080 x264 FLAC).mkv").AssumeFPS(24000,1001) LoadPlugin("D:\dither-1.9.5\dither.dll"...

我是这样修改的，仅针对Limited Range片源 diff --git a/filters/video/depth.c b/filters/video/depth.c index 25dde25..ac1a9c7 100644 --- a/filters/video/depth.c +++ b/filters/video/depth.c @@ -57,16 +57,11 @@ static int csp_num_interleaved( int csp, int plane ) return ( csp_mask == X264_CSP_NV12 && plane == ...

histamine 写了：现在我开始认为
dst[x*pitch] = x264_clip3( (((src[x*pitch]+half)<<2)+err)*pixel_max >> 18, 0, pixel_max );
这行也有问题，为什么要“ *pixel_max >> 18 ”，改成“ >> 8 ”行吗？

验证了一下，这个改法是有问题的（仅指“ *pixel_max >> 18 ”改成“ >> 8 ”），所以可以无视我说的这段话（关于“ *pixel_max >> 18 ”改成“ >> 8 ”的那段话）

06_taro 写了：应该直接给avs写一个O10的function……

求思路

好吧，我想到一个思路
先计算出10bit数据，然后左移6位到16bit，输出给x264，在x264内部右移6位，得到我们之前计算出来的10bit数据

这样就避免了由于我们对“dither”理解不同引发的一系列问题

现在我开始认为
dst[x*pitch] = x264_clip3( (((src[x*pitch]+half)<<2)+err)*pixel_max >> 18, 0, pixel_max );
这行也有问题，为什么要“ *pixel_max >> 18 ”，改成“ >> 8 ”行吗？似乎这样改是错的啊

或者说我们其实根本不该用目前x264里面的dither算法，应该自己再写一个？
（如果做了上面两处修改之后，和修改之前的dither算法就不一样了）

好吧，我再做一点补充 对于Dither_convert_8_to_16().Dither_convey_yuv4xxp16_on_yvxx()输出的16bit，LSB全是0，这是一个特殊的情况，也就是说不管是直接右移6位还是使用error diffusion dither方法转换到10bit均不会产生精度损失，也不会产生banding，两者结果应该是一致的（或者说两者应该是等价的？） 现在看一下x264里面的dither算法 65 #define DITHER_PLANE( pitch ) \ 66 static void dither_plane_##pitch( pixel *dst, i...

LZ可以试着利用这几个函数 http://avisynth.org/mediawiki/ShowBlue ShowAlpha(clip clip, string pixel_type) ShowBlue(clip clip, string pixel_type) ShowGreen(clip clip, string pixel_type) ShowRed(clip clip, string pixel_type) http://avisynth.org/mediawiki/MergeRGB MergeARGB(clip clipA, clip clipR, clip clipG, clip ...

一个简单粗暴的方法，来验证16bit输入时x264有否调用dither_plane函数 也就是软件debug时最简单也最实用的printf大法 在depth.c里面添加 #include <stdio.h> 在get_frame函数中 148 if( h->bit_depth < 16 && output->img.csp & X264_CSP_HIGH_DEPTH ) 149 { 150 printf("dithering!\n"); //添加此句 151 dither_image( &h->buffer.img, &output-...

我自始至终都怀疑从dither_plane的这个函数实际使用时没有调用，这个函数是为了降回输入bitdepth用的（注释上也说了）。如果直接输出10bit，用的就是我早先贴的那句。 但是x264是支持16bit输入的，这时16bit->10bit用的并不是 dst[k] = ((src[k] << 8) + src[k]) >> shift; 这句的吧 如果没有调用到dither_plane函数，那么我们利用dither系列工具输出伪16bit时x264内部走了怎么样的路径？ 注意这时候我们已经指定了--input-depth 16 我们能保证这个路径是正确的吗？ 在前面的帖子里你自己也比较...