[SOLVED] x264 encode of DVD MPEG-2 results in green splotches

[MrVideo]

A sample of the problem is available in this zip file (http://vidiot.com/video/Terra_sample.zip).

If you run the MKV file thru mediainfo, you'll see the x264 version used and what the parameters that I used are.

You get a flashing green bar at the bottom of the video and green splotches along the left and right edges. I've run into this issue before, but I do not think I ever solved it.

The source is 480 video from a DVD. It is untouched and placed into a MKV file. VideoReDo is used to extract a short sample from the beginning of the video. AVISynth is used as the program to do the streaming to x264. The AVS script is included. 2-pass encoding.

If anyone has any ideas on what to do to fix this issue, I'd appreciate the pointer to said fix. Thanks.

[SeeMoreDigital]

I've just used MeGUI to generate an AVC encode from your sample which looks fine. Which application are you using?

[sneaker_ger]

I've just used MeGUI to generate an AVC encode from your sample which looks fine.
Did you use his exact AviSynth script?
Most likely this has nothing to do with x264.

[SeeMoreDigital]

Did you use his exact AviSynth script?No way ;)

[poisondeathray]

preview your script in vdub2 or mpchc, are the errors there before encoding ?

update your dgindexnv and dgdecodenv.dll - the dgi reports older version. Or to help debug and rule out some GPU/driver issue, repeat with dgindex/dgdecode.dll instead

[MrVideo]

No way ;)
Why not. All my work is done via AVS scripts. I have a Z-shell script in which I use AVS script templates. So, I'm trying to solve this with my operating procedures. MeGui is not part of what I do.

[MrVideo]

preview your script in vdub2 or mpchc, are the errors there before encoding?
I installed the VirtualDub2 suite of stuff on my XP-64 system. But, when I run VirtualDub64, I can't load the AVS script.
update your dgindexnv and dgdecodenv.dll - the dgi reports older version.
XP system. Don't think I can.
Or to help debug and rule out some GPU/driver issue, repeat with dgindex/dgdecode.dll instead
I do have a script set up for using dgindex/dgdecode.dll for Mpeg-2/4:2:2 videos. I ran it and same result:
LoadPlugin("C:\Program Files (x86)\DGMPGDec\DGDecode.dll")
MPEG2source("e:\\TERRA_NOVA_112-113_extended.d2v")
ConvertToYV12(interlaced=true) <-- with or without this line
assumetff()
telecide(guide=1)
decimate()

[sneaker_ger]

If you are using AviSynth 32 bit you need to use VirtualDub 32 bit.

[MrVideo]

If you are using AviSynth 32 bit you need to use VirtualDub 32 bit.
Ah. OK, I will change my shortcut.

Before I saw this reply, I installed MeGUI to see what it was doing. I know that it created AVS scripts, so I wanted to see what it was doing.

Long story short: I discovered that when it ran dgindex, the d2v file was flagged such that the video was declared 100% film, so 23.976. But, when I run dgindex, the d2v file gets set to 29.97. I do not know what MeGUI is doing to get the film setting. I can force it by adding "-fo 1" to the command line.

When no IVTC is run, the output is fine. But, when it is, the problem appears.

Net result:
assumetff()
telecide(guide=1)
decimate()
does not work, while:
assumetff()
tfm(order=1,mode=0,slow=2,display=false)
Tdecimate()
does.

Thanks for the pointers that made me do a bunch of tests. I will now go work on my scripts.

[videoh]

When no IVTC is run, the output is fine. But, when it is, the problem appears.

Net result:
assumetff()
telecide(guide=1)
decimate()
does not work, while:
assumetff()
tfm(order=1,mode=0,slow=2,display=false)
Tdecimate()
does. I was not able to reproduce this using DGIndex + Decomb with your source and script.

[MrVideo]

I was not able to reproduce this using DGIndex + Decomb with your source and script.
Well, Decomb is a different filter as well. Plus, the last thing I want to do is decomb. The true 23.976 frame rate is ultimately desired. No idea why the
telecide(guide=1)
decimate()
combination with this source is having issues. The combo works just fine with 1080i MPEG-2 sources.

[poisondeathray]

Well, Decomb is a different filter as well. Plus, the last thing I want to do is decomb.

telecide() and decimate() are from decomb.dll

Check your version - Maybe you are using some older version ?

[MrVideo]

telecide() and decimate() are from decomb.dll
While that is indeed true, the point was that I do not want to use the decomb filter.
Check your version - Maybe you are using some older version?
I was under the impression that what I have is the latest that will work under XP. But, I will go check to make sure.

[StainlessS]

the point was that I do not want to use the decomb filter.

Au contraire, seems like you do want to use the Decomb.dll [it does not have a Decomb filter].


telecide(guide=1)
decimate()




Decomb_ORDERED_Function_List


There follows a list of all function names together with CPP style argument specifiers that inform
Avisynth the argument types and optional names. Optional arguments have square brackets surrounding
their name as in [name] and are followed by a type specifier character that gives the type.
Unnamed arguments are not optional. eg "cc[arg1]b[arg2]i" would be two compulsory unnamed clip args,
followed by optional 'arg1' of type bool and optional 'arg2' of type int.

# Argument type specifier strings.
c - Video Clip
i - Integer number
f - Float number
s - String
b - boolean
. - Any type (dot)
# Array Specifiers
i* - Integer Array, zero or more
i+ - Integer Array, one or more
.* - Any type Array, zero or more
.+ - Any type Array, one or more
# Etc
###################################


Decimate "c[cycle]i[mode]i[threshold]f[threshold2]f[quality]i[ovr]s[show]b[debug]b"
FieldDeinterlace "c[full]b[threshold]i[dthreshold]i[map]b[blend]b[chroma]b[ovr]s[show]b[debug]b"
IsCombed "c[threshold]i"
Telecide "c[back]i[guide]i[gthresh]f[post]i[chroma]b[vthresh]f[bthresh]f[dthresh]f[blend]b[nt]i[y0]i[y1]i[hints]b[ovr]s[show]b[debug]b"

[MrVideo]

Au contraire, seems like you do want to use the Decomb.dll [it does not have a Decomb filter].
The problem with some of the above replies, is the lack of specifics. I misunderstood the use of decomb as being a filter, instead of the library. It was because of the use of the decode library's two filters that I ran into trouble, thereby using another party's tfm() and TDecimate() filters.

As suggested above, I've downloaded the decomb.dll 5.2.4 version. I have another encode going at the moment, so I can't test to see if the problem has been fixed.

UPDATE: I updated the decomb.dll on the Win7 box and ran a test there. The newest version now works. No idea why I thought it couldn't be updated. Maybe it was the DGindexNV that I can't update.