When choosing a bitrate for your video, a good starting point is to set a variable bitrate equal to the pixel-width of the video. For example, the bitrate 640x480 SD would be 640 kbps, and 1280x720 HD would be set at 1280 kbps. Video that contains extensive action scenes may require a slightly higher bitrate.
Single Pass vs. Two Pass
Im most cases, 2-pass encoding achieves very good results. It's important to realize the tradeoff: you gain about 10% video quality bit-for-bit but the encoding time is about twice as long. You might experiment with values floating between 0.60 and 0.80 if you want more VBR. if qcomp = 1.00, then the quantizer will be constant for second pass. Insert the following into your API call:
We recommend that you provide two sample videos, and tell your users to choose Low or High Action content setting to experiment a bit with your B-frames and then define two "baseline" settings for each bitrate. For web video, it's best to narrow your targets to a maximum of four different bitrates, especially if you are going to be processing thousands of uploads.
For more detail on H.264 controls for scenecut thresholds, B-frames, and more, please refer to:
Advanced H.264 Guide http://sites.google.com/site/linuxencoding/x264-ffmpeg-mapping
H.264 parameters for our API http://www.encoding.com/help/article/advanced_configuration_options_for_the_libx264_video_codec
An excellent collection of HD videos at 2mbits/sec can be found at http://californiaisaplace.com/cali/
Fast and Slow Modes
Encoding.com employs the x264 software library for H.264 encoding. You can manage encoding performance by specifying x264 presets. Learn more about x264 here: http://www.videolan.org/developers/x264.html
The prefix for a preset is a double-dash:
You must apply the presets prior to all other options. Any presets you do set will override the x264 defaults which are:
--subme 7 --bframes 3 --weightb --8x8dct --ref 3 --mixed-refs --trellis 1 --crf 23 --threads auto
As such, all options that you set will act on top of the preset you choose, regardless of the option order.
ultrafast: --ref 1 --scenecut 0 --nf --no-cabac --bframes 0 --partitions none --no-8x8dct --me dia --subme 0 --aq-mode 0
veryfast: --partitions i8x8,i4x4 --subme 1 --me dia --ref 1 --trellis 0
fast: --mixed-refs 0 --ref 2 --subme 5
medium: (the defaults shown above)
slow: --me umh --subme 8 --ref 5 --b-adapt 2 --direct auto
slower: --me umh --subme 9 --ref 8 --b-adapt 2 --direct auto --partitions all --trellis 2
placebo: --me tesa --subme 9 --merange 24 --ref 16 --b-adapt 2 --direct auto --partitions all --no-fast-pskip --trellis 2 --bframes 16
For all encodes (irrespective of presetting), using --pass 1 will automatically trigger the "turbo" settings below, which overrides all command line options.
--trellis 0 --no-8x8dct --partitions none --me dia --ref 1 --subme MIN(2, previous subme)
You can disable this using --slow-firstpass.
For all encodes, if you don't set your own --ref option and instead use the default or a preset, x264 will automatically lower --ref if the --level you set conflicts with it. If you set --ref explicitly, it will not override what you set.
For HD encoding jobs over 15 minutes duration, we recommend turbo mode since you will see 3x speed gains over normal mode. Enable turbo mode with this simple call:
Macroblocking is an often undesirable video characteristic in which objects appear to be made up of small squares, rather than proper detail and smooth edges. The blocks may appear throughout the image, or just in portions of the image. The causes of macroblocking-which are quite different from pixellation-are related to one or more of the following factors: video compression, data transfer speed, signal interruption, and video processing performance. Macroblocking is often apparent in cable, satellite, and web streaming services, since those services typically employ high video compression to maximize their bandwidth. Macroblocking can also be the result of poor video processing and upscaling by the playback device.
To reduce macroblocking and improve H.264 encoding efficiency, it's best that the horizontal and vertical framesize dimensions be multiples of 16. These are the most common framesizes:
- SD (4:3 aspect ratio): 320x240, 432x320, 480x360, 544x400, 640x480, 768x576
- HD (16:9 aspect ratio): 432x240, 576x320, 640x360, 720x400, 848x480, 1024x576, 1280x720, 1920x1080
In 4:2:0 H.264 encoding, each block contains 4 luminance samples (Y), 1 blue sample (Cb), and 1 red sample (Cr). Modern video decoding chips (GPUs) are optimized for playback of 16x16 macroblocking.
Keyframes and GOPs
Low action scenes generally handle more bidirectional frames (B-frames) better, since they don't have to track interframe motion as aggressively. Higher action content will require more keyframes (I-frames) to keep the picture from breaking apart. Longer GOPs (group of pictures) having more B-frames will demand more buffering from the playback GPU to recursively track the motion for each macroblock. Fortunately, x264 offers very good scene detection, which is why for most applications, we set keyframes to 300.
Example for modern mobiles (30 fps with a 10 second GOP):
For older computers, and early generations of iPod and Blackberry phones, the chips might not have enough processing power and memory to successfully buffer longer GOPs. Keep your bitrates low, try lower framerates, and shorter GOPs.
Example for older mobiles (15 fps with a 4 second GOP):
More information about GOPs available on wiki http://en.wikipedia.org/wiki/Group_of_pictures