Page 1 of 1

[RESOLVED] DGDecodeNV <=> DGDecodeIM Different Frame On Same ID

Posted: Mon Oct 27, 2014 11:04 pm
by MeteorRain

Code: Select all

nv = dgsource("xxx.dgi").reduceby2
im = dgsourceim("xxx.dgi").reduceby2
stackhorizontal(nv, im)
Suppose I have a script like this. xxx.dgi is the project file of a MPEG2-TS recorded from TV.

The image from nv appears to be 2 frames ahead of im. i.e. nv[100] == im[102]. Also nv[last] appears to be broken (above half correct below half random image) but im[last] is a good frame.

Is this considered a bug? Do I need to upload the source / project file? This issue appears on large number of TS sources and is not specific on a single sample.

VERSION: NV2048 IMBeta20HW. Debug=true shows the same Display/Coded frame number.

Re: DGDecodeNV <=> DGDecodeIM Different Frame On Same ID

Posted: Tue Oct 28, 2014 11:54 am
by admin
Could be a bug, but I need a source stream that can be used to duplicate and debug the problem. Can you provide that for me please?

Re: DGDecodeNV <=> DGDecodeIM Different Frame On Same ID

Posted: Tue Oct 28, 2014 3:00 pm
by MeteorRain
admin wrote:Could be a bug, but I need a source stream that can be used to duplicate and debug the problem. Can you provide that for me please?
https://www.dropbox.com/sh/3ewrv5l52upr ... tMa0a?dl=0

Here you go. I suppose a random sliced commercial does not involve any copyright problem and it should be enough to demonstrate the problem.

Re: DGDecodeNV <=> DGDecodeIM Different Frame On Same ID

Posted: Wed Oct 29, 2014 8:48 am
by admin
Thank you. I have duplicated the issue and am investigating it.

Re: DGDecodeNV <=> DGDecodeIM Different Frame On Same ID

Posted: Mon Mar 16, 2015 12:23 pm
by admin
I found some time to look into this. Fortunately, it is definitely a problem in DGDecIM and not DGDecNV. I'll probably have to seek Intel support to solve this. Keep your fingers crossed...

Interestingly, the bug also explains a glitch at the start I find with double-rate deinterlacing.

Re: DGDecodeNV <=> DGDecodeIM Different Frame On Same ID

Posted: Tue Mar 17, 2015 12:33 pm
by admin
It's a problem in the older decode sample that I started with (surface management is screwed). The latest decode sample works fine and matches DGDecNV. So I am rebuilding DGDecIM based on the latest decode sample.

Re: DGDecodeNV <=> DGDecodeIM Different Frame On Same ID

Posted: Sun Mar 29, 2015 2:22 pm
by admin
Status update...

After some hair-raising moments, I was able to re-engineer DGDecIM to use the latest Intel decode sample code. So far I have implemented MPEG2 and VC1 support and tested the sample provided by MeteorRain. The output and random access now matches DGDecNV.

I find that the new Intel decode sample design allows not only for accurate random access but also for a simplified and more robust interface to the Avisynth filter code, definitely making it worth our while to proceed with the re-engineering. The remaining tasks are to implement AVC, and then add back deinterlacing support, etc.

Re: DGDecodeNV <=> DGDecodeIM Different Frame On Same ID

Posted: Mon Mar 30, 2015 1:36 am
by MeteorRain
:idea: Nice

Re: DGDecodeNV <=> DGDecodeIM Different Frame On Same ID

Posted: Mon Mar 30, 2015 8:30 am
by admin
Update: AVC video is working now. That's all the ES formats working. Next I have to test all the containers for each ES format, and then implement deinterlacing.

Update 2: All containers working. Moving on to implement the VPP.

Re: DGDecodeNV <=> DGDecodeIM Different Frame On Same ID

Posted: Tue Mar 31, 2015 1:46 pm
by admin
Here is a new beta for testing before starting the VPP support, beta 50:

http://rationalqm.us/misc/dgdecim_b50.zip

Random access should be correct and robust and it should match DGDecNV. Your test results will be greatly appreciated. Thank you.

Re: DGDecodeNV <=> DGDecodeIM Different Frame On Same ID

Posted: Wed Apr 01, 2015 2:42 pm
by nixo
Hi,

Thank you for this. I've been testing the x86 .dll with Avisynth+ and haven't had any issues.

Re: DGDecodeNV <=> DGDecodeIM Different Frame On Same ID

Posted: Wed Apr 01, 2015 3:09 pm
by admin
Great to hear, nixo, thank you for your test results. VPP support is going fine and you'll have deinterlacing, etc., soon.

Re: DGDecodeNV <=> DGDecodeIM Different Frame On Same ID

Posted: Thu Apr 02, 2015 9:20 am
by admin
I successfully implemented the VPP, however, when I enable deinterlacing RunFrameVPPAsync() returns an error that crashes everything. It happens with the out-of-the-box sample code also. I have posted a query about this at the Intel forum, and hopefully a solution will be forthcoming.

Re: DGDecodeNV <=> DGDecodeIM Different Frame On Same ID

Posted: Fri Apr 03, 2015 6:45 pm
by admin
Oy, I thought things were looking up for Intel support but after their reply, I am having doubts again. OK, let's wait to see what "the team" says, but my experience is that when you get a reply like that, you're not going to hear from them again any time soon. I hope they prove me wrong about that! Sometimes it's good to be wrong. :P

Re: DGDecodeNV <=> DGDecodeIM Different Frame On Same ID

Posted: Tue Apr 07, 2015 11:00 am
by admin
It doesn't look good for getting VPP functionality working any time soon, due to lack of Intel support. So I have linked b50 as the release version. I'm marking this thread as RESOLVED, however, because the mismatch with DGDecNV has been resolved.