Hi Tom, after I removed the lowpass transformation for the 8x8 blocks it seems that some of my initial assumptions have changed. Please, see the attached pdf with two curves. The first one only has lowpass transformation for 16x16 and 32x32 blocks. The second curve has lowpass for all blocks (8x8,16x16,32x32). In first case it looks reasonable to consider removing the limitations for high QP. I wonder what it's happening... I would expect at least that the performance would be closer for high QPs.
Thanks, Humberto On Mon, Nov 6, 2017 at 5:27 PM, Tom Vaughan <tom.vaug...@multicorewareinc.com> wrote: > Hi Humberto, > We need to understand the effect on performance and encoding efficiency > under different conditions (quality levels - or QPs, performance presets, > and picture sizes). Once we have a better understanding, we can figure out > when to turn it on. It's likely to be something that can help the fastest > presets go faster, where encoding efficiency is less of a priority than > performance. But as you noted, it may also be something that we would only > enable when x265 is using higher QP values. > > I've asked our team to do some experiments, but if you have any date from > your experiments we would love to see it. > > Thanks, > Tom > > -----Original Message----- > From: x265-devel [mailto:x265-devel-boun...@videolan.org] On Behalf Of > Mont3z Claros > Sent: Monday, November 6, 2017 7:28 AM > To: Development for x265 > Subject: Re: [x265] [PATCH] Implementation of low-pass subband dct > approximation > > Hi, > > thanks for you comment and thanks for accepting my contribution. > > I did so many tests using constant QP that I forgot about the other more > important rate-control modes. We could relax this by just ORing it with > limits for those other modes. However I understand that ideally the > application of this transformation is a function of QP and the blocks mean > deviation. I've tried to do this indirectly by fixing the QP's limit and by > using the transformation only on 16x16 and 32x32 blocks. > > I'll try figure out a better way to best add those limitations. > Please, let me know if you can think of anything that might help. > > Humberto > >>> + >>> void setupAliasPrimitives(EncoderPrimitives &p) { #if >>> HIGH_BIT_DEPTH @@ -256,6 +271,11 @@ #endif >>> >>> setupAliasPrimitives(primitives); >>> + >>> + if (param->bLowPassDct && param->rc.qp > 20) >>> + { >>> + enableLowpassDCTPrimitives(primitives); >>> + } >> >> >> Essentially this means that you enable lowpass-dct only when doing >> constant QP encodes. You could consider relaxing this to enable the >> option for other rate-control modes as well (ABR/CRF) and have some >> directives in your docs as to when the feature is better to use. >> Hard-coding the limits in the code isn't a great idea, IMO. >> >>> >>> } >>> >>> x265_report_simd(param); >>> diff -r 6a310b24c6a2 -r 893b36b82133 source/common/primitives.h >>> --- a/source/common/primitives.h Thu Nov 02 12:17:29 2017 +0530 >>> +++ b/source/common/primitives.h Sat Oct 14 09:19:03 2017 -0700 >>> @@ -259,8 +259,12 @@ >>> * primitives will leave 64x64 pointers NULL. Indexed by LumaCU */ >>> struct CU >>> { >>> - dct_t dct; >>> - idct_t idct; >>> + dct_t dct; // active dct transformation >>> + idct_t idct; // active idct transformation >>> + >>> + dct_t standard_dct; // original dct function, used >>> by >>> lowpass_dct >>> + dct_t lowpass_dct; // lowpass dct approximation >>> + >>> calcresidual_t calcresidual; >>> pixel_sub_ps_t sub_ps; >>> pixel_add_ps_t add_ps; >>> diff -r 6a310b24c6a2 -r 893b36b82133 source/x265.h >>> --- a/source/x265.h Thu Nov 02 12:17:29 2017 +0530 >>> +++ b/source/x265.h Sat Oct 14 09:19:03 2017 -0700 >>> @@ -1505,6 +1505,11 @@ >>> >>> /* Disable lookahead */ >>> int bDisableLookahead; >>> + >>> + /* Use low-pass truncated dct approximation >>> + * This DCT approximation is less computational intensive and >>> + gives >>> results close to >>> + * standard DCT for QP >= 23 */ >>> + int bLowPassDct; >>> } x265_param; >>> >>> /* x265_param_alloc: >>> diff -r 6a310b24c6a2 -r 893b36b82133 source/x265cli.h >>> --- a/source/x265cli.h Thu Nov 02 12:17:29 2017 +0530 >>> +++ b/source/x265cli.h Sat Oct 14 09:19:03 2017 -0700 >>> @@ -282,6 +282,7 @@ >>> { "force-flush", required_argument, NULL, 0 }, >>> { "splitrd-skip", no_argument, NULL, 0 }, >>> { "no-splitrd-skip", no_argument, NULL, 0 }, >>> + { "lowpass-dct", no_argument, NULL, 0 }, >>> { 0, 0, 0, 0 }, >>> { 0, 0, 0, 0 }, >>> { 0, 0, 0, 0 }, >>> @@ -543,6 +544,7 @@ >>> H1("-r/--recon <filename> Reconstructed raw image YUV or >>> Y4M output file name\n"); >>> H1(" --recon-depth <integer> Bit-depth of reconstructed raw >>> image file. Defaults to input bit depth, or 8 if Y4M\n"); >>> H1(" --recon-y4m-exec <string> pipe reconstructed frames to >>> Y4M >>> viewer, ex:\"ffplay -i pipe:0 -autoexit\"\n"); >>> + H0(" --lowpass-dct Use low-pass subband dct >>> approximation. Default %s\n", OPT(param->bLowPassDct)); >>> H1("\nExecutable return codes:\n"); >>> H1(" 0 - encode successful\n"); >>> H1(" 1 - unable to parse command line\n"); >>> >>> _______________________________________________ >>> x265-devel mailing list >>> x265-devel@videolan.org >>> https://mailman.videolan.org/listinfo/x265-devel >>> >> >> >> _______________________________________________ >> x265-devel mailing list >> x265-devel@videolan.org >> https://mailman.videolan.org/listinfo/x265-devel >> > _______________________________________________ > x265-devel mailing list > x265-devel@videolan.org > https://mailman.videolan.org/listinfo/x265-devel > _______________________________________________ > x265-devel mailing list > x265-devel@videolan.org > https://mailman.videolan.org/listinfo/x265-devel
Traffic_2560x1600_30_crop.pdf
Description: Adobe PDF document
_______________________________________________ x265-devel mailing list x265-devel@videolan.org https://mailman.videolan.org/listinfo/x265-devel