Deinterlacing PAL footage stutters when frame rate doubled?

[juiceycow]

Hi team,

I'm having issues with my captured VHS PAL (720x576 (YUY2, HuffYUV, VDub 1.9.11)) footage stuttering when I deinterlace and double the frame rate to 50fps.

It looks similar to a wrong field order issue, where every second frame jumps backwards. It looks fine deinterlaced @ 25fps (either using SelectEven() or FPSDivisor=2 in the script) but bumping up to 50fps has issues.

I thought it was an issue with QTGMC, but I can recreate the issue in Vdub (on both the capture WinXP PC as well as Win10 PC) using deinterlace bob or yadif - double frame rate BFF). I can also recreate it in Hybrid.

In AviSynth+ I've tried changing the sources; FFmpegSource2, LibavVideoSource and AVISource but it still persists.

I'm just starting out, so my Avisynth+ script is pretty basic, based on this tutorial

SetFilterMTMode ("QTGMC", 2)
AVISource("01vdub1-9-11_PAL.avi", atrack=1)
#ConvertToYV12()
AssumeBFF()
QTGMC(preset="Slower", EdiThreads=2)
Prefetch(10)

Could it be an issue at the capture stage? (PAL VCR, DMR-ES15 passthrough, WinXP, AIW 9000).

I've read that HuffYUV is always TFF, but this seems to be BFF.

I've attached a raw sample of a capture.

[themaster1]

you have captured 720x480 (ntsc) and 25.000 fps, there is a mismatch here.... perhaps qtgmc think it's ntsc

[juiceycow]

Quote:

Originally Posted by themaster1

you have captured 720x480 (ntsc) and 25.000 fps, there is a mismatch here.... perhaps qtgmc think it's ntsc

Ah, whoops. I've fixed the attachment in the original post.

It's still an issue (I was working with a larger PAL capture all day yesterday trying to figure it out)

[hodgey]

There is something odd with the field ordering in the clip. Does this happen on all tapes or just this one?

Doing

assumetff()
separatefields()
interleave(selecteven(),selectodd().trim(2,0))
weave()

Fixes the ordering on most of the fields, but the running part in the middle is off still. I don't know what could cause half of the fields to be delayed by 2 fields though. Are you sure you are capturing a PAL tape with everything set to PAL? (The PAL Panasonic dvd-recorders can be switched between NTSC and PAL.) Does the weird field ordering happen if you run the output from the vcr straight to the capture card?

[juiceycow]

I've done some more tests and think I'm getting closer (If I don't go batty in the process)

I changed over to an NTSC JVC HR-S3500U VCR (no TBC) plugged directly into the PC via S-Video, and after an hour of getting green video on my caps I worked out it was macrovision on the tape so then I could move onto testing...

I think Ive narrowed it down to the Timing options in Vdub (adding extra frames?).
I had both 'drop frames when captured frames are too close together' and 'insert null frames when captured frames are too far apart'. Unchecking these and messing with Resync mode made it work ok.. BUT not always. Most of the time the issue persisted.
One test worked just by switching over to a different compression (from huff to lag)

I've attached a sample (HuffYUV) that had issues in the first few frames, but then came good.
The other sample is when I changed to Lagarith compression and it worked after the first few frames.

I'll add the ES-15 into the mix tomorrow and test the timing.

This thread could probably be moved into the capture section, as it looks like it's a cap issue.

[lordsmurf]

QTGMC is not perfect. Sometimes, regardless of settings, it jitters. I had a long post on VH were just the VHS clock jitter. jagabo wrote a script when I'd run Yadif on the clock (smooth now), and feather to QTGMC elsewhere. No perfect, but way better.

I sometimes give up, just 25fps and move on. The 50fps is just not worth the effort on some of those.

Some people instead that 50i>25p is "throwing away 50%" of data, but that's just not accurate. QTGMC has to transform fields to frames, and data is created, sometimes doubled. So yes, some motion data is tossed, but not 50%.

I don't know that we're talking the same issues here, but the overall general advice stands.

[juiceycow]

Just some more troubleshooting today.

I reinstalled WinXP on a fresh (SD) drive and threw in my AIW 128 Pro AGP card (swapping out the AIW Radeon 9000), reinstalled all new drivers from these forums (other than the main video drivers, which are on the AMD website legacy section).

... and it worked. No stuttering / extra frames etc So I'll put the issue down to a driver (capture? video? TBD) issue, so I can now experiment with the Radeon 9000 again.

Worst case I just stick with the AIW 126 Pro

-- merged --

Just a final note on this one.

I re-installed my AIW Radeon 9000 card along with fresh WinXP SP base install, but instead of my original convoluted driver installation , I just used the drivers from the AMD site from 2006.
ie Catalyst Software Suite 6.11 just the Display Driver and WDM drivers. (Catalyst Control Center failed - I don't need it anyway).
and DAO/MDAC package (Windows Media Encoder 9, DAO/MDAC.)

I dont use MMC, so I didnt bother messing with an install attempt.

No more stuttering issue!

Looking at some of my original test captures from a month ago, I have a feeling the original issue is something to do with the field order getting messed up somewhere in the capture eg video is playing BFF, but codec is capturing as TFF, then I'm trying to play / post process BFF. Just a theory

Just an aside; After solving the stutter, I thought I had introduced an audio sync problem ie 50fps YUV2 playback in vdub will drift out of sync pretty fast, but plays fine if I ConvertToYV12 (rather than keep it in YUV2) or keep it at 25fps. Turned out it's just vdub's playback. The video would save fine I have to read up on more colorspace stuff anyway.