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. |
3rd November 2009, 16:57 | #1282 | Link |
Registered User
Join Date: Aug 2006
Posts: 77
|
I'm not sure this problem can be "solved" without some sort of pattern recognition (either in the frame or the motion). The equivalent of temporal softener on the movement MIGHT help. A somewhat specific approach could be to take the common movement of each row and then compensate to somewhere closer to their vertical neighbors or the whole frame. I'm afraid this will introduce compensation artifacts. And because the angles are inherently different from frame to frame (sort of the definition of skew and wobble), the blocks SAD will be less than perfect and false positives might be far more common than usual.
__________________
GA-P35-DS3R, Core2Quad Q9300@3GHz, 4.0GB/800 MHz DDR2, 2x250GB SATA HD, Geforce 6800 |
17th November 2009, 17:45 | #1283 | Link |
Unregistered User
Join Date: Jul 2008
Location: Netherlands
Posts: 133
|
Is it possible to calculate the integral from the motion vectors?
So that for example on frame 10 you have the vectors relative to frame 1 in stead of the previous one?
__________________
avi + m2t -> Vdub + DGIndex -> AE CS3 -> x264 -> Hell On Earth Woop, woop! That's the sound of the police! |
19th November 2009, 08:39 | #1284 | Link | |
Registered User
Join Date: Feb 2002
Location: California
Posts: 2,695
|
I get a crash when using the following script. If I disable SetMTMode, I don't get the crash. Since there has been some discussion about crashes wtih SetMTMode with version 2.5.9, I tried 2.4.7, but it also crashed.
I monitored the MEMusage and VM Size reported by Windows Task Manager (I'm running WinXP Pro SP3), and it crept up slowly for about two minutes. Than about ten seconds before the crash, these numbers quadrupled in a few seconds, eventually consuming all available memory (I have 6 gigs, although only a portion of that is available with my XP 32-bit). This script sometimes works fine, and other times it crashes. I am feeding it from frameserved video out of Vegas Pro 7.0d. It always works if I disable the SetMTMode. My computer is an Intel i7 3.2GHz (stock clocking). 8 core. It is very stable and I regularly render with all 8 cores maxed out. I did try to change memory usage with the SetMemoryMax command, but that didn't seem to eliminate the crashes. Quote:
Last edited by johnmeyer; 8th July 2015 at 14:47. Reason: Change vector order in Interleave statement in RemoveDirtMC |
|
19th November 2009, 13:30 | #1285 | Link |
Registered User
Join Date: Apr 2002
Location: Germany
Posts: 5,391
|
Purely from the guts, I suspect clense could be the culprit. Clense works recursive: temporal median of previous/current/next, where "previous" is not the original source frame, but the already-clensed frame from one step before. This already-clensed frame is stored in a filter-private cache slot. (That's what the avsrecursion.dll is needed for.)
I could imagine that this workflow is not reliably compatible with MT. If no other/better ideas come up, you might try to (temporarily) replace the line > clensed=input.Clense(grey=_grey, cache=4) with > clensed = input.MedianBlurT(0,0,0,1).merge(input,0.5).MedianBlurT(0,0,0,1) Result is not exactly the same, but surely similar enough that you won't see noticeable difference in the end. It's also a good bit slower. However, it removes the possibly problematic recusive-ness from Clense out of the script, and the end result remains being perfectly usable. If you still get those crashes, then the problem is somewhere else. If the crashes disappear, then Clense is nailed.
__________________
- We´re at the beginning of the end of mankind´s childhood - My little flickr gallery. (Yes indeed, I do have hobbies other than digital video!) |
20th November 2009, 01:18 | #1286 | Link |
Registered User
Join Date: Feb 2002
Location: California
Posts: 2,695
|
Didée,
Your advice was correct. Replacing Clens with MedianBlurT stopped the crashing. However, it was about half the speed of the crashing code, but still twice as fast as doing the script without SetMTMode. I'm going to experiment with other plugins to replace what Clens is doing. Your blur idea is good, but after doing a lot of A/B testing on video processed with the original script and video processed with your fix, the original script does a slightly better job. In other words, you were absolutely correct that the differences would be subtle, but I hate to give an inch on quality, if I can help it. Many thanks. [Edit] Spoke too soon. It still crashes. Will have to look elsewhere. It sure isn't consistent as to when it crashes. [Edit2]It's only been a few minutes since I made my edit and no one has yet responded so I thought I'd post some more info. The biggest change in stability is changing the "overlap" parameter that is ultimately used by MAnalyse. If I use this calling function (in the script I posted above): final=MDegrain2i2(despotted,0,0) I can sometimes get through encoding a three hour video without a crash. However, if I instead use this call: final=MDegrain2i2(despotted,2,0) I usually get a crash within the first few minutes of operation. So, I am suspecting MVTools2 and the overlap function in particular. Last edited by johnmeyer; 20th November 2009 at 02:17. Reason: New information |
20th November 2009, 20:08 | #1287 | Link | |
Potentate
Join Date: Mar 2003
Posts: 219
|
Quote:
Also, try the kill audio before the setmtmode - I seem to recall SET identifying that audio was not properly handled (could be wrong). T |
|
20th November 2009, 20:23 | #1288 | Link |
Registered User
Join Date: Feb 2002
Location: California
Posts: 2,695
|
Interesting about the killaudio command. After I read your post I search for SetMTMode and Killaudio in this forum and found a few other posts which, like yours, suggested that it may be a problem, but nothing definitive.
I went ahead and made the change in the script. I don't have any video to process today, but when I do, I'll see what happens. Thanks! |
10th January 2010, 01:18 | #1289 | Link |
Registered User
Join Date: Jan 2009
Posts: 9
|
Yushko Frame Rate Converter
Hi everyone!
1) Yushko Frame Rate Converter - doublerate frame rate converter with strong artifact detection and scene change detection. Its based on "MVTools" and "MaskTools". In order to run the YFRC script, you have to have "MaskTools.dll" and "mvtools.dll". 2) "Hello World" Ok, lets try to apply YFRC on some test clip. To do it you need: a) any *.AVI clip with properties: Frame rate 25p, Frame Size 720x576, Color Space YV12; b) download and copy "mvtools.dll" and "masktools.dll" to the directories "C:\Program Files\AviSynth 2.5\plugins\MvTools2\" and "C:\Program Files\AviSynth 2.5\plugins\"; c) download and copy "Yushko_09dd_01mm_2010yy.avsi" or newer to the directory "C:\Program Files\AviSynth 2.5\plugins\"; d) create *.avs file near your *.avi file with content like this: AVISource("720x576x25p.avi").YFRC() Links: Download from:http://videomontazh.com.ua/avisynth/...01mm_2010yyyy/ Example clip, 24p->48p, x264 30MB: http://videomontazh.com.ua/avisynth/...m_2010yyyy.mp4 |
5th February 2010, 17:42 | #1290 | Link | |
Registered User
Join Date: Jun 2005
Posts: 365
|
Quote:
Code:
setMTMode(2,3) source=AVISource("test.avi") LoadPlugin("C:\Program Files (x86)\AviSynth 2.5\plugins\mvtools2.dll") super = source.MSuper(pel=2) backward_vec = MAnalyse(super, blksize=8, dct=1, overlap=4, isb = true, search=3) forward_vec = MAnalyse(super, blksize=8, dct=1, overlap=4, isb = false, search=3) source.MFlowFps(super, ThSCD1=350, blend=false, backward_vec, forward_vec, \ num=2*FramerateNumerator(source), den=FramerateDenominator(source)) distributor() Yushko: MVTools: Same thing here: Yushko: MVTools: And here: Yushko: MVTools: But there are some problems with Yushko. Sometimes it just skips a frame that has too much artifact, repeating the last frame, which causes a very annoying stutter. This behavior also brings another problem that we can see here: Yushko: MVTools: Notice that with Yushko we can't see the frame with the lighting, because it probably judged the lighting as an artifact or scene change, skipping that frame. Finally, in this scenario (that occurs a lot of times in the beginning of this movie) MVTools seems to predict better than Yushko: Yushko: MVTools: The sample I used can be downloaded here. Maybe Fizick could merge part of the code of Yushko work, using the best parts and avoiding the bad ones. What you think? Thanks for sharing your information. Last edited by Delerue; 5th February 2010 at 18:08. |
|
5th February 2010, 23:31 | #1291 | Link |
Unregistered User
Join Date: Jul 2008
Location: Netherlands
Posts: 133
|
Thanks. I didn't even know Yushko. Can you provide a link? The first google result on yushko framerate is this very page. :P
It's unfortunate that once again the better party depends on the shot. But here's a question I've had for a while now: How come frame doubling/quadrupling gives artifacts so often? The chip in my Samsung 100 Hz HDTV or my folks' Philips 100Hz HDTV converts or interpolates 25 fps footage to 100fps footage on the fly, in real time (ok there's a tiny 2 frame delay, you can hear it when you listen to the unshifted audio output), and there are almost never artifacts. (And when there are, it's totally different from the MVFlow kinda distortions you see in solutions we know. It's like a block of motion is misplaced or skipped.) It does it's work so good and fast I would like to see that behaviour in an AviSynth plugin. And I cannot believe a single chip from a €600 TV is faster than my quad core.
__________________
avi + m2t -> Vdub + DGIndex -> AE CS3 -> x264 -> Hell On Earth Woop, woop! That's the sound of the police! |
6th February 2010, 00:31 | #1292 | Link |
Registered User
Join Date: Apr 2002
Location: Germany
Posts: 5,391
|
I don't own such a TV personally, but one of my mates has a Samsung with 100Hz Truemotion (or however it's called). Per system settings it is configurable to weak/normal/strong. What I can say is: overall it is pretty much okay. But I do see artifacts regularly. And in scenes where I know that MVTools would produce artifacts, on the Samsung it is simply so that it is not smooth in those scenes, but gives just the "normal 25fps judder". So, guess what's happening ... the biggest trick is to reckognize where things get difficult, and just do "nothing" in those cases. Simple as that. Not any magic.
__________________
- We´re at the beginning of the end of mankind´s childhood - My little flickr gallery. (Yes indeed, I do have hobbies other than digital video!) |
6th February 2010, 00:35 | #1293 | Link |
Unregistered User
Join Date: Jul 2008
Location: Netherlands
Posts: 133
|
I guess there are many different quality chips because the (brand new) one I have is awesome at it. And indeed, very occasionally, it skips a macroblock (not the entire frame), but apart from that it actually is like magic imo. Or if you call Mvtools solutions magic, this is just voodoo.
__________________
avi + m2t -> Vdub + DGIndex -> AE CS3 -> x264 -> Hell On Earth Woop, woop! That's the sound of the police! |
8th February 2010, 21:05 | #1294 | Link |
Registered User
Join Date: Jun 2005
Posts: 365
|
Exactly! And I think that this behavior (turning on/off the 'smoother' constantly) is very bad and bothers a lot, specially with long pans. I've tested at least six models/manufacturers and I can tell you that MFlowFPS is better than all of them. But, of course, there's a lot of things to improve in MFlowFPS, as we can see in the SS above.
|
15th February 2010, 21:50 | #1295 | Link | |
Registered User
Join Date: May 2007
Posts: 220
|
Quote:
Code:
# RollAway filter by um3k/Justin Phillips # Reduces rolling shutter artifacts on video from CMOS-chipped camcorders/DSLRS # "Amount" is the same as that used for DeShaker. The formula can be found here: # http://www.guthspot.se/video/deshaker.htm#rolling shutter setting # "Segh" is the height of the segments the image is split into. It should be an even number, and a dividend of the clip height. # This script is compatible with SetMTMode. # Use SetMemoryMax in your script to increase speed. Set it to a fairly high number that is reasonable for you computer's capabilities. # # Alpha 1 function RollAway_alpha1(clip c, float amount, int segh) { Assert(IsInt(segh/c.height), "'segh' must be a dividend of clip height") ctime = amount/2 segs = c.height/segh den = segs-1 num = den super = c.MSuper() fv = MAnalyse(super, blksize=8, isb = false, overlap=4) bv = MAnalyse(super, blksize=8, isb = true, overlap=4) DeRoll(c, super, fv, bv, ctime, den, segh) } function DeRoll(clip c, clip super, clip fv, clip bv, float ctime, int den, int segh, int "segn", clip "stack") { stackh = Defined(stack) ? stack.height \ : 0 segn = Defined(segn) ? segn+1 \ : 0 num = abs(den-segn*2) fclp = c.MFlow(super, fv, time=ctime*num/den).Crop(0, segn*segh, -0, segh).SelectEvery(1, 1) bclp = c.MFlow(super, bv, time=ctime*num/den).Crop(0, segn*segh, -0, segh).SelectEvery(1, -1) nseg = stackh > c.height/2 ? bclp \ : fclp stack = Defined(stack) ? StackVertical(stack, nseg) \ : nseg segn = segn return stack.height == c.height ? stack \ : DeRoll(c, super, fv, bv, ctime, den, segh, segn, stack) } The lower "segh" is set, the slower the filter will be, but the results will show less seam artifacts. Last edited by um3k; 15th February 2010 at 22:30. |
|
16th February 2010, 00:51 | #1297 | Link |
Unregistered User
Join Date: Jul 2008
Location: Netherlands
Posts: 133
|
Wow, not tried it yet but I really really like that there's a shutter compensation attemt in AviSynth with MVtools.
I cannot wait to try it! But I must :P
__________________
avi + m2t -> Vdub + DGIndex -> AE CS3 -> x264 -> Hell On Earth Woop, woop! That's the sound of the police! |
|
|