8bit to 10bit color green on skin?

[DzeSezMee]

Hi guys.

Can anyone give me a hint why the colors seem to change a bit in my encodings?

https://i.ibb.co/T2jKbD5/8bit-to-10bit-hevc.jpg

https://i.ibb.co/9s7HR4v/8bit-to-10bit-2.jpg

source: left
encoding: right

I am using Handbrake for encoding

Source Media Info

Format/Info : Advanced Video Codec
Format profile : High@L4
Format settings : CABAC / 4 Ref Frames
Format settings, CABAC : Yes
Format settings, Reference frames : 4 frames
Codec ID : V_MPEG4/ISO/AVC
Duration : 1 h 41 min
Bit rate : 5 500 kb/s
Width : 1 920 pixels
Height : 1 080 pixels
Display aspect ratio : 16:9
Frame rate mode : Constant
Frame rate : 24.000 FPS
Color space : YUV
Chroma subsampling : 4:2:0
Bit depth : 8 bits
Scan type : Progressive
Bits/(Pixel*Frame) : 0.111
Stream size : 3.88 GiB (97%)
Writing library : x264 core 155 r2917 0a84d98
Encoding settings : cabac=1 / ref=4 / deblock=1:-1:-1 / analyse=0x3:0x113 / me=hex / subme=8 / psy=1 / psy_rd=1.00:0.15 / mixed_ref=1 / me_range=16 / chroma_me=1 / trellis=2 / 8x8dct=1 / cqm=0 / deadzone=21,11 / fast_pskip=1 / chroma_qp_offset=-3 / threads=12 / lookahead_threads=2 / sliced_threads=0 / nr=0 / decimate=1 / interlaced=0 / bluray_compat=0 / constrained_intra=0 / bframes=3 / b_pyramid=2 / b_adapt=2 / b_bias=0 / direct=3 / weightb=1 / open_gop=0 / weightp=2 / keyint=48 / keyint_min=25 / scenecut=0 / intra_refresh=0 / rc_lookahead=48 / rc=2pass / mbtree=1 / bitrate=5500 / ratetol=1.0 / qcomp=0.60 / qpmin=0 / qpmax=69 / qpstep=4 / cplxblur=20.0 / qblur=0.5 / vbv_maxrate=7699 / vbv_bufsize=11000 / nal_hrd=none / filler=0 / ip_ratio=1.40 / aq=3:1.00
Default : Yes
Forced : No
Color range : Limited
Matrix coefficients : BT.709

my encoding setting

crf=22
main 10
encoder level 4.0
preset slow

qpmax=51:keyint=240:min-keyint=24:bframes=6sy-rd=1.2sy-rdoq=4.00:aq-strength=1.3:aq-motion:b-intra:no-deblock:no-sao:colorprim=1:transfer=1:colormatrix=1:input-depth=10:no-info

[Asmodian]

You seen to have input-depth=10 set but your input is 8 bit?

[Greenhorn]

Do you see any marked differences between the images in this set at https://slow.pics/c/9VvamLy8? I don't, but want to make sure we're on the same page. (Frames from a test video, encoded with standalone x265.)

If you don't-- the problem is presumably somewhere in Handbrake. There's been talk (here, I think?) of ffmpeg (used by Handbrake and many other apps for decoding/encoding) decoding 10-bit content incorrectly in the past; maybe Handbrake's still on an older version?

To parrot Asmodian, don't set input-depth to 10 if you aren't encoding FROM 10-bit. Every version of x264/5 I've used has just silently ignored that option or even crashed when I've set it incorrectly, but if the version Handbrake is using doesn't I could see it being really troublesome.

[Forteen88]

IIRC, the ex x264-developer, DarkShikari, wrote that encoding a 8-bit video source to 10-bit, makes the encodes look better compared to encoding that 8-bit video source to 8-bit.

EDIT: And I mean at the same bitrate!

[charliebaby]

Originally Posted by Forteen88

IIRC, the ex x264-developer, DarkShikari, wrote that encoding a 8-bit video source to 10-bit, makes the encodes look better compared to encoding that 8-bit video source to 8-bit.

that's for sure that going from 8 bit to 10bit is more beautiful :-)

[foxyshadis]

Originally Posted by Forteen88

IIRC, the ex x264-developer, DarkShikari, wrote that encoding a 8-bit video source to 10-bit, makes the encodes look better compared to encoding that 8-bit video source to 8-bit.

EDIT: And I mean at the same bitrate!

10-bit output is inherently better in AVC, for any given bitrate, because of its design decisions. Only true 10+ bit sources benefit from 10-bit encoding in HEVC, although there's also no reason not to use it in many cases, unless you have older hardware that can only decode 8-bit.

But that has nothing to do with misidentifying the input as a completely different format than the one you're feeding.

[RanmaCanada]

Originally Posted by foxyshadis

10-bit output is inherently better in AVC, for any given bitrate, because of its design decisions. Only true 10+ bit sources benefit from 10-bit encoding in HEVC, although there's also no reason not to use it in many cases, unless you have older hardware that can only decode 8-bit.

But that has nothing to do with misidentifying the input as a completely different format than the one you're feeding.

10 bit is fantastic for preventing banding, especially in anime.

[foxyshadis]

Originally Posted by RanmaCanada

10 bit is fantastic for preventing banding, especially in anime.

Yes, any 10+ bit source will be improved, particularly anime. Scene releasers were some of the first to embrace much higher fidelity, even from an 8-bit source. If you process and export entirely in HBD, then it's no longer just 8-bit.

[Selur]

@foxyshadis: shouldn't 8bit content even with HEVC benefit from 10bit encoding at least in regards to avoid banding?

[poisondeathray]

Originally Posted by Selur

shouldn't 8bit content even with HEVC benefit from 10bit encoding at least in regards to avoid banding?

Yes

eg.
Turing 8bit vs. 10bit HEVC . Lighthouses of the Pacific (8bit source)
https://forum.videohelp.com/threads/...ts#post2562122

Originally Posted by K.i.N.G

I've also noticed green tinting when encoding 8bit sources to 10bit.
Even if I convert them to 10bit before feeding it to the encoder..

For the people seeing "green tint" , how are you viewing it? (how is it being converted to RGB for display) . The most common reason is when 10bit YUV => 8bit RGB is not being done properly

[K.i.N.G]

Originally Posted by poisondeathray

For the people seeing "green tint" , how are you viewing it? (how is it being converted to RGB for display) . The most common reason is when 10bit YUV => 8bit RGB is not being done properly

In staxrip's video comparison tool, VLC media player, MPC-HC (both with default video renderer and mad-vr).

[poisondeathray]

Originally Posted by K.i.N.G

I've also noticed green tinting when encoding 8bit sources to 10bit.
Even if I convert them to 10bit before feeding it to the encoder..

Originally Posted by K.i.N.G

In staxrip's video comparison tool, VLC media player, MPC-HC (both with default video renderer and mad-vr).

Post more info: such as what you're doing exactly, what tools and versions used, sample source, sample encode.

[K.i.N.G]

Originally Posted by poisondeathray

Post more info: such as what you're doing exactly, what tools and versions used, sample source, sample encode.

What more is there to say.
EVERY 8bit source I encode to 10bit has this.

I use staxrip to encode (have tried MANY different versions, always the same result). Different versions of x265 (sorry, too much to remember every version I used).

I'm using the vapoutsynth workflow so maybe I should try using avisynth to see if it gives different results.
Even though I'm not processing the source with any filters...

I'm currently using ffms as source so I could try to use a different source type.

I could also try to see of encoding in handbrake or ripbot etc...

But I'm currently too busy... I'll try to post an update later.

[Boulder]

At least if you process things in high bit depth, 10-bit encoding will help compared to 8-bit.

[K.i.N.G]

I've also noticed green tinting when encoding 8bit sources to 10bit.
Even if I convert them to 10bit before feeding it to the encoder..

[charliebaby]

if I can give you some advice, install windows properly and do not install any codec or filter on your computer and throw Handbreak try with another software or on the command line

[benwaggoner]

Try encoding to 10-bit and then reencoding back to 8-bit. If it winds up looking right, that suggests a playback issue instead of an encode/decode issue.

Also, try to get some known-good 10-bit encodes and play them on your machine as well.