fbpx
Welcome, Guest
Username: Password: Remember me
{JFBCLogin}
25 Jan 2021
New boarders will have their posts moderated - Don't worry if you cannot see your post immediately.
Read More...
  • Page:
  • 1

TOPIC:

Rendering not saved 18 May 2022 15:42 #120601

  • Elmos
  • Elmos's Avatar Topic Author
  • Offline
  • New Member
  • New Member
  • Posts: 1
  • Thank you received: 0
Once a render a project, shouldn't it remained rendered when I reopen the project? It used to be like this. Not any more. It is very annoying, especially when a project needs over an hour to render... Any ideas?

Please Log in to join the conversation.

Rendering not saved 18 May 2022 16:22 #120602

Switch off background rendering and don’t render.

Please Log in to join the conversation.

Rendering not saved 18 May 2022 19:01 #120609

  • joema
  • joema's Avatar
  • Offline
  • Platinum Member
  • Platinum Member
  • Posts: 2131
  • Karma: 27
  • Thank you received: 521

Once a render a project, shouldn't it remained rendered when I reopen the project? It used to be like this. Not any more. It is very annoying, especially when a project needs over an hour to render... Any ideas?

I believe it's been like this for quite a while. I remember seeing this on 10.4.3 in 2018. Yes is has huge impact if you have lots of compute-intensive Fx on the timeline.

There are actually two different layers to the problem:

1 - Render cache is not stable in some cases, e.g, the render cache segments are marked as "not valid" in the library's SQL database, thus causing render dots to appear. This can happen from simply restarting FCP or in some cases switching between proxy and original media (assuming both data sets are rendered, as separate render files are maintained for each).

2 - Even if no render dots appear, in some cases render cache is not used to expedite export. If valid cache exists those files should be used for export; it should not be necessary to re-read the original files and recompute all Fx on each clip. You could have a timeline which took 1 hr to render to cache, timeline performance may exhibit smooth behavior, yet when exporting to ProRes 422 it could take 1 hr. On a machine with sufficient I/O bandwidth, that export should take about 10 seconds. FCP only needs to read the render cache segments, concatenate those and write them to an output file. It does that in some cases but in other cases it will not -- even though both cases show no render dots.

The core issue may be related to the Motion runtime engine which underlies most FCP Fx and titles. Motion is highly interactive and one of the marquee features is it never requires rendering to see the results. That is fine if composing on the interactive Motion canvass, but in FCP if other highly compute intensive Fx are ALSO in the same Fx stack, I believe some FCP/Motion effects prevent all Fx in that stack from being effectively cached. If that happens on Neat Video, Digital Anarchy's Flicker Free, Imagenomic Portraiture, etc, it can cause a gigantic slowdown in export performance.

This can be easily reproduced. Put the built-in Basic Title on a ProRes 422 clip with no changes from the defaults. Also put Neat Video on that clip, render it clip with CTRL+R, export to ProRes 422 and time it. It will be very fast. Now change Basic Title's lettering from "Title" to "Titles" and render that with CTRL+R. The render dots go away and the timeline will be smooth -- but export will be permanently slow, in some case 50 times slower -- because it is recomputing Neat Video (and any other Fx in the stack covered by Basic Title).

This is not an anomaly with Neat Video -- it happens with all other Fx (inc'l FCP's own built-in video NR), it's just more obvious with the time-consuming ones.

Case #2 may be less apparent if exporting to an H264 or HEVC codec on a machine with slow encoding, since the encode bottleneck can predominate. But for ProRes 422 exports it's very obvious. It's more apparent if exporting H264/HEVC on an M1 Max machine since the encoding is faster, thus revealing the bottleneck on unnecessary timeline re-rendering.

I have discussed this at length verbally and in email with Pro Apps Escalation Support, and emailed them a simple replication scenario. However in those discussions they didn't view it as a bug or plan to take any action. See below posts for more details.

When Randy Ubillos designed FCPX, he supposedly mandated that all individual Fx must render very rapidly. IOW if other Apple FCPX developers wanted some cool built-in effect but it wouldn't render within about 2 sec, he disallowed that. Even today the built-in Fx are fast -- maybe fast enough that this problem often goes unseen, esp by Apple support personnel who normally don't use more compute-intensive 3rd-party Fx. But in the real world it can be a major problem.

https://www.fcp.co/forum/4-final-cut-pro-x-fcpx/31621-help-losing-renders-after-fcpx-close-or-project-switch
https://www.fcp.co/forum/4-final-cut-pro-x-fcpx/34357-pre-rendering-files-on-timeline-has-no-effect#110389

Please Log in to join the conversation.

  • Page:
  • 1