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
Try StreamFab Downloader and download from Netflix, Amazon, Youtube! Or Try DVDFab and copy Blu-rays!
+ Reply to Thread
Results 1 to 9 of 9
Thread
-
-
In that order? It's backwards. It will definitely cause orphaned fields. You need to TFM first, then TDecimate.
Code:LSMASHVideoSource("original.mov") AssumeTFF() TFM() TDecimate() ConvertBits(8) # for 8 bit encoding with x264
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.Last edited by jagabo; 13th Jan 2023 at 07:55.
-
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. -
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.
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 -
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.
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.
But I don't really care about storage so proper ProRes would be optimal..
If that doesn't work I could still use regular x264 and use stupidly high crf values.
http://forum.doom9.org/showthread.php?p=1884556#post1884556 -
Since it is interlaced video it should have been ConvertToYUV420(interlaced=true).
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.
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.
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.
Yes.
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 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! -
By the way, although the prores file is 10 bit, it looks like the original cap was 8 bit.
-
Similar Threads
-
Any tips on brightening background star fields?
By JoelHruska in forum Newbie / General discussionsReplies: 4Last Post: 20th Aug 2021, 23:55 -
QTGMC TFF not working on Separated fields?
By taigi in forum Video ConversionReplies: 16Last Post: 5th Jun 2021, 10:38 -
Help me to understand the NTSC signal fields
By Videogamer555 in forum CapturingReplies: 26Last Post: 6th Aug 2019, 11:52 -
Separate visualization of Y,U and V fields
By VHS_Hunter in forum RestorationReplies: 9Last Post: 15th Sep 2018, 14:52 -
Avisynth separate fields without dominance
By Megafox in forum Newbie / General discussionsReplies: 3Last Post: 9th Mar 2018, 18:59