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 Usage

Reply
 
Thread Tools Search this Thread Display Modes
Old 31st October 2009, 21:04   #1281  |  Link
Redsandro
Unregistered User
 
Redsandro's Avatar
 
Join Date: Jul 2008
Location: Netherlands
Posts: 133
I think I mentioned that.
__________________
avi + m2t -> Vdub + DGIndex -> AE CS3 -> x264 -> Hell On Earth
Woop, woop! That's the sound of the police!
Redsandro is offline   Reply With Quote
Old 3rd November 2009, 16:57   #1282  |  Link
TSchniede
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
TSchniede is offline   Reply With Quote
Old 17th November 2009, 17:45   #1283  |  Link
Redsandro
Unregistered User
 
Redsandro's Avatar
 
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!
Redsandro is offline   Reply With Quote
Old 19th November 2009, 08:39   #1284  |  Link
johnmeyer
Registered User
 
Join Date: Feb 2002
Location: California
Posts: 2,691
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:
# Despot script for Shindig
loadplugin("C:\Program Files\AviSynth 2.5\plugins\MVTools\mvtools2.dll")
loadplugin("C:\Program Files\AviSynth 2.5\plugins\RemoveDirtSSE2.dll")
loadplugin("c:\Program Files\AviSynth 2.5\plugins\TIVTC.dll")

#SetMemoryMax(768
SetMTMode(5)
Avisource("M:\frameserver.avi").ConvertToYV12(interlaced=true)
SetMTMode(2,0)

KillAudio()
AssumeBFF()
tfm(mode=1,pp=6,field=-1,display=false)
tdecimate(mode=0)
source=assumefps(23.976)

despotted=RemoveDirtMC(source,33,false)

final=MDegrain2i2(despotted,2,0)

#stackhorizontal (source,final)
return final


#--------------------------------------------------------
function MDegrain2i2(clip source, int "overlap", int "dct")
{
overlap=default(overlap,0) # overlap value (0 to 4 for blksize=8)
dct=default(dct,0) # use dct=1 for clip with light flicker
super = MSuper(source,pel=2, sharp=1)
backward_vec2 = MAnalyse(super, isb = true, delta = 2, overlap=overlap, dct=dct)
backward_vec1 = MAnalyse(super, isb = true, delta = 1, overlap=overlap, dct=dct)
forward_vec1 = MAnalyse(super, isb = false, delta = 1, overlap=overlap, dct=dct)
forward_vec2 = MAnalyse(super, isb = false, delta = 2, overlap=overlap, dct=dct)
source.MDegrain2(super, backward_vec1,forward_vec1,backward_vec2,forward_vec2,thSAD=400)
}

function RemoveDirt(clip input, int limit, bool _grey)
{
clensed=input.Clense(grey=_grey, cache=4)
alt=input.RemoveGrain(2)
# return RestoreMotionBlocks(clensed,input,alternative=alt,pthreshold=4,cthreshold=6, gmthreshold=40,dist=1,dmode=2,debug=false,noise=limit,noisy=12,grey=_grey,show=true)
return RestoreMotionBlocks(clensed,input,alternative=alt,pthreshold=6,cthreshold=8, gmthreshold=40,dist=3,tolerance= 12,dmode=2,debug=false,noise=limit,noisy=12,grey=_grey,show=false)
}

function RemoveDirtMC(clip,int "limit", bool "_grey")
{
_grey=default(_grey, false)
limit = default(limit,6)
i=MSuper(clip,pel=2)
bvec = MAnalyse(i,isb=false, blksize=8, delta=1, truemotion=true)
fvec = MAnalyse(i,isb=true, blksize=8, delta=1, truemotion=true)
backw = MFlow(clip,i,bvec)
forw = MFlow(clip,i,fvec)
clp=interleave(forw,clip,backw)
clp=clp.RemoveDirt(limit,_grey)
clp=clp.SelectEvery(3,1)
return clp
}

Last edited by johnmeyer; 8th July 2015 at 14:47. Reason: Change vector order in Interleave statement in RemoveDirtMC
johnmeyer is offline   Reply With Quote
Old 19th November 2009, 13:30   #1285  |  Link
Didée
Registered User
 
Join Date: Apr 2002
Location: Germany
Posts: 5,389
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!)
Didée is offline   Reply With Quote
Old 20th November 2009, 01:18   #1286  |  Link
johnmeyer
Registered User
 
Join Date: Feb 2002
Location: California
Posts: 2,691
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
johnmeyer is offline   Reply With Quote
Old 20th November 2009, 20:08   #1287  |  Link
tedkunich
Potentate
 
Join Date: Mar 2003
Posts: 219
Quote:
Originally Posted by johnmeyer View Post
So, I am suspecting MVTools2 and the overlap function in particular.
I too had crashes with MVTools - I believe the later builds resolved my problems (but I have not been processing much of late)

Also, try the kill audio before the setmtmode - I seem to recall SET identifying that audio was not properly handled (could be wrong).

T
tedkunich is offline   Reply With Quote
Old 20th November 2009, 20:23   #1288  |  Link
johnmeyer
Registered User
 
Join Date: Feb 2002
Location: California
Posts: 2,691
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!
johnmeyer is offline   Reply With Quote
Old 10th January 2010, 01:18   #1289  |  Link
runforlife
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
runforlife is offline   Reply With Quote
Old 5th February 2010, 17:42   #1290  |  Link
Delerue
Registered User
 
Join Date: Jun 2005
Posts: 365
Quote:
Originally Posted by runforlife View Post
Hi everyone!

1) Yushko Frame Rate Converter - doublerate frame rate converter with strong artifact detection and scene change detection. [...]
Hi! I did some tests with Yushko script vs pure MVTools. The MVTools script was this:

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()
First test Yushko seems to be better:

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.
Delerue is offline   Reply With Quote
Old 5th February 2010, 23:31   #1291  |  Link
Redsandro
Unregistered User
 
Redsandro's Avatar
 
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!
Redsandro is offline   Reply With Quote
Old 6th February 2010, 00:31   #1292  |  Link
Didée
Registered User
 
Join Date: Apr 2002
Location: Germany
Posts: 5,389
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!)
Didée is offline   Reply With Quote
Old 6th February 2010, 00:35   #1293  |  Link
Redsandro
Unregistered User
 
Redsandro's Avatar
 
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!
Redsandro is offline   Reply With Quote
Old 8th February 2010, 21:05   #1294  |  Link
Delerue
Registered User
 
Join Date: Jun 2005
Posts: 365
Quote:
Originally Posted by Didée View Post
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".
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.
Delerue is offline   Reply With Quote
Old 15th February 2010, 21:50   #1295  |  Link
um3k
Registered User
 
Join Date: May 2007
Posts: 220
Quote:
Originally Posted by Redsandro View Post
I was wondering if anyone is interested in bringing rolling shutter compensation to MVTools, or if something similar has already been attempted?
Something like this, perhaps?

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)
}
It isn't exactly fast, but it works. Sometimes. And I can't guarantee any semblance of stability.

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.
um3k is offline   Reply With Quote
Old 15th February 2010, 22:56   #1296  |  Link
hydra3333
Registered User
 
Join Date: Oct 2009
Location: crow-land
Posts: 540
Any chance of before and after images/snippets ?
hydra3333 is offline   Reply With Quote
Old 16th February 2010, 00:51   #1297  |  Link
Redsandro
Unregistered User
 
Redsandro's Avatar
 
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!
Redsandro is offline   Reply With Quote
Old 16th February 2010, 13:12   #1298  |  Link
Gavino
Avisynth language lover
 
Join Date: Dec 2007
Location: Spain
Posts: 3,431
Quote:
Originally Posted by um3k View Post
Code:
function RollAway_alpha1(clip c, float amount, int segh)
{
    Assert(IsInt(segh/c.height), "'segh' must be a dividend of clip height")
Since segh and c.height are both ints, segh/c.height will always satisfy IsInt(). You want
Code:
    Assert(segh%c.height == 0, ...)
Gavino is offline   Reply With Quote
Old 16th February 2010, 15:30   #1299  |  Link
um3k
Registered User
 
Join Date: May 2007
Posts: 220
Quote:
Originally Posted by Gavino View Post
Since segh and c.height are both ints, segh/c.height will always satisfy IsInt(). You want
Code:
    Assert(segh%c.height == 0, ...)
Thanks, I was wondering why that wasn't working...fortunately a different error stepped in to prevent an endless loop.

Last edited by um3k; 16th February 2010 at 17:27.
um3k is offline   Reply With Quote
Old 16th February 2010, 17:29   #1300  |  Link
Gavino
Avisynth language lover
 
Join Date: Dec 2007
Location: Spain
Posts: 3,431
Actually, looking at this again,
Quote:
Originally Posted by um3k View Post
"'segh' must be a dividend of clip height"
the required condition is:
Assert(c.height%segh == 0, ...)
Gavino is offline   Reply With Quote
Reply

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 16:49.


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