LAV CUVID Decoder - High Quality Hardware decoding for NVIDIA

[nevcairiel]

LAV CUVID is DEAD. All of its functionality has been merged into LAV Video (http://forum.doom9.org/showthread.php?t=156191). LAV CUVID will not be developed any further.

------------------------------------------------------------------------------------------------------

Hi folks,

i would like to introduce my LAV CUVID Decoder.
It is a DirectShow Video Decoder utilizing the NVIDIA hardware decoder engine through the CUDA Video Decoding API ("CUVID").

Its still in its early stages, but its already been tested thoroughly and supports all major formats that the NVIDIA hardware can decode, which are right now H264, VC-1, MPEG2 and MPEG4-ASP (DivX/Xvid). Both progressive and interlaced types are supported.

As a bonus, when decoding interlaced content, it can do full adaptive deinterlacing, the best your GPU has to offer.

So, without further introduction, here it is!

Features
- Decoding of H264, VC-1, MPEG2 and MPEG4-ASP (each given appropriate hardware support)
- Full Adaptive Deinterlacing, including Frame Doubling (perfect smooth playback of 1080i/60 content!)
- Usable with all renderers! Including madVR (http://forum.doom9.org/showthread.php?t=146228), which is recommended for the best playback quality!
- NV12/YV12 output

Download
Source Code is available from my Git repository (http://git.1f0.de/gitweb?p=lavcuvid.git;a=summary)

Binarys are available here:

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

A note on the different versions: The CUDA 4.0 builds require a 270 series driver (or newer). The "Old CUDA" build should in theory work with much older drivers, in case you cannot upgrade.

Changelog -- Full changelog (http://git.1f0.de/gitweb?p=lavcuvid.git;a=blob;f=CHANGELOG.txt;hb=HEAD) -- Release Notes (http://forum.doom9.org/showthread.php?p=1525979#post1525979)
0.13 - 2011/09/13
- Improved resource release behavior
- Improved VC-1 in EVO with pulldown flags

[nevcairiel]

This is a decoder for NVIDIA GPUs, it does not work with ATI/AMD or Intel, and it never will!

Requirements/Recommendations
- NVIDIA PureVideo HD capable graphics card (VDPAU Feature Set A or better - see list here (http://en.wikipedia.org/wiki/Nvidia_PureVideo#Table_of_PureVideo_.28HD.29_GPUs))
- At least 256MB of Video RAM, 512MB recommended
- Recent NVIDIA Drivers - CUDA 4.0 compatible driver recommended (270 series), older drivers may work with the "Old CUDA" build.
- Vista/7 recommended due to much improved driver handling, but XP SP3 "should work" (see hints below)

Performance
- 1080p60 decoding is only supported on VP4 hardware (VDPAU Feature Set C)
- When encountering performance issues, turning off the "HQ DXVA processing" option will yield the best gain in performance, at a minimal loss of quality.
- Using the latest driver (275.33 at the time of writing), can greatly improve the performance.

Hints
- When running on Windows XP, its recommended to turn the "Use HQ DXVA processing" setting off, its not fully supported on XP and might cause image corruption.


Known Issues
- The decoder will try to decode all video streams, and not refuse formats that are not supported.
- VC-1/MPEG4-ASP VFR content will most likely not play properly.

reserved for FAQ, etc.

[nevcairiel]

To say a few words about 0.1:

First: This is a very early test version, it can quite possibly blow up.

It comes without any configuration, and its only tested on VP4 (Fermi) hardware.
In the future, you will be able to configure things like:
- Use Stream Aspect Ratio (currently always on)
- Which Codecs should be active
- Should Deinterlacing be performed (currently always in "adaptive" mode)
- And whatever i can think of.

Also, it only supports NV12 output. This might change in the future, but any conversion of course gives you a performance penality, and NV12 is the native format of the decoder.

Oh, and if you're using it together with LAV Splitter on interlaced VC-1, make sure to disable the VC1 timestamp correction in the LAV Splitter settings. The next version of LAV Splitter will have this decoder added to the auto-detect mode.

BTW, if anyone is good with assembler, i could need some asm function which changes the stride of a NV12 image. My C implementation is probably quite slow.

[Sebastiii]

Amazing :)

Can't register filter, maybe need minimum driver version or hardware (9600GT) ?
Thanks.

[adam777]

Hi nev,
I'm unfortunately unable to utilize this decoder due to my laptop being equipped with an ATI card, but I suggest writing as clear as possible why ATI can't be supported, at least for the foreseeable future.
I suppose it won't be long before this question starts popping up.

[BatKnight]

When I use your LAV CUVID Decoder to play a 1280x688 movie at a 1920x1080 resolution in MPC-HC, what is doing the upsample? My GPU? The MPC-HC?

When I used ffdshow I had an Avisynth script to spline36resize my videos to 1920x1080, but when using CUVID I no longer know if it is being done by the graphics card (would this be a good thing, quality-wise?) or being done by what I have selected at the MPC-HC Resizer's drop-down box.

Nuno

[nevcairiel]

The decoder does not do any upscaling, so it'll be the renderer MPC-HC uses.


Can't register filter, maybe need minimum driver version or hardware (9600GT) ?

Which driver are you using?
The CUDA SDK 3.2 is relatively new (Jan. 2011), could be that you need at least a 260 series driver.

I can probably use a bit older SDK, and switch to dynamically loading the dlls, so such issues can be avoided.

For Hardware Support, Wikipedia to the rescue. You need at least VDPAU Feature Set A for H264 decoding, B for VC-1 and MPEG2, and C for MPEG4-ASP.
http://en.wikipedia.org/wiki/Nvidia_PureVideo#Table_of_PureVideo_.28HD.29_GPUs

The 9600GT is a "A" Feature Set, so at least you get H264 decoding out of it.

[SamuriHL]

Oh sure. This gets released while I was just forcing my bedroom machine to use software decoding temporarily while I waited. :p Guess I'll go back in there and get this set up. Thank you so much, Nev!!!

[BatKnight]

I am getting dropped frames every 5 seconds approximately when playing 1920x1080 movies, either AVC or VC-1.
I get smooth playing on 720p movies or others.
My specs are in my signature.

At the moment of playing my GPU is at 20% usage at most, measured by EVGA Precision.

I've tried EVR Custom and EVR Sync, and every option in MPC-HC, and all kind of combinations don't make a difference.
BUT, maVR is flawless. No dropped frames at all. In fact it solved my dropped frames problem with madVR when using ffdshow.

But, why is EVR Custom and Sync dropping frames?
How can I help you debug this?

Nuno

[bjd]

@nevcairel

This really is impressive work. Just testing it with my bluray collection - awesome performance with 1080p VC-1,AVC and MPEG2. No issues on a GT430 just simply amazing PQ via MadVR.

Also tested on some MPEG2 576P/50i material - works a treat.

:thanks: :thanks:

[nevcairiel]

I am getting dropped frames every 5 seconds approximately when playing 1920x1080 movies, either AVC or VC-1.


Not sure whats going on there. Do you have frame time correction on in EVR? Try enabling/disabling it, depending what you had before.

My movies play just fine in EVR Custom as well as madVR.

[SamuriHL]

Ok, initial impressions. WOW! This is AWESOME! My "problem" MKV that nothing does well is Golden Compass. It's a blu-ray rip and is VC-1. Nothing really plays it well, including DXVA, at 24Hz. Before I came out and saw you had released this, I had set up ArcSoft video decoder to handle VC-1 decoding. It pegged the CPU but was decent enough to watch. With your decoder, CPU utilization went down to about 25% or so, which for that machine, is VERY good. Had no problems with subtitles or video. Next up was an AVC MKV blu-ray rip. CPU was again good, but, unfortunately, when skipping around in the video to test certain parts I got a very odd thing going on. It gives me a green block overlay in the middle of the screen. It comes and goes quite a bit. I haven't tried other AVC movies to see if that's reproducible or not. Don't forget that my goal here is to pump this out to madVR in MPC-HC, so, that's how I'm testing this. I didn't see these issues with CoreAVC on that same video.

[BatKnight]

Not sure whats going on there. Do you have frame time correction on in EVR? Try enabling/disabling it, depending what you had before.

My movies play just fine in EVR Custom as well as madVR.
Nope, it was off, but enabling it didn't change anything.
The graph is a mess, even playing at 24Hz I used to have a perfect straight green line, but with CUVID it is a mess, full of spikes.

I've found that disabling Wait For Flushes stops the dropping frames but now I get noticeable tearing and stuttering.

But like I said, madVR is almost perfect.
Any ideas?

Nuno

[sneaker_ger]

Thank you.

I did a short test with a 9200M GS (VP3 feature set B) and it will attempt to open ASP, which is bound to fail of course: the screen stays black. H.264 and VC1 worked fine in a short test. It will also attempt to decode H.264 with the resolutions not supported by VP3 (http://en.wikipedia.org/wiki/PureVideo#The_Third_Generation_PureVideo_HD) which will also result in a black screen.

[sneaker_ger]

Amazing :)

Can't register filter, maybe need minimum driver version or hardware (9600GT) ?
Thanks.

Did you install the VC++2010 runtime components (http://www.microsoft.com/downloads/details.aspx?FamilyID=a7b7a05e-6de6-4d3a-a423-37bf0912db84) yet?

[BatKnight]

More feedback.
I've done testing and testing and got to a conclusion: When playing an AVC/H.264/x264 1920x1080 MKV the audio doesn't match/sync with lips after seeking. This happened on all my AVC movies. This only happens with 1920x1080 AVC videos, with 1920x800 or lower then I can't reproduce it...

With VC-1 movies the audio matches/syncs perfectly with lips and I've randomly seeked and couldn't make it unsync.

Nuno

PS: Tested it with madVR, with Aero on and off

[yesgrey]

nevcairiel,

I just want to say a big thanks!

I was hoping that someone would bring something like this, so that I could be able to watch those WVC1 interlaced music concerts with hardware deinterlacing. It's working very good with me.

:thanks:

[Sebastiii]

Did you install the VC++2010 runtime components (http://www.microsoft.com/downloads/details.aspx?FamilyID=a7b7a05e-6de6-4d3a-a423-37bf0912db84) yet?

Yep :)

I think it's nev answer me need recent driver and surely more recent video card :)

Thanks, will update this soon :)

[ranpha]

Running my test files over this decoder (testing mostly XviD files first), but I am very impressed by the decoder-level deinterlacing capabilities.

[SamuriHL]

No one else is seeing the issue I'm having with a greenish rectangle showing up in AVC playback? :(

[ranpha]

No one else is seeing the issue I'm having with a greenish rectangle showing up in AVC playback? :(

I have seen green rectangles too when playing a couple of my H.264 videos (those are DXVA-compliant clips too). In fact, H.264 videos presents the most problems to me with this decoder as of now. Haven't seen any problems with VC-1/MPEG4-ASP as of yet, need to test more, especially VC-1.

[SamuriHL]

VC-1 is flawless for me. It's just AVC that's giving me the issue so far. Thanks for the confirmation. Hopefully Nev will look into it when he has time. No rush, Nev. I'm super pleased to have VC-1 working. I can use CoreAVC in the meantime. SO awesome that I don't have to upgrade my bedroom machine to get madVR support. And yes, it works at 24Hz. Amazing work!

[sneaker_ger]

Following sample crashes on start:
http://www.mediafire.com/?sjw9tw8u01uk4c7

[robpdotcom]

Hardware decoding with madVR..... man, I wish I had an nVidia card.

My next one will surely be nVidia now, so thanks in advance.:cool:

[SamuriHL]

Yea, it's really truly awesome. It will probably affect my decision if I ever upgrade my main HTPC, as well. Even if my machine is fast enough to do software decoding, why NOT use the hardware and let madVR do its magic at the same time?? :)

[nevcairiel]

I did a short test with a 9200M GS (VP3 feature set B) and it will attempt to open ASP, which is bound to fail of course: the screen stays black. H.264 and VC1 worked fine in a short test. It will also attempt to decode H.264 with the resolutions not supported by VP3 (http://en.wikipedia.org/wiki/PureVideo#The_Third_Generation_PureVideo_HD) which will also result in a black screen.

This should be fixed in the next version, i hope. Previously i "forgot" to actually error out when the hardware would say that its incompatible.

Following sample crashes on start:
http://www.mediafire.com/?sjw9tw8u01uk4c7
I told you it might blow up. :D
Not quite sure why this one crashes, the crash is in nvidias code, but i'll look into it.


No one else is seeing the issue I'm having with a greenish rectangle showing up in AVC playback? :(
Can you somehow reproduce that reliably?

[Sebastiii]

Which driver are you using?
The CUDA SDK 3.2 is relatively new (Jan. 2011), could be that you need at least a 260 series driver.

I can probably use a bit older SDK, and switch to dynamically loading the dlls, so such issues can be avoided.

For Hardware Support, Wikipedia to the rescue. You need at least VDPAU Feature Set A for H264 decoding, B for VC-1 and MPEG2, and C for MPEG4-ASP.
http://en.wikipedia.org/wiki/Nvidia_PureVideo#Table_of_PureVideo_.28HD.29_GPUs

The 9600GT is a "A" Feature Set, so at least you get H264 decoding out of it.

Hi Nev :) i can confirm all above, need new drivers and only H264 works with my old card :)
:thanks:

[CruNcher]

Nice nev the 2nd Directshow Filter after the "Cuda Video Decoder" filter from the Chinese that supports nvcuvid for Dshow now :)
Now there is only a free Nvcuvenc filter missing :)

Though now that i moved to Sandybridge Discrete GPU DSP Decoding limits become more and more obvious 60 fps (@ 20W idle Fermi + 3W 1080p Decoding DSP) seem slow if you can manage 4 cores efficiently (@ that low power), and in that terms Intels more performant Quicksync solution also beats AMD/Nvidias easily currently.

The major Drawbacks for nvcuvid though are no 4:2:2 (Donald talked about this was in discussion state some months ago) and 10-bit, 4K support (never most likely) :(

I wonder what Cuda 4.0 brings new to Nvcuvid and Nvcuvenc, they at least fixed some (Motion Estimation) bugs in the Encoder didn't test the Decoder yet :)

Also it seems clear that neither AMDs nor Nvidias DSP will stay for a long time inside some of the Discrete GPUs lineup anymore it seems useless from a Power, Performance and Cost efficiency point now with CPU/GPU combined in the newer (AMD/INTEL) Desktop Platforms these days for Video based workloads at least.

[nevcairiel]

QuickSync is only encoding, the decode engine in Intel CPUs still has some bugs, and it can only be used with the integrated GPU. Now if they were to decouple this, and allow decoding directly into system RAM, without using the integrated GPU .. i would agree with you - but they don't.

[CruNcher]

QuickSync is only encoding, the decode engine in Intel CPUs still has some bugs, and it can only be used with the integrated GPU. Now if they were to decouple this, and allow decoding directly into system RAM, without using the integrated GPU .. i would agree with you - but they don't.

Hmm did i miss something the Intel iGPU inside Sandy Bridge has no memory so it uses the shared memory that is like copying directly into the Ram because it's system memory, you don't have the path AMD/Nvidias Discrete DSP has to go which Nvidia with GPU Direct at least improved for GPU2GPU transfers (avoiding GPU0 Ram ->System Memory->GPU1 Ram by going directly GPU0 Ram->GPU1 Ram)
Also looking @ Intels research they improving in terms of Video Deinterlacing and still work on more efficient stuff based on the available EUs

[nevcairiel]

Hmm did i miss something the GPU has no memory so it uses the shared memory that is like copying directly into the Ram because it's system memory ;)

Its in the same hardware memory, but you still have to copy it around once into the system area, and you still have to use the integrated GPU - which you usually don't do when you have a dedicated GPU in there.

[SamuriHL]

Can you somehow reproduce that reliably?

Yup. I have a file it happens on every time. Very easy to repro, how can I help?

[nevcairiel]

Yup. I have a file it happens on every time. Very easy to repro, how can I help?

Can you see if cutting an area out of the file where it happens still makes it happen on that cut, and upload it?

[SamuriHL]

Can you see if cutting an area out of the file where it happens still makes it happen on that cut, and upload it?

Yea, I can do that today. My wife is still sleeping so I can't do it til later. But I'll definitely give that a shot. The movie is Alice in Wonderland and I made the MKV with MakeMKV.



General
Complete name : AliceInWonderland.mkv
Format : Matroska
File size : 21.3 GiB
Duration : 1h 48mn
Overall bit rate : 28.1 Mbps
Encoded date : UTC 2010-06-29 23:33:38
Writing application : MakeMKV v1.5.6 beta win(x64-release)
Writing library : libmakemkv v1.5.6 beta (0.7.7/0.8.1) win(x64-release)

Video
ID : 1
Format : AVC
Format/Info : Advanced Video Codec
Format profile : High@L4.1
Format settings, CABAC : Yes
Format settings, ReFrames : 4 frames
Muxing mode : Container profile=Unknown@4.1
Codec ID : V_MPEG4/ISO/AVC
Duration : 1h 48mn
Bit rate mode : Variable
Maximum bit rate : 31.0 Mbps
Width : 1 920 pixels
Height : 1 080 pixels
Display aspect ratio : 16:9a
Frame rate : 23.976 fps
Color space : YUV
Chroma subsampling : 4:2:0
Bit depth : 8 bits
Scan type : Progressive
Language : English
Color primaries : BT.709-5, BT.1361, IEC 61966-2-4, SMPTE RP177
Transfer characteristics : BT.709-5, BT.1361
Matrix coefficients : BT.709-5, BT.1361, IEC 61966-2-4 709, SMPTE RP177

Audio
ID : 2
Format : DTS
Format/Info : Digital Theater Systems
Format profile : MA
Codec ID : A_DTS
Duration : 1h 48mn
Bit rate mode : Variable
Channel(s) : 6 channels
Channel positions : Front: L C R, Side: L R, LFE
Sampling rate : 48.0 KHz
Bit depth : 24 bits
Title : HD Lossless
Language : English

Text
ID : 3
Format : PGS
Codec ID : S_HDMV/PGS
Codec ID/Info : The same subtitle format used on BDs/HD-DVDs
Language : English

Menu
00:00:00.000 : en:Chapter 00
00:04:24.889 : en:Chapter 01
00:10:36.886 : en:Chapter 02
00:18:13.509 : en:Chapter 03
00:24:44.316 : en:Chapter 04
00:28:41.344 : en:Chapter 05
00:36:51.125 : en:Chapter 06
00:46:15.731 : en:Chapter 07
00:52:44.786 : en:Chapter 08
01:04:05.049 : en:Chapter 09
01:10:02.198 : en:Chapter 10
01:15:36.490 : en:Chapter 11
01:23:39.264 : en:Chapter 12
01:34:12.688 : en:Chapter 13
01:36:58.354 : en:Chapter 14
01:40:12.131 : en:Chapter 15

[nevcairiel]

If you have the original BluRay of that movie handy, can you try playing the m2ts with LAV Splitter?

The H264 in MKVs and MP4s is muxed somewhat differently, and i have some code which manually brings it into the same form as from MPEG-TS, which is the only form the hardware understands. So if it works from the original BluRay, but not from the MKV you made from it (without re-encoding, just remuxing), then i know which area to check first.

PS:
Only LAV Splitter delivers that untouched, Haali and MPC-HC internal convert H264 from MPEG-TS into the same form as it would be in MKV/MP4.

[SamuriHL]

I'll have to look and see if that's one of the discs my parents grabbed when they were here. I think my mom wanted to see it so it may be at their house right now. If so I'll get it back next weekend. My dad's still not set up for playing things on a PC, but, given they have an OLD Sony player that sucks, I might be fixing that soon. :) Anyway, I'll look and see if that's one they took with them. They borrowed a bunch of discs as my dad is now retired.

[madshi]

Hmm did i miss something the Intel iGPU inside Sandy Bridge has no memory so it uses the shared memory that is like copying directly into the Ram because it's system memory, you don't have the path AMD/Nvidias Discrete DSP has to go which Nvidia with GPU Direct at least improved for GPU2GPU transfers (avoiding GPU0 Ram ->System Memory->GPU1 Ram by going directly GPU0 Ram->GPU1 Ram)
There's a difference between theory and practice. Im my real life measurements I can transfer 1080p NV12 textures from GPU RAM to System RAM with up to 700fps when using a newer NVidia card. With an Intel GPU I get somewhere between 5fps and 25fps, depending on GPU model. This is by using D3D standard methods to transfer surfaces. I know that the Intel Media SDK internally uses a different transfer method which is a lot faster. But it's not available via D3D.

[SamuriHL]

Yea, that's a disc that my parents borrowed. Figures cause I can't get it to happen on ANY other MKV I have. I'm splitting it now so I can get you a sample that breaks.

[kieranrk]

As a bonus, when decoding interlaced content, it can do full adaptive deinterlacing, the best your GPU has to offer.


Do you know if the card actually uses the best deinterlacing or just claims to do so but actually doesn't as shown by didee?

[nevcairiel]

Do you know if the card actually uses the best deinterlacing or just claims to do so but actually doesn't as shown by didee?

I know that the cheese slice test looks pretty good to me.
I can only tell it to use adaptive deinterlacing, it doesn't give me feedback what its actually doing, though.

[SamuriHL]

Nev,

You were right. I took a clip (http://www.mediafire.com/?ubgs42nnihjhl41) that makes it happen and converted it back to m2ts and then opened it. Plays perfect. So, play around with that clip and see if you can repro it. Then use tsMuxer to convert it to m2ts if you want and it plays fine. Thanks!!!

[nevcairiel]

It looks like the problem is simple. The SPS/PPS Header stored in the MKV is not valid for that part of the file, so you get corrupted playback until the bitstream contains a new one, but then it corrupts again because i actually inject the header before every IDR frame..

I'll have to figure out how to deal with that. Maybe i can analyse the stream and see if it contains its own SPS/PPS NALUs, or only feed the container header to the decoder once at the beginning.
If anyone has some insight when the decoders expect to receive the SPS/PPS, please do tell. =)

[madshi]

FWIW, eac3to muxes MKV files practically unchanged. All headers remain in the bitstream. SPS/PPS headers are stored "in front of" the video frames which follow them. Works great for all MPEG2, VC-1 and h264 this way.

Not sure how to handle playback if you seek and the bitstream doesn't contain SPS/PPS headers. How are you (as a splitter) supposed to know whether the SPS/PPS headers in the container are still valid for the seek point? How are you supposed to know whether the stream itself contains valid headers or not? I guess the best way to handle this would be to keep current headers in a cache and update them whenever they occur in the bitstream. After a seek you should probably check whether the seeked to frame has headers in front of them. If so, use them. If not, well then you're screwed... :) In that case I'd probably add those headers from the container.

Hmmm... But then: If the headers don't ever change, then why injecting them into the stream at all? Maybe you should simply not inject headers *AT ALL*?

[nevcairiel]

My current plan would be to just inject them at the beginning and after a seek.
DXVA probably requires this as well, i should check with MPC-HCs code how they deal with that.

[madshi]

My current plan would be to just inject them at the beginning and after a seek.
What if the bitstream itself contains headers at every seek point? If you inject headers you might overwrite the correct headers with wrong ones.

[nevcairiel]

If i send my headers to the decoder before any other data, shouldn't a new header that was actually contained in the data overwrite mine?
I'll have to think about this.

Too bad just decoding a buffer that only contains SPS and PPS to init it doesn't work, for some reason it doesn't like that.

What the DXVA MPC-HC codec does is basically decode the headers of every frame, updating its context as it goes forward. But i do not keep my own context, its all in the CUVID driver. I'll have to figure out when it actually "forgets" about the context - does a full flush (as it happens on seeks) already cause it to forget? If not, sending the container SPS/PPS on start would be good enough, i figure.

[nevcairiel]

Ok, some testing revealed, a Flush does actually drop its state, but feeding it the SPS/PPS after the flush does seem to work just fine. The Sample from SamuriHL plays fine now, and files that were directly encoded into MKV (so, no SPS/PPS NALUs in the bitstream), are still working fine as well.

I'll do some more tests, and finish working on some configuration that i had lined up.

[SamuriHL]

That's awesome, Nev and Madshi! Thank you for looking into that!

[ranpha]

After testing more Xvid videos, it seems that Xvid videos (a lot of them I say) in AVI containers stutters a lot. Remuxing the very same videos into .mp4/.mkv containers and they started playing smoothly! Anyone else seen the same issue?

[nevcairiel]

After testing more Xvid videos, it seems that Xvid videos (a lot of them I say) in AVI containers stutters a lot. Remuxing the very same videos into .mp4/.mkv containers and they started playing smoothly! Anyone else seen the same issue?

I have seen this, its mostly because AVI really doesn't have much of a timestamp. If using MPC-HC and EVR-CP, turn on frame-time correction. madVR should also work fine. At least thats what i've seen so far.