Log in

View Full Version : LAV CUVID Decoder - High Quality Hardware decoding for NVIDIA


Pages : 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 [21] 22 23 24 25 26 27 28

Xaurus
14th August 2011, 00:55
I am also struggling with 1080i. Using a 570 GTX. The problems arise when there is "scrolling" in the film, for example a great test part is the 1080i version of the last episode of Game of Thrones, around 6-7 minutes when the Stark mother is in the woods and you can see lots of trees scrolling infront of her, from left to right. They are jerky and I have yet to find a proper way of making this smooth.

jmone
14th August 2011, 07:03
I have no issues with any of the interlaced formats with LAVCUVID including:
- VC1 1080-60i
- AVC 1080-60i
- AVC 1080-50i

More discussion and samples in this thread over at MC16 http://yabb.jriver.com/interact/index.php?topic=64782.msg441197#msg441197

Infact it is the one reason I swaped from ATI to an nvidia GPU as the LAVCUVID is the only one that can properly deinterlace VC1(i) !

CruNcher
14th August 2011, 08:40
there is more :) then just the 60i there are different methods :)

fieldinterlaced
frameinterlaced
then mixes of frame-field interlaced + progressive

I am also struggling with 1080i. Using a 570 GTX. The problems arise when there is "scrolling" in the film, for example a great test part is the 1080i version of the last episode of Game of Thrones, around 6-7 minutes when the Stark mother is in the woods and you can see lots of trees scrolling infront of her, from left to right. They are jerky and I have yet to find a proper way of making this smooth.

sample ?

Xaurus
14th August 2011, 13:41
sample ?

I have just the whole episode...

Aegwyn11
14th August 2011, 16:16
I chopped the credits off the end of an episode of Human Planet, but the file's still almost 80 MB. Where's the best place to upload such a file?

nevcairiel
14th August 2011, 16:18
www.mediafire.com

mindbomb
14th August 2011, 16:21
you guys, try using lav splitter with lav cuvid if you aren't already doing so.

nevcairiel
14th August 2011, 16:24
Especcially with VC-1 its certainly possible that other splitters are doing a sub-par job at timestamping it. It took me quite a while to get VC-1 "just right".

Aegwyn11
14th August 2011, 16:52
Let me know if this doesn't work:

http://www.megaupload.com/?d=WDG3KNY1

I also have more information. Using this sample, I did some testing using the latest versions of LAV Splitter and Haali and got some interesting results. Here's my findings:

LAV Splitter (VC-1 timestamp correction totally disabled) and Haali:
Exclusive mode - constant jerkiness
Windowed mode - smooth as can be, perfect

LAV Splitter (VC-1 timestamp correction partially enabled or fully enabled):
Exclusive mode - periodic jerks as described above
Windowed mode - same as exclusive mode

nevcairiel
14th August 2011, 17:03
The second mode is the mode its supposed to be played at with LAV CUVID, however you're right that there is an occasional glitch. It appears that the timestamps are not being processed perfectly, i am however not sure if thats the splitters fault or LAV CUVIDs fault. I'll do some investigation.

For the first mode, it works with windowed mode because madVR has some special logic in there to fix timestamps, however that doesnt work in exclusive mode anymore because all frames are immediately rendered.

nevcairiel
14th August 2011, 17:37
LAV CUVID Decoder 0.10

0.10 - 2011/08/14
- Refuse connection to MPEG-2 4:2:2 material
- Improved VC-1 interlaced timestamp handling

Download: Installer (32/64-bit, CUDA 4.0+) (http://files.1f0.de/cuvid/LAVCUVID-0.10.exe) - 32-bit (CUDA 4.0+) (http://files.1f0.de/cuvid/LAVCUVID-0.10.zip) - 64-bit (CUDA 4.0+) (http://files.1f0.de/cuvid/LAVCUVID-0.10-x64.zip) -- 32-bit (Older CUDA) (http://files.1f0.de/cuvid/LAVCUVID-0.10-LegacyCUDA.zip)

The timestamp fixes are rather temporary and might as well blow up in my face again, but it worked smoothly on all files i just tested on.
I'll be working on a much improved timestamp handling soon, so that it'll be future proof and also work better with Haali.

In the meantime, using LAV Splitter with "VC-1 timestamp correction" set to "auto" (half-checked), it should work smoothly.

madshi
14th August 2011, 17:42
I'll be working on a much improved timestamp handling soon, so that it'll be future proof and also work better with Haali.
I've been thinking about using the same logic for VC-1 which ffdshow uses for MPEG2, namely syncing to I-frames, only, and interpolating the timestamps for B- and P-frames. Shouldn't that work well for VC-1, too? I think it might make the decoder work smoothly for both types of splitter timestamps (PTS and DTS). Haven't tested it yet, though.

Thoughts?

nevcairiel
14th August 2011, 17:46
I've been thinking about using the same logic for VC-1 which ffdshow uses for MPEG2, namely syncing to I-frames, only, and interpolating the timestamps for B- and P-frames. Shouldn't that work well for VC-1, too? I think it might make the decoder work smoothly for both types of splitter timestamps (PTS and DTS). Haven't tested it yet, though.

Thoughts?

Sadly, thats won't really work. That theory would only work out 100% on frames where PTS=DTS, but thats not true for I-Frames if B-Frames are present. So it would produce different results with the two different demuxing modes. Sadly, i don't think there is a universal solution that works for all splitters equally.

What i do in LAV Video seems to work so far. I support both modes, and have to add all splitters that deliver PTS to a internal list. I know, its not the best way, i probably need to keep maintaining that list for ages, but the most commonly used splitters are covered (Haali, LAV and MPC-HC). Only other TS splitters will probably need to be added eventually.

My plan for LAV CUVID is quite simple, i'll switch LAV Splitter over to delivering DTS, and then just need to figure out how to assign the incoming timestamps back to the outgoing timestamps in LAV CUVID, because right now i do not know the delay (in frames) introduced by the decoder. But that should be doable. ;)
The good thing about this solution is that as a by-product it'll also fix the timestamp issues of MPEG-4 ASP. :)

madshi
14th August 2011, 18:32
Sadly, thats won't really work. That theory would only work out 100% on frames where PTS=DTS, but thats not true for I-Frames if B-Frames are present. So it would produce different results with the two different demuxing modes.
That's too bad.

My alternative idea was to simply monitor the incoming timestamps. It should be easy enough to automatically detect whether the incoming timestamps are DTS or PTS, and to adjust the decoder behaviour accordingly. For the first couple of frames the decoder might then use the wrong logic, but that shouldn't be too much of a problem. In theory the decoder could even store the detected logic to the registry, so the next time it will be right from the start. This way no manual list needs to be maintained.

Aegwyn11
14th August 2011, 18:44
Makes sense I think. I installed your new version of CUVID and it all seems happy now (at least with the one clip that I uploaded). I'll let you know if I notice any other goofyness with VC-1. Thanks!!

ranpha
14th August 2011, 21:23
The timestamp feature now makes this XviD clip (http://goo.gl/8I09y) watchable with LAV CUVID + madVR. Last time, I have to use EVR custom presenter + FTC for it to work smoothly. I hope that when the timestamp feature become final, these kind of files will still work in the future.

nevcairiel
14th August 2011, 23:02
I tried to figure out what to do about timestamps as a final solution, but i couldn't come up with something good yet.
The NVIDIA decoder doesn't make it easy on you to take over the timestamp management yourself. It doesn't let me know when it dropped a frame due to missing references (after seeks), or general corruption, not to mention the variable decoding delay due to the pipelining in the hardware, so its really not trivial to map incoming timestamps back onto the decoded frames.
I think i have to be creative about this. We'll see how this all works out.

The goal is of course to keep XviDs working, and for now the temporary fix seems to do its job.

CruNcher
14th August 2011, 23:17
@Nev sniff it doesn't fall back to Lav Video for Mpeg-2 4:2:2 it still tries to playback it :(

nevcairiel
14th August 2011, 23:18
@Nev sniff it doesn't fall back to Lav Video for Mpeg-2 4:2:2 .ts it still tries to playback it :(

Works for me. :)

CruNcher
14th August 2011, 23:22
Hmm strange i set both on prefered and Mpeg-2 is active and all 4:2:2 gets rendered with Lav Cuvid :(

http://img708.imageshack.us/img708/4932/lavcuvidtakesit.png

nevcairiel
14th August 2011, 23:31
It of course only works if the splitter provides a proper sequence header. The 422 mpeg2 ts I tested worked just fine with lav splitter.

CruNcher
14th August 2011, 23:51
Yep works now perfect :)

mkanet
15th August 2011, 01:04
Hi, I would love to be able to use this video decoder with my Nvidia card 8500GT. I currently use CoreAVC 2.5.5 for H.264 CUDA decoding (Verifying full Cuda compatibility).

I am currently trying to use LAV CUVID in graphedit to playback a VC1 m2ts file. Is there a reason why I HAVE to manually set "VC1" in the decoder's prop page in order to connect it to LAV splitter?

The filter graph is almost finished when I manually connect the respective filters, however, I cant get the LAV CUVID pinout to connect to ANY video renderer. I can't right-click and select render pin either. I get the error: "Sorry, the Filter Graph cannot render this pin.".

Is there something I need to do prior to regsvr32 installing the CUVID Decoder? I didnt use the Windows 32bit installer to install CUVID. I only extracted the zip file I downloaded in to a folder and double-click the install.bat file to register the filter. I'm pretty sure I must be missing something very basic.

OS: 32bit Windows Vista SP2

Thanks!

mindbomb
15th August 2011, 02:51
what nvidia drivers are you using?

mkanet
15th August 2011, 03:23
I have the current WHQL driver on Nvidia's website. Driver versions don't make any difference for me in the last several months; at least for CoreAVC (with full CUDA support).

what nvidia drivers are you using?

ranpha
15th August 2011, 04:06
Maybe it has something to do with the fact that your 8500GT GPU doesn't support VC-1 decoding.

mkanet
15th August 2011, 05:14
Same thing with H.264.

Maybe it has something to do with the fact that your 8500GT GPU doesn't support VC-1 decoding.

Superb
15th August 2011, 08:49
Then you didn't install it correctly. Did you run the install.bat as an administrator? Did you keep the .ax file in the same folder after you've installed it?
Simply use the installer provided in the first post of this thread.
8500GT doesn't do VC-1 CUDA decoding, but H.264 should work.

nevcairiel
15th August 2011, 08:50
You should actually get partial acceleration of VC-1 with the 8500GT.

The only thing you need for LAV CUVID to function is the proper hardware, and a renderer that accepts NV12 or YV12. (I believe Haalis renderer does not, but all default Windows renderers do)

Superb
15th August 2011, 09:00
Partial acceleration? w/ LAV CUVID? What does the rest of the decoding? Does CUDA use CPU for the rest? Does the filter itself?

nevcairiel
15th August 2011, 09:28
The NVIDIA decoder does the required parts on the CPU then, offloading IDCT and MC to the GPU.

mkanet
15th August 2011, 12:45
I dont do anything differently for this decoder than I do with other filters I install. The .ax file never changed folders from original time I regsvr32'ed it. Used administrator account (if I didn't, I dont think the filter would install or show up in graphedit.

I have no problems doing partial VC1 hardware decoding using other decoders such as WMVideo Decoder DMO and MPC HC Video. The same problem happens when trying to decode H.264. No video renderers want to connect to it.

I have a small clue possibly. I noticed that the settings in the filter prop page dont stay. If I click on various settings such as H.264, VC-1, etc, the next time I open the prop page, the settings are not there.

What could cause the filter not to retain it's settings? Is the filter sensitive to which folder location?

Then you didn't install it correctly. Did you run the install.bat as an administrator? Did you keep the .ax file in the same folder after you've installed it?
Simply use the installer provided in the first post of this thread.
8500GT doesn't do VC-1 CUDA decoding, but H.264 should work.

Gleb Egorych
15th August 2011, 19:33
nevcairiel, do you have any plans to implement forced deinterlacing for bad flagged material? There was some discussion about that a few months ago, I wonder if it's in your TODO list.

nevcairiel
15th August 2011, 19:35
Interlacing isnt "flagged", a frame either is progressive, or its interlaced. There is a clear difference in coding the image, you cannot mess that up in a bad encode. :p

e-t172
15th August 2011, 20:02
I frequently stumble upon files which seem to have been encoded after a "weave" filter… I know, it's disgusting, but it would be useful to have an option to do something about it.

Gleb Egorych
15th August 2011, 20:38
nevcairiel, I meaned interlaced material with wrong field order flag. Such streams appear rather often over DVB.

nevcairiel
15th August 2011, 20:40
nevcairiel, I meaned interlaced material with wrong field order flag. Such streams appear rather often over DVB.

You can already configure the field order.


I frequently stumble upon files which seem to have been encoded after a "weave" filter… I know, it's disgusting, but it would be useful to have an option to do something about it.
You wouldn't happen to have a sample of that at hand, so i can see if i can force it to deinterlace progressive material?

jazzysmooth
16th August 2011, 01:31
I dont do anything differently for this decoder than I do with other filters I install. The .ax file never changed folders from original time I regsvr32'ed it. Used administrator account (if I didn't, I dont think the filter would install or show up in graphedit.

I have no problems doing partial VC1 hardware decoding using other decoders such as WMVideo Decoder DMO and MPC HC Video. The same problem happens when trying to decode H.264. No video renderers want to connect to it.

I have a small clue possibly. I noticed that the settings in the filter prop page dont stay. If I click on various settings such as H.264, VC-1, etc, the next time I open the prop page, the settings are not there.

What could cause the filter not to retain it's settings? Is the filter sensitive to which folder location?

My only suggestion is to review my posts #589 (http://forum.doom9.org/showthread.php?p=1501577#post1501577) and #595 (http://forum.doom9.org/showthread.php?p=1501847#post1501847) - it was Nvidia driver related in my case. I have since went and purchased a GT430 and no problems since.

leeperry
16th August 2011, 03:41
As much as I wasn't lucky w/ your splitter on XPSP3, this decoder looks pretty darn amazing on my 96SP 8800GS http://forum.slysoft.com/images/smilies/agreed.gif

Why accepting the "XVID" FourCC and not "DX50/XviD/xvid"? Couldn't it also do DivX3 and so? I can't get it to decode any MPEG-4 so far tbh...not even "XVID".

And I thought VC1 was just a WMV9 profile? No chance of decoding WMV1/3/9 using backward compatibility? Anyway, seeking in VC-1 ended up in pixelated garbage when using the built-in ffdshow decoder, now it's flawless :cool:

Also, I had to make it output YV12 otherwise everything looked blue in NV12 when post-processing in ffdshow(using the 275.33 drivers): http://thumbnails46.imagebam.com/14527/059281145260832.jpg (http://www.imagebam.com/image/059281145260832) http://thumbnails43.imagebam.com/14527/4fb5f4145260834.jpg (http://www.imagebam.com/image/4fb5f4145260834)

same problem for h264 and vc1...I haven't tried w/o ffdshow, though.

:thanks:

betaking
16th August 2011, 07:34
As much as I wasn't lucky w/ your splitter on XPSP3, this decoder looks pretty darn amazing on my 96SP 8800GS http://forum.slysoft.com/images/smilies/agreed.gif

Why accepting the "XVID" FourCC and not "DX50/XviD/xvid"? Couldn't it also do DivX3 and so? I can't get it to decode any MPEG-4 so far tbh...not even "XVID".

And I thought VC1 was just a WMV9 profile? No chance of decoding WMV1/3/9 using backward compatibility? Anyway, seeking in VC-1 ended up in pixelated garbage when using the built-in ffdshow decoder, now it's flawless :cool:

Also, I had to make it output YV12 otherwise everything looked blue in NV12 when post-processing in ffdshow(using the 275.33 drivers): http://thumbnails46.imagebam.com/14527/059281145260832.jpg (http://www.imagebam.com/image/059281145260832) http://thumbnails43.imagebam.com/14527/4fb5f4145260834.jpg (http://www.imagebam.com/image/4fb5f4145260834)

same problem for h264 and vc1...I haven't tried w/o ffdshow, though.

:thanks:
GeForce 8800 GS, 8800 GT, 8800 GTS (512 MB/1 GB)

G92

VP2

A

October 2007
Feature Set A
Complete acceleration for H.264
Partial acceleration for MPEG-1, MPEG-2, VC-1/WMV9

nevcairiel
16th August 2011, 09:44
Why accepting the "XVID" FourCC and not "DX50/XviD/xvid"?

It accepts XVID, xvid, DIVX, divx, DX50, dx50, MP4V, mp4v, M4S2, m4s2, MP4S, mp4s.


Couldn't it also do DivX3 and so?

No, DivX3 is whats called "MS-MPEG4", its not ISO MPEG4-ASP. There is a significant difference, and the hardware doesn't support it.


I can't get it to decode any MPEG-4 so far tbh...not even "XVID".

Your hardware is not capable of decoding XVID. You need a VP4/VDPAU Level C card for that.


And I thought VC1 was just a WMV9 profile? No chance of decoding WMV1/3/9 using backward compatibility?

It is, but for some reason feeding it WMV3 content doesn't work. The NVIDIA decoder just refuses.


Also, I had to make it output YV12 otherwise everything looked blue in NV12 when post-processing in ffdshow(using the 275.33 drivers):
Yeah, thats a stupid ffdshow bug.


@Everyone:
I noticed a issue with my timestamp hack for VC-1. With 0.10, VC-1 in MKV will only properly work with LAV Splitter, any other splitter will probably make the image look absolutely non-smooth.
I'm working on a new way to deal with this. VC-1 in MPEG-TS should work with the MPC-HC splitter, with Haali its a hit-or-miss. :)

jmone
16th August 2011, 10:16
@Everyone:
I noticed a issue with my timestamp hack for VC-1. With 0.10, VC-1 in MKV will only properly work with LAV Splitter, any other splitter will probably make the image look absolutely non-smooth.
I'm working on a new way to deal with this. VC-1 in MPEG-TS should work with the MPC-HC splitter, with Haali its a hit-or-miss. :)

So what containers with VC-1 work well with LAVSplitter? I've been remuxing my HD-DVD (mostly VC-1) to:
- Movies: Blu-ray stucture
- TV Eps: M2TS files

nevcairiel
16th August 2011, 10:16
With LAV Splitter, any container is fine.

jmone
16th August 2011, 10:21
Of course :)

mkanet
16th August 2011, 13:30
From what I understand, CUVID works even an 9x00 Nvidia card using any recent Nvidia driver. I'm not sure on this, but I thought the Nvidia 8500GT should be very similar; if not identical to the 9400GT/9600GT in respect to GPU capabilities; at least it doesnt make any difference when using CoreAVC with full CUDA support for H.264 decoding.

I'm curious if CUVID is supposed to save it's settings when you make changes to it's settings (in the prop page). For me, in graphedit, as soon as I make the CUVID settings changes, if I go back in to verify the settings, they all disapear again; and, have to select the again. I wonder if this can be fixed with an updated CUVID decoder.

My only suggestion is to review my posts #589 (http://forum.doom9.org/showthread.php?p=1501577#post1501577) and #595 (http://forum.doom9.org/showthread.php?p=1501847#post1501847) - it was Nvidia driver related in my case. I have since went and purchased a GT430 and no problems since.

nevcairiel
16th August 2011, 15:02
@Everyone:
I noticed a issue with my timestamp hack for VC-1. With 0.10, VC-1 in MKV will only properly work with LAV Splitter, any other splitter will probably make the image look absolutely non-smooth.
I'm working on a new way to deal with this. VC-1 in MPEG-TS should work with the MPC-HC splitter, with Haali its a hit-or-miss. :)

Here is a new test build with a new way to calculate timestamps for VC-1 and MPEG4 ASP.

http://files.1f0.de/cuvid/LAVCUVID-0.10-timestamps.zip

In my limited testing, it worked quite good, with all splitters. But, its really an experimental feature, and i don't know how well it'll work out with all those weird and odd files out there.

If you're using LAV Splitter, i recommend to set the "VC-1 timestamp correction" to completely off. Thats the best way for LAV CUVID now, and the next version of LAV Splitter will have the "auto" mode changed according to that.

Gleb Egorych
16th August 2011, 17:49
You can already configure the field order.
It doesn't solve the problem. ffdshow has the same problem, but there is a workaround to force bob and TFF. Unfortunately the trick doesn't work in LAV CUVID Decoder.

Alexey1975
17th August 2011, 04:56
It doesn't solve the problem. ffdshow has the same problem, but there is a workaround to force bob and TFF. Unfortunately the trick doesn't work in LAV CUVID Decoder.

Thank you Nevcairiel for your Great and Valuable Job!
Just only one request for your LAV CUVID Decoder: It desperately lacks of "Always Do Deinterlace" option!
Please, add it.

Is it possible to do at all?

leeperry
17th August 2011, 10:00
Your hardware is not capable of decoding XVID. You need a VP4/VDPAU Level C card for that.

OK, thanks for the replies! I wonder if it'd be worth it to buy a newer graphic card in order to achieve a lower power consumption? I've got a wattmeter so I could also double-check and post figures.

OTOH, the GT520 with the newest VP5/D features only has 48SP, so it would suck for both games and mVR+LAV CUVID I think?

But apparently the VP4 boards provide a more thorough h264/VC1 hardware support, and XVID/DX50 support could help too. My 8800GS is VP2/A.

This said, I'm thrilled to see that your decoder can do hardware double frame rate on 29.97 material....I really don't like how YADIF looks plus it'd leave the CPU free, and I keep reading that the nvidia drivers rock at this :devil:

nevcairiel
17th August 2011, 10:04
The 520 is too slow for deinterlacing, and dont even think about gaming with it. :)

I don't think its actually saving that much power, if any at all.