As for why I did not include TMPGEnc in the previous article and only post this article now, because it refused to read MKV again. Installing Shark007 did not help, but CCCP did.
Also, the original article which was supposed to be a quick look became an 8-way slugfest with 14 encodes instead as I spotted sources of errors and went to correct them. I swore to limit the number of encodes to five for all my future reviews, and I almost forgot about this already as I wrote this portion; I had to force myself to stop at five after realizing things are becoming messy.
Test setup
Input: 1920x1080 @ 23.976fps, 1m31s, 17.3Mbps H.264 (High@L5.1) (CABAC / 7 Ref Frames)
Output: One-pass, resolution 480x272, frame rate unchanged
Freemake: "Auto" was selected, resulted in a setting of 13MB, and a resulting filesize of 11.7MB.
Mediacoder: I trial-and-errored with this one, and with a bit of math settled on 62 quality with resultant filesize of 11.5MB on my third try.
TMPGEnc: The settings I have been using for PSP (quality-based, 24-25-27 for I-P-B frames respectively) resulted in a filesize of 11.2MB.
In short, I was very lucky. Or maybe not, because...
Where I screwed up
Freemake encoded at Main@L2.1, CABAC, 1 Ref Frame(s). I chose MP4 output and as mentioned in the previous article, settings are limited. But then I found a PSP output button which resulted in Baseline@2.1, 1 Ref Frame(s).
Freemake also did another encode with DXVA turned on.
Mediacoder encoded Baseline@L3.2, 2 Ref Frames, 1 B-Frame
Mediacoder also encoded another file at Baseline@L3.2, 3 Ref Frames, 3 B-Frames, which resulted in around the same encoding speed.
TMPGEnc encoded Main@L3.2, CABAC, 3 Ref Frames, 3 B-Frames
As you can see, this is very messy. I dunno why I encoded @ Baseline for Mediacoder, I have no excuse for that. But PSP definitely supports Main profile and CABAC, so there is little reason for Freemake to choose Baseline@2.1 for the PSP. So I'll ignore that encode and use the Main@L2.1 one.
Another screwup - I think CUDA acceleration was on in Freemake in the previous article as well as in the first encode for this article. However when I did another encode with CUDA off, the speed was slightly faster, like in the case for Mediacoder. Considering they both use x264, Freemake probably got the same image quality with and without CUDA turned on as was the case with Mediacoder. So no big harm done.
I also screwed up a little with aspect ratios - TMPGEnc and Freemake added black bars to make the video stay 16:9 (480x270 on a 480x272 screen), but I didn't do the same with Mediacoder. But in my defense, these were the default settings which I didn't touch. Also the impact is minimal.
For some reason Freemake decided to put the black bars only on the bottom, now this is not my fault.
Also, not as important, but I just wanted to say - TMPGEnc supports CUDA acceleration for filters only, so although I have a GTX 560 and CUDA is turned on, GPU was 0% all the way because no filters were used.
Encoding time comparison
You may be wondering, how come Freemake is vastly slower compared to Mediacoder this time round. Even TMPGEnc, which is slow as a m**********, is faster than Freemake.
This screenshot has the answer.
It is so easy to encode at 480x272, it takes more CPU power to decode say a second of the 1080p H.264 than to encode one at 480x272. So decoding speed becomes a more important factor at determining the encoding speed.
Because Mediacoder and TMPGEnc both used DirectShow to read the files, they decoded using LAV, or that is what I think because LAV is the only decoder capable of decoding Hi10P that is installed on my system. And LAV is a fast decoder. In comparison, Freemake used something else - probably built-in or Microsoft, I don't really know, but I know it is not LAV (at least not the same one) because it failed to read a Hi10P video properly.
This also means that DXVA decoding is going to help a lot with encoding speed, evident in the speed of Freemake with DXVA enabled. And most of the time we (as in consumers) convert a downloaded H.264 video to a smaller file with lower quality (why would you do the opposite?), so fast decoding is going to be important.
The great thing about using DirectShow to decode is that you can use any decoder and any filter with that encoder, and any settings that affect DirectShow players, like enhancements and subtitles, will also show up with that encoder.
Encoding quality comparison
Screenshots
Freemake looks better with DXVA on, interesting.
Mediacoder looks the same with or without the additional Ref and B-Frames.
Freemake is undoubtedly the worst out of the three.
TMPGEnc did some sharpening (I swear I didn't touch any setting). It was very nicely executed, because when everything is blur like **** at such low resolutions the extra sharpness comes in handy. Funnily I don't recall seeing this sharpening when downscaling is not involved, so it must have been added by TMPGEnc during downscaling, which is very smart. I mean, look at the screenshots, this is the first time I can safely say that there is no reason to not apply this sharpening.
However, this means TMPGEnc and Mediacoder are apple and orange.
Conclusion - which encoder is right for me?
(Because it isn't always about you)
Things learnt today:
- An encoder (or encoder settings) that is good in scenario A may not be the best in scenario B
- Decoding speed (and acceleration) is very important when encoding at low resolutions and bitrates
- DirectShow is important
So Freemake, despite poorer quality, was slower due to decoding speed, but after DXVA was enabled it was very fast. But still, the image quality (which improved with DXVA enabled?) has room for improvement. But more importantly, without Hi10P support it is going to be hard for me to use it, with more and more encodes going Hi10P these days.
Mediacoder... nothing much to say about it. TMPGEnc's extra sharpening has benefits that greatly outweigh the costs. Looks like I'm sticking to TMPGEnc.
Update 15/01/12 - Is TMPGEnc Xpress really the winner? Does the extra sharpening really make it better over Mediacoder using x264? What if one can get the best of both worlds? Find out here.
No comments:
Post a Comment