TDeint and TIVTC

[flossy_cake]

Thought this was an interesting comparison on a motion scene

BWDIF
https://i3.lensdump.com/i/RR0lV0.png

BWDIF with edeint=nnedi3 (I believe this uses nnedi3 pixels for interpolated pixels, but I'm not 100% sure)
https://i.lensdump.com/i/RR0znD.png

IVTC original frame
https://i1.lensdump.com/i/RR0S5q.png

Note: to help visualise detail & aliasing I added the same amount of sharpening to all 3, then zoomed in 200% nearest neighbour

[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

Here's an updated version which handles the combing detection issue with a latching system where if a scene contains 4 or more combed frames, the remainder of the scene is treated as combed until the next scene at which point the latch is reset.

Here is the PAL equivalent version, useful for DVD's containing mostly 2:2 with the occasional 1:1 section. I say "occasional" as I wouldn't use it on predominantly 1:1 content since every new scene starts with the assumption that the content is not 1:1 (i.e not combed) and it has to detect a combed frame before it switches to mocomp deinterlacing (bwdif) and this delay is not totally unnoticeable given IsCombedTIVTC is not perfect at immediately detecting slight combing. To mitigate this I'm working on a system to try and "learn" the content type based on the last n scenes. eg. if the last n scenes were combed, then start with the assumption the next scene is combed, and only switch back to "assume not combed" if there are q noncombed frames in a row with motion above threshold t.

Test clip: https://drive.google.com/file/d/1vnk...ew?usp=sharing

# Convert 25i to 50p
# 2:2 sections weaved/TFM'd to 25p and frame doubled to 50p
# 1:1 sections bwdif'd to 50p


global isCleanPAL = true	# set false for 'dirty' 2:2 content with field offset eg. cheese slices or the office pre-pilot episode
global sceneThresh = 35		# for darker low-APL content, use a lower value eg. 25 
global showDebug = true		# seems to consume a lot of Avisynth resources, so turn it off if you get dropped frames in real-time use
global isCombed = false
global combedCount = 0
global yDiff = 0
global lastScene = 0
global lastSceneYDiff = 0
global lastFrameNum = 0
global latchDeint = false


clip = "https://drive.google.com/file/d/1vnkI505_OOUOYJ9QVh89WDtkFHiugbOF/view?usp=sharing"

global orig 		= LWLibavVideoSource(source=clip, stream_index=-1, repeat=true, cache=false)
global orig_double 	= orig.ChangeFPS(50000, 1000)
global bwdif_double	= bwdif(orig, field=-2, thr=2)			
global tfm_double	= TFM(orig, order=-1, mode=0, PP=0, cthresh=9, MI=80, scthresh=100,
			\ slow=2, ubsco=true, mmsco=true, micmatching=1, display=false).ChangeFPS(50000, 1000)


Select(orig_double)

function Select(clip c)
{
	c = ScriptClip(c, 
	\ """
	
		global yDiff = YDifferenceToNext(isCleanPAL ? orig_double : tfm_double, -2)
			
		# increase sensitivity of combed frame detection when almost no movement
		# - helps prevent combing on eyelids & mouths on static shots of talking heads
		global isCombed = IsCombedTIVTC(isCleanPAL ? orig_double : tfm_double, 
						\ cthresh 	= (yDiff >= 2.0) ? 9 : 9 ,
						\ MI 		= (yDiff >= 2.0) ? 64 : 32 )
						
					
		if (yDiff > sceneThresh || current_frame > lastFrameNum+2 || current_frame < lastFrameNum-2 ){ 
			global latchDeint = false
			global lastScene = current_frame
			global lastSceneYDiff = yDiff
			global combedCount = 0
		}
		
		if (isCombed){
			global combedCount = combedCount + 1 
		}
		
		if (!latchDeint && isCombed && combedCount >= 1){
			global latchDeint = true
		}
		
		global lastFrameNum = current_frame
	
		if (showDebug){
			debug = "frame: " + String(current_frame) + "\n" + "yDiff: " + String(yDiff)
			\ + "\n" + "isCombed: " + String(isCombed) + "\n" + "combedCount: " + String(combedCount)
			\ + "\n" + "latchDeint: " + String(latchDeint) + "\n" + "lastScene: " + String(lastScene)
			\ + " (" + String(lastSceneYDiff) + ")"
		}
					
		if (latchDeint || isCombed) { 
			if (!showDebug){bwdif_double}
			else {bwdif_double.SubTitle("BWDIF\n"+debug,font="courier new",size=24,lsp=10)}
		}
		else { 			
			if (isCleanPAL){
				if (!showDebug){orig_double}
				else {orig_double.SubTitle("ORIG\n"+debug,font="courier new",size=24,lsp=10)}
			}
			else {
				if (!showDebug){tfm_double}
				else {tfm_double.SubTitle("TFM\n"+debug,font="courier new",size=24,lsp=10)}		
			}
		}
		
		
		
	\ """ , after_frame=true)
	
	return c
}

edit: updated to force a scene change on seek

edit: also the sceneThresh value should be set depending on the overall brightness of the content. eg. a brighter lit show like The Office has scene changes around a value of 40-50 while a darker dimly lit show like Garth Marenghi's Darkplace will be lower, maybe 20-30.

edit: btw the internal shots in that test clip (The Office) are supposed to be field resolution (288p) -- that's not TFM stuffing anything up. It was shot at 576i and every 2nd field was discarded to make 576p25 from it (field1 is actually a slightly blurred copy of field2... some kind of CRT deflicker filter I imagine... can sharpen it up by using nnedi3 "keep bottom field".. but then the intro sequence will be worse since that is full 576p25 resolution)

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

Here's an unusual clip
https://drive.google.com/file/d/11u7...ew?usp=sharing

[flossy_cake]

After some extensive tinkering this week with TFM, BWDIF & ScriptClip and gaining some more knowledge on various types of content, I plan to create some deinterlacing presets for PAL content, then later on some NTSC presets.

Nomenclature

1:1 = each field is a unique image from a new moment in time, aka "video" content. Not equivalent to "combed" as a frame can be combed and not necessarily 1:1.
2:2 = a pair of 2 fields makes a unique progressive image, aka "film" content. Includes cases where field order is offset eg. bottom field of frame A matches with top field of frame B (eg. The Office pre-pilot clip, Cheese Slices clip)

Presets in order from film-centric to video-centric

Preset name: PAL_FILM
Useful for: purely 2:2 content, eg. PAL movies, The Office Pre-pilot, Cheese Slices
Implementation: TFM only
Pros: maximum progressive resolution
Cons: doesn't handle 1:1 sections at all (they will just remain combed)

Preset name: PAL_VIDEO_LOW
Useful for: 2:2-centric content with the occasional 1:1 scene, eg. The Office, Garth Marenghi's Darkplace
Implementation: smart select between TFM & BWDIF based on whether the output of TFM is 1:1 (combed). A hysteresis characteristic ("latching") is used so that if a single combed frame comes out of TFM, BWDIF will stay in effect for the remainder of that scene.
Pros: keeps 1:1 sections at full framerate (50p) with minimal/rare combing artefacts, good retention of progressive resolution on 2:2 sections
Cons: 2:2 sections can potentially get falsely detected as 1:1 due to false positives from IsCombedTIVTC metric, causing resolution to needlessly drop to half on motion (static stuff will still get weaved though, so all is not lost). Also, if the beginning of any 1:1 scene has extremely small amounts of motion, eg. a talking head sitting perfectly still and blinking, this won't be enough motion to detect as 1:1 and you may see their eyelids comb.

Preset name: PAL_VIDEO_MEDIUM
Useful for: a random mix of 2:2 and 1:1 content, eg. broadcast TV
Implementation: Same as PAL_VIDEO_LOW but with stronger hysteresis characteristic: the BWDIF latch will stay latched until n frames of 2:2 *motion* start coming out of TFM.
Pros: minimises the blinking eyelids issue with PAL_VIDEO_LOW as that would only happen if that scene directly followed a 2:2 scene
Cons: transition from a 1:1 scene to a 2:2 talking head scene may not switch back to TFM fast enough due to not enough motion in the talking head - you will have to wait until there is a bit of motion before full progressive resolution is obtained.

Preset name: PAL_VIDEO_HIGH
Useful for: predominantly 1:1 content, eg. The IT Crowd, Fawlty Towers, Mr Bean
Implementation: BWDIF only
Pros: handles 1:1 and 2:2 sections at full frame rate without any possibility of combing artefacts
Cons: half resolution on 2:2 sections with motion

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

[flossy_cake]

Originally Posted by flossy_cake

I plan to create some deinterlacing presets for PAL content, then later on some NTSC presets.

Haven't gotten around to this due to IRL issues, but I have optimised the PAL one a bit. Notably by increasing the sensitivity of detecting combed frames when there is very little motion, which seems to resolve the issue with combed mouths and eyelids on static talking head scenes since those will switch to BWDIF more quickly. Also added 'isCleanPAL' boolean which defaults to true which means the field order of the content is not offset like in cheese slices or office pre-pilot. For content like that, set it to false. Actually it should be fine with false for everything given the increased combed frame detection on low motion solves that too, but just in case, since the output on TFM on 1:1 sections with very little motion can sometimes be stuttery due to TFM getting confused about whether fields match or not, and you wouldn't want it switching to the TFM stream in those cases, and TFM is only necessary for cheese slices type content which the vast majority of PAL content isn't.