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 + 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 + 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.