Support forum for DG Tools

Here an interlaced file:
http://www.mediafire.com/file/tquq8uc9o ... .m2ts/file

I can deinterlace or bob it with the switch in DGSource(………..,deinterlace=2), for example. The result is clean.
However, when I do the same with the standalone version of DGBob (or DGTelecide), I am getting a blended mess.
Why are the results different?

With

DGTelecide(mode=1, dthresh=3.5)

it looks okay to me, however I am not that good at seeing those fine details.
What settings did you use for DGTelecide?

Just tried using

LoadPlugin("C:/Program Files (Portable)/dgdecnv/x64 Binaries/DGDecodeNV.dll")
DGSource("I:\W2gutoff.dgi", fieldop=0)
AssumeTFF()
SeparateFields()

and the resulting pattern appears to be a,a,b,b,c,c, etc

gonca's got it right.

First, it is not interlaced; the content is progressive. So don't deinterlace it!

It does have a one-field phase shift, so this will work fine:

dgsource("D:\tmp\Sharc deinterlacing\W2gutoff.dgi")
separatefields().trim(1,0).weave()

Or, if you want to field match:

dgsource("D:\tmp\Sharc deinterlacing\W2gutoff.dgi")
DGTelecide()

While you should not deinterlace this clip, be aware that applying different deinterlacing algorithms to progressive content may yield different results. I can't see any problem here.

Thanks guys

I tried your suggestions, but still the only way to get something useful is via the "deinterlace=" switch in DGSource. All other methods produce blended crap. Even when I separate the fields, all fields are blended. Maybe something is broken in avisynth here. I'll reinstall it from scratch.

Thanks for the hint about field shifted pseudo-interlace. Actually that file was produced by VEGAS. The original source was a progressive .mp4 VFR "by name" clip, 1920x1080p29.97 (nominal). For blu-ray compliance VEGAS has to convert this to interlaced. Apparently VEGAS did this by producing a field-shifted pseudo-interlace clip. I was wondering why it did it this way, but perhaps something is broken here. On the other hand I am aware that these "VFR by name" footage can produce problems with NLEs.

Is there a way to convert VFR to CFR without re-enoding the video?


Edit:

Frame view:
a) Decoding with DirectShowSource() returns clear frames at rate 59.94 as aabbccddee…… (repeated clear frames at double rate)
b) Decoding with DGSource() returns blended frames at rate 29.97 fps (all blended at single rate)
c) Decoding with DGSource(......, deinterlace=1) returns clear frames at 29.97fps as abcdefg.... (clear frames at single rate)

Field view:
a1) Decoding with DirectShowSource() followed by separatefields() returns clear fields at rate 119.88 fields per second as aaaabbbbccccddddeeee..... (clear repeated fields at 4-fold rate = double field rate)
b1) Decoding with DGSource() followed by separatefields() returns blended fields at rate 59.94 as abcdefg....... (all fields blended at field rate)
c1) Decoding with DGSource(....., deinterlace=1) followed by separatefields() returns clear fields at rate 59.94 as aabbccddee ...… (repeated fields at field rate)

Obviously the 2 Source filters do not produce the same results. With DGSource I can obtain unblended output with the internal "deinterlace=" switch only, it seems.
The field shift correction with separatefields().trim(1,0).weave() works with the DSS filter but fails with DGSource.

Please start a new thread for your VFR stuff.

Can you please post a screenshot of this "blended crap" together with the script that creates it? I don't see how Avisynth could be doing this.

Picture of a blended field attached

Script:
DGSource("W2gutsmart.dgi")
assumeTFF().separatefields()

What player are you using to display and grab the screenshot? What frame number is it (after separatefields)? What version of Avisynth+ is it?

Does it show like that in DGIndexNV (Zoom=1) or only after serving?

I don't see anything like that.

Player:
- The one which is in AvsPmod
- MPC-HC
- VirtualDub2

Frame number:
I get this with any frame/field, perhaps a bit more pronounced in the 2nd half of the clip. With the exception of pictures without movement

Avisynth Version:
AviSynth+ 0.1 (r2772, MT, i386)
I am getting the same with AviSynth 260

I see the blended frames (not fields) with interlace scanlines in DGIndexNV, Zoom=1. And also with PureVideo Deinterlacer set to Single Rate or Double Rate.

NVIDIA GeForce GT 730 (GK208) [ASUS]; Drivers 418.91.

LoadPlugin("C:/Program Files (Portable)/dgdecnv/x64 Binaries/DGDecodeNV.dll")
DGSource("I:\W2gutoff.dgi", fieldop=0)
AssumeTFF()
SeparateFields()

This produces
First half Second half Edit
Using 64 bit apps

Such clear pictures as gonca's I am only getting with DSS or with DGSource(…….,deinterlace=1), or DGSource(…….,deinterlace=2) for bobbing.
Confused………. It looks like something is out of step here.

I am also getting clean pictures when I extract the fields with ffmpeg and reencode with x264 (I didn't find a way with ffmpeg without reencoding)

32 bit version

I'm baffled. I get the same results as gonca. Are you absolutely positive we are working with the same sample?

Long shot but....
I am on AviSynth+ version r2728

Yes. I just verified it by downloading the file which I have uploaded, and made a CRC check against my local original file. It's the same.
Strange, strange, strange ......

Do you have access to another system that you can try it on?

No, not with NVIDIA GPU. But as gonca and you got the same result, I conclude that something is borked here.
Perhaps there is something pathalogical with the file? I tried with the ffms2 (Libav) sourcefilter, like
and got a fields sequence with clear, unblended pictures at 119.88 fields per second like babb cbcc dcdd edee ..........

MPC-HC with internal LAV filters and YADIF SW deinterlacer plays the file nicely without blends like abcde .... (single rate, 29.97fps) or aabbccddee (bobbed 59.94fps).

Problem solved!
Installing the latest slipstream of DGDecNV solved the problem. I had still the previous slipstream from January on my system. Sorry for all the confusion, I should have thought of this earlier

I'm happy for you but I don't think DGDecNV ever had such a bug. What slipstream was it that you claim has such a bug? I can retest with that version.

I am not 100% sure but I think it was the one published around January 31. Was this slipstream 165?
If DGDecNV wasn't the culprit I only hope that the issue will not return.

I tested with slipstreams 168 and 161

Yes, it was 165. I will check it when I get the cropping/resizing fix released.

Not seeing any blended fields with build 165.

I'll also test with 165 when the current job is finished. I have absolutely no clue what else could have made the fix. I've tried almost all other options.

I reinstalled slipstream 165 and the problem is back.
So at least I am happy that I found a likely, reproducible cause for my problem.

There is perhaps a faint probability that the .dgi and the .dll are not from the same slipstream, but wouldn't this have caused an error in avisynth?
I may try such criss-crossing later today. So far such misalignment (old .dgi, new .dll) has normally produced an error - in my experience.


Edit:
Even a .dgi which was created with slipstream 165 works ok with the .dll of slipstream 168. I conlcude from this that the culprit is the .dll of slipstream 165 - at least on my system. It's all reproducible here.

So still looking weird. I don't think it's worth digging further, especially as the latest version is working fine for you. I'll mark this resolved, but post again if the problem recurs with later versions.