Hello,
Just tried QTGMC and it produced artifacts like this
Issue and fix detailed below, generated using claude.
Environment: VapourBox 0.9.10, macOS (Apple Silicon), source: NTSC DVD rip (MakeMKV), MPEG-2 720×480, 29.97fps, bottom field first, yuv420p
Symptom:
Deinterlacing with QTGMC (Very Slow, field order correctly set to BFF, double rate) produces output where the main combing is fixed, but faint horizontal stripes remain in flat, saturated color areas (most visible in blues). Player-side deinterlacers (e.g. IINA) mask the stripes, confirming residual field structure in the file.
idet on the output confirms it's not clean:
Single frame detection: TFF: 943 BFF: 433 Progressive: 483
Multi frame detection: TFF: 1372 BFF: 321 Progressive: 305
Diagnosis:
From the app log, the decode pipeline is:
Decoder args: ["-i", <src>, "-map", "0:v:0", "-s", "720x480",
"-f", "rawvideo", "-pix_fmt", "yuv420p", ...]
ffmpeg pipes raw headerless yuv420p frames into VapourSynth, so the clip enters the script with no _FieldBased property. Field order reaches QTGMC only via the TFF parameter (log shows tff=Some(false), correct). But because the clip itself isn't marked field-based, the 4:2:0 chroma planes are handled with progressive siting, while the source's interlaced 4:2:0 stores chroma per-field. Result: cross-field chroma contamination → the horizontal striping (classic interlaced chroma upsampling error).
Verification:
I rebuilt the pipeline manually (bestsource → core.std.SetFieldBased(clip, 1) → vsdeinterlace.QTempGaussMC) on the same source. Output idet:
Single frame detection: TFF: 0 BFF: 1 Progressive: 1789 Undetermined: 1810
Multi frame detection: TFF: 0 BFF: 46 Progressive: 3554
Stripes gone. Same QTGMC, same source — the only functional difference is that the clip is declared field-based before processing.
Suggested fix:
In the generated script template, set core.std.SetFieldBased(clip, 1 or 2) (per the user's field-order setting) on the imported clip before the deinterlace stage — or switch source ingestion to a source filter (bestsource/ffms2) that preserves stream properties instead of the raw pipe.
Hello,
Just tried QTGMC and it produced artifacts like this
Issue and fix detailed below, generated using claude.
Environment: VapourBox 0.9.10, macOS (Apple Silicon), source: NTSC DVD rip (MakeMKV), MPEG-2 720×480, 29.97fps, bottom field first, yuv420p
Symptom:
Deinterlacing with QTGMC (Very Slow, field order correctly set to BFF, double rate) produces output where the main combing is fixed, but faint horizontal stripes remain in flat, saturated color areas (most visible in blues). Player-side deinterlacers (e.g. IINA) mask the stripes, confirming residual field structure in the file.
ideton the output confirms it's not clean:Diagnosis:
From the app log, the decode pipeline is:
ffmpeg pipes raw headerless yuv420p frames into VapourSynth, so the clip enters the script with no
_FieldBasedproperty. Field order reaches QTGMC only via theTFFparameter (log showstff=Some(false), correct). But because the clip itself isn't marked field-based, the 4:2:0 chroma planes are handled with progressive siting, while the source's interlaced 4:2:0 stores chroma per-field. Result: cross-field chroma contamination → the horizontal striping (classic interlaced chroma upsampling error).Verification:
I rebuilt the pipeline manually (bestsource →
core.std.SetFieldBased(clip, 1)→vsdeinterlace.QTempGaussMC) on the same source. Output idet:Stripes gone. Same QTGMC, same source — the only functional difference is that the clip is declared field-based before processing.
Suggested fix:
In the generated script template, set
core.std.SetFieldBased(clip, 1 or 2)(per the user's field-order setting) on the imported clip before the deinterlace stage — or switch source ingestion to a source filter (bestsource/ffms2) that preserves stream properties instead of the raw pipe.