Page 1 of 1

Re: Standalone QuickSync deinterlacer

Posted: Wed Feb 01, 2017 1:33 pm
by 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.

Re: Standalone QuickSync deinterlacer

Posted: Wed Feb 01, 2017 2:40 pm
by admin
It's a problem. Sorry about that. Let me check again.

Re: Standalone QuickSync deinterlacer

Posted: Wed Feb 01, 2017 3:00 pm
by admin
Please re-download and try again. Clear your browser cache. If it still fails I'll make a debug build.

Re: Standalone QuickSync deinterlacer

Posted: Wed Feb 01, 2017 4:46 pm
by Sharc
Bingo! All ok now. (Except the duplication of the first frame, as you mention in the doc).

Re: Standalone QuickSync deinterlacer

Posted: Wed Feb 01, 2017 5:42 pm
by admin
Thanks for the update, Sharc. I screwed up the upload. Sorry for the inconvenience.

What processor and OS are you running on?

Re: Standalone QuickSync deinterlacer

Posted: Thu Feb 02, 2017 1:28 am
by 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

Re: Standalone QuickSync deinterlacer

Posted: Thu Feb 02, 2017 7:16 am
by admin
Thank you, Sharc.

Re: Standalone QuickSync deinterlacer

Posted: Tue Feb 07, 2017 9:07 am
by 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

Re: Standalone QuickSync deinterlacer

Posted: Sat Mar 25, 2017 4:29 pm
by 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.

Re: Standalone QuickSync deinterlacer

Posted: Sat Mar 25, 2017 6:03 pm
by 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 ?

Re: Standalone QuickSync deinterlacer

Posted: Sat Mar 25, 2017 6:48 pm
by admin
hydra3333 wrote: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.

Re: Standalone QuickSync deinterlacer

Posted: Sat Mar 25, 2017 10:52 pm
by Aleron Ives
:!:

Re: Standalone QuickSync deinterlacer

Posted: Sun Mar 26, 2017 9:17 am
by Sharc
Enjoy the taste of Globalization, guys!

Re: Standalone QuickSync deinterlacer

Posted: Sun Mar 26, 2017 9:34 am
by 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.

Re: Standalone QuickSync deinterlacer

Posted: Mon Mar 27, 2017 4:33 am
by hydra3333
admin wrote: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.
admin wrote: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
8-)