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 11th February 2005, 14:01   #181  |  Link
manono
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.
manono is offline   Reply With Quote
Old 17th February 2005, 01:31   #182  |  Link
rawr
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.
rawr is offline   Reply With Quote
Old 17th February 2005, 04:28   #183  |  Link
tritical
Registered User
 
Join Date: Dec 2003
Location: MO, US
Posts: 999
Quote:
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.
Was this just a general comment or did you have a specific feature in mind that would be useful to have? Atm, tfm allows for changing which field is matched from (and thus which field is maintained after post-processing) and allows for this to be controlled via overrides to vary on a per frame basis. Also, tfm actually supports 5 possible weave combinations, which include all the possible configurations that can be formed using the top or bottom field from the current frame with fields from the two surrounding frames. It also allows for using frames from an external deinterlacer to replace frames that are detected as combed after field matching (instead of using one of its in built pping types) and to even motion mask those external frames. I'm just wondering what other per field aspect you are looking for?

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...
tritical is offline   Reply With Quote
Old 17th February 2005, 15:46   #184  |  Link
rawr
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-)
Now, if I could just force the decimate to fall on the (U-) and ensure that the top field is fed to the first blend, and the bottom to the next blend, AND maintain this across different overrides for different scenes, then this should work. Maybe.

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.
rawr is offline   Reply With Quote
Old 17th February 2005, 19:52   #185  |  Link
tritical
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:
Now, if I could just force the decimate to fall on the (U-) and ensure that the top field is fed to the first blend, and the bottom to the next blend, AND maintain this across different overrides for different scenes, then this should work.
I don't understand what you mean by "ensure that the top field is fed to the first blend" ?

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.
tritical is offline   Reply With Quote
Old 17th February 2005, 21:16   #186  |  Link
KaiserS
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.
  Reply With Quote
Old 18th February 2005, 20:04   #187  |  Link
tritical
Registered User
 
Join Date: Dec 2003
Location: MO, US
Posts: 999
KaiserS, I sent you a pm with an ftp address where you can upload the clip if you are willing to. I'd very much like to run a few tests on it.

Last edited by tritical; 18th February 2005 at 20:09.
tritical is offline   Reply With Quote
Old 18th February 2005, 20:16   #188  |  Link
KaiserS
Guest
 
Posts: n/a
Had a problem uploading it to your ftp, so I sent you a PM where you can download it from mine. Thanks.
  Reply With Quote
Old 20th February 2005, 07:14   #189  |  Link
tritical
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
One note about KaiserS's problem. It turned out that the problem was the incorrect field order was being used by tfm. The reason why though, was that the clip violated the d2v field order rule. The first trf flag was a 0 but the stream was actually tff. Seems the video was hard telecined as tff, but was stored as bff in the mpeg2 stream... very strange. Anyways, I have been thinking about changing the default mode value for tfm from 1 to 3 so that it will by default handle videos with field order changes or cases when the order parameter is set incorrectly, but decided not to for now. Anyone have an opinion on this?

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.
tritical is offline   Reply With Quote
Old 22nd February 2005, 06:00   #190  |  Link
DarkNite
Almost Silent Member
 
DarkNite's Avatar
 
Join Date: Jun 2002
Location: Purgatory
Posts: 273
Quote:
Anyways, I have been thinking about changing the default mode value for tfm from 1 to 3 so that it will by default handle videos with field order changes or cases when the order parameter is set incorrectly, but decided not to for now. Anyone have an opinion on this?
I don't mind. If it causes jerkiness (is that even English?) in certain sources then people can simply follow the suggestions in the documentation and change the mode parameter to one that makes more sense for their situation/source.

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.
DarkNite is offline   Reply With Quote
Old 28th February 2005, 21:27   #191  |  Link
Leak
ffdshow/AviSynth wrangler
 
Leak's Avatar
 
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, if I'm using mode=1, hybrid=1 and conCycle=2 I'm getting a noticeable jerk in the horizontal pan because TDecimate decides that it should drop frame 6250. If I use conCycle=1 and a low enough sceneThresh (10 in this case), it'll treat this cycle as video, but will still only drop frame 6253, which looks quite perfect.

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)
Leak is offline   Reply With Quote
Old 28th February 2005, 22:53   #192  |  Link
tritical
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.
tritical is offline   Reply With Quote
Old 1st March 2005, 02:16   #193  |  Link
tritical
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.
tritical is offline   Reply With Quote
Old 1st March 2005, 17:08   #194  |  Link
Leak
ffdshow/AviSynth wrangler
 
Leak's Avatar
 
Join Date: Feb 2003
Location: Austria
Posts: 2,441
Quote:
Originally posted by tritical
@Leak
I made those two changes tivtc test... 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?
Yes, it works.

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)
Leak is offline   Reply With Quote
Old 2nd March 2005, 14:57   #195  |  Link
tritical
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.
tritical is offline   Reply With Quote
Old 8th March 2005, 00:42   #196  |  Link
scharfis_brain
brainless
 
scharfis_brain's Avatar
 
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.
scharfis_brain is offline   Reply With Quote
Old 8th March 2005, 01:35   #197  |  Link
tritical
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.
tritical is offline   Reply With Quote
Old 11th March 2005, 00:53   #198  |  Link
tritical
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()
TDeint:
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.
tritical is offline   Reply With Quote
Old 14th March 2005, 02:47   #199  |  Link
tritical
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.
tritical is offline   Reply With Quote
Old 5th April 2005, 03:21   #200  |  Link
tritical
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
TDeint changes from v0.9.7.1:
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
EDIT (April 24):

[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.
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 12:56.


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