CTools

[real.finder]

Originally Posted by Ceppo

AvspMod does it wrong, for some reason it calls 3 times the first frame. I use x264 preset very fast. You can still use AvspMod if you edit the file, just delete the duplicates at the beginning since it says 3 times frame 0. You might also want to look at the last frame in the txt file.

Thanks for the sample.

yes with x264 it only one "0 0"

but "cycle at frame ..." errors still there!

[Ceppo]

I updated the ReadMe and fixed the CDecimate2 bug in the v1.0.3 you can find above. Now it should work correctly.

yes with x264 it only one "0 0"

but "cycle at frame ..." errors still there!

The point of CDecimate is to get the correct decimate. There is no metric to do it right. The only way is to get a 00000, 11000, 01100, 00110, 00011, 10001 pattern every 5 frames. If in the txt file is not so, it will give you an error. I'm working on a way to reduce and minimalize the amount of required editing in the txt file. If you have a live action you often get the right pattern since everything is moving (so you have to edit only the critical parts). On anime, due the duplicates, this doesn't happen so there is a lot of editing to do.

[real.finder]

The point of CDecimate is to get the correct decimate. There is no metric to do it right. The only way is to get a 00000, 11000, 01100, 00110, 00011, 10001 pattern every 5 frames. If in the txt file is not so, it will give you an error.

If you have a live action you often get the right pattern since everything is moving (so you have to edit only the critical parts). On anime, due the duplicates, this doesn't happen so there is a lot of editing to do.

so if someone work with anime he/she will need so much time edit the file!

isn't better to add an option to just ignore these cases for peoples that dont have time and patient to edit thousands of lines?

also gispos said this about avspmod problem

In my opinion, the error is due to a non-existent option of the plugins. "After initializing, don't write the same frame multiple times"
It would be easy to integrate this option into the plugins!

Programs that display frames or need to initialize other variables when creating the clip must call get_frame multiple times at the beginning.
For example, if the matrix is read, get_frame must be called first. And with each call the plugin writes the frame number.

and I agree with him, since tivtc and others don't have this problem

[Ceppo]

so if someone work with anime he/she will need so much time edit the file!

isn't better to add an option to just ignore these cases for peoples that dont have time and patient to edit thousands of lines?

also gispos said this about avspmod problem

I understand your concern and you are right. I'm working on it to reduce to the minimum the editing by increasing accuracy. I will also make the option to ignore the error and try some heuristic way to handle those cases.

In my opinion, the error is due to a non-existent option of the plugins. "After initializing, don't write the same frame multiple times"
It would be easy to integrate this option into the plugins!

Programs that display frames or need to initialize other variables when creating the clip must call get_frame multiple times at the beginning.
For example, if the matrix is read, get_frame must be called first. And with each call the plugin writes the frame number.

Thanks a lot for the feedback, I will follow the advice!

EDIT
Also, now I'm working on a new field matching mode, and I'm getting good results.
EDIT 2
I need only to implement the write only thing and write the ReadMe file for the new functions.
Here a preview: 60i VFR
WIth this Script:

CTelecineNew(bob=true,inputTxt=true)
CPostProcessing(isbob=true)
CDecimateNew(isBob=true,error=false)

The release will be in the day.

[Ceppo]

Updated to v1.0.4, feedback is much appreciated.

EDIT
fix'd

[real.finder]

thanks
with this

#~ CTelecineNew(bob=true,write=true) #1st pass
CTelecineNew(bob=true,inputTxt=true)
CPostProcessing(isbob=true,edeint2=qtgmc)
CDecimateNew(isBob=true,error=false)

I got this

[Ceppo]

Sorry, I was in a hurry and I didn't update CTools.avsi.

https://www.mediafire.com/file/tqrbk...%2529.zip/file

[real.finder]

Originally Posted by Ceppo

Sorry, I was in a hurry and I didn't update CTools.avsi.

https://www.mediafire.com/file/tqrbk...%2529.zip/file

it work now but with https://xfl.jp/E5n90r I got same frame in all clip with this

#~ CTelecineNew(bob=true,write=true) #1st pass
CTelecineNew(bob=true,inputTxt=true)
CPostProcessing(isbob=true,edeint2=qtgmc)
CDecimateNew(isBob=true,error=false)

[Ceppo]

Test

CTelecineNew(bob=true,inputTxt=true)
CPostProcessing(isbob=true)#QTGMC() is the default
CDecimateNew(isBob=true,error=false)

Aside missing the fade. It looks everything all right to me.
I can't recreate the problem

EDIT:
Maybe your CTelecine file is empty??? After the pass you have to close AVSPmod since I didn't yet included a close() function.

[real.finder]

Originally Posted by Ceppo

Test

CTelecineNew(bob=true,inputTxt=true)
CPostProcessing(isbob=true)#QTGMC() is the default
CDecimateNew(isBob=true,error=false)

Aside missing the fade. It looks everything all right to me.
I can't recreate the problem

EDIT:
Maybe your CTelecine file is empty??? After the pass you have to close AVSPmod since I didn't yet included a close() function.

it's not empty, do I need 3 passes in this case?

[Ceppo]

it's not empty, do I need 3 passes in this case?

No. There must some kind of other bug.
You are using 64bit or 32bit version? Just to track the problem.

[real.finder]

Originally Posted by Ceppo

No. There must some kind of other bug.
You are using 64bit or 32bit version? Just to track the problem.

64bit

[Ceppo]

Do you have some people online to make them try on that source? I need to understand if it's a stack related problem.

[real.finder]

Originally Posted by Ceppo

Do you have some people online to make them try on that source? I need to understand if it's a stack related problem.

I didn't get what you mean but I note in every experience some frames show randomly, like in avspmod if I hit f5 in some frame it will change to another

removing CDecimateNew(isBob=true,error=false) line will fix it but this not what we want

[Ceppo]

Ok, just curios remove inputTxt=true from CTelecine and try again. Also if you could please tell me how much RAM you have.

[real.finder]

Originally Posted by Ceppo

Ok, just curios remove inputTxt=true from CTelecine and try again. Also if you could please tell me how much RAM you have.

it's same

it's rdp server with 64 gb ram

32bit seems ok

[Ceppo]

So it's a 64bit issue. I will make some changes to reduce the stack, since is the only lead I have at the moment. Hope to release it for tomorrow.

[Ceppo]

Updated. It was a 30min modification.

v1.0.5
- Reduced stack in CTelecineNew and CDecimateNew
- Now CTelecineNew closes automatically the txt file on last frame.
- Speed improvement.

Hope it works now.

[real.finder]

thanks, seems work fine, but there are something

"# timestamp format v1" should be "# timecode format v1"

and with

D2VSource("Hybrid_30p_+_24i_+60i_+_ifade.d2v")
i=last
bob=stgmc(useEdiExt=2,EdiExt=sanimebob(useBWDIF=true, FastNnediHBD=true),Sharpness=0,tr2=2,ESearchP=true, Refinemotion=true, fastma=true)
#~ CTelecineNew(bob=true,write=true,thr60i=0.1)
CTelecineNew(bob=true,thr60i=0.1)
CPostProcessing(0.1,0.9,isbob=true,edeint=i.CPostProcessingMask(bob=bob,nt=4),edeint2=bob)
CDecimateNew(isBob=true,error=false)

it still got some random frames replaced with last frame even in 32bit!

[Ceppo]

thr60i in CTelecineNew and thr2 in CPostProcessing must have the same value. Try this way.
If still does that, tomorrow I will look into it (same clip I guess). Also, you are supposed to bob after CTelecineNew.

"# timestamp format v1" should be "# timecode format v1"

Last version of mkvtoolnix doesn't accept that.