TDeint and TIVTC

[hello_hello]

After having another play, I'm still at a loss as to why field matchers/deinterlacers think the progressive frames need deinterlacing and why they make such a mess of it when they do, but for re-encoding.....

What seems to work for the sample at least, is to use much less enthusiastic field matching than TFM's defaults and to back off the combing detection quite a lot. The easiest way to do the former is to use TDeint instead of TFM, and they both have the MI argument.

This fails to find a match for the orphan fields around the scene changes so it de-interlaces them instead, which IMHO is better than duplicate frames.

TDeint(MI=200, TryWeave=true)

Trouble is, there's somehow aliasing built in anyway, and even denoising seems to make it worse, and anti-aliasing tends to blur so I'd sharpen to counter-act it, and of course I'd also be keen not to sharpen noise much....

Both screenshots are the script output upscaled to 1080p by MPC-HC.

FFVideoSource("E:\soft telecine.mkv", FPSNum=24000, FPSDen=1001, threads=1)
CropResize(0,0, 9,0,-7,0, InDAR=15.0/11.0, ResizeWO=true)

https://i.ibb.co/N9Hhd4S/Cropping-and-resizing-only.png

FFVideoSource("E:\soft telecine.mkv", FPSNum=24000, FPSDen=1001, threads=1)
TDeint(MI=200, TryWeave=true)
MCDAA3()
MDegrainNL(Tr=3, thSAD=300)
LSFMod()
CropResize(0,0, 9,0,-7,0, InDAR=15.0/11.0, ResizeWO=true)

https://i.ibb.co/f2f6SMZ/Filtered-cr...nd-resized.png

soft telecine encode.mkv (5.1MB)

[flossy_cake]

Originally Posted by hello_hello

After having another play, I'm still at a loss as to why field matchers/deinterlacers think the progressive frames need deinterlacing

Actually Asd-g is changing all that and making it so that for yadif & bwdif, if frame flag _FieldBased=0 (progressive) then it won't deinterlace and throws an error. I'm trying to convince them here to just passthrough the frame instead of throwing error.

Originally Posted by hello_hello

This fails to find a match for the orphan fields around the scene changes so it de-interlaces them instead, which IMHO is better than duplicate frames.

Yep, and that is how my Sony DVD player handles it when playing the disc as well, which I find ideal. LWlibavVideoSource actually flags those frames as _FieldBased=2 so it's trivial to do a ScriptClip to switch to bwdif/tdeint etc. when _FieldBased=2.

Also I edited one of my previous comments to mention that the short clips I've been cutting appear to have mucked up metadata in the process of clipping them from the full episode, so I wouldn't necessarily trust the result on those short clips. For instance bwdif was producing some unexpected aliasing but TDeint was not, and I never got to the bottom of it apart from finding that both performed as expected on the full episode but not the short clip.

Anyway, I can see the first screenshot of yours is full resolution progressive frame, and the second one appears blurred on the white rims of the blue cups. I'm not sure if it's weaving or not (I'm guessing it should since you set the MI so high?) but it still looks rather clean and nice -- looks like you are doing antialiasing, denoise & sharpen. For sharpening I'm using MadVR's options but I'm definitely keen on using an antialiasing filter for some of my content so I'll check out MCDAA3 ... just hope it's fast enough for real time.

[hello_hello]

Originally Posted by flossy_cake

Actually Asd-g is changing all that and making it so that for yadif & bwdif, if frame flag _FieldBased=0 (progressive) then it won't deinterlace and throws an error. I'm trying to convince them here to just passthrough the frame instead of throwing error.

I suspect, given they're fairly new, frame properties will cause a lot of pain for a while.

A friend PM'd me last week wanting to know why some of his scripts were being encoded as interlaced without him changing the encoder command line. I assumed it was operator error until I remembered he likes to pipe scripts to ffmpeg and it supports frame properties now. It turned out the source filter was setting _FieldBased=1 & he was mostly deinterlacing with bwdif and it set _FieldBased=0, but when he used anything else to de-interlace.....

I'm not an expert on this, but is there any way a source filter can know if a video is really progressive unless it's something like an NTSC DVD with repeat flags for applying telecine? If there's no repeat flags I assume it could be interlaced, progressive or hard telecined, and if it's combinations of each then it's probably all encoded as interlaced anyway.

Originally Posted by flossy_cake

Yep, and that is how my Sony DVD player handles it when playing the disc as well, which I find ideal. LWlibavVideoSource actually flags those frames as _FieldBased=2 so it's trivial to do a ScriptClip to switch to bwdif/tdeint etc. when _FieldBased=2.

In your case there's orphaned fields so you want to treat them as interlaced, but is _FieldBased=2 just a safe assumption that could be incorrect?
As far as I know a progressive scan player would output either 23.976 or 59.97 etc, but without repeat flags it has to physically check for repeated fields and combing as plugins do and choose to de-interlace or apply IVTC on the fly.

Originally Posted by flossy_cake

Also I edited one of my previous comments to mention that the short clips I've been cutting appear to have mucked up metadata in the process of clipping them from the full episode, so I wouldn't necessarily trust the result on those short clips. For instance bwdif was producing some unexpected aliasing but TDeint was not, and I never got to the bottom of it apart from finding that both performed as expected on the full episode but not the short clip.

I did see a mention of bwdif crapping out at the beginning of the sample, and I did notice the first three frames had the same timecodes, Maybe that had something to do with it, but I think the reason I used FPSNum=24000, FPSDen=1001 instead of repeat=false is the former dropped two of them so there wasn't a pause for a second at the beginning.

If you use rffmode=1, the output would be 60i and all fields would need to be set to interlaced, even for the soft telecined sections. It's then up to the de-interlacer/field matcher to look at them and decide if they're video or film and handle them accordingly.
If rffmode=0, in a perfect world the film sections would be output as progressive and could be marked as progressive, but any sections without repeat flags would still need to be checked. If there's hard telecine I don't think bwdif is the right tool for the job, but I can't imagine why it should throw an error if _FieldBased=0.

Well here's a fun fact for you. I'm going to bang my head against the desk very hard shorty to punish myself, because I think your sample is actually soft telecine from start to finish. If you use rffmode=0 with ffms2 there's no orphaned fields on the scene changes. My guess is it's outputting 24.379fps because without FPSNum=24000, FPSDen=1001 it operates in variable frame rate mode and outputs the average frame rate, and those three frames with the same timecodes at the beginning have fudged the average.
It looks like it's rffmode=1 shuffling fields around scene changes, maybe because of the first three frames, but &%$@ me! How did I not notice that until now??!?

In my defence I did remux the MKV as a TS file to index it with DGIndex, which probably created more problems, and I think LSmash was decoding it differently again, but still.... &%$@ me!

Originally Posted by flossy_cake

Anyway, I can see the first screenshot of yours is full resolution progressive frame, and the second one appears blurred on the white rims of the blue cups. I'm not sure if it's weaving or not (I'm guessing it should since you set the MI so high?) but it still looks rather clean and nice -- looks like you are doing antialiasing, denoise & sharpen. For sharpening I'm using MadVR's options but I'm definitely keen on using an antialiasing filter for some of my content so I'll check out MCDAA3 ... just hope it's fast enough for real time.

The blurring of the cups would have been MCDAA3 cleaning up the all the wobble (alaising) on the cup rims, but it probably doesn't really exist. I think that's one of real.finder's functions.

[flossy_cake]

Originally Posted by hello_hello

In your case there's orphaned fields so you want to treat them as interlaced, but is _FieldBased=2 just a safe assumption that could be incorrect?

I suppose it depends how reliable LWLibavVideoSource is at setting _FieldBased based on whatever metadata/flags are inside the MPEG2 stream. To be safe I'll probably do a check for _FieldBased and an additional IsCombedTIVTC check, although the latter should be sufficient most of the time.

Originally Posted by hello_hello

Well here's a fun fact for you. I'm going to bang my head against the desk very hard shorty to punish myself, because I think your sample is actually soft telecine from start to finish. If you use rffmode=0 with ffms2 there's no orphaned fields on the scene changes. My guess is it's outputting 24.379fps because without FPSNum=24000, FPSDen=1001 it operates in variable frame rate mode and outputs the average frame rate, and those three frames with the same timecodes at the beginning have fudged the average. It looks like it's rffmode=1 shuffling fields around scene changes, maybe because of the first three frames, but &%$@ me! How did I not notice that until now??!?

Well, on my system with ffmpegsource2(rffmode=0) I'm still getting the orphaned field on scene change



Adding (fpsnum=24000, fpsden=1001) has no effect, except playback stutters for a few seconds every now and again, and the short clip isn't long enough to show it. I'm kind of at the point of giving up trying to understand what's going on under the hood with soft telecine. Although I came across this (good luck understanding it)

Some quotes from ISO 13818-2
note there are TWO different "progressive" flags

top_field_first -- The meaning of this element depends upon picture_structure, progressive_sequence and repeat_first_field.
If progressive_sequence is equal to ‘0’, this flag indicates what field of a reconstructed frame is output first by the decoding process:
In a field picture top_field_first shall have the value ‘0’, and the only field output by the decoding process is the decoded field picture.
In a frame picture top_field_first being set to ‘1’ indicates that the top field of the reconstructed frame is the first field output by the decoding process. top_field_first being set to ‘0’ indicates that the bottom field of the reconstructed frame is the first field output by decoding process

If progressive_sequence is equal to 1, this flag, combined with repeat_first_field, indicates how many times (one, two or three) the reconstructed frame is output by the decoding process.
If repeat_first_field is set to 0, top_field_first shall be set to ‘0’. In this case the output of the decoding process corresponding to this reconstructed frame consists of one progressive frame.
If top_field_first is set to 0 and repeat_first_field is set to ‘1’, the output of the decoding process corresponding to this reconstructed frame consists of two identical progressive frames.
If top_field_first is set to 1 and repeat_first_field is set to ‘1’, the output of the decoding process corresponding to this reconstructed frame consists of three identical progressive frames.

repeat_first_field -- This flag is applicable only in a frame picture, in a field picture it shall be set to zero and does not affect the decoding process.
If progressive_sequence is equal to 0 and progressive_frame is equal to 0, repeat_first_field shall be zero, and the output of the decoding process corresponding to this reconstructed frame consists of two fields.
If progressive_sequence is equal to 0 and progressive_frame is equal to 1:
If this flag is set to 0, the output of the decoding process corresponding to this reconstructed frame consists of two fields. The first field (top or bottom field as identified by top_field_first) is followed by the other field.
If it is set to 1, the output of the decoding process corresponding to this reconstructed frame consists of three fields. The first field (top or bottom field as identified by top_field_first) is followed by the other field, then the first field is repeated.
If progressive_sequence is equal to 1:
If this flag is set to 0, the output of the decoding process corresponding to this reconstructed frame consists of one frame.
If it is set to 1, the output of the decoding process corresponding to this reconstructed frame consists of two or three frames, depending on the value of top_field_first.

https://forum.videohelp.com/threads/...ame#post806241

Originally Posted by hello_hello

As far as I know a progressive scan player would output either 23.976 or 59.97 etc, but without repeat flags it has to physically check for repeated fields and combing as plugins do and choose to de-interlace or apply IVTC on the fly.

I suspect my Sony DVD player is not analysing pixels for combing because the earlier seasons of that show are hard telecined and the Sony does mocomp deint for those (anything that moves drops to 240p). Therefore, I'm inferring that if it was obeying the repeat flags for the soft telecined seasons, then internally it would have 60i and do mocomp deint as well, but instead it outputs all frames progressively at 1080p60 and deints only those frames with orphan fields (I've stepped through frame-by-frame to observe those frames drop to 240p).

[hello_hello]

You're correct, there's still orphan fields. I was tired and too quick to get excited.

I've been seeing this on scene changes with rffmode=1, and when it went away with rffmode=0, I incorrectly assumed there'd no longer be orphans.



Converting the frame rate with fpsnum=24000, fpsden=1001 doesn't seem to do much, but the frame count drops from 256 to 252. Naturally the frame rate changes from 24.379 to 23.976. Hopefully the glitches are only little pauses in decoding and it'll playback smoothly once it's encoded.... ummmmm sorry..... I'm used to that being the end goal... but if it's pure soft telecine rffmode=0 should give you 23.976fps and there'd be no need for ffms2 to do any frame rate conversion.

I suspect my Sony DVD player is not analysing pixels for combing because the earlier seasons of that show are hard telecined and the Sony does mocomp deint for those (anything that moves drops to 240p).

Thinking about it, maybe players do just interpolate "interlaced" fields into full frames, whether it's a hard telecined field or a video field. If not it'd have to field match first, and if it did that before weaving fields together it'd probably have to check the weaved frames for combing. I'm just guessing though as I have no idea what they do.

What about decoding this way?
Rather than obey the repeat flags, FFMS2 should decode the soft telecine sections as film while duplicating the progressive frames for 29.97fps.

Hopefully TryWeave will handle hard telecine, with TDecimate() removing the duplicates in the film sections, and if there's any video sections hiding amongst the film (opening or closing credits maybe), it'll be converted to 23.976fps using frame blending.

FFVideoSource("D:\soft telecine.mkv", threads=1, rffmode=0, fpsnum=30000, fpsden=1001)
A = last
TDeint(MI=200, TryWeave=true, clip2=A)
TDecimate(Hybrid=1)

[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.

[poisondeathray]

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)

[flossy_cake]

Sorry I should have been clearer - a sync issue would only arise if we tried to represent every unique image from the 3:2 source in the 24p output without any duplicates, skipped frames or blended frames. The point I'm trying to make is that the source isn't really genuine 24p, it's in a way "hard coded" to 60hz if you want to see every unique image in the source as it was intended to be seen. eg. if the first frame of a new scene is combed, and only contains image data from that scene, then field 1 is an orphan field and can't be matched to anything by TFM so it ends up getting removed in the subsequent TDecimate. So the first image from that new scene is actually lost, whereas if the final output is 60p, that orphaned field could have the opportunity to get deinterlaced and shown in the output.

[flossy_cake]

Originally Posted by flossy_cake

I'm kind of at the point of giving up trying to understand what's going on under the hood with soft telecine.

MPC Video Renderer's ctrl+J debug screen seems to show the frame rate changes in real time. MadVR doesn't show this and lead me into all kinds of wrong assumptions. With this clip for instance, MPC Video Renderer shows the frame rate actually changes between 29.97 and 23.976 dynamically depending on the scene. Sometimes it even changes between 29.97 and 29.97i as if to imply there are some frames flagged as interlaced. On top of this, the field order also changes dynamically from scene to scene, sometimes rapidly back and forth each frame! I wish I could just force it all to 29.97i TFF so I have a known quantity which I could then use TFM & TDecimate on like with normal hard telecined stuff. I've got a feeling the flags in the clip were also damaged by the software which clipped it (probably ffmpeg) as even using Bob() on it was resulting in wrong field order artefacts regardless of what field order I set. Or maybe that's an issue with the source filter, I don't really know.

[flossy_cake]

Originally Posted by flossy_cake

2:2-centric content with the occasional 1:1 scene, eg. The Office, Garth Marenghi's Darkplace

Had a look at these discs on the Sony DVD player and to my surprise it's quite bad at handling it -- the 1:1 sections are combed until there is a very large amount of motion, at which point the DVD player realises it's 1:1 and switches to mocomp deint. Then on switchback to 2:2 there is something different about the image quality, can't quite understand it. Some kind of really mild combing artefact that is almost imperceptible. It sort of looks progressive but then sort of doesn't? Can't describe it, but it's not the same clarity as the 2:2 section before the 1:1 section.

Anyway, I thought this was remarkable as the same DVD player has no trouble identifying those orphan fields from NTSC 3:2 soft telecine. I guess for NTSC content it's looking at the repeat field flags, whereas with PAL content there generally doesn't seem to be any such flags so it must be relying on trying to detect combing in the image itself (much like IsCombedTIVTC but way worse accuracy... or thresholds have deliberately been set high to maximise progressiveness on 2:2).

[Genji]

In TDecimate, if specify very large numbers for cycleR and cycle (ex. cycleR=7779,cycle=38895), cannot see the result on the screen.
(To begin with, setting display=true in this case will force AvsPmod to close.)

Is it possible to split the result display on the screen only, while leaving the cycleR and cycle specifications as they are?
For example, even if cycleR=7779,cycle=38895 is specified, if the screen display can show 250 frames at a time, etc., can check and make progress.

[kedautinh12]

You can create issue here
https://github.com/pinterf/TIVTC/issues

[pinterf]

Released TIVTC v1.0.28 (20231210) & TDeInt v1.9 (20231210)
https://github.com/pinterf/TIVTC/releases/tag/v1.0.28

For more details read the relevant documentations included in the packages.

TIVTC:

## TIVTC

**v1.0.28 (20231210)**
- Request #43: (https://github.com/pinterf/TIVTC/issues/43)
  TDecimate debug parameters displayDecimation, displayOpt.
  Able to show << or >> instead of ** on debug display by the distance from the last decimated frame compared to displayOpt.
- Fix minor display glitch (regression since v1.0.19pack): display=true would duplicate the 
  most bottom frame info text to the top position of the next column.

**v1.0.27 (20230511)**

- Fix #40: TDecimate: frame properties were not inherited at specific modes (20230511)
- Implement #39: CFrameDiff, FrameDiff: add offset parameter (int, default 1), to compare frames more than 1 distance away.
  offset value must be >=1, already existing prevf parameter is used to set the direction.

**v1.0.27test (20220915)**
  (bugfixes, frame property support backport from VapourSynth version -20220915)
- Fix: TDecimate mode 0,1 crash in 10+bits in blend (dubhater)
- Fixes in Mode 0,1 when clip2 is different format (dubhater)
- Fix: slow C code was used in calcMetricCycle.blurframe (dubhater)
- Fix: V14(?) regression TDecimate fullInfo was always false (dubhater), ("Don't know what it affected")
- MacOS build fixes (akarin)
- mingw build fixes
- Source code: refactorings, backported from VapourSynth port (dubhater, https://github.com/dubhater/vapoursynth-tivtc), 
- Source code: backport other simplification changes.
- Frame properties (priority over burned-into-image hints). Similarly to bitmapped hints, they are used when parameter "hint" is true.
  Frame properties set by TFM: TFMMatch, _Combed, TFMD2VFilm, TFMField, TFMMics, TFMPP
  Frame properties read by TFM and TDecimate: TFMMatch, TFMD2VFilm, TFMField
  Frame properties read by TFMPP: TFMField, _Combed
  Frame properties read by TDecimate creation: TFMPP (but if Avisynth variable "TFMPPValue" exists then the variable has priority over it)
  Frame properties never read: TFMMics
  Traditionally, TFM is using a 32 bit "hint" encoded in the lsb bits of the first 32 pixels of a frame.
  When Avisynth interface V8 is available, then frame properties are used instead of the image destructing bit hints.
  - Bitmapped hint replacement frame property names are: TFMMatch, _Combed, TFMD2VFilm, TFMField.
      Mapping:
        Bits 0-2: (ISP, ISC, ISN, ISB, ISU, ISDB, ISDT) are filled upon match (TFMMatch) and combed (_Combed) and field (TFMField)
          ISP: match == 0
          ISC: match == 1 && combed < 2
          ISN: match == 2
          ISB: match == 3
          ISU: match == 4
          ISDB: match == 1 && combed > 1 && field == 0
          ISDT: match == 1 && combed > 1 && field == 1
        Bit 3: set to 1 if field == 1 (TFMField 0 or 1)
        Bit 4: set to 1 if combed > 1 (_Combed)
        Bit 5: set to 1 if d2vfilm is true (TFMD2VFilm)
  - Other frame properties:
      TFMMics: array[6] of integer
      TFMPP: integer
  Frame properties set by TDecimate:
    TDecimateCycleStart (not used)
    TDecimateCycleMaxBlockDiff uint64_t[] (not used)
    TDecimateOriginalFrame (not used)
    _DurationNum, _DurationDen (not used yet, for variable frame rate (?), backport from VapourSynth port is in progress)

TDeint

## TDeint
**v1.9 (20231209) - pinterf**

- Fix C reference code of YUY2+luma-only: check_combing_c_Metric1 metrics
  Probably no one had problems with it on Intel, since it's implemented in SSE2 as well.

[hello_hello]

Originally Posted by pinterf

Released TIVTC v1.0.28 (20231210) & TDeInt v1.9 (20231210)
https://github.com/pinterf/TIVTC/releases/tag/v1.0.28

Thanks!

[FranceBB]

Thank you as always, Ferenc!
I actually followed the whole discussion on GitHub that led to this build (until you closed the issue) as I was getting the notifications via email (although I didn't reply) and it's highly appreciated.
I just swapped it on prem in prod the other day on Windows Server 2019, while on my PC I can say that it works just fine on XP.
It will also be included in the upcoming FFAStrans 1.4.0 due to be released on Christmas Day.

[pinterf]

Ikotas has published a nice detailed guide for IVTC from 29.97fps to 25fps utilizing TDecimate.
Activation emails are kinda slowish here at doom9, so I was asked to help in publishing.

Here it is (in Japanese)
https://ikotas.github.io/25fpsIVTCGuide/

And in English - easy-click-version - for those without auto-translate:
https://ikotas-github-io.translate.g..._x_tr_pto=wapp

Thanks to Ikotas for taking the time to prepare this description.

[Micheal813]

I have some mpg video that is mostly hard telecined to play at 29.97 fps. There are some small sections that are just progressive 29.97 fps. I index it with DGIndex and it shows 100% video.

If I use this script and go frame by frame in VDub, some sections show pattern AABBCCDD (Progressive?) and some show AABBBCCDDD(Hard Telecine?).

mpeg2source("path\to\video.mpg")
AssumeTFF()
SeparateFields()


I'm using this script for the final product:

mpeg2source("path\to\video.d2v")
TFM(d2v="path\to\video.d2v")
TDecimate()

Is this correct? It seems to work and convert everything to 23.976, but just wanted to check.

Thanks

[FranceBB]

Originally Posted by Micheal813

I have some mpg video that is mostly hard telecined to play at 29.97 fps. There are some small sections that are just progressive 29.97 fps.

You have two paths in front of you:

Option A) You deinterlace everything, so that the telecined parts will be duplicated to 29.970p but you'll save the progressive ones

Option B) You IVTC everything to 23.976p so that the telecined parts will be 23.976 and the progressive parts will be decimated to 23.976p

Originally Posted by Micheal813

I'm using this script for the final product:

mpeg2source("path\to\video.d2v")
TFM(d2v="path\to\video.d2v")
TDecimate()

Is this correct? It seems to work and convert everything to 23.976, but just wanted to check.

Yes, that's option B, it will IVTC the telecined parts and decimate the progressive ones so that you're gonna get 23.976p in the end.

To be absolutely fair, I don't know what I would personally do. I had to make this decision long time ago with animations which were hard telecined in the normal parts ('cause animating stuff costs money) with 3 "good" and 2 repeated,
3 good and 2 repeated, 3 good and 2 repeated etc and 29.970p parts whenever a panning was occurring ('cause panning is done by a computer, so it didn't cost any money). I actually decided to go with option A and preserve the 29.970p parts by duplicating the 23.976p ones. This was back when I was working at Viewster after moving away from Crunchyroll, so around 2015.

[Micheal813]

Originally Posted by FranceBB

You have two paths in front of you:

Option A) You deinterlace everything, so that the telecined parts will be duplicated to 29.970p but you'll save the progressive ones

Option B) You IVTC everything to 23.976p so that the telecined parts will be 23.976 and the progressive parts will be decimated to 23.976p



Yes, that's option B, it will IVTC the telecined parts and decimate the progressive ones so that you're gonna get 23.976p in the end.

To be absolutely fair, I don't know what I would personally do. I had to make this decision long time ago with animations which were hard telecined in the normal parts ('cause animating stuff costs money) with 3 "good" and 2 repeated,
3 good and 2 repeated, 3 good and 2 repeated etc and 29.970p parts whenever a panning was occurring ('cause panning is done by a computer, so it didn't cost any money). I actually decided to go with option A and preserve the 29.970p parts by duplicating the 23.976p ones. This was back when I was working at Viewster after moving away from Crunchyroll, so around 2015.

Thank you for the help. What would the script for option A look like?

[FranceBB]

Originally Posted by Micheal813

What would the script for option A look like?

A simple tdeint should suffice:

MPEG2Source("video.d2v")

tdeint(mode=2, order=-1, field=-1, mthreshL=6, mthreshC=6, map=0, type=2, debug=false, mtnmode=1, sharp=true, cthresh=6, blockx=16, blocky=16, chroma=true, MI=64, tryWeave=true, link=1, denoise=true, slow=2)