<div dir="ltr">So, flickering artifacts introduced by I frames have been around since MPEG-2, but HEVC exaggerates the flickering.<div><br></div><div>Give us a couple of days to see if we can come up with a quick and dirty hack in I-frame predictions. </div><div> </div></div><div class="gmail_extra"><br><div class="gmail_quote">On Thu, Mar 10, 2016 at 6:11 PM, Webterminate Catchall <span dir="ltr"><<a href="mailto:catchall@webterminate.com" target="_blank">catchall@webterminate.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Thanks for your quick response Deepthi! -- I've now posted more info at<br>
<a href="https://bitbucket.org/multicoreware/x265/issues/214/ghosting-artefacts-even-with-low-crf-when" rel="noreferrer" target="_blank">https://bitbucket.org/multicoreware/x265/issues/214/ghosting-artefacts-even-with-low-crf-when</a><br>
... but in case anyone on this list wants to see it, here it is:<br>
<br>
I didn't set many arguments specifically, I just went with the x265<br>
default settings, both when using ffmpeg and when using x265 directly.<br>
Also tried it with the latest ffmpeg binaries I could find for Windows<br>
last night, and the problem remains very visible at CRF 22 which<br>
otherwise gives good image quality. It seems particularly bad when<br>
dealing with slightly blurry source material. Flickering is still pretty<br>
visible as the yellow text scrolls over some of the fainter stars in the<br>
iconic opening sequence of Star Wars.<br>
<br>
Input line was simply: -i .\starwars-test-src.mkv -an -vcodec libx265<br>
<br>
Reported settings were:<br>
x265 [info]: HEVC encoder version 1.9<br>
x265 [info]: build info [Windows][GCC 5.2.0][64 bit] 8bit<br>
x265 [info]: using cpu capabilities: MMX2 SSE2Fast SSSE3 SSE4.2 AVX AVX2<br>
FMA3 LZCNT BMI2<br>
x265 [info]: Main profile, Level-3 (Main tier)<br>
x265 [info]: Thread pool created using 4 threads<br>
x265 [info]: frame threads / pool features : 2 / wpp(10 rows)<br>
x265 [warning]: Source height < 720p; disabling lookahead-slices<br>
x265 [info]: Coding QT: max CU size, min CU size : 64 / 8<br>
x265 [info]: Residual QT: max TU size, max depth : 32 / 1 inter / 1 intra<br>
x265 [info]: ME / range / subpel / merge : hex / 57 / 2 / 2<br>
x265 [info]: Keyframe min / max / scenecut : 23 / 250 / 40<br>
x265 [info]: Lookahead / bframes / badapt : 20 / 4 / 2<br>
x265 [info]: b-pyramid / weightp / weightb : 1 / 1 / 0<br>
x265 [info]: References / ref-limit cu / depth : 3 / 1 / 1<br>
x265 [info]: AQ: mode / str / qg-size / cu-tree : 1 / 1.0 / 32 / 1<br>
x265 [info]: Rate Control / qCompress : CRF-20.0 / 0.60<br>
x265 [info]: tools: rd=3 psy-rd=2.00 signhide tmvp strong-intra-smoothing<br>
x265 [info]: tools: deblock sao<br>
<br>
So keyframe min = 23; max=250; scenecut=40<br>
<span class=""><br>
<br>
<br>
<br>
<br>
On Wed, Mar 9, 2016 at 12:45 AM, Webterminate Catchall <<br>
</span><span class="">catchall at <a href="http://webterminate.com" rel="noreferrer" target="_blank">webterminate.com</a>> wrote:<br>
<br>
> Dear all,<br>
><br>
> What's the relevance of the bug tracker apparently run by Multicoreware<br>
> on <a href="http://bitbucket.org" rel="noreferrer" target="_blank">bitbucket.org</a>? (<a href="https://bitbucket.org/multicoreware/x265/issues" rel="noreferrer" target="_blank">https://bitbucket.org/multicoreware/x265/issues</a>) ...<br>
> Is this the central, authoritative bug tracker? Or should I report bugs<br>
> for x265 somewhere else? A while ago I filed this:<br>
><br>
><br>
<a href="https://bitbucket.org/multicoreware/x265/issues/214/ghosting-artefacts-even-with-low-crf-when" rel="noreferrer" target="_blank">https://bitbucket.org/multicoreware/x265/issues/214/ghosting-artefacts-even-with-low-crf-when</a><br>
> ... but it got so little response that I'm wondering whether I've been<br>
> reporting it to some fork or peripheral place that's not relevant for<br>
> the actual development of x265.<br>
><br>
> Cheers,<br>
> :: Florian<br>
><br>
> _______________________________________________<br>
> x265-devel mailing list<br>
</span>> x265-devel at <a href="http://videolan.org" rel="noreferrer" target="_blank">videolan.org</a><br>
<span class="">> <a href="https://mailman.videolan.org/listinfo/x265-devel" rel="noreferrer" target="_blank">https://mailman.videolan.org/listinfo/x265-devel</a><br>
><br>
<br>
<br>
<br>
--<br>
Deepthi Nandakumar<br>
Engineering Manager, x265<br>
Multicoreware, Inc<br>
</span>-------------- next part --------------<br>
An HTML attachment was scrubbed...<br>
URL:<br>
<<a href="http://mailman.videolan.org/pipermail/x265-devel/attachments/20160309/a3940edc/attachment.html" rel="noreferrer" target="_blank">http://mailman.videolan.org/pipermail/x265-devel/attachments/20160309/a3940edc/attachment.html</a>><br>
<div class="HOEnZb"><div class="h5">_______________________________________________<br>
x265-devel mailing list<br>
<a href="mailto:x265-devel@videolan.org">x265-devel@videolan.org</a><br>
<a href="https://mailman.videolan.org/listinfo/x265-devel" rel="noreferrer" target="_blank">https://mailman.videolan.org/listinfo/x265-devel</a><br>
</div></div></blockquote></div><br><br clear="all"><div><br></div>-- <br><div class="gmail_signature"><div dir="ltr"><div><div>Deepthi Nandakumar<br></div>Engineering Manager, x265<br></div>Multicoreware, Inc<br></div></div>
</div>