Approach to automatic decombing?

[bilu]

Hi,

There are lots of encoding tools who could benefit from automatic reliable decombing (many will see "reliable" and "automatic" as an oxymoron,right? ;) ).

Seems neuron2's opinion about an all-purpose video deinterlacer goes to TomsMoComp:

http://forum.doom9.org/showthread.php?s=&postid=325357#post325357

http://forum.doom9.org/showthread.php?s=&postid=325522#post325522

Tried it today, does a very good job.There are no tools around for automatic IVTC, I think.


I've seen some other ideas around:

http://forum.doom9.org/showthread.php?s=&threadid=54191

This is a tool that works with Telecide's (debug=true) mode by processing the output captured by DebugView, I haven't got it to work yet.In the mean time I found a better process than DebugView:

http://www.post1.com/home/ivec/dbgproxy.html

This tool forwards Windows OutputDebugString to MS-DOS STDERR, which I can redirect to a file (on XP at least) using AVS2AVI and a XVID Null encode:

dbgproxy avs2avi MOVIE.AVS MOVIE.AVI -s codec.cfg 2> debug.txt

and then parse the Telecide output.

(no typo on the > syntax, using 2> redirects STDERR instead of STDOUT)



Well, back to the point:

I guess we could in theory do a XVID Null encode with and AVS script with just MPEG2Source and Telecide(debug=true) to get the metrics, and then make a strategy out of it to use as an override file on the real encodes.

A Null encode with just this filter would be relatively quick and save time on both passes as well as improving reliability.

Better yet, such process could be done automaticaly based on the metrics and so avoiding user analisys ( and deal with hard-telecined sources too, not like my primitive ParseD2V method based on FILM flags).


Neuron2 also talked about the possibility of such a method once:

http://forum.doom9.org/showthread.php?s=&threadid=52928

and I would like to hear his opinion again, although I know he has been very, very busy. :)


Of course I'd like other opinions as well :D


Best regards,
Bilu

[Guest]

I don't understand your specifications, since you didn't give any. :)

Are you trying to create a tool with this specification?

"Perform perfect decombing without any user intervention".

If not, please clarify the specifications.

And BTW, forum rules proscribe you from asking for the best anything; thread title edited.

[bilu]

Thanks for editing the title :)

My idea is:

1) XVID Null encode with Telecide(debug=true) and DBGProxy, just to get the metrics

2) *Missing* A strategy to find out field order and if the stream is interlaced PAL, reversed field PAL, Telecined / Hard-Telecined (wouldn't matter any more since we wouldn't base our work on flags :) ), Mostly Film Hybrid or Mostly Video Hybrid.

I haven't looked if any parameter in Telecide has influence in the metrics, and what could be done in this case. But it would be nice to be able to use a strategy based on the metrics because we could in theory automate the process. I also didn't look yet at possible ways to use the override files like in the tool I mentioned on my first post.

3) Encode using the Telecide and Decimate override files?


It's basically the same idea you mentioned on the "all purpose script needed" thread (last link on my first post)


Do you think such a strategy is possible?



Best regards,
Bilu

[manono]

Hi-

I'm not sure I understand fully, but this sounds fairly similar to what MultiDecimate does. You run a real fast "First Pass" to get the metrics (I'm getting around 100fps with it, although I'd probably have to explain to you you how I can do that), and then you set up the 2 real passes using the Cycle Mode. The decimation there is determined by the metrics, and what kind of Cycle-Frame Removal you specify. Have you looked at MultiDecimate, bilu, to see if it does what you want?

[bilu]

@manono

Thanks to Tom Daniel ('manono') for suggesting this new decimation functionality.

I guess you know it well, don't you? :p


It's partially what MultiDecimate does. I've tested it now for the first time using:

ConvertToYUY2(interlaced=true)
Telecide(post=false)
MultiDecimate(pass=1,quality=3)

Metrics are already saved to a file so I could skip the whole DBGProxy process.

This was the mfile.txt generated by first pass on a Telecined encode:

0 0.000000
1 0.688529
2 0.730384
3 0.896588
4 0.000000
5 0.741072
6 1.285882
7 1.167753
8 1.094568
9 0.000000
10 1.347239
11 1.387400
12 1.430105
13 1.715316
14 0.000000
15 1.434957
16 1.486446
17 1.716319
18 2.016002
19 0.000000
20 1.617898
21 1.833077
....

There are cyclic duplicates (0,4,9,14,19,...) so we know we can decimate here. This works as a duplicate detector, but says nothing about the field order (I think).

A command-line interface instead of a GUI is required to automate the second-pass process.

It would need a new mode: something like "Global Protect static scenes" mode, (i.e. that would only decimate if lower than a threshold and lower than the number of defined duplicates in a row).

This mode should be enhanced to deal with hybrid decimation when needed, i.e. that could recognize Telecined streams, look at the Video/Film ratio to choose the best method, and that could decimate Video parts on hybrids in the new way described by Neuron2 on his journal (it's a must).


So what I'm saying is:

1) Generated metrics should help distinguish Field Order, Video and Film parts;

2) The process should depend entirely on script plugins and/or command-line tools, not GUIs;

3) Should be able to calculate a FILM cycle percentage to decide between mode=1 or mode=3 decimation strategies;

4) Should decimate Video parts in neuron2's new mode: I think it's hard to improve on that :)

This way we would have a nice automatic 2-pass hybrid decombing :)



I had a problem using MultiDecimate over the progressive Fox News clip that neuron2 has on his journal.

Loaded with DirectShowSource("D:\fox30.avi",29.97)

Using "Global: Protect static scenes" with a threshold=1.0 or 0.5 and a run length=2 I got a clip with listed FPS of 9.396 fps ( on Zoom Player ). And that's strange because it only detected 3 duplicates at the end of the clip :confused:


Do you think this is a realistic objective?


I'm getting around 100fps with it, although I'd probably have to explain to you you how I can do that

A Null encode with only the needed MultiDecimate and Mpeg2source filters plus a fast IDCT? Or other stuff? :)


Best regards,
Bilu

[bilu]

Another typical application is removing 3 out of 4 frames for clips that were rendered at 120fps to properly present hybrids of film and video.
Haven't tried this method yet, is it reliable?


I have also looked more seriously at Decombs override options (using 4.1b4).

A process could be:

1) Use MultiDecimate 1st pass to get metrics;

2) Parse the file for duplicate framenumbers and post them into another file;

3) Check the framenumber differences between duplicates and save them to a file;

4) Check how many of these differences are 5's and make an hybrid decombing decision based on it;

5) Generate override file with the "v" and "f" flags;

6) Encode :)


Bilu

[manono]

Hi bilu-

I guess you know it well, don't you?

MultiDecimate is a godsend for encoding silent films with weird cycles. Any of you guys out there encoding silents, jump on it. I haven't decided for myself yet just how useful it'll be for encoding hybrid material, as I haven't seen any recently. There may be problems with keeping the audio in synch.

A Null encode with only the needed MultiDecimate and Mpeg2source filters plus a fast IDCT? Or other stuff?

I just tried XviD's Null Mode for the first time, and it works well. Thanks for the tip. And I also crop pretty heavily into the video to make it run faster, since it's just finding the metrics. And if you don't at least crop the black bars away, it'll lower the metrics significantly.

Haven't tried this method yet, is it reliable?

If you're asking me, I don't have any anime raws with which to test, but I don't see why it wouldn't work well. The anime fansubbers should be experimenting with it also.

The rest of what you're asking is for neuron2 to answer, but:

This way we would have a nice automatic 2-pass hybrid decombing

I think you must be dreaming. :)

[Guest]

Originally posted by manono
This way we would have a nice automatic 2-pass hybrid decombing

I think you must be dreaming. :) No, I think it's feasible.

[bilu]

I've looked at http://www.doom9.org/ivtc-tut.htm, sections "PAL TO NTSC" and "BAD TELECINES". It seemed to me that sometimes you could get Telecine patterns different from 5.

"Check the framenumber differences between duplicates and save them to a file" seems a nice strategy here. We could avoid decimating the next duplicate when difference=1, to protect static scenes. We could also know which is the most used difference pattern on the clip and use it for decimation.

Example: 55 differences of 5, 20 differences of 3.
We would choose 5 for decimate.

I don't know if there are any streams around with patterns using more than one duplicate in a row. I'd like opinions on that.

No, I think it's feasible.

Am I thinking correctly? What would you add?



Best regards,
Bilu

[manono]

Hi-

It seemed to me that sometimes you could get Telecine patterns different from 5.

Sure. Quite a few PAL to NTSC DVDs are converted from 25fps, and not slowed first to 24fps before telecining, and you have to Decimate(6) to get them to play smoothly. One common framerate for silent films is 20fps, and you Decimate(3). And for silent films in particular, they can be on the DVD as anything from 15 to 25 original fps.

I don't know if there are any streams around with patterns using more than one duplicate in a row.

They're rare in my experience, but not unheard of. I saw one just today, as a matter of fact. Every so often there was a "mini-cycle" of 4, with 2 original frames followed by 2 duplicates of the second frame. And of course anime is frequently drawn as 8 or 12fps and has multiple duplicates in a row.

[bilu]

Originally posted by manono
They're rare in my experience, but not unheard of. I saw one just today, as a matter of fact. Every so often there was a "mini-cycle" of 4, with 2 original frames followed by 2 duplicates of the second frame.

Was it anime, silent film, or a movie?

Bilu

[bilu]

@manono

I maybe killing my own thread by posting off-topic, but I have a doubt and maybe you can help me:

I've been testing hybrid decombing modes over completely film or completely video streams because I have no hybrid movies. So I grab every weird sample I can ( haven't grabbed the chest torture clip that neuron2 posted on the Uncomb thread though )

I've tested with this one posted here:
http://forum.doom9.org/showthread.php?s=&postid=325687#post325687

using MultiDecimate(pass=1) and noticed that duplicates aren't 0.00000 in the metrics, but something between 0 and 1 even using post=false.

Do you think it is safe to assume that metrics from imperfect duplicates with blended fields like these will allways be less than one? Better to use TomsMoComp over the others?

Thanks in advance,
Bilu

[MrBunny]

@bilu

Mr. Graft is still hosting the Star Trek Challenge vob which is a standard hybrid clip, but hard to deal with because of the rapid pan.

http://forum.doom9.org/showthread.php?threadid=43362

You can have a look at it if you want an example of a hybrid source. It is a bit short though.

[bilu]

@MrBunny

Thanks :)

[manono]

Hi bilu-

Was it anime, silent film, or a movie?

It was both a silent film and a movie. :) Outside of anime, though, I think I've seen that happen only half a dozen times or so, and always with silents with large and complicated cycles.

Do you think it is safe to assume that metrics from imperfect duplicates with blended fields like these will allways be less than one?

I know it's not safe to assume that. They can be frequently over 1. I've seen quite a few DVDs that I think were mastered from laserdisc, and the duplicate frames are often different enough from the frame before them to give a metric larger than 1. A lot of the BBC TV shows converted to NTSC DVD were mastered from videotape or some such garbage and show the same thing.

[bilu]

Manono,

Do you think duplicate metrics range should be about the same for an entire movie?

I ask this because I made a test over Swan's snip.avi clip
(http://forum.doom9.org/showthread.php?s=&postid=325687#post325687)
with a batch file that has int(metric) as parameter.

So if I run "do.bat 1" it will select every frame with int(metric)=1, output framenumber differences to a file and then count the differences.

The results is more clear than the explanation, I think.

do.bat 0
========
1 2
2 5
3 4
4 1
5 62
6 0
7 0
8 0
9 0
10 4
11 0
12 0
13 0
14 0
15 0

This shows that there were 62 frames with int(metric)=0 with a difference of five frames to the next frame within the same int(metric).

do.bat 1
========
1 28
2 8
3 6
4 3
5 6
6 2
7 1
8 2
9 0
10 0
11 0
12 0
13 0
14 1
15 0

do.bat 2
========
1 43
2 19
3 11
4 6
5 2
6 0
7 2
8 2
9 1
10 0
11 0
12 2
13 2
14 0
15 0

do.bat 3
========
1 38
2 10
3 5
4 7
5 1
6 2
7 1
8 3
9 4
10 1
11 0
12 1
13 0
14 1
15 0

So if:
- lower thresholds mean better probability to be a duplicate;
- difference=1 means consecutive frames within the same metric range, probably not combed parts;

Then maybe the probable cycle is 5, because it's the most used difference in lower thresholds, and difference=1 shouldn't be accounted.

And if you calculate

(nr of duplicates on cycle)/(framecount/cycle)

62 / (379/5) = 62/75,8 = 0,817

it gives you 0,817 in this case, which means this duplicate pattern at the 5th frame is used in 81,7% of the stream. This would make us choose Decimate (mode=3) as we recognized it as a mostly film hybrid.


What do you think?

Best regards,
Bilu

[manono]

Hi-

What do you think?

Sorry bilu, but I didn't understand any of it. I just use MultiDecimate for decimating silent films where the cycles can be large and complex (I've seen cycles of over 200 frames). It isn't and can't be perfect, because sometimes the true original frames have metrics lower than the duplicate frames, if the source material isn't so good. This can occur when there isn't much or isn't any movement in the original frame, or when the movement is off in the distance. This can also occur if the duplicate is a blend of 2 frames and has a larger metric than some of the true original frames in the designated cycle. This can be fixed by adjusting the metrics manually, but can get pretty time consuming.

I would like to try it out with some hybrid material one of these days. I'll probably have some anime to test soon. But it may not be too useful for that unless we have the option to "Remove no more than x frames out of every y frames", in order to keep the duplicates meant to be kept, from being removed. And I'm still not sure how to maintain audio synch, unless you keep the cycle low enough.

[bilu]

It isn't and can't be perfect, because sometimes the true original frames have metrics lower than the duplicate frames, if the source material isn't so good. This can occur when there isn't much or isn't any movement in the original frame, or when the movement is off in the distance. This can also occur if the duplicate is a blend of 2 frames and has a larger metric than some of the true original frames in the designated cycle.

Yes, I know now :rolleyes:

I've uploaded the D2V file, the MultiDecimate metrics file, my batch file for counting duplicates (XP only, same dir as mfile.txt) and the results from running the batch for int(metrics)=0, 1 and 2.

http://pagpessoais.iol.pt/bruno_henriques/tngsample/

The clip is TNGsample.vob from the "Star Trek hybrid challenge" thread.

I can see now that metrics are not reliable for detecting duplicates, at least for now :(


Bilu

[bilu]

This may have potential:

Quantified Motion Filter: adaptive motion filter for Avisynth
http://forum.doom9.org/showthread.php?s=&threadid=56051

Having the possibility to separate low-motion from the rest could enable duplicate search for thresholds 0.00000 and between 0 and 1 (maybe 2?) on the medium/high motion metrics file.

For low-motion metrics we would only search for 0.00000.

If we don't find enough 0.00000 in the low-motion metrics we would have to stick to the result from the high/medium motion metrics file.

Besides cropping black bars this could be a precision enhancer too.

I'll have to check that.


Bilu

[sh0dan]

Conditional filter support would be a great thing for decomb i agree. If it (in some version) was able to simply return the combing detections it makes it would be even more flexible.

However I don't think it's the time right now, as Donald is currently working on these algorithms. Personally I would rather see a stabilized version with YV12 support.

There is one small (development) problem. For decomb to become conditional, it would have to be able to do the decision without having ant knowledge of any prior decisions. I son't know if decomb still stores previous decisions for pattern recognizion, of if it is completely beyond that, and each frame is considered separate.

[bilu]

Originally posted by sh0dan
There is one small (development) problem. For decomb to become conditional, it would have to be able to do the decision without having ant knowledge of any prior decisions. I son't know if decomb still stores previous decisions for pattern recognizion, of if it is completely beyond that, and each frame is considered separate.

For this to work nicely it would have to become a 2-pass process like in MultiDecimate. It's also the only way to choose between mode=1 or mode=3 automatically on hybrid movies.

EDIT: On this thread I've been looking for reliable processes to obtain statistics useful for pattern detection so we could make a safe decision for a second pass. Metrics on low-motion have been a problem, and so have been blended fields (maybe they can be "patterned" as well?).


Bilu

[bilu]

NOTE 1:I'm now using this function on MPEG-2 sources for Telecide:

function FOrder(clip c) {
fo= GetParity(c)? 1:0
return fo
}

Usage example: Telecide(order=FOrder(),guide=1,post=0,show=true)


NOTE 2:After reading this neuron2 post:

http://forum.doom9.org/showthread.php?s=&postid=337685#post337685

about Star Trek hybrids I decided to make a test with

Telecide(order=1, guide=1,post=0,debug=true)

and after parsing I noticed the matching was perfect. That was not the case when using post=2 or post=4 unless I used a high vthresh like neuron2 mentioned.

Parsing the output is great to recognize patterns: ncccn is Telecine and nccccn is PAL to NTSC conversion. That's why I'm testing with guide=0 mostly because it fails sometimes but not that much and I can find every kind of pattern this way.

In a test using guide=1 with the Star Trek TNG clip I had a parsing result of 73% FILM and 63% FILM using guide=0. Seems to me guide=0 is enough to make a decision. I plan to still use ParseD2V to check for MPEG-2 FILM flags. If they exist, pattern checking will be done with guide=1, just to get how much is FILM to decide between mode=1 or mode=3 behaviour.

I've also noticed on another clip that on a very slow panning motion and pure telecined clip Telecide couldn't match the pattern either with guide=0 or guide=1, it was about 300 frames all matching current.

It's understandable that such low-motion is hard to match any kind of motion-pattern. That's why I intend to use the QMF script

http://forum.doom9.org/showthread.php?s=&threadid=56051

with Telecide, checking the limits for pattern detecting to define a medium-motion threshold from which I can use Telecide. This way I would only get the metrics over telecide-measurable motion. If I didn't get enough (to be defined) measurable motion from a clip my automatic process would exit asking for the user to do a manual analisys.

I won't have the time to test this week and the next, but it does sound reasonable to me :)


Bilu

[Si]

function MakeTopFirst(clip c) {
c= GetParity(c)? c:ComplementParity(c)
return c
}


I'm not a function person (never written one in fact) but doesn't your function just check the parity and if its true, leave it alone and if its false , reverse it?

If this is true and given that Parity in Avisynth is just a "state of mind" couldn't you just use AssumeTFF (or have I lost something on this journey :confused: :) )

regards

Simon

[bilu]

@ siwalters

http://www.avisynth.org/index.php?page=AssumeFieldFirst

However, this information isn't necessarily correct, because field information usually isn't stored in video files and AviSynth's source filters just normally default to assuming bottom field first (with the exception of the MPEG2Source plugin which gets it right!). AssumeTFF and AssumeBFF let you explicity tell Avisynth what you believe the field order type a clip is.

http://www.avisynth.org/index.php?page=ComplementParity

If the input clip is field-based, ComplementParity changes top fields to bottom fields and vice-versa. If the input clip is frame-based, it changes each frame's dominant field (bottom-dominant to top-dominant and vice-versa).

That's why I use ComplementParity, to be able to use Telecide(order=1) allways.

EDIT: This is just for MPEG-2, take a look at this thread also:

http://forum.doom9.org/showthread.php?s=&threadid=55665


Bilu

[Si]

IMO the only way to get your head around "Parity" is to extensively play with it.

If you make up a clip with distictive red top and green bottom fields - lets call this source.

source
ViewFields

gives red at top - green on bottom.


source
ComplementParity
ViewFields

gives red at top - green at bottom

source
separatefields
ComplementParity
Weave
ViewFields

gives green at top - red at bottom (a spatial field swap function)

So you can see if doesn't physically alter field spatial or temporal order unless you use it after a separatefields command.

To alter the "field domininance" requires the use of a field dominance reverser filter (cough -see my website :o ) or a bit of juggling with separatefields/weave/selecteven/odd/trim etc)

I hope there are no mistakes in the above - it is so easy to let a typo blow you out of the water on this subject :)

So AFAICT your function changes the Parity flag to true if its false and keeps it true if its true (yes/no?)

Given that Ben thought bottom field dominance was the norm I assume your function could be replaced by AssumeBFF (but it could be AssumeTFF if my assumption is wrong. :confused: )

If your source has had separatefields applied to it prior to the function then it will spatially swap the fields.

Hope this helps but I know field order discussions aren't actually helpful in practice ;)

regards
Simon
PS anyone got a function to display parity status as Info is saying parity unknown even if I put in an AssumeTFF before it :(

[bilu]

GetParity gets true if clip is TFF.

You were right about ComplementParity, SwapFields does the job you mentioned.

Still I found that it wasn't what I wanted: changing field-dominance can make wrong matches like fields 1-0-3-2 instead on 0-1-2-3. It's better to define a function for the Telecide order switch. I've changed my prior post, has a reliable function for MPEG-2 now.


Thanks for the feedback :)

Bilu

[FredThompson]

You might want to modify this to set flags for your routine:

GetParity() ? nop() : ReverseFieldDominance()

It makes TFF into BFF without any loss of fields.

Right now my head is fuzzed up trying to puzzle through a complex ConditionalFilter so I don't know if that line helps you or not.

Auto-deinterlace sure seems interesting.

Why do you have to define a function? Can't you just use a phrase similar to the one above in the call?

[bilu]

My function has changed to

function FOrder(clip c) {
fo= GetParity(c)? 1:0
return fo
}

Usage example: Telecide(order=FOrder(),guide=1,post=0,show=true)

and updated on my prior post, don't know if you're talking about this one or the older function.

I didn't knew ReverseFieldDominance but now I took a look at neuron2 site for an explanation. It does field shifting in a way that could probably affect IVTC patterns or something. I haven't tested it, but then again my new function seems to be the safer path (at least to me) since it doesn't change the stream.

About using a function instead of just a boolean condition: Telecide commands become easier to read and write.
If you look at the tool in my sig, you'll see a file called functions.avs to be imported later.

I keep a lot of functions there. :)


Bilu

[FredThompson]

Understand about function declaration. I'm doing the same with some current stuff and also using import.

I was using the Simon Walter's AVS version but you got me to thinking so I went back to his site which led to here: http://forum.doom9.org/showthread.php?s=&threadid=46765

The reason for changing the stream is DV camcorder is TFF. Was looking for a way to convert to BFF if needed because it's too hard to keep track of which files are TFF and which are BFF. Oh, I keep everything interlaced if at all possible. That's a big difference.

This is what Donald suggested so I went with it after discovering the DoubleWeave trick yields a broken stream.

[Si]

@Fred
The reason for changing the stream is DV camcorder is TFF.
Many people have said DV Camcorder (both PAL and NTSC) is always BFF.

When I personally transferred some footage off a PAL DV camcorder using firewire I had to change the footage from BFF to TFF to play it out to VHS through my Matrox G400.

As I've said many times - field order is a nightmare subject ;)

regards
Simon

[FredThompson]

Yes, you're correct, DV is BFF. CCE defaults to TFF and that's what I was using. The whole reason for the line of code is so I don't have to remember which is dominant ;)

[bilu]

It's not sad, but worrying: neuron2 is leaving the forum, but not development.

I'll still base my work in this thread on his work though, I have no choice :D (as good and adequate as his work, I mean)

http://forum.doom9.org/showthread.php?s=&threadid=57337


Bilu

[bilu]

A first glance of what can be expected through MPEG-2 pattern recognizing. I won't post how I did it yet because it's based on XP batch language and a DOS tool from Simtel.net, and I want to learn awk and work with it.

Basically I parsed Telecide's debug output of the command:

Telecide(order=FOrder(),guide=0,gthresh=0,post=0,debug=true)

and then accounted

ncccn -> Telecine

nccccn -> PAL to NTSC conversion

ncc -> somewhat used anime pattern, MPEG-2 flags are 3131313131. Accounted after deleting the other patterns.

Some results (won't post the links for samples posted in the forum yet):

Dragons Lair (old cartoon)
============
FILM = 60
PAL2NTSC = 7
ANIME = 4

Neo Genesis Evangelion (anime)
======================
FILM = 36
PAL2NTSC = 8
ANIME = 21

Read or Die (anime)
===================
FILM = 25
PAL2NTSC = 10
ANIME = 26

Star Trek TNG "Hybrid Challenge" clip
=====================================
FILM = 62
PAL2NTSC = 0
ANIME = 5

Lord of the Rings
=================
FILM = 99
PAL2NTSC = 0
ANIME = 0

Monty Python's And Now For Something Completely Different
=========================================================
FILM = 98
PAL2NTSC = 0
ANIME = 0

It seems to be a credible way for making an automatic decision, and as I said before, by using ParseD2V I can use guide=1 for sure if it finds 0123 Telecine MPEG-2 flags to garantee a more precise result.

But the most important is that this process does not depend on MPEG-2 repeat flags and can work on hard-telecined streams.

The ANIME pattern can help making a decision, although I don't know which decision could be more correct because I never encoded anime.


Best regards,
Bilu

[bilu]

Since ANIME patterns like 3131313 exist for creating duplicates, I think it makes sense to use IVTC over these if FILM patterns were found.

If you can imagine a Telecine pattern over an ANIME pattern, you know things can get very ugly. So maybe it's better to account ANIME patterns for an IVTC frame decision.

Remembering again neuron2 last post about the Star Trek TNG clip

http://forum.doom9.org/showthread.php?s=&postid=337685#post337685

about using a larger vthresh for IVTC on hybrids, I tried it with default vthresh and it really messed up the pattern recognition. With a higher vthresh it was perfect as he said.

I'm tempted to work with guide=1,post=0 allways on hybrids or anime (after finding with my process if they are hybrids or anime on a first step) and deinterlace afterwards with DGBob, TomsMoComp or FieldDeinterlace. This way I can't get bad matching caused by hybrid processing.

I'm also tempted to account ANIME and FILM patterns together for a Decimate mode decision.


EDIT: Tried neuron2 method for Star Trek TNG on encoding, not just on metrics.

Telecide(order=FOrder(),guide=1,post=4,vthresh=45,hints=true)
Decimate(mode=3,threshold=0.6)

works better than the other approaches I was tempted to try.
Also tried it over all the clips I mentioned before and it worked flawlessly. I'll make it my default approach over Pure Telecine, Hybrid and NTSC Anime movies.


Best regards,
Bilu

[bilu]

Thread will be continued from here:

http://neuron2.net/ipw-web/bulletin/bb/viewtopic.php?t=13

It makes more sense to get the feedback from both developers and users of the tools used in this thread, that's why I made this decision.


Bilu