LAV CUVID Decoder - High Quality Hardware decoding for NVIDIA [Archive] - Page 17

BeNooL

6th June 2011, 07:45

I guess people ask for a tray icon for 2 reasons:

(1) So they can change the LAV CUVID settings through the tray icon instead of having to right click the video -> filters -> properties. Doing it through the tray icon is noticeably better if you have a 2 monitor setup, with the video running on secondary monitor. The tray icon will then be on the primary monitor, allowing you to change settings without interrupting fullscreen video playback on the secondary monitor.

(2) Seeing that tray icon in the tray bar is a very quick way to tell which filters are being used. If you don't see that tray icon you know that a "wrong" filter was selected by MPC-HC. I find this useful e.g. for the Haali Splitter. Whenever I see the Haali icon in the tray bar, I know that the Haali Splitter is being used. That's just "nice" as a quick way to see which splitter is currently being used.

That sums it up completely IMHO.

CruNcher

6th June 2011, 12:14

Did you at least check the clip if its not 4:2:2 again, and wasting my time?
Btw, deep links on that trailers page don't work anyway.

That wouldn't be logic as Apples H.264 Decoder doesn't support 4:2:2 ;)

I guess people ask for a tray icon for 2 reasons:

(1) So they can change the LAV CUVID settings through the tray icon instead of having to right click the video -> filters -> properties. Doing it through the tray icon is noticeably better if you have a 2 monitor setup, with the video running on secondary monitor. The tray icon will then be on the primary monitor, allowing you to change settings without interrupting fullscreen video playback on the secondary monitor.

(2) Seeing that tray icon in the tray bar is a very quick way to tell which filters are being used. If you don't see that tray icon you know that a "wrong" filter was selected by MPC-HC. I find this useful e.g. for the Haali Splitter. Whenever I see the Haali icon in the tray bar, I know that the Haali Splitter is being used. That's just "nice" as a quick way to see which splitter is currently being used.

You hit the nail on the Head, it's a very usability friendly thing in a (controlled) dshow environment where you want to see immediately what is rendering what, the same usability ffdshows try icon provides in showing you the whole graph it currently operates in, this way you don't have to click through all the MPC-HC menus or right click to find your way through x cascaded menus to see the Graph building (inefficient), though much nicer would be if MPC-HC would get this for the Status OSD as well (simple CTRL+J and you see whats going on, much more efficient in several scenarios), also because not everyone uses Explorer as his main Shell @ all and then a Tray icon would become useless again ;)

SamuriHL

6th June 2011, 13:41

Madshi just volunteered to add it to his madVR icon??? Woa, that's awesome! :p LOL! :D

nevcairiel

6th June 2011, 13:45

You hit the nail on the Head, it's a very usability friendly thing in a (controlled) dshow environment where you want to see immediately what is rendering what

Right click MPC-HC -> Filters, voila, all the info in the world!
Or if you're super OCD, attach GraphStudio to the graph!

I will definitely not add a tray icon just so people can see the icon when LAV CUVID is running. Thats alot of wasted development time for a, IMHO, useless icon.

ffdshow has alot of filters and other stuff you can activate, or choose subs, its not comparable. I just don't see the use in an icon for such a simple decoder.
If every playback component is going to add an icon, we'll end up with 5-6 new icons just when the movie starts. Thats horrible!
.. Actually it is already like this if you use ffdshow, and i don't like it.

I should do what the DivX decoder did, and blend a logo over the screen in a corner at the start of playback. :p

Oh, and because madshi talked so much about "to see which splitter is currently being used", LAV Splitter will eventually get a tray icon, so you can switch streams and chapters on players that don't offer this functionality natively. Thats a useful feature, having an icon just for the sake of having an icon .. is not.

clsid

6th June 2011, 14:01

Not everybody uses MPC or ffdshow or MadVR. Basic players like WMP don't offer all the required stream selection functionality. A tray icon is useful for stream selection.

nevcairiel

6th June 2011, 14:02

Like i said, LAV Splitter will get a tray icon for stream and chapter selection.

LAV CUVID will not, unless someone sends me a patch that looks clean enough.

ney2x

6th June 2011, 14:10

I should do what the DivX decoder did, and blend a logo over the screen in a corner at the start of playback. :p

That would be awesome!

Like i said, LAV Splitter will get a tray icon for stream and chapter selection.

LAV CUVID will not, unless someone sends me a patch that looks clean enough.

I'll ask mr.duck maybe he can send... :D

Not everybody uses MPC or ffdshow or MadVR. Basic players like WMP don't offer all the required stream selection functionality. A tray icon is useful for stream selection.

I think it's time also to add support for LAV CUVID and LAV Filters in Win7DSFilterTweaker for those who used WMP :D

SamuriHL

6th June 2011, 14:11

No no no no no no! :D

yesgrey

6th June 2011, 14:16

I should do what the DivX decoder did, and blend a logo over the screen in a corner at the start of playback. :p
I would do better: output only the logo.:devil:

nevcairiel

6th June 2011, 14:17

That would be easier then blending it over the frame, too! :)

BeNooL

6th June 2011, 18:12

I can confirm version 0.8 "32-bit (Older CUDA)" is now working fine for me with the headless GeForce :)
Thank you nevcairiel.

now it is time to use it and see how it all performs.

CruNcher

7th June 2011, 08:58

Right click MPC-HC -> Filters, voila, all the info in the world!
Or if you're super OCD, attach GraphStudio to the graph!

I will definitely not add a tray icon just so people can see the icon when LAV CUVID is running. Thats alot of wasted development time for a, IMHO, useless icon.

ffdshow has alot of filters and other stuff you can activate, or choose subs, its not comparable. I just don't see the use in an icon for such a simple decoder.
If every playback component is going to add an icon, we'll end up with 5-6 new icons just when the movie starts. Thats horrible!
.. Actually it is already like this if you use ffdshow, and i don't like it.

I should do what the DivX decoder did, and blend a logo over the screen in a corner at the start of playback. :p

Oh, and because madshi talked so much about "to see which splitter is currently being used", LAV Splitter will eventually get a tray icon, so you can switch streams and chapters on players that don't offer this functionality natively. Thats a useful feature, having an icon just for the sake of having an icon .. is not.

The way via the MPC-HC menu structure takes to much time (see also my post) and Graphedit/Graphstudio Graph attaching is a even more time consuming task. I still believe the most convenient option would be the MPC-HC OSD itself (CTRL+J) being able to display the current Graph running, this implementation way you could also avoid problems with different Windows Shells :)
Granted though that's not really falling into your resort @ all, i just found it a very nice way in ffdshow but thinking thrice about it it's inefficient to click arround to see the Graph if you can display it directly in the Host application without needing to click anywhere ;)

nevcairiel

7th June 2011, 08:59

The EVR-CP OSD shows the current Decoder, at least in current trunk builds.

CruNcher

7th June 2011, 10:45

Hmm nothing of that visible in VMR9 Renderless @ build 3190, anyways only the Decoder is a beginning but transforming the whole current Filter display text into the OSD is what i had in mind :)
Below the Render Device:

Render Device: NVIDIA Geforce 9800 GT
Graph: File Source Async -> Lav Splitter -> Lav Audio Decoder -> Mainconcept Mpeg-2 Decoder -> Video Mixing Renderer 9 Renderless -> Default DirectSound Device

Virtual_ManPL

7th June 2011, 12:51

@ nevcairiel - Thank you for x86-64 compilation! Works great. :D

GTPVHD

9th June 2011, 05:27

http://www.nvnews.net/vbulletin/showpost.php?p=2432758&postcount=370

H264 DECODING (1920x1080): 120 frames/s

GF119 has VDPAU FEATURE SET D, it's the only GPU with feature set D so far. Looks like Nvidia GPUs with feature set D hardware decoder has doubled the performance for the H.264 decoder.

nevcairiel

9th June 2011, 08:23

Too bad the GT 520 is too slow for any real usage (it cannot even deinterlace 1080i60 at highest quality, the test you linked only shows 55 fields/s), kinda hoping for a 540 or so using that video decoder but offering enough 3D performance.

Didée

9th June 2011, 09:29

GF119 has VDPAU FEATURE SET D, it's the only GPU with feature set D so far. Looks like Nvidia GPUs with feature set D hardware decoder has doubled the performance for the H.264 decoder.
Whatever "feature set D" might improve over "C", it's not the raw decoding performance. Those 120fps are referring to grey.ts, wich is ~8000kbps and not very complex. My little GT240 is decoding that one at 118fps too. (IIRC, Im not at home ATM)

nevcairiel

9th June 2011, 09:31

Whatever "feature set D" might improve over "C", it's not the raw decoding performance. Those 120fps are referring to grey.ts, wich is ~8000kbps and not very complex. My little GT240 is decoding that one at 118fps too. (IIRC, Im not at home ATM)

Maybe the test is not perfect, still, Feature Set D does nearly double the decoding performance.
There is a test from a GTX 580 a few posts above that, which shows "H264 DECODING (1920x1080): 66 frames/s"

BTW, the hardware decoder doesn't really care that much about complexity or bitrate (the beauty of fixed-function hardware), the biggest hit is resolution.

CruNcher

9th June 2011, 09:31

Yep intel easily beats that :P

nevcairiel

9th June 2011, 09:35

Yep intel easily beats that :P

Too bad that Intels 3D performance is just horrible.

I should write a Hardware decoder for Intel (its pretty easy, their SDK is beautiful). Wonder if you can use QuickSync decoding and then use madVR on a real GPU if you use Virtu or Synergy. Should be easy to test, need to install Virtu on my box. :)

I wish Intel iGPU would get some more 3D performance in the next generation, so that using it with madVR would be a viable solution.

roozhou

9th June 2011, 10:30

hoborg

9th June 2011, 10:32

Any reason to use hardware decoding on a CPU as fast as Sandybridge?

HW deinterlacing for example?

CruNcher

9th June 2011, 10:35

Too bad that Intels 3D performance is just horrible.

I should write a Hardware decoder for Intel (its pretty easy, their SDK is beautiful). Wonder if you can use QuickSync decoding and then use madVR on a real GPU if you use Virtu or Synergy. Should be easy to test, need to install Virtu on my box. :)

I wish Intel iGPU would get some more 3D performance in the next generation, so that using it with madVR would be a viable solution.

Their is already a official Dshow Encoder/Decoder available ;)
And yeah those combination Frameworks are also things i thought about early on, though as im an early adopter of SB Virtu isn't available and i wait for Synergy :)
But the Israelis have something Nvidia neither ATI has yet any information about from their Labs and that almost released http://www.youtube.com/watch?v=EPhXqQFb7wE
These things are the only thing that will make me to move to the next NT because it's almost impossible todo Virtu or Synergy on XP and these frameworks are just to crazy to think about the possibilities :)

nevcairiel

9th June 2011, 11:14

Their is already a official Dshow Encoder/Decoder available ;)

Thats only pretty static sample applications, and only work in DXVA mode, not in madVR compatible mode. :p

GTPVHD

9th June 2011, 11:21

Anyone that says their GT 240 is getting over 100FPS is wrong. The GTX 580 has the same VP4 decoder as the GT 240 and it doesn't even break 66FPS.

http://www.nvnews.net/vbulletin/showpost.php?p=2330104&postcount=320

NVIDIA GPU GeForce GT 240 (GT215)
H264 DECODING (1920x1080): 66 frames/s

http://www.nvnews.net/vbulletin/showpost.php?p=2420599&postcount=14

Sorry about the confusion. VDPAU feature set D describes improved capabilities in the hardware. However, supporting these features requires software changes that are not yet available.

Feature Set D decoder has real improvements over VP4/Feature Set C.

Too bad the GT 520 is too slow for any real usage (it cannot even deinterlace 1080i60 at highest quality, the test you linked only shows 55 fields/s), kinda hoping for a 540 or so using that video decoder but offering enough 3D performance.

The next-gen Nvidia Kepler GPU family should have the same Feature Set D decoder or better decoder. So you get high performance H.264 decoding and better shader performance from Kepler's improved architechture.

CruNcher

9th June 2011, 11:43

Anyone that says their GT 240 is getting over 100FPS is wrong. The GTX 580 has the same VP4 decoder as the GT 240 and it doesn't even break 66FPS.

http://www.nvnews.net/vbulletin/showpost.php?p=2330104&postcount=320

http://www.nvnews.net/vbulletin/showpost.php?p=2420599&postcount=14

Feature Set D decoder has real improvements over VP4/Feature Set C.

The next-gen Nvidia Kepler GPU family should have the same Feature Set D decoder or better decoder. So you get high performance H.264 decoding and better shader performance from Kepler's improved architechture.

Much more interesting is that Tegra 3 will be finally able to deliver smooth 1080p/i @ low power :P

Didée

9th June 2011, 12:02

It's quite possible that I mixed-up some numbers, they were from memory (and dating half-a-year back).

BTW, the hardware decoder doesn't really care that much about complexity or bitrate (the beauty of fixed-function hardware), the biggest hit is resolution.
When I e.g. look here (http://forum.doom9.org/showthread.php?p=1421852#post1421852), I see that a VP4/Feat.C card decodes a 9Mbps stream @ 109fps, and a 25Mbps stream @ 65fps. That's not quite "doesnt care about bitrate". Or is it?

BTW, what are those *.dat-samples in the VDPAU test archive? On Windows I can't decode them with anything, also mediainfo can't make heads or tail of them. The AVC files aren't even reckognized when renamed to *.264, so they aren't native raw streams either?

Maybe the test is not perfect, still, Feature Set D does nearly double the decoding performance.
There is a test from a GTX 580 a few posts above that, which shows "H264 DECODING (1920x1080): 66 frames/s"
Frankly, I don't really know, but ... feature set is feature set, and VP engine is VP engine. If VP4 still is VP4, then it seems a bit strange that just the "feature set" should bring the raw decoding to double performance.

Is it absolutely sure that it's not some sort of a Linux-/driver-related effect?

BTW, I've no particular interest in this topic, since I'm fine with CPU decoding (i7-860 stays @ its lowest Multiplier when decoding 10Mbps 1080p, so I've not any need for GPU decoding).

I'm just wondering, and finding that particular VDPAU test not exactly "transparent".

nevcairiel

9th June 2011, 12:06

Frankly, I don't really know, but ... feature set is feature set, and VP engine is VP engine. If VP4 still is VP4, then it seems a bit strange that just the "feature set" should bring the raw decoding to double performance.

NVIDIA never really confirmed those VP2/3/4 names, its something we made up, all they use is the feature set, and they correspond perfectly to the VP's. 2=A, 3=B, 4=C

But its also not unheard of that they use the next-gen video decoder on a low-end card of the current generation. The 220 and 240 for example have the VP4 decoder of the 4xx generation, while all "faster" 2xx cards have a VP2.

Is it absolutely sure that it's not some sort of a Linux-/driver-related effect?

Yes. I've also seen Windows benchmarks.

I'm just wondering, and finding that particular VDPAU test not exactly "transparent".

Its not meant as the all knowing benchmark, more as a "does this work at all" kinda thing.

Didée

9th June 2011, 12:16

NVIDIA never really confirmed those VP2/3/4 names, its something we made up, all they use is the feature set, and they correspond perfectly to the VP's. 2=A, 3=B, 4=C
Oh, it is like THAT? Now you can tell me "badly informed". :)

Seen in that light, the list would continue with "5=D", and everything makes sense.

Time to continue with more fruitful discussion ...

andyvt

9th June 2011, 12:19

I should write a Hardware decoder for Intel (its pretty easy, their SDK is beautiful). Wonder if you can use QuickSync decoding and then use madVR on a real GPU if you use Virtu or Synergy. Should be easy to test, need to install Virtu on my box.

The "sample_decode" MSDK application shows how to use HWA decoding and get the raw data.

nevcairiel

9th June 2011, 12:20

The "sample_decode" MSDK application shows how to use HWA decoding and get the raw data.

Yeah i know it. Beautifully done by Intel, the samples cover everyhting you need. :)

andyvt

9th June 2011, 12:27

Yeah i know it. Beautifully done by Intel, the samples cover everyhting you need. :)

So next week then ;)

nevcairiel

9th June 2011, 12:30

Sadly, there isn't that much use for such a filter yet, as you need a dedicated card anyway to use madVR. Maybe when Ivy Bridge is near and the 3D performance looks much better. ;)

CruNcher

9th June 2011, 12:31

Still only a few yet implemented it compared to Nvcuvid and Nvcuvenc which almost every Asian Video Converter has now support for ;)
Though Stanley was the first again implementing Intels Encoder (he also was the first implementing Nvidias Encoder) from the less known ISVs in MediaCoder (and free) :)

Sadly, there isn't that much use for such a filter yet, as you need a dedicated card anyway to use madVR. Maybe when Ivy Bridge is near and the 3D performance looks much better. ;)

Or you see how wonderfully DXVA VMR9/EVR can work with Shaders where MadVR isn't supported yet ;)

nevcairiel

9th June 2011, 15:45

Or you see how wonderfully DXVA VMR9/EVR can work with Shaders where MadVR isn't supported yet ;)

Its not that madVR isn't supported, its just that the iGPUs are too damn slow for the resizing shaders that madVR uses - and that won't change with EVR, the shaders will still be too slow. :d

The default resizers in EVR in MPC-HC are just simple bilinear and bicubics, nothing advanced, so it works on all kinds of hardware. If you switch to those in madVR, it also works. But that defeats the point, kinda.

andyvt

9th June 2011, 16:30

Sadly, there isn't that much use for such a filter yet, as you need a dedicated card anyway to use madVR. Maybe when Ivy Bridge is near and the 3D performance looks much better. ;)

It would net hw decode and DI. GPU perf would still be an issue, but it's better than what we have now.

nevcairiel

9th June 2011, 16:40

It would net hw decode and DI. GPU perf would still be an issue, but it's better than what we have now.

A DXVA decoder can already do those, except not with madVR.
I might do it one day when i feel like it, i sometimes have those days where i need to do something cool. :)

andyvt

9th June 2011, 18:17

A DXVA decoder can already do those, except not with madVR.
I might do it one day when i feel like it, i sometimes have those days where i need to do something cool. :)

I hear ya. Definitely something that would be cool, but not a huge benefit yet for the effort required.

edison

9th June 2011, 19:54

something like "SVP"(frame interpolation) ? :)

yesgrey

10th June 2011, 00:39

Sadly, there isn't that much use for such a filter yet, as you need a dedicated card anyway to use madVR. Maybe when Ivy Bridge is near and the 3D performance looks much better. ;)
Another issue is that Sandy Bridge only allows 24.0Hz timings. It's not possible to get 23.976Hz, and we need it for Blu-ray... maybe Ivy Bridge would also solve that.

andyvt

10th June 2011, 00:42

Another issue is that Sandy Bridge only allows 24.0Hz timings. It's not possible to get 23.976Hz, and we need it for Blu-ray... maybe Ivy Bridge would also solve that.

If you disable UAC you get 23.973.

yesgrey

10th June 2011, 00:50

If you disable UAC you get 23.973.
Really? I read that it was some hardware problem that would only be corrected on next model... So I guess that's good news.

andyvt

10th June 2011, 01:02

Really? I read that it was some hardware problem that would only be corrected on next model... So I guess that's good news.

That's true too, although I haven't heard anything concrete on whether it will be addressed in IVB.

yesgrey

10th June 2011, 01:28

That's true too, although I haven't heard anything concrete on whether it will be addressed in IVB.
I read that they have found and solved the problem, but would be included only in a future version. I'm not sure it would be on IVB, though. I guess I read the news on Anandtech's.

nevcairiel

10th June 2011, 06:07

It didn't get in SNB because they rushed out the chipset without much re-design (its a flaw in the PCH, not in the GPU itself).
Lets hope they take enough time to do fix it for IVB this time around, although they did say IVB would run on the 6-series chipset boards, so its unsure if there will be a new chipset generation at all. :(

The 7-series chipset seems to be targeted at SNB-E, but maybe there will also be 7-series chipsets for IVB as well. Only time will tell!