Quote:
Originally Posted by flossy_cake
It occurred to me that with 3:2 stuff containing orphaned fields on scene changes, it is logically/mathematically impossible to pull out a perfectly clean 24p. Because the source doesn't actually contain 24p, it contains 24p plus the occasional extra field here and there. This offsets the timing slightly such that over time those extra fields add up and would cause the video to go out of sync. So the only way to TFM such content is to use a final output mode of 60p -- only then we have the necessary time slice granularity to represent all images in the source without video going out of sync. Another option is to do frame blending of the orphaned field and its neighbouring 24p frame. This might be my preferred method as it avoids 3:2 judder of 60p, but I couldn't get it to work as it's implemented by TDecimate which comes after TFM, and TFM is making the decisions about orphaned field handling before TDecimate gets a chance at it.
|
It should be in sync - and I've never seen any those types of film (or film equivalent) based NTSC DVD's that are not because of those types of cadence interruption edits after IVTC
The "granularity" of 59.94p is potentially "finer" than 23.976p, but the running time is the same (same length as audio), and so the sync is pretty much the same (maybe a few ms difference, less than a frame duration, so not out of sync to human eyes/ears) . That interpolated 59.94p from film content actually has 3:2 duplicates, so the "granularity" isn't really better in that case (in terms of motion , or unique frames)
When you perform "normal" IVTC, the frame count @23.976p is the same whether or not you have a a) duplicate at that spot, b) or a blend, or c) a deinterlaced frame, so the timing is unchanged, sync is unchanged
The deinterlaced frame (a frame from an interpolated single field) is the best option in most cases (if a good algorithm is used) because is is an actual unique frame. It best represents what actually should have been there. Blends look bad, and duplicates aren't ideal either. Some cases where deinterlace might not be as good is if the remaining orphaned field is of noticable lower quality (e.g. at the end of a GOP, sometimes the bitrate allocation for the single field is lower than normal, it can be full of encoding artifacts - if you can't selectively clean them up, then a duplicate might look better)