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

[MrVideo]

The reason that I cannot use DGDecodeNV to serve the video to x264 is that my nVidia card does not support H.264/4:2:2 video (4:2:0 only).

Is there something else I can use to do the serving?

Here is an example with one of my AVS templates:
LoadPlugin("C:\Program Files (x86)\DGAVCDecNV\DGDecodeNV.dll")
dgsource("=DRIVE=\=FILENAME=")
assumetff()
telecide(guide=1)
decimate()
Yes, it is to IVTC the 1080i29.97 to 1080p23.976.

Any and all tips appreciated.

[sneaker_ger]

ffms2?

[MrVideo]

Going this web page (https://github.com/FFMS/ffms2) I find the following line:
This plugin is a part of the FFMS2 project and is available for download here;
Except there is no link. I think it is obtained from here: https://github.com/FFMS/ffms2/releases
If that is the case, then I think the file is: ffms2-2.23.1-msvc.7z
I have no idea where to drop the contents of the directory contained therein.
In the user manual (https://github.com/FFMS/ffms2/blob/master/doc/ffms2-avisynth.md) I find the following line:
Because of LAVF's demuxer, most raw streams (such as elementary h264 and other mpeg video streams)
will fail to work properly.
I do most of my work as H.264 elementary streams. But, if I have to feed it the TS file and ignoring the audio, so be it.

Once I have the plugin, the user manual gives no example as how to incorporate it into an AVS script, like the one I have above. That said, I am assuming that I would use FFVideoSource, as I will be ignoring the audio (that is handled differently).

Still playing with the info, but still confused.

UPDATE: D'Oh! Looks like the ftms2.dll is dropped into the AVSynth plugins directory.

[Groucho2004]

I recommend qyot27's ffms2 C-plugin (http://avisynth.nl/index.php/FFMS2#C_Plugin).

[StainlessS]

FFmpegSource: (ffms2)
https://forum.doom9.org/showthread.php?t=127037

LSmashSource: (LSMASHVideoSource)
https://forum.doom9.org/showthread.php?t=167435

Both in Avs Devs forum, seems devs dont think that they are of interest to users.

LSmash, has two video decoders,
LSMASHVideoSource for ISO

Function IsISOFileName(String s) {
s=RT_GetFileExtension(s) Return(s==".mov"||s==".mp4"||s==".3gp"||s==".3g2"||s==".mj2"||s==".dvb"||s==".dcf"||s==".m21")}


Otherwise use LWLibavVideoSource.

[MrVideo]

I recommend qyot27's ffms2 C-plugin (http://avisynth.nl/index.php/FFMS2#C_Plugin).
Any particular reason?

EDIT: I see that his requires AVISynth 2.6.0 (or later). Does the github 2.23.1 do so as well?

I have a version of 2.6.0, but haven't installed it. I'm running XP-64 (yes it is old, but works for what I need).

[Groucho2004]

Any particular reason?

EDIT: I see that his requires AVISynth 2.6.0 (or later). Does the github 2.23.1 do so as well?

I have a version of 2.6.0, but haven't installed it. I'm running XP-64 (yes it is old, but works for what I need).
I have not tried all variations of ffms2/lsmash but this one just works (also on XP32/64, the latest ffms/lsmash will not work on XP).

If you don't have Avisynth(+) 2.6 installed you should really do so.

[Sharc]

If you don't have Avisynth(+) 2.6 installed you should really do so.
Note for MrVideo: BD-RB does not (yet) support AVS+.

[MrVideo]

I have not tried all variations of ffms2/lsmash but this one just works (also on XP32/64, the latest ffms/lsmash will not work on XP).
Then that is a good reason to use his.
If you don't have Avisynth(+) 2.6 installed you should really do so.
As noted above, I can't, because I use BDRB.

While I have a Win7 box (recently brought up), the XP64 box is only meant for x264 recoding and BDRB authoring use.

[feisty2]

I have not tried all variations of ffms2/lsmash but this one just works (also on XP32/64, the latest ffms/lsmash will not work on XP).

If you don't have Avisynth(+) 2.6 installed you should really do so.

Except no one else cares about xp support.
"I don't wanna upgrade to win10 for various reasons."
"Switch to Linux" - Good
"Xp till death" - Bad

[Sharc]

Then that is a good reason to use his.

As noted above, I can't, because I use BDRB.

You can upgrade from Avisynth 2.5.8 to Avisynth 2.6.0, but not to AVS+ for BD-RB.

[MrVideo]

You can upgrade from Avisynth 2.5.8 to Avisynth 2.6.0, but not to AVS+ for BD-RB.
I will be upgrading to 2.6.0.

[MrVideo]

Except no one else cares about xp support.
There are still many who do.
"I don't wanna upgrade to win10 for various reasons."
It is really evil. The stranglehold it puts on users is horrible. The crap I had to go thru to get Win7 running so that I, as the only user, could actually use the box.
"Switch to Linux" - Good
I run a Fedora 25 server. Unfortunately, no one ports any of the programs I need to use on Linux (Adobe, AVISynth, BDRB, VideoReDo and many others).
"Xp till death" - Bad
But, it continues to work for what I need.

On all three of my XP/Win7 boxes, I have cygwin installed so that can do lots of stuff. I have scripts that do my AVISynth jobs. No GUI required.

[Groucho2004]

When I wrote "Avisynth(+)" I meant either Avisynth 2.60 (classic) or AVS+ (which is also v2.60).

If you want some flexibility or want to try out other Avisynth versions you could give this (https://forum.doom9.org/showthread.php?t=172124) a try.

[Groucho2004]

Except no one else cares about xp support.Funny that all Avisynth versions and ~99% of plugins work fine on XP.

[feisty2]

it's not a stranglehold, no one said "you HAVE TO upgrade to win10", sure you have every right to avoid win10 if that's what you want.
BUT, if you're gonna do that, you just have to plan for something else, obsolete software is simply toxic, especially ancient antique like xp, it's been 16 years since the initial release of xp...
generally, you would update that antique to the latest version of the same thing (that is, win10), but you find win10 is somehow not what you want, then, you should really pick something else, maybe Linux, or OSX, whatever you like.
xp should die cuz it also fails to work with modern hardware (at least it couldn't release the full potential of the modern hardware, you have no AVX, FMA and stuff with xp).
it might work for what you need, FOR NOW, but it works with lower efficiency, and that's very harmful.
xp is an obsolete program, not your soulmate, it would be extra easy to get rid of if only you could just let go

[feisty2]

Funny that all Avisynth versions and ~99% of plugins work fine on XP.

that's because country bumpkins like you demanded it

[Groucho2004]

that's because country bumpkins like you demanded itWho are you and what have you done to feisty2? He would never spell the word "because" in this obsolete manner.

[feisty2]

Who are you and what have you done to feisty2? He would never spell the word "because" in this obsolete manner.

Save your sarcasm for your xp sinking ship, maybe one day the gravity on earth suddenly disappears and the hardware manufacturers choose to again, support xp

[Groucho2004]

Save your sarcasm for your xp sinking ship, maybe one day the gravity on earth suddenly disappears and the hardware manufacturers choose to again, support xp
I'm curious about why you get so rowled up about people who still use XP. Is it the brain-washing by M$ and its minions? Why do you even care?

[MrVideo]

When I wrote "Avisynth(+)" I meant either Avisynth 2.60 (classic) or AVS+ (which is also v2.60).
Ah, gotchya.
If you want some flexibility or want to try out other Avisynth versions you could give this (https://forum.doom9.org/showthread.php?t=172124) a try.
Very interesting. I've downloaded it. Don't know if I'll play with it yet.

Does the bat file contain a reference URL to your thread? Even if it is just a comment.

[feisty2]

I'm curious about why you get so rowled up about people who still use XP. Is it the brain-washing by M$ and its minions? Why do you even care?

I don't give a damn about ms.
My hate for xp has nothing to do with ms and if ms goes bankrupt now, I would still hate xp, simply because it's OBSOLETE
I hate anything obsolete, so it's not just xp exclusively

[MrVideo]

I'm curious about why you get so rowled up about people who still use XP. Is it the brain-washing by M$ and its minions? Why do you even care?
Maybe he wants to get his licks in before the big one that results in SF and LA sliding into the ocean. :D

[MrVideo]

I hate anything obsolete, so it's not just xp exclusively
Does that mean you buy a new phone as soon as the model you have becomes obsolete by the newer version? Must be nice to have to funds to do that with every new phone model.

Oh, and there are still owners of Model-T fords. Do you hate those cars too?

[Groucho2004]

Does the bat file contain a reference URL to your thread? Even if it is just a comment.No, I'll add it in the next version.

[feisty2]

Does that mean you buy a new phone as soon as the model you have becomes obsolete by the newer version? Must be nice to have to funds to do that with every new phone model.

Oh, and there are still owners of Model-T fords. Do you hate those cars too?

And that's totally different
A new cellphone costs you money and a new copy of software sometimes costs you nothing (win10 is free, linux is free...)

[MrVideo]

And that's totally different
A new cellphone costs you money and a new copy of software sometimes costs you nothing (win10 is free, linux is free...)
In theory XP, Vista (Yuck!), Win7, Win8/8.1, all supposedly cost money. So, your argument doesn't hold water. Like a new phone, a newer version of M$ OS software is supposed to cost money.

Some of the software I'm running on XP, I can't even get updated for Win7. It isn't just the OS that costs, many a time you have to buy a newer version of a program to use on that newer OS (usually at a discount, but still).

Just because you don't like a lot of obsolete stuff, doesn't that everyone else has to as well.

[feisty2]

And model-T fords are now meant to be some kind of antique collection, not something you would actually drive on the street,,,
Same goes for xp, using xp for your daily work is kind of similar to driving model-T on the street, which is simply not appropriate

[Sharc]

And that's totally different
A new cellphone costs you money and a new copy of software sometimes costs you nothing (win10 is free, linux is free...)
Well well.... with Win10 users supply them via the default telemetering a lot of information free of charge how they use their PC etc.

[MrVideo]

And model-T fords are now meant to be some kind of antique collection, not something you would actually drive on the street,,,
Funny, I've seen model T being driven on the street.
Same goes for xp, using xp for your daily work is kind of similar to driving model-T on the street, which is simply not appropriate
My main daily work is done on my Linux server, like using a browser. Downloading files. The XP/Win7 boxes have specific functions.

[feisty2]

Funny, I've seen model T being driven on the street.

My main daily work is done on my Linux server, like using a browser. Downloading files. The XP/Win7 boxes have specific functions.

I've seen people cheating during the tests, does it mean that cheating is appropriate?

[Groucho2004]

Same goes for xp, using xp for your daily work is kind of similar to driving model-T on the street, which is simply not appropriateIn my day job I have to use XP because some of the software I need does only run on NT4/W2K/XP/Server2003. Appropriate or not, that's how it is. You clearly have no clue of what's going on in some professional environments.

Also, the BS about security is just M$ spreading FUD. I have a box with XPSP1 and a properly configured Outpost firewall which has never caught any worm/virus. The problem is almost always an idiot user who clicks on an email attachment or a web dialog that will install nasty crap.

[manolito]

To get back on topic, a good alternative to ffms2 (like Groucho I also prefer the C-Plugin version by quot27) is DSS2Mod by forclip.

It is based on Haali's DSS2, but much better... Just place the correct DLL in your AviSynth\Plugins folder (there are separate DLLs for AVS 2.5 and 2.6) and call it like this:

DSS2("My File", fps={source fps}, Preroll=15)

It is DirectShow based (I know a lot of people will cringe when they hear this), but with the exposed Preroll parameter it does a much better job when seeking. It only handles video, it always uses the "Convertfps=true" parameter, i.e. it always converts VFR to CFR. In my experiece it gives ffms2 a run for the money...


Cheers
manolito

[manolito]

Also, the BS about security is just M$ spreading FUD. I have a box with XPSP1 and a properly configured Outpost firewall which has never caught any worm/virus. The problem is almost always an idiot user who clicks on an email attachment or a web dialog that will install nasty crap.

Totally agreed, my experience with XP is the same. I do run XP and Win7 in parallel, I never caught any malware under both OS, I even got rid of my AntiVirus software and just use the good old (and of course obsolete) ThreatFire (a behavioral scanner, no AV signatures, very light on resources).

For idiot user definition I would add that such users never back up their computers. And when disaster strikes they call folks like me to help them. And a few months later I find that they still make no backups...


Cheers
manolito

[feisty2]

To get back on topic, a good alternative to ffms2 (like Groucho I also prefer the C-Plugin version by quot27) is DSS2Mod by forclip.

It is based on Haali's DSS2, but much better... Just place the correct DLL in your AviSynth\Plugins folder (there are separate DLLs for AVS 2.5 and 2.6) and call it like this:

DSS2("My File", fps={source fps}, Preroll=15)

It is DirectShow based (I know a lot of people will cringe when they hear this), but with the exposed Preroll parameter it does a much better job when seeking. It only handles video, it always uses the "Convertfps=true" parameter, i.e. it always converts VFR to CFR. In my experiece it gives ffms2 a run for the money...


Cheers
manolito

Is it frame accurate? (Dunno about DSS2, but DSS is not)

[manolito]

From the DSS2Mod readme:
7. Added "preroll" setting (int, default = 0, if < 0 rounded to 0). Since DirectShow seeking isn't frame-accurate (or time-accurate,
as there is no frames, only time), when we perform a seeking to calculated time position, in some cases we can "overseek" or "overjump"
requested position. Also with some decoders or files you may see alot of artifacts after seeking (has something to do with GOP and keyframes).
"preroll" - it's a number of frames that will be minused from the requested frame No. when calculating desired time position for seeking.
All "extra-frames" will be read frame-by-frame till we get what we want. Or in other words: we want frame No. 100 and preroll=10;
seeking will be performed, as if we need frame No. 90; frames from 90 (or where we will be after seeking, since it isn't accurate most of the time)
to 100 will be safely readed frame-by-frame. If after seeking you can see artifacts or frozen frames for some time - you may want to increase preroll
value to 10, 20,... or probably 100 and even more (for ts\m2ts files). Or repack your file to something more seekable. Or use DGDecNV.

For problematic files like H264 or H265 interlaced transport streams the Preroll param should be set to a value of 100 or higher. For "normal" sources I always get frame accurate seeking with Preroll set to 15.


Cheers
manolito

[MrVideo]

While my H.264/4:2:2 videos will be interlaced, I will not be seeking to any particular location. I will be recoding from the first frame through to the last. Depending on the source, I will be IVTCing it, or leaving it as interlaced.

[manolito]

Then I would suggest to give DSS2Mod a test run. It is faster than ffms2 because it does not index the source.

Frameserving the source in a linear mode is one thing. Another thing to keep in mind is when using temporal filters which request frames before and after the current frame. This must be considered as "seeking". MVTools for example is notorious for requesting out of order frames when doing its motion vector thing.


Cheers
manolito

[MrVideo]

Then I would suggest to give DSS2Mod a test run. It is faster than ffms2 because it does not index the source.
Indexing doesn't bother me. I've been doing it for years now with the DG tools. It only takes a few minutes, A drop in the bucket compared to the actual coding time.
Frameserving the source in a linear mode is one thing. Another thing to keep in mind is when using temporal filters which request frames before and after the current frame. This must be considered as "seeking". MVTools for example is notorious for requesting out of order frames when doing its motion vector thing.
I will be doing 2-pass recoding. The keeping it as 1080i would mean no seeking (I hope). The tools I'll be using to do the IVTC are as shown in the first posting. So, you are right, there is probably seeking involved there. I do not know.

[Sharc]

@MrVideo
By the way: Did you ever try to IMPORT your 4:2:2 source in BD-RB? Since version 0.50.23 it supports importing of certain 4:2:2 lossless video formats and converts it to 4:2:0 YV12 on the fly for further processing and encoding with x264.

[MrVideo]

By the way: Did you ever try to IMPORT your 4:2:2 source in BD-RB? Since version 0.50.23 it supports importing of certain 4:2:2 lossless video formats and converts it to 4:2:0 YV12 on the fly for further processing and encoding with x264.
It isn't lossless. It is H.264/4:2:2.

[Sharc]

It isn't lossless. It is H.264/4:2:2.
So can you IMPORT it in BD-RB or not?

[Groucho2004]

If you want some flexibility or want to try out other Avisynth versions you could give this (https://forum.doom9.org/showthread.php?t=172124) a try.
Very interesting. I've downloaded it. Don't know if I'll play with it yet.It's the easiest way to install/switch/uninstall Avisynth even for "GUI" people with very little knowledge of CLI/batch files.

[MrVideo]

So can you IMPORT it in BD-RB or not?
No idea at this point. Will check later. The point is that it isn't lossless, i.e., not one of the new supported formats.

[Sharc]

No idea at this point. Will check later. The point is that it isn't lossless, i.e., not one of the new supported formats.
If IMPORT with BD-RB fails you can open your H.264 4:2:2 in VirtualDub FilterMod (google for it) and convert it to a format of your convenience.

[MrVideo]

If IMPORT with BD-RB fails you can open your H.264 4:2:2 in VirtualDub FilterMod (google for it) and convert it to a format of your convenience.
I prefer to do all of this with my scripts and avoid dealing with a GUI. Same with using BDRB, i.e., a GUI.

By using my scripts, I just drop the files onto the computer, add them to the "doit" script, select the option template and let it run. I can do multiple files with no hand holding and do other things while the job is running.

[MrVideo]

So can you IMPORT it in BD-RB or not?
I finally got a chance to get back to this project.

Well, I'll be damned. I imported a TS file and it took it. It mangled the audio, but I don't care about that, as I'll be dealing with that separately.

I then clicked on BACKUP and it actually re-encoded it to 4:2:0. It did it as 1-pass though. I need to find the option to get it to do 2-pass encoding.

[MrVideo]

Problem has been solved. I've discovered that x264 can directly read in the h.264/4:2:2 video and recode it to h.264/4:2:0. :D

[poisondeathray]

Problem has been solved. I've discovered that x264 can directly read in the h.264/4:2:2 video and recode it to h.264/4:2:0. :D

Only if it's progressive.

It won't perform interlaced downsample correctly

[MrVideo]

Only if it's progressive.

It won't perform interlaced downsample correctly
Looks great. I see nothing wrong with the interlaced output.

[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

[MrVideo]

OK, here comes a massive update.

First off, those who keep telling me to ditch XP and move on, need to read this.

Win7: The big run of recoding H264/422 to H264/420, with IVTC, had problems. A bunch of videos ended up crashing LSMASHSource/x264. I got back a status code of 139, which was ultimately determined to be 128+11, i.e. a segmentation fault. The other issue, reported in an above post, is the out-of-order fields for an interlaced recode.

XP-64: Got LSMASHSource to be accepted by AVSMeter. Yes, I went thru the process of installing the AIO redistribution package, instead of the x86 version I downloaded from M$. I have no idea why that AIO kept installing different versions. All I care is that my script now works.

Here comes the part where I am not leaving XP-64 any time soon. As a test, I took one of the files that Win7 crashed with and ran it. I worked. The video was accepted and the IVTC coded result was as expected. I haven't tried the other ones yet. This means that the latest version of LSMASHSource has a problem. I'll have to report it on the LSMASH thread that I found and provide a sample for the author to work with.

There's more... the old XP version of LSMASH recoded to interlaced with correct field order. I ran two files through and they were both correct. So, two bugs to report with the latest LSMASH.

Lastly, "fpsnum = 30000" works, while "fpsnum=30000" does not. OK, I only tried the one with spaces around the = sign, so it might be another issue with the latest LSMASH. If "fpsnum=30000" works under XP, I'll report it as well. It is not unusual for authors to expect spaces surrounding = signs.

So, I am a happy camper because conversion of H264/422 -> H264/420 is working.

Thanks to all who responded and pushed me into getting this done right.

[Groucho2004]

Lastly, "fpsnum = 30000" works, while "fpsnum=30000" does not. OK, I only tried the one with spaces around the = sign, so it might be another issue with the latest LSMASH. If "fpsnum=30000" works under XP, I'll report it as well. It is not unusual for authors to expect spaces surrounding = signs.fpsnum/fpsden work fine (spaces or not) for me. However, you have to wrap your elementary stream in a container (mkv for example) otherwise strange things will happen.

[MrVideo]

fpsnum/fpsden work fine (spaces or not) for me. However, you have to wrap your elementary stream in a container (mkv for example) otherwise strange things will happen.
All of these runs have been done with the original TS files.

The no spaces did not work for me under Win7. The options were ignored.

[MrVideo]

So, I am a happy camper because conversion of H264/422 -> H264/420 is working.
I have to retract this a little bit. I just did a 1080i run on the XP-64 box and it screwed up just like it did under Win7-64.

I have no idea how to get 1080i 4:2:2 -> 1080i 4:2:0 to work correctly.

UPDATE: I just did another file and it too started out wrong. But, it seems that during the capture, the feed got glitched. The strange thing is that the output corrected itself after dealing with the glitch.

[Emulgator]

Regarding the field offset:
You may want to check if your script decoded under WinXP vs. Win7 delivers the same frame count.
Especially if frame 0 under WinXP equals frame 0 under Win7.
I also work under both OS for the same reason as you do and found that depending on Source filter the results do differ.
So if quartz.dll was involved, under one OS the source filter would never deliver source frame 0 to Avisynth,
instead deliver frame 1 and Avisynth would report that as first frame 0.
I just do not remember which, only remember that porting my scripts from WinXP to Win7 back then would deliver screwed cuts by 1 frame and some more hickups.
(decoding DV-AVI under DirectShow, IIRC).

[MrVideo]

You may want to check if your script decoded under WinXP vs. Win7 delivers the same frame count.
Especially if frame 0 under WinXP equals frame 0 under Win7.
I'm not sure how knowing that is going to help, since both XP and Win7 provide the same bad results.

I have no way of knowing if there are issues with frame delivery as I have no way to look at the video before running it thru the script. These videos all start with many seconds of black.

That said, I do have an H.264 video that is a 2:3 pulldown cadence check. I can run that thru the script, leaving out the conversion to YUV, to see it screws up with that video, or not.