Playback problems using long source clips?

[alexboothby]

I'm editing a trailer for a movie on Smoke 2015 and am having HUGE problems playing back my HD sequence.  My edited sequence constantly freezes or continues playing audio while displaying a black image.  It stalls constantly, for 20-30 seconds at a time.  Playback is particularly poor on clips with rendered effects.  

In the past I've edited 3K prores4444 sequences on this system and have never experienced performance this poor.  The only thing unusual is that I'm using a source clip which is 2 hours long  (1080p, Quicktime Prores 422, 10bit).    Any Smoke sequence I create using this material has HUGE playback problems.  I thought the source quicklime might be corrupt so I re-compressed it to the same specs using Compressor.  Same problems occur.

Does Smoke 2015 have a problem working with long Quicktimes?  If so, what is the solution?

I'm running: Smoke 2015 on a brand new 2014 Mac Pro, OS X 10.9.5, processor: 3 HHz 8-Core, memory: 64GB, Graphics: AMD Firepro D700 6144 MB,

Desperate for a solution.  Thanks in advance! 

[alexboothby]

Also, my drive is a Thunder Bolt 15 TB Pegasus fast RAID.   I'm NOT using cached source media.

[Anonymous]

Break it into smaller pieces.
Either smaller quick times or better yet, image sequences.
Be careful about how many images you render into one directory.

[alexboothby]

Thank you sir!  Most appreciated!

Can anyone suggest an appropriate duration for a source Quicktime?  Is 20 minutes okay?  I work with long quicktimes all the time, from interviews, etc. 

On a related note I do wish Autodesk would be more clear about the BEST ways to get the BEST performace out of our systems.  For example, I can find no clear answers about whether cashing media (from ProRes source clips) during import gives better performance or worse.   A lot of people are stuggling with Smoke's speed and could really use a published list of tips to enhance performance.   "Turn off Spotlight!"  That should be on the list.  "Long source quicktimes are bad".  That should too.  Personally, I think users would be a lot happier to adjust workflow to enhance performance even if it means hearing some bad news.   Solid Information is 10x more appreciated than "good-news-only" marketting. 

End rant 🙂

[Anonymous]

Well if you have a thunderbolt drive then you most likely have two thunderbolt ports on your machine.

It's a good idea to have fast source storage, fast rendering storage (your framestore) & fast recording storage (for your exports/masters).

As for the current problem, I'm speculating but it could be that your two hour file is recorded in non-sequential fragments on your storage.

Once you begin to edit the sequence in smoke, you are directing the software to read a part of the huge file, then jump to another section of the platters to look for other data, then re-orient and pick up more pieces of the huge file. You may just be reaching the physical limitations of your equipment - (no jokes about adequate equipment!!!).

Sooooo, were I in your shoes I would try:

Store all the long Quicktimes on your fastest storage with the most drives.

Soft-import it, don't cache it.

Get a USB3 or thunderbolt SSD (at least 512GB) to use as a framestore for rendering dissolves, timewarps or whatever on your timelines and a cheap RAID to send your masters to.

It sounds as though you cannot avoid large QuickTimes (you must have killed someone in a previous life) so my $0.02 would be to increase the number of fast volumes so that you can increase your read/write/render capacity.

[jamesgrean]

This opens up a question about soft imports vs caching:

Say I have a load of DPX sequences and TIFFs and TGAs and some Quicktimes. Say they're on one of the bigger Pegasus2 RAIDs. No other drives connected on that bus.

When is it better to soft import and when is it better to cache?

Personally I haven't been caching at all, as it seems as long as the media is on the Pegasus, it's just as good as cached. 

For compressed QTs or other compressed codecs, I could understand caching so there's no decompression overhead.

To my mind, the advantage of not having it cached, is that when you archive the project you're only archiving renders. The source material can be backed up separately and once, rather than backed up once (eg graded rushes on a drive) and then backed up inside the Flame archive (cached graded rushes). Saving both space and time.

[Anonymous]

Personally I rarely cache much if anything.
Precomps in batch or raw material.
The legacy import/cache lost its shine once standardfs was introduced.