> 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 but I do not use it to get the frames. When it was written that we could access accelerated windows, I did not mean to say that the output from dxgigrab is an accelerated format. The access to such window frames is due to the API that allows us to map the frames for CPU access. > The name of these files seem way too generic to just sit there like this > in the top level. I can either rename or rearrange the files to a sub-folder is the patch is to be accepted. > Are these headers parts of any normal windows SDK? > I don't see them in anything mingw has. > Does this break cross compiling from Linux, or with anything that's not > MSVC? > And given it's winrt... does this work on normal Desktop Windows? Build was tested from a normal Windows 10 Desktop with both VisualStudio 2019 and 2022, the required SDK is 10.0.18632.0. lower SDK do not have required includes and SDK 10.019XXX is bugged. Other SDKs were not tested. In the following link you can find the configuration used to build. https://git.jami.net/savoirfairelinux/jami-daemon/-/blob/master/contrib/src/ffmpeg/windows-configure-make.sh please consider $1 = win32 and $2 = x64 . For note, the current Jami beta release (https://jami.net/download-jami-windows/) uses the patch for window sharing in calls. _______________________________________________ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
