NMM-HD

06_taro 写了：x264_rev2044+598_tMod-10bit-Fix_Scale_Dither-Limited_Range.7z
改成直接<<shift的转换，和dither的转换一样，在limited range下是正确的了。不过别用在full range上。
其实本来想改成根据fullrange旗标来选择scale/dither方式的，不过访问param->vui->b_fullrange要改的东西不少，反正full range一般又用不到直接懒了下不动了

意思是直接扔8bit的（不做O16这样的处理）也没有关系了？

还有，置顶的是这个么？看样子还没...

264768502 写了：再爆个问题 现在解码端10bit->8bit是用啥? 也是sws吗

LAV Video说是内部做了dither，FFD不知道了……

upyzl 写了： 意思是直接扔8bit的（不做O16这样的处理）也没有关系了？

还有，置顶的是这个么？看样子还没...

是的，这个内部的转换就是<<2，和O16一样，主要是方便给x64版pipe时用8bit的x86 avs输入可以用avs4x264或者ffmpeg -f yuv4mpegpipe这样比较方便的方法的。置顶没加入，因为虽然full range用得少，但是对正式放出的编码器来说最好还是能对full/limited range做出对应正确的处理，所以这个暂时不放置顶，除非勤快下把根据range自适应的给编译出来= =

libswscale里的swscale_unscaled.c也要改一下

有问题的代码应该是下面这几行 能力不足，暂时无法确定libswscale里的dither算法有无问题

x264_rev2059+600_tMod.7z

Scale和Dither在這個新版徹底修完了，full range用x264原有方法做，limited range用正確的移位方法做，順便感謝各位菊苣……

另外avs的upconv和x264内置的upconv/dither速度测试：

i5-430m不开Turbo Burst，704x396的输入，2059+600_tMod-10bit x86版x264，全默认设置，随便编码了500帧，五次取平均值：
O16(10)　　--input-depth 10　　10.44 fps
O16(16)　　--input-depth 16　　11.42 fps
O16()　　　--input-depth 16　　11.44 fps
#不加O16　　--input-depth 8　　11.65 fps

2和3的速度差应该是因为在定义了bitdepth时对bitdepth判定导致的，所以如果输出16bit的话最好直接O16()，不要再O16(16)了，不过即使O16(16)多判定一次还是比O16的v1.1里不判定直接走一次Dither_lut16更快些
当然四个编码结果都是一样的(CRC32/MD5/SHA1)

所以现在这个修正版下应该没有用O16的必要了……

所以现在这个修正版下应该没有用O16的必要了

小白问下
我用的是r2059+600、fix bit depth filter这个版本的X264,
我的AVS里写的是
LanczosResize(1280,720)
直接扔8bit,没做O16等处理，加了 --input-depth 16参数
压制时显示的信息是 avs [info]: 640x720p 0:0 @ 10000000/333667 fps (cfr)
压出来的分辨率是 640x720
如果不加 --input-depth 16参数，则分辨率正常！这个是我的问题还是？求解！

直接8bit 你写--input-depth 16干嘛 你是想做啥

弱弱地问下，10bit编码是怎么实现的

histamine 写了：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; j < length; j++)
478                                 AV_WL16(&dstPtr2[j], (srcPtr[j]<<(dst_depth-8)) |
479                                                      (srcPtr[j]>>(2*8-dst_depth)));
480                         }
481                         dstPtr2 += dstStride[plane]/2;
482                         srcPtr  += srcStride[plane];
483                     }
484                 } else if (src_depth <= dst_depth) {
485                     for (i = 0; i < height; i++) {
486 #define COPY_UP(r,w) \
487     for (j = 0; j < length; j++){ \
488         unsigned int v= r(&srcPtr2[j]);\
489         w(&dstPtr2[j], (v<<(dst_depth-src_depth)) | \
490                        (v>>(2*src_depth-dst_depth)));\
491     }
492                         if(isBE(c->srcFormat)){
493                             if(isBE(c->dstFormat)){
494                                 COPY_UP(AV_RB16, AV_WB16)
495                             } else {
496                                 COPY_UP(AV_RB16, AV_WL16)
497                             }
498                         } else {
499                             if(isBE(c->dstFormat)){
500                                 COPY_UP(AV_RL16, AV_WB16)
501                             } else {
502                                 COPY_UP(AV_RL16, AV_WL16)
503                             }
504                         }
505                         dstPtr2 += dstStride[plane]/2;
506                         srcPtr2 += srcStride[plane]/2;
507                     }
508                 } else {

能力不足，暂时无法确定libswscale里的dither算法有无问题

libswscale已经针对8bit->10bit问题做了一定程度上的修正
http://git.videolan.org/?p=ffmpeg.git;a ... 20cfd19594

From abe0b8e9f378a0f8781c1a3da6714d20cfd19594 Mon Sep 17 00:00:00 2001
From: Michael Niedermayer <michaelni@gmx.at>
Date: Thu, 25 Aug 2011 13:54:43 +0200
Subject: [PATCH] sws: use shift for chroma sample up convertion sws: use
shifts for non full range luma sample upconvertion

Signed-off-by: Michael Niedermayer <michaelni@gmx.at>

有关讨论：
http://thread.gmane.org/gmane.comp.vide ... devel/9285

期待最终解决方案