4

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

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

Smallest file by AME on the left and reencoded by libx264 on the right

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.

Improve this question

2 Answers 2

Reset to default
4

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.

Improve this answer
2
  • 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
    Commented Mar 19, 2020 at 9:01
  • 1
    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
    Commented Mar 19, 2020 at 11:41
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, 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.

  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:

Improve this answer
4
  • 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
    Commented Mar 21, 2020 at 10:55
  • 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
    Commented Mar 25, 2020 at 5:09
  • @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
    Commented Mar 27, 2020 at 4:03
  • 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
    Commented Mar 27, 2020 at 4:43

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.