Welcome to Doom9's Forum, THE in-place to be for everyone interested in DVD conversion. Before you start posting please read the forum rules. By posting to this forum you agree to abide by the rules. |
22nd December 2004, 07:46 | #141 | Link |
Registered User
Join Date: Dec 2003
Location: MO, US
Posts: 999
|
Minor bug fix release [link removed], changes:
Code:
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. Last edited by tritical; 4th January 2005 at 03:38. |
27th December 2004, 15:20 | #142 | Link | |
Registered User
Join Date: May 2004
Posts: 94
|
Quote:
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... |
|
27th December 2004, 15:48 | #143 | Link |
Registered User
Join Date: May 2004
Posts: 94
|
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 |
3rd January 2005, 07:59 | #144 | Link |
Registered User
Join Date: Dec 2003
Location: MO, US
Posts: 999
|
And here comes another release... [link removed], the changes:
Code:
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. Last edited by tritical; 4th January 2005 at 03:37. |
4th January 2005, 03:36 | #146 | Link |
Registered User
Join Date: Dec 2003
Location: MO, US
Posts: 999
|
And another release... [line removed]. Finally got the last thing on the todo list taken care of, a chroma option for tdecimate. Changes:
Code:
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 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. Last edited by tritical; 8th January 2005 at 09:31. |
5th January 2005, 17:39 | #148 | Link | |
Registered User
Join Date: May 2004
Posts: 94
|
Quote:
So... which one is the best ? |
|
5th January 2005, 17:47 | #149 | Link |
brainless
Join Date: Mar 2003
Location: Germany
Posts: 3,653
|
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: Code:
video=last analyse=last.separatefields().selectevery(4,0,3).weave() analyse.smartdecimate(6250,2997,bob=video,weave=video) Code:
tdecimate(mode=2,rate=23.976)
__________________
Don't forget the 'c'! Don't PM me for technical support, please. |
6th January 2005, 02:09 | #150 | Link |
Registered User
Join Date: Dec 2003
Location: MO, US
Posts: 999
|
@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 . @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? |
8th January 2005, 09:29 | #152 | Link |
Registered User
Join Date: Dec 2003
Location: MO, US
Posts: 999
|
[link removed], changes:
Code:
TDecimate: - Fixed SetCacheHints being called incorrectly and always defaulting to CACHE_ALL - Small change to protect against overflow in mmx/sse2 blend routines when one of the weights is 1.0 TFM: - Fixed SetCacheHints being called incorrectly and always defaulting to CACHE_ALL Also, mode 2 is probably gonna be scrapped here soon, as it just isn't working. I have another idea for doing arbitrary frame rate decimation using cycles with automatically varying cycle/cycleR values throughout the clip. The good thing about such a method is it will be free of dependence on a threshold, but basing it off cycles means it does have to make some assumptions about how often so many duplicates are present. I have not been able to test it yet to see if it will work out, but it can't be any worse then mode 2 is now . Last edited by tritical; 20th February 2005 at 07:17. |
10th January 2005, 23:29 | #154 | Link |
Registered User
Join Date: May 2004
Posts: 94
|
tritical, have a look here, there is an example in which your TD2VFix does not work
http://forum.doom9.org/showthread.ph...083#post593083 |
20th January 2005, 16:31 | #155 | Link |
brainless
Join Date: Mar 2003
Location: Germany
Posts: 3,653
|
probably a bug:
chroma is always getting included in the Y-comb mask. even if chroma=false is used to make 'sure' that chroma isn't inculed in the luma mask. this can be prooved using a video with rainbowed static subtitles. they always do show heavy bobbing. Only if I set mthreshc to incredible high values like 100, the bobbing stops.
__________________
Don't forget the 'c'! Don't PM me for technical support, please. |
20th January 2005, 19:30 | #156 | Link |
Registered User
Join Date: Dec 2003
Location: MO, US
Posts: 999
|
Its not really a bug, but lack of a feature. The chroma option only controls whether chroma is used in the combed frame decision, which is only used if full=false or tryWeave=true. When making the comb mask the chroma and luma planes are always linked. When I get around to working on TDeint again I'll add in a link parameter to let the user control how the planes are linked (no linking, Y to UV, UV to Y, or full).
|
21st January 2005, 00:52 | #157 | Link |
Registered User
Join Date: Dec 2003
Location: MO, US
Posts: 999
|
TDeint v0.9.7, changes:
Code:
+ Added link and denoise parameters + Added ELA interpolation (tomsmocomp version) as type = 3 + Hints option can now read hints from tfm as well as telecide + map = 2 now sets the chroma pixels that are to be interpolated to 255 and not just the luma - Changed default type value to 2 (kernel interpolation) - Changed default tryWeave value to false |
21st January 2005, 12:30 | #158 | Link |
interlace this!
Join Date: Jun 2003
Location: i'm in ur transfers, addin noise
Posts: 4,555
|
excellent
would you recommend the ELA or kernel method as a generic deinterlacer? i've been using the ELA and haven't had any trouble (field-blended anime seems to come out very well regardless of what's used, which is awesome as field-blends are usually a deint killer rather than an easy case).
__________________
sucking the life out of your videos since 2004 |
21st January 2005, 13:53 | #160 | Link |
Brazilian Anime Ripper
Join Date: Nov 2001
Location: Brazil
Posts: 237
|
#BangoO:
TDeint: 0.9.7 TIVTC: 0.9.7.2 You are confused
__________________
Capture cards: Compro VideoMate Gold+ (Philips SAA7134 based) (not active) Hauppauge PVR 150MCE (not active) ATI TV Wonder Elite (active) |
Tags |
tdeint, tivtc |
Thread Tools | Search this Thread |
Display Modes | |
|
|