[FFmpeg-devel] [RFC] 10-bit H.264 decoding support
Pascal Massimino
pascal.massimino
Mon Nov 1 06:29:21 CET 2010
Jason,
On Sun, Oct 31, 2010 at 11:06 AM, Jason Garrett-Glaser <
darkshikari at gmail.com> wrote:
> Over at x264, we're about to commit a few thousands of lines of asm
> for x264's 10-bit encoding, which will make it about 4.4 times faster
> (fast enough to be usable).
>
> 10-bit (en|de)coding gives the following advantages:
>
> 1. ~15% better compression *of typical 8-bit content*. In terms of
> "where this comes from", this gain is split roughly evenly (at typical
> bitrates) between:
> a. Higher precision output (in reality, this would be dithered down,
> but you'd still get the visual benefit).
> b. Higher precision intermediate values in (en|de)coding a frame.
> c. Higher precision reference frames.
>
care to elaborate here? Higher-precision refs and intermediate values
also mean more residuals (or noisier ones). Aren't they harder-to-code?
Also: how are keyframes (only) doing with 10bits precision? any visible
gain having higher-precision prediction here?
skal
> 2. Almost complete elimination of banding artifacts. See:
> http://kuukunen.net/misc/banddenoise_8bit.png vs
> http://kuukunen.net/misc/banddenoise_10bit.png
>
> And that's without a proper 10-bit dithering function.
>
> 3. AVC Intra support (a rather nice thing to be able to put on the
> features list).
>
> Now we need libavcodec to support this; just having the JM reference
> for a decoder is not very useful! Here's some possible options:
>
> 1. Localize all modifications of pixels to function pointer-accessed
> functions. Add a "pixel size" integer in the context, either 1 or 2,
> used in cases where pixel addresses are calculated (partitions). Make
> "linesize" refer to the number of bytes, not the number of pixels (I
> think this is already true). Then template every single pixel
> function accordingly, and load them on runtime based on the bit depth.
>
> 2. Just template the whole decoder. Slightly faster, but far larger
> binary and potentially a big symbol hassle.
>
> 3. Something else?
>
> Thoughts, comments? Bikesheds not welcome.
>
> Dark Shikari
> _______________________________________________
> ffmpeg-devel mailing list
> ffmpeg-devel at mplayerhq.hu
> https://lists.mplayerhq.hu/mailman/listinfo/ffmpeg-devel
>
More information about the ffmpeg-devel
mailing list