H.264

DivX Plus HD is our video profile based on the H.264 standard. Below you'll find some guides to help you encode to this profile and add features to your DivX MKV video.

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.

 

Builds Tested

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.

 

Bitstream Properties

Here we describe key arguments that you should pass on the x264 command line to produce a fully DivX Plus HD compliant video bitstream.

--vbv-maxrate=20000 --vbv-bufsize=25000

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.

--level 40

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.

--qpmax 51

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.

--bframes 3

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.

--keyint <4*FPS>

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>

 

Video Properties

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.

Rate
(Numerator)
Scale
(Denominator)
Approximate FPS
= Rate / Scale
Max Dimensions Min Dimensions
60 1 60 1280x720 320x240
60000 1001 59.940 1280x720 320x240
50 1 50 1280x720 320x240
30 1 30 1920x1080 320x240
30000 1001 29.970 1920x1080 320x240
25 1 25 1920x1080 320x240
24 1 24 1920x1080 320x240
24000 1001 23.976 1920x1080 320x240
Width and height must each be multiples of 8.
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.

Rate control

  • 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.

Profile selection

  • 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.

 

Footnotes:

  1. x264's Project Home Page
  2. AVISynth's Project Home Page

Smooth FF/RW

DivX Plus MKV extension: Smooth FF/RW

Have you ever been frustrated when trying to fast-forward or rewind a video because your player becomes unresponsive and the video skips large chunks of time unpredictably making it hard to quickly find the scene you're looking for? Rewinding can be particularly infuriating using CDs or DVDs, and with downloaded video even faster media can still be problematic due to the long and irregular gaps between keyframes.

DivX Plus offers an extension to the MKV container called Smooth FF/RW that helps to solve this experience problem by including a special navigation track in your MKV file during authoring. This extension is supported by all DivX Plus devices and gives you the option to trade a small filesize overhead for a much better navigation experience. This article shows how you can try this new feature with the easy-to-use DivX Plus Converter as well as providing information and sample tools that you can use to author this feature manually or to add support in your own encoding tool chain.

 

See it in action

We took a regular DivX Plus HD .mkv video, added the Smooth FF/RW extension, then filmed it playing it in a DivX Plus HD device:


No video? Get the DivX Web Player for Windows or Mac

You can also download this file and play it in the DivX Plus Player.

 

 

Clicking the fast-forward and rewind buttons in DivX Plus Player multiple times increases the playback rate, shown in the lower-left hand corner of the video area. For files that include a Smooth FF/RW track the following behavior is typical:

Mode Rate What's displayed
Rewind 16x-32x Smooth FF/RW track at several fps for easy viewing
Rewind 2x-8x Smooth FF/RW at full speed for precise navigation
Play 1x Normal playback
Fast-forward 2x-4x
  • Main video track if CPU is fast enough, otherwise..
  • Smooth FF/RW track at full speed for precise navigation
Fast-forward 8x Smooth FF/RW track at full speed for precise navigation
Fast-forward 16x-32x Smooth FF/RW track at several fps for easy viewing

When a file contains a Smooth FF/RW track DivX Plus Player can also update the picture instantly as you click and drag the scrub control at the bottom of the window.

Keep in mind that although DivX Plus Player can somewhat simulate the navigation experience on your desktop the biggest improvement can be seen when you're sitting back on the couch using a real device with a remote control in your hand. Without the Smooth FF/RW extension it is impossible to deliver this level of control with internet-based content. That's because in order to achieve such high compression modern encoders use delta frames that mostly depend on being decoded in sequence. To display a specific picture during FF/RW a player has to find the nearest past key frame, which acts as a restart point, then decode from there forward until the desired picture is reached. This is generally infeasible during fast-forward and especially so during rewind because keyframes are often irregularly spaced and can be up to several hundred frames apart.

 

How it works

The Smooth FF/RW extension adds a subsampled copy of the main video track to the .mkv file where the pictures are all key frames. Both the picture resolution and frame rate are substantially reduced, and the Smooth FF/RW track typically adds 10-15% to the overall file-size.

 

Special backwards references are also added so that players can rapidly traverse the Smooth FF/RW track in both directions.

 

Creating a Smooth FF/RW track manually

You can manually author a Smooth FF/RW track that will work on any DivX Plus HD device so long as you:

  1. Respect the video constraints of DivX Plus HD profile, and..
  2. Follow the additional requirements for the Smooth FF/RW track.
  3. Add the Smooth FF/RW track to your video using a mux supporting the correct Smooth FF/RW track extension syntax.

The next sections of this article are more technical and walk through the Smooth FF/RW track requirements, encoding such a track, and adding the encoded track to an existing .mkv file.

 

Smooth FF/RW track requirements

In order to guarantee playback on DivX Plus devices, observe these additional restrictions when encoding Smooth FF/RW tracks:

Property Requirements
Frame types IDR only
Frame rate

One of the following decimations of the main video track rate:

  • 5/1 fps
  • 5/1.001 fps
  • 4/1 fps
  • 4/1.001 fps
  • 1/1 fps
  • 1/1.001 fps

The rate denominator for the Smooth FF/RW track must match that of the main video track. E.g. if the main video is at 23.976 (24/1.001) fps the Smooth FF/RW track can be at 3.996 (4/1.001) fps.

Picture timing SEI No conveyance of telecine or interlaced modes, e.g. pic_struct = 0
Field types Progressive only
Picture resolution 1/2 or 1/4 of main video track resolution
Picture width 160-960 pixels, modulus 8
Picture height 120-544 pixels, modulus 8
Sample aspect Must match aspect of the main video track
NAL bitrate Maximum 2Mbps
CPB size 25 Mbit

 

Encoding a Smooth FF/RW track manually

Let's work through an example of encoding a Smooth FF/RW track using x264, a popular open-source H.264 encoder. Imagine we have a 1080p (1920x1080) main video track at 23.976fps encoded at around 8Mbps average, and we want to create a Smooth FF/RW track at around 1/4 resolution.

  1. Calculate the resolution of the Smooth FF/RW track.

    Width = 1920 / 4 = 480 pixels
    Height = 1080 / 4 = 270 pixels

    Note that the height is not evenly divisible by 8. We can correct that by rounding up:

    270 / 8 = 33.75
    Height = 34 * 8 = 272 pixels (rounding up)

    Final dimensions for the Smooth FF/RW track are 480x272.

  2. Choose a frame rate to decimate to. The main track is at 23.976fps, which is actually 24/1.001, so consulting the table above we will choose 4/1.001fps because 4 goes into 24 evenly.

    Now we know our Smooth FF/RW video will be 480x272@4fps.

  3. Choose a data rate for the Smooth FF/RW track

    Typically a good choice will be around 10-15% of the average data data rate of the main video track. In this example the main video track was encoded at 8Mbps, which gives a range of:

    8000 * 0.10 = 800 kbps
    8000 * 0.15 = 1200 kbps

    For this example we'll choose 1000kbps (12.5%)

  4. Create the Smooth FF/RW video track.

    One way to create such a clip from the main video track is to use AVISynth. A suitable script might look like this:

    # Load the main track (you might use another source filter)
    DirectShowSource("MainTrack.mkv", audio=false)

    # Force the correct frame rate numerator/denominator
    AssumeFPS(24000,1001)

    # Drop frames and force the new rate
    ChangeFPS(4000,1001)

    # Downsample. A sharp/slow resizer is not necessary
    BilinearResize(480,272)
  5. Pass the AVISynth script to x264 for encoding:

    x264 --level 40 --keyint 1 --vbv-maxrate=2000 --vbv-bufsize=25000 --bitrate 1000 -o SmoothFFRWTrack.264 SmoothFFRWTrack.avs

    Arguments in blue are derived from the master DivX Plus HD requirements, and arguments in green are derived from the Smooth FF/RW track requirements.

    After encoding is complete we have a valid .264 elementary stream ready for muxing.

 

Adding the Smooth FF/RW track to an MKV file

To add a Smooth FF/RW track to an .mkv file you need to use a mux utility that understands the syntax of the extension. DivX provides a reference implementation in the DivXMKVMux sample tool. Begin by downloading and installing the DivXMKVMux package.

 

For easy access to DivXMKVMux launch a command console via the shortcut provided in the DivX Plus programs group on your Start menu. The console will start in the installation directory and the installation directory is automatically added to the PATH environment variable for the console session so that you can type "DivXMKVMux" from any other directory.

You can access the full list of arguments for DivXMKVMux using:

DivXMKVMux --help

The help output is lengthy because DivXMKVMux is fairly flexible, but the required syntax is actually quite straightforward. To use DivXMKVMux to add a Smooth FF/RW track to an existing .mkv file as a post-processing simply step specify an input file with the -r argument:

DivXMKVMux -o Complete.mkv -r MainTitle.mkv -tt SmoothFFRWTrack.264

You can view the output file including the Smooth FF/RW track in DivX Plus Player.

 

Let us know what you think

Please send us your comments and questions on this feature via the DivX Plus (.mkv) forum (requires sign-in).



Technical description

This section of the article describes the technical implementation of the Smooth FF/RW track and assumes the reader is familiar with MKV EBML structure. Less technical readers may wish to skip this section.

The following diagrams illustrate how Smooth FF/RW tracks are represented in DivX Plus HD .mkv files. Note that during development this feature has been referred to as TrickTrack. For the purposes of consistency that nomenclature is retained in this technical description. At a high level:

  • The Smooth FF/RW track is contained in a separate EBML structure following the EBML structure for the main video.
  • Each video TrackEntry has a TrickTrackFlag indicating whether or not the track is a Smooth FF/RW track.
  • In each video TrackEntry there is a cross-reference to the related SegmentUID and TrackUID in the corresponding EBML structure. Note that the EBML class IDs for these cross-references differ depending on TrickTrackFlag.
  • Only when all expected elements are present and all cross-references between master and Smooth FF/RW track segment and track UIDs are succesfully resolved is a valid relationship established

 

Additionally, backwards references are written into BlockGroups for the Smooth FF/RW track that allow fast traversal of the Smooth FF/RW track in both directions. The illustration below shows how these references are written for the first Cluster. For files with multiple Clusters references will also exist from the first BlockGroup for the Smooth FF/RW track in each new cluster to the last BlockGroup for the Smooth FF/RW track in the previous cluster.

 

The EBML elements for the Smooth FF/RW extension are:

[+] Click to expand Key

Element Name Lvl EBML ID Ma Mu Rng Def Type D+ Description
Segment->Track->TrackEntry
TrickTrackUID 3 [C0] - - >0 - u * The TrackUID of the Smooth FF/RW video in the paired EBML structure corresponding to this video track.
TrickTrackSegUID 3 [C1] - - - - b * The SegmentUID of the Segment containing the track identified by TrickTrackUID.
TrickTrackFlag 3 [C6] - - 0-1 0 u * Set to 1 if this video track is a Smooth FF/RW track. If set to 1, MasterTrackUID and MasterTrackSegUID should must be present and BlockGroups for this track must contain ReferenceFrame structures. Otherwise, TrickTrackUID and TrickTrackSegUID must be present if this track has a corresponding Smooth FF/RW track.
MasterTrackUID 3 [C7] - - >0 - u * The TrackUID of the video track in the paired EBML structure that corresponds to this Smooth FF/RW track.
MasterTrackSegUID 3 [C4] - - - - b * The SegmentUID of the Segment containing the track identified by MasterTrackUID.
Segment->Cluster->BlockGroup
ReferenceFrame 3 [C8] - - - - c * Contains information about the last reference frame.
ReferenceOffset 4 [C9] * - - - u * The relative offset, in bytes, from the previous BlockGroup element for this Smooth FF/RW video track to the containing BlockGroup element.
ReferenceTimeCode 4 [CA] * - - - u * The timecode of the BlockGroup pointed to by ReferenceOffset.

Additional details:

  • All of the above elements are mandatory for a valid implementation of the Smooth FF/RW extension.
  • Lacing is not supported for the Smooth FF/RW video track.

Recommendations:

  • Players that do not yet support the Smooth FF/RW extensions can avoid playing the Smooth FF/RW track as a title by detecting a TrickTrackFlag element whose value is 1.

World Fonts

DivX Plus MKV extension: World Fonts

One of the benefits of authoring content in MKV is the ability to include multiple subtitle tracks so viewers in different geographies can enjoy your work. Some uncertainties accompanying multilingual subtitle tracks include whether viewers will have suitable fonts installed to view the content, whether the subtitles will appear stylistically correct on every system, and what happens when someone tries to play the file on a device that may not be capable of displaying all the languages you've included?

DivX Plus offers an extension to the MKV container called World Fonts that solves these problems by authoring appropriate TrueType fonts into the file in a manner such that all players can reliably load them and display subtitles for every language. A special optimization technique is used to significantly reduce the size of the font data so fonts can be loaded not only by desktop players but also by DivX Plus Web Player and hardware devices with limited memory.

 

See it in action

We encoded Blender Foundation's Sintel trailer with four subtitle languages, including complex east-asian languages like Chinese, each version with and without the World Fonts extension. The subtitles that include World Fonts will be displayed correctly even if your local system or player does not support them. Note that DivX Web Player 2.0.2 contains preliminary support for this feature and this will become more optimal in future.


No video? Get the DivX Web Player for Windows or Mac

The available subtitles are:

  1. French
  2. French with World Fonts
  3. Chinese (Not yet natively supported)
  4. Chinese with World Fonts
  5. Japanese (Not yet natively supported)
  6. Japanese with World Fonts
  7. Russian
  8. Russian with World Fonts

Select a subtitle by right-clicking the video as it plays. Notice that even though Chinese and Japanese are not yet natively supported by DivX Plus Web Player they display correctly when World Fonts are applied.

You can also download this file and play it in the DivX Plus Player.

 

How it works

The World Fonts extension allows the content author to associate a specific TrueType font with each individual subtitle track. The font data is then optimized by scanning through each subtitle track and identifying all of the characters and symbols that need to be displayed, then removing anything unnecesary. Each font is then embedded in the .mkv file and associated with the subtitle track that it has been optimized for. The reduced data size means that World Fonts can be used with DivX Plus Web Player without causing lengthy buffering and by devices with limited memory.

 

How effective is optimization?

Subtitles in most Western European languages that use a latin alphabet (e.g. English, French, German, Italian, Spanish and so on) typically require between 60 to 110 glyphs after optimization. One font often used by desktop software to render subtitles is Arial, and by comparison it contains well over 1600 glyphs. Optimizing Arial for a Western European language subtitle typically yields data savings of 86-92%.

 

Asian languages use a far larger number of glyphs and fonts supporting these languages can be massive. For example, Arphic's "PL KaitiM" for Traditional Chinese is nearly 10MB large with over 14,000 glyphs. Fonts this large simply can't be loaded by many devices. However, only a fraction of these glyphs are necessary to display subtitle tracks for languages like Chinese and Japanese.

 

Complete Unicode fonts, i.e. those that support all languages, are larger still. For example, the well-known Arial Unicode contains more than 50,000 glyphs comprising over 22MB of data. In these cases optimization for many languages will yield savings of more than 99%.

 

Adding World Fonts to a .mkv file

To add a World Fonts to an .mkv file you need a utility to perform the font optimization and a file writer that fully implements the requirements of the extension. DivX provides a reference implementation in the DivXMKVMux sample tool. Begin by downloading and installing the DivXMKVMux package.

 

For easy access to DivXMKVMux launch a command console via the shortcut provided in the DivX Plus programs group on your Start menu. The console will start in the installation directory and the installation directory is automatically added to the PATH environment variable for the console session so that you can type "DivXMKVMux" from any other directory.

You can access the full list of arguments for DivXMKVMux using:

DivXMKVMux --help

The help output is lengthy because DivXMKVMux is fairly flexible, but the required syntax is actually quite straightforward. There are several different ways DivXMKVMux can be used to add an optimized font to an .mkv file. If you haven't already added subtitles to your .mkv file it's easy to add the tracks and optimized fonts in one straightforward operation. Use -r to indicate you're remuxing an existing .mkv file and then specify subtitle files and associated font files with -s:

DivXMKVMux -o MyOutput.mkv -r MyInput.mkv -s font:MyEnglishFont.ttf lang:eng name:English English.srt -s font:MyFrenchFont.ttf lang:fre name:French French.srt -s font:MyGermanFont.ttf lang:ger name:German German.srt

Specifying names for the subtitle tracks is optional but you must specify the correct language code or the tracks may not be listed correctly in some players. You can lookup valid alpha-3 language codes in the ISO 639.2 code-list. Remember to quote ("") any filenames containing spaces.

If you are starting with a .mkv file that already contains subtitle tracks first list the existing tracks so that you can see the list of track numbers as interpreted by DivXMKVMux:

DivXMKVMux -l MyInput.mkv
Track language info:

Title 0:

    Vid: 1 video stream(s)
        0 - master video track

    Aud: 1 audio streams(s)
        0 - eng

    Sub: 3 subtitle stream(s)
        0 - eng
        1 - fre
        2 - ger

Then use -r to remux the file, specifying an appropriate font for each subtitle track with -f:

DivXMKVMux -o MyOutput.mkv -r MyInput.mkv -f add:MyEnglishFont.ttf outtrack:0 -f add:MyFrenchFont.ttf outtrack:1 -f add:MyGermanFont.ttf outtrack:2

For each subtitle track in the input .mkv file DivXMKVMux will optimize the specified font and then add it to the output .mkv file.

Note that it is strongly recommended to pass only UTF-8 encoded .srt files to DivXMKVMux, especially for non-Latin languages, because this prevents the risk that other encodings are not transformed to UTF-8 correctly internally. If you pass .srt files to DivXMKVMux that don't have a unicode BOM they are assumed to be ANSI and the active system codepage will be used to convert them to UTF-8 unless you explicitly override the codepage number using the -s codepage: option. Generally, if the SRT does not display correctly when opened in Notepad the file is probably not UTF-8 and the active codepage is unsuitable for the conversion.

You can easily convert the encoding of any input .srt file to UTF-8 using Notepad++, a free text editor, by performing these steps:

  1. Open your .srt file.
  2. Check if the highlighted option in the "Encoding" menu is "Encode in UTF-8". If it is then the file is already UTF-8.
  3. From the Encoding menu choose an appropriate character set, verify the text is displayed correctly, then choose "Convert To UTF-8".
  4. Save your .srt file.

You can also avoid this process by creating your .srt files with UTF-8 encoding originally.

 

Support for World Fonts

Initial support of the World Fonts extension is included in DivX Plus Player and DivX Web Plus Player with these known-issues:

  • In DivX Plus Webplayer 2.0.2 you may be unable to select the first subtitle track. You can work around this problem by choosing any other subtitle and then change to the first subtitle track, or by using the JavaScript API.
  • In the DivX Plus Player 8.1 an attached font may not be loaded if its face style is different than the style set in the player preferences. For example, your preferences are to use an italic face but the attached font has a regular face.

World Fonts are supported in all DivX Plus HD devices.

 

Let us know what you think

Please send us your comments and questions on this feature via the DivX Plus (.mkv) forum (requires sign-in).



Technical description

This section of the article describes the technical implementation of the World Fonts feature and assumes the reader is familiar with MKV EBML structure. Less technical readers may wish to skip this section.

The following diagrams illustrate how World Fonts are represented in DivX Plus HD .mkv files. At a high level:

  • The extension uses various pre-existing MKV EBML element IDs.
  • Some of these elements must take on specific values. Consult the syntax table below for further detail.
  • Fonts are stored as attachments, and must be explicitly associated with the specific subtitle TrackEntry for which they have been optimized by use of an AttachmentLink element in the TrackEntry that references the Attachment FileUID. Only once this reference is successfully resolved is a relationship established.

Additionally, the following restrictions apply to fonts:

  • The font must be a TrueType (.ttf) font type.
  • The font must contain a table with a Microsoft Unicode character map ("cmap" table entry with Platform ID=1, Encoding ID=3).

 

The EBML elements for World Fonts are:

[+] Click to expand Key

Element Name Lvl EBML ID Ma Mu Rng Def Type D+ Description
Segment->Track->TrackEntry
TrackType 3 [83] * - 1-254 - u - The type of this track. Value must be 0x11 for subtitles.
AttachmentLink 3 [74][46] - - >0 - u - The FileUID of the AttachedFile that contains the TrueType font that has been optimized for this subtitle track.
Segment->Attachments->AttachedFile
FileDescription 3 [46][7E] - - - - 8 - For this extension must be "true type font".
FileName 3 [46][6E] * - - - 8 - The file name of the original TTF font file.
FileMimeType 3 [46][60] * - - - s - For this extension must be "application/x-truetype-font".
FileData 3 [46][5C] * - - - b - The binary contents of the optimized TrueType font.
FileUID 3 [46][AE] * - >0 - u - A unique ID for this attachment. This ID must be referenced by the AttachmentLink element of the subtitle TrackEntry for which this TrueType font file has been optimized.
FileUsedStartTime 3 [46][61] - - - - u * The timecode at which this optimized font attachment comes into context, based on the Segment TimecodeScale. This element is reserved for future use and if written must be the segment start time.
FileUsedEndTime 3 [46][62] - - - - u * The timecode at which this optimized font attachment goes out of context, based on the Segment TimecodeScale. This element is reserved for future use and if written must be the segment end time.

DivX 7 Playback Preview

Our third Project Rémoulade release is a preview of the new playback components from the upcoming DivX 7 bundle. Building upon past releases, DivX Player 7.0 Beta 1 now features support for MKV files containing high definition H.264 video and surround sound AAC audio! The preview also includes components that extend support for the MKV container and H.264 video to most Windows media players.



Update: The DivX 7 Playback Preview has been superseded by the release of DivX 7. Click here to read the complete original article.


Contents

  1. What's in DivX 7 Playback Preview?
  2. What's new in DivX Player 7.0 Beta 1?
  3. Known issues in this preview
  4. Downloading DivX 7 Playback Preview
  5. Uninstalling DivX Playback Preview
  6. How you can help us

What is in the DivX 7 Playback Preview?

With the DivX 7 Playback Preview we bring new technologies to DivX Player and other DirectShow-based media players that enable playback of DivX Plus videos. DivX Plus HD is a new DivX video profile that will bring the following formats into the DivX ecosystem when DivX 7 is launched:


  • H.264 video

    A new standard for video compression that is more technically complex than the standard used by DivX 6. H.264 provides better compression and picture quality at the expense of higher system requirements for content creation and playback. Related releases from Project Rémoulade include the DivX H.264 Decoder (Beta 1, Beta 2, Beta 3) and the DivX H.264 Encoder (Alpha 1).

  • AAC audio

    A high-efficiency audio coding standard natively supporting multichannel audio and studio-quality sample rates for crystal clear theatrical surround sound. AAC audio suffers fewer audible artifacts than MP3 at very low bitrates and also requires less bitrate to achieve transparency. MP3 is the audio standard for previous versions of DivX video.

  • MKV container format

    MKV files will be used to contain the H.264 video and AAC audio tracks. The format is feature-extensible by design and supports many audio and subtitle streams within a single file.


The DivX 7 Playback Preview also includes the DivX H.264 Decoder filter and the DivX MKV Demux filter*. These DirectShow filters extend playback support for MKV files with H.264 video streams to all DirectShow-based media players.

* The DivX MKV Demux filter does not override any other MKV file splitters you have installed.


What's new in DivX Player 7.0 Beta 1?



DivX Player has been extensively upgraded in preparation for some of the exciting new features that will be released with DivX 7 for Windows! Some of the major changes include:


  • High-performance H.264 video decoding with support for Baseline, Main, High, High 10, and High 4:2:2 profiles, full interlace support, multithreaded decoding on up to 8 CPU cores and optimizations for MMX, SSE and SSE2 instruction sets.

  • Multichannel AAC (LC/HE) decoding

  • Support for MKV files including:
    • Multiple audio tracks for multilingual audio, directors commentary or isolated musical scores
    • Multiple subtitle tracks for multilingual subtitles
    • Ordered chapters for chaining MKV files together during playback

  • Initial support for SSA and ASS subtitles which can either be stored within the MKV file or externally

  • Fast frame-accurate seeking

  • Real-time handling of interlaced H.264 video:
    • Bob de-interlace
    • Display top field only
    • Display bottom field only
    • Display weave

We have also made several other general improvements since DivX Player 6.8.2:


  • The Direct3D renderer is compatible with a wider range of video cards and has improved performance when video is rendered on a secondary display (except where the video area crosses a display boundary). The Direct3D renderer became the default in DivX Player 6.8.1 for systems supporting DirectX 9 with Pixel Shader 2.

  • The GDI renderer has returned and allows DivX Player to display video in circumstances where no hardware acceleration is available, e.g. when the video hardware is in use or over remote desktop.

  • Better handling of AVI files that have a broken index. It is now possible to seek inside the file where a partial index exists and warnings are no longer displayed as soon as the file is opened.

  • Better support for media created using the DivX Author application.


Known issues in this preview

This non-exhaustive list of known-issues summarizes some important points you should be aware of when using DivX Player 7 Beta 1:


  • Formatting information is currently stripped from SSA and ASS subtitles

  • When playing AAC HEv2 streams only one channel may be audible

  • For some H.264 files encoded with MBAFF the field order may be detected incorrectly. This may cause the video to flicker during playback. You can work around this issue by temporarily selecting to display top field only.

  • Audio synchronization may be lost on systems using Realtek HD Audio adapters. This appears to be a problem in the Realtek drivers, a workaround is to open the Sounds and Audio Devices control panel to reduce the hardware acceleration for playback to the "Basic acceleration" level.

  • DivX Player may crash while fast-forwarding H.264 video at high speed.

  • There are various known issues for the OpenGL renderer. This renderer is neither the default or fall-back renderer on any system.

  • It is possible to select the DirectDraw renderer when DivX Player is running under the Vista Aero UI. This combination is unsupported and will currently result in a misleading error message stating the video format is invalid. Do not use the DirectDraw renderer if you are using the Vista Aero UI.

When you play MKV files in third-party media players you may also encounter these known issues relating to the DivX MKV Demux filter:


  • Files that do not contain a video track are not yet supported.

  • Loss of audio synchronization may occur when playing MKV files containing DivX 6 content (ASP video, MP3 audio).

  • After seeking or unpausing the video may briefly play faster or slower than normal while resuming.


Downloading DivX 7 Playback Preview

The DivX 7 Playback Preview has been superseded by the release of DivX 7. You can now download everything that was included in this preview for free as part of the DivX for Windows bundle.


Uninstalling DivX 7 Playback Preview

If for any reason you wish to uninstall this beta please use the shortcut in the DivX programs group of your Start menu to "Remove the DivX Media Pack", and complete the installation process before re-installing any older version of the DivX software. Only this uninstaller will cleanly remove the DivX 7 Playback Preview components.


How you can help us

We want to hear from you! Did you experience any problems using this beta software? Did the player perform well on your system? Did you find a bug? Give us your feedback via the DivX Labs forums!



If your feedback relates to performance issues you can also email us some of the following information to help us diagnose the problem:


  • Screenshots from CPU-Z that show your CPU, memory and mainboard configuration.

  • Screenshots from DXDiag, which you can launch by simply typing DXDiag into the Run box on your Start menu, so that we can see information about your graphics card (e.g. vendor/model/memory/driver revision).

  • Screenshots of any crash dialogs, including the details view if available.

  • In the case of crashes, an export from MSInfo32, which you can launch by simply typing MSInfo32 into the Run box on your Start menu, so that we can see information about the operating system, running software and application errors.

If you email us please include your DivX Labs user name and links to any forum threads that further describe the issue.


DivX H.264 Decoder Beta 1


Features of the DivX H.264 Decoder

 
  • H.264 Main, High, High 10, High 4:2:2 profiles
  • Full interlace support (MBAFF, PAFF, mixed)
  • Multithreading supporting up to 8 CPUs
  • Optimizations for MMX, SSE, SSE2

Configuring the decoder

Once installed the decoder can be configured either by accessing the filter property page from a host application (i.e. a media player), or by selecting the H.264 Decoder Config link in the DivX programs group on your Start menu:



Click to enlarge

The options that can be set include:

 
  • Deblocking

    Deblocking should normally be on for H.264 video because the encoder assumes that the decoder will perform in-loop deblocking in accordance with the format specification and codes the video accordingly. Turning off deblocking will therefore introduce artifacts during playback, but because deblocking is computationally expensive this option can be desirable for low-powered systems that could not normally decode H.264 or where battery life is at a premium. Disabling deblocking does not look too bad with most content. Deblocking is enabled by default.

  • Multithreading

    When enabled, this option allows the decoder to subdivide the decoding process across multiple CPUs or cores to accelerate decoding and provide a smoother playback experience. Multithreading is enabled by default.

  • Low latency

    This is an experimental feature that may increase the frame rate for more basic bitstreams at lower resolutions, or on systems with larger CPU cache. Low latency is enabled by default.

  • Disable logo

    Turns off the small DivX logo that appears in the lower-right of the picture for a few seconds at the start of playback. Disable logo is disabled by default.

  • Use default encoding settings in this application When this decoder filter property page is accessed from within a host application, this setting instructs the decoder to turn off features such as color correction and the logo overlay and turn on features such as deblocking to ensure that DivX video sources are processed in their original form without any adjustments applied. This is important when transcoding for example. This option is disabled by default and is set on a per-application basis.

  • Brightness, Contrast, and Saturation

    These sliders enable image adjustments that may improve the appearance of H.264 video on your computer. Each slider is centered by default.

Creating our test clips

To test the new decoder we encoded a 12 minute long video sequence from Last Man Standing, a very sharp source clip combining high texture detail, fast motion, strong color contrast, flashing lights, frequent scene changes, computer graphics, indoor and outdoor scenes, and smoke and particles. It was encoded using x264 version 0.59.807 08b5132 with the following options:

 
--keyint 250 --bframes 4 --b-pyramid --ref 4 --aq-strength 0 --partitions "all" --8x8dct --direct "auto" --weightb --me "umh" --merange 32 --subme 7 --b-rdo --mixed-refs --trellis 2 --no-fast-pskip --no-dct-decimate --sar 1:1

We ran one encoding using --qp 16, resulting in output with an average data rate of 45.57Mbps, and another with --bitrate 15000 --pass <1,2>. The 45 Mbps stream is extremely high quality and the high data rate ensures that during benchmarks the majority of the CPU time is spent in the decoder (as opposed to the file splitter, renderer, or host application). The 15 Mbps stream represents a rate more typical of common 1080p material.

Our test clips are too large to post but you can view some representative sample images:



Click to view slideshow


Results of our own initial testing

In order to provide some insight into Beta 1 we ran a few benchmarks against some mature third-party H.264 decoder filters, namely CoreAVC 1.7.0 and FFDShow-tryouts rev 1945 CLSID build, dated 2008-04-17. For each decoder we used GraphEdit to create a filter graph comprising the Haali splitter, the H.264 decoder and the default video renderer filter. The graph configuration looked like this:



Click to enlarge

We disabled the clock for the graph, displayed the properties for the renderer filter, used Process Explorer to measure the total CPU time required to decode each clip subtracting any CPU time accumulated until the graph was run, and also noted the average frames per second achieved. We decoded each clip with every decoder three times for all of our dual core benchmarks but only twice for our single CPU benchmarks because these take much longer and the dual core tests had showed almost no deviation across multiple repetitions for any decoder on our test machine. For fairness, for every decoder we chose the result with the highest average frame rate per second of CPU time.

Our test system used an Intel Core 2 Extreme X6800 (Conroe) CPU @ 2.93Ghz, 1066Mhz FSB, 4MB of L2 cache, 4GB of DDR2 RAM, and a PCI-Express NVIDIA Quadro FX 3550/4000 SDI video card with 256MB of memory, a 256-bit bus, and ForceWare version 6.14.11.6265.



Click to enlarge

To begin, these charts show the average frames per second per decoder according to the renderer filter:



Click to view charts

You can see that on our test system Beta 1 already achieves far more frames per second (average) than FFDShow-tryouts, and also bests CoreAVC in three out of four cases. But how much CPU time was used by each decoder to obtain these results? A fast decoder is not necessarily performing well if it consumes too much CPU time. To further investigate the performance of each decoder we also charted the total CPU time used in each case:



Click to view charts

Once again the decoder performs extremely well for it's first beta release! The charts clearly show that the DivX H.264 decoder is not simply achieving high frame rates at the expense of excessive CPU time. Performance will be further enhanced as we roll out more beta releases at DivX Labs. Stay tuned ;)


An update on performance

Since releasing Beta 1 we have gathered a lot of information from members of the beta group including performance statistics for many more CPU types. Although we can consistently reproduce the above illustrated performance on our test system which was not specially selected, proving the high efficiency of the decoder core, third-party performance tests on other processors have shown some variance - particularly those performed with CPUs that have less L2 cache. This is somewhat expected as early versions of the decoder are tested for the first time on a wider range of hardware and the current beta version generally performs to within 10% of the frame rate achieved by CoreAVC on the same system. We are actively working to ensure that the decoder performs equally well across all common processor configurations.


Downloading DivX H.264 Decoder Beta 1

This version of the H.264 Decoder has been superseded by the release of DivX 7. You can now download the DivX H.264 Decoder for free as part of the DivX for Windows bundle.

DivX H.264 Decoder Beta 3


The third beta release of the DivX H.264 Decoder improves performance for older AMD CPUs, introduces preliminary support for DVB applications, adds support for baseline profile, and greatly improves stability of the decoder.



Update: This version of the H.264 Decoder has been superseded by the release of DivX 7. Click here to read the complete original article.


What's new in Beta 3

The following changes have been made to the decoder:

  • A problem writing to video memory on systems using older AMD CPUs that reduced performance by as much as 60 percent has been addressed. Beta 3 is also slightly faster than Beta 2 on all of our test systems.

  • Support has been added for packetized NAL bitstreams and the decoder can now be used with DVB applications. Preliminary testing included:

    • DVBViewer
    • DVBDream*
    • TerraTec Home Cinema

    * This currently requires you to manually add the DivX H.264 Decoder GUID to the [H264_CODECS] section of guids.ini in the DVBDream installation folder immediately after installation and to select the DivX H.264 Decoder on first run. The GUID is {6F513D27-97C3-453C-87FE-B24AE50B1601}.

  • New support for dynamic format changes enables DVB applications to switch between live streams of different resolutions.

  • H.264 baseline profile streams can be decoded thanks to support for flexible macroblock ordering and arbitrary slice ordering.

  • Error resilience has been significantly improved, providing better stability during playback of defective and damaged bitstreams.

  • The decoder accurately handles DirectShow timestamps to minimize jitter.

  • Full support for H.264 streams read from MKV containers.

Known issues for Beta 3

This non-exhaustive list of known-issues summarizes some important points you should be aware of when using Beta 3:

  • The decoder does not yet include built-in deinterlacing. When viewing interlaced material you may see horizontal lines and jagged edges around objects during motion if your media player does not deinterlace. We recommend viewing interlaced content at it's native resolution or larger to minimize undesirable artifacts caused by downsampling.

  • ReClock users may find that the ReClock Audio Renderer filter cannot determine the video frame rate of streams decoded by the DivX H.264 Decoder filter.

Downloading Beta 3

This version of the H.264 Decoder has been superseded by the release of DivX 7. You can now download the DivX H.264 Decoder for free as part of the DivX for Windows bundle.


How you can help us

We want to hear from you! Did you experience any problems using Beta 3? Did the decoder perform well on your system? Did you find a bug? Send us your feedback.

If your feedback relates to performance issues or software stability please consider attaching some of the following to your email:

  • Screenshots from CPU-Z that show your CPU, memory and mainboard configuration.

  • A screenshot from GraphStudio after dragging and dropping your media file onto the application so that we can see how DirectShow attempts to render the media on your system.

  • Screenshots from DXDiag, which you can launch by simply typing DXDiag into the Run box on your Start menu, so that we can see information about your graphics card (e.g. vendor/model/memory/driver revision).

  • Screenshots of any crash dialogs, including the details view if available.

  • In the case of crashes, an export from MSInfo32, which you can launch by simply typing MSInfo32 into the Run box on your Start menu, so that we can see information about the operating system, running software and application errors.

DivX H.264 Encoder Beta 1 & Tutorial

UPDATED - 03/12/2009

The latest package to be released from Project Rémoulade is a beta version of the DivX H.264 Encoder. This multithreaded encoder produces high definition H.264 video bitstreams that are compatible with the draft profile for DivX 7 H.264 HD video. The encoder is a command line utility and accepts input from raw AVI files as well as the AVISynth frameserver.

View our tutorial for the DivX H.264 Encoder


An introduction to the DivX H.264 Encoder

In this article we'll start with a walk-through of using the command line encoder. We'll cover everything from encoder installation to the third-party software needed to create and play MKV files, tools for video processing, some of the constraints in the draft DivX 7 H.264 HD video profile and some tips on customizing your experience with the encoder for easier, more automated multipass encoding. Our guide should be very easy to follow so grab a cup of tea and let us teach you the basics! In the near future we'll also discuss the draft profile in more detail for those who are interested.


Contents


1. Installing the DivX H.264 Encoder Beta 1

Setting up the encoder is very straightforward. Members of the Project Rémoulade or Project Rémoulade Apps groups who are signed in to their DivX Labs accounts can download the installation package. If you're not yet a group member please create a DivX Labs account and then subscribe to the Project Rémoulade Apps group to gain access to this download.

After downloading and launching the installation package you should see the following screen:



Click to enlarge

You should note the installation folder location because this is where the command line utility will be installed. A shortcut named Encoder Console that opens a command window at this location is automatically added to your Start menu Programs folder under DivX\DivX H.264 Codec CLI . Launch the Encoder Console and type divx264 -help to see the list of arguments that can be passed to the encoder. If you aren't used to working with command line utilities don't worry if it looks a little complicated. We'll walk you through it in a moment, but first let's also install a few other components you'll need.


2. Installing third-party software

This beta version of the encoder outputs raw H.264 video bitstreams. To transform these bitstreams into video files that will play in your favorite media players you'll need some additional software to write them into an MKV container after encoding, and then during playback something to read the bitstream back out of the container and an H.264 decoder to transform the bitstream back into actual video. We also recommend additional software to serve video into the encoder; we'll explain that more in step 3. First, let's get everything installed!

  • AVISynth 2.57 [Homepage]

    AVISynth is a script-based frame server. You will use it to prepare your source video for encoding and to serve it as input to the H.264 encoder. During the AVISynth installation it is convenient (but not required) to associate .avs files with Notepad via the option on the component selection screen.

  • VirtualDub [Homepage]

    VirtualDub is a video processing application. You will use it to preview the output of your AVISynth scripts. Simply extract the .zip archive into any new folder. No installation process is required.

  • MKVToolnix [Homepage]

    MKVToolnix is a package of tools for working with MKV containers. You will use it to write the raw H.264 bitstream that the encoder creates into an MKV file.

    Note: You may want to jot down the installation path for MKVToolnix that displays during installation. Later we'll explain how to use this information to make MKVToolnix more convenient to use.

  • Haali Media Splitter [Homepage]

    Haali Media Splitter is a DirectShow filter capable of parsing MKV containers. Once installed it can be used automatically by any DirectShow media player to read data streams from MKV files. This includes most players for Windows.

  • DivX H.264 Decoder Beta 2 [Homepage]

    The DivX H.264 Decoder is a DirectShow filter that decodes H.264 video streams. Once installed it can be used automatically by any DirectShow media player to decode H.264 video bitstreams ready for display.

    Note: To download the DivX H.264 Decoder you must be a member of the Project Rémoulade group and signed into your DivX Labs account. The download link will then appear on the Project Rémoulade homepage.

  • MONOGRAM GraphStudio [Homepage]

    MONOGRAM GraphStudio allows you to build, view, edit and run DirectShow filter graphs. We'll use it to examine how the MKV files we create are rendered and to access settings for the DivX H.264 Decoder. No installation of GraphStudio is required. Simply save the file to disk.

3. Creating an AVISynth script

The first step in encoding H.264 video is to prepare the input for the encoder. It's best to use AVISynth because we can easily work with various file types including compressed AVI files which the beta encoder does not support natively, and make any necessary adjustments to the video before encoding it.

AVISynth is a scripted frame-serving engine. When an application that supports AVI files, such as VirtualDub, opens an .avs file (.avs is the file extension for AVISynth scripts) the AVISynth engine loads and creates the source video on the fly according to the script you've written to generate it. AVISynth scripts can be as simple as a single line that loads a single source file, or as complex as necessary to produce professional-grade video effects using multiple sources and dozens of freely available plugins. Let's start with a very simple script to check that AVISynth is installed correctly.

Start Notepad and enter the following:

Save this file with a .avs extension instead of the default .txt extension. If you can't see the file extension when you save the file turn off the option to "Hide extensions for known file types" in the Windows Folder Options control panel under the View tab. Next, start VirtualDub and drag your .avs file onto the VirtualDub program window. You should see a video that is ten seconds long displaying information about the installed version of AVISynth:



Click to enlarge

This video has been generated by AVISynth's internal filter named Version, which you used in your .avs script. Find information about all of AVISynth's built-in filters on the avisynth.org Internal Filters wiki page if you're interested or need help. We'll briefly cover each of the filters that are key to getting started in this guide. Don't worry about the second video display that appears in the VirtualDub window for now, it's only useful when you apply additional processing in VirtualDub and that's not part of this tutorial.

AVISynth has several source filters built-in that allow it to input many file types. We'll use either AVISource or DirectShowSource. Modify the following script by uncommenting one (and only one) of the "source" lines and changing the filename to the name of your input file:



Click to enlarge
Download this sample script
(Note: After downloading change the file extension to .avs)


Notice in the screenshot that we've turned off Word Wrap and enabled the Status Bar using Notepad's Format and View menus respectively. Should AVISynth report an error on any particular line, this can make finding the problem easier. Also notice that this time around we're using the "return" instruction to explicitly instruct the AVISynth engine to pass our clip MySource to VirtualDub. Because we're assigning our source to the clip variable MySource AVISynth doesn't implicitly know that this is what we want to return to the host application.

As before, drag the .avs file onto the VirtualDub program window to test the script. If all is working you should see your source video!

The next thing we need to know is the frame rate of the video and picture dimensions. To ensure reliable playback on a wide range of consumer electronics devices the draft profile for DivX 7 places constraints on these properties, requiring that the picture dimensions be at least 320x240 pixels with width and height each being multiples of eight, that the picture dimensions do not exceed 1280x720 if the frame rate is greater than 30hz, and that the video has the exact equivalent of one of the following Rate/Scale combinations:

Rate
(Numerator)
Scale
(Denominator)
Approximate FPS
= Rate / Scale
Max Dimensions Min Dimensions
60 1 60 1280x720 320x240
60000 1001 59.940 1280x720 320x240
50 1 50 1280x720 320x240
30 1 30 1920x1080 320x240
30000 1001 29.970 1920x1080 320x240
25 1 25 1920x1080 320x240
24 1 24 1920x1080 320x240
24000 1001 23.976 1920x1080 320x240
Width and height are tested independently for minimums and maximums.
Width and height must each be multiples of 8.
Any rate/scale substitutions must evaluate to exact equivalents.

Let's go back to our first .avs script that simply used the built-in Version filter to display the version of AVISynth that is installed. Because everyone following this tutorial has access to the same Version filter we'll use this as a video source for the next few examples. Of course you could substitute any AVISource or DirectShowSource that you like.

Open the simple Version() script again with VirtualDub and choose File information... from the File menu. Notice that the frame size is 436x80. This gives us two problems to deal with: The width is not a multiple of eight (436 divided by 8 is not a whole number) and the height is less than 240 pixels. If we divide the width by eight we get 436 / 8 = 54.5 . Rounding up to the nearest whole number and multiplying by eight gives us the nearest larger resolution: 55 * 8 = 440 pixels. So we need to add 4 pixels to the height of the clip and 160 pixels to the width to meet the profile constraints. We can use AVISynth's built-in AddBorders filter to pad the frame with a black border. Let's add 2 pixels to the top and bottom and 80 pixels to the left and right of the frame using the color black:

If you drag this new script onto VirtualDub you can see how AddBorders has changed the video:



Click to enlarge

Note that if we had wanted to avoid adding pillarboxing AVISynth gives us several alternatives including cropping and resizing. You can see examples of these in the following sample:



Click to enlarge
Download this sample script
(Note: After downloading change the file extension to .avs)

Okay, so now we know several methods of manipulating the picture dimensions to fit our needs. What about taking care of the frame rate? The approximate frame rate of the video is calculated as a fraction, or in other words ~fps = numerator/denominator. The numerator is also referred to as the "rate" and the denominator as the "scale". Certain rates are easy to specify exactly. For example, 24fps can simply be given as 24/1. Others are trickier depending on the precision required. For example, you might find that a source loaded with AVISource or DirectShowSource has a frame rate of 29.97 fps calculated from a rate/scale of 5000000/166833 = 29.970089[...] fps which is actually different to the DivX 7 profile constraint of 30000/1001 = 29.970029[...] fps. The draft profile is strict in this regard so as to ensure accurate presentation of content across many device types. Note that equivalent substitutions are permitted, for example 120000/4004 = 30000/1001 = 29.970089[...] fps.

Sound tricky? It really isn't. Let's examine the frame rate of Version() by applying AVISynth's internal Info filter:



Click to enlarge
Download this sample script
(Note: After downloading change the file extension to .avs)



Click to enlarge


As you can see from the screenshot, Version() already has a valid rate/scale of 24/1 = 24.0000 fps so there's no need to make any changes. However, what if you have to deal with an incompatible rate?

Let's think back to our earlier example of a source at 29.97 fps using a rate/scale of 5000000/166833 instead of the profile requirement of 30000/1001. That's a difference of only (5000000/166833) - (30000/1001)= ~0.00006 fps, and over the length of a two hour long video it results in a difference in duration of only 0.00006 fps * 7200 seconds = ~0.436 frames, or approximately 0.463 frames * (1 second / 29.97fps) = ~15ms total, which is probably not even worth worrying about. You could simply override the rate/scale in AVISynth without adjusting the audio or video at all. But what if the source frame rate was not close to one of the rates in the spec, or you wanted to ensure "perfect" sync over a very long video? AVISynth provides a few of ways to handle this. Let's look at two of them:

  • ChangeFPS duplicates or removes frames as necessary to attain the new frame rate without changing the clip duration. This is the easiest and, in many cases, the cleanest way to change the frame rate because no adjustment to the audio is necessary. There are no changes in pitch, sample rate, duration or sync to worry about. Keep in mind that in our example, adapting the rate/scale resulted in less than half of one frame of skew over two hours, so if you are simply adapting for a permitted rate/scale it is unlikely that many frames will be duplicated or removed. Duplicate frames can also be processed extremely efficiently by the encoder.

  • AssumeFPS simply speeds up or slows down the video. This technique is more complex in that it actually affects the duration of the video. If you are also processing audio through AVISynth, either as part of the original video source or by using some combination like WAVSource and AudioDub then AVISynth will also raise or lower the audio sampling rate as necessary to maintain sync. This implies a change in pitch and the audio may end up at a non-standard sampling rate. You can later use ResampleAudio later to resample the audio back to a standard rate (e.g. 44.1Khz or 48Khz), or instead use TimeStretch to stretch the audio clip to the new video duration without changing the pitch. If you were not passing audio through AVISynth, which is sometimes the case, you would have to manually adapt the audio before encoding it to ensure it remained in sync.

Both ChangeFPS and AssumeFPS accept a numerator (rate) and denominator (scale) as arguments. The following sample script shows some examples of changing the frame rate. As you can see using ChangeFPS() is very simple:



Click to enlarge
Download this sample script
(Note: After downloading change the file extension to .avs)

Now you know how to adapt any source to become valid input for the encoder and you can see why even though the DivX H.264 Encoder can encode raw AVI files directly, it's still very handy to be familiar with the basics of AVISynth. It offers such useful functionality that you may always want to feed AVS files to the encoder (this is exactly what many of the community-created graphical user interfaces do). To complete this part of the tutorial, create an .avs script for a source file of your choosing that returns a video with frame rate and picture dimensions that fall within the constraints of the draft DivX 7 HD profile. Audio is optional because the H.264 encoder is not directly concerned with it.


4. Using the DivX H.264 Encoder with your AVS script

Launch the Encoder Console shortcut that was created in you Start menu Programs group under DivX\DivX H.264 Codec CLI when you installed this beta software. You'll see the following:



Click to enlarge


The shortcut runs a batch script that automatically adds the installation folder to the PATH environment variable for this particular console window, allowing you to run the encoder conveniently from any directory. Later we'll explain how to do the same for MKVToolnix. Although this tutorial isn't intended as a guide to the Windows command interpreter here are a few essentials to help you navigate the file system just in case you aren't already familiar with it:

Command Meaning
CD ..Go up one directory
CD \Go up to the root of the drive
CD \WindowsGo to the root directory, then into the Windows directory
CD "\Program Files\DivX"Go to the root directory, then into the Program Files\DivX directory. Notice that whenever a filename contains spaces you should quote it, otherwise the command interpreter doesn't know to treat it as a single command argument. This is also important when specifying paths and file names to the DivX H.264 encoder and other tools. You can quote filenames without spaces, but it is not necessary.
D:Change context to the D drive (if you have one). The command interpreter remembers the current directory on each drive individually.
CD D:\ExampleChanges the current directory on the D drive to D:\Example . Note that if you are currently working on the C drive this doesn't automatically switch your context. You will remain in the current directory on the default drive (normally C:) until you type D: to change drive contexts.
DirList the contents of the current directory
Dir "C:\Program Files"List the contents of C:\Program Files , without actually changing to that directory.
Dir /?Get help for the Dir command. Most commands will give help when you specify /? as the only argument. Note that the beta encoder is an exception, and will give you help if you specify -help as the only argument.
Help|MoreSee a list of valid commands. Adding "|More" makes the console pause after each screen of output.
ExitExit the command interpreter. You can also use the close button on the console window.

Change directory to the location where you stored the .avs script that you want to encode or alternatively your raw AVI file if you chose not to make an AVISynth script for it. Type the following command to see the form of the DivX H.264 Encoder command line:

DivX264 -help

You can also download -help as a text file for easier viewing. In command line documentation it's convention to use square brackets to indicate parts of the command line that are optional, and angular brackets to indicate parts of the command line that are mandatory. You can see that the basic usage is as follows:

Usage: [options] -i <input file> -o <output file>

You must specify the name of the input and output file using -i and -o respectively, otherwise you'll get an error. You can also precede the -i and -o arguments with one or more options as detailed by -help. For example, we could prefix them with the -br argument to specify "Target bitrate in kbps". Because -br is documented as "-br <int>" if we specify -br we must also specify an integer value following it, which will be the target bitrate.

Let's start with something simple: a one pass encoding using the default options. The encoder will automatically choose a reasonable bitrate based on the resolution and frame rate of the source file unless we specify one, which is fine for our initial experiment. Enter the following, substituting the name of your source file and the output filename that you want:

DivX264 -frames 100 -i "MySource.avs" -o "Output.264"

The encoder should start running. If you get an error message check that the frame rate and picture dimensions meet the draft DivX 7 profile constraints. The file extension ".264" is commonly used to denote raw H.264 video bitstream, which is what the beta encoder outputs. We will later use MKVToolnix to write this bitstream into an MKV container file to allow DirectShow media players to play it back. Notice that we've added the option "-frames 100" to the command line. This tells the encoder to stop after it has encoded the first 100 frames from the source file, which is useful when you're first experimenting because you don't have to wait for it to finish encoding an entire file. When you have a command line you are happy with simply remove this argument.


5. Bitrate, rate control, encoding modes, and more

Before moving on to the topic of writing MKV containers, let's cover a few of the encoder's important options. We've already mentioned use of -br for setting the bitrate, but let's elaborate further because it's critical for balancing quality against file size. The bitrate tells the encoder how much data it can use per second of video on average, over the entire duration of the video. This means that if you specify a bitrate of 4000kbps, for example, the encoder may use more than 4000kbps for some parts of the video and less for others depending on the relative complexity of any particular sequence of frames, but on average it will aim to spend 4000kbps over the entire file. Keep in mind that the rate is given in bits per second, not in bytes per second, which is what you're likely used to dealing with. There are 8 bits in every byte, so you can simply divide and multiply by 8 if you need to convert between the two. For example, if you have a video that is an hour and a half long and you encode it at 2000kbps the final size of the raw bitstream will be approximately 1.5 hours * 60 minutes * 60 seconds * (2000,000 / 8) = 1,350,000,000 bytes, or approximately 1287MB (there are 1,048,576 bytes in one megabyte). The MKV container will add a small overhead on top of this rate, as will any accompanying audio.

There are many bitrate calculators available online for free. Use your favorite search engine to find one. Let's work through one example to illustrate the mathematics. In our example we want to encode an hour long video in 720p @ 25fps with 128kbps audio and fit everything inside a 1GB file. Which bitrate should we use?

  • The first thing to realize is that bitrate calculations for target file size care only about two things: How long is our video, and how much storage capacity do we have? The fact that the video is 720p and 25fps is irrelevant to hitting a target file size, although using a bitrate that is too low for the video in question will of course result in degraded quality.

  • Start by calculating the duration of the file: 60 minutes * 60 seconds = 3600 seconds.

  • Next, calculate how much storage is available: 1GB = 1,073,741,824 bytes * 8 bits = 8,589,934,592 bits / 1000 = ~8,589,934 kilobits.

  • Then subtract the storage that will be used by audio (@128kbps): We have 3600 seconds * 128 kilobits = 460,800 kilobits of audio to store. That leaves us with 8,589,934 kilobits - 460,800 kilobits = 8,129,134 kilobits for video.

  • The video bitrate will therefor be 8,129,134 kilobits / 3600 seconds = ~2258kbps, minus a very small amount for the overhead of the MKV container we will later store everything in.

Our command line might look like this:

DivX264 -br 2258 -i "MySource.avs" -o "Output.264"

When it comes to creating high-quality video bitrate is only one part of the equation. In our example the encoder has an average bitrate of 2258kbps to work with, but we know that depending on how the picture complexity varies throughout the file it may allocate more bits to some frames than to others. The algorithm that makes such allocations must therefore affect the overall quality of the video. This algorithm is called the rate control, and there are two rate control modes available in the beta encoder: 1-pass and Multipass.

1-pass mode is the default and causes the encoder to manage data allocation based on the complexity of the incoming sequence of frames. This allows the rate-control to spend bits fairly appropriately as long as the video complexity remains fairly consistent.However, because the encoder can't look ahead (it's making only one pass over the video), rapid changes in video complexity can lead it to speculate about the rate allocation in a suboptimal manner. For example, imagine a situation in which the encoder is processing a panning shot of a landscape. This is probably a low-motion sequence that is very easy to motion compensate leading to high picture quality with only an average bitspend. Then imagine an action scene immediately following. The image texture is now changing extensively from frame to frame and motion compensation becomes more difficult. After encoding one or two frames of this new sequence at the same quality as the landscape sequence the data rate has spiked due to the increased video complexity. The encoder knows it only has a certain average bitrate to work with and that it must also limit rate spikes so that the output bitstream can be played back smoothly by decoders in consumer electronics devices. As the encoder is still unable to predict what will happen in upcoming frames, it may have to react by reducing the data rate sharply in order to avoid rate spikes and to maintain its bitrate budget, in turn causing noticeable variations in the picture quality.

Multipass mode attemps to work around this lack of foresight by breaking the encoding process down into at least two passes. During the first pass the encoder analyzes the source video complexity and stores this information in a statistics file. No video is output during the first pass. Later, the encoder is started again to perform the actual encoding. During this second pass the statistics file that was created on the first pass is loaded to inform the rate control algorithm of the complexity of every frame of video that it should expect to encode, and this enables the rate control to efficiently distribute the available bits throughout the video in a manner that improves quality consistency. The downside to multipass encoding, of course, is that you have to pass the video through the encoder at least twice, which can take a long time, depending on your source file and encoder settings.

There is nothing special to do to perform a 1-pass encoding. Let's look at the command line for a 2-pass encode using our previous example again. To run the first pass we could use:

DivX264 -br 2258 -npass 1 -sf "MyStats.dat" -i "MySource.avs" -o "Output.264"

Immediately following the completion of this first pass we could then use:

DivX264 -br 2258 -npass 2 -sf "MyStats.dat" -i "MySource.avs" -o "Output.264"

As you can see, multipass encoding is no harder than 1-pass encoding, it just takes longer.

One of the most frustrating aspects of performing a multipass encoding can be waiting for the first pass to finish so that you can start the second pass, and an easy way to solve this problem is to use batch scripts to do this work for you. A batch script is simply a plain text file (as Notepad would create) with a .bat file extension instead of a .txt extension. By entering both commands into a batch file and then typing the name of the batch file into the console window the commands will be executed automatically one after the other by the command interpreter. You can easily create batch scripts that are reusable. For example, take a look at the following batch script:



Click to enlarge
Download this sample script
(Note: After downloading change the file extension to .bat)


This script makes use of the way the command interpreter passes command line arguments into the batch script so that you can pass the script any bitrate and any source file name on the command line instead of editing the script for every encoding. Inside the script the first argument becomes %1, the second argument becomes %2, and so forth. So if you called the batch script this way:

MultipassSample.bat 2258 Sample

.. the command interpreter would run the following DivX264 commands:

DivX264 -br 2258 -npass 1 -sf "Sample.dat" -i "Sample.avs" -o "Sample264"

DivX264 -br 2258 -npass 2 -sf "Sample.dat" -i "Sample.avs" -o "Sample.264"

You can create a second batch script that calls the MultipassSample.bat script for many source files in a row using the Call command. If you're interested, you can also look at a more advanced sample that handles both one pass and multipass encoding, prints some status information to the console and does some basic error checking. The syntax for the advanced sample is:

AdvancedEncodingSample.bat <passes> <bitrate> <filename>

Of course, batch scripts are just one way to make use of the encoder. You could also design a graphical front-end application using anything from VisualBasic to C to .Net.

The last encoder option that we'll cover in this tutorial is the algorithm quality optimization mode. Variations on the algorithms and bitstream features in use can exist inside the encoder, as well as settings that control how much effort the encoder expends trading off the efficiency of the many decisions it can make while encoding. The -aqo option controls whether the encoder is configured to be faster at some expense of efficiency or vice versa. Remember that the bitrate is the largest factor when it comes to quality and the rate control method determines how the available bits are allocated. The -aqo mode determines how much time the encoder spends ensuring it is making the most efficient use of those bits. In the beta encoder there are three -aqo modes available:

  • -aqo 0
    Fastest mode, least efficient.

  • -aqo 1
    Balanced mode, best trade-off of speed versus efficiency. This is the default mode.

  • -aqo 2
    Highest quality mode, slowest but most efficient.

For example, to use the highest -aqo mode you could write:

DivX264 -br 2258 -aqo 2 -i "Sample.avs" -o "Sample.264"


6. Preparing MKVMerge

The last two steps of this tutorial will explain how to write our raw H.264 video bitstream into an MKV container. This is necessary because in order for DirectShow media players to play the video they need to recognize the media type, stream properties such as resolution and frame rate and other information that makes navigation possible. This information is all provided by the source splitter (in our case the Haali Media Splitter), which parses the information from the MKV container file when DirectShow calls upon it to do so, enabling the DirectShow media system to construct a filter graph that contains all the decoders and transforms necessary to render the file. Most players won't play the raw bitstream directly. We can also add audio to the MKV container file if we want. But first, we have a small problem to overcome.

Earlier in the tutorial, we explained that the batch script responsible for running the Encoder Console you've been using adds the encoder installation directory to the PATH environment variable so that you can run the encoder from any directory. Let's now explain what that means.

Every running process under Windows (and DOS, for that matter) has a set of "environment variables" associated with it. These are just string variables that contain information that let applications understand the environment they're running in. In the console window, type the following command:

Set

You will see a long list of variable names and their associated data appear on screen. Some of these are set by Windows as global environment settings, others are specific to the user currently logged into the system, and some may be set by applications or batch scripts. If you looked at the advanced batch script in section 4 you may have noticed it uses the Set command to temporarily store information about the number of passes remaining in an environment variable while the script runs. The environment variable we're interested in right now is called PATH. Type the following to see the value of the PATH environment variable:

Echo %PATH%

You will notice that PATH is a long list of directory names separated by semicolons. If you're running the command from the Encoder Console window, you'll also see that the first folder name is where the encoder was installed to. The batch script that runs the Encoder Console adds this automatically when it runs. The command interpreter uses this list of directories to look for programs and scripts when you type the name of a program as a command and it can't be found in the current directory. This is why you can type the command divx264 from any directory when you are using the Encoder Console; the interpreter searches for it using the PATH list and locates the program. But try running MKVMerge, the utility from MKVToolnix that we want to use:

MKVMerge

You'll receive an error message because the interpreter doesn't find MKVMerge in the current directory, nor can it locate it on the PATH list. There are two ways to solve this problem:

  1. Prefix the MKVMerge command with the complete installation path for MKVToolnix every time we want to use it.

  2. Add the installation folder for MKVToolnix to the PATH environment variable.

Explicitly specifying the full path to MKVMerge on every use is cumbersome and tedious. Instead, we can automatically add this folder to the PATH variable when the Encoder Console starts, just as the path to divx264 is also added. To do so, we'll edit the batch script that was installed along with the beta encoder. Use Windows Explorer to navigate to the DivX264 installation folder. This is the folder that is the current working directory when you first open an Encoder Console window. You will see a batch script there named Encoder Console.bat. This is the script that is run when you launch the Encoder Console from the Start menu. Right-click the batch script and choose Edit from the context menu. Windows Vista users only: Due to security restrictions you may need to right-click Notepad on your Start menu and choose "Run as administrator", then drag and drop the batch file onto the Notepad window. Once the file is open in Notepad you should see the following:



Click to enlarge


On the first line you can see that the script modifies the PATH variable by prefixing it with %CD%, a reference to the current directory (i.e. the folder the script is started in, which is the installation folder in our case). During installation we suggested that you note down the installation folder of the MKVToolnix package. If you don't know it, find it using Windows Explorer now. The default installation folder is C:\Program Files\MKVToolnix . Add the MKVToolnix path to the Encoder Console batch script as follows:



Click to enlarge


Don't forget to separate everything using semicolons. Close any open Encoder Console windows before saving your changes, then open a new Encoder Console window from the Start menu and type the following again:

MKVMerge

If everything worked, you should see MKVMerge run, although it won't do anything meaningful because we didn't pass any valid arguments. Let's do that now.


7. Writing the H.264 video bitstream into an MKV container

MKVMerge has an extensive list of arguments that can be used to write various stream types into MKV containers including many types of audio and video, and to set metadata records such as content titles and language information. The HTML documentation that is installed as part of the MKVToolnix package is more verbose than the command line help and more convenient for reading. Open it now. You'll find it on your Start menu Programs folder under MKVToolnix\Documentation\Command line reference .

As you can see, there's far too much information here for us to cover in this tutorial so we'll focus on the arguments necessary to write the video bitstream you've created into an MKV container. We'll use the global options --title <title> to set the content title and -o <outfile> to specify the name of the MKV file to write, as well as the per-track options --default-track <TID[:bool]> to mark this track as the default video track and --default-duration <TID:x> to indicate the default frame duration.

The basic syntax of MKVMerge is:

MKVMerge [global options] -o out [options1] [[options2] ...] [@optionsfile]

There are only two pieces of information we really need to complete the process. The first is the track ID (or TID). The TID refers to the track number in each input file that we want MKVMerge to import. Type the following to see the list of TID's that MKVMerge assigns to the raw H.264 bitstream:

MKVMerge -i "Sample.264"

You should see that the video stream is assigned Track ID 0. If we had multiple input files it's possible that each of them contains a track with ID 0. MKVMerge won't mix them up because the command syntax says that the options for each file always appear before the filename.

The second is frame rate of the video, i.e., the value for --default-duration. The documentation states that the value must be postfixed with s, ms, us, ns or fps to specify the default duration in seconds, milliseconds, microseconds, nanoseconds or "frames per second" respectively. The number x itself can be a floating point number or a fraction. So we could pass the frame rate, e.g. --default-duration 29.970fps, or for improved accuracy the rate/scale (inverting them to get the actual duration of a frame in seconds), e.g. --default-duration 1001/30000s.

Your command line may look something like this:

MKVMerge --title "My sample video" -o "Sample.mkv" --default-track 0:true --default-duration 0:1001/30000s "Sample.264"

You may also wish to add an audio track, e.g. an accompanying MP3 file. Audio encoding is outside the scope of this tutorial, but if you want to experiment, try a command line similar to this one:

MKVMerge --title "My sample video" -o "Sample.mkv" --default-track 0:true --default-duration 0:1001/30000s "Sample.264" --language 0:eng "Sample.mp3"


8. Playing the MKV file

You should now be able to play the MKV file using any DirectShow-based media player, e.g. Windows Media Player. Note that the first time you try to open an MKV file in later editions of Windows Media Player it will warn you that it does not recognize the file extension. Simply ignore this message by selecting the option to play the file anyway.

A more interesting way to see what's going on behind the scenes of the DirectShow media system is to use GraphStudio to render the file. GraphStudio displays the DirectShow filters that are combined to form the filter graph in order to render a file. You can examine which filters are being loaded on your system and some of the information that is being passed between them. While the graph is stopped you can also disconnect some filters and manually insert others to see the result of using alternative decoders and renderers. Here's what a typical graph might look like for an MKV file containing both video and audio:



Click to enlarge


Note that by right-clicking on the DivX H.264 Decoder Filter, you can access its property page to change various settings for decoding:



Click to enlarge


Such property pages are also common for other DirectShow filters.


Known issues for DivX H.264 Encoder Alpha 1

The following are known issues in DivX H.264 Encoder Alpha 1:

  • The encoder does not provide a method to flag SAR in the bitstream. You can correct sources that are not 1:1 SAR to 1:1 using a resize transform in AVISynth. There is an example using LanczosResize in the downloadable ResoulutionSample.avs script.

  • It's not possible to stop the encoder using either Ctrl+C or Ctrl+Break.

  • The encoder doesn't support input from compressed AVI files. Create an AVISynth script using the AVISource filter to process such files.

  • The second pass of a multipass encoding may run slowly if the target average bitrate is extremely high (e.g. approaching 20Mbps).

  • The error message displayed when the width or height of the input video is not a multiple of eight pixels is incorrect.

  • The components screen in the installation package refers to "Beta 1". This is a mistake.

How you can help us

We want to hear from you! Did you find our tutorial helpful? Which additional options would you like to see available in the encoder and why? Did the encoder perform well on your system? Did you find a bug? Send us your feedback.

If your feedback relates to performance issues or software stability please consider attaching some of the following to your email:

  • Screenshots from CPU-Z that show your CPU, memory and mainboard configuration.

  • Screenshots from DXDiag, which you can launch by simply typing DXDiag into the Run box on your Start menu, so that we can see information about your graphics card (e.g. vendor/model/memory/driver revision).

  • Screenshots of any crash dialogs, including the details view if available.

  • In the case of crashes, an export from MSInfo32, which you can launch by simply typing MSInfo32 into the Run box on your Start menu, so that we can see information about the operating system, running software and application errors.

DivX MKV Mux Beta 1


For easy access to DivXMKVMux launch a command console via the shortcut provided in the DivX Plus programs group on your Start menu after installation. The console will start in the installation directory and the installation directory is automatically added to the PATH environment variable for the console session so that you can type "DivXMKVMux" from any location.

You can access the full list of arguments for DivXMKVMux using:

DivXMKVMux --help

For further information on experimenting with these extensions visit the following articles, which cover include high-level demonstrations, concept overviews, step-by-step guides, and technical specifications:


Known-issues

The following are known-issues that you should be aware of. The list is not comprehensive.

  • The DivXMKVMux sample application primarily supports input formats that are relevant to the DivX Plus format. These include H.264, AAC, SRT, and XML files for tags and chapter data. Please use --inputformats to see a complete list.
  • Attachments may not be preserved when remuxing with -r.
  • After SRT input is converted from ANSI to UTF-8 a temporary output file will remain in the input folder.
  • DivXMKVMux can crash if a very long output title is passed using titleName:
  • It is not currently possible to combine ordered and non-ordered chapter lists

Let us know what you think

Please submit your comments and questions to the DivX Plus (.mkv) forum (requires sign-in).


If you're experiencing problems with the software please include your full command line, any relevant details of your input files, what you expect DivXMKVMux to produce as output and what the actual output is.

DivX Plus HD H.264 Encoder (Beta 2)


What's new in Beta 2
  • Target Quality Mode

    One of the problems faced in video compression is determining at which data rate we need to encode a given piece of content to achieve a particular output quality. Certain sources are likely to require higher bitrates than others, e.g. a fast-action film versus a CGI animation, and experimental encoding can be time consuming, exacerbated by the fact that the rate-control can be misguided with less than 2 passes. A target quality mode can help solve this problem.

    As an alternative to the 1-pass (-br) and n-pass (-br -npass) bitrate-based modes that we described in our last tutorial you can now enable a preliminary implementation of quality-based rate-control whose goal is to provide a consistent perceived output quality across a wide variety of input material without exceeding data rate constraints for playback devices. By using the new -qf <int> argument you can specify a target quality in the range 0-51, with lower numbers implying a higher target quality, e.g.:

    DivX264 -i "Input.avs" -o "Output.264" -qf 18

    This target quality mode is useful when you want to target a certain output quality from a single encoding pass and you are willing to let the encoder determine the necessary data rate instead of targeting a particular output file size. All other variables held constant, higher quality settings (lower -qf <int> values) will produce larger files and you will need to experiment a little to find the setting that best balances your personal preferences. The target quality mode can be leveraged for compression checks by GUI applications and should produce similar quality to a 2-pass encoding at the same effective rate but in much less time.


  • Sample Aspect Ratio

    Sample aspect ratio (also known as "pixel aspect ratio" in the DivX 6 encoder) is a method of informing the renderer that the pixels in each decoded picture buffer actually represent a sample of the original video whose shape was not necessarily square - i.e. that the renderer may need to rescale the decoded picture to be taller or wider before displaying it. The technique allows devices with constrained buffer shapes to handle pictures that are wider or taller than they would otherwise support. Examples include certain HD cameras as well as common formats such as DVD, where SAR is often used in conjunction with letterboxing or pillarboxing to ensure that videos with a variety of frame shape can be stored in high quality in a fixed-shape frame buffer.

    You can now specify the sample aspect ratio (SAR) of the input video using the -sar argument. In its alpha release the encoder always assumed that pixels were square (1:1 SAR) and thus it was necessary to resize certain source material to ensure this was actually true. Because these adjustments are no longer necessary it's possible to achieve better picture resolution and less pre-processing time in the input pipeline. These pictures demonstrate just one common use case for SAR:



    Widescreen picture formatted for PAL 720x576 16:9 DAR DVD, as encoded.
    (Click to enlarge and read more)



    The same picture after the renderer applies 16:11 SAR during playback.
    (Click to enlarge)


    If your input video does not have 1:1 SAR you need to specify the ratio of width to height of each sample that the renderer should display during playback. Note that the display aspect and sample aspect are two related but different properties. Some frequently encountered sample aspects are shown below:

    SD Format SAR
    PAL 4:3 12:11
    PAL 16:9 16:11
    NTSC 4:3 10:11
    NTSC 16:9 40:33


    The DivX Plus HD profile implements stricter rules for interlaced content to ensure robust playback on a wide variety of devices. When encoding interlaced material using the -tff or -bff arguments 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)


  • Stdin support

    The encoder now accepts raw video input via stdin, which makes it both easier to develop around the encoder and to use a wider variety of tools in the input pipeline for encoding DivX Plus HD content. In our tutorial for the alpha version of the encoder we showed how to use AVISynth to read a source file in an arbitrary format, decode it, and perform some basic manipulations like resizing to a supported resolution and frame rate. These same operations can now be performed using other common video processing toolkits. Let's look at a typical example using FFmpeg.

    FFmpeg's documentation can appear a little daunting at first due to it's extensive functionality, but really it's not much more complex than the command line tools we've already encountered. The command line documentation tells us that the basic syntax looks like this:

    ffmpeg [[infile options][`-i' infile]]... {[outfile options] outfile}...

    We'll use a handful of the available options to input an AVI file, crop and resize it to a supported resolution, and output raw video at a valid frame rate ready to pipe into the DivX Plus HD encoder. Let's assume our input video is 1920x1088 @ 30fps progressive and we want to encode at 720p @ 23.976fps. We can tell FFmpeg to decode our AVI file using -i, crop 8 pixels from the height using -cropbottom, resize to 1280x720 using -s, and convert the frame rate using -r. The first part of the command line might look as follows:

    ffmpeg.exe -i "C:\SomeFolder\MyInput.avi" -cropbottom 8 -s 1280x720 -r 24000/1001

    We also need to use -f and -pix_fmt to tell FFmpeg that we want to output YV12 planar video (the raw format that the DivX Plus HD encoder expects via stdin), and to write those raw frames to stdout, which we will later pipe to the encoder's stdin. To do that we just put a "-" character where we'd normally write the output filename. This makes our complete command-line for FFmpeg look like this:

    ffmpeg.exe -i "C:\SomeFolder\MyInput.avi" -cropbottom 8 -s 1280x720 -r 24000/1001 -f rawvideo -pix_fmt yuv420p -

    Next we ask the DivX Plus HD encoder to read input via the stdin, again using the "-" character where we'd normally write a file name. Because the only data the encoder will see is raw video frames we also have to tell it the resolution and frame rate of the input video on the command line when using the stdin feature. Let's use the new target quality mode (-qf) in conjunction with the stdin feature to create a high quality file in just one pass:

    divx264.exe -i - -y 1280x720 -fps 24000/1001 -qf 18 -o "C:\SomeFolder\MyOutput.264"

    Neither of these commands will work on their own. We must combine them using the pipe character, "|" to pipe FFmpeg's stdout handle to the DivX Plus HD encoder's stdin handle:

    ffmpeg.exe -i "C:\SomeFolder\MyInput.avi" -cropbottom 8 -s 1280x720 -r 24000/1001 -f rawvideo -pix_fmt yuv420p - | divx264.exe -i - -y 1280x720 -fps 24000/1001 -qf 18 -o "C:\SomeFolder\MyOutput.264"

    When we execute this command FFmpeg will decode and transform the input video, and the DivX Plus HD encoder will output an H.264 video stream, all without creating any intermediary files. All that remains is to mux the video stream into an MKV container:

    MKVMerge.exe -o "C:\SomeFolder\MyMKVVideo.mkv" --default-duration 0:1001/24000s "C:\SomeFolder\MyOutput.264"



    Encoding using stdin then creating an MKV file.
    (Click to enlarge)


    Keep in mind that the encoder requires valid input resolution and frame rates as input. We covered these in our last tutorial, but for convenience here's the table once again:

    Rate
    (Numerator)
    Scale
    (Denominator)
    Approximate FPS
    = Rate / Scale
    Max Dimensions Min Dimensions
    60 1 60 1280x720 320x240
    60000 1001 59.940 1280x720 320x240
    50 1 50 1280x720 320x240
    30 1 30 1920x1080 320x240
    30000 1001 29.970 1920x1080 320x240
    25 1 25 1920x1080 320x240
    24 1 24 1920x1080 320x240
    24000 1001 23.976 1920x1080 320x240

    Width and height must each be multiples of 8.
    Width and height are tested independently for minimums and maximums.
    Any alternative rate/scale representations must evaluate to exact equivalents.


  • Input trimming

    A minor new feature is the ability to trim frames from the beginning of the input video using -start. In conjunction with the existing -frames argument it is possible to specify a range of frames to be encoded, which can be useful for conducting short tests as well as removing unwanted sequences from captured material. An example of using both features to encode only frames 1000 through 2999 is as follows:

    divx264.exe -i "MyInput.avs" -o "C:\SomeFolder\MyOutput.264" -qf 18 -start 1000 -frames 2000

    The -start argument currently works only with input from file because seeking is not possible when reading from stdin. When using stdin you should use options in the decoding application in place of -start and -frames, for example FFmpeg's -ss and -t arguments.

  • Ctrl+C, Ctrl+Break supported

    It's now possible to stop the encoder by pressing Ctrl+C or Ctrl+Break while it is running.

Known issues for DivX Plus HD H.264 Encoder Beta 2

The following are known issues in this version:

  • The encoder may run slowly with input that is in RGB colorspace. If you are using an AVISynth script for input add ConvertToYV12() to your script to convert video to YV12 colorspace.

  • The encoder doesn't support input from compressed AVI files. Create an AVISynth script using the AVISource filter to process such files.

  • The encoder will only accept 1:1 SAR for 704x576i and 704x480i input.

Downloading DivX Plus HD H.264 Encoder Beta 2

To download this beta you need to create a free DivX Labs account then join the Project Rémoulade Apps group. Downloads for Project Rémoulade are available at the top of the group homepage for signed-in members.


How you can help us

We want to hear your feedback! Please submit your comments and questions to the DivX Plus forum (requires sign-in).


If your feedback relates to performance issues or software stability, please consider attaching some of the following to your post:

  • Screenshots from CPU-Z that show your CPU, memory and mainboard configuration.

  • Screenshots of any crash dialogs, including the details view if available.

  • An export from MSInfo32, which you can launch by simply typing MSInfo32 into the Run box on your Start menu, so that we can see information about the operating system, running software and application errors.