[x265] [PATCH] Implementation of low-pass subband dct approximation

Mont3z Claros mont3z.claro5 at gmail.com
Wed Nov 8 04:12:47 CET 2017


I believe that the large blocks (16x16 and 32x32) are so low frequency
that the lowpass subband approximation causes only marginal additional
error, even for low QPs.
Perhaps by using a Lagrangian that favors more rate instead of
distortion it might be possible to get large blocks of higher
frequency and this might stress the lowpass dct.

During this experimental phase it might be better just to remove the
QP constrain as it was proposed by Pradeep. I'll submit a new patch
removing it.

Humberto

On Tue, Nov 7, 2017 at 1:06 AM, Mont3z Claros <mont3z.claro5 at gmail.com> wrote:
> 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