x264 10bit编码推广讨论

[mawen1250]

> There have been complaints about how ffmpeg/libav
> converts M-bit to N-bit YUV, e.g. see
> http://forum.doom9.org/showthread.php?t=161915 which
> I've been asked to look into.

Glad to see the doom9 thread ending up here!

FWIW, the problem applies to RGB, as well, not just to YUV.


> The current code in swscale is based on how 8-bit to
> 16-bit YUV conversions have been done earlier - basically
> duplicating each input byte in the output (e.g. 0xf0 -> 0xf0f0,
> 0x65 -> 0x6565). I believe this is the right thing for full
> range content.

Not necessarily. If you upscale like that, smooth gradiants
will not be perfectly smooth, anymore. IMHO, there are three
ways to upscale full range content:

(1) 10bit = 8bit << 2
(2) 10bit = round(8bit * 1023 / 255) (similar to byte duplicating)
(3) 10bit = dither(8bit * 1023 / 255)

Solution (1) keeps gradiants smooth, but loses a bit of
dynamic range. Solution (2) maintains full dynamic range,
but gradiants are not perfectly smooth, anymore. Solution
(3) keep gradiants smooth *and* maintains full dynamic
range. However, if you try to compress (3), compression
efficiency will go down due to the dither noise. Also (3) will
perform slowest, of course.

My personal favorites are either (1) or (3), while swscale
currently does (2).

Furthermore, the chroma channel needs to be scaled
with signed math, to make sure that 8bit 128 gets properly
scaled to 10bit 512. If you use (1), though, signed math
is not necessary.

> As I can see the issues with the current code is mainly:
> 3) Dithering back to the original bit depth may not
> preserve original value.

I don't see 3) as a problem.

> a) What method should be used for conversion?

For limited range content: Simple shifting.
For full range content: Either (1) or (3). See above.

> b) Should we distinguish between limited and full range YUV?

The only way not to would be to use simple shifting everywhere, IMHO.

Best regards, Mathias.

按照madshi的这说法，Full Range的转换有移位和dither(8bit * 1023 / 255)两种选择，前者最简单平滑并且和Limited Range处理方式统一，但就是1021-1023这段消失了。后者也保持了平滑，但是dither后会对编码效率产生影响，dither本身也会消耗资源，这就抵消了一部分使用10bit的编码效率上的优势了。

[histamine]

要看dither算法和原始数据，未必采用dither就一定会降低编码效率

事实上，我在上面修改过的dither算法将LSB全为0的16bit数据转换到10bit，根本不会降低编码效率

对于Full Range，直接采用位移的方法不是很妥当

即使dither造成了编码效率下降，但和8bit编码比起来，我推测还是10bit编码更有优势
我用gradfun3处理片源，输出16bit交给x264 10bit编码，效果仍然比输出8bit交给x264 8bit编码更好

[06_taro]

實際上full range下chroma有unsign/sign的問題……嘛反正limited range對了就行了，我不關心full range

[histamine]

fullrange YUV的源我几乎没碰到过，据说某些数码相机拍出来的可能是fullrange YUV
并且我找到一份IIDC 1394-based Digital Camera Specification，里面提到了fullrange YUV 8bit，U/V范围是-128~127，按十六进制0x00~0xFF保存

还是等大牛们最终解决fullrange的问题算了

[mawen1250]

fullrange YUV的源我几乎没碰到过，据说某些数码相机拍出来的可能是fullrange YUV
并且我找到一份IIDC 1394-based Digital Camera Specification，里面提到了fullrange YUV 8bit，U/V范围是-128~127，按十六进制0x00~0xFF保存

还是等大牛们最终解决fullrange的问题算了

数码相机拍出来的不是RGB吗？似乎没有必要用YUV存储。还是说数码相机的摄像功能？
数码相机一般用的色域是sRGB和Adobe RGB。

[dgwxx]

taro的O16处理tv range输出10bit给x264的话，是否存在over range的问题呢。

Full range的动画也不是没有啊，DEEN的片子、做的不好的里番都有full range的。最近僵尸的BD里的实拍特典就很乱，有的是tv range，有的是full range，必须一一手动判断。僵尸第二季BD我说什么不做了……谁愿意做谁做-v-

[histamine]

数码相机拍出来的不是RGB吗？似乎没有必要用YUV存储。还是说数码相机的摄像功能？
数码相机一般用的色域是sRGB和Adobe RGB。

据说某些数码相机拍出来的可能是fullrange YUV

http://csclab.murraystate.edu/bob.pilgr ... 01.3.2.pdf
IIDC 1394-based Digital Camera Specification这个标准是用在工业用途上的，可以直接看61页和73页

Fullrange YUV的DVD/HDTV/BD动画片源大多是制作时弄错了吧，让我弄就转换到Limited Range YUV绕开这个问题或者将错就错

精力有限，既然已经有人开始着手解决这个问题，我就不纠结了

[dgwxx]

full的片子，如果压制的时候做了YC压缩，播放的时候还要再伸张回来。这样一压缩一伸张难免有质量上的损失。所以僵尸我压的时候保留了原range（当然，开僵尸的时候还没10bit呢）。

[histamine]

能否通过YC压缩输出10bit精度的数据，这样损失会比输出8bit数据小一些

[06_taro]

O16對limited range是正確的，full range仍然錯誤。現在最新的x264-devel的git裡（未發布stable build）已經更正limited range的8->10算法了，不過full range仍然沒改，結果和目前tMod的一樣。