- removed version
--rd-refine causes artifacts
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.
Comments (8)
-
reporter -
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.
-
--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 -
reporter 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.
-
reporter 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.
-
reporter 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.
-
Thanks, closing this now. I'm inclined to think this was more a pre-processing issue (cropping).
-
- changed status to resolved
- Log in to comment