分页: 11 / 21

Re: x264 10bit编码推广讨论

发表于 : 2011-08-08 18:06
SAPikachu
dgwxx 写了:像AU似的,做成那种无关range的计算不行么……
http://www.nmm-hd.org/bbs/thread-1035-1-1.html
AU是自己的格式所以怎么弄都可以吧,不过10bit就要尽可能符合标准了

Re: x264 10bit编码推广讨论

发表于 : 2011-08-08 21:38
SAPikachu
https://gist.github.com/1131739

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

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

然后x264指定--input-depth 10即可。

Re: x264 10bit编码推广讨论

发表于 : 2011-08-09 1:25
06_taro
修正一下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了……

Re: x264 10bit编码推广讨论

发表于 : 2011-08-09 8:05
SAPikachu
昨晚脚本复制错了囧

Re: x264 10bit编码推广讨论

发表于 : 2011-08-09 8:49
histamine
我是这样修改的,仅针对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}

Re: x264 10bit编码推广讨论

发表于 : 2011-08-09 15:50
mawen1250
Yousei-raws的zeros12390开始柯南剧场版5连发
用了10bit还一本10GB,之前发的剧场版8bit也就7GB,我彻底无语了。

Re: x264 10bit编码推广讨论

发表于 : 2011-08-09 22:37
nuomi
mawen1250 写了:Yousei-raws的zeros12390开始柯南剧场版5连发
用了10bit还一本10GB,之前发的剧场版8bit也就7GB,我彻底无语了。
Yousei-raws總是(?)毫無理由高開碼率,而且有時反而質量還不行。。。

Re: x264 10bit编码推广讨论

发表于 : 2011-08-10 0:54
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一般又用不到直接懒了下不动了 {:cat_18}

Re: x264 10bit编码推广讨论

发表于 : 2011-08-10 5:43
xiao7
mawen1250 写了:Yousei-raws的zeros12390开始柯南剧场版5连发
用了10bit还一本10GB,之前发的剧场版8bit也就7GB,我彻底无语了。
M1的画质比较惨 根据yousei的理念 体积大是很必然的

Re: x264 10bit编码推广讨论

发表于 : 2011-08-10 7:32
264768502
再爆个问题 现在解码端10bit->8bit是用啥? 也是sws吗