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.

 

Go Back   Doom9's Forum > Capturing and Editing Video > Avisynth Development

Reply
 
Thread Tools Search this Thread Display Modes
Old 31st July 2006, 17:06   #681  |  Link
Isochroma
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
Isochroma is offline   Reply With Quote
Old 31st July 2006, 23:43   #682  |  Link
foxyshadis
ангел смерти
 
foxyshadis's Avatar
 
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.
foxyshadis is offline   Reply With Quote
Old 3rd August 2006, 05:30   #683  |  Link
tritical
Registered User
 
Join Date: Dec 2003
Location: MO, US
Posts: 999
I added the ability to simply specifiy an input fps value instead of using a timecode file in tc2cfr. I updated tc-GUI as well.
tritical is offline   Reply With Quote
Old 3rd August 2006, 05:59   #684  |  Link
Isochroma
Registered User
 
Join Date: Mar 2005
Posts: 468
Thanks! You now have my gratitude & thanks x 2...
Isochroma is offline   Reply With Quote
Old 4th August 2006, 01:14   #685  |  Link
Mug Funky
interlace this!
 
Mug Funky's Avatar
 
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
Mug Funky is offline   Reply With Quote
Old 4th August 2006, 03:15   #686  |  Link
tritical
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?
tritical is offline   Reply With Quote
Old 4th August 2006, 09:02   #687  |  Link
Velocity 7
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")
Here's another example video which TFM is having trouble with.

Last edited by Velocity 7; 4th August 2006 at 19:27.
Velocity 7 is offline   Reply With Quote
Old 6th August 2006, 02:54   #688  |  Link
puffpio
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.
puffpio is offline   Reply With Quote
Old 6th August 2006, 05:14   #689  |  Link
tritical
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.
tritical is offline   Reply With Quote
Old 6th August 2006, 05:37   #690  |  Link
puffpio
Registered User
 
Join Date: Nov 2001
Posts: 176
there's always more than one way to solve a problem..got some good help in the other forum tackling the problem in different ways :P
puffpio is offline   Reply With Quote
Old 16th August 2006, 02:45   #691  |  Link
tritical
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.
tritical is offline   Reply With Quote
Old 23rd August 2006, 00:04   #692  |  Link
ChiDragon
Registered User
 
ChiDragon's Avatar
 
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)
This obviously won't work for TFM with a d2v input though. It would also be easier and look cleaner to just have a parameter to set instead of adding and trimming video, of course.

Thanks for your time and for making such a great combination of filters, I use TIVTC and TDeint all the time!
ChiDragon is offline   Reply With Quote
Old 25th August 2006, 06:45   #693  |  Link
CruNcher
Registered User
 
CruNcher's Avatar
 
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
CruNcher is offline   Reply With Quote
Old 28th August 2006, 23:07   #694  |  Link
tritical
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?
tritical is offline   Reply With Quote
Old 16th September 2006, 17:04   #695  |  Link
Carpo
Registered User
 
Carpo's Avatar
 
Join Date: Dec 2002
Location: /dev/null
Posts: 1,368
nevermind problem has been sorted
__________________
The Internet: where men are men, women are men, and children are FBI Agents

Last edited by Carpo; 17th September 2006 at 13:08.
Carpo is offline   Reply With Quote
Old 19th September 2006, 09:32   #696  |  Link
rig_veda
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?
rig_veda is offline   Reply With Quote
Old 20th September 2006, 04:32   #697  |  Link
Mug Funky
interlace this!
 
Mug Funky's Avatar
 
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
Mug Funky is offline   Reply With Quote
Old 20th September 2006, 07:59   #698  |  Link
tritical
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.
tritical is offline   Reply With Quote
Old 26th September 2006, 19:01   #699  |  Link
Chainmax
Huh?
 
Chainmax's Avatar
 
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.
Chainmax is offline   Reply With Quote
Old 3rd October 2006, 21:14   #700  |  Link
tritical
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.
tritical is offline   Reply With Quote
Reply

Tags
tdeint, tivtc

Thread Tools Search this Thread
Search this Thread:

Advanced Search
Display Modes

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off

Forum Jump


All times are GMT +1. The time now is 19:13.


Powered by vBulletin® Version 3.8.11
Copyright ©2000 - 2024, vBulletin Solutions Inc.