So, flickering artifacts introduced by I frames have been around since MPEG-2, but HEVC exaggerates the flickering.
Give us a couple of days to see if we can come up with a quick and dirty hack in I-frame predictions. On Thu, Mar 10, 2016 at 6:11 PM, Webterminate Catchall < catch...@webterminate.com> wrote: > Thanks for your quick response Deepthi! -- I've now posted more info at > > https://bitbucket.org/multicoreware/x265/issues/214/ghosting-artefacts-even-with-low-crf-when > ... but in case anyone on this list wants to see it, here it is: > > I didn't set many 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 > > > > > > On Wed, Mar 9, 2016 at 12:45 AM, Webterminate Catchall < > catchall at webterminate.com> wrote: > > > Dear all, > > > > What's the relevance of the bug tracker apparently run by Multicoreware > > on bitbucket.org? (https://bitbucket.org/multicoreware/x265/issues) ... > > Is this the central, authoritative bug tracker? Or should I report bugs > > for x265 somewhere else? A while ago I filed this: > > > > > > https://bitbucket.org/multicoreware/x265/issues/214/ghosting-artefacts-even-with-low-crf-when > > ... but it got so little response that I'm wondering whether I've been > > reporting it to some fork or peripheral place that's not relevant for > > the actual development of x265. > > > > Cheers, > > :: Florian > > > > _______________________________________________ > > x265-devel mailing list > > x265-devel at videolan.org > > https://mailman.videolan.org/listinfo/x265-devel > > > > > > -- > Deepthi Nandakumar > Engineering Manager, x265 > Multicoreware, Inc > -------------- next part -------------- > An HTML attachment was scrubbed... > URL: > < > http://mailman.videolan.org/pipermail/x265-devel/attachments/20160309/a3940edc/attachment.html > > > _______________________________________________ > x265-devel mailing list > x265-devel@videolan.org > https://mailman.videolan.org/listinfo/x265-devel > -- Deepthi Nandakumar Engineering Manager, x265 Multicoreware, Inc
_______________________________________________ x265-devel mailing list x265-devel@videolan.org https://mailman.videolan.org/listinfo/x265-devel