INTERACT FORUM
More => Old Versions => Media Center 17 => Topic started by: Matt on May 07, 2012, 12:32:00 pm
-
This is from Ganesh at Anandtech:
MC 17 should try to avoid deinterlacing in multiple places, i.e, if
madVR is set to do deinterlacing, there should be no need for LAV
Video Decoder to do it. In fact, Hendrik indicated on Doom9 that doing
so would increase the GPU load because of extra number of frames which
need to get transferred for madVR to process [
http://forum.doom9.org/showthread.php?p=1572953#post1572953 ]. If it
is possible, MC 17 can try to detect if madVR deinterlacing is turned
on and, if that is the case, set LAV Video Decoder Hardware / GPU
deinterlacing to Weave (None).
Should Red October HQ disable deinterlacing in LAV and assume madVR will take care of it?
Will madVR leverage nVidia CUDA deinterlacing?
Thanks for any advice.
-
Obviously Nev will have better details, but from my reading of the threads, LAV can/will use more/better tools for de-interlacing than madVR. When madVR does it, it's of the same 'quality' as LAV, but it is able to do so with less content/tools.
So, I think it makes sense to have LAV do all the de-interlacing, and just let madVR render what it receives from LAV.
-
There is no big difference in deinterlacing from madVR or from LAV CUVID. Its the same hardware deinterlacing doing its work, not much will change.
As he outlined, it'll be slightly more efficient to let madVR do it, because it doesn't have to leave the GPU again.
So for all i care, always let the renderer do it when possible.
-
always let the renderer do it when possible.
Is this the difficult part? When to have madVR do it, and when should LAV do it?
I just figured that since LAV can handle it in more situations, it might be best to just let LAV always handle it.
But, of course, you 2 know MUCH more about this than I do, so feel free to ignore me :)
-
There is no difficult part. Why would the renderer not be able to do it?
-
I didn't think madVR was able to de-interlace every possible stream, so then MC would need to choose which streams to have de-interlaced where (adding a decision layer/difficulty).
But again, you're the expert, and I'm certainly not trying to argue with you about it. :-X If you think it's best to have madVR do it all, that's totally fine with me :D
-
Does both madVR and lav both support the same HW based deinterlacing on Intel, AMD, as well as nvidia?
-
lav doesn't do any hw deinterlacing on intel or amd.
-
When talking about NVidia GPUs, it would probably make sense to let madVR do the deinterlacing because (as nevcairiel already explained) there should be no difference in quality, while we might get slightly better performance when letting madVR do the work. Furthermore madVR can do DXVA2 deinterlacing with all GPUs (NVidia, AMD, Intel, whatever) on all OSs, including Windows XP (if you install .NET 3.0 or newer). LAV on the other hand can do software YADIF deinterlacing, which madVR currently does not do. So pick your poison. My recommendation would be to let madVR perform DXVA2 deinterlacing for NVidia and AMD GPUs, but for Intel GPUs it might be a matter of taste or a matter of priorities. LAV YADIF deinterlacing might provide better image quality than Intel DXVA2 deinterlacing, on the cost of higher CPU consumption. The quality of DXVA2 deinterlacing depends on the GPU hardware and from what I've read Intel's hardware deinterlacing isn't that great. But I haven't compared quality myself, so I can't really say.
There shouldn't be any streams that madVR cannot deinterlace. However, there could be slight differences in when and how deinterlacing is activated. If madVR doesn't automatically activate deinterlacing for some streams, you can manually activate it by pressing Ctrl+Alt+Shift+D twice. Generally, madVR should behave mostly similar to VMR and EVR in terms of video deinterlacing. There are a couple of differences, though, because I think that VMR/EVR don't always do the "right" thing, so I tried to improve on that in madVR.
Another topic is IVTC. madVR can perform (software) IVTC with all kinds of movie cadences, which to my best knowledge no other DirectShow filter (nor DXVA) can currently do in comparable quality. But that's probably a separate topic. For those of you who're wondering what I'm talking about: If you let DXVA "deinterlace" movies for you then for 1080i60 movies you'll get 1080p30 or 1080p60 output, but *not* 1080p24 output. Which means that you'll still have the 3:2 motion judder. madVR's IVTC algorithm on the other hand allows you to convert 1080i60 back to the original 1080p24 to get perfect motion smoothness.
-
I'm trying to figure out what the code should look like on our side.
Is it possible to configure madVR deinterlacing from code?
Maybe if it defaults to "on", this is good enough?
Thanks.
-
FYI madVR is doing the deinterlacing in RO HQ on intel now
-
Reading through this, it seems like making that change is a no-brainer.
The differences between performance/quality on Intel integrated GPUs, Nvidia, and AMD here and other places might be one reason to implement something like this (http://yabb.jriver.com/interact/index.php?topic=72016.msg487150#msg487150) for MC18.
-
I'm trying to figure out what the code should look like on our side.
Is it possible to configure madVR deinterlacing from code?
Maybe if it defaults to "on", this is good enough?
You can certainly configure madVR deinterlacing from code, but currently it's a global setting, not a session setting. The session setting stuff is still on my to do list. Anyway, in "mvrInterfaces.h" search for "deinterlacing" to find how to modify the madVR global settings from code.
madVR defaults to DXVA2 deinterlacing "on". Whether that is good enough for your needs, I can't say.
-
So I propose the following program flow for de-interlacing decision making:
if renderer is madVR or EVR:
turn off all LAV deinterlacing
let renderer do deinterlacing
else if hardware acceleration is selected in MC (and hardware supports it):
turn on LAV hardware deinterlacing
else
turn on LAV software deinterlacing (YADIF)
endif
Recently we added code to set LAV deinterlacing to "aggressive" mode for mpeg-2 streams, since we ran into the problem of some interlaced television streams being incorrectly marked as progressive. In the above scheme, madVR would be used for deinterlacing and may run into the problem of not "aggressively" deinterlacing these streams. Comments from madshi and nevcairiel welcome.
-
The "aggressive deinterlacing" option will affect the deinterlacingdone by madVR or EVR as well, because it also translates to the interlace signaling on the outgoing frames, so it should be just fine.
On that note, if you go this route, i would also let EVR do the deinterlacing, and not limit it to madVR.
-
On that note, if you go this route, i would also let EVR do the deinterlacing, and not limit it to madVR.
I thought LAV did a better job than EVR at deinterlacing in some cases. Is that not the case?
-
I thought LAV did a better job than EVR at deinterlacing in some cases. Is that not the case?
I dunno. Its the same hardware deinterlacer, i fail to see where there might be a difference, unless EVR bugs out with some streams.
Not to mention that its NVIDIA only anyway.
-
The "aggressive deinterlacing" option will affect the deinterlacingdone by madVR or EVR as well, because it also translates to the interlace signaling on the outgoing frames, so it should be just fine.
On that note, if you go this route, i would also let EVR do the deinterlacing, and not limit it to madVR.
Ok, I changed the flow to let EVR do the deinterlacing as well as madVR. Thanks for clarifying the "aggressive" option. By the way, do I set LAV HW deinterlacing mode to "Weave" in the case where we're letting EVR/madVR do the work?
-
By the way, do I set LAV HW deinterlacing mode to "Weave" in the case where we're letting EVR/madVR do the work?
Yes, Weave is "no deinterlacing", it just weaves the two fields together without any interpolation.
-
Just to clear things up: I think the main purpose/benefit of letting LAV Video do hardware deinterlacing is if you want to further process the video via CPU. This makes a lot of sense if you have ffdshow raw processor (+ some AviSynth scripts) in the processing chain, or if you maybe even don't want to render at all, but use a DirectShow encoder to encode a new video. For a pure playback chain with no CPU post processing at all, in theory there should be no benefit letting LAV Video do the hardware deinterlacing instead of the renderer.
I don't think EVR deinterlaces worse than LAV or madVR (except for one special situation where madVR does things differently, but that's not too important right now, I guess). EVR might not always activate deinterlacing when it needs to, but you can use LAV Video for force EVR to deinterlace, so no problem. One thing, though: I've read that when using EVR, with some decoders you only get single rate deinterlacing (30p output for 60i content) instead of double rate (60p output). But I'm not really sure if that is true. And even if it's true, I guess at least when using LAV Video Decoder, EVR should always output double rate, right, Hendrik?
-
I guess at least when using LAV Video Decoder, EVR should always output double rate, right, Hendrik?
Yes.
I don't even know what those other decoders are doing wrong that prompts EVR to only go single-rate.
-
Here's what Ganesh (of Anandtech) had to say about hardware deinterlacers:
Btw, I just skimmed through the thread and saw Mathias mentioning
about Intel HW deinterlacing quality. Just wanted to mention that
based on our current tests, there is really not much difference
between NV, AMD and Intel's HW deinterlacers.
-
I remember to have seen screenshots in doom9 from Intel deinterlacing which didn't look good (clearly visible artifacts), but I don't remember which hardware is was exactly. Also I don't know if it was just a one in a million corner case, or if the problems I saw there occur more often. Anyway, I can't really say much about it since I haven't tested it myself. If Ganesh says their tests indicated good quality, then probably there's no reason to worry.