Encoding with x264
Encoding DivX Plus HD video bitstreams using x264
x264 is a popular H.264 encoder whose source is freely available under GNU General Public License (GPL).1 It can be used to encode video bitstreams for DivX Plus HD MKV files which are later combined (muxed) with other assets such as audio tracks and metadata.
The DivX Plus HD format is designed to bridge the gap between desktop computers and consumer electronics (CE) devices such as DVD players, set-top boxes, connected devices, and portable media players. Wheras desktop systems can play media with a wide variety of characteristics so long as they are powerful enough, playback support and experience on CE devices is constrained by numerous factors: the capabilities of the decoder hardware, network bandwidth, drive read rate, memory I/O performance, renderer capabilities and display properties.
The DivX Plus HD profile establishes capabilities that will be met by all DivX Plus HD certified devices. By configuring an encoder accordingly, you can be assured that your content will play well wherever the DivX Plus logo appears.
The information in this article was derived using x264 builds up to version 1301, but should also apply to later versions. Read our recommendations below to find important information for particular ranges of builds. If you have feedback or suggestions please let us know via the DivX Plus HD forum.
Here we describe key arguments that you should pass on the x264 command line to produce a fully DivX Plus HD compliant video bitstream.
These arguments inform x264 about the data rates supported by all certified devices. During encoding, the data rate fluctuates as the complexity of the video changes over time and an encoder must manage the data rate so that video does not temporarily slow or stall during playback.
This argument tells x264 to mark the video bitstream as conforming to level 4.0. From this, decoders can understand certain requirements about the memory and processing rates required to decode the bitstream.
This value allows x264 to use the highest possible quantizer if under exceptional circumstances it is necessary to meet data rate constraints.
Note that the default value for qpmax is 51 and therefore it is not necessary to explicitly specify it, only to avoid overriding it.
Frames with bi-directional prediction assemble the picture texture from both past and future frames. Devices certified for DivX Plus HD are tested to decode up to three consecutive bi-directionally predicted frames.
This argument ensures that there is at least one keyframe every four seconds. This improves the navigation experience on consumer electronics devices that may display only keyframes during fast-forward and rewind. Note that the value is given in frames, therefore multiply the frame rate of the input file by 4 and take the integer part. For example, when encoding a 24fps clip use --keyint 96, and for a 23.976 NTSC clip use --keyint 95. Although it is possible to use longer or shorter intervals we have found four seconds to be a good trade-off between navigation experience and compression efficiency.
Thus, a fully compliant x264 command line would contain at minimum the following arguments:
x264 --vbv-maxrate=20000 --vbv-bufsize=25000 --level 40 --bframes 3 --keyint <4*FPS> -o <output file> <input file>
The same arguments can be combined with the --preset and --tune arguments in recent versions of x264 as follows:
x264 --preset <…> --tune <…> --vbv-maxrate=20000 --vbv-bufsize=25000 --level 40 --bframes 3 --keyint <4*FPS> -o <output file> <input file>
DivX Plus devices fall into many categories with varying scaler capabilities and a range of supported display types. To ensure the correct presentation in all playback scenarios, it is important that the input video adheres to some key constraints.
Video frame rates should match those listed in the table below, which cover common video formats and enable robust display timing implementations. Maximum and minimum picture dimensions for each valid frame rate are also given.
|Approximate FPS |
= Rate / Scale
|Max Dimensions||Min Dimensions|
Width and height are tested independently for minimums and maximums.
Any alternative rate/scale representations must evaluate to exact equivalents.
Toolchains that leverage AVISynth, a frame-serving toolkit freely available under GNU General Public License (GPL)2, can use AssumeFPS() to force the correct numerator and denominator for input files with frame rates that are insignificantly different or any of the FPS functions otherwise, e.g. ChangeFPS().
If the pixels in the input video are non-square samples of the original video you can specify the correct sample aspect ratio using x264's --sar argument. For progressive video any Sample Aspect Ratio (SAR) present in Table E-1 of the H.264 specification with aspect_ratio_idc in the range one through sixteen is permitted, including in order of tallest to widest:
10:11, 1:1, 12:11, 40:33, 4:3, 15:11, 16:11, 3:2, 160:99, 18:11, 20:11, 64:33, 2:1, 24:11, 80:33, 32:11
Depending on the playback environment, decoder and display devices will have specific methods of handling interlaced content. Some devices may de-interlace internally, while others may output interlaced video for an external display to present as appropriate. In order that interlaced material is displayed correctly stricter rules apply during encoding, and in the video bitstream only the following combinations of resolution and SAR are permitted:
|Interlaced resolution||Support SARs|
|1920x1080i60||1:1 (16:9 frame)|
|1920x1080i50||1:1 (16:9 frame)|
|1440x1080i60||1:1 (4:3 frame), 4:3 (16:9 frame)|
|1440x1080i50||1:1 (4:3 frame), 4:3 (16:9 frame)|
|720x480i60||1:1, 40:33 (16:9 frame), 10:11 (4:3 frame)|
|720x576i50||1:1, 16:11 (16:9 frame), 12:11 (4:3 frame)|
|704x480i60||1:1, 40:33 (16:9 frame), 10:11 (4:3 frame)|
|704x576i50||1:1, 16:11 (16:9 frame), 12:11 (4:3 frame)|
|640x480i60||1:1 (4:3 frame)|
|480x480i60||1:1, 20:11 (16:9 frame), 15:11 (4:3 frame)|
|480x576i50||1:1, 24:11 (16:9 frame), 18:11 (4:3 frame)|
|352x480i60||1:1, 80:33 (16:9 frame), 20:11 (4:3 frame)|
|352x576i50||1:1, 32:11 (16:9 frame), 24:11 (4:3 frame)|
There are extensive tutorials on using x264 on their official website, but we invite you to discuss settings or your applications in our developer forum if you need help creating DivX Plus compatible files.
Recommendations and Points of Interest
Over time x264's developers have provided feature enhancements and bug fixes as well as changes to command line setings. Some of these changes affect x264's behavior and how closely its output complies with the settings specified. We make the following notes and recommendations to ensure good interoperability with DivX Plus devices. We continue to research recent changes in x264 and this page may be updated periodically as appropriate.
- You should not use any build of x264 prior to 861 because VBV was not fully implemented prior to this. Without buffer management there is a high risk that content will stutter during playback on devices.
- VBV implementation was improved in builds 977 and later leading to smaller buffer underflows.
- We recommend using builds 1287 or later due to important fixes for VBV conformance.
- 1-pass rate control tends to allow more buffer underflows than 2-pass rate control. 2-pass encoding is therefore recommended for the most reliable playback experience. You must use the same target rates during both passes to maintain VBV compliance.
- x264 builds prior to 1179 default to outputting bitstreams compliant with H.264 Main profile.
- x264 builds builds 1179 and later default to outputting bitstreams compliant with H.264 High profile.
DivX Plus HD supports both Main profile and High profile bitstreams. You can cause builds prior to 1179 to output High profile bitstreams by adding the argument --8x8dct to the x264 command line.