Received: by 2002:a25:7ec1:0:0:0:0:0 with SMTP id z184csp4024276ybc; Thu, 14 Nov 2019 19:52:56 -0800 (PST) X-Google-Smtp-Source: APXvYqzbU1837oTuEo9nTyT2rn+h5LQ4M40heWYn+vID+XKuhdnny2K5eCR+K/5mgE1gwPk4YS4p X-Received: by 2002:a17:906:5f81:: with SMTP id a1mr4298729eju.54.1573789975916; Thu, 14 Nov 2019 19:52:55 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1573789975; cv=none; d=google.com; s=arc-20160816; b=FAmmAduxoAZCtZ7maemssESPvqRjQGuz+WkwlRvVjbHM0RmjppyoUDkq8L0fen4SVo 72zMsQtMVyFlhwRD+NUhJSyeYNlMblcR1SjXK/mVncP477QqAprBFW863htYEdO3NLf5 rtydGPZi3a3/ZJhDESEncC3k9/Lwglwh8/vhPbCyRmPsXccB+czoGzvr74bZixHmitoV GTco1MTlEd3c5USWIhtglSrrYZ7wM9L1I3RqSZVMigBgDvTPU9hKeBM0vw3S5bv6CNJa /RR9IE9AX1czQ088/NnSSoOJfPoIeDHbTxIoBDE1U2dy1Ll8VREALbUv8skBhuKNdwmB cpOQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:content-transfer-encoding:mime-version :message-id:date:subject:cc:to:from:dkim-signature; bh=aoHM/+WaO5NdDyBd89fOija9I2bAkO5UR3LO1LNuzn0=; b=KGKVficERtOD05BFktConliCND/hDcik20kqa2BW7edlUmH8uQKYPG5NgKsduh6ojS x6jeSBik6c+rhadzvAm1u+qOVwbyOYGL2BOMS0DHDpbc6Wkn3xf7HEBxnyCbWAuS2GM+ qgDp5SwVu9SoN2ltPb/IQVxvErcDYsHS+VqQlErLPZPTVC/6e0hc2+FlmfUlW27t112+ pmaslMaDYEIt+yBJUoqdmnqveHemvWTpG5njdBuV5wbq1aejdApqwQbTDbB57JuM20Np 4JkJUiCoSmWTTwH+C26y1g1t/CZvxWyBq8rforpH75pvFDEB4GMkU+uinsqoo2difiCk n9+g== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@chromium.org header.s=google header.b=dUOQQA7I; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=chromium.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id q3si4741109eju.242.2019.11.14.19.52.29; Thu, 14 Nov 2019 19:52:55 -0800 (PST) Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; dkim=pass header.i=@chromium.org header.s=google header.b=dUOQQA7I; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=chromium.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1727020AbfKODuV (ORCPT + 99 others); Thu, 14 Nov 2019 22:50:21 -0500 Received: from mail-pl1-f193.google.com ([209.85.214.193]:46841 "EHLO mail-pl1-f193.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726786AbfKODuV (ORCPT ); Thu, 14 Nov 2019 22:50:21 -0500 Received: by mail-pl1-f193.google.com with SMTP id l4so3696200plt.13 for ; Thu, 14 Nov 2019 19:50:20 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=chromium.org; s=google; h=from:to:cc:subject:date:message-id:mime-version :content-transfer-encoding; bh=aoHM/+WaO5NdDyBd89fOija9I2bAkO5UR3LO1LNuzn0=; b=dUOQQA7I7azOiR9oYN73mh4AZ7L7cneL2H8q46OW5PvCuk7dl9oV65Fc+ofLVKwnIi Yy6JeJ10UHl7RfPgdOgzK+SwTxcBqZ8mj79n7+x/AWeshU0dUzIquTqScneSspZhEPoZ pMpJtQLv0TFtdrkZ4M479Zl0/TRTW1wrbrXPs= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:to:cc:subject:date:message-id:mime-version :content-transfer-encoding; bh=aoHM/+WaO5NdDyBd89fOija9I2bAkO5UR3LO1LNuzn0=; b=aDJjMaQNyCjlCjf+j0+iCnZgbPHjvUQ+KCotF5IVR78z21AnGE9Wr3xvwBCmaGSjvW 4Q+wZWIKz93p+0AqE/1DGvrKpKoZCS0aRDhYNcQWQbBrmB6bkNAmzCwjgSpO5OUFH/39 fVS2cR5ZgsBpzgvrGs+IiVR8mnREk4zc+5NiyFss5xzAQ1XLIgy+i8SCxKtB7eqrzWRX 9K+1yktnPKN2Re+mPVwkK0b+tyVb0dQINZCcysE/L+0U9G0z1LQecKHciHfL5yKtvEcy 9XGm/a2BZmkL9hPvDVwqdGcmfv/YuRZZV7HpVOG0cBeClNjhs/Db4cLJsw1XsgK+lbLx glsQ== X-Gm-Message-State: APjAAAWbplegaCbijqRWEyhuNVkrPVnzSitVpFnsYUJnC8RoDNqa+5sn tgD8QEZAF11BpBPbvzjpR9AEBA== X-Received: by 2002:a17:902:6a88:: with SMTP id n8mr452520plk.226.1573789820467; Thu, 14 Nov 2019 19:50:20 -0800 (PST) Received: from acourbot.tok.corp.google.com ([2401:fa00:8f:203:93d9:de4d:e834:3086]) by smtp.gmail.com with ESMTPSA id f7sm9900736pfa.150.2019.11.14.19.50.18 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Thu, 14 Nov 2019 19:50:19 -0800 (PST) From: Alexandre Courbot To: Ezequiel Garcia , Boris Brezillon Cc: linux-media@vger.kernel.org, linux-kernel@vger.kernel.org, Alexandre Courbot Subject: [PATCH] media: hantro: make update_dpb() not leave holes in DPB Date: Fri, 15 Nov 2019 12:50:13 +0900 Message-Id: <20191115035013.145152-1-acourbot@chromium.org> X-Mailer: git-send-email 2.24.0.432.g9d3f5f5b63-goog MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org update_dpb() reorders the DPB entries such as the same frame in two consecutive decoding requests always ends up in the same DPB slot. It first clears all the active flags in the DPB, and then checks whether the active flag is not set to decide whether an entry is a candidate for matching or not. However, this means that unused DPB entries are also candidates for matching, and an unused entry will match if we are testing it against a frame which (TopFieldOrderCount, BottomFieldOrderCount) is (0, 0). As it turns out, this happens for the very first frame of a stream, but it is not a problem as it would be copied to the first entry anyway. More concerning is that after an IDR frame the Top/BottomFieldOrderCount can be reset to 0, and this time update_dpb() will match the IDR frame to the first unused entry of the DPB (and not the entry at index 0 as would be expected) because the first slots will have different values. The Hantro driver is ok with this, but when trying to use the same function for another driver (MT8183) I noticed decoding artefacts caused by this hole in the DPB. Fix this by maintaining a list of DPB slots that are actually in use, instead of relying on the absence of the active flag to do so. This also allows us to optimize matching a bit. Signed-off-by: Alexandre Courbot --- drivers/staging/media/hantro/hantro_h264.c | 18 ++++++++++++------ 1 file changed, 12 insertions(+), 6 deletions(-) diff --git a/drivers/staging/media/hantro/hantro_h264.c b/drivers/staging/media/hantro/hantro_h264.c index 568640eab3a6..2357068b0f82 100644 --- a/drivers/staging/media/hantro/hantro_h264.c +++ b/drivers/staging/media/hantro/hantro_h264.c @@ -474,14 +474,19 @@ static void update_dpb(struct hantro_ctx *ctx) { const struct v4l2_ctrl_h264_decode_params *dec_param; DECLARE_BITMAP(new, ARRAY_SIZE(dec_param->dpb)) = { 0, }; + DECLARE_BITMAP(in_use, ARRAY_SIZE(dec_param->dpb)) = { 0, }; DECLARE_BITMAP(used, ARRAY_SIZE(dec_param->dpb)) = { 0, }; unsigned int i, j; dec_param = ctx->h264_dec.ctrls.decode; - /* Disable all entries by default. */ - for (i = 0; i < ARRAY_SIZE(ctx->h264_dec.dpb); i++) + /* Mark entries in use before disabling them. */ + for (i = 0; i < ARRAY_SIZE(ctx->h264_dec.dpb); i++) { + if (ctx->h264_dec.dpb[i].flags & + V4L2_H264_DPB_ENTRY_FLAG_ACTIVE) + set_bit(i, in_use); ctx->h264_dec.dpb[i].flags &= ~V4L2_H264_DPB_ENTRY_FLAG_ACTIVE; + } /* Try to match new DPB entries with existing ones by their POCs. */ for (i = 0; i < ARRAY_SIZE(dec_param->dpb); i++) { @@ -492,18 +497,19 @@ static void update_dpb(struct hantro_ctx *ctx) /* * To cut off some comparisons, iterate only on target DPB - * entries which are not used yet. + * entries which are already used. */ - for_each_clear_bit(j, used, ARRAY_SIZE(ctx->h264_dec.dpb)) { + for_each_set_bit(j, in_use, ARRAY_SIZE(ctx->h264_dec.dpb)) { struct v4l2_h264_dpb_entry *cdpb; cdpb = &ctx->h264_dec.dpb[j]; - if (cdpb->flags & V4L2_H264_DPB_ENTRY_FLAG_ACTIVE || - !dpb_entry_match(cdpb, ndpb)) + if (!dpb_entry_match(cdpb, ndpb)) continue; *cdpb = *ndpb; set_bit(j, used); + /* Don't reiterate on this one. */ + clear_bit(j, in_use); break; } -- 2.24.0.432.g9d3f5f5b63-goog