So I have several Avisynth scripts to compress as lossless intermediates. They display fine in AVSPMod, one of them made VirtualDub2 crash, probably because of too many “Morph” commands, I splitted it in two parts, now all of them are loading correctly. But for the larger ones (11-12min each), the compression fails early on with an error message saying :
What's going on, and what should I do ?Code:Avisynth read error: GetFrameBuffer: Returned a VFB with a 0 data pointer! size=8163391, max=1073741824, used=210497082 I think we have run out of memory folks!
Side question : if I compress with Lagarith and specify “RGB” in “Pixel format”, it compresses as YUV anyway. Why is that ? MagicYUV and UtVideo seem to honor that setting, and generate files about twice as large. If I convert to RGB in Avisynth with ConvertToRGB("Rec709"), Lagarith compresses as RGB, and still generates the smallest files of the three (albeit larger than in YUV, as it should be – in a test with a short video, I got 209Mo in Lagarith RGB vs. 122Mo in Lagarith YUV, and 239Mo for MagicYUV RGB, 293Mo for UtVideo RGB), so it seems to be the most efficient. So should I use the ConvertToRGB command for all scripts, or am I missing something ?
(I want RGB because for some reason YUV lossless files are displayed with the wrong color matrix in the NLE software I use.)
One of the scripts that fail :
The FrameSurgeon.txt file is a command file which contains hundreds of frame interpolation commands. According to its author it's very stable and unlikely to choke even with that many calls. The Morph function is much more sensitive and causes memory issues when called more than a few dozen times in the same script. I only used it for a few particularly problematic frames for which FrameSurgeon would produce egregious artifacts (typically in cases of rapid movement of a large enough object).Code:LoadPlugin("C:\Logiciels autonomes\MeGUI\tools\lsmash\LSMASHSource.dll") LWLibavVideoSource("20151224_132902.m2ts", threads=1).Trim(1070,21350) mdata=DePanEstimate(range=5,trust=4.0,dxmax=-1,dymax=-1,stab=1.00) DePanStabilize(data=mdata,cutoff=2.0,damping=10,initzoom=1.00,dxmax=6,dymax=6,method=1,mirror=15,prev=0,next=0,blur=30,info=false) FrameSurgeon(cmd="20151224_132902 A FrameSurgeon.txt", show=false) Morph(123,125) Morph(135,137) Morph(142,144) Morph(977,979) Morph(1206,1208) Morph(1219,1221) Morph(1237,1239) Morph(1245,1247) Morph(1255,1257) Morph(1418,1421) Morph(2183,2185) Morph(2188,2190) Morph(2197,2199) Morph(12865,12868) Morph(15723,15725) ConvertToRGB("Rec709")
Try StreamFab Downloader and download from Netflix, Amazon, Youtube! Or Try DVDFab and copy Blu-rays! or rip iTunes movies!
+ Reply to Thread
Results 1 to 20 of 20
Thread
-
-
You could enable LAA and therefore make 32 bit VDub use up to 4GB of memory on a 64 bit OS. Run "auxsetup.exe" in the 'extra' directory and select 'Enable LAA'.
Edit: Alternatively, use 64 bit VDub and Avisynth+.Last edited by Groucho; 18th Dec 2018 at 07:45.
-
Best alternative IMO .
Another approach is to split up the script into smaller sections for processing. Maybe include "x" number of frames then append. Maybe batch encode scripts
Lagarith is more efficient than those other two, compression wise. It's also slower for encoding/decoding .
You can get smaller filesizes with ffv1 in long gop mode, or x264 in lossless long gop mode . But they have less support in other applications .
So should I use the ConvertToRGB command for all scripts, or am I missing something ?
If you let something else do it, it might use non ideal parameters. Codecs make that choice usually choose based on speed - but something that converts fast often has other trade offs -
You could enable LAA and therefore make 32 bit VDub use up to 4GB of memory on a 64 bit OS. Run "auxsetup.exe" in the 'extra' directory and select 'Enable LAA'.
Edit: Alternatively, use 64 bit VDub and Avisynth+.Best alternative IMO .
– Will all the required filters / functions work in 64b ? I tried loading one of the scripts in VD2 x64 before, but it failed because it couldn't load LSMASHSource.dll, so I didn't insist. So first I would need the 64b version of LSMASHSource. Then I don't remember what were the required plugins for Morph and FrameSurgeon (configured them months ago). Do all common plugins have a stable 64b version now ? As for DePan, apparently it came with MVTools, there's a x64 version included, which I already placed in the plugins64 directory; I don't know if anything else is needed. It's so complicated to get this working with one configuration, that I always dread the prospect of having to start all over again !
– Will the scripts then work in AVSPMod ? (Which seems to work in 32b.)
You can get smaller filesizes with ffv1 in long gop mode, or x264 in lossless long gop mode . But they have less support in other applications .
Anyway, Lagarith seems to be the best compromise here. -
Yes, and there is a 64bit version
Then I don't remember what were the required plugins for Morph and FrameSurgeon (configured them months ago). Do all common plugins have a stable 64b version now ? As for DePan, apparently it came with MVTools, there's a x64 version included, which I already placed in the plugins64 directory; I don't know if anything else is needed. It's so complicated to get this working with one configuration, that I always dread the prospect of having to start all over again !
But you mentioned HDRAGC in another thread. That does not yet, but someone was working on it
I don't know about those specific StainlessS' functions, but he usually builds x64 versions now as well
– Will the scripts then work in AVSPMod ? (Which seems to work in 32b.)
You can get smaller filesizes with ffv1 in long gop mode, or x264 in lossless long gop mode . But they have less support in other applications .
Anyway, Lagarith seems to be the best compromise here.
I agree, Lagarith is probably is the best compromise here, when you need to use it in some NLE for RGB
Or do what people used to do before avisynth+ or x64, just split it up. Divide and conquer -
Most common plugins have a 64bit version now.
But you mentioned HDRAGC in another thread. That does not yet, but someone was working on it
Interesting anyway, I thought that this filter had been abandoned for years (12 years to be precise ). Is there an active thread where that someone talks about it ? Are there improvements planned as well ? An issue I've had with it is that it seems to completely ignore the values outside of the normal video range (and in the case of those recordings there's a lot outside of that range), so another filter has to be used before to bring the blacks to 16 and the highlights to 235, but then it seems to reduce the contrast...
I don't know about those specific StainlessS' functions, but he usually builds x64 versions now as well
And from https://www.mediafire.com/folder/hb26mthbjz7z6/StainlessS : there are x64 versions of RT_Stats and FrameSel, but not ClipClop and Prune ; the source code is included, so I suppose that I could build a x64 version myself, but right now I don't know how to do that, and to learn how to do it would make me wander even further from the already excruciatingly painstaking process I'm trying to put to completion... Reminds me of something I read on a forum years ago which expressed how I feel about that kind of things so well that I added it to my collection of quotes :
“I guess you could say I'm rather lazy in that I have to be provoked into learning that kind of detail about a subject. There are so many pieces of the grand puzzle to know that I, most of the time, just shoot from the hip hoping to knock a few things loose and clear the path. There never seems to be enough time to learn every tangent in an array of possibilities while trying to keep in mind that these secondary and tertiary 'projects' are leading you further away from the simple task you just wanted to be done with. Many times, when it looks like the target is going to require a sniper rifle instead of my shotgun, instead of spending the time and resources procuring 50cal long barrel, mounting a scope, sighting it as I work on my breathing and windage calculations for a year or so, I look for a trained sharpshooter instead. When fishing the knowledge pool I never expect anything less than to be humbled. ...but I CAN cook a really mean ratatouille MoFo! Thanks Man.”
“Klozov” 20091007
(As for myself, I can't even cook a ratatouille... I wouldn't even know where to begin ! ) -
You could enable LAA and therefore make 32 bit VDub use up to 4GB of memory on a 64 bit OS. Run "auxsetup.exe" in the 'extra' directory and select 'Enable LAA'.
EDIT : And a Google search for : « virtualdub "enable LAA" » returns a measly two hits...
EDIT : What's strange is that the VirtualDub2 process uses less than 2GB when it fails, according to ProcessExplorer : 1314064KB once the “A” script is loaded, and it fails when that reaches about 1750000KB – strangely Windows Task Manager reports about 1GB less).
EDIT : After a few trials I managed to render the first of the problematic scripts. Memory usage maxed out at about 1730000 according to ProcessExplorer, and about 1236000KB (slightly increasing while the value in ProcessExplorer stalled). Why this discrepancy ?
Only two more !Last edited by abolibibelot; 18th Dec 2018 at 16:54.
-
Just the original thread at doom9. Someone mentioned looking at the source and building a 64bit version. It would make sense to make requests there. I know a few people nudged and bumped the thread recently (because I'm one of them)
You can definitely get better results doing it in other programs, but it's still a useful filter and one of the semi-frequently ones still missing from the x64 plugin list. I would also like to see it extended to 10bit; since 10bit is increasingly common in consumer space right now
I don't know about those specific StainlessS' functions, but he usually builds x64 versions now as well
And from https://www.mediafire.com/folder/hb26mthbjz7z6/StainlessS : there are x64 versions of RT_Stats and FrameSel, but not ClipClop and Prune ; the source code is included, so I suppose that I could build a x64 version myself, but right now I don't know how to do that, and to learn how to do it would make me wander even further from the already excruciatingly painstaking process I'm trying to put to completion...
If you're just trying to get stuff done by the deadline , I would just carry on with the x86 workflow you have going, and divide it up a bit to beat the memory issues
I know you posted about interpolation errors - that's actually normal and expected. Some sets of settings might give you slightly better on some frames, and slightly worse on others. That' s the nature of interpolation . eg.blksize 16 might be ok for some, but 8 might be better for others. If you went through iterations with something like avsoptimizer, you might be able to calculate a best solve for a section optimizing dozens of parameters. But in the time it takes you to do that, there are ways to fix with other programs too with masking / compositing / motion tracking . There are user guided workflows that take track points and edge splines to guide the interpolation, so you minimize the blobby edge morphing artifacts. That's one of the main complaints and problems with interpolation - it's the incomplete object separation by the algorithms used, so you end up with morphing blobby edges. With other methods, you're practically guaranteed to get better results, but it depends on how much time investment you can put in . And some types of content are tough to interpolate no matter what
In the end, I'm sure your family will be happy, because it's the thought that counts. Spend more time with them, instead of in front of a computer -
Radical solution for you might be switching to Vapoursynth 64 threaded beast, it just might work, loading your avisynth 32bit script into Vapoursynth64 using avsproxy.dll. Download from here or here(its dll and exe file, put it into Vapoursynths Plugin64 folder) . You can get rid of these memory issues. Then you just use VirtualDub2 64bit to load it in.
point is, forget about 32bit, install Python64bit, Vapoursynth64bit and get VirtualDub2 64bit
Vapoursynth script:
Code:import vapoursynth as vs file = r'20151224_132902.m2ts' #or full path clip = vs.core.lsmas.LibavSMASHSource(file) clip = clip[1070,21350] clip = vs.core.avsw.Eval( 'mdata=DePanEstimate(range=5,trust=4.0,dxmax=-1,dymax=-1,stab=1.00)' 'DePanStabilize(data=mdata,cutoff=2.0,damping=10,initzoom=1.00,dxmax=6,dymax=6,method=1,mirror=15,prev=0,next=0,blur=30,info=false)' 'FrameSurgeon(cmd="20151224_132902 A FrameSurgeon.txt", show=false)' 'Morph(123,125)' 'Morph(135,137)' 'Morph(142,144)' 'Morph(977,979)' 'Morph(1206,1208)' 'Morph(1219,1221)' 'Morph(1237,1239)' 'Morph(1245,1247)' 'Morph(1255,1257)' 'Morph(1418,1421)' 'Morph(2183,2185)' 'Morph(2188,2190)' 'Morph(2197,2199)' 'Morph(12865,12868)' 'Morph(15723,15725)', #just make sure there is comma after last line of your avisynth script but not any above clips=[clip], clip_names=["last"]) clip = vs.core.resize.Bicubic(clip, matrix_in_s = '709', format = vs.RGB24) clip.set_output()
Last edited by _Al_; 18th Dec 2018 at 22:01.
-
@Groucho
I was using VirtualDub2_41867, with the newer VirtualDub2_43073 I get this dialog indeed. Applied the patch, it seems to have done the trick : now I can load the whole “B” script which failed to load before, it's compressing right now, apparently without hiccup. Memory usage is at 3340840KB, no wonder it was starved... And 2498284KB for the “A” script.
@_Al_
Radical solution for you might be switching to Vapoursynth 64 threaded beast, it just might work, loading your avisynth 32bit script into Vapoursynth64 using avsproxy.dll. Download from here or here(its dll and exe file, put it into Vapoursynths Plugin64 folder) . You can get rid of these memory issues. Then you just use VirtualDub2 64bit to load it in.
point is, forget about 32bit, install Python64bit, Vapoursynth64bit and get VirtualDub2 64bit
...
But the result of the stabilization by DePanStabilize is quite ugly, when watched in motion (the borders seem “liquid” in places, and there are weird artifacts, like a small brilliant object – a literal nail in the coffin actually – which “dances” every now and then, tried different parameters, it just changes which frames are affected), so I'll have to start all over again, and once again I'm at a loss... é_è I think I'll have to use Deshaker after all... I must be in Hell already, that's the only explanation...
Is there really no way to run Deshaker in YUV ? Will there be a significant quality loss when if I have to do a triple YUV<=>RGB conversion ? The alternative would be to run the interpolation filters without stabilization, then convert to RGB, then run Deshaker, but then I would have to review the whole footage AGAIN to look for badly interpolated frames, which I would have to interpolate AGAIN after rendering the whole movie, in the encoding script... Unless someone has a better/brighter idea ?...
@poisondeathray
Just the original thread at doom9. Someone mentioned looking at the source and building a 64bit version. It would make sense to make requests there. I know a few people nudged and bumped the thread recently (because I'm one of them)
You can definitely get better results doing it in other programs, but it's still a useful filter and one of the semi-frequently ones still missing from the x64 plugin list. I would also like to see it extended to 10bit; since 10bit is increasingly common in consumer space right now
I know you posted about interpolation errors - that's actually normal and expected. Some sets of settings might give you slightly better on some frames, and slightly worse on others. That' s the nature of interpolation . eg.blksize 16 might be ok for some, but 8 might be better for others. If you went through iterations with something like avsoptimizer, you might be able to calculate a best solve for a section optimizing dozens of parameters.
But in the time it takes you to do that, there are ways to fix with other programs too with masking / compositing / motion tracking .
There are user guided workflows that take track points and edge splines to guide the interpolation, so you minimize the blobby edge morphing artifacts. That's one of the main complaints and problems with interpolation - it's the incomplete object separation by the algorithms used, so you end up with morphing blobby edges. With other methods, you're practically guaranteed to get better results, but it depends on how much time investment you can put in . And some types of content are tough to interpolate no matter what
Getting a decent stabilization before the interpolations is more of an issue...
In the end, I'm sure your family will be happy, because it's the thought that counts. Spend more time with them, instead of in front of a computer
And even then it's not self-evident. I did that movie mostly for my older brother, who has a kind of mental disability roughly similar to autism, he was particularly affected by the death of our grandmother, especially two days before Christmas (he often has child-like reactions and behaviours, and Christmas is still very important to him); I rented a car in the hope that I could bring him with me to the funeral, but he insisted that he did not want to come, so at least I tried to establish a link of sorts through video, I had him put the jacket of a suit borrowed from a neighbour (he put that over his pyjamas !) to record him with my lousy camera while he was saying hello and explaining that he was very sad, and then, suddenly cheerful, went on to imitate the-woman-in-the-Adams-family-movie when she says “Donald Duuuuck”, to, quote, unquote, “pay tribute to Grandma” (it must have made sense in his peculiar mind). Then I recorded the whole ceremony, to have something to show to him, I felt bad about it, and I felt like it was considered offensive by some (even now, when reviewing the footage, I catch some disapproving looks staring right at me – or maybe I'm imagining things... in any case, whatever they thought then, they must have long forgotten, while I'm still ruminating all this !), but I felt like it was my burden and my duty to do it no matter what, pour la beauté du geste. Then I tried to show the little video of my brother to my uncle and aunts but they didn't seem that interested, although two of them agreed to say a word for him in front of the aforementioned damned device (I knew it had an issue but didn't realize that it was so severe), as well as our mother. Then I showed him those three videos and put them on his computer. So it's mostly about computers these days...
I promised him to make a movie out of all that, which should have been done in a matter of weeks, but there were many, many issues to overcome – plus many totally unrelated problems to deal with, so it got stalled for a looong time before I managed to produce a watchable first version, just in time for his birthday this year. Our mother and I rented an apartment for a few days to visit him (she hadn't seen him in almost four years, and it was only the third time in more than 25 years – yet they live about 200km apart), and he was utterly pissed off at first (think of him as Raymond Babbitt missing “The People's Court”). Then it got a little better – although his idea of fun was pretending that he was Obelix punching her in the air like an uninvited Roman (now that I think of it, he really felt like we were invading his territory...). I hoped that watching this together would bring them closer, give them something serious and meaningful to share, but it didn't happen, it won't ever happen, nothing will ever change, and I already know that when the day comes that she'll be put in a wooden box herself, I will be utterly alone. So it's mostly about waiting for everything to end these days...
And I guess that spending time in front of a damn computer is one of my fragile workarounds to not go completely crazy too soon. Because it's mostly about saving appearances these days...Last edited by abolibibelot; 19th Dec 2018 at 03:14.
-
You can use mdepan instead of depanestimate for depanstabilize, and get slightly better results, but deshaker is better 999/1000 times.
Deshaker runs in RGB only. There might be a way to use the log file to apply the transforms in YUV, but that's only the analysis part. You'd still have to emulate what settings the deshaker engine is using in pass 2. And guth has not released the source code.
The loss from several YUV<=>RGB conversions is not that bad compared to a shaky or poorly stabilized video . You can check yourself in avisynth with ConvertToXX() several times . The higher the quality the source video, the more easily easier you will see the loss . You can minimize the losses over sections where you only need to convert by only converting those section (instead of entire length)
You can do lossless YUV filtering on RGB source, but filtering each Y,U,V plane separately as Y8 then merging them back as R,G,B - but you don't necessarily get the same results than as if you applied the filter directly. But you can demonstrate that tranform is lossless
Or if some of the functions could be re-written in float (there is a vapoursynth mvtools that can run in float) , then it would be possible to interpolate without additional loss from RGB<=>YUV (you can convert losslessly if the intermediate calculations are in float) . Also if some of the interpolations were done at higher bit depths , that would minimize RGB<=>YUV losses as well (more precision, less rounding errors)
@poisondeathray
Didn't you say that you generally disliked “auto anything” ?
You can definitely get better results doing it in other programs, but it's still a useful filter and one of the semi-frequently ones still missing from the x64 plugin list. I would also like to see it extended to 10bit; since 10bit is increasingly common in consumer space right now
I know you posted about interpolation errors - that's actually normal and expected. Some sets of settings might give you slightly better on some frames, and slightly worse on others. That' s the nature of interpolation . eg.blksize 16 might be ok for some, but 8 might be better for others. If you went through iterations with something like avsoptimizer, you might be able to calculate a best solve for a section optimizing dozens of parameters.
But in the time it takes you to do that, there are ways to fix with other programs too with masking / compositing / motion tracking .
There are user guided workflows that take track points and edge splines to guide the interpolation, so you minimize the blobby edge morphing artifacts. That's one of the main complaints and problems with interpolation - it's the incomplete object separation by the algorithms used, so you end up with morphing blobby edges. With other methods, you're practically guaranteed to get better results, but it depends on how much time investment you can put in . And some types of content are tough to interpolate no matter what
Getting a decent stabilization before the interpolations is more of an issue... -
So in the mean time, I found some answers to some of my questions :
http://forum.doom9.net/showthread.php?p=1815546
=> No, Deshaker can definitely not accept YUV as input.
But “jagabo” wrote in 2010 :
“When people talk about lossless integer colorspace conversion what they usually mean is that you don't get successively greater errors if you convert back and forth repeatedly. So on the very first conversion from RGB to YUV you will get losses but if you turn around and convert that back to RGB and then back to YUV and back to RGB, etc you don't accrue more and more errors. I believe AviSynth has implemented this level of losslessness.”
Does that apply here ?
You can use mdepan instead of depanestimate for depanstabilize, and get slightly better results, but deshaker is better 999/1000 times.
Deshaker runs in RGB only. There might be a way to use the log file to apply the transforms in YUV, but that's only the analysis part. You'd still have to emulate what settings the deshaker engine is using in pass 2. And guth has not released the source code.
The loss from several YUV<=>RGB conversions is not that bad compared to a shaky or poorly stabilized video . You can check yourself in avisynth with ConvertToXX() several times . The higher the quality the source video, the more easily easier you will see the loss . You can minimize the losses over sections where you only need to convert by only converting those section (instead of entire length)
Look at the mvtools2 documentation . The filter wrapper might not expose those parameters nicely (they might be set to default values) . But there are dozens of settings that can affect the quality of interpolation and the results, and it's impossible to know which ones work better for some sources or scenarios, you basically have to try or do testing . Even on the same scene, a certain set of settings might be ideal for frame 1 but a completely different set for frame 7 etc...
(Quote : “I think that the only person that really understood mvtools usage (excluding original authors) was probably Didee, and he only very rarely visits (maybe in response to some particularly inciting post). I certainly dont fully (or even halfly, quarterly) understand mvtools, is almost a total mystery. Best one can do is read the docs/examples and try to make some sense of it. If anybody ever did write a mvtools 'guide', he would have a monumental task on his hands, methinks.”
It's a more advanced workflow , too much to describe in a post. But the general idea is mattes and rotoscoped shapes define areas of foreground / background subjects , and track points can plug into the interpolation engine, so the results are generally better. It requires user intervention.
The main issue with all interpolation / optical flow approaches is incomplete separation (there are a bunch of other issues too, but that's the main one; if you're interested I posted quite a bit about this at doom9) . e.g. if a hand crosses in front of a body, you lose the outline of the hand. Or legs cross in front of each other, you lose separation between what is what. That's why you get the blobby morphing blended artifacts instead of a clean frame.
Deshaker, or complement by fixing problem areas with other programs (you can use motion tracking, user guided stabilization too) .
But again, more involved , but better results . Deshaker can have problems; any "auto" stabilizer can. For example , a car zooms past in the foreground and the stabilization gets skewed . Very common problem.
“Remember discarded areas to next frame : When enabled, this feature makes Deshaker try to ignore approximately the same areas from one frame to the next. Deshaker will then become a lot more successful in ignoring moving objects. As long as they enter the scene rather slowly (by not covering too much of the background), Deshaker will usually be able to ignore those objects even if they eventually grow to cover most of the frame.”
Other common problems are cmos/rolling shutter jelly - deshaker can address it but only to a very limited extent.
Side question : I have a few thousands frame interpolation commands for FrameSurgeon, in a text file containing lines like :
Code:I1 165 # means that frame 165 will be interpolated I2 168 # means that frames 168 and 169 will be interpolated ...
-
No ; for avisynth, the more conversions, the more loss at 8bit (and for every other program it's true too).
There are various lossless RGB<=>YUV transforms, but they don't apply here and you always need at least +2-3 more bits required for the intermediate before going back
You can reduce the amount of losses by working at higher bit depths, but your other program needs to be able to do that too . Can the other program handle RGB30 (10bit RGB), RGB48 (16bit RGB) , or float formats ? Unlikely in a consumer video editor
And referring to the quote above, is it correct that only the first RGB=>YUV conversion is lossy in Avisynth ?
Look at the mvtools2 documentation . The filter wrapper might not expose those parameters nicely (they might be set to default values) . But there are dozens of settings that can affect the quality of interpolation and the results, and it's impossible to know which ones work better for some sources or scenarios, you basically have to try or do testing . Even on the same scene, a certain set of settings might be ideal for frame 1 but a completely different set for frame 7 etc...
(Quote : “I think that the only person that really understood mvtools usage (excluding original authors) was probably Didee, and he only very rarely visits (maybe in response to some particularly inciting post). I certainly dont fully (or even halfly, quarterly) understand mvtools, is almost a total mystery. Best one can do is read the docs/examples and try to make some sense of it. If anybody ever did write a mvtools 'guide', he would have a monumental task on his hands, methinks.”
It's a more advanced workflow , too much to describe in a post. But the general idea is mattes and rotoscoped shapes define areas of foreground / background subjects , and track points can plug into the interpolation engine, so the results are generally better. It requires user intervention.
They are different types of tracking and stabilization software , used for different purposes. Deshaker is more like a general use stabilizer. And overall it's good. But there is no ability to adjust scenes or adjust inclusion / exclusion areas (except at the frame edges) . So in that respect , it's not suitable for compositing or visual effects type trackers which require accuracy. Deshaker wouldn't be accurate enough to match move or do composited patch repairs . Different types of visual effects trackers , can track separate objects, or background, or foreground, or whatever. You can tell it what to track or ignore. You can stabilize around a specific object or background, instead of a general smoothness.
DePanStabilize's method=-1 is descibed as “tracking of the base (first) frame instead of stabilization” – I haven't tried this as it seems completely different in purpose.
Side question : I have a few thousands frame interpolation commands for FrameSurgeon, in a text file containing lines like :
Code:I1 165 # means that frame 165 will be interpolated I2 168 # means that frames 168 and 169 will be interpolated ...
-
Now Deshaker is giving me random black frames, which produces some funky results once interpolated by FrameSurgeon :
(Perhaps it's dumbfounded by the horror of the suit jacket over the pyjamas...)
I'm going to scream !
Probably easier to get StainlessS to implement it as a debug view in his script
Code:Dv, Default 0, ClipClop and Prune DebugView level (0 - 4, Need DebugView utility)
I've also found interesting insight in this 10 years old thread :
https://forum.doom9.org/showthread.php?t=136025
The script proposed by “g-force” is quite effective at suppressing small vibrations, but alas it's confused by those damn blurry frames : if frame n is blurry, meaning that the edges are doubled, it will align frame n+1 with either the upper edge or the lower edge of n, instead of ignoring it and aligning it with n-1 instead.
This statement reflects my experience thus far :
“I've never been able to dial in the settings for DePanStabilize to be of any use. Doesn't fix quick jitter, and tracks slower pans too well.”
Some general advice for using DePanStabilize :
“The 'trick' with [DePanStabilize] is: use a different (cropped) clip for DepanEstimate. What to crop? It depends on the scene... Focus on something that should not move... A house or something. I use tweak(bright=-100,cont=2.0) on this clip too... Somehow this helps, too.
Also, I nearly always set cutoff to 0.5 and trust between 1 and 1.5.
The same values for dxmax and dymax both in DepanEstimate() and in DepanStablize helps... (30 is a good value)
Sometimes I get better stabilizing with Depan then with Deshaker.. It realy depends on the source.”
I haven't tried the cropping trick, I'm not sure where I should crop to improve the efficiency, in this particular case, most of the shots are, or should be static, so I don't see how cropping could improve the efficiency, while a few shots have motion everywhere, so cropping around a particular spot on a given frame would be pointless since 5 frames later the picture's content is completely different.
The last suggestion works only with method=0, which in my tests gives very poor results.Last edited by abolibibelot; 19th Dec 2018 at 20:10.
-
Maybe you have too much going on there. I would split it up. Easier to debug too. Deshaker to a physical file
But take it step by step, are you sure it's deshaker in avisynth ? Comment out the rest of the script and seek around with Lsmash only - because LSmash and transport streams can have problems too
Probably easier to get StainlessS to implement it as a debug view in his script
Code:Dv, Default 0, ClipClop and Prune DebugView level (0 - 4, Need DebugView utility)
libvidstab is ok, but deshaker is clearly better in terms of results. Just like deshaker is clearly better than depanstabilize (with either mdepan or depanestimate) , at least in that general purpose stabilizer / hand held scenario . I don' t know anyone that would say otherwise. Zero. -
Maybe you have too much going on there. I would split it up. Easier to debug too. Deshaker to a physical file
But take it step by step, are you sure it's deshaker in avisynth ? Comment out the rest of the script and seek around with Lsmash only - because LSmash and transport streams can have problems too
And yes I checked, by placing “Return(last)” at different spots in the script. Besides, it worked fine with Depan so it's most likely due to Deshaker. Apparently it doesn't like when a frame is accessed directly, instead of linearly from the begining. Also, just tried loading the Avisynth script containing the Deshaker command into VirtualDub2 (which is now patched with “LAA”), it plays fine when moving forward, but as soon as I go back 1 frame it turns black, and stays black, and all following frames are black. The “extrapolate colors into border” feature is said to be very slow, so it might be too demanding for real-time processing, I dunno... (That's another dilemma : zooming in by a fixed factor will soften the picture and cut people's faces in some places, but trying to interpolate borders seems to produce an ugly result more often than not.) -
But take it step by step, are you sure it's deshaker in avisynth ? Comment out the rest of the script and seek around with Lsmash only - because LSmash and transport streams can have problems too
And yes I checked, by placing “Return(last)” at different spots in the script. Besides, it worked fine with Depan so it's most likely due to Deshaker. Apparently it doesn't like when a frame is accessed directly, instead of linearly from the begining. Also, just tried loading the Avisynth script containing the Deshaker command into VirtualDub2 (which is now patched with “LAA”), it plays fine when moving forward, but as soon as I go back 1 frame it turns black, and stays black, and all following frames are black. The “extrapolate colors into border” feature is said to be very slow, so it might be too demanding for real-time processing, I dunno... (That's another dilemma : zooming in by a fixed factor will soften the picture and cut people's faces in some places, but trying to interpolate borders seems to produce an ugly result more often than not.)
Probably the most consistent source filter is DGSource/DGDecodeNV, but it's not free and requires a compatible Nvidia card. But it indexes the file, so it's robust , even with non linear seeks. A side benefit is offloading from the CPU . ffms2/lsmash index the file too, but they can exhibit flaky behaviour with transport streams. It's a well known issue.
LSmash is probably ok for linear seeks, or something simple... but you have clipclop /framesurgeon there on top, that requires non linear access. It's very tough on a long GOP source, probably making a large contributing to your memory issues as well
The border options are tough to decide on, they all have compromises. You have to decide on what sorts of trade offs you're willing to make
This is the sort of scenario where it helps to have interactive / keyframable settings. Instead of 1 set of settings, it's nicer to be able to make adjustments. eg. Maybe on some close up shots, you don't want to soften so much but can take a bit less steady as a trade off, or maybe the border fill works on one scene ok etc...Basically tweak it as you go, or fine tune the settings. So although deshaker is overall very good, it doesn't have those type of adjustable settings on the fly (or at least not easily; I guess you could cut it up and sort of frankenstein it together) -
Regarding the issue of displaying only the interpolated frames, I tried this dirty method : opened the command file in Calc, with spaces as separators, removed the “I” at the begining, added a column with a value calculated as [B] + [A] - 1, added columns with “Trim(” / “,” / “)”, then exported as .csv, edited that with WinHex to remove the x09 separator character and replace the new line symbols with “ ++ ”, exported that as .avs, added an AVISource command... It works but very slowly, AVSPMod (or Avisynth) seems to choke with so many Trim commands (1387). Is there a practical limit to the number of Trim segments, or the length of an Avisynth command in general ?
I found a function named AdvancedMultiTrim, which seems to be designed for that purpose, but right now I wouldn't know how to convert such a list into a list of individual frames (must be very simple to program such a thing, but I know next to nothing about programming).
Similar Threads
-
Creating AVS script in MeGui
By Manxsee in forum Video ConversionReplies: 2Last Post: 12th Jun 2018, 13:24 -
Creating AVS script in MeGui . .
By Manxsee in forum Newbie / General discussionsReplies: 1Last Post: 12th Jun 2018, 12:31 -
VirtualDub2 edit a MKV then save to MKV with no compression
By Marco33 in forum EditingReplies: 12Last Post: 5th May 2018, 22:39 -
How to resolve some errors with avs script?
By robusco in forum Video ConversionReplies: 12Last Post: 4th Dec 2015, 13:37 -
Cant get AVS Script to work
By bob52 in forum Newbie / General discussionsReplies: 6Last Post: 6th Feb 2014, 13:27