any thoughts on what is going on with this encode?

[Lathe]

BTW, a HUGE Thank You to all the help on the last one, that was really great and I learned a lot.

This one is also puzzling, I DL from YouTube (which is fully legitimate, they allow it) and I was quite surprised that this rather obscure Telefilm looked this good! Frigg'n LOVE this movie!

I notice that MediaInfo shows the framerate to be 30.000. It shows as Progressive, so that means that it does NOT need the DeTelecine, right? I did try the aforementioned Vinverse with default settings, and it seemed to look pretty good,it did get rid of most of the combing, but around the edges of say Jeff Fahey's coat when he moves, there is a little bit of a 'Shimmer' I'm sure I could live with it, but I'd love to get some input on what is going on with this encode so I can continue to learn from you guys! :D Thanks!

http://lathe-of-heaven.com/Curiosity Kills.snippet.mkv

[Sharc]

The video has been borked by poor deinterlacing and poor framerate conversion introducing blends, IMO.
I don't see a real fix for it, but you may want to try something along the line


QTGMC()
SRestore() #deblending, returns the original 25fps
FineDehalo() #adjust to reduce the halos

[Selur]

looks like interlaced content got (wrongly) resized and encoded progressively, down scaling vertically and deinterlacing will leave you with ghosting.
sRestore&Co and deblurring might help a bit, but this won't look good,...

[Lathe]

The video has been borked by poor deinterlacing and poor framerate conversion introducing blends, IMO.
I don't see a real fix for it, but you may want to try something along the line


QTGMC()
SRestore() #deblending, returns the original 25fps
FineDehalo() #adjust to reduce the halos


Thanks Bro, kinda thought so...

[Lathe]

looks like interlaced content got (wrongly) resized and encoded progressively, down scaling vertically and deinterlacing will leave you with ghosting.
sRestore&Co and deblurring might help a bit, but this won't look good,...

Thanks Selur! Yeah, it kind of struck me that someone had encoded it incorrectly, but I can live with it. DAMN good film!

[Lathe]

Just a quickie... Most of these when checking MediaInfo look like this. So, it is saying basically that all of these are interlaced, TFF. However, since I THINK I remember that most of these are from either VHS transfers using a DVD Recorder or from actual ripped NTSC DVDs, shouldn't that be instead that they are Telecined and need to be Detelecined? I'm a bit confused about that. And, IF these are in fact all Interlaced, what then should I use, one or some of these:

AssumeTFF()?
SeparateFields()
Weave()
FieldDeinterlace(blend=true) ???

Or, if these are what I THINK they are from Telecinced NTSC DVD's, then shouldn't I use these as a general rule:

TFM()
TDecimate() ???

Also, in doing a search on the 29.xxx framerate, it yielded this, which is even more confusing because it sounds like it is BOTH! WTF!???

When converting telecined video to progressive, a proper deinterlacing process is crucial for avoiding artifacts

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

Here is how MediaInfo usually shows these:


General
Unique ID : 160996461276992400713407217393433583199 (0x791ECA62E2B45FCA85E17FD0217C1E5F)
Complete name : D:\Getting to Know You.mkv
Format : Matroska
Format version : Version 2
File size : 3.12 GiB
Duration : 2 h 0 min
Overall bit rate mode : Variable
Overall bit rate : 3 709 kb/s
Frame rate : 29.970 FPS
Encoded date : 2025-11-02 02:29:04 UTC
Writing application : MakeMKV 1.18.2 win(x64-release)
Writing library : libmakemkv 1.18.2 (1.3.10/1.5.2) win(x64-release)

Video
ID : 1
ID in the original source medium : 224 (0xE0)
Format : MPEG Video
Format version : Version 2
Format profile : Main@Main
Format settings : BVOP
Format settings, BVOP : Yes
Format settings, Matrix : Default
Format settings, GOP : M=3, N=15
Format settings, picture structure : Frame
Codec ID : V_MPEG2
Codec ID/Info : MPEG 1 or 2 Video
Duration : 2 h 0 min
Bit rate mode : Variable
Bit rate : 3 447 kb/s
Maximum bit rate : 9 558 kb/s
Width : 704 pixels
Height : 480 pixels
Display aspect ratio : 4:3
Original display aspect ratio : 4:3
Frame rate mode : Constant
Frame rate : 29.970 (30000/1001) FPS
Standard : NTSC
Color space : YUV
Chroma subsampling : 4:2:0
Bit depth : 8 bits
Scan type : Interlaced
Scan order : Top Field First
Compression mode : Lossy
Bits/(Pixel*Frame) : 0.340
Time code of first frame : 00:00:00:00
Time code source : Group of pictures header
GOP, Open/Closed : Open
GOP, Open/Closed of first frame : Closed
Stream size : 2.90 GiB (93%)
Language : English
Default : No
Forced : No
Color primaries : BT.601 NTSC
Transfer characteristics : BT.601
Matrix coefficients : BT.601
Original source medium : DVD-Video

[Lathe]

How about this one? Some go very easily, just Detelecine and that's it. The Curiosity Kills although I guess screwed up still looked pretty good. But some like this one are a bit weird and I can't tell.

Thanks!

http://lathe-of-heaven.com/The.Death.Artist.snippet.mkv

Going frame by frame I can't detect any pattern. It SEEMS like several frames in a row are progressive, but then some in motion periodically have combing...?

[Selur]

looks like telecined content on a first glance.

TFM()
TDecimate(mode=7)

seems to work fine to me,..
Do not trust interlaced/progressive flags, better look at the fields or frames,...

QTGMC()
sRestore()

should work too,...

[Lathe]

looks like telecined content on a first glance.

TFM()
TDecimate(mode=7)

seems to work fine to me,..
Do not trust interlaced/progressive flags, better look at the fields or frames,...

QTGMC()
sRestore()

should work too,...

Thank you Sir! Yeah, I do step through the frames, but I find it hard to tell exactly what is going on...

[Lathe]

So, is TDecimate(mode=7) different from simply doing TDecimate()? Didn't you or someone say that the default is mode=6? So, how does one determine, as you did in the clip above that I needed to use mode=7 instead of the default 6?

And yes, mode=7 is working fine on that movie, thanks!

[Selur]

default is mode 0, read the documentation it describes what each of the modes does,.. http://avisynth.nl/index.php/TIVTC/TDecimate

[Lathe]

default is mode 0, read the documentation it describes what each of the modes does,.. http://avisynth.nl/index.php/TIVTC/TDecimate

OOPS, I will do that, thanks!

I still don't see how a person determines WHICH mode to use, but I will read the documentation.

[Lathe]

Okay, I read it, but I don't fully understand it. I can see that the default seems to go through and just look for duplicate frames. Isn't that what you always want when detelecining say a DVD or VHS rip? (for movies primarily)

Mode 0 = Straight M-in-N decimation. TDecimate will examine each set of N
frames and decimate the M most similar frames. The values of M and
N are controlled via the cycleR and cycle parameters. Blend decimation
of video (30p) is supported in the this mode (hybrid = 1), as well as
blending of 24p into 30p (hybrid = 3).

And, how does this differ from mode 6 which looks pretty thorough?

Mode 6 = This is for doing 120fps->vfr w/ timecode file. It requires a complete metrics
input file generated via mode 4 on a previous pass. It will decimate bit for bit
identical frames only. All decimation will be into one of the following frame
rates: 119.880, 59.940, 39.960, 29.970, 23.976.

So, what exactly does mode=7 do differently, and what do you look for in a video that would make you choose it? I honestly don't understand what mode 7 is doing at all... So, should I choose mode 7 for EVERY DVD and VHS rip then?

Mode 7 = This mode is similar to mode 2 in that it uses a decimation algorithm that can
achieve any arbitrary framerate. However, it operates quite differently
from mode 2. It is useful for when you cannot achieve the desired framerate
with M-in-N decimation and cannot afford to go with two-passes in mode 2 (in which
case mode 7 will usually give better results if the duplicate distribution is
at least somewhat consistent).

The output framerate for this mode is set using the "rate" parameter. It
also uses the "dupthresh" and "vidthresh" parameters... dupthresh sets a
threshold such that any frames with difference values under dupthresh are
considered duplicates, and vidthresh sets a threshold such that any frames
with difference values above vidthresh are considered non-duplicates. Frames
with difference values inbetween dupthresh and vidthresh are classified as
similar unless they represent a descernable local minimum or maximum in the
difference values string. By default dupthresh is set to 0.5 and vidthresh
is set to 4.0 (they use the usual 0 to 100 normalized scale).

[Sharc]

http://lathe-of-heaven.com/The.Death.Artist.snippet.mkv

Going frame by frame I can't detect any pattern. It SEEMS like several frames in a row are progressive, but then some in motion periodically have combing...?
It's standard 2:3 telecined film.
- Stepping through the frames you see a repetitive pattern of 2 combed frames followed by 3 clean frames.
- or stepping through the fields you see a repetitive 2-3 pattern like aabbbccdddeefff......
Use a scene with motion to see it clearly.

As suggested by Selur just IVTC (inverse telecine, aka detelecine) it to get the original 24fps (23.976fps) progressive film frames back.
TFM() #returns progressive frames at 29.97fps, with repetitive duplicates like ABCDDEFGHH .....
TDecimate() # removes the duplicates, keeping the 23.976fps unique film frames ABCDEFGH.......

[johnmeyer]

Things I've learned about video like this.

1. ALWAYS ignore any Mediainfo (or other tool's) "interlaced" or "progressive" report. Assume that EVERYTHING is interlaced, and only after you do #2 (below), should you decide what you really have.

2. ALWAYS do a separatefields() and only then should you step through the video, one field at a time. If it is progressive, you will see no spatial movement between each even and odd field pair, just the up/down bobbing of the even/odd fields. If it is interlaced, you will see movement between each and every field. If it is telecined, you will see some fields which repeat and others which don't.

3a. If #2 shows that you have telecined film, then use TFM/TDecimate (or other tool of your choice) to recover the original progressive film. NEVER use SelectEvery() to recover the original progressive film from telecined film. You MUST use a tool which can adapt to cadence changes which often happen at scene changes, or where the video has been cut during some operation that was done before you obtained the video. Because of this, SelectEvery() works really well ... until it doesn't.

3b. If #2 shows that you have progressive or simple interlaced film, try to leave it that way, rather than deinterlacing, and only deinterlace if you are going to resize or apply a temporal filter. Deinterlacing ALWAYS degrades the video. Even in 2025, most of you watch interlaced video all the time, and modern TV sets will handle it just fine.

[Lathe]

It's standard 2:3 telecined film.
- Stepping through the frames you see a repetitive pattern of 2 combed frames followed by 3 clean frames.
- or stepping through the fields you see a repetitive 2-3 pattern like aabbbccdddeefff......
Use a scene with motion to see it clearly.

As suggested by Selur just IVTC (inverse telecine, aka detelecine) it to get the original 24fps (23.976fps) progressive film frames back.
TFM() #returns progressive frames at 29.97fps, with repetitive duplicates like ABCDDEFGHH .....
TDecimate() # removes the duplicates, keeping the 23.976fps unique film frames ABCDEFGH.......

Thanks Bro! Yeah, that's pretty much what I've been doing. I looked up about the different modes, and I have to admit Google's AI is REALLY doing a fantastic job at zeroing in on exactly what you have asked! The results explained the differences really well, and apparently mode 6 and 7 are for more rare cases where something is already screwed up or blended. I still don't know precisely in detail what they are doing, but it shows that normally I would just use the default code as you showed above.

I was just kind of curious why Selur suggested to use mode 7 on the specific movie? But hey, thanks to you guys, I'm still learning! :D

[Lathe]

Things I've learned about video like this.

1. ALWAYS ignore any Mediainfo (or other tool's) "interlaced" or "progressive" report. Assume that EVERYTHING is interlaced, and only after you do #2 (below), should you decide what you really have.

2. ALWAYS do a separatefields() and only then should you step through the video, one field at a time. If it is progressive, you will see no spatial movement between each even and odd field pair, just the up/down bobbing of the even/odd fields. If it is interlaced, you will see movement between each and every field. If it is telecined, you will see some fields which repeat and others which don't.

3a. If #2 shows that you have telecined film, then use TFM/TDecimate (or other tool of your choice) to recover the original progressive film. NEVER use SelectEvery() to recover the original progressive film from telecined film. You MUST use a tool which can adapt to cadence changes which often happen at scene changes, or where the video has been cut during some operation that was done before you obtained the video. Because of this, SelectEvery() works really well ... until it doesn't.

3b. If #2 shows that you have progressive or simple interlaced film, try to leave it that way, rather than deinterlacing, and only deinterlace if you are going to resize or apply a temporal filter. Deinterlacing ALWAYS degrades the video. Even in 2025, most of you watch interlaced video all the time, and modern TV sets will handle it just fine.

WOW! That is super frigg'n helpful, thank you mate! :thanks:

Excellent, that will help a lot. I didn't know that you had to do a separate 'separatefields' first and THEN check the video, no wonder I couldn't tell. Perfect, thanks again!

The only thing is I am a bit confused when you say 'fields' as opposed to frames. I KNOW each step is a frame, but I'm not quite sure when you say to check for these things within a 'field'...

[RetsimLegin]

We have to go back to the time when SD video formats were designed, and the world watched on analogue Cathode Ray Tubes.

Classic SD video formats are interlaced. That always applies - whether the original source was shot using a film camera or was shot directly with a video camera. They always consist of either 576 or 480 (PAL/NTSC) horizontal lines which coincide with the physical workings of a cathode ray tube. CRTs scan a single spot of "light" over the screen left to right, top to bottom. The frame rates are either 25fps or 29.97 (PAL/NTSC) fps. I'll get on to 23.976fps later.

On viewing a CRT screen, these frame rates are both so low as to cause extensive visible flickering of the image on viewing as that scanning spot lights up and then fades away ready for the next scan. To reduce this, these formats use interlacing in which the speed of that top-to-bottom scan is doubled, by presenting the odd numbered lines first and then starting over at the top with the even lines. So rather than a single top-to-bottom scan of the entire image, you get two per "frame" and that's less visible as flicker.

These two groups of lines (odd, even) are fields. Each contains a complete picture top to bottom, but each has half the total number of horizontal scan lines (i.e. half the vertical definition).

Here is where it matters. If the original material was shot on film and then telecine'd (which is, in effect, the film presented to some sort of video camera and captured), each of these pairs (odd, even) of fields will have been captured from exactly the same film frame. Each contains exactly the same image from the same frame, but each field has only half the vertical resolution of the whole. Merge them together and you have your complete frame.

However, if that original material was shot using a contemporary video camera, then it will have shot the footage in the same manner as that CRT would display it - odd lines top to bottom, followed by even lines top to bottom, and at either 50 or 59.94 fields per second. Such material is natively interlaced, meaning that after that first field (alternate lines) was captured, any moving objects in the subject will have moved infinitesimally before the second field is captured. Thus the content of the even lines will differ slightly from the odd ones that preceded it.

You can see then that in a "perfect" world, for telecine'd material, simply merging the two fields reconstructs the film frame. Whereas with true video content that would generate a frame in which the content of the two fields may differ slightly, and that is visible as combing on the edges of those objects that moved in the split second between the capture of the two fields.

The world isn't perfect, though. In NTSC land, TVs run at 59.94 fields (=29.97 frames) per second. That's a throwback to early days when TVs were dependent of the mains electricity AC frequency which in NTSC land is nominally 60hz. The .06 difference allows for variation in that nominal frequency.

So - as regards material that was originally captured on film - film cameras run at 24 frames per second. To display 24fps native material at 29.97, it is first shown to the video camera at the imperceptibly slower 23.976fps. To fit that to 29.97 fps, every 5th frame is shown twice (duplicated).

In the digital era (i.e. as with NTSC DVDs) you may get either of:
- true 29.97 fps
- "fake" 29.97 fps in which the actual content is 23.976fps but flags are present in the data to direct the playback device to duplicate every 5th frame.

It's somewhat simpler in PAL land. 24fps film material is "simply" captured at the marginally higher speed of 25 frames (50 fields) per second and shown that way.

Of course, all this gets muddied when things are done after that initial capture.

Filmed material that is later edited or recomposed after capture to video may not retain that original structure. Video content (of either type) that has been converted from NTSC to PAL (or vice versa) likewise. For example - those regular duplicated (every 5th) frames in NTSC land may no longer fall at regular intervals. Hence the potential complexity in detecting these duplicates and removing them.

[johnmeyer]

The only thing is I am a bit confused when you say 'fields' as opposed to frames. I KNOW each step is a frame, but I'm not quite sure when you say to check for these things within a 'field'...When I advised to always first view the video by doing a "SeparateFields()" I meant that you should view the video through a script which contains nothing more than that one operation. The result will be a half-height video which has double the number of "frames." However the resulting frames are actually the individual fields of the original video. As stated in the preceding video, interlaced video (whether SD or HD) shows one moment in time on the odd fields and the next moment in time on the even fields. If you take a snapshot of the entire frame and include both the even and odd fields, you will actually get a snapshot of two different moments in time and this is why you see "teeth" where a thrown ball gets split up into horizontal slices with half the thrown ball ahead of the other half.

In the digital world we can think of the even and odd fields as just two distinct moments in time, but in the original SD analog world every "point" (in quotes because analog didn't have pixels) on every scan line was a slightly later moment in time, so it was a continuous process. This is still important even in today's digital world when dealing with things like a "rolling shutter" which can create some really nasty artifacts if not dealt with correctly.

[Cary Knoop]

In NTSC land, TVs run at 59.94 fields (=29.97 frames) per second. That's a throwback to early days when TVs were dependent of the mains electricity AC frequency which in NTSC land is nominally 60hz. The .06 difference allows for variation in that nominal frequency.

The 59.94 Hz / 29.97 fps rate is not because of AC mains frequency variation allowance.
It is because of the NTSC color subcarrier frequency and the need to avoid visible luma–chroma beat interference when color was added to B&W TV.

[johnmeyer]

The 59.94 Hz / 29.97 fps rate is not because of AC mains frequency variation allowance.
It is because of the NTSC color subcarrier frequency and the need to avoid visible luma–chroma beat interference when color was added to B&W TV.Yes, you are 100% correct. It has nothing to do with the mains 60Hz frequency variations.

[Lathe]

We have to go back to the time when SD video formats were designed, and the world watched on analogue Cathode Ray Tubes.

Classic SD video formats are interlaced. That always applies - whether the original source was shot using a film camera or was shot directly with a video camera. They always consist of either 576 or 480 (PAL/NTSC) horizontal lines which coincide with the physical workings of a cathode ray tube. CRTs scan a single spot of "light" over the screen left to right, top to bottom. The frame rates are either 25fps or 29.97 (PAL/NTSC) fps. I'll get on to 23.976fps later.

On viewing a CRT screen, these frame rates are both so low as to cause extensive visible flickering of the image on viewing as that scanning spot lights up and then fades away ready for the next scan. To reduce this, these formats use interlacing in which the speed of that top-to-bottom scan is doubled, by presenting the odd numbered lines first and then starting over at the top with the even lines. So rather than a single top-to-bottom scan of the entire image, you get two per "frame" and that's less visible as flicker.

These two groups of lines (odd, even) are fields. Each contains a complete picture top to bottom, but each has half the total number of horizontal scan lines (i.e. half the vertical definition).

Here is where it matters. If the original material was shot on film and then telecine'd (which is, in effect, the film presented to some sort of video camera and captured), each of these pairs (odd, even) of fields will have been captured from exactly the same film frame. Each contains exactly the same image from the same frame, but each field has only half the vertical resolution of the whole. Merge them together and you have your complete frame.

However, if that original material was shot using a contemporary video camera, then it will have shot the footage in the same manner as that CRT would display it - odd lines top to bottom, followed by even lines top to bottom, and at either 50 or 59.94 fields per second. Such material is natively interlaced, meaning that after that first field (alternate lines) was captured, any moving objects in the subject will have moved infinitesimally before the second field is captured. Thus the content of the even lines will differ slightly from the odd ones that preceded it.

You can see then that in a "perfect" world, for telecine'd material, simply merging the two fields reconstructs the film frame. Whereas with true video content that would generate a frame in which the content of the two fields may differ slightly, and that is visible as combing on the edges of those objects that moved in the split second between the capture of the two fields.

The world isn't perfect, though. In NTSC land, TVs run at 59.94 fields (=29.97 frames) per second. That's a throwback to early days when TVs were dependent of the mains electricity AC frequency which in NTSC land is nominally 60hz. The .06 difference allows for variation in that nominal frequency.

So - as regards material that was originally captured on film - film cameras run at 24 frames per second. To display 24fps native material at 29.97, it is first shown to the video camera at the imperceptibly slower 23.976fps. To fit that to 29.97 fps, every 5th frame is shown twice (duplicated).

In the digital era (i.e. as with NTSC DVDs) you may get either of:
- true 29.97 fps
- "fake" 29.97 fps in which the actual content is 23.976fps but flags are present in the data to direct the playback device to duplicate every 5th frame.

It's somewhat simpler in PAL land. 24fps film material is "simply" captured at the marginally higher speed of 25 frames (50 fields) per second and shown that way.

Of course, all this gets muddied when things are done after that initial capture.

Filmed material that is later edited or recomposed after capture to video may not retain that original structure. Video content (of either type) that has been converted from NTSC to PAL (or vice versa) likewise. For example - those regular duplicated (every 5th) frames in NTSC land may no longer fall at regular intervals. Hence the potential complexity in detecting these duplicates and removing them.

Wow! Lovely and thorough explanation, thank you Sir! I will indeed ponder this and learn! :D

[Lathe]

When I advised to always first view the video by doing a "SeparateFields()" I meant that you should view the video through a script which contains nothing more than that one operation. The result will be a half-height video which has double the number of "frames." However the resulting frames are actually the individual fields of the original video. As stated in the preceding video, interlaced video (whether SD or HD) shows one moment in time on the odd fields and the next moment in time on the even fields. If you take a snapshot of the entire frame and include both the even and odd fields, you will actually get a snapshot of two different moments in time and this is why you see "teeth" where a thrown ball gets split up into horizontal slices with half the thrown ball ahead of the other half.

In the digital world we can think of the even and odd fields as just two distinct moments in time, but in the original SD analog world every "point" (in quotes because analog didn't have pixels) on every scan line was a slightly later moment in time, so it was a continuous process. This is still important even in today's digital world when dealing with things like a "rolling shutter" which can create some really nasty artifacts if not dealt with correctly.

Oh, I see... So just running SeparateFields() and then looking at the results I would go frame be frame and look for what you had said, I think I got it...

[wonkey_monkey]

So - as regards material that was originally captured on film - film cameras run at 24 frames per second. To display 24fps native material at 29.97, it is first shown to the video camera at the imperceptibly slower 23.976fps. To fit that to 29.97 fps, every 5th frame is shown twice (duplicated).



Every fourth frame would need to be shown twice (it would be both the fourth and fifth video frames), but in fact it's every fourth field which is shown twice. You get two fields from one film frame, making the first video frame, then you get two fields from the next film frame to make the next video frame, but then the next video frame consists of fields from separate film frames.

If the film frames are A, B, C, D... then the video frames you get go like this:

AA, BB, BC, CD, DD, EE, FF, FG, GH, HH...

(You could also say "every fifth [output] field is a duplicate [of an earlier one]", but "every fifth field is duplicated" is misleading)

[RetsimLegin]

Every fourth frame would need to be shown twice (it would be both the fourth and fifth video frames), but in fact it's every fourth field which is shown twice. You get two fields from one film frame, making the first video frame, then you get two fields from the next film frame to make the next video frame, but then the next video frame consists of fields from separate film frames.

If the film frames are A, B, C, D... then the video frames you get go like this:

AA, BB, BC, CD, DD, EE, FF, FG, GH, HH...

(You could also say "every fifth [output] field is a duplicate [of an earlier one]", but "every fifth field is duplicated" is misleading)

I'll concede that I misphrased that. Yes - every 5th frame is a duplicate of its predecessor. I won't concede that in fact it's fields that are presented in this way; it may be true in some cases, but at least for every film-sourced content I have ever investigated and converted to its true frame rate, progressive, it has been frames that were duplicated.

[Cary Knoop]

The standard, historically correct telecine process is 3:2 pulldown, and it is performed at the field level, not by duplicating whole frames.

- Original film runs at 24 fps, slowed to 23.976 fps for NTSC compatibility.
- Output video is 59.94 interlaced fields per second (29.97 frames, each containing two fields).
- The telecine cadence duplicates fields in a repeating 3-2 pattern.

If you label film frames A, B, C, D, … the output fields look like:

A A B B B C C D D D E E ...
2 3 2 3 2 (fields per film frame)

When those fields are paired back into video frames, the visible sequence becomes:

AA, BB, BC, CD, DD, EE, FF, FG, GH, HH ...

This is the standard and expected structure for film material on NTSC video.
It is fully reversible by IVTC to recover the original progressive 23.976 fps frames with no quality loss.

There are other ways to convert 24→29.97, but they are not “telecine” in the traditional sense:

Whole-frame duplication (progressive but introduces periodic motion stutter).

Frame blending (worst case: smeared motion and ghosting).

These alternatives appear mostly in consumer transfers, poorly mastered DVDs, and low-quality re-encodes. They are not part of professional broadcast workflows.

[johnmeyer]

Yup, it is fields, not frames, which are duplicated.

I've worked on a LOT of telecined film, much of it from historical sources. Anything produced prior prior to digital video (i.e., before late 1990s) is converted from film to video at the field level. But here's the important point: given how NTSC analog video is designed, it actually could not work any other way because there is no such thing as a frame in NTSC analog video.

[edit]Another key thing to understand is that when you duplicate anything, you end up with a result which is not perfectly smooth. If you were to duplicate an entire frame, you would double the temporal interruption, thus making the resulting video even more jumpy and jerky. That is why it is always done at the field (1/60 of a second duplication) rather than frame (1/30 of a second).

[Selur]

side note: aside from looking at fields, one could also bob and then look at patterns&co ([url=https://forum.selur.net/thread-3010.html][INFO] Interlacing patterns[/url|); personally, I sometimes look at the fields and sometimes at the bobbed frames and both ways work fine for me.

[Lathe]

The standard, historically correct telecine process is 3:2 pulldown, and it is performed at the field level, not by duplicating whole frames.

- Original film runs at 24 fps, slowed to 23.976 fps for NTSC compatibility.
- Output video is 59.94 interlaced fields per second (29.97 frames, each containing two fields).
- The telecine cadence duplicates fields in a repeating 3-2 pattern.

If you label film frames A, B, C, D, … the output fields look like:

A A B B B C C D D D E E ...
2 3 2 3 2 (fields per film frame)

When those fields are paired back into video frames, the visible sequence becomes:

AA, BB, BC, CD, DD, EE, FF, FG, GH, HH ...

This is the standard and expected structure for film material on NTSC video.
It is fully reversible by IVTC to recover the original progressive 23.976 fps frames with no quality loss.

There are other ways to convert 24→29.97, but they are not “telecine” in the traditional sense:

Whole-frame duplication (progressive but introduces periodic motion stutter).

Frame blending (worst case: smeared motion and ghosting).

These alternatives appear mostly in consumer transfers, poorly mastered DVDs, and low-quality re-encodes. They are not part of professional broadcast workflows.

Excellent information, thank you!

[Lathe]

side note: aside from looking at fields, one could also bob and then look at patterns&co ([url=https://forum.selur.net/thread-3010.html][INFO] Interlacing patterns[/url|); personally, I sometimes look at the fields and sometimes at the bobbed frames and both ways work fine for me.

Thank you Selur, this stuff sure can be tricky!

[wonkey_monkey]

3:3:2:2 is used sometimes as well; it can be converted back to 24p just by deleting the interlaced frames, without having to reconstruct some frames using fields in different frames:

AA AB BB CC DD EE EF FF GG HH

[Lathe]

3:3:2:2 is used sometimes as well; it can be converted back to 24p just by deleting the interlaced frames, without having to reconstruct some frames using fields in different frames:

AA AB BB CC DD EE EF FF GG HH

The really tricky part is trying to figure out exactly what it is doing so that you can choose the right method to undo it... So, in this case, assuming I can figure out if it exists, what would I use to undo it, the simple TFM() TDecimate() or something else in this case? Thanks!

[johnmeyer]

TFM() followed by TDecimate(), without any special settings, works for a large percentage of cases. Try it, and then look at the results, using the same steps I outlined above. When looking at the fields of the video that results from TFM/TDecimate, you should see two fields with no temporal movement, followed by two more matching fields, etc. There should be no more residual duplicates (i.e., three or more fields in a row without temporal movement) and there should be no single fields with temporal movement between either the preceding or succeeding field.

[Lathe]

TFM() followed by TDecimate(), without any special settings, works for a large percentage of cases. Try it, and then look at the results, using the same steps I outlined above. When looking at the fields of the video that results from TFM/TDecimate, you should see two fields with no temporal movement, followed by two more matching fields, etc. There should be no more residual duplicates (i.e., three or more fields in a row without temporal movement) and there should be no single fields with temporal movement between either the preceding or succeeding field.

Awesome! I'm glad that the one thing works for most, which so far in doing my old movies and recordings seems to do pretty well so far.

I wonder why Selur recommended mode 7 on the clip above though... Was there something where you could tell it needed that special touch? Just curious so I can continue to understand... Considering your explanation above, I would ASSume then that that clip did NOT look like you were describing above how it should look, with some 'Frames/Fields' still with motion/blurring perhaps...

[Lathe]

This snippet is taken from a Laserdisc, I can't believe I'm finding some great prints of these really super obscure but excellent Telefilms! It is progressive, but there is a bit of jerky motion here and there.

Any thoughts? Thank You!

http://lathe-of-heaven.com/Sketch.Artist.II.Snippet.mkv

[wonkey_monkey]

This snippet is taken from a Laserdisc, I can't believe I'm finding some great prints of these really super obscure but excellent Telefilms! It is progressive, but there is a bit of jerky motion here and there.

Any thoughts? Thank You!

http://lathe-of-heaven.com/Sketch.Artist.II.Snippet.mkv

Have you already run that through filters? Because it's 23.976fps, so it can't be a raw capture from Laserdisc.

[johnmeyer]

Have you already run that through filters? Because it's 23.976fps, so it can't be a raw capture from Laserdisc.Absolutely correct.

[Selur]

I wonder why Selur recommended mode 7 on the clip above though..
I wasn't sure the pattern is stable and then mode 7 usually is a good bet.

[Lathe]

I wasn't sure the pattern is stable and then mode 7 usually is a good bet.

Ah, I see, thank you Sir!

[Lathe]

Have you already run that through filters? Because it's 23.976fps, so it can't be a raw capture from Laserdisc.

Hmmm, no... So, what filters should I run it through first, the SeparateFields() one? I just know it's different from the DVD rips and that it shows supposedly as progressive, but I don't really quite know what to do with it.

[real.finder]

3b. If #2 shows that you have progressive or simple interlaced film, try to leave it that way, rather than deinterlacing, and only deinterlace if you are going to resize or apply a temporal filter. Deinterlacing ALWAYS degrades the video. Even in 2025, most of you watch interlaced video all the time, and modern TV sets will handle it just fine.

well, you can use QTGMC( SourceMatch=3, Lossless=1 ) to preserves the original fields so you can deinterlace it later if there will be something better

[wonkey_monkey]

Hmmm, no... So, what filters should I run it through first, the SeparateFields() one? I just know it's different from the DVD rips and that it shows supposedly as progressive, but I don't really quite know what to do with it.

You shouldn't run it through any, if you're trying to provide sample so that we can try and determine what the best filters to use on it are.

What you posted can't be an accurate representation of a laserdisc rip; there's no such thing as 23.976fps laserdisc video. It can only be 25fps (interlaced, but might look progressive) or 29.97fps (interlaced, would always have some interlaced frames).

Something between the laserdisc output and your upload has converted it.

[Lathe]

well, you can use QTGMC( SourceMatch=3, Lossless=1 ) to preserves the original fields so you can deinterlace it later if there will be something better

I've never gotten the QTGMC to work, I'll look into it...

[Lathe]

You shouldn't run it through any, if you're trying to provide sample so that we can try and determine what the best filters to use on it are.

What you posted can't be an accurate representation of a laserdisc rip; there's no such thing as 23.976fps laserdisc video. It can only be 25fps (interlaced, but might look progressive) or 29.97fps (interlaced, would always have some interlaced frames).

Something between the laserdisc output and your upload has converted it.

No, I see what you mean, but I 'acquired' the file as is, so I of course have NO idea what was done to it. That's the point and why I posed the snippet. I understand that done 'Properly' it should not be that way, but since it is... What do I do with it...? :)

[Cary Knoop]

It is pretty much foobar at this stage and to add insult to injury the encoding is Xvid.

Use a high-grade LaserDisc player using S-Video or composite (S-Video is normally but not always better!)
Feed the analog output through a full-frame TBC to correct horizontal jitter and stabilize sync.
Capture the signal as lossless or near-lossless 4:2:2 (YUY2) at 720x480 with levels preserved (ensure WTW/BTB are not clipped).
Do not deinterlace or filter during capture.

[Lathe]

It is pretty much foobar at this stage and to add insult to injury the encoding is Xvid.

Use a high-grade LaserDisc player using S-Video or composite (S-Video is normally but not always better!)
Feed the analog output through a full-frame TBC to correct horizontal jitter and stabilize sync.
Capture the signal as lossless or near-lossless 4:2:2 (YUY2) at 720x480 with levels preserved (ensure WTW/BTB are not clipped).
Do not deinterlace or filter during capture.

Hey, I really appreciate the input, but I am not set up to convert from Laserdisc, I don't even have any. This file was 'acquired' As Is, I just want to know if there is anything I should do with it.

[Lathe]

Here is another curious one... This is a VHSrip. I did not do the rip, I got it from the Internet Archive which is allowed. What is odd is that MediaInfo shows it as (Telecined?) at 29.xxx FPS, however when stepping through the video I don't see any blurring or combing whatsoever. Is that possible? Thank you!

http://lathe-of-heaven.com/Vampire.1979.VHSripSnippet.mkv

***EDIT

Okay, I went ahead and DeTelecined it as usual and sharpened it a little, but other than the sharpening it doesn't look that different. I'm THINKING that since the original snippet above did not comb or blur that DeTelecining it was unnecessary and likely didn't help. But, I can't tell.

Any thoughts...?

http://lathe-of-heaven.com/VampireEncode.mkv

[Selur]

I don't see that it is indicated as telecine (= 3:2 Pulldown) when analyzed by MediaInfo:
F:\Hybrid\64bit>MediaInfo.exe --Full c:\Users\Selur\Desktop\Vampire.1979.VHSripSnippet.mkv
General
Count : 359
Count of stream of this kind : 1
Kind of stream : General
Kind of stream : General
Stream identifier : 0
Unique ID : 2195702403259729417073045580128253602
Unique ID : 2195702403259729417073045580128253602 (0x1A6E07C912089B855542910AA78F6A2)
Count of video streams : 1
Count of audio streams : 1
Video_Format_List : AVC
Video_Format_WithHint_List : AVC
Codecs Video : AVC
Audio_Format_List : AC-3
Audio_Format_WithHint_List : AC-3
Audio codecs : AC-3
Audio_Channels_Total : 2
Complete name : c:\Users\Selur\Desktop\Vampire.1979.VHSripSnippet.mkv
Folder name : c:\Users\Selur\Desktop
File name extension : Vampire.1979.VHSripSnippet.mkv
File name : Vampire.1979.VHSripSnippet
File extension : mkv
Format : Matroska
Format : Matroska
Format/Url : https://matroska.org/downloads/windows.html
Format/Extensions usually used : mkv mk3d mka mks
Commercial name : Matroska
Format version : Version 4
File size : 7313950
File size : 6.98 MiB
File size : 7 MiB
File size : 7.0 MiB
File size : 6.98 MiB
File size : 6.975 MiB
Duration : 48146
Duration : 48 s 146 ms
Duration : 48 s 146 ms
Duration : 48 s 146 ms
Duration : 00:00:48.146
Duration : 00:00:48;02
Duration : 00:00:48.146 (00:00:48;02)
Overall bit rate : 1215295
Overall bit rate : 1 215 kb/s
Frame rate : 29.970
Frame rate : 29.970 FPS
Frame count : 1442
Stream size : 18646
Stream size : 18.2 KiB (0%)
Stream size : 18 KiB
Stream size : 18 KiB
Stream size : 18.2 KiB
Stream size : 18.21 KiB
Stream size : 18.2 KiB (0%)
Proportion of this stream : 0.00255
IsStreamable : Yes
Title : Vampire. 1979. VHSRIP. XVi D CG : Free Download, Borrow, and Streaming : Internet Archive
Movie name : Vampire. 1979. VHSRIP. XVi D CG : Free Download, Borrow, and Streaming : Internet Archive
Encoded date : 2025-11-07 05:32:34 UTC
File creation date : 2025-11-07 08:05:34.263 UTC
File creation date (local) : 2025-11-07 09:05:34.263
File last modification date : 2025-11-07 08:05:34.944 UTC
File last modification date (local) : 2025-11-07 09:05:34.944
Writing application : mkvmerge v89.0 ('And the Melody Still Lingers On (Night in Tunisia)') 64-bit
Writing application : mkvmerge 89.0 ('And the Melody Still Lingers On (Night in Tunisia)') 64-bit
Encoded_Application_Name : mkvmerge
Encoded_Application_Version : 89.0 ('And the Melody Still Lingers On (Night in Tunisia)') 64-bit
Writing library : libebml v1.4.5 + libmatroska v1.7.1
Writing library : libebml v1.4.5 + libmatroska v1.7.1

Video
Count : 398
Count of stream of this kind : 1
Kind of stream : Video
Kind of stream : Video
Stream identifier : 0
StreamOrder : 0
ID : 1
ID : 1
Unique ID : 10605709482477499492
Format : AVC
Format : AVC
Format/Info : Advanced Video Codec
Format/Url : http://developers.videolan.org/x264.html
Commercial name : AVC
Format profile : Constrained Baseline@L3
Format settings : 1 Ref Frames
Format settings, CABAC : No
Format settings, CABAC : No
Format settings, Reference frames : 1
Format settings, Reference frames : 1 frame
Internet media type : video/H264
Codec ID : V_MPEG4/ISO/AVC
Codec ID/Url : http://ffdshow-tryout.sourceforge.net/
Duration : 48114.000000
Duration : 48 s 114 ms
Duration : 48 s 114 ms
Duration : 48 s 114 ms
Duration : 00:00:48.114
Duration : 00:00:48;02
Duration : 00:00:48.114 (00:00:48;02)
Bit rate : 764806
Bit rate : 765 kb/s
Width : 640
Width : 640 pixels
Height : 480
Height : 480 pixels
Sampled_Width : 640
Sampled_Height : 480
Pixel aspect ratio : 1.000
Display aspect ratio : 1.333
Display aspect ratio : 4:3
Frame rate mode : CFR
Frame rate mode : Constant
FrameRate_Mode_Original : VFR
Frame rate : 29.970
Frame rate : 29.970 FPS
Frame count : 1442
Color space : YUV
Chroma subsampling : 4:2:0
Chroma subsampling : 4:2:0
Bit depth : 8
Bit depth : 8 bits
Scan type : Progressive
Scan type : Progressive
Bits/(Pixel*Frame) : 0.083
Delay : 1
Delay : 1 ms
Delay : 1 ms
Delay : 1 ms
Delay : 00:00:00.001
Delay : 00:00:00;00
Delay : 00:00:00.001 (00:00:00;00)
Delay, origin : Container
Delay, origin : Container
Stream size : 4599736
Stream size : 4.39 MiB (63%)
Stream size : 4 MiB
Stream size : 4.4 MiB
Stream size : 4.39 MiB
Stream size : 4.387 MiB
Stream size : 4.39 MiB (63%)
Proportion of this stream : 0.62890
Default : Yes
Default : Yes
Forced : No
Forced : No

Audio
Count : 298
Count of stream of this kind : 1
Kind of stream : Audio
Kind of stream : Audio
Stream identifier : 0
StreamOrder : 1
ID : 2
ID : 2
Unique ID : 5253985232306056446
Format : AC-3
Format : AC-3
Format/Info : Audio Coding 3
Format/Url : https://en.wikipedia.org/wiki/AC3
Commercial name : Dolby Digital
Commercial name : Dolby Digital
Format settings, Endianness : Big
Codec ID : A_AC3
Duration : 48136.000000
Duration : 48 s 136 ms
Duration : 48 s 136 ms
Duration : 48 s 136 ms
Duration : 00:00:48.136
Duration : 00:00:48.136
Bit rate mode : CBR
Bit rate mode : Constant
Bit rate : 448000
Bit rate : 448 kb/s
Channel(s) : 2
Channel(s) : 2 channels
Channel positions : Front: L R
Channel positions : 2/0/0
Channel layout : L R
Samples per frame : 1536
Sampling rate : 44100
Sampling rate : 44.1 kHz
Samples count : 2122798
Frame rate : 28.711
Frame rate : 28.711 FPS (1536 SPF)
Frame count : 1382
Compression mode : Lossy
Compression mode : Lossy
Delay : 11
Delay : 11 ms
Delay : 11 ms
Delay : 11 ms
Delay : 00:00:00.011
Delay : 00:00:00.011
Delay, origin : Container
Delay, origin : Container
Delay relative to video : 10
Delay relative to video : 10 ms
Delay relative to video : 10 ms
Delay relative to video : 10 ms
Delay relative to video : 00:00:00.010
Delay relative to video : 00:00:00.010
Stream size : 2695568
Stream size : 2.57 MiB (37%)
Stream size : 3 MiB
Stream size : 2.6 MiB
Stream size : 2.57 MiB
Stream size : 2.571 MiB
Stream size : 2.57 MiB (37%)
Proportion of this stream : 0.36855
Service kind : CM
Service kind : Complete Main
Default : Yes
Default : Yes
Forced : No
Forced : No
bsid : 8
Dialog Normalization : -31
Dialog Normalization : -31 dB
dsurmod : 0
acmod : 2
lfeon : 0
dialnorm_Average : -31
dialnorm_Average : -31 dB
dialnorm_Minimum : -31
dialnorm_Minimum : -31 dB
dialnorm_Maximum : -31
dialnorm_Maximum : -31 dB
dialnorm_Count : 504
=> did you look at a different file?

[Lathe]

I don't see that it is indicated as telecine (= 3:2 Pulldown) when analyzed by MediaInfo:

=> did you look at a different file?

Good point Selur, thank you! I guess I saw the usual 29.xxx and just assumed that it was like all the others. I didn't know that you could have a 29.xxx framerate and it still be progressive and not telecined. I just learned something new! :D

So, I guess I don't really have to do anything with it. Also too, some here have mentioned quite strongly NOT to go by what MediaInfo shows, that it can be inaccurate, so I don't know how far that goes...

***EDIT

Also too... any suggestions about what I can do to improve this one, the faces look so waxy, is there anything to improve that. I suppose just some sharpening and I don't know what else.

Also, any suggestions as to what to do with the Laserdisc snippet above too would be awesome, thanks!

[Selur]

Vampire.1979.VHSripSnippet: unless you use something like CodeFormer or similar there you won't get any details, since there are none in the source. (too high compressed; look at it with Retinex applied to better see all the compression artifacts)
https://i.ibb.co/f57yh8B/grafik.png (https://ibb.co/nvSYH3Z)
with Retinex + CodeFormer:
https://i.ibb.co/n87VBGBW/grafik.png (https://ibb.co/vv3rhFht)
https://i.ibb.co/23GXkMFj/grafik.png (https://ibb.co/Df03RM17)
https://i.ibb.co/V0cXJH2n/grafik.png (https://ibb.co/TDxzYKmj)
https://i.ibb.co/DHbBybqN/grafik.png (https://ibb.co/cSvWHvmP)
https://i.ibb.co/NgWDsMpZ/grafik.png (https://ibb.co/fVr62st4)
https://i.ibb.co/wZxjjrxV/grafik.png (https://ibb.co/fVPLLGPf)
https://i.ibb.co/VYgB0gKL/grafik.png (https://ibb.co/QvPm7P5J)
(maybe diffusion based machine learning stuff might work better,...)

All in all, you can't really do much to 'improve' such content.

Restoration and similar, starting from a highly compressed source, is usually a fool's errant. (or work that has to be done nearly frame-by-frames, which usually isn't worth the effort)

Cu Selur

Ps.: aside from Retinex another thing it to throw DetailSharpen or FineSharpen at it to see where you can get. (both will usually cause additional artifacts, but allow to see how much detail are potentially there,..)
PPs.: and 'No', there currently isn't and filter or similar that can 'undo' blend deinterlacing.