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 1700C42E49 for ; Wed, 7 Sep 2022 21:57:14 +0000 (UTC) Received: from [127.0.1.1] (localhost [127.0.0.1]) by ffbox0-bg.mplayerhq.hu (Postfix) with ESMTP id 649A668B965; Thu, 8 Sep 2022 00:57:11 +0300 (EEST) Received: from mail-wr1-f54.google.com (mail-wr1-f54.google.com [209.85.221.54]) by ffbox0-bg.mplayerhq.hu (Postfix) with ESMTPS id 46193689DAB for ; Thu, 8 Sep 2022 00:57:05 +0300 (EEST) Received: by mail-wr1-f54.google.com with SMTP id b17so9348518wrq.3 for ; Wed, 07 Sep 2022 14:57:05 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=jkqxz-net.20210112.gappssmtp.com; s=20210112; h=content-transfer-encoding:in-reply-to:from:references:to :content-language:subject:user-agent:mime-version:date:message-id :from:to:cc:subject:date; bh=U0nhn29m3ISOJUFlr4Z4hKI656u+L8fPcIlEYbDorD8=; b=Py3iJYVDAdoFDQO+XEOwL+hfQg9qqauf+hFm4UphiCXLRWEWJixFzl0x/wJhmDSBc8 +ybx3q+J9Ia24gQciuB3q6ADSTDR/+y6yss6gbtXa8KL0ojFjUfQUFmmSyU2cOB7/RiZ dWOWIGGsQ+KTeIeHqp6SZlHxD2o7tJIJ6PtNOZch07zGI2KHAPq71ai1MdemmWT1nWtm +Fn948uaVbeb4O4hZNNQf4yPnoP/dO1su1V/NeWV5g69Di3mUBNtaaZ9v71iqUsaY3fL RkE93AoUebam1WaDwZyazsT7ESsH+sF4L+FRxLk2EOfa2ipa1le94hoo2aqWzBJNwURu 8pcw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=content-transfer-encoding:in-reply-to:from:references:to :content-language:subject:user-agent:mime-version:date:message-id :x-gm-message-state:from:to:cc:subject:date; bh=U0nhn29m3ISOJUFlr4Z4hKI656u+L8fPcIlEYbDorD8=; b=w26PUHC75+GV5c6rfdMxTQFHjmJZ1xq+vRILd0TE79mHGwt9naBzc4ELGyBneXxCPw 7tyg8gKEJg5ULHErXU/Dy41aQWUyqcmlajzrnqYwKqZNAWdb5WNEIZZIlhAtb3L7PGPK v82CAnzJLSMlrU+O9wypVukmUENqkMk378yKVCEJMaQoJGQj8wSUF7bx6k9w7jLzYKcQ xKgHexfWnYCvVsQoEyrNcqD5JaEUQiASvhQDM8gavOigrBRoVNh+qxk0zIxJGizC7n5W AgQVWEriZlUp5pU4HsHo+9cXoHy7r3XensTC8wD1KJRT+vy/64w4OA2Yky/cOwhFS8EJ nw2g== X-Gm-Message-State: ACgBeo1CzPmsATy1Z9P6VhRwCuTOuM0mY1VaZZD1T0v9eDp5DTpMgrp3 mmtIebee5hgJlbIvDdEsDNPojhE6vdPyvA== X-Google-Smtp-Source: AA6agR7dFiDeID5rusAGuZJI6ytyoAiKNFXW3kf1zmhwoU6EYzk9YJbplqsg42t/8erI+CmPMI/wOg== X-Received: by 2002:a05:6000:1c14:b0:226:deb1:d7cc with SMTP id ba20-20020a0560001c1400b00226deb1d7ccmr3362876wrb.494.1662587824500; Wed, 07 Sep 2022 14:57:04 -0700 (PDT) Received: from [192.168.0.14] (cpc91224-cmbg18-2-0-cust209.5-4.cable.virginm.net. [81.106.228.210]) by smtp.gmail.com with ESMTPSA id i18-20020a5d5592000000b0022878c0cc5esm13626832wrv.69.2022.09.07.14.57.03 for (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Wed, 07 Sep 2022 14:57:04 -0700 (PDT) Message-ID: <9599a3fb-8cd4-b2df-366d-bf6257ea63e4@jkqxz.net> Date: Wed, 7 Sep 2022 22:56:37 +0100 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101 Thunderbird/102.1.2 Content-Language: en-US To: ffmpeg-devel@ffmpeg.org References: <20220823081929.413947-1-fei.w.wang@intel.com> <20220823081929.413947-2-fei.w.wang@intel.com> From: Mark Thompson In-Reply-To: <20220823081929.413947-2-fei.w.wang@intel.com> Subject: Re: [FFmpeg-devel] [PATCH v3 2/3] lavc/decode: Add internal surface re-allocate method for hwaccel 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 23/08/2022 09:19, Fei Wang wrote: > From: Linjie Fu > > Add HWACCEL_CAP_INTERNAL_ALLOC flag to indicate hwaccels are able to > re-allocate surface internally through ff_decode_get_hw_frames_ctx. > So that hwaccels don't need to reinitialize all hw related configs > when decode resolution change, just need to re-allocate new surface > by using new resolution. > > Signed-off-by: Linjie Fu > Signed-off-by: Fei Wang > --- > libavcodec/decode.c | 36 ++++++++++++++++++++++++++++++++++++ > libavcodec/hwconfig.h | 1 + > 2 files changed, 37 insertions(+) You can't just not call the user get_format callback and allocate your own surfaces - this breaks direct rendering and other cases where the user wanted to manage the surfaces. This is also missing any check that the hardware decoder supports the stream post-transition - if the decoder does not support the new size (or any other property of the new stream) then this will try to blindly decode it anyway and fail, where previously it would have correctly fallen back to software decoding. None of these patches say what the aim is, but from reading them and seeing that VP9 is the intended target then I am guessing that this is intended to support the case where the stream resizes while still using previous reference frames - is that right? If my guess is correct, I think you should (a) mention that fact in the patches, and (b) target the support at specifically that case, and not try to mess with any other reinit cases. Something like: if you know you are in that case (the decoder itself has this information and could pass it to ff_get_format somehow) and the context supports it (I am still unclear how this support can be determined - the libva documentation is very clear that a context is tied to a particular height/width), then remember the context across the user get_format call and if things match up then re-use it. If for some reason you are in that case but it can't work (e.g. because the new size isn't supported by the hardware), then you need a better error message - the stream is actually broken because most frames are not decodable until you reach another recovery point (since the reference frames are in hardware surfaces so the software decoder can't use them). - Mark _______________________________________________ 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".