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. |
11th April 2006, 08:32 | #603 | Link |
Almost Silent Member
Join Date: Jun 2002
Location: Purgatory
Posts: 273
|
@malouf
Some things you could try are the functions mentioned previously in this thread using eedi2 in cunjunction with tdeint. If all else fails: I use FreezeFrame for issues where I know the frames that are consistently giving me problems (or rather giving the automated solution problems). Then again, I'm used to using YATTA and most people just aren't that masochistic. FreezeFrame would be used best after deinterlacing and before anything else. In bad game captures I would use it before the motion blur to replace the usual junk frames here and there with the previous or next frame. If it's a duplicate frame or static scene no one will ever know, but if it's a hard panning sequence it may introduce a stutter.
__________________
Rethinking the "Why?" chromosome. Last edited by DarkNite; 11th April 2006 at 08:56. |
11th April 2006, 09:06 | #604 | Link |
Registered User
Join Date: Sep 2004
Posts: 4
|
Hi,
I tried the method with eedi2 and tdeint, it produces the same artifacts at the same place... And for freezeframe, the problem is that I need to have something that works automatically on every video, I make lots of videos, and don't want to review them frame by frame to correct them :-( The ideal solution would be that tdeint, before deinterlacing, checks if the current interlaced frame is perfectly identical to the previous one. If it is identical, just output again the last progressive frame. I guess it wouldn't be difficult, but maybe I'm mistaken ? I can post a small part of one of the videos that has the problem, maybe it would be more clear? |
13th April 2006, 02:28 | #605 | Link |
Registered User
Join Date: Feb 2002
Location: California
Posts: 2,695
|
[See last line of post, if you don't have time to read all this].
I am getting occasional failures in the TFM v0.9.12.1 matching. I have tried every mode, each option for slow, and each option for micmatching. What happens is that the MICS parameters show, for example p=0, c=5, n=25, b=4, u=0 yet TFM chooses the current rather than the previous field. 99.9% of the matches are correct. Here is the script: Code:
converttoYUY2(interlaced=false) AssumeBFF() colorYUV(autogain=true) tfm(display=true,micout=2,mode=7,cthresh=115,mi=35,pp=1,field=0,metric=0,micmatching=3,slow=1,sco=-1,debug=false) Code:
[1568] TFM: mode 7 - non-linear access detected! [1568] TFM: frame 10693 - comparing c to p (SLOW 1) [1568] TFM: frame 10693 - nmatches: 547252 vs 827794 (1.5) mmatches: 106221 vs 128984 (1.2) [1568] TFM: frame 10693 - match c: Detected As NOT Combed! (6 <= 35) [1568] TFM: frame 10693 - match p: Detected As NOT Combed! (0 <= 35) [1568] TFM: frame 10693 - final match = c MIC = 6 [1568] TFM: frame 10693 - mics: p = 0 c = 6 n = 256 b = 256 u = 0 [1568] TFM: frame 10693 - mode = 7 field = 0 order = 0 d2vfilm = F [1568] TFM: frame 10693 - CLEAN FRAME [1568] TFM: mode 7 - non-linear access detected! [1568] TFM: frame 10704 - comparing c to p (SLOW 1) [1568] TFM: frame 10704 - nmatches: 1186349 vs 1009180 (1.2) mmatches: 583070 vs 500389 (1.2) [1568] TFM: frame 10704 - match c: Detected As NOT Combed! (10 <= 35) [1568] TFM: frame 10704 - match p: Detected As NOT Combed! (5 <= 35) [1568] TFM: frame 10704 - final match = p MIC = 5 [1568] TFM: frame 10704 - mics: p = 5 c = 10 n = 256 b = 256 u = 0 [1568] TFM: frame 10704 - mode = 7 field = 0 order = 0 d2vfilm = F [1568] TFM: frame 10704 - CLEAN FRAME ... I just took a break before posting and looked some more. I think that any time either c=0 or p=0, TFM makes the wrong choice. It is as simple as that. Let me know if this is correct. [Edit] Update a few minutes later. My input is NTSC DV (BFF). However, I tried changing field to field=1, and it seems to work better. So, field=0 and also field=-1 preceded by AssumBFF() both create the problem. Last edited by johnmeyer; 13th April 2006 at 02:51. |
13th April 2006, 09:34 | #606 | Link |
Registered User
Join Date: Dec 2003
Location: MO, US
Posts: 999
|
@malouf
The problem is that tdeint's motion check is only 5 fields, 2.5 frames, so if an interlaced frame is repeated one time the chance that interlaced areas will be declared static and weaved is high. If such a frame is repeated twice then it will definately be declared static. Having tdeint check for absolutely identical frames and consider all pixels to be moving would prevent the artifacts, but definitely wouldn't be good for normal operation. You could try using securedeint() which produces longer temporal masks (which should prevent the problem)... or you might be able to hack up a function in avisynth that checks difference to previous frame and if it is zero replaces the frame will all white (255), which should make it be detected as moving. @Fizick If someone wanted to help on the docs I definitely wouldn't say no . So far I have manged to convert most of the stuff for tivtc except for the two biggest readmes (tfm/tdecimate). @johnmeyer Would you be able to post a clip that I could test with? Your settings seem strange off hand... specifically mode 7 and cthresh=115. Also, the MIC values aren't normally used for selecting matches, but only for determining which frames are combed. The nmatch/mmatch numbers generated by the field matching routine are what determine which match is chosen (lower is better). With micmatching enabled the MIC's can override the match decision, but the 0 vs 6 difference in the first example isn't large enough to trigger it (with blockx/blocky=16 a difference of at least 15 between the selected match and the match with the lowest mic value is needed to even consider changing it). @All I found another little bug in eedi2 that could occasionally cause an access violation by reading/writing 8 bytes past the end of a buffer. The affected routine is only used if the input is yuy2 and the cpu supports sse2. I'll try to put up a fix sometime soon. |
13th April 2006, 18:13 | #607 | Link | |||
Registered User
Join Date: Feb 2002
Location: California
Posts: 2,695
|
Quote:
http://download.yousendit.com/16F3395A7B1B6689 Frame 9 is where the problem occurs. If you change the Field parameter from 0 (which is where I think it should be for NTSC DV) to 1, TFM works. Quote:
Quote:
I actually made a test DVD last night, and I almost have this working. I export the TFM parameters in pass one, import it to Excel, and use Excel formulas to look at the TFM values to create a decimate file. In pass 2, I feed that file to Multidecimate, and feed the almost-unaltered (after removing the CRC line -- thanks for that hint) pass-1 TFM parameters file back into TFM. In the second pass, I remove the "colorYUV(autogain=true)" line. Speaking of autogain, for anyone reading this thread, I found -- at least in my application -- that using autogain makes a HUGE improvement in the consistency of TFM's matching. Many of the movies I am transferring consist of poorly exposed, low contrast footage, and as the exposure and contrast changes, so do the TFM matching parameters. Using Autogain equalizes things sufficiently that I can use one script for the entire reel of film. In fact, the improvement is so good that I suggest that if there is a way to feed an autogain version of a clip to one instance of TFM, and then have the resulting parameters be used by a second instance of TFM to actually operate on the clip it might be a very worthwhile addition. This way it wouldn't require two passes (although my application will still require a second pass because I don't have a predictable "n of m" decimation pattern). In summary, now that I understand that MICmatching requires a bigger difference, I can try to deal with that, so I guess you don't need to look into that any further. However, I still think that there is something strange going on with the Field= parameter. I get all sorts of combing artifacts with Field=0, and none with Field=1, even though I am using a DV source. Finally, I have read your documentation 100 times, and read through every post in this thread, but I can't find the answer to this: What does "MIC" stand for? |
|||
16th April 2006, 00:42 | #608 | Link | ||
Registered User
Join Date: Jan 2006
Posts: 32
|
Hello, I'm trying to encode hyrid video to mkv-vfr using megui as an encoder, and Tivtc filter. But I'm having a problem using one pass method as you can check in this post:
http://forum.doom9.org/showthread.ph...055#post814055 I don't know the reason for this error message in megui, but using two pass method, i was able to open the script via megui!! in your read me: Quote:
from: http://www.avisynth.org/VariableFrameRateVideo Quote:
|
||
16th April 2006, 03:00 | #609 | Link |
Angel of Night
Join Date: Nov 2004
Location: Tangled in the silks
Posts: 9,559
|
You don't need nicefps (which is a separate plugin, see warpenterprises) starting with Avisynth 2.5.7 alpha. All that part does is extend the length of your newly decimated video to be exactly as long as your old video, so that all bitrate calcs are kept in sync, so yes, unless you want to do the algebra yourself every time (or use a quality-based encode), you do need that, whether 1 or 2 pass.
You can output mp4, but you still have to mux to mkv. But see the updated version of the guide for a few more options if you want to end up in mp4. 1-pass vfr can't be seeked into, and megui always seeks to the middle frame if you open the preview, so set it to not open the preview and you should be okay. Another problem is you can't really correct the bitrate skew in 1-pass mode, so you might have to go quality-based for that. |
16th April 2006, 14:13 | #610 | Link |
Angel of Night
Join Date: Nov 2004
Location: Tangled in the silks
Posts: 9,559
|
I'm just kind of curious, but what sort of improvements are in store for eedi? Anything I should wait around on, or just minor speed/quality tweaks? (I've been using it a lot lately on some too-small stuff, helps a lot.)
|
18th April 2006, 23:17 | #613 | Link |
Registered User
Join Date: Jun 2004
Posts: 144
|
I'm getting an error with TFM "Illegal Transitions found in dvd2avi file". It makes me a "fixed" file that still gives the error. 2 out of about 15 episodes have this issue, using identical settings.
edit: I think the fixed file is working after all. Last edited by swaaye; 19th April 2006 at 01:03. |
20th April 2006, 03:16 | #614 | Link |
Registered User
Join Date: Dec 2003
Location: MO, US
Posts: 999
|
First, sorry for the lack of responses... I've got a big project due in two weeks and I'm having to spend insane amounts of time on it.
@swaaye It appears your problem was fixed? If you do have a d2v file that tfm generates a fixed version of and then says something is wrong with the fixed version could you post it somewhere? @Fizick Yep, I know that tdeint/tivtc html docs already exist.. I've been using those as the basis for the new ones (updating, rewriting, and layout changes). @foxyshadis The main changes are to making it more stable with larger search areas (new default for maxd will be 24) and better at connecting lines with very small slopes. I've changed some hard thresholds to relative thresholds based on the angle direction and added an extra gap/hole filling routine to the edge map filtering and directon map filtering. Due to the new defaults and extra processing it is a little bit slower. @johnmeyer I'll try to look at the clip tommorrow though it sounds like you've found a method to accomplish what you need. The problems you have with the field parameter may be related to using mode 7 in tfm. In mode 7 tfm internally switches the field parameter between 0/1 (it starts out on the initially set value) based on combed frame detections to try and follow a specific pattern found in some field blended material. In almost all other cases you want to always match of the same field to maintain smoothness. Try using matching mode 0 or 1 and setting field=0 and then field=1. I guess MIC stands for "max (or maximum) interlacing count". Originally, tfm never kept track of the "MIC" value it just checked to see if any of the blocks in the image produced counts over MI. When I decided to start keeping track of the values I just added C onto MI to get MIC for a new variable name. |
20th April 2006, 15:35 | #615 | Link |
Registered User
Join Date: Feb 2002
Location: California
Posts: 2,695
|
I gave up on mode 7 shortly after my post and have been using mode 0. Still haven't been able to get reliable detection in low motion areas. However, I am now trying to create my own decimation routine that uses a form of guidance that is based on my unusual application. I'll post back here when I've either got it working, or have another question.
|
29th April 2006, 21:16 | #616 | Link |
Registered User
Join Date: Jan 2006
Posts: 17
|
Tritical:
I'm sorry to bother you, but I've noticed a weird output bug with tdecimate. Sometimes it simply refuses to write out the stats using mode=4 and specifying an output file. I run the pass to collect the stats, the file is created, but it stays blank. Any notion what I might be doing wrong? |
29th April 2006, 21:20 | #617 | Link |
Angel of Night
Join Date: Nov 2004
Location: Tangled in the silks
Posts: 9,559
|
The file won't be flushed until virtualdub (or whatever is running the pass) is closed. Closing the video with ctrl-W and reopening off the recent menu is what I always do. Must have the biggest buffer in the world or something...
|
29th April 2006, 22:55 | #618 | Link |
Registered User
Join Date: May 2002
Posts: 220
|
TDecimate request: exclusion band of lines (y0/y1) as in TFM.
TDecimate request: exclusion band of lines (y0/y1) as in TFM.
Hi Tritical, This is a humble request: I regularly do NTSC analog TV captures that are telecined material broadcasted with the original audio and the subtitles (interlaced!) with the translation blended on top of the telecined material. The exclusion band of lines (y0/y1) for TFM has allowed me to successfully match the fields correctly. This is great! But the subtitles are still causing me problems with TDecimate: After using TFM, the telecined material is correctly matched, but almost every frame where each subtitle starts or ends (only the first and last frames where the subtitle appears) is detected as combed because of the subtitles. These “combed” frames (2 on each subtitle, with 2000+ subs gives more than 4000! on a 20 minutes capture) interfere with TDecimate metrics calculation resulting in the wrong frames being deleted, and if hybrid > 0 with unnecessary 30p to 24p frame blending processing. I have also tried setting PP=0 and hints=false, but the metrics calculation on TDecimate gets confused by the subtitles, particularly if the subtitles starts or ends exactly on a duplicated frame (the ones that should be decimated). Last night I discovered “MergeHints” on your TIVTC package, which allowed me to get better results by excluding from the TFM hints generation the lines where the subtitles are, using this AVIsynth script: (704x480 yv12 material) Code:
Save_Hints=crop(128,64,480,288,align=true).Tfm(order=1, mode=0, PP=0) Tfm(order=1, mode=0, y0=352, y1=448, PP=6, Hint=FALSE, opt=3) #, display=true) MergeHints(hintClip=Save_Hints) TDecimate(Hint=true, opt=3, hybrid=0) #, display=true) I hope you’re doing well with your project, and I’d like to thank you for the time and energy you devote to this filters you give us all. Regards, JuanC |
30th April 2006, 22:57 | #619 | Link |
Registered User
Join Date: Apr 2006
Posts: 13
|
I've a question concerning the speed. I use these settings for VDub to convert my captured movies into Xvid
Code:
LoadPlugin("c:\avisynth\dgmpgdec146b2\DGDecode.dll") audio=MPASource("c:\Charmed.-.S03E04 T01 DELAY 96ms.mpa") video=MPEG2Source("c:\Charmed.-.S03E04.d2v") video=TDeint(video,order=1).lanczos4resize(720,540) AudioDub(video,audio) The quality is really great but I'm not so happy with the perfomance as it dropped by 50% from 30fps to about 16fps. Ist this loss normal or are there any improvements possible? so long |
1st May 2006, 10:00 | #620 | Link |
brainless
Join Date: Mar 2003
Location: Germany
Posts: 3,653
|
every filter has an impact on encoding speed.
so will tdeint. and 16fps still are a reasonable good speed. So it seems you never got into the range of spf for your encoding speeds (spf == seconds per Frame)
__________________
Don't forget the 'c'! Don't PM me for technical support, please. |
Tags |
tdeint, tivtc |
|
|