From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from ffbox0-bg.mplayerhq.hu (ffbox0-bg.ffmpeg.org [79.124.17.100]) by master.gitmailbox.com (Postfix) with ESMTP id 4E26D47436 for ; Thu, 7 Sep 2023 14:30:11 +0000 (UTC) Received: from [127.0.1.1] (localhost [127.0.0.1]) by ffbox0-bg.mplayerhq.hu (Postfix) with ESMTP id 7F66068C801; Thu, 7 Sep 2023 17:30:09 +0300 (EEST) Received: from mail-oa1-f46.google.com (mail-oa1-f46.google.com [209.85.160.46]) by ffbox0-bg.mplayerhq.hu (Postfix) with ESMTPS id 579F368C6B3 for ; Thu, 7 Sep 2023 17:30:03 +0300 (EEST) Received: by mail-oa1-f46.google.com with SMTP id 586e51a60fabf-1c0fcbf7ae4so815362fac.0 for ; Thu, 07 Sep 2023 07:30:03 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20221208; t=1694097001; x=1694701801; darn=ffmpeg.org; h=content-transfer-encoding:in-reply-to:from:content-language :references:to:subject:user-agent:mime-version:date:message-id:from :to:cc:subject:date:message-id:reply-to; bh=3UVFVuEdljVNOGbxCW6rT8ZpRzMs8aVGTcfWdmuvpwI=; b=Dqe8GAIQ9vuTTda372RcYS87AfWwttFMISqJezWPTl0kekDI+A3STED5GKyI6a2gFN lEGk6lUWgUqTUuz+hvoh162LsEZsGgwdPo9NjZg0ZOrSQCgSjoiU+smIWZAiAOfrgAWu M12isD7tLYEoX1Dbo/3MuOMdpanrLhCw+9wiOYplPCdXmDNCSGWnXe/7nb1+hLFF+cDV M7XfGaRbOs6ZYx+/zyPchESLkoUmwKlrm9MzjZU9PROF4fdxjCb+dEUDSq/P0uf8u6oV hcXScCK5505fnVkyLaF9svQFGB/dBsvr/iytj4HTBU2/cgHcxifRIIfEZHc1BV9q4pjs NJ4g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20221208; t=1694097001; x=1694701801; h=content-transfer-encoding:in-reply-to:from:content-language :references:to:subject:user-agent:mime-version:date:message-id :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=3UVFVuEdljVNOGbxCW6rT8ZpRzMs8aVGTcfWdmuvpwI=; b=LQJS2bLQME/tT2fLl8oura6+CF9n4B5G/KvupyQkz47IrgE7TFMjCU2eDTEd5AGUjQ aq14DA/yJ2ez8Hz1RkYZvZJvlUE15s3oG8mxX2gFEZsx6sxbw3A6pqSzXaEvpzoMQdu3 LJf5WOzqoCZ2WDT3C87iKysLjQCPNFPLw08pko8Y6i21qHKxIK5bU7bi28pjF5TMzGWH K7B4QFfnTb42iWSA2AjmS+oLR24UMc+xNq4kFsR3xjiF0urGowspi/RIZortD6vaVLNv jtoRX8lIsGEDIr6/OYSx3LLtUVXT/zeTfEogdxXg+DTDx+SYbN1b2AtMcAb5V6o1fOJe XsGw== X-Gm-Message-State: AOJu0YxtAVSSW4L6XUjcE5gXLE/BDra7kagDnuFgzBIzgHb8nSEXTFKi wX8S2THcrcHkYqKnRem63pATqwDodgY= X-Google-Smtp-Source: AGHT+IHyI43UcXVCQ4FU3jHTpSsrVmhSt333NeTfWqMCN5p/w/ZOD/JO3Wu/vyIFcji0OT1DaGi9DQ== X-Received: by 2002:a05:6871:78a:b0:1bb:c0ee:5536 with SMTP id o10-20020a056871078a00b001bbc0ee5536mr25719548oap.47.1694097001115; Thu, 07 Sep 2023 07:30:01 -0700 (PDT) Received: from [192.168.0.10] (host197.190-225-105.telecom.net.ar. [190.225.105.197]) by smtp.gmail.com with ESMTPSA id m3-20020a056870a40300b001d53c57b55asm1301549oal.57.2023.09.07.07.29.59 for (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Thu, 07 Sep 2023 07:30:00 -0700 (PDT) Message-ID: <810ca3b7-4da6-1791-95e8-214b428ae9a6@gmail.com> Date: Thu, 7 Sep 2023 11:30:02 -0300 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:102.0) Gecko/20100101 Thunderbird/102.15.0 To: ffmpeg-devel@ffmpeg.org References: <20230907020645.37017-1-jamrial@gmail.com> Content-Language: en-US From: James Almer In-Reply-To: Subject: Re: [FFmpeg-devel] [PATCH] avcodec/av1dec: export pixel format even if no hardware decoder is present X-BeenThere: ffmpeg-devel@ffmpeg.org X-Mailman-Version: 2.1.29 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 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Errors-To: ffmpeg-devel-bounces@ffmpeg.org Sender: "ffmpeg-devel" Archived-At: List-Archive: List-Post: On 9/7/2023 5:06 AM, Andreas Rheinhardt wrote: > James Almer: >> And remove the AVOID_PROBING flag, given it's the last av1 decoder to be tested >> either way. >> This fixes a regression introduced in 1652f2492f88434010053289d946dab6a57e4d58, >> where even if forcing the native av1 decoder, if another decoder was present, >> like libdav1d or libaom-av1, they'd be used for probing and some fate tests >> would have different results. >> >> Signed-off-by: James Almer >> --- >> libavcodec/av1dec.c | 8 ++++---- >> tests/fate/lavf-container.mak | 8 ++++---- >> tests/ref/fate/av1-annexb-demux | 2 +- >> tests/ref/lavf-fate/av1.mkv | 4 ++-- >> tests/ref/lavf-fate/av1.mp4 | 4 ++-- >> 5 files changed, 13 insertions(+), 13 deletions(-) >> >> diff --git a/libavcodec/av1dec.c b/libavcodec/av1dec.c >> index ec8401f4e0..a1e08185a7 100644 >> --- a/libavcodec/av1dec.c >> +++ b/libavcodec/av1dec.c >> @@ -612,6 +612,9 @@ static int get_pixel_format(AVCodecContext *avctx) >> if (ret < 0) >> return ret; >> >> + s->pix_fmt = pix_fmt; >> + avctx->pix_fmt = ret; >> + >> /** >> * check if the HW accel is inited correctly. If not, return un-implemented. >> * Since now the av1 decoder doesn't support native decode, if it will be >> @@ -623,9 +626,6 @@ static int get_pixel_format(AVCodecContext *avctx) >> return AVERROR(ENOSYS); > > Is the log message here actually accurate? The get_format callback > choosing the software pixel format does not mean that the hardware this > is run on or the lavc binary in use do not support hardware accelerated > AV1 decoding. It's not, but that's also unrelated to this patch. > (How is an API user actually supposed to know that decoding will fail if > the software pixel format is selected?) Other than the first returned ENOSYS, nothing. I could make it always return ENOSYS, same as before this patch, but anything we do will probably be hacky unless we add an actual software implementation. _______________________________________________ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-request@ffmpeg.org with subject "unsubscribe".