Differences

This shows you the differences between two versions of the page.

--- tutorial:h264 [2010/04/11 06:53]
j.m x264 is only an encoder
+++ tutorial:h264 [2010/04/16 18:40]
j.m removed
@@ Line 147: / Line 147: @@
   * **Max Consecutive:** This setting controls the //maximum// number of consecutive //B-Frames//. B-Frames refer to both, the previous //and// the following I-Frame (or P-Frame). This way B-Frames can compress even more efficient than P-Frames. B-Frames can significantly improve the visual quality of the video at the same file size. Therefore using B-Frames is highly recommended. Also note that allowing //more// B-Frames will never hurt the quality: You can even //safely// choose the maximum of **16** consecutive B-Frames. That's because you only specify the upper bound for the number of //consecutive// B-Frames. x264 will still decide how many consecutive B-Frames are actually used. So even if you allow up to 16 consecutive B-Frames, the encoder will rarely go that high. Nevertheless limiting the maximum number of B-Frames to //less// than 16 is reasonable, because most videos won't benefit from using more than **~4** consecutive B-Frames anyway! Raising the B-Frame limit higher than that would only slowdown the encoding process for //no// real benefit! If you set the B-Frame limit to **0** (the default), B-Frames will be //disabled//. Of course disabling B-Frames is **not** recommended!
+  * **B-Frame Bias:** This setting controls the probability that a B-Frame is used instead of a P-Frame. The default value is **0**, which also is the recommended setting. A //positive// value increases the probability that a B-Frame is set. In contrast a //negative// value decreases the probability that a B-Frame is set. Of course the encoder will never violate the //Max Consecutive// limit, no matter what //Bias// setting is used.
+  * **Adaptive B-Frame Decision:** This option controls how the encoder chooses the number of consecutive B-Frames. No matter what settings you choose, the encoder will //never// violate the maximum consecutive B-Frame limit (but it may decide to use //fewer// B-Frames). The followiing modes are available:
+    * **Fast:** This mode uses a fast and suboptimal B-Frame decision algorithm. It usually uses a very low number of B-Frames, even with a pretty high B-Frame limit. Use this mode only if you favor speed over quality!
+    * **Optimal:** This mode is also known as "Trellis B-Frame decision", but isn't related to the //Trellis// quantization option at all. It is significant slower than the "Fast" B-Frame decision method, but will find the optimal number of B-Frames and thus is //highly recommended//. Especially fades are handled much better with this method. Since the speed of this method //highly// depends on the B-Frame limit, you should limit the maximum number of consecutive B-Frames to a reasonable value!
+    * **Disabled:** This option will //disable// the adaptive B-Frame decision. Use this for testing only!
+  * **B-Frames as reference:** This feature is often called "B-Pyramid". If you enable this settings, B-Frames are allowed to make references non-linearly in order to improve bitrate usage and quality. This way B-Frames can refer to B-Frames. Usually it's recommended to keep this feature **enabled** as it should improve the result. Nevertheless you have to take into account that this is a "High Profile" feature and thus requires a suitable decoder, like libavcodec (MPlayer, ffdshow, etc.) or CoreAVC. The following modes are available:
+    * **Strict:** Strictly hierarchical B-Pyramid. This mode is fully BluRay compatible.
+    * **Non-Strict:** Normal B-Pyramid mode. Gives better results than the "strict" mode, but it's **not** BluRay compatible (as BluRay has weird specs).
+    * **Disabled:** Don't use B-Frames as references. //Not// recommended.
+===I-Frames===
+  * **Minimum GOP Size:** This setting controls the //minimum// number of frames between two IDR frames. IDR frames are similar to Keyframes in MPEG-4 ASP videos: Playback can only be started at an IDR frame, as no frame //after// the IDR frame will refer to a frame //before// the IDR frame. In H.264 this is //not// possible with "normal" I-Frames, because of the multiple references. So IDR frames are needed to allow seeking in the video. Nevertheless too many IDR frames would cause an inefficient encoding, so there's a //minimum// interval for IDR frames. As a rule of thumb, this value should equal the //framerate// of the video. For example a 25 fps video should use a value of **25**, a 29.97 fps video should use a value of **30** and so on.
+  * **Maximum GOP Size:** In contrast to "Min IDR frame interval" this setting controls the //maximum// number of frames between two IDR frames. A //higher// value will result in a larger IDR frame interval and thus slowdown seeking; a //lower// value will result in a shorter IDR frame interval and thus improve seeking. As a rule of thumb, the IDR frame interval shouldn't be lower than the framerate of the video multiplied with a factor of //10//. For example a 25 fps video should use at least a value of **250**, a 29.97 fps video should use at least a value of **300** and so on. Using even higher values will improve the compression at the cost of some seeking performance. Of course martial with many "long takes" and long "tracking shots" will benefit much more from long GOP's than martial which mainly consists of very short scenes. Please note that long GOP's will hurt error resilience, which may be a problem for steaming media (and also for Blu-Ray authoring)
+  * **Scene Cut Threshold:** This setting controls the threshold for x264' //scene change// detection. This way the encoder can put an I-Frame at every scene change (instead of an P- or B-Frame), which should lead to better looking scene cuts. A //lower// threshold results in a more aggressive scene change detection, which might be useful for very dark videos. In contrast a //higher// threshold will detect less scene changes. The default is **40** and should be suitable for most videos.
+==== Analysis ====
+=== Analysis Configuration ===
+  * **Mixed Refs:** If this setting is enabled, each 16x16 macro block can choose it's own (optimal) reference frame. This will slow down the encoding process, but it allows a more efficient compression. Especially if you use a high number of //reference frames//, this setting will give you great improvement and is worth the additional encoding time. If you use few reference frames, //Mixed Refs// will be less effective. You should keep this setting **enabled**, if visual quality is more important than encoding speed.
+  * **Chroma ME (Motion Estimate):** If this setting is enabled, then the color information (chroma) will be taken into account for motion detection, otherwise it will not. With "Chroma ME" enabled the motion detection will be slower but more accurate. So it will usually produce a //higher// visual quality at the cost of some encoding time. Therefore it's recommended to always keep this setting **enabled**, except encoding speed is more important than visual quality.
+  * **Trellis Quantization:** This setting enables the //Trellis// RD quantization. Basically Trellis will perform an additional quantization step: It will keep certain "details" that would have been removed otherwise. At the same time it will remove certain "details" that would have been kept otherwise. Usually Trellis will //improve// the overall quality in a noticeable way, but it causes a significant //slowdown// of the encoding process. Before the //Psy optimizations// were added to x264, Trellis **2** was said to have a tendency to remove fine details and improve edges. Therefore Trellis **1** often was considered the better choice. But now when using **Psy RDO**, it's highly recommended to use Trellis **2**, although it's significant slower than Trellis **1**. If speed is more important than quality, set Trellis to **0** in order to disable it. Note that **Psy-Trellis** requires //Trellis// quantization, so //Psy-Trellis// will be disabled when Trellis is set to **0**. Also note that //Trellis// requires //CABAC//. The following modes are available:
+    * **2: Always On** (Slow, best quality)
+    * **1: Final Makroblock only** (Faster, medium quality)
+    * **0: Disabled** (Fastest, worst quality)
+  * **Fast P-Skip:** If this setting is //checked//, then "Fast P-Skip" will be used. Fast P-Skip is an optimization that will speedup the encoding process at the cost of some visual quality. Nevertheless the quality loss caused by Fast P-Skip usually is //negligible// while the speedup is distinct. Therefore it's recommended to keep //Fast P-Skip// checked. Unfortunately in rare cases Fast P-Skip causes artifacts in "flat" scenes, so you might want to uncheck //Fast P-Skip// in case visual quality is more important than encoding speed.
+  * **DCT Decimate:** If this setting is checked, then //DCT Decimation// will be used. This feature allows x264 to discard "unnecessary" DCT blocks. Those DCT blocks won't be written to the bitstream, which saves some bitrate and improves encoding efficiency. Of course there will be a subtle loss in quality, but usually the effect is negligible. Since DCT Decimation leads to significant //smaller// files in Quantizer-based modes (QP or CRF) it's recommended to keep this setting //enabled//. You should //not// disable the //DCT Decimation//, unless you have a very good reason to do so. Rumors say that //DCT Decimation// shouldn't be use together with **Trellis** quantization, but this has been refuted!
+  * **Noise Reduction:** This setting controls x264' internal denoise filter. Please note that denoising is //not// part of the H.264 specifications! So this has be considered an additional //pre-prcoessing// feature. The default value is **0**, which will completely turn //off// the denoise filter in x264. There is no need to change this setting, except you explicitly want to apply additional denoising to your video //before// encoding. Usually good values for noise reduction are //no// higher than **1000**. Nevertheless you will usually be better off with a good "stand-alone" denoise filter like [[Video_filter_FluxSmooth|FluxSmooth]] or [[Video_filter_MPlayer_denoise3d|MPlayer's denoise3d]]. If you use one of those, please make sure x264' noise reduction is //off//!
+=== Psycho-visually optimized RDO & Trellis ===
+The human eye doesn't just want the image to look similar to the original, it wants the image to have similar //complexity//. Therefore, we would rather see a somewhat distorted but still detailed block than a non-distorted but completely blurred block. The result is a bias towards a detailed and/or grainy output image, a bit like xvid except that its actual detail rather than ugly blocking (see [[http://x264dev.multimedia.cx/?p=164]] and [[http://forum.doom9.org/showpost.php?p=1144270&postcount=1]] for more info). The purpose of **Psy RDO** is to keep the complexity of an encoded block similar to the complexity of the original block. This way //Psy RDO// produces an image that looks much sharper and more detailed in many cases (compared to //none// Psy RDO). It also helps to preserve film grain greatly! Please note that Psy RDO will inherently //hurt// metrics, such as PSNR and SSIM. As soon as psycho-visual optimizations are involved, the classical metrics become useless! Also note that Psy RDO will work with //RDO// modes only: If //Partition Decision// is set to **6** (or higher), then Psy RDO will be on by default, otherwise it will be disabled. In addition to //Psy RDO// there also is **Psy-Trellis** now. This is still considered an "experimental" feature and //disable// by default, but it seems to help greatly for retaining textures in the video. Note that Psy Trellis is based on //Trellis// quantization. Consequently it will only be effective with Trellis quantization enabled too (Trellis **1** is sufficient now, but **2** will be more effective).
+  * **Psy RDO Strength:** This setting controls the strength of //Psy RDO//. Note that the latest //Psy RDO// patch will automatically scale the strength of Psy RDO, based on the quantizer of the frame! Therefore the "strength" stetting is simply an additional factor, which will be multiplied to the //internal// scaling factor. The default value for //Psy RDO Strength// is **1.0**, which should be sufficient for "Film" material. Using even higher values may introduce artifacts! Furthermore it is recommended to //lower// Psy-RDO to a value of **0.4** for "Animation" material. This does //not// mean that Psy-RDO is generally harmful for "Animation" material, you just needs to //lower// the strength for such material.
+  * **Psy Trellis Strength:** This setting controls the strength of //Psy Trellis//. The default value is **0.0** currently, so Psy Trellis will be //disabled// by default. Anyway, it //may// be beneficial to use Psy Trellis for encoding "Film" material. But be careful! Tests have shown that a value of **1.0** usually is too strong for Psy Trellis. For most sources a value of **0.15** should be sufficient. Even higher values may introduce artifacts! Also using Psy-Trellis for "Animation" footage is not recommended.
+  * **Note:** At the moment //Psy Trellis Strength// isn't available in Avidemux. The default strength of **0.0** will be used. Patched builds of libx264 may behave differently though.
+=== Luma Quantization Deadzones ===
+  * **Intra Luma Quantization Deadzone**
+    * [TO-DO] If you know what information to put here, please contact us!
+  * **Inter Luma Quantization Deadzone**
+    * [TO-DO] If you know what information to put here, please contact us!
+=== Quantization Matrix ===
+  * **Flat Matrix:** The quantization is the //lossy// part of video compression: The coefficients will be divided through the //quantization matrix// and then rounded off. The "Flat Matrix" is the default quantization matrix of the H.264 specifications - all entries are simply filled with 16's. This matrix is known to give //pretty good// results for a wide range of videos and bitrates. This means //subjective// quality as well as PSNR values.
+  * **JVT Matrix:** This is the alternative quantization matrix of the H.264 specifications. Tests have shown that the "JVT Matrix" performs //poorly//, although it's part of the official specifications. Therefore it's highly recommended to **not** use this matrix, except for testing and comparison! You will be far better off with the "Flat Matrix" in almost any case.
+  * **Custom Matrix:** This setting allows you to load your //own// quantization matrices. Creating quantization matrices as a complex task an needs a //deep// understand of how video compression works in detail. So creating new quantization matrices should be reserved to the H.264 gurus. Nevertheless you can find a list of suitable matrices at [[http://forum.doom9.org/showthread.php?p=887125#post887125|this]] and [[http://forum.doom9.org/showthread.php?p=677092#post677092|this]] location. Please note that your "Deblocking Filter" settings have a huge impact on how good/bad a certain quantization matrix performs! Also most custom matrices are targeting a certain bitrate range (e.g. ultra high or ultra low bitrates) and will perform //bad// outside this range. Last but not least you should //not// use any custom matrices, except you know what you are doing. In most cases you will get satisfactory results simply by sticking with the "Flat Matrix" (default).
+  * **Remarks:** Now that x264 contains various //psycho-visual optimizations// (Adaptive Quantization, Psy-RDO, Psy-Trellis) custom quantization matrices have become obsolete! Most of the things that people tried to achieve with custom matrices, such as  detail and grain retention, can now be achieved by Psy optimizations in a more sophisticated way. Furthermore the Psy optimizations are tuned for the default //flat// matrix. So using "extreme" custom matrices may result in undesired effects when Psy optimizations are involved! Therefore we highly recommend to stick with the "flat" matrix, unless you have a very good reason to use a custom matrix.
+==== Quantizer ====
+=== Quantizer Control ===
+  * **Minimum Quantizer:** Specifies the //minimum// quantizer to be enforced. This means //every// frame will get //at least// this amount of data loss. The default value is **10**, which makes sure no bitrate is wasted on too low quantizers. This value should be okay, even for high quality videos.
+  * **Maximum Quantizer**: Specifies the //maximum// quantizer to be allowed. This means //none// of the Frames will get a higher amount of data loss than this. The default value is **51**, which is the maximum quantizer possible. So "Max Qp" is //not// limited by default. Of course the encoder will only go that high when it's really necessary, so don't worry!
+  * **Maximum Quantizer Step:** Specifies how much the quantizer can change between two consecutive frames. The default value is **4**. This makes sure that two consecutive frames won't get //too// different quantizers. If you allow significant greater QP Steps, this might result in visible quality "jumps" between frames, so don't do that.
+  * **Average Bitrate Tollerance:** This setting effects the "Single Pass" bitrate-based mode only. It controls how //precise// the encoder will hit the target bitrate (or target file size). The goal of "Bitrate Variance" is to get as close as possible to the quality of an CRF mode encode, while still being somewhere near the target file size. A value of **0.0** would restrict the encoder to //exactly// hit the desired bitrate. The default value of **1.0** allows an discrepancy of //1%//, which is still pretty restrictive but already a lot better than pure CBR. Please note that the discrepancy usually should be within a range of //30%//. Furthermore CRF mode still gives much better results than the bitrate-based mode and therefore is the recommended method!
+  * **Factor between I- and P-Frame Quants:** This setting controls how much //stronger// P-Frames will be compressed compared to I-Frames. A value of **1.0** would assign the //same// quantizers to P-Frames and I-Frames, while the default value of **1.4** assigns //40%// higher quantizers to P-Frames (compared to I-Frames). This equals the "I-Frame Boost" option of Xvid. Compressing P-Frames stronger than I-Frames is recommended, as I-Frames serve as the initial reference of a scene and thus have a huge impact on the quality of the following frames. Therefore you should //not// change the default value, unless you have a very good reason to do so!
+  * **Factor between P- and B-Frame Quants:** This setting controls how much //stronger// B-Frames will be compressed compared to P-Frames. A value of **1.0** would assign the //same// quantizers to B-Frames and P-Frames, while the default value of **1.3** assigns a //30%// higher quantizer the B-Frames (compared to P-Frames). Compressing B-Frames stronger than P-Frames is recommended, as B-Frames are //not// referenced by other frames (except for the B-Pyramid), while P-Frames server as reference for the following frames. Therefore you should //not// change the default value, unless you have a very good reason to do so!
+  * **Chroma to Luma Quantizer Offset:** This setting controls how much //stronger// the color information (chroma) will be compressed compared to the brightness information (luma). Sometimes it's makes sens to compress the color information stronger than the brightness information, as data loss in the color information is //less// visible to the human eye than data loss in the brightness information. The specified offset will be //added// to the chroma quantizers. It can be configured between **-12** and **+12**. The default value is **0** and usually it's recommended to keep the default value! Note that both, //Psy-RDO// and //Psy-Trellis//, will lower the offset by one or by two, if enabled. So you may end up with an offset of **-4** by using Psy optimizations.
+=== Quantizer Curve Compression ===
+  * **Quantizer Curve Compression (%):** This setting is also called "qcomp" or "bitrate variability" (**not** to be confused with //bitrate variance//). It controls how much the bitrate can fluctuate over the entire video. Setting this to **0%** would enforce a //constant bitrate// stream, while a value of **100%** would result in a //constant quantizer// stream. The default value is **60%**, which gives good results for most videos. So do **not** change the default, unless you have a very good reason to do so! Note that //adaptive quantization// (AQ) partially replaces the effect of //qcomp// and x264 will internally raise qcomp to compensate based on the adaptive quantization strength. Also note that using //CRF// mode together with a //qcomp// of 100% is technically equivalent to //QP// mode, except that CRF mode still is able to use AQ (which QP mode can't do). Hence the more you raise //qcomp//, the closer //CRF// mode gets to a //QP// encode.
+  * **Reduce Fluctuation Before Curve Compression:** This setting will apply a temporal Gaussian blur to the quantizer curve //before// the "Quantizer Compression" step. This is done in order to flatten unwanted quantizer fluctuations, which should make the visual quality more stable, especially in Anime content. The default value is **20.0** and usually doesn't need to be changed.
+  * **Reduce Fluctuation After Curve Compression:** This setting will apply a temporal Gaussian blur to the quantizer curve //after// the "Quantizer Compression" step.  This is done in order to //further// flatten unwanted quantizer fluctuations. The default value is **0.5** and usually doesn't need to be changed.
+  * **Remarks:** Further information on how x264' rate control works in detail can be found at [[http://git.videolan.org/gitweb.cgi?p=x264.git;a=blob;f=doc/ratecontrol.txt|this]] location.
+=== Adaptive Quantization ===
+//Adaptive Quantization (AQ)// allows each macroblock within the frame to choose a //different// quantizer, instead of assigning the //same// quantizer to //all// blocks within the frame. The purpose of AQ is moving more bits into "flat" macroblocks. This is done by adaptively lowering the quantizers of certain blocks (and raising the quantizers of other blocks). Without AQ, flat and dark areas of the image tend to show ugly blocking or banding. Thanks to the new AQ algorithm, blocking and banding can be greatly reduced! With AQ enabled, you can expect a significant(!) gain in overall image quality. Especially in dark scenes and scenes with "flat" backgrounds (sky, grass, walls, etc.) much more details can be preserved. Nevertheless AQ seems to perform less efficient with "Animation" material than it does with "Film" material, but still helps to prevent banding. Note that AQ can be used with the bitrate-base modes (//Single-Pass// and //Two-Pass//) as well as with the //CRF// mode. It can **not** be used with the //QP// mode! That's because QP mode uses constant quantizers per definition, which is one of the reasons why QP mode generally should be avoided nowadays.
+  * **AQ Strength:** This setting controls the amount of AQ that is applied to the frames. The default //AQ Strength// is **1.0** now, so AQ will be //enabled// by default. The default value should be well-balanced and give good AQ results for most sources. If you think your video requires stronger AQ, then you can raise the //AQ Strength//. A value of **1.5** is considered "strong" AQ. If you think the AQ effect is too strong, you can lower the //AQ Strength//. A value of **0.5** is considered "low" AQ. While sticking with an AQ value of **1.0** is recommended for "Film" material, it should be lowed to **0.6** for "Anmiation" material.
+  * **AQ Mode:** This setting chooses the AQ algorithm. The following modes are currently available:
+    * **Variance AQ:** The default AQ algorithm. Recommended.
+    * **Auto-Variance AQ:** New //experimental// AQ algorithm that tries to adapt the AQ strength per frame (now improved for //MB-Tree//).
+    * **Disabled:** Don't use AQ at all. //Not// recommended.
+  * **Example:** [[http://i18.tinypic.com/82u8c9j.gif|x264 with VAQ -vs- No AQ]] (animated GIF image)
+==== Advanced ====
+=== Video Buffer Verifier ===
+VBV (Video Buffering Verifier) defines a specific buffering model. In that model the decoder (player) reads the input data from a buffer. That buffer has a limited size. Also the buffer is filled at a limited data rate. VBV makes sure that the buffer will //never// run out of data, i.e. it makes sure that there is always enough data left in the buffer to decode the next frame. Therefore VBV forces additional bitrate and buffering constraints on the encoder. It's highly recommended to **not** use VBV, unless you can't get around it. VBV //may// hurt the video quality, but it never will improve the quality! Unfortunately hardware players (including mobile devices) may need VBV for proper playback. You will have to look up the particular VBV requirements for each device individually. In particular BluRay has strict VBV requirements. Note that x264's VBV implementation now works just fine with both, 1-Pass and 2-Pass modes. There's no need to use 2-Pass mode for VBV anymore. (See [[http://en.wikipedia.org/wiki/Video_buffering_verifier]] for details about VBV)
+  * **Maximum VBV Bitrate**: Specifies the maximum bitrate (in kbit/s) at which data enters the buffer. This equals the bandwidth of the network (for streaming media) or the maximum disc read speed (for local playback). Note that this setting does //not// restrict the maximum (local) video bitrate. The (local) video bitrate is allowed to exceed the //maximum VBV bitrate// as long as there's enough data left in the buffer. A value of **0** indicates that VBV is //not// used (Default).
+  * **Maximum Buffer Size**: Specifies the buffer size of the device/player (in kilobit). This is the maximum amount of data that can be hold inside the buffer. Usually this is pre-defined by the individual device/player you are encoding for. A value of **0** indicates that VBV is //not// used (Default).
+  * **Initial VBV Buffer Occupancy**: Specifies the filling level of the device buffer at the start of playback. **90%** is the default.
+  * **Note:** VBV cannot be used without specifying both, the Maximum VBV Bitrate //and// the VBV Buffer Size. Specifying only one of them (while the other one is **0**) does nothing!
+=== Slicing ===
+H.264 allows to segment each frame into several parts. These parts are called "slices". The advantage of using multiple slices (per frame) is that the slices can be processed independently and in parallel. This allows easy multi-threading implementations in H.264 encoders and decoders. Unfortunately using multiple slices hurts compression efficiency! The more slices are used the worse! Therefore you should **not** use slices, if you don't have to. But if your H.264 decoder uses //slice-based// multi-threading (i.e. multiple slices are decoded in parallel), then multi-threading will only be used, if the video was encoded with multiple slices. Fortunately most software decoders do //not// require slices, because they use //frame-based// multi-threading (i.e. multiple frames are decoded in parallel). Hardware decoders may require slices though. In particular the BluRay specs say that at least **4** slices must be used.
+  * **Maximum Size per Slice**: Specifies the maximum size per slice (in byte). x264 will use as many slices as required to comply with that restriction. A value if **0** means that multiple-slices are //not// used.
+  * **Maximum Size per Slice**: Specifies the maximum number of macroblocks per slice. x264 will use as many slices as required to comply with that restriction. A value if **0** means that multiple-slices are //not// used.
+  * **Slices per Frame:** Specifies the number of slices per frame. A value if **0** means that multiple-slices are //not// used.
+  * **Note:** x264 does //not// require multiple slices to take advantage of multiple processor cores. Since r607 x264 uses //frame-based// multi-threading.
+=== Zones ===
+  * **Add**: Add a new zone to the list.
+  * **Edit**: Edit an existing zone.
+  * **Add**: Remove a zone from the list.
+Zones can be used to //manually// assign a lower or higher bitrate to a certain section of the video (e.g. enforce a lower bitrate for the ending credits). There are two modes to control the bitrate of a zone: Using a "Bitrate Factor" you can change the bitrate //relative// to the encoders decision and using a "Quantizer" you can overwrite the encoders decision with a //constant// quantizer value.
+==== Output ====
+=== Output Settings ===
+  * **IDC Level:**
+    * By default x264 will detect the [[H264#H.264.2FAVC_Profiles_and_Levels|Level]] of the resulting H.264 stream based on the encoder settings you have chosen (and based on the properties of your video). //This// option can be used to overwrite x264 decision. Be aware that x264 will **not** enforce the selected Level for you! You only specify what Level will be signaled in the header of your H.264 stream. But this does **not** mean that your stream actually complies to that level! Hence you can easily produce an //invalid// stream by specifying an improper level. Therefore it's //highly// commended to keep the //IDC Level// setting on **Auto** and let x264 detect the proper Level. If you want your H.264 stream to comply to a specific H.264 Level, then you //must// choose your encoder settings accordingly. Also you must make sure that your video's resolution and framerate don't exceed the Level's limits. In short: Don't change //this// option, unless you have a very good reason to do so!
+  * **Sequence Parameter Set Identifier:**
+  * [TO-DO] If you know what information to put here, please contact us!
+  * **Enforce Repeatability:**
+  * [TO-DO] If you know what information to put here, please contact us!
+  * **Use Access Unit Delimiters:**
+  * [TO-DO] If you know what information to put here, please contact us!
+=== Pixel Aspect Ratio ===
+This setting defines the "Pixel Aspect Ratio" (PAR) of the video. Do **not** change the default value of **1:1** (aka "Square Pixels"), unless you are encoding [[http://en.wikipedia.org/wiki/Anamorphic_widescreen|anamorphic]] video! In case you are encoding anamorphic material //and// you want to keep it anamorphic, then you will have to set the correct PAR value. Otherwise your video would be displayed with wrong //aspect ratio//! If you have an //anamorphic// source and you want to convert it to "Square Pixels" (PAR = 1:1), then you must invoke the [[Video_filter_Resize|Resize]] filter and resize the video accordingly. Note that "Pixel Aspect Ratio" is **not** equal to "Display Aspect Ratio" (DAR). Anyway, the DAR can be calculated from the PAR using this formula: DAR = Width/Height * PAR. For example: 720/576 * 64/45 = 16/9. The advantage of working with PAR values is that the PAR of a video won't change when cropping the video, while the DAR most likely //will// change. The following PAR options are available:
+    * **Custom:** Enter a user-defined PAR value
+    * **Predefined Aspect Ratio:** Choose one of the most common PAR values from the list
+    * **As Input:** Keep the PAR of the source video
+=== Video Usability Information ===
+These settings are only suggestions for the playback equipment. Use them at your own risk!
+  * **Overscan**
+  * **Video Format**
+  * **Color Primaries**
+  * **Transfer Characteristics**
+  * **Color Matrix**
+  * **Chroma Sample Location**
+  * **Full Range Samples**
+===== Unavailable x264 options in Avidemux =====
+  * **AQ Mode** - currently Avidemux sticks with //AQ mode// **1**, mode **2** isn't available yet.
+  * **Sub-ME 10** - currently the highest //Sub-Me// mode available in Avidemux is **9**, mode **10** (aka "QPRD") is not available yet.
+  * **Psy-Trellis** - currently Psy-Trellis will be //disabled// in Avidemux (Psy-RDO //is// available though!)
+  * **Progressive Intra Refresh**
+  * [[http://en.wikipedia.org/wiki/PSNR|PSNR]] and [[http://en.wikipedia.org/wiki/SSIM|SSIM]] calculations
+==== Obsolete x264 options ====
+  * **B-RDO:** RD based mode decision for B-Frames. This option has been removed in r996. It's now enabled implicitly at //Sub ME 7// or higher.
+  * **Pre-Scenecut:** Since r1117 x264 will //always// use Pre-Scenecut, because it's generally better than regular scenecut in terms of accuracy and regular scenecut didn't work in threaded mode anyways.
+  * **Bidirectional ME:** Jointly optimize both motion vectors in B-Frames. This option has been removed in r996. It's now enabled implicitly at //Sub ME 5// or higher.
+  * **AQ Sensitivity:** This option //never// existed in official x264. It was used only in experimental //Adaptive Quantization// patches. Current AQ doesn't use it.
+===== H.264/AVC Profiles and Levels =====
+The H.264/AVC specifications define a number of different **profiles**. Each profile specifies which //features// of H.264 are allowed (or not allowed). If you want your H.264 video stream to be compliant to a certain profile, then you may only enabled features allowed in //this// profile. Profiles are needed to make sure your video file will play fine on a certain decoder. For example a "Main" profile compliant video will play 100% fine on //every// "Main" profile capable decoder/player. When working with the **x264** encoder, there are basically two profiles you have to take care of: the "Main" profile and the "High" profile. Nevertheless x264 is //missing// the Error Resilience feature from the "Baseline Profile" as well as the Interlacing Support from "Extended  Profile". If you want to play your video on //software// players, then you don't need to care about profiles that much. The H.264 decoder from "libavcodec", which is used in MPlayer, VLC Player, ffdshow and many more, supports all of x264' features, including the "High" and "Predictive Lossless" profile features. Same for proprietary decoders, such as CoreAVC. Nevertheless if you are targeting a //hardware// player, then profiles are very important, as hardware players are very //restrictive// on what profile they support.
+In addition to the //profiles//, the H.264/AVC specifications also define a number of **levels**. While //profiles// define which compression features of H.264 may (or may not) be used, the //levels// put further restrictions on other properties of the video. These restrictions include the maximum resolution, the maximum bitrate, the maximum framerate (for a given resolution) and the maximum number of reference frames (indirectly limited though MaxDPB). In order play your H.264 video on a specific //hardware// player, that player must not only support your videos //profile//, but also your video's //level// (or a higher one). Again //software// players usually don't have such restrictions, as long as you CPU is powerful enough.
+**Note:** The common notation for Profiles and Levels is "Profile@Level", for example //High@4.1//. Furthermore there is //no// way to directly encode your video to a specific level and/or profile. If you want your video to comply to a certain profile/level, you must choose the encoder settings accordingly. Presets may be helpful to find the correct settings. Anyway, it may still be necessary to resize your video and/or change the framerate.
+==== List of all H.264/AVC Profiles ====
+^                                    ^Baseline  ^Extended  ^Main  ^High  ^High 10  ^High 4:2:2  ^High 4:4:4 Predictive  ^
+|I and P Slices                      |YES       |YES       |YES   |YES   |YES      |YES         |YES                    |
+|B Slices                            |NO        |YES       |YES   |YES   |YES      |YES         |YES                    |
+|SI and SP Slices                    |NO        |YES       |NO    |NO    |NO       |NO          |NO                     |
+|Multiple Reference Frames           |YES       |YES       |YES   |YES   |YES      |YES         |YES                    |
+|In-Loop Deblocking Filter           |YES       |YES       |YES   |YES   |YES      |YES         |YES                    |
+|CAVLC Entropy Coding                |YES       |YES       |YES   |YES   |YES      |YES         |YES                    |
+|CABAC Entropy Coding                |NO        |NO        |YES   |YES   |YES      |YES         |YES                    |
+|Flexible Macroblock Ordering (FMO)  |YES       |YES       |NO    |NO    |NO       |NO          |NO                     |
+|Arbitrary Slice Ordering (ASO)      |YES       |YES       |NO    |NO    |NO       |NO          |NO                     |
+|Redundant Slices (RS)               |YES       |YES       |NO    |NO    |NO       |NO          |NO                     |
+|Data Partitioning                   |NO        |YES       |NO    |NO    |NO       |NO          |NO                     |
+|Interlaced Coding (PicAFF, MBAFF)   |NO        |YES       |YES   |YES   |YES      |YES         |YES                    |
+|4:2:0 Chroma Format                 |YES       |YES       |YES   |YES   |YES      |YES         |YES                    |
+|Monochrome Video Format (4:0:0)     |NO        |NO        |NO    |YES   |YES      |YES         |YES                    |
+|4:2:2 Chroma Format                 |NO        |NO        |NO    |NO    |NO       |YES         |YES                    |
+|4:4:4 Chroma Format                 |NO        |NO        |NO    |NO    |NO       |NO          |YES                    |
+|8 Bit Sample Depth                  |YES       |YES       |YES   |YES   |YES      |YES         |YES                    |
+|9 and 10 Bit Sample Depth           |NO        |NO        |NO    |NO    |YES      |YES         |YES                    |
+|11 to 14 Bit Sample Depth           |NO        |NO        |NO    |NO    |NO       |NO          |YES                    |
+|8x8 vs. 4x4 Transform Adaptivity    |NO        |NO        |NO    |YES   |YES      |YES         |YES                    |
+|Quantization Scaling Matrices       |NO        |NO        |NO    |YES   |YES      |YES         |YES                    |
+|Separate Cb and Cr QP control       |NO        |NO        |NO    |YES   |YES      |YES         |YES                    |
+|Separate Color Plane Coding         |NO        |NO        |NO    |NO    |NO       |NO          |YES                    |
+|Predictive Lossless Coding          |NO        |NO        |NO    |NO    |NO       |NO          |YES                    |
+^                                    ^Baseline  ^Extended  ^Main  ^High  ^High 10  ^High 4:2:2  ^High 4:4:4 Predictive  ^
+From Wikipedia, the free encyclopedia
+==== List of all H.264/AVC Levels ====
+^Level number ^Max macroblocks per second ^Max frame size (macroblocks) ^Max video bit rate (VCL) for Baseline, Extended and Main Profiles ^Max video bit rate (VCL) for High Profile ^Max video bit rate (VCL) for High 10 Profile ^Max video bit rate (VCL) for High 4:2:2 and High 4:4:4 Predictive Profiles ^Examples for high resolution @ frame rate (max stored frames) in Level ^
+|1 |1485 |99 |64(nbsp)kbit/s |80(nbsp)kbit/s |192(nbsp)kbit/s |256(nbsp)kbit/s |128x96@30.9(nbsp)(8) 176x144@15.0(nbsp)(4) |
+|1b |1485 |99 |128(nbsp)kbit/s |160(nbsp)kbit/s |384(nbsp)kbit/s |512(nbsp)kbit/s |128x96@30.9(nbsp)(8) 176x144@15.0(nbsp)(4) |
+|1.1 |3000 |396 |192(nbsp)kbit/s |240(nbsp)kbit/s |576(nbsp)kbit/s |768(nbsp)kbit/s |176x144@30.3(nbsp)(9) 320x240@10.0(nbsp)(3) 352x288@7.5(nbsp)(2) |
+|1.2 |6000 |396 |384(nbsp)kbit/s |480(nbsp)kbit/s |1152(nbsp)kbit/s |1536(nbsp)kbit/s |320x240@20.0(nbsp)(7) 352x288@15.2(nbsp)(6) |
+|1.3 |11880 |396 |768(nbsp)kbit/s |960(nbsp)kbit/s |2304(nbsp)kbit/s |3072(nbsp)kbit/s |320x240@36.0(nbsp)(7) 352x288@30.0(nbsp)(6) |
+|2 |11880 |396 |2(nbsp)Mbit/s |2.5(nbsp)Mbit/s |6(nbsp)Mbit/s |8(nbsp)Mbit/s |320x240@36.0(nbsp)(7) 352x288@30.0(nbsp)(6) |
+|2.1 |19800 |792 |4(nbsp)Mbit/s |5(nbsp)Mbit/s |12(nbsp)Mbit/s |16(nbsp)Mbit/s |352x480@30.0(nbsp)(7) 352x576@25.0(nbsp)(6) |
+|2.2 |20250 |1620 |4(nbsp)Mbit/s |5(nbsp)Mbit/s |12(nbsp)Mbit/s |16(nbsp)Mbit/s |352x480@30.7(nbsp)(10) 352x576@25.6(nbsp)(7) 720x480@15.0(nbsp)(6) 720x576@12.5(nbsp)(5)|
+|3 |40500 |1620 |10(nbsp)Mbit/s |12.5(nbsp)Mbit/s |30(nbsp)Mbit/s |40(nbsp)Mbit/s |352x480@61.4(nbsp)(12) 352x576@51.1(nbsp)(10) 720x480@30.0(nbsp)(6) 720x576@25.0(nbsp)(5) |
+|3.1 |108000 |3600 |14(nbsp)Mbit/s |14(nbsp)Mbit/s |42(nbsp)Mbit/s |56(nbsp)Mbit/s |720x480@80.0(nbsp)(13) 720x576@66.7(nbsp)(11) 1280x720@30.0(nbsp)(5) |
+|3.2 |216000 |5120 |20(nbsp)Mbit/s |25(nbsp)Mbit/s |60(nbsp)Mbit/s |80(nbsp)Mbit/s |1280x720@60.0(nbsp)(5) 1280x1024@42.2(nbsp)(4) |
+|4 |245760 |8192 |20(nbsp)Mbit/s |25(nbsp)Mbit/s |60(nbsp)Mbit/s |80(nbsp)Mbit/s |1280x720@68.3(nbsp)(9) 1920x1080@30.1(nbsp)(4) 2048x1024@30.0(nbsp)(4) |
+|4.1 |245760 |8192 |50(nbsp)Mbit/s |62.5(nbsp)Mbit/s |150(nbsp)Mbit/s |200(nbsp)Mbit/s |1280x720@68.3(nbsp)(9) 1920x1080@30.1(nbsp)(4) 2048x1024@30.0(nbsp)(4) |
+|4.2 |522240 |8704 |50(nbsp)Mbit/s |62.5(nbsp)Mbit/s |150(nbsp)Mbit/s |200(nbsp)Mbit/s |1920x1080@64.0(nbsp)(4) 2048x1080@60.0(nbsp)(4) |
+|5 |589824 |22080 |135(nbsp)Mbit/s |168.75(nbsp)Mbit/s |405(nbsp)Mbit/s |540(nbsp)Mbit/s |1920x1080@72.3 (13) 2048x1024@72.0 (13) 2048x1080@67.8 (12) 2560x1920@30.7 (5) 3680x1536@26.7(nbsp)(5) |
+|5.1 |983040 |36864 |240(nbsp)Mbit/s |300(nbsp)Mbit/s |720(nbsp)Mbit/s |960(nbsp)Mbit/s |1920x1080@120.5 (16) 4096x2048@30.0 (5) 4096x2304@26.7 (5) |
+^Level number ^Max macroblocks per second ^Max frame size (macroblocks) ^Max video bit rate (VCL) for Baseline, Extended and Main Profiles ^Max video bit rate (VCL) for High Profile ^Max video bit rate (VCL) for High 10 Profile ^Max video bit rate (VCL) for High 4:2:2 and High 4:4:4 Predictive Profiles ^Examples for high resolution @ frame rate (max stored frames) in Level ^
+From Wikipedia, the free encyclopedia
+For more detailed information, please refer to "Annex A" in the official ITU-T H.264 specifications!
+===== GPU support =====
+Since [[http://de.wikipedia.org/wiki/GPGPU|GPGPU]] has become a hot topic, people began asking for GPU support in Avidemux. These people need to understand that Avidemux cannot offer GPU support for H.264 encoding, until GPU support is implemented in the //x264// library. There is a project scheduled to add [[http://de.wikipedia.org/wiki/CUDA|CUDA]] support to x264 (see [[http://wiki.videolan.org/SoC_x264_2009#GPU_Motion_Estimation]]), but there are no results yet (May 2009). We know that there are //commercial// H.264 encoders with GPU support available already. But if you look at these encoders closely, you will notice that their speed-up claims are marketing blabber. These encoders may be fast, but their quality isn't anywhere near x264's quality! Also note that marketing people tend to compare their encoders to the completely unoptimized //H.264 Reference Encoder//. x264 is faster than the reference encoder by several orders of magnitude, which renders these speed comparisons meaningless. x264 can run extremely fast on a CPU and scales up to at least 16 cores. So don't believe everything that marketing people claim!
+===== IDR-frames =====
+IDR frames are: An IDR frame is what has been traditionally known as an I frame. An IDR frame, just like an I frame in MPEG-1/2 and MPEG-4 ASP, starts with a clean slate, and all subsequent frames will make reference to the IDR frame and subsequent frames. Non IDR I frames should be rare, but since they cannot be ruled out, enforcing a minimal IDR interval can help improve compression in some high motion scenes. In H.264/AVC you can also have I frames inside a GOP, which are not seekable, since the long time references introduced in H.264/AVC could result in a P frame after the I frame to reference a P frame before the I frame.
+Max IDR-keyframe interval indicates the maximum distance between two IDR frames. Similarly, Min IDR-keyframe interval indicates the minimum distance between two IDR frames.
+===== List of References =====
+  * [[http://www.neuron2.net/library/avc/T-REC-H%5b1%5d.264-200711-I!!PDF-E.pdf|Official ITU-T H.264 Specifications]] - provided by Neuron2
+  * [[http://akuvian.org/src/x264/overview_x264_v8_5.pdf|x264 - A high performance H.264/AVC encoder]] - by Loren Merritt and Rahul Vanam
+  * [[http://forum.doom9.org/forumdisplay.php?f=77|H.264/AVC Thread on Doom9's Forum]] - especially posts by //akupenguin//, //Dark Shikari// and //*.mp4 guy//
+  * [[http://git.videolan.org/gitweb.cgi?p=x264.git;a=blob;f=doc/ratecontrol.txt|A qualitative overview of x264's ratecontrol methods]] - by Loren Merritt
+  * [[http://git.videolan.org/gitweb.cgi?p=x264.git;a=blob;f=doc/threads.txt|The x264 multi-threading threading method]] - by Loren Merritt
+  * [[http://sites.google.com/site/linuxencoding/x264-ffmpeg-mapping|x264 ffmpeg mapping and options guide]]
+  * [[http://en.wikipedia.org/wiki/X264|Wikipedia, the free encyclopedia]] - article about the "x264" encoder ([[http://de.wikipedia.org/wiki/X264|German version]])
+  * [[http://gabextreme.googlepages.com/x264vfwunited|DeathTheSheep's AVC VfW Guide]]
+  * [[http://mewiki.project357.com/wiki/X264_Settings|MeWiki - x264 settings]]
+  * [[http://www.flaskmpeg.info/board/thread.php?threadid=5571|Selur's man x264 (Hilfe zum x264 CLI)]] - German documentation
+  * [[http://www.digital-digest.com/articles/x264_options_page1.html|Digital Digest - x264 Options Explained]]
+===== See also =====
+  * [[Compiling H.264]]

Avidemux

User Tools

Site Tools

Differences

Page Tools