I’m noticing that straight playback (no processing or other effects) within Silhouette seems a bit sluggish. I am wondering if I am missing something…
I have a 3840x2160 (UHD) 16-bit DPX sequence of 120 frames. I’ve minimized the cache/ram settings in Silhouette to cause it to rely as much as possible on the disk system. The playback is from a direct attached array of multiple NVME drives, which are more than capable of 4K 16-bit playback of DPXs in real time, so I know the hardware is not the issue.
For comparison, Nuke is playing the same sequence back at 1:1 at 24 fps.
Silhouette, however, can’t seem to playback the same sequence faster than approximately 5 frames per second. I’ve only dragged the sequence into the source window and double-clicked it for playback, so I don’t think there would be any additional processing being done at this point.
Am I seeing a limit on the DPX loading speed of Silhouette’s code or is there some other setting I should be looking into for faster playback from disk? Or is this because caching is taking some time (since, per our previous thread, it cannot be truly disabled)?
The issue is that the caching can’t be turned off. By lowering the caching preference, you are telling Silhouette to use less system RAM to cache with and the clip is never caching completely and continues to try. The result is that less frames are cached. Turn the Cache preference back up to 50% and then note the Cache display at the bottom right of the interface.
If the second number is smaller than the amount of frames in the sequence, you will not be able to fit the whole clip into ram. If this is the case, set the start frame and end frame of the Timebar so that you can cache completely a portion of the clip.
That makes sense and is in keeping with our previous thread, but I thought I’d make certain. Although minimizing the number of frames cached helps overall, with a minimum other than 0% (which isn’t possible but would be desirable in my case to avoid caching) every time a new frame loads the overhead of it caching and the 'oldest frame" un-caching may be expensive on the overall cycles/time to display a new frame from disk.
So I suspect that the existing process is something like:
1-New Frame is loaded from disk
2-Oldest Frame is unallocated from cache memory
3-Frame is cached/parsed into RAM cache
4-Cached Frame is displayed.
…repeat for each frame.
Steps 2 and 3 may be very CPU ‘expensive’ (assuming that the actual disk-load of the new frame into the system and display are pretty fast) and slows the overall “new frame” cycle by 3-400 percent.
Thanks for the clarification, and I’ll look forward to the possibility of disabling the cache process & faster (real-time?) loads in a future revision.
The current playback system isn’t the nicest, I’ll admit. Using the “Preload frames” preference should help as that will load some frames in the background ahead of the play head, but only when you’re parked.
I am hoping to have a player improvement in our next release which should playback closer to real time. #SI-1504
Understood about preload frames, thanks.
My goal is to not use the cache/preload at all while jogging/playing. Looking forward to the future faster playback from disk, thank you for the efforts.
On a more personal note…Paul, by chance were you or Marco part of ASDG in Wisconsin?
Sam, yes Paul was part of ASDG/Elastic Reality back in the 90’s.
I thought his name sounded familiar. I ran a small company and wrote compositing & visual effects apps for the Amiga that utilized ADPro & MorphPlus as image processing engines around that time. I communicated quite a bit with ASDG back in the Perry Kivolowitz days right up until the death of the platform. Small world.