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. |
31st July 2006, 17:06 | #681 | Link |
Registered User
Join Date: Mar 2005
Posts: 468
|
Ah! Thanks for the info, Haali. There are good reasons to generate a file with null frames first, though. Editing in VFW apps is just one of them...
Was playing around with a lowest common denominator calculator today and noted that it would be practically impossible to insert enough null frames in a 25fps PAL AVI to get it to LCD with a 29.97fps one (5272378157511475 fps required!). But it seems that with a 0.1% speedup to 30fps, the 29.97fps clip can be made compatible with everything |
31st July 2006, 23:43 | #682 | Link |
ангел смерти
Join Date: Nov 2004
Location: Lost
Posts: 9,558
|
No, the LCM of 25 and 29.97 is still 150fps - realistically, does 1/1000 of a second judder bother anyone? Cameras aren't even that precise. Although a 0.1% desync doesn't sound like a lot, after 30 minutes you already have a 2 second difference.
It's fairly easy to just switch the framerates and resave in vdub, using direct stream copy, compared to AVI60, and you have more choices as well. |
4th August 2006, 01:14 | #685 | Link |
interlace this!
Join Date: Jun 2003
Location: i'm in ur transfers, addin noise
Posts: 4,555
|
yo, to shift the thread in a slightly different direction, i noticed that tdeint(mode=2) doesn't seem to support yuy2. no biggie, as i can either use mode 1 or just switch to tivtc.
also, tryweave and emask don't appear to get along with each other. also no biggie - i was planning to use this but ditched it in favour of another method. but thought you'd like to know regardless.
__________________
sucking the life out of your videos since 2004 |
4th August 2006, 03:15 | #686 | Link |
Registered User
Join Date: Dec 2003
Location: MO, US
Posts: 999
|
mode 2 should support yuy2 just fine, but there was a little typo causing it to mess up and throw an error. I'll try to put up a fixed version tommorrow. Also, what do you mean by tryweave and emask don't get along?
|
4th August 2006, 09:02 | #687 | Link |
Registered User
Join Date: May 2003
Posts: 88
|
I'm having trouble using TFM on this particular video. A few of the frames are not getting matched up properly; the low motion seems to be screwing up combing, especially near the end of this panning sequence.
Script I'm using at the moment: Code:
LoadPlugin("TIVTC.dll") LoadPlugin("mpeg2dec3dg.dll") MPEG2Source("haruhiep2_3.d2v") TFM(mode=5, pp=5, d2v="haruhiep2_3.d2v") Last edited by Velocity 7; 4th August 2006 at 19:27. |
6th August 2006, 02:54 | #688 | Link |
Registered User
Join Date: Nov 2001
Posts: 176
|
Hello..
I've used your plugins for awhile now and they always do the job. However I have clip now that I cant solve It's 60 fps progressive HD clip there are two types of video inside 1) 24fps video that has duplicated frames to 60fps in a 'aabbb' pattern 2) 60fps pure video with no duplicated frame Using TDecimate(mode=1, cycleR=3) I can remove the duplicate frames from #1 segments..but the pure 60 fps video then comes out jerky...there is a hybrid parameter, but that is only when cycleR=1, so I can't blend the 60fps to 24fps.. Im gonna expierment with mode 2 and 7...currently on a mode 4 stats generation pass... any ideas? Last edited by puffpio; 6th August 2006 at 03:30. |
6th August 2006, 05:14 | #689 | Link |
Registered User
Join Date: Dec 2003
Location: MO, US
Posts: 999
|
@Velocity 7
Thanks for the clips. I'll do some testing and see if I can get tfm to match them correctly. @puffpio Currently, tdecimate doesn't have any way to do what you want automatically. It is designed around 24/30 mixtures. Its hybrid operation could be extended to cases where cycleR != 1, but it would require significant changes that I don't really have time to make atm. |
16th August 2006, 02:45 | #691 | Link |
Registered User
Join Date: Dec 2003
Location: MO, US
Posts: 999
|
If the clip2 processing is really slow, you could probably get away with using it on only the final pass without any problems. The only thing that could happen is that the difference metrics calculated by tdecimate happen to be changed enough by the pping difference that tdecimate decides to decimate a different frame or switches its decision about video/film for a certain section. Even if that did happen I don't think it would noticable.
|
23rd August 2006, 00:04 | #692 | Link |
Registered User
Join Date: Sep 2005
Location: Vancouver
Posts: 600
|
TIVTC request
tritical:
Would it be possible to add an option to disable the CRC check for input files? I use output and input files in combination with black overlays as a way to IVTC without having moving channel bugs and bumpers interfere with the proper pattern. I know it's possible to work around the check by deleting the CRC from the metrics file, but that means I can't do batch processing. As a workaround for batching, I've used this sort of thing in both the analysis script and the encode script: Code:
BlankClip(last,length=20)++last TDecimate() Trim(16,0) Thanks for your time and for making such a great combination of filters, I use TIVTC and TDeint all the time! |
25th August 2006, 06:45 | #693 | Link |
Registered User
Join Date: Apr 2002
Location: Germany
Posts: 4,926
|
@tritical
can blends like this get better in future versions ?
__________________
all my compares are riddles so please try to decipher them yourselves :) It is about Time Join the Revolution NOW before it is to Late ! http://forum.doom9.org/showthread.php?t=168004 |
28th August 2006, 23:07 | #694 | Link |
Registered User
Join Date: Dec 2003
Location: MO, US
Posts: 999
|
@ChiDragon
Yep, I can do that. @CruNcher Probably not. Do a separatefields() on that image and you'll see that the individual fields that make up that frame are actually interlaced. Where did that image come from? |
19th September 2006, 09:32 | #696 | Link |
Registered User
Join Date: Aug 2005
Posts: 20
|
I noticed, that when producing VFR with a TDecimate override of for example
0,2729 v 2730,45863 f my script produced a timecode that went like: # timecode format v1 Assume 29.970030 2730,19145,23.976024 19146,19148,17.982018 19149,31912,23.976024 31913,31915,17.982018 31916,37234,23.976024 Now i got curious what internally happens to make it so. Why those sections of 3 frames each that use a fps of exactly 17.982018? Why is it always 3 frames and exactly 17.982018 fps and why isn't the output just plain 23.976024 fps for the whole part markt in the override file as film. I'm assuming it's to keep things in sync, but how does it work behind the scene? And are these 17.982018 fps sections distributed by chance or do they have a reason to appear exactly where they occur? |
20th September 2006, 04:32 | #697 | Link |
interlace this!
Join Date: Jun 2003
Location: i'm in ur transfers, addin noise
Posts: 4,555
|
you'll get that from a 3-in-5 decimation of 29.97fps...
i suppose you've got anime there, and there's some characters moving once every few frames, a few of which happen to fall on the interlaced part of the 3:2 cycle...
__________________
sucking the life out of your videos since 2004 |
20th September 2006, 07:59 | #698 | Link |
Registered User
Join Date: Dec 2003
Location: MO, US
Posts: 999
|
The 17 fps parts are from when tdecimate detects an ivtc pattern change that results in 2 duplicates in the current 5 frame cycle that it is looking at. For example:
nndnn nndnd nnnnd n = new d = dup Is one possible scenario that could occur due to a pattern change. IIRC, the specific things tdecimate looks for when trying to detect this and mode=0 (or mode 5 with vfrdec=0) are: 1.) previous cycle has exactly 1 dup (indicated by matches by tfm and that frame has the lowest difference metric in the cycle) 2.) next cycle has exactly 1 dup (same requirements as previous cycle) 3.) current cycle has exactly two dups (indicated by matches by tfm and those two frames have the two lowest difference metrics in the cycle) 4.) the dups in the current cycle are not directly next to eachother 4.) the position of the first dup in the current cycle equals the position of the dup from the first cycle 5.) the position of the second dup in the current cycle equals the position of the dup from the next cycle for mode = 1 (or mode 5 with vfrdec=1) those same requirements apply plus a check that none of the frames surrounding the two match duplicates in the current cycle, or any other frames in the current cycle besides the two match duplicates, had metrics < dupthresh (i.e. were detected as metric duplicates). Last edited by tritical; 20th September 2006 at 08:11. |
26th September 2006, 19:01 | #699 | Link |
Huh?
Join Date: Sep 2003
Location: Uruguay
Posts: 3,103
|
I have a bad NTSC-to-PAL conversion that needs reverting to NTSC in order to regain motion smoothness in some slowed-down scenes that look horrible. In order to do that, the source will be bobbed and then decimated. What would be the difference between using TDecimate(cycleR=2003,cycle=5000) and TDecimate(mode=7,rate=29.97) on it?
__________________
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. |
3rd October 2006, 21:14 | #700 | Link |
Registered User
Join Date: Dec 2003
Location: MO, US
Posts: 999
|
TDecimate(cycleR=2003,cycle=5000)
This one will actually break the clip up into sections of 5000, get a difference metric for all frames in a section, and then determine which frames in the section to remove. TDecimate(mode=7,rate=29.97) This one doesn't work on sections. It calculates an offset into the stream based on the decimation factor and then based on the difference metrics of a few surrounding frames and how the previous frames that were processed up to that point were decimated, decides whether to keep the frame or not. So this one wont have to sit there for long periods processing chunks of 5000 frames, it also will request all frames in linear order. I would say that if your clip actually has a strict cycle (i.e. the number of dups in every 5000 is evenly spread and doesn't' vary) then mode 0 would be better than mode 7. |
Tags |
tdeint, tivtc |
Thread Tools | Search this Thread |
Display Modes | |
|
|