[CinCV TNG] Motion stabilisation issue / solved
miro.rovis at croatiafidelis.hr
Wed May 25 20:31:54 CEST 2016
On 160521-18:45+0200, Miroslav Rovis wrote:
> On 160520-15:23+1200, edouard chalaron wrote:
> > Works perfectly !! Thanks !
> > E
> Works perfectly here too! Motion stabilization is back to its former
> glory. ;-)
It really did look like that. But, (in part only), some bad news, if I'm
not mistaken. Read on, pls.
> I've stabilized this video with the old Cinelerra from Gentoo portage:
> (that is actually cut out to one third of its length, I'll test on the
> raw 17 minutes video)
(I did that, and at first it looked good, but... read on.)
> and (pls. note that it's at least around 10 hours for Cinelerra to
> stabilize it)...
No. It was only some six hours. (It would likely be more than 10h with
the old Cinelerra.)
But then I tested with a 27 minutes video (I'm mostly talking 1920x1080
HD handheld cellphone-camera videos, which I often later, for now,
downsize for publishing)...
The first time. with the (forgive the idiotically wrong name --I had
forgot to set the date when I changed the memory card--, but that's the
basename for files I used in the XML, so can't now change it):
And as I was watching what I was getting, I figured out how to set a few
labels at the right place before or after where I set them in 01.xml,
and then btwn those better-positioned labels, how to get the smoother
stabilizing motion plugin sessions. I managed to get the picture
stabilized almost so good as what yuu get with the real camera like
there will be a few to see in the video when I, hopefully within days,
post it (a downsized version, slow connection and little space online,
but the motion will be shown the same, but the video will, God willing,
--empty at the time of sending this email--
And so the:
is just the few labels changed, and related start and end of motion
stabilization sessions changed, but... (*Here's the point!*)...
But this time it took more than 24 hours to render! Almost three times
Have a look. the xml's were saved pretty much just before start of
-rw-r--r-- 1 miro miro 15860 2016-05-23 19:38
-rw-r--r-- 1 miro miro 1947821155 2016-05-24 06:14
-rw-r--r-- 1 miro miro 17881 2016-05-24 07:02
-rw-r--r-- 1 miro miro 1948054131 2016-05-25 11:32
See the difference? The 01.xml took less than 11 hours to render, and
the 02.xml took 28 hours to render.
I don't have other than just slow aDSL, so I can't post the 1.8G
video-2000-01-01-01-01-35_Hebrang_domjenak_Vice_Vr.mp4 (which is a 27
minutes file --and anyway, I want to, first, protect my authorship with
my Flowstamp program --which I never have the approx. one week time of
dedicated work to fix an unfinished part of its functionality:
but I'll try and post (within days) the 768x576 downsized version of the
7 to 10 minutes choice-sections of that video within days, and the
Cinelerra motion stabilization will shine in it.
Except for the unexpected slowliness which is unexplainable to me... Other
than... (read further below)
I had carefully tried to account for how the slowliness shows in my
system, but it's a *very clumsy* and broad select-and-paste-type of
documentation that I was able to set aside for the purpose of reporting
how the 2 yrs old, and then the new updated motion-plugin Cinelerra-CV
worked for me.
First it can be looked at how the 17 minutes video that I made a number
of motion stabilizations on worked on the old 2014 Cinelerra from Gentoo portage, which can be
compared more easily already now, because the (downsized) video is at:
(as I already reported four days ago).
Then it could be gleaned, and I'm sorry, those are really poor notes,
how that same video, as I already said above, was rendered faster with
new cinelerra-cv from git.
That must be (a little tired and my head is spinning with this non too
And, still fast enough it looked to me, It can be seen there how the
first round on the 01.xml (the XML is:
) for the video above (that I am yet to post the
downsized version of on that new locatation to be) went pretty fast:
I don't want to speculate, but maybe I can allow to myself to suppose
that the reason must be somewhere in the new code, for which reason
Cinelerra, somehow, loses the ability to get to full processor power at
repeated work... I use ImageMagick a lot in my Flowstamp program, and
ImageMagick just never ever can use full processing power, it is always
slow. Compare it to FFmpeg which is a fast breeze with its "-thread 0"
Enough of my speculation.
Instead, I have to admit that, while I was waiting for the 02.xml to
finish, I had a downtime psychologically... And didn't make the notes,
because of the slight despair that I felt.
So here's the incomplete and short explanation: it never went up using fmor
only 4 out of 6 available processors in the first one third of 02.xml
And it went slowlier even.
In the end, the last say one third of those 28 hours, it kept somewhere
btwn the use of only one to two processors out of the 6 available...
It is, for the reason stated above, really only explained in this
email, I'll really post just a link to this email in that:
> I'll try and do it like I did where I promised I would. The one month old link:
> has new video.
is solved completely though.
Just the slowliness remains. If I'm not mistaken.
I hope this report will, regardless of clumsiness, still be usefull.
Pls. allow later corrections (and check for them in the following
emails). A few things need to click into place for this report to be
complete, and then I need to check all components of it, as best I can.
In now possibly even more slowlier time... still a pinch of despair is
biting in my soul.
Regards! I just don't believe in any non-FOSS. Cinelerra has all my
hope. And it's great to see so much work on Cinelerra lately.
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 819 bytes
Desc: not available
More information about the Cinelerra