头像
SAPikachu
帖子: 192
注册时间: 2011-02-28 19:55
联系: 网站

Re: x264 10bit编码推广讨论

dgwxx 写了:像AU似的,做成那种无关range的计算不行么……
http://www.nmm-hd.org/bbs/thread-1035-1-1.html
AU是自己的格式所以怎么弄都可以吧,不过10bit就要尽可能符合标准了
T: @SAPikachu
头像
SAPikachu
帖子: 192
注册时间: 2011-02-28 19:55
联系: 网站

Re: x264 10bit编码推广讨论

https://gist.github.com/1131739

刚才弄了个patch,让x264可以直接使用avs输出的10bit数据,暂时避免x264 dither的问题。

avs的upconv代码改成这样就可以输出10bit数据: 之前脚本有误,请看楼下。。。

然后x264指定--input-depth 10即可。
上次由 SAPikachu 在 2011-08-09 8:18,总共编辑 2 次。
T: @SAPikachu
头像
06_taro
核心会员
核心会员
帖子: 998
注册时间: 2010-09-22 18:32
来自: United Kingdom
联系: 网站

Re: x264 10bit编码推广讨论

修正一下LS的代碼

代码: 全选

Dither_convert_8_to_16()
Dither_lut16("x 6 >>", y=3, u=3, v=3)
Dither_convey_yuv4xxp16_on_yvxx()
然後加--input-depth 10即可。
另外,必須用打過這個patch的x264,原版不行……

廣告:
基於這個直接輸出16bit/10bit的avs函數:
http://www.nmm-hd.org/newbbs/viewtopic.php?f=7&t=325

可以直接配合使用的x264:
http://www.nmm-hd.org/newbbs/viewtopic.php?f=8&t=219

至少這樣就我個人而言可以比較放心地奔向10bit了……
つまんねー事聞くなよ!

I, personally, for me, believe (obviously sometimes) that my OS choice is right. That's me. I'm not telling you that you should believe it. Learn the facts, and the origins behind the facts, and make up your own damn mind. That's why you have one. (source)

Follow me: @06_taro

304——
为纪念伟大的宇宙史上最强压制304先生,联合国教科文组织决定,将每年的第304天,即平年的10月31日或者闰年的10月30日,定为世界304日。
头像
SAPikachu
帖子: 192
注册时间: 2011-02-28 19:55
联系: 网站

Re: x264 10bit编码推广讨论

昨晚脚本复制错了囧
T: @SAPikachu
histamine
帖子: 85
注册时间: 2010-09-23 20:07

Re: x264 10bit编码推广讨论

我是这样修改的,仅针对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 == 1 ) ? 2 : 1;
 }
 
-/* The dithering algorithm is based on Sierra-2-4A error diffusion. 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. */
 #define DITHER_PLANE( pitch ) \
 static void dither_plane_##pitch( pixel *dst, int dst_stride, uint16_t *src, int src_stride, \
                                         int width, int height, int16_t *errors ) \
 { \
     const int lshift = 16-BIT_DEPTH; \
-    const int rshift = 2*BIT_DEPTH-16; \
     const int pixel_max = (1 << BIT_DEPTH)-1; \
     const int half = 1 << (16-BIT_DEPTH); \
     memset( errors, 0, (width+1) * sizeof(int16_t) ); \
@@ -77,7 +72,7 @@ static void dither_plane_##pitch( pixel *dst, int dst_stride, uint16_t *src, int
         { \
             err = err*2 + errors[x] + errors[x+1]; \
             dst[x*pitch] = x264_clip3( (((src[x*pitch]+half)<<2)+err)*pixel_max >> 18, 0, pixel_max ); \
-            errors[x] = err = src[x*pitch] - (dst[x*pitch] << lshift) - (dst[x*pitch] >> rshift); \
+            errors[x] = err = src[x*pitch] - (dst[x*pitch] << lshift); \
         } \
     } \
 }
@@ -112,13 +107,8 @@ static void dither_image( cli_image_t *out, cli_image_t *img, int16_t *error_buf
 
 static void scale_image( cli_image_t *output, cli_image_t *img )
 {
-    /* this function mimics how swscale does upconversion. 8-bit is converted
-     * to 16-bit through left shifting the orginal value with 8 and then adding
-     * the original value to that. This effectively keeps the full color range
-     * while also being fast. for n-bit we basically do the same thing, but we
-     * discard the lower 16-n bits. */
     int csp_mask = img->csp & X264_CSP_MASK;
-    const int shift = 16-BIT_DEPTH;
+    const int shift = BIT_DEPTH-8;
     for( int i = 0; i < img->planes; i++ )
     {
         uint8_t *src = img->plane[i];
@@ -129,7 +119,7 @@ static void scale_image( cli_image_t *output, cli_image_t *img )
         for( int j = 0; j < height; j++ )
         {
             for( int k = 0; k < width; k++ )
-                dst[k] = ((src[k] << 8) + src[k]) >> shift;
+                dst[k] = src[k] << shift;
 
             src += img->stride[i];
             dst += output->stride[i]/2;
diff --git a/input/raw.c b/input/raw.c
index 6d4bb28..1b2b46c 100644
--- a/input/raw.c
+++ b/input/raw.c
@@ -108,14 +108,11 @@ static int read_frame_internal( cli_pic_t *pic, raw_hnd_t *h )
         error |= fread( pic->img.plane[i], pixel_depth, h->plane_size[i], h->fh ) != h->plane_size[i];
         if( h->bit_depth & 7 )
         {
-            /* upconvert non 16bit high depth planes to 16bit using the same
-             * algorithm as used in the depth filter. */
             uint16_t *plane = (uint16_t*)pic->img.plane[i];
             uint64_t pixel_count = h->plane_size[i];
             int lshift = 16 - h->bit_depth;
-            int rshift = 2*h->bit_depth - 16;
             for( uint64_t j = 0; j < pixel_count; j++ )
-                plane[j] = (plane[j] << lshift) + (plane[j] >> rshift);
+                plane[j] = plane[j] << lshift;
         }
     }
     return error;
8bit输入时和16bit(LSB全为0)输入时编码结果,与按照SAPikachu大大的方案修改后avs 10bit输入时是一样的(我对比了下三者的CRC32/MD5)
至少我这样改了后可以放心在OS X下用,或者把我的修改方法和SAPikachu大大的修改方案结合起来也可以 {:cat_16}
头像
nuomi
帖子: 197
注册时间: 2010-09-25 12:59

Re: x264 10bit编码推广讨论

mawen1250 写了:Yousei-raws的zeros12390开始柯南剧场版5连发
用了10bit还一本10GB,之前发的剧场版8bit也就7GB,我彻底无语了。
Yousei-raws總是(?)毫無理由高開碼率,而且有時反而質量還不行。。。
头像
06_taro
核心会员
核心会员
帖子: 998
注册时间: 2010-09-22 18:32
来自: United Kingdom
联系: 网站

Re: x264 10bit编码推广讨论

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一般又用不到直接懒了下不动了 {:cat_18}
つまんねー事聞くなよ!

I, personally, for me, believe (obviously sometimes) that my OS choice is right. That's me. I'm not telling you that you should believe it. Learn the facts, and the origins behind the facts, and make up your own damn mind. That's why you have one. (source)

Follow me: @06_taro

304——
为纪念伟大的宇宙史上最强压制304先生,联合国教科文组织决定,将每年的第304天,即平年的10月31日或者闰年的10月30日,定为世界304日。
头像
xiao7
帖子: 138
注册时间: 2010-09-25 16:16

Re: x264 10bit编码推广讨论

mawen1250 写了:Yousei-raws的zeros12390开始柯南剧场版5连发
用了10bit还一本10GB,之前发的剧场版8bit也就7GB,我彻底无语了。
M1的画质比较惨 根据yousei的理念 体积大是很必然的
264768502
核心会员
核心会员
帖子: 402
注册时间: 2010-09-23 17:38

Re: x264 10bit编码推广讨论

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

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