NEW NewBlue Video Stabilizer

Comments

megabit wrote on 2/24/2010, 5:16 AM
Is it also you finding that with the 64-bit version of the NB Stabilizer , Vegas (64bit of course) renders much slower than the 32bit version?

AMD TR 2990WX CPU | MSI X399 CARBON AC | 64GB RAM@XMP2933  | 2x RTX 2080Ti GPU | 4x 3TB WD Black RAID0 media drive | 3x 1TB NVMe RAID0 cache drive | SSD SATA system drive | AX1600i PSU | Decklink 12G Extreme | Samsung UHD reference monitor (calibrated)

Ninan wrote on 2/24/2010, 5:20 AM
Stabilization of individual clips worked ok for me (VMS Platinum 90b). However, after having applied NB Stabilizer clip by clip to the timeline of a longer earlier edited project, VMS crashed during the rendering, reporting error the source of which could not be identified. This has happened several times, both with the old and new, supposedly fixed, version of the Stabilizer. It seems that the error occurs when the first transition is encountered.
Laurence wrote on 2/24/2010, 5:21 AM
Well the stabilizer shouldn't crash at the transition point, but after the transitions are in it's too late to stabilize. If it didn't crash it wouldn't look good anyway.
Ninan wrote on 2/24/2010, 5:43 AM
Thanks Laurence. But the message is the same after putting together the earlier stabilized clips and consequently inserting transitions. The first transition point - the rendering reports error - VMS hangs.
NewBlueFX wrote on 2/24/2010, 5:46 AM
Yes, I got your screen shots and they were very helpful. Forgive me for not replying - I've been swamped (a good swamped, though.)

Thanks,

Todor
NewBlueFX wrote on 2/24/2010, 6:59 AM
We are unable to repro your problem with transitions. I'll send you a note with contact information so you can send us more details on how to make this happen.

Thanks,

Todor
Tom Pauncz wrote on 2/24/2010, 7:21 AM
Just to confirm, I couldn't repro this on Pro 9.0c.

Three clips on t/l, mixed formats. Applied NB to all clips separately, then moved them over for transition. No problem rendering.

Changed transitions to something other than default, still no problem.

Also tried to apply NB after clips overlapped, no problem either applying NB or rendering.

HTH,
Tom
bigrock wrote on 2/24/2010, 10:59 AM
After the latest update I was able to do the analyze on video that was originally failing. It was MJpeg video in a Quicktime container (MJpeg in an AVI container worked ok for me).

Here is some sample videos I posted last night (start them at the same time so you can compare the two):

This is video with pure default settings on the NewBlue Stabilizer:



This is the video with no stabilization at all:



I do believe it is capabable of better quality than what is produced with the default settings and I will post a new sample when I have it. So far I think it works fairly well and is easier than the old deshaker.
johnmeyer wrote on 2/24/2010, 12:27 PM
Bigrock,

If you will give me permission, I can post your same footage, stabilized with Deshaker, just so people can get a comparison. I was able to download from YouTube your footage in 1080p resolution. However, since it is copyrighted and has your bug/logo on it, I don't feel I should re-post it without your permission.

The Deshaker footage you'll see, if I do upload it, is far more stable than the NewBlue footage. However, that may be misleading because I used some very aggressive settings and you may have used the NewBlue defaults. This is one of those things that makes comparisons really difficult.

Also, FWIW, using these settings I got a rendering "framerate" of about 1.5 fps on my very fast 8-core i7 (and the newest Deshaker does use all 8 cores). In other words, really slow. I then tried using something closer to the defaults that ship with the DLL version of the Deshaker script, and got 6 fps during the analyze phase. Either way, it is pretty slow on thie 1920x1080 footage (which I had to convert to uncompressed, which means that disk access times, even on my super-fast drive, get to be a factor).

So let me know if I can post.

Thanks!
jetdv wrote on 2/24/2010, 1:02 PM
Bigrock: This is video with pure default settings on the NewBlue Stabilizer:John: However, that may be misleading because I used some very aggressive settings and you may have used the NewBlue defaults. This is one of those things that makes comparisons really difficult.

Yep, default vs aggressive...
Laurence wrote on 2/24/2010, 1:12 PM
A little bit of shaking of the logo I imagine!
bigrock wrote on 2/24/2010, 2:07 PM
John I set you a couple of emails. Please post the Deshaker settings you used and I will run it here and post it tonight. It should run way way faster on my machine as I have the original media and it is not uncompressed.

I have several other setting combinations uploading right now. One with the Static Cam preset and border method set to Fit with 100% cropping, and one with the Static cam preset and border method set to Replicate and cropping at 0%.
enespacio wrote on 2/24/2010, 2:13 PM
Here's the best comparison that I could compile between NB and Vdub deshaker with a very shaky clip. Bear in mind this is the first time I've tried either one of these.

I've tried multiple settings with NB Stabilizer. The best results I've gotten so far were using Default Stabilization with Strength set at 76, Border fill set to Fit, and Crop set to 100.

]

I've always wanted to try Vdub deshaker, but was intimidated by it. I decided to dive in anyway and am glad that I did. I found it no harder to tweak than NB. I checked the "Camcorder has a rolling shutter" box and used the "Fixed zoom" option on Pass 2.

]

I'm not sure which is better. My advice to any other "noobs" out there like me, is to take a stab at Vdub. I may still buy NB after more testing. I own all of their Video Essentials and like them very much.

James
johnmeyer wrote on 2/24/2010, 6:32 PM
Please post the Deshaker settings you used and I will run it here and post it tonight. I have sent, via PM, a link to an MP4 file that has the deshaken footage. However, as already mentioned, after the deshaking, the logo moves all around (I excluded the logo from the first pass analysis, but there is no way to stop it from being moved during the deshaking process).

Since I am using the Andy Edmiston DLL script, it has the ability to import and export the Deshaker settings. If you use that version of the Deshaker script (instead of my jscript version) you should be able to save the following to a text file, and then use the "import" function in the DLL script to import and use these settings.

Here they are:

JHM Best=12|1|30|4|1.33333|7|1|0|640|480|0|1|1|8000|8000|8000|0|4|1|0|2|5|40|300|4|e:\Deshaker.log|0|1|0|0|0|175|0|0|0|0|0|0|0|1|99|99|99|1|1|1|30|30|0|0|0|0|1|1|1|10|1|15|1000|1|88
bigrock wrote on 2/24/2010, 8:55 PM
I've put the 5 sample clips so far as the first post of a new thread so it is easier to find.

The new thread is http://www.sonycreativesoftware.com/forums/ShowMessage.asp?ForumID=4&MessageID=698082
GlennChan wrote on 2/24/2010, 10:39 PM
Have any of you tried using a 1-point motion tracker to stabilize footage, like in After Effects or Shake?

1-point motion tracking goes really fast, and then afterwards you have to zoom the picture larger and manually stick in the camera movements you want (or if you want no movement, you just zoom in).

Compared to the optical flow camera stabilization Smoothcam node in shake... the smoothcam is a waste of time.
redpaw wrote on 2/25/2010, 5:43 AM
sorry megabit for the delay... yeap 64 version takes way looooonger to process.
the same clip (3min long) takes 16'15" to analyze in 32bit vegas 9.0c and 19'55" in evgas 9c 64bit.

now, what i noticed and i think that anyone has pointed that out yet is... that the plugin uses ONLY 1 CORE! now, c'mon! be serious! no wonder it takes ages!

checked Mercalli's demo and it very nicely utilizes all the cores - the way it should be!
didnt get a chance to check deshaker yet tho.
but that totally pulled me back from buying at the moment. looks like it's tiem to get familiar with virtualdub again :)
Jay Gladwell wrote on 2/25/2010, 6:38 AM

"... the plugin uses ONLY 1 CORE."

It's using all four on my machine.


Tom Pauncz wrote on 2/25/2010, 7:22 AM
On a relatively short clip, it appears to use only 4 out of 8 on my system.
Tom
redpaw wrote on 2/25/2010, 7:27 AM
hmm... i tried it on 32bit and 64bit version of vegas - both times cpu usage was ~10% with only 1 core used ;/
looks like i'm gonna have to have a proper look into that so
redpaw wrote on 2/25/2010, 7:36 AM
Tom, i assume you're using 32bit version of vegas? in preferences->video the maximum number of rendering threads is set to 4. that's all you can get. so unless you;ve got 64bit version you wont be able to use them all in vegas.
Tom Pauncz wrote on 2/25/2010, 8:12 AM
Actually that's not quite correct.

I know the default/max is 4 but when you get into the internal settings (not recommended for novices), you can set it to the number of cores you actually have.

Mine is set at 8. And yes, it's 32bit on WinXP-SP3.
Tom
redpaw wrote on 2/25/2010, 3:25 PM
yes you can... but i dont think that it makes a difference in 32bit version (well - going up to 8 anyway), there's a reason why it's set to 4 and i believe it's because (but correct me if i'm wrong - and i wish i were!) 32bit cannot make use of more then 4. if i set it up to 8 in internal pref and then will try to change it in video options it says 8 but after closing it and opening again its back to 4.
now, the way around (kind of) is to turn off Hyperthreading in BIOS - it'll 'reduce' the number of cores to 4 but you'll be able to use them 'more'. and if 32bit version is your main app it might be the way to go. i'm using mostly x64 - so i'll rather stay with 8.

now, i checked this plugin with vegas 8.0c and 8.1 and still no sign of if getting any use of the more then one cores! what am i doing wrong?!
A. Grandt wrote on 2/26/2010, 1:24 AM
I took some clips I made a little over a year ago with a Sony HDR-SR11E. Hand held, and wobbly.

It looks like the NB stabilizer have a problem with interlaced video, as I get a severe sawtooth effect on the default settings. Either that, or I'm doing it wrong.

The two short clips are here:
[url=http://www.grandt.com/Vegas/00000.MTS]
A slightly too fast, (VERY) unsteady pan right to left

[url=http://www.grandt.com/Vegas/00001.MTS]
A slow left to right pan, no too steady.