Standalone QuickSync deinterlacer

This is the home of QuickSync (aka Intel Media SDK) stuff.
Sharc
Distinguished Member
Distinguished Member
Posts: 208
Joined: Thu Sep 23, 2010 1:53 pm

Re: Standalone QuickSync deinterlacer

Post by Sharc » Wed Feb 01, 2017 2:33 pm

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.

User avatar
admin
Site Admin
Posts: 4382
Joined: Thu Sep 09, 2010 3:08 pm

Re: Standalone QuickSync deinterlacer

Post by admin » Wed Feb 01, 2017 3:40 pm

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

User avatar
admin
Site Admin
Posts: 4382
Joined: Thu Sep 09, 2010 3:08 pm

Re: Standalone QuickSync deinterlacer

Post by admin » Wed Feb 01, 2017 4:00 pm

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

Sharc
Distinguished Member
Distinguished Member
Posts: 208
Joined: Thu Sep 23, 2010 1:53 pm

Re: Standalone QuickSync deinterlacer

Post by Sharc » Wed Feb 01, 2017 5:46 pm

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

User avatar
admin
Site Admin
Posts: 4382
Joined: Thu Sep 09, 2010 3:08 pm

Re: Standalone QuickSync deinterlacer

Post by admin » Wed Feb 01, 2017 6:42 pm

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

What processor and OS are you running on?

Sharc
Distinguished Member
Distinguished Member
Posts: 208
Joined: Thu Sep 23, 2010 1:53 pm

Re: Standalone QuickSync deinterlacer

Post by Sharc » Thu Feb 02, 2017 2:28 am

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

User avatar
admin
Site Admin
Posts: 4382
Joined: Thu Sep 09, 2010 3:08 pm

Re: Standalone QuickSync deinterlacer

Post by admin » Thu Feb 02, 2017 8:16 am

Thank you, Sharc.

User avatar
admin
Site Admin
Posts: 4382
Joined: Thu Sep 09, 2010 3:08 pm

Re: Standalone QuickSync deinterlacer

Post by admin » Tue Feb 07, 2017 10:07 am

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

User avatar
admin
Site Admin
Posts: 4382
Joined: Thu Sep 09, 2010 3:08 pm

Re: Standalone QuickSync deinterlacer

Post by admin » Sat Mar 25, 2017 4:29 pm

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.

User avatar
hydra3333
Distinguished Aussie Member
Distinguished Aussie Member
Posts: 164
Joined: Wed Oct 06, 2010 3:34 am
Contact:

Re: Standalone QuickSync deinterlacer

Post by hydra3333 » Sat Mar 25, 2017 6:03 pm

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 ?

Post Reply