How good is the WMV deinterlacing?

[swiego]

I am looking to archive a bunch of footage in WMV advanced profile with the registry goodies turned on. (I can live with the Windows-only bit.) Some of my footage is interlaced and I was debating whether to let WME deinterlace it or not. Any thoughts on how good it is? I've used some of the various avisynth and virtualdub deinterlacers (though I am out-of-date since this past summer) so I'm somewhat familiar with different deinterlacers and the benefits of having a good one. Where does the WME deinterlacer fit?

I'm assuming that it's on par with the quality of the rest of the encoder (which is to say, pretty good) but would be interested to hear if anyone's dissected it.

[zambelli]

It is not as good as the advanced deinterlacers such as TDeint, LeakKernelDeint, MVBob, MCBob, and others. It's more on par with FieldDeinterlace with blend=true. I'd recommend preprocessing your source with one of the more advanced deinterlacers before encoding.

[swiego]

Thanks for the quick reply and input!

Advanced Profile with the nice IQ settings is rather slow... tossing in Neat Video and some of the nice deinterlacers out there results in something like 0.5fps on a Core2... eek!

[Jay Bee]

It is not as good as the advanced deinterlacers such as TDeint, LeakKernelDeint, MVBob, MCBob, and others. It's more on par with FieldDeinterlace with blend=true.

Is this the WME pre-encode deinterlacer you're talking about or the DirectShow playback deinterlacer?

And what's stopping DirectShow playback form using a nice deinterlacer like the Purevideo decoder does for MPEG-2? I just had a quick look at the interlaced VC-1 clip you posted here (http://forum.doom9.org/showthread.php?p=858686#post858686) and even when opening it via DirectShowSource() it looks poorly deinterlaced rather than interlaced. Does this mean that deinterlacing is being performed by the decoder instead of the renderer?
http://img6.picsplace.to/img6/25/thumbs/Zwischenablagebild.jpg (http://img6.picsplace.to/img.php?file=img6/25/Zwischenablagebild.jpg)

[zambelli]

Is this the WME pre-encode deinterlacer you're talking about or the DirectShow playback deinterlacer?
WME9 internal deinterlacer.

And what's stopping DirectShow playback form using a nice deinterlacer like the Purevideo decoder does for MPEG-2?
Nothing is. In fact, that's exactly the deinterlacer that typically gets used in playback. PureVideo is just Nvidia's fancy name for DXVA support. VMR7 (when in mixing mode) and VMR9 will typically leverage available hardware deinterlacing whenever any content is signaled as being interlaced using VideoInfoHeader2 flags.

I just had a quick look at the interlaced VC-1 clip you posted here (http://forum.doom9.org/showthread.php?p=858686#post858686) and even when opening it via DirectShowSource() it looks poorly deinterlaced rather than interlaced. Does this mean that deinterlacing is being performed by the decoder instead of the renderer?
Yes, it looks like your WMV decoder is performing internal deinterlacing. Prior to v11 that was the default behavior due to the fact that interlaced signaling wasn't very well implemented in the pre-v11 decoder. You can change this behavior by setting DWORD value "Deinterlace" in HKEY_CURRENT_USER\Software\Microsoft\Scrunch to 0. Once you do that, try loading the same video in GraphEdit, replace the default VMR with VMR9 and hit Play. If you look at the VMR9 properties, you ought to see 59.94 fps as the rendered framerate, indicating that hardware bobbing is happening.

[Jay Bee]

Thx for the reply.

I've now installed WMP11 Final and the clip does indeed work as it should in WMP11! And in GraphEdit it says 59.94 fps in the VMR9 properties, like you said. But the problem is that when I use exactly the same graph (WM ASF Reader/WMVideo Decoder DMO/VMR9) in Zoom Player or Media Player Classic, I get the same 29.97 Hz deinterlacing as in the screenshot in my above post and it also says 29.97 Hz in the VMR9 properties. :confused:

Do you see an obvious reason for this or is it most likely to be bugs in these Players?

[DrP]

I'm pretty sure that WMV9 (and later) interlaced content when played on a non-microsoft player instead of showing distinct fields has the video blur merged into a non-interlaced frame as its output by the codec. A good reason to avoid Microsoft if that is still being done.

[zambelli]

Do you see an obvious reason for this or is it most likely to be bugs in these Players?
Looks like internal decoder deinterlacing is still kicking in for some reason in those apps. MPC/Zoom developers might be able to fix this for all their users by programatically setting the MFPKEY_DECODER_DEINTERLACING (http://msdn.microsoft.com/library/en-us/CODEC_API/html/mfpkey_decoder_deinterlacingproperty.asp) property when building the graph to ensure that the right setting is used every time.

In the meantime, can you try setting that reg key I mentioned few posts above and see if it makes a difference?

You can also check the pin properties of the WMV decoder output or VMR input in MPC to verify that VideoInfoHeader2 is present and the video is signaled as interlaced.

[zambelli]

I'm pretty sure that WMV9 (and later) interlaced content when played on a non-microsoft player instead of showing distinct fields has the video blur merged into a non-interlaced frame as its output by the codec. A good reason to avoid Microsoft if that is still being done.
It has nothing to do with whether the player is Microsoft's or not, but whether the decoder properties are set correctly. It seems like in some cases the decoder is still defaulting to the old behavior, although you can see from Jay Bee's post that GraphEdit exhibits the right default behavior (no internal deinterlacing) - so it's somewhat unclear what causes apps like MPC and Zoom to default the other way.

[Jay Bee]

OK, I did some more tests. Here's the summary:

1. Play in WMP11 with Scrunch/Deinterlace=0 --> 60 Hz deinterlacing

2. Play in WMP11 with Scrunch/Deinterlace=1 --> 30 Hz deinterlacing

3. Play in Graphedit --> 30 Hz deinterlacing and following pin info:
http://img6.picsplace.to/img6/25/31.png
http://img6.picsplace.to/img6/25/32_000.png
Scrunch/Deinterlace makes no difference.

4. Play in MPC with Scrunch/Deinterlace=0 --> no deinterlacing at all and following pin info:
http://img6.picsplace.to/img6/25/41.png
http://img6.picsplace.to/img6/25/42.png

5. Play in MPC with Scrunch/Deinterlace=1 --> 30 Hz deinterlacing and the same pin info as in 4.

So basically WMP11 is the only way to play the file properly, Graphedit recognizes that it's supposed to output 60 Hz but fails to do so and in MPC the decoder fails to set the correct interlaced flag. Any hope for an easy fix? Maybe I should ask ZP/MPC devs? Would it be patchable if it was a Microsoft problem, seeing that WMP11 is final and all?

It sure would be great to have a decoder with good interlace support so I can finally stop wasting space with MPEG-2.

[zambelli]

So basically WMP11 is the only way to play the file properly, Graphedit recognizes that it's supposed to output 60 Hz but fails to do so and in MPC the decoder fails to set the correct interlaced flag. Any hope for an easy fix? Maybe I should ask ZP/MPC devs? Would it be patchable if it was a Microsoft problem, seeing that WMP11 is final and all?
Thanks for the additional info. In an earlier post you stated that GraphEdit was rendering 59.94 fps with VMR9:
And in GraphEdit it says 59.94 fps in the VMR9 properties, like you said...
I'm a little confused now - does GraphEdit play at 29.97 fps or 59.94 fps?

BTW, any discrepancy between WMP and other players will be due to the fact that WMP is built on WM Format SDK, while other players are built on DirectShow - so the APIs are different, and that includes interfaces for interlaced signaling. The signaling in DShow gets pretty complicated because the interlacing info originates within the ASF reader (from ASF Data Unit Extensions) and is then sent downstream in the graph through the DMO wrapper... providing plenty of opportunity to lose things along the way. ;) Getting the scenario right without breaking app compatibility gets very tricky.

[Jay Bee]

I'm a little confused now - does GraphEdit play at 29.97 fps or 59.94 fps?

Oops, I made a small mistake. In GraphEdit I was using VMR7 instead of VMR9. Here's the correct info.

GraphEdit, MPC and ZP all show the following behavior:

-With WMR7 the actual video plays at 29.97 fps and the Deinterlace tab under VMR says 59.94 fps.

-With WMR9 the actual video plays at 29.97 fps and the Deinterlace tab under VMR says 29.97 fps.

-Setting Scrunch/Deinterlace=0 changes the output from this

http://img6.picsplace.to/img6/25/1_273.jpg

to this

http://img6.picsplace.to/img6/25/2_140.jpg

Didn't know about the WM Format SDK. Is this something that other devs can adopt or would that be more like a complete rewrite?

[Jay Bee]

Some more info about WMP11:
With "Use video mixing renderer" off (under options/performance/advanced) the output is like screenshot one in the post before this one.

Turning it on without "Use overlays" or "Use high quality mode" makes the output look like screenshot two.

Turning on either "Use overlays" or "Use high quality mode" makes the proper deinterlacing kick in, which looks like this:

http://img6.picsplace.to/img6/25/3_101.jpg

[zambelli]

Some more info about WMP11:
With "Use video mixing renderer" off (under options/performance/advanced) the output is like screenshot one in the post before this one.
Turning it on without "Use overlays" or "Use high quality mode" makes the output look like screenshot two.

Turning on either "Use overlays" or "Use high quality mode" makes the proper deinterlacing kick in, which looks like this:

This is to be expected with WMP11. "High quality mode" makes use of VMR-7's YUV mixing mode, which is where the advanced deinterlacer kicks. I generally recommend that people run WMP in "High quality" mode for this reason.

GraphEdit, MPC and ZP all show the following behavior:
-With WMR7 the actual video plays at 29.97 fps and the Deinterlace tab under VMR says 59.94 fps.
-With WMR9 the actual video plays at 29.97 fps and the Deinterlace tab under VMR says 29.97 fps.
-Setting Scrunch/Deinterlace=0 changes the output from this
Are you sure you didn't switch VMR7 and VMR9 around in that statement?
Also, did you run both renderers with Deinterlace=0?

[Jay Bee]

This is to be expected with WMP11. "High quality mode" makes use of VMR-7's YUV mixing mode, which is where the advanced deinterlacer kicks. I generally recommend that people run WMP in "High quality" mode for this reason.


Are you sure you didn't switch VMR7 and VMR9 around in that statement?
Also, did you run both renderers with Deinterlace=0?

Yes, to both. Just rechecked to make sure.

[zambelli]

Yes, to both. Just rechecked to make sure.
OK, thanks. One more piece of info: could you post the pin info, like you did before, for Deinterlace=0 in both VMR7 and VMR9?

[Jay Bee]

Sure, here's the info for Deinterlace=0 from MPC. If you need anything else from GraphEdit or ZP just say so.

VMR7:
http://img6.picsplace.to/img6/25/Zwischenablagebild.png
http://img6.picsplace.to/img6/25/Zwischenablagebild__1_.png

VMR9:
http://img6.picsplace.to/img6/25/Zwischenablagebild__2_.png
http://img6.picsplace.to/img6/25/Zwischenablagebild__3_.png

[zambelli]

Sure, here's the info for Deinterlace=0 from MPC. If you need anything else from GraphEdit or ZP just say so.
Jay Bee, thank you for all the data. You've been extremely helpful. I had to also remind myself a bit about this topic because its functionality was solved differently for XP versus Vista and there was quite a lot of back-and-forth emailing about it at the time.

The problem is this: deinterlacing is not happening because VideoInfoHeader2 is not being used (notice all its flags being at 0). You see, plain VideoInfoHeader does not contain any interlacing or aspect ratio flags, so the only way to send these downstream is to use the extended VIH2. This was done by design (as unfortunate as it is) in WMP11 for XP. It's a long and convoluted story why we didn't make the change to VIH2, but suffice to say that sticking with VIH was basically done for backwards compatibility with filters and apps which expect VIH from the WMV decoder.

Only one exception was made to this design decision, and that's for DXVA. When DXVA decoding is used (such as on Nvidia GeForce 6xxx series and better cards), VIH2 gets used (and interlaced flags get set) because we know with certainty that DXVA and VMR7/9 support VIH2.

WMP and WM Format SDK don't suffer from this problem because they do not rely on an interface such as VIH2 to convey these interlaced flags. Ironically, getting high quality bobbing to work in WMP still requires the additional step of enabling "High quality mode" (VMR7 mixing mode).

In Vista, on the other hand, we had time to implement a more adequate design. VIH2 gets used whenever WMV decoder encounters interlaced content in DirectShow, even if DXVA is not used for decoding. Like in XP, WMP exhibits the correct behavior at all times.

Until this is fixed in XP (and I can't guarantee or promise that), the workaround is to either a) use WMP11, b) use the inferior internal codec deinterlacer (Deinterlace=1) or c) upgrade to a video card such as the Nvidia GeForce 6600 (or better) that supports DXVA WMV decoding.

[Jay Bee]

Well thanks to you too, for taking this topic seriously. Other companies could learn something here.

I'm using a 6600 GT AGP which did have WMV9 DXVA support up until the 78.05 driver, after that it was removed for all AGP cards even though Nvidia still claim (http://www.nvidia.com/page/purevideo_support.html) support, even for VC-1, which of course isn't supported in 78.05.

Anyway, I also have access to a PC with a 6200 PCIE card so I could do some tests using newer drivers (Do you know BTW which driver version introduced VC-1 DXVA?).

Well it turns out deinterlacing does indeed work with the 6200 with both ZP and MPC in both VMR7 and VMR9! There were a few problems with what looked like field order problems or some other kind of stuttering but I think that was only with the combination VMR7 and MPC.

So summerizing, interlaced VC-1 files can be played with good deinterlacing, without any problems and without any obscure, non-default settings on
1) any Vista machine
2) any XP machine in WMP11
3) any XP machine with a PCIE card in any DirectShow player

And in the special case of Nvidia AGP cards and non-WMP11 player the file will still deinterlace, just with low quality.

Right?

This means that interlaced support is already much better with VC-1 than with any MPEG-4 decoder in existance. Time for me to start looking into the whole encoding side of things (and get a new GPU :)).

Two more questions: I know nothing about ATI cards, whats the VC-1 DXVA Deinterlace situation there? And is there a way other than comparing CPU usage to tell if DXVA is actually being used for WMV and VC-1?

[protovision]

Great info in this post, thanks!

I had a related question, where I'm not sure whether to deinterlace when shifting format from 1080i/25fps(pal) to WMV VC-1 for xbox 360 playback on a 1080i ntsc TV.

the source seems to indicate 'interlace: frames', but I don't know if that means 50i. any advice for optimum vc-1 quality and playback?

also, I figure when converting, leaving interlacing as int, and prog as prog, is the best for 'future-proofing', would that be a correct assumption, especially in my example, vc-1?

thanks!

p.

[zambelli]

the source seems to indicate 'interlace: frames', but I don't know if that means 50i. any advice for optimum vc-1 quality and playback?
What's the source format? MPEG-2? AVI?
When you watch the source format frame-by-frame, does it appear to be interlaced or not?

also, I figure when converting, leaving interlacing as int, and prog as prog, is the best for 'future-proofing', would that be a correct assumption, especially in my example, vc-1?

That's the idea, yes. However, keep in mind that unless your 1080i TV is a CRT (tube) model, you'll never actually see a true interlaced video displayed. All other display types (LCD, plasma, DLP, etc) are progressive, so even interlaced content gets deinterlaced eventually - in the display if not before.

[protovision]

... However, keep in mind that unless your 1080i TV is a CRT (tube) model, you'll never actually see a true interlaced video displayed.

Thanks for the reply!

In my case, I'm watching on a RPTV, 1080i, so the interlaced source isn't a problem for me, and will leave my re-encodes same as original for now.

In the future, when I have a 1080p (or holodeck), I would assume that the device will do the 3:2 pulldowns itself (or whatever it is in this case) from my interlaced material.

ttyl,
p.