LAV CUVID Decoder - High Quality Hardware decoding for NVIDIA

[namaiki]

mindbomb, how much video ram on all of those cards? Also, you can check statistics for GPU/VRAM usage and load with the latest Forceware with GPU-z.

[mindbomb]

the 9400m has none since it's integrated, but it's vp3, so is suspect thats why it has very good performance for h264
the gtx 260 has 896mb, and the 8600gt has 256mb

i dont think its a video ram issue on the 8600gt, since it seems to use 240mb of ram for all videos, but performance is especially poor for 1080p h264, while 720p h264 is fine, and vc-1 isn't perfect, but its in much better shape than 1080p h264.

[CruNcher]

nev http://forum.doom9.org/showpost.php?...postcount=6181 <- im almost sure this is somehow timestamp related changing Mainconcepts timestamp setting has several effects on the droped frames rate. Im trying your Lav Splitter and audio decoder again

I tried the combination of Lav Audio Decoder + Lavf Splitter + VMR9 Renderless and still i get frame drops after 12 seconds

VMR9 Renderless = Drops after 12 seconds
VMR7 Renderless = OK (useless no Shader support)
VMR9 Windowed = Drops after 12 seconds (useless no Shader support)
VMR7 Windowed = OK (useless no Shader support)

So its affecting only VMR9 on my system and with Cyberlinks Decoder its ok so it seems only renderer related not really timestamp @ all or a combo of both maybe even Driver related. Still i wonder what Cyberlink does different that it doesn't get affected compared to all the others.

I guess i try another player with VMR9 support and see if it happens their too (maybe it has something todo with MPC-HC sync stuff and GPU buffering)

Hmm nope same in Graphstudio connected to Video Rendering Mixer 9 every decoder DXVA or CUDA fails with that stream except Cyberlinks Decoder maybe it has todo something with my more strict Windows Timings.

IDLE

ClockRes v2.0 - View the system clock resolution
Copyright (C) 2009 Mark Russinovich
SysInternals - www.sysinternals.com

Maximum timer interval: 15.625 ms
Minimum timer interval: 1.000 ms
Current timer interval: 15.625 ms

Video Playback

ClockRes v2.0 - View the system clock resolution
Copyright (C) 2009 Mark Russinovich
SysInternals - www.sysinternals.com

Maximum timer interval: 15.625 ms
Minimum timer interval: 1.000 ms
Current timer interval: 0.977 ms

seems that with really high resolution timings not every decoder can cope with on VMR9

[thuan]

On my 9800GT with 512MB RAM, with madVR and LAV CUVID or EVR-CP and DXVA, playing 1080p video use around 450MB RAM. The funny thing is the video decoder engine usage is a mess jumping around to around max 70% and sometimes down to 10% with mem controller load never goes over 20% but it still stutters on certain heavy bitrate video like slideshow.

[roozhou]

I have a 8500gt with 128MB VRAM. With driver earlier than 197.45, the VP2 unit on this card is unable to decode H264 video with width >1856. With newer driver, DXVA1 can be used on 1920x1080 content but CUDA still has the 1856 width limit (Both CoreAVC and LAV CUVID).

[xv]

Found another bug:
LAVCUVID will connect and try to decode not supported H.264 profiles, tested with lossless (old and new format).
Result is heavily corrupted image (new lossless format) or no output at wrong resolution (old lossless format). Would be great if LAVCUVID could detect unsupported H.264 profiles and refuse the connection.

[CruNcher]

Yep thats a big no go if you cant decode it let the next filter in the chain try it ISVs should also learn that, though i guess nev just missed to parse for x264 losless as nvcuvid knowingly doesn't support it and never will
It also tries to playback Mpeg-2 Studio Profile as well and obviously fails

PS: I also wanted to add that even benchmarks show that its slower then CoreCodecs Nvcuvid implementation http://forum.doom9.org/showpost.php?...0&postcount=48 therefore it is more stable (more consistent playback results) if you close MPC-HC playback reopen close reopen CoreAVCs Nvcuvid has a tendency to lose efficiency and recovers after the 3rd run very slowly LA CUVID doesn't show this behavior (every run it goes to its full speed of 45 fps), something that DXVAchecker obviously ignores

[Xorp]

Any chance this decoder could someday perform inverse telecine on interlaced film content? (ie the occasional 1080i60 movie Blu-ray) Like Dscaler does for MPEG2.

[madshi]

@Xorp, nevcairiel says it already does. I don't fully believe it yet, though. I think the hardware should properly detect the cadence and put the right fields together, but I doubt that the hardware will mod the output to 24p. I think the output will be either 30p or 60p. I'm ready to be proven wrong, though...

[CruNcher]

Nev any idea where round about 40 fps of 45 fps are disappearing too when rendering out with any of the NVcuvid Dshow filters (not only yours) on either Haalis or Madshis renderer ?

it looks like that currently

VMR7 = 45 fps
VMR9 = 45 fps
Haali = 4 fps
Madvr = 4 fps
Haali(CPU) = 60 fps
Madvr(CPU) = 60 fps

little heavy that loss, catch them and force them to arrive @ Haali/Madvr

[nevcairiel]

I can play 60fps content just fine on madVR.

[CruNcher]

Hmm strange i tried that 4 girls stream it tasks VP2 a lot here http://forum.doom9.org/showthread.ph...71#post1477571 impossible to get 60 fps with that on VMR even Cyberlink DXVA only goes up to 53 fps

Hmm but with Madvr and Haali in combination with LAV CUVID (no connection to Haali actually falls back to Video Renderer), CoreAVC CUDA or CUDA Video Decoder its really problematic almost every frame drops away you don't even need a OSD to see that over here

Arggggghhhh



do you see what i see ??? that could explain it

lets see what i send madshi over with madnv12test

D3D9 Surface speed test:
NV12: upload 440 fps, download 554 fps, trick download failed
YV12: upload 76 fps, download 17 fps, trick download failed
A8R8G8B8: upload 431 fps, download 262 fps, trick download failed

Forcing CoreAVC Nvcuvid to NV12 only on Madvr is indeed much faster though still more of a Slideshow compared to DXVA

[GTPVHD]

VP2 and VP3 doesn't have enough performance to decode 60FPS videos, only VP4 can do it. Upgrade to a VP4 enabled Nvidia GPU.

http://www.nvnews.net/vbulletin/show...&postcount=325(VP4)

http://www.nvnews.net/vbulletin/show...&postcount=339(VP4)

H264 DECODING (1920x1080): 66 frames/s

http://www.nvnews.net/vbulletin/show...&postcount=364(VP3)

H264 DECODING (1920x1080): 52 frames/s

http://www.nvnews.net/vbulletin/show...&postcount=306(VP2)

H264 DECODING (1920x1080): 44 frames/s

[sneaker_ger]

Originally Posted by GTPVHD

VP2 and VP3 doesn't have enough performance to decode 60FPS videos, only VP4 can do it. Upgrade to a VP4 enabled Nvidia GPU.

How bitrate dependent is this? I got some 70 fps on 1080p with a VP3 on a quick graphstudio benchmark.

[mark0077]

Hi nevcairiel, your tweak of disabling vc-1 frame time correction in the lav splitter fixed my random frame drops here and there.

Now comparing your decoder to ffmpeg-mt, unfortunately I still get more dropped frames and I have an idea where incase its any help.

When I was tweaking my avisynth mvtools scripts recently, and when i didn't know about ffmpeg-mt, I would find that certain scenes in 1080p movies brought up my cpu usage just that little bit, I assume due to more detailed scenes / higher bitrate. Whatever the reason, I would get 1,2, maybe a bunch of even 10 frame drops all at once in these busy scenes. I noticed that cpu and gpu usage was still very very low (core i7 920 @ 3.7ghz, gtx 295). So I found that the simple switch to the multithreaded decoder spread the load that little bit so that the increases in cpu / gpu usage during those busy scenes wasn't enough to overload one core of my cpus.

Now I see the very same behaviour with your decoder. I get frame drops in these busy scenes again, that I don't with ffmpeg-mt. I'm basically asking is there anything in your decoders code that puts any sort of load on the cpu that could also be made to be multithreaded. I have a strong feeling that if this was possible, that I could also see 0 frame drops with your decoder like I do with ffmpeg-mt as none of my cpu cores would reach a point where I would get dropped frames. Feel free to ask any questions about my setup if you're interested in pursuing any possible enhancements.

I'm outputting from lav splitter -> lav cuvid decoder -> nv12 -> ffdshow + avisynth -> nv12 -> madVR -> GTX295

[nevcairiel]

The decoding is all done in hardware, i cannot really change how that works. However, there are some ways to improve the pipelining, like right now i only have one output buffer, which once its filled with a picture, gets send to the renderer. What i will do is allow more output buffers (which will increase memory usage on the GPU, though), and then queue them up for sending to the renderer - this might help in "busy" situations.

[mark0077]

Thanks navcairiel, I'll test out any changes that you might be able to make and report back whenever any new builds are available Keep up the good work.

[CruNcher]

Originally Posted by GTPVHD

VP2 and VP3 doesn't have enough performance to decode 60FPS videos, only VP4 can do it. Upgrade to a VP4 enabled Nvidia GPU.

http://www.nvnews.net/vbulletin/show...&postcount=325(VP4)

http://www.nvnews.net/vbulletin/show...&postcount=339(VP4)



http://www.nvnews.net/vbulletin/show...&postcount=364(VP3)



http://www.nvnews.net/vbulletin/show...&postcount=306(VP2)

What was the sample i get 52 fps (VP2) on a 60 fps sample which tasks according to GPU-Z the Video Engine @ 95% it's not that easy to confirm if all test different sample complexities

[Virtual_ManPL]

FYI - CUDA Toolkit 4.0 RC2 (32bit & 64bit)

Waiting for 64bit release of LAV CUVID Decoder

[tiny]

Possible bug?

The framerate of pure interlaced sources is not doubled in the output with force bob enabled. It happens with all renderers.


Tested using MPC-HC 1.5.2.3018 on WinXP SP3. CPU: C2D @ 2.13GHz, GPU: GTS450.