How to serve H.264/4:2:2 video when use of DGDecodeNV not possible

[poisondeathray]

Looks great. I see nothing wrong with the interlaced output.

Are you using ffmpeg with libx264, or x264.exe ?

I would check again - unless you're using some sort of special build, or other processing, there will be chroma artifacts and ghosting if you let x264 do the conversion. The interlaced 4:2:2 => 4:2:0 downsampling is done in progressive manner

ffmpeg can do it properly if you specify interlaced scaling

It's analogous to avisynth, when using ConvertToYV12(interlaced=true) vs. ConvertToYV12(interlaced=false) . In the former case it's clean, proper interlaced 422=>420 conversion. In the latter you will get chroma artifacts.

[MrVideo]

Are you using ffmpeg with libx264, or x264.exe?
x264: core: 148 r2762 90a61ec
In the latter you will get chroma artifacts.

Here are three image grabs via VideoReDo:
image 1 (http://vidiot.com/images/S020A-O10-FLA-110-00.jpg)
image 2 (http://vidiot.com/images/S020A-O10-FLA-110-01.jpg)
image 3 (http://vidiot.com/images/S020A-O10-FLA-110-02.jpg)

Here are two videos:
interlaced (http://vidiot.com/video/S020A-O10-FLA-110.ts)
IVTC (progressive) (http://vidiot.com/video/S020A-O10-FLA-110.mkv)

If there are issues with the video, I sure do not see it.

[poisondeathray]

When you IVTC, it becomes progressive.

When you downsample 4:2:2 to 4:2:0 , it's already progressive

The problem is when it's interlaced, and you keep it interlaced (non film content), and try to convert 4:2:2 to 4:2:0 with x264

Hence:
Only if it's progressive.

It won't perform interlaced downsample correctly

[MrVideo]

When you IVTC, it becomes progressive.
I know that.
When you downsample 4:2:2 to 4:2:0 , it's already progressive
Not in this case.
The problem is when it's interlaced, and you keep it interlaced (non film content), and try to convert 4:2:2 to 4:2:0 with x264
Just because it is interlaced does not mean that it doesn't contain 23.976 source material that is 2:3 pulldown to interlaced 29.97, as is this material.

Did you even look at what I supplied?

The interlaced video is the result of the interlaced 4:2:2 being run through x264 and kept interlaced at 4:2:0. The IVTC video is the result of the interlaced 4:2:0 video being frame served via AVISynth and IVTC'd to 23.976p. The idea of the IVTC video is to show that the AVS script that does IVTC with interlaced video worked with the x264 4:2:2 to 4:2:0 video, i.e., it wasn't progressive. The VideoReDo program declared the 4:2:0 video as interlaced (MBAFF).

Everything is working as I expect it.

[poisondeathray]

Did you even look at what I supplied?

Maybe you should look a bit more closely.

Did you see the chroma artifacts ? Want me to post screenshots or do you want to look again first ?




Everything is working as I expect it.

Nope... It's exactly as I described - interlaced chroma artifacts

Either look at the fields or IVTC the transport stream sample

[MrVideo]

Did you see the chroma artifacts? Want me to post screenshots or do you want to look again first?
Nope. I did not see any artifacts. Post.
Either look at the fields or IVTC the transport stream sample
I have no means to view individual fields. Only frames of the two fields. As stated, the IVTC video is sourced from the interlaced posting.

[poisondeathray]

Really ? Seriously ?

Look especially at "reds". Like red apples, red titles etc...

It might be because of the low bitrate hiding some artifacts, but you can see them in the MKV as well.

Take the interlaced sample and IVTC as you normally would and step in avspmod or vdub

It's blatantly obvious, but I'll post some screenshots if you want

[poisondeathray]

The interlaced video is the result of the interlaced 4:2:2 being run through x264 and kept interlaced at 4:2:0. The IVTC video is the result of the interlaced 4:2:0 video being frame served via AVISynth and IVTC'd to 23.976p. The idea of the IVTC video is to show that the AVS script that does IVTC with interlaced video worked with the x264 4:2:2 to 4:2:0 video, i.e., it wasn't progressive.

The problem with your progressive 422=>420 downsample produces interlaced chroma errors that translate in to that progressive IVTCed video

If you take the original, and do it properly, those artifacts won't appear

https://www.mediafire.com/file/o12n6b3j1xa36bj/interlaced_chroma_artifacts.zip

Here is a package of screenshots. The botched 420 interlaced video in the transport stream is IVTCed, then a screenshot. Notice the horizontal interlaced combing arifacts.(This used progressive RGB conversion for the screenshot in avspmod, because it had been IVTCed). If you compare the same shot in the MKV, the artifacts are there too, but slightly obscured from the re-encoding and lowish bitrate. Go frame by frame in avspmod or vdub

when you have progressive content, arranged as fields (i.e. hard telecine, encoded interlaced) you still have to treat it as interlaced. This includes chroma up/down sampling, colorspace conversions (interlaced=true, not interlaced=false)

But if you IVTC, then it's progressive. Then you treat everything as progressive (ie. ConvertToRGB, or YV12 etc.. would use interlaced=false, not interlaced=true).

When you use the wrong conversion, bad things happen

[MrVideo]

The problem with your progressive 422=>420 downsample produces interlaced chroma errors that translate in to that progressive IVTCed video
The original 4:2:2 video, from the CW network sat feed, is interlaced. It is not progressive. Mediainfo even verifies that it is interlaced. It is meant for broadcast, so it is interlaced.
If you take the original, and do it properly, those artifacts won't appear
And just what is properly? Why can't x264 deal with interlaced 4:2:2 video?

I'm trying to do this as a 2-pass project.

Here are three images that are from the TS video, as captured via VideoReDo and saved as JPG from the BMP source in Photoshop:

image 1 (http://vidiot.com/images/S020A-O10-FLA-110-1.jpg)
image 2 (http://vidiot.com/images/S020A-O10-FLA-110-2.jpg)
image 3 (http://vidiot.com/images/S020A-O10-FLA-110-3.jpg)

The samples are from an area that you captured. No idea why your images are different than mine.

But, I do see the problem with the IVTC MKV video when I blow up the image in Photoshop.

As a side note, while this video is 23.976 hard telecined to 29.97, there will be some times where the video will be pure 29.97 interlaced video, i.e., from a live video camera source (no not sports - I don't do sports :D ).

[poisondeathray]

The original 4:2:2 video, from the CW network sat feed, is interlaced. It is not progressive. Mediainfo even verifies that it is interlaced. It is meant for broadcast, so it is interlaced.


Yes, which is why you need to treat it as such. Even though the content is progressive, it's encoded as fields.



And just what is properly? Why can't x264 deal with interlaced 4:2:2 video?


Yes it can deal with it fine. interlaced 422 input To interlaced 422 output

BUT the conversion it uses for interlaced 422 => 420 uses progressive downsampling, hence the errors. There is no switch or option for interlaced chroma down/up sampling conversion, just like there aren't other switches for various matrices (metadata yes, but actual conversion no) . That type of manipulation has to be done in other programs like avisynth, ffmpeg, vapoursynth etc...

You can simulate what it does in avisynth. Take the interlaced 422 stream and use

ConvertToYV12(interlaced=false) vs. ConvertToYV12(interlaced=true)


The samples are from an area that you captured. No idea why your images are different than mine.

Probably videoredo isn't ivtc'ing and it's probably using different conversion to RGB (interlaced).

Here I specified the steps and conversions directly. So I know exactly is going on


But, I do see the problem with the IVTC MKV video when I blow up the image in Photoshop.


The lowish bitrate in the re-encode hides some of the artifacts but they are there. You shouldn't need to blow it up, but you might have to view it by frame (easy to miss in motion)

[MrVideo]

Yes, which is why you need to treat it as such. Even though the content is progressive, it's encoded as fields.
Ah, that explains it. I never describe interlaced video as progressive, no matter the source content.
That type of manipulation has to be done in other programs like avisynth, ffmpeg, vapoursynth etc...
I can't use AVIsynth because I can't use DGDecodeNV to do the frame serving. Hence the purpose of this thread.
You can simulate what it does in avisynth. Take the interlaced 422 stream and use

ConvertToYV12(interlaced=false) vs. ConvertToYV12(interlaced=true)
I wish I could, but I can't.
Probably videoredo isn't ivtc'ing and it's probably using different conversion to RGB (interlaced).
VRD doesn't do IVTC and I have it set to not deinterlace. The image captures were done from still frames, as I stepped through the video to get to those locations.
The lowish bitrate in the re-encode hides some of the artifacts but they are there. You shouldn't need to blow it up, but you might have to view it by frame (easy to miss in motion)
With VRD, the video is not full frame, so the artifacts get masked by the reduced size. But, as was seen, my captures were a little different anyway.

This is all going to be moot.

Please explain how to use AVISynth, and/or ffmpeg to handle the 422 source.

[poisondeathray]

You can use l-smash to open 4:2:2 AVC

If you're going to IVTC first, then you can just use ConvertToYV12() to convert to 4:2:0 , because interlaced=false by default, and after IVTCing, it will be progressive frames

If you're keeping it interlaced, or doing other operations while still interlaced, then use interlaced=true

e.g.

LWLibavVideoSource("422_Video.ts")




Be careful of how a "preview" is being done in programs. When you "see" something, it's being converted to RGB. It might use 601 or 709, or it might use interlaced or progressive "behind the scenes"

[MrVideo]

I am trying this on XP-64 system. The L-Smash 32bit DLL files were installed in the path shown in the AVS file.
LoadPlugin("C:\L-SMASH-Works\LSMASHSource.dll")
LWLibavVideoSource("CW-H264-promos-171004-422.h264")
ConvertToYV12(interlaced=true)
assumetff()
telecide(guide=1)
decimate()

When I run my script (Z-shell under cygwin), I get the following error:
avs [error]: LoadPlugin: unable to load "C:\L-SMASH-Works\LSMASHSource.dll", Module not found. Install missing library?
(e:\\CW-H264-promos-171004-422.avs, line 1)
x264 [error]: could not open input file `e:\\CW-H264-promos-171004-422.avs'
x264 pass 1 exited with error code 255.
I have no idea what module it can't find. I had this same crap of an issue with FRIM stuff. Never got it working.

[poisondeathray]

It might have problems with elementary video . Do you have video with container ?

https://www.dropbox.com/sh/3i81ttxf028m1eh/AAABkQn4Y5w1k-toVhYLasmwa?dl=0

is this 32bit avisynth ? If so, use LSMASHSource-AviSynth-plugin-r929-msvc-32bit

if 64bit avisynth use L-SMASH-Works-r929-20170224-64bit

[Groucho2004]

I get the following error:
avs [error]: LoadPlugin: unable to load "C:\L-SMASH-Works\LSMASHSource.dll", Module not found. Install missing library?
(e:\\CW-H264-promos-171004-422.avs, line 1)
x264 [error]: could not open input file `e:\\CW-H264-promos-171004-422.avs'
x264 pass 1 exited with error code 255.
I have no idea what module it can't find.
Most likely one of the MS runtime libraries. Run "AVSMeter -avsinfo" to find out which one. Or, just install the all in one package from ricktendo (http://repacks.net/forum/viewtopic.php?f=6&t=125).

[MrVideo]

Most likely one of the MS runtime libraries. Run "AVSMeter -avsinfo" to find out which one. Or, just install the all in one package from ricktendo (http://repacks.net/forum/viewtopic.php?f=6&t=125).
"AVSMeter -avsinfo" ultimately crashes. The old AVS Info tool doesn't see the plugin.

The plugin does get loaded automatically when I run the script, but ultimately fails. The problem of an entry point in KERNEL32 that doesn't exist in XP.

[Groucho2004]

The problem of an entry point in KERNEL32 that doesn't exist in XP.The newer LSmash versions are built without XP support. You have to use an older version or use ffms2 as I suggested in post #4 in this thread.

[Groucho2004]

"AVSMeter -avsinfo" ultimately crashes.Define "crashes". No error message?

[MrVideo]

It might have problems with elementary video . Do you have video with container?
Not the problem. Read on.
https://www.dropbox.com/sh/3i81ttxf028m1eh/AAABkQn4Y5w1k-toVhYLasmwa?dl=0
I did some searching and that is where I found the files.
is this 32bit avisynth ? If so, use LSMASHSource-AviSynth-plugin-r929-msvc-32bit
Lack of installation instructions in the distributed files caused me to install the "Works" DLLs. I thought "Source" meant the source files for personal compiling. Silly me.

Once I removed those files and installed the correct DLL in the AVISynth plugins directory, things wanted to start up. As noted in the previous post, doing this on XP-64 is not going to happen.

So, I have everything installed on the newer Win7-64 box. AVISynth is still the 32bit version. I had to copy over all of the plugins from the XP box, as there were none. I probably have a file somewhere in which I initially installed a core bunch of plugins. But, I've added to them since them, so it was easier to just copy what is I already have.

After removing the first line in my AVS script, it is off and running, doing an IVTC. The only thing I've found weird is that the fps is not 24000/1001, it is 359/15. When I was doing the previous stuff with x264 directly, it too wouldn't do 30000/1001. I think it was 359/12. I even added "--fps 30000/1001" to the set of x264 options, but it was ignored. Any idea why it is showing the wrong frame rate? I'm sure that when it is all said and done, programs like MediaInfo and VideoReDo will report 23.976.

As I write this, it has about 21 min left in the 2nd pass.

[MrVideo]

Define "crashes". No error message?
The program encountered an error GUI shows up. Looking at the report, it is complaining about KERNEL32.dll. So, I suspect an entry point that doesn't exist in XP-64.

Nothing showed in the the program's textual output. It just stops at the point the error occurs. Is there an older version that works under XP? If not, no big deal.

I like the older AVS Info Tool program. With that one you could select an external DLL and it would report all of its needs. I do not see how to do that with AVSMeter.

Oh wait. I just tried running it on Win7 with the -avsinfo flag (before I ran it against the script) and it too crashed. It had an error with KERNELBASE.dll. It died at the end of the "uncategorized / other" list. No idea what it was going to do next.

I just noticed that the program failed at the same point as it did under XP-64.

[MrVideo]

The newer LSmash versions are built without XP support. You have to use an older version or use ffms2 as I suggested in post #4 in this thread.
Since older versions are part of the distribution, do you know which version is the last one to have XP support? If not, I'll ask on the Doom-9 L-Smash thread.

[MrVideo]

For a moment there I thought the IVTC output had issues. There was one spot in a promo that was messed up. So, I went back and looked at the 422 source with VLC and sure enough, that is the way the promo got edited. If it was meant to be artistic, it looks awful.

I'm currently running a non-IVTC interlaced run to see its output.

Since I still have some of the 422 videos, I'll rerun them.

Thanks for all your help poisondeathray and Groucho2004.

[MrVideo]

I wish I would have delved into L-Smash earlier. It was suggest way back at the start of the thread, but unfortunately, short on details as to how to use it. But, all is good now.

[MrVideo]

There is a major issue with the IVTC encode. The frame rate is 23.93 fps, instead of 23.976 fps. The interlaced encode is just as bad: 29.92 fps.

So, my guess is that it can't figure out the frame rate. I then supplied my script with the TS file and now it is doing 30000/1001. I can live with that.

Baby steps. :D

UPDATE: The interlaced coding finished and there is an issue. The fields are shifted. Instead of F0a/F0b-F1a/F1b. it is F0b/F1a-F1b/F2a.

I looked at the bad frame in Photoshop and it is worse than that:

Bad Frame (http://vidiot.com/images/CW-H264-promos-171004-1.jpg)
Good Frame (http://vidiot.com/images/CW-H264-promos-171004-2.jpg)

Blow up the bad frame and you can see in a line where the good video is supposed to be, it is gray. The pattern, top down, is good field, black field, gray, black field (rinse and repeat).

UPDATE-2: The IVTC run looks great.

[MrVideo]

Looks like I am going to have some frame rate determination issues. BDRB ran into this issue with some of my files as well. For some reason a file is determined to be VFR. But all the files are from the same sat feed, yet whatever it is looking at to determine what it thinks the frame rate is, is giving it false information.

Would setting "fpsnum=30000" and "fpsden=1001" work?

Nope. I don't know if the parameters are space separated or comma separated. I tried both.

I tried using assumefps(29.97) after the converttoyv12. That seems to work.

But, the "avs [info]" line reports 29.97/125. That is incorrect.

So, I changed to assumefps(30000, 1001) and gives an info line of 24000/1001.

I do not understand why the 29.97 didn't work.

[Groucho2004]

So, I changed to assumefps(30000, 1001) and gives and info line of 24000/1001.How exactly do you determine the output frame rate (which program do you use to load the script)? Can you post the full script?

[MrVideo]

How exactly do you determine the output frame rate (which program do you use to load the script)? Can you post the full script?
x264 calls the script.
LWLibavVideoSource("E:\\CW-H264-promos-170823-422.ts")
ConvertToYV12(interlaced=true)
AssumeFPS(30000, 1001)
assumetff()
telecide(guide=1)
decimate()
The incoming frame rate is supposed to be 29.97fps. Most of the time it is autodetermined correctly. But, in the case of this file (and others I know it will get wrong), it got it wrong, thinking it was VFR.

And since it is being IVTC'd, the ultimate rate is 23.976fps.

While I head off to bed (up all night), I'm having a boat load of files being recoded (IVTC'd as well).

[Groucho2004]

Since older versions are part of the distribution, do you know which version is the last one to have XP support? If not, I'll ask on the Doom-9 L-Smash thread.
r783 from here (https://www.dropbox.com/sh/3i81ttxf028m1eh/AADHSoWk3xwfpTfNN3JnGMQ8a/Old?dl=0&lst=).

[Groucho2004]

Would setting "fpsnum=30000" and "fpsden=1001" work?

Nope. I don't know if the parameters are space separated or comma separated. I tried both.
This:
LWLibavVideoSource("E:\CW-H264-promos-170823-422.ts", fpsnum = 30000, fpsden = 1001)
should work.

[Groucho2004]

I like the older AVS Info Tool program. With that one you could select an external DLL and it would report all of its needs.Nope, no such feature in the AVS Info tool. You could select a different avisynth.dll but that's it.

If you want to list all info on plugins including dependencies you must run "AVSMeter -avsinfo -log". The created log file ("avsinfo_x86.txt" or "avsinfo_x64.txt") contains all available info.

[MrVideo]

Nope, no such feature in the AVS Info tool. You could select a different avisynth.dll but that's it.
Tools -> plugin info

[MrVideo]

r783 from here (https://www.dropbox.com/sh/3i81ttxf028m1eh/AADHSoWk3xwfpTfNN3JnGMQ8a/Old?dl=0&lst=).
Thanks, downloaded.

[Groucho2004]

Tools -> plugin infoThat dialog lists the plugins in the auto-load directory and info about them. I assume that you mean these plugins when you write "select an external DLL".

[MrVideo]

That dialog lists the plugins in the auto-load directory and info about them. I assume that you mean these plugins when you write "select an external DLL".
You are right. I mis-wrote.

[MrVideo]

r783 from here (https://www.dropbox.com/sh/3i81ttxf028m1eh/AADHSoWk3xwfpTfNN3JnGMQ8a/Old?dl=0&lst=).
OK, got it installed, but it is complaining about not finding MSVCR120.dll, which is in c:\windows\system32.

[Groucho2004]

OK, got it installed, but it is complaining about not finding MSVCR120.dll
https://forum.doom9.org/showthread.php?p=1820754#post1820754

[MrVideo]

I'm confused. How is that going to help? I already have the Visual C++ redistribution package installed.

[Groucho2004]

I'm confused. How is that going to help? I already have the Visual C++ redistribution package installed.If you had it installed, you would not get that error message.

[MrVideo]

But, it is installed. I got the x86 and x64 packages from M$ site. I installed them. I'm sure it was already installed, as the x86 installer asked if I wanted to repair or remove. And, as I've stated, the MSVCR120.dll is in c:\windows\system32. What more can I do than that?

When I put the Win7 box together, I had installed the package on that system as well. The MSVCR120.dll is in the same location and I get no complaints on that box.

EDIT: Oh, and I can't run AVSMeter on the XP system, as it crashes because of a kernel32.dll error.

[Groucho2004]

And, as I've stated, the MSVCR120.dll is in c:\windows\system32.So, you're using 64 bit Avisynth? Or are you running a 32 bit OS? Now you have me confused.

AVSMeter crashing probably means that something is screwed with your Avisynth install. So, in order to fix all this properly I suggest the following:

Uninstall/clean everything related to Avisynth (make a copy of the plugins you need before you do that):
- Delete "C:\Program Files (x86)\AviSynth" and subdirs (just an example, your path to Avisynth may differ)
- Delete these registry keys:
"HKEY_CURRENT_USER\Software\Avisynth"
"HKEY_LOCAL_MACHINE\SOFTWARE\Avisynth"
"HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\Avisynth" (only on 64 bit OS)

Install Avisynth

Install the correct MS runtimes.

[MrVideo]

So, you're using 64 bit Avisynth? Or are you running a 32 bit OS? Now you have me confused.
No, I'm using the 32bit AVISynth, 2.6.0.5, installed in the Program Files (x86) location. It is XP-64.
AVSMeter crashing probably means that something is screwed with your Avisynth install. So, in order to fix all this properly I suggest the following:
AVIsynth has been running flawlessly. I'm guessing that AVSMeter is compiled without XP support, so it croaks when trying to access a procedure in kernel32.dll. It gets through listing the details of the avisynth.dll and lists all of the plugins. Then it croaks.

Whenever I see a kernel32.dll error, it has always been because the program no longer works with XP.

It is version 2.6.5. Did you compile it with XP support?
Install the correct MS runtimes.
And just what do you consider "correct M$ runtimes?"

EDIT: I ran "AVSMeter script.avs -log" on one of my AVS scripts that IVTC/encodes an H.264/4:2:0 29.97 stream. AVSMeter runs it just fine. The ESC keys doesn't stop it. I had to do a Ctrl-C. No idea where the log was placed.

[Groucho2004]

No, I'm using the 32bit AVISynth, 2.6.0.5, installed in the Program Files (x86) location. It is XP-64.So, MSVCR120.dll has to be in SysWoW64.


AVIsynth has been running flawlessly. I'm guessing that AVSMeter is compiled without XP support, so it croaks when trying to access a procedure in kernel32.dll. It gets through listing the details of the avisynth.dll and lists all of the plugins. Then it croaks.Nope, AVSMeter runs on XP and above. The "croaking" is most likely a plugin in the wrong place or that won't run on XP.


And just what do you consider "correct M$ runtimes?"The ones with the correct bitness and version. For the third time, install the AIO package.

[MrVideo]

I forgot... AVSMeter croaks on my Win7-6 box as well, and that is a fresh install of AVISynth. The error reported is with KERNELBASE.dll.

AVSMeter64 complains that it can't find avisynth.dll, which makes sense as it is the 32 bit install.

[Groucho2004]

I forgot... AVSMeter croaks on my Win7-6 box as well, and that is a fresh install of AVISynth. The error reported is with KERNELBASE.dll.Remove all plugins and try again.

[MrVideo]

OK, I'll set them aside and put them back, one-by-one. The XP box is now busy doing a sat feed capture, so nothing else can be done on it.

[MrVideo]

OK, the following plugins were not like by Win7:
eedi3.dll
ffavisynth.avsi
ffavisynth.dll
RemoveGrainsSSE2.dll
RepairSSE2.dll
SimpleResize.dll
SSE2Tools.dll
yadddif.dll
I removed them from the XP box as well. The LSMASHSource.dll on the XP box is not liked. But, I haven't done anything else with the box, yet.

Here are the AVSMeter log files (plugin functions to end not included):
Log file created with: AVSMeter 2.6.5 (x86)

[OS/Hardware info]
Operating system: Windows XP (x64) Service Pack 2.0 (Build 3790)
CPU brand string: AMD Phenom(tm) II X4 965 Processor
CPU features: MMX, SSE, SSE2, SSE3, SSE4A, 3DNOW, 3DNOWEXT, MMXEXT, POPCNT


[Avisynth info]
VersionString: AviSynth 2.60, build:Jan 14 2015 [09:58:31]
VersionNumber: 2.60
File / Product version: 2.6.0.5 / 2.6.0.5
Interface Version: 6
Multi-threading support: No
Avisynth.dll location: C:\WINDOWS\SysWOW64\avisynth.dll
Avisynth.dll time stamp: 2015-01-13, 22:59:20 (UTC)
PluginDir2_5 (HKLM, x86): C:\Program Files (x86)\AviSynth 2.5\plugins


[CPP 2.5 / 32 Bit Plugins]
C:\Program Files (x86)\AviSynth 2.5\plugins\AddGrainC.dll [1.5.0.0]
C:\Program Files (x86)\AviSynth 2.5\plugins\ColorMatrix.dll [2.5.0.0]
C:\Program Files (x86)\AviSynth 2.5\plugins\Convolution3DYV12.dll [1.0.0.5]
C:\Program Files (x86)\AviSynth 2.5\plugins\Decomb.dll
C:\Program Files (x86)\AviSynth 2.5\plugins\dfttest.dll [1.8.0.0]
C:\Program Files (x86)\AviSynth 2.5\plugins\DGAVCDecode.dll [1.0.9.0]
C:\Program Files (x86)\AviSynth 2.5\plugins\DGDecode.dll [1.5.5.0]
C:\Program Files (x86)\AviSynth 2.5\plugins\EEDI2.dll [0.9.2.0]
C:\Program Files (x86)\AviSynth 2.5\plugins\FFT3DFilter.dll [2.1.1.0]
C:\Program Files (x86)\AviSynth 2.5\plugins\FluxSmooth.dll
C:\Program Files (x86)\AviSynth 2.5\plugins\LeakKernelDeint.dll [1.5.4.0]
C:\Program Files (x86)\AviSynth 2.5\plugins\mt_masktools-25.dll [2.0.48.0]
C:\Program Files (x86)\AviSynth 2.5\plugins\mvtools2.dll [2.5.11.2]
C:\Program Files (x86)\AviSynth 2.5\plugins\NicAudio.dll
C:\Program Files (x86)\AviSynth 2.5\plugins\nnedi.dll [1.3.0.0]
C:\Program Files (x86)\AviSynth 2.5\plugins\nnedi2.dll [1.6.0.0]
C:\Program Files (x86)\AviSynth 2.5\plugins\nnedi3.dll [0.9.4.0]
C:\Program Files (x86)\AviSynth 2.5\plugins\TCPDeliver.dll [1.0.0.6]
C:\Program Files (x86)\AviSynth 2.5\plugins\TDeint.dll [1.1.0.0]
C:\Program Files (x86)\AviSynth 2.5\plugins\TIVTC.dll [1.0.5.0]
C:\Program Files (x86)\AviSynth 2.5\plugins\TomsMoComp.dll [0.0.1.8]
C:\Program Files (x86)\AviSynth 2.5\plugins\UnDot.dll [0.0.1.1]
C:\Program Files (x86)\AviSynth 2.5\plugins\VerticalCleanerSSE2.dll
C:\Program Files (x86)\AviSynth 2.5\plugins\VSFilter.dll [1.0.1.5]

[CPP 2.6 / 32 Bit Plugins]
C:\Program Files (x86)\AviSynth 2.5\plugins\DirectShowSource.dll [2.6.0.2]

[Uncategorized / 32 Bit DLLs]
C:\Program Files (x86)\AviSynth 2.5\plugins\libavcodec.dll
Log file created with: AVSMeter 2.6.5 (x86)

[OS/Hardware info]
Operating system: Windows 7 (x64) Service Pack 1.0 (Build 7601)
CPU brand string: AMD Phenom(tm) II X4 955 Processor
CPU features: MMX, SSE, SSE2, SSE3, SSE4A, 3DNOW, 3DNOWEXT, MMXEXT, POPCNT


[Avisynth info]
VersionString: AviSynth 2.60, build:Mar 31 2015 [16:38:54]
VersionNumber: 2.60
File / Product version: 2.6.0.6 / 2.6.0.6
Interface Version: 6
Multi-threading support: No
Avisynth.dll location: C:\Windows\SysWOW64\avisynth.dll
Avisynth.dll time stamp: 2015-03-31, 06:40:58 (UTC)
PluginDir2_5 (HKLM, x86): C:\Program Files (x86)\AviSynth\plugins


[CPP 2.5 / 32 Bit Plugins]
C:\Program Files (x86)\AviSynth\plugins\AddGrainC.dll [1.5.0.0]
C:\Program Files (x86)\AviSynth\plugins\ColorMatrix.dll [2.5.0.0]
C:\Program Files (x86)\AviSynth\plugins\Convolution3DYV12.dll [1.0.0.5]
C:\Program Files (x86)\AviSynth\plugins\Decomb.dll
C:\Program Files (x86)\AviSynth\plugins\dfttest.dll [1.8.0.0]
C:\Program Files (x86)\AviSynth\plugins\DGAVCDecode.dll [1.0.9.0]
C:\Program Files (x86)\AviSynth\plugins\DGDecode.dll [1.5.5.0]
C:\Program Files (x86)\AviSynth\plugins\EEDI2.dll [0.9.2.0]
C:\Program Files (x86)\AviSynth\plugins\FFT3DFilter.dll [2.1.1.0]
C:\Program Files (x86)\AviSynth\plugins\FluxSmooth.dll
C:\Program Files (x86)\AviSynth\plugins\LeakKernelDeint.dll [1.5.4.0]
C:\Program Files (x86)\AviSynth\plugins\LSMASHSource.dll
C:\Program Files (x86)\AviSynth\plugins\mt_masktools-25.dll [2.0.48.0]
C:\Program Files (x86)\AviSynth\plugins\mvtools2.dll [2.5.11.2]
C:\Program Files (x86)\AviSynth\plugins\NicAudio.dll
C:\Program Files (x86)\AviSynth\plugins\nnedi.dll [1.3.0.0]
C:\Program Files (x86)\AviSynth\plugins\nnedi2.dll [1.6.0.0]
C:\Program Files (x86)\AviSynth\plugins\nnedi3.dll [0.9.4.0]
C:\Program Files (x86)\AviSynth\plugins\TCPDeliver.dll [1.0.0.6]
C:\Program Files (x86)\AviSynth\plugins\TDeint.dll [1.1.0.0]
C:\Program Files (x86)\AviSynth\plugins\TIVTC.dll [1.0.5.0]
C:\Program Files (x86)\AviSynth\plugins\TomsMoComp.dll [0.0.1.8]
C:\Program Files (x86)\AviSynth\plugins\UnDot.dll [0.0.1.1]
C:\Program Files (x86)\AviSynth\plugins\VerticalCleanerSSE2.dll
C:\Program Files (x86)\AviSynth\plugins\VSFilter.dll [1.0.1.5]

[CPP 2.6 / 32 Bit Plugins]
C:\Program Files (x86)\AviSynth\plugins\DirectShowSource.dll [2.6.0.2]

[Scripts / AVSI]
C:\Program Files (x86)\AviSynth\plugins\Pantarheon3D.avsi
C:\Program Files (x86)\AviSynth\plugins\QTGMC.avsi

[Uncategorized / 32 Bit DLLs]
C:\Program Files (x86)\AviSynth\plugins\libavcodec.dll

[Uncategorized / Other]
C:\Program Files (x86)\AviSynth\plugins\tdeint.htm
I do not know why this is the case: C:\Windows\SysWOW64\avisynth.dll

When I try and run AVSMeter64, it says that it can't find the avisynth.dll.

Everything works on the Win7 box. There are still some issues there though. One is the interlace encoding is coming out wrong (see post above). Some of the H.264/422 files are causing x264 to error out with code 139, whatever that is.

[Groucho2004]

I do not know why this is the case: C:\Windows\SysWOW64\avisynth.dllNot sure what you mean, this is the correct location for 32 bit avisynth.dll.

When I try and run AVSMeter64, it says that it can't find the avisynth.dll.Makes sense since you don't have 64 bit Avisynth installed.

[MrVideo]

Where would the 64 bit version go?

[Groucho2004]

Where would the 64 bit version go?System32

Edit: Here's (http://www.samlogic.net/articles/32-64-bit-windows-folder-x86-syswow64.htm) an article about directory naming conventions on 64 bit Windows.

[MrVideo]

Thanks for the article. I was fooled with the SysWoW64 name. I haven't been running 64 bit M$ for that long. 64 bit on Unix/Linux, a whole different story. :D