TDeint and TIVTC

[tritical]

Yeah, you should be able to replace it, but I'm not sure exactly what your script is suppose to do. Cause IsCombed and IsCombedTIVTC each only return true or false, but in your script you are testing if the result is less then 14 which it always will be since it can only be 0 or 1.

The number of parameters doesn't really make a difference, to call it with multiple parameters just do:

conditionalfilter(X,X,Y,"IsCombedTIVTC(MI=32,blocky=8,blockx=8,chroma=false)", "=", "true")

as an example.

[Chainmax]

This script portion is supposed to reduce jumpy lines on combed frames and was suggested by scharfis_brain to BoNz1 a long time ago in this thread (http://forum.doom9.org/showthread.php?s=&threadid=69565&highlight=jumpy+lines). I'm guessing that the 14 in the conditionalfilter line is related to the threshold parameter in IsCombed.

[tritical]

I think he probably meant something like this:

x=mpegsource("trallalaa")
y=x.trim(1,0)
conditionalfilter(x,x,y,"iscombed(threshold=14)","=","false")

Cause you can test the original version:

x=mpegsource("trallalaa")
y=x.trim(1,0)
conditionalfilter(x,x,y,"iscombed","<","14")

And it will always return x, since the result of iscombed is always less then 14.

[Chainmax]

I don't think so because he said this as well:

you'll maybe have to replace < with > and adjust 14 up or down.

Maybe he can explain it himself? I'll PM him and ask what he meant.

[scharfis_brain]

x=mpegsource("trallalaa")
y=x.trim(1,0)
conditionalfilter(x,x,y,"iscombed(threshold=14)","=","false")

wherever this script snipplet is from, I can remember it was questioned for a functionality, that replaces a combed frame with its predecessor. (maybe useful for low-fps telecined anime, not suited for 24fps or so footage)

that's all the magic behind.

[tritical]

I am not questioning the functionality of this line:

conditionalfilter(x,x,y,"iscombed(threshold=14)","=","false")

but this line:

conditionalfilter(x,x,y,"iscombed","<","14")

That line is nothing more then a slow way to return all the frames from the "x" clip. The operator and value strings "<" and "14" have nothing to do with any parameters the function takes. They are used only in conjunction with the return value from the function to see if the statement is true. And in the case of IsCombed the return value is only false or true (0 or 1). So testing if the return value is less then 14 will always return true and that line will always return the frame from source 1 (x). You can test it yourself, any "<" or ">" test won't make a difference (it will always either return all source "x" frames or all source "y" frames) for IsCombed unless it differentiates between 0 and 1 (true or false).

[scharfis_brain]

the line
conditionalfilter(x,x,y,"iscombed","<","14")

is pretty much useless, cause iscombed does not return comb-amount-values.

it only returns true/false if the current frame reaches the given threshold.
the threshold has to be set within iscombed, not outside.

[Chainmax]

That's exactly the line you recommended in the thread I linked to...what did you mean to recommend then?

[scharfis_brain]

which thread?

[Mug Funky]

http://forum.doom9.org/showthread.php?s=&threadid=69565&highlight=jumpy+lines

that one.

you also said you hadn't tested it... :)

[Chainmax]

You posted the answer before I could...bad, bad Mud Funky :P ;). This goddamned computer keeps hanging up constantly. I'm gong to have it checked, I swear.

scharfis_brain: the link to that thread is nine posts above this one.

[scharfis_brain]

WTF....

Did I really wrote this?

hmm...
This occurs, if one is doing direct stream copy form brain to keyboard without AVS-Check :(

obviously the condfilter-line I posted about one year ago is WRONG. Stupid me...

[Leak]

I was wondering - will you be adding MMX or SSE code to this plugin?

This would be a great way to make it waaay faster than Decomb, and I guess that the parts which do the frame metrics calculation and blending (where the filter most likely spends the most time in) aren't gonna change much anymore, right?

If you want, I can give it a try. :)

np: Yasushi Ishii - Musical Play Smiling Rebellious Flower (Hellsing Original Soundtrack Raid)

[tritical]

I wasn't planning on it. If you want to take a look and try speeding parts of it up be my guest :). Assuming normal processing (non-combed frames, etc...) the majority of the time is spent in only three routines:

match comparison (TFM)
combed frame detection (TFM)
diff metric calculations (TDecimate)

TDecimate is usually slower then TFM by a good bit when there aren't a lot of frames that need deinterlacing or need extra matches tried. The frame blending routine in tdecimate is also ridicously slow... I didn't spend any time on it cause I never use blending, but it would be by far the easiest one to make an mmx version of, and could probably give a good speed up if a lot of blending is taking place.

[tritical]

Said I wasn't going to, but the frame blending routine was very simple to make an mmx version of so I went ahead and did it. I'm definitely not gonna try to do mmx or isse versions of the other main functions though. This version also includes a few minor fixes to TDecimate having to do with incorrect mkv timecode v2 format output in modes 3 and 5. Here it is... [link removed, look farther into the thread]. Changes:


TDecimate:

- fixed outputting of a few extra timecode entries when using
tcfv1=false (v2 format) in mode 3 or mode 5 and the last
frame was not a cycle boundary
- fixed incorrect formatting of the first 2 lines of the
mkvOut file when in mode 3 and using tcfv1=false (v2 format)
+ added mmx and sse2 blending routines (used when hybrid = 1)

[Leak]

Originally posted by tritical
Said I wasn't going to, but the frame blending routine was very simple to make an mmx version of so I went ahead and did it.

Whoa - that would have been the first thing for me to do come this weekend... :)

I'm definitely not gonna try to do mmx or isse versions of the other main functions though.

Well, I'll do that, then...

Also, would you mind me adding a "forceCPU" parameter as seen in my plugins? If I manage to introduce bugs into the MMX or SSE code (and I know I will, at least at first... :)) it would let everybody and their dog fall back to the plain C++ versions.

np: K-Taro Takanami - Love Of Babble (Chobits Original Soundtrack 001)

[tritical]

Nope, I wouldn't mind... you can add whatever you feel like :D.

[Leak]

Originally posted by tritical
Nope, I wouldn't mind... you can add whatever you feel like :D.

Ugh. Well, I would have already done something if I hadn't underestimated the time marking 24 MicroJava-compilers for my part-time tutor job at the university takes... :(

I'll try to start on it this weekend even though I have to come into work on Saturday.

Anyhow, I just tried TIVTC on the first episode of Ghost In The Shell: Stand Alone Complex and found that there was a duplicate frame causing a stutter after a few scenechanges, just as it happened with Decomb on other sources.

I'm wondering - since you're already doing scene change detection for the video parts, would it be possible to detect them for the film parts as well and treat them specially?

I was thinking about something like this:

If you find a scenechange and on one side of it there are more than <cycle> dups in a row, look for a frame to drop on the opposite side of the scenechange first and drop a frame there if you can find one - this would take care of scenechanges that go from a still scene to a moving one.

On the other hand, if the scenechange is badly edited so you'd have to drop a duplicate on both sides (which might be detectable by looking ahead and back a bit and finding out the used pattern, or just by checking if there's 2 or more candidates within <cycle> frames of the scenechange in both directions) you could drop the one closest to the scenechange on each side and insert a new frame at the scenechange's position that blends the 2 neighbouring frames so audio & video stay in sync. IMHO that would be much less noticeable than a sudden jerk in a pan that just started or ended.

I tried cutting out a scene or two to illustrate this, but everytime I cut out a part with Cuttermaran, run it through DGIndex and load it in an AviSynth script, I get different metrics in TDecimate due to different combing... :confused: (and yes, I did cut at an I-frame and chose starting points that didn't cause a shift of the cycles that TFM gets...)

Well, this is just a suggestion; I'll see if I can find a way to cut out parts reliably (help, anyone?) and upload you an example or two if I manage to do it - if you want, of course. :)

np: Autechre - Latent Quarter (Envane)

[tritical]

Well, a few minutes investigation into Leak's observation revealed that longest string decimation mode in v0.9.4 and before has a couple bugs causing it to not work correctly (i.e. not at all for what it is intended to do)... There is a reason why this filter isn't 1.0 yet :D. Anyways, I've fixed the above mentioned bugs, but am gonna wait till I get a chance to check out Leak's sample before posting a new version. So I would recommend no one use longest string decimation in TDecimate for the time being.

[BangoO]

Hi tritical and the others.

First of all, thx for these great filters.
TFM() works like a charm, a lot better than Telecide() from what I tested.
TDecimate() works also better than Decimate(), but it's awfully slow, I don't know whether it's normal or not.

The source is an HDTV 1080i file that I'm trying to IVTC.
With a TFM() followed by a Decimate(), I encode in WM9 at around 8fps.
Just replacing the Decimate() with a TDecimate(), I encode in WM9 at around 2fps.

Both Decimate() and FDecimate() use the default values.

Is this normal ?
If not, what should I do ?

Thx a lot ;)

PS: I use this version TIVTCv094-1.zip
PS2: I have a P4 3.2

[tritical]

In a word, yep :(. The main things that make it so much slower are:

1.) by default decimate only checks luma while tdecimate checks both luma and chroma (set quality = 3 in decimate to sample both)
2.) tdecimate uses overlapping blocks while decimate doesn't
3.) tdecimate can use user defined block sizes in metric calculations (the blockx and blocky parameters) while decimate uses fixed 32x32 blocks

I am suprised it was that much of a drop off, though it would make more difference with larger frame sizes. I could try adding a quality setting like decimate has (to do subsampling) or having a metrics mode that does not use overlapping blocks or both. Though then tdecimate would be pretty much the same as decimate for most similar 1-in-N non-hybrid cases.

[BangoO]

Thx for the fast answer :)
It would be nice to have a TDecimate as fast as Decimate, but then it would be Decimate... so...

I'll try playing with Decimate() parameters to check if I can get something perfect.
It works perfectly 99% of the time, TDecimate worked on the last 1%, too bad :)

[tritical]

[link removed, look farther down], changes:


TDecimate:

- Fixed problems with longest string decimation and static to
panning and panning to static scene workarounds in longest
string decimation
+ added se parameter (causes mode 3 to stop early once the last
actual frame is delivered)
+ mmx and sse2 blending routines now work with any width (not
just mod 8 and mod 16)

This version should fix all problems with longest string decimation and correctly handle Leak's clip (whichever way it is decoded :D).

[BangoO]

triptical, I have a file (29.97fps 3:2 pattern, that I'm trying to IVTC) with a glitch in the middle resulting in a field order change (bff to tff).

When I was using Telecide, my script looked like that:

Loadplugin("C:\Program Files\AVIsynth 2.5\plugins\mpeg2dec3.dll")
a = trim(mpeg2source("D:\test.d2v"),0,80192)
b = trim(mpeg2source("D:\test.d2v"),80193,0)
a = Telecide(a,order=0,guide=1,post=2)
a = Decimate(a)
b = Telecide(b,order=1,guide=1,post=2)
b = Decimate(b)
return a + b


So, with your filters, I thought I could use:

Loadplugin("C:\Program Files\AVIsynth 2.5\plugins\mpeg2dec3.dll")
Loadplugin("C:\Program Files\AVIsynth 2.5\plugins\TIVTC\TIVTC.dll")
a = trim(mpeg2source("D:\test.d2v"),0,80192)
b = trim(mpeg2source("D:\test.d2v"),80193,0)
a = TFM(a,order=0)
a = Decimate(a)
b = TFM(b,order=1)
b = Decimate(b)
return a + b

But it does not work, the second part of the clip goes "forward and backward".


So I tried this:
Loadplugin("C:\Program Files\AVIsynth 2.5\plugins\mpeg2dec3.dll")
Loadplugin("C:\Program Files\AVIsynth 2.5\plugins\TIVTC\TIVTC.dll")
mpeg2source("D:\test.d2v")
TFM()
Decimate()

But it displays lots of interlaced frames in the second part since the field order is wrong.


So, then, I tried to play with the options of TFM and tried this:

Loadplugin("C:\Program Files\AVIsynth 2.5\plugins\mpeg2dec3.dll")
Loadplugin("C:\Program Files\AVIsynth 2.5\plugins\TIVTC\TIVTC.dll")
mpeg2source("D:\test.d2v")
TFM(mode=3)
Decimate()

It seems to work just fine, and does not care about the field order.


What do you think about all this ?

Thx again ;)

PS: I'm using TIVTCv095.

[tritical]

Not really sure off hand, but I do have a couple questions:

First, in this script where the second part is messed up:

Loadplugin("C:\Program Files\AVIsynth 2.5\plugins\mpeg2dec3.dll")
Loadplugin("C:\Program Files\AVIsynth 2.5\plugins\TIVTC\TIVTC.dll")
a = trim(mpeg2source("D:\test.d2v"),0,80192)
b = trim(mpeg2source("D:\test.d2v"),80193,0)
a = TFM(a,order=0)
a = Decimate(a)
b = TFM(b,order=1)
b = Decimate(b)
return a + b

If you set order = 0 in the second TFM call does it also produce bad results on the second part?

Second, if you use this script:

Loadplugin("C:\Program Files\AVIsynth 2.5\plugins\mpeg2dec3.dll")
Loadplugin("C:\Program Files\AVIsynth 2.5\plugins\TIVTC\TIVTC.dll")
mpeg2source("D:\test.d2v")
TFM(d2v="D:\test.d2v")
Decimate()

Does TFM pop up an error about illegal transitions? If so, does the resulting fixed d2v file produce correct output with that script?
Also, the reason setting mode=3 seems to fix things is because, as you said, it really doesn't care about the field order since mode 3 does 3-way matching.

[BangoO]

Originally posted by tritical
If you set order = 0 in the second TFM call does it also produce bad results on the second part?
Yes it does.

Originally posted by tritical

Does TFM pop up an error about illegal transitions? If so, does the resulting fixed d2v file produce correct output with that script?
It does pop up an error about illegal transition, and the fixed d2v works !

This is GREAT !

Just so I know, what does it fix in the d2v so that the field order is now the same all along ?
I'm concerned about this as I don't want to loose some frames even if they look like crap because of the glitch, otherwise the sound will be off synch.

[Dreassica]

Or use dgindex to create d2v, since that fixes fieldorder changes.

[Leak]

Originally posted by tritical
This version should fix all problems with longest string decimation and correctly handle Leak's clip (whichever way it is decoded :D).

Yes, it does... :D

Now, how Bandai managed to b0rk the telecine in this part so there's a cycle of 5 frames with no dup right after the cycle containing the scene change (with the pan going at the same speed per new frame as in the cycles after it) so that it'll pan faster during that cycle when viewing it on a TV is beyond me - now IVTC would have to drop a frame that really isn't a dup or blend the frames down, but what can you do?

It plays smoother with conCycle=1, though, so I'll use that. Also, Last Exile for instance had a few blend transitions where they faded quickly from one pan into another with the telecine patterns not matching up where blending down looked much better (it's a fade after all) than a dropped field in the middle...

np: Autechre - PIOBmx19 (Garbage)

[tritical]

Or use dgindex to create d2v, since that fixes fieldorder changes.
Actually, dgindex can still produce d2vs with illegal transitions... though the only time I've seen them is on vob boundaries. Also, I don't think dgfix, which only supports dgindex's d2vs, would be included with dgindex if it never suffered from this problem?

Just so I know, what does it fix in the d2v so that the field order is now the same all along ?
I'm concerned about this as I don't want to loose some frames even if they look like crap because of the glitch, otherwise the sound will be off synch.
It changes the rff flags in places where two consecutive top or bottom fields are called for (which is what changes the order). It wont cause any syncing problems, a single field may be added (repeated) or eliminated (not repeated) at each of the illegal transition points, but that is it. So no frames will be dropped or anything like that. For more info look here (http://neuron2.net/ipw-web/bulletin/bb/viewtopic.php?t=88&highlight=fixd2v).

[BangoO]

Ok, thx a lot for those explanations, and for those great filters ;)

[acrespo]

I have too many jagged lines with TFM. I already tried all modes but I have the same ammount of jagged lines to all modes.
My source is anime (Inuyasha TV Episodes).

My actual script is:
LoadPlugin("d:\encodes\filtros\removegrain.dll")
LoadPlugin("d:\encodes\filtros\removedirt.dll")
LoadPlugin("d:\encodes\filtros\dup.dll")
LoadPlugin("d:\encodes\filtros\dgdecode.dll")
LoadPlugin("d:\encodes\filtros\mpasource.dll")
LoadPlugin("d:\encodes\filtros\masktools-v1.5.5.dll")
LoadPlugin("d:\encodes\filtros\tivtc.dll")
LoadPlugin("d:\encodes\filtros\degrainmedian.dll")
LoadPlugin("d:\encodes\filtros\mvtools.dll")
LoadPlugin("d:\encodes\filtros\hqdn3d.dll")

import("d:\encodes\filtros\degrainMC.avs")
import("d:\encodes\filtros\LimitedSharpen.avs")
import("d:\encodes\filtros\FastLineDarken_1.3.avs")

video=MPEG2Source("d:\inuyasha117.d2v")
audio=MPASource("d:\inuyasha117.mpa")
AudioDub(video,audio)
Trim(107,10213)++Trim(10369,21066)++Trim(21224,36415)

TFM(mode=1)
TDecimate(mode=1,hybrid=1)

Crop(2,18,-6,-16,align=true)
LimitedSharpen(dest_x=320,dest_y=240)
DeGrainMC()
hqdn3d()
FastLineDarken()
dup(threshold=1,blend=true,maxcopies=8)

[Mug Funky]

could you post a small sample of the m2v where it exhibits this problem?

i've noticed that some telecines are inherently a little jaggy (though not as bad as you get from field-discarding), like Evangelion Platinum (better than the old release, but could be better) and Serial Experiments Lain. so even with correctly matched fields there might still be some jaggyness from a rough telecine.

[Didée]

Originally posted by acrespo

Crop(2,18,-6,-16,align=true)
LimitedSharpen(dest_x=320,dest_y=240)
DeGrainMC()
hqdn3d()
FastLineDarken()
dup(threshold=1,blend=true,maxcopies=8)
Ouch, the pain.

Jagginess might come from applying too much filtering on a *too small resolution*. I'd have a particular suspect on FastLineDarken for that respect.
And instead of calling LimitedSharpen before all those denoisers, you can completely drop it as well and spare its CPU time: everything it has done will be 100% destroyed by the aftercoming filters ...

What about

Crop(2,18,-6,-16,align=true)
DeGrainMC()
hqdn3d()
dup(threshold=1,blend=true,maxcopies=8)
FastLineDarken()
LimitedSharpen(dest_x=320,dest_y=240)

[acrespo]

No, it's not the filters, because I tried Kernelbob+BlendBob and the problem is not occurring.
The jagged problem is really from TFM.

[ObiKenobi]

Try turning off postprocessing and see if that helps.

[acrespo]

Yes!! PP=0 resolve the jagged problem but I need PP because I have too many interlaced parts now. What can I do?

[tritical]

@acrespo
Could you provide some more information, such as if the problem is there are too many false combed frame detections (in which case try setting chroma=false), or if combed frame detections are ok but you just don't like the results from cubic deinterlacing (in which case try using PP = 5 for blending or PP = 7 for ela). Using display=true in tfm could help with determining which is the case. If you could provide a small sample clip that would be even better.

@All
Well there was another problem with hybrid detection, it was from not correctly differentiating between deinterlaced frames and c matches when checking for duplicates via matches in tdecimate. It would cause some cycles that had combed frames that were deinterlaced to not be detected as video when they should have been. Also, I haven't been invoking a cache between TFM and TFMPP when PP>4, which was making things slower when frames needed deinterlacing.

On the non bug related side, I've added handling for the case when 2 dups need to be dropped when there's a change from a panning scene to another panning scene. In the case of vfr (hybrid=2) both dups are dropped and the timecodes are adjusted for that cycle to compensate and in the cfr case either 1.) both dups are dropped and the frame before the scenechange is repeated or 2.) if tdecimate doesn't know exactly where the scenechange is it drops the lowest metric frame and replaces the other with a blend of its two neighbors. If anyone has any other ideas or suggestions for what to do in such a case feel free to post them.

[Leak]

Would you happen to have a link for your latest version? If nothing terrible happens tomorrow, I'm going to dig into it and try to come up with some MMX/SSE/SSE2 code - which probably would be a good idea to do on the latest code... :)

np: Autechre - Dial (Gantz Graf EP)

[DarkNite]

Just wanted to drop in and say that I've been getting great results with TIVTC. TFM is working well and TDecimate is coming along great.

Keep up the good work, and best of luck on future optimizations.

[tritical]

Was gonna post this last time, but there was one lingering problem I didn't get fixed before I had to leave. So here is [link removed, look farther down], pretty much just the changes/fixes mentioned before:

TFM:
- Fixed not invoking a cache between TFM and TFMPP when PP > 4
+ Some internal additions to allow TDecimate to tell the
difference between c matches and deinterlaced frames
+ Added debug output to d2v checking... when debug=true and a
d2v file is specified it will report the type of d2v
detected, the detected field order from the d2v if order = -1,
and report the errors if any are found

TDecimate:
- Fixed not differentiating between c matches and deinterlaced
frames when hybrid > 0 and checking for dups via matches
- Fixed crash with debug=true and large cycles (> 50) due to
too small of a string buffer
- Changed default sceneThresh to 13
- conCycle and conCycleTP now default to 1 when vidDetect = 3
and still default to 2 when vidDetect != 3
+ Added handling for cycles around scene changes which need 2
dups removed
+ Some other internal changes

@DarkNite
Thanks for the comments, glad to see someone got some use out of it, and hopefully Leak will work some mmx/isse magic to improve the speed a little.

[tritical]

Minor bug fix release [link removed], changes:


TDecimate:
- Fixed a problem with timecode file generation that would occur
in mode 5 with tcfv1 = true. If the cycle following a cycle
that needed 2 dups removed was detected as video then an
erroneous line would be written to the file.
- Fixed not initializing mkvOutF file handle

TFM:
- Fixed passing AsClip() a NULL argument during TFM and TFMPP
object creation if no clip was given for clip2. This would
cause assertion failure when compiled in debug mode.

Thanks go to Leak for spotting most of those.

[BangoO]

Originally posted by tritical
It changes the rff flags in places where two consecutive top or bottom fields are called for (which is what changes the order). It wont cause any syncing problems, a single field may be added (repeated) or eliminated (not repeated) at each of the illegal transition points, but that is it. So no frames will be dropped or anything like that. For more info look here (http://neuron2.net/ipw-web/bulletin/bb/viewtopic.php?t=88&highlight=fixd2v).
Well, on the file I tested, it adds some fields, and then when I use TFM()/Decimate(), there are some places where I have repeated frames that don't have if I don't fix the D2V.
Therefore, the audio gets out of synch :(

I tried with DGIndex, DGFix and DGDecode, and I don't have the repeated frames anymore, but I still have to check the whole thing for possible out of synch audio.

In the file I tested, there are 2 field order changes, but TFM(d2v=...) fixes a lot more than that.
Maybe that's the cause, I don't know...

[BangoO]

I did some more tests...
If I correct the D2V created by DVD2AVI and correct it just where there is the FO change, the audio stays in synch all along.
In this case, it was a 0 1 0 sequence, replaced by a 0 0 0 sequence.

I assume TFM fixes the following sequences:
0 3
1 0
1 1
2 0
2 1
3 2
3 3

The question is... which ones can produce an FO change (I know from my example that "1 0" can) ?

Thx ;)

[tritical]

And here comes another release... [link removed], the changes:
TDecimate:
- Fixed incorrect setcachehints call due to checking the value of
the wrong argument
+ Faster and more accurate mmx/sse2 blending routines, thanks to
Leak
+ Optimized the metric calculation routines a little. Exactly
how much of a speed increase is dependent on the source
being processed.
+ Some other optimizations and internal changes.

TFM:
- Changed the d2v method of fixing illegal transitions to one
that doesn't alter the total # of fields in the clip.
- Changed default value for the chroma option to false
+ Some other optimizations and internal changes.
The new d2v fixing method is in response to BangoO's questions... a thread on the subject can be found here: http://forum.doom9.org/showthread.php?threadid=87267. While this version doesn't have any major optimizations, it does give a noticeable speed increase (mainly from TDecimate). How much is dependent on the source, but I can say that it dropped the one pass time on an episode of Last Exile from 20 minutes to 15 minutes 30 seconds on my comp.

[BangoO]

Great !
Thx tritical ;)

I just tested, TDecimate() is still very slow compared to Decimate() on HD material.

[tritical]

And another release... [line removed]. Finally got the last thing on the todo list taken care of, a chroma option for tdecimate. Changes:

TDecimate:
- Fixed mode 4 display output saying "mode 3" instead of "mode 4"
+ Added chroma parameter
+ mode 4 display and debug output now display the sceneChange
metrics along with the block difference metrics
The chroma option can disable consideration of chroma planes when caculating metrics (similar to quality=2 in decimate, which is its default), which can give a speed up (not huge, but noticeable). The metrics will tend to be slightly higher for chroma=false then chroma=true, so I adjusted the defaults for dupThresh, vidThresh, and sceneThresh. They still default to 1.1, 1.1, and 13 when chroma=true, but if chroma=false they default to 1.4, 1.4, and 15. Getting close to a 1.0 version.

EDIT: whoops.. I lied, there was one more thing to add. An improvement to longest string decimation that should improve its operation/accuracy quite a bit... so thats v0.9.7.1.

[Mug Funky]

you is da man, tritical.

[BangoO]

Originally posted by tritical
The chroma option can disable consideration of chroma planes when caculating metrics (similar to quality=2 in decimate, which is its default), which can give a speed up (not huge, but noticeable)
TDecimate(chroma=false) seems to be as fast as Decimate().
So... which one is the best ? :D

[scharfis_brain]

I tried to replace smartdecimte with tdecimate in restore24.

without success.
tdecimate causes steady jerkyness, due to its fixed threshold.

I used mode=2,rate=23.976 with 50fps input.

would it be possible for you, trictical, to make mode2 working with an adaptive threshold?
the pattern of the 23.976 video in the 50fps video is irregular, max. number of dupes is 3 and minimum is one.

smartdecimate is able to do this without any jerk, but it needs reinterlaced contents for its analysis.


I intend to replace this:


video=last
analyse=last.separatefields().selectevery(4,0,3).weave()
analyse.smartdecimate(6250,2997,bob=video,weave=video)


with this:


tdecimate(mode=2,rate=23.976)

[tritical]

@BangoO
If your just using TDecimate(chroma=false) vs decimate() there honestly is hardly any difference. The only thing will be in the metric calculations with tdecimate's overlapping blocks vs decimate's non-overlapping blocks, and I doubt this would cause any noticeable difference when doing most similar decimation. I would probably just stick with decimate since it will be faster.

@Mug Funky
Thanks :p.

@scharfis_brain
Yep, mode 2 sucks quite a bit as it is now. I haven't touched it since the very first version of tdecimate. Like you pointed out, it is far too dependent on one threshold. An adaptive threshold would help... I can think of a few other changes that would help it quite a bit as well. Would it be possible for you to send me part of that clip to test on?