On = Feb 28, 2018, at 4:12 PM, Benny Christensen <AE-List@media-motion.tv> wrote:

As far as I can see = part=20 of the problem is trying to do complex computations on high res h264=20 files to begin with.

You are adding computational overhead just to edit the frames and then=20= adding multiple layers of effects only makes it worse.

I would have converted the movie to a frame based format like ProRes or=20= an equivalent and then added the layers of effects.

At those large frame sizes I think it would make the difference.

My rule of thumb is that AVCHD, h264, HEVC are all fine for shooting and delivery, but I WANT ACTUAL FRAMES when I edit.

Good Luck.

--
=20 =20 =20 =20

<PP Logo = vertical sm.png>

Benny = Christensen Editor

117=20= N.W. 142nd Street
Edmond, OK 73013

t (405) 858-0700 | m (405) 401-2070

e benny@producersplayhouse.com
w www.producersplayhouse.com

<fb-c.jpg>= <in-c.jpg>= <youtube-c.jp= g> =09

Jim Curtis

February 28, 2018 at 2:47 PM

Hi RJ,

As you=20 probably know, H.264 can accommodate varying bit-rates, and as I=20 mentioned already, he lower the bit rate, the more the CPU has to work=20= to decompress the video on the fly.

I=E2=80=99= m not familiar with the=20 "HEVC Main 10 BT2020 HDR codec=E2=80=9D unless that just happens to be = invisible to me. The only time I dive deep into encoder settings is when I get=20= specifications from an ad distro like AdStream or HDFastChannel, etc.

I call video compression / decompression one of =E2=80=9Cthe black = arts.=E2=80=9D A lot=20 of it is magic, as far as I know.

Ae will = tell you if you=E2=80=99re in a 16-bit or 32-bit project and you apply an effect that=E2=80=99s only 8 = or=20 16-bit.

In Pr, you can tell which of the = effects are 32-bit=20 color (or GPU accelerated or YUV) by the icons to the right of the name=20= in the Effects Tab. This is why, if I can do projects in Pr as opposed=20= to Ae, I choose Pr to make use of my Titan GPU.

There are ways=20 to purge RAM without restarting. There are some utilities for this=20 (like MemoryClean), and you can do it in the Terminal with sudo purge .=20= You can run those without quitting Pr.

The = =E2=80=9Cnoise=E2=80=9D you mention=20 might be layers of compression artifacts. You might have better luck=20 with your layering and noise if you transcoded your files to a lightly=20= compressed intraframe format like ProRes4444 or DNxHR 444. That would=20= also take stress off a CPU decoding multiple layers of Long-GOP.

I have no experience with Resolve or FCPX. So, I can=E2=80=99t help = with that=20 question.

As for stability and Pr, CC17 and = CC18 have been the=20 most stable for me. I don=E2=80=99t think the OS has that much to do = with it. I think most of the past issues were in the Adobe code. I have one=20 client who runs CC18 on Windows machines, and they=E2=80=99ve been more=20= problematic, but my anecdote is hardly universal.

Prior builds of Pr used to be bad at corrupting their own preferences, render and cache files. I haven=E2=80=99t noticed that nearly as much in the last two = major=20 releases. Most of the issues I have with Pr in the last couple of years have been due to corrupt media, corrupt sequences, corrupt projects,=20 and corrupt plug in instances - all of which were easily fixed, once = I=E2=80=99d figured out what the culprit was.

About = the only complaint I=20 have now is that the Dynamic Link between Ae and Pr can become unlinked=20= as I switch around projects, and that the DL to AME is pretty flakey=20 some times from either Pr and Ae. And I suspect that=E2=80=99s also a = code=20 problem, not due to OSX. My other complaint has been aired on this=20 forum by many others, that Ae seems to render less efficiently than it=20= did going back to Ae CC14. Most of my Ae crashes now are either plug-in or GPU related.

+---End of=20 message---+
To unsubscribe send any message to=20 <ae-list-off@media-motion.t= v>