Adobe Media Encoder "encodes all sources in sequence, but encodes all outputs of a source in parallel." That one sentence from Adobe's queue documentation explains most of what people mean when they complain that the Media Encoder queue is slow with multiple files: ten different clips get processed one after another, no matter how much of your machine is sitting idle.
It is not a misconfiguration, and there is no hidden switch that changes it. Once you know the rule, you can stop hunting for that switch and start shaping the queue so the parallelism you do get is doing something useful.
The rule, in Adobe's own words
Adobe states it twice on the queue page, in two different phrasings. First the short version:
"Adobe Media Encoder can encode multiple outputs from a single source simultaneously. However, source files are processed sequentially based on their order in the queue."
Then the blunt one:
"Adobe Media Encoder encodes all sources in sequence, but encodes all outputs of a source in parallel. It is used to export multiple formats for the same source simultaneously, but it cannot be used to export different sources simultaneously."
Two consequences fall straight out of that:
- Ten different source files are ten sequential jobs. Queue order is the only thing you control.
- One source with ten outputs is one pass with ten parallel outputs. This is the exact case parallel encoding was built for.
And the feature is already on. Adobe: "Parallel encoding is on by default. To disable parallel encoding, select Edit > Preferences and deselect Enable Parallel Encoding." So if your queue is crawling through a list of unrelated clips, enabling parallel encoding is not the fix — it is already enabled, it just does not apply to the shape of the work you handed it.
There is one documented wrinkle: "In certain cases, export settings require an output to encode in serial rather than in parallel mode. In such cases, the queue returns to parallel encoding after temporary serial encoding is complete." The page does not spell out which export settings trigger that fallback, so treat a temporarily serial multi-output job as expected behaviour rather than a fault.
Reshape the queue so parallelism applies
The practical move follows from the rule. If you are producing several deliverables of the same sequence — an H.264 master, a smaller social cut, an audio-only version — do not add the source three times. Add it once and attach three outputs to it. Adobe describes this directly: "You can create multiple versions of a source by adding different output instances using different formats or presets." Those outputs encode together; three separate queue entries would not.
If your files genuinely are different sources, sequencing is unavoidable, but two things still help. Adobe supports stitching at queue time — "You can combine multiple media files into a single file when adding them to the queue" — though "you cannot edit the duration of sources once they have been added to a stitched clip." And you can deprioritise entries instead of deleting them: the queue's status table defines Skip as "The user can skip one, or more selected files. With the files selected, choose Edit > Skip Selection."
For a one-off job that is really just a container change, queueing Media Encoder at all is overkill — a browser-side conversion finishes while the app is still launching:
Try it right here
Runs in your browser. Your file is not uploaded anywhere.
That runs locally in your tab, so nothing is uploaded and there is no queue to wait behind. If your source is QuickTime straight off a camera or a Mac screen recording, MOV to MP4 is the same job with the destination spelled out.
Watch folders: hand the sequencing off entirely
If the real problem is that you are babysitting a queue, Media Encoder has an official unattended path. Adobe's description, verbatim:
"You can configure Adobe Media Encoder to look for files in certain folders called Watch Folders. Adobe Media Encoder automatically encodes the files placed in the watch folder. When Adobe Media Encoder finds a video or audio file in a watch folder, it encodes the file using the encoding settings assigned to the folder. It then exports the encoded file to an output folder created inside the watch folder."
Combine that with the multiple-outputs rule and you get what most people want from parallel encoding: drop a file in, get several formats out, without touching the app. The settings are attached to the folder, and the same "different output instances using different formats or presets" mechanism applies.
Start behaviour is also configurable: "If you have the Start queue automatically when idle for preference selected, encoding begins when the specified amount of time has elapsed after the watch folder has added an item to the encoding queue."
What makes each individual job slow
Since the sources are going to run one at a time, per-job speed is where the remaining time is. Four settings have documented cost, and Adobe is unusually direct about all four.
VBR 2-pass. "2 Pass encoding makes two passes through the file, from beginning to end and then from end to beginning. The second pass lengthens encoding times but ensures greater encoding efficiency and often produces higher-quality output." CBR is the other side of the trade: it "can shorten export times but may impact the quality for more complex frames." Worth choosing deliberately — see CBR vs VBR in Premiere Pro.
Maximum Render Quality. Adobe: "Export times can increase significantly, especially on systems without a supported GPU." And it is frequently checked for no benefit: "This option is only useful when exporting to a different frame size. If you're exporting at the same frame size as your source media, leave this setting deselected." Systems with supported GPU hardware "automatically use maximum render quality if Renderer is set to Metal, CUDA, or OpenCL."
Render at Maximum Depth. "In some scenarios, enabling Render at Maximum Depth may increase encoding times. Also, systems with GPU acceleration enabled will always render effects at the highest bit depth available, regardless of this setting."
Hardware encoding. For H.264 and HEVC, "Hardware Encoding is the default choice, which tells Premiere to use available hardware on your system to speed up encoding times," but "If your system does not support certain export settings, the Performance menu switches automatically to Software Encoding." If a job suddenly takes far longer than an identical one did, check whether Performance flipped — more on that fallback here.
One more that is easy to miss, and specific to Media Encoder rather than Premiere: preview files are not reused automatically. Adobe: "Media Encoder does not automatically use Premiere preview files for encoding. To make use of the Premiere preview files, you must select the Use Previews option in Adobe Media Encoder for each encoding process." Per process — not once, globally.
Slow, or actually stuck?
Before optimising, confirm the queue is moving. In Adobe's status table, Ready means "The item is in the encoding queue but has not been encoded," while Failed means "Adobe Media Encoder encountered an error when attempting to encode the specified item."
One documented cause of an immediate failure is the destination: "When specifying a destination folder, ensure that the specified destination folder exists. If you specify a folder that does not exist, an error message informs you that the file cannot be encoded because the folder cannot be found."
And when the reason is not obvious, there is an official log. Media Encoder writes two plain-text files — AMEEncodingLog.txt "for successfully encoded jobs" and AMEEncodingErrorLog.txt "for jobs that failed, or were stopped by the user." You can open them from inside the app: "To view the log file, choose File > Show Log or press Ctrl + L," and "To view the error log file, choose File > Show Errors." On disk they live here:
Windows 10 (v22H2 or later) and 11: C:\Users\[user]\Documents\Adobe\Adobe Media Encoder\[product version]\AMEEncodingLog.txt
Mac OS Monterey (version 12 or later): /Users/[user]/Documents/Adobe/Adobe Media Encoder/[product version]/AMEEncodingLog.txtFAQ
Can Adobe Media Encoder encode multiple files at the same time? No. Adobe's documentation says it "encodes all sources in sequence, but encodes all outputs of a source in parallel," and that "it cannot be used to export different sources simultaneously." Multiple outputs of one source run together; multiple sources do not.
How do I turn on parallel encoding? It is already on — "Parallel encoding is on by default." The preference exists to switch it off, at Edit > Preferences, by deselecting Enable Parallel Encoding.
Why did one of my outputs encode on its own instead of in parallel? Adobe notes that "certain cases" of export settings force serial encoding for an output, after which "the queue returns to parallel encoding after temporary serial encoding is complete." The page does not list which settings do this; check the official documentation for your version.
Why is Media Encoder slower than exporting straight from Premiere? One documented reason is preview files: Media Encoder "does not automatically use Premiere preview files for encoding," and you must tick Use Previews for each encoding process. Premiere's own export dialog has the same option in the General section.
Do I need Media Encoder at all for simple conversions? Not for a format or container swap. Browser-side tools handle those without a queue — start at all Clapr tools or browse more Premiere and export guides.
All quotes above are from Adobe's official Premiere Pro and Media Encoder help pages, checked 22 September 2026. Adobe revises these pages; verify against the current documentation before relying on any behaviour described here.
