QTGMC only works if I use ConvertToYV12 on my 1080i HDTV recorded files, why?

Hey guys, Ive recorded some 1080i stuff on the TV. The files are AVC in .TS containers. I want to deinterlace it with QTGMC and endcode at 720p. Problem is- I get an error message when QTGMCing it "interleaved2planar... error". If I use "ConvertToYV12", then QTGMC works without any trouble. Do you know why it is the case?, here is Mediainfo of the source files: Code:

DirectShowSource is the culprit. Your source already is YV12 (4:2:0), correct, but DirectShowSource seems to convert it to something else (probably YUY2), and therefore you need to convert to YV12 yet again for QTGMC. Don't use DirectShowSource.

The reason I suggested remuxing as an MKV first is I've found ffms2 to be pretty reliable with MKVs, but a little less so with TS files. Generally the worst that might happen is ffms2 will output the frame rate as 50fps (because it's interlaced) which can usually be fixed by telling it the correct frame rate to use. ie: FFVideoSource("E:\video.mkv", cachefile="D:\test.mkv.ffindex", fpsnum=25, fpsden=1, threads=1) DirectShowSource is the least frame accurate method. It's usually okay when encoding from start to finish but with complicated filtering where frames mightn't be requested in order, it's probably best to avoid it. If you're using the latest "official" stable ffms2, which is getting a bit old, there's some more recent builds to be found in recent posts if you happen to have any problems. Or try . PS ffms2 requires the Haali Media Splitter for TS files.

I use threads=1 because on a couple of odd occasions I had problems without it (I think the source video was Divx one time). Anyway, it just sets the number of threads to be used for decoding and I'm not sure more threads would necessarily speed things up, given the CPU will also be pretty busy with filtering and encoding etc. I can't say I've compared speeds though. Depending on the decoder being used it mightn't have any effect anyway (if it doesn't support threaded decoding). Threads=0 means the same number of threads as you have CPU cores. The default is threads=-1 (minus one) which is the same as threads=0. Is that what you meant when you said it automatically selects threads=1? I never rule out using DirectShowSource if other methods fail with "problem" files. Sometimes (at least with ffdshow decoding) I've found it'll keep decoding when other methods fail, but I tend to only use it for simple "start to finish" encoding. For anything else I'd use DirectShowSource to decode to a lossless file and then re-encode from there. Oh..... and there' an issue with AVIs and ffms2 if you use it's frame rate conversion in a script. If you don't it's fine, but for some reason it tends to drop or duplicate frames now and then when it shouldn't and motion can be "jittery" in places (if a video is 25fps and you use fpsnum=25 and fpsden=1 in a script, in theory it should have no effect). I don't think it's been fixed but it only effects AVIs and I tend to go with "remuxing as MKV" for most file types before encoding anyway. I think using the frame rate conversion in each script is a good idea, maybe even more so for TV captures, because without it if there's any missing/null frames the video gets treated as variable frame rate and it can mess with the audio sync. If you add the frame rate conversion stuff to the script (ffms2 and L-Smash both have the same options) then the output should be the correct constant frame rate and frames will be duplicated as required to account for any "missing" frames. Just thought I'd mention it..... but if you have any audio sync problems or the output frame rate is slightly off, try using the frame rate conversion options. If the total frame count changes when you add the appropriate frame rate "conversion" to the script (ie fpsnum=25, fpsden=1 for 25fps video) then you probably need it.

qtgmc only support yuv420p

@hello_hello- well Deinterlacing is THE main PITA to be honest with you. Encoding progressive stuff is like 20x less work :) For example right now Im encoding a tv show (tv series) Ive captured from hdtv as well, but the source is not interlaced. Its 1080i source as well and Im just resizing it to 720p and my system encodes at 11.6 fps with crf18 and "very slow" x264 preset. The test file above, using "QTGMC preset=very slow" and exactly the same x264 preset, my system encodes with 1.72 fps. Thats 5-6x slower, just because of interlacing :sly: If it was about me, I would only allow progressive video and only square pixels and only 1 codec, beeing h264 high profile above 4.1... Would solve like 90% of all problems.

The trouble with QTGMC is eventually you may discover as a de-interlacer it also makes a pretty decent denoiser. Then you find you're running it in progressive mode a lot and using it almost every time you encode. There's days, if I encode without filtering I almost feel like it's a luxury..... and watching the encode progress along at 15fps or more seems a little un-real. The one advantage to running QTGMC in progressive mode is you can resize first, then add QTGMC to the script, unlike de-interlacing where you need to de-interlace first, then resize. For desnoising in progressive mode, I find the result rends to be a little more natural looking if you run QTGMC a little faster, although I tend to use QTGMC in combination with LSFMod more and more these days, which slows things down. QTGMC(InputType=1, Preset="Medium", EzDenoise=1) LSFMod() No filtering Before (resized to 720p, no filtering): QTGMC + LSFMod Anyway, check your CPU usage when running QTGMC. Changes are it won't be running very hard as QTGMC is a bottleneck. You can either go the multi-threaded AVIsynth route to speed it up, which is less stable, or do what I do and run more than one encode at a time. You'll still only encode at 1.72fps (or maybe a tad slower), but at least you'll be doing it twice. When encoding just one video I make a copy of the script, add Trim() to the each so each script is encoding half the video, then I run them together, When it's done, the encoded video can easily be appended with MKVMergeGUI (make sure to add --stitchable to x264 command line so you won't have any problems appending them).

Your second image nuked the detail on the rope that's hanging near 45 degrees. Film grain is not your enemy. :)

1. Noise is an inherent property of the film medium. Objectively speaking that's the most authentic representation of the original, and everything else is subjective. 2. Every processing of the material reduces quality, either by the filter or by the recompression (unless you want to go lossless). Sure you can remove the grain (and some details), SVP it to 60fps etc. but it's an old film and should look like an old film from the theater. Degraining removes that feeling. EDIT: Just look at these nice shots: Seeing noise like that means that you're looking at a high-quality video.

I tried, but I'm getting a "don't hotlink" message for each one.