DLL Redirection Using Manifests

[user57]

i have shortly looked into that cuda/cuvid code, i expected it does set (control, output, input) - and yes it is doing exactly that

it is right that a grafic card that supports a codec is needed to make use of nvenc/nvdec (or with other words if you want a grafic card doing the de/encoding you need a grafic card that can do this)
what seems a missconsumtion to me is that you need a grafic-card to make a de/encoder - that is just not right

the example code is totally bond to the dx9 video engine 
// Create the D3D object.
"Direct3DCreate9Ex(D3D_SDK_VERSION, &g_pD3D)"
to this point it dont look to bad for xp (dx9Ex video engine) (and in the end maps a RGB buffer to that dx9ex engine)

but it can be expected there is a deeper code (inside the d3d9/11 dll), where you if you use that engine code actually dont see what it is doing there
the code itself, is also mixed up some parts initialize cuda/cuvid while other gather the d3d9/11 video engine
so this method use both (d3d video engine + cuda/cuvid engine)
(it is mapping the cuda/cuvid engine to opengl/d3d video as RGB buffer)

it would be possible that the driver simply dont have the right control code and just returns 0 or not function

it could be that if the right parameters are set, that these are just not being processed (either nvcuvid.dll, d3d9.dll or the driver version)

the nvidia driver either user or kernel level is closed source, makes it hard to overview and dont allow a direct controlment with high level functions (what also only do set control/parameters,input, output)

for ffmpeg i looked around for the NVDEC/NVENC engine, ffmpeg use up these engines (ffmpeg is not independent)
rather ffmpeg is to understand as command line that if it wants to use NVDEC/NVENC ffmpeg then calls up these engines
so ffmpeg isnt doing it alone either or "just can be used on xp" 

the user engine/api seems to be at nvcuvid.dll
what then calls a function inside that nvcuvid.dll like this:
cuvidMapVideoFrame(&hDecoder, nPicIdx, &cuDevPtr, &nPitch, &stProcParams);
but this is a low level function it dont tell what nvcuvid.dll (and all its followers such as the video driver) actually really do

https://github.com/tpn/cuda-samples/blob/master/v9.0/3_Imaging/cudaDecodeD3D9/videoDecodeD3D9.cpp
https://docs.nvidia.com/video-technologies/video-codec-sdk/11.1/nvdec-video-decoder-api-prog-guide/index.html

then website for a devloper making use of NVDEC/NVENC tells us this:
Software: Windows 11, Video Codec SDK v12.2, NVIDIA display driver: 551.76

this seems hard to me it tells a driver version that xp actually dont have (551.76)
the SDK might be able to do it without opengl/d3d video (as cuda/cuvid maps a RGB buffer in the end, why would it have to be a opengl or d3d video engine?)
but a new SDK tends to use new api sets (and here is where it says something about win11)
it might actually already use win10+ apis in the SDK already
the driver and the nvcuvid.dll (the newer versions) might also be used up with win11 windows api´s

a real solution would look totally different
we would need the high level functions that control the nvidia driver
then we could set the right parameters/controlcode, input buffer, output buffer (RGB)
the control code, input buffer, and the output buffer can be done in a player then

that would be very os independent solution and could make use of nvidia grafic cards that support hardware de/encoding

 

it will be exciting to see what happens now
 

[Zorba the Geek]

I have done some research, and it seems that Microsoft will permit you to create your own side-by-side assemblies in the WinSxS folder, but the custom dependencies have to be digitally signed, and you have to generate a public key token.  The whole process looks complicated to me.  If it could be successfully  be done we could place our One Core API DLLs here without modifying the operating system or applications at all.  All that would be needed is a simple text file in the same folder as the application's program file.