[x265] [PATCH] Implementation of low-pass subband dct approximation
Mont3z Claros
mont3z.claro5 at gmail.com
Tue Nov 7 09:41:51 CET 2017
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
-------------- next part --------------
A non-text attachment was scrubbed...
Name: Traffic_2560x1600_30_crop.pdf
Type: application/pdf
Size: 29281 bytes
Desc: not available
URL: <http://mailman.videolan.org/pipermail/x265-devel/attachments/20171107/f879f5f4/attachment-0001.pdf>
More information about the x265-devel
mailing list