[FFmpeg-devel] [RFC] d3dva security hw+threads

[Soft Works]

> -----Original Message-----
> From: ffmpeg-devel <ffmpeg-devel-bounces at ffmpeg.org> On Behalf Of
> Anton Khirnov
> Sent: Monday, September 5, 2022 7:59 AM
> To: FFmpeg development discussions and patches <ffmpeg-
> devel at ffmpeg.org>
> Subject: Re: [FFmpeg-devel] [RFC] d3dva security hw+threads
> 
> Quoting Soft Works (2022-09-04 09:43:36)
> >
> >
> > > -----Original Message-----
> > > From: ffmpeg-devel <ffmpeg-devel-bounces at ffmpeg.org> On Behalf Of
> > > Anton Khirnov
> > > Sent: Sunday, September 4, 2022 8:58 AM
> > > To: FFmpeg development discussions and patches <ffmpeg-
> > > devel at ffmpeg.org>
> > > Subject: Re: [FFmpeg-devel] [RFC] d3dva security hw+threads
> > >
> > > Quoting Timo Rothenpieler (2022-09-02 01:46:59)
> > > > On 02.09.2022 01:32, Michael Niedermayer wrote:
> > > > > Hi all
> > > > >
> > > > > Theres a use after free issue in H.264 Decoding on d3d11va
> with
> > > multiple threads
> > > > > I dont have the hardware/platform nor do i know the hw
> decoding
> > > code so i made
> > > > > no attempt to fix this beyond asking others to ...
> > > >
> > > > hwaccel with multiple threads being broken is not exactly a
> > > surprise.
> > > > So we could just disable that, and always have it be one single
> > > thread?
> > >
> > > We are already disabling it in a way - the frame threading code
> > > ensures
> > > that threads run one at a time when hwaccel is being used.
> >
> >
> > Is there a described way to repro? I would try whether it still
> > happens after removing the lock code in hwcontext_d3d11va.c.
> > Those locks are not really needed and might prevent release
> > of dx11 resources in proper order. It's a guess only but
> > easy to try.
> 
> The problem is not in d3d11 locking code, but in the generic code
> that
> does not have clear enough ownership rules. Steve already tested that
> my
> patch from Friday fixes this.

Oh I see. I was missing the context. The patch makes sense to me.

Thanks,
sw