From patchwork Fri Nov 24 18:24:13 2017 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Philip Langdale X-Patchwork-Id: 6339 Delivered-To: ffmpegpatchwork@gmail.com Received: by 10.2.161.94 with SMTP id m30csp2532809jah; Fri, 24 Nov 2017 10:30:05 -0800 (PST) X-Google-Smtp-Source: AGs4zMaCC1IswoW0idcAyUhzhR7VlwpaJFu9dKEtJ2HHYHIxshHLuSSryNRU8o9jY45DXig6uqps X-Received: by 10.223.132.101 with SMTP id 92mr24732870wrf.85.1511548204979; Fri, 24 Nov 2017 10:30:04 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1511548204; cv=none; d=google.com; s=arc-20160816; b=jH5m/qf17grbnlOc9ERWbK7iS4ZYDwS0aFD/1NzWCW3cencuyU5BFHlzCssExyr3An l5UXH+JLjZszfFRZLlQEmMUvqEDj4t+uqIA6ZCeIysG25sn6sdUwf/wMn93lN+GQITg5 hqxq773ImCfeArGri3MMC33sDDBiGtAtBiy8X8F8BWPFme/ZU+DjbKtRgJpmtJdTu15M s25hCnUfoJANZ/CAkf2BDtt7OrXahKf2n92jVrGrpjQHj+4ckl/YsnwbMGnS3mmJendA znPINO3HH2oNdFAFegBPodUpjFOFZfOptfonbioDtzeLHYP7g54pPaeeQKlET5Euwli0 pnUQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=sender:errors-to:content-transfer-encoding:mime-version:cc:reply-to :list-subscribe:list-help:list-post:list-archive:list-unsubscribe :list-id:precedence:subject:message-id:date:to:from:dkim-signature :delivered-to:arc-authentication-results; bh=SRV14AquqoLMIi3VxFYL6nMszLLZhBBM/s4obd2DvBs=; b=ZuEWGQhfWtMmWvOoTX/4v5WNyW0YTtJ+LqazDkqTZgc8kQrepRgDSJXRExUXWWiRqI nwEPJSq2Axb6KUvJKksRYPl7d5WryK073rPdasvTuG6S/WNXbbiYP0CoazFEwBYClWX+ dHyodJcsDOjJY2Y0nC3sDQ+/862UnL13AunkqTuv+WhbO7VTwIySUisGWFKWxn4zVTBp qJL6Ost++zJZyA5gDxwaR0jUQ+8xbvcGAR3YjfkcJ20e4TlwU3H0G+ANba98XZkeMoV8 GCnTYwDH6B3BtFC1AsTAECfH0SKEpmlwpKpnt78/WpJJBcbftMP8GR+vRxu2Vl0xDK7z 6UQA== ARC-Authentication-Results: i=1; mx.google.com; dkim=neutral (body hash did not verify) header.i=@overt.org header.s=mail header.b=jycIbvPp; spf=pass (google.com: domain of ffmpeg-devel-bounces@ffmpeg.org designates 79.124.17.100 as permitted sender) smtp.mailfrom=ffmpeg-devel-bounces@ffmpeg.org Return-Path: Received: from ffbox0-bg.mplayerhq.hu (ffbox0-bg.ffmpeg.org. [79.124.17.100]) by mx.google.com with ESMTP id m5si17165963wrb.75.2017.11.24.10.30.04; Fri, 24 Nov 2017 10:30:04 -0800 (PST) Received-SPF: pass (google.com: domain of ffmpeg-devel-bounces@ffmpeg.org designates 79.124.17.100 as permitted sender) client-ip=79.124.17.100; Authentication-Results: mx.google.com; dkim=neutral (body hash did not verify) header.i=@overt.org header.s=mail header.b=jycIbvPp; spf=pass (google.com: domain of ffmpeg-devel-bounces@ffmpeg.org designates 79.124.17.100 as permitted sender) smtp.mailfrom=ffmpeg-devel-bounces@ffmpeg.org Received: from [127.0.1.1] (localhost [127.0.0.1]) by ffbox0-bg.mplayerhq.hu (Postfix) with ESMTP id 746F868A1EA; Fri, 24 Nov 2017 20:30:02 +0200 (EET) X-Original-To: ffmpeg-devel@ffmpeg.org Delivered-To: ffmpeg-devel@ffmpeg.org Received: from mail-io0-f227.google.com (mail-io0-f227.google.com [209.85.223.227]) by ffbox0-bg.mplayerhq.hu (Postfix) with ESMTPS id 26F2A689E18 for ; Fri, 24 Nov 2017 20:29:56 +0200 (EET) Received: by mail-io0-f227.google.com with SMTP id z74so30348353iof.12 for ; Fri, 24 Nov 2017 10:29:57 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:dkim-signature:from:to:cc:subject:date :message-id; bh=rF13EryAFXd/8/EOqPzgkVB3OUrVsIFMx0Sqbc7073o=; b=RW5TQpp5wEHpUPP+EwADmsR5qBlOoOQE+ttvASbmy6+9eNUk6OYqMizSbr0ZkYbUk+ WA+NutqpMrA/isk7BXYpeS7qYBcM5Cv4AQ0KL8o1b85UkYX5Id8m9T+1Rbcg4NF2q4GR ykm46oJGYf+yi5LCHeN9Y/qVMK/xOAlEe7SHXlzakHVgsOb6qZSIK96B3EYCfklE5/Fw 82KnFNPhdAV7tQalIUnFNQGoMG8PQnqdYhIT0IEiUTPKMfVx0asWECLT9YnKBJdAD2jI bthlUcxZz+IXlhBPOZKsllAsp9FotoLN5d6kwwPfqQaPGWMZoGHor99kCvjTt2e+vTrs OHuA== X-Gm-Message-State: AJaThX7XgMt4XtRTwKSoN5HylWn4V362hj23zNQMYFIfSuNbOdUF4pU2 8/akXwRzQQSgU1x/7/xUwJNkCATJfLlmP3C4O9rO6vVH20femg== X-Received: by 10.107.191.6 with SMTP id p6mr9797402iof.278.1511547870815; Fri, 24 Nov 2017 10:24:30 -0800 (PST) Received: from mail.overt.org (155.208.178.107.bc.googleusercontent.com. [107.178.208.155]) by smtp-relay.gmail.com with ESMTPS id d14sm2987343iti.2.2017.11.24.10.24.30 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 24 Nov 2017 10:24:30 -0800 (PST) X-Relaying-Domain: gapps.overt.org Received: from authenticated-user (mail.overt.org [107.178.208.155]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by mail.overt.org (Postfix) with ESMTPSA id 4BAFB605CB; Fri, 24 Nov 2017 18:24:30 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=overt.org; s=mail; t=1511547870; bh=L9sI4HVoh9Nu3mCHeEwZZVe2rSsjAeI7/m3FMeJUsGY=; h=From:To:Cc:Subject:Date:From; b=jycIbvPpPsNOoN+m2gvDygyRR8P95jKDSWuRFxL5IUYUU4Yy93K+PdTLIIwe1j54H 0zFt/3U1QqiGhA/SSZxLP6sHTw9dzIOwvmLRJgikzlxEc5Le/hfpvBWwLC9Y6cAObU p9NGAk0Xec8CG78s0+zdQ4NLrWFh71vcWQyV+Ifel1iB+JRDz3orNKAHtNzVo3eKkd kLBVAmNE/PLXOFvzdJIRlN1QcGvBmwM7ogK4lntA9drdjVuuKhcxeLvlFn2tt2vWyl uFi2KwlxiYJhGQMO94cLDW6bGxUBSDIBFttkgMTMFw3KNdjjojAvE4TDqcj0mJlE1q 7sfdsYRlvD5Aw== From: Philip Langdale To: ffmpeg-devel@ffmpeg.org Date: Fri, 24 Nov 2017 10:24:13 -0800 Message-Id: <20171124182413.20535-1-philipl@overt.org> Subject: [FFmpeg-devel] [PATCH] avcodec/nvdec: Round up odd width/height values X-BeenThere: ffmpeg-devel@ffmpeg.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: FFmpeg development discussions and patches List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Reply-To: FFmpeg development discussions and patches Cc: Philip Langdale MIME-Version: 1.0 Errors-To: ffmpeg-devel-bounces@ffmpeg.org Sender: "ffmpeg-devel" nvdec will not produce odd width/height output, and while this is basically never an issue with most codecs, due to internal alignment requirements, you can get odd sized jpegs. If an odd-sized jpb is encountered, nvdec will actually round down internally and produce output that is slightly smaller. This isn't the end of the world, as long as you know the output size doesn't match the original image resolution. However, with an hwaccel, we don't know. The decoder controls the reported output size and the hwaccel cannot change it. I was able to trigger an error in mpv where it tries to copy the output surface as part of rendering and triggers a cuda error because cuda knows the output frame is smaller than expected. To fix this, we can round up the configured width/height passed to nvdec so that the frames are always at least as large as the decoder's reported size, and data can be copied out safely. In this particular jpeg case, you end up with a blank (green) line at the bottom due to nvdec refusing to decode the last line, but the behaviour matches cuviddec, so it's as good as you're going to get. Signed-off-by: Philip Langdale --- libavcodec/nvdec.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/libavcodec/nvdec.c b/libavcodec/nvdec.c index 206429c603..dc7badc4d9 100644 --- a/libavcodec/nvdec.c +++ b/libavcodec/nvdec.c @@ -534,8 +534,8 @@ int ff_nvdec_frame_params(AVCodecContext *avctx, } frames_ctx->format = AV_PIX_FMT_CUDA; - frames_ctx->width = avctx->coded_width; - frames_ctx->height = avctx->coded_height; + frames_ctx->width = (avctx->coded_width + 1) & ~1; + frames_ctx->height = (avctx->coded_height + 1) & ~1; frames_ctx->initial_pool_size = dpb_size; switch (sw_desc->comp[0].depth) {