--rd-refine causes artifacts

[SI]

I just tested the new --rd-refine option, and it seems to cause some weird artifacts at times. See the area right next to the hand where the gun is. There seems to be a block missing in the encoded file. It's there if --rd-refine is not used.

This was the command line: c:\x265\x265.exe --input - --y4m --input-depth 16 --deblock -1:-1 --rc-lookahead 60 --merange 25 --limit-refs 3 --no-amp --no-sao --ctu 16 --max-tu-size 16 --qg-size 16 --psy-rd 2.0 --psy-rdoq 5.0 --rdoq-level 1 --crf 17 --keyint 480 --sar 160:179 --colormatrix "bt470bg" --colorprim "bt470bg" --transfer "bt470bg" --preset veryslow --output "r:\airwolf_s03e01.hevc"

I've attached screenshots from the original clip (cropped etc. in the Vapoursynth script so it's not directly what you get from the VOB), and a sample video clip. Please let me know if you need a longer clip to analyse.

[Deepthi Nandakumar]

Thanks - rd-refine is an experimental feature, hence the push to dev branch (and not stable).

We're not fully satisfied with the results of rd-refine, and fully expect to make more improvements/fixes in the coming weeks.

[Kavitha Sampath]

--input-depth 16 used above is incorrect and might lead to corrupted bitstream as the video clip seems to be 8bit.
Without using input-depth 16, the missing block couldn't be reproduced at our end using the clip attached

[SI]

The sample clip is cut directly from the VOB to let you analyse things. I'm quite sure I did convert the source to 16 bits before feeding it to x265 but I'll check that when I get to the computer where the Vapoursynth script is.

[SI]

I'm able to reproduce the issue with a Vapoursynth script like this:

import vapoursynth as vs

core = vs.get_core()

clp = core.d2v.Source(r'C:\x265\airwolf.d2v')

clp = core.vivtc.VFM(clp, order=1, chroma=False)

clp = core.vivtc.VDecimate(clp)

clp = core.std.CropRel(clp, left=0, right=12)

clp = core.fmtc.bitdepth(clp, bits=16)

clp.set_output()

It seems that it occurs with that specific cropping, I was not able to catch it for example by cropping 4 pixels from the left and 8 from the right side.

I also tested and the encoder doesn't even begin encoding if I try to feed the clip as 8 bits with input-depth 16.

[SI]

I'm not able to reproduce this with the latest source. Either it was a miscompile by VS2015 or something else commited afterwards has fixed it.

[Deepthi Nandakumar]

Thanks, closing this now. I'm inclined to think this was more a pre-processing issue (cropping).