Decimate Gurus I need your help

[Zep]

i have an interesting 59.94 progressive HDTV stream


the problem is there is no static pattern for dupe frames.
Normally i would use selecteven() or selectodd() to get down
to 29.97 then a Decimate(5) to get to 23.976 and all would be
good to go. But this stream is wacko. There is a single
frame randomly placed in it every 10 to 40 frames with NO dupe
frame. Now what is more wacko still is this single frame does
not happen the whole way through. minutes can go by with no
single non duped frame then all of the sudden they start up
again.

if i use selecteven() or selectodd() then 50% of these are cut
and i get a jump which of course looks bad.

if i use decimate (2) then the 2 frames will NEVER be dupes
since the one is always the only one so 50% of the time it
gets deleted there too since it is randomly placed.

the basic pattern normally is AAABBCCCDD the whole way but
this stream is

AAABCC or AAABCCC or AABCCC (it randomly changes as it goes)



suggestions?

[scharfis_brain]

please count the unique frames of 240 HDTV-Frames.
are there 100 unique Frames or only 96 Frames?

if there are 96 frames, the video contains 24p else if there are 100 frames it contains 25p.

I recommend using smartdecimte in this case:

for 24p :

x=last
x.separatefields()selectevery(4,0,3).weave()
smartdecimate(24,60,bob=x,weave=x)

for 25p :

x=last
x.separatefields()selectevery(4,0,3).weave()
smartdecimate(1250,2997,bob=x,weave=x)


does this thread refect your problem?
http://neuron2.net/ipw-web/bulletin/bb/viewtopic.php?p=3508#3508t=429&highlight=weird+pattern

[Zep]

Originally posted by scharfis_brain
please count the unique frames of 240 HDTV-Frames.
are there 100 unique Frames or only 96 Frames?

if there are 96 frames, the video contains 24p else if there are 100 frames it contains 25p.

I recommend using smartdecimte in this case:

for 24p :

x=last
x.separatefields()selectevery(4,0,3).weave()
smartdecimate(24,60,bob=x,weave=x)


does this thread refect your problem?
http://neuron2.net/ipw-web/bulletin/bb/viewtopic.php?p=3508#3508t=429&highlight=weird+pattern


it is 1280 x 720p at 59.94 FPS so it is a matter
of just pattern matching. to knock it down to 24(23.976)

yes that thread has some linkage :) What i have here
is more random though. The single non dupes frames
can be anywhere and there is no repeat pattern in
some areas of the clip. I have a feeling they just
appended scenes and didn't do a full compress on the whole
thing. it is like you get one pattern on the close up
of a face. Then cut to another scene and it all changes.

multidecimate did a good job and it kept the stills
i wanted. 60+ frames worth for each still photo
from a photo album on screen etc... so those can't
be fully cut out.


i will have to try smartdecimate next


thanks

[Guest]

I've discovered a great new arbitrary decimation algorithm. It has the following features:

* one-pass operation
* specify any decimated framerate
* one frame comparison per output frame (!)
* preferentially decimates duplicates over singletons
* maintains audio sync throughout

This should be a good fast solution to Zep's problem and I expect it will make Decimate() obsolete. I've already begun coding.

[JuanC]

Originally posted by neuron2
... and I expect it will make Decimate() obsolete. I've already begun coding. Out of curiosity: Would it be able to blend duplicated frames (or fields after beeing separated) and output the blended frames (or fields) instead of discarding them?

That would help me clean-up my hybrid analog TV captures and maintain the framerate.

[Zep]

Originally posted by neuron2
I've discovered a great new arbitrary decimation algorithm. It has the following features:

* one-pass operation
* specify any decimated framerate
* one frame comparison per output frame (!)
* preferentially decimates duplicates over singletons
* maintains audio sync throughout

This should be a good fast solution to Zep's problem and I expect it will make Decimate() obsolete. I've already begun coding.

YEAH!!!!!

I need this BIG time cause I now have tried multidecimate
(which does fine but audio sync is hosed to a point I can't
fix unless i spend hours sliding around audio chunks)

smartdecimate same problem as normal decimate, i.e. the
rapid pattern changes confuse it and it too drops singletons
as well as AA pairs. (which shocks me that it would drop
2 good frames and cause a jump in motion. however the read me
did say if you do not have pattern it would fail so...)


This truly is a case where I can't help the function
by walking it and getting a pattern because there is none.
We truly have to have a super smart decimat to the point
where Decimate(23.976) is all that is needed.


DG I am very impressed you can pull that off with 1 pass.
i was almost certain it would take 2 passes.

this is great news!


Thanks :)

[manono]

Zep-

It sounds to me like you were using MultiDecimate in Global Mode. If you use Cycle Based, the audio should stay in synch.

And I agree that having Decimate(WhateverFPS), if that's what neuron2 has in mind, is very good news.

[scharfis_brain]

oh, sounds very good!

It would be really cool, If it could handle weird decimation ratios like 2997/6250 and pattern like those:

ABBBCDDDEFFGGHH ....
13131222
or

ABBBBCDEEEEFGHHHIIJJKKLL
14114113222


Dideé and me are pulling out our hairs on getting smartdecimte running in large scripts like restore24...
smartdecimate is like a small child:
one day everything works fine,
the other day nothing works, only crashes and weird behaviours...

[Guest]

I have the filter done and now I want to write documentation and do a journal entry. Maybe by tonight I will release it. Don't expect perfection, because it cannot be achieved, as I will explain. But this will be a useful step forward. At least it won't crash or act weirdly.

[Zep]

Originally posted by neuron2
I have the filter done and now I want to write documentation and do a journal entry. Maybe by tonight I will release it. Don't expect perfection, because it cannot be achieved, as I will explain. But this will be a useful step forward. At least it won't crash or act weirdly.

Cool! I have 2 streams waiting for that filter so i can encode them :D


A dupe frame staying in here and there is ok but a singleton
being cut is BAD news because that is very noticeable. As long
as no singletons are cut i think it will good to go.

[Zep]

Originally posted by manono
Zep-

It sounds to me like you were using MultiDecimate in Global Mode. If you use Cycle Based, the audio should stay in synch.

And I agree that having Decimate(WhateverFPS), if that's what neuron2 has in mind, is very good news.

Cycle Based wasn't even close to decimating correctly.
(of course I may have found better parms if I spent more
time but I moved on to Global: Protect static scenes)

Remove duplicates: Global: Protect static scenes worked
well (it did leave a few dupes but only very few) but didn't
cut any singletons and that was the main goal. (the secondary
was leave the static scenes alone. photos and NO motion for
60+ frames so 60+ dupes in a row etc...)

[Guest]

I've made the first release of my new free decimator, FDecimate().

Please be sure to read the help file carefully to understand why free decimation cannot be perfect if you want to keep the audio and video in sync.

http://neuron2.net/fdecimate/fdecimate.html

[Zep]

Originally posted by neuron2
I've made the first release of my new free decimator, FDecimate().

Please be sure to read the help file carefully to understand why free decimation cannot be perfect if you want to keep the audio and video in sync.

http://neuron2.net/fdecimate/fdecimate.html

awesome gonna test it now :D

[len0x]

Originally posted by neuron2
I've made the first release of my new free decimator, FDecimate().


Very cool!
Question: is metrics parameter enables debug info or I have to enable it explicitely ?

[Guest]

Originally posted by len0x
Question: is metrics parameter enables debug info or I have to enable it explicitly? Yes, metrics=true forces show=true and debug=true.

[len0x]

Please note that, while FDecimate() can be used for traditional 1-in-N decimation, it is probably preferable to stay with Decimate() for those applications, because it does not require the setting of a threshold for duplicate detection when used in mode=0.


Does this mean that when using telecide for normal IVTC before decimate its better to use old decimate? And what about mode 1 and 3 for hybrid sources - old one as well?

[Leak]

Originally posted by len0x
Does this mean that when using telecide for normal IVTC before decimate its better to use old decimate? And what about mode 1 and 3 for hybrid sources - old one as well?

Hmmm... Don mentions using FDecimate to bring 120FPS files containing both 24FPS and 30FPS segments down to a different frame rate - but if you're going for 30FPS you'll get studdering on the 24FPS parts due to missing frames and if you're going for 24FPS you'll get the same for the 30FPS parts (like telecine, but probably worse since it's a duplicated frame instead of 2 duplicated fields).

Still, if you're going for 24FPS, couldn't FDecimate detect there's not enough duplicates to throw out and do a blend decimation from 30 to 24 (or maybe directly from 120 to 24) a la mode 3 to get down to 24?

np: Giardini Di Mirò - Dancemania (Hits For Broken Hearts And Asses)

[manono]

Hi-

...but if you're going for 30FPS you'll get studdering on the 24FPS parts due to missing frames...

You may or may not get noticeable stuttering during the 24fps parts, but if you do, it surely won't be because of missing frames, but because of the extra duplicate frames.

[Guest]

Originally posted by len0x
Does this mean that when using telecide for normal IVTC before decimate its better to use old decimate? Yes, unless you are using mode=2 (which tries to handle multiple duplicates sanely), in which case FDecimate() may be more reliable.

And what about mode 1 and 3 for hybrid sources - old one as well? FDecimate() currently has no equivalents to these, so yes.

I was a little over-excited when I said it would obsolete Decimate(). :cool:

[Guest]

Originally posted by Leak
Still, if you're going for 24FPS, couldn't FDecimate detect there's not enough duplicates to throw out and do a blend decimation from 30 to 24 (or maybe directly from 120 to 24) a la mode 3 to get down to 24? It's conceivable. I made FDecimate() quickly to investigate some issues with a few streams and thought I might as well release it as it helps in some circumstances. For example, manono had given me a silent clip The Cook and I was able to render it very well with one pass using FDecimate(), whereas before it required 2 passes using MultiDecimate and some complicated guesswork to get the cycles set right. Maybe I'll add some extra functionality to it, who knows? :p

[Leak]

Originally posted by manono
You may or may not get noticeable stuttering during the 24fps parts, but if you do, it surely won't be because of missing frames, but because of the extra duplicate frames.

Ehm... I was thinking of dups as also being a missing frame, since the dup is where a different frame should've been.

Of course, better wording might have been a good idea... ;)

np: Underworld - Pearl's Girl (Underworld 1992-2002)

[Leak]

Originally posted by neuron2
Maybe I'll add some extra functionality to it, who knows? :p

Well - you, perhaps? *ducks* :D

np: Underworld - Pearl's Girl (Underworld 1992-2002)

[Guest]

I thought of an idea that may help us out of our dilemma.

The basic problem is that after decimation we are missing some unique frames from the input. We can't put them back without messing up audio. Or can we? What if we put them back as blends:

before:

A A A B B C D D D E E

normally C could disappear, but if so we render:

A B+C C+D E F

I believe this may be a solution for decimating these clips while retaining smoothness and audio sync. I'll perform some experiments and report back.

[len0x]

Originally posted by neuron2

I believe this may be a solution for decimating these clips while retaining smoothness and audio sync. I'll perform some experiments and report back.

Thats exactly what I was thinking :)

[Guest]

Originally posted by len0x
Thats exactly what I was thinking :) Hey, don't be shy! Speak up when you have thoughts. :)

[scharfis_brain]

erhmmmmm..

dropping or blending an orphan frame? why this?

wouldn't it be much cleverer, delaying the video by, lets say up to 3 frames, until frames get dropped or blended? maybe sometime later in the video we have the chance getting some more duped frames that are compensating orphaned frames.

or maybe accept a slight AV async, until a scenechange occurs
(dropping frames directly before/after scenechanges is not noticeable, while dropping frames within a scene IS noticeable)

[Guest]

In practice, it doesn't happen that way. And the av sync mismatch is not slight. But hey, go ahead and implement it for a test of concept if you really think it is viable.

The only thing that really would be cleverer in my view would be to insert blank audio whenever required to retain orphans. I don't know how random 33ms audio silences would sound and in any case I'm not motivated enough by the problem to go down that route. But adding the blend mode to FDecimate() is not too difficult.

[Zep]

Originally posted by neuron2
In practice, it doesn't happen that way. And the av sync mismatch is not slight. But hey, go ahead and implement it for a test of concept if you really think it is viable.

The only thing that really would be cleverer in my view would be to insert blank audio whenever required to retain orphans. I don't know how random 33ms audio silences would sound and in any case I'm not motivated enough by the problem to go down that route. But adding the blend mode to FDecimate() is not too difficult.

grab either side of the 33ms gap and PULL the audio range
to center via an audio stretch with pitch save.

zep ducks... :D

[len0x]

Originally posted by neuron2
I don't know how random 33ms audio silences would sound


I can imagine it will sound awful...

[scharfis_brain]

for sure, I cannot implement this mzself, I just had some thoughts...

so, why is it not possible to accept a slight A/V async to achieve that only frames on scene changes (and not within a scene) are getting dropped? Most of the FIlms have very much cuts, so it should be okay...

I do not mean the 24 / 30 hybrid problem here. I think about weird patterns....

[Didée]

I would prefer to post some praises about fdecimate... but alas, I found a strange thing about it, that hinders me in evaluating it for a specific case:

It seems that fdecimate is not playing nicely together with scripts that use AviSynth's conditional environment.

When I exchange SmartDecimate (within Restore24) with fdecimate, then the script goes totally goofy.
I discovered the following: when calling fdecimate(metrics=true), then

- the clip is still decimated to 23,976 fps (the docs say it won't decimate at all when metrics=true)

- much more serious: some variables in Restore24 will "freeze".

Restore24 uses a good amount of global variables. And at least one of them, initialized with a value of 1.0, will freeze at 0.999..., instead of getting updated on every frame. Probably even more variables are affected, I can't tell for now.

The script's flow is basically quite simple:

[clip /w blended fields] -> [bob] -> [conditional filtering] -> [clip /w dups] -> [decimation]

Obviously, decimation is the very last step.

Without fdecimate as decimator, everything is fine. When calling fdecimate(metric=true), the mentioned freeze of one or more global variables will occur, so that the blend replacement doesn't work any more at all.
Lastly, when simply calling fdecimate(), then the freeze of variables seems to NOT occur. But still, the decimation goes glorily wrong, then.


Donald, I know this is a pretty muddy bug report :| But I have no clue what really is going on here. Only thing I know - something IS going on.

Perhaps you have an idea where to look for the cause. I'll be happy to provide more information, if you tell me which.


Regards

Didée

[Guest]

@Didee

That's really strange, especially the claim that it still decimates with metrics=true!

What happens if you save the output of the clip minus the final FDecimate() as an AVI and then apply FDecimate() to that. Is it the same?

Anyway, please PM me with the script and some instructions for recreating the issue and I'll look at it.

@scharfis_brain

I'm not saying your idea is without merit, but with the two clips I have there are lengthy scenes that drift terribly out of sync. So I don't think it is reliable enough to handle all instances but it may allow one to avoid some blends. But it would be a very difficult thing to implement and may well require two pass operation.

[Didée]

intermediate report:

When first saving the de-blended 50fps clip to HD, and then feeding that to fdecimate, then the decimation is handled correctly. (Phew ;) )

But even when doing it this way, setting metrics=true gives me a strange output. fdecimate then delivers a clip with 23.976fps, and 'correctly' reduced framecount.
But the actual series of frames is : new-dup-new-dup-new-dup-dup-new...

:confused:

I'll provide you tomorrow with test material.


- Didée

[Guest]

I know what's going on. I'll fix that in the next release, which will also add the singleton blend mode.

I forgot to make the fps and frame count settings conditional on the metrics setting. :scared:

I'd like to get the test materials anyway, to address the other problem you reported.

[Guest]

Status report: Found some bugs that could explain the problems. Fixed them. YUY2 was causing memory overwrites.

I've completed the code that detects when a skip occurs and it is working well. Now I just need to add the frame blend code stolen from Decomb and then we'll know whether it was all worthwhile or not. :)

I'll do that tomorrow.

BTW, my skip detection code shows that I accumulate as many as 10-15 skips before a scene change in many cases. That would be a large desync and then I'd have to lop off 10-15 frames at the scene change. So it's a good idea in theory but not in practice.

[Zep]

Originally posted by neuron2
Now I just need to add the frame blend code stolen from Decomb and then we'll know whether it was all worthwhile or not. :)


hehe


[
I'll do that tomorrow.

BTW, my skip detection code shows that I accumulate as many as 10-15 skips before a scene change in many cases. That would be a large desync and then I'd have to lop off 10-15 frames at the scene change. So it's a good idea in theory but not in practice. [/B]

woah that many. Did you get a 15 from that clip where thay are walking
down the hall way for like 1 minute without a scene change?(just curious)

[Guest]

Originally posted by Zep
woah that many. Did you get a 15 from that clip where thay are walking down the hall way for like 1 minute without a scene change?(just curious) There are 23 skips in that scene! Most of them are minor but a few are really obvious.

[Zep]

Originally posted by neuron2
There are 23 skips in that scene! Most of them are minor but a few are really obvious.

i kinda figured there was a lot because that was the scene
i love to test on because lots of movement (the pillars)
makes for easy spotting of singletons and i saw plenty of them.
(I never counted how many though)

yes it is the singleton cuts that are really obvious in
that scene.

[Guest]

I've completed my experiments with the blend idea. They are very disappointing. The skips are just as obvious if slightly attenuated. The improvement is nowhere near enough to justify itself.

So I just went ahead and fixed the existing version, resulting in version 1.0.1:

http://neuron2.net/fdecimate/fdecimate101.zip

For those wondering how FDecimate() differs from ChangeFPS(), it can preferentially deliver unique frames, avoiding duplicates where possible.

I don't see a fully acceptable solution to Zep's problem short of a coordinated adjustment of the audio.

@didee

I tried to run your restore24 scripts but I got an error that the script wasn't returning a video clip and I didn't have time to to track that down. Also, there was a syntax error on a levels call, so apparently this script had never run. Anyway, please try the fixed version and report back. Thank you.

[Zep]

Originally posted by neuron2

I don't see a fully acceptable solution to Zep's problem short of a coordinated adjustment of the audio.


darn. now what? more and more streams are like those.
Do you even want to try to adjust audio or is that too much
of a pain to get into?

i wish i had to a way to do the whole clip like i did in my tests
without doing it manually just to see how good it comes out on a
full encode.

Are there any free compilers that can do avisynth filter dev with?
I have some ideas but i can't ask you to keep messing with this.
It is time i get my hands dirty and i always wanted to get into
filter tests so now is a good as time as any :)

[Zep]

Originally posted by scharfis_brain
for sure, I cannot implement this mzself, I just had some thoughts...

so, why is it not possible to accept a slight A/V async to achieve that only frames on scene changes (and not within a scene) are getting dropped? Most of the FIlms have very much cuts, so it should be okay...

I do not mean the 24 / 30 hybrid problem here. I think about weird patterns....

you gonna download that clip off my server or what? LOL
been sitting there for 3 days :D


read your PMs!!!

[Guest]

Originally posted by Zep
darn. now what? more and more streams are like those.
Do you even want to try to adjust audio or is that too much
of a pain to get into? I personally don't have the time to tackle this large project. I would fdecimate() it at 29.97 and live with it.

i wish i had to a way to do the whole clip like i did in by tests with out doing it manually just to see how good it comes out on a full encode. It is very easy to write down simple sequences that defeat your idea. That is why I haven't taken it very seriously. (Readers: This was discussed only in a PM exchange with Zep.)

Are there any free compilers that can do avisynth filter dev with? I have some ideas but i can't ask you to keep messing with this. It is time i get my hands dirty and i always wanted to get into filters tests so now is a good as time as any http://forum.doom9.org/showthread.php?s=&threadid=74608&highlight=free+Microsoft+compiler

Good luck! Unless it involves coordinated audio adjustment I believe you are destined for terminal frustration. But I'll keep an open mind.

I'm going back to DGMPGDec development. :)

[Didée]

Originally posted by neuron2
I tried to run your restore24 scripts but I got an error that the script wasn't returning a video clip and I didn't have time to to track that down. Also, there was a syntax error on a levels call, so apparently this script had never run. Anyway, please try the fixed version and report back. Thank you.
Sorry Donald, but ... no.

A syntax error on a levels call ... c'mon, do you think I would provide you with such a sucking script? ;)

I just cross-checked on a clean setup, and the package does run out of the box there. And so it does on my two other machines on which I checked it also. So it must be an error on your side. I suspect either a conflict with some auto-loaded plugins, or with avisynth_c.dll.

The better news is: with the new version of fdecimate, the issue seems to be gone. :)

Playtime after soccer EM will have finished for today ...


- Didée

[scharfis_brain]

@zep:

I examined some hundreds of frames of the begining of that file.

the pattern of that movie at the beginning:

...23232323 -> first frames until the 1st singleton shos up
*******
132323232323232 -> 15 frames in 36
2232323232323232 -> 16 frames in 39
2232323232323232 -> 16 frames in 39
2232323232323232 -> 16 frames in 39
2232323232323232 -> 16 frames in 39
223232323232323 -> 15 frames in 35
*******
1323.... -> frames after the 2nd singleton

okay, that sums up to 2x15 and 4x16 frames (=94 frames)
between two singletons (including one singleton)
that had been telecined into 36 + 4x39 + 35 = 227 frames

this results into a final framerate of:

94 frames * 59.84fps / 227 frames = 24.821 fps

and now please re-read my post(s) above.

I strongly suggested counting frames, didn't I?

I think, that this weird pattern occured due to a
speedup of this movie.
A lot of broadcastes do this to be able to show more ads.

I can see this kind of movie destruction in germany, too...

This means, fdecimate(fps=24.821) *SHOULD* (not tested, coz it crashes on my K6-2)
result in a skip & blendfree 24.821 fps stream...

as I everytime say: "count your frames!"

btw. smartdecimate seems to suffer skips and dupes even if set to the correct decimation ratio at the beginning, after some cycles had been passed, smartdecimate seems to catch the pattern....
(not intensively tested, coz complete clip isn't DLed yet here, but you can remove that file from your space)

[Zep]

Originally posted by scharfis_brain


I strongly suggested counting frames, didn't I?


yes and my reply is still the same.

For me walking the episode to make sure is NEVER gonna happen.
In fact this is exactly the kind of stuff i WANT my computer
to do so i do not have to :D

Can you imagine if every TV show changed the pattern each week
just like the show sent you. OUCH!!! That show I sent you
changed the pattern 2 times in 3 weeks.

of course now this means maybe we can talk DG into writing
a pattern finder/counter filter LOL




I think, that this weird pattern occured due to a
speedup of this movie.
A lot of broadcastes do this to be able to show more ads.

I can see this kind of movie destruction in germany, too...

This means, fdecimate(fps=24.821) *SHOULD* (not tested, coz it crashes on my K6-2)
result in a skip & blendfree 24.821 fps stream...

as I everytime say: "count your frames!"


i will give it go but what if the patterns change in the next 19
minutes of the episode? Or the pattern breaks at an edit point?
(which it does and which that clip I sent you never reached an
edit point)




btw. smartdecimate seems to suffer skips and dupes even if set to the correct decimation ratio at the beginning, after some cycles had been passed, smartdecimate seems to catch the pattern....
(not intensively tested, coz complete clip isn't DLed yet here, but you can remove that file from your space)


can you show me the script you use for smartdecimat please.
(the parms I tried didn't work so well on signletons the rest
though was good)

I'm leaving the clip up for now since a number of people saw
my post to you about the clip and asked for it too in PMs. :)

thanks

[Zep]

Originally posted by neuron2
I personally don't have the time to tackle this large project. I would fdecimate() it at 29.97 and live with it.


ok i thought as much



It is very easy to write down simple sequences that defeat your idea. That is why I haven't taken it very seriously. (Readers: This was discussed only in a PM exchange with Zep.)


I never said it couldn't be defeated . In fact i said it WOULD
be defeated on some patterns and even listed one of those
patterns for you BUT my MAIN point was

It works on the ABC broadcast streams and that is all i need :D
(athough the ABC pattern is chaotic it is consistently chaotic LOL)

For other patterns from other broadcasters you would have to
find then insert/replace ***OTHER*** patterns just for them :)



http://forum.doom9.org/showthread.php?s=&threadid=74608&highlight=free+Microsoft+compiler

Good luck! Unless it involves coordinated audio adjustment I believe you are destined for terminal frustration. But I'll keep an open mind.


Thanks for link!

yeah most likely gonna be a head hitting wall thing but
at least I get to learn to code filters on the way. LOL

I also feel, as you know from my PMs, the audio would need
to adjusted. Lets hope someone figures out a way to do this
whithout having to mess with audio.

you know in if a mov wrapper you can have each frame stay
on screen a different amount. If avu could do that this would
be so easy to fix. To leave audio alone the tell the singleton
to stay on screen for 12ms and the tripleton to to 1 frame
on Decimate to get off the screen 12ms sooner.


I'm going back to DGMPGDec development. :)


HAHA well that is where I think everyone wants you anyway :D

[Zep]

Originally posted by scharfis_brain
@zep:



This means, fdecimate(fps=24.821) *SHOULD* (not tested, coz it crashes on my K6-2)
result in a skip & blendfree 24.821 fps stream...



no go. mixed results. Singletons are cut and many dupes remain
so of course jerky playback. :(

i tried .5 ,1,2 and 5 on threhold and interestingly enough 5
was the best which I think means some low metric frames (0 to 5)
are cut which left some room for more signeltons to stay in since
they are mostly greater than metric 5 and if one is lower than 5
the change is not so HUGE, so the jerkiness is not so noticable.

DG would have to explain this as I'm only guessing based on the 1 clip


So what is your smartdecimate script? :D

[scharfis_brain]

the script used:

loadplugin("c:\x\avisynth_c.dll")
loadCplugin("C:\x\smartdecimate.dll")

a=avisource("aclip.59.94.FPS.avi")
a.separatefields()
selectevery(4,0,3)
weave()
smartdecimate(1241,2997,bob=a,weave=a)

smartdecimate has additional fieldmatching paramters, that may improve the decimation, please read its doc for further information.

it was 4:00 in the morning I tested this before going to bed, so don't rely on the things I said about smartdecimate in the post above :)
(I only had about 1000 frames to test on)

btw. does the pattern I posted change or is that pattern constant all over the episode?
I assume, that it already jerks like hell on TV, especially on those points: 231323

[Guest]

Originally posted by Didée
Sorry Donald, but ... no.

A syntax error on a levels call ... c'mon, do you think I would provide you with such a sucking script? ;)
There is no boolean as the last parameter for Levels on the version of Avisynth I have installed.

[Didée]

Originally posted by neuron2
There is no boolean as the last parameter for Levels on the version of Avisynth I have installed.
Oh. Now that you mention it: yes, once upon a time, Avisynth didn't have the coring parameter for levels(). :)

- Didée