Premiere Pro -> Media Encoder Workflow Is Poorly Deisgned

@Fergus H  @R Neil Haugen 

This is a repost of something I put on the Premiere forum. I feel like this forum gets even less traffic / respones from Adobe but nevertheless here we go: 

....One of my main gripes with AME is the mystery box of why Media Encoder works fine sometimes and other times it fails.

I've have the following issues on an ongoing basis over the last 10 years of trying to use AME: 

• encodes the file incorrectly with either:
  • offline media
  • broken fx licencing 
  • wrong AE comp being rendered
  • weird audio sync glitches 
  • captions refusing to burn in
  • gpu errors
  • Encodes a a much slower rate, which makes no sense if it is the same exact encoding engine. 
  • stops mid-encode 
  • etc. 

Media Encoder has a funny setting where you can either: "encode sequences natively" Or use the PrProHeadless option which usually means a slower and longer project load as it loads full premiere in the BG minus the GUI. However, I usually have less render issues with that option up until recently, where now AME will not render for me if the "encode sequences natively" box is unchecked.

What drives me crazy is how finnicky all of this is. It should "just work." There should be one unified encoding engine and not two separate ones with often separate outcomes. Often times on complicated projects with long run times. many dynamic links, effects, media encoder can just NOT be trusted.

From my perspective here is how AME bogs down the export process. Just look at the number of things that have to happen before AME exports:

• First of all Premiere has export a .prproj current sequence(s), which on bigger projects can take a significant amount of time. Each sequence is saved as its own project file which can be lot of premiere and filesystem overhead (TIME). 
• Then media encoder opens, which takes at least 20 seconds, or worse if you have a lot of plugs (More wasted time)
• Then Media Encoder has to load BG premiere, re-load the project (wait), and fire up a dynamic link to the PrProHeadless process. (Additional wasted time)
  • It's at this point that AME 23.5 usually refuses to encode because the dynamic link stalls. (Wasted time trying to either troubleshoot this issue or just going back to Premiere and Exporting)
• If you are lucky AME will encode without issue. 

This is a Kafkaesque system that needs a re-do. This is why I don't want to "SEND to AME" as the repair for the broken export system inside of PrPro. On many projects it adds a ton of unneeded time and steps and a lot of unreliablity. 

My ideal rendering system:

• Ditch the new Export window it was a solution looking for a problem. Bring back AME window within Premiere.
• Ditch all of the two app tap-dance garbage workflow between PR and AME
• Build a robust render queue within Premiere that you can send sequences to but without all the rigamaroll of Dynamic Link and AME. Have exist as a panel or (un)dockable window. (save a lot of time saving and re-loading projects etc) It would look and function much like the render queue from After Effects. 
• Move AME to just transcoding tasks where you may want to take a master file and encode 100 different file type or your listed example of watch folder encodes. Maybe it can still exist in parallel but it needs to be 100% as robust as hitting export in Premiere no more "native/ProHeadless" confusion. 

9 times out of 10 I have no need or deisre to "edit while rendering" as this leads to either bad edit performance or slower exports from constantly pausing. Putting a render queue into premiere and ditching the two app workflow would be a vast improvment.