oh and my ae is 126.96.36.199
With the current architecture used in AE it is highly unlikely that Warp stabilizer, or any kind of tracking software will utilize more than a small portion of your system resources because the data analyzed is so small. Think about it for a moment, look at all the pixel values in a frame of video (not a very big number) compare them with the frame before and frame after (still not a very big number) and calculate the movement of the areas that show the most consistent values in a block of say 100 pixels. Expecting those small numbers to fill up 48GB of ram and those calculations to fully utilize 100% of your CPU's calculating power is an unreasonable expectation. Jacking up the memory use or the CPU use by 2 or 3% may be possible with some fine tweaking, but you are probably spending a lot of time trying to fix something that isn't really broken. As long as AE is running smoothly for most of your work you are not going to find any major speed increases with Warp Stabilizer or any other tracker by tweaking your system settings.
The speed of the solve depends on the complexity of the shot, the codec used, and, this is important to know, some shots will not solve or stabilize, some will. The codec of the original footage makes a difference. As long as your system is set up and works fine for your standard AE projects, Warp Stabilizer and Camera Tracker should work just fine. Problematic formats include AVCHD (ammeter video codec), mpeg, and codecs from many screen capture apps.
If I have misunderstood your question tell us what problems you are having and what kind of footage you are using and we may be able to point you in the right direction.
There's nothing wrong. Most temporal operations in AE require strictly linear progression and are not at all or barely multi-threaded or in any other way accelerated. AE is chewing through the footage one frame at a time and that's just it. Nothing you can do about it.
thank you for your reply! It might be that I want to fix something that isn´t broken but I guess there still must be a bottleneck that could be
optimised ... e.g. disk IO ? Also if I can´t do anything about it and it´s not the cpu and ram I still would like to understand the process bottleneck.
video file is RED 5k r3d , there is a redrocket for debayering so it´s light on cpu.
i will do some test with a smaller resolution file and see if this goes faster.
If it's taking a long time, could just be the footage. What does the shot look like? Is there a lots of detail or very little detail? Is there rapid camera movement with lots of motion blur, or is the shot nice and smooth and stable. All of these factors make a difference in how long it takes to process the shot for stabilizing or camera tracking.
thank you for your reply! If you say it chews through the frames one by one the video file resolution/file size/codec have no impact on the process?
And as Rick said cpu and ram usage is low the conclusion must be it is adobe who limits the speed?;) I guess this can´t be true ...
i will do some test with a smaller resolution file and see if this goes faster what you say it should not if I understand your reply correct .... it chews always
in the same speed ... ?
@ Rick : I am looking to speed up the analyse phase ... solving just takes a few seconds
the clip I was using for the test is an areal shot from the helicopter, no motion blur, not too much detail cause of snowy landscape but enough good tracking points that
are in the shot for the whole time, there are no real harsh movements.
i will test different shot with the same length /resolution
i will try the same shot with a more contrasty raw development
It's not that Adobe limits the speed, it's that there just are not that many numbers to crunch.
screen grab from the more contrasty grade
did some tests with always the same shot (scaled down) in a 1080 composition:
123 frames 5k r3d less contrast - 8:06 sec (of 2190frames @ 5.02GB)
123 frames 5k r3d - 4:08 sec (of 2190frames @ 5.02GB)
123 frames 5k QT h264 - 3:50 sec (of 2190frames @ 20.39GB)
123 frames 4k QT h264 - 2:32 sec (of 2190frames @ 11.67GB)
123 frames 1080p QT h264 - 0:41 sec (of 2190frames @ 3.02GB)
conclusion: definitely better contrast matters the most (you are right Rick) but there is also 20sec difference
between 5k h264 and 5k r3d so codex/debayering also matters and we can see 3:09 sec difference
in the QT files going from 1080 to 5k so resolution/size matters also.
did some more tests with always the same shot in a composition with fitting resolution:
123 frames 5k r3d - 4:08 sec (of 2190frames @ 5.02GB) in 5k composition
123 frames 5k QT h264 - 3:50 sec (of 2190frames @ 20.39GB) in 5k composition
123 frames 4k QT h264 - 2:32 sec (of 2190frames @ 11.67GB) in 4k composition
123 frames 1080p QT h264 - 0:40 sec (of 2190frames @ 3.02GB) in 1080p composition
conclusion: scaling down doesn´t effect the analyse speed
anything wired with my conclusions?
does anybody see a final conclusion what could be done better to speed up analysing my r3d as
I want to keep the raw as long as possible?
that´s exactly what I am thinking ... adobe is not limiting the speed and cpu and ram are minimally used so is it probably the disk IO ? or is gpu involved ? have you seen my tests?
The disk IO's probably have very little to do with it. It's most likely the shot. There can be a tremendous difference in tracking and analyzing time between shots and between codecs. Some codecs take a tremendous amount of processing (and most often badly optimized processing) time to decode and analyze. Others are very quick. I would take 1000 frames of your footage, transcode it to something like jpeg QuickTime and then run tests. I would also take 1000 frames of two completely different shot types and run some tests. It would be nice for this process to go faster, but for now it's not multi threaded and there's not much you can do to make it more efficient unless your disk drive setup is completely out of whack.
all those above test where done with two cpu cores each having 3 GB ram. I changed it to eight cpu cores with 3gb ram each and the analysing of the QT1080 went down to 0:34 seconds so 6 seconds faster with more cores. The QT 5k was analysed in 3:52 sec so 16 seconds faster with more cores.
i will try the new test you proposed tomorrow , thank you for your time Rick!