LAV CUVID Decoder - High Quality Hardware decoding for NVIDIA

[CruNcher]

Discreet and IGP work different Generally IGP Nvidia MCPs (ION,ION2) are more efficient (memory copy improvements) then the older Discreet Cards
Also one of the reasons it wont be possible to use a older Nvidia Discreet Card in a mulitplexed Vista/7 enviroment anymore (would be far to slow) :(

[nevcairiel]

Are you sure that you are using lavfsplitter and not Haali Media Splitter with it's option for custom media type for H.264? (unless LAV CUVID already supports 'CCV1' which I admittedly cannot test)

It should support the Haali media type just fine.

[yesgrey]

i just noticed something quite strange, my 9400m has 256mb of video ram, as well as my 8600gt. However, when running lav cuvid and madvr, it appears that my 8600gt runs out of ram while my 9400m runs them comfortably.
The onboard GPUs use your system RAM, so, probably it simply is using more than the 256MB. Try looking at the task manager to see the system memory usage...

[Gleb Egorych]

Hi, nevcairiel!

In ffdshow thread I wrote about combing problem with DVB sources. Unfortunately, LAV CUVID decoder suffers from the same problem as well. Check the discussion here:
http://forum.doom9.org/showthread.php?p=1488062#post1488062
http://forum.doom9.org/showthread.php?p=1488151#post1488151
http://forum.doom9.org/showthread.php?p=1488173#post1488173

Could it be workarounded?

[Ger]

As an ATI user (still), I can't comment on what LAV CUVID does, but I can elaborate on the ffdshow thing if you don't mind the off topic aspect.

FWIW, I just updated my post in that ffdshow discussion (Gleb's second link above) with some additional comments and a link to the sample I was referring to. Basically, I have to use "Force bob" in ffdshow's output tab (applies hw deint also to frames marked as progressive as I understand it) or there will be combing clearly visible with the initial bottle animation. This sample also has an extra problem with field order, so Top field first must also be forced in ffdshow or the picture will "shake". The ffdshow flagging code is here (http://ffdshow-tryout.svn.sourceforge.net/viewvc/ffdshow-tryout/trunk/src/TffdshowDecVideo.cpp?view=markup) currently around line 1339 and the next 60 lines or so.

While forcing these two options are OK for most of my DVB content, there will be problems with occasional bottom field first content, and also the fact that this force bob option triggers frame doubling even for fully progressive 23p files (as seen in MPC-HC's EVR-CP CTRL-J stats). I guess ffdshow profiles can help to some extent, but I didn't bother since I use ffdshow mostly for MPEG-2 anyway and other decoders for other stuff.

I'm also curious if VIDEOINFOHEADER2's dwInterlaceFlags has any effect at all. When I check the pin info, Microsoft, ffdshow seems to set it to 0x00000081 while CoreAVC uses 0x00000000 IIRC. This seems to determine if you see an I or a P in the first line in the EVR-CP stats.

BTW, that sample (and most other MPEG-2 samples I think) also shows a cosmetic issue with LAV Splitter 0.23 (see the video track in filters menu). Sorry, wrong thread again. I'll shut up now. ;)

[n3w813]

This is the error I get when I try to play a mkv with MPC-HC with LAVSplitter and LAVCuvid....

"The following pin(s) failed to find a connectable filter:"

Media Type 0:
--------------------------
Video: MPEG4 Video (H264) 1920x1080 23.98fps

AM_MEDIA_TYPE:
majortype: MEDIATYPE_Video {73646976-0000-0010-8000-00AA00389B71}
subtype: Unknown GUID Name {31435641-0000-0010-8000-00AA00389B71}
formattype: FORMAT_MPEG2_VIDEO {E06D80E3-DB46-11CF-B4D1-00805F6CBBEA}
bFixedSizeSamples: 0
bTemporalCompression: 1
lSampleSize: 1
cbFormat: 166

VIDEOINFOHEADER:
rcSource: (0,0)-(1920,1080)
rcTarget: (0,0)-(1920,1080)
dwBitRate: 0
dwBitErrorRate: 0
AvgTimePerFrame: 417084

VIDEOINFOHEADER2:
dwInterlaceFlags: 0x00000000
dwCopyProtectFlags: 0x00000000
dwPictAspectRatioX: 1920
dwPictAspectRatioY: 1080
dwControlFlags: 0x00000000
dwReserved2: 0x00000000

MPEG2VIDEOINFO:
dwStartTimeCode: 0
cbSequenceHeader: 34
dwProfile: 0x00000064
dwLevel: 0x00000028
dwFlags: 0x00000004

BITMAPINFOHEADER:
biSize: 40
biWidth: 1920
biHeight: 1080
biPlanes: 1
biBitCount: 0
biCompression: AVC1
biSizeImage: 0
biXPelsPerMeter: 0
biYPelsPerMeter: 0
biClrUsed: 0
biClrImportant: 0

pbFormat:
0000: 00 00 00 00 00 00 00 00 80 07 00 00 38 04 00 00 ........€...8...
0010: 00 00 00 00 00 00 00 00 80 07 00 00 38 04 00 00 ........€...8...
0020: 00 00 00 00 00 00 00 00 3c 5d 06 00 00 00 00 00 ........<]......
0030: 00 00 00 00 00 00 00 00 80 07 00 00 38 04 00 00 ........€...8...
0040: 00 00 00 00 00 00 00 00 28 00 00 00 80 07 00 00 ........(...€...
0050: 38 04 00 00 01 00 00 00 41 56 43 31 00 00 00 00 8.......AVC1....
0060: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
0070: 00 00 00 00 22 00 00 00 64 00 00 00 28 00 00 00 ...."...d...(...
0080: 04 00 00 00|00 19 67 64 00 28 ac 34 e5 01 e0 08 ......gd.(¬4å.à.
0090: 9f 96 10 00 00 07 d0 00 01 76 a8 f1 83 19 60 00 Ÿ–....Ð..v¨ñƒ.`.
00a0: 05 68 ef b3 c8 f0 .hï³Èð

[nevcairiel]

Hi, nevcairiel!

In ffdshow thread I wrote about combing problem with DVB sources. Unfortunately, LAV CUVID decoder suffers from the same problem as well. Check the discussion here:
http://forum.doom9.org/showthread.php?p=1488062#post1488062
http://forum.doom9.org/showthread.php?p=1488151#post1488151
http://forum.doom9.org/showthread.php?p=1488173#post1488173

Could it be workarounded?
I only briefly skimmed the posts, but it sounds like you have field order problems, no?

If the field order is wrongly defined in the stream, there is no fix. But thats why there is a configuration option for you to configure the field order.


BTW, that sample (and most other MPEG-2 samples I think) also shows a cosmetic issue with LAV Splitter 0.23 (see the video track in filters menu). Sorry, wrong thread again. I'll shut up now. ;)
What cosmetic issue?
Says "mpeg2video main, yuv420p, 544x576, 15000 kb/s" for me.
You're probably referring to the resolution, because actual display resolution is 720x576? Well, that is the resolution of the encoded bitstream. If some forced aspect ratio makes the renderer scale the pixels - thats unimportant for the splitter really - and the splitter tells the video decoder, for them its unimportant too. They might actually rely on getting the correct (unscaled) values for decoding.

[Gleb Egorych]

I only briefly skimmed the posts, but it sounds like you have field order problems, no?

If the field order is wrongly defined in the stream, there is no fix. But thats why there is a configuration option for you to configure the field order.

Yes, it's a field order problem, "Auto" algorithm often works wrong for PAL DVB streams. I consider it as a bug because, for example, with Cyberlink DXVA and InterVideo DXVA I've never had the problem. Ger wrote:
One problem with the current flagging algo (MatMaul's code IIRC) is that if force bob is used and field order can't be detected the auto field order falls back to bottom field first even for PAL content. Since PAL is nearly always top field first it should fall back to TFF for PAL IMHO.

[nevcairiel]

The hardware decoder itself determines the field order of the content. There is nothing i can do.

There is really not much i can tweak. The NVIDIA driver offers a parser, which analyses the data and prepares it to be decoded. Then it decodes, and all i do is copy the data and send it to the renderer.
Its all a closed system - i get data from the source filter, i pipe data through hardware, i send data off to the renderer. I don't really touch the data unless absolutely necessary to get the hardware to like it.

[Ger]

I will answer the cosmetic issue question in the LAV Filters thread in a sec.

Regarding Gleb's issue:
The combing is AFAIK not caused by field order, but by not deinterlacing (I assume badly flagged) frames tagged as progressive. Don't take my word for it, but this is what the ffdshow "Force bob" option does, at least according to its tooltip. The MPC-HC (software but with interlaced flags set) and Cyberlink (DXVA) decoders seems to always operate this way (but without the double frame rate with progressive content I assume), as there is no combing with hw deint and that clip and those decoders.

Combing is OTOH visible with a lot of MPEG-2 DVB content when ffdshow is in Auto/Auto mode and the same is true for the MS decoder and apparently for LAV CUVID. Force bob takes care of it in ffdshow, but introduces field order issues, and also double frame rate with progressive content (regular 23p avi/xvid played at 47.XX fps according to EVR-CP stats).

At least that's what it seems like to me, but I'm clueless and speculating. Maybe it's more complicated in reality.

There is no quality difference (apart from the combing as described above) between Force bob and Auto in ffdshow. Both are using ATI's vector adaptive. I think, for once, ATI and Nvidia behave the same in this regard (how they respond to different decoders and ffdshow flagging options).

The wrong field order issue is different. That causes a "shaky" picture, not combing. This can be seen with ffdshow set to "Force bob" and leaving the field order on auto or forcing bottom field first with that same sample and the bottle animation. In ffdshow only "Force bob" + "Top field first" makes that sample look "good", like Gleb described in his initial post in the ffdshow thread.

See the code I linked to in my last post in this thread or play with the ffdshow options on the output page with that sample (you can see different results immediately, no need to reload the video) if you're interested.

I don't know if the same flagging options are available with CUVID though. If you don't think they are, then you're probably right as usual. And of course (ATI) I haven't even tested how LAV CUVID works now.

Conclusion: Interlacing sucks. ;)

[skingery]

I've been using Nev's splitter and decoder for a while and everything has been great. Telling newbies about them can get tricky because there are a lot of options in MPC-HC so I'm trying to gather together what people think are good options for the best picture quality.

Been lurking on the threads for a while and it seems if you have the processor and GPU horsepower, people are getting the best results with MPC-HC+MADVR+LAV Splitter+LAV Decoder. Is that about right?

So, if your system is struggling with that, what is the next step down? EVR CP and some resizer? And then the next step down?

I know there are other options like ffdshow and reclock but I'm trying to keep things simple for now.

There are many many hardware combinations out there but if we could get some simple best practices for where to start troubleshooting to get the best picture and performance I think it would be helpful.

[Gleb Egorych]

Yes, it's rather not_deinterlacing, but ffdshow requires not only force interlaced flag but also field order to output properly. Sadly LAV CUVID manual settings don't help to workaround the problem. I tried different combinations of deinterlace options without success. So I guess the solution could require patching stream on the fly.

[nevcairiel]

I can of course also add a flag to force deinterlacing of frames flagged progressive - that much control i do have, i just don't have any control of how those flags are determined.

[yesgrey]

I can of course also add a flag to force deinterlacing of frames flagged progressive
Good idea.

[Weirdo]

Thanks for this excellent decoder! Sorry if this has been addressed already. Does it work with DVD-Video? I can't seem to enable LAV CUVID when playing a VIDEO_TS folder (MPC-HC/EVR custom).

[nevcairiel]

It only works when you directly open the .vob files, dvd navigation mode is currently not supported.

[Weirdo]

It only works when you directly open the .vob files, dvd navigation mode is currently not supported.Thanks, I hope this could be fixed in the future, for both CUVID and madVR.

[Volfield]

Possible bug. I have black screen when play video like this:

Video
ID : 1
Format : AVC
Format/Info : Advanced Video Codec
Format profile : High@L5.1
Format settings, CABAC : Yes
Format settings, ReFrames : 16 frames
Codec ID : V_MPEG4/ISO/AVC
Duration : 23mn 25s
Nominal bit rate : 1 200 Kbps
Width : 640 pixels
Height : 480 pixels
Display aspect ratio : 4:3
Frame rate : 23.976 fps
Color space : YUV
Chroma subsampling : 4:2:0
Bit depth : 8 bits
Scan type : Progressive
Bits/(Pixel*Frame) : 0.163
Title : [Mendoi-SHS-KAA] Inukami! - 15
Writing library : x264 core 54 svn-628M
Encoding settings : cabac=1 / ref=16 / deblock=1:0:0 / analyse=0x3:0x133 / me=umh / subme=7 / brdo=1 / mixed_ref=0 / me_range=32 / chroma_me=1 / trellis=0 / 8x8dct=1 / cqm=0 / deadzone=21,11 / chroma_qp_offset=0 / threads=4 / nr=0 / decimate=1 / mbaff=0 / bframes=5 / b_pyramid=0 / b_adapt=1 / b_bias=0 / direct=1 / wpredb=1 / bime=0 / keyint=250 / keyint_min=25 / scenecut=40(pre) / rc=2pass / bitrate=1200 / ratetol=1.0 / rceq='blurCplx^(1-qComp)' / qcomp=0.60 / qpmin=10 / qpmax=51 / qpstep=1 / cplxblur=20.0 / qblur=0.5 / ip_ratio=1.40 / pb_ratio=1.30

Player: MPCHC, PotPlayer
Render: MADVR, EVR CP
Splitter: Haali, LAV

[patul]

I have jerky x264 playback (unwatchable) if the "Use DXVA Interop Mode" enabled (LAVCUVID v0.4), other than that it is fine.

GF 9500 GT, driver version 266.58.
Haali + LAV CUVID + madVR + PotPlayer

:thanks:

Edit: Updated to 270.61 WHQL Driver, but the problem is still there.

[SamuriHL]

I can't get lav cuvid to connect in mc16. Nev or jmone...have either of you tried it?

[nevcairiel]

I have jerky x264 playback (unwatchable) if the "Use DXVA Interop Mode" enabled (LAVCUVID v0.4), other than that it is fine.

Which OS are you on?
DXVA Interop is known to have issues on XP, but so far it worked fine on 7.

However, it also uses more performance then the "normal" mode, so if your card is nearly maxxed out, that would explain it as well.

I can't get lav cuvid to connect in mc16. Nev or jmone...have either of you tried it?

I didn't try, but there is no reason it wouldn't work.

[patul]

Which OS are you on?
DXVA Interop is known to have issues on XP, but so far it worked fine on 7.

However, it also uses more performance then the "normal" mode, so if your card is nearly maxxed out, that would explain it as well.


Sorry for being unclear at the first place, my OS is XP SP3. And sorry again for not reading two pages back. Should have read entire thread before posting.

:thanks:

[SamuriHL]

I didn't try, but there is no reason it wouldn't work.

Yea I realize it should work but it's not using lav cuvid even though I set it up in the settings. I can bring up the prop page in the configure options but when i play any video it connects to a different decoder. Can you give it a try when you get a chance? Thanks!

[SamuriHL]

Ok, update. I was able to get CUVID working finally. I've learned a few "oddities" about MC16. When configuring the directshow filters, I've found on my AMD machine and my nVidia machine that adding the video decoder first, then ffdshow audio, then ffdshow raw decoder works best. THEN, you must go into the configure page for EACH ONE. Only then does it seem to work for me. In any case, I now have it setup so I can open a blu-ray, as well. Man that is so SWEET! With LAV CUVID and MC16 on my nVidia machine, the CPU usage hovers around 40% which is right where it should be. Oh I am SO happy now! Thanks, Nev, for all your amazing work!

[jmone]

SamuriHL - Just back and tested on my MacBookAir (2010) running Win7 excluisvly with the lowly 320G GPU and I'm playing a Blu just fine (over wireless even) with LAVSplitter, LAV CUVID, FFDSHOW, madVR. No prob and all smooth with both cores running at around 50%. How good is that! + no issues for me with the config at all in MC16 - it all just worked immediatly.

[jmone]

SamuriHL - I can also load the FFDSHOW Subtitle Filter just fine (without it crashing MC) though it adds about 10% to the CPU Utlilisation. Oddly however, I'm back to the subtitles "not displaying" however after a say 30secs. As I updated FFDSHOW, madVR, LAV (all) I'm not sure what changed (and this will no doubt be the wrong thread anyway)!

[SamuriHL]

Glad it's working for you. I've had no further issue with lav cuvid since I got it working. Watched some recorded shows in MC last night with cuvid...flawless. the ffdshow suvpb filter crashes MC on both my htpc's if I add it.

[joeydrunk]

So I'm running Windows 64x, ffdshow 64x and mpchc 64. So will this work on w64? Will I just have to use the 32bit versions of mpc-hc and ffdshow to be able to use this?

[nevcairiel]

64-bit is currently not supported, so yes, if you want to use this, you need 32-bit versions of mpc-hc and ffdshow. In the future, there might be a 64-bit version available. I'm currently low on time and working on my other projects instead. :p

[SamuriHL]

Forget 64 bit. You're wanting to use madVR so you're stuck with 32 bit for a long, long time. :D

[PeQuE]

Anyone here tried LAV CUVID under MediaPortal? I gave it a try yesterday. All went well, smooth, good performance, but I can't play any file with AVC video stream inside... MediaPortal tells me there's no dshow filter available for this kind of content... On the other hand, HDTV (which video stream in fact is also H264) is working well (I'd say better than any other filter tried by me, included MS DTV and last PDVD11). Also I've tried to play that same file with Graphstudio and using LAV CUVID as video filter, no problem at all.

Thanks a lot!

[nevcairiel]

LAV CUVID Decoder 0.5

0.5 - 2011/04/30
- Added YV12 as an supported output format
- Refactored CUDA/CUVID initialization
- Deny connection if the source filter indicates an unsupported H264 profile
- Improvements to dynamic media type changing

Download: 32-bit (http://files.1f0.de/cuvid/LAVCUVID-0.5.zip)

Wewt! Man i have not written assembler for so long, that was really fun. Wrote some MMX function which helps in the NV12->YV12 conversion. I hope its actually faster then the C code, i couldn't really test it, for me the filter is limited by the hardware decoding performance... But it certainly wasn't slower. :)

With YV12 output, it is now possible to use LAV CUVID with DirectVobSub, if anyone would want to. I bet there is that occasional weird renderer that doesn't like NV12..
NV12 is still the preferred output, because it doesn't require conversion.

Anyhow, i hope this fixes the black screen bugs you sometimes got on startup, and might even work better for live tv with channel changes and such - although that feature is not heavily tested.

Have fun!

[CruNcher]

- Deny connection if the source filter indicates an unsupported H264 profile

Noooooo only H.264 ? whats about Mpeg-2 Studio Profile ?

[nevcairiel]

MPEG2 profiles are not usually exported in the media type.

[CruNcher]

but you could get it @ least from lav splitter directly :)

anyway if you find a workaround (fix) for this http://forum.doom9.org/showpost.php?p=1493989&postcount=369 i will change entirely from DXVA to Lav CUVID :D
except for WMV9 in .wmv which doesn't work yet with LAV CUVID ;)

Though im not sure why it happens for the Battlefield Bitstream after 1:17 so stays stable for so long 77 seconds instead of 12 seconds with the wipeout clip, though im also not sure if you even can fix this from outside or if Nvidia would have to look @ nvcuvid directly and change maybe the buffering for these cases and VP2 with 512 MB, though Cyberlink also found a way to prevent that from within DXVA.

[SamuriHL]

Thanks, Nev. I understand the reason for the colorspace conversion. :) It means I could now, if I wanted to, use DirectVobSub on my nVidia box at least. No Cyberlink BS on that machine. :)

[Sebastiii]

Thanks :) i really have to have a new card :)
Seb.

[Tom Keller]

With YV12 output, it is now possible to use LAV CUVID with DirectVobSub, if anyone would want to. I bet there is that occasional weird renderer that doesn't like NV12..
NV12 is still the preferred output, because it doesn't require conversion.
Thanks for that :) ! But would it be possible to add an option to the configuration dialog for forcing one specific output format manually (something like a selection between "Auto/NV12/YV12")?

[CruNcher]

New build brakes a Mpeg-2 sample :(
tried with both MPC-HC Splitter/Lav Splitter it worked with both and 0.4 it brakes with 0.5 it plays some frames and then freezes :(

It only brakes on VMR9 now with that sample works with others (VMR7,MadVR) with 0.4 it works on VMR9 :(

[VFR maniac]

0.5 build breaks resized playback.
For instance, when I seek somewhere, or reach the end of a movie and play it as repeating, then display size is reverted to original size.

[nevcairiel]

0.5 build breaks resized playback.
For instance, when I seek somewhere, or reach the end of a movie and play it as repeating, then display size is reverted to original size.

previous versions also did that. :p

[CruNcher]

another one bites the dust no connection anymore :(

[VFR maniac]

previous versions also did that. :p

What!?
Certainly oldest versions also reproduced that but 0.4 didn't at least in my environment.

[CruNcher]

So finaly 3 streams broke with 0.5 in some way :(

The High10 and High 4:2:2 fallback works marvelous :)
and it is stable again in terms of reloading as before 0.4 :)

The disconnection of 1 of the 3 streams seems to be an issue with the new fallback for non supported streams though that stream works without any issues on 0.4 and is baseline even, yep it fallsback i really wonder why :P

Here is the stream that fallsback but wouldn't need to http://www.mediafire.com/download.php?3xjrymbaigi9mpl its a old one that also made problems with lav splitter some revs ago ;)

So 2 streams are actually really problematic because it's a renderer dependent issue in 0.5 now (VMR9) :(

[nevcairiel]

The disconnection of 1 of the 3 streams seems to be an issue with the new fallback for non supported streams though that stream works without any issues on 0.4 and is baseline even, yep it fallsback :P

So what does the media type say?
Any profile > 100 (0x64) will be declined - thats the only check happening.

[CruNcher]

profile_idc is 66 baseline

its dwProfile: 0x00000242

here are the streams that fail on VMR9 with 0.5 now (work perfect with 0.4 and before triple checked)

http://www.mediafire.com/download.php?jp43ralx7i8bi29

[nevcairiel]

its dwProfile: 0x00000242


242? that doesn't look right, not right at all. Of course it would fail with that.


http://www.mediafire.com/download.php?jp43ralx7i8bi29

I can reproduce the problem with VMR9 renderless, although i'm not doing anything i'm not supposed to do, the renderer must just be stupid.
It just sends a new media type, which it is supposed to do. Like, if the aspect ratio changes or something, we have to send a new type - if then the video freezes .. well, broken renderer. :P

[nevcairiel]

LAV CUVID Decoder 0.6

0.6 - 2011/05/01
- New Media Types will only be generated when attributes actually changed
- The size changed event will only be triggered when size or aspect ratio changed

Download: 32-bit (http://files.1f0.de/cuvid/LAVCUVID-0.6.zip)

These two changes fix playback with VMR-9, which is apparently an extra stupid renderer that just freezes when you send it a new media type. Silly thing.
Additionally, the size of the player should only change when the stream changes - that is the AR in the stream changes, or the video size itself. Dunno if the size can change, but the AR can certainly change mid-stream. :)

Good Night! :p

[SamuriHL]

Thanks, Nev! I'll try this out tonight.

[CruNcher]

LAV CUVID Decoder 0.6

0.6 - 2011/05/01
- New Media Types will only be generated when attributes actually changed
- The size changed event will only be triggered when size or aspect ratio changed

Download: 32-bit (http://files.1f0.de/cuvid/LAVCUVID-0.6.zip)

These two changes fix playback with VMR-9, which is apparently an extra stupid renderer that just freezes when you send it a new media type. Silly thing.
Additionally, the size of the player should only change when the stream changes - that is the AR in the stream changes, or the video size itself. Dunno if the size can change, but the AR can certainly change mid-stream. :)

Good Night! :p

Perfect fixed, and yes its not really normal that it freezes VMR9 AR switching works fine in other decoders :)