On Tue, Jan 19, 2021 at 9:24 AM Niranjan Bala <niran...@multicorewareinc.com>
wrote:
> From c0947ffa313365f68f85b1f988e0521327d71a75 Mon Sep 17 00:00:00 2001
> From: Niranjan <niran...@multicorewareinc.com>
> Date: Wed, 13 Jan 2021 20:27:02 +0530
> Subject: [PATCH] Fix: Access violation when aqMode=0 + qgSize=8
>
> ---
> source/common/lowres.cpp | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/source/common/lowres.cpp b/source/common/lowres.cpp
> index 578981d64..334640ec9 100644
> --- a/source/common/lowres.cpp
> +++ b/source/common/lowres.cpp
> @@ -73,7 +73,7 @@ bool Lowres::create(x265_param* param, PicYuv *origPic,
> uint32_t qgSize)
>
> size_t planesize = lumaStride * (lines + 2 * origPic->m_lumaMarginY);
> size_t padoffset = lumaStride * origPic->m_lumaMarginY +
> origPic->m_lumaMarginX;
> - if (!!param->rc.aqMode || !!param->rc.hevcAq || !!param->bAQMotion)
> + if (!!param->rc.aqMode || !!param->rc.hevcAq || !!param->bAQMotion ||
> !!param->bEnableWeightedPred || !!param->bEnableWeightedBiPred)
> {
>
[AM] The right fix for this issue would be to disable aq offset computation
if aq-mode=0 and no-cutree is specified or to handle
curFrame->m_lowres.wp_ssd computation outside calcAdaptiveQuantFrame().
Please revisit the code and see if this unwanted memory allocation per
frame can be avoided.
> CHECKED_MALLOC_ZERO(qpAqOffset, double, cuCountFullRes);
> CHECKED_MALLOC_ZERO(invQscaleFactor, int, cuCountFullRes);
> --
> 2.18.0.windows.1
>
>
> --
>
> Thanks & Regards
> *Niranjan Kumar B*
> Video Codec Engineer
> Media & AI Analytics
> +91 958 511 1449
> <https://multicorewareinc.com/>
> _______________________________________________
> x265-devel mailing list
> x265-devel@videolan.org
> https://mailman.videolan.org/listinfo/x265-devel
>
--
Regards,
*Aruna Matheswaran,*
Video Codec Engineer,
Media & AI analytics BU,
_______________________________________________
x265-devel mailing list
x265-devel@videolan.org
https://mailman.videolan.org/listinfo/x265-devel
