Skip to main content
readysetpoetry
Participant
October 6, 2026

Auto Reframe analysis causes runaway memory use until macOS kills Premiere – 26.5.2 / macOS 27.0.1 / Apple silicon

  • October 6, 2026
  • 5 replies
  • 37 views

Environment

  • Premiere Pro 26.5.2
  • macOS 27.0.1
  • Mac Studio (2026), M5 Max, 64 GB unified memory
  • Footage: ProRes 422 LT, 4K, on an Apple RAID (Mac OS Extended, Journaled); also tested with media on the internal SSD
  • Sequence: vertical 2160×3840 (9:16)
  • Media Analysis and Automatic Transcription are both off
  • Hardware-accelerated decoding: off

     

Summary
After applying Auto Reframe to a sequence, Premiere's memory footprint climbs to several hundred GB (I saw 355 GB and 386 GB in Activity Monitor) on a 64 GB machine. macOS then terminates Premiere. The windows just disappear: no crash dialog and no crash report. It happens during playback and also when Premiere is idle. Any project containing the Auto Reframed sequence then spikes and gets killed right after opening.

Steps to reproduce

  1. Create a vertical 2160×3840 sequence with ProRes 422 LT 4K footage.
  2. Apply Auto Reframe to the sequence or a section of it.
  3. Leave Premiere idle or play back, and watch Premiere's memory in Activity Monitor.
  4. Quit, then reopen the project. Memory spikes again almost immediately.

Expected: Auto Reframe analysis completes with normal memory use.
Actual: Memory grows without limit until macOS kills Premiere.

Evidence

  • The system log shows Premiere was terminated by macOS's memory pressure handler (jetsam), not by a normal crash:
    [app<application.com.adobe.PremierePro.26...>] termination reported by launchd (1, 13, 9)
  • No .ips crash report is generated.
  • Before the runaway, Premiere's resident memory was a normal ~10–30 GB. The footprint shown in Activity Monitor is what explodes, which suggests a GPU/Metal or decoder memory leak.

Isolation testing

  • The same sequence without Auto Reframe (imported via XML into a new project, same RAID media) stays stable at about 10–11 GB, including when left idle.
  • Duplicating that sequence and applying Auto Reframe to a short section reproduces the spike every time.
  • Ruled out: third-party plugins (Boris FX removed), control-surface apps (TourBox, SoundFlow, Kensington Konductor quit), storage (RAID vs. internal SSD), low disk space (233 GB free), Media Intelligence and transcription (off), and preferences/media cache (cleared).
  • Software Only rendering isn't available on Apple silicon, so I couldn't test without Metal.

Workaround: Avoid Auto Reframe and reframe manually with Position/Scale keyframes.

    5 replies

    Amy the Stuv
    Community Manager
    Amy the StuvCommunity Manager
    Community Manager
    October 6, 2026

    Hello ​@readysetpoetry 

    Welcome to the Premiere Forums. You’ve written a very thorough report, but I still can’t reproduce this issue. Would you mind taking a moment to provide the following information?

    • When does the memory start climbing and does it happen during analysis or afterward?
    • A screen recording, if possible—ideally showing the Auto Reframe steps and the memory increase. Let me know if you need a private upload link for this.
    • Project context: approximate project size, sequence length and roughly estimated clip count; whether it’s in a Production; whether it reproduces in a new/empty project, when it first began, and whether it affects all projects.
    • Troubleshooting tried: have you tested a launch with Shift and the reset options described in the guide How do I write a bug report?  
    • Auto Reframe specifics: What were the exact source sequence dimensions/aspect ratio and selected target ratio?

    Hope we can help,

    Amy

    readysetpoetryAuthor
    Participant
    October 7, 2026

    Hi Amy, thanks for the quick response. Answers below:

    When does memory climb?
    [During analysis / after analysis completes / both]. Premiere's memory is normal (about 7–11 GB) before Auto Reframe. Once Auto Reframe is applied, memory climbs steadily into the hundreds of GB (355–386 GB on a 64 GB machine) until macOS terminates the app. It also happens while Premiere is idle. Reopening any project that contains the Auto Reframed sequence triggers the climb almost immediately, before I touch anything.

    Screen recording:
    Yes, I'd appreciate a private upload link. The recording shows the Auto Reframe steps and memory rising in Activity Monitor.

    Project context:

    • Project size: My original project is 10.4 mb, however I also created a simpler project to test the issue and got the same results. that one is 129kb
    • Sequence length: 05:09, about 120 clips in the sequence
    • In a Production: No
    • Reproduces in a new project: Yes. I imported the edit via FCP XML into a brand-new project. Without Auto Reframe, it's stable at about 7–11 GB, including idle. Duplicating that sequence and applying Auto Reframe to the sequence
    • When it began: Oct 6, 2026, the first time I used Auto Reframe on this new Mac Studio (Premiere 26.5.2, macOS 27.0.1). The same project was previously edited on an older Intel Mac Pro.
    • Affects all projects: only projects or sequences with Auto Reframe applied. The same media and sequences without Auto Reframe are stable.

    Troubleshooting tried:

    • Preferences reset (Option+Shift launch): done, still reproduces
    • Media cache cleared and moved to an external drive
    • Third-party plugins removed (Boris FX); control-surface apps quit (TourBox, SoundFlow, Kensington Konductor)
    • Media on the Apple RAID vs. internal SSD: both reproduce
    • Media Analysis and Automatic Transcription are both off
    • Hardware-accelerated decoding: [on/off]
    • Plenty of free disk space (233 GB) and 16 GB reserved for other applications in Memory settings

    Auto Reframe specifics:

    • Source sequence: [3840×2160, 16:9, 23.976 fps]
    • Target: [9:16 vertical, 2160×3840]
    • Motion tracking setting: Default
    • Applied via: Sequence > Auto Reframe Sequence / Auto Reframe effect on clips, do not nest

    Termination evidence from the system log: termination reported by launchd (1, 13, 9), which is the jetsam memory-pressure kill. No .ips crash report is generated.

    Thanks,
    Sarah

    Amy the Stuv
    Community Manager
    Amy the StuvCommunity Manager
    Community Manager
    October 7, 2026

    Link sent to you via DM. I’ll keep looking into this issue. Thank you for the additional information.

    Terms & ConditionsAccessibility statement
    Using the community Terms of use Privacy Cookie preferences Do not sell or share my personal information ad choicesAdChoices