IVTC orphaned fields

[sebastiaaan]

Hi there,

I recently got hold of some masters of SD music videos and I'm trying to fix any issues they came with. I don't want to go on a rant about something but some of them are very difficult to deal with, such as interlaced encoded as progressive or straight up mixes of interlace and telecine.

The one I'm asking about has none of these issues whatsoever, it's a 720x480 29,97i ProRes file. From what I can tell it uses 3:2 pulldown or some sort of it so I tried my luck with TIVTC. The thing is, no matter how many settings I change (I've spent 2 good hours of reading the docs and googling) I still end up with orphaned fields. I also tried deinterlacing and then removing the duplicate frames but the problem still persists. The only clean result was by using Premiere Pro and forcing a 23.976 progressive output, although it looks like crap (I assume it's because Premiere doesn't interpolate the missing fields thus halving the vertical resolution = looks pixelated). But what fascinates me is that Premiere catches the fields spot on, no duplicates, no orphanages and no combing at all.

I tried reproducing the Premiere workflow in other programs (Handbrake, Staxrip) but I can't for the live get a similar result. All my attempts at inverse telecine didn't succeed, it always ends up looking like this, no matter what pp values I specify in TFM():

[Attachment 68666 - Click to enlarge]

Maybe the problem is that my TDecimate values are off, but I tried a lot of different settings so I think I'm just lost..

Can someone with knowledge in this area please help me create a script that will take care of this problem? Or is the file itself the culprit, thus not really fixable without spending an insane amount of time on it? I also attached the Premiere output file to demonstrate that it takes good care of these fields so it must be an error in my script or TIVTC in general I guess.

Here are my settings, although as I said I've tried multiple modes and values:
TDecimate(mode=0, cycle=5,cycleR=1)
TFM(mode=4, pp=6, mi=40, slow=2)

Thanks in advance

[jagabo]

TDecimate(mode=0, cycle=5,cycleR=1)
TFM(mode=4, pp=6, mi=40, slow=2)

In that order? It's backwards. It will definitely cause orphaned fields. You need to TFM first, then TDecimate.

LSMASHVideoSource("original.mov") 
AssumeTFF()
TFM()
TDecimate()
ConvertBits(8) # for 8 bit encoding with x264

I didn't look really closely but I didn't notice any problems with that. Even with TFM(pp=0) which would allow orphaned fields through (as interlaced frames) I didn't see any problems.

That said, it's very common for music videos to have orphaned fields and other problems because they are usually edited after being telecined and shots are sped up and slowed down to match the music.

[sebastiaaan]

TDecimate(mode=0, cycle=5,cycleR=1)
TFM(mode=4, pp=6, mi=40, slow=2)

In that order? It's backwards. It will definitely cause orphaned fields. You need to TFM first, then TDecimate.

LSMASHVideoSource("original.mov") 
AssumeTFF()
TFM()
TDecimate()
ConvertBits(8) # for 8 bit encoding with x264

I didn't look really closely but I didn't notice any problems with that. Even with TFM(pp=0) which would allow orphaned fields through (as interlaced frames) I didn't see any problems.

That said, it's very common for music videos to have orphaned fields and other problems because they are usually edited after being telecined and shots are sped up and slowed down to match the music.

Hey thanks for your reply! Yeah no, I tried TFM().TDecimate() as well as the other way around (like in my post) but I still ended up with the same results. So I curiously downloaded Hybrid to do a test encoding, I almost always exclusively use StaxRip since I find the UI much nicer. And voila, it looks perfect just like in your attached file. This is very weird to me though. I pasted the Hybrid script 1:1 to StaxRip and it still doesn't work! May I ask what you use for your scripts, any GUI or are you doing everything through the command line?

I swear I never could get TIVTC to work since I only used StaxRip but I guess it's time to move on.. Thank you very much for helping me, I finally identified the problem.

[jagabo]

May I ask what you use for your scripts, any GUI or are you doing everything through the command line?

I have batch files that create generic scripts. For example, I downloaded your video to my Desktop, right clicked on the file and selected Send To -> AVS_LSMASHVideoSource.bat. That created an AVS script with just the LSMASH source line with the filename. I then opened the script with VirtualDub2, previewed and edited it. Once I was happy with the script I used the x264 command line encoder (drage/drop the AVS file onto a batch file) to encode it. I also have batch files for encoding with ffmpeg. Finally I checked the encoded video by opening it with VirtualDub2 and stepping through frame by frame.

I swear I never could get TIVTC to work since I only used StaxRip but I guess it's time to move on.. Thank you very much for helping me, I finally identified the problem.

Did StarRip identify the field order properly? The video is TFF but AviSynth assumes BFF if the source filter doesn't specify the field order. I had to use AssumeTFF() because LSMASHVideoSource() didn't supply the field order. Did StaxRip do any other processing before TFM().TDecimate()? Maybe that processing screwed something up. You can use Info() any time in a script to get the properties at that point in the script (printed on the video).

[sebastiaaan]

May I ask what you use for your scripts, any GUI or are you doing everything through the command line?

I have batch files that create generic scripts. For example, I downloaded your video to my Desktop, right clicked on the file and selected Send To -> AVS_LSMASHVideoSource.bat. That created an AVS script with just the LSMASH source line with the filename. I then opened the script with VirtualDub2, previewed and edited it. Once I was happy with the script I used the x264 command line encoder (drage/drop the AVS file onto a batch file) to encode it. I also have batch files for encoding with ffmpeg. Finally I checked the encoded video by opening it with VirtualDub2 and stepping through frame by frame.

I swear I never could get TIVTC to work since I only used StaxRip but I guess it's time to move on.. Thank you very much for helping me, I finally identified the problem.

Did StarRip identify the field order properly? The video is TFF but AviSynth assumes BFF if the source filter doesn't specify the field order. I had to use AssumeTFF() because LSMASHVideoSource() didn't supply the field order. Did StaxRip do any other processing before TFM().TDecimate()? Maybe that processing screwed something up. You can use Info() any time in a script to get the properties at that point in the script (printed on the video).

Good call! Upon importing the video into StaxRip it added
ConvertToYUV420()
right after LSMASHVideoSource

Removing this line ConvertToYUV420() fixes it completely. I feel dumb now that I didn't notice that, I thought that since it's "tied" to the source filter it's better to not touch it. Do I even need this line? Or is it fine to put it at the end? And what's the difference between ConvertToYV12() and ConvertToYUV420 or more like what should be used and when? Does it matter which output codec I use?

Also regarding ConvertBits(8), I only need that for 8-bit encodes, right? Is there a way to tell if a video is 8 or 10bit when it doesn't show up in MediaInfo? I'm not too familiar with ProRes but I noticed that sometimes flags such as color space or bit depth are not set (or at least they don't show up in MediaInfo) thus making it difficult for me to know what I'm dealing with.

I'm also looking for a clean way to encode these videos back to ProRes however I don't really trust those ffmpeg encoders (especially because Apple warned against using them) so I'd need some sort of an intermediate (lossless) codec to do the "proper" ProRes encodes through either Premiere/Resolve or on my Mac. However I've read that relying on a lossless codec will bring some downsides such as wrong color space/bit depth/rgb range. Not sure if there's a "definitive" codec for this use case or is there? FFV1/UT Video isn't supported by those programs unfortunately. Only option is either prores_ks hq or x264 lossless qp (although slow) and then re-encoding to ProRes with Premiere/Resolve/Compressor. Not sure if that degrades the quality as it's an intraframe codec and no other processing will (hopefully) be applied.

If that doesn't work I could still use regular x264 and use stupidly high crf values. But I don't really care about storage so proper ProRes would be optimal..

Sorry for the many questions but thank you so so much for already helping me, without you I'd have never noticed what the culprit was. <3

[poisondeathray]

Removing this line ConvertToYUV420() fixes it completely. I feel dumb now that I didn't notice that, I thought that since it's "tied" to the source filter it's better to not touch it. Do I even need this line? Or is it fine to put it at the end? And what's the difference between ConvertToYV12() and ConvertToYUV420 or more like what should be used and when? Does it matter which output codec I use?

If you're using modern avs+, modern TIVTC plugin, you don't need the line . Old TIVTC versions only worked in 8bit .

ConvertToYV12() means 8bit 4:2:0 only . ConvertToYUV420 would convert at the current bit depth to 4:2:0. Your source prores is 10bit 4:2:2 so it would be converted to 10bit 4:2:0 after using ConvertToYUV420 . It's also wrong for another reason, because the encoding is interlaced, it should be ConvertToYUV420(interlaced=true) if you were using it before TIVTC, otherwise the chroma would get downsampled in a progressive manner and you'd get chroma artifacts

I wouldn't use either ConvertToYV12() or ConvertToYUV420() - just keep 10bit 4:2:2 , since your goal is to output prores or similar to import back into a NLE

IIs there a way to tell if a video is 8 or 10bit when it doesn't show up in MediaInfo? I'm not too familiar with ProRes but I noticed that sometimes flags such as color space or bit depth are not set (or at least they don't show up in MediaInfo) thus making it difficult for me to know what I'm dealing with.

Prores HQ is 10bit only, no other options . That doesn't necessarily indicate what the source upstream actually was.

I'm also looking for a clean way to encode these videos back to ProRes however I don't really trust those ffmpeg encoders (especially because Apple warned against using them) so I'd need some sort of an intermediate (lossless) codec to do the "proper" ProRes encodes through either Premiere/Resolve or on my Mac. However I've read that relying on a lossless codec will bring some downsides such as wrong color space/bit depth/rgb range. Not sure if there's a "definitive" codec for this use case or is there? FFV1/UT Video isn't supported by those programs unfortunately. Only option is either prores_ks hq or x264 lossless qp (although slow) and then re-encoding to ProRes with Premiere/Resolve/Compressor. Not sure if that degrades the quality as it's an intraframe codec and no other processing will (hopefully) be applied.

ffmpeg prores works fine in 2023 . The ffmpeg prores bitrates are typically a bit higher than Apple certified Prores. There were potential issues about 8-10 years ago, but ffmpeg prores is very stable now. If it makes you feel better you can use DNxHR/DNxHD as an alternative . The "best" 10bit 422 lossless format compatible for Apple would be uncompressed v210 in MOV container but you need lots of storage. Prores or DNxHD would be a good compromise, they are near lossless.

But I don't really care about storage so proper ProRes would be optimal..

If you really don't care about storage, then go uncompressed 10bit422 - v210 in mov

If that doesn't work I could still use regular x264 and use stupidly high crf values.

The quality for 10bit422 x264 using --qp 1 intra is actually signifcantly higher than ProRes 422HQ at lower bitrates . I posted some benchmarks in a thread at doom9. But x264 decodes much slower; and on a mac prores is extremely fast
http://forum.doom9.org/showthread.php?p=1884556#post1884556

[jagabo]

Removing this line ConvertToYUV420() fixes it completely.

Since it is interlaced video it should have been ConvertToYUV420(interlaced=true).

Do I even need this line?

Generally, it depends on what the later filters accept. The source video is YUV 4:2:2 10 bits and flagged interlaced. What comes out of the LSMASHSource() is YUV422P10, YUV 4:2:2 10 bits, planar (rather than interleaved samples). It doesn't matter if it's interlaced or progressive because the chroma isn't subsampled vertically -- as long as you handle it properly. In this case TFM() by it's nature assumes the video is interlaced, can handle YUV422P10 properly, and produces progressive frames. And TDecimate() can handle the resulting YUV422P10 frames. So you don't need the ConvertToYUV420() before filtering.

Or is it fine to put it at the end?

Generally, you want to do your filtering with the most bits and the least chroma subsampling. But it won't make much difference with TFM() and TDecimate(). Whether you need it or not at the end depends on what the encoder accepts as input and what you want in the final output. I converted from 10 bits to 8 bits to use x264.

And what's the difference between ConvertToYV12() and ConvertToYUV420

Basically the supported input and output formats. ConvertToYV12() converts to YUV 4:2:0 planar and only works with 8 bit video. ConvertToYUV420() does the same but works with higher bit depths -- ie your 10 bit video.

Also regarding ConvertBits(8), I only need that for 8-bit encodes, right?

Yes.

Is there a way to tell if a video is 8 or 10bit when it doesn't show up in MediaInfo? I'm not too familiar with ProRes but I noticed that sometimes flags such as color space or bit depth are not set (or at least they don't show up in MediaInfo) thus making it difficult for me to know what I'm dealing with.

It doesn't really matter what the codec does internally. What does matter is what comes out of the decoder. In this case LSMASHVideoSource() or ffVideSource() produce 10 bit planar YUV with 4:2:0 chroma subsampling.

I'm also looking for a clean way to encode these videos back to ProRes however I don't really trust those ffmpeg encoders (especially because Apple warned against using them)

I don't use prores much so I'm no expert on the subject. But when I have used it I had no problems with ffmpeg's prores decoding or encoding. I have had problems with Quicktime for Windows though!

[jagabo]

By the way, although the prores file is 10 bit, it looks like the original cap was 8 bit.

[poisondeathray]

By the way, although the prores file is 10 bit, it looks like the original cap was 8 bit.

Yes, the gradient near the end of the sample has quantized increment/decrement values of 4 in the Y channel. It should be smoother for real 10bit