Is there an adaptive deinterlacer script?

[Morte66]

Normally when I encode something in MeGUI, I'll use its avisynth script generator and hit "Analyse" in the Deinterlacing frame, to let it suggest a deinterlacer, then take whatever it suggests. [It's not like I know enough to argue.] This means sitting watching the GUI for a minute or two while it runs its analysis. Over 7 seasons of Buffy, that gets old.

So I'm wondering if there is some avisynth script/function kicking around that would analyse the video, and kick off whichever deinterlacer it likes best. It should be functionally equivalent of the GUI process, but run unattended during the queued encoder jobs (rather than running attended prior to queueing the encoder job). I could put it in MeGUI profiles, or call it in a script created by robot4rip.

It strikes me as the sort of function somebody might have written, but I don't know where to look. Does anybody know of such a thing?

[foxyshadis]

Every ep in a set should be the same, buffy is sold as a whole season, right? So you should only need to analyse one from each season.

Your "automated method" would basically be using the same avisynth script and changing the name of the input each time. I don't know if you can fast-track megui into using a preset avs and changing just the title, but it might be there.

[berrinam]

Over 7 seasons of Buffy, that gets old.Well, as foxyshadis said, it shouldn't really be necessary to run the analysis lots of times, as they should all be encoded in the same way. However, assuming they aren't (just for the theory of it), you could use the One Click Encoder to do the analysis automatically, but there is currently no other way of automating it in MeGUI. Perhaps another solution to this sort of thing is finding some way to do the analysis immediately after the d2v creation, so that all of that processing goes together. Obviously, MeGUI still needs a lot of work to integrate all the new tools that have been added.

So I'm wondering if there is some avisynth script/function kicking around that would analyse the video, and kick off whichever deinterlacer it likes best.I really doubt that this sort of thing has been written. I looked around this forum a lot before I wrote MeGUI's interlace detection, as it is quite an advanced thing to do, and I wanted to see if I could get any examples as to how one should do it. Basically, I didn't find anything other than a small description of AutoGK's method. That's what I based my algorithm on, as well as my own understanding of interlacing.

So I don't think that there is an AviSynth filter that does what you ask, and it certainly wouldn't use the same algorithm as MeGUI's, since I wrote that algorithm recently, and I am not aware of it having been used anywhere else. Of course, for someone experienced in AviSynth filter writing, it shouldn't be too hard to such a filter. My algorithm and the code is released under GPL, and I'm willing to help someone working on such an AviSynth plugin if they have trouble understanding my code. But still...... I'm not convinced it even should be an AviSynth filter.

Your "automated method" would basically be using the same avisynth script and changing the name of the input each time. I don't know if you can fast-track megui into using a preset avs and changing just the title, but it might be there.
AviSynth templates can do ANYTHING! All you would need to do is create an AviSynth template like this:
<input>
tdeint()
<crop>
<resize>
<denoise> And replace tdeint() with whatever MeGUI suggests on the first episode, and assume that the same filter will be appropriate for the entire season.

[Morte66]

Every ep in a set should be the same, buffy is sold as a whole season, right? So you should only need to analyse one from each season.

You can never rely on this with a DVD set, especially if it was shot on video. It usually works, but MeGUI used a whole repertoire of deinterlacers over the course of "Rising Damp" and I don't think I saw more than two consecutive episodes the same.

As for Buffy...

Buffy 101 TDeint(full=false)
Buffy 102 TDeint(full=false)
Buffy 103 TDeint(order=1,full=false)
Buffy 104 TDeint(full=false)

...I'll post the rest when it gets to them.

Your "automated method" would basically be using the same avisynth script and changing the name of the input each time.
... and an adaptive deinterlacer would pretty much get me there.

##

However, assuming they aren't (just for the theory of it), you could use the One Click Encoder to do the analysis automatically, but there is currently no other way of automating it in MeGUI.
I'm now doing Buffy in OCE, since I established that I don't want to do anything to it that OCE can't handle, and it was a wonderfully painless setup job. :)

I was really asking with an eye to the future , particularly:

- Encodes that need avisynth audio processing, which are beyond OCE and the profile system right now. But with any luck this will be resolved.

- My idle dream of having robot4rip write an avisynth script and a batch job to encode it, which I can then run in pairs of single-threaded jobs to get 100% utilisation of both cores inst4ead of the ~75% I get with x264 SMP. I guess I should raise a MeGUI request for multiprocessing at the job queue level, i.e. launching multiple jobs in parallel rather than launching single jobs and hoping they will parallel process.

##

AviSynth templates can do ANYTHING!

They don't seem able to do...LoadPlugin("C:\Program Files\DGMPGDec\dgdecode.dll")
loadplugin("C:\Program Files\avisynth 2.5\plugins\NicAudio.dll")
video=mpeg2source("D:\something.d2v",cpu=4)
audio=nicac3source("VTS_01_1 T01 3_2ch 448Kbps DELAY 0ms.ac3",2)
audiodub(video,audio)
AssumeFPS(24,1,true)
SSRC(48000,false)... because they have no way of knowing the audio filename. But if I could ensure through my workflow that the demuxed audio track always had the same name, and just hard code that line... Hmm, does this get me anywhere? Nah, OCE (only thing which will automate the deinterlacing) won't load that script for audio.

So I can't get full automation of audio and video just yet. I'll look forward to it, though. :)

[Morte66]

I thought this might be interesting. These are the deinterlacers chosen by MeGUI for Buffy R2/PAL seasons 1-3:

101-102 TDeint(full=false)
103 TDeint(order=1,full=false)
104-112 TDeint(full=false)
201 TDeint(full=false)
202 tfm().tdecimate(hybrid=3)
203-319 TDeint(full=false)
320 #Not doing anything because source is progressive
321 LeakKernelDeint(order=1,sharp=true)
322 TDeint(full=false)

So for each box set, taking the deinterlacer chosen for the first episode and applying it globally would have been wrong for at least one episode.

[berrinam]

I thought this might be interesting. These are the deinterlacers chosen by MeGUI for Buffy R2/PAL seasons 1-3:

[quote]101-102 TDeint(full=false)This means it is detected interlaced/progressive with unconstant field order
103 TDeint(order=1,full=false)Same as above, but with constant field order
202 tfm().tdecimate(hybrid=3)This has been detected as hybrid interlaced/progressive, mostly interlaced.
321 LeakKernelDeint(order=1,sharp=true)Detected as completely interlaced

Yeesh. It really shows why having real-world examples for testing would have been useful.... it looks like I've made the thresholds too sensitive, so they detect way too many things as hybrid, when they are probably not. I guess that your sources are probably all TFF, interlaced, which means that you could use the LeakKernelDeint filter on all of them.

With regards to this, then the choice with source detection is to desensitive the thresholds, which could stuff up the few people with terrible hybrid sources that have only small amounts of the other types, I could leave it as it is, I could spend a lot of time rethinking the algorithm, or I could make processing take several times longer, to get more information about the source.

My inclination is to lower the thresholds. I was modelling my thresholds on AutoGK, which seemed to be able to pick up any hybrid combinations, so I made my algorithm ultra-sensitive to match that. It seems like I forgot about normal sources.

With regards to what source detection recommended to you, each of the settings recommended are fine, IMO. None of them will actually harm your video, and they all will deinterlace it. So the end result is not a problem, but the detection is (only very slightly) off.

EDIT: Alternatively, I could leave it alone. There is nothing drastically wrong with any of the filter-chains it recommended -- each of them deinterlaces (even the tfm().tdecimate(mode=3) one is designed to deinterlace as part of tfm's PP, and upsample the film sections that TDecimate detects!), so it isn't too much of a problem. Most of your results were pretty consistent, anyway. Maybe the problem (very minor, actually) is just too much choice?