Keyframes

Our MPEG-2 encoder offers advanced encoding parameters for both GOP structure and cadence. Closed GOPs with scene detection are ideal for delivery to many STBs (Set-Top-Boxes), such as Tivo and Roku. The Strict GOPs option locks the size to your keyframe value, and is necessary for some hardware DRM solutions. We also now provide MPEG-2 keyframe presets for both DVD and Long-GOP output, as well as the option to turn B-frames on/off. This greatly increases compatibility with a wide range of MPEG-2 players and chipsets.

MPEG-2 API options

Here are all the accepted values for our API

<output>mpeg2</output>  
<keyframe>[12|15|25|30]</keyframe><!--GOP length for NTSC/PAL-->
<bframes>[2|0]</bframes><!--bidirectional frames-->
<gop>[cgop|sgop]</gop><!--closed or strict GOP-->   
</output>

MPEG-2 Advanced XML Samples

Sample for Tivo and NTSC DVD output

Closed 15-frame GOP using standard IPBBPBBP cadence.

<output>mpeg2</output>  
<keyframe>15</keyframe>   
<bframes>2</bframes>  
<gop>cgop</gop>   
</output>

Sample for PAL DVD output

Closed 12-frame GOP using standard IPBBPBBP cadence.

<output>mpeg2</output>  
<keyframe>12</keyframe>   
<bframes>2</bframes>  
<gop>cgop</gop>   
</output>

Sample for Cablelabs Broadcast NTSC output

Long 30-frame GOP using broadcast IPPPPPPP cadence.

<output>mpeg2</output>  
<keyframe>30</keyframe>   
<bframes>0</bframes>  
<gop>cgop</gop>   
</output>

The x264 Project has lead the way on H.264 development by introducing many key features. Variance Adaptive Quantization (VAQ) and Rate–Distortion Optimization (RDO) attempt to preserve video quality and motion estimation against the amount of data required to encode the video. Advanced controls include options for GOP structure, keyframing, scene detection, macroblocking, and interframe quantization. Many of these features are discussed in depth on the x264 forums. A list of the x264 flags available to our API follows:

Frame-type options:

Ratecontrol:

Analysis:

The default value for keyframe interval set by the optional format field <keyframe> is 300, i.e. keyframe is added every 300 frames. For a framerate of 30fps this would equal 10 secs. But for 15fps (most often used for FLV) it would be 20 seconds, which may be too often. To change this value, simply use the <keyframe> parameter within the <format> element. For example, setting the value to 30 will allow to seek the video for every 2 seconds, assuming framerate 15 fps.

About Keyframes: Because video compression only stores incremental changes between frames (except for key frames), it is not possible to fast forward or rewind to any arbitrary spot in the video stream. That is because the data for a given frame only represents how that frame was different from the preceding frame. For that reason it is beneficial to include key frames at arbitrary intervals while encoding video. For example, a key frame may be output once for each 10 seconds of video, even though the video image does not change enough visually to warrant the automatic creation of the key frame. That would allow seeking within the video stream at a minimum of 10 second intervals. The down side is that the resulting video stream will be larger in size because many key frames were added when they were not necessary for the visual representation of the frame. http://en.wikipedia.org/wiki/Key_frame

Occasionally compression requirements dictate that you use a Constant Bit Rate (CBR) instead of a Variable Bit Rate (VBR). This is especially helpful for video streaming.  In our encoding platform, VBR is the default setting for Encoding.com since it generally provides much higher quality. For scenes where there is a high amount of action or detail, VBR will often spike up to 300% of the target bitrate. The reverse is also true, VBR will dramatically pull back on scenes with low detail.

Why would you use CBR?

CBR is far more constrained, with the actual bitrate only floating about 20% above and below the target. Some video playback devices have cheaper "chips", hardware decoders with limited buffer that are unable to handle VBR. With MPEG-4 being built into most modern chipsets, this issue is largely going away. CBR is also often used in satellite television broadcasts, where many channels will be multiplexed into one transport stream with limited bandwidth.

Sample API tags for CBR:

If you wish to check your encodes, Winhoros Bitrate Viewer is a great way to scan your files and quickly get detailed bitrate information.

If you are having problems getting the bitrate you need, try using a lower value in the bitrate tag. If that doesn't work, please submit a support ticket with the Media ID # of the job.

Since users often will be uploading a wide variety of videos, I generally like to break them down into two types:

Static/Low Action - stable tripod shots, very little background movement, actors standing still 
Active/High Action - panning/jerky camera, lots of action, sports-like movement

A good starting point is to choose a variable bitrate setting equal to the width of the video. So, for example: 640x480 SD at 640 kilobits per sec (kbps), or 1280x720 HD at 1280 kbps. Higher action video may require a slightly higher bitrate to prevent blocking artifacts.

Noise Reduction

Applying some noise reduction is useful to save bits for high detail regions, but be careful not to overdo it. I've seen video samples where whole areas of ocean and grassy fields disappear to achieve a lower bitrate. This of course, falls under artistic preference, but generally I'd rather see a smaller framesize and more detail. At low bitrates, it is increasing important to improve the quality of noisy video sources, such as film containing lots of grain or video shot in low light. The 3D noise reduction in ffmpeg allows control over both luma and chroma values for fine-tuning your output image quality.

	<noise_reduction>4:3:6</noise_reduction> 

luma_spatial – Spatial Luma Strength. Allowed values: [0,255]
chroma_spatial – Spatial Chroma Strength. Allowed values: [0,255]
luma_temp – Temporal Luma Strength. Allowed values: [0,255]

General recommended starting value is 4:3:6. [luma_spatial:chroma_spatial:luma_temp] Noise reduction is also available via our web interface as the High Quality 3D Denoiser option.

Single Pass vs. Two Pass

For most purposes 2-pass encoding achieves very good results. It's a tradeoff of diminishing returns, 2-pass gaining perhaps 10% quality bit-for-bit but doubling the encoding time. Do not lower qcomp, CBR is horrible on quality. I'd experiment with values floating between 0.60 and 0.80 if you want more VBR. if qcomp = 1.00 then quantizer is constant for second pass. Real variable bitrate with constant quality. if qcomp = 0.00 then bitrate is constant for second pass. Real constant bitrate with variable quality.

<two_pass>yes</two_pass>

I'd recommend having two sample videos, tell your users to choose Low or High Action content setting, experiment a bit with your B-frames then define two "baseline" settings for each bitrate. For web video it's best to narrow your targets to four different bitrates at most, especially if you are going to be processing thousands of users uploading. Most folks have a slow (up to 240kbits), good (~700kbits), or fast (2mbits and higher) connection. I'd say H.264 over 2mbits is generally overkill for website content. For general purposes, I'd recommend 2-pass and we push a 10 second keyframe interval (300 frames) which may not be appropriate for "high-action" source video.

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/ 

16x16 Macroblocks

H.264/AVC does a much more efficient job when the horizontal and vertical framesize dimensions are multiples of 16. Good examples include:

SD (4:3) aspect ratios: 320x240, 432x320, 480x360, 544x400, 640x480, 768x576
HD (16:9) aspect ratios: 432x240, 576x320, 640x360, 720x400, 848x480, 1024x576, 1280x720, 1920x1080

In 4:2:0 H.264/AVC coding, 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 (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 with more B-frames also require more buffering by 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.

H.264/AVC sample for modern mobiles (30 fps with a 10 second GOP)

	<framerate>30</framerate>
	<keyframe>300</keyframe>

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.

H.264/AVC sample for older mobiles (15 fps with a 4 second GOP)

	<framerate>15</framerate>
	<keyframe>60</keyframe>

More information about GOPs available on wiki http://en.wikipedia.org/wiki/Group_of_pictures

Turbo Mode

NOTE: For bigger or longer HD encoding jobs, turbo mode is absolutely recommended since you will see speed gains in the neighborhood of 3x faster vs. normal mode. Please be aware turbo is running on more powerful encoders, so it costs an extra $1 per gigabyte.

<turbo>yes</turbo>