[x265] [PATCH] Implementation of low-pass subband dct approximation
Mont3z Claros
mont3z.claro5 at gmail.com
Tue Nov 7 10:06:00 CET 2017
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.claro5 at 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.vaughan at 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-bounces at 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 at videolan.org
>>>> https://mailman.videolan.org/listinfo/x265-devel
>>>>
>>>
>>>
>>> _______________________________________________
>>> x265-devel mailing list
>>> x265-devel at videolan.org
>>> https://mailman.videolan.org/listinfo/x265-devel
>>>
>> _______________________________________________
>> x265-devel mailing list
>> x265-devel at videolan.org
>> https://mailman.videolan.org/listinfo/x265-devel
>> _______________________________________________
>> x265-devel mailing list
>> x265-devel at videolan.org
>> https://mailman.videolan.org/listinfo/x265-devel
More information about the x265-devel
mailing list