[FFmpeg-devel] [PATCH v2 1/5] avutil/hwcontext_d3d11va: fix the uninitialized texture bindflag

[Soft Works]

> -----Original Message-----
> From: ffmpeg-devel <ffmpeg-devel-bounces at ffmpeg.org> On Behalf Of
> Xiang, Haihao
> Sent: Sunday, May 1, 2022 6:15 AM
> To: ffmpeg-devel at ffmpeg.org
> Subject: Re: [FFmpeg-devel] [PATCH v2 1/5] avutil/hwcontext_d3d11va:
> fix the uninitialized texture bindflag
> 
> On Sat, 2022-04-30 at 13:59 +0000, Soft Works wrote:
> > > -----Original Message-----
> > > From: ffmpeg-devel <ffmpeg-devel-bounces at ffmpeg.org> On Behalf Of
> > > Hendrik Leppkes
> > > Sent: Saturday, April 30, 2022 12:02 AM
> > > To: FFmpeg development discussions and patches <ffmpeg-
> > > devel at ffmpeg.org>
> > > Subject: Re: [FFmpeg-devel] [PATCH v2 1/5]
> avutil/hwcontext_d3d11va:
> > > fix the uninitialized texture bindflag
> > >
> > > On Fri, Apr 29, 2022 at 12:45 PM Tong Wu
> > > <tong1.wu-at-intel.com at ffmpeg.org> wrote:
> > > >
> > > > When uploading rawvideos using d3d11va hardware framecontext,
> the
> > >
> > > bindflag
> > > > is not initialized and will cause creating texture failure. Now
> fix
> > >
> > > it,
> > > > assign it the value of D3D11_BIND_RENDER_TARGET.
> > > >
> > >
> > > As with similar fixes of this nature, this implicit behavior to
> fix
> > > one particular bug does not seem fitting inside the hwcontext
> itself.
> > > There can be a large list of usages of the hwcontext that all
> require
> > > different BindFlags, but we can only define one default - why this
> one
> > > specifically?
> >
> > I agree that this change is not ideal. On one side, it is "safe" in
> a way
> > that a texture is practically unusable for video processing without
> having
> > at least one of the flags (decoder, encoder or render_target),
> > so this wouldn't "hurt" anybody.
> >
> > > So rather:
> > >
> > > Where is the context created?
> >
> > Looking at the command line in the commit message, this is about
> > standalone D3D11 context creation.
> >
> > > Why is a required flag not set there? That would be better,
> because
> > > that knows what flags it needs.
> >
> > There doesn't really exist an appropriate "there". I see two options
> >
> > 1. Add a generic internal device creation parameter to the
> dictionary
> >    in ffmpeg_hw.c like "standalone=1"
> >    (for all devices created via init_hw_device)
> >
> > Some time ago, I had another case where I thought this could be
> useful.
> > Then, this could be used in d3d11va_device_create() to set an
> internal
> > field 'default_bindflags' which would be used as condition in
> > d3d11va_frames_init. The situation would remain similar though, as
> that
> > when the device is used by a decoder (which sets the decoder flag)
> > this needs to override the default.
> >
> > 2. Use a device parameter specific to the D3D11
> > hwcontextD3D11_BIND_RENDER_TARGET
> >
> > This would need to be specified in the command line.
> > Everything else like in #1
> >
> > What do you think?
> 
> There aren't extra parameters for other standalone hwcontext creation.
> May we
> take BindFlags=0 as the default setting and set texDesc.BindFlags to
> D3D11_BIND_RENDER_TARGET directly ?

The ffmpeg cli is not the only way how ffmpeg libs are being used.
That's why we shouldn't make assumptions which might apply when used in 
the context of ffmpeg cli.
I think that's what Hendrik wanted to point out as far as I understood.

Kind regards,
softworkz