1. MulticoreWare Avatar MulticoreWare
  2. mcw
  3. x265_git
  4. Issues

Ghosting/artefacts even with low CRF when compared to x264

Issue #214 new
Florian Friedrich created an issue

Hi all,

This is the fist time I'm posting a bug for anything video-codec related, so I hope I'm able to capture this properly. I'll describe a specific example, because I don't have the knowlege to do it in the abstract.

I just built x265 snapshot 1.8+129-e2e507ffe752 and associated libraries, and I'm using them via the latest build of ffmpeg. (Very simple command line: ffmpeg -i infile.mkv -an -vcodec libx265 -crf 20 outfile.mkv)

Doing a test encode of the first minute of Star Wars Episode IV, with the famous yellow text scrolling against a backdrop of stars, I noticed that as the letters move over those stars, the stars flicker, or even appear to slightly tremble a few pixels back and forth, just before and after the letters (this is particularly visible for the fainter stars). This happens even with very low CRFs; it gets less noticeable for lower CRFs, but is clearly visible at any CRF greater than about 13, and very intense above for CRF>20). By comparison, x264 with CRF=22 gives a perfectly smooth and consistent backdrop of stars. (They fade slightly just before letters obscure them, but this looks to be part of the source, i.e. the yellow letters seem to have a dark halo around them; the stars stay perfectly in place, don't flicker, and the letters pass smoothly over them, using x264).

I'm filing this as a major bug, because it's a case of significant and very easily noticeable lower quality than an older codec that x265 is specifically designed to surpass.

(The "version" drop down in this issue doesn't allow me to select "1.8" ... I'm confused ...)

EDIT: I just tried x265 directly, not via ffmpeg, and the problem still remains. I believe this is different from https://bitbucket.org/multicoreware/x265/issues/169/abnormal-distortion-bug, since none of the workarounds mentioned there apply here, and the issue listed here does get better with very low CRFs, which isn't the case for the issue referenced above.

Comments (27)

  3. Deepthi Nandakumar

    Thanks, can you give us access to the source and encodes you generated. Can you clip out the first minute and we will do our best to reproduce this exactly.

  4. Florian Friedrich reporter

    The source is h.264 with unknown settings: http://tpi.infocide.com/x265test-src.mkv For the examples referenced here I used ffmpeg as described above, but got (visually) exactly the same results when running x265 on a raw YUV file. So: x264 encode with CRF 20: http://tpi.infocide.com/x265test-264-crf20.mkv And: x265 encode with CRF 20: http://tpi.infocide.com/x265test-265-crf20.mp4 (sorry, different container format, but I got the same result with MKV)

    Pay attention, for example, to a star that passes between the "i" and the "o" of the word "period" in the first line from about 3 seconds in. In the orgininal and the x264, it stays steady (there's slight dimming, but the star stays in place); in the x265 file, it flickers very visibly and jumps around noticeably. The effect is still visible even at CRF=15.

  5. Ma0

    I can add 2 samples to this issue.

    1) www.msystem.waw.pl/x265/hd177.y4m Encoded sample with options '-D10 --crf 15 --preset veryslow' www.msystem.waw.pl/x265/hd177vs10.mkv I can't find any options to make this sample watchable.

    2) www.msystem.waw.pl/x265/uhd177.y4m Encoded sample with options '-D10 --crf 15 --preset slower' www.msystem.waw.pl/x265/uhd177sr10.mkv The move is all wrong (vibrates). Encoded sample with options '-D10 --crf 15 --preset veryslow' www.msystem.waw.pl/x265/uhd177vs10.mkv - now it is much better.

    For me the problem is with small object with little contrast. There are wrong decisions about move of this objects and after a while the object is moved in correct place. This is like skipping frames in move.

  6. Former user Account Deleted

    I can agree to this bug, I notice it now often, always a "halo" around people and the background is moving with them. The only way to reduce this effect is to use "grain".

  7. Deepthi Nandakumar

    @Florian,

    Your test case looks like a flickering artifact, caused due to pyscho visual shifting when an I-frame was inserted. What were your scenecut, keyint, open-gop arguments?

  8. Florian Friedrich reporter

    I didn't set those arguments specifically, I just went with the x265 default settings, both when using ffmpeg and when using x265 directly. Also tried it with the latest ffmpeg binaries I could find for Windows last night, and the problem remains very visible at CRF 22 which otherwise gives good image quality. It seems particularly bad when dealing with slightly blurry source material. Flickering is still pretty visible as the yellow text scrolls over some of the fainter stars in the iconic opening sequence of Star Wars.

    Input line was simply: -i .\starwars-test-src.mkv -an -vcodec libx265

    Reported settings were: x265 [info]: HEVC encoder version 1.9 x265 [info]: build info [Windows][GCC 5.2.0][64 bit] 8bit x265 [info]: using cpu capabilities: MMX2 SSE2Fast SSSE3 SSE4.2 AVX AVX2 FMA3 LZCNT BMI2 x265 [info]: Main profile, Level-3 (Main tier) x265 [info]: Thread pool created using 4 threads x265 [info]: frame threads / pool features : 2 / wpp(10 rows) x265 [warning]: Source height < 720p; disabling lookahead-slices x265 [info]: Coding QT: max CU size, min CU size : 64 / 8 x265 [info]: Residual QT: max TU size, max depth : 32 / 1 inter / 1 intra x265 [info]: ME / range / subpel / merge : hex / 57 / 2 / 2 x265 [info]: Keyframe min / max / scenecut : 23 / 250 / 40 x265 [info]: Lookahead / bframes / badapt : 20 / 4 / 2 x265 [info]: b-pyramid / weightp / weightb : 1 / 1 / 0 x265 [info]: References / ref-limit cu / depth : 3 / 1 / 1 x265 [info]: AQ: mode / str / qg-size / cu-tree : 1 / 1.0 / 32 / 1 x265 [info]: Rate Control / qCompress : CRF-20.0 / 0.60 x265 [info]: tools: rd=3 psy-rd=2.00 signhide tmvp strong-intra-smoothing x265 [info]: tools: deblock sao

    So keyframe min = 23; max=250; scenecut=40

  9. preasean

    This is not an I-frame problem, as the example provided by Ma0 only has one single I-frame (all other frames are reference frames) with default settings, but the issue remains. If you look closely (frame by frame), you will see that it always looks like as if the object in question has divided itself into two copies with 50% transparency each where one of them is wrongly at the previous position and the other one has moved correctly.

  10. Florian Friedrich reporter

    I'm not 100% certain the example provided my Ma0 shows what I'm talking about; the video just seems tiny and blurry, so I'm not sure what it demonstrates. Please have a look at the examples from the Star Wars opening sequence I provided above.

  11. Zawibic

    Use the second video example, zoom in (> 200%), watch frame by frame and focus on the fast moving vehicles. Then you will notice an effect similar to your example. The only difference is that in your example, the objects (stars) are standing almost still, while in the example by Ma0 the objects (vehicles) are moving. But the effect (flickering) and the shape of the objects (tiny little dots) are the same. So it's somehow related and fits to your description, but it may well be that the underlining bug is different. It could also be the case that there is a whole series of underlying bugs, and your observation is caused by multiple bugs amplifying each other. (Where some of these bugs are also casing the flickering in the example by Ma0, and some are unique to your flickering issue) So when more examples are provided, the chance that your bug gets fixed increases, even if it's not 100% the same. Also this is about improving x265 for the general case, not just fixing your Star Wars example and forget about everything else.

  13. LigH

    Checked this issue with x265 v1.9+96 using uhd177.y4m (provided by Ma0) as source, each preset, and "-D 10 --crf 15" as documented; in addition, I tested several parameters which should have altered the mini-GOP structure (B-frame bias; B-frame pyramid; weighted P/B frames). Still, there is always a choppy/flickering/inconsistent motion, mainly for the (second-) last vehicle, sometimes for the first as well, most noticeable in the "slower" preset. Archive of a sample result with additional parameters "--qcomp 0.8 --psy-rd 0.3" as recommended by 'littlepox' in the doom9 forum, did not fix the issue either.

  15. fauxreaper

    --no-cutree also works as a workaround. Ghosting is greatly reduced. Can other people test --no-cutree to see if they find improvements on their samples?

  16. Deepthi Nandakumar

    bframes 0 isnt exactly a feasible option.

    Can you test this issue with the no-recursion-skip flag?

  18. Florian Friedrich reporter

    I just did a quick check with the original file I described above, and version 2.0 of the x265 libraries that are used in my current ffmpeg build. With CRF 20 the problem remains as obvious and visible as ever.

    I wonder when this will be fixed, since it simply makes x265 completely unusable in practice.

  20. Hans

    Yeah, too bad that this issue has so little attention by developers. Part of the reason could be that this issue is so rare, and fixing doesn't improve SSIM or any other measure. There is always a strong force to just optimize for numbers.

  21. Florian Friedrich reporter

    Is there any update at all on this!? I reported it well over a year ago, and it still hasn't been addressed. It's not a rare issue at all, and it's so visible in so many situations of any smooth movement over small bright objects (such as the Star Wars title sequence I used for my examples above), as to make x265 simply impossible to use for many real-world scenarios. It's a real show-stopper when using relatively aggressive compression settings.

    Perhaps the developers only care about super high resolution, high quality streams, because it's sexy, but I really hope they haven't given up on their ambitions of achieving top-of-the-class quality in low-bandwith settings as well! -- It's simply astonishing that x265 can't even compete with its predecessor in this area, due to the specific and very obvious flaw pointed out in this bug report.

  22. LigH

    Or maybe they are paid by commercial customers to implement other features for generous bitrates first, and we free users have to spend a little more patience. But I am sure that this issue will be addressed, as it would annoy the commercial customers as well. As far as I see, reports have been detailed enough to be valuable for hunting the reason.

  23. Pradeep Ramachandran Account Deactivated

    We believe that HEVC is equally beneficial at all resolutions and all bitrates and constantly implement features in x265 that target all such scenarios; we're not just focused on the higher end of resolutions and quality. The delay in addressing some of these issues are just because we have more things to work on than the number of hours in a given day :-). And we always accept patches to improve the encoder from anyone who is willing to contribute!

    That said, we have recently updated our lambda tables that has significantly improved the visual quality of our encoder. Could you please try your encodes again on the latest dev tip and report back with updates? Do you still see the ghosting artifacts that are plaguing you?

  24. fauxreaper

    There's still ghosting artifacts with sample on https://mailman.videolan.org/pipermail/x265-devel/2016-May/010350.html with new lambda tables on 8bit.

    With --no-cutree the problem almost vanishes. I think that because of hardsubs, cutree propagates letters' pixels (that's good) but also propagates pixels between the letters (that's probably bad), causing artifacts. A possible solution would be to propagate 2Nx2N blocks only if its 4 NxN subblocks can be safely propagated?

  25. Florian Friedrich reporter

    Pradeep and fauxreaper, thanks for the responses. Sadly, it seems the current version 2.3 of x265 still doesn't seem to resolve this bug. (Download and look at http://tpi.infocide.com/x265test-ver2.3-crf18.mkv) This was compressed with CRF 18, so should be pretty good quality, and nonetheless, at around 4 seconds into the clip, a star that passes between the "i" and the "o" of the word "period" in the first line flickers very visibly, which isn't the case in the source file.

  28. Log in to comment
Assignee
–
Type
bug
Priority
major
Status
new
Component
–
Version
–
Votes
15
Watchers
9