H.264 is the de-facto standard for file based video delivery, a fact we all know and live with. Premiere Pro tries its best to hide some of the more advanced aspects of it’s two h.264 encoding methods but there comes a point where sometimes we need to dig a bit deeper. I remember editing a commercial about 2 years ago where I was given a deliver spec with very specific needs about GOP size, B frame count, and so on. While Premiere allows you to edit keyframe distance (GOP size), it doesn’t let you control the amount of B frames directly. I compressed that video with FFMPEG/x.264 and I’ve been using it ever since for fine control.
I have to give a special thanks to Creative Cow contributor Ivan Myles for bringing up this conversation and digging in to find some of the information I’m about to present.
Before we dive into things, if you aren’t familiar with h.264 or know what GOP, M and N values, P frames, or B frames are, then I suggest the following resources:
A Guide to Common Video Formats: Containers, Compression, and Codecs
http://en.wikipedia.org/wiki/H.264
http://en.wikipedia.org/wiki/Group_of_pictures
First we have Premiere’s h.264 codec in the MP4 container. It’s no big secret that this is MainConcept’s h.264 codec with more streamlined controls. You’ll notice that the M value and number of B frames is almost solely dependent on the selected h.264 profile. Level, to a point is selected based on framerate, frame size, etc. and seems to have no bearing on controlling the number of B frames. It also appears that the multiplexing controls restrict the use of B frames for Apple devices while also changing the ID of the MP4 container for compatibility with certain device families.
Adobe Premiere Pro h.264 MP4 Container | |||||
Options | Container ID | Profile | M Size | B frames | GOP Example |
Standard | MP42 | Baseline | 1 | 0 | IP… |
Standard | MP42 | Main | 4 | 3 | IBBBP… |
Standard | MP42 | High | 3 | 2 | IBBP… |
iPod | M4V | Baseline | 1 | 0 | IP… |
iPod | M4V | Main | 1 | 0 | IP… |
iPod | M4V | High | 1 | 0 | IP… |
PSP | MSNV | Baseline | 1 | 0 | IP… |
PSP | MSNV | Main | 4 | 3 | IBBBP… |
PSP | MSNV | High | 3 | 2 | IBBP… |
We also have Quicktime’s native h.264 codec. This codec is limited to the Main profile and Premiere Pro limits Quicktime to single-pass operation. Checking the option for frame reordering will turn on the use of B frames.
Adobe Premiere Pro h.264 MOV Container | ||||
Options | Profile | M Size | B frames | GOP Example |
Standard | Main | 1 | 0 | IP… |
Frame Reordering | Main | 2 | 1 | IBP… |
The use of the MainConcepts codec is superior and MOV and MP4 can be used interchangeably in many workflows. MP4, as a container, is based off Quicktime so a quick renaming of file extensions often allows the use of MP4 files in programs that only accept MOV. If you’re using more advanced features of either container, it may be worth a true rewrap using FFMPEG or FFMBC after encoding. This page goes over some of the fundamental differences between the two containers.
Thanks for your post. Can FFMPEG/x.264 somehow be integrated/added to Premiere (as an export option) or are you using an entirely different application for your advanced x264 encoding?
I use Windows so there is no suitable solution. If you’re on OSX then this appears to be a stable solution many people recommend to make x264 a Quicktime codec http://www003.upp.so-net.ne.jp/mycometg3/
Does it make any sense that QuickTime MPEG-4 would come out with richer colors and less pixelation?
This is what I found when trying to find the best settings myself:
http://goo.gl/8GZq4i
Here is how I interpret your findings: I don’t trust Quicktime’s native encoder because of the gamma issue. As to whether it’s hard coded or due to flags on the file (either seem hit and miss), I’m not entirely sure and I’ve even tried reaching out to Technicolor to get their expert opinion. Generally, if I export it and bring it back into Premiere, if the colors match then that’s what I want to use; it’s like an audio mixer who mixes on the most accurate speakers possible knowing that in the real world it may be played on everything from an iPhone to a club sound system. There are huge amounts of variability in the wild when it comes to what colors will look like in non-professional software and screens.
Secondly, you may want to retest. Your keyframe distance too high for your QuickTime export. While this can preserve bitrate usage which is why you see less pixelation overall, you’ll probably end up with pixelation issues around cuts/fades if scenes change rapidly. Good rule of thumb, unless you’re limited by producing a file for a specific hardware device, is keyframe distance equal to half your framerate even if you have to bump up your bitrate to increase quality. A keyframe is a full frame stored in the file while surrounding frames just store the changes between keyframes, this is why they can eat up the bitrate you allocate.
Interesting, thanks for the input. I am going to test this out and see what I get.