@len0x: auto-IVTC methods for AutoGK

[len0x]

Originally posted by bilu
But between A) and B) from my last post, which do you prefer? Collect Decimate's output or scale frame differencing in Avisynth?


I have to look at it first. Before I see how difficult mapping can be I can't tell for sure. I'd like to be able to do that without dbgproxy though...

[bilu]

Originally posted by len0x
I have to look at it first. Before I see how difficult mapping can be I can't tell for sure. I'd like to be able to do that without dbgproxy though... The source code is available in dbgproxy.zip, and it's very small.

[len0x]

Originally posted by bilu
The source code is available in dbgproxy.zip, and it's very small.

source code of what ?

[bilu]

Of dbgproxy, to capture the OutputDebugString from Decomb and parse it.

[len0x]

ah, you mean that I can do that by myself without using dbproxy and no mapping is still required ? It's getting interesting :)

[bilu]

yep, that's it :)

But still requires parsing, of course.

Edit: You should try DBGProxy to see what kind of output you get and prepare your parsing.

[bilu]

About the Star Trek Hybrid clip, I finally found this post again:

http://forum.doom9.org/showthread.php?s=&postid=337685#post337685
This works good for me for the challenge clip:

telecide(order=1,guide=1,post=4,vthresh=45,hints=true)
decimate(mode=3,threshold=0.6)

Two points: 1. You need to get the threshold right for mode=3. 2. It's important not to have too low a vthresh with post=4, because it will force backward matches that declare out-of-pattern and thus force video decimation.

I'm planning a new attack on hybrid clips. But first we have to nail this crashing problem with guide=1 for betas 11 and beyond.post (0-5, default 2) controls whether and how Telecide performs postprocessing to clean up frames that come through the field-matching still combed:

post=0: Use this to totally disable postprocessing.
post=1: Use this to enable the metrics calculation and to display the vmetric values but not perform deinterlacing.
post=2: Use this to enable deinterlacing. Note that in this mode, the field matching occurs normally and the best matched frame is deinterlaced and delivered.
post=3: This is the same as post=2 except that the deinterlacing motion map is displayed in white on the deinterlaced frames.
post=4: This is the same as post=2 except that instead of using the best field match for the frame, the original frame is deinterlaced. You would use this to pass video sequences through when you have a hybrid clip.
post=5: This is the same as post=4 except that the deinterlacing motion map is displayed in white on the deinterlaced frames.


vthresh (0.0-255.0, default 50.0) sets the combed frame detection threshold for the postprocessing. You may want to increase this value if too many good frames are being deinterlaced, or reduce it if some combed frames are not getting caught. The default is a reasonable general purpose value. Note that this threshold determines whether a frame is considered combed and needs to be deinterlaced; it is not the threshold you might be familiar with in Smart Deinterlacer. That threshold is determined by dthresh (below); it is the threshold for deinterlacing the frames detected as combed.

Vthresh: frames that exceed it will be considered combed and will be post-processed (deinterlaced).

Post=4: try to do a field match with the FILM pattern. If it can't it will deinterlace (post-process) the current frame instead of trying to match with the best field available. This will be useful for Decimate hybrid modes: they will recognize this as VIDEO and treat accordingly.

So what neuron2 seems to be saying is: if vthresh is low frames will be post-processed, and this will lead to bad matches in post=4 pattern detection, so there is a risk that FILM gets treated as VIDEO both in Telecide and Decimate.

I don't know if this problem is solved, and I think vthresh should somewhat be disabled during hybrid processing: after all, frames will be post-processed by post=4 whenever they don't fit the FILM pattern.

So for now I'd stick with post=0 and deinterlace after the Telecide/Decimate process with KernelDeint. I'd also prefer to use hints=false with Telecide so that it doesn't affect KernelDeint: works better this way with very fast scene changes.

I'll post this in Neuron2 and in Avisynth Usage forums to know if there is any solution (or misunderstanding of mine) to this "vthresh VS post=4" issue.

Reported in:
http://forum.doom9.org/showthread.php?s=&threadid=66236
http://neuron2.net/ipw-web/bulletin/bb/viewtopic.php?p=2724#2724


Bilu

[alucard83]

Bilu is the Star Trek mostly film or video?

[bilu]

Mostly film with video parts on remastered or new special effects.
As most Sci-fi hybrid movies. In anime you can't tell for sure :D but some also get 3D CGI effects @30fps on top of Telecined 24fps->30fps.

From http://www.doom9.org/ivtc-tut.htm :

THE DREADED HYBRIDS. Many "making of" documentaries or other special features on DVD’s, and unfortunately, some complete DVDs (a very few thank goodness) are a mix of Film and Video (30fps Interlaced) material. Some (including a lot of the newer anime DVDs, such as Excel Saga) are a mix of Film and 30fps Progressive material. Here you are faced with 2 choices, neither of them pleasant. It, in part, depends on how much of each there is and how it looks with the 2 solutions. For example, a DVD made from a television show might have been created in Film, but have a few minutes of Computer Generated effects done at 29.97fps. The Anime Serial Experiments Lain has some of this. So do the infamous Star Trek: The Next Generation DVDs. So, do you IVTC it and make it 23.976fps and have the CG material play jerky? Or do you make the whole thing 29.97fps so that it will play relatively smoothly, but in the process get lower quality for the same file size, because of the 25% greater number of frames? It's a tough decision. I've seen DVD Documentaries which are made up of mostly Film material. But there will also be interlaced photographs which are frequently panned or zoomed. You IVTC these and those photographs play very jerky. Perhaps the best solution is to use Decomb's Decimate(Mode=1). This will preserve most of the progressive material and will play relatively smoothly but, again, keep it at 29.97fps. If you are using AviSynth 2.51, you can try the Mode=3 option which will blend much of the 29.97fps material and return the whole thing to 23.976fps. I can't tell you what to do in those cases. You’ll have to experiment and see what looks best to you.

Bilu

[bilu]

Good news: I wasn't able to recreate the problem.

Even with an insane vthresh=0 (mark all frames for post-processing) I wasn't able to make it go out-of-pattern - it never got jerky.

telecide(order=1,guide=1,post=4)
decimate(mode=3,threshold=0.6)

works just fine on this clip.

@len0x
Let's keep on moving ;)


Bilu

[len0x]

Originally posted by bilu

@len0x
Let's keep on moving ;)


I'm trying :)
But I'm short on time a bit since not only I have to fix bugz in AutoGK, but also update GK this weekend...

p.s. and also I just spent 4 hours marking courseworks of stupid students :)

[bilu]

Originally posted by len0x
I'm trying :) No need to hurry, mate :)
I just thought you had stopped working on AutoIVTC until my "post=4 VS vthresh" thingy was clear. I'm glad it was a false alarm.Originally posted by len0x
p.s. and also I just spent 4 hours marking courseworks of stupid students :) what are you teaching, oh talented one? :D


Bilu

[len0x]

Originally posted by bilu
what are you teaching, oh talented one? :D


Thank god, nothing :)
But occasionally I've been asked to mark some stuff though...

[bilu]

Hi Len0x,

Any news?


Bilu

[len0x]

yes and no :)

No means I haven't done anything actually, but yes mean that I know when I do that :)

This week i'm releasing 0.8 and then go for three weeks holiday during which I'm planning to come up with two features for AutoGK:
- batch encoding
- IVTC hybrid parameters tuning

[bilu]

My two favorites... :D

[len0x]

after that I don't really see any other tool even come closer to AutoGK :)

P.S. bli'me - my 1500's post :)

[bilu]

Originally posted by len0x
after that I don't really see any other tool even come closer to AutoGK :)

Well, it would be great if encoding tools for RV9 and/or Matroska also got AutoIVTC... ;)

How do you deal with the Field Shift problem? Using Telecide(guide=2) on PAL and KernelDeint on NTSC everytime a source is considered interlaced?

I'd like to know if NTSC sources could also suffer from the field shift problem. I've allways heard of this as a PAL problem :rolleyes:


Bilu

[len0x]

Shifted order is dealt with in d2v (Field operation).
I chose the mode which has less interlacing percentage.
And yes, it's specific to PAL sources.

P.S. RV has no future...

[bilu]

Originally posted by len0x
P.S. RV has no future...

Let's give them a chance, shall we? :D
They're behaving very well with the community, it's the best codec around for anime according to some, they only lack standalone support but hey, not everybody encodes for standalones... ;)

Bilu

[len0x]

Originally posted by bilu
they only lack standalone support but hey, not everybody encodes for standalones... ;)


this is what I call future...
by the end of next year the number of standalones which do not have support of divx/xvid will be the same as now the number which supports them (the money big players are investing in this now are amazing). So why normal end-user should bother with the format he can't really watch anywhere apart from PC whilst there is a format which can be played almost everywhere ?

[bilu]

I guess you're right. Then again, on today's news:
elta also promises to support XviD GMC by mid February as well as OGM. Maybe we can see OGM getting somewhere. And if ChrisHJW pushes enough, maybe even Matroska... :D

Bilu

[len0x]

Originally posted by bilu
I guess you're right. Then again, on today's news:
Maybe we can see OGM getting somewhere. And if ChrisHJW pushes enough, maybe even Matroska... :D


I didn't say anything about containers. Their support is rather on the firmware level, not hardware. Totally different story for codecs.
In fact i believe that both OGM and MKV can be adopted by hardware vendors, but there must be tools producing those files.

[bilu]

Originally posted by len0x
I didn't say anything about containers. Their support is rather on the firmware level, not hardware. Totally different story for codecs. I know, I know. Hope the RV guys start taking a look at licensing to become competitive in such a market. Wouldn't be a bad thing to avoid MPEG licensing monopoly... :rolleyes:

Bilu

[len0x]

First problem I'm running into:

dbgview has issues when running VDubMod, but not avs2avi...

And while writing a simple debugger for it I also see lots of issues with debug process of vdubmod... (for a start I can't even launch vdubmod as debug process - very probably it's _very_ slow to do that)

[bilu]

You don't need to use VDMod in any debug mode, you just need to capture Win32OutputDebugString(). Any process may use this independently, and dbgview will in this case capture messages from Telecide/Decimate, with no need to capture debug from VDMod itself.

I've just downloaded the latest VDMod and DebugView and previewed a script like this:

Telecide(FOrder(),debug=true)
Decimate(debug=true)

with DebugView open, and successfully captured the debug messages.
And since there was no codec or VDMod messages, the output I got was only from Telecide and Decimate. With DBGProxy I had no problems either, although it gets more garbage in the output, drivers loaded ,etc.

So you just need to use VDMod normally and have a process capturing Win32OutputDebugString() messages. You can find related examples on the net or use DBGProxy's source code for that.

PS: Well, maybe you already knew that :rolleyes: .
What kind of issues have you seen between VDMod and DBGView?


Bilu

[len0x]

I know more than that :) (And btw, I'm using dbgproxy from the link you posted ealier)

First when I'm running vdubmod under dbgproxy i get this log (I'm trying to get debug info from KernelDeInt as an example):

dbgproxy is starting up...
Process Launched...
Process Created
DLL Loaded: ntdll.dll
DLL Loaded: C:\WINDOWS\system32\kernel32.dll
DLL Loaded: C:\WINDOWS\system32\ADVAPI32.dll
DLL Loaded: C:\WINDOWS\system32\RPCRT4.dll
DLL Loaded: C:\WINDOWS\System32\AVICAP32.dll
DLL Loaded: C:\WINDOWS\system32\USER32.dll
DLL Loaded: C:\WINDOWS\system32\GDI32.dll
DLL Loaded: C:\WINDOWS\System32\WINMM.dll
DLL Loaded: C:\WINDOWS\system32\VERSION.dll
DLL Loaded: C:\WINDOWS\System32\MSVFW32.dll
DLL Loaded: C:\WINDOWS\system32\SHELL32.dll
DLL Loaded: C:\WINDOWS\system32\msvcrt.dll
DLL Loaded: C:\WINDOWS\system32\SHLWAPI.dll
DLL Loaded: C:\WINDOWS\system32\COMCTL32.dll
DLL Loaded: C:\WINDOWS\System32\AVIFIL32.dll
DLL Loaded: C:\WINDOWS\system32\ole32.dll
DLL Loaded: C:\WINDOWS\System32\MSACM32.dll
DLL Loaded: C:\WINDOWS\system32\comdlg32.dll
DLL Loaded: D:\GK4U\VDubMod\corona.dll
DLL Loaded: <unknown>
DLL Loaded: <unknown>
EXCEPTION cont-first @77f75a58: Breakpoint was encountered
DLL Loaded: C:\WINDOWS\WinSxS\x86_Microsoft.Windows.Common-Controls_6595b64
DLL Loaded: C:\WINDOWS\System32\SynTPFcs.dll
DLL Loaded: C:\WINDOWS\System32\MSCTF.dll
DLL Loaded: D:\GK4U\VDubMod\SciLexer.dll
DLL Loaded: C:\WINDOWS\System32\IMM32.DLL
DLL Loaded: <unknown>
DLL Loaded: C:\WINDOWS\system32\oleaut32.dll
DLL Loaded: C:\WINDOWS\System32\Riched20.dll
DLL Loaded: <unknown>
DLL Loaded: <unknown>
DLL Loaded: C:\WINDOWS\System32\MSVCP60.dll
DLL Loaded: C:\WINDOWS\System32\QUARTZ.dll
EXCEPTION noncont-first @77e73887: Unknown Exception
EXCEPTION noncont-first @77e73887: Unknown Exception
DLL Loaded: C:\WINDOWS\System32\DCIMAN32.DLL
DLL Loaded: C:\WINDOWS\System32\CLBCATQ.DLL
DLL Loaded: C:\WINDOWS\System32\COMRes.dll
DLL Loaded: C:\WINDOWS\System32\ddraw.dll
EXCEPTION noncont-first @77e73887: Unknown Exception
EXCEPTION noncont-first @77e73887: Unknown Exception
DLL Loaded: <unknown>
DLL Loaded: <unknown>
DLL Loaded: <unknown>
DLL Loaded: <unknown>
!MPEG2DEC3: D2V v1.77.3 Detected...Compensating
!MPEG2DEC3: bad frames = 0

EXCEPTION noncont-first @77e73887: Unknown Exception
!KernelDeint Version 1.4.0, (C) 2003, Donald A. Graft, All Rights Reserved

EXCEPTION noncont-first @77e73887: Unknown Exception
EXCEPTION noncont-first @77e73887: Unknown Exception
!KernelDeint: frame 0: interlaced

!KernelDeint: frame 0: interlaced

!KernelDeint: frame 0: interlaced

EXCEPTION noncont-first @77e73887: Unknown Exception
DLL Loaded: <unknown>
DLL Loaded: C:\WINDOWS\System32\winspool.drv
EXCEPTION cont-first @37641a4: Access Violation.
FATAL FAILURE -> terminating the process...
Result: FAIL - process had to be exterminated.


I saw the code and know why this is happening (exception causes dbgproxy to kill the process.) Here is how full debugging thing works:

1) you create the process with DEBUG_ONLY_THIS_PROCESS flag
2) you have a loop waiting for WaitForDebugEvent
3) then you process OUTPUT_DEBUG_STRING_EVENT

So I can't atm even start VDubMod with debug flag - main window never shows up :( Without debug flag I obviously can't get WaitForDebugEvent to work properly.

[bilu]

Originally posted by len0x

I saw the code and know why this is happening (exception causes dbgview to kill the process.) Here is how full debugging thing works:

1) you create the process with DEBUG_ONLY_THIS_PROCESS flag
2) you have a loop waiting for WaitForDebugEvent
3) then you process OUTPUT_DEBUG_STRING_EVENT

So I can't atm even start VDubMod with debug flag - main window never shows up :( Without debug flag I obviously can't get WaitForDebugEvent to work properly.

I may not understand you well in programming issues ;)

Why don't you simply output to a file and parse it later instead of using that full debugging process? It's simpler and probably faster too.

Bilu

[len0x]

Originally posted by bilu
I may not understand you well in programming issues ;)

Why don't you simply output to a file and parse it later instead of using that full debugging process? It's simpler and probably faster too.


Let me explain. To capture debug messages you _have_ to run the program (vdubmod) in debug mode. Now I have two options:

1) use dbgproxy (which is a debugger itself and runs everything as debug processes) to output to file and parse it. This doesn't work as I previously told you since dbgproxy kills vdubmod.

2) use my own debugger the same way as in dbgproxy and write file myself. This doesn't work for me yet coz I can't seem to start VdubMod properly...

Dead end so far...

[bilu]

Originally posted by len0x
Let me explain. To capture debug messages you _have_ to run the program (vdubmod) in debug mode. Now I have two options:

1) use dbgproxy (which is a debugger itself and runs everything as debug processes) to output to file and parse it. This doesn't work as I previously told you since dbgproxy kills vdubmod.

2) use my own debugger the same way as in dbgproxy and write file myself. This doesn't work for me yet coz I can't seem to start VdubMod properly...

Dead end so far...

This command-line tool can launch any other program while acting as a debugger to:

* Capture program crashes: when the debugged program crashes, it is terminated without user intervention. A specific return code informs the calling script of what happened.
* Capture program logs generated using the DebugString call, and output them to STDERR (standard error output) prefixed with a '!'.
* Send additional messages to STDERR, about DLL loading, thread creation/termination, etc) -- information typically seen in the output log of a debugger in Windows.


The return codes of dbgproxy are:
-1 Failed to launch the debugged application -- check your command line.
0 The debugged application ended normally, with a return code of zero.
1 The debugged application ended normally, but with a non-zero return code.
2 The debugged application had to be killed because of a fatal error -- a description of the issue has been written to STDERR.

Can't you just trim functionality from DBGProxy's source?
a) Avoid additional messages like thread creating/terminating;
b) Avoid terminating apps on fatal error;

This way you could:
a) use DBGProxy's way of loading VDMod;
b) avoid using debug mode in VDMod;

Bilu

[len0x]

Originally posted by bilu
Can't you just trim functionality from DBGProxy's source?
a) Avoid additional messages like thread creating/terminating;
b) Avoid terminating apps on fatal error;

This way you could:
a) use DBGProxy's way of loading VDMod;
b) avoid using debug mode in VDMod;


I'm trying to find C++ compiler at hand :)
In any case I wanted to use delphi for that. I completely duplicated the calls (it's win32 API anyway), but damn thing is not working...

[len0x]

I made some progress after all ! :)
finally after half a day of struggling I managed to run applications under debug mode with no probs... hopefully now nothing can stop me from reading debug output in memory without writing to intermediate files.

[bilu]

Originally posted by len0x
I made some progress after all ! :)
finally after half a day of struggling I managed to run applications under debug mode with no probs... hopefully now nothing can stop me from reading debug output in memory without writing to intermediate files. That's the spirit ;)

Merry Xmas len0x :)


Bilu

[len0x]

Finally the whole infrastructure is in place and I can implement thershold algorythm itself. I'm looking at the optput of decimate now and trying to think: if all the values I get are already for dupes only then the threshold can be simply set as rounded maximum of metrics from Decimate, right?

So there is no need in algorythm of 90% as you described in the very beginning. What do you think ?

P.S. Also the output I get from decimate is in form of:


Decimate: 0: 0.00
Decimate: 1: 0.21
Decimate: 2: -0.00
Decimate: 3: -0.00
Decimate: 4: -0.00
Decimate: in frm 0, use frm 0
Decimate: dropping frm 1
Decimate: in frm 1, use frm 2
Decimate: dropping frm 3
Decimate: 4: 2.44
Decimate: 5: 0.14
Decimate: 6: -0.00
Decimate: 7: -0.00
Decimate: 8: -0.00
Decimate: in frm 2, use frm 4
Decimate: dropping frm 5
Decimate: in frm 3, use frm 6
Decimate: dropping frm 7
Decimate: 8: 3.41
Decimate: 9: 0.12
Decimate: 10: -0.00


Am I safe to just to look at frames 1,3,5,7,9... ? (coz I feed only sequences of two dupe frames anyway).

[bilu]

This is the kind of output I've seen so far, never seen negative values :confused: Are you sure you used Telecide(guide=0) before Decimate?
!Decimate: 0: 0.00
!Decimate: 1: 5.50
!Decimate: 2: 6.11
!Decimate: 3: 6.55
!Decimate: 4: 0.00
!Decimate: in frm 0, use frm 0
!Decimate: dropping frm 4
!Decimate: in frm 1, use frm 1
!Decimate: dropping frm 4
!Decimate: in frm 2, use frm 2
!Decimate: dropping frm 4
!Decimate: in frm 3, use frm 3
!Decimate: dropping frm 4
!Decimate: in frm 4, use frm 5
!Decimate: dropping frm 9
!Decimate: 5: 6.87
!Decimate: 6: 7.00
!Decimate: 7: 6.69
!Decimate: 8: 6.73
!Decimate: 9: 0.00
We would only need the thresholds from frames 4 and 9 in this case, you are correct. Only the dropped frames threshold value matter.

Bilu

[len0x]

I'm using the following script:

Telecide(order=getOrder(),guide=0,back=0,post=0).Decimate(cycle=2,debug=true,threshold=0.0)

I wonder what is the precision of threshold parameter - 0.1 or 0.01 ?

[bilu]

Originally posted by len0x
I'm looking at the optput of decimate now and trying to think: if all the values I get are already for dupes only then the threshold can be simply set as rounded maximum of metrics from Decimate, right?

So there is no need in algorythm of 90% as you described in the very beginning. What do you think ?

P.S. Also the output I get from decimate is in form of:

Decimate: 0: 0.00
Decimate: 1: 0.21
Decimate: 2: -0.00
Decimate: 3: -0.00
Decimate: 4: -0.00
Decimate: in frm 0, use frm 0
Decimate: dropping frm 1
Decimate: in frm 1, use frm 2
Decimate: dropping frm 3
Decimate: 4: 2.44
Decimate: 5: 0.14
Decimate: 6: -0.00
Decimate: 7: -0.00
Decimate: 8: -0.00
Decimate: in frm 2, use frm 4
Decimate: dropping frm 5
Decimate: in frm 3, use frm 6
Decimate: dropping frm 7
Decimate: 8: 3.41
Decimate: 9: 0.12
Decimate: 10: -0.00

Am I safe to just to look at frames 1,3,5,7,9... ? (coz I feed only sequences of two dupe frames anyway). I'm waking up now it seems... :)

If you're using something like I mentioned here (http://forum.doom9.org/showthread.php?s=&postid=407507#post407507) for dup prediction then you're feeding a frame and its duplicate ( to be able to generate the diff threshold), not two dups. Hence every even frame threshold counts, but not all frames.

EDIT: Precision seems to be 0.1 from the reference manual.

EDIT 2: Still waking up... since frames in Avisynth start on nr. 0, then you were allways right :) : 1,3,5,7,9,....


Bilu

[len0x]

Originally posted by bilu
If you're using something like I mentioned here (http://forum.doom9.org/showthread.php?s=&postid=407507#post407507) for dup prediction then you're feeding a frame and its duplicate ( to be able to generate the diff threshold), not two dups.

Well, that's what I meant by two dupes (one is duplicate of the other) :)

So I will proceed to by selecting maximum metric for duplicates as a threshold parameter for Decimate then.

[bilu]

Originally posted by len0x
Well, that's what I meant by two dupes (one is duplicate of the other) :)

So I will proceed to by selecting maximum metric for duplicates as a threshold parameter for Decimate then. Please test this over some hybrid stuff before assuming the maximum metric. My tests with the Star Trek hybrid have shown some thresholds higher than 0.6 IIRC and 0.6 is what looks best. Hence that majority theory - you could have some dirtier dupes.


Bilu

[len0x]

Originally posted by bilu
Please test this over some hybrid stuff before assuming the maximum metric. My tests with the Star Trek hybrid have shown some thresholds higher than 0.6 IIRC and 0.6 is what looks best. Hence that majority theory - you could have some dirtier dupes.


I won't be able to do that before I release new version, unfortunately. But it's gonna be alpha, so ppl around here can test it (including you I hope).

[bilu]

That means new version soon? :D

Bilu

[len0x]

Originally posted by bilu
That means new version soon? :D


kinda... next week I hope :)

[len0x]

I hardly could test it on NTSC sources though (have just a few of them at hand and no hybrid stuff at all). On normal IVTC-able source I get threshold of 0.2-0.3.

I have only two questions now:

- is this threshold useful only for mode=1,3 of Decimate or mode=0 (normal IVTC) can benefit from it as well ?
- atm I'm putting two decimal digits as threshold value, so I wonder if Decimate interprets that properly.

[bilu]

I can provide some neuron2's Star Trek hybrid clip and some dirty telecined clips as well (some are AVI, not VOB). Send me a PM with an upload address if you want.

Only modes 1 and 3 benefit from the threshold.
I think two decimals are OK, it's not the first time I hear about it.
But I can't try at the moment.


Bilu

[len0x]

Originally posted by bilu
I can provide some neuron2's Star Trek hybrid clip and some dirty telecined clips as well (some are AVI, not VOB). Send me a PM with an upload address if you want.


This has to wait until I'm back from holidays - I can't download/upload anything atm...

[len0x]

Can you test your vob samples with new (0.86) AutoGK. The value chosen for thershold of decimate is: max_decimate_value_for_dupes+0.01

[bilu]

I don't have much time, can you PM me an upload place?

Bilu

[len0x]

I don't have one atm, but can download it from anywhere though...

[bilu]

I've uploaded them to Dark-Cracker.
Please ask him if they're still online and if you can use my account.

It's about 160 MB of VOB samples. All samples are NTSC.

13.391.872 telecine1.vob
19.509.248 telecine2.vob
46.243.840 anime_telecine.vob
35.921.920 hybrid.vob
52.293.632 interlaced.vob

EDIT: Server is down, and before uploading sucessfully some days ago he told me "hum i think my server have shutdown i am currently not at home (i made my study in an another town and i come back to my house only friday). i will restart the server once i will come back and i will send u a PM once the ftp server will be open, sorry for the time waste " , so I guess it'll have to wait. I'll try tonight your last alpha on my samples and give you some feedback tomorrow.

EDIT2: Values I hope to achieve:

telecine1.vob -> 0.01
telecine2.vob -> 0.01
anime_telecine.vob -> 0.01

They're all pure telecined.

hybrid.vob -> looked good at neuron2's proposed value (0.6), but our method is more scientific :D I'm curious about the results.


Bilu

[darkonejr]

len0x,

I've tested this on a couple of Babylon5 episodes, with mixed results. Sometimes, I get calculated threshold values that are higher than 1 (I got 3.34 in one, 4.26 in another)... I'd imagine that the resulting video results can't be good, though I didn't notice anything that jumped out at me when I took a cursory look at it... In any case, I have log files, just need to know which one you need.


Julian