2*2 and 4*1 block artefacts in encoded video

[Former user]

x265 v2.3+33commits x265 v2.4+2commits Take a look at selected areas in all snapshots. You can see 22 and 14 black rectangle artefact which was absent in source.

target frame is the very first frame where a pig/cow/animal has been like static image without curves around.

CLI (via AviSynth pipe tool executed in PShell): & 'c:\Program Files (x86)\AviSynth\additional\avs4x265.exe' --x265-binary 'c:\Program Files (x86)\AviSynth\additional\x265_64-10bit[vc12].exe' --preset veryslow --crf 23.2 --crf-max 51 --crf-min 0 --vbv-maxrate 100000 --vbv-bufsize 2000000 --vbv-init 0.99 --qcomp 0.5 --qpstep 100 --rd 4 --ref 6 --bframes 16 --weightb --b-intra --max-merge 5 --subme 7 --tu-intra-depth 4 --tu-inter-depth 4 --limit-tu 0 --limit-refs 0 --no-limit-modes --rskip --no-amp --pools '2' --wpp --no-pme --no-pmode --frame-threads 1 --rc-lookahead 250 --lookahead-slices 0 --ssim --psnr -o "c:\desktop\pph_135_23.2.hevc" c:\desktop\pph.avs

[LiveM]

Hi, that's me - the author of this topic. Sorry for Anonymous account usage.

Thanks, Pradeep! Hi, Kavitha! If you have some questions or any thoughts feel free to ask or share it.

Cause it uses AviSynth frame server to get frames I'll post AviSynth pph.avs script content:

###PREPARE SOURCE###
DSS2("C:\Desktop\pph_source\135.ts", fps=25)
AssumeTFF()

###PROCESS###
ConvertToYV12()

###SEND FRAME TO ENCODER###

So it is just converts 25i to 25p and send to x265.

That video has some kind of 25i. Let's make some terms: -) truly 25i - content has 50 fields per second and each half-frame consists of even or odd fields and each filmed every 1/50 of second - different time moments; -) "falsie" 25i - content has 50 fields per second and each half-frame consists of even or odd fields also but each filmed every 1/25 of second - both even and odd fields filmed in the same time moments. So this is falsie 25i - it is originated from 25p. And AviSynth task is just to combine/put together both fields to get original 25p frames to send progressive frames to encoder.

DSS2 is source filter/loader to read frames from disk and to decode them.

You can see titles of pics files: 2.3+33, 2.4+2 - it is builds of x265 from http://x265.ru/en/builds/ . I use Visual C++ compiled builds cause it's a little bit faster than others in my case of H/W and S/W. I use always 10bit builds.

[Kavitha Sampath]

Hi LiveM, I tried to reproduce the artifact in my end using the avisynth script that you have used. On analysing the target area of the frame, I see that they are not actual artifacts instead it is the effect of quantization on the residuals. For lower QP of the same block, we will see no such black spots and for much higher QP due to very high quantization the error (between actual block and predicted block) gets retained. I am attaching the screenshot of the target area in hevc analyser for different QPs.

[LiveM]

Thank you, Kavitha, for your investigation and report details! Amazing pics attached to show the diffs. And now I saw how that analyzer looks like.

If I understood you in the right way, then this artefact/lack caused by high QP (low bitrate to describe that area properly). CRF increase steps in your investigation shows it.

I do not read your x265 encoder's code and do not know architecture/algorithm of encoding in component details to say that your investigation is not full and to make other-than-QP-reasons ideas to take place. Please have take time to think and discuss it (it = may be it is cause other than QP component lack on some input values or it is other QP-based component lack) inside of your team. So it actually depends on your knowledge of encode process like insider. For me as dabbler it looks like it cause of high QP (I do not know any other dependencies to assume them) but you as insider know the encoding process deeper.

If you know that it is cause exactly low bit rate encoding - well I believe in you as professional and will agree with you - let it be the true reason of that. Then please close this ticket if you decide that diagnostics is finished.

If you have any questions or experiments to do on my side to help you please let me know.

Thanks for cooperation to try to make x265 better!

[LiveM]

Kavitha, small detail: looks like you took later frame in snaps than I mentioned as "target frame is the very first frame where a pig/cow/animal has been like static image without curves around." I to look into your pics: the red border is on frames POC=243, POC=244 but target frame is the first frame there animal is red flatly and perhaps POC=246 in crf=23 snap. But probably it is no matter - I think that later frames should have better quality cause that area becomes almost with no motion, but in that later frames we can see that black pixels group also.