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 371D7428A3 for ; Fri, 6 May 2022 05:38:14 +0000 (UTC) Received: from [127.0.1.1] (localhost [127.0.0.1]) by ffbox0-bg.mplayerhq.hu (Postfix) with ESMTP id 6EC1B68B233; Fri, 6 May 2022 08:38:11 +0300 (EEST) Received: from mail-lf1-f54.google.com (mail-lf1-f54.google.com [209.85.167.54]) by ffbox0-bg.mplayerhq.hu (Postfix) with ESMTPS id 6FCC068B180 for ; Fri, 6 May 2022 08:38:04 +0300 (EEST) Received: by mail-lf1-f54.google.com with SMTP id t25so10792444lfg.7 for ; Thu, 05 May 2022 22:38:04 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=mime-version:references:in-reply-to:from:date:message-id:subject:to; bh=lL5iZlqwZscmEp0wVxtDRxNw/kCVzCV6tpcntgRaTFs=; b=Qtx5wYbAa6bibE2XgS3TQfedoJuPdHTv3tT6s1kjgf1+YH5CeMAGVfohHR81HRi/yh U3RDg8lkTyKsBdsg1o0vPplLffNcFZ3tXbwjTgCxWT82cfPUzR7bMcW/cAyIM32XKcja OYwULopMO+RVdCmq8U8OVwugslk/LuCTLFtZLvdh40EXrVZjwD0TNkSw3GkaAhd3CkHT hkapE49dHWX6Vw+ryuQ9T2U3cCZ/E2N4q5x/CBKjFzrpwS0xKfagSyV8g6YqHQq/+Bzl 2vncnOoATjahA+99+Rnek7FMToanCj1L9QbMFMTfZ3E+xWVMYSRlE/x7ujLtGDTok4dx inKw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to; bh=lL5iZlqwZscmEp0wVxtDRxNw/kCVzCV6tpcntgRaTFs=; b=giNXjxerbJ1Sl43Ejq2j7p5gFIVIF6zh/UpVFlOPMUOJ8kgNiVC0IiL80alNSZigLu 3VLksZ1D7KeIw4x8cSY9wdpxn8X7vgOvt6hzPOBcUug5kiNnkyFnJs5+jsyWOIwV8doV omFm0q7C9ezGN0Wl3vyeOwrUnncVaoeUNZ2EUXUEWaq2KAPmubeW36LmszWmFznwsb/o K+TQg6LFy1AlRFKPAIM6NEK+vniuEwZXtG9hqLPkA4j0JQ3ykNKrAjvuOCoyJZX5oUTe pLoDfZl49iPIDSWfokiYihrwnFwrvfKdbQRtamcDn853mUJdFABvp+08WijKRobObdw/ 4Lrw== X-Gm-Message-State: AOAM5330X/huPzDkYjGdvvZ+Y2FwHpzqi6r4Y057EDC9EG08H+abtoPz no2RpgO37gjZTB+3VKSP1st/Py4cYpxu1h50dtWOxhBZ X-Google-Smtp-Source: ABdhPJzXClumKl0dDt17JvghNN6ViZn0IKsCt6J4+elkuiDcZWathhVoeEUmK693FuUgVW2W9QHuVawRVsSvezhv4tw= X-Received: by 2002:a05:6512:2586:b0:472:6266:4052 with SMTP id bf6-20020a056512258600b0047262664052mr1342711lfb.684.1651815483278; Thu, 05 May 2022 22:38:03 -0700 (PDT) MIME-Version: 1.0 References: <20220429104505.1747-1-tong1.wu@intel.com> In-Reply-To: From: Hendrik Leppkes Date: Fri, 6 May 2022 07:37:51 +0200 Message-ID: To: FFmpeg development discussions and patches Subject: Re: [FFmpeg-devel] [PATCH v2 1/5] avutil/hwcontext_d3d11va: fix the uninitialized texture bindflag 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-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Errors-To: ffmpeg-devel-bounces@ffmpeg.org Sender: "ffmpeg-devel" Archived-At: List-Archive: List-Post: On Fri, May 6, 2022 at 3:11 AM Soft Works wrote: > > > > > -----Original Message----- > > From: ffmpeg-devel On Behalf Of Wu, > > Tong1 > > Sent: Thursday, May 5, 2022 11:50 AM > > To: FFmpeg development discussions and patches > devel@ffmpeg.org> > > Subject: Re: [FFmpeg-devel] [PATCH v2 1/5] avutil/hwcontext_d3d11va: > > fix the uninitialized texture bindflag > > > > > > -----Original Message----- > > > > From: ffmpeg-devel On Behalf Of > > > > Hendrik Leppkes > > > > Sent: Sunday, May 1, 2022 5:54 PM > > > > To: FFmpeg development discussions and patches > > > devel@ffmpeg.org> > > > > Subject: Re: [FFmpeg-devel] [PATCH v2 1/5] > > avutil/hwcontext_d3d11va: > > > > fix the uninitialized texture bindflag > > > > > > > > On Sun, May 1, 2022 at 5:48 PM Hendrik Leppkes > > > > > > wrote: > > > > > > > > > > On Sun, May 1, 2022 at 7:09 AM Soft Works > > > > > > wrote: > > > > > > I think that's what Hendrik wanted to point out as far as I > > > > understood. > > > > > > > > > > > > > > > > Basically, I want explicit behavior, not implicit defaults. > > Anytime > > > > a > > > > > hwcontext is created, something should tell it what its going to > > be > > > > > used for, so we can determine which flags make sense (or > > ideally, it > > > > > should just specify the flags). > > > > > > > > > > This patch creates an implicit default for one use-case, is this > > > > going > > > > > to work with all others? No, of course not, because it has to > > know > > > > > what flags to set. Thats why explicitly setting those flags is > > > > > important, instead of just fixing one implicit case. > > > > > > I said I agree with you - basically, just that we need to > > differentiate between > > > the use case: > > > > > > 1. Use via API > > > => No defaults should be applied, caller is responsible for > > specifying > > > the flags > > > > > > 2. Use via ffmpeg cli > > > => Applying the render target flag would be safe here. > > > We could require this to set via parameter, but there won't > > ever > > > be a case to specify something different than the render > > target flag > > > > > > Why? Let's look at the possible flags: > > > > > > D3D11_BIND_DECODER > > > In all decoding cases, this flag is set explicitly, so it overrides > > any default we > > > would set > > > > > > D3D11_BIND_VIDEO_ENCODER > > > Set explicitly when required, so it overrides any default we would > > set > > > > > > D3D11_BIND_RENDER_TARGET > > > All other cases require this flag (e.g. video processing) > > > > > > No Flag > > > Dead end, texture would be unusable for any kind of video processing > > > > > > > > > > On that note, the example commandline it fixes just does hwupload > > and > > > > nothing else - does that even require render target to be flagged? > > > > From what I can tell it uses a simple > > > > ID3D11DeviceContext::CopySubresourceRegion to copy from the > > staging > > > > texture, which should not require any particular bind flags. Bind > > > > Flags in turn would then depend on what you are actually trying to > > do > > > > with the texture (shader input, etc), in this example... nothing? > > > > > > We are still in the context of ffmpeg cli - you know that there are > > no shaders > > > or 3d operations and no etc. > > > > > > But at this point, you can derive to another context or you can > > hwmap. > > > For all of those things, you need D3D11_BIND_RENDER_TARGET. > > > > > > > > > Summary > > > > > > As mentioned I see two possibilities: > > > > > > 1. Use D3D11_BIND_RENDER_TARGET as a default when used in context of > > > ffmpeg cli, otherwise no default flags > > > > > > 2. Require a device initialization parameter in the command line > > > (but it would always be about setting the render target flag > > > and there's no case where you would NOT want to set it) > > > > > > > Thanks for the possible solutions for this issue. The No.1 seems more > > reasonable because > > No.2 just seems more unnecessary. But I will still need to find a > > better place to set the flag. > > I would favor #1 as well. > > Regarding "better place to set the flag": > > The BindFlag needs to be set when initializing a FRAMES context. > But at this point, there's no way to determine whether the code is running > in an ffmpeg cli process or used by an API consumer. > > But there would be an opportunity to convey this information on > device init. The device (D3D11VA) could then set an internal flag > from device init and use this on frames init to determine which default > to use for the BindFlags value. > > Remains the question how ffmpeg cli can convey this information to > the device (for use during device init). > > What I thought would be to have ffmpeg.c (or rather ffmpeg_hw.c) > to ALWAYS (for all hwaccels) add an entry to the options dictionary, > something like "cli" or similar. > This would avoid introducing a "special-case" mechanism just for > this case (=> by making it a common behavior). > > There are other cases where this might be useful in order to > discriminate API usage from cli usage. > > But let's see what the others think first.. > Think of the CLI applications as an API user, and design for that, because thats really what they are, and thats how you actually end up with a good API that covers more cases. If special CLI logic is needed, it should be in the CLI applications, and not in the libraries. - Hendrik _______________________________________________ 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".