On Thu, Feb 09, 2023 at 04:58:46PM +0100, Timo Rothenpieler wrote:
> On 09.02.2023 15:22, aline.gondimsan...@savoirfairelinux.com wrote:
> > From: Aline Gondim Santos
> >
> > A dxgi grab device may be either a display or a window.
> > Differently from the existing gdigrab, this new device does
>
> How do you get access to the d3d hwdevice, given this lives in lavd,
> which has no provisions for that?
> This looks much more like it'd fit in with the desktop duplication
> capture, which ended up being a vsrc filter for that reason.
Upon developing the device i did notice the d3dhwdevice
On 09.02.2023 17:10, Nicolas George wrote:
Timo Rothenpieler (12023-02-09):
How do you get access to the d3d hwdevice, given this lives in lavd, which
has no provisions for that?
Would it work better if it was in the same library?
It's not so much about in which library it is, but that
Timo Rothenpieler (12023-02-09):
> How do you get access to the d3d hwdevice, given this lives in lavd, which
> has no provisions for that?
Would it work better if it was in the same library?
Regards,
--
Nicolas George
___
ffmpeg-devel mailing list
On 09.02.2023 15:22, aline.gondimsan...@savoirfairelinux.com wrote:
From: Aline Gondim Santos
A dxgi grab device may be either a display or a window.
Differently from the existing gdigrab, this new device does
not make the mouse to flick and also allows proper grabbing of
accelerated windows,
From: Aline Gondim Santos
A dxgi grab device may be either a display or a window.
Differently from the existing gdigrab, this new device does
not make the mouse to flick and also allows proper grabbing of
accelerated windows, such as chrome or visual studio code.
Signed-off-by: Aline Gondim
