Standalone QuickSync deinterlacer

[admin]

I just made a standalone QuickSync deinterlacer for Avisynth. It does both single- and double-rate deinterlacing and runs about 100 fps on 1080i material doing double-rate deinterlacing (including decoding). Quality is very good for HW deinterlace, similar to CUVID. At a future time I can add other features from the Intel VPP sample, such as cropping and resize, denoising, etc. You can place this after your DGSourceIM() call in your script. I thought that was more general and flexible than building it into DGSourceIM() because you can use any other source filters as well. You could even place it after DGSource() if you want CUVID decoding with Intel deinterlacing.

You'll need a QuickSync-enabled processor for HW decoding but you can run it in SW on any processor.

I'll release a beta hopefully tomorrow. New toys are always welcome, right?

[Aleron Ives]

New toys are always welcome, right?

As long as they aren't a choking hazard, sure.

[admin]

Aleron, you need to be careful about what you put in your mouth

[AJR]

Hello,

yes of course, new tools are always welcome!

Id like to know what leads you to make such decision to produce new tool. Isnt it against your current bussines (dgdecnv/dedecim)? Or this standalone deinterlacer will became paid tool after beta stage?
Does it mean that work on DGDecIM is over?

[admin]

Greetings, AJR. I hope you are enjoying a stellar start to the new year.

This is a positive thing for DGIM stuff. Neither DGIM or DGNV is deprecated in any way. I'm just following the Unix tool philosophy -- partition functionality. DGBobIM will remain free. I can also package it in the DGDecodeIM DLL for convenience, just like DGMPGDec has auxiliary filters. To be honest, the hassle of adding the licensing to DGBobIM would not bring me much delta $$$ over what I get for DGDecNV/DGDecIM. It's just a little offering to the Gods. I've said many times that the donations aren't making me rich, just giving me some pocket change for HW purchases, and I am happy with that. It sounds funny to me to refer to it as a business model. The latest purchase generously funded by my users was a replacement for my failed X58 motherboad housing my i7-980X. I run the low-end nVidia cards in there for backward compatibility testing. So thanks!

DGDecIM work is not over. I need to add the full GUI and bring the features up to DGDecNV. Competition is wonderful.

And now I'm off to prepare a beta of DGBobIM.

[admin]

Here is a first release to beat on.

http://rationalqm.us/dgdecim/dgbobim_100.rar

Feedback will be appreciated.

[Sharc]

Thanks for the new bobber/deinterlacer.
A minor issue only:
My CPU is not Quick-Sync enabled. When I set engine=0 (for auto-detection) I am getting the error "could not init MFX session".
I have to set engine=2 explicitly to make it work.

P.S. Do you prefer to have the discussions here or elsewhere?

[admin]

Thanks, Sharc. I'll fix that. Let's keep the discussion here.

[admin]

OK, I fixed the engine=0 bug, so please re-download. Thanks for pointing it out, Sharc.

[admin]

I just added a debug option so you can query whether HW or SW is being used, and which MSDK API version is used. Re-download if you want that.

[Sharc]

I re-downloaded but still get the same error for engine=0 "could not init MFX session". No problem however, as engine=2 is ok.

[admin]

It's a problem. Sorry about that. Let me check again.

[admin]

Please re-download and try again. Clear your browser cache. If it still fails I'll make a debug build.

[Sharc]

Bingo! All ok now. (Except the duplication of the first frame, as you mention in the doc).

[admin]

Thanks for the update, Sharc. I screwed up the upload. Sorry for the inconvenience.

What processor and OS are you running on?

[Sharc]

Processor Name: Intel Core 2 Quad Q9300 2.5GHz
CPU Code Name: Yorkfield
CPU S-Spec: SLAWE

Operating System: MS Windows 10 Professional (x64) Build 14393.693 (RS1)

Avisynth: 2.6.0.5

[admin]

Thank you, Sharc.

[admin]

I've released a new version of DGBobIM. It removes SW operation and improves HW operation. Let me explain things...

It's pretty obvious that my "franchise" is robust frame accuracy, as embodied in DGDecNV/IM. Interestingly, very similar challenges are involved in developing a bobber that can jump to any requested frame number and start delivering from the correct source field. For example, suppose one asks for frame number 100 from a TFF stream that is being double-rate deinterlaced (bobbed). The frame returned should correspond to the top field of the source frame number 50. Then stepping forward should yield the subsequent fields from the source, etc. If one asks for frame number 101, the frame returned should correspond to the bottom field of source frame 50. Stepping backward should also yield the correct preceding fields from the source. This what I mean by random access for bobbing.

Sadly, the Intel VPP, as implemented by the sample code, does not behave this way. It does not care if the first field is correct or if it is repeated! Suppose we start the VPP running with requested frame N with N even. The frames generated as you seek and then step forward correspond to these source fields:

N/2 top
N/2 top
N/2 bottom
N/2 + 1 top
N/2 + 1 bottom
...

There is a spurious repeated first frame corresponding to the correct source field. OK, you think, we just suppress it, and it works. Not very difficult. But things are completely different if you request frame N with N odd:

N/2 top
N/2 + 1 top
N/2 + 1 bottom
...

Here we do not have a spurious frame but we have the wrong field at the seek point. It should be N/2 bottom. This is much harder to correct. I had to offset the source frame back by one (to N/2 - 1), let the VPP run, and then ignore the extra fields. It's similar to backing off by a GOP for random access in DGDecNV/IM.

I discovered this bad behavior experimentally and developed code that modifies the VPP sample code to deliver the correct fields in all cases. Now, for example, you can put Reverse() after DGBobIM(), which forces random access for all frames, and everything will be fine. Slow but fine. In normal use cases random access is nonexistent or sporadic, so the slowness of seeking is not an issue.

So I developed all that and was quite proud of myself. I included a script colored_fields.avs in the 1.0.1 distribution to allow you to explore this stuff. Of course, if Intel ever modifies the way the VPP operates, such that the behavior changes, I will have to revisit things. Time to move on to SW. Uh oh, I found that the misbehavior is completely different, so that I would have to implement a completely different strategy. My brain was hurting and I didn't immediately see a good approach, so I made the decision to simply not support SW. Maybe one day I will revisit it but motivation is lacking as there are already many fine SW deinterlacers. The reason for doing this filter was to get iGPU acceleration.

A possible nightmare may be that different versions of the iGPU and its DLL misbehave in different ways. I hope that is not the case but time will tell. For the record, DGBobIM was developed on a Haswell with 4600 graphics. It would be interesting to hear from people with different versions of the iGPU. Please use colored_fields.avs for testing.

Here is the new version. Your feedback will be appreciated as always.

http://rationalqm.us/dgdecim/dgbobim_101.rar

[admin]

I hate Intel so bad.

So after I brought up TheBeast running Win10, I thought OK let's fire up DGBobIM and see how it runs on Intel Graphics 630 (Kaby Lake). I opened the test script in VirtualDub and it crashed. After 4 hours of debugging I discovered these two things:

1. The Intel sample code configured for D3D9 does not run on Win10. The D3D9 create call fails, because the hWindow and hDeviceWindow are both null. The windows documentation for this call says it should fail, but strangely, on Win 8.1 it succeeds.

2. The Intel sample code configured for D3D11 does run on Win10, but it does not support YV12.

Fortunately DGDecodeIM works OK, because it doesn't use D3D surfaces.

So I have two choices:

1. Convert everything to D3D11 and kludge up my own YV12 support by converting YV12 to NV12.

2. Say sayonara to the Intel MDSK for anything but maintaining DGDecodeIM.

Given my recent CUDA focus, I am opting for option 2 at this time.

Rest in peace, Intel MSDK.

[hydra3333]

Hmm. For all of Intel's trainloads of money, they do not seem to act professionally in regard to that software, do they ?
Maybe they employ kids, or outsource to countries where professional ethics are almost non-existent ?

[admin]

outsource to countries where professional ethics are almost non-existent ?

Go to the IMSDK support forum and look at the names of the people who reply from Intel. I worked as a software development manager for many years, and I can tell you, outsourcing to 3rd-world countries may look good to the bean-counters, but after you throw out the crappy code they produce and redo it yourself, you end up increasing costs when you hoped to reduce them. And that does not even factor in the 12-hour time shift that makes communication a nightmare, or the language barriers.

The current Intel VPP sample does not even compile with the latest SDK. It's a frigging joke. The same tired excuse is always given: the sample code is intended as a starting point, not production quality. What kind of starting point is code that doesn't compile, or which (after fixing the compilation errors) runs on one OS but not another? You could get away with that crap if there was a viable support option, but the support sucks even worse than the code itself.

OK, you got me going. I lived in India for 4 years. I know the culture is to tolerate crappiness in all things. So I am not surprised that the same attitude attaches to software development there. I know it from personal experience, having led a "development team" in Bangalore on deputation from a major US corporation.

[Aleron Ives]

[Sharc]

Enjoy the taste of Globalization, guys!

[admin]

Oh darn, you replied before I edited that yucky stuff out. It's OK.

BTW, I was able to build the Intel sample and DGBobIM without using D3D9 or D3D11, getting around the earlier mentioned errors. Both work just fine on Win8.1 but fail miserably on Win10. That's right, even if you can get the sample to build and run on Win10, it fails to run correctly. The postprocessing simply does not perform correctly. That's it. I officially end all IMSDK development. I will support DGDecIM as long as it continues to function. If Intel breaks it with some future driver/MSDK then I'll bury it too.

[hydra3333]

I worked as a software development manager for many years

he he, so did I for a while; not big time but enough for fun.

factor in the 12-hour time shift that makes communication a nightmare, or the language barriers.

I work in a framework along those lines in a related role. Very fortunately for me, le bon personnel are first class even with cultural differences at play (eg they make interesting if different minor assumptions around business rule operations than Aussies may).

All in all, many sympathies ... in your old role, I can vouch that when it's hitting the fan then you really do have to find ways and means https://www.youtube.com/watch?v=ftm1hiXgYsA&t=64
https://www.youtube.com/watch?v=ftm1hiXgYsA&t=117