-
Back to Premiere. sigh.
-
[David Cherniack] “AFAIK it had all to do with playback…which was why it was called a playback engine. It worked in the first 64 bit build of PrPro as I recall. GPU acceleration worked with some effects, not with the actual decode of the codecs during playback…”
That was also my recollection. MPE was a catch-all term for numerous performance enhancements to the playback engine, including improved multi-threading, 64-bits, and GPU-accelerated effects. Initially only some effects were GPU-accelerated but the entire playback engine felt fast. Adobe obviously had done a lot of profiling work to optimize decode-oriented code paths.
The Premiere intro video still on Adobe’s web site today describes it as allowing “editors to work with 4k and beyond, without time-consuming transcoding”, and “never needing to render until your work is complete”: https://helpx.adobe.com/premiere-pro/how-to/what-is-premiere-pro-cc.html?set=premiere-pro–get-started–overview
Back in the DV and 1080p H264 days, CS5/CS6 did seem very fast on period Windows machines. The ability to edit compressed native camera formats with good performance and without transcoding was impressive – it wasn’t just an advertising slogan.
That raises the question, over time did the other NLEs get disproportionately faster on newer hardware generations or was Premiere not that fast back then but the other NLEs were even slower?
I recollect CS5 as seeming very fast. However when I recently inherited a cross-NLE project and had to concurrently run Resolve 16, Premiere 14 and FCPX 10.4.8 on my 10-core Vega 64 iMac Pro, FCPX felt super fast, Resolve felt nearly that fast, and Premiere seemed very laggy and sluggish.
I think some of it is just aesthetic – the FCPX skimmer is hyper-responsive and Resolve 16 is similar. But that doesn’t necessarily make you edit faster. There’s a difference between feeling fast vs producing more completed work fast.
-
[Oliver Peters] “Nope. You can turn it off and go software-only and it makes no difference on standard media playback. It affects effects processing and transform functions, so if you add filters in software-only or several layers with PIP, then you are taxing the CPU. It also affects the output using an external i/o.”
You could, and can, certainly turn GPU acceleration of effects and today I’m pretty sure that some codecs are GPU accelerated in decode-and-playback, but back then it was all CPU for decode. Joe is right, back then it seemed pretty fast but today it may be showing its age. It doesn’t yet look optimized for the new Mac Pro according to Puget Systems comparative tests.
David
https://AllinOneFilms.com -
[Oliver Peters] “ometimes that does go fast. But on this batch of revisions, when you try to follow this process, you can never stop the “looking for matching filenames.” So at each step you get a spinning beach ball for a while until it to a point where it lets you go to the next folder.”
I have definitely seen this behavior, just not in a while. It is abnormal and very slow. It sometimes yanks control from the user before you can even point the UI to a folder. There is no progress bar, but a spinning beach ball for a long time, which itself indicates poor programming or a malfunctioning system layer.
Was the media on shared storage? Was the media indexed for Spotlight searching? If it’s using Spotlight lookups to expedite the searches, some aspects of this may not work properly on a NAS. In my testing, filename searches work but some metadata searches are unreliable on a NAS. FCPX would have to read metadata to determine relink compatibility.
If it’s on local storage it would be interesting to rebuild Spotlight indexes on that and see if it makes a difference. https://support.apple.com/en-us/HT201716
-
[Joe Marler] “Was the media on shared storage?”
From my earlier post:
The original edit was done from media on shared storage. Library on a local machine and media left in place. These files were archived onto different archive drives. That’s because the media isn’t associated with one single project. So the library and various media files are on several different drives. In order to make the necessary revisions at home, I have to copy all of these pieces (media and library) back onto single larger RAID. So obviously in that process, paths and volume names have all changed. Filenames are unique.
Not sure about Spotlight indexing. Certainly nothing on shared storage would be Spotlight indexed.
– Oliver
Oliver Peters – oliverpeters.com
-
You can select the new drive and hit “choose”
You don’t have to wait for anything else.
-
[Jeremy Garchow] “You can select the new drive and hit “choose”
You don’t have to wait for anything else.”
Oliver was taking about an intermittent bug whereby you *can’t* hit “choose”. The relink UI yanks control from you and goes to a beach ball. It is apparently enumerating something in the background for several minutes. Then it finally finishes and you can select the folder and the rest of the relink process is normal. On very large datasets I’ve seen this phase take 10-15 min. This is on various local Thunderbolt 2 arrays, not just a NAS.
I used to see this frequently when relinking very large datasets, but not recently. Hypothetically it could be the difference between a brute-force sequential search for metadata in thousands of files vs an indexed Spotlight lookup.
Oliver is on a NAS and Spotlight indexes don’t always work correctly there, but it’s just speculation it’s even using Spotlight. It could be something else. But it’s a bug, not lack of a feature. It usually works OK but in some cases the relink performance falls off a cliff.
-
[Joe Marler] “Oliver was taking about an intermittent bug whereby you *can’t* hit “choose”. “
I see. I guess I’m lucky and I’ve never seen that.
I switch (or at least used to) switch between local and NAS a lot.
If I have the same master media files (and not transcodes) on each set of drives, relinking is usually only a few clicks away.
-
[Joe Marler] “but in general interactive use FCPX is still a little more responsive.”
I think this is what I cherish most with any app I work with.
Sure I expect apps such as Maya to be slow on most functions since the assumption is that its a graphics hog and data-set dependent but a vertical bar and already cached set of frames should not be lagging period.
This is where FCPX shines IMHO.
Now, of course, I can come up with a few functions that Premiere exceeds over FCPX but I just can’t have that “lag” feeling when I’m doing basic edits. -
[Oliver Peters] “…on this batch of revisions, when you try to follow this process, you can never stop the “looking for matching filenames.” So at each step you get a spinning beach ball for a while until it to a point where it lets you go to the next folder.”
I just noticed there was a fix in 10.4.1 which says: “Relink Files button highlights after selection, allowing you to press Enter to commit the command”.
While that fix is vaguely worded, the problem I formerly saw might be described that way. IOW it would not wait to initiate the relink search until you pressed Enter – it would immediately start. This prevented isolating the relink search scope. However I think more was wrong than that, but fixes in release notes are not comprehensive.
I saw this problem frequently before 10.4, but I don’t recollect seeing it since then, at least on locally-attached storage.
-
[Joe Marler] ” I can combine multiple media trees from a NAS to a directly-attached RAID, change all the paths, and FCPX File>Relink Files will rapidly scan the entire volume and relink all the files.”
This part I really love between the two.
I get a lot of odd drives from clients and when they tell me its a Premiere project, I have to add at least two days of lead time.
I have had mixed RED, Sony, EVA1, etc… footies in projects and FCPX always avoids the hassle when drives/media get moved.
For me, however, I use link and avoid proxies unless I have a lot of time in my hands and that’s usually feature-length work.
Reply to this Discussion! Login or Sign Up