Sorry, I've said high QP but I've actually meant low QPs. Those tests were made with QP varying from 13 to 43.
On Tue, Nov 7, 2017 at 12:41 AM, Mont3z Claros <mont3z.cla...@gmail.com> wrote: > 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 _______________________________________________ x265-devel mailing list x265-devel@videolan.org https://mailman.videolan.org/listinfo/x265-devel
