TDeint and TIVTC [Archive] - Page 32

flossy_cake

5th October 2022, 10:54

Variable frame rate easier?

# Analysis pass (comment out any filters after TDecimate so they don't run)
# TFM(Output=FTFM()).TDecimate(Mode=4, Hybrid=2, Output=FTDec())

# Encoding pass (uncomment any filters after TDecimate)
TFM(Input=FTFM()).TDecimate(Mode=5, Hybrid=2, Input=FTDec(), TFMIn=FTFM(), mkvOut=FTC())

After some faffing about it seems for my purposes I can just go:

TDecimate(mode=3, hybrid=2, viddetect=2, cycle=5, cycleR=1, mkvOut="TIMES.txt")

But TDecimate requires "linear access" for mode3 and won't let me call it from ffmpeg. Maybe Virtualdub can manage it?

Anyway I did manage to get ffmpeg crunching with this:

ffmpeg -i "VFRpass1.avs" -threads 4 -f null NUL && ffmpeg -i "VFRpass2.avs" -threads 4 -f null NUL

VFRpass1.avs:
LWLibavVideoSource(source="1112-11.mkv", cache=false)
TDecimate(mode=4, hybrid=2, viddetect=2, cycle=5, cycleR=1, output="FTDEC.txt")

VFRpass2.avs:
LWLibavVideoSource(source="1112-11.mkv", cache=false)
TDecimate(mode=5, hybrid=2, viddetect=2, cycle=5, cycleR=1, input="FTDEC.txt", mkvOut="TIMES.txt")

Skipping the TFM() step doubles my framerate from 150fps to 300fps, and it seems to be working -- the TIMES.txt file it generates is identical. The viddetect=2 is required though. Seems to be something buggy going on with that.

ffmpeg says it supports vfr encoding with "-vsync vfr" but I couldn't get it to work. ffmpeg doesn't seem to support matroska timecode files either but hoping someone can correct me on that.

hello_hello

5th October 2022, 12:21

Skipping the TFM() step doubles my framerate from 150fps to 300fps, and it seems to be working -- the TIMES.txt file it generates is identical. The viddetect=2 is required though. Seems to be something buggy going on with that.

What happens without viddetect=2?

I'm hopeless with ffmpeg so hopefully someone else can help you there. Although....

The first line of the timecodes file should be
# timecode format v1

This is just a guess, but try changing it to
# timestamp format v1
to see if ffmpeg will play with it then.

flossy_cake

5th October 2022, 13:25

What happens without viddetect=2?

Nevermind I was mistaken about that. The default is 3 which requires both TFM matches and TDecimate metrics to recognise it as "video". Since I never used TFM it would always fail this condition and that's why the stairs section wouldn't switch to blend. And in your example it didn't fail since you were feeding it TFM matches via the txt file.

This is just a guess, but try changing it to
# timestamp format v1
to see if ffmpeg will play with it then.

Problem is I can't even find any ffmpeg argument relating to mkv timestampcode files. The ffmpeg GUI XMediaRecode also has no such option and no control over framerate mode. Seems like ffmpeg doesn't support it at all but hoping I'm mistaken.

hello_hello

6th October 2022, 00:57

If you're not married to XMediaRecode but want to use a GUI, try MeGUI. You can just add the timecodes file in the x264 encoder configuration. https://i.ibb.co/QvhkcMG/1.png
I still don't know if x265 has a VFR mode and MeGUI's x265 encoder configuration is pretty basic anyway.

I'm not sure I understand the "linear access" problem you mentioned earlier, but the TIVTC plugin has a RequestLinear() function if that's any help.

flossy_cake

6th October 2022, 03:52

# Analysis pass (comment out any filters after TDecimate so they don't run)
# TFM(Output=FTFM()).TDecimate(Mode=4, Hybrid=2, Output=FTDec())

# Encoding pass (uncomment any filters after TDecimate)
TFM(Input=FTFM()).TDecimate(Mode=5, Hybrid=2, Input=FTDec(), TFMIn=FTFM(), mkvOut=FTC())

Sample x264 command line:
x264.exe --level 4.1 --preset slow --tune film --crf 18.0 --tcfile-in "D:\VFR_TIMES.txt" --output "D:\VFR.mkv" "D:\VFR.avs"

I'm trying to reproduce this and am totally confused, because the file VFR_TIMES.txt won't exist until after the "encoding pass" in your VFR.avs is complete, so I'm not sure how you are feeding that as an input to x264.exe if it hasn't been created yet.

If you wouldn't mind, could you split it up into:

VFR pass1.avs
VFR pass2.avs
Inputfile for x264.avs

edit: also this is my VFR_TIMES.txt, it seems correct though as I've stepped through the video and identified frame 219 is the last of the 24p section

# timecode format v1
Assume 29.970030
# TDecimate v1.0.8 by tritical
# Mode 5 - Auto-generated mkv timecodes file
0,219,23.976024
# vfr stats: 51.02% film 48.98% video
# vfr stats: 275 - film 264 - video 539 - total
# vfr stats: longest vid section - 0 frames
# vfr stats: # of detected vid sections - 0

flossy_cake

6th October 2022, 04:17

I'm not sure I understand the "linear access" problem you mentioned earlier, but the TIVTC plugin has a RequestLinear() function if that's any help.

It works!

CreateTimestampFile.avs:

file = "clips\1112-11.mkv"
LWLibavVideoSource(source=file, cache=false)
TDecimate(mode=3, hybrid=2, viddetect=2, cycle=5, cycleR=1, mkvOut="TIMES.txt")
RequestLinear()

To run it from ffmpeg:

ffmpeg -i "CreateTimestampFile.avs" -threads 4 -f null NUL

So now I have this TIMES.txt file with the required information, I just need to figure out how to use it to encode the new VFR file.

btw I tried mkvtoolnix and handbrake without success but I'm probably doing something wrong, just can't figure out what.

I'm still not clear on what the input file is when encoding the new VFR file -- is it the original 1112-11.mkv or the TDecimated version of it?

hello_hello

6th October 2022, 04:18

I'm trying to reproduce this and am totally confused, because the file VFR_TIMES.txt won't exist until after the "encoding pass" in your VFR.avs is complete, so I'm not sure how you are feeding that as an input to x264.exe if it hasn't been created yet.

If you wouldn't mind, could you split it up into:

VFR pass1.avs
VFR pass2.avs
Inputfile for x264.avs

The timecodes file should be created as soon as you open the 2nd pass script. The 2nd pass doesn't need to be run as such, just opened, and the timecodes file is created in an instant (assuming the 1st pass files exist).

When I'm doing a bunch of VFR encodes I often add the same scripts to MeGUI twice, once as an analysis pass and then again as an encoding job, modifying MeGUI's encoder configuration to adjust the name of the timecodes file each time if need be. The encoding pass would be commented out at that stage.

Once all the analysis passes have finished I open the scripts and comment out the analysis pass and uncomment the encoding pass, then let MeGUI run the encoding jobs. As soon as MeGUI opens each script for encoding it's timecodes file is created and as long as the name of the timecodes file added to the x264 command line matches, the encodes run normally.

If you're running the encodes via the command line yourself or using a batch file etc, you should still be able to do much the same thing.

Each script can use the same name for the timecodes file, if you prefer, because as soon as you open the 2nd pass script the existing timecodes file will be over-written, but I tend to give them unique names when encoding a bunch of scripts.

PS. The first pass files are similar. As soon as you open the 1st pass script any existing metrics files with the same names will be over-written with blank ones and you'll have to run the analysis pass again, so once it's run, be careful about opening the 1st pass script again.

hello_hello

6th October 2022, 04:29

So now I have this TIMES.txt file with the required information, I just need to figure out how to use it to encode a the new VFR file.

btw I tried mkvtoolnix and handbrake without success but I'm probably doing something wrong, just can't figure out what.

If you're VFR encoding with x264 and it's configured to write the encoded video to an MKV you don't need to add the timecodes file when muxing. It'll be created as VFR.

If you're encoding at a CFR (and probably when x264 is writing to a raw AVC stream) you'd add the timecodes to MKVToolNix under the Timecodes tab, assuming it hasn't changed (I'm using a pretty old version as I mostly use XP). Make sure the video track is the one selected when you add it.

https://i.ibb.co/WKC3fh2/Clipboard01.jpg

I don't think Handbrake will use a timecodes file for encoding. Does it accept Avisynth scripts as the input video anyway?

I'm still not clear on what the input file is -- the original 1112-11.mkv or the TDecimated version of it?

The original for encoding and the decimated/re-encoded version for muxing.

hello_hello

6th October 2022, 04:37

edit: also this is my VFR_TIMES.txt, it seems correct though as I've stepped through the video and identified frame 219 is the last of the 24p section

# timecode format v1
Assume 29.970030
# TDecimate v1.0.8 by tritical
# Mode 5 - Auto-generated mkv timecodes file
0,219,23.976024
# vfr stats: 51.02% film 48.98% video
# vfr stats: 275 - film 264 - video 539 - total
# vfr stats: longest vid section - 0 frames
# vfr stats: # of detected vid sections - 0

As long as you mean frame 219 in the output file it looks about right (unfortunately I've deleted the one I created yesterday so I can't compare them).

Edit: Here's the timecodes file I extracted from VFR.mkv. It's extracted as version 2 timecodes, but line #222 seems to be where it changes from 42ms between timestamps to 33ms. Subtract two from that because the first line isn't a timecode and the first frame is zero rather than one, and the video section starts on frame #220 (I think that's right).

VFR_track1__eng_.tc.txt (https://files.videohelp.com/u/210984/VFR_track1__eng_.tc.txt)

flossy_cake

6th October 2022, 05:25

The timecodes file should be created as soon as you open the 2nd pass script

Oh you're right it does! I was confused because I was using mode3 to generate the TIMES.txt file, and mode3 doesn't finish creating the file until the video has finished playing in MPC-HC, or finished processing in ffmpeg.

But in your case mode5 seems to be taking the TFM metrics and immediately generating the TIMES.txt file from it.

I got your code working on my end and the result is good. I tested the VFR file on my set top box @ 60hz and to my surprise it does actually manage it correctly, although there is a slight pause on the rate change.

I'm seeing some comments that VFR may not be a good idea as many devices don't handle it correctly. Given those comments I'm leaning towards the 60p CFR solution again but there doesn't seem to be a way to automate it.

hello_hello

6th October 2022, 05:50

flossy_cake

7th October 2022, 00:31

I've never had a problem with VFR but that doesn't mean it's always fine.
The Samsung TV here with a built in media player seems to play them fine and it's 11 years old. Both the Bluray players with USB inputs for video also play them fine. I have a bunch of cartoons I decimated with Dedup so the frame rate is all over the place. They're not the combinations of 24fps and 30fps you get with TDecimate. I haven't had problems with those.

Maybe it's ok then. Have you had any issues with audio going out of sync?

Wish I could get VFR working in mkvtoolnix as that seems to offer the possibility of muxing in the VFR timecodes without having to re-encode the video. But in your x264 example it requires the output of TFM().TDecimate() in order for it to work, and avisynth outputs uncompressed video so that would seem to imply it does need to be re-encoded i.e generation loss and many hours/days of 100% CPU usage (trying to preserve my PC -- don't want hotspots accumulating on the motherboard).

Are you using your normal encoder settings? Keyframe interval and that sort of thing?

The only thing I meddled with is 10-bits instead of 8 (high10 for x264; main10 for x265).

hello_hello

7th October 2022, 21:15

Maybe it's ok then. Have you had any issues with audio going out of sync?

No.

Wish I could get VFR working in mkvtoolnix as that seems to offer the possibility of muxing in the VFR timecodes without having to re-encode the video.

You can't do that because the timecodes need to have the same number of frames as the video. You can't use timecodes to skip a duplicate frame or anything like that.

flossy_cake

18th October 2022, 07:01

kedautinh12

18th October 2022, 07:15

Are you try prefetch??

flossy_cake

18th October 2022, 08:35

Are you try prefetch??

Yes but I'm probably doing it wrong. It looks very complicated like different filters need different modes and stuff: http://avisynth.nl/index.php/SetFilterMTMode#Enabling_MT

When 1080i video is choppy and audio crackling, cpu usage is around 20% but every core seems to be getting usage. Not sure if that means it's truly multithreading or not.

Anyway I did manage to get this 1080i test clip (https://drive.google.com/file/d/1AMmHwIfJrJAPb1Uv17tcGDVy_576kCZf/view?usp=sharing) TDeinting at full frame rate by setting mtnmode=0 & slow=0, eg.

FFmpegSource2("1080i25, 1-1 cadence.ts", fpsnum=25, fpsden=1, atrack=-1)
TDeint(mode=1, full=false, tryWeave=true, mtnmode=0, slow=0)

edit: nope, it seems TDeint(slow=0) causes 2:2 sections to no longer get weaved
edit2: but setting opt=0 fixes that, but then I'm back to square 1 with CPU bottleneck on 1080i playback :rolleyes:

Compatibility with source filters:
Working with AudioDub(LWLibavVideoSource(), LWLibavAudioSource()).
DSS2() working but no audio.
DirectShowSource() working but wrong field order it seems

flossy_cake

18th October 2022, 10:10

Definitely seems to be a CPU bottleneck as I can pause the video, wait a few seconds for the framebuffer to fill up, press play, then it plays smooth for about 5 seconds before choking. Then I can pause again, wait, repeat the process. Setting the CPU buffer in MadVR also extends the period of smooth playback but in the end it always catches up cause it can't fill the buffer faster than it's reading out of it.

takla

18th October 2022, 13:18

flossy_cake

18th October 2022, 15:40

Try this

FFmpegSource2(whatever)
TDeint(whatever)
Prefetch(4, 50)

Interesting result. Video starts playing, then as usual bogs down to slow motion framerate with stuttering audio, but then after about 10 seconds CPU usage spikes up to 40%, playback becomes smooth again. But then a few seconds later it bogs down with slow motion fps and stuttering audio and CPU usage back at 20%. This whole cycle then repeats itself at infinitum.

Is this happening to anyone else with that 1080i clip (https://drive.google.com/file/d/1AMmHwIfJrJAPb1Uv17tcGDVy_576kCZf/view?usp=sharing)?

i.e with TDeint("1080i, 1-1 cadence.ts", mode=1, full=false, tryWeave=true, cthresh=6, mtnmode=0, slow=1)

As mentioned previously, I can set slow=0 and get smooth playback, but then the 2:2 weave detection stops working and 2:2 sections of video are needlessly dropping to half vertical res for moving parts of the image. Which is actually worse than not deinterlacing it at all.

That 1080i clip doesn't contain any 2:2 sections but here is a 576i 2:2 cadence clip (https://drive.google.com/file/d/1HkOfMlb4P0KaqMyvoA4ZZFAsaHu54Koh/view?usp=sharing).

So just to clarify: I'm trying to get both the 1080i clip to play at full frame rate 50fps without combing artefacts, and the 576i clip to play at 25fps without vertical resolution dropping to half. This can be achieved with the TDeint settings above, however then I get slow frame rate and stuttering audio with 1080i.

But it works so it's just a matter of trying to give TDeint enough CPU cycles to work with. Something is bottlenecking it. Using other source filters doesn't seem to have any effect other than FFmpegSource2 seems to crash if I seek the 1080i clip, so I would recommend using AudioDub(LWLibavVideoSource(), LWLibavAudioSource()) .

kedautinh12

18th October 2022, 15:43

Use only prefetch(4)

flossy_cake

18th October 2022, 16:25

tdeint(mode=1)
4 threads - 496 fps
tdeint(mode=1,slow=0,type=0,mtnmode=0,ap=25,aptype=1)
4 threads - 845 fps
tdeint(mode=1,slow=0,type=0,mtnmode=0)
4 threads - 1150 fps
tdeint(mode=1,slow=0,type=0,mtnmode=0,edeint=nnedi3(-2))
4 threads - 209 fps
s

Ffmpeg command line says I'm only getting 54fps when calling the script from ffmpeg with

ffmpeg -i "c:\temp\scripts\avisynth\tdeint.avs" -threads 4 -f null NUL

https://i.ibb.co/sJLvrWn/fps.png

Same cpu usage as realtime avisynth with MPC-HCx64, around 15-20% :confused:

https://i.ibb.co/tczGQNw/cpu.png

edit: oh, he used a NTSC DVD. I'm getting 900fps on that 576i 2-2 clip so yeah I guess 1080i is 5x the pixels but should still be at least 60fps. Maybe something else about 1080i... maybe pixel format is different.

Use only prefetch(4)

Yep that was one of the first things I tried...

flossy_cake

18th October 2022, 18:33

I compared this configuration of TDeint to Nvidia's DXVA "video mode" deint and they seem to do a similar job with both of them using the same strategy on 1:1 sections but NVidia is slightly less responsive at switching to weave for 2:2 sections.

I forgot about how Nvidia DXVA deint screws up the chroma position and blurs it, even when unticking "use DXVA chroma upscaling when doing DXVA deinterlacing" in the renderer (it's better than not ticking it, but still noticeably wrong).

Therefore TDeint is looking better than NV DXVA deint... just need to solve the bottleneck for 1080i

takla

18th October 2022, 23:01

Just stick to yadif_cuda from ffmpeg. Your cpu is too weak for realtime 1080i.

hello_hello

19th October 2022, 01:55

Has anyone managed to get TDeint working for realtime deinterlacing of 1080i?

My system is i7-4790k & GTX1070, and TDeint realtime deint of 480i and 576i seems fine -- only 6% CPU usage and playback is smooth. But for 1080i, CPU usage is around 17% and video plays slow and stutters.

I want realtime processing as I want to avoid generation loss through transcoding.

Yeah, but that argument falls apart once you realise it has to be re-encoded to remove the monumentally annoying station logo anyway. ;)

As mentioned previously, I can set slow=0 and get smooth playback, but then the 2:2 weave detection stops working and 2:2 sections of video are needlessly dropping to half vertical res for moving parts of the image. Which is actually worse than not deinterlacing it at all.

That 1080i clip doesn't contain any 2:2 sections but here is a 576i 2:2 cadence clip (https://drive.google.com/file/d/1HkOfMlb4P0KaqMyvoA4ZZFAsaHu54Koh/view?usp=sharing).

Are you sure that's what's happening?

Edit: I now realised you said "moving parts of the image" so maybe I misunderstood what you meant, but I'll leave the post as-is in case it's useful for someone else. There's info you may not be aware of at the end of this post regarding TryWeave and your progressive sample though.

I haven't used TDeint much so I'm trying to make sure I understand what it's options do, but the way I read the TryWeave info, it tries to match each field with both the previous and next one before repairing any combing, rather than rigidly combining fields in a set order. Either way though, it only messes with pixels where combing is detected (at least by default).

An easy way to see the pixels it's fiddling with is to do something like this. The pixels that would normally be taken from a de-interlaced version of the video to repair combing are the red ones.

A = last
B = BlankClip(A, color=color_red)
TDeint(edeint=B)

For the frame below, TryWeave=true results in a match without combing, whereas there's combing when TryWeave=false, but it's only fiddling with the combed pixels and the resolution remains the same for the rest of the frame. For some frames the detected combing is the same regardless of the TryWeave setting. Slow=true does seem to prevent TryWeave working though.

https://i.ibb.co/NNzZSss/1.jpg

A = last
B = BlankClip(A, color=color_red)
TDeint(TryWeave=true, edeint=B)

https://i.ibb.co/WD1XSVQ/2.jpg

I've read the description for the Full argument about 20 times and I'm still not sure I get it, but I think it's only intended for when TDeint is being used as a post-processor for another filter such as TFM.

The important parts of the description seem to be these.

With the addition of full=false, another way to use TDeint as a post-processor is to have it use its own combed frame detection as follows (this also allows it to work with any field matcher, not just telecide or tfm)

true - normal processing
false - check all input frames for combing first

So for the example below... I think......
When full=true, TDeint checks TFM's output and repairs any combing.
When full=false, it appears to check the original video (clip2) along with TFM's output, and uses the frames requiring the least amount of combing repair. Something like that.... I think....

A = last
B = BlankClip(A, color=color_red)
TFM(pp=1)
TDeint(Full=false, edeint=B, clip2=A)

By the way, pretty much all PAL DVDs are encoded as interlaced even if they're progressive, and for whatever reason, it's not uncommon for the fields to be misaligned, or out of phase. So they can look and smell quite interlaced even when they're not. Before I knew better I de-interlaced quite a few progressive PAL DVDs requiring nothing more than TFM() to match the fields up correctly. I'm pretty sure that's the case for your sample. Even if you tell it not to repair combing, TFM(pp=1) still fixes most of it. For TDeint, TryWeave allows it to do the same thing. For normal interlaced content though, or for progressive content that's not messed up the same way, I don't think TryWeave would be able to magically make so much combing disappear.

flossy_cake

19th October 2022, 14:23

Thanks for the advice. Given what you said about lots of PAL DVD's having screwed up field order then it sounds like TDeint alone wouldn't be sufficient as a "1 size fits all" solution and I would need to use TFM as well.

btw TDeint can do the pixel debug thing with eg. slow=0, map=2, then you should see a lot of pixels in purple being unnecessarily interpolated on the 576i 2:2 clip . Then set slow=1 and the purple pixels go away, at least that's how it's behaving on my machine. Or just step through frame-by-frame and notice the interpolation aliasing on fine details.

It's weird though cause the interpolation only lasts for a single 20ms frame of the 50p output -- on the 2nd 20ms frame it's full progressive, like this:

0ms: frame A field 1 interpolated to 576p (purple pixels)
20ms: frame A field 1+2 weaved to 576p (no purple pixels)
40ms: frame B field 1 interpolated to 576p (purple pixels)
60ms: frame B field 1+2 weaved to 576p (no purple pixels)

Annoyingly just enough to ruin the output and produce line twitter and the perception of half res :)

I'm super annoyed about the chroma issue with NVidia DXVA deint! That was my main solution that I remembered isn't such a great solution anymore. I can sort of compensate with z_ConvertFormat(chromaloc_op="top_left=>center", interlaced=true) which shifts the chroma location from center to top left, but it's still not right. The chroma is duller and more blurry. Great job NVidia!

I tried also a few hours fiddling with DGTelecide() and PVBob(). Couldn't get the former to do full framerate, and the latter doesn't have any 2:2 detection so half res on moving 2:2 sections.

*sigh*

flossy_cake

19th October 2022, 16:51

I suppose my ideal realtime deinterlacer would go something like this

if cadence != 1:1
use TFM().TDecimate() or MadVR's film mode deint
else
use full framerate deint, eg. TDeint(mode=1) or BWDIF(field=-2) or yadifmod2(mode=1)

This should result in something where no frames or resolution is lost.

I have found that MadVR's film mode deint is very competent at detecting a whole range of cadences in realtime and dealing with dynamically changing cadences and field orders (it even gets the 1080i cheese slices right which is a stupid clip that would never occur in reality). It also runs flawlessly on my i7-4790k with very low CPU usage (<10%) and runs on the CPU apparently.

If anyone knows how to implement such a solution in Avisynth, please advise :thanks:

flossy_cake

20th October 2022, 07:44

Just stick to yadif_cuda from ffmpeg. Your cpu is too weak for realtime 1080i.

Yadif is ok. At full frame rate it makes some nice smooth diagonal lines when typical field interpolation results in more aliasing. But it can't resolve the stationary 1px black & white lines pattern and some other high contrast 1px height parts of the image. It also seems to look slightly softer on details eg. texture in a person's hair. Softer but smoother and less aliased. I think I would prefer BWDIF but even that is still only "ok". Neither will weave 2:2 motion in full frame rate mode so that's throwing away half the available resolution for no good reason and that is why I can't accept them as a general purpose deint.

For 1080i25 1:1 cadence with TDeint(slow=1) my CPU is at 18% usage and getting only 45fps which is not enough for realtime use. Doesn't this seem like a bottleneck? Theoretically shouldn't it do 90fps @ 36% CPU?

takla

20th October 2022, 17:06

Multithreading doesn't scale linearly. But you can try Prefetch(8) if you're fine with high cpu usage. Also, use ffmpeg -benchmark -i whatever to see your fps

flossy_cake

20th October 2022, 18:12

Also, use ffmpeg -benchmark -i whatever to see your fps

I was just outputting to NUL:

ffmpeg -i "c:\temp\scripts\avisynth\tdeint.avs" -threads 4 -f null NUL

https://i.ibb.co/sJLvrWn/fps.png

Is that the same or did you mean something different?

On an unrelated note, there seems to be a small errata with this:

Mode 1 = Exactly like mode 0, except instead of decimating the M most similar frames, frames are decimated from the longest remaining strings of duplicates. The duplicate detection uses the dupThresh parameter.
http://avisynth.nl/index.php/TIVTC/TDecimate

The bit in bold doesn't seem to be the case, as I can lower dupThresh to a very low value like 0.2 so that the duplicate is above the threshold and gets detected as "(new)" in the display=true debug, and yet it still says underneath it "DROP" and drops the frame decimating the 30p stream to 24p:

https://i.ibb.co/CtW4DhF/drop2.png

Not that this really matters for my usage purposes but it leaves me curious about which scenario dupThresh would actually get used.

hello_hello

20th October 2022, 18:57

Thanks for the advice. Given what you said about lots of PAL DVD's having screwed up field order then it sounds like TDeint alone wouldn't be sufficient as a "1 size fits all" solution and I would need to use TFM as well.

I'm not sure why TryWeave wouldn't work well for a progressive source, as long as there's no telecine and it's just matching the fields to restore the progressive frames. Although for 3:2 pulldown I think it should work and the result would probably be the same as for TFM, assuming TDeint(mode=0).
TFM's field matching does a fair bit more checking to find the best match though, and unlike TryWeave the best match is used even if there's combing to repair, and of course TFM can't output a double frame rate. There's all sorts of horrors for a field matcher to deal with at times, especially for NTSC. For quite a while it was common practice to overlay one type of video on another, such as applying telecine to film to make it 29.97i, then overlaying the telecined fields with something truly interlaced or progressive. When that sort of thing happens you can't just remove the telecined fields without effecting the interlaced stuff overlaid on top, or just de-interlace and remove the telecine too. For an interlaced display it's fine, but not so much for making progressive frames. Anyway for progressive PAL, if lining the fields up correctly is all that's required, TryWeave should be fine.

btw TDeint can do the pixel debug thing with eg. slow=0, map=2, then you should see a lot of pixels in purple being unnecessarily interpolated on the 576i 2:2 clip . Then set slow=1 and the purple pixels go away, at least that's how it's behaving on my machine. Or just step through frame-by-frame and notice the interpolation aliasing on fine details.

It's weird though cause the interpolation only lasts for a single 20ms frame of the 50p output -- on the 2nd 20ms frame it's full progressive, like this:

0ms: frame A field 1 interpolated to 576p (purple pixels)
20ms: frame A field 1+2 weaved to 576p (no purple pixels)
40ms: frame B field 1 interpolated to 576p (purple pixels)
60ms: frame B field 1+2 weaved to 576p (no purple pixels)

Annoyingly just enough to ruin the output and produce line twitter and the perception of half res :)

When you include slow=0 for your 25i sample
TDeint(mode=1, tryweave=true, map=2, slow=0)
TryWeave no longer works and TDeint is only managing to find a perfect match for every second field.
Therefore every second frame needs to be repaired after field matching, so they alternate between having and not having purple pixels.
With slow=0 removed, TryWeave works properly (or it's more accurate because it's slower) and the purple pixels disappear. It's not because map=2 doesn't work without slow=0, it's because there's no longer any combing repair required.

In my head at least, for a truly progressive source, and assuming there's always movement between frames, each field can only match correctly with one other, which is the one belonging to the same progressive frame. So when mode=1 and TryWeave=true, each field should have a matching one while also being the other field's match. Or to put it another way, when field one needs a partner it might be matched to field two, and when it's time to find field two a partner it'll be matched to field one and you have two identical progressive frames and double the frame rate.
Of course for a truly interlaced source each field is a different moment in time, so assuming there's movement between frames there's no perfect match, and the help files says if the frame produced by TryWeave contains combing it's not used and normal interpolation takes over.

If for whatever reason there's a need to repair combing after field matching, and of course when de-interlacing, line twitter and aliasing etc will always be a problem. Much less so if you de-interlace with QTGMC though. Has anyone mentioned QTGMC yet? :) It's slow because it spends time repairing that sort of thing. It always bobs the entire frame though, which I don't always mind, because it's efforts to repair the de-interlacing means it naturally denoises and sharpens a little, but you can compromise.

A = last
B = A.QTGMC()
A.TDeint(edeint=B)

If TDeint needs to repair combing in every frame it'll be as slow as using QTGMC on it's own, but if not it'll be faster to some degree.

Or try changing TDeint's de-interlacing method. Sometimes even blend interpolation can look quite good, especially if it's relative to the other methods and they don't.

I'm super annoyed about the chroma issue with NVidia DXVA deint! That was my main solution that I remembered isn't such a great solution anymore. I can sort of compensate with z_ConvertFormat(chromaloc_op="top_left=>center", interlaced=true) which shifts the chroma location from center to top left, but it's still not right. The chroma is duller and more blurry. Great job NVidia!

I'm not familiar with the problem. Does it shift the chroma or upsample it incorrectly?

flossy_cake

20th October 2022, 19:33

I'm not familiar with the problem. Does it shift the chroma or upsample it incorrectly?

Both kind of. It's a known issue in the MadVR thread, and MadVR even has an setting to "avoid using DXVA chroma upscaling when doing DXVA deinterlacing", and it improves it, but still is slightly shifted and blurred. Apparently once DXVA gets its hands on the chroma, it's game over and we can't restore the original chroma back out of it. Because I think DXVA deint needs to upscale the chroma to 4:4:4 before it can analyse pixels for combing etc. and that's where the damage is being done. Or so I'm lead to believe.

On a perfect source it's kind of tolerable but if I get a dodgy source with chroma alignment issue like TV channel 44 (you may have noticed it in the clip that chroma is shifted to the right) then it results in 2 generations of chroma mishandling and that is too much to tolerate.

edit: animated png
https://i2.lensdump.com/i/1xVHg5.png

hello_hello

20th October 2022, 19:52

The bit in bold doesn't seem to be the case, as I can lower dupThresh to a very low value like 0.2 so that the duplicate is above the threshold and gets detected as "(new)" in the display=true debug, and yet it still says underneath it "DROP" and drops the frame decimating the 30p stream to 24p:

When Hybrid=0 and for Cycle=5 and CycleR=1, each group of five frames is considered to be film and one of them has to go. If there's no duplicate in the group then it's the next best candidate. The following probably should have said "the longest remaining strings of duplicates per cycle".

Mode 1 = Exactly like mode 0, except instead of decimating the M most similar frames, frames are decimated from the longest remaining strings of duplicates.

The defaults are fine because for normal 3:2 pulldown, for every eight fields that go in, ten come out, or referring to frames instead of fields, for every four that go in five come out, so ideally you only want to reverse that. If you give TDecimate more wiggle room, for example Cycle=50 and CycleR=10, it'll still remove the same number of frames over-all, but not necessarily the same frames. I assume, in theory at least, TDecimate could decide to keep the first 40 frames in the group and remove the last ten as duplicates. Adjusting dupThresh would change the number of frames considered to be legit duplicates, and therefore the number of legit duplicates in succession for any given cycle.

For very large cycles it's possible to effect the A/V sync if the duplicates aren't distributed/decimated evenly throughout. Therefore you could look at the beginning of each cycle as also being a reset for the A/V sync.

flossy_cake

20th October 2022, 21:42

I suppose my ideal realtime deinterlacer would go something like this

if cadence != 1:1
use TFM().TDecimate() or MadVR's film mode deint
else
use full framerate deint, eg. TDeint(mode=1) or BWDIF(field=-2) or yadifmod2(mode=1)

Hmm, might be possible to do something with ConditionalFilter ?

The conditional functions are IsCombedTIVTC, CFieldDiff, and CFrameDiff which can be used via AviSynth's conditional filtering environment to test if frames are combed, determine how well two fields fit together, or calculate the difference between frames.
http://avisynth.nl/index.php/TIVTC#Description

Maybe something like...

ConditionalFilter(last, bwdif(field=-2), TFM().TDecimate(), "IsCombedTIVTC", "=", "true")

No idea what I'm doing though :o

hello_hello

21st October 2022, 12:38

Both kind of. It's a known issue in the MadVR thread, and MadVR even has an setting to "avoid using DXVA chroma upscaling when doing DXVA deinterlacing", and it improves it, but still is slightly shifted and blurred. Apparently once DXVA gets its hands on the chroma, it's game over and we can't restore the original chroma back out of it. Because I think DXVA deint needs to upscale the chroma to 4:4:4 before it can analyse pixels for combing etc. and that's where the damage is being done. Or so I'm lead to believe.

What color formats can DXVA play with?
If it'll de-interlace RGB, maybe convert to RGB before anything else. Or if you're using filters that don't work with RGB, you could try full chroma YUV instead.

For HD
ConvertToRGB32(interlaced=true, matrix="Rec709")
or
ConvertToYV24(interlaced=true)

There's a ChromaShift plugin, but for YV12 it's 2 pixel increments, or 4 if it's interlaced, or if you're really keen and know the exact shift you can use a resizer to compensate. To shift the chroma of a 1080p video 7.3 pixels to the left (it'd be -7.3 to shift it right).

A = last
MergeChroma(A, A.Spline36Resize(1920,1080, 7.3,0,1920,1080))

On a perfect source it's kind of tolerable but if I get a dodgy source with chroma alignment issue like TV channel 44 (you may have noticed it in the clip that chroma is shifted to the right) then it results in 2 generations of chroma mishandling and that is too much to tolerate.

If you're referring to the 1080i sample I'm not seeing any chroma shift. I'm still on XP and I don't think DXVA2 works for MPC-HC any more, but I enabled Cuvid DXVA de-interlacing in LAV filters and it's a little less sharp than BWDIF but nothing too drastic. My video card's probably 12 years old and the drivers would probably be 11 years old as I never update them, so maybe they pre-date the problem.

I'd have to experiment myself to see if I could get the de-interlacing to work as you've described with ConditionalFilter. I don't use conditional filtering much. It'd probably also slow things down even more.

flossy_cake

22nd October 2022, 08:02

If you're referring to the 1080i sample I'm not seeing any chroma shift.

It was the 576i clip with the channel 44 watermark. That TV channel has issue with chroma shifted to the right slightly. Actually I have 3 generations of chroma mishandling not 2:

1. TV channel error
2. DXVA deint error
3. My Samsung TV downsampling to 4:2:2 internally

But you can see 1 vs 2 on that animated png and it still looks bad on a 4:4:4 monitor.

If it'll de-interlace RGB, maybe convert to RGB before anything else.

Great idea, but unfortunately there doesn't seem to be a way of calling DXVA deint from Avisynth. This is the deint mode MadVR uses when selecting "video mode" deint in MadVR's settings, or by tagging the file or parent folder with [deint=video]. It's unique because it is a full fps deint like bwdif(field=-2) but also has some 2:2 motion detection as well (but it's not sensitive enough for my liking... needs too much motion before it senses 2:2 so any slight camera wobble or very slow pan will still be only bobbing and look blurry/flickering -- doh! I think they set the motion threshold for 1080i which has smaller pixels so slight camera movement will travel more distance in pixels per distance camera movement).

I've tried to achieve a better result with TDeint(mode=1, full=false, tryWeave=true, slow=1) but after testing with some more clips eg. The IT Crowd DVD, its combing detection just isn't good enough either. Basically the intro sequence to the show is 2:2 then the show proper is all 1:1. The intro gets weaved nicely, but the show proper has issues on scenes where actors are sitting very still and the only thing moving is their mouth. In this case their mouth movement gets combed cause it's not above the combing detection threshold. There are myriad settings to play with: cthresh, blockx, blocky, MI etc. but despite playing with these for hours I could not achieve a good balance where the intro would get weaved and no mouth combing. The best I could get was with cthresh=3 and those other parameters left alone.

I guess I will try with just TFM() which should weave the intro sequence but I don't know how it's going to handle those problematic 1:1 scenes.

In the end I suspect I will have to use an override file to handle the intro sequence separately. It's kind of cool that we can even do such a thing, but at the same time I feel like we're annoyingly close to having a "set it and forget it" option.

edit:

Great idea, but unfortunately there doesn't seem to be a way of calling DXVA deint from Avisynth.

Actually now that I think about it, I don't think it needs to be called from Avisynth. I will give your suggestion a try -- thanks.

hello_hello

22nd October 2022, 12:32

I thought you were opening scripts in MPC-HC and using MadVR to de-interlace or something like that. Maybe I misunderstood. I almost never watch interlaced video as I always de-interlace with QTGMC and re-encode, so I haven't had much experience with "player" de-interlacing issues.

Try Metric=1 for TDeint (and TFM). It often does better on small amounts of fine combing than the default metric.
Failing that, try following TDeint with VInverse. http://avisynth.nl/index.php/Vinverse

flossy_cake

22nd October 2022, 14:49

I thought you were opening scripts in MPC-HC and using MadVR to de-interlace or something like that.

MadVR has 2 deinterlacing modes: film and video. Film uses MadVR's own CPU code to perform IVTC much like TFM().TDecimate() and it works quite well with very little CPU usage. Video I've been told just hands the frames off to the GPU driver to perform DXVA deinterlacing. This is also quite good and cheap for mixed 1:1 and 2:2 content (but not 3:2) but has the chroma issue on NVidia cards. Admittedly I'm using an old driver so I should probably update that to see if NVidia fixed it.

I tried metric=1 and saw a slight improvement allowing me to increase cthresh by 1 to achieve the same result. Ultimately still visible artefacting though and I'd still prefer bwdif which doesn't have the issue at all, but of course bwdif doesn't weave 2:2 moving sections.

Tried VInverse() which does seem to work but it's only half framerate so I can still see actor's mouths moving at 25fps compared to the rest of their face animating at 50fps. I guess human vision is very critical when it comes to facial recognition -- if something is even slightly off it will be noticed. VInverse also seems to soften the image slightly? bwdif is slightly softer than TDeint as well though so I shouldn't complain. I guess that tight weave threshold of TDeint is contributing to its slightly sharper output.

I'm applying avs scripts by simply opening them with MPC-HC so they get applied in realtime. This realtime functionality is essential to me as I want to avoid transcoding and have the flexibility of making per-season or even sometimes per-episode adjustments.

Another issue I'm dealing with is the Avisynth source filter isn't passing interlaced flags which breaks DXVA deint which for some reason requires them in order to work.

There is something unique about the interlacing in this particular show The IT Crowd. Even DXVA struggles with it and sometimes weaves pixels when it shouldn't be, leaving 1 pixel wide combing artefacts in certain patterns. Which is weird because DXVA deint looks quite clean on that 576i SDI Public Senat clip in the other thread.

flossy_cake

22nd October 2022, 15:34

Another issue I'm dealing with is the Avisynth source filter isn't passing interlaced flags which breaks DXVA deint which for some reason requires them in order to work.

Finally got to the bottom of this one -- unticking Avisynth in MPC-HC's source filters. Apparently this tells MPC-HC not to use its internal version of LAV decoders. Instead it uses Avisynth source filter only. Whereas with the box ticked I think Avisynth source filter gets passed through LAV decoder afterwards which can't see any interlaced flags cause Avisynth is just a raw uncompressed square pixel frameserver apparently.

edit: aaaand it looks like there are all kinds of audio sync issues , so it seems I need to pass it through LAV to avoid that. edit2: using a different audio renderer seems to solve that.

flossy_cake

22nd October 2022, 17:50

What color formats can DXVA play with?
If it'll de-interlace RGB, maybe convert to RGB before anything else. Or if you're using filters that don't work with RGB, you could try full chroma YUV instead.

For HD
ConvertToRGB32(interlaced=true, matrix="Rec709")
or
ConvertToYV24(interlaced=true)

There's a ChromaShift plugin, but for YV12 it's 2 pixel increments, or 4 if it's interlaced, or if you're really keen and know the exact shift you can use a resizer to compensate. To shift the chroma of a 1080p video 7.3 pixels to the left (it'd be -7.3 to shift it right).

A = last
MergeChroma(A, A.Spline36Resize(1920,1080, 7.3,0,1920,1080))

Thanks for this.

I couldn't get any improvement with converting to 444/RGB -- whatever NVidia is doing to the chroma is some kind of permanent damaging processing regardless of what pixel format I send it.

However with MergeChroma I am able to get a "better" result, but chroma is still blurred around edges, even though it is aligned. I think NVidia's DXVA implementation might be downsampling the chroma internally as part of its deint process.

DTL

23rd October 2022, 00:07

In typical endusers motion pictures distribution formats chroma is downsampled so can not have naturally same sharpness as luma. With conversions to RGB and any 4:4:4 chroma is upsampled by some process (filter/interpolator) that can give different sharpness. Current digital subsampled formats have build-in bugs and they are not still removed and also industry do not have any standards on YUV<->RGB spatial conversions. So every hardware/software developer uses its own ideas how it can be. Also there is 2 different processings in converting subsampled->full sampled: intermediate and final (display/monitor). Intermediate is designed to keep sharpness in many sub<-> full conversions (production chain) and final is for viewing (end-user consumption). So only final conversion to display RGB have anti-gibbs conditioning filter that looks like some blurring of chroma. Intermediate production converters do not have anti-gibbs filtering so looks sharper (but can/must produce chroma/RGB ringing in some processings like scaling - so it is up to upscaler designer to keep track what is feed to its input).

Typical production workflow (1 iteration):
YUV 4:2:0 storage/delivering -> 4:4:4 RGB -> RGB adjust/blend/tuning/mix/artistic -> YUV 4:2:0 storage/delivering. Do not change digital sample count of luma (format). It uses intermediate unfiltered chroma processing to keep chroma sharpness in many iterations.

Typical end user consumption process:
YUV 4:2:0 distribution -> 4:4:4 RGB for display -> display scaling (or DAC for analog that is equal to infitine samples upscale) -> optical image for viewing. It should use final (end of chain) anti-gibbs filtered chroma upscale in 4:2:0->4:4:4 conversion.

NVIDIA for home (video playback) and DXVA are endusers processing for typical motion pictures consumption so typically should be designed with not as sharp (unfiltered) prof conversions for intermediate processing.

AVS currently do not separate intermediate/final chroma upscale so may look sharper in compare with DVXA/NVIDIA upscale for displaying.

flossy_cake

23rd October 2022, 10:30

The problem with DXVA chroma handling is that it also shifts the chroma position down and to the right by 0.5 pixels according to my tests with a 4:2:0 chroma pattern.

Also if I feed DXVA deint a true 4:4:4 test pattern and/or 4:4:4 pixel format, it STILL downsamples it to 4:2:0. Disabling DXVA deint passes full chroma.

Here is my best guess at what might be happening with DXVA deint for a 4:2:0 source:

LAV decoder outputs 4:2:0 -> MadVR upscales to 4:4:4 -> DXVA deint downscales to 4:2:0 & shift chroma location 0.5 -> final output is upscale to 4:4:4 again.

I am not sure who is doing the final output upscale to 4:4:4, it might be DXVA or it might be some other part of the GPU driver matching it to whatever chroma is set in NVCP.

In any case the extra redundant step of downscaling to 4:2:0 and back up to 4:4:4 seems to be imbuing the chroma with a bit of softness, plus the 0.5 shift makes the end result noticeably poor. Then on top of this the TV network has its own chroma shift issue, plus my TV is downsampling to 4:2:2 internally and the end result is starting to look a bit shabby.

Take those last 2 steps out and I might not be able to tell anything is wrong in a double blind test on typical content. But on a test pattern I would for sure.

I'm not really a stickler for chroma -- I see people in the MadVR thread fussing over various chroma upscaling algorithms, spending a lot of GPU cycles to do NGU chroma upscaling. But honestly I can't see much difference on anything but test patterns or sources that have chroma problems baked into the source. As long as the alignment is right, I'm satisfied with the typical filters like Bicubic, Lanczos, Spline etc. The sharper algorithms tend to do worse on sources with chroma issues baked into the source.

DTL

23rd October 2022, 11:21

DXVA2 support chroma placement signalling - https://learn.microsoft.com/en-us/windows/win32/api/dxva2api/ne-dxva2api-dxva2_videochromasubsampling .

typedef enum _DXVA2_VideoChromaSubSampling {
DXVA2_VideoChromaSubsamplingMask = 0xf,
DXVA2_VideoChromaSubsampling_Unknown = 0,
DXVA2_VideoChromaSubsampling_ProgressiveChroma = 0x8,
DXVA2_VideoChromaSubsampling_Horizontally_Cosited = 0x4,
DXVA2_VideoChromaSubsampling_Vertically_Cosited = 0x2,
DXVA2_VideoChromaSubsampling_Vertically_AlignedChromaPlanes = 0x1,
DXVA2_VideoChromaSubsampling_MPEG2,
DXVA2_VideoChromaSubsampling_MPEG1,
DXVA2_VideoChromaSubsampling_DV_PAL,
DXVA2_VideoChromaSubsampling_Cosited
} DXVA2_VideoChromaSubSampling;

Same is for DXVA (1.0) - https://learn.microsoft.com/en-us/windows-hardware/drivers/ddi/dxva/ne-dxva-_dxva_videochromasubsampling

So your workflow need detect (or other ways found) correct chroma placement in your source of 4:2:0 subsampled and pass this data to the DXVA. So it is expected the DXVA processing result will be more correct. If not - you may also report issues to Microsoft support and may be NVIDIA support if you use DXVA and NVIDIA hardware - may be somewhere this chroma placement processing is broken in some Microsoft or NVIDIA layer (DirectX or NVIDIA driver or hardware).

If you use DXVA via MadVR may be you need to consult its developer or try manual set DXVA chroma placement flags to see if your execution layers of DXVA (DirectX + NVIDIA driver + NVIDIA hardware) correctly process it.

May be we need additional accept/detect/pass and manual override of chroma placement signalling to DXVA in MadVR if it still not have this interface and functions. Same as with interlacing in the old days.

flossy_cake

23rd October 2022, 13:03

May be we need additional accept/detect/pass and manual override of chroma placement signalling to DXVA in MadVR if it still not have this interface and functions. Same as with interlacing in the old days.

You could be right, however I have tested on GTX 1070 vs R9 380 and the latter has no chroma shift with DXVA deint. So it looks to be an NVidia driver issue perhaps not honouring or misinterpreting the meaning of the chroma positioning value. But I need to update my driver to see if Nvidia fixed it.

StainlessS

23rd October 2022, 14:45

I need to update my driver to see if Nvidia fixed it.

[NVidia Official Advanced Driver Search]:- https://www.nvidia.com/Download/Find.aspx?lang=en-uk#

DTL

23rd October 2022, 16:14

You could be right, however I have tested on GTX 1070 vs R9 380 and the latter has no chroma shift with DXVA deint. So it looks to be an NVidia driver issue perhaps not honouring or misinterpreting the meaning of the chroma positioning value. But I need to update my driver to see if Nvidia fixed it.

If your calling software do not provide correct chroma placement signalling to DXVA - it may be simply better defaults or better auto-detection in AMD/ATI driver and/or hardware.

Do you get confirmation that calling software (madVR ?) really sends required chroma placement signalling to DXVA ?

In both madVR and LAV decoder controls I do not see any settings for chroma placement signalling (auto/passthrow/manual or others).

flossy_cake

23rd October 2022, 17:25

[NVidia Official Advanced Driver Search]:- https://www.nvidia.com/Download/Find.aspx?lang=en-uk#

Thanks but what is the significance of advanced?

If your calling software do not provide correct chroma placement signalling to DXVA - it may be simply better defaults or better auto-detection in AMD/ATI driver and/or hardware.

Do you get confirmation that calling software (madVR ?) really sends required chroma placement signalling to DXVA ?

In both madVR and LAV decoder controls I do not see any settings for chroma placement signalling (auto/passthrow/manual or others).

I don't know if author Madshi is signalling chroma placement. I'd give him the benefit of the doubt though as his whole renderer is geared towards videophile levels of accuracy. I can safely assume it is something he would care a lot about & I doubt he would just ignore DXVA function params and think to himself "don't worry about it".

Although maybe it is LAV Video Decoder (ffmpeg) which is providing the incorrect chroma placement and MadVR is just passing that incorrect info on? But in that case AMD shouldn't get it right either.

I guess that tight weave threshold of TDeint is contributing to its slightly sharper output.

After further scrutinising and pixel peeping with DVD IT Crowd using frame advance and seeing which pixels are getting weaved, it seems TDeint is still noticeably superior to BWDIF when both are in the same full framerate mode where 2:2 motion doesn't get weaved but static unmoving parts of image does get weaved & the rest interpolated.

i.e BWDIF(field=-2) vs TDeint(mode=1, mtnmode=1, slow=2)

But, TDeint produces some junk interpolated pixels around the edges of raster so I have to zoom in 2px to make sure there is no underscan. But really the texture detail preservation on TDeint is a lot better on static shots -- the slightest bit of video noise or camera movement triggers BWDIF into interpolation so in practice I am very rarely actually achieving true 576p resolution with BWDIF.

TDeint does seem to use about double the amount of CPU though, but fmpeg says 170fps for 720x576i @ 15% CPU usage so that is plenty of headroom still.

DTL

23rd October 2022, 18:26

Correct metadata signalling from demuxer-decoder-renderer is expected only in prof level developed environment like microsoft windows and its multimedia extensions like DirectX or other. So may be try to play your content by DirectShow if possible and check the correct chroma decoding and RGB dematrix.
Example: Take standard prof authored DVD interlaced and try to playback using DirectShow. The microsoft MPEG2 decoder should provide correct chroma placement flags to renderer.
May be your content do not have metadata encoded into and decoder can not provide anything for unknown source. Only the author of content may be know what is the correct chroma placement and need to found way how to to put this to content or pass to decoding and playback environment by other ways.
So in good playback devices for pixel-peepers the manual control for chroma placement is expected to support playback from unknown sources with better result.

StainlessS

23rd October 2022, 20:15

but what is the significance of advanced?
Not Advanced:- https://www.nvidia.com/en-gb/geforce/drivers/

Advanced:- https://www.nvidia.com/Download/Find.aspx?lang=en-uk#

Advanced can also select "Windows Driver Type", ie Standard / DCH.
Just a bit better selection control [Advanced can also select Beta].

Advanced Driver Search, is NVidia's [not mine] description on that page.

EDIT: There are also more choices under Product Type, eg
NVS, Data Center/Tesla, GRID,
Perhaps additional diffs.

EDIT: + More OS selections, I'm not gonna look for more, you look if you like :)

flossy_cake

24th October 2022, 14:28

A = last
B = BlankClip(A, color=color_red)
TDeint(TryWeave=true, edeint=B)

Is it possible to manually implement something like the above but for BWDIF , in order to visually expose which pixels it weaves and which ones it interpolates?

BWDIF does actually have an edeint param but it does something else:

clip edeint =

Clip from which to take spatial predictions. This clip must be the same width, height, and colorspace as the input clip.
If using same rate output, this clip should have the same number of frames as the input. If using double rate output, this clip should have twice as many frames as the input.

http://avisynth.nl/index.php/BWDIF

I'm sure there's got to be some way to "diff" it with the original clip.

I'm asking because although I subjectively prefer the sharper look of TDeint, it does have a tendency to corrupt fine details, eg. text becomes a bit distorted. Only noticeable on test patterns though, but I'm still curious to see whether BWDIF is really so sensitive to motion that it will interpolating almost the whole time and only weaving under rare perfectly still conditions i.e test patterns or static computer generated overlays.

poisondeathray

24th October 2022, 15:06

Is it possible to manually implement something like the above but for BWDIF , in order to visually expose which pixels it weaves and which ones it interpolates?

BWDIF does actually have an edeint param but it does something else:

I'm sure there's got to be some way to "diff" it with the original clip.

I'm asking because although I subjectively prefer the sharper look of TDeint, it does have a tendency to corrupt fine details, eg. text becomes a bit distorted. Only noticeable on test patterns though, but I'm still curious to see whether BWDIF is really so sensitive to motion that it will interpolating almost the whole time and only weaving under rare perfectly still conditions i.e test patterns or static computer generated overlays.

subtract, or overlay with difference mode . You can use levels to amplify the differences

eg.

.
.
.
a = last
b = a.bwdif(some settings)

Subtract(a,b)

#Levels(127, 1, 129, 0, 255) # for 8bit
#Levels(511, 1, 513, 0, 1023) # for 10bit

If the distortions in text, fine patterns from tdeint (or bwdif) are due to the interpolation algorithm, you can specify a different deinterlacer or interpolation algorithm with edeint (for tdeint, or bwdif) . QTGMC is a commonly used one, or NNEDI3 if you want faster