Cartoon video sample neither 3:2 nor 100% interlaced? IVTC/Deint help

[videobackup]

Thanks!

https://www.mediafire.com /file/fwj7a8qqgsgy7fq/ Untitled+01testsample.7z/file (delete spaces)

YUV v210 29.970 capture from NTSC broadcast 1080i, trying to encode to 10 bit 4:2:2 x265 1080p 24/1001 fps. I've just been using Staxrip with AVS filters to accomplish all video processing, while using VDub64 to preview and compare.

My TIVTC settings (using TFM and TDecimate) work for the 3:2 pulldown type shows I've captured and encoded, but this show has way more interlacing and those settings don't work. Yet it doesn't seem to be totally interlaced video I think?
I read a guide about using vdub and frame-by-frame advance to try to determine if a video is 3:2 or totally interlaced, by that method it didn't seem either 3:2 or totally interlaced to me, but I might have misunderstood.

Also the deinterlacing filters and settings I've tried make lots of parts of the image look jagged compared to the original. I've read the wiki pages for AVS filters and some guides, which led me also to try TDeint. TDeint makes the image less jagged but used on its own the resulting video is all one image per frame, wrong timing for source material.

Could be mistaken but unless someone has a method with better picture quality I guess I should use some combination of TFM, TDecimate and TDeint?

First settings tried were:
TFM(order=1, mode=7, pp=7, field=1, slow=2)
TDecimate(mode=1)

Got jagged type corruption throughout frames and the frame rate compared to original was wrong (images supposed to hold for 2-4 frames were shortened)

Second try was:

TDeint(mode=2,order=1,mtnmode=3,blim=100)
Less jagged than other method (though still noticable, can that be improved?) but it created a video where each image was one frame, totally incorrect timing.


If it matters my goal is picture/playback quality, so if any filter based deinterlacing is definitely going to degrade quality would it be a better idea to just encode it as an interlaced 29.97 x264 (instead of x265 since apprently there's less interlaced support) and just watch it with hardware/display deinterlacing instead?

Thanks very much

[davexnet]

Is that clip the source or something you encoded?
Assuming it's the source, just

LWLibAVVideoSource(...)
tfm().tdecimate()

looks ok. Probably could do with some filtering, but I'm not sure what's available for 10 bit

[jagabo]

It's normal 3:2 pulldown, bff. A simple TFM().TDecimate() worked for me. (The motion seems overly fast though.) The previous compression was such bad quality you're left with quantization artifacts that look like residual combing. You can use a filter like vInverse() or Blur(0.0, 1.0).Sharpen(0.0, 0.7) to get rid of it.

[Selur]

Using waifu2x and lowering the fps to 15 and the result isn't that bad.
(I agree normal tfm().tdecimate() is the way to go)

Cu Selur

[videobackup]

Thanks!

Normal TFM/Tdecimate timing looks fine to me, thanks for suggesting that.
I guess I added some wrong option to it? I was trying to add the settings that would increase quality.


There are still some problems though.

During opening (before sample clip starts) there's a part where the scene comes into view starting blank then a small circuler view widens from the center until full scene visible.
The processing doesn't handle this and deletes a frame of animation from that transition without preserving any fields of that image.
maybe there's a setting I can try? I used slow=2 on TFM, that didn't help.



Next is that when I use VDub's deinterlacing filter to double framerate and preview field by field, then compare the two field images against each single frame in the TFM filtered file, it looks like TFM/TDec copies the field with more pixelation and artifacts.

What's weird though is that even when one field is overall best, there are still some places the worse field of the two is a little better.
So instead of just keeping one field of two is there any filter or setting that will try to combine the less pixelated artifacty parts from both of the two fields?


Thanks again for suggestions.
Just in case though, if I do nothing except compress it as interlaced x264 with the correct field order, MPC output to a compatible TV @ 1080i should play that back same as it plays source?

[jagabo]

During opening (before sample clip starts) there's a part where the scene comes into view starting blank then a small circuler view widens from the center until full scene visible.
The processing doesn't handle this and deletes a frame of animation from that transition without preserving any fields of that image.
maybe there's a setting I can try? I used slow=2 on TFM, that didn't help.

There are a few possible causes. Often in opening credits the frame rate is often manipulated to better sync the video and audio. For example, a shot may be sped up from to last 1.0 second to 0.9 second in order for the shot change to fall on a musical beat. That makes is impossible to restore the video to 24 fps without losing frames. Sometimes TDecimate() will choose to keep the wrong frames because the compression noise outweighs the frame change differences.

Next is that when I use VDub's deinterlacing filter to double framerate and preview field by field, then compare the two field images against each single frame in the TFM filtered file, it looks like TFM/TDec copies the field with more pixelation and artifacts.

As noted, sometimes the noise outweighs the frame differences. TDecimate() will delete an original frame in order to keep the extra noisy frame.

What's weird though is that even when one field is overall best, there are still some places the worse field of the two is a little better.
So instead of just keeping one field of two is there any filter or setting that will try to combine the less pixelated artifacty parts from both of the two fields?

Use something like the Blur/Sharpen command I gave earlier.

Just in case though, if I do nothing except compress it as interlaced x264 with the correct field order, MPC output to a compatible TV @ 1080i should play that back same as it plays source?

Yes, aside from the compression artifacts.