LAV CUVID Decoder - High Quality Hardware decoding for NVIDIA

[Xaurus]

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]

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/inde...1197#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]

there is more then just the 60i there are different methods

fieldinterlaced
frameinterlaced
then mixes of frame-field interlaced + progressive

Originally Posted by Xaurus

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]

Originally Posted by CruNcher

sample ?

I have just the whole episode...

[Aegwyn11]

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]

www.mediafire.com

[mindbomb]

you guys, try using lav splitter with lav cuvid if you aren't already doing so.

[nevcairiel]

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]

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]

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]

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+) - 32-bit (CUDA 4.0+) - 64-bit (CUDA 4.0+) -- 32-bit (Older CUDA)

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]

Originally Posted by nevcairiel

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]

Originally Posted by madshi

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]

Originally Posted by nevcairiel

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]

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]

The timestamp feature now makes this XviD clip 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]

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]

@Nev sniff it doesn't fall back to Lav Video for Mpeg-2 4:2:2 it still tries to playback it

[nevcairiel]

Originally Posted by CruNcher

@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]

Hmm strange i set both on prefered and Mpeg-2 is active and all 4:2:2 gets rendered with Lav Cuvid