[x265] Bitbucket / Multicoreware bug tracker relevance?

[Deepthi Nandakumar]

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 <
catchall at 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 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/20160310/59019f91/attachment.html>