LAV Filters - DirectShow Media Splitter and Decoders

[mark0077]

Is there any way for LAV Video Decoder to allow on the fly changes to "Hardware Acceleration" -> "Hardware/GPU" -> "Algorithm" settings?

For most of my mpeg2 content, I need to manually select to either use or not use "Adaptive" vs "None" de-interlacing during playback based on whether I can see if it needs deinterlacing or not. Can I somehow make these settings changes take effect without restarting the movie?

I use avisynth frame interpolation after LAV Video Decoder so I can't use madVR's de-interlacing settings and therefore can't use its keyboard shortcuts to change this on the fly.

[kitame]

is there any solution to counter screen tearing on fixed screen refresh rates? a monitor of mine hates 23.976 or 29.97 and causes screen tearing whenever i play sources with output frame rates like those =(

theres seems to be an issue with 29.97fps videos as well, they tend to generate ghosting problems or better known as telecine judder.
http://img839.imageshack.us/img839/6655/judder.png
note: notice the mouth, in motion you'd see afterimages of the line.

[DragonQ]

Do you have Windows Aero off? You need to have it on to avoid tearing in videos, in my experience.

[hoborg]

Hi.
I dind't see any tearing on that picture.
Here is tearting:
http://www.tweakguides.com/images/GGDSG_19.jpg

Wiki:
http://en.wikipedia.org/wiki/Screen_tearing

[ryrynz]

@hoborg He was referring to two separate issues tearing and ghosting, the picture he posted highlighted only the second issue (ghosting).

[SassBot]

is there any solution to counter screen tearing on fixed screen refresh rates? a monitor of mine hates 23.976 or 29.97 and causes screen tearing whenever i play sources with output frame rates like those =(

theres seems to be an issue with 29.97fps videos as well, they tend to generate ghosting problems or better known as telecine judder.

note: notice the mouth, in motion you'd see afterimages of the line.

Is that really an issue with LAV? That just looks like poor quality deinterlacing or your source already has blend issues to begin with. Also, since when has "ghosting" ever been known as telecine judder? Telecine judder is a jerkiness in things like smooth pans due to the pattern of duplication of fields to turn a 24fps signal into 29.97. It has nothing to do with blended after images.

[kitame]

then i might've misunderstood the meaning of judder, although the issue is still there, its not exactly LAV's fault but the fixed screen refresh rate's, im asking if theres any form of solution that can be done without opting to drastic measures.
and i doubt its the source, when i try my other monitors that can match the source's framerate the ghosting drastically lessens. but forcing the screen refresh rate to lock at 60fps reintroduces them, my hypothesis about this one is that the frames that ghosts is getting duplicated, making them more visible.

also concerning interlaces, turning it forced off or on doesnt solve it.

edit: i have a hypothesis, is it possible that the supposedly current frame is getting drawn after the supposedly next frame is drawn? like a frame pattern of 1 2 3 5 4 6 7 9 8, where as the swapped orders causes the ghosting effect.
also from 29.97 to 60 its orders is somewhere near 1 1 2 2 3 3 4 4 5 5, but if you apply my hypothesis it could be 1 1 2 2 3 3 5 4 5 4 6 6 7 7 9 8 9 8 making the ghost effect more visible.

[SassBot]

The screenshot you posted seems to purely be an issue of a blended source or deinterlacing a telecined source instead of properly IVTCing it. Can you post a sample clip of the source?

[kitame]

know any site that i could upload the whole thing untouched? a 90mb 6min file i mean.

edit: nvm, backread and saw sendspace. i hate my ISP... 30KB/s up.

[SassBot]

It doesn't have to be the full file. Just like a 30 second snippet that shows the problem areas.

[CharlieCL]

I am wondering whether LAV codec changed time resolution.

[kitame]

lol, i did try to cut a segment, although by the time i finished doing so the original already completed uploading XD

http://www.sendspace.com/file/toi2i7 [original]
http://www.sendspace.com/file/hc5z3z [28sec clip]

edit: i did some observation of other files with similar issues to this, the problem does show on the others but this particular file seems to have the worst... im feeling that this file is the problem on top of the issue.

[nhakobian]

then i might've misunderstood the meaning of judder, although the issue is still there, its not exactly LAV's fault but the fixed screen refresh rate's, im asking if theres any form of solution that can be done without opting to drastic measures.
and i doubt its the source, when i try my other monitors that can match the source's framerate the ghosting drastically lessens. but forcing the screen refresh rate to lock at 60fps reintroduces them, my hypothesis about this one is that the frames that ghosts is getting duplicated, making them more visible.


If you have a hard telecine source encoded as progressive (or field-blended as has already been suggested), it can appear on playback to have similar characteristics to frame judder (every so often you'll have a field blended "stickiness" to the picture). This is more common with old(er) tv-shows (and anime) that were shot on film, had telecine applied, then had CGI/edits applied at video frame rates.

These sources particularly difficult as different elements on screen could be composited at different framerates, i.e., the background could be 30i, while the foreground could be 24p telecined to 30i. In that case, there isnt any way to fully correct the image. The closest you can get is performing IVTC (if there is enough motion in the foreground to lock into the pattern) and then performing adaptive deinterlacing to clear up the background (or visa-versa). From the frame you provided, it almost looks like this was a segment where this type of correction failed. If the whole video looks like this, its a good chance than it was a poor encode or just had such bad alternating IVTC cadences or interlaced sections that the encoder gave up. (I've seen this type of output on Netflix videos and cable on-demand too since they take a bit of hand holding to get any better output.)

Just had a thought, it could also be a strange field order reversal in the source, but that wouldnt be as likely.

Either way, this is probably an issue with the source, or with the encode, not the playback. Its possible that maybe something in the encoded file is wierd and its causing Lav to mess up.

[kitame]

i see, so most likely the files with these sort of issue is the main cause. re-encoding this as is wouldn't solve the problem either, i tried anyway, and the raws aren't available either.

[Mikey2]

I thought I already posted this, but I cannot see the post. Basically, I just grabbed my first 10Bit video. I thought that the LAV Video Decoder will correctly decode and output this type of source. However, the read-me on the source said I need to use CoreAVC. I have CoreAVC, but I prefer to use LAV for [software] decoding. Am I ok just using LAV as usual? Do I need to turn-off the 8-bit 4CC codes (NV12 etc)?

Finally, I am using madVR for rendering...does this have any relevance on that (i.e. once decoded, is a 10bit raw video any different from an 8bit one, and if so, does anything need to be done on the rendering side of things?)

Finally, does this make that big a difference in image quality?

Thanks much in advance for your help and sorry if this is a re-post.

[nevcairiel]

LAV works just fine out of the box with 10-bit content, you don't need to change anything (neither in LAV or madVR).
Most 10-bit encodes are not done for quality benefits, but for better compression. You can get a 10-bit encode to be 10-20% smaller then the same encode as 8-bit.

[kitame]

^ not only the benefits of compression, but usually encoders opt for 10bit because of its fault-tolerant behavior.
even if your settings is off it can tolerate without damage on the video quality, which means its less hassle for the encoder when using 10bit.
you can see this practice being used when file sizes of 10bit encodes is far larger than of the 8bit encodes.

as for LAV's settings, try resetting it to default if you're getting issues. as far as the user's end, yes it has a visible difference in image quality, although only as a byproduct of going 10bit because of the given reason above.

[Mikey2]

Thanks for the responses! I was able to decode 10Bit (P010) when going straight from LAV Video->Madvr.

However, and I guess this should be posted on ffdshow's thread, but part of the funkiness is in LAV. No matter what I do, when LAV Video is connected to ffdShow the pins show YV12. (I.e. In this case it seems to down-sample to 8bit YV12.)

Let me put it in another way (i.e. repeat myself. ;) )I posted a similar question here before just when using an 8BIT source. It seems that the LAV OUT PIN and the ffdShow IN PIN always show YV12 regardless of the source. (I use ffdShow for debanding and occasionally for aviSynth.) This did not bother me in the past since going from YV12<>NV12 is not an issue. However, losing P010 is of course an issue (is it dithering/down-sampling to 8bit?)

Furthermore, both filters have a list of the FOURCC codes to output. If I turn-off all of the 8-bit ones, I can force the output to p010, but am I correct that this is needless up-conversion? This does in fact allow ffdShow to output 10Bit; i.e. I can pipe LAV (YV12 8BIT)-> ffdshow(P010 10BIT [with all 8-bit codes unchecked]->madVR. But I have a feeling this is still losing the 10bit resolution when ffdShow does its magic in 8BIT then up-converts to 10BIT (This is just a guess.)

Normally I would use a ffdshow preset filter for this (i.e. IF 4CC IS P010 THEN disable all 8-bit output types.) But this does not work because LAV Video is still erroneously sending YV12 to the filter.

For now it looks like I need to skip ffdshow. Without it, LAV VIdeo converts to P010 (10BIT)->madVR (P010 10BIT) without any issues.

Finally, I was shocked: on my Pioneer Kuro (which is known for its color-deptch), the difference was dramatically better! I was definitely not expecting that!

Thanks in advance for your help!
MikeY

[kitame]

try setting ffdshow's primary output colorspace to P010 under the same tab and see if that solves it.

[clsid]

The processing filters in ffdshow only support 8-bit.
LAV uses dithering when converting 10-bit to 8-bit.
The quality gain of 10-bit video is mainly due to more efficient encoding.
The thought of 'having more colors' is just placebo effect, because madVR also dithers to 8-bit!

[Keiyakusha]

Finally, I was shocked: on my Pioneer Kuro (which is known for its color-deptch), the difference was dramatically better! I was definitely not expecting that!
Just want to expand a bit on what clsid said. You should think of 10bit as of "yet another thing in x264 that makes encoding more efficient" by using 10bit it is easier to get the same quality as 8 bit but with smaller filesize. Thats it. Don't expect any wonders from it. Assuming that everything works fine , its not going to look any better if you output P010 from LAV.

[kitame]

^ depends if LAV's dithering is worse than MadVR's =P

[Mikey2]

Oh well, wishful thinking I guess.

I am still surprised that most people think that how the video is decoded (via software, CUVID, libdavcodec, Cyberlink, CoreAVC, Intel, Adobe (flash HW Accel,) Arcsoft etc etc etc..) actually has an effect on the video-quality (post-processing notwithstanding.) It took me a long time to realize this, and it saved me a bit of money by putting the decoding of my videos on my overclocked CPU, freeing up my GPU's for better resizing algorithms in the renderer.)

Since my Pioneer Kuro display speaks of 10bit signals in the HDMI 1.3 specification, I thought that 10Bit was an example of the later, but I guess it is the former. (Unfrotuanteyly with only one example, I cannot even make a subjective test. So my comment about it being "better looking "was unwarranted. I'm sorry about that. FWIW it does look great and plays without any lost frames/jitter nor any "black crush" or other signal-loss, so that's all that really matters right? :)

...OK now to finally watch the darn movie! ;)

[mindbomb]

i'm absolutely in love with the mixer in lav audio.

small comment:
"don't mix stereo sources" option's name should be changed to "don't mix stereo/mono sources" ?

since it seems to also affect mono audio. (which is a great feature)

[Joniii]

Would it be possible to add similar surface overlay "hack" that ffdshow has for displaying subtitles in DXVA?

I would like to use LAV Video because it has also MPEG-2 DXVA but without subtitles, it's better to use ffdshow DXVA.

[egur]

The processing filters in ffdshow only support 8-bit.
LAV uses dithering when converting 10-bit to 8-bit.
The quality gain of 10-bit video is mainly due to more efficient encoding.
The thought of 'having more colors' is just placebo effect, because madVR also dithers to 8-bit!

That's not quite right. When converting YUV to RGB from true 10 bit, the error in RGB will be smaller allowing smoother gradients. This is most visible in blue gradients (e.g. blue skies).

[kitame]

^ you have to tell that to a vast majority of people, discussing benefits of 10bit vs 8bit is mind bleeding.

[Keiyakusha]

That's not quite right. When converting YUV to RGB from true 10 bit, the error in RGB will be smaller allowing smoother gradients. This is most visible in blue gradients (e.g. blue skies).
what is "true 10 bit"?
Also, while its probably true mathematically, its hard to believe this is actually visible (or actually I don't believe at all). And if so, this is nothing else than, how it was called, placebo effect.
Edit: I'm sure if i'll take blue to white gradient and convert it from rgb to yuv (4:4:4 since we're not talking about subsampling) and back, there will be no visible differences, while mathematically of course there will be some. So having more precision from 10bit is useless because we can't get better than perfect result.
And true 10bit (if I'm guessing right what you mean) doesn't exist in consumer world where we use LAV and ffdshow. Not to mention that with proper dithering there is still no visible issues with any blue skies when we will do yuv-rgb conversion after.

[kitame]

the visibility is present on videos that usually ends up with heavy banding, try encoding a video from the source at 10bit with the same or less bitrate of that 8bit encode that suffers heavy banding.

the problem with 8bit encodes is the part where balancing dithering and denoising is annoyingly hard and while pushing for a low bitrate usually results in banding imho, and 10bit solves this problem even if it does dither down to 8bit, because realtime dithering doesnt have the awful bottleneck of bitrate starvation.

[Keiyakusha]

the visibility is present on videos that usually ends up with heavy banding, try encoding a video from the source at 10bit with the same or less bitrate of that 8bit encode that suffers heavy banding.

the problem with 8bit encodes is the part where balancing dithering and denoising is annoyingly hard and while pushing for a low bitrate usually results in banding imho, and 10bit solves this problem even if it does dither down to 8bit, because realtime dithering doesnt have the awful bottleneck of bitrate starvation.
Its not what we're talking about. We talking about YUV-RGB conversion and how more bits give more precision to make (or not) this conversion better. Or at least I'm talking about it.

[egur]

what is "true 10 bit"?
Also, while its probably true mathematically, its hard to believe this is actually visible (or actually I don't believe at all). And if so, this is nothing else than, how it was called, placebo effect.
Edit: I'm sure if i'll take blue to white gradient and convert it from rgb to yuv (4:4:4 since we're not talking about subsampling) and back, there will be no visible differences, while mathematically of course there will be some. So having more precision from 10bit is useless because we can't get better than perfect result.
And true 10bit (if I'm guessing right what you mean) doesn't exist in consumer world where we use LAV and ffdshow. Not to mention that with proper dithering there is still no visible issues with any blue skies when we will do yuv-rgb conversion after.

By "true" 10 bit I mean that the 2 lower bits are not always zero, otherwise they'll be the same as 8 bit.
Blue gradients can create a "step" or band when converted to RGB. The error of the conversion between two neighboring pixels in RGB can be 2 (2 in 8 bit) this is caused since Cb values are multiplied by ~2.
When viewed in a high brightness and contrast display such a plasma or a powerful projector, this is very clear.
FYI, video processors in TVS operate in 10-16 bit depending on the model.
It's good to go down to 8 bit as late as possible to avoid accumulated rounding errors.

[Keiyakusha]

By "true" 10 bit I mean that the 2 lower bits are not always zero, otherwise they'll be the same as 8 bit.
Blue gradients can create a "step" or band when converted to RGB. The error of the conversion between two neighboring pixels in RGB can be 2 (2 in 8 bit) this is caused since Cb values are multiplied by ~2.
When viewed in a high brightness and contrast display such a plasma or a powerful projector, this is very clear.
FYI, video processors in TVS operate in 10-16 bit depending on the model.
It's good to go down to 8 bit as late as possible to avoid accumulated rounding errors.

I see. I got your point. Still I believe your point of view is too mathematically-influenced. (Or how should I say it?. Sorry my English is not good.) I believe this kind of rounding errors are small enough (hard enough to see) to be disregarded, and TVs that operate in 10+ bits (same as many other features we can find in TVs) I consider to be mostly marketing tricks to take more money from consumers. But I think this is beyond something that we should discuss in this thread.

However I fully agree, going to 8bit as last step always preferable. My point is just that when its not very convenient, like in case of ffdshow - we don't lose much (if something at all).

[kitame]

Its not what we're talking about. We talking about YUV-RGB conversion and how more bits give more precision to make (or not) this conversion better. Or at least I'm talking about it.

you missed the last part of what i said:
"because realtime dithering doesnt have the awful bottleneck of bitrate starvation."

which basically means 10bit->8bit vs 8bit will sport less banding with greater compression, simply because you've stored the video at a more accurate form and dithering in realtime doesn't induce that of bitrate starved 8bit encode's issues.
or a more shorter explanation, starving bitrate in 8bit encode causes banding, while dithering down to 8bit in realtime doesnt have a bitrate limitation. so in the beginning if you provided plenty of bitrate there'll be no banding issues at all.

edit: although yes far from the original discussions, it still tackles the issues and reasons.

[Keiyakusha]

you missed the last part of what i said:
"because realtime dithering doesnt have the awful bottleneck of bitrate starvation."
Sorry. I guess I missed not last part but the whole thing.

which basically means 10bit->8bit vs 8bit will sport less banding with greater compression, simply because you've stored the video at a more accurate form and dithering in realtime doesn't induce that of bitrate starved 8bit encode's issues.
or a more shorter explanation, starving bitrate in 8bit encode causes banding, while dithering down to 8bit in realtime doesnt have a bitrate limitation. so in the beginning if you provided plenty of bitrate there'll be no banding issues at all.
True. But again its not what we was talking about.

[Fullmetal Encoder]

That's not quite right. When converting YUV to RGB from true 10 bit, the error in RGB will be smaller allowing smoother gradients. This is most visible in blue gradients (e.g. blue skies).

The irony is that, as I understand it, a fundamental limitation of one of our most popular display technologies (LCDs) is that they typically have the most difficulty displaying shades of blue properly. I will be very interested to see what OLEDs can do about such issues.

[RealSnoopyDog]

Hi nevcairiel, i just found an older recording of a movie via SAT (H.264 1080i - .ts format) on my HD, which has a "glitch" somewhere. Normally, you see some pixel errors there and playback continues normally, but the latest two 0.51.3 LAV builds that i have crash here.
I tested with 0.51.3-33 and 0.51.3-36 => crash.
0.51.3, 0.51.3-18 and 0.51.3-28 => playback continues.
This happens with nVidia and ATI

[vad74]

nevcairiel
I founded big problem with LAV Video Decoder and XBMC. My computer have Intel Core i3 processor. I install XBMC DSPlayer, and in LAV setup select Intel QuickSync decoder for hardware accelerate H.264 video streams. In XBMC in fullscreen mode I run 1080p video. Than I press Enter - Video properties - LAV Video Decoder properties. XBMC go to window mode, and open window with LAV Video Decoder properties. And I see in active decoder avcodec! Not Intel QuickSync. Then I repeate run this video from XBMC in window mode. And in LAV window I see active decoder QuickSync.

What I need do for use QuickSync with XBMC in fullscreen mode? Please help me. LAV v0.50.5. XBMC DSPlayer last version. Thanks.

[nevcairiel]

If XBMC in fullscreen mode uses D3D Exclusive mode, then the decoder just cannot get access to the required D3D interfaces, because its locked by XBMC. That is all.
I still have on my list to try to fix this with WMC, maybe the same thing works for XBMC, but it'll have to wait a while.

[Pat357]

Hi nevcairiel, i just found an older recording of a movie via SAT (H.264 1080i - .ts format) on my HD, which has a "glitch" somewhere. Normally, you see some pixel errors there and playback continues normally, but the latest two 0.51.3 LAV builds that i have crash here.
I tested with 0.51.3-33 and 0.51.3-36 => crash.
0.51.3, 0.51.3-18 and 0.51.3-28 => playback continues.
This happens with nVidia and ATI

Can you upload a sample ? (Mediafire or so...)

[powder21]

Hi all. The old ATI video card on my uncle's HTPC needs replacing. I'm looking at the following nVidia cards (not an ATI fan)

EVGA GeForce GTX 560 (Fermi) DS SSC 1GB 256-bit GDDR5 (http://www.newegg.com/Product/Product.aspx?Item=N82E16814130685)

MSI N550GTX-Ti Cyclone OC GeForce GTX 550 Ti (Fermi) 1GB 192-bit GDDR5 (http://www.newegg.com/Product/Product.aspx?Item=N82E16814127573)

Current Setup:
AMD Athlon II x4 2.3Ghz Quad
ATI Radeon HD 5750
4GB DDR3
Player is MPC-HC
Video: LAV Splitter -> LAV Video (DXVA2 Copyback) -> madVR
Audio: LAV Splitter -> LAV Audio -> AC3Filter (downmixing) -> Reclock (for WASAPI only)

It appears either card I'm looking at is more powerful than the ATI card, but I have no idea how much more power might be needed when I throw CUVID into the mix. I will also be using madVR's ability to auto-switch display modes and, while I can't imagine the nVidia cards not being able to handle that, I thought I'd get some opinions before ordering. The power consumption of the 550 would be less than the 560 so I'd kind of prefer that one (plus that particular card's fan is supposed to be super quiet), but it has 144 less CUDA cores and again, never used CUVID before, so I don't know how that factors in.

Please let me know. Thanks.

ALSO: Currently (before card crapped out) with software deinterlacing unchecked in LAV and Auto activate deinterlacing when needed (if in doubt, deactivate deinterlacing) checked in madVR, the deinterlacing worked great. Wondering if the same would be true with cards I'm looking at.

[kitame]

^ wait for GTX650Ti (not the GTX650, its a ripoff GTX640 with ddr5 support), the power consumption on this shouldn't be over 100w.

im no fan of graphics acceleration because of the issues at hand, but well as far as gpu acceleration is concerned anything over GT520 can handle 1080p.

[powder21]

Unfortunately, waiting is not an option at the moment and the 650 would be out of price range anyway.

Good to know the 550 should handle the hardware acceleration seeing as how I already ordered it. :)

Kind of in one of those need it now sort of situations. Thanks for the info and suggestion. Much appreciated.

[Keiyakusha]

Cuvid, dvxa and such works just as good on any gpu, even cheapest one (assuming it have this capability at all) Its not related to the gpu processing power. Taking the one that eats less energy (and possibly even weak enough to be cooled passively) is what many HTPC guys do. As for madvr I don't know about minimum requirements but 550 gpu should be more than enough/ better ask that in madvr thread though

[nevcairiel]

Cuvid, dvxa and such works just as good on any gpu, even cheapest one. Its not related to the gpu processing power.

Thats only partly true. The decoder itself is independent of the GPU itself, and has the same speed on all cards, however the memory bandwidth is important when you're dealing with CUVID, and if you plan to deinterlace, also the shader performance to some degree.

Having said that, the only card truely too slow are the 510/520 or the 605/610/620 (just decoding+deinterlacing with EVR, no madVR or other expensive things).

For madVR, some people are reportedly happy with a 430 or similar, personally i would get at least a 440 or above, but those ranges are not available in newer models. So the 550 will do just fine.
Anyone with some patience, i would recommend to try to look for a 640 with DDR5 (only OEM so far), or a 650 (tba), or just get a 7xxx AMD. I'm personally quite happy with a passive 7750 right now. :) (i simply use CPU decoding and don't bother with anything else)

[Keiyakusha]

Thats only partly true. The decoder itself is independent of the GPU itself, and has the same speed on all cards, however the memory bandwidth is important when you're dealing with CUVID, and if you plan to deinterlace, also the shader performance to some degree.
Well, Last time I tried budget gpu with 128bit interface and DDR5 memory, it was having enough bandwidth for playing standard blurays. Current budget variants should have better bandwidth. They wouldn't be stuffing them with decoding chip anyway if its not capable of playing things.
As for deinterlace and stuff, I have no idea about that, that's why pointed that madvr thread may be better place to ask. Though I'm sure 550 gpu will be more than enough

[LordMerlin]

What I need do for use QuickSync with XBMC in fullscreen mode? Please help me. LAV v0.50.5. XBMC DSPlayer last version. Thanks.

In the settings XBMC in the video section, enable the setting "Use of a window on the whole screen instead of full-screen mode".

[powder21]

Thats only partly true. The decoder itself is independent of the GPU itself, and has the same speed on all cards, however the memory bandwidth is important when you're dealing with CUVID, and if you plan to deinterlace, also the shader performance to some degree.

Having said that, the only card truely too slow are the 510/520 or the 605/610/620 (just decoding+deinterlacing with EVR, no madVR or other expensive things).

For madVR, some people are reportedly happy with a 430 or similar, personally i would get at least a 440 or above, but those ranges are not available in newer models. So the 550 will do just fine.
Anyone with some patience, i would recommend to try to look for a 640 with DDR5 (only OEM so far), or a 650 (tba), or just get a 7xxx AMD. I'm personally quite happy with a passive 7750 right now. :) (i simply use CPU decoding and don't bother with anything else)

Thanks nev! I would have liked to have waited for a reply like this, but when you need a component replaced in order to get back up and running, well, you need it pronto. Especially when family is involved :)

This is definitely some good info to have though, so I will keep it in mind for other HTPC builds.

[mkanet]

It doesn't take much to play bluray. My old 8500GT GDDR2 from 2006 could playback bluray/hd-dvd movies with low CPU usage using PowerDVD. Even back then, the 8500GT was considered a lower-end display card; but, the first generation from Nvidia to support bluray playback via GPU.

Well, Last time I tried budget gpu with 128bit interface and DDR5 memory, it was having enough bandwidth for playing standard blurays. Current budget variants should have better bandwidth. They wouldn't be stuffing them with decoding chip anyway if its not capable of playing things.
As for deinterlace and stuff, I have no idea about that, that's why pointed that madvr thread may be better place to ask. Though I'm sure 550 gpu will be more than enough

[Keiyakusha]

It doesn't take much to play bluray. My old 8500GT GDDR2 from 2006 could playback bluray/hd-dvd movies with low CPU usage using PowerDVD. Even back then, the 8500GT was considered a lower-end display card; but, the first generation from Nvidia to support bluray playback via GPU.

Its not about CPU usage (or better to say purevideo engine load) but about bandwidth. Even if DXVA works, Cuvid (and dxva cb?) may not (or at least not at full realtime speed). High bitrate full HD frames in one direction and uncompressed in another - this is may be too much for some gpus. Not that I measured any of this. I just know that newer even budget cards can handle it.

[sneaker_ger]

Its not about CPU usage (or better to say purevideo engine load) but about bandwidth. Even if DXVA works, Cuvid (and dxva cb?) may not (or at least not at full realtime speed). High bitrate full HD frames in one direction and uncompressed in another

Don't forget that the uncompressed picture has to be send yet another time back to the GPU before being send to the display...