
There is no point in using more chunks that there are CPU cores in the computer. Chunks can be any number between 1 and 64. Here hap_q can be changed to hap or hap_alpha if you wish to use these flavours instead of HapQ. This will convert Movie.mov to a HapQ movie using 4 chunks and store the result in MovieHap.mov. If you want to use ffmpeg, there are windows binaries to download here: Īssuming you are running windows: Just put ffmpeg.exe and the file you wish to convert in a folder, open a windows command prompt and navigate to that folder and issue the following command:įfmpeg -i Movie.mov -vcodec hap -format hap_q -chunks 4 MovieHap.mov Each chunk will add a slight overhead, both in the form of a slightly higher decoding time and slightly larger files, but the difference is usually (close to) negligible. It the video plays fine without using chunks, don't bother to use chunks. If the bitrate is too high, you will have to render to a lower resolution, or, if playing HapQ, switch to Hap. The compression methods are fixed and leave no room for any adjustments. Jokyo's HAPQ play in Touch and Mad.As I have mentioned in previous posts, given a certain resolution and Hap flavour (Hap, HapQ or HapAlpha) there is no way to control the bitrate.

His version of HAPQ Slow is only slightly below HAPR imho and it looks nearly as good (much better than FFPMEG and After Codec's HAPQ). If you have the dough, this is the path I recommend. Named HAPR, it is a much better looking encode. I bought the stand alone version and have to admit that it does an incredible job encoding and introduces next level HAP that we so desperately need. The stand alone costs more but seems to be more efficient than using AME. You can buy their codecs so you can render using AE/PR/AME or you can buy his stand alone. And it's locked to a computer which is incredibly annoying if you're moving from machine to machine a lot. There's a new third party encoder that I've been using that I like by this dude Jokyo based in France. I have not tested After Codecs for QC recently, but am willing to bet it has similar banding issues (regardless of Hap or HapQ preference) Faster to encode as some other intermediary first. It's pretty good! But I do not recommend rendering directly from sequence(s) to HAP.

You can still encode directly to HAP in AE/AME/PR by using "After Codecs" – this is a paid plugin from Aescripts. That said: HAP's encoding can be pretty rough on gradients and causes some gnarly banding. There's a learning curve attached to this process, but just write down what you learn so you don't forget :). Export from AE/PR whatever is a lightly compressed or uncompressed codec before sending to FFMPEG.

You can transcode HAP via FFMPEG – this is probably the fastest HAP renderer.
