Re: 3am X264 PRO Plugin Crack
Gifford Brickley
Legal Report Trademark Abuse
VideoLAN, VLC, VLC media player and x264 are trademarks internationally registered by the VideoLAN non-profit organization.
VideoLAN software is licensed under various open-source licenses: use and distribution are defined by each software license.
The problem here was that x264 was not properly installed. I checked the x264 source directory and the installation destinations and some files were missing. After manually copying them into the respective directories recompiling the gstreamer ugly module worked.
For me, it is x264/x265 export with CRF support, that I am missing. The h.264/h.265 encoding in Resolve just doesn't come close to x.264/x.265. Right now, I'm exporting DNxHR from DVR and then encode my mp4's in Handbrake. I would looove to get rid of this step, as I usually have to do it several times because I keep noticing new mistakes in the end file.
Well, this is just a first prototype of 2 days work. Nothing has been optimized yet. But I don't think voukoder will ever be faster than the native DVR implementation. The goal is to have more encoders available in DVR - the existing encoder implementations seem to be quite good actually.
Still: Voukoder is not the magical tool to make everything faster. But it might offer you more encoders and more options. And I guess DVR uses CUDA in a clever way to prevent lots of copy actions from/to host and gpu.
A new plug-in for Premiere Pro has been released that uses the x264 encoder to export to H.264 and H.264 Blu-ray. I've had a chance to use it a fair bit, and the quality is excellent compared to Premiere Pro's built-in MainConcept H.264 encoder. It's also fast -- as fast as the Premiere Pro plug-in architecture will allow.
Were you trying to queue an export from Pr? At least one recent version of Premiere Pro (CC or CS6 or both) would call the 32-bit version of the Adobe Media Encoder instead of the 64-bit version of the AME. The solution is to move, rename or delete the 32-bit AME .exe file. When Pr can't find it, it switches to the 64-bit version.
EDIT: It was CS6 where I first encountered this bug. Further, the shortcut to the AME that is created in your Start Menu when you install Premiere Pro also points to the 32-bit version of the AME, so this issue may appear even if you're not queuing the export from Pr.
Guys, don't be giving your money away that easily. I've done my own tests and found out that x264 PRO for Premiere is a perfect example of overhyped product. I was really excited to find out someone turned x264 into a Premiere plugin, so I decided to give it a try. Sadly, after a few tests I realized this plugin is a total waste of time. First of all, it's much slower than MainConcept H.264 codec, found in Adobe CC package, and I honestly don't see, how it's better quality-wise. Secondly, it creates more artifacts than original x264 freeware codec. And thirdly, it shifts colors of the material you are encoding. I don't see why anyone would spend 299$ for this thing.
But, I won't waste your time babbling unsubstantiated statements. Alllow me to present you some actual figures. I've converted my recent 12 minutes 12 seconds long 1080p project (STARS Academy at the 18th WCOPA Event on Vimeo) using Adobe Media Encoder CC 2014 v8.0.1.48 (MainConcept and x264 PRO codecs) and MediaCoder v0.8.32.5660 (x264 original codec). The Vimeo version is reduced in quality and size, of course. My conversions were made from nearly lossless Full HD material. All codecs were set to 12 Mbps target bitrate, 24 Mbps maximum bitrate (except original x264, which didn't offer max bitrate setting), High profile, VBR 2-pass encoding, AAC 256 kbps audio. Both x264 codecs were set to Film picture tuning and Very Slow encoding quality, because I wanted to see the best possible result that I can squeeze out of each codec at a given bitrate. Timewise, the results are:
Original x264 completed conversion 25% faster, then x264 PRO, while Adobe's MainConcept implementation did it almost 75% faster! Of course, if I would have set x264 encoding quality to Medium, the difference wouldn't be so substantial. But wait till you see, how these encodes differ quality-wise. Seriously, after comparing the 3 results side by side I became a fan of Adobe's native H.264 encoder. It's super-fast, and it does a great job of preserving fine lines and keeping artifacts to minimum. It does so at a cost of some details becoming washed off. If we are to compare original x264 vs MainConcept, there is room for discussion, which coded and under what circumstances is better. But if we are comparing any of these two against x264 PRO by 3am Digital Studios, the answer is obvious to me. There is nothing about x264 PRO that makes it a winner. It's slow, it shifts colors pretty bad, and it's an excellent artifacts generator.
Let me show you. The following are 100% magnified 720p crops from the 1080p material. In each comparisson I got 10 screenshots that I picked randomly. They're all compressed to nearly lossless JPEG (you wouldn't be able to tell the difference between the original and Photoshop's Save for Web Quality 80). So, just move your mouse cursor over each screenshot to see, how codecs performed against each other.
Obviously, Adobe's MainConcept H264 codec is great. However, I do agree to the common opinion that x264 is a better choice. Even, when I switch it to Medium quality, it takes 34 minutes to encode, while the resulting picture still has more details then MainConcept's result. At the same time there are no ugly encoding artifacts, such as those from 3am Digital Studios implementation. 3am developer(s) should do a better job implementing x264. At the moment it's a waste of time and money.
You never answered my e-mails once I presented my facts and comparisons. But I figured people deserve to know the truth, because no matter what large media corps your have among 3am Digital Studios customers, they obviously don't spend too much time testing quality of a codec. I think, for many just seeing "x264" in product's title, or to read impressive commercial texts, is a good enough reason to make up their mind.
1: If the quality of your codec in its best quality produces more artifacts than MainConcept, what's the point to mention your codec in its draft quality? Yes, it's true that speed-wise you will be equal to MC, but quality-wise - it will be a mess (not even close to "approximately the same quality", as you say). And, as you know, I have video clips to prove that: Download - Inbox Files. The 2nd and the 3rd file, which took same time to encode, compared against each other on Premiere's timeline with 100% magnification show the obvious difference between the two codecs. Also this test reveals another problem that Premiere decodes your files starting only from third frame, which makes them appear two frames short and desynced. So, to make a comparison, x264 PRO clip has to be dragged 2 frames to the right.
2: I don't have clarity about the colorspace thing to comment on that, but I just noticed that for some reason the encodes I made with your codec found under download link in the above paragraph do not have this shifted colors problem, while encodes I made of the full clip, had it. I was encoding from the same CineForm source, so I'm puzzled about why one encode ended up in true colors, while other - in shifted. But I'm not gonna investigate that since the my main disappointment about x264 PRO consists of artifacts and blurriness. It's nice to know, though, that you can somehow avoid shift of colors.
3: This depends on how you encode. It's a known fact that the best quality squeezable out of any AVC codec comes from 2-pass encoding. If, say, you have bunch of effects applied in your project that slow it down (for example, Neat Video for noise reduction, which will drastically reduce a speed of render), 2-pass will mean rendering that "heavy" project twice. So, it may actually be that rendering it in 1 pass to a near lossless codec, such as CineForm or DNxHD, and then encoding this "light" file in 2 passes would be faster than waiting for the "heavy" 2nd pass to finish. Plus, if something turns out to be incorrect in the output file, let's say a glitch in the middle of your project, you don't have to reencode the whole thing to fix that small part. So, to me encoding to CineForm or DNxHD and then to H.264 is the way to go.
But, if we do talk about direct encoding to H.264 via plugin, then certainly MainConcept, built into Adobe's Media Encoder and Premiere, is the way to go, proven by my tests. If someone insists on the best possible quality, then freeware MediaCoder (not to be confused with Media Encoder) with latest x264 included is the way to go. Either you encode into CineForm and then drop these files to MediaCoder, or you can can actually make a direct connection between Adobe (Premiere or Media Encoder) and MediaCoder via the freeware DebugMode FrameServer plugin. It requires a bit of technical knowledge, but really not much. Once DebugMode FrameServer is installed, you can choose it from the codecs list. Exporting to it creates an empty file, which you can drop to MediaCoder and finish exporting to the latest x264. This will produce maximum quality possible up to a bitrate of 16 mbps, which is a limitation of MediaCoder's free version. In case someone wants to try it, I'll give a quick tip about MediaCoder's settings:
My main question is: tell me, 3am Digital Studios, if your codec is an implementation of original x264, how come the quality of it differs so noticeably? I can understand the speed problem could be due to mentioned Media Encoder serving up frames very slowly, but what about the compression? I mean just look at that: Roll your mouse over each of these 10 stills, compare the encodes I made under download link above and tell me, how can anyone possibly make a grand quality encode with x264 PRO, when even at 12 Mbps we get this kind of artifacts?
Well, why not use the TMPGEnc x264 plugin then, at a fraction of that price (way too high). It seems it is even more configurable and TMPGEnc (Pegasys) are more than well-known creators of excellent software. Only drawback, it's Windows-only.
b1e95dc632