Recently I've built vslsmashsource.dll with last available ffmpeg libs. As result I can decode H264 with cpu, cuvid and quicksync decoders from lsmas.LWLibavSource.
While testing, I found that DGDecodeNV and cuvid decoder from vslsmashsource performs on approx. the same speed (250 fps on my GTX 750), DGDecodeIM and qsv decoder differs: ~120 fps vs. ~380 fps (i5-4670k). Is there some limitation in DGDecodeIM?
P.S.: I know you're busy with tonemap stuff right now, so feel free to check things here once you done with it.
Decoding speed
Decoding speed
PC: RTX 2070 | Ryzen R9 5950X (no OC) | 64 GB RAM
Notebook: RTX 4060 | Ryzen R9 7945HX | 32 GB RAM
Notebook: RTX 4060 | Ryzen R9 7945HX | 32 GB RAM
Re: Decoding speed
To be honest, DJ, I haven't looked at DGIM stuff for many years and it's still using an early Intel SDK. Let me get the next release of DGHDRtoSDR out and then I'll have a look at it. I placed a shortcut to this thread on my desktop so I don't forget.
Re: Decoding speed
I've got some very bad news on the DGIM front. ![Crying or Very Sad :cry:](./images/smilies/icon_cry.gif)
As I geared up to investigate your decoding issue, I updated my Intel video driver to the most recent one. I immediately discovered that this driver is no longer compatible with the older sample code I had based DGDecIM on. Specifically, random access is now broken with the latest video drivers. DG tools' raison d'etre is robust random access, so this is a very serious development.
This is not the first time that Intel has progressed in a non-backward-compatible way. I had a filter that did HW deinterlacing (single and double rate) using the IM engine. Worked great. Then one day it stopped working right after a video driver update. So I abandoned it because I should not have to re-design and re-implement my application at a video driver update. Now we have the same situation with DGDecIM. In contrast, nVidia is excellent at maintaining backward compatibility. DGDecNV still is based on the very first CUVID API and sample code from 2008, which nVidia shared with me in the very early stages of its development (my feedback was helpful to nVidia as you can see from the development dialog available at my website). So we have had 10 years of flawless backward compatibility! Intel? They never replied to any of my emails and bug reports. I got a forum response once but it was beyond clueless and worthless. It's not hard to understand why I became an ardent nVidia supporter. I think it's stupid not to have a recent nVidia GPU available.
Now, realistically, I am not going to throw out the whole of DGDecIM and start all over again. I tried for several hours to salvage things but I am deluged with calls returning MFX_ERR_UNKNOWN, which leaves me busted. And Intel support on these matters is absent.
Most likely DGDecIM is going to sleep with the fishes. No time or motivation to start another huge development to support the latest incarnation of IMSDK, especially given that NVDec/CUDA is stellar in so many ways.
![Crying or Very Sad :cry:](./images/smilies/icon_cry.gif)
As I geared up to investigate your decoding issue, I updated my Intel video driver to the most recent one. I immediately discovered that this driver is no longer compatible with the older sample code I had based DGDecIM on. Specifically, random access is now broken with the latest video drivers. DG tools' raison d'etre is robust random access, so this is a very serious development.
This is not the first time that Intel has progressed in a non-backward-compatible way. I had a filter that did HW deinterlacing (single and double rate) using the IM engine. Worked great. Then one day it stopped working right after a video driver update. So I abandoned it because I should not have to re-design and re-implement my application at a video driver update. Now we have the same situation with DGDecIM. In contrast, nVidia is excellent at maintaining backward compatibility. DGDecNV still is based on the very first CUVID API and sample code from 2008, which nVidia shared with me in the very early stages of its development (my feedback was helpful to nVidia as you can see from the development dialog available at my website). So we have had 10 years of flawless backward compatibility! Intel? They never replied to any of my emails and bug reports. I got a forum response once but it was beyond clueless and worthless. It's not hard to understand why I became an ardent nVidia supporter. I think it's stupid not to have a recent nVidia GPU available.
Now, realistically, I am not going to throw out the whole of DGDecIM and start all over again. I tried for several hours to salvage things but I am deluged with calls returning MFX_ERR_UNKNOWN, which leaves me busted. And Intel support on these matters is absent.
Most likely DGDecIM is going to sleep with the fishes. No time or motivation to start another huge development to support the latest incarnation of IMSDK, especially given that NVDec/CUDA is stellar in so many ways.
Re: Decoding speed
Okay, thx for info.
Yup, sometimes I see green screen on seeking with LwLibAV, so that's it...
Okay then, LWlibav is usable for previewing on fast speed, i can stick with that. Thx for clarification.
Yup, sometimes I see green screen on seeking with LwLibAV, so that's it...
Okay then, LWlibav is usable for previewing on fast speed, i can stick with that. Thx for clarification.
PC: RTX 2070 | Ryzen R9 5950X (no OC) | 64 GB RAM
Notebook: RTX 4060 | Ryzen R9 7945HX | 32 GB RAM
Notebook: RTX 4060 | Ryzen R9 7945HX | 32 GB RAM
Re: Decoding speed
Unfortunately my notebook is too slow on Nvidia part — 48 fps (GT555M), but still good with IM (~120 fps) and Lwlibav (~220 fps). As for PC - yup, GTX750 is pretty fast — ~250 fps (and even faster than my server's 760, which is just ~128 fps).
PC: RTX 2070 | Ryzen R9 5950X (no OC) | 64 GB RAM
Notebook: RTX 4060 | Ryzen R9 7945HX | 32 GB RAM
Notebook: RTX 4060 | Ryzen R9 7945HX | 32 GB RAM
Re: Decoding speed
Check.