I am setting up our new engine and am having some dificulty with setting up a particular encode. We have several series that are cutting in apple prores 422 HD and we need to encode them to H264 with timecode burn to send out for screening purposes. Even with split and stich hitting all the cores on our server i cannot get an hour show to encode in less then real time. I have tried VBR and CBR encoding. The quality has always been gorgeous and the timecode for 24p has been accurate unlike everytime we use apple's compressor. I just cannot make it go faster. We are looking for about a 500mb file in h.264 at a frame size of 640x360. What settings can I dial backwards to make it go faster?
We are on an xsan with fiber and i have switched from load balancing to hardware balancing in the cluster preferences which seems to work better.
Can you provide some more details on your setup? How many machines and what specs? Also how many parallel encodes do you have set on each one? H.264 is a very multi-threaded codec so sometimes its better to take the number of parallel encodes down a bit so that you are not over-saturating the CPUs. How do you have your Split-and Stitch parameters set up? You want try to configure everything so that you can do all of the splits in one pass. For example if you have 3 12core macpros and you set them to do 4 encodes each you have 12 split "slots" total. In the sns parameters in the encoder you would set the max number of splits to 11 (keep one extra for audio) and the minimum duration such that Episode can split up the file 11 times. Also make sure that "use local cache" in unchecked. This will make sure that all of your splits are being written to the SAN ( make sure your file cache is set to the SAN in preferences on each node).
You can try single pass instead of 2 pass if you have not tried that already, will give big time savings if the quality is acceptable. Hope these suggestions are helpful.
Product Manager | Episode
We have the engine running on a single 8 core xserve in our main machine room. My split settings are 7 splits and i had local cache checked. I am running a test now. I also had the cache set on the xserve itself. I have switched that to the xsan as well. What is the best practice for the cache location? Should i make it a folder on the main level of our xsan?
What is the difference between main and baseline enocding for h.264?
Thank you for helping,
You should see improvement by getting the cache set to the SAN and writing the splits to the SAN (un-cecking "use local cache" in the encoder), especially in the stitch process as its all disk read and write at that point. Its best to set the cache to your fastest disk system, similar to how you would set up FCP or similar. Doesn't need to be in a particular directory for Episode, just depends on how you have your SAN set up as far as which volumes are faster, affinities and such.
Main and baseline are sets that describe a particular set of features or specs for H.264. You can read about what the different profiles are on wiki: http://en.wikipedia.org/wiki/H.264/MPEG-4_AVC#Profiles
You should not see any speed differences between the two however. CAVLC entropy encoding is a bit faster than CABAC so you can check that out. Are you doing any filtration besides resize and TC burn? That can sometimes play a role in performance. Again take a look at one pass, you may be pleasantly surprised.
I would try setting your number of parallel encodes in preferences to 5,6 or maybe even a bit lower if you are mainly doing these H264 encodes. Try setting it to 5 and then set the max splits to 4 and see if that helps. If you still have some CPU left in activity monitor then set the numbers up a bit higher. You want to max out all the CPUs but not go too far.
Product Manager | Episode
Thank you so much for the quick reponse and patience. I spent yesterday pounding through the entire telesteam forum before posting so as not to waste any of your time. I am very happy with episode i just need to learn how to be a better operator. Compression is an artform at this point.
I am using the resize filter to bring the frame size down to 25 percent of the original frame. Does having it be a quarter size frame make the math esier and faster?
When i am using the VBR setting unchecking two pass i am using single pass?
The general philosophy behind bring the overall simeltaneous encodes down from the maximum my computer will do from eight to five is better because of h.264 saturating the cores?
In other words, just because my computer cand do eight jobs at once does not mean it is doing it faster?
No worries, we are getting into the finer points of Episode optimization here :-)
Yes, in VBR you have a choice of 1 or 2 pass, so unchecking the 2 pass option will give you single pass. With CBR its single pass only so the choice gets grayed out and even if its checked when grayed out you still get single pass.
The reason I am suggesting you lower your number of parallel encodes is that you are encoding to H.264, which on its own a very multi-threaded codec. Not all codecs are this way, for example the On2 VP6 codec only operates on a single core. Since H.264 spreads itself out across cores so well it does not take that many parallel encodes (splits in your case) to fully saturate multi-core machines to 100%. When you start to go over that you are losing efficiency and overall speed. Do a test encode without split and stitch and you look at the CPU utilization in activity monitor, then make a similar encoder but change it to flash8 with VP6. You will see a big difference in the amount of CPU being used and its due to the codec.
So test with different numbers of parallel encode slots and see which number just gets you to 100% across all CPUs. That should be the best number. So yes you are correct, just because you can set the number higher does not mean its the best all the time. If you are doing lots of different encodes to different codecs it might make sense to set it to some happy medium but if all you are doing is lots of parallel H.264 then tweak if for that.
Product Manager | Episode