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. |
24th January 2007, 19:38 | #902 | Link |
Registered User
Join Date: Mar 2005
Posts: 468
|
Just noticed that b13 of DGIndex came out. One of the changes listed is:
* The Correct Field Order option is removed and the field order correction function is now available through the Tools menu: Fix D2V. I did this because this correction should not be applied to streams with frame repeats, and trying to prevent it via a code check runs into technical complications.Will a wrong field order have any effect on TIVTC? |
25th January 2007, 02:39 | #903 | Link |
Registered User
Join Date: Sep 2005
Location: Vancouver
Posts: 600
|
Oh, I didn't know I had to use tfmIn for it to work! Sorry about that. It makes sense considering it would need to grab every frame to get the hints otherwise. The only mention I see of that in the TDecimate readme is in the Changes List section. Maybe you should add it to the tfmIn description for us dummies. (right now it says that it's only useful for hybrid > 0)
I get an invalid specifier error when trying to use tfmIn for files output with PP=0 in TFM though. Last edited by ChiDragon; 25th January 2007 at 06:25. |
25th January 2007, 19:00 | #904 | Link |
Registered User
Join Date: Dec 2003
Location: MO, US
Posts: 999
|
@Isochroma
If you use the d2v="" parameter in tfm, then it checks for illegal field order changes in the d2v (wont work with frame repeats, but tfm shouldn't be needed on those streams)... so it wont matter there. If you don't use the d2v parameter, use a matching mode that can't handle field order changes (only modes 4 and 5 can), and the stream does have field order changes, then there will be a problem. @ChiDragon An explanation in the tdecimate readme is probably a good idea. Another way to get around the need for the tfmIn file is to set hints=false in tdecimate. However, then tdecimate wont get to use any info from tfm. The basic chain of events when tdecimate runs is: startup: 0.) If hints isn't manually set by the user, then grab frame 0 and detect if there are hints in it. If there are, set hints=true, else, set hints=false. during operation: 1.) If there's a tfmIn file, don't read hints for frames that the tfmIn file has info for. 2.) else if hints=true, reads hints for frames that don't have info from a tfmIn file. 3.) else if hints=false, never read hints I'll check out the problem with the pp=0 files. |
29th January 2007, 09:46 | #905 | Link |
Registered User
Join Date: Dec 2003
Location: MO, US
Posts: 999
|
Found and fixed the problem with tdecimate reading tfm output files created with pp=0. I'll put up a new version soon (a work around would be to just use pp=1 in tfm, though it will be slightly slower than pp=0 depending on the matching mode). I am also considering changing the sdlim default in tdecimate so that when cycleR > 1 it defaults to the largest possible value such that there would never be any cases where it couldn't mark a full cycleR worth of frames. I'm thinking that when someone uses cycleR>1 they are generally looking for the decimation to be spread throughout the cycle as sdlim allows instead of actually removing the cycleR frames with the lowest metric (which could all be next to each other).
|
30th January 2007, 07:28 | #906 | Link |
Registered User
Join Date: Sep 2005
Location: Vancouver
Posts: 600
|
Thanks! Yeah, I've been using PP=1 in the meantime.
I'm not sure defaulting sdlim to the largest possible value is a good idea. With the videos I'm encoding now that need sdlim=2, setting sdlim to 3 (or -3) makes TDecimate drop non-dups often. Actually, it drops wrong frames every cycle, but most of them don't matter as it's simply dropping the first of two same-frames (they're only "wrong" since you'd normally want to drop the 2nd frame, with the low metric). The trouble comes at the start and end of the cycles, where it may drop an actual dup at the end of a cycle and then drop a new frame at the start of the next cycle. Last edited by ChiDragon; 30th January 2007 at 07:31. |
1st February 2007, 04:27 | #907 | Link |
Registered User
Join Date: Sep 2005
Location: Vancouver
Posts: 600
|
I've got a weird crash happening now... I'm using this ovr line:
Code:
80194,80303 ++-++-++++-++++-++++-++++-++-++++-++++-++++-++++-++-++++-++++-++++-++++-++-++++-++++-++++-++++-++-++++-++++-++++-++++-++-++++-++++-++++-+++-+++-++++-++++-++++-+++-+++-++++-++++-++++-++-++++-++++-++++-++ |
1st February 2007, 11:22 | #909 | Link |
Registered User
Join Date: Sep 2005
Location: Vancouver
Posts: 600
|
Well, I took the ovr line for a full cycle and just copied and pasted it to this partial cycle (partial because the video ends before it completes). I haven't had problems with redundant overrides before, and using that full line for the range "79992,80002" doesn't cause a crash.
Last edited by ChiDragon; 1st February 2007 at 11:25. |
6th February 2007, 00:46 | #910 | Link |
*Space Reserved*
Join Date: May 2006
Posts: 953
|
tritical, I know this is offtopic, but I was wonderin' if you could perhaps compile speedier versions of Didée's filters such as SeeSaw, Deblock_QED, LimitedSharpenFaster, Mcbob, Soothe, Spresso like how you did for Vinverse?
Probably not gonna happen, but I thought i'd ask since it usually don't hurt to do so btw, keep up the nice work. Edit: tritical, if you or someone else who's interested in porting these filters to .dlls need the scripts, (the latest versions), let me know. Last edited by Terranigma; 6th February 2007 at 01:48. |
7th February 2007, 22:36 | #911 | Link |
Registered User
Join Date: Dec 2003
Location: MO, US
Posts: 999
|
The biggest problem is that I don't know the inner workings of a number of the scripts you metion, some of which are very complex, so it would take me some time to go through them before I could even start turning them into filters. Some of the simpler ones, like Soothe and Spresso, I could do pretty easily, but I don't think there would be much of a speed up since they are mainly just lutxy calls. Though in memory intensive scripts it might help since it would cut down on the number of filters/clips being created and thus cache instances.
Could you post a link to the latest versions of Soothe/Spresso, just to make sure I'm looking at the right ones? I might take a stab at them sometime. |
17th February 2007, 01:15 | #913 | Link |
Huh?
Join Date: Sep 2003
Location: Uruguay
Posts: 3,103
|
I'm having a weird issue: when using the folloeing IVTC lines:
Code:
Deinted=TDeint(order=1,field=1,type=1) TFM(d2v="C:\SimpS7\Epi1.d2v",order=1,mode=6,PP=7,slow=2,mChroma=false,Clip2=Deinted) TDecimate(mode=1) If I remove the "d2v=..." part in the TFM line, the .AVS loads without an issue. What could be causing this?
__________________
Read Decomb's readmes and tutorials, the IVTC tutorial and the capture guide in order to learn about combing and how to deal with it. |
17th February 2007, 03:34 | #915 | Link |
Registered User
Join Date: Dec 2003
Location: MO, US
Posts: 999
|
Alain2 is correct... the error literally means that the field order value you gave to tfm isn't the same as the field order the d2v file indicates. Also, the latest dgindex/dgdecode (v1.4.9 beta 14) will not work with tfm's d2v option because of a new field that was added to the data lines (this may be what is causing your problem since the extra field means tfm never gets to the trf flags). I'll add support for d2v format v16 in the next release.
|
17th February 2007, 03:56 | #916 | Link |
Huh?
Join Date: Sep 2003
Location: Uruguay
Posts: 3,103
|
Alain2: the video is TFF for sure and I even put an AssumeTFF() before the code snippet I posted. Alas, I upgraded to dgmpgdecv1.49b14 right before trying to load the scripts, whereas previous attempts used b13, so tritical is right on the money .
I patiently await for news, master .
__________________
Read Decomb's readmes and tutorials, the IVTC tutorial and the capture guide in order to learn about combing and how to deal with it. |
17th February 2007, 05:57 | #917 | Link | |
Angel of Night
Join Date: Nov 2004
Location: Tangled in the silks
Posts: 9,559
|
Quote:
Perhaps it's time to create a well-defined format and some smarter shareable parser code to go with it? (Not to be an xml-solves-all-things sort, but it would make the parsing easier. But then you'd have to include expat, meh.) |
|
17th February 2007, 22:26 | #919 | Link |
Registered User
Join Date: Dec 2003
Location: MO, US
Posts: 999
|
@ChiDragon
Could you post the entire script you were using that caused the crashes? I tried to reproduce with: blankclip(pixel_type="YV12",length=80304,fps_denominator=1001,fps=30000) tdecimate(ovr="ovr.txt") where ovr.txt had the single line you posted, but it doesn't crash for me. @foxyshadis Yeah, I thought it was quite funny that the very next version after I removed the check wouldn't work. However, adding support for new d2v format versions isn't actually much of a problem atm (it took only 4 lines of code to support v16). When you say create a well defined format and sharable parser code are you talking about creating a parser separate from tivtc and having it create a file that tfm could read instead of tfm parsing the d2v itself? |
18th February 2007, 16:50 | #920 | Link |
*Space Reserved*
Join Date: May 2006
Posts: 953
|
How are you guys actually using an ovr file with tdecimate? I'd try everything to specify a dropped frame or pattern, and it seems to be of no effect. The frame that i've specified to drop would still be there.
I'd use tfm with tdecimate sorta like this tfm(mode=4,pp=1,slow=2,flags=1,hint=true) tdecimate(mode=1,expp=true,ovr="C:\Myovr.txt") The "ovr" file would read something like this Code:
217 - |
Tags |
tdeint, tivtc |
Thread Tools | Search this Thread |
Display Modes | |
|
|