Log in

View Full Version : How to DeShake 50i camcorder m2ts?


Cela
18th May 2010, 23:06
Don't know if I should post here or in Avisynth Usage. Since I use may avisynth script within VirtualDub, I decided to try it here.

My camcoder produces AVCHD 1440x1080/50i. Its the _i_ which makes it getting hard!
I run into a problem when I try to define Pass 2 in Filters for Deshaker v2.4!
I used Gunnar Thalin's "The Short Guide":These are the minimum number of steps you must make in order to stabilize a video clip:
1. Open your video clip in VirtualDub (menu: File/Open video file).
2. Add the Deshaker filter (menu: Video/Filters, click: Add, double-click: Deshaker).
3. In the Deshaker configuration dialog that appears, select the correct Source pixel aspect and Video type, and click OK to close.
4. Step through the video in some way (for example using File/Preview filtered in VirtualDub). No useful video is created during this first pass.
5. Open the Deshaker configuration dialog again (menu: Video/Filters, double-click: Deshaker line), and select Pass 2 by clicking on it. §)
6. Encode the video the usual way (menu: File/Save as AVI). At the transition from step 5 to step 6 there was the problem!
>Establish Pass2 in Video, Filters,...: leaving VirtualDub's filter pane with OK does NOT return into VirtualDub main GUI window to enable step 6 (e.g. Queue batch operation, Save as AVI...), BUT starts to do some processing in the background, which does not end within a reasonable time for a setup of Pass 2 processing.

To be more specific:
>click OK to close the Pass 2 filter setup within the filter works ok.
>>click OK to close the VirtualDub Filter pane does not finish! So I never get to step 6!

Instead a small Deshaker window pops up with the message "Deshaking..."! *)

*) Problem solved!
At that point I would expect it simply to store the filter setup somewhere in memory or elsewhere so that it knows what to do when executed in step 6 of the guide.
This seems to take not seconds but several minutes!

Anyway, after leaving it as described above, when I came back some time later, VirtualDub was in idle state waiting for input. Then I could carry on with step 6 from The Short Guide: "6. Encode the video the usual way...".
Some two hours later I will know if Deshake will be successful!

§) WARNING: Be patient! It can take several minutes before VirtualDub gets ready for the user to continue with step 6 of the guide! I may have overlooked this warning.

Deshaker v2.4 yields awesome results.
in http://forums.virtualdub.org/index.php?act=ST&f=5&t=17772& starting from page 2 there are procedures and scripts described which can automate the whole process!

And here's a demo which demonstrateshow wonderful deshaker is... FWIW
http://www.vimeo.com/groups/avchdlite/videos/6872650

Help yourself.... ;)

wonkey_monkey
19th May 2010, 17:10
If I remember correctly the length of time taken to do the deshaking is proportional (?) to the magnitude of the "smoothness" variables you assign. I think there could be room for optimisation (and make it proportional only to the number of frames in the video)... but it is still superb.

David

Cela
20th May 2010, 20:33
I am not taking about the length of time taken to do the deshaking.
What concerned me is the length of time taken to set up the pass2 of deshaking, i.e. the length of time taken at the very end of step 5 of Gunnar Thalin's "The Short Guide" leaving the Filters setup window in Virtual Dub! At that moment Deshaker filter apparently can still be busy with its setup, and if so, it appears to be connected with the existance of C:\Users\me\AppData\Local\Deshaker\Deshaker.log and its current size. If there is no such file left over from a previous run, then there is no delay. If that file exists from a previous run and is pretty large, then I experience a fairly long delay for a Filter setup stage, and I may take a coffee break of some minutes.

I know, and it is ok for me, that deshaking execution takes its time depending on the length of the input video, the filter setup and of the power of the computer. My recent test (including within the avs script Yadif deinterlacing, resizing and transcoding from m2ts to Xvid) took for pass1 05:16 h and for pass2 03:09h, giving a total of 08:25h, and giving a perfectly deshaked result.

Can anybody confirm and explain the unusual filter setup behavior?

wonkey_monkey
20th May 2010, 23:15
I am not taking about the length of time taken to do the deshaking.

I don't want to sound contrary, but I think you are talking about the deshaking - the dialogue box that pops up does say "deshaking...", after all.

Can anybody confirm and explain the unusual filter setup behavior?

What happens, in simple terms, that after you've set up Pass 2 and closed the filter window, Deshaker then does all of the deshaking calculations. These determine the transformations to be made on each output frame, but does not actually perform those transformations - that's done on the fly as you request each output frame.

These calculations take a long time because for each output frame the calculation is a "window" over x input frames, the value of x depending on your smoothness parameters.

David

PS I don't speak for guth, this is just my supposition based on experience writing similar filters, and some hints from guth in another thread.

Cela
21st May 2010, 21:02
... What happens, in simple terms, that after you've set up Pass 2 and closed the filter window, Deshaker then does all of the deshaking calculations. These determine the transformations to be made on each output frame, but does not actually perform those transformations - that's done on the fly as you request each output frame.

These calculations take a long time because for each output frame the calculation is a "window" over x input frames, the value of x depending on your smoothness parameters.
...David, thank you for your help! :)
Now I may begin to understand: If pass 1 results are available (even as a leftover from a previous job), that is, if Deshaker.log exists within directory C:\Users\me\AppData\Local\Deshaker\, Deshaker begins straight away with some preliminary calculations before any request for a frame output.
In my case this may be premature, since I am just beginning to schedule a new job.

For each job to be scheduled
1. I first make the setup for step 1 and 'Queue batch operation' for step1, then
2. make the setup for step 2 and again 'Queue batch operation' for step 2.

This being so, couldn't I simply cancel these Deshaker calculations without waiting for them to finsh?
These get me stuck just at the end of filter setup for the future step 2, just before I can do the 'Queue batch operation' for step 2.
Why? Because the current Deshaker.log is as a leftover from a previous job and has nothing to do with step 1 of the job which I am currently preparing. Actually the old Deshaker.log should not exist any longer. It should have been deleted after completion of the old job to which it belonged! Though, sometimes it may be handy to have it for a repetition of step 2 for the old job with modified parameters.

After execution of the new job will be executed started by Job Control, first step 1 of the new job will be done and produce a new Deshaker.log, and then step 2 will (need to) redo the calculations based on the new Deshaker.log produced by pass 1 of the new job.

Would this be ok? Or am I lost again?