<p>I avoid AME and use x264 via <code>ffmpeg</code> for H.264 encoding. From Premiere I prefer to output a temporary lossless compressed format as the intermediate, such as the free and open-source <a href="https://github.com/umezawatakeshi/utvideo" rel="nofollow noreferrer">Ut video</a>, instead of DNxHD/DNxHR/ProRes. This avoids any generation loss (minor as it may be with ProRes/DNxHD, but still technically present as they are not lossless). Also, I'm guessing it is faster to encode but I never benchmarked it.</p>

<ol>
<li><p>Save your project and close Premiere Pro.</p></li>
<li><p>Install ​<a href="https://github.com/umezawatakeshi/utvideo/releases" rel="nofollow noreferrer">Ut Video</a>.</p></li>
<li><p>Open Premiere, select your sequence, and choose <em>File > Export > Media</em> (or press <kbd>Ctrl</kbd>+<kbd>M</kbd>).</p></li>
<li><p>Under <em>Export Settings</em> choose <em>Format: AVI</em> and make sure <em>Export Video</em> and <em>Export Audio</em> are both checked. Then under <em>Video Codec</em> choose <em>Ut Video Codec YUV420</em>. Lastly, check your <em>Basic Video Settings</em> to make sure Premiere did not screw around with the frame size, frame rate, etc, as it is apt to do.</p></li>
<li><p>Encode the AVI to MP4 with <code>ffmpeg</code>. Use the highest <code>-crf</code> value that gives you an acceptable quality and the slowest <code>-preset</code> you have patience for.</p></li>
</ol>

<p>These instructions were written for CS6, but CC will be similar enough.</p>

<p>More info:</p>

<ul>
<li><a href="https://trac.ffmpeg.org/wiki/Encode/PremierePro" rel="nofollow noreferrer">FFmpeg Wiki: Premiere</a>. It's outdated, but the UT video section still applies.</li>
<li><a href="https://trac.ffmpeg.org/wiki/Encode/H.264" rel="nofollow noreferrer">FFmpeg Wiki: H.264</a></li>
<li><a href="https://trac.ffmpeg.org/wiki/Encode/H.265" rel="nofollow noreferrer">FFmpeg Wiki: H.265/HEVC</a></li>
</ul>

CC BY-SA 4.0
2020-03-21T10:55:39.780Z
Thank you very much. In other situations, I would be very interested in a free open-source lossless intermediate format (in the audio world, I am a keen user of FLAC). In the present situation, I will probably go for something more immediate even if lossy. As a side comment, I did try to install Ut Video and it now has very many codecs available, none whose name is as above; other people reading this question and answer in the future may profit from a recommendation as to what specific codec would be a good choice.
Paolo
CC BY-SA 4.0
2020-03-25T05:09:35.440Z
There's probably not much point going for a lossless codec as your intermediate. The quality difference between using something lossless and a purpose-built intermediate codec like ProRes, DNxHR, or Cineform is going to be negligible after you compress to h.264. An intermediate codec will save a lot of hard drive space, and possibly be faster to render.
stib
CC BY-SA 4.0
2020-03-27T04:03:57.497Z
@stib In my case the intermediate is always temporary, so file size is a non-issue. Doing a quick test run in AME 19 showed that ut video encoding took about the same time as prores and dnxh* using vanilla settings (ut video encoding in ffmpeg is significantly faster, and decoding is somewhat faster). Additionally, I'm guessing ut video would be easier on the editor, and therefore more responsive, but I haven't tested. But my preference is not all based on numbers: I prefer open source.
llogan
CC BY-SA 4.0
2020-03-27T04:43:44.120Z
I've had trouble getting UtVideo to work in the past, but that was a while ago. Another codec you might be interested in is FFV1, we use that at work for archival purposes (thanks to me refusing to let them use a proprietary codec).
stib
CC BY-SA 4.0
2020-03-19T17:59:39.977Z
2020-03-19T17:59:39.977Z
llogan
<p>Adobe licenses its H.264 encoder from Mainconcept, which doesn't do that well at low bitrates. x264 is pretty much the frontier when it comes at low size output for a given quality target, or quality for a given bitrate target. x264 is what's used by platforms like Youtube / Vimeo ..etc to encode user videos.</p>

<p>One thing you could try is to increase the keyframe interval. Default for x264 is 250 frames. Mainconcept will be something around 30-60 frames. If you can get them similar, I expect this to provide a moderate benefit in AME's encoding.</p>

<p>It is possible to use x264 with Adobe tools via VFW - <a href="https://sourceforge.net/projects/x264vfw/files/" rel="nofollow noreferrer">https://sourceforge.net/projects/x264vfw/files/</a>. But I don't recommend it. It's not maintained and there were stability issues.</p>

<p>My recommendation is to export a lighly compressed 1080p encode from AME - possibly DNxHD/HR codec in MOV or MXF container format, and then run the following ffmpeg command:</p>

<pre><code>ffmpeg -i input.mov -c:v libx264 -crf 20 -movflags +faststart output.mp4
</code></pre>

<p>The <code>faststart</code> flag helps with quick playback start for web viewers.</p>

CC BY-SA 4.0
2020-03-19T09:01:34.703Z
Thanks a lot. Very useful--it is good to know that it is likely a waste of time to try to get AME to match the output of x264. I will definitely try you suggestion pretty soon.
Paolo
CC BY-SA 4.0
2020-03-19T11:41:19.253Z
You're now ahead of a lot of professionals who still use AME to do h.264 encoding, congratulations. The other advantage of exporting a master in an intermediate format like DNxHR or ProRes is that you can get the compression right without having to re-render. It's usually much quicker to compress than to render and compress.
stib
CC BY-SA 4.0
2020-03-19T05:36:00.823Z
2020-03-19T05:36:00.823Z
Gyan
<p>I am a terrible ignoramus in the subject, but the coronavirus has thrown me in the business of producing videos with my lectures. I care a bit for video quality and a bit more for small size. My source is probably seen as abysmal from professionals: it is a screen capture (4K) by Zoom, heavily compressed. It still looks fairly decent and I import clips in Adobe Premiere Pro 2020 and edit them. The problem is in encoding the final sequences.</p>

<p>I lazily started by using the default preset for H.264 ("Match Source - High bitrate). Unsurprisingly, files are very big but visual quality as good as it gets. Good enough for me at first.</p>

<p>Then a student suggested I use this to compress the videos with this</p>

<blockquote>
  <p><strong><em>ffmpeg -i input.mp4 -vf scale=1920:-1 -vcodec libx264 -crf 20 output.mp4</em></strong></p>
</blockquote>

<p>I did not run myself but he sent me an example and my 1.4 GB file went down to 74 MB without any particularly noticeable quality loss (note that most of the videos are slides and completely static for minutes, so it stands to reason that they compress very well). Here an example of typical frames:</p>

<p><a href="https://i.sstatic.net/Cia77.jpg" rel="nofollow noreferrer"><img src="https://i.sstatic.net/Cia77.jpg" alt="Original by AME on the left and reencoded by libx264 on the right"></a></p>

<p>Great, but, of course, I thought that I would not reencode with libx264 and rather produce similarly small files directly from Adobe Media Encoder. Firstly, I reduced the resolution to 1920x1080 during the export. Then, I spent an inordinate amount of time with the default H.264 encoder ("Hardware Encoding") to explore what happens reducing the only control I thought I should focus on (Target Bitrate). I would not manage to go below 650 MB with the smallest target bitrate (0.19 Mbps) but could reach 420 MB with a target bitrate of 1 Mbps. This makes little sense to me, but then I read somewhere to use the "Software Encoding" to get small files. I tried (also exploring blindly different profiles: Main, High, High10) and set the target and maximum bitrate also to the minimum (0.19 Mbps again). Size went down to 112 MB and, although not as small as the libx264 file, I thought it would be ok. The problem is that the quality degraded very noticeably. Here are a couple of examples:</p>

<p><a href="https://i.sstatic.net/Rnlgf.jpg" rel="nofollow noreferrer"><img src="https://i.sstatic.net/Rnlgf.jpg" alt="Smallest file by AME on the left and reencoded by libx264 on the right"></a></p>

<p><a href="https://i.sstatic.net/bE2Pp.jpg" rel="nofollow noreferrer"><img src="https://i.sstatic.net/bE2Pp.jpg" alt="Smallest file by AME on the left and reencoded by libx264 on the right"></a></p>

<p>Clearly, I must be missing something pretty fundamental here, but what? Is it possible that Adobe Media Encoder is so much inferior to libx264? Did I miss some key encoding parameter? (There do not seem to exist many in AME, nor they look like those of libx264.)</p>

<p>Any help would be much appreciated!</p>

<p>p.</p>

<ffmpeg><h.264><compression><adobe-media-encoder><libx264>
Producing small H.264 files with Adobe Media Encoder vs ffmpeg/libx264
Paolo
# Producing small H.264 files with Adobe Media Encoder vs ffmpeg/libx264

(Asked by: username_0 on 2020-03-18)

I am a terrible ignoramus in the subject, but the coronavirus has thrown me in the business of producing videos with my lectures. I care a bit for video quality and a bit more for small size. My source is probably seen as abysmal from professionals: it is a screen capture (4K) by Zoom, heavily compressed. It still looks fairly decent and I import clips in Adobe Premiere Pro 2020 and edit them. The problem is in encoding the final sequences.

I lazily started by using the default preset for H.264 ("Match Source - High bitrate). Unsurprisingly, files are very big but visual quality as good as it gets. Good enough for me at first.

Then a student suggested I use this to compress the videos with this

> ***ffmpeg -i input.mp4 -vf scale=1920:-1 -vcodec libx264 -crf 20 output.mp4***

I did not run myself but he sent me an example and my 1.4 GB file went down to 74 MB without any particularly noticeable quality loss (note that most of the videos are slides and completely static for minutes, so it stands to reason that they compress very well). Here an example of typical frames:

[![Original by AME on the left and reencoded by libx264 on the right](https://i.sstatic.net/Cia77.jpg)](https://i.sstatic.net/Cia77.jpg)

Great, but, of course, I thought that I would not reencode with libx264 and rather produce similarly small files directly from Adobe Media Encoder. Firstly, I reduced the resolution to 1920x1080 during the export. Then, I spent an inordinate amount of time with the default H.264 encoder ("Hardware Encoding") to explore what happens reducing the only control I thought I should focus on (Target Bitrate). I would not manage to go below 650 MB with the smallest target bitrate (0.19 Mbps) but could reach 420 MB with a target bitrate of 1 Mbps. This makes little sense to me, but then I read somewhere to use the "Software Encoding" to get small files. I tried (also exploring blindly different profiles: Main, High, High10) and set the target and maximum bitrate also to the minimum (0.19 Mbps again). Size went down to 112 MB and, although not as small as the libx264 file, I thought it would be ok. The problem is that the quality degraded very noticeably. Here are a couple of examples:

[![Smallest file by AME on the left and reencoded by libx264 on the right](https://i.sstatic.net/Rnlgf.jpg)](https://i.sstatic.net/Rnlgf.jpg)

[![Smallest file by AME on the left and reencoded by libx264 on the right](https://i.sstatic.net/bE2Pp.jpg)](https://i.sstatic.net/bE2Pp.jpg)

Clearly, I must be missing something pretty fundamental here, but what? Is it possible that Adobe Media Encoder is so much inferior to libx264? Did I miss some key encoding parameter? (There do not seem to exist many in AME, nor they look like those of libx264.)

Any help would be much appreciated!

p.

**Tags:** ffmpeg, h.264, compression, adobe-media-encoder, libx264


---

## 2 answers

### Answer by username_3 on 2020-03-19. Score: 4 | Accepted answer

Adobe licenses its H.264 encoder from Mainconcept, which doesn't do that well at low bitrates. x264 is pretty much the frontier when it comes at low size output for a given quality target, or quality for a given bitrate target. x264 is what's used by platforms like Youtube / Vimeo ..etc to encode user videos.
One thing you could try is to increase the keyframe interval. Default for x264 is 250 frames. Mainconcept will be something around 30-60 frames. If you can get them similar, I expect this to provide a moderate benefit in AME's encoding.
It is possible to use x264 with Adobe tools via VFW - https://sourceforge.net/projects/x264vfw/files/. But I don't recommend it. It's not maintained and there were stability issues.
My recommendation is to export a lighly compressed 1080p encode from AME - possibly DNxHD/HR codec in MOV or MXF container format, and then run the following ffmpeg command:
ffmpeg -i input.mov -c:v libx264 -crf 20 -movflags +faststart output.mp4

The faststart flag helps with quick playback start for web viewers.

> **Comments:**
> **username_0**: Thanks a lot. Very useful--it is good to know that it is likely a waste of time to try to get AME to match the output of x264. I will definitely try you suggestion pretty soon.  
> **username_2**: You're now ahead of a lot of professionals who still use AME to do h.264 encoding, congratulations. The other advantage of exporting a master in an intermediate format like DNxHR or ProRes is that you can get the compression right without having to re-render. It's usually much quicker to compress than to render and compress.  

---

### Answer by username_1 on 2020-03-19. Score: 2

I avoid AME and use x264 via `ffmpeg` for H.264 encoding. From Premiere I prefer to output a temporary lossless compressed format as the intermediate, such as the free and open-source [Ut video](https://github.com/umezawatakeshi/utvideo), instead of DNxHD/DNxHR/ProRes. This avoids any generation loss (minor as it may be with ProRes/DNxHD, but still technically present as they are not lossless). Also, I'm guessing it is faster to encode but I never benchmarked it.

1. Save your project and close Premiere Pro.
2. Install ​[Ut Video](https://github.com/umezawatakeshi/utvideo/releases).
3. Open Premiere, select your sequence, and choose *File > Export > Media* (or press `Ctrl`+`M`).
4. Under *Export Settings* choose *Format: AVI* and make sure *Export Video* and *Export Audio* are both checked. Then under *Video Codec* choose *Ut Video Codec YUV420*. Lastly, check your *Basic Video Settings* to make sure Premiere did not screw around with the frame size, frame rate, etc, as it is apt to do.
5. Encode the AVI to MP4 with `ffmpeg`. Use the highest `-crf` value that gives you an acceptable quality and the slowest `-preset` you have patience for.

These instructions were written for CS6, but CC will be similar enough.

More info:

* [FFmpeg Wiki: Premiere](https://trac.ffmpeg.org/wiki/Encode/PremierePro). It's outdated, but the UT video section still applies.
* [FFmpeg Wiki: H.264](https://trac.ffmpeg.org/wiki/Encode/H.264)
* [FFmpeg Wiki: H.265/HEVC](https://trac.ffmpeg.org/wiki/Encode/H.265)

> **Comments:**
> **username_0**: Thank you very much. In other situations, I would be very interested in a free open-source lossless intermediate format (in the audio world, I am a keen user of FLAC). In the present situation, I will probably go for something more immediate even if lossy. As a side comment, I did try to install Ut Video and it now has very many codecs available, none whose name is as above; other people reading this question and answer in the future may profit from a recommendation as to what specific codec would be a good choice.  
> **username_2**: There's probably not much point going for a lossless codec as your intermediate. The quality difference between using something lossless and a purpose-built intermediate codec like ProRes, DNxHR, or Cineform is going to be negligible after you compress to h.264. An intermediate codec will save a lot of hard drive space, and possibly be faster to render.  
> **username_1**: @username_2 In my case the intermediate is always temporary, so file size is a non-issue. Doing a quick test run in AME 19 showed that ut video encoding took about the same time as prores and dnxh* using vanilla settings (ut video encoding in ffmpeg is significantly faster, and decoding is somewhat faster). Additionally, I'm guessing ut video would be easier on the editor, and therefore more responsive, but I haven't tested. But my preference is not all based on numbers: I prefer open source.  
> **username_2**: I've had trouble getting UtVideo to work in the past, but that was a while ago. Another codec you might be interested in is FFV1, we use that at work for archival purposes (thanks to me refusing to let them use a proprietary codec).  

---

