From patchwork Tue Apr 18 21:50:52 2023 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 8bit X-Patchwork-Submitter: =?utf-8?b?TsOtY29sYXMgRi4gUi4gQS4gUHJhZG8=?= X-Patchwork-Id: 675479 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by smtp.lore.kernel.org (Postfix) with ESMTP id 7063FC77B75 for ; Tue, 18 Apr 2023 21:51:05 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S233118AbjDRVvE (ORCPT ); Tue, 18 Apr 2023 17:51:04 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:38964 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S232715AbjDRVvD (ORCPT ); Tue, 18 Apr 2023 17:51:03 -0400 Received: from madras.collabora.co.uk (madras.collabora.co.uk [46.235.227.172]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id E2EFB119; Tue, 18 Apr 2023 14:51:01 -0700 (PDT) Received: from notapiano.myfiosgateway.com (zone.collabora.co.uk [167.235.23.81]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (No client certificate requested) (Authenticated sender: nfraprado) by madras.collabora.co.uk (Postfix) with ESMTPSA id 8599B6603206; Tue, 18 Apr 2023 22:50:58 +0100 (BST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=collabora.com; s=mail; t=1681854660; bh=RGjq8g5zSwAVgKk0TGPC1T322t6+hUZkLQBY3DZCsjA=; h=From:To:Cc:Subject:Date:From; b=Br0CFSM/bNNEoa2cmi08w2PcL224kZEvs14SsLrjZDiVhdEyj0BqUKp3AfK19sIlY BUae7lT0Kx8nvK/46VxRjtetrMQA1FsfQFqk2Y7qIjFuDkYMMAY4BcMfbMp+NaJRip jSxSYACVjbo1zKHQBPAMksA51SPcEfdnzMoUUwDKGtXbjQP/zY0DE/guGbz5xjRytL gkFZ8vJ9XWXI2bRtZQ30UySsit0/moqKCeUF1FC8K0WyLVO+1+vqJ1GVvTOWAlopFu mrPowIxJJapDbkbovtst0QIhQ9DgmRRmR9IU0d66a+aZAo1AbC0E18fhAOLB+lePyV LirMr8K+BJeEg== From: =?utf-8?b?TsOtY29sYXMgRi4gUi4gQS4gUHJhZG8=?= To: Hans Verkuil Cc: kernel@collabora.com, AngeloGioacchino Del Regno , =?utf-8?b?TsOtY29sYXMgRi4gUi4gQS4gUHJhZG8=?= , Andrew-CT Chen , Matthias Brugger , Mauro Carvalho Chehab , Tiffany Lin , Yunfei Dong , linux-arm-kernel@lists.infradead.org, linux-kernel@vger.kernel.org, linux-media@vger.kernel.org, linux-mediatek@lists.infradead.org Subject: [PATCH] Revert "media: mediatek: vcodec: Fix bitstream crop information error" Date: Tue, 18 Apr 2023 17:50:52 -0400 Message-Id: <20230418215052.2371755-1-nfraprado@collabora.com> X-Mailer: git-send-email 2.40.0 MIME-Version: 1.0 Precedence: bulk List-ID: X-Mailing-List: linux-media@vger.kernel.org This reverts commit cd61f3c6794bea2b717fe6083ca2ad189db75418. That commit's purpose was to prevent the padding from being decoded when userspace didn't set a selection, relying on the default one. However, as described in the Step 6 of the Initialization procedure for the Memory-to-Memory Stateful Video Encoder Interface [1]: "Set the visible resolution for the stream metadata via VIDIOC_S_SELECTION() on the OUTPUT queue if it is desired to be different than the full OUTPUT resolution." And from the Note: "To avoid encoding the padding, the client needs to explicitly configure this selection target" Hence the behavior in the original commit doesn't follow the interface and needs to be reverted. This fixes the following v4l2-compliance failure observed on mt8192-asurada-spherion: fail: v4l2-test-formats.cpp(924): sel.r.width != fmt.g_width() test VIDIOC_S_FMT: FAIL [1] https://www.kernel.org/doc/html/latest/userspace-api/media/v4l/dev-encoder.html#initialization Signed-off-by: Nícolas F. R. A. Prado --- Hi, With this patch applied, there's only one failure left on mt8192-asurada-spherion: fail: v4l2-test-controls.cpp(1167): node->codec_mask & STATEFUL_ENCODER test VIDIOC_(UN)SUBSCRIBE_EVENT/DQEVENT: FAIL But from the documentation I see that the V4L2_EVENT_EOS for stateful encoder is deprecated behavior, so should the v4l2-compliance test be the one changed to not require this? We're enabling running v4l2-compliance with this driver in KernelCI [2], so after we fix these two remaining issues it should be easy to notice if any failures are introduced. Thanks, Nícolas [2] https://github.com/kernelci/kernelci-core/pull/1889 drivers/media/platform/mediatek/vcodec/mtk_vcodec_enc.c | 8 ++++---- 1 file changed, 4 insertions(+), 4 deletions(-) diff --git a/drivers/media/platform/mediatek/vcodec/mtk_vcodec_enc.c b/drivers/media/platform/mediatek/vcodec/mtk_vcodec_enc.c index db65e77bd373..9ff439a50f53 100644 --- a/drivers/media/platform/mediatek/vcodec/mtk_vcodec_enc.c +++ b/drivers/media/platform/mediatek/vcodec/mtk_vcodec_enc.c @@ -505,13 +505,13 @@ static int vidioc_venc_s_fmt_out(struct file *file, void *priv, f->fmt.pix.pixelformat = fmt->fourcc; } - q_data->visible_width = f->fmt.pix_mp.width; - q_data->visible_height = f->fmt.pix_mp.height; - q_data->fmt = fmt; - ret = vidioc_try_fmt_out(ctx, f, q_data->fmt); + ret = vidioc_try_fmt_out(ctx, f, fmt); if (ret) return ret; + q_data->fmt = fmt; + q_data->visible_width = f->fmt.pix_mp.width; + q_data->visible_height = f->fmt.pix_mp.height; q_data->coded_width = f->fmt.pix_mp.width; q_data->coded_height = f->fmt.pix_mp.height;