A couple of weeks ago I had posted a comparison on my blog showing the quality differences between Premiere Pro & FCP X when it came to H264 compression. Since writing the article I have had loads of questions about my findings and have done some more testing on my own time, so I am posting the follow up test results here today.
For those of you that were asking about more specific settings that weren’t detailed in my first post, here are a couple of screenshots from Compressor and Media Encoder, showing how I had things set up. I ran the tests (both times) using FCPX/Premiere Pro as well as Compressor/Media Encoder, and used the same settings each time. It’s worth noting that the screenshots below were taken from my most recent test (as I didn’t take screenshots during my initial test), but all of the settings were identical.
Compressor
Media Encoder
Some of the most important settings that were universally used throughout all my tests were:
Data Rate: 20000 kbits/sec
Resolution: 1920 x 1080
Frame Rate: 23.976
Field Order: Progressive
PAR: 1.0
Frame Reordering: On
Encoding: Best Quality / Use Maximum Render Quality
Container: .MOV
The reason that I highlighted which container I used for the file is because on my initial test there was some variance on Media Encoder between H264 .MOV files and H264 .MP4 files (the former of which was more problematic).
On my first test, for some reason Compressor had a cleaner image that had fewer artifacts and less color shifting as you can see here (click to enlarge):
FCP X/Compressor
Premiere Pro/Media Encoder
Once I decided to re-do the test using a more recently updated version of Premiere Pro/Media Encoder however, I got very different results. Here are two screenshots from an H264 encoded video file (one from Premiere Pro and one from FCP X)… It’s nearly impossible to tell the difference between the two now:
FCP X/Compressor
Premiere Pro/Media Encoder
The only variable that had changed between my initial test and the most recent test which gave very different results, was the updated version of Premiere Pro/Media Encoder that I was using. I tested the same settings while rendering out directly from Premiere, as well as directly from Media Encoder and had the same improved results both times. Clearly whatever small issue may have existed with the previous iteration of Adobe’s software has now been rectified, and it’s great to have such confidence in the compression capabilities of the software now.
The main reason that I did this follow up test (outside of all of the requests from my blog readers) was because Adobe had contacted me after seeing my initial post and wanted to know more about this issue themselves. I have to say that I was very impressed by the level of interest that they expressed in this small test, as one of the most important things that I look for when investing my time and money in a piece of software today, is the integrity of the company that has created it. There’s no question to me after speaking with the Adobe team that they are dedicated to continually perfecting their products in a way that will reflect professional customer feedback and real user experiences. No matter what your preference may be with regards to editing or creative software, there is no denying that it’s refreshing to have a company as big as Adobe make such an effort to actually listen to their customers.
This mentality is becoming more and more important every day, not only in the post-world but also with manufacturers of cameras, production gear and many other technologically driven businesses in our industry. At the end of the day, it’s the real users that are seeing first hand (in real world environments) the strengths and weaknesses of any given product and then recommending it to colleagues (or not) based on their own experience with it. I hope that more companies in our industry start to understand the importance of listening more clearly to their user base and allowing genuine feedback to guide future products and updates.
Be sure to subscribe to the newsletter on the right panel of this page to be updated on more articles like this, reviews, tutorials, and inspiration!
16 Comments
Mark
atI know not common today, but I recently had to encode SD DVCam files to MPEG-2 for DVD and found Adobe Media Encoder v22.1.1 to be atrocious. I felt like I’d time travelled back to 2002 chasing esoteric mpeg-2 encoders on Power Mac G4. I usually just use Adobe CC, but grabbed Compressor 4.1.6 and was surprised to get better outputs. I also did some HEVC encoding tests comparing GPU hardware accelerated (AMD RX 6800 XT) to CPU slower encodes. On my tests of 4K 100Mbps downscaled to 2K 15Mbps output the much faster GPU hardware accelerated results were so close in quality to the CPU software encodes that I would not bother to do slower encodes – the last time i did this sort of test a while ago the GPU accelerated results were noticeably worse than CPU software encoding.
Noam Kroll
atAppreciate you sharing this here, Mark!
sean chandler
atWith the release of Premiere Pro CC 2018 and FCPX 10.4, which one is the better for Mac users, specifically recent (last couple of years) MacBook Pro?
Noam Kroll
atAt this point, I have moved off of Premiere and am entirely on FCP X and DaVinci Resolve, so I can’t speak to Premiere Pro…
Rey
atfinally this article is the longtime answer Ive been looking. this is the reason why my gopro videos look so grainy and get worse when uploaded in youtube. Ive been using Premiere pro from the beginning and it sucks, Im moving to final cut, premiere sucks and a ripoff! they have far more advance settings and options than FCPX but I dont care how futuristic they are, their H264 sucks and its all I want to make my videos look better on youtube.
Noam Kroll
atIt was a huge frustration for me too, but thankfully Adobe has addressed the issue now! Either way, it’s great to know both pieces of software so you can choose which one is best based on your project.
Owen
atHi Noam,
Thanks for doing these comparisons. As a premiere user I’m relieved to see that you can achieve identical results. One question: I always tick the “render at maximum depth” box in Premiere/media encoder, although I can’t say I know that it makes a difference. Is there a reason you have left this option turned off in these comparisons?
Thanks.
Noam Kroll
atHi Owen, thanks for the note! I have tried it with both option on and off, and typically haven’t seen a major quality difference (or a noticeable one for that matter).
Final Cut X & Adobe Premiere Pro H.264 Compression Update | 4K Shooters
at[…] [via http://www.noamkroll.com] […]
Petar Zeman
atGreat update!
Can you say what was render times for both?
Cheers.
Noam Kroll
atThanks a lot! I didn’t time them, but Media Encoder/Premiere was significantly faster as usual.
Julien Chichignoud
atHi Noam,
Thanks for investigating further.
The reason why the Adobe export looked inferior is more obvious now. The screenshot you posted shows that your Premiere/AME export is set-up as 1-pass (not sure if VBR or CBR). For some reason you can’t do 2-pass VBR in a Quicktime container from there.
The Quicktime container also explain why you had a gamma shift, as Quicktime files contain a gamma tag which is often misread depending on what software you open the file with (and isn’t read at all when uploaded to YouTube/Vimeo). For that reason, I stick with .mp4 containers and have had very consistent results, both from FCP and Premiere.
Noam Kroll
atThanks Julien.
Just to clarify though, on my original test (which did show different results) I used every possible VBR/CBR setting and combination and still didn’t get the right results. Since I was able to get good results from Premiere/ME even with a 1 pass VBR, I was confident that it wasn’t that setting which was the variable in question… Still not sure exactly what caused the issue, but the good news is that Adobe has worked hard to fix it!
Jarle Leirpoll
atNoam, if you still have the original video files that you exported for the first test, we could examine them, and see what Profile, Level and other settings you used.
Please make them available, so we can see if your claim that “The only variable that had changed between my initial test and the most recent test which gave very different results, was the updated version of Premiere Pro/Media Encoder that I was using” is actually true.
Noam Kroll
atHi Jarie,
I will dig through the archive and post some clips down the road when I do another follow up. Next I will be comparing some other codecs and software in addition to FCP X/Premiere.
Chris Hocking
atWhat version of CC were you running for the original tests?
Noam Kroll
atI will need to check into that and see if I can pull up the exact version. Sorry I don’t have the answer at this time… It was likely 1 iteration before the update that I had used on the follow up.