DGDecIM: Frame-accurate Avisynth source filter for QuickSync

[Guest]

I've made enough progress on supporting the Intel Media SDK in DGDec to start a new thread. I plan to have DGDec support both nVidia and Intel decode engines but for the purposes of this thread I will call it DGDecIM.

The chick has poked its head through the eggshell but still has to wriggle its whole body out. What I have done is this: I made a DGI for an AVC stream (panama.264 famous in another thread) using DGIndexNV in the normal way. Then I modified DGDecodeNV to support the Intel decode engine using the same DGI file. Random access is working fine and I get over 200fps for a 1080p stream with 8% CPU usage in QuickSync mode. Pretty fine! The implementation uses what I called a potential simplified design in the DGMVCSource thread, so that one thread and consequent synchronization (with large Windows scheduling delays) is eliminated, significantly increasing the decode frame rate.

Before releasing a beta, I still need to add VC1 and MPEG2 and generally check robustness and end of stream handling. Also, I can consider adding support for Intel HW cropping/resizing, deinterlacing, IVTC, etc., and add MVC support. But things are looking good!

-----
Current version:

http://neuron2.net/misc/dgdecim_b20.zip
-----

NOTES ON POSTING IN THIS THREAD:

Rules 3 and 11 (rules (http://forum.doom9.org/forum-rules.htm)) are enforced broadly in this thread and posters are asked to make sure all posts have useful technical content and/or report defects. Requests about status of developments, expressions of approval or disapproval thereabout, chit-chat, and other random nontechnical posts are eschewed and may be deleted. I believe this policy results in a more useful and readable thread. Thank you for your understanding and cooperation.

Posts reporting defects should provide a source stream, the Avisynth script, and instructions for demonstrating the defect with that same source stream and script.

[mastrboy]

It has begun :)

Will it be licensed as DGIndexNV is? and if so, would existing DGIndexNV users be able to reuse their licenses or would it require a new one?

[Guest]

I haven't decided about that stuff yet.

[Guest]

Status update: I have implemented the EOS stream handling and it is working fine. I have added support for MPEG2 and VC1. Unfortunately, the current HW support for VC1 is broken (http://software.intel.com/en-us/forums/topic/494916) and a fix is expected possibly at the end of February. The VC1 support works fine in SW mode (which is way slower of course) so I will release a beta that forces SW mode for VC1 input. I want to do a little more testing and then I'll give you guys a beta, possibly as early as tomorrow.

[Guest]

Here is beta 1:

http://neuron2.net/misc/dgdecodeim_b1.zip

As mentioned earlier, this requires you to use DGIndexNV to create your index file. I am working on an indexer that can be used without Nvidia.

Please read the Notes.txt document for usage information.

Your feedback will be appreciated.

EDIT: In some initial tests, QuickSync appears about 20-25% faster than CUVID.

[Stereodude]

1080i MPEG2 Intel engine:Number of frames: 10001
Length (hhh:mm:ss.ms): 000:05:33.700
Frame width: 1920
Frame height: 1080
Framerate: 29.970 (30000/1001)
Colorspace: YV12

Frames processed: 10001 (0 - 10000)
FPS (min | max | average): 79.22 | 320.96 | 191.33
CPU usage (average): 11%
Thread count: 31
Physical Memory usage (peak): 565 MB
Virtual Memory usage (peak): 715 MB
Time (elapsed): 000:00:52.272

1080i MPEG2 Nvidia engine:Number of frames: 10001
Length (hhh:mm:ss.ms): 000:05:33.700
Frame width: 1920
Frame height: 1080
Framerate: 29.970 (30000/1001)
Colorspace: YV12

Frames processed: 10001 (0 - 10000)
FPS (min | max | average): 68.01 | 261.23 | 141.07
CPU usage (average): 13%
Thread count: 6
Physical Memory usage (peak): 526 MB
Virtual Memory usage (peak): 625 MB
Time (elapsed): 000:01:10.896

[Guest]

Thanks, interesting! That's about 35% faster with 2% less CPU using QuickSync.

Now, if Intel can fix the VC1 HW support, we will be golden.

[Stereodude]

1080p H264 (Blu-Ray) Intel engine:Number of frames: 10000
Length (hhh:mm:ss.ms): 000:06:57.083
Frame width: 1920
Frame height: 1080
Framerate: 23.976 (24000/1001)
Colorspace: YV12

Frames processed: 10000 (0 - 9999)
FPS (min | max | average): 50.13 | 338.37 | 170.68
CPU usage (average): 4%
Thread count: 31
Physical Memory usage (peak): 571 MB
Virtual Memory usage (peak): 691 MB
Time (elapsed): 000:00:58.591

1080p H264 (Blu-Ray) Nvidia engine:Number of frames: 10000
Length (hhh:mm:ss.ms): 000:06:57.083
Frame width: 1920
Frame height: 1080
Framerate: 23.976 (24000/1001)
Colorspace: YV12

Frames processed: 10000 (0 - 9999)
FPS (min | max | average): 50.31 | 172.54 | 89.84
CPU usage (average): 3%
Thread count: 4
Physical Memory usage (peak): 475 MB
Virtual Memory usage (peak): 556 MB
Time (elapsed): 000:01:51.307

[Guest]

Wow! :scared:

Don't bother posting VC1 as HW acceleration is not yet implemented for Intel.

[Stereodude]

I have a troublesome 1080i MPEG-2 TS sample (http://www.sendspace.com/file/n3holw) for you.

AVS script:LoadPlugin("C:\HDTV Tools\DGDecIM\DGDecodeIM.dll")

DGSource("test_clip2.dgi",engine=0)
My findings:
The Intel engine will lock VD up when trying to step backward through the clip. To see this open the script in VD, jump to frame 125 (CTRL+G), and then press and hold down the left arrow on the keyboard.
The Nvidia engine doesn't lock up, but won't decode the clip correctly when stepping backward either (DGDecNV does the same thing also). To see this change the engine in the script, open the script in VD, jump to frame 125 (CTRL+G), and then step backward to frame 103 (or earlier).
DGMPGDec has no problem stepping backward with the clip.
The Intel engine and Nvidia engine don't return the same video. You can see this with the following script. Play/step to frame 24&25 and you'll see they're offset 1 frame from each other, yet both return 242 frames. FWIW, the Nvidia engine matches DGMPGDec with this test.LoadPlugin("C:\HDTV Tools\DGDecIM\DGDecodeIM.dll")

source1=DGSource("test_clip2.dgi",engine=0)
source2=DGSource("test_clip2.dgi",engine=1)

stackvertical(source1,source2)

[Sharc]

ok, I have prepared the .dgi with DGIndexNV.
How do I use DGDecodeIM now? DGsource(.....dgi, engine=1)? Can you perhaps post an example for a basic script?

Edit: I just got it....

[Stereodude]

Wow! :scared:I suppose I should mention I'm using a i7-4770k w/ HD 4600 integrated graphics and a GeForce GT440 (VP5).

[Sharc]

Here a problematic VC-1 interlaced source (http://www.mediafire.com/download/66cjz888bfha6xz/vc-1_hulk.m2ts).
SW decoding (engine=1); NVIDIA GForce 9600GS.

[Reel.Deel]

Hi neuron2,

Tried various Blu-ray/DVD sources and they all work with the Nvidia engine, but with the Intel engine VirtualDub instantly just hangs and no error message.
In AVSMeter I get the following message:

AVSMeter 1.7.6 (AVS 2.6, x86) by Groucho2004
Analysing script, please wait...
Return on error: error code -3, pipeline_decode.cpp 316

Don't know if this is any help but my CPU is a i7-4930k (http://ark.intel.com/products/77780) (no integrated graphics).

[Guest]

ok, I have prepared the .dgi with DGIndexNV.
How do I use DGDecodeIM now? DGsource(.....dgi, engine=1)? Can you perhaps post an example for a basic script?

Edit: I just got it.... Just for others then:

loadplugin("dgdecodeim.dll")
dgsource("file.dgi") #uses Intel
dgsource("file.dgi", engine=0) # uses Intel
dgsource("file.dgi", engine=1) #uses CUVID

[Guest]

Here a problematic VC-1 interlaced source (http://www.mediafire.com/download/66cjz888bfha6xz/vc-1_hulk.m2ts).
SW decoding (engine=1); NVIDIA GForce 9600GS. In what way is it problematic? Does it work in plain DGDecNV?

[Guest]

Hi neuron2,

Tried various Blu-ray/DVD sources and they all work with the Nvidia engine, but with the Intel engine VirtualDub instantly just hangs and no error message.
In AVSMeter I get the following message:

Don't know if this is any help but my CPU is a i7-4930k (http://ark.intel.com/products/77780) (no integrated graphics). I'll release a new beta this evening with some more tracing to see what is happening. I simply do not know if the Intel Media SDK will work in SW mode without integrated graphics. Further tracing will reveal the answer.

[Stereodude]

Don't know if this is any help but my CPU is a i7-4930k (http://ark.intel.com/products/77780) (no integrated graphics).If you don't have an iGPU do you have the QuickSync engine?

[Sharc]

In what way is it problematic? Does it work in plain DGDecNV?
It produces jerky playback and blended frames.
It works in plain DGDecNV, however there are few duplicated frames (hard telecined?) which cause some jerkyness, but no blended frames in DGDecNV.

[Guest]

If you don't have an iGPU do you have the QuickSync engine? Intel supports SW decoding also, so intuitively you wouldn't need an iGPU for that. Unless...even the SW support requires the appropriate Intel driver, which would not be installed on a system without an iGPU. We can do some tracing to see what is really true.

[Guest]

It produces jerky playback and blended frames.
It works in plain DGDecNV, however there are few duplicated frames (hard telecined?) which cause some jerkyness, but no blended frames in DGDecNV. DGDecodeNV() and DGDecodeIM(engine=1) should act the same. I will investigate it.

[rack04]

Intel supports SW decoding also, so intuitively you wouldn't need an iGPU for that. Unless...even the SW support requires the appropriate Intel driver, which would not be installed on a system without an iGPU. We can do some tracing to see what is really true.

What driver are you referring to? I just tried engine=0 and I get the same crash. I assume there is something that needs to be installed.

[Guest]

I'm talking about the Intel graphics driver. If you have an iGPU in your processor and you run Nvidia as your primary, you can still access QuickSync, but you have to enable the Intel GPU in the bios and then install the Intel driver as secondary. Then you will have both QuickSync and CUVID. I am still investigating what the situation is for Intel Media SDK in SW mode on a processor without an iGPU.

[Guest]

Don't know if this is any help but my CPU is a i7-4930k (http://ark.intel.com/products/77780) (no integrated graphics). Can you try installing the Intel Media SDK 2014 and let me know if that changes anything? There is this thing called a "mfx dispatcher" that calls the HW or the SW DLL. It seems the dispatcher is in the SDK. I'm just learning about this stuff along with you guys. ;)

http://software.intel.com/en-us/vcsource/tools/media-sdk

Also, can you try opening an AVC file with dgmvcsource() using SW mode (hw=1)?

[Reel.Deel]

Can you try installing the Intel Media SDK 2014 and let me know if that changes anything?
Is there another place where I can download this without registration?

Also, can you try opening an AVC file with dgmvcsource() using SW mode (hw=1)?

Tried the latest version with hw=1 and it works. Used the sample that was included in the earlier betas.

[Guest]

Is there another place where I can download this without registration? It's not a big deal. If you want to be on the bleeding edge, you sometimes need to do the needful. :D

Nevertheless, you're right, it seems a bit much to require end users to install an SDK.

Tried the latest version with hw=1 and it works. Used the sample that was included in the earlier betas. That changes things in a very positive way. ;) I will release a beta later today or tomorrow that allows you to force SW mode, and should get things working for you.

Thank you for the important test results! :thanks:

[kypec]

Also, can you try opening an AVC file with dgmvcsource() using SW mode (hw=1)?
That switch definition seems quite counter-intuitive, isn't it? :confused:
I'd expect that forcing software mode should be activated by either hw=0 or sw=1...

[Guest]

That switch definition seems quite counter-intuitive, isn't it? :confused:
I'd expect that forcing software mode should be activated by either hw=0 or sw=1... The documentation explains that "hw" is an integer offering various choices and not a boolean. "hw" is renamed as "engine" for DGDecIM, and if you understand it that way I'm sure the confusion will dissolve away.

[Guest]

Here is beta 2 with expanded engine options. You can force SW for Intel, for example.

http://neuron2.net/misc/dgdecodeim_b2.zip

@Reel.Deel

This should fix your issue. I expect it to work either with Intel auto or Intel SW in your system. Please advise your results.

EDIT: Please use beta 3 and make sure you have libmfxsw32.dll co-located with dgdecodeim.dll.

[rack04]

I assume I can test this software by using a computer with Nvidia card to index using DGDecNV and then transfer that index file to a laptop without a Nvidia card to test using iGPU?

[Guest]

I assume I can test this software by using a computer with Nvidia card to index using DGDecNV and then transfer that index file to a laptop without a Nvidia card to test using iGPU? That will work as long as the paths in the DGI file are correct after moving to the laptop. You can edit the DGI file as needed or deselect 'use full paths' when you make the index file.

This will be moot soon as I am working on the stand-alone indexer.

[Stereodude]

Here is beta 2 with expanded engine options. You can force SW for Intel, for example.

http://neuron2.net/misc/dgdecodeim_b2.zipengine=2 instantly crashes VirtualDub when I try it on the files I previously tested with. 0, 1 and 3 work okay.

[Guest]

OK, thanks, checking...

[Guest]

engine=2 works fine for me. Do you have the libmfxsw32.dll in the same place as dgdecodeim.dll?

I have added the libmfxsw32.dll to the ZIP and revised the Notes to mention it. If this turns out to be the reason for your crash I will fix up the error checking to be a little more helpful. :)

[Guest]

OK, my bad...

I have to add the code to find libmfxsw32 as it is in DGMVCSource. For now, put it in the system dir and I will release a fixed beta.

Thanks for pointing this out.

[Stereodude]

engine=2 works fine for me. Do you have the libmfxsw32.dll in the same place as dgdecodeim.dll?

I have added the libmfxsw32.dll to the ZIP and revised the Notes to mention it. If this turns out to be the reason for your crash I will fix up the error checking to be a little more helpful. :)I didn't have it. I wasn't aware that there was any requirement for an extra file. I have subsequently added it into C:\HDTV Tools\DGDecIM\ where DGDecodeIM.dll is, but the crash is the same.

Here's the crashinfo from VD (http://www.sendspace.com/file/1cz8bi).

[Stereodude]

I have to add the code to find libmfxsw32 as it is in DGMVCSource. For now, put it in the system dir and I will release a fixed beta.So, that's C:\Windows\SysWOW64 on a x64 system... Works now.

[Guest]

Here is beta 3 with the correct dll loading code. Now the libmfxsw32.dll can be put with dgdecodeim.dll and you don't need to put it in the system directory.

http://neuron2.net/misc/dgdecodeim_b3.zip

Thanks again for your test results.

[Stereodude]

For whatever it's worth, the Intel SW engine has all the same problems (lockup stepping backward and returning at least part of the the video offset by 1 frame) as the HW engine that I detailed in this post (http://forum.doom9.org/showthread.php?p=1668691#post1668691).

[Guest]

I have a troublesome 1080i MPEG-2 TS sample (http://www.sendspace.com/file/n3holw) for you. Thanks. I'll look into it.

[Stereodude]

Here is beta 3 with the correct dll loading code. Now the libmfxsw32.dll can be put with dgdecodeim.dll and you don't need to put it in the system directory.

http://neuron2.net/misc/dgdecodeim_b3.zipI can confirm it works without libmfxsw32.dll in the system directory.

[Guest]

I can confirm it works without libmfxsw32.dll in the system directory. Thank you.

[CarlPig]

I can't get it to work, because i got this error: error=0x7e

[Guest]

I can't get it to work, because i got this error: error=0x7e What did you do and where did you see that error? What is the input file information, your script, etc?

[CarlPig]

1. Created the dgi file on one of my 2 pc's with DGIndexNV 2046 and NVIDIA Geforce GTX 560 TI.
2. Created a avs file to the dgi file and it worked on that pc.
3. Moved all 3 files, a mkv file with mpeg2 codec, the dgi file and the avs file to my other pc with QuickSync.
4. Extracted the beta 3 to DGIndexNV folder.
5. Corrected the dgi file and avs file with the new paths for the mkv file and replaced DGDecodeNV.dll with DGDecodeIM.dll ind the avs file.
6. Installed Intel Media SDK 2014
7. Replaced fieldop=0 with engine=1

Note: engine=0 gives the same error.

http://cloudho.st/i/2h5KfT7D.png

Script:
LoadPlugin("C:\Program Files (x86)\MeGUI\tools\dgindexnv\DGDecodeIM.dll")
DGSource("C:\Video\New folder\KS1975.dgi", engine=1)

[Guest]

Do you have libmfxsw32.dll in the same directory as dgdecodeim.dll?

Please show a screenshot of windows explorer open to C:\Program Files (x86)\MeGUI\tools\dgindexnv.

Your Avisynth installation may be missing some run-time DLLs. Are other scripts running OK? DGMVCSource?

[Reel.Deel]

@Reel.Deel

This should fix your issue. I expect it to work either with Intel auto or Intel SW in your system. Please advise your results.

EDIT: Please use beta 3 and make sure you have libmfxsw32.dll co-located with dgdecodeim.dll.

Thanks for the quick update, I just quickly tried with engine=0 and engine=2 and both work. Unfortunately the speed it's not very good. With AVSMeter I get 34fps with Intel SW and 150fps with Nvidia.
Is there any room for improvement in this area or is it all up to Intel?

[CarlPig]

Do you have libmfxsw32.dll in the same directory as dgdecodeim.dll?

Please show a screenshot of windows explorer open to C:\Program Files (x86)\MeGUI\tools\dgindexnv.

Your Avisynth installation may be missing some run-time DLLs. Are other scripts running OK? DGMVCSource?

My DGIndexNV Dir: http://cloudho.st/i/TfRMPV7D.png

DGMVCSource comes with this error message when i use a mkv: http://cloudho.st/i/I4XLQV7D.png

But if i demux the h264 stream out of the mkv file and open it with DGMVCSource it works.

This works:
LoadPlugin("C:\Program Files (x86)\MeGUI\tools\dgmvcdecode\dgmvcdecode.dll")
DGMVCSource("C:\Video\New folder\station.2-001.h264","",view=0,frames=1000,hw=1)

But this one do not work, it gives that error i have linked to a little further up in this post:
LoadPlugin("C:\Program Files (x86)\MeGUI\tools\dgmvcdecode\dgmvcdecode.dll")
DGMVCSource("C:\Video\New folder\station.2-001.mkv","",view=0,frames=1000,hw=1

Note: I have installed the newest chipset, graphics driver and Intel Media SDK 2014

My mainboard is a ASUS Z87-K
My CPU is a i5-4670 with integrated graphics

[ryszardzonk]

My digital platform have recently upgraded to new http://www.ericsson.com/ourportfolio/products/avp-4000-family system and I am kinda forced to upgrade from the ancient DGIndex/DGAVCIndex as more and more streams appeared in new format and was about to go with DiAVC + DGAVCDecDI (as I have no Nvidia card), but I read this DGDecIM appeared :)

My question is would DGDecIM work on any Intel CPU (using sw for non Quicksync platform) and if yes than what do I need to get it to work besides purchasing license for DGDecNV which I am about to do shortly ;)

[Guest]

Thanks for the quick update, I just quickly tried with engine=0 and engine=2 and both work. Unfortunately the speed it's not very good. With AVSMeter I get 34fps with Intel SW and 150fps with Nvidia.
Is there any room for improvement in this area or is it all up to Intel? It's all up to Intel. Anyway, the point of this development is to get QuickSync support. The SW support is a bonus.

[Guest]

But if i demux the h264 stream out of the mkv file and open it with DGMVCSource it works.
OK, thanks, I know what the problem is and will fix it for the next beta. MKV input is broken for MPEG2 and VC1 (AVC is OK) with Intel Media SDK. Please test only with elementary streams from MPEG2 or VC1 MKVs until then.

It's interesting because this bug has been there in DGDecNV all along but the NV decoder doesn't mind seeing double start code prefixes. :)

[Guest]

My question is would DGDecIM work on any Intel CPU (using sw for non Quicksync platform) and if yes than what do I need to get it to work besides purchasing license for DGDecNV which I am about to do shortly ;) It should work but I haven't decided about licensing yet. Most likely I will cover it under the DGDecNV license as you suggested. Remember, though, this is still under development, I haven't formally announced anything or made a release for general availability. And during this early development period you will need Nvidia HW to run DGIndexNV to generate your index files.

[CarlPig]

OK, thanks, I know what the problem is and will fix it for the next beta. Please test only with elementary streams until then.

Ok good to know.

[Guest]

Ok good to know. Just to clarify, only MPEG2 and VC1 MKV files are affected.

[Guest]

Here is beta 4:

http://neuron2.net/misc/dgdecim_b4.zip

The problem with MPEG2 and VC1 in MKV containers is fixed.

A quick-and-dirty indexer for non-Nvidia systems is included. It requires the standard license so your existing licenses will work. Those people without Nvidia systems can get a license and then be able to operate on a non-Nvidia system. Please be aware that we are still in early development but things are pretty much working.

[CarlPig]

I need a license to my non-Nvidia system, because i only have a license to my Nvidia system.

[Guest]

Ah, I forgot about that! :scared: How to get the machine ID? Standby...

[Guest]

Re-download beta 4. Now if you type 'dgindexim' without parameters in a DOS window you will see the machine ID.

[Guest]

Sorry, re-download as I made a quick bug fix in the machine ID printing (to show as uppercase).

[CarlPig]

Ok i will re-download and trying it.

[CarlPig]

Now i get the machine ID, i can get it when i type dgindexim in DOS or double clicking on the indexer.
I have indexed a MKV with MPEG2 and get the dgi file.
But i still get this error: "error=0x7e" when i trying to open my script.

[Guest]

Please give me the input file.

[CarlPig]

I can not give you a sample right now, because my internet connection is too slow.

so I have to wait until my family gets up when they are sleeping now, so i can borrow their internet connection.

[Guest]

You can cut a smaller piece. Anyway, I wait for your sample. Also please give your script.

[CarlPig]

Here:
LoadPlugin("C:\Video\New folder\DGDecodeIM.dll")
DGSource("C:\Video\New folder\KS1975.dgi", engine=1)

[Guest]

That forces Intel HW. Didn't you say you had no iGPU? Did you try engine=2 for SW?

[CarlPig]

Here is a sample:
http://www.mediafire.com/download/q1ir8yzyj11noxa/KM1975.Sample.mkv

I do not know specifically what iGPU is, and I do not think that I find something useful by writing iGPU on Google.

And i got the same error with both engine=0,1 and 2.

[Guest]

iGPU refers to an Intel GPU integrated into the CPU.

Everything works fine for me here with your sample. Can you please do these three things to help find out why it is not working for you:

1. Give details of your processor.

2. Run the system analyzer tool from the Intel Media SDK install and show the output. The analyzer is in the tools folder.

3. Run Dependency Walker on dgdecodeim.dll and report any unresolved DLLs.

[CarlPig]

My mainboard is a ASUS Z87-K: https://www.asus.com/Motherboards/Z87K/‎
My CPU is a i5-4670: http://ark.intel.com/products/75047/

Intel Media SDK System Analyzer (64 bit)

The following versions of Media SDK API are supported by platform/driver:

Version Target Supported Dec Enc
1.0 HW Yes X X
1.0 SW Yes X X
1.1 HW Yes X X
1.1 SW Yes X X
1.3 HW Yes X X
1.3 SW Yes X X
1.4 HW Yes X X
1.4 SW Yes X X
1.5 HW Yes X X
1.5 SW Yes X X
1.6 HW Yes X X
1.6 SW Yes X X
1.7 HW Yes X X
1.7 SW Yes X X
1.8 HW No
1.8 SW Yes X X

Graphics Devices:
Name Version State
Intel(R) HD Graphics 4600 10.18.10.3345 Active

System info:
CPU: Intel(R) Core(TM) i5-4670 CPU @ 3.40GHz
OS: Microsoft Windows 8.1 Pro
Arch: 64-bit

Installed Media SDK packages (be patient...processing takes some time):
Intel« Media SDK 2014 for Clients (x64)

Installed Media SDK DirectShow filters:

Installed Intel Media Foundation Transforms:
Intel« Hardware M-JPEG Decoder MFT : {00C69F81-0524-48C0-A353-4DD9D54F9A6E}
Intel« Quick Sync Video H.264 Encoder MFT : {4BE8D3C0-0515-4A37-AD55-E4BAE19AF471}

Here is a screenshot from Dependency Walker: http://cloudho.st/i/6GkKqoXd.png

[Guest]

Thank you, Carl, that is great info and I can see the problem now from your DLL trace.

DGDecodeIM currently supports also the Nvidia engine via engine=3. It is desirable to be able to support all the available engines but if done simply as I have done, the DLL will have dependencies on all the DLLs associated with the various engines. In your case it fails to find the CUDA/CUVID DLLs because they are not installed.

I can either try to find a way to support all the engines in one filter using some tricks for DLL loading or I can release an Intel-only version that doesn't have dependencies on CUDA. I'll explore this today and make a decision. The easiest will be to make an Intel-only version. Either way you'll be able to run the code on your non-Nvidia system.

Thanks again for your help in uncovering this issue! :thanks:

[CarlPig]

I'm happy to help you.

[Guest]

Carl, can you please try this DLL? I did a quick and dirty removal of CUDA dependencies. Don't try engine=3!

http://neuron2.net/misc/Carl.zip

[CarlPig]

It working, i have now converted a movie.

I have used engine=1

[Guest]

OK, great! I'll make a clean new beta and we can open this to a wider audience.

Your assistance is greatly appreciated.

[CarlPig]

Thanks.

[Guest]

Here's beta 5, the first usable version for non-Nvidia users.

http://neuron2.net/misc/dgdecim_b5.zip

Next I will integrate the indexer into the source filter and then start addressing the problem streams that have been mentioned. Also, I want to look at performance because pistacho says 700fps is possible. :) There is a doubtful Sleep() call in the decode sample, and other things to look at.

[Sharc]

4. The engine options chooses the decoding engine.
engine = 0: Intel automatic (uses HW if available, otherwise uses SW)
engine = 1: Intel HW
engine = 2: Intel SW
So for Nvidia it is engine=0, or is Nvidia no more included?

[Sharc]

DGDecodeNV() and DGDecodeIM(engine=1) should act the same. I will investigate it.
Did you have a chance to look at it?

[Guest]

That's in the problem stream category. Still working on basic functionality at this point. All reports have been noted and will be addressed.

[CarlPig]

Intel HW cropping/resizing and deinterlacing will be great to have.

[Guest]

So for Nvidia it is engine=0, or is Nvidia no more included? Nvidia is not included. Future may bring it back if DLL tricks can be played.

[lansing]

I tested with a 1080p mp4 that I downloaded from youtube, on my i7 4770k @ 4.3Ghz, HD4600.

avsmeter reads:

Number of frames: 9419
Length (hhh:mm:ss.ms): 000:05:14.281
Frame width: 1920
Frame height: 1088
Framerate: 29.970 (2997/100)
Interlaced: No
Colorspace: YV12

Frames processed: 9419 (0 - 9418)
FPS (min | max | average): 125.1 | 439.3 | 374.5
CPU usage (average): 10%
Thread count: 39
Physical Memory usage (peak): 168 MB
Virtual Memory usage (peak): 322 MB
Time (elapsed): 000:00:25.154


the frame height was wrong. And the index note doesn't have the display size and frame rate correct.


Stream Type: MP4
Video Type: AVC
Profile: High
Level: 4
Coded Size: 1920x1088
SAR: 1:1
Display Size: 0x0
Frame Rate: 0.000000 fps
Colorimetry: BT.709 [1]*
Frame Structure:
Frame Type:
Coded Number: 9419
Playback Number: 9419
Frame Repeats: 0
Field Repeats: 0
Bitrate:
Bitrate (Avg):
Bitrate (Max):
Audio Stream: 1: MPEG-4 AAC LC 126kbps 44100 2ch
Elapsed:
Remain: 0:00:00
FPS:
Info: Finished!

[lansing]

with a concert h264 bd muxed into mkv.

Intel QuickSync HW

Frames processed: 14120 (0 - 14119)
FPS (min | max | average): 108.9 | 378.0 | 273.9
CPU usage (average): 10%
Thread count: 39
Physical Memory usage (peak): 185 MB
Virtual Memory usage (peak): 332 MB
Time (elapsed): 000:00:51.556


with nvdia gtx 650 ti boost

Frames processed: 4540 (0 - 4539)
FPS (min | max | average): 106.5 | 186.4 | 142.1
CPU usage (average): 3%
Thread count: 16
Physical Memory usage (peak): 76 MB
Virtual Memory usage (peak): 179 MB
Time (elapsed): 000:00:31.951

[Guest]

That's great performance.

The height is the coded frame height, it is not wrong.

The log is a remnant of the GUI DGIndexNV and will be removed along with other obsolete stuff.

[lansing]

with a concert 1080 mpeg2

Intel QuickSync

Frames processed: 5200 (0 - 5199)
FPS (min | max | average): 110.9 | 314.2 | 254.8
CPU usage (average): 15%
Thread count: 40
Physical Memory usage (peak): 179 MB
Virtual Memory usage (peak): 299 MB
Time (elapsed): 000:00:20.409


Nvidia VP5 card

Frames processed: 8000 (0 - 7999)
FPS (min | max | average): 193.8 | 392.2 | 286.0
CPU usage (average): 17%
Thread count: 16
Physical Memory usage (peak): 132 MB
Virtual Memory usage (peak): 191 MB
Time (elapsed): 000:00:27.976


one thing I notice is that when running nvidia card on mpeg2 video, its video engine stayed at 0% + 33% GPU loaded as shown in gpu-z. While when running on h264 video, the video engine was 99% loaded and 5% gpu load.

And for iGPU, its gpu usage scales with the speed. For the highest speed so far 374fps, gpu load is 15%; for 254fps, it's 9%.

[Guest]

Check the INI file and manual description for DGIndexNV. CUDA versus CUVID may make a difference.

[lansing]

Check the INI file and manual description for DGIndexNV. CUDA versus CUVID may make a difference.

I'm using beta4 for this run and seems like the decode mode switch for AVC stream was broken, when I changed the decode_mode in the dgi file to 1,1,1 or 0,0,0 to have them all use CUDA or CUVID, only the MPEG2 stream really shows any effect: I could see a switch of usage from gpu load to video engine load in GPU-Z. The AVC stream has no effect though, as it stayed using the video engine on all three switches.

[Guest]

Yes, this behavior is known and that is why I pointed it out.

Please always use the latest beta going forward.

[lansing]

I thought you mentioned that beta5 didn't have Nvidia engine, that's why I'm using beta4.

I really look forward to the HW IVTC by the Intel engine in the near future, since TIVTC in both Avisynth+ and Vapoursynth weren't doing so great with 1080 videos, I only got 50-60fps.

[Guest]

I thought you mentioned that beta5 didn't have Nvidia engine, that's why I'm using beta4. Well, since you have an Nvidia system you can run DGDecodeNV for comparisons. :sly: The index file is common between the two.

I really look forward to the HW IVTC by the Intel engine in the near future Yes, I'll be excited to experiment with it and see what it can do.

[lansing]

I can confirm that pistacho's MVCsource with latest available version 2.1.1 did reached over 600fps AVC decoding @ 24% GPU loaded. Props to him.

Number of frames: 116220
Length (hhh:mm:ss.ms): 001:04:37.874
Frame width: 1920
Frame height: 1080
Framerate: 29.970 (60000/2002)
Interlaced: No
Colorspace: YV12

Frames processed: 52250 (0 - 52249)
FPS (min | max | average): 287.9 | 707.7 | 606.7
CPU usage (average): 11%
Thread count: 35
Physical Memory usage (peak): 205 MB
Virtual Memory usage (peak): 314 MB
Time (elapsed): 000:01:26.120


And I test Cyberlink's MediaEspresso, looks like it uses Nvidia CUVID for hw decoding and Intel QuickSync for hw encoding when both devices are present, and both device ran at 99% loaded when active. Since the hw encoding side of iGPU can max out the usage, I suspect it can be the same for hw decoding too. Well, like maybe 50% GPU load at 1000+fps? lol

[Guest]

pistacho's done a great job refactoring, though it's a shame he seems reluctant to share his tricks with us. Nevertheless, I've already identified some changes that increase the frame rate (at the expense of CPU). I have reached 350 fps in a private build for a stream that previously ran at 200 fps and see other chances to improve that. I'll release those improvements at some point.

Frame accuracy is the first goal for me, however. As Avisynth expects source filters to be frame accurate, I believe that any source filter that is not frame accurate is either just some kind of decoding test bed or it is broken/crippled. Simulate a seek to near the end of a file by silently decoding the entire file!? No way to seek backward (beyond immediate Avisynth/application caching)?! Color me unimpressed. Sure, such filters can be useful in limited use cases, but why not implement frame accuracy when the methods are known and straightforward to implement?

[Guest]

Here is beta 6. You can specify the source stream instead of the index file in your script and then the DGI file will be automatically created if it does not exist.

http://neuron2.net/misc/dgdecim_b6.zip

With this I consider the basic functionality to be in place and we can start looking at problematic streams. I also have to create some documentation for QuickSync-only users. Then on to performance tweaking and Intel HW-based cropping/resizing/IVTC etc.

[lansing]

Here is beta 6. You can specify the source stream instead of the index file in your script and then the DGI file will be automatically created if it does not exist.

http://neuron2.net/misc/dgdecim_b6.zip

With this I consider the basic functionality to be in place and we can start looking at problematic streams. I also have to create some documentation for QuickSync-only users. Then on to performance tweaking and Intel HW-based cropping/resizing/IVTC etc.

I tried the auto dgi generate, I dragged the avs to virtualdub and I saw the pop up message about index file being generating. However I waited for quite a while but still don't see any file generated and the pop up message just stayed there.

LoadPlugin("path\dgdecim_b6\DGDecodeIM.dll")

DGSource(xyz.mp4", engine=1)

[Guest]

Try hitting OK! :D

Well alright I have updated beta 6 so that the dialog doesn't hold up the indexing and it dismisses itself after 10 seconds if you don't hit OK. Re-download it to get that change.

Even after the warning dialog dismisses, you have to wait until the indexing is complete, and then the first frame will be displayed in VirtualDub. Remember, indexing a BluRay can take 5 minutes or more! Shorter streams will finish much faster. I am welcome to ideas for improving the user interface.

[lansing]

Try hitting OK! :D

Well alright I have updated beta 6 so that the dialog doesn't hold up the indexing and it dismisses itself after 10 seconds if you don't hit OK. Re-download it to get that change.

Even after the warning dialog dismisses, you have to wait until the indexing is complete, and then the first frame will be displayed in VirtualDub. Remember, indexing a BluRay can take 5 minutes or more! Shorter streams will finish much faster. I am welcome to ideas for improving the user interface.

still doesn't seem to work for me. After I drag the avs to virtualdub, immediate after the index generating message box, an error box pop up saying "failed to open input file".

[Guest]

The script you posted is missing a quote. Could that be it? If not, please give your exact script. Also, verify your file name and path, as that is the obvious interpretation of the error message.

[lansing]

ok i figured out the problem, the program filtered out all the space in the filename, so files with their file name contain spaces doesn't work.

[Guest]

What program filtered them out? Your brain? :) Anyway, I am happy you have it working and thank you for your testing.

[lansing]

i renamed the same file to "1.mp4" and it works, when I change it to "1 2.mp4" then it says "failed to open input file".

[Guest]

I see. Investigating that...

EDIT: I know the reason. Thanks for pointing it out. Please standby for fixed version...

[Guest]

OK, I slipstreamed the fix into beta 6 so please re-download it and test. Spaces in filenames should be OK. Needed to quote the arguments for CreateProcess().

[lansing]

yes it's fixed, thanks.

And will one single index file work for both 32bit and 64bit version of the program in the future?

[ryszardzonk]

I tried to use DGDecIM by placing it in the same directory I have located licensed DGIndexNV and DGAVCIndexDI, but when I open the file it spits out an error "Machine ID 9F9AB12C: Incorect options to DGIndex. Please refer to the manual." I would guess it should open just like other apps.

Hence I was not able to open DGDecIM I used DGAVCIndexDI (no nvidia card) to index the file for use in megui which opens just fine with DGAVCDecodeDI.dll plugin renamed to DGAVCDecodeNV.dll, but with new plugin with original name or as DGDecodeNV.dll megui was not able to to load the index giving the "Avisynth script error: DGSource: The input file is not a DG project file."
#LoadPlugin("C:\Program Files\MeGUI\tools\dgindexnv\DGDecodeNV.dll")
LoadPlugin("C:\Program Files\MeGUI\tools\dgindexnv\DGDecodeIM.dll")
#DGSource("D:\kodowanie\20140207 1633 - cz01.dgi",fieldop=0)
DGSource("D:\kodowanie\20140207 1633 - cz01.dgi",engine=0)
any hints?

[Guest]

And will one single index file work for both 32bit and 64bit version of the program in the future? Yes, of course.

[Guest]

I tried to use DGDecIM by placing it in the same directory I have located licensed DGIndexNV and DGAVCIndexDI, but when I open the file it spits out an error "Machine ID 9F9AB12C: Incorect options to DGIndex. Please refer to the manual." I would guess it should open just like other apps.

First get the licensing set-up. Get the machine ID as you have done and create a license (if you don't already have one for that machine). Then put the license file in the same directory as DGIndexIM.exe/DGDecodeIM.dll/libmftsw32.dll.

Now you have two options to make the index file:

1. Run dgindexim from a DOS window like this:

dgindexim -i file.264 -o file.dgi

Then make your script and reference the DGI file.

or...

2. Just make your script referencing the input stream (file.264) instead of the DGI file. Open the script. The index file will be created automatically.

-----

It's described in the Notes.txt document. Didn't you read it?

[tormento]

Made some tests.

The initial launch gives me the following:

http://imagizer.imageshack.us/v2/150x100q90/713/3onb.png (https://imageshack.com/i/jt3onbp)

Pasted license.txt from DGDecNV dir ;)

The Intel engine works fine under VirtualDub, not so ok with MeGui, even with preview window disabled.

Under VirtualDub it doesn't work with MT AviSynth but I suppose it is normal for a beta ;)

[Guest]

The initial launch gives me the following:

Working as designed. :)

Pasted license.txt from DGDecNV dir Good thinking!

The Intel engine works fine under VirtualDub, not so ok with MeGui, even with preview window disabled. Can you be more specific so I can follow up with Zathor? Thanks.

Under VirtualDub it doesn't work with MT AviSynth but I suppose it is normal for a beta ;) You've surely been here long enough to know that "it doesn't work" is not very useful as a trouble report.

Thanks for your testing. Additional details will be very helpful.

[tormento]

Thanks for your testing. Additional details will be very helpful.
The CPU is a Sandy Bridge i7 2600K paired with a Geforce GTX 760.

The GT2 gpu was enabled with the appropriate switch on bios and attached to a fake monitor by control panel, thus giving me the opportunity to use both GPUs for testing.

The test file was a raw BD stream muxed into mkv.

Script follows:

loadplugin("D:\eseguibili\media\DGDecIM\dgdecodeim.dll")
dgsource("E:\bicicletta.dgi", engine=0) # uses Intel

It works perfectly under VirtualDub, single instance (no MT).

The same script crashes when loaded into plain MeGUI, even with preview window disabled (which has wicked seeking habits).

The same script crashes even under VirtualDub, when MTed, modified as follows (my usual encoding script):

SetMTMode(5)
SetMemoryMax(2048)
loadplugin("D:\eseguibili\media\DGDecIM\dgdecodeim.dll")
dgsource("E:\bicicletta.dgi", engine=0) # uses Intel
ChangeFPS(last,last,true)
SetMTMode(2)
SMDegrain (tr=4,PreFilter=2,thSAD=600,contrasharp=false,refinemotion=false,plane=4,chroma=true,lsb=true,mode=6)

If you'll tell me what to encode and how to help you, I'd be glad to.

[MeteorRain]

Had a halt on a specific bluray m2ts file when testing with dgim.


DGDecodeNV_dgsource("testcut.dgi") // Good on #2046

DGDecodeIM_dgsource("testcut.dgi") // Halt on #b5&b6 when reading the first frame. VDM & avs4x264 was used to reproduce.

I have cut a 10s clip from the m2ts using tsRemuxer. https://copy.com/4fN3epxUyDJT

The dgi is generated by DGNV2046x32. No problem when decoding other m2ts in the same bluray disc, only this file fails.

EDIT: Later I found some other episodes with the same problem.

EDIT: Also tested on ver.b6

[tormento]

Had a halt on a specific bluray m2ts file when testing with dgim.
Is that AVC or VC-1?

[MeteorRain]

Is that AVC or VC-1?

Avc. You can download the test clip if you like.

It doesn't crash, but consume 100% CPU and just halt, not responding.

[lansing]

Tested with my concert blu-ray today, I extract the stream using megui and muk into mvk, and then created the index based on that. On preview in virtualdub, some time there are bad frames of green blocks and some garbage blocks.

[Guest]

@lansing

JPGs are of no use. If you want an issue looked at you have to give me the source stream that I can use to duplicate the issue. Thank you.

[lansing]

@lansing

JPGs are of no use. If you want an issue looked at you have to give me the source stream that I can use to duplicate the issue. Thank you.

I can't even duplicate it myself lol. This happen when I jump back and forth in the timeline in a short period of time, and then it will appear on some frame where there are scene change. But when I jump a little back from that location and start playing the video normally in virtualdub, the blocks were gone when it got to those frames.

[Guest]

Sure, but can't you give me a sample?

[lansing]

this one, 9 scene changes in 10 seconds:
test clip (http://www.mediafire.com/download/r5y2l7ne2e3jbgo/test_bad_decode.mkv)

[yup]

Hi neuron2!

I have same error even after paste license.txt from DGindixNV to directory with dgindexim.exe. I try make new license with id which show dgindexim.exe with the same result. On PC exist internal graphic from Intel and NVidia card.
Please advice.

yup.

http://imagizer.imageshack.us/v2/150x100q90/713/3onb.png (https://imageshack.com/i/jt3onbp)

[kalehrl]

It's a bit off topic, but the latest Intel drivers seem to have enabled QuickSync on Haswell Pentium and Celeron processors. :)
http://downloadmirror.intel.com/23639/eng/ReleaseNotes_GFX_3412_64.pdf
Now you can buy a $40 processor and get QuickSync.

[Guest]

Hi neuron2!

I have same error even after paste license.txt from DGindixNV to directory with dgindexim.exe. I try make new license with id which show dgindexim.exe with the same result. On PC exist internal graphic from Intel and NVidia card.
Please advice.
That is the designed behavior and that screenshot is normal, it doesn't mean your license is not working. You didn't give parameters to DGIndexIM. Did you try to index a file:

dgindexim -i file.264 -o file.dgi

[Guest]

Here is beta 7:

http://neuron2.net/misc/dgdecim_b7.zip

* Fixed auto cropping of 1088 -> 1080
* Fixed random access with pulldown streams
* Experimental frame rate improvement

I would be interested in your decode frame rates with beta 7 versus beta 6. Also we need to see if this causes any decoding issues, because I did something not quite kosher but for me it increases the decode frame rate somewhat.

I am addressing the other reported issues but plan to release lots of betas as we go along. :)

[lansing]

ran 15k frames in avsmeter,

beta 6 @ 12% iGPU

Number of frames: 116220
Length (hhh:mm:ss.ms): 001:04:37.874
Frame width: 1920
Frame height: 1088
Framerate: 29.970 (30000/1001)
Interlaced: No
Colorspace: YV12

Frames processed: 15540 (0 - 15539)
FPS (min | max | average): 112.4 | 339.0 | 272.9
CPU usage (average): 10%
Thread count: 39
Physical Memory usage (peak): 187 MB
Virtual Memory usage (peak): 338 MB
Time (elapsed): 000:00:56.947



beta 7 @ 10% iGPU

Number of frames: 116220
Length (hhh:mm:ss.ms): 001:04:37.874
Frame width: 1920
Frame height: 1080
Framerate: 29.970 (30000/1001)
Interlaced: No
Colorspace: YV12

Frames processed: 15480 (0 - 15479)
FPS (min | max | average): 94.50 | 345.1 | 227.6
CPU usage (average): 11%
Thread count: 36
Physical Memory usage (peak): 196 MB
Virtual Memory usage (peak): 347 MB
Time (elapsed): 000:01:07.999


UPDATE on newer beta7:

frame rate actually dropped.

frame height is correct, green screen gone.

[Guest]

Please re-download beta 7. I backed off on the aggressive fps increase, as it is causing decode issues. I replaced it with a less aggressive improvement that shouldn't cause issues. We'll see.

As I told you before, the coded height is correct. Are you saying that you still get the extra 8 lines displayed when serving the video? My testing shows them to be cropped off. For those streams you should have this in the DGI file:

CLIP 0 0 0 8

You'll have to regenerate your index file with the beta 7 indexer, or you can edit the existing DGI.

I fixed the beta number in both executables.

[lansing]

I updated my last post, see benchmark above.

[qupfer]

Hi,

it's a bit offtopic but hope to get help here ;)
I lost the overview about the different Index tools with their system requirements :D

I have a SandyBridge CPU on a P67 Board with a nVidia Video card.
Is it correct, that I can't use the QuickSync acceleration because my board (the chipset) doen't support the integrated graphic?

And I'm right with the assumption, that DGDecIM also include the nVida-acceleration-part? (not sure if i understand the first post in this topic correctly).
So I can use italternatively to DGindexNV?

And the last question. What is the most common way for a complete AMD based computer?


thanks

[Guest]

And I'm right with the assumption, that DGDecIM also include the nVida-acceleration-part? (not sure if i understand the first post in this topic correctly).
So I can use italternatively to DGindexNV? Yes, DGDecIM can use either QuickSync acceleration or SW decoding.

And the last question. What is the most common way for a complete AMD based computer? Keeping on topic, DGDecIM can be used in SW mode on an all-AMD system.

[Guest]

I have a troublesome 1080i MPEG-2 TS sample (http://www.sendspace.com/file/n3holw) for you.
...
The Intel engine will lock VD up when trying to step backward through the clip. To see this open the script in VD, jump to frame 125 (CTRL+G), and then press and hold down the left arrow on the keyboard. This is fixed in beta 7.
The Nvidia engine doesn't lock up, but won't decode the clip correctly when stepping backward either (DGDecNV does the same thing also). To see this change the engine in the script, open the script in VD, jump to frame 125 (CTRL+G), and then step backward to frame 103 (or earlier). Interesting. I will look into that issue with DGDecNV. It doesn't happen with DGDecIM.
The Intel engine and Nvidia engine don't return the same video. You can see this with the following script. Play/step to frame 24&25 and you'll see they're offset 1 frame from each other, yet both return 242 frames. FWIW, the Nvidia engine matches DGMPGDec with this test. I can't duplicate this with beta 7.

[Guest]

Regarding vc-1_hulk.m2ts:

It produces jerky playback and blended frames.
It works in plain DGDecNV, however there are few duplicated frames (hard telecined?) which cause some jerkyness, but no blended frames in DGDecNV. Using beta 7, I do not see any blended frames. There is pulldown, yes. Please point me to specific frame numbers if you still believe this is an issue.

You can set fieldop=2 if you don't want dgdecodeim to honor the pulldown. That will give you progressive frames but then AV sync may be something to consider.

[Guest]

this one, 9 scene changes in 10 seconds:
test clip (http://www.mediafire.com/download/r5y2l7ne2e3jbgo/test_bad_decode.mkv) Duplicated the problem. Thank you. Investigating...

[Guest]

Had a halt on a specific bluray m2ts file when testing with dgim. Duplicated the issue. Thank you. Investigating...

BTW, it works on the demuxed ES, so it should be easy to fix. Famous last words! :)

EDIT: Ha! It was easy. New beta coming shortly...

[Guest]

Here is beta 8. It fixes the hang reported by MeteorRain. I wasn't passing enough data to DecodeHeader().

http://neuron2.net/misc/dgdecim_b8.zip

[Nico8583]

Perhaps I have not seen but does DGDecIM already support H264, VC-1 and MPEG2 ?

[Guest]

Yes, it supports all the video and container types that are supported by DGDecNV: AVC, VC1, MPEG2, ES, PS, TS, MTS, M2TS, MP4, MKV.

[Nico8583]

Thanks, I'll try soon ;-) and all types are decoded with Intel Media ? Is it based on the same Intel Media SDK version than DGMVCSource ?

[lansing]

Encountered another problem, the program is not taking non English character in the file path. I have folders in another language and they're showing up as question marks.

[Guest]

and all types are decoded with Intel Media ? Is it based on the same Intel Media SDK version than DGMVCSource ? Yes, they are all decoded, and yes, it is the same SDK.

Just in case you are wondering, the SDK accepts only ES and I do all the necessary demuxing in the filter.

[Guest]

Encountered another problem, the program is not taking non English character in the file path. I have folders in another language and they're showing up as question marks. I don't support Unicode filenames.

[Guest]

Here is beta 9, which now works in MEGUI (with preview). The ultimate test. ;)

http://neuron2.net/misc/dgdecim_b9.zip

[DarkSpace]

I don't support Unicode filenames.
I'm curious: Why not?
Also, I look forward to software decoding... I never had a CUDA-capable card, and therefore could never even test DGDecNV.

[Zathor]

Here is beta 9, which now works in MEGUI (with preview). The ultimate test. ;) :o Thanks!

[Nico8583]

Thanks, I'll try and tell you :)

[lansing]

nvm, beta 9 doesn't exist the speed problem between loading the actual file and index file.

[Guest]

:o Thanks! I meant it positively! MEGUI's power and versatility is unmatched in my view, and that's one reason it is a great test vehicle for source filters. Any deficiencies are in the source filters. Due to its correctness and robustness, MEGUI is a very useful tool for finding problems in filters generally.

[Nico8583]

Could you provide an example licence file (name and content) ? I have my ID but I don't know how to create licence file.

[Guest]

I'm curious: Why not? It never rose high enough on my priority list, which is determined by number of people asking for it and my own personal preferences for how I want to spend my time.

Also, I look forward to software decoding... Carpe diem.

[Guest]

Could you provide an example licence file (name and content) ? I have my ID but I don't know how to create licence file. Did I send you an activation email? If so, it explains how to make the license. If not, then send me a PM with your email address and I will send an activation to you at that address.

[Nico8583]

Did I send you an activation email? If so, it explains how to make the license. If not, then send me a PM with your email address and I will send an activation to you at that address.
Ok thanks !

[DarkSpace]

It never rose high enough on my priority list, which is determined by number of people complaining and my own personal preferences for how I want to spend my time.
Thanks for the answer. Just for the record, I believe that Unicode support is nice to have.

Carpe diem.
I will, when (if) my laptop's BluRay drive decides to once again recognize when I insert a disc.

Another curious question: Will you actively support AviSynth+ (rather than having it passively supported because of AviSynth compatibility) or VapourSynth also? I searched the thread, but didn't find any mention of it.

[asteri]

@DarkSpace
AviSynth+ is compatible. I use it with x64 version of DGDecNV and also I have tested it with DGDecIM 32bit.

@all
I am little disapointed about the speed. I made real encoding test and results are follows. I encoded to 720p x264:
DGDecNV (x64) - encoded 75747 frames, 15.40 fps
DGDecIM (x32) - encoded 75747 frames, 12.35 fps

I know it is not fair compare x32 vs. x64 encoding process. But from previous tests I know x64 version is about 2-3fps faster than x32 encoding process. I can make conclusion that DGDecNV and DGDecIM have very similar speed. Any mistakes?

Tests were done on i7 4800MQ and nVidia Quadro K2100M and DGDecIM beta9.

[Sharc]

Regarding vc-1_hulk.m2ts:

Using beta 7, I do not see any blended frames. There is pulldown, yes. Please point me to specific frame numbers if you still believe this is an issue.

You can set fieldop=2 if you don't want dgdecodeim to honor the pulldown. That will give you progressive frames but then AV sync may be something to consider.
It looks to me like a butchered hybrid stream, i.e. interlaced for the interview segment and pulldown for the movie segment. Separate the fields and look for example field 179 (the hand), 383, 403, 485, 495 (all with blueish ghosts) to name but a few. It's the same for fieldop=2.

[DarkSpace]

@DarkSpace
AviSynth+ is compatible. I use it with x64 version of DGDecNV and also I have tested it with DGDecIM 32bit.
I'm aware of compatibility, but thanks (it was perhaps misleading, I'll edit my original post). What I meant was whether avs+ will be actively supported, e.g. by setting the MT mode in the plugin itself (http://forum.doom9.org/showthread.php?p=1667360#post1667360).

[Guest]

I am little disapointed about the speed. I made real encoding test and results are follows. I encoded to 720p x264:
DGDecNV (x64) - encoded 75747 frames, 15.40 fps
DGDecIM (x32) - encoded 75747 frames, 12.35 fps

I know it is not fair compare x32 vs. x64 encoding process. But from previous tests I know x64 version is about 2-3fps faster than x32 encoding process. I can make conclusion that DGDecNV and DGDecIM have very similar speed. Any mistakes? DGDecIM is a decoder. I care about and can control only the decode frame rate. In the current beta DGDecIM is 25-50% faster than DGDecNV. In my private beta about to be released I have a decode rate of 500fps+, which is 300-400% faster. No reason for disappointment here. :)

[Guest]

It looks to me like a butchered hybrid stream, i.e. interlaced for the interview segment and pulldown for the movie segment. Separate the fields and look for example field 179 (the hand), 383, 403, 485, 495 (all with blueish ghosts) to name but a few. It's the same for fieldop=2. Then it's not an issue for me, right?

[Guest]

I'm aware of compatibility, but thanks (it was perhaps misleading, I'll edit my original post). What I meant was whether avs+ will be actively supported, e.g. by setting the MT mode in the plugin itself (http://forum.doom9.org/showthread.php?p=1667360#post1667360). If someone tells me clearly what to do and how to do it, and it does not break 2.5.8 support, I will certainly try to help. I'm not sure MTing a source filter that already delivers 500fps (upcoming beta) would benefit much from the effort, but you tell me, I'm an MT dilettante.

[Groucho2004]

I know it is not fair compare x32 vs. x64 encoding process.
Exactly.

Any mistakes?
See above.

But from previous tests I know x64 version is about 2-3fps faster than x32 encoding process. I can make conclusion that DGDecNV and DGDecIM have very similar speed.
You're measuring encoding speed, not decoding speed. In your scenario the encoder determines how many frames/second it needs, the decoders are almost idle and very bored.

[Guest]

Thanks for the answer. Just for the record, I believe that Unicode support is nice to have.
Noted, thank you.

[Guest]

In your scenario the encoder determines how many frames/second it needs, the decoders are almost idle and very bored. Yes, very well put. :goodpost:

[Sharc]

Then it's not an issue for me, right?
Looks like, yes.
I got alert because it looked better (no ghosts, but partly jerky) when decoding it with DGDecodeNV / Nvidia.
Anyway, it finally looks ok when I append telecide():
The interview section becomes progressive and the movie section shows a regular 3:2 pulldown pattern.
Finally, appending telecide().tdecimate() does the trick.
So we can put this clip aside.....

[Groucho2004]

I'm not sure MTing a source filter that already delivers 500fps (upcoming beta) would benefit much from the effort
That's your polite way of saying what I think - It makes no sense. :D

[Guest]

Here is beta 10, with performance improvement. I am reaching 500fps+ with AVC 1920x1080.

http://neuron2.net/misc/dgdecim_b10.zip

For those interested in the changes that so dramatically improve the decode rate, there were two (no secrets here):

1. The asynchronous pipeline was being synced after every frame decode. It's done that way in the Intel sample, but it is not necessary. Empirically and theoretically, it suffices to sync the pipeline only once after each decoder reset and then omit the sync call on linear-access subsequent frames. Sync is performed after every seek and then linear decode proceeds without sync'ing.

2. The NV12->YV12 conversion is very expensive. I optimized the conversion and frame copy to the Avisynth buffer. I am wondering if the SDK can give me YV12 directly. I will look into that. Also possible, do the conversion on the iGPU.

[Guest]

I hope you will add Intel HW deinterlacing in the next build. My current priority list, assuming the 500fps build holds up, is:

* check VC1 HW decode with recently released Intel driver
* address any problem streams (I have only one right now: test_bad_decode.mkv)
* HW postprocessing (crop, resize, deinterlace, ivtc)
* MVC support

And at some point I have to make nice documentation and then formally make the whole thing available at my web site.

[Guest]

That's your polite way of saying what I think - It makes no sense. :D I think if you can find a way to respond to things in a polite and helpful way then you achieve a win-win interaction. An interaction that requires asserting that the other has no sense is not win-win. And it's debatable anyway; what's wrong with trying to squeeze as much as one can out of a process?

Still, I enjoy the humor. :p

[DarkSpace]

Noted, thank you.
Okay.

If someone tells me clearly what to do and how to do it, and it does not break 2.5.8 support, I will certainly try to help. I'm not sure MTing a source filter that already delivers 500fps (upcoming beta) would benefit much from the effort, but you tell me, I'm an MT dilettante.
From that, I suppose you want Mode 3 (serialized) for your filter. In that case, the header should contain something like

int __stdcall SetCacheHints(int cachehints,int frame_range) {
if (cachehints == 509) /* CACHE_GET_MTMODE */
return 3; /* MT_SERIALIZED */
else
return 0;
}

to register the filter as such.

EDIT:
That's your polite way of saying what I think - It makes no sense. :D
I took no offense, I realize that source filter typically have no MT, anyway. MT modes in the plugin was mainly an example, but neuron2's answer gave me the information I wanted, so thanks!

EDIT2:
I guess I'll have to find my old HDD, I should have some streams there that I might be able to use to test, also with MT modes...

[Groucho2004]

what's wrong with trying to squeeze as much as one can out of a process?
Nothing.
However, you might be opening a can of worms going that route. Multi-threading always has some overhead, synchronization issues, etc.
Just look at FFMS2. More often than not, users have to specify "Threads=1" in order to get a filter chain working properly.

[Guest]

Nothing.
However, you might be opening a can of worms going that route. Multi-threading always has some overhead, synchronization issues, etc.
Just look at FFMS2. More often than not, users have to specify "Threads=1" in order to get a filter chain working properly. I wasn't committing to support MT usage and I've always been dubious about its reliability in practice, at least as currently implemented, but I still see it as a valid and potentially useful technology and wouldn't want to discourage interested people from exploring it and applying it where possible.

[lansing]

benchmark on beta10 @30% iGPU

Number of frames: 116220
Length (hhh:mm:ss.ms): 001:04:37.874
Frame width: 1920
Frame height: 1080
Framerate: 29.970 (30000/1001)
Interlaced: No
Colorspace: YV12

Frames processed: 39050 (0 - 39049)
FPS (min | max | average): 199.1 | 669.6 | 601.3
CPU usage (average): 18%
Thread count: 39
Physical Memory usage (peak): 176 MB
Virtual Memory usage (peak): 338 MB
Time (elapsed): 000:01:04.948


Reached a whopping 600fps :eek:, kind of weird that the benchmarks vary though. Sometime it stayed at 600fps, sometime 575fps.

[Guest]

I noticed that too. Strange.

[lansing]

problem found, random seeking in beta 10 will cause chroma ghosting, happen to both avc and mpeg2 streams. And after seek, frame accuracy will be off, I compared side by side with beta 9 in avspmod, the same number frame didn't match up.

[asteri]

DGDecIM is a decoder. I care about and can control only the decode frame rate. In the current beta DGDecIM is 25-50% faster than DGDecNV. In my private beta about to be released I have a decode rate of 500fps+, which is 300-400% faster. No reason for disappointment here. :)

I wrote it in wrong way ;)

Maybe the DGDecIM is 30% faster then DGDecNV in decoding but impact on speed of the whole encoding process is minimal to nothing.

I think this is the important measurement for those of us with nvidia cuda capable card.

Still I think the whole encoding process (decoding+encoding) it must be slower because you will use CPU for decoding and encoding. But with cuda card could be decoding part done by another hw (nvidia cuda graphics) and almost whole power of CPU could be used for encoding. Am I right?

Of course I have to say big thank you for this DGDecIM version even if it will be slower. It is very important to have some alternative for people without cuda graphics. Current DGAVCDecDI isnt good choice.

EDIT: My measurement was done with beta9, I will try b10 later ;)

[lansing]

it must be slower because you will use CPU for decoding and encoding

You are missing the whole point of this tool then. This decoder was created to take the loads off the cpu by utilizing it's internal gpu, to let the internal gpu do the decoding job. Yes, just like what you're talking about with the nvidia card.

Maybe the DGDecIM is 30% faster then DGDecNV in decoding but impact on speed of the whole encoding process is minimal to nothing.
You need to compare apple to apple here. We are talking about decoding speed, not anything else. The overall encoding speed can be affected by many other stuffs, the most obvious bottleneck is the speed of the cpu itself. No matter how fast the decoding speed is, if cpu can only run at N frame per second for encoding, then your whole process will be as fast as your weakest link.

[asteri]

You are right, but If there will be no speedup of the whole process then speedup in decoding phase only is not important for me ;)

It was my fault expected speed up of the whole process.

Thanks guys for clarification

[Sharc]

Do I have to remove dgdecodeNV.dll from the avisynth plugins folder for testing dgdecodeIM.dll (which I load explicitly from a local folder) to make sure that DGSource uses dgdecodeIM?

[yup]

neuron2!

Thanks now work!
I am testing short clip from camera and see a lot off block in Virtualdub (1440x1088 interlaced source 25 fps).
When I read the same dgi (created by IM indexer) file by NV decoder all was O'k.

yup.

[Guest]

Do I have to remove dgdecodeNV.dll from the avisynth plugins folder for testing dgdecodeIM.dll (which I load explicitly from a local folder) to make sure that DGSource uses dgdecodeIM? I'll have to look into that. For now it's probably best to do that. You can use the debug=true parameter to see which one is actually being used.

[Guest]

problem found, random seeking in beta 10 will cause chroma ghosting, happen to both avc and mpeg2 streams. And after seek, frame accuracy will be off, I compared side by side with beta 9 in avspmod, the same number frame didn't match up. It is very important for us to be sure that the performance improvement has not broken things. Can you please provide a stream and instructions for duplicating what you report here? Thank you.

[Guest]

neuron2!

Thanks now work!
I am testing short clip from camera and see a lot off block in Virtualdub (1440x1088 interlaced source 25 fps).
When I read the same dgi (created by IM indexer) file by NV decoder all was O'k.

yup. Please advise if it happens also with beta 11. We are testing the effect of the performance improvements.

[Guest]

In view of lansing's reports I have backed off the pipeline change in beta 11:

http://neuron2.net/misc/dgdecim_b11.zip

I'll follow up with Intel to see if there is any way to reliably use this finesse. Even without it the color conversion changes are giving me about 400fps.

For those interested in testing we have:

b9 no performance changes
b10 pipeline and color conversion changes, likely broken
b11 color conversion changes only

[Guest]

You are right, but If there will be no speedup of the whole process then speedup in decoding phase only is not important for me ;)

It was my fault expected speed up of the whole process.
The point of this development is to provide non-Nvidia users with a frame-accurate source filter. I have never claimed that it will speed up transcoding, although in some scenarios it may give a modest improvement.

[Guest]

I'll have to look into that. For now it's probably best to do that. You can use the debug=true parameter to see which one is actually being used. I did some testing and it appears that the loadplugin in the script overrules the plugin directory.

Probably Gavino could confirm or disconfirm this; I haven't looked at Avisynth code for a long long time.

[Sharc]

problem found, random seeking in beta 10 will cause chroma ghosting, happen to both avc and mpeg2 streams. And after seek, frame accuracy will be off, I compared side by side with beta 9 in avspmod, the same number frame didn't match up.
Hmm.... I don't want to overcomplicate things, but I noticed ugly chroma ghosting in my "problematic" clip 'vc-1_hulk' as well and concluded that the clip is probably butchered. Surprisingly the chroma ghosting also exists when I decode with DGDecodeNV. In my case the ghosting shows typically up as blueish ghosts in some frames/fields.

[Sharc]

I did some testing and it appears that the loadplugin in the script overrules the plugin directory.
Yep, I came to the same conclusion (thanks to the debug=true).
A problem may only arise when both .dll are in the avisynth plugins folder and no specific LoadPlugin(...) is in the script. In my tests the DGDecodeNV gets preference in this case.

[Guest]

Hmm.... I don't want to overcomplicate things, but I noticed ugly chroma ghosting in my "problematic" clip 'vc-1_hulk' as well and concluded that the clip is probably butchered. Surprisingly the chroma ghosting also exists when I decode with DGDecodeNV. In my case the ghosting shows typically up as blueish ghosts in some frames/fields. The two are unrelated. Your source clip is bad. The ghosting is in the source.

[Sharc]

The two are unrelated. Your source clip is bad. The ghosting is in the source.
Thanks for double checking. I'll bury this clip now definitely :D

[Guest]

Yep, I came to the same conclusion (thanks to the debug=true).
A problem may only arise when both .dll are in the avisynth plugins folder and no specific LoadPlugin(...) is in the script. In my tests the DGDecodeNV gets preference in this case. Do you folks out there want me to have separate filter names:

dgsourceim()
dgsourcenv()

This affects only people who want to be able run both of them.

[Sharc]

Short term it would probably prevent ambiguities or doubts.
Long term only one decoder may be good for all cases, making anything else obsolete?

[lansing]

Tested beta 11, no more chroma ghostng, frame matched up with beta 9 in preview. Speed well above 400fps.

Another thing I notice, it feels like the gpu has its own cache remembering the last activity or something? I ran three consecutive benchmarks on the same file. On the first run, speed steadied at 475fps for about 13k frames before it dropped to 42x fps at 15k frames, where I exited. On the second run, the speed stayed at 475fps until the 15k frames mark before it began to drop again, this time I let it run until the 40k frames mark before i exited it. And on the third run, it ran at 470fps for the first 40k frames with the same behavior.

[CarlPig]

Do you folks out there want me to have separate filter names:

dgsourceim()
dgsourcenv()

This affects only people who want to be able run both of them.

Yes that is a good idea.

[lansing]

Do you folks out there want me to have separate filter names:

dgsourceim()
dgsourcenv()

This affects only people who want to be able run both of them.

+1 for that. It's always better for users to know what it is by its name. Btw, what is "IM" stand for anyway?

[Guest]

Tested beta 11, no more chroma ghostng, frame matched up with beta 9 in preview. Speed well above 400fps. Sweet. Thanks for your test results.:thanks:

Another thing I notice, it feels like the gpu has its own cache remembering the last activity or something? I ran three consecutive benchmarks on the same file. On the first run, speed steadied at 475fps for about 13k frames before it dropped to 42x fps at 15k frames, where I exited. On the second run, the speed stayed at 475fps until the 15k frames mark before it began to drop again, this time I let it run until the 40k frames mark before i exited it. And on the third run, it ran at 470fps for the first 40k frames with the same behavior. There is lots of caching to take into consideration, especially the HW disk cache and the OS file caching. There is also Avisynth frame caching but it wouldn't come into play for linear decode. There is no iGPU frame caching.

IM = Intel Media

[tormento]

Do you folks out there want me to have separate filter names
If you plan to join DGDecNV with DGDecIM, IMHO, a single filter name is better, with option to select the decoder.

As the indexing software is able to create avs file automatically, you should put a voice in menus to select the hw decoder to use, greyed if not available.

[yup]

Please advise if it happens also with beta 11. We are testing the effect of the performance improvements.

neuron2!

I am testing beta9 and beta11 and see also block but in other place comparing to beta 10.
yup.

[Guest]

I am testing beta9 and beta11 and see also block but in other place comparing to beta 10.
yup. If you want any attention to your problem, you'll need to provide a test stream, your script, and an explanation of how to duplicate the issue. Thank you.

[yup]

If you want any attention to your problem, you'll need to provide a test stream, your script, and an explanation of how to duplicate the issue. Thank you.

I find progressive source and one work fine.
Problem only with camera source mts file, which I convert using MeGUI Extractor for h264.
This source work fine with NV tools.
After weekend I try upload source.
yup.

[Guest]

Here is beta 12. It changes the source filter name to dgsourceim() and it fixes tormento's "bad" MKV stream handling.

http://neuron2.net/misc/dgdecim_b12.zip

At this point I have only yup's issue to fix; nothing else has been reported. It would sure be nice if yup could upload the stream now so I could work on it this weekend. ;)

[Sharc]

beta12 works ok here, but I can only test it in SW mode.
Looking forward to the integration of MVC :)

[Guest]

Looking forward to the integration of MVC :) More than HW deinterlace, ivtc, and crop/resize?

[CarlPig]

HW deinterlace yes sir.

[lansing]

I have a tv recorded stream that will cause avsmeter to hang when it ends. No such problem with virtualdub analysis pass, avspmod preview, or mpc playback.

bad (http://www.mediafire.com/download/9o934akzqiqv1f9/hangs.mkv)

[Nico8583]

I'm agree with MVC integration before HW filter :D

[Groucho2004]

I have a tv recorded stream that will cause avsmeter to hang when it ends. No such problem with virtualdub analysis pass, avspmod preview, or mpc playback.

bad (http://www.mediafire.com/download/9o934akzqiqv1f9/hangs.mkv)
Have you tried different decoders? I tried DGDecodeNV and LWLibavVideoSource. No problem.
I can't use DGDecIM, don't have the required hardware.

[CarlPig]

I personally voted on HW deinterlace, because i don't own a 3d device, so i do not need MVC.

[Sharc]

More than HW deinterlace, ivtc, and crop/resize?
Do you expect better deinterlacing quality compared to decomb, tdeint or similar? Something like a speedy QTGMC perhaps?
When I go for deinterlacing at all it is always for subsequent re-encoding which tends to mask the HW decoding speed benefit -- with the exception of QTGMC. Similar applies for HW crop & resize I think.
But mainly: my current HW does not support the new Intel functions, hence my selfish preference for MVC ;-)

[lansing]

Have you tried different decoders? I tried DGDecodeNV and LWLibavVideoSource. No problem.
I can't use DGDecIM, don't have the required hardware.

Just tried, LWLibavVideoSource and dgnv engine were both fine.

[Guest]

Have you tried different decoders? I tried DGDecodeNV and LWLibavVideoSource. No problem.
I can't use DGDecIM, don't have the required hardware. Hi Groucho2004. You are right, it's an issue with my filter not AVSMeter. I'm working on it.

[Guest]

Do you expect better deinterlacing quality compared to decomb, tdeint or similar? Something like a speedy QTGMC perhaps? Certainly better than decomb and tdeint! I suppose it will be comparable to the Nvidia deinterlacing we already have, but I haven't tested anything yet.

[tormento]

it fixes tormento's "bad" MKV stream handling.

Thanks.

Have you tried some MEGui testing with screen preview enabled and AVS improved opening?

[Sharc]

Certainly better than decomb and tdeint! ......
Interesting. Is there a principal advantage with HW deinterlacing over SW, other than speed? Are their algos more sophisticated, or something which can't be done similarly in SW (apart from speed of course)?

[Guest]

Yes, the HW speedup allows for more sophisticated algorithms. And of course one goal is to recover CPU for encoding, so just the fact that the deinterlace is removed from the CPU is an advantage.

[Guest]

Have you tried some MEGui testing with screen preview enabled and AVS improved opening? Yes, I have no issues with MEGUI. Do you have any issues with it?

[Guest]

Here is beta 13. For me it fixes the problem with AVSMeter hanging. lansing, please report your result.

There may be others issues, I am still working on it.

http://neuron2.net/misc/dgdecim_b13.zip

[tormento]

Yes, I have no issues with MEGUI. Do you have any issues with it?

Tried with MT enabled?

[Guest]

Tried with MT enabled? No. I don't consider MT important for a fast source filter and anybody that wants to try to multithread it is on their own. Didn't we go through this once already?

[lansing]

Here is beta 13. For me it fixes the problem with AVSMeter hanging. lansing, please report your result.

There may be others issues, I am still working on it.

http://neuron2.net/misc/dgdecim_b13.zip

still hangs in my machine

[MeteorRain]

Here is beta 12. It changes the source filter name to dgsourceim()

Have been afk for a few days. Update to b13 and failed to load old scripts. Finally find this.

Changing the name of a filter breaks all old (used, prepared, or as template) scripts. :scared:

No one remembers the avisynth way of distinguishing filters with same name?

DGDecodeIM_DGSource("clip.dgi") # DGIM will be used
DGDecodeNV_DGSource("clip.dgi") # DGNV will be used

BTW, I can confirm the hanging problem got fixed on b8. Good job. Thanks.

EDIT: I also occasionally noticed that the FPS fraction line inside dgi (by dgindexim) is not reduced. It writes 120000/5005 instead of 24000/1001.

In the dgi for the same file by dgindexnv, it writes 24000/1001.

Not a big deal though, just FYI.

[lansing]

Found a bug on filter ignoring file extension.

I have a test1.ts, and a test1.dgi that was pointing to it. And in my avs script I was calling test1.mkv, but the script still works.

[Guest]

Currently, if the DGI exists, it is used. I could enforce that the referenced file matches the file given in the DGI. Thanks for pointing it out.

[yup]

neuron2!

I try last beta13, the same issue.
See uploaded files
source mts
https://www.dropbox.com/s/2l8ttetg8uh73xb/00000.MTS
and converted h264
https://www.dropbox.com/s/o8vhciux96xmp47/test.h264

yup.

[kypec]

Do you folks out there want me to have separate filter names:

dgsourceim()
dgsourcenv()

This affects only people who want to be able run both of them.

I don't quite understand why are you trying to reinvent the wheel. AviSynth provides very elegant method for resolving function name ambiguities, please look at the bottom of AVS wiki (http://avisynth.nl/index.php/Plugins) page to see how it works:# using methodX from pluginA.dll
pluginA_methodX()
# using methodX from pluginB.dll
pluginB_methodX()

[MeteorRain]

I don't quite understand why are you trying to reinvent the wheel.Which I already said on #219;)

[Guest]

I prefer my method. It's less typing. And with the "standard" method users that don't know about it can still go wrong, because the prefix is optional.

[RedDwarf1]

The small amount of testing that I have done shows that the speed seems to be influenced by the iGPU core clock which tends to ramp up and down quite a lot while the tests are running. While at 1150Mhz the decode speed seems higher than when it's clocked at 350Mhz. It might be worth seeing if that can be fixed at full speed while the test is running. Has anyone else found the decode speed fluctuating depending upon the core speed ramping?

Is there a test sample that can be used to compare speeds? It would be nice to see any differences between the 4th gen and 3rd gen CPU's to compare how any optimizations affect different CPU's. I realise that this is only a beta and your trying to iron out decoding errors etc but it would be nice to have a glimpse of any speed differences between the CPU's. Mine is a 3770k.

I have limited access to 1080p except for satellite broadcasts and a few demo videos such as rat and pigeon impossible.

Pigeon impossible on Win 7 x64 with 3770k
AVSMeter 1.7.6 (AVS 2.6, x86) by Groucho2004
AviSynth 2.60, build:Mar 9 2013 [13:28:27]
Active MT Mode: 0

Number of frames: 8968
Length (hhh:mm:ss.ms): 000:05:58.720
Frame width: 1920
Frame height: 1080
Framerate: 25.000 (25000/1000)
Interlaced: No
Colorspace: YV12

Frames processed: 8968 (0 - 8967)
FPS (min | max | average): 1.732 | 557.7 | 166.5
CPU usage (average): 9%
Thread count: 19
Physical Memory usage (peak): 494 MB
Virtual Memory usage (peak): 738 MB
Time (elapsed): 000:00:53.869

[Guest]

Thanks, that's certainly an important line for us to follow. I won't be able to do much on it personally though until any remaining decoding issues are resolved, as you mentioned. But I welcome you and others getting a start on it and posting here. I'll be able to engage with you on it hopefully in not too long.

Right now, lansing's problem stream is being highly recalcitrant. I have some theories about it, however, and am pursuing it as the top priority. I'd also welcome yup to post his problem stream.

[yup]

I'd also welcome yup to post his problem stream.
Hi neuron2!
Please see post #222 this thread.
yup.

[MeteorRain]

A MKV file that causes DGIM to halt on opening.
DGNV works fine.
Extract h264 from MKV and index as dgi, works fine.
I'm on ver. b13.

https://copy.com/Ew9GR4nC6Yrs

[Guest]

I'm on ver. b15.
Did you mean b13? Thanks for the stream. Investigating...

@yup

Thank you!

[Guest]

A MKV file that causes DGIM to halt on opening. DGNV works fine. This is fixed in beta 14:

http://neuron2.net/misc/dgdecim_b14.zip

I wasn't injecting SPS/PPS from CodecPrivate when packaging data for the SDK DecodeHeader() call. Thank you for pointing it out.

[Guest]

Please see post #222 this thread.
yup. Thanks, yup. I ran your sample with beta 14 and didn't see any issues. I made the minimal script and opened it in VirtualDub and played it through with no errors. I even added reverse() to the script to force random access on every frame and that ran fine too. So, if you still have an issue, please provide your script and x264.exe command line using your sample. Also please tell me which version of x264.exe you use. Are you using the Intel HW or SW decoding?

I have tested a lot of MTS files and don't find any issues.

[Guest]

I also occasionally noticed that the FPS fraction line inside dgi (by dgindexim) is not reduced. It writes 120000/5005 instead of 24000/1001.

In the dgi for the same file by dgindexnv, it writes 24000/1001.

Not a big deal though, just FYI. Interesting. I don't do any reduction; rather, the values received from the decoder are used, in this case, the Intel SDK DecodeHeader() call. We could look to see what the ES actually specifies, but it seems unimportant in practice.

[Guest]

lansing's bad stream misbehaves with the Intel decode sample also, so I have posted about it at the Intel forum:

http://software.intel.com/en-us/forums/topic/506806

[yup]

Hi neuron2!

Now i am out my work horse (short vocation).
I am using simple script
LoadPlugin("DGIndexIM.dll")
DGSourceIM("t.dgi")
I am not set engine, my PC have Intel Graphic.
You advice manual set engine?
When I back I continue testing.
yup.

[Guest]

@yup

Thanks yup, but the stream you gave me is not called t.mts, so it seems you have not given me a stream that I can use to duplicate your issue. I will ask again for what I need. You need to give me these if you want support.

1. A stream that I can use to duplicate your issue. Don't send me some random stream, send me the one you have personally experienced issues with.
2. The corresponding Avisynth script.
3. A description of how to make the problem happen. If you are transcoding then I need the encode command line and encoder version number.

Thank you for your understanding. I can fix things only when I can duplicate them.

You do not need to set the engine manually.

[CarlPig]

Do you have a status for supporting HW deinterlace??

[Guest]

I report all my activities in real time, and have made my priorities clear. Pinging me about it is a NOP and risks annoying me. ;)

[Guest]

Here is beta 15. It seems to fix MPEG2 streams, including lansing's stream that hangs AVSMeter. (Nothing at all wrong with the great AVSMeter!)

http://neuron2.net/misc/dgdecim_b15.zip

I found two problems:

1. The Intel decode sample has a bug that causes it to exit the main decode loop too soon in some cases. DGDecIM inherited the bug.

2. The Intel MPEG2 decoder discards leading B frames in display order! The AVC and VC1 decoders just deliver (corrupted) frames as I would expect. My existing random access relies on the fact that pushing a complete frame to the decoder always results in a delivered frame, and CUVID does so consistently for all the video types. Certainly it is perverse to have MPEG2 handled differently from AVC/VC1 by a decoder in this regard. I was able to make a workaround for this wart. Please advise if you find any issues with MPEG2 streams.

Now if we can just get Intel to fix HW decode for VC1...

[Guest]

Please re-download beta 15. I slipstreamed an additional fix needed as a result of the workaround.

[lansing]

confirm beta 15 fixed the mpeg2 hang problem, thanks for the work.

[Guest]

Thanks, lansing.

I have slipstreamed some more fixes into beta 15. Please redownload beta 15 to get these fixes. The leading B frame handling was broken for MPEG2 and there was a regression for some VC1 and AVC streams, so it's important to get this updated beta 15.

This version also fixes an issue raised earlier by lansing. When a mismatch is seen between the filename in the script and the filename in the existing DGI, the user is offered the choice of ignoring the mismatch and using the existing DGI file or regenerating the DGI using the filename in the script.

http://neuron2.net/misc/dgdecim_b15.zip

[mastrboy]

I finally have a weekend coming without any work, so was considering testing out DGDecIM on some sources, but do I have to have a monitor connected to the intel GPU, or is enabling it in bios enough?
(I currently have it disabled in bios as I use a nvidia 660 card instead)

[Guest]

It depends on which OS you run: Win7 versus Win8.

I have Win8 and all I had to do was enable the iGPU in the BIOS and install the Intel driver. My Nvidia card remains primary and there is no monitor or dummy connected to the iGPU spigot.

More info:

http://software.intel.com/en-us/forums/topic/311872

On Win7 you have 3 options it seems:

1. Connect a spare monitor to the iGPU.
2. Connect a VGA-dummy to the iGPU.
3. Use Eric's workaround given in the link above.

[aegisofrime]

It depends on which OS you run: Win7 versus Win8.

I have Win8 and all I had to do was enable the iGPU in the BIOS and install the Intel driver. My Nvidia card remains primary.

More info:

http://software.intel.com/en-us/forums/topic/311872

On Win7 you have 3 options it seems:

1. Connect a spare monitor to the iGPU.
2. Connect a VGA-dummy to the iGPU.
3. Use Eric's workaround given in the link above.

I'm on Windows 7 and I didn't have to do anything, my monitor remains connected to my AMD Radeon 7850. My situation is exactly like yours. FWIW I'm using a MSI Z87-GD45 Gaming and my CPU is a i7-4770. Not sure if my particular hardware supports not needing the iGPU connected.

[Guest]

That's great news, thanks for reporting it. Maybe things have changed since Eric's older post. Let's see what happens for mastrboy.

[lansing]

I finally have a weekend coming without any work, so was considering testing out DGDecIM on some sources, but do I have to have a monitor connected to the intel GPU, or is enabling it in bios enough?
(I currently have it disabled in bios as use a nvidia 660 card instead)

If you're using Window 8, then there's nothing to worry about, as you can simply enable iGPU and discrete GPU in the BIOS and it'll work.


If you're using Windows 7 desktop, watch the link in here about creating a fake display:
http://forum.doom9.org/showthread.php?p=1652628#post1652628

It doesn't matter which port you connect your display to. I connected my monitor through my video card and it still works. Also remember to position your display appearance like vivan said in the post.


If you're using Windows 7 laptop with a Nvidia card built in, you can probably able to set it in Nvidia's control panel to use iGPU for a particular program (I forgot the general name for those laptop model). It's so stupid for Nvidia to enabled this in laptop but not in desktop.

[Guest]

It's so stupid for Nvidia to enabled this in laptop but not in desktop. Can I ask you to please refrain from insults like this, at least in this thread? Thank you. If there is one thing that Nvidia is not, it is not stupid.

[lansing]

This version also fixes an issue raised earlier by lansing. When a mismatch is seen between the filename in the script and the filename in the existing DGI, the user is offered the choice of ignoring the mismatch and using the existing DGI file or regenerating the DGI using the filename in the script.


This doesn't make much sense to me. The filename of the script could had no relationship to the filename of the dgi. For example, if I loaded two dgi in a script, test1.dgi and test2.dgi, and appended them together, it's highly unlikely that I'm going to name my script test1.avs.

A reasonable way to do this is to generate the dgi with the video file extension added to the dgi filename from the start, like test.mkv.dgi, test.avi.dgi instead of test.dgi causing the confusion, then users don't have to make any choice.

[Guest]

It's worth considering, maybe later. Thanks.

[mastrboy]

I'm running Win 8.0 on the machine that was in question. So thanks for all the info, I will do some test tomorrow when various sources since it doesn't seem I need to have a monitor connected.
(I was already looking into making a fake plug, but couldn't find any resistors with 68-75 ohm resistors laying around to plug into a dvi-vga adapter... (ref: http://www.overclock.net/t/384733/the-30-second-dummy-plug)

[asteri]

I'm running Win 8.0 on the machine that was in question. So thanks for all the info, I will do some test tomorrow when various sources since it doesn't seem I need to have a monitor connected.
(I was already looking into making a fake plug, but couldn't find any resistors with 68-75 ohm resistors laying around to plug into a dvi-vga adapter... (ref: http://www.overclock.net/t/384733/the-30-second-dummy-plug)

Thanks it looks pretty easy and usefull! Can you please write exact pins which are connected? I am not sure, the picture is not accurate.

Thanks

[Guest]

Did you check this link?

http://http://soerennielsen.dk/mod/VGAdummy/index_en.php

[Guest]

I did some experiments with the QuickSync deinterlacer (using the VPP sample) in both single and double rate. It works fine and doesn't look half bad, as the English would say. Now on to integrating it into DGDecodeIM...

Also, please do let me know if you have any decoding issues. Things have gone quiet on that front so either things are looking good or no one is using it. ;) After I get the deinterlacing working I'd like to make a first formal release. Then I would add cropping/resizing.

[kalehrl]

Would you be so kind as to have a look at a sample posted here:
http://forum.doom9.org/showthread.php?p=1672767#post1672767
The sample was a h264 SD .ts capture turned into a .mkv with MeGUI's HD streams extractor.
I can also post untouched .ts sample if you need it.
Thank you

[Guest]

Would you be so kind as to have a look at a sample posted here:
http://forum.doom9.org/showthread.php?p=1672767#post1672767
The sample was a h264 SD .ts capture turned into a .mkv with MeGUI's HD streams extractor.
I can also post untouched .ts sample if you need it.
Thank you Specifically, what did you want me to look at? This thread is about DGDecIM and I don't see anything relevant in the post you linked.

The stream is recorded with very low bitrate and has field blending. A deblender will be more appropriate than a deinterlacer here, but the low bitrate will make it difficult to get good results, IMHO.

[kalehrl]

I just thought the sample was tricky because I didn't get good results deinterlacing it with handbrake or qstranscode using intel qsv.

[Guest]

Well, as I said it is not interlaced so deinterlacing is not the right thing. Still, it looks OK when deinterlaced using DGDecNV, albeit with major blending as expected. Just for fun, I will run it through QSV and see what I get. Your post in the other thread seems to indicate that the DirectShow filter did not even apply any deinterlacing. I don't know anything about the existing QSV-enabled DirectShow filters. How do you know you have enabled the deinterlacer using that script?

[kalehrl]

The file plays fine when using mpc with lav filters (CCCP codec pack).
The intel deinterlacer is applied and I don't see any combing artifacts.
When using directshow, the intel deinterlacer is not applied so I'm baffled why not.
I don't know how to enable it in the avisynth script.
I thought it should be applied automatically in the same way as during playback but it's not the case.
The combing artifacts are all over the place.
The lav filter tray icon appears in the right corner so I know lav filter is used by directshow.

[Guest]

It works fine for me using the Intel VPP sample processor. You need to talk to the author of your DirectShow filter, or wait for me to integrate this into DGDecIM (or use DGDecNV right now if possible). You may also want to revise your post to include the additional details you've given here. Ask them how to enable deinterlacing for the filter when invoking it through DirectShowSource().

Finally, you posted in a thread about Eric's filter but here you talk about LAV!

[MeteorRain]

I have been using DGDecIM in encoding several episodes of bluray contents without any problem, so far.

Couldn't be happier.

[yup]

Hi neuron2!
I am back to testing.
Script:
LoadPlugin("DGDecodeIM.dll")
DGSourceim("t.dgi",engine=1,debug=true)

Result O'k if see only forward from start to end script, but if try random access I see
https://www.dropbox.com/s/5giglbikuxeb0s6/dgim.png
For preview I am using Virtualdub 1.10.4.
Source file the same.
yup.

[lansing]

Hi, I encountered another problem. I have a tv recorded show that was mpeg2 30p, but because there was a 10 seconds telecined content at the start of the video, the entire show has been displayed as 30i in dgsourceim.
I tried loading the video with directshowsource and ffvideosource, both displayed the telecined content and the show as they are. And if I cut out a random part of the show, dgsourceim will be display correctly as well, which is 30p.

[Guest]

Hi neuron2!
I am back to testing.
Script:
LoadPlugin("DGDecodeIM.dll")
DGSourceim("t.dgi",engine=1,debug=true)

Result O'k if see only forward from start to end script, but if try random access I see
https://www.dropbox.com/s/5giglbikuxeb0s6/dgim.png
For preview I am using Virtualdub 1.10.4.
Source file the same.
yup. Are you not reading my responses to you? You have given me no source file named "t", which your script refers to, and the frame 6 in your screenshot does not match frame 6 in the stream you gave me. I cannot see any problem with the file you *did* give me. Can you please go back and read my last response to you and give me what I need to work on your issue:

http://forum.doom9.org/showthread.php?p=1672200#post1672200

[Guest]

Hi, I encountered another problem. I have a tv recorded show that was mpeg2 30p, but because there was a 10 seconds telecined content at the start of the video, the entire show has been displayed as 30i in dgsourceim.
I tried loading the video with directshowsource and ffvideosource, both displayed the telecined content and the show as they are. And if I cut out a random part of the show, dgsourceim will be display correctly as well, which is 30p. I don't understand your issue from your description and you have not provided a stream with your script and instructions. Please do so if you want any help from me.

I can't think of any way DGDecodeIM can change your progressive content to interlaced. Feel free to educate me by providing a stream etc.

[Guest]

I have been using DGDecIM in encoding several episodes of bluray contents without any problem, so far.

Couldn't be happier. Thank you for your feedback. Do you use BDRB, MEGUI, or do you do everything manually?

[yup]

Hi neuron2!

t.dgi made from h264 file which I uploaded using command line
dgindexim -i test.h264 -o t.dgi
yup.

[yup]

neuron2!

Problem solved!
dgi files generate old version DGIndexIM. When I make new, all O'k.
yup.

[Guest]

Problem solved!
dgi files generate old version DGIndexIM. When I make new, all O'k. Hi yup, thanks for the update and I'm glad it's solved for you!

[lansing]

I don't understand your issue from your description and you have not provided a stream with your script and instructions. Please do so if you want any help from me.

I can't think of any way DGDecodeIM can change your progressive content to interlaced. Feel free to educate me by providing a stream etc.

I've trimmed two stream using dgindex, trim1 include the 10 seconds telecine part followed by a transition animation that was displaying as interlace. Trim2 I took out the telecine part and leave only the transition animation, where it shows up as progressive.

trim1 (http://www.mediafire.com/download/v3quoxktcud2fnk/trim1.m2v)

trim2 (http://www.mediafire.com/download/5ar7f3cvanc752a/trim2.m2v)

[Guest]

Thank you for the samples. It's not a bug. It is acting correctly as designed. The start of the stream has soft pulldown and when you honor it you create a one-field phase shift that makes the rest of the stream appear to be interlaced. You can prove it to yourself by adding fieldop=2 to the DGDecodeIM() call.

The correct handling of the video to allow you to honor the pulldown and not create the phase shift is a matter for another thread. It will involve the strategic deletion of a single field. If you are clever you can do it by editing the index file. ;)

[Sharc]

@neuron2:
Playback of this hybrid (http://www.mediafire.com/download/1yv93pu01yorfc8/01054.track_4113.264)progressive/hard telecined clip is smooth until about frame 1300 when it begins to stutter.
(DGdecIM_b15, SW decoding).

[Guest]

I'm not seeing any problems with it here. How are you playing it?

[Sharc]

I play the script in MPC-HC.

[Guest]

Please try playing it in VirtualDub.

Also, please give your script.

[Sharc]

In VirtualDub playback is more fluent but I see some horizontal slices with horizontal displacement of the Picture.

Script:
LoadPlugin("c:\Program Files Video\AviSynth 2.5\plugins\DGDecodeIM.dll")

#The engine options chooses the decoding engine.
# engine = 0: Intel automatic (uses HW if available, otherwise uses SW)
# engine = 1: Intel HW
# engine = 2: Intel SW

Video=DGSourceIM("c:\Program Files Video\DGDecodeIM_Testing\01054.track_4113.dgi",engine=2,debug=false)

return video #.spline16resize(1280,720)
#assumefps(1000)

#info()

[Guest]

In VirtualDub playback is more fluent but I see some horizontal slices with horizontal displacement of the Picture. You see that with linear playback or random access? What frame number does it happen on?

Generally speaking, I am not a mind reader and you can help by being very specific about things. Tell me what I have to do to see what you see.

[Sharc]

Linear playback in VDub:
The horizontal slices are very obvious. e.g. frames 264 to 272 are sliced, or 337, 351, 352, 356, 357, 361, 362 to name just a few.
The .dgi was created with DGindexNV. Does this matter?

Edit: It seems that the interlaced frames of the telecined sections get predominantly sliced. Maybe it's just happening on my PC?

[Guest]

I'm not seeing any issues here as you describe. You can try changing the script to reference the 264 file directly and then let DGDecodeIM create the index. It shouldn't matter but you never know. Please make sure you actually run beta 15 and the associated libmfxsw32.dll.

EDIT: I just tried it with an index file created by DGIndexNV and still I do not see any issues.

[Sharc]

I think I found the cause:
The broad horizontal slices are caused by the scaling (vertical resize) for the PC monitor which happens to be just at a zoom factor which produces this pattern for the interlaced frames.
When I watch at original resolution I see the usual line-by-line interlaced frames, as expected. :rolleyes:
Sorry, never mind.

[Guest]

No problem, Sharc. That outcome is way better than any other. :)

And thanks for your testing and many other valuable contributions to Doom9.

[Sharc]

My pleasure :)

[MeteorRain]

Thank you for your feedback. Do you use BDRB, MEGUI, or do you do everything manually?

Locating source files by symbolic links.

Encoding using make (by makefile).

[yup]

Hi neuron2!
My investigation on 2 PC.
1. Windows 7 64 home ext. built Intel HD4000 no problem
2. Windows 7 64 professional built Intel HD and GTX 560
a. monitor connected to GTX560
When i try my source with issue I see block artifacts, if change engine to SW all O'k
progressive source O'k for both engine
b. monitor connected to Intel HD
all work fine.
Testing beta 15.
yup.

[Guest]

@yup

It's very difficult to help you without a stream, a script, and instructions to duplicate the issue.

[yup]

@yup

It's very difficult to help you without a stream, a script, and instructions to duplicate the issue.

neuron2!
It is not issue, but investigation. Stream the same which I uploaded and script also.
yup.

[RedDwarf1]

I don't think that Intel HD graphics works on Win 7 unless a monitor is connected to the onboard graphics. I had lots of issues getting the Intel HD graphics decoding video and it only worked properly with a monitor connected to the onboard graphics. LucidLogix is meant to allow Intel and a separate GPU to function but I could not get it working without a monitor connected to the onboard graphics, so LucidLogix was essentially useless. I have a nVidia card installed, no monitor connected and largely unused and intend removing it as soon as DGDecIM is finalized.

[Guest]

Good point, RedDwarf1!

@yup

If you read the thread carefully you will find possible workarounds:

http://forum.doom9.org/showthread.php?p=1672321#post1672321

[MeteorRain]

https://copy.com/Msd1BaOULQAv

death on opening

[Guest]

https://copy.com/Msd1BaOULQAv

death on opening Hmm, that's a weird one. The Intel SDK returns MFX_ERR_UNKNOWN from the DecodeFrameAsync() call. I'll have to try this with the decode sample and go from there.

Do you happen to have the x264 encode line you used to generate this stream, on the off chance that some specific setting is causing it?

I want to get a beta out with the deinterlacer enabled before I dive into this stream issue.

[Guest]

Here is an update on the HW deinterlacing support.

It wasn't trivial to port the sample VPP code to DGDecodeIM(). First, the decoding loop itself is structured differently, so I had to revise DGDecodeIM() to be the same. Second, the sample VPP code and DGDecodeIM() used different frame allocation methods and that made all the code not directly portable. So I had to revise the sample VPP code to use the same method as DGDecodeIM().

After all that, I was able to port the code and get things working. I need to do some cleanup and cover possible error cases and then I will make a beta, possibly today.

[MeteorRain]

Hmm, that's a weird one. The Intel SDK returns MFX_ERR_UNKNOWN from the DecodeFrameAsync() call. I'll have to try this with the decode sample and go from there.

Okey so basicly it's 10-bit and shouldn't be passed to HW decoder but the SW one.
The DGNV equivalent works fine but no engine information available with debug=true.

Not sure if 10-bit matters.

-----

Alright it fails on all(?) 10-bit files.

[Guest]

Thanks for reporting the cause, MeteorRain. QuickSync HW does not support 4:2:2 or 10-bit at this time. I will consider adding an error message.

The DGNV equivalent works fine but no engine information available with debug=true. DGDecNV has only a HW decoder; it cannot decode with SW.

[Guest]

I discovered something interesting. I have an AVC stream that is encoded as progressive but the content itself is interlaced. There doesn't seem to be a way to force the deinterlacer to work on it. Such streams are rare I suppose, so I will go ahead with a beta and follow up on this afterwards.

[Guest]

Here is beta 16 with HW deinterlacing (currently single rate only). I also implemented lansing's nice idea about index file naming, so don't get confused if things seem to have changed.

http://neuron2.net/misc/dgdecim_b16.zip

[CarlPig]

Will "deinterlace=1" add both hw decode and deinterlacing, or should i add hw decode too??

[Guest]

The engine parameter is auto by default, so if HW is present it will be used. deinterlace=1 is valid only if the active engine is the HW engine. Any attempt to use deinterlace=1 with the SW engine is ignored.

[MeteorRain]

Thanks for reporting the cause, MeteorRain. QuickSync HW does not support 4:2:2 or 10-bit at this time. I will consider adding an error message.

DGDecNV has only a HW decoder; it cannot decode with SW.

I pass engine=2 and it still cannot decode 10-bit.

And DGDecNV can decode 10-bit without any problem. Does that mean nvidia VP core can decode 10-bit in HW? Or was that an improper / fake decoding? (which i don't think so)

EDIT:

Okey I see artifacts when decoding 10-bit content with DGNV. I strongly suggest a warning message issued to users to prevent silent decoding errors and artifacts.

[kalehrl]

Can the license for this tool be bought?

[Guest]

While it is in the beta phase I am giving free licenses. Please send me a Pm with your valid email address.

[lansing]

with beta 16, I got an error "there is no function named "" " if I add any filter after the source filter when loading from mkv or ts

dgsourceim("abc.ts")
tfm()



And if I load it with dgi, no error occur.

dgsourceim("abc.ts.dgi")
tfm()

[Guest]

I cannot duplicate that, and those two follow identical code paths when the DGI file exists. Also, please see the last paragraph here:

http://forum.doom9.org/showthread.php?p=1668177#post1668177

[lansing]

It happens to all the files I have.

I ran a few test with different file path,

This one returns "there' is no function name "" ":

dgsourceim("F:\test2.mkv")
tfm()


this one returns "there is no function named "gi" ":

dgsourceim("F:\a\test2.mkv")
tfm()


this one returns "there is no function named "" ":

dgsourceim("F:\a\b\test2.mkv")
tfm()


this one returns "there is no function named "gi" ":

dgsourceim("F:\a\b\c\test2.mkv")
tfm()

[Guest]

I can't duplicate it. How are you opening the script? Just playing in VirtualDub? What version of Avisynth?

Post your DGI file.

Anybody else seeing this?

[lansing]

I save the script in the same folder as the video file, and then either drag it into avsmeter or virtualdub, both return the same error

And if I change the video filename to "test", and then put some random word in the next line, I'll get "I don't know what "dgi" means"


dgsourceim("F:\test.mkv")
randomletter

[Guest]

It's hard to help when you disregard my questions and requests. All I can say is there appears to be some problems with your system or environment.

[MeteorRain]

It happens to all the files I have.

I ran a few test with different file path,

This one returns "there' is no function name "" ":
this one returns "there is no function named "gi" ":
this one returns "there is no function named "" ":
this one returns "there is no function named "gi" ":


Do you have a corrupted file system?

Or are you using a mapped folder from another system / through virtual machine?

I have observed similar file corruption under vmware / virtualbox shared folders mounted on a Linux guest. Not sure if it's a similar problem but there's a big chance the avs file is not written properly or not read by other application properly.

[RedDwarf1]

I can't duplicate it. How are you opening the script? Just playing in VirtualDub? What version of Avisynth?

Post your DGI file.

Anybody else seeing this?

Yes I am getting a similar thing.

this works

LoadCplugin (AviSynthPluginsDir + "CPlugins\yadif.dll")
DGSourceIM(engine = 1, deinterlace=1, debug=true, "M:\Video Record\DVBViewer\test\2014-03-16_21-40-44_BBC Red Button HD_.ts")
#FlipVertical()
#yadif(order=1)

either of the following gives> script error: there is no function named ""

LoadCplugin (AviSynthPluginsDir + "CPlugins\yadif.dll")
DGSourceIM(engine = 1, deinterlace=0, debug=true, "M:\Video Record\DVBViewer\test\2014-03-16_21-40-44_BBC Red Button HD_.ts")
#FlipVertical()
yadif(order=1)

LoadCplugin (AviSynthPluginsDir + "CPlugins\yadif.dll")
DGSourceIM(engine = 1, deinterlace=1, debug=true, "M:\Video Record\DVBViewer\test\2014-03-16_21-40-44_BBC Red Button HD_.ts")
FlipVertical()
#yadif(order=1)

Opening a dgi works as it should.

[Guest]

@RedDwarf1

The filename should be the first parameter! I give clear examples in the Notes.txt file.

DGSourceIM("M:\Video Record\DVBViewer\test\2014-03-16_21-40-44_BBC Red Button HD_.ts", engine=1, deinterlace=1, debug=true)
FlipVertical()

I did duplicate the issue with your parameter order. It seems to be an idiosyncracy of Avisynth script parsing. Probably Gavino could explain what is going on. I will ping him. It's not something I'm bothered about, as things work fine with the input file given first (at least for me).

[RedDwarf1]

The auto created dgi file

Ah okay I will try that

[RedDwarf1]

That seems to of stopped the error

[Guest]

OK, good, and thank you for the DGI file. I PM'ed Gavino about this as I see it as an Avisynth issue.

It's not the same as lansing's case, unless he has not given the exact scripts.

[Guest]

Here is beta 17 with three bug fixes:

* Error messages and graceful exits were added for 10-bit and chroma formats other than 4:2:0. These checks are in the indexer, so don't try to use a DGI that you made previously! Now you will be unable to create the DGI unless you cheat and use the DGNV indexer. I will fix the latter at some point also.

* Some failures with DecodeHeader() were fixed. Some files that hung on open now work properly.

* When a pipeline init failure occurred a crash would occur. Now a proper ThrowError() is executed.

http://neuron2.net/misc/dgdecim_b17.zip

[RedDwarf1]

@RedDwarf1

The filename should be the first parameter! I give clear examples in the Notes.txt file.
Some people do read before bed, just not me. lol It was nearly 12:30am and I should of been in bed but I was attempting to reproduce the errors that lansing had posted in order to help out. It's nice to have deinterlacing available and I did not want some unresolved error holding things up.

Initial testing shows that it seems to work fine with BBC MBAFF video. All the MBAFF video that I have seen previously looked like progressive video and only the end credits were interlaced. However this Red Button Click programme does have interlaced video, the news ticker is interlaced and so are some other areas of the video. DGDecIM seems to be handling it fine.

DGSourceIM("M:\Video Record\DVBViewer\test\2014-03-16_21-40-44_BBC Red Button HD_.ts", engine=1, deinterlace=1, debug=true)
FlipVertical()

I did duplicate the issue with your parameter order. It seems to be an idiosyncracy of Avisynth script parsing. Probably Gavino could explain what is going on. I will ping him. It's not something I'm bothered about, as things work fine with the input file given first (at least for me).
Thanks for explaining things. It seems to work if a function is not used after the source filter. If a variable is declared before any function is used then it works fine. Even with the filename after the parameters or with a video filename.

I had not used any parameters before this because deinterlacing was not available when I last tried DGDecIM. I just stuck them in to test it without reading the notes ;)

this works
LoadCplugin (AviSynthPluginsDir + "CPlugins\yadif.dll")
DGSourceIM( "M:\Video Record\DVBViewer\test\2014-03-16_21-40-44_BBC Red Button HD_.ts")
#FlipVertical()
dummy=0
yadif(order=1)
return last
and this, I did purposely put the parameters before the filename and it works!
LoadCplugin (AviSynthPluginsDir + "CPlugins\yadif.dll")
DGSourceIM( engine = 1, deinterlace=1, debug=true, "M:\Video Record\DVBViewer\test\2014-03-16_21-40-44_BBC Red Button HD_.ts")
#FlipVertical()
dummy=0
#yadif(order=1)
return last

but not this
LoadCplugin (AviSynthPluginsDir + "CPlugins\yadif.dll")
DGSourceIM( "M:\Video Record\DVBViewer\test\2014-03-16_21-40-44_BBC Red Button HD_.ts")
FlipVertical()
dummy=0
yadif(order=1)
return last

or this
LoadCplugin (AviSynthPluginsDir + "CPlugins\yadif.dll")
DGSourceIM( "M:\Video Record\DVBViewer\test\2014-03-16_21-40-44_BBC Red Button HD_.ts")
#FlipVertical()
#dummy=0
yadif(order=1)
return last

OK, good, and thank you for the DGI file. I PM'ed Gavino about this as I see it as an Avisynth issue.

It's not the same as lansing's case, unless he has not given the exact scripts.

I was getting the same errors because I did get avisynth reporting "I don't know what "dgi" means" as well as 'script error: there is no function named ""'. That was why I thought that it was related to the same issue. I cannot get it to do that now for some reason - a nights sleep and no longer being so tired.

[Guest]

Are you saying something is still not working? I am having trouble getting your point.

I don't have yadif installed but this works fine for me:

loadplugin("dgdecodeim.dll")
dgsourceim("00000.mts",deinterlace=1,engine=1)
FlipVertical()
dummy=0
FlipHorizontal()
return last

If something like that fails for you, can you try it without C plugin stuff?

[RedDwarf1]

Are you saying something is still not working? I am having trouble getting your point.

I don't have yadif installed but this works fine for me:

loadplugin("dgdecodeim.dll")
dgsourceim("00000.mts",deinterlace=1,engine=1)
FlipVertical()
dummy=0
FlipHorizontal()
return last

If something like that fails for you, can you try it without C plugin stuff?

Sorry for complicating things.

Something, maybe the Avisynth script parsing as you say, causes an error when an internal or external filter is called immediately following the source filter, unless a variable declaration is placed immediately after the source filter.

For example, this gives an error 'script error: there is no function named ""' line 2
DGSourceIM( "M:\Video Record\DVBViewer\test\2014-03-16_21-40-44_BBC Red Button HD_.ts")
FlipVertical()
#dummy=0
return last

this works:
DGSourceIM( "M:\Video Record\DVBViewer\test\2014-03-16_21-40-44_BBC Red Button HD_.ts")
dummy=0
FlipVertical()
return last

because there is no internal or external filter following the source media file filter, there is a "dummy" variable declaration which prevents the error from occurring.

The question is, why is this occurring? Is it some anomaly with avisynth script parsing or is there a problem with DGDecIM?

[Groucho2004]

For example, this gives an error 'script error: there is no function named ""' line 2
DGSourceIM( "M:\Video Record\DVBViewer\test\2014-03-16_21-40-44_BBC Red Button HD_.ts")
FlipVertical()
#dummy=0
return last

Which version of Avisynth are you using?
Have you tried other versions?

[Guest]

Hmm, very strange, this is failing for me:

loadplugin("H:\Don\Programming\C++\DGDecIM\DGDecodeIM\x32\release\dgdecodeim.dll")
dgsourceim("00000.mts")
FlipVertical()

But it works if I specify the DGI file. I'm going to do some tracing now. BTW, I run Avisynth 2.5.8.

[Guest]

Oops, I made a boo-boo. Fix coming shortly.

:stupid:

[Guest]

Please re-download beta 17 and everything will be milk and honey again.

The technical explanation for the curious: Avisynth had set aside space for the argument holding the filename array, but that space only has room for the string actually given. Then when I mapped from the source file to the DGI file name I overwrote that Avisynth array space with the new longer filename, not realizing the array might be too small (actually I didn't think about it at all and just typed strcpy(dgi, ifile) where dgi was the first parameter to the create function, a pointer to the first argument space). I had to make a local array with proper space and then copied the first parameter to it, after which I could append ".dgi" without hosing up Avisynth. Moral of the story: do not modify Avisynth arguments.

[RedDwarf1]

Thank you neuron2.

I had just tested using 2 different source filters and they worked regardless of any workarounds. It's good to see that you worked it out and splatted another bug.

I'm using 2.6 a5 MT build

[Guest]

You're welcome, RedDwarf1, and thank you for your testing and reports.

[RedDwarf1]

I have just done a speed test and I got very low speed :( Much slower than DGDecNV, barely averaging above realtime! DGDecIM is deinterlacing the same BBC Red Button MBAFF video that I have been testing but this is the first speed test that I have done for deinterlacing.

M:\Video Record\DVBViewer\test>avsmeter "red button.avs"

AVSMeter 1.7.6 (AVS 2.6, x86) by Groucho2004
AviSynth 2.60, build:Mar 9 2013 [13:28:27]
Active MT Mode: 0

Number of frames: 3476
Length (hhh:mm:ss.ms): 000:02:19.040
Frame width: 1920
Frame height: 1080
Framerate: 25.000 (25000/1000)
Interlaced: No
Colorspace: YV12

Frames processed: 3476 (0 - 3475)
FPS (min | max | average): 9.121 | 131.2 | 26.59
CPU usage (average): 3%
Thread count: 19
Physical Memory usage (peak): 332 MB
Virtual Memory usage (peak): 589 MB
Time (elapsed): 000:02:10.715

#LoadCplugin (AviSynthPluginsDir + "CPlugins\yadif.dll")
DGSourceIM("M:\Video Record\DVBViewer\test\Red Button HD.dgi", engine = 1, deinterlace=1)

What has slowed it down?

[Guest]

Apparently the deinterlacer has slowed it down. ;)

I need your stream please.

I too noticed that the deinterlacer seems slow. I'm not doing anything different or weird, just following their sample code. I will try to look into it. Still, I reckon, real-time deinterlacing of HD is tolerable, especially when transcoding, compared to a SW solution.

Have you compared it to DXVA via QS-enabled DirectShow filters?

[RedDwarf1]

Apparently the deinterlacer has slowed it down. ;)

I need your stream please.
uploading to mediafire

I too noticed that the deinterlacer seems slow. I'm not doing anything different or weird, just following their sample code. I will try to look into it, but if it becomes an Intel support issue, forget it, their support is virtually nonexistent. Still, I reckon, real-time deinterlacing of HD is tolerable, especially when transcoding, compared to a SW solution.

Have you compared it to DXVA via QS-enabled DirectShow filters?
Not yet but I will later. I'm heading to bed ASAP.

[RedDwarf1]

FullHD transport stream (https://www.mediafire.com/?cfid42cpl4z4ldi)

[yup]

Hi neuron2!
I want testing beta 17 and get error about license. I am replace only dll and exe file in my directory. DGIndexNV also get the same error.
My PC Windows 7 64 professional, without connection to network (may be it is reason).

yup.

[aegisofrime]

Apparently the deinterlacer has slowed it down. ;)

I need your stream please.

I too noticed that the deinterlacer seems slow. I'm not doing anything different or weird, just following their sample code. I will try to look into it, but if it becomes an Intel support issue, forget it, their support is virtually nonexistent for end users like us. Still, I reckon, real-time deinterlacing of HD is tolerable, especially when transcoding, compared to a SW solution.

Have you compared it to DXVA via QS-enabled DirectShow filters?

I haven't had a chance to try the deinterlacer (currently overseas away from home), but I'm curious as to how's the quality? Is it to much to hope that it might be as good as QTGMC?

[Selur]

Is it to much to hope that it might be as good as QTGMC?
yes, it definitely is, you should hope for more like Yadif-level (or a bit worse) quality deinterlacing.

[Guest]

I don't find it to be worse than yadif! I find it closer to qtgmc quality. I'll post some screenshots when I get a chance.

[Guest]

Hi neuron2!
I want testing beta 17 and get error about license. I am replace only dll and exe file in my directory. DGIndexNV also get the same error.
My PC Windows 7 64 professional, without connection to network (may be it is reason). When you disconnect your internet connection, your machine ID changes. Make a new license for that configuration and *add* it to your existing license file. Please follow up in email if needed as I don't want to clutter this thread with licensing issues.

[Guest]

FullHD transport stream (https://www.mediafire.com/?cfid42cpl4z4ldi) Thank you.

I am seeing better performance than what you reported (see below, second is with deinterlacer). What is your processor? Mine is an i7 4770.

C:\Users\Don\Downloads>avsmeter "2014-03-16_21-40-44_BBC Red Button HD_.avs"

AVSMeter 1.7.5 (AVS 2.5, x86) by Groucho2004
AviSynth 2.58, build Dec 22 2008 [08:46:51]

Number of frames: 3476
Length (hhh:mm:ss.ms): 000:02:19.040
Frame width: 1920
Frame height: 1080
Framerate: 25.000 (25000/1000)
Interlaced: No
Colorspace: YV12

Frames processed: 3476 (0 - 3475)
FPS (min | max | average): 35.33 | 449.2 | 320.0
CPU usage (average): 6%
Thread count: 12
Physical Memory usage (peak): 346 MB
Virtual Memory usage (peak): 444 MB
Time (elapsed): 000:00:10.864

C:\Users\Don\Downloads>avsmeter "2014-03-16_21-40-44_BBC Red Button HD_.avs"

AVSMeter 1.7.5 (AVS 2.5, x86) by Groucho2004
AviSynth 2.58, build Dec 22 2008 [08:46:51]

Number of frames: 3476
Length (hhh:mm:ss.ms): 000:02:19.040
Frame width: 1920
Frame height: 1080
Framerate: 25.000 (25000/1000)
Interlaced: No
Colorspace: YV12

Frames processed: 3476 (0 - 3475)
FPS (min | max | average): 8.340 | 96.51 | 63.45
CPU usage (average): 9%
Thread count: 13
Physical Memory usage (peak): 349 MB
Virtual Memory usage (peak): 571 MB
Time (elapsed): 000:00:54.786

[Guest]

Here is a deinterlacer comparison. The first is QTGMC and the second is QS. This is from one of my deinterlacer torture clips, so neither looks very good, but they appear comparable to me, although QTGMC clearly looks sharper. Both handle the diagonal lines well without aliasing. Given the relative slowness of QS deinterlacing compared to NV, I'd have to expect that they are doing something useful with the processing time. ;)

[kalehrl]

QS is definitively better than Yadif but worse than QTGMC even at Super Fast preset.

[Guest]

That pretty much sums it up. One must decide if the extra quality of QTGMC is worth the CPU processing time. IMHO, a lot depends on the quality of the input stream. If it is typical broadcasted stuff, one might argue that QTGMC is overkill. For bluray streams and other high-quality sources, one can make a case for QTGMC. It is good to have options.

Remember too that QS is real-time so it can be used in players, etc.

[Guest]

Intel beta driver 3496 fixes the issue with HW decode of VC1, but I have to release a new beta that doesn't force SW for VC1 before you can take advantage of it. I want to investigate one more issue I am aware of for MPEG2 streams before I do that.

[Guest]

Here is beta 18:

* VC1 HW decoding is now supported. Use it only if you have Intel driver 3496 beta or greater installed, otherwise, use SW decoding (engine=2).

* Seeking to the last GOP in MPEG2 files now works.

* Fixes bad frames at the beginning of the stream for some MPEG2 streams.

http://neuron2.net/misc/dgdecim_b18.zip

My priorities now are:

1. Double rate deinterlacing.

2. Crop/resize on iGPU.

3. Create documentation and make first formal release.

4. MVC support.

5. Performance tweaking.

6. IVTC.

Did I miss anything?

[lansing]

beta17 fixed my problem with the "there' is no function name "" " issue, thanks RedDwarf1 and neuron2 for the follow up.

And where can I get the beta Intel driver? I used their site's auto detect and they only gave me 3412, which I already have.

]
Did I miss anything?

HW IVTC?

[Guest]

Don't do auto detect. Do a search for 3496 using the browse function.

https://downloadcenter.intel.com/Detail_Desc.aspx?agr=Y&DwnldID=23644&keyword=3496&lang=eng

IVTC will be worth considering if it is properly adaptive, reliable, etc. I have to do some testing. For example, if there is no postprocessor to catch bad matches then one has to run a SW external postprocessor, which negates much of the value of doing IVTC on the iGPU.

[WorBry]

That pretty much sums it up. One must decide if the extra quality of QTGMC is worth the CPU processing time. IMHO, a lot depends on the quality of the input stream. If it is typical broadcasted stuff, one might argue that QTGMC is overkill. For bluray streams and other high-quality sources, one can make a case for QTGMC. It is good to have options.

Remember too that QS is real-time so it can be used in players, etc.

Another point to consider is that QTGMC, in default mode, doesn't preserve the original fields (requires highly CPU-intensive SourceMatch/Lossless modes to do so) and, I assume, the QS 'double-rate' deinterlacer will, in order that the original fields can be recovered and re-interlaced downstream, if desired ? So in comparing quality, perhaps YadifMod-NNEDI3 would be a more valid reference as a high-end 'pure' (in the classic sense) deinterlacer?

[Guest]

Another point to consider is that QTGMC, in default mode, doesn't preserve the original fields Can you elaborate a little on this please? I wasn't aware of that.

BTW, my deinterlacer comparison is a bit off because the QTGMC is doing double rate and the QS is doing single rate. When I complete the QS double rate support, we can compare them fully correctly.

[bxyhxyh]

In index file it says SIZ 1920 x 1088
Source is 1920x1080.
Is it ok?

[Guest]

Yes, it shows the coded size not the display size. Don't worry, though, it will be cropped for output.

[WorBry]

Can you elaborate a little on this please? I wasn't aware of that.


The English Instructions included in the QTGMC package download give a more complete explanation:

http://forum.doom9.org/showthread.php?p=1423459#post1423459

But basically, in default mode, the temporal gaussian blur and resharpening functions that are applied to the core bob (to eliminate interline shimmer/twitter) alter both the interpolated and original field pixels. In fact, if you re-interlace the output, what you see on playback (in a media player with bob-deinterlacer) is a kind of undulating distortion of fine line detail and high-contrast edges where shimmer would otherwise have appeared.

There are two optional 'lossless' modes, one of which does restore the 'exact pixels' of the source fields, but possibly at the expense of some residual shimmer, minor combing and noise. Like I said, the TQGMC 'instructions' explain it more fully.

[Guest]

Thank you for the useful explanation and link.

Maybe QS doesn't preserve them too? We'll have to see when I get double rate implemented.

[Mixer73]

Subbed, I do a bit of encoding on a mobile machine with QS so I wonder what benefit using this would bring for MPEG2->264?

[Guest]

It serves decoded video via Avisynth at high speed and with low CPU usage in a frame-accurate manner. It has all the same features as DGDecNV.

[MeteorRain]

I just experienced a deadlock(?) in DGIM when encoding a tv cap. DGIM was used with deinterlace=1.

It was a 2 hours long tv capture video file and I just left it encoding and when I came back it halted with DGIM consuming 100% of a single core.

I reproduced the problem with exact the same process. It halted at (in my case) frame #53922 when encoding, in both try.

However if I open the avs inside VDM, jump to #53500 and then play it for about 1000 frames, it works perfectly without any problems.

I'm still trying to find out the minimum condition to reproduce the issue, so just a FYI for now.

[MeteorRain]

OK I now can reproduce the issue if I started from #40010 and DGIM halts at #13925(+40010) when encoding, with or without deinterlace.

I come up with a TS file of 931MB which can reproduce the issue. Further trim the file and the issue will not happen.

Do you want me to upload the file somewhere?

dgsourceim("testc.dgi")
crop(0,0,16,16)

[MeteorRain]

FPS (min | max | average): 35.33 | 449.2 | 320.0
CPU usage (average): 6%

FPS (min | max | average): 8.340 | 96.51 | 63.45
CPU usage (average): 9%


I'm also curious about the CPU usage. By using process explorer I observed very high usage from libmfxhw32.dll. Expected behavior?

EDIT: Maybe It wasn't clear. I meant the deinterlace function inside DGIM/QS causes high CPU usage on libmfxhw32.dll even in hardware mode. Is the deinterlacer working under SW mode?

[bxyhxyh]

I just experienced a deadlock(?) in DGIM when encoding a tv cap. DGIM was used with deinterlace=1.

It was a 2 hours long tv capture video file and I just left it encoding and when I came back it halted with DGIM consuming 100% of a single core.

I reproduced the problem with exact the same process. It halted at (in my case) frame #53922 when encoding, in both try.

However if I open the avs inside VDM, jump to #53500 and then play it for about 1000 frames, it works perfectly without any problems.

I'm still trying to find out the minimum condition to reproduce the issue, so just a FYI for now.
I have same issue with bluray source.
I didn't use deinterlace or any other parameters. I can't upload sample now because of internet problems.

[Guest]

Do you want me to upload the file somewhere?

dgsourceim("testc.dgi")
crop(0,0,16,16) Yes please. Also I need your encoder version and command line. Thanks.

[MeteorRain]

Yes please. Also I need your encoder version and command line. Thanks.

avs2avi dead.avs -c null -o n

avs2avi alone can reproduce the issue.

I'll find a place to upload the huge file. Hold on....

https://copy.com/0LObIiiRjWbp Be sure to remove the link if it is inappropriate for this forum.

Since it hangs when decoding a specific GOP, I cut the file one GOP after. So you should be able to hit the issue on the last GOP of this file.

[Groucho2004]

avs2avi dead.avs -c null -o n

avs2avi alone can reproduce the issue.
Try VirtualDub analysis pass or avsmeter for this purpose.

[MeteorRain]

Try VirtualDub analysis pass or avsmeter for this purpose.

AVSMeter 1.7.3 [AVS2.6] by Groucho2004
AviSynth+ 0.1 (r1576, x86)

Number of frames: 11790
Length (hhh:mm:ss.ms): 000:06:33.393
Frame width: 16
Frame height: 16
Framerate: 29.970 (30000/1001)
Interlaced: No
Colorspace: YV12

Frame (current | last): 11739 | 11789
FPS (cur | min | max | avg): 183.00 | 35.72 | 265.26 | 182.36
CPU usage (current | average): 11% | 12%
Thread count: 28
Physical Memory usage: 125 MB
Virtual Memory usage: 252 MB
Time (elapsed | estimated): 000:01:04.378 | 000:01:04.652

Press ESC to stop...


I didn't think it's avs2avi's fault because I tried different x264, tried avs4x264mod piping, tried wrap it inside MP_Pipeline, etc., and they all fail the same. Process explorer clearly shows the high cpu usage inside the dgim library dll thread.

[Groucho2004]

I tried different x264, tried avs4x264mod piping, tried wrap it inside MP_Pipeline, etc., and they all fail the same.
I assume you tried different Avisynth versions as well, right?

[MeteorRain]

I assume you tried different Avisynth versions as well, right?

Not yet. This is a good point but I'm still doing multiple parallel encoding and can't replace the dll in the middle.

Also from experience if something was wrong inside the dgim dll thread, and switching from dgim to dgnv will solve the problem, I would first suspect the issue staying inside dgim, unless avs+ was doing something really strange and no one has noticed that before.

Anyway thanks for pointing that out. I'll try go back to avs and see what happens. (Of course after I wake up)

[bxyhxyh]

Mine is avisynth 2.6 icl10 build by Groucho2004, x264 is 2409.

When I open source file with LWLibavVideoSource, it was ok, dss2 was ok, ffvideosource was ok.

It is stopping like dss2, which sometimes stuck at 99%.

[Guest]

Please report your Intel driver version. We need to try with 3496 beta. I am away from my PC until later today, then I will run some longer tests.

[MeteorRain]

libmfxhw32.dll = 4.0.1533434.80609, 4.14.1.9
Intel driver = 10.18.10.3412 on 2014-1-22

Also tested on AVS 2.6

AVSMeter 1.7.3 [AVS2.6] by Groucho2004
AviSynth 2.60, build:Mar 9 2013 [13:28:27]
Active MT Mode: 0

Number of frames: 11790
......

Frame (current | last): 11749 | 11789
......

[bxyhxyh]

Intel driver 10.18.10.3412

[Guest]

Can you gents please try 3496 beta as I suggested?

I'm downloading MeteorRain's sample now for investigation.

@bxyhxyh

Please give me the bluray title and tell me if it is AVC, MPEG2, or VC1. Thank you.

[MeteorRain]

Can you gents please try 3496 beta as I suggested?
The previous link is dead. I assume you are talking about Intel® Iris™ and HD Graphics Driver for Windows* 7/8/8.1 64-bit
Version: 15.33.18.64.3496 (https://downloadcenter.intel.com/Detail_Desc.aspx?agr=Y&DwnldID=23714&lang=eng), right?

Will give it a shot.

No it still doesn't work

[bxyhxyh]

@neuron
It is anime called Paprika, mpeg-2. I'll try to upload sample.

[Guest]

Ok, thanks (Paprika is a cool anime). I have duplicated the issue with MeteorRain's stream. It seems to affect MPEG2 only. 3496 beta will not help you.

Initial indications point to an issue in the Intel SDK. Investigating...

[Guest]

OK, I have slipstreamed a possible fix into beta 18. It fixes MeteorRain's stream. Re-download beta 18 and update DGDecodeIM.dll. Please report your results.

MPEG2 is hosed in the Intel SDK and I am having to code workarounds and hope the house of cards remains standing. Meanwhile my post about it at the Intel forum remains waiting for support.

[MeteorRain]

So far so good for this particular file. I'll be doing several long time encoding recently, and will report if I find issues later.

Thanks for the quick fix!

[bxyhxyh]

Sample - https://www.dropbox.com/s/9bqh4syiu6zotet/00000.ts

[Guest]

I meant the deinterlace function inside DGIM/QS causes high CPU usage on libmfxhw32.dll even in hardware mode. What do you mean by high? Action in the hw dll should not be surprising when the hw engine is used.

Is the deinterlacer working under SW mode? You can easily show that it does not work. That's why it is mentioned in the Notes.txt file.

[Guest]

Sample - https://www.dropbox.com/s/9bqh4syiu6zotet/00000.ts Thanks for your sample. It's fixed by the latest beta 18.

[MeteorRain]

What do you mean by high? Action in the hw dll should not be surprising when the hw engine is used.

I was concerning about a higher CPU usage by the dll under de-interlaced mode.

As a general thinking, if the deinterlacer is working purely on hardware, there shouldn't be that much CPU usage inside the dll compared to non-deinterlaced mode. It looks like its speed is limited due to the single core performance instead of the iGPU chip.

[Guest]

I can't understand meaningless terms like "that much".

In my earlier posted results I had 6% CPU for deinterlace=0 and 9% for deinterlace=1. Do you find this to be problematic?

[MeteorRain]

In my earlier posted results I had 6% CPU for deinterlace=0 and 9% for deinterlace=1. Do you find this to be problematic?

I had process explorer (the sysinternal one) monitoring the CPU usage of all threads inside the process when I'm running avsmeter.

I observe the fact that a single thread inside libmfxhw32.dll consume 10.5% when deinterlacing. Considering it's a 4c8t processor, 10.5% equals to 84% usage of a single physical core, which I think is a rather high usage.

If it's multi-threaded decoding, at least its performance can be scaled on a multi-core processor. But consider that it's a single thread that takes that much resources, the performance is strictly limited to the single core performance.

Please correct me if I was wrong. Thanks.

========== EDIT

Also if you consider the decoding speed, the performance is more "problematic".

Without deinterlacing, it works at 250fps+ when consuming 6.5% and AVSMeter and DGIM consume the rest 6%.
With deinterlacing, it works at 70fps and consumes 10.5% and AVSMeter and DGIM consume 2% combined.

This result comes out under both circumstances that I did or did not limit the process to use only one core.

[Groucho2004]

I observe the fact that a single thread inside libmfxhw32.dll consume 10.5% when deinterlacing. Considering it's a 4c8t processor, 10.5% equals to 84% usage of a single physical core, which I think is a rather high usage.
That's a weird logical fallacy.
If you consider a real 8 core CPU where 1 thread is at 10.5% usage, the total CPU usage (which is by the way what AVSMeter measures) would be 1.3%.

The load for a single core CPU in this scenario would be 10.5%.

[MeteorRain]

That's a weird logical fallacy.
If you consider a real 8 core CPU where 1 thread is at 10.5% usage, the total CPU usage (which is by the way what AVSMeter measures) would be 1.3%.

The load for a single core CPU in this scenario would be 10.5%.

Apologize if I didn't state clearly. 10.5% usage I mentioned was against the total CPU usage. I also test it with 2 physical core given (Core 1 and Core 5) and it remains the same.

If this is not that clear, here is the screenshot.

http://i.imgur.com/npeeSA7.png

EDIT: If you see my edit section you should have some idea when I said 6.5% plus the rest 6% which is 12.5%, one-eighth of the whole processor.

[Groucho2004]

OK, I see what you mean. So, how is the usage distribution when you use less cores? I'm not sure what you mean by "I also test it with 2 physical core given (Core 1 and Core 5) and it remains the same".

[MeteorRain]

OK, I see what you mean. So, how is the usage distribution when you use less cores? I'm not sure what you mean by "I also test it with 2 physical core given (Core 1 and Core 5) and it remains the same".

I tested with 1 core assigned (by setting affinity), and with 2 cores assigned, and I observed the same usage. That is to say, it is single threaded and consumes as much as a single core and this becomes its bottleneck.

And I also concerned about the high CPU usage (and the much difference between deinterlace is on or off).
If the deinterlacing is done purely on hardware, there shouldn't be that large difference on the CPU usage.

I suppose the dll is just pulling frames from the GPU chip, right?
Please correct me if I'm wrong.

[Groucho2004]

Setting affinity to one core is not the same as having only one core available. You have to disable cores in the BIOS to simulate this.

[Guest]

And I also concerned about the high CPU usage (and the much difference between deinterlace is on or off).
If the deinterlacing is done purely on hardware, there shouldn't be that large difference on the CPU usage. Who says it's done purely in hardware? The Intel sample code also shows a similar impact for using the deinterlacer. And have you compared performance of (say) DXVA with the deinterlacer on and off? Don't be so fast to pin what you see as poor performance on DGDecodeIM. As I said earlier, I am not doing anything special, just following the Intel sample code.

I suppose the dll is just pulling frames from the GPU chip, right? Who knows? I don't have access to the details of the implementation.

Performance tweaking is on my priority list, and some improvement may be possible. I just don't know yet.

[nevcairiel]

I get similar results in my MediaSDK decoder implementation with deinterlacing. Around ~450-470 fps raw decoding on this particular 1080p H264 interlaced clip, and only ~140 fps with double-rate deinterlacing (or 70-80 with half rate, but really, who uses that).
Its the one part where NVIDIAs CUDA/CUVID decoder is faster, even before Maxwell, as it can decode at ~140 fps and then double-rate deint to 280 fps.

[Guest]

If it's multi-threaded decoding, at least its performance can be scaled on a multi-core processor. But consider that it's a single thread that takes that much resources, the performance is strictly limited to the single core performance.

Please correct me if I was wrong. There is only one iGPU. How do you intend to negate this fact through multithreading?

Really, if you think you can improve the architecture or implementation, you should contact Intel about it. I suspect that they have thought it through carefully, however.

[MeteorRain]

Who says it's done purely in hardware? The Intel sample code also shows a similar impact for using the deinterlacer. And have you compared performance of (say) DXVA with the deinterlacer on and off? Don't be so fast to pin what you see as poor performance on DGDecodeIM. As I said earlier, I am not doing anything special, just following the Intel sample code.

Who knows? I don't have access to the details of the implementation.

Performance tweaking is on my priority list, and some improvement may be possible. I just don't know yet. If you find it unusable as is, then my advice would be to not use it.

I never want to blame DGIM. The high usage comes from the Intel SDK and I was just curious about it and wondering if you have some idea. Well anyway it seems to be off-topic so I'll stop here.

Thanks for various ideas.

[Guest]

it seems to be off-topic It's not off-topic, just very low on the priority list right now. Pressing about it is distracting from the directions I want to go in right now. If you have some technical ideas about improving performance feel free to post about it.

All of which does not detract from my appreciation for your contributions to the thread (and the forum), for which thank you. :thanks:

[Guest]

I got double-rate deinterlacing working in the Intel sample (it's not super obvious). Look for a new beta tonight or tomorrow. I will also remove the time limit on the beta.

Also, at this point I politely decline further free beta licenses, as I plan to make a formal first release tomorrow.

[asteri]

Hello,

I cant make DGDecIM work in HW mode on laptop with Intel i7-2630QM. Of course it has QuickSync http://ark.intel.com/products/52219/Intel-Core-i7-2630QM-Processor-6M-Cache-up-to-2_90-GHz
I cant even install Intel GPU drivers and in Device manager I dont see iGPU just only the Quadro1000. In BIOS I dont see any option to enable iGPU.

Any advice welcome!

@neuron2
Can you make also x64 version with initial release?

[Video Dude]

I cant make DGDecIM work in HW mode on laptop with Intel i7-2630QM. Of course it has QuickSync http://ark.intel.com/products/52219/Intel-Core-i7-2630QM-Processor-6M-Cache-up-to-2_90-GHz
I cant even install Intel GPU drivers and in Device manager I dont see iGPU just only the Quadro1000. In BIOS I dont see any option to enable iGPU.



If you can't find the iGPU in the BIOS, look in the user manual or pdf for changing the graphics mode. It may be listed in a different section or labeled different than what you were expecting. Do a Google search with the laptop model and how to enable the graphics in the BIOS.

Your laptop likely has switchable graphics (Nvidia Optimus). There should be a graphics control panel that lets you specify which graphics to use per installed program. If you don't see it, make sure you have both the Intel and Nvidia drivers installed correctly. For some laptops, installing the Nvidia drivers found on the Nvidia site will disable Nvidia Optimus. Nvidia mentions this on their driver download page and you must use the Nvidia OEM drivers distributed directly from the laptop manufacturer instead.

[asteri]

Thanks for tip, but I cant find any Intel graphics related drivers on vendor website. The model is HP EliteBook 8560w, all drivers for this model should be here:
LINK (http://h20565.www2.hp.com/portal/site/hpsc/template.PAGE/public/psi/swdHome/?sp4ts.oid=5071173&spf_p.tpst=swdMain&spf_p.prp_swdMain=wsrp-navigationalState%3DswEnvOID%253D4059%257CswLang%253D%257Caction%253DlistDriver&javax.portlet.begCacheTok=com.vignette.cachetoken&javax.portlet.endCacheTok=com.vignette.cachetoken)
All drivers are nVidia related :/ (or ATI). This laptop is aimed to CAD, CAM application using certified graphics card.

Any other suggestions?

[Guest]

You need to go to your support site for your PC and ask them. I cannot do that support in this thread.

[Nico8583]

Hi, a little question : with your DGDecIM (or DGMVCSource), is it necessary, recommended or useless to install a codec pack (like ffdshow) in order to encode avs to x264 ?

Also, I've seen on an earlier post you have changed DGI name but I don't see anything on release note ? And you write "This beta expires on April 1, 2014.", what happens after ?

[CarlPig]

I think DGDecIM goes Final April 1, 2014.

[Groucho2004]

Hi, a little question : with your DGDecIM (or DGMVCSource), is it necessary, recommended or useless to install a codec pack (like ffdshow) in order to encode avs to x264 ?
Necessary - no
Recommended - no
Useless - Yes

:D

[Nico8583]

Necessary - no
Recommended - no
Useless - Yes

:D

Thanks, it's simple and clear :D so I need to install only Avisynth, not ffdshow or matroska :)

[Guest]

As I mentioned in #379 I will remove the time limit before it affects anyone.

I've run into a big problem with the VPP in double-rate deinterlacing mode. On a random access I have to reset the VPP. In single-rate mode it works fine, but in double-rate mode decoding after a VPP reset results in a crash in libmfxhw32.dll. All attempts to work around it have failed so far. I suppose I could try to completely tear down the pipeline and re-init it, but that will change the design radically and why should I have to do that when the documentation says I only have to reset the engine?

There's no way to get support because my posts at the Intel forum don't get answered. Simple things sometimes get answered, sure, but it seems they are unwilling to duplicate reported problems and the actual developers aren't on the forum, and nobody really seems to care. I will likely just release what I have and suspend further development until there is some improvement in support. Anyway, Nvidia's Maxwell and Pascal are looking really exciting and there is great support, so why should I continue banging my head against a wall with an SDK that is hosed up in many ways and isn't properly supported? I don't want to spend my time getting frustrated randomly trying things and building a house of cards. To be honest, I rue the day I even started this project.

[aegisofrime]

As I mentioned in #379 I will remove the time limit before it affects anyone.

I've run into a big problem with the VPP in double-rate deinterlacing mode. On a random access I have to reset the VPP. In single-rate mode it works fine, but in double-rate mode decoding after a VPP reset results in a crash in libmfxhw32.dll. All attempts to work around it have failed so far. I suppose I could try to completely tear down the pipeline and re-init it, but that will change the design radically and why should I have to do that when the documentation says I only have to reset the engine?

There's no way to get support because my posts at the Intel forum don't get answered. Simple things sometimes get answered, sure, but it seems they are unwilling to duplicate reported problems and the actual developers aren't on the forum, and nobody really seems to care. I will likely just release what I have and suspend further development until there is some improvement in support. Anyway, Nvidia's Maxwell and Pascal are looking really exciting and there is great support, so why should I continue banging my head against a wall with an SDK that is hosed up in many ways and isn't properly supported? I don't want to spend my time getting frustrated randomly trying things and building a house of cards. To be honest, I rue the day I even started this project.

That is disappointing on Intel's part. I do want to get an nvidia GPU, but the 750Ti isn't fast enough for gaming, and I don't want to get a GTX 770 when the 870 is likely around the corner. :(

Have you tried asking egur for help?

[Guest]

Here is beta 19 with a few small fixes and the time limit is removed.

http://neuron2.net/misc/dgdecim_b19.zip

[Sharc]

Thanks for all your efforts.
Same destiny for DGMVCsource?

[Guest]

Same destiny for DGMVCsource? We'll see. It may not be too hard to merge the two.

[Nico8583]

We'll see. It may not be too hard to merge the two.

Good news :) and yes, thanks for all your work !!

[asteri]

Here is beta 19 with a few small fixes and the time limit is removed.

http://neuron2.net/misc/dgdecim_b19.zip

Remove line from Notes.txt ;)
9. This beta expires on April 1, 2014.

[Guest]

Thanks for pointing it out.

[aegisofrime]

Out of curiosity, after the recent setbacks due to Intel's lack of cooperation, is it safe to conclude that this project is dead in the water? After reading rumors about Maxwell high end parts being delayed to next year, I'm thinking about finally getting that GTX 750Ti :(

[CarlPig]

Out of curiosity, after the recent setbacks due to Intel's lack of cooperation, is it safe to conclude that this project is dead in the water? After reading rumors about Maxwell high end parts being delayed to next year, I'm thinking about finally getting that GTX 750Ti :(

Here is a link for maxwell support: http://forum.doom9.org/showthread.php?t=170349

[Guest]

Out of curiosity, after the recent setbacks due to Intel's lack of cooperation, is it safe to conclude that this project is dead in the water? I cannot proceed further without support and at this time it is not forthcoming, although that can change. So draw your own conclusions. Whatever happens, it still works pretty good as is but won't get the bells and whistles.

[WorBry]

.... it still works pretty good as is....

Indeed it does, and if double-rate deinterlacing is the only bell/whistle that is not possible just now, folks can just as easily use a deinterlacer of their choice. Any possibility of adding audio demux though?

[Nico8583]

MVC support would be marvelous before to add new functionality :)

[RedDwarf1]

Out of curiosity, after the recent setbacks due to Intel's lack of cooperation, is it safe to conclude that this project is dead in the water? After reading rumors about Maxwell high end parts being delayed to next year, I'm thinking about finally getting that GTX 750Ti :(

The Maxwell GPU's do sound very promising indeed. I particularly like the power saving features that they introduce and that feature alone makes them far more interesting to me than everything else combined.

Quicksync slow de-interlacing has meant that I have largely lost interest in it because broadcast TV is what I deal with most rather than bluray. I don't intend upgrading yet again so quickly for what would be very little benefit judging by the de-interlace performance with the 4770. For me, maxwell sounds like where I am headed. I would however prefer a single slot card.

[Guest]

i've been testing dgindexim out and i've notice one option that isn't there nor does it do it by default which is shocking
it seems if you make a dgi file it doesn't exit on its own at all even with any of the commands that i know of, the only way to do this is ctrl c or killing the app. it would nice to have this option back as its kind of unusable to a point. i've tryed these for the cmds:

DGIndexIM.exe -i test.ts -o testing.dgi
DGIndexIM.exe -i test.ts -o testing.dgi -e
DGIndexIM.exe -i test.ts -o testing.dgi -a -e

please fix this minor issue i've also notice this a few times but its still the same in beta 19 I received this report via PM. Everybody, please use the thread and not PM for bug reports. I'll look into this now.

EDIT: I cannot reproduce this. Maybe your stream has a problem. Does it happen with all streams for you?

[Guest]

WorBry asked me about audio demuxing. I thought that it should be working via the CLI, i.e., when you run dgindexim manually. The options are described in the DGIndexNV manual. I will test this also now.

[cegy]

I received this report via PM. Everybody, please use the thread and not PM for bug reports. I'll look into this now.

EDIT: I cannot reproduce this. Maybe your stream has a problem. Does it happen with all streams for you?

i think i've found the problem if you make a index file via cmd it won't exit yet if you did it by a basic batch file it does exit which is very odd also you can't demux the audio using -a :(

[Guest]

i think i've found the problem if you make a index file via cmd it won't exit yet if you did it by a basic batch file it does exit which is very odd also you can't demux the audio using -a :( It exits in all cases for me. If you still have an issue, I can make a debug load for you. Also, what is your OS and how do you start your command window? It should be cmd.exe. Anybody else seeing this?

A note that may explain what is happening: When the command finishes, you won't see a new command window prompt unless you hit return. The process did end, however.

Audio demux is addressed in b20 (see next post).

[Guest]

Here is beta 20. It sets Enable_Audio_Demux=1 in the INI file by default. You have to either change it manually in your existing INI file, or delete your INI file and let a new one be created. Also, DGSourceIM() when given a stream as input will automatically set -a (audio demux) for the indexer. Finally, the progress report to the console now prints with a \r instead of a \n.

http://neuron2.net/misc/dgdecim_b20.zip

[cegy]

It exits in all cases for me. If you still have an issue, I can make a debug load for you. Also, what is your OS and how do you start your command window? It should be cmd.exe. Anybody else seeing this?

A note that may explain what is happening: When the command finishes, you won't see a new command window prompt unless you hit return. The process did end, however.

Audio demux is addressed in b20 (see next post).


open up cmd.exe and cd to the folder and then do it as that's the only way that i know of but i do use the stexbar myself to make it easier.

audio demuxing does works great but i do wonder if its got the same issue as dgindexnv has with reporting random delays when it was 0ms, from my testing it seems this issue isn't here could you confirm this ?

p.s its in the todo.txt for dgindenv incase anyone asks
"Demux zero-delay audio (instead of reporting delay)"

[Guest]

open up cmd.exe and cd to the folder and then do it as that's the only way that i know of but i do use the staxbar myself to make it easier. I don't know what staxbar is and so you are confusing me. Try without it and report again.

audio demuxing does works great but i do wonder if its got the same issue as dgindexnv has with reporting random delays when it was 0ms, from my testing it seems this issue isn't here could you confirm this ? I don't know what you mean by "reporting random delays when it was 0ms", nor am I aware of any such issue. If you have an issue, you need to give a stream I can use to reproduce it.

p.s its in the todo.txt for dgindenv incase anyone asks
"Demux zero-delay audio (instead of reporting delay)" That is a different matter.

[cegy]

I don't know what staxbar is and so you are confusing me. Try without it and report again.


i told you two different ways on how i get this issue both of which give the same result :(

also if you did google stexbar you would find it
http://stefanstools.sourceforge.net/StExBar.html

[Guest]

I can't reproduce it, so there's nothing I can do for you. If anyone else reports it then I can try a debug load for you.

You haven't told me your OS as I asked you, nor have you answered if it affects all streams. And you haven't clarified the audio issue or provided a stream.

[cegy]

oh sorry i forgot to say i'm using windows 7 sp1 32bit and it happens to any type/sort of streams i want to use but we'll see if anyone else gets this problem or if its just me :(

[Guest]

OK. Do I have to ask again for the audio issue clarification or should I just forget it?

[cegy]

OK. Do I have to ask again for the audio issue clarification or should I just forget it?

its was more of a question to you than me having a issue. i did only bring it up due to the different in the audio delay being reported from dgavcindex and dgindexnv but it seems this isn't a issue any more it seems but if i do find any issues like this i'll report it to you! :thanks:

[Guest]

I don't know anything about dgavcindex. ;)

[WorBry]

Here is beta 20. It sets Enable_Audio_Demux=1 in the INI file by default.

Great. Works fine with my AVCHD camcorder files, so I'm a happy camper. Thanks a lot. :)

[Nico8583]

Is there an impact with this new audio functionnality ? I don't need it, so do I leave by default ?

[Guest]

If you use the indexer by CLI you can disable demuxing by omitting the -a. If you do it on the fly with the script, then you always get -a (but see below). The overhead of demuxing (not large anyway) will only affect the indexing. Serving of the video will not be affected.

I could add an option to dgsourceim() to enable/disable demuxing, but I don't really see the point. OK, you may have to delete an audio file if you don't want it.

Another thing you can do is change Enable_Audio_Demux to 0 in the INI file, and then nothing will ever be demuxed, regardless of the -a option.

Great. Works fine with my AVCHD camcorder files, so I'm a happy camper. Thanks a lot. :) Good to hear! Thanks for reporting your results.

[Nico8583]

Ok thanks, I use CLI command (dgindexim -i panama.264 -o panama.264.dgi) so I don't use -a. But what type of source can include audio ? TS ? M2TS ? Because I use only .264 or .vc1 file so video only.

[Guest]

All of the following supported containers may contain audio:

ps (e.g., vob or mpeg)
ts
mts
m2ts
mp4
mkv

Elementary streams such as .264, .vc1, and .m2v contain only video.

So you do not need to do anything if you use only elementary streams. You can of course refer to the stream in your script (rather than the index file) and the indexer will be run automatically. You do not have to run it manually.

[Nico8583]

Thanks :) another question : when you'll merge DGDecIM and DGMVCSource, is .dgi file will be necessary for AVC and/or MVC elementary streams ?

[Guest]

Thanks :) another question : when you'll merge DGDecIM and DGMVCSource, is .dgi file will be necessary for AVC and/or MVC elementary streams ? I haven't thought about it yet. What would you like to see?

[Nico8583]

I would like to know what does .dgi do and if it will change anything on MVC source decoding with this pre-analysis

[Guest]

I suppose the DGI file won't have to change as only the base stream would need to be indexed. But we'll see.

[asteri]

Hello neuron2, I would welcome 64bit version of current beta. Is it possible?

[Guest]

Hello neuron2, I would welcome 64bit version of current beta. Is it possible? Try this and let me know if it works. I tested DGIndexIM but not DGDecodeIM as I do not have a 64-bit Avisynth installed.

http://neuron2.net/misc/dgdecim_b20_64bit.zip

[Nico8583]

@asteri : and if you can compare 32 and 64 bit performances, I'm interested :)

[Guest]

Please re-download as I had forgot to load the 64-bit SW DLL instead of the 32-bit one, which would have prevented DGDecodeIM.dll from running.

[lansing]

I tested on my blu-ray video, 64 bit seems to be 20% faster.

32 bit

Number of frames: 202621
Length (hhh:mm:ss.ms): 001:52:40.787
Frame width: 1920
Frame height: 1080
Framerate: 29.970 (120000/4004)
Interlaced: No
Colorspace: YV12

Frames processed: 15100 (0 - 15099)
FPS (min | max | average): 64.56 | 563.7 | 394.2
CPU usage (average): 11%
Thread count: 19
Physical Memory usage (peak): 178 MB
Virtual Memory usage (peak): 331 MB
Time (elapsed): 000:00:38.304



64 bit

Number of frames: 202621
Length (hhh:mm:ss.ms): 001:52:40.787
Frame width: 1920
Frame height: 1080
Framerate: 29.970 (120000/4004)
Interlaced: No
Colorspace: YV12

Frames processed: 17600 (0 - 17599)
FPS (min | max | average): 188.1 | 567.5 | 479.9
CPU usage (average): 11%
Thread count: 19
Physical Memory usage (peak): 126 MB
Virtual Memory usage (peak): 269 MB
Time (elapsed): 000:00:36.674

[Guest]

Thanks for the test results, lansing. May I ask what build of Avisynth you use and where I can get it?

[Nico8583]

Thanks for results also :-) 2s less for x64 with 2000 frames longer than 32 bits, good result ;-)

[Groucho2004]

May I ask what build of Avisynth you use and where I can get it?
Most likely the 64 Bit version from here (http://www.avs-plus.net/).

[lansing]

I'm using avs+ r1576.

I ran it on another blu-ray and the difference is 30%. However, for the few mpeg2 1080 videos I tested, the differences are only between 4%-10%. And also memory usage are significantly lower with 64 bit in all the samples.

[Guest]

Thanks, lansing, I just tested on a random AVC stream and got a 10% increase in FPS.

BTW: The subthread about easily switching between 32-bit and 64-bit Avisynth was moved here:

http://forum.doom9.org/showthread.php?t=170453

[Nico8583]

Is there a quality difference between 32 and 64 bits ? And between Avisynth 2.5.8 and others versions ?

[Guest]

Is there a quality difference between 32 and 64 bits ? And between Avisynth 2.5.8 and others versions ? No, and no.

[asteri]

Strange, I got lower avg speed with x64 version. Maybe I should try another stream, but currently I dont have any others by me.

32bit:

AVSMeter 1.7.7 (AVS 2.6, x86) by Groucho2004
AviSynth+ 0.1 (r1576, x86)

Number of frames: 74435
Length (hhh:mm:ss.ms): 000:49:37.400
Frame width: 1920
Frame height: 1088
Framerate: 25.000 (25/1)
Interlaced: No
Colorspace: YV12

Frames processed: 74435 (0 - 74434)
FPS (min | max | average): 36.62 | 232.9 | 128.7
CPU usage (average): 4%
Thread count: 11
Physical Memory usage (peak): 75 MB
Virtual Memory usage (peak): 253 MB
Time (elapsed): 000:09:38.567


64bit:

AVSMeter 1.7.7 (AVS 2.6, x64) by Groucho2004
AviSynth+ 0.1 (r1576, x64)

Number of frames: 74435
Length (hhh:mm:ss.ms): 000:49:37.400
Frame width: 1920
Frame height: 1088
Framerate: 25.000 (25/1)
Interlaced: No
Colorspace: YV12

Frames processed: 74435 (0 - 74434)
FPS (min | max | average): 41.59 | 246.9 | 124.6
CPU usage (average): 4%
Thread count: 11
Physical Memory usage (peak): 75 MB
Virtual Memory usage (peak): 268 MB
Time (elapsed): 000:09:57.330


Tested on i7-4600U (2C/4T)-it is some kind of more power saving i7 for laptop

[jdobbs]

Maybe I'm just dense, but can someone tell me why I'm getting an "Access Violation" error when I try to run DGDecodeIM()?

Here are my AVS file contents:LoadPlugin("C:\APPS\DGDecNV\DGDecodeIM.dll")
DGSourceIM("D:\WORKING8\WORKFILES\VID_00800.DGI", engine=2)
ConvertToYV12().AssumeFPS(24000,1001)

When I try to open it with X264 I get an access violation on line #2. If I attempt to open it with MPC I get the same error message but the audio plays. I looked at the DGI file and it appears to be fine. It looks exactly like one I created with DGDecNV (except for the first line).

I have DGDecodeIM installed in the same folder as DGDecNV (along with the license file). libmfxsw32.dll is installed in that folder also. I can run DGIndexIM and it indexes the source fine, so I don't think it's a license issue.

I'm running on Windows 7, 64 bit with an AMD processor and no Intel video capability (but it does have an NVIDIA card).

[Guest]

Can you open the script in VirtualDub?

Does it happen with all streams?

[jdobbs]

Can you open the script in VirtualDub?

Does it happen with all streams?Same error with VirtualDub. I haven't tried any other streams -- but this one opens and works fine with DGDecodeNV. I'll try another stream. I'll also try opening this one directly and let it index on-the-fly and see what happens.

[jdobbs]

Now I'm even more confused. I tried opening it with the source pointing directly at the M2TS file -- and it didn't try to index it -- it just started playing the music:
LoadPlugin("C:\APPS\DGDecNV\DGDecodeIM.dll")
DGSourceIM("N:\BD\ANCHORMAN_2\BDMV\STREAM\00800.M2TS", engine=2)
ConvertToYV12().AssumeFPS(24000,1001)

[jdobbs]

I see now. It had previously created a .DGI in the source folder. That may be the source of the problem. I'll do some testing and get back to you.

[jdobbs]

Ok. If I let the on-the-fly indexing complete, it opens the file ok. But, if I run DGIndexIM to create a .DGI file in my working folder, and then reference the .DGI it doesn't work. It appears it tries to index the .DGI file.

So if I try to open this file with MPC:LoadPlugin("C:\APPS\DGDecNV\DGDecodeIM.dll")
DGSourceIM("D:\WORKING8\WORKFILES\00031.DGI", engine=2)
ConvertToYV12().AssumeFPS(24000,1001)It tells me it is indexing, and I get this as the index file (named 00031.DGI.dgi):DGAVCIndexFileNV14 DGIndexIM beta 20 X32
C:\APPS\DGDecNV\

00031.DGI 2801675

DEVICE 0
DECODE_MODES 0,1,0
STREAM 0
CLIP 0 0 0 0
RANGE 0 0 2801674 0
AUDIO

SIZ 0 x 0
FPS 0 / 0
CODED 0
PLAYBACK 0
0.00% FILM
ORDER -1 and then I get the "Access Error" violation.

I'm using the zip file from the first post of this thread. Is that the most recent one?

[jdobbs]

Got it. It doesn't like the uppercase letters ".DGI" in the AVS file. I edited the AVS file and made it lowercase, and now it opens and plays the file with this source:LoadPlugin("C:\APPS\DGDecNV\DGDecodeIM.dll")
DGSourceIM("D:\WORKING8\WORKFILES\00031.dgi", engine=2)
ConvertToYV12().AssumeFPS(24000,1001)

[Guest]

Interesting. I will fix that. The case should not matter.

[jdobbs]

Cool. I'm trying to add support for DGDecodeIM() into the next BD Rebuilder release.

Question: Does DGDecodeIM() honor pulldown flags? I tested FRIMDecode() and noticed it didn't with the Intel library.

[Guest]

Question: Does DGDecodeIM() honor pulldown flags? I tested FRIMDecode() and noticed it didn't with the Intel library. Yes, it does if so instructed. Use it the same way as DGDecodeNV.

[jdobbs]

So I could do this?

DGSourceIM("D:\WORKING8\WORKFILES\00031.dgi", engine=2, fieldop=0)

[GZZ]

I use Avisynth+ 64 bit with the exact same script (dif. path) and its working just fine running 64 bit version of dgIndex.

But I'm wonderingen why the procent (%) when indexing a file goes like this 1, 2, 3, 4, 3, 4, 5%... it sometimes goes back and then forward again. I'm indexing *.mkv files (h264 content)

[Guest]

So I could do this?

DGSourceIM("D:\WORKING8\WORKFILES\00031.dgi", engine=2, fieldop=0) Yes, sir. The default for fieldop is 0 anyway so you could omit it if that pleases you.

[Guest]

But I'm wonderingen why the procent (%) when indexing a file goes like this 1, 2, 3, 4, 3, 4, 5%... it sometimes goes back and then forward again. I'm indexing *.mkv files (h264 content) Hmm, that's bizarre. I'll try to duplicate it, but at a minimum I can force it never to go backwards. :rolleyes:

[jdobbs]

Yes, sir. The default for fieldop is 0 anyway so you could omit it if that pleases you.Actually I'm more interested in using it for recovering film frames (on imported DVDs) -- so the fieldop option is great.

Thanks!

[Guest]

Actually I'm more interested in using it for recovering film frames (on imported DVDs) -- so the fieldop option is great.

Thanks! The concept of course is due to the legendary jackei of DVD2AVI fame. He also invented "force film". All hail jackei.

[jdobbs]

The concept of course is due to the legendary jackei of DVD2AVI fame. He also invented "force film". All hail jackei.I didn't know that. I second that "hail".

[jdobbs]

I'm getting decoding errors with pretty much any MPEG-2 (DVD resolution) source that I try to decode. The source video is remuxed into an M2TS using TSMUXER, and then is fed via AVISYNTH using DGIndexIM/DGDecodeIM. Here is the AVS file:LoadPlugin("C:\APPS\DGDecNV\DGDecodeIM.dll")
DGSourceIM("D:\WORKING5\WORKFILES\VID_00001.dgi", engine=2, fieldop=0)
ConvertToYV12().AssumeFPS(24000,1001)Below is a jpg showing the output (the source is showing a sky scene). The same source plays correctly when using DGDecodeNV. Other sources may differ somewhat, but all have issues within the first few seconds of playback.

[Guest]

I slipstreamed two fixes into b20 so re-download it if you need these fixes.

1. DGDecodeIM: Accept uppercase "DGI" extension without crashing.

2. DGIndexIM: Progress indication never goes backward.

[Guest]

What happens if you don't remux into M2TS, i.e., open the VOB directly with DGDecodeIM? Or is it that the M2TS plays correctly in NV but not IM?

Can you provide an M2TS fragment that I can use for testing?

[jdobbs]

What happens if you don't remux into M2TS, i.e., open the VOB directly with DGDecodeIM? Or is it that the M2TS plays correctly in NV but not IM?

Can you provide an M2TS fragment that I can use for testing?It plays correctly in NV but not IM.

I posted this in the wrong thread... I'll move it.

[Edit] I'll create a short fragment and get it to you.

[Guest]

OK, awaiting your sample...

[jdobbs]

OK, awaiting your sample...I sent a link via PM.

[Guest]

Thanks, investigating...

[Guest]

More shame for Intel...

It works just fine with the HW engine, but not for the SW engine. There is nothing I can do about it and asking Intel through their forum is a useless waste of time, as they only say they will ask their "experts" and then never come back with anything.

[jdobbs]

Ughhh... I guess I'll back-off on adding it to BD Rebuilder.

Thanks.

[asteri]

I slipstreamed two fixes into b20 so re-download it if you need these fixes.

1. DGDecodeIM: Accept uppercase "DGI" extension without crashing.

2. DGIndexIM: Progress indication never goes backward.

I think the same bug I saw in DGDecNV, can you integrate "never go back" fix also in the DGDecNV ?

[Guest]

At some point, yes.

[MeteorRain]

Recently I just tried the resize_h and resize_w parameters and it hangs after reading some frames.

EDIT: Being aware that I'm not on the latest version, I just update it to beta 20.

It appears that some videos get decoding smoothly (but incorrect image displayed), some crash on initializing.

[Guest]

Please use the latest version and provide a stream(s) to allow me to duplicate it.

[MeteorRain]

akiyuuki.dreamhosters.com/dgtest.tar

[Guest]

Sorry, I forgot that resizing is not implemented. I should add an error message. Thanks for pointing it out.

"It appears that some videos get decoding smoothly (but incorrect image displayed), some crash on initializing."

Do you have a stream for this and instructions for seeing the problem?

[tormento]

HW crop is not working yet, correct?

It does misunderstand dgi crop coordinates, correct?

[Guest]

Cropping and resizing are not implemented and I have to remove those parameters or add an error message. Further work on DGDecIM is low priority for me, however, at this time.

[Nico8583]

Hi,
Intel Media SDK 2014 R2 has been released on 12 May 2014 : http://software.intel.com/sites/default/files/MediaSDK2014R2Clients.zip
Perhaps it solves bugs (MVC Pacific Rim bug and some bugs found in this topic) ?
I'm trying to search changelog.

[jdobbs]

Hi,
Intel Media SDK 2014 R2 has been released on 12 May 2014 : http://software.intel.com/sites/default/files/MediaSDK2014R2Clients.zip
Perhaps it solves bugs (MVC Pacific Rim bug and some bugs found in this topic) ?
I'm trying to search changelog.I'm running "Pacific Rim" with FRIMDecode/FRIMEncode and the new DLL now. I'll let you know if it makes a difference.

[Guest]

Thanks, jdobbs! If it improves things, I'll update DGDecIM.

[jdobbs]

I ran it against the short test file that was created -- and it doesn't look like it helps. But just to be sure I'm now running against the original source disc. It will be a few hours (probably 5) before it completes.

[Nico8583]

Thanks jdobbs, I hope you'll get a better result...

Is it necessary to compile a new DLL ? Some functions have perhaps changed and need to recompile ? I don't know how Intel SDK works.

[jdobbs]

The new DLL is included in the package.

I ran "Pacific Rim" from the original disc. It completed, but still has the same issues at the same point as before.

[Guest]

FYI, there are parts of the SDK code that get compiled into the DGDecodeIM DLL; it's not all in the Intel DLLs. However, it's unlikely those parts would affect decoding in this case.

[Nico8583]

Thanks for information, so perhaps it is necessary to compile a new DLL with parts of the SDK code ? Or perhaps it could not solve the problem, even with this new version...

[Guest]

I don't think it matters. AFAIK, the only built-in piece is the distributor which determines whether to use HW or SW and then invokes it.

[Carpo]

Did a bit of testing

Intel Core i7 with Intel HD2000 graphics, using Intel 15.28.22.64.3517 drivers (these are the latest I can use, as newer version say my PC does not meat the minimum requirements)

Test 1 - DVD Source

AVS

LoadPlugin("D:\TestAVS\DGDecodeIM.dll")
dgsourceim("D:\TestAVS\DGIM.dgi",engine=1)


D:\TestAVS>avsmeter "D:\TestAVS\DGIM.avs"

AVSMeter v1.10 (Jul 17 2011 01:20:35) by Groucho2004
AviSynth 2.60, build:Sep 18 2013 [17:36:36]

Number of frames: 134798
Length (h:m:s.ms): 1:29:51.920
Frame width: 720
Frame height: 576
Framerate: 25.000 (25000 / 1000)
Progressive: Yes
Colorspace: YV12

Hit ESC to exit...
Frame 134798/134798, fps (min/max/avg): 725.23 | 1523.52 | 1063.21


TEST 2

AVS

LoadPlugin("D:\TestAVS\DGDecodeIM.dll")
dgsourceim("D:\TestAVS\DGIM.dgi",engine=1)
Load_Stdcall_Plugin("D:\MeGUI_2418_x86\tools\avisynth_plugin\yadif.dll")
Yadif(order=1)


AVSMeter v1.10 (Jul 17 2011 01:20:35) by Groucho2004
AviSynth 2.60, build:Sep 18 2013 [17:36:36]

Number of frames: 134798
Length (h:m:s.ms): 1:29:51.920
Frame width: 696
Frame height: 572
Framerate: 25.000 (25000 / 1000)
Progressive: Yes
Colorspace: YV12

Hit ESC to exit...
Frame 134798/134798, fps (min/max/avg): 579.17 | 850.80 | 727.12

As i understand cropping and resizing is not implemented at this time so I did not test with those, I am testing out the same script, but have added QTGMC, will post results later as it's taking a bit longer than yadif, which is to be expected.


QTGMC Result


AVSMeter v1.10 (Jul 17 2011 01:20:35) by Groucho2004
AviSynth 2.60, build:Sep 18 2013 [17:36:36]

Number of frames: 134798
Length (h:m:s.ms): 1:29:51.920
Frame width: 720
Frame height: 576
Framerate: 25.000 (25 / 1)
Progressive: Yes
Colorspace: YV12

Hit ESC to exit...
Frame 134798/134798, fps (min/max/avg): 6.04 | 7.28 | 6.83


Test 3 - Rat.264

AVS

LoadPlugin("DGDecodeIM.dll")
dgsourceim("rat.264.dgi")

AVSMeter v1.10 (Jul 17 2011 01:20:35) by Groucho2004
AviSynth 2.60, build:Sep 18 2013 [17:36:36]

Number of frames: 839
Length (h:m:s.ms): 0:00:34.993
Frame width: 1920
Frame height: 1080
Framerate: 23.976 (24000 / 1001)
Progressive: Yes
Colorspace: YV12

Hit ESC to exit...
Frame 839/839, fps (min/max/avg): 65.70 | 181.61 | 128.05


Test 4

AVS

LoadPlugin("DGDecodeIM.dll")
dgsourceim("rat.264.dgi", engine=1)


AVSMeter v1.10 (Jul 17 2011 01:20:35) by Groucho2004
AviSynth 2.60, build:Sep 18 2013 [17:36:36]

Number of frames: 839
Length (h:m:s.ms): 0:00:34.993
Frame width: 1920
Frame height: 1080
Framerate: 23.976 (24000 / 1001)
Progressive: Yes
Colorspace: YV12

Hit ESC to exit...
Frame 839/839, fps (min/max/avg): 68.34 | 182.66 | 128.62

Not the longest of clips I could have used I know, but it's all I have at this time, I will test with a few Blurays I have once the QTGMC test's have completed.

[Nico8583]

The new DLL is included in the package.

I ran "Pacific Rim" from the original disc. It completed, but still has the same issues at the same point as before.
Could you remind me position(s) bug(s) ?

[sef]

Could you remind me position(s) bug(s) ?

I think this:

Look at 1:06:14. Soon after, you'll see the monster that appears in the fire. The bottom of the image is bad, then the whole image becomes bad. There are 6 bad frames in total.

First bad image in the sequence (Only the bottom part is bad):
http://imagizer.imageshack.us/v2/xq90/600/skjg.png (https://imageshack.com/i/goskjgp)
Last bad image:
http://imagizer.imageshack.us/v2/xq90/31/m367.png (https://imageshack.com/i/0vm367p)

[Nico8583]

Thanks, I have the same issue with my Pacific Rim (French Edition) :(

[jdobbs]

Yep, that's it.

[Sharc]

Still, Pacific Rim seems to be only remaining case causing this issue, right?

[jdobbs]

Still, Pacific Rim seems to be only remaining case causing this issue, right?it's the only one I've seen.

[Nico8583]

Does anyone tried 2D conversion with Pacific Rim ? Because the problem appears on AVC and MVC stream, so the problem is perhaps on AVC stream ?

[Sharc]

The independent stream (.264) plays without the glitches.

[Nico8583]

Have you played it with Intel Decoder ?

[Sharc]

with dgdecNV ......

[Guest]

That's inconclusive. Try it with DGDecIM.

[Sharc]

"This beta Version is expired" (?)
I am using b20 ...

[Guest]

Re-download from my web site.

[Sharc]

Independent (AVC) stream of Pacific Rim:
- Decoding with dgdecIM: Glitches
- Decoding with dgdecNV: No glitches

[Guest]

As expected. Now, try getting support from Intel. :devil:

[Nico8583]

Thanks Sharc, so if we want to test (if Intel decides to provide support...) we can only play AVC stream. I'm going to try to open a case today and I hope Intel will take care of it...

[MeteorRain]

DGIndexIM main window will get the input focus when starting, and even the window does not appear, press space will pause the progress, and if you ever lost the focus on the hidden window you'll have no way to resume the process, only Ctrl-C to terminate it.

[Nico8583]

I have open this thread if anyone want to add/confirm informations : https://software.intel.com/fr-fr/forums/topic/516009

[r0lZ]

I have added a comment to your bug report, and I encourage everybody to do it too. If there are many complains, perhaps they will finally do something...

[Nico8583]

Thanks r0lZ, I'm agree with you ;)

[Guest]

DGIndexIM main window will get the input focus when starting, and even the window does not appear, press space will pause the progress, and if you ever lost the focus on the hidden window you'll have no way to resume the process, only Ctrl-C to terminate it. Is this a bug report or what? I don't fully understand your English. If it is a bug report please describe the impact and how to reproduce it.

[MeteorRain]

Is this a bug report or what? I don't fully understand your English. If it is a bug report please describe the impact and how to reproduce it.

Sorry for the confusion.

How to reproduce:

Under command prompt, run dgindexim by
dgindexim -i input.xxx -o output.dgi

When dgindexim starts, command prompt window will lost focus.
If you press space now, the key will be sent to dgindexim hidden window, and will pause the indexing process.
And if you somehow move the focus away from the hidden window, you'll never put focus back and thus have to kill the indexing process by process manager.

Sorry for my poor English.

[Guest]

Thanks for the clear explanation. I will investigate it. Perhaps just removing the pause function may solve it?

[Guest]

It looks like converting DGIndexIM to a true command line application is the only option. I will do it as time allows.

BTW, I slip-streamed the new licensing scheme into b20. If you re-download you'll have to make a new license file using the online generator.

[MeteorRain]

Thanks for the clear explanation. I will investigate it. Perhaps just removing the pause function may solve it?

A quick fix is to remove / disable the shortcut keys when in hidden mode (as the problem should also exist in "DGIndexNV -h")

A better fix is to convert it to command line app but this is not a very big deal here.

===

And in case you missed this, please check #467 for the sample that you asked for.

Cheers.

[Guest]

@MeteorRain

Please re-download b20 and update DGindexIM and DGDecodeIM, then report here whether it improves the focus issue. Thank you for your report and testing.

Regarding your stream in #467, be aware that resizing and cropping is not supported. I added error messages when resizing or cropping is enabled. If you have other issues with it, please advise. Everything looks OK to me.

[MeteorRain]

@MeteorRain

Please re-download b20 and update DGindexIM and DGDecodeIM, then report here whether it improves the focus issue. Thank you for your report and testing.

:thumb: :thanks:

[asteri]

Strange that Neuron is now Guest? :/ Hope he is still with us.

Id like to ask you Neuron, if you can add in the DGDecIM package in Notes what everything is implemented on HW/SW level, if I am right deinterlacing and crop is HW, but resize for example is just SW or isnt implemented at all? I didnt use DGDecIM some time so I am not sure now. I think it will save you similar questions if you place such info in Notes.txt :)

And what about futher communication with Intel. Do you see any effort from Intels side and will you continue develop DGDecIM?

Ohh and I see in DGDecIM package libmfxswXX.dll from Dec of 2013 but current version is April of 2014. Does it make any sense to replace it to get better results or current DGDecIM supports only the libmfxswXX.dll from end of 2013 ?

Thanks

[videoh]

u probably wanna ask at the DG forum

[jdobbs]

Here's (http://rationalqm.us/board/index.php) a link to the DG forum.

[asteri]

Ok, I will ask on his forum. I thought DGDecIM was discussed mainly here and DG forum is primary for DGDecNV and DGAVCDecDI, isnt it?

[Sharc]

The author (ex "neuron2") of the DG.... tools has recently left this forum. You may continue to discuss his tools here, but you won't get a reply from the author. You can only approach him via his own forum.

[asteri]

Oh, I didnt know it. Strange...
Thank you for the info.