Reinterlacing for tv - should it matter if it was previously deinterlaced?

[brassplyer]

Have some files that were originally VHS captures deinterlaced with Avisynth for cleanup, trimming and upload to Youtube. Now I'm reinterlacing with Avisynth with what I understand is a common script:


SetMemoryMax(1024)
FFMpegsource2("W:\Sourcefile.avi", atrack = -1)
Crop(6,4,-6,-2)
Lanczos4Resize(1440,1080)
AddBorders(240,0,240,0)
AssumeBFF().SeparateFields().SelectEvery(4, 0, 3).Weave()


The 60fps file it's made from - which is created by deinterlacing 29.97 NTSC video with QTGMC - looks fine both played locally on the machine and when uploaded to Youtube. However what I'm seeing when that 60fps file is reinterlaced, upconverted and played back on HDTV is that motion doesn't look clean. Not as screwed-up looking as if the fields were in the wrong order but the elements that move look smeared/blurred, not as clean as the original interlaced DVD source which was captured from VHS.

One of the files is a 30fps file downloaded from Youtube that's been converted to 60fps with the same script as above but with

convertfps(60)

added to the above script after the crop command.

Any theories as to why this would be? Do you see any issues with the order of the commands in the script that could make a difference?

If file samples are needed to answer let me know.

Thanks.

[poisondeathray]

In order to re-interlace for NTSC systems, you need to start with 59.94 CLEAN frames per second . ConvertFPS from 30 to 60 adds BLENDED frames (ie not clean)

The other options are ConvertFPS() which duplicates frames. The motion will still be 29.97, so it will look choppy compared to true 59.94 . And the other option is to use motion interpolation to generate inbetween frames to try to "guess" where the original frames were dropped (Eg. use mvtools2 derivatives). It can work ok on some content, some scenes, but serious artifacts on others

[brassplyer]

In order to re-interlace for NTSC systems, you need to start with 59.94 CLEAN frames per second . ConvertFPS from 30 to 60 adds BLENDED frames (ie not clean)

It's just the one file that's 30fps converted to 60. Most of the video is 29.97 interlaced that's deinterlaced to 60 progressive. Does that count as clean fps?

[poisondeathray]

In order to re-interlace for NTSC systems, you need to start with 59.94 CLEAN frames per second . ConvertFPS from 30 to 60 adds BLENDED frames (ie not clean)

It's just the one file that's 30fps converted to 60. Most of the video is 29.97 interlaced that's deinterlaced to 60 progressive. Does that count as clean fps?

Yes, the 60p sections should look fine, are you saying they do not?

Also, you should be using TFF for HD (All interlaced HD is TFF by convention, but SD can be BFF or TFF)

And you should be using exact framerates , not "60" or "30" which are lazy abbreviations . It should be 60000/1001 for "59.94" and 30000/1001 for "29.97"

Discrepancies in framerates can cause some applications to resample the frames , perhaps explaining some of the motion blending you are seeing

[brassplyer]

In order to re-interlace for NTSC systems, you need to start with 59.94 CLEAN frames per second . ConvertFPS from 30 to 60 adds BLENDED frames (ie not clean)

It's just the one file that's 30fps converted to 60. Most of the video is 29.97 interlaced that's deinterlaced to 60 progressive. Does that count as clean fps?

Yes, the 60p sections should look fine, are you saying they do not?

Right, there's a problem whether it was originally 30 fps converted to 60 or originally deinterlaced 60.

Also, you should be using TFF for HD (All interlaced HD is TFF by convention, but SD can be BFF or TFF)

Functionally should it make a difference? Does the player detect and play it either way? If I'm not mistaken when you shoot video with a consumer SD camcorder it records BFF.

And you should be using exact framerates , not "60" or "30" which are lazy abbreviations . It should be 60000/1001 for "59.94" and 30000/1001 for "29.97"

Discrepancies in framerates can cause some applications to resample the frames , perhaps explaining some of the motion blending you are seeing

Okay.

[JVRaines]

QTGMC does smoothing, interpolation and resharpening. Weaving the output won't give you back the interlaced source.

[poisondeathray]

Right, there's a problem whether it was originally 30 fps converted to 60 or originally deinterlaced 60.

Then it might be the framerate issue. For example, if you used a 60.0FPS video as input into a NLE intended for BD , most will resample the frames to the proper 60000/1001 (or 59.94 as an approximation) using frame blending.

If you had used ConvertFPS(60) on the "30p" section and joined it up with the other sections, that tells me the framerate in all the sections were wrong. Avisynth won't let you append a 60000/1001 section with a 60.0 section.

Also, you should be using TFF for HD (All interlaced HD is TFF by convention, but SD can be BFF or TFF)

Functionally should it make a difference? Does the player detect and play it either way? If I'm not mistaken when you shoot video with a consumer SD camcorder it records BFF.

It shouldn't make a difference, but how various hardware handles it might be problematic.

Consumer SD camcorders can be BFF or TFF (for example, some SD MPEG2 camcorders record TFF, but most DV is BFF) . But 99.999% of HD is TFF by convention. That's what BD or any interlaced HD playback hardware is expecting. Better safe than sorry.

[poisondeathray]

QTGMC does smoothing, interpolation and resharpening. Weaving the output won't give you back the interlaced source.

This is very true . But I was assuming from the description something worse , or at least the motion elements were worse than the "60p" QTGMC version on PC

[brassplyer]

I discovered one of the project files I was using that's *supposed* to be 29.97 interlaced is still 59.94. However one of the files that's a problem is 29.97 interlaced like it's supposed to be.

[brassplyer]

If you had used ConvertFPS(60) on the "30p" section and joined it up with the other sections, that tells me the framerate in all the sections were wrong. Avisynth won't let you append a 60000/1001 section with a 60.0 section.

Just did that one file by itself. Ends up the same framerate as the other files - 29.97 interlaced.

Also, you should be using TFF for HD (All interlaced HD is TFF by convention, but SD can be BFF or TFF)

Functionally should it make a difference? Does the player detect and play it either way? If I'm not mistaken when you shoot video with a consumer SD camcorder it records BFF.

It shouldn't make a difference, but how various hardware handles it might be problematic.

Consumer SD camcorders can be BFF or TFF (for example, some SD MPEG2 camcorders record TFF, but most DV is BFF) . But 99.999% of HD is TFF by convention. That's what BD or any interlaced HD playback hardware is expecting. Better safe than sorry.

Okay, sounds like a plan.

[brassplyer]

QTGMC does smoothing, interpolation and resharpening. Weaving the output won't give you back the interlaced source.

Would you expect the reinterlaced result to behave as I described in the OP? I.e. - not as good as the original interlaced material? Is it possible to make it as good?

[poisondeathray]

QTGMC does smoothing, interpolation and resharpening. Weaving the output won't give you back the interlaced source.

Would you expect the reinterlaced result to behave as I described in the OP? I.e. - not as good as the original interlaced material? Is it possible to make it as good?

Since the QTGMC version looked fine on the computer and youtube at "60p", then the reinterlaced version should look similar in terms of "elements that move having smearing or blurring" , assuming you encoded it correctly with adequate bitrate

Also describe what else you are doing. ie. how are you getting the final video ? What other steps have you omitted in describing

Upload a sample of the problem file

[brassplyer]

Also describe what else you are doing. ie. how are you getting the final video ? What other steps have you omitted in describing

Other than what I've already described, encoding the project to m2t file with Vegas Pro 9 25mbps constant, then authoring in DVD Architect Pro.

Upload a sample of the problem file

First I'm going to try some of the suggestions given here - making sure the rates are specified 29.97, TFF and see if it makes any difference. I'll upload samples if I'm still not getting the desired results.

[poisondeathray]

Or another option is (pillarboxed) 1280x720p59.94 . Which means you get "60p" on youtube, and it's a valid BD format. Higher quality at a given bitrate, more efficient encoding, no variability in deinterlacing quality (YOU control how it was deinterlaced with QTGMC, instead of relying on hardware - the quality which varies on different setups.) . You only need 1 version instead of multiple versions. I don't see any reason for re-interlacing since these are VHS sourced. Some would even argue to keep it interlaced SD blu-ray (but then you wouldn't get "60p" on youtube) .

[Skiller]

Would you expect the reinterlaced result to behave as I described in the OP? I.e. - not as good as the original interlaced material? Is it possible to make it as good?

OK, strictly technically speaking, to re-interlace one has to consider taking the original lines of the source and discarding the interpolated ones inbetween which were created during deinterlacing. You could also discard the original lines and keep only the interpolated ones for the re-interlaced video. But then whenever the video is deinterlaced again, the deinterlacing interpolates new lines inbetween already interpolated lines which is not good and makes the video more and more inaccurate because you are watching 0% of the original recorded lines and 100% interpolated ones.
So one should try to re-interlace so that the interpolated lines are discarded and the original ones are kept. That would make the deinterlacing in the middle a lossless process. Keeping the original lines is a matter of not changing the (original) field dominance and splicing the video only at even frames. So much for the theory.

In reality, when using QTGMC without Lossless=1 parameter, none of the resulting lines are actually untouched and it makes little difference with a high quality deinterlacer like QTGMC anyway.



You should make two versions, one for YouTube (not pillarboxed, just 960x720 59.94p), and one for Blu-ray (SD interlaced or 720p pillarboxed).