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 February 2005, 14:01 | #181 | Link |
Moderator
Join Date: Oct 2001
Location: Hawaii
Posts: 7,406
|
Hi-
Although this is getting farther and farther off topic (I'm sorry, tritical), I have to agree with rawr. Although Restore24 does a decent job with field blended 25->30fps, I find it pretty much useless for field blended 24->30fps. I'm wrestling with one at the moment. I also believe that locking onto the pattern is the way to go, something like scharfi's UnblendPattern, but with pattern change detection. If you're really anal about this video, rarw, and have hours and hours to kill, you might try it. |
17th February 2005, 01:31 | #182 | Link |
Registered User
Join Date: Jan 2005
Location: UK
Posts: 18
|
To return slightly on topic, TFM() actually comes darn close to doing everything I need. Has all the interface I need (2-pass, first to editable plaintext, avs pattern overrides, smart matching... etcetcetc) problem is it doesn't acknowledge that fields exist, nor that you can do anything other than four weaves and one decimate in a cycle.
As this is anime, I actually have a lot of identical frames in a row, problem is you get reasonably noticable jitter between the weave and the tdeint frames. Doesn't matter for pans, but can be distracting on still frames. ATM I'm using Dup() with blend on - main problem is that even denoised there's a fair difference between weave and bob frames, compared to some teeny mouth movements, so hitting the 'right' frames to blend can be tough. Having a kill-this-frame, use-next-instead (or previous) is probably the last sensible thing I can do with this. With a few other minor tweeks an field matched encoded version of that clip is on the lamehost - I upped the vertical res so the bob/weave matching problem is more obvious. Work on a 'use this pattern for this range' function is pretty well set, bar annoynaces with the ChangeFPS() bug - adding blank space to the start isn't a good solution for offsets. Main problems are I *still* want to do this two pass, and avs just doesn't want me to read from file. I might have to try to compile some dll that just does some fileread function wrapping. rawr. |
17th February 2005, 04:28 | #183 | Link | |
Registered User
Join Date: Dec 2003
Location: MO, US
Posts: 999
|
Quote:
On a side note, the next version of tivtc is just about ready. Fixed the d2v fixing stuff (it is currently broken for non 100% 3:2 pulldown films), and added d2v support for the new dgindex project files (v7 and v8). The d2v option now also uses the rff flags to help detect duplicates in tdecimate and identify 24p sections when doing hybrid detection. Most similar decimation in tdecimate now takes duplicate via matches info into account as well. Wont be getting to mode 2 of tdecimate in this release though... |
|
17th February 2005, 15:46 | #184 | Link |
Registered User
Join Date: Jan 2005
Location: UK
Posts: 18
|
Oh, my main problem with it is probably that I have a very specific thing I want to do, and this isn't really set up for it. The standard run gave 4/4 blended fields, and my attempts with overrides just lead to confusing the idiot decimate even more. I can't override the decimate... or can I? Either way, I just have no idea how to apply TFM() to my problem - I've provided the vob if you care to try. It worries me that I can't even get the override to produce blank (unprocessed output), no decimate at all.
So, anyway, my main concerns are: It's not set up for following a set pattern at all - this means it misses small problems when it shouldn't need to. I can't control what frame will get dropped, nor have I succeeded in getting the override to actually match the right fields. There's no 'this frame is bad, but similar to the next - use that instead' facility as far as I can see. At any rate, I could probably set up a clip2 that would have the right field to TDeint and replace when there's a blend, but TFM doesn't seem to like the idea of finding duplicates and using the better option, which is my other aim. Trying to map my current system to yours, I think this is right: Code:
TFF Z|ZA A|AB B|B BC|C CD|D 0]1 [2]3 [45] 6[7] 8[9 P- C+ C- C+ (U-) rawr. [Edit: Using (U-) rather than (P+) should make it easy for the decimate maybe...] Last edited by rawr; 17th February 2005 at 15:50. |
17th February 2005, 19:52 | #185 | Link | |
Registered User
Join Date: Dec 2003
Location: MO, US
Posts: 999
|
Yeah, most of that is too specific as far as functionality goes. However, you can override tdecimate's decisions using an overrides file and can specify a decimation pattern to be used over a specific range of frames, but it works off frame numbers only, so you wouldn't be able to set it up too look for a specific match such as U- to drop. You would have to identify the pattern and any pattern changes within the file.
For copying the next or previous frame instead of using the current that will never be a feature of tfm because trying to have it work automatically would create about 5000x more problems then it would fix. You could however use stickboy's remap frames filter, or something similar, after tfm and before tdecimate and specify the copying/replacing manually. Quote:
Anyways, in the end tfm is, as you pointed out before, not really intended to handle this type of specific case, same for tdeint... unless you want to do the entire thing with manual overrides . Last edited by tritical; 17th February 2005 at 20:12. |
|
17th February 2005, 21:16 | #186 | Link |
Guest
Posts: n/a
|
Hey tritical, I really enjoy TIVTC and use it almost exclusively now for doing IVTC. But recently I was going to make some encodes of my Patlabor DVDs but it completely trips up from the start and just passes out bad matches all the way through, which can be fixed with manual overrides but thats quite a pain (maybe TIVTC can be intergrated into YATTA one day?). I think the problem has to do with what appears to be a real rough telecine for the first couple of seconds (even if good matches come through the video has tons of aliasing) then it smoothes out. I've tried Decomb and it works reasonably well. It provides better matches but leaves alot of combing in the mouth flaps, has that problem with alot of anime, and requires going through manually as well which is why I chose TIVTC cause it didn't have this problem. Would it be possible to get a clip to you to see if you can work it out? I'm having a hell of a time trying to get it to work right. Thanks.
Last edited by KaiserS; 17th February 2005 at 21:40. |
20th February 2005, 07:14 | #189 | Link |
Registered User
Join Date: Dec 2003
Location: MO, US
Posts: 999
|
[link removed], changes:
Code:
TFM: + Added support for new dgindex d2v project file versions 07/08 (dgindex v1.2) to the d2v option. - Fixed the d2v method of fixing illegal transitions. + TFM now uses the rff flags from the d2v to help tdecimate identify duplicates and 24p film. - Changed default MI value to 100. - Fixed the readme file indicating chroma=true, when it actually defaults to false TDecimate: + Most similar decimation mode now takes duplicate via match info into account + Match duplicate info and d2v duplicate info is shown with debug/display options + rff info from d2v option in tfm is now taken into account when doing hybrid detection + Increased the maximum possible cycle value to 300 Still on the todo list for TIVTC are mainly TDecimate features. 1.) The rff d2v info is currently only used to help identify 24p sections when doing hybrid detection... need to have it taken into account when deciding what frame to drop as well. 2.) Redo/Improve mode 2 of tdecimate. Last edited by tritical; 11th March 2005 at 00:54. |
22nd February 2005, 06:00 | #190 | Link | |
Almost Silent Member
Join Date: Jun 2002
Location: Purgatory
Posts: 273
|
Quote:
The only time I've observed obvious jerky behavior was when trying mode=4 with a hybrid source using the one pass method of blend decimation. It's beautiful when jerky motion is ghosted as well.
__________________
Rethinking the "Why?" chromosome. |
|
28th February 2005, 21:27 | #191 | Link |
ffdshow/AviSynth wrangler
Join Date: Feb 2003
Location: Austria
Posts: 2,441
|
One suggestion:
Looking at my standard testbed for TIVTC (GITS:SAC Ep. 1), there's a scene where the camera pans horizontally across a cityscape followed by a vertical pan across a street. The metrics for the 5 frames including the scene change are the following: Code:
6250: 11.96 c (new) 6251: 12.98 b (new) 6252: 13.47 b (new) 6253: 14.13 b (new) \the scene change is 6254: 41.04 h (new) /between these 2 frames Now, of course I could use conCycle=1, but this produces an unneccessary blend that I'd rather avoid - shouldn't frame 6253 or 6254 (i.e. one side of the scenechange) get dropped here no matter if it was treated as video or film, i.e. if there's a scenechange in a cycle that wasn't treated as video because of conCycle being 2 or more, and it's a deinterlaced half-frame to boot, why not drop that (or at least one of the 2 frames around the scenechange) since obviously no other duplicate was detected? (Or something along those lines...) I don't want to use a low sceneThresh since that produces not-so-good results on the parts that really are video, but have rather low motion... np: Banco de Gaia - Not In My Name (You Are Here) |
28th February 2005, 22:53 | #192 | Link |
Registered User
Join Date: Dec 2003
Location: MO, US
Posts: 999
|
The simplest change would be when using concycle>=2, having tdecimate handle single cycles that are detected as video and have a scene change detected in them as video even though they are standalones. That would (should) fix the problem above.
This type of special handling around scenechanges is only active for hybrid=1 handling atm and will probably never be used for hybrid=0 (hybrid=2, of course, doesn't have to worry about it) for two reasons... 1.) because any cycle where it is necessary to do so I consider to be hybrid (in this case 30fps progressive) thus needing hybrid handling and 2.) making it work for hybrid=0 would be difficult cause tdecimate obviously doesn't do video detection in that case which is the main key to knowing that it is needed. As for the scenethresh issue, you may get better results if you set chroma=false in tdecimate. Currently the scenechange metrics are computed from the block metrics to save time, so whether or not they include chroma depends on that setting, and the scenechange metrics w/o chroma should be much better. Making a change internally so that the scenechange metric is always calculated using only luma regardless of the chroma setting would be easy for yv12 but impossible for yuy2. There would have to be a separate calculation routine for yuy2 in the case that chroma=true. It might be worth it though, and I doubt many people use it in yuy2 to begin with. Last edited by tritical; 28th February 2005 at 23:18. |
1st March 2005, 02:16 | #193 | Link |
Registered User
Join Date: Dec 2003
Location: MO, US
Posts: 999
|
@Leak
I made those two changes [link removed]... single video cycle with scenechange and concycle>=2 and scenechange metrics are now always calculated via luma only regardless of the chroma setting. Whenever you have time could you test that version on that gits:sac clip and see how it handles it? Also, having that type of handling around scenechanges for hybrid=0 might be worthwhile. Something like what you mentioned above, if all the frames in the cycle have metrics above a specific threshold, check if there is a scenechange present and drop a frame on the scenechange instead of the frame with the lowest metric. Only problem is it adds another threshold, I may just set that internally to a value large enough that it would never trigger accidently (4.0 or so) and see what happens. Anyways, that wont be added for a while probably... Last edited by tritical; 11th March 2005 at 00:54. |
1st March 2005, 17:08 | #194 | Link | |
ffdshow/AviSynth wrangler
Join Date: Feb 2003
Location: Austria
Posts: 2,441
|
Quote:
Anyhow - another idea: could you make it possible to suppress scene change detection in "long" (that is, 2 or more cycles) video parts, since everything is getting blended there anyway? In the intro there's a few spots where 2 consecutive video cycles get frames dropped even though there really wasn't a frame change, and I'm not sure this won't be noticeable in the output - I'd rather have the whole intro blended down equally. I.e. why detect scene changes in the "real" 30 FPS parts, where the special handling is rather bound to stand out among the rest? Getting a non-blended frame now and then doesn't really do much, does it? np: Andrew Pekler - Unidentified (But Then Again) |
|
2nd March 2005, 14:57 | #195 | Link |
Registered User
Join Date: Dec 2003
Location: MO, US
Posts: 999
|
It could be disabled in that case... though I very much dislike when a blend comes across a scenchange, even if there has been blending up to that point.
Out of curiosity, would forcing the constraint that for a scenechange to be detected there must be only one frame with a metric above sceneThresh in all three cycles (prev, curr, next), help with that clip? Currently it is required that there be only one frame above sceneThresh in the current cycle for it to be detected as a scenechange. Forcing there to be at max one per three cycles would probably help eliminate false detections in areas with lots of motion. |
8th March 2005, 00:42 | #196 | Link |
brainless
Join Date: Mar 2003
Location: Germany
Posts: 3,653
|
tritical, after tweaking a lot with may motion adaptive deintlacers, I found many various real world videos that are causing them to produce weird combing artifacts.
pleaso take a look at SMDs Thread: http://forum.doom9.org/showthread.ph...0&pagenumber=1 these weird artifacts are produced because the motion in the fields is causing a stable on/off pattern within the field sequence, which lets the motion map think, that they are static. maybe an ADDITIONAL motion vector check could help to differenciate between true static and pseudo static (moving patterns) structures ?!?
__________________
Don't forget the 'c'! Don't PM me for technical support, please. |
8th March 2005, 01:35 | #197 | Link |
Registered User
Join Date: Dec 2003
Location: MO, US
Posts: 999
|
Did you have a specific check in mind? Cause to me it seems the only thing that would do it is comparing the opposite parity fields in some way instead of only comparing same parity fields. Either direct or indirect by comparing to an interpolated value.. i.e. a spatial combing metric which currently tdeint completely avoids. Also, as soon as it goes the combing metric route you might as well use an area based deinterlacer since almost any combing metric is only gonna spare the non-detailed areas to begin with, which you mentioned in the other thread. I'm open to any new ideas though... I sure don't have any for eliminating that type of artifacting besides the old combing metric routine.
Actually, you might be able to retain some of the benefits of motion adaptation if you switch between using inter-field and intra-field differencing on a block basis. Usually those types of artifacts occur in areas where most of the surroundings are moving as well (and are detected as such). Just an idea. Last edited by tritical; 8th March 2005 at 01:40. |
11th March 2005, 00:53 | #198 | Link |
Registered User
Join Date: Dec 2003
Location: MO, US
Posts: 999
|
Small bugfix updates that I meant to post last week, but forgot about...
[link removed] [link removed]. The changes mentioned above for Leak's issue were also included in this version of TIVTC. Complete change list: TIVTC: Code:
TDecimate: + Scene change metrics are calculated using only luma, regardless of the chroma option + There can only be one change above sceneThresh within the current cycle as well as the surrounding two cycles for it to be detected as a scene change + D2V rff duplicate info is taken into account when deciding what frames to drop, instead of only for hybrid detection + When hybrid > 0 and concycle or concycleTP is greater then 1, single cycles that are detected as video and that have a scene change detected in them are treated as video TFM: - Fixed a crash that would occur if the d2v option was enabled and trim() or some other filter that altered the number of frames was used prior to tfm() Code:
+ Fixed not correctly reading hints from newer versions of tivtc or if colorimetry hints were present from dgdecode. Last edited by tritical; 23rd April 2005 at 01:28. |
14th March 2005, 02:47 | #199 | Link |
Registered User
Join Date: Dec 2003
Location: MO, US
Posts: 999
|
Alright, here we go again ... [link removed]. This mainly focused on adding some missing logic (assuming match info from tfm is present) in most similar decimation mode. It can now handle panning->static and static->panning transitions like longest string. It can also detect when a cycle needs two frames dropped. I also tweaked longest string decimation a little (this is for when extra info such as match info or rff info from tfm is present). It should make slightly better decisions and be more accurate at finding cycles that need two frames dropped. Complete changes:
Code:
TDecimate: + Added missing logic to most similar decimation mode. It can now correctly handle panning->static and static->panning areas like longest string. It can also detect cycles that need two duplicates dropped. Assuming match info is present. + Tweaked decimation decisions for both longest string/most similar. + Added isse luma diff calculation routine for yuy2 - Fixed a bug in the longest string decimation decision that utilized match info from tfm. TFM: + Post-processing now only links luma->chroma on the motion map, instead of doing full luma->chroma, chroma->luma, and chroma->chroma linking. Last edited by tritical; 23rd April 2005 at 01:29. |
5th April 2005, 03:21 | #200 | Link |
Registered User
Join Date: Dec 2003
Location: MO, US
Posts: 999
|
Four posts in a row, ! Well, I've been unusually busy lately and haven't been able to work on TIVTC or TDeint hardly at all, but here is one minor update... [link removed]. The only change is the addition of a new filter called MergeHints() that allows the use of denoisers and other such filters inbetween tfm and tdecimate while still allowing tdecimate to get tfm's hints. I think a little example will best explain how to use it (it will work with any filter that hides hints in the lsb of the first 64 pixels, such as decomb, dgdecode, and others):
This is a script where TFM's hints would normally be destroyed and never reach TDecimate: mpeg2source(d2v="source.d2v") tfm(d2v="source.d2v") temporalsoften(3,3,5,15,2) #destroys the hints blur(0.25) #destroys the hints tdecimate(mode=1) To fix this, and preserve the hints (they can greatly aid decimation, especially if using hybrid detection), use MergeHints as follows: mpeg2source(d2v="source.d2v") tfm(d2v="source.d2v") savedHints = last temporalsoften(3,3,5,15,2) blur(0.25) MergeHints(hintClip=savedHints) tdecimate(mode=1) The only thing remaining for TIVTC before v1.0 is the new mode 2 operation for tdecimate, which should be added within the next few days (thanks to scharfis for sending a clip to test with). Also, after considering some possible solutions for handling motion adaptive artifacts in TDeint, I've decided to take the only way out I can think of and add an optional post processing mode. It will scan the final output frame using the 5-point combing metric from tfm with a user controllable threshold (set relatively high). Any pixels detected will then be interpolated. Its not an optimal solution, but should provide a means with which very visible artifacts can be prevented. That is the only thing left on the todo list for TDeint before it reaches v1.0. There is also a new ela method I've been working on, but atm it doesn't look like I'll be merging it into TDeint or TIVTC for a while. However, there is a reason that they each have a clip2 option. EDIT (April 22nd): Still haven't had time to get the new mode 2 for tdecimate added to TIVTC or the post-processing added to TDeint . However, I have made a few smaller, mainly bugfix releases: [link removed] [link removed] TIVTC changes from v0.9.8.3: Code:
TFM: + Debug and display options now output a value called MIC (the value that is computed and compared against MI to check if a frame is combed) to make tweaking the MI parameter easier. - Changed default MI value to 85 (also changed to 85 in IsCombedTIVTC) - Fixed the white box drawn on combed frames when PP=1 sometimes being drawn in the incorrect spot when mode was set to 1, 2, or 4 TDecimate: + Added exPP parameter, fixes handling of interlaced frames marked in tfmIn files when PP=1 in tfm and an external post-processor is used to deinterlace the combed frames. - Fixed crash caused by above circumstances Code:
- Fixed not correctly using the field information from tfm's hints when acting as a post-processor for it. Also fixed not correctly altering the match info of tfm's hints when acting as a post-processor for it (PP=1 in tfm). + Improvements to type 3 interpolation, renamed to modified ELA-2 [link removed] Got some free time and finished up a v1.0 beta 1 of TDeint. It adds the artifact protection (AP) threshold and post-processing (yes, the AP name was stolen from DGBob), which can be used to help prevent very obvious motion adaptive artifacts, and variable window size during combed frame detection (blockx, blocky). I called it beta 1 as I'm gonna wait a week or two and see if anyone spots a lingering bug... though I seem to be the only one posting in this thread anymore . Anyways, it only took ~ 7 months to get to v1.0. Last edited by tritical; 24th May 2005 at 10:54. |
Tags |
tdeint, tivtc |
Thread Tools | Search this Thread |
Display Modes | |
|
|