The "Black" wasn't the 30 frame thing - ALL the clip was black.
However, now, this morning after rebooting and kickin' the PC (joking!), I NOW have a Take2, it is NOT Black and is now supplying steadied output. I've now tried used Uncompressed Outbound.
Question1: What should I be doing with the Outbound and Inbound? I have been able to recreate what I was getting yesterday and that was electing for PAL Widescreen In- and Outbound. Would that do the Black media coming back?
Question2: What should I be experimenting with the Deshaker Filter?
The "Black" wasn't the 30 frame thing - ALL the clip was black.
OK but could it be added as a third take and if so was it ok?
Question1: What should I be doing with the Outbound and Inbound? I have been able to recreate what I was getting yesterday and that was electing for PAL Widescreen In- and Outbound. Would that do the Black media coming back?
I'm at a loss to explain how a reboot would cure the problem - is that drive an external one? If it was the choice of DV codec outbound I wouldn't expect kicking the PC to have any effect - it would be black and stay black.
I usually do uncompressed outbound and inbound. Occasionally if I'm dealing with MPEG2 from a DVD on the timeline, I will use the optional compress on inbound using a DVD-compatible template so that on my final render I get as much "No recompression required" as possible.
Question2: What should I be experimenting with the Deshaker Filter?
Since writing the script, I've barely had a chance to experiment with the dialog I created for the filter. This would probably be worth a post on the main forum because I'm sure some people use the filter stand-alone and would be able to help.
I want to add "presets" into New Deshaker and it would be nice to have some available as part of the standard package.
I went through your deshaker settings from the logfile you sent me and I can see that you have selected "Generate interlaced progressive video" on the Deshaker dialog.
From the Deshaker documentation:
Generate "interlaced progressive" video
Usually, Deshaker will generate video with the same video type (interlaced/progressive) as the source video. But if you enable this setting it can turn interlaced video into progressive video with twice the framerate. Since VirtualDub doesn't allow changing frame rate, two progressive frames are interlaced into the same output frame. So in order to get the true progressive video you must separate the fields of this video afterwards. You can do that with AVISynth and its SeparateFields function (and a preceeding ComplementParity for "upper field first" video). You should never deinterlace this video in any other way than to simply separate the fields.
Uncheck that setting on Pass 2 and you should be ok.
So, how is this an improvement on John Meyer's?Grazie, this is a HUGE improvement on my hack. I can think of no reason you would ever want to use my stuff again.
1. You can set the deshaker settings directly from Vegas. Thus, if you don't like something, you can change it.
2. You can change all the places where you want to put things. Lots of people didn't want to put files on the C: drive, or want to change where rendered files go.
3. You can more easily change render templates (although I have a question on that below).
4. Perhaps most important, you can now use the latest version of deshaker. Supposedly this has support for multi-cores and should run faster, although I haven't been able to tell any difference between this version of deshaker (2.4) and the two versions older one that was bundled with my script (2.0).
This newer version of Deshaker has quite a few additional settings that better handle recreating edges. This is really important.
5. The script is written as a DLL which means it can't be altered and, therefore, broken.
6. The script is written to work with the latest versions of Vegas. I guess perhaps that is the one reason for still using my script: if you use any version of Vegas prior to V8.x.
Question for Andy:
I am still confused about the two settings at the bottom of your main dialog. The first is a setting called VirtualDub Compressor and is set to "0." I found that I could put the FOURCC codec code into that dialog and that this would then cause VirtualDub to use this codec when compressing deshaken video. For instance, if I enter "hfyu" then VirtualDub uses the HuffYUV codec. Or, "dvsd" and it uses the MainConcept DV codec or "cfhd" and it uses the Cineform codec. This is the same as my script, and I included those codes in the comments section so hackers could change it.
However, below this setting, you have another called compress inbound. I played with this and I think what this does is to take the deshaken video coming back from Deshaker, and before it adds it as a take, it has Vegas, not VirtualDub, convert it to some other format. When I tried this out, it seemed to work, but the overall time to deshake a few events seemed to be MUCH longer than just having VirtualDub handle the encoding to something other than uncompressed. The flip side is that it gives you access to the quality codecs inside of Vegas, and not everyone has external codecs they can use.
Is my understanding of this correct?
P.S. I'll try to get some time this week to put together a few presets along the lines of what you see in some of the commercial products. I may not have time to do this, but I'll try.
This is the same as my script, and I included those codes in the comments section so hackers could change it.
John,
Absolutely. This is the bit that will be replaced with the VirtualDub-like compression dialog. I simply made it a free editable box to type in a FOURCC code (in fact on the download page I do document that fact).
The flip side is that it gives you access to the quality codecs inside of Vegas, and not everyone has external codecs they can use.
Again absolutely. I originally added this in to an amended copy of your script and because I used it, I kept it in the C# version I ported.
Regarding the speed. When I first ran it against version 2.4 I was convinced it had gone wrong because it completed so quickly.
Grazie,
If you are completely happy with John's version, there's absolutely no reason to change. It worked yesterday, it will continue to work tomorrow.
Andy
edit: The H: drive is an internal physical drive.
No I meant the drive where the deshaken video ends up.
Another idea/wish to your future development of the New Deshaker:
The possibility to chose if you strip the media for all FX'es, Pan/crops etc. OR NOT.
Why?
I record a lot of handheld things (in AVCHD 720p mp4) and therefore 80 percent of my matertial must be deshaked.
This is actually an advantage, as I do it with your script and let it render to m2t which also is the final format - and so I must not recompress any more when rendering finally and save one step which would take time and induce noise.
Some of the material also needs some heavy denoising through Neat Video, some Color adjustments etc. and it would be nice if all this could be done once and for all in the first step where you let Vegas render the clip to out00001.avi
Another idea/wish to your future development of the New Deshaker:
I certainly will not argue against having additional options for the user. However, when I worked on my the crude script/hack which preceded Andy's excellent, professional version, I very deliberately removed all fades, fX, and pan/crop prior to doing the deshaking. You pretty much HAVE to do this if you are going to add the result back as a take, because the things I just mentioned get applied to the raw video, and if you render using those effects, the result will be that they will be applied twice, which is obviously not what you want.
If you want to render the deshaken video with the fX (and perhaps pan/crop) intact, then they will have to be added back to the the timeline instead of the original video, or perhaps on a new timeline by themselves. Either of these options could work, but the original idea of putting them on the timeline as takes (which was the idea of the original author, David Arendt) still seems to me to have so many advantages that I would still prefer to do it that way.
The other big advantage of NOT applying the fX to the deshaken footage is that those deshaken events can then be used in some other project, where you probably would not want to have the same fX applied.
One final note. If you want to use the dehaken events elsewhere, I'd recommend considering using an embedded VEG file that refers back to the original project. That way, if you are trying to match fX, any changes you make in the original project will automatically be reflected in any other project that uses those same deshaken events, without having to go back and re-render everything.
johnmeyer wrote: but the original idea of putting them on the timeline as takes (which was the idea of the original author, David Arendt) still seems to me to have so many advantages that I would still prefer to do it that way
I can not argue against that - however it really depends on the way one is working with his media.
In my case I edit the video fully - with my clips in AVCHD on the timeline. With color adjustments, pan/crop, FX'es and so on.
Finally I render to "semi final" and watch the video several times on the large Plasma and apply the final adjustments.
When this is done, I apply the Deshaker on 80-90 percent of the material and let the Deshaker deliver its result in the same m2t format, that I render the final video to. From now on Vegas renders using the "No Recompression Required" mode. (BTW another GREAT feature in Vegas)
If the Pans, FX'es etc are NOT removed before Deshaking then they will prevent Vegas from using the "No Recompression Required" mode for the final render and so make Vegas decompress + apply Pans, FX'es etc and then compress again - and so add a noticeable loss of quality.
Therefore my idea to apply the Pans, FX'es etc at the same time as Vegas renders to avi for the Deshaker.
Another of your arguments is possible reuse of the deshaken takes - Well at least in my workflow this is quite desireable albeit not possible - because many of my videos are synchronized to different pieces of music, so that the same take could be, say, a multiple of 3.5 seconds in one video and of 4.2 seconds in another.
Writing my wish I did think of the double Pan, FX'es problem as you mention, but did not write about them thinking that Andy would delete them by himself from the deshaken take.
Finally Vegas has the "Undo Run Script" feature - so no unrecoverable harm is done and you can always fine-tune Pans, FX'es and then run the Deshaker again.
More finally I did not want my idea as the Modus Vivendi of the New Deshaker - just an option - which by default, of course, should be the way it works today.
If you want to render the deshaken video with the fX (and perhaps pan/crop) intact, then they will have to be added back to the the timeline instead of the original video..
This is close to what I was planning to do. I had in mind that unselecting the "remove fx prior to deshaking" (for example) option will, in fact, cause them to be removed from the original event after the new take is added. The default will be removal as per the original script.
Obviously the knock-on effect is that these settings (pan/crop, fx etc) will be lost to the original take.
Edit: Actually, it would be possible to set the "bypass" flag on all the effects on the original event rather than removing them.
Edit: Actually, it would be possible to set the "bypass" flag on all the effects on the original event rather than removing them.Can that be done an a per-take basis? I just tried it, and once I deselect the fX in the event dialog, if I then change to another take, that fX is still deselected. I think I understand the request, but I am not sure that you can do what is asked unless you put it on a separate timeline. True, you can simply replace the original event, but then you've lost any reference to that event, and the edits and trims and grouping and other things that have been applied. Since deshaker often results in footage that has artifacts, I often find it necessary to go back to the original footage and either re-do the deshaking after editing the event (usually splitting it at the point where deshaker has a problem and then deshaking each split event separately), or just using the original unshaken footage.
So, whatever gets done, I think you have to provide a simple way to review and compare the deshaken footage to the original.
Also, while I will never, ever argue that someone else's workflow is not valid, I should point out that any workflow where you end up doing some fX on some footage, and then subsequently doing something else to that footage later on needs to be done very carefully. Many fX are subtle, and unless you label your media carefully, it may not be obvious whether the footage has been color graded, sharpened, blurred, cropped, etc. I would be very concerned about accidentally applying some of these more subtle changes more than once.
However, whatever Andy does will be good stuff because it is obvious (to me at least) that he really knows what he is doing.
Can that be done an a per-take basis? I just tried it, and once I deselect the fX in the event dialog, if I then change to another take, that fX is still deselected
Nope. It's per event. At least with the FX they can merely be disabled - with pan/crop they're gone.
However, this will be implemented as an option (and not the default one). If you choose to uncheck the "Remove FX prior ro render" or "Remove Pan/Crop settings prior ro render" checkboxes, a warning dialog wil be shown explaining the ramifications of the action. The tooltips will also make it clear as well.