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 13th June 2006, 06:51   #661  |  Link
tritical
Registered User
 
Join Date: Dec 2003
Location: MO, US
Posts: 999
@johnmeyer
I'm glad that tfm is useful for your project. If you need any other info just ask .

@All
Going back to the eedi2 discussion... one of things I've noticed is that when chaining multiple calls together for resizing sometimes changing the order of the turn() calls can make a very large difference in line reconstruction. For example, the lena image again, but this time using:

turnleft().eedi2().turnright().eedi2()

as opposed to:

eedi2().turnleft().eedi2().turnright()

which is what I used to generate the one in the previous post. In this image, I've stacked the two images side by side and tried to highlight a few of the major areas of improvement. Notice that most of the areas are edges/lines of >= 45 degrees.

After thinking about it, the reasons for the improvement are pretty simple. First, the vector matching method currently used to detect directions has only single pel accuracy up to the previous and next scan lines. So the angle directions drop off very fast at first (90 at 0 steps, 45 at 1 step, 27 at 2 steps, etc...). This leads to poor accuracy when dealing with edges that have angles of >= 45 degrees. Second, the interpolation of the new pixels is limited to half pel precision at the previous and next lines.. so basically all edges/lines with an angle of >= 45 degrees will be lumped into 3 possible output pixel values. What happens when you rotate the image 90 degrees is that the lines/edges that were previously in the 45-90 degree grouping are now in the 0-45 degree range where the accuracy of angle detection and interpolation are much improved.

I think the most obvious solution is when initially calculating directions to do one pass horizontally (to get <= 45 degree lines/edges) as is done now, and then to do another pass vertically (to get >= 45 lines/edges). Also, when doing the final interpolation, directions of > 45 degrees should use pixels from lines further away than just the prev/next lines in order to get improved accuracy. Of course, there are some fine details to work out, but it shouldn't be too hard to implement. Hopefully this improvement will make it into the next version along with the one step, general resize method. The downside is that this improvement will slow things down to ~3/4 to 1/2 the current speed.
tritical is offline   Reply With Quote
Old 13th June 2006, 18:40   #662  |  Link
scharfis_brain
brainless
 
scharfis_brain's Avatar
 
Join Date: Mar 2003
Location: Germany
Posts: 3,653
The newest version of eedi2:


The predecessor of the current version:


I used maxd=12 and pp=0 as you suggested.
__________________
Don't forget the 'c'!

Don't PM me for technical support, please.
scharfis_brain is offline   Reply With Quote
Old 21st June 2006, 01:01   #663  |  Link
tritical
Registered User
 
Join Date: Dec 2003
Location: MO, US
Posts: 999
The difference is most likely because of the extra filtering step I added to the direction map post-processing. Any way I could get the original clip from you?
tritical is offline   Reply With Quote
Old 21st June 2006, 07:45   #664  |  Link
scharfis_brain
brainless
 
scharfis_brain's Avatar
 
Join Date: Mar 2003
Location: Germany
Posts: 3,653
this is the original clip.
http://rapidshare.de/files/23657792/doom9.avi.html

it is pretty good evaluating interpolation algorithms and motion/comb masks
__________________
Don't forget the 'c'!

Don't PM me for technical support, please.
scharfis_brain is offline   Reply With Quote
Old 27th July 2006, 00:25   #665  |  Link
tritical
Registered User
 
Join Date: Dec 2003
Location: MO, US
Posts: 999
[link removed], changes:
Code:
tfm:
   - fixed crash in modes 0/4 when pp=0 and micout > 0
   - fixed "possible missed combed frames" listing in ovr help information sometimes 
       including frames that were marked combed via an ovr file

tdecimate:
   + set fps to average value of the clip in mode 5 (so duration stays the same)
   + use 6 decimal places in v2 tc output
I had planned to include a lot more in this release, but I just haven't had the time to do much lately. Things that will eventually get added (as I have promised in various places):

1.) exclusion band in tdecimate+framediff
2.) exclusion band for combed frame detection in tfm+is/showcombedtivtc
3.) option to require 'x' number of blocks above MI for combed frame detection in tfm+is/showcombedtivtc
4.) pp option in tfm that would try to replace combed frames with clean neighbor frames if available

Last edited by tritical; 4th October 2006 at 07:04.
tritical is offline   Reply With Quote
Old 27th July 2006, 03:38   #666  |  Link
JuanC
Registered User
 
Join Date: May 2002
Posts: 220
wow! that's great!

And the features you're announcing will make it even greater !

Thanks again
JuanC is offline   Reply With Quote
Old 27th July 2006, 05:50   #667  |  Link
anonymez
Registered User
 
Join Date: Jun 2006
Posts: 54
thanks a bunch tritical!

ps has to be said: tdeint is well past RC stages, make it 1.0 final already!
anonymez is offline   Reply With Quote
Old 27th July 2006, 06:57   #668  |  Link
tritical
Registered User
 
Join Date: Dec 2003
Location: MO, US
Posts: 999
@All
I also updated the avi_tc_package to v1.4. The main changes were:

1.) added avs output option to cfr2tc. The avs file will exactly duplicate the avi file you would get if you ran cfr2tc with avi output. Bascially, it generates a bunch of trim().selectevery().assumefps() lines and then appends the clips together. This eliminates the need to create a new avi file.
2.) added tcConv... it does v1<->v2 conversions.
3.) updated tc-GUI to match.

@anonymez
Yeah, it is pretty much done... though I still have plans to make the field matching and combed frame detection in tdeint exactly the same (working and parameter wise) as tfm. Currently, the field matching in tdeint is equivalent to slow=0+mchroma=true in tfm. The combed frame detection is the same as tfm's atm, but the new options I am going to add to tfm should get added to tdeint as well. At some point it might just be worth it to combine tdeint/tivtc into one.

The main reason I would like to have the improved field matching modes of tfm in tdeint is because it's used in mode 2, which I pretty much use all the time. My usual script these days for anime ivtc is:

mpeg2source("")
inter = separatefields().eedi2(field=-2)
deint = tdeint(mode=2,edeint=inter)
tfm(d2v="",clip2=deint,MI=60)
tdecimate(mode=4+5)

Last edited by tritical; 27th July 2006 at 06:59.
tritical is offline   Reply With Quote
Old 27th July 2006, 07:31   #669  |  Link
foxyshadis
ангел смерти
 
foxyshadis's Avatar
 
Join Date: Nov 2004
Location: Lost
Posts: 9,558
Quote:
Originally Posted by tritical
@All
I also updated the avi_tc_package to v1.4. The main changes were:

1.) added avs output option to cfr2tc. The avs file will exactly duplicate the avi file you would get if you ran cfr2tc with avi output. Bascially, it generates a bunch of trim().selectevery().assumefps() lines and then appends the clips together. This eliminates the need to create a new avi file.
Sweet.
Quote:
Originally Posted by tritical
2.) added tcConv... it does v1<->v2 conversions.
Very sweet. Does it attempt to use standard framerates, if they're close enough?
foxyshadis is offline   Reply With Quote
Old 27th July 2006, 09:07   #670  |  Link
tritical
Registered User
 
Join Date: Dec 2003
Location: MO, US
Posts: 999
No, it doesn't. To get the framerates for v2->v1 it just averages over the duration of the current range... which will get pretty close usually. Afaict, this is exactly what mkv2vfr does, since in my tests converting the v2 output of mkvextract to v1 resulted in fps numbers that matched mkv2vfr's output.
tritical is offline   Reply With Quote
Old 29th July 2006, 06:40   #671  |  Link
Chainmax
Huh?
 
Chainmax's Avatar
 
Join Date: Sep 2003
Location: Uruguay
Posts: 3,103
Quote:
Originally Posted by tritical
...
tdecimate(mode=4+5)
How is that possible? It's probably a typo, right?
__________________
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 29th July 2006, 07:28   #672  |  Link
foxyshadis
ангел смерти
 
foxyshadis's Avatar
 
Join Date: Nov 2004
Location: Lost
Posts: 9,558
Just shorthard for carrying out the full mode 4 and mode 5 translations.

Certainly, it would be interesting to have a mode 9 to do it all, like decombvfr, if only for those generated scripts that don't need to be tweaked... but if we did that we'd have to document that the mode 8 that you seek is not among these modes...
foxyshadis is offline   Reply With Quote
Old 30th July 2006, 01:31   #673  |  Link
Isochroma
Registered User
 
Join Date: Mar 2005
Posts: 468
I seem to be having some difficulty with tc2cfr. I have an avi file of fps 23.976 which I would like to convert to one with a framerate of 119.880 by inserting null frames at the appropriate intervals. However, tc2cfr wants a timecode file.

It seems according to the documentation that this program will take an avi and add null frames, producing a timecode file in addition. What should I do?
Isochroma is offline   Reply With Quote
Old 30th July 2006, 02:51   #674  |  Link
foxyshadis
ангел смерти
 
foxyshadis's Avatar
 
Join Date: Nov 2004
Location: Lost
Posts: 9,558
Use this as the timecode file:

# timecode format v1
Assume 23.967

Alternately you can just use vdub, which can do 24 or 30->120 in the same way. (But no hybrid, obviously, and you can't automate it.)
foxyshadis is offline   Reply With Quote
Old 30th July 2006, 03:42   #675  |  Link
Isochroma
Registered User
 
Join Date: Mar 2005
Posts: 468
Thanks! But I found AVI60, this nice Japanese program to convert various framerate AVIs to 119.880. It works quite nicely, though it's all in Japanese.

Really, someone should make a simple tool that doesn't require in-depth knowledge of obscure file formats. Just something that adds a certain number of null frames to an AVI and doesn't require anything else to do its job.

More than what is needed; less than what is required.
Isochroma is offline   Reply With Quote
Old 31st July 2006, 02:10   #676  |  Link
tritical
Registered User
 
Join Date: Dec 2003
Location: MO, US
Posts: 999
I could make it use the default framerate of the input avi if no timecode file is given, but what is the point of making a 120fps avi out of a source that is all one framerate to begin with?
tritical is offline   Reply With Quote
Old 31st July 2006, 03:32   #677  |  Link
Isochroma
Registered User
 
Join Date: Mar 2005
Posts: 468
Because I have 3 source files:

#1: 23.976 fps
#2: 29.970 fps
#3: 23.976 fps

They must be merged sequentially. Therefore, they are all first converted to 119.880 fps, then #1 is opened in vdub, then the other two are appended and the resulting file saved as the complete. In direct stream copy mode, the null frames inserted by AVI60 are preserved in the final output AVI.

Next, your cfr2tc app is used with the complete AVI as source. It removes all null frames and generates a v2 timecode file and an AVI with null frames removed.

Finally, the AVI and timecodes file are muxed into a MKV via cmdline (note: the manual and cmdline parameters explanation for MKVMerge does not provide any information on the --timecodes "x:name" function; also undocumented is that despite x used to identify which media track the timecode file applies to, the --timecodes "x:name" string must be preceding the track it applies to, with no other tracks in between.

I found out that if it is listed after, the resulting file will not use the timecodes. Slightly offtopic, but despite its many revisions, MKVtoolnix remains sorely lacking in frontend support for timecode files, both in the GUI (no support or documentation) and the cmdline (support but limited documentation).

Your applications and their GUI are useful as well on another point: AVI60 is both impossible to understand due to Japanese labels and documentation, and has a minor defect: the AVI files produced have a trivial structural corruption that prevents their use in your applications. The manifestation of it is that at the end of processing with cfr2tc an error will be reported. The problem is solved by direct stream copy with vdub; the resulting file is slightly different in size (indicating structural change) but has the same number of frames. And being produced by vdub, of course it works with all apps, including yours. Thankfully vdub preserves null frames in direct stream copy mode as well.

Finally, AVI60 has very limited convert-to options - 60 and 119.880 fps only. The cmdline seems to have other options, but I cannot read Japanese. Your apps have an excellent method of framerate input - the native ratio x/y used in the AVI file structure. Thus they are the natural successors to AVI60 provided they can fully emulate AVI60's functionality.

Last edited by Isochroma; 31st July 2006 at 05:38.
Isochroma is offline   Reply With Quote
Old 31st July 2006, 05:26   #678  |  Link
foxyshadis
ангел смерти
 
foxyshadis's Avatar
 
Join Date: Nov 2004
Location: Lost
Posts: 9,558
You know, if you're going to mkv anyway you can just add the first and append the rest into mkvmerge and it'll apply their respective timestamps to the resultant mkv. I just tested to be sure and it worked great.

You also did a good job of highlighting exactly why I asked for avi_tc, if you go back in the avisynth VFR page's history you'll see the rather insane procedure that existed for making 120 fps avis with avi60.
foxyshadis is offline   Reply With Quote
Old 31st July 2006, 05:36   #679  |  Link
Isochroma
Registered User
 
Join Date: Mar 2005
Posts: 468
Yes, you're correct. However using that method is pretty crude and doesn't present the kind of usefulness that vdub or other vfw applications do.

The idea is to get all avi files to the same framerate via insertion of null frames, so they may be edited/joined/subbed together. Long mkvmerge commandlines just don't do it for me, if you know what I mean
Isochroma is offline   Reply With Quote
Old 31st July 2006, 14:59   #680  |  Link
Haali
Registered User
 
Join Date: Jul 2003
Posts: 282
mkvmerge discards null frames automatically, if you mux a 120fps avi directly to mkv, you get a vfr file in one step.
Haali 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 18:07.


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