Any docs decribe debug/show info of Decomb?

[Valeron]

i'm playing IVTC on some anime DVD with decomb 5.21.

i've manual override telecide() parameters to reach a near perfect postprocessing and field match, but the ending song seems jerky and got frame drop, thus i wanna to manual fine tune the threshold2, but i can't found the info about debug info from decimate() and how to manipulate the threshold2 with it.

i've read the reference manual and all the docs, got mostly the knowlege, but the debug/show info is lost, anywhere i can get docs on the topic?

[Guest]

It's not documented. Was there something specific that you wanted to understand?

[Valeron]

thx, neuron
here is a sample (ftp://vtemp:testdemo@218.3.150.121:5500/ED.avi) to show you what specific problem i encounted. some part of this sample got unexpected frame dropping.

according to the reference manual(if i do not comprehend wrong), the threshold2 parameter in decimate control the decimate behavior with mode 2.

and the manual told me to anaylze the debug info to fine tune this problem. that's what i need to understand.

sorry to forget the script
here it is

entire=MPEG2Source("G:\DVD_VIDEO\kagekame_01_pro.d2v")
ED=trim(entire,39409,42107)
ED=telecide(ED,order=1,post=2,back=1)
ED=decimate(ED,mode=2)
ED=Crop(ED,4,2,-4,-2)
ED=bicubicresize(ED,720,540)
return Convolution3D(ED,preset="animeHQ")

[Guest]

Before I download 22Meg at 5Kbytes/sec, please tell me whether it is the unprocessed source video.

I can't do anything useful with your processed result.

[Valeron]

it's the encode result~
the source is vob files, 1.29G in total
i've no tool to cut it

any idea to place it on the server?

you can try download accelerator to enable multi session download, afaik, this account promise multi session connection.

[Valeron]

i've used ChopperXP to extract the clip (ftp://vtemp:testdemo@218.3.150.121:5500/clip.vob)(not exactly the same, several frame exceed i trimmed in the script)

PS: are you(neuron) going to document the debug info in the future? i think this will help many guys a lot

[Guest]

That server is dreadfully slow (3 KBytes/sec). Can't you use a popular file upload site like rapidshare?

If not, check back in again in 24 hours. :(

[Valeron]

these links promise unlimit multi session download, try it with a download accelerator
hope it help

PS: i'm uploading clip.vob to rapidshare, but it's damn slow for me, i've got only 4kbytes/s uploading....
if you don't have an accelerator and can't bear the slow single session download, wait till i post the rapidshare link.

thank you for your attention to my case

[Guest]

I'll just continue with the current download.

I'm at 15% now.

I did

Telecide(post=0)
Decimate()

...on what I have and didn't see any issues. Where does the problem occur (frame number after decimation)?

[Valeron]

from about 700 to 900 frames, 1150 to 1350 frames, with the script i post above

[Valeron]

:stupid:

thx neuron, you probably should stop the download now!

i try disable postprocessing a minute ago, surprised! it give me what i want!

why do postprocessing will lead to such kind of frame drop?
how does telecide postprocess/deinterlace the clip?

[Valeron]

@dear neuron:
another question, can i used an overriden script file to force some frames to be de-postprocessed?

the manual doesn't clearly state which frame will be take into account as postprocessed necessary(i know dthresh in charge of this task, but can i force those frames as "not comb" to disable postprocess(no "comb" then no necessary to decomb)), does my idea work?

[Guest]

I'll answer fully after I get the whole clip and look at it.

From Decomb reference manual for Telecide():

To force a frame to be considered NOT combed, use lines like this:

100 -
100,500 -

[Valeron]

thx for your so kind reply, neuron

i'll encode the "final"(hopefully) version and look forward your detailed explanation.

here time is 4:10 am(kinda late because somewhere in Germany is drawing my heart), i've to go to bed now, see u

[Guest]

The download just finished a minute ago. Sleep well.

[Guest]

from about 700 to 900 frames Using my simple script on your clip I see no problems at all in that range (single stepping through that range in VirtualDub). Can you try it and direct me to the exact frame number where you think there is a problem?

why do postprocessing will lead to such kind of frame drop? As I said, I see no "frame drop", nor is postprocessing likely to cause such a thing. I'll wait for your answer to my question above.

how does telecide postprocess/deinterlace the clip? Very well, thank you.

Seriously, is there something in the reference manual that you find unclear about it?

[Valeron]

Using my simple script on your clip I see no problems at all in that range (single stepping through that range in VirtualDub). Can you try it and direct me to the exact frame number where you think there is a problem?


my cpu can't play the script even only with telecide&decimate&resize flawless. but the cpu usage won't reach 100% it's around 90%.

the frame drop is noticed when i playback the encode result with XviD 1.1(certainly i leave the frame drop ratio to 0), maybe i named it wrong, i might call it "frame jump like something dropped"

i followed the reference manual and your recommend to used mode 2 decimate.

If mode=2, Decimate() deletes a frame from the longest run of duplicates. This mode is the most reliable with anime and other material where the motion may occur only in every second, third, or fourth (etc.) frames.
but take the words above into account, is this part more fitting for mode 0?

just now i serve the script

entire=MPEG2Source("G:\DVD_VIDEO\kagekame_01_pro.d2v")
ED=trim(entire,39409,42107)
ED=telecide(ED,order=1,post=2,back=1)
ED=decimate(ED,mode=2)
ED=Crop(ED,4,2,-4,-2)
return bicubicresize(ED,720,540)

(mode 2 decimate, trim from the original vob) into VirtualDub and step it through, i found duplicate that haven't been decimate
here they are
430&431
781&782
785&786
793&794
797&798
801&802
806&807
813&814
821&823
829&830
837&838
841&842
.....etc in the range

then i try the clip.vob without trim but mode 2 still.

ED=MPEG2Source("G:\DVD_VIDEO\kagekame_ED.d2v")
ED=telecide(ED,order=1,post=2,back=1)
ED=decimate(ED,mode=2)
ED=Crop(ED,4,2,-4,-2)
return bicubicresize(ED,720,540)

some duplicates gone but some stay still(and some new generated?)
you can check frames below:
726&727
770&771
778&779
782&783
786&787
.... etc

i've check mode 0, some duplicates stay still, some shifted by one frame
770&771
777&778
781&782
785&786
789&790
806&807
..... etc


Seriously, is there something in the reference manual that you find unclear about it?

no information about how to analyze from debug info to tweak the advanced parameter of telecide&decimate&fielddeinterlace, for what kind of source should disable postprocessing?(experience dependent?)
interpolate vs blend, which delivered better quality?

and....
maybe i need some times to wrap up all my questions to go on

[Guest]

my cpu can't play the script even only with telecide&decimate&resize flawless. but the cpu usage won't reach 100% it's around 90%. You're not understanding my intent! I asked you to single step through in VirtualDub with my script. I ask that to test whether the script is correct for rendering this video. It doesn't matter whether the script can be played in real time. If you do that and see that the script is correct, then we will know that the problem lies in your encoding: either your encoding itself is flawed, your decompressor is hosed, or your CPU lacks horsepower to properly play back the file. Playing around with different Decimate() modes is not going to fix that!

the frame drop is noticed when i playback the encode result with XviD 1.1 Then, as I said, there is no reason to mess with Decimate() modes.

i followed the reference manual and your recommend to used mode 2 decimate. Not to solve encoder issues! Mode 2 is for material where the motion may occur only in every second, third, or fourth (etc.) frames, i.e., when there are runs of duplicates. The clip you supplied has no runs of duplicates at all, so there is no reason to apply mode 2 decimation.

It seems to me that you are barking up the wrong tree. Use mode 0 and look for the source of your problem in the right place.

[Valeron]

@neuron:
did you check my whole post above seriously, i've step through in VD but i still see duplicates there, the frame number i've listed.
even with mode 0....
have you check it?


i've check mode 0, some duplicates stay still, some shifted by one frame
770&771
777&778
781&782
785&786
789&790
806&807
..... etc



Not to solve encoder issues! Mode 2 is for material where the motion may occur only in every second, third, or fourth (etc.) frames, i.e., when there are runs of duplicates. The clip you supplied has no runs of duplicates at all, so there is no reason to apply mode 2 decimation.


i see here maybe i misunderstand mode 2 doesn't meant for anime generally, so i have to confirm


i followed the reference manual and your recommend to used mode 2 decimate.

If mode=2, Decimate() deletes a frame from the longest run of duplicates. This mode is the most reliable with anime and other material where the motion may occur only in every second, third, or fourth (etc.) frames.

but take the words above into account, is this part more fitting for mode 0?


now i got it, i see i can't use mode 2 for this part so i will rewrite my whole avs to do different processing on it. but how on earth i still see duplicates with mode 0?:thanks:

[Guest]

I didn't notice your observation because the scripts you gave all show mode=2.

Well, you've apparently turned on the back option to Telecide(). From the manual talking about the back option:

"But use it with caution, because it can make some clips jerky."

Use my script (third time I've asked you to do that!). Here it is for your reference:

AssumeTFF() # for Telecide() 5.2.2; not needed for 5.2.1
Telecide(post=0) # version 5.2.2 takes order from Avisynth; add order=1 for 5.2.1
Decimate()

I see no problems with that.

Advanced options invoke heuristics to deal with problematic video, and they are not perfect. But the clip you provided is not problematic in any way, so the bare options work fine.

[Valeron]

thx, i'll keep these in mind~

then can i come to a conclusion about how decomb help me to perfect IVTC the source like this?

Decomb can do mostly job for us when IVTC a clip by default setting. But it hardly give a near "perfect" result. Its very source dependence. We've to manual override something such as force some section to be de-postprocess to delivered a better picture, overriden some wrong field match(back is also an option allow previous frame match consideration), handcraft some scene to be decimated with different mode(for anime, the openning, ending and scene with fast motion is such kind of zone), anyway, to do a perfect IVTC is not easy.

[Guest]

Sure, everything you say is correct. But since I don't have the time or motivation to write a book about it, all I can do is help when specific problems are raised. And the threads at this forum already cover a lot of it. Maybe you would consider contributing to the community by assembling these resources into a collection of indexed links. I'm just too busy making new tools.

[Valeron]

:thanks:

i hope i can help contribute to the community in the futrue when i'm more experience with it. since i'm still a newbie to "perfect" IVTC, i can't speak more than my case.

index the links on this topic sounds a good idea, i'll try

[gameplaya15143]

to do a perfect IVTC is not easy.
Actually, I think it's very easy... but very time consuming :devil:

manually overriding telecide for every frame take a long time, as does setting up decimation overrides.

From the first post, it seems like the credits are purely interlaced (29.97fps, perhaps maybe just the text scroll). In these places it is best to override telecide and tdecimate. Then you might be able to get decent results instead of horrible results.

Use tdecimate instead of decimate, you can override tdecimate and set decimation patterns manually. (AFAIK decimate can't do that)