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

[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.