User Tools

Site Tools


tutorial:h.264

Differences

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

Link to this comparison view

Both sides previous revision Previous revision
Next revision
Previous revision
tutorial:h.264 [2010/04/17 07:21]
j.m
tutorial:h.264 [2012/11/11 08:51] (current)
Line 5: Line 5:
 ===== Overview ===== ===== Overview =====
  
-**H.264**, which is also known as "​MPEG-4 Part-10" or "​MPEG-4 Advanced Video Coding"​ (AVC), is a digital video compression standard, which is noted for achieving very high data compression. While H.264 generally requires more [[enw:CPU|CPU]] power for playback than video encoded with the older MPEG-4(nbsp)Part(nbsp)2 standard (as used by [[general:​Xvid]] or DivX), the compression efficiency is much better! That means: With H.264/AVC you can get a significantly better quality at the same file size -or- you can get the same quality at a significantly smaller file size (compared to MPEG-4(nbsp)ASP). While H.264 compresses much more efficient than MPEG-4(nbsp)Part(nbsp)2,​ the advantage over MPEG-2 is even greater.+**H.264**, which is also known as "​MPEG-4 Part 10" or "​MPEG-4 Advanced Video Coding"​ (AVC), is a digital video compression standard, which is noted for achieving very high data compression. While H.264 generally requires more CPU power for playback than video encoded with the older MPEG-4(nbsp)Part(nbsp)2 standard (as used by [[general:​Xvid]] or DivX), the compression efficiency is much better! That means: With H.264/AVC you can get a significantly better quality at the same file size -or- you can get the same quality at a significantly smaller file size (compared to MPEG-4(nbsp)ASP). While H.264 compresses much more efficient than MPEG-4(nbsp)Part(nbsp)2,​ the advantage over MPEG-2 is even greater.
  
 More detailed information about H.264 can be found in the corresponding [[http://​en.wikipedia.org/​wiki/​H.264/​MPEG-4_AVC|Wikipedia article]]. A comparison of various H.264 encoders against MPEG-4 Part-2, MPEG-2 and other video formats can be found at [[http://​mirror05.x264.nl/​Dark/​website/​compare.html]]. More detailed information about H.264 can be found in the corresponding [[http://​en.wikipedia.org/​wiki/​H.264/​MPEG-4_AVC|Wikipedia article]]. A comparison of various H.264 encoders against MPEG-4 Part-2, MPEG-2 and other video formats can be found at [[http://​mirror05.x264.nl/​Dark/​website/​compare.html]].
Line 15: Line 15:
 ==== Get x264 for Avidemux ==== ==== Get x264 for Avidemux ====
  
-If x264 is not available in your version of Avidemux, there is a guide on how to download and compile x264 by yourself. It is in the [[Compile|H.264]] section. ​+If x264 is not available in your version of Avidemux, there is a guide on how to download and compile x264 by yourself. It is in the [[build:​Compiling x264]] section. ​
  
-After you compile x264, you will have to re-compile Avidemux to build in the x264 feature. There is also a guide on how to do this in the [[Compile SVN|Install -> Compile ​Avidemux ​from SVN (Subversion)]] section.+After you compile x264, you will have to re-compile Avidemux to build in the x264 feature. There is also a guide on how to do this in the [[build:​Compiling ​Avidemux]] section.
  
-Note that if you are using the pre-compiled Avidemux builds for //Microsoft Windows//, the required x264 library ships with the installer. Hence //**no**// additional software is required! Stuff like "Codec Packs",​ "VFW Codecs"​ or "​DirectShow Filters"​ will **not** work with Avidemux! Anyway, the latest builds of the x264 library for Avidemux can be found in [[http://​avidemux.org/​admForum/​viewtopic.php?​id=5615|this]] thread (make sure you navigate to the very //last// post!). These builds usually are newer and less tested ​than the ones that ships with Avidemux.+Note that if you are using the pre-compiled Avidemux builds for //Microsoft Windows//, the required x264 library ships with the installer. Hence //**no**// additional software is required! Stuff like "Codec Packs",​ "VFW Codecs"​ or "​DirectShow Filters"​ will **not** work with Avidemux! Anyway, the latest builds of the x264 library for Avidemux can be found in the [[http://​avidemux.org/​admForum/​viewtopic.php?​id=5615|libx264 GIT builds]] thread (make sure you navigate to the very //last// post!). These builds usually are newer – and less tested ​– than the ones that ships with Avidemux.
  
 ===== x264 options available in Avidemux ===== ===== x264 options available in Avidemux =====
  
 Avidemux contains most of the options available in the **x264** library. For options //not// yet available, see the "​Unavailable"​ section in this article. Avidemux contains most of the options available in the **x264** library. For options //not// yet available, see the "​Unavailable"​ section in this article.
- 
-[[Image:​x264.png]] 
  
 ==== General ==== ==== General ====
Line 47: Line 45:
 === Macroblock-Tree Rate Control === === Macroblock-Tree Rate Control ===
  
-  * The setting enables //​Macroblock-Tree Rate Control// (aka "​MB-Tree"​). It tracks the propagation of information from future blocks to past blocks across motion vectors. It could be described as localizing qcomp (quantizer curve compression) to act on individual blocks instead of whole scenes. Thus instead of lowering quality in high-complexity scenes (like x264 does //without// MB-Tree), it'll only lower quality on the complex part of the scene, while for example a static background will remain high-quality. It also has many other more subtle effects, some potentially negative, most probably not. This helps at all bitrates, but can even help at phenomenally low bitrates where the video would otherwise fall apart completely. Note that MB-Tree now handles fades much better thanks to //​Weight-P//​. Since //MB-Tree// greatly improves the overall quality, it should //always// be enabled. See [[http://​forum.doom9.org/​showthread.php?​t=148686|this]] thread for more information on how MB-Tree works.+  * The setting enables //​Macroblock-Tree Rate Control// (aka "​MB-Tree"​). It tracks the propagation of information from future blocks to past blocks across motion vectors. It could be described as localizing qcomp (quantizer curve compression) to act on individual blocks instead of whole scenes. Thus instead of lowering quality in high-complexity scenes (like x264 does //without// MB-Tree), it'll only lower quality on the complex part of the scene, while for example a static background will remain high-quality. It also has many other more subtle effects, some potentially negative, most probably not. This helps at all bitrates, but can even help at phenomenally low bitrates where the video would otherwise fall apart completely. Note that MB-Tree now handles fades much better thanks to //​Weight-P//​. Since //MB-Tree// greatly improves the overall quality, it should //always// be enabled. See the [[http://​forum.doom9.org/​showthread.php?​t=148686|x264 "​Macroblock Tree Ratecontrol"​ testing]] thread for more information on how MB-Tree works.
     * **Frametype Lookahead:​** This settings specifies the number of frames for frame-type lookahead, i.e. the distance (in frames) //MB-Tree// looks into the future. The more frames MB-Tree uses for lookahead, the more efficiently it works. Or in other words: A //higher// value will improve the result, while a //lower// value will hurt the result. Therefore you should use the highest value you can afford. Unfortunately a larger lookahead will slow down the encoding speed and increase memory usage at the same time. The default value is **40**, which should be well-balanced for most purposes. If quality is more important than encoding speed, you should increase the value. However going higher than **60** is //not// recommended,​ because even higher values will only give a very minor additional improvement (if at all). If speed is more important the quality, you may lower the value. But going lower than **30** is //not// recommended.     * **Frametype Lookahead:​** This settings specifies the number of frames for frame-type lookahead, i.e. the distance (in frames) //MB-Tree// looks into the future. The more frames MB-Tree uses for lookahead, the more efficiently it works. Or in other words: A //higher// value will improve the result, while a //lower// value will hurt the result. Therefore you should use the highest value you can afford. Unfortunately a larger lookahead will slow down the encoding speed and increase memory usage at the same time. The default value is **40**, which should be well-balanced for most purposes. If quality is more important than encoding speed, you should increase the value. However going higher than **60** is //not// recommended,​ because even higher values will only give a very minor additional improvement (if at all). If speed is more important the quality, you may lower the value. But going lower than **30** is //not// recommended.
     * **Warning:​** If you encounter crashes with high //Frametype Lookahead// values, then this is probably because you ran out of memory! In that case you must lower the value in order to avoid the crash.     * **Warning:​** If you encounter crashes with high //Frametype Lookahead// values, then this is probably because you ran out of memory! In that case you must lower the value in order to avoid the crash.
Line 53: Line 51:
 === Multi-Threading === === Multi-Threading ===
  
-  * This setting controls how many threads x264 will use for encoding. Thanks to its multi-threading implementation,​ x264 is able to fully utilize the processing power of modern multi-core processors. This is achieved by encoding several frames in parallel (see [[http://​git.videolan.org/​gitweb.cgi?​p=x264.git;​a=blob;​f=doc/​threads.txt]] for details). Tests have shown that x264 scales extremely well up to at least [[http://​avidemux.org/​admWiki/​images/​8/​84/​X264_16_cores.png|16 cores]]. Anyway, to make optimal usage of your multi-core machine, the correct number of threads must be selected. The following options are available:+  * This setting controls how many threads x264 will use for encoding. Thanks to its multi-threading implementation,​ x264 is able to fully utilize the processing power of modern multi-core processors. This is achieved by encoding several frames in parallel (see [[http://​git.videolan.org/​gitweb.cgi?​p=x264.git;​a=blob;​f=doc/​threads.txt]] for details). Tests have shown that x264 scales extremely well up to at least 16 cores. Anyway, to make optimal usage of your multi-core machine, the correct number of threads must be selected. The following options are available:
     * **Disabled:​** Disables multi-threading. One single thread will be used. This makes //no// difference for single-core machines, but will //​significantly//​ slow down x264 on multi-core machines.     * **Disabled:​** Disables multi-threading. One single thread will be used. This makes //no// difference for single-core machines, but will //​significantly//​ slow down x264 on multi-core machines.
     * **Auto-Detect:​** Let x264 decide the optimal number of threads. The formula used is: threads = cpu_cores * 3/2. Tests have shown that this formula (usually) gives the optimal performance. It's highly recommended to keep this setting!     * **Auto-Detect:​** Let x264 decide the optimal number of threads. The formula used is: threads = cpu_cores * 3/2. Tests have shown that this formula (usually) gives the optimal performance. It's highly recommended to keep this setting!
Line 112: Line 110:
     * **Smart Mode:** Fade detection. Provides full quality improvement in fades. Especially useful with //​MB-Tree//​. This is the recommended mode!     * **Smart Mode:** Fade detection. Provides full quality improvement in fades. Especially useful with //​MB-Tree//​. This is the recommended mode!
     * **Disabled:​** Don't use Weight-P at all. //Not// recommended.     * **Disabled:​** Don't use Weight-P at all. //Not// recommended.
-    * **Warning:​** Some H.264 decoders are known to be broken with respect to Weight-P. See [[http://​x264dev.multimedia.cx/?​p=212|this]] post for a list of broken decoders. With Weight-P enabled you will get //​distorted//​ output, if you use one of the broken decoders! Most notably CoreAVC Decoder 1.9.x has a well-known Weight-P bug that won't be fixed. Either update to CoreAVC 2.0, use a different decoder (e.g. ffdshow or DivX H.264 decoder) or //disable// Weight-P. The last solution is the worst, of course.+    * **Warning:​** Some H.264 decoders are known to be broken with respect to Weight-P. See the [[http://​x264dev.multimedia.cx/?​p=212|spec-violation hall of shame]] post for a list of broken decoders. With Weight-P enabled you will get //​distorted//​ output, if you use one of the broken decoders! Most notably CoreAVC Decoder 1.9.x has a well-known Weight-P bug that won't be fixed. Either update to CoreAVC 2.0, use a different decoder (e.g. ffdshow or DivX H.264 decoder) or //disable// Weight-P. The last solution is the worst, of course.
  
 ==== Partition ==== ==== Partition ====
Line 133: Line 131:
     * **Remarks:​** Note that CABAC requires at least a "​Main"​ Profile capable H.264 decoder. If you are targeting for the "​Baseline"​ or "​Extended"​ Profile, then CAVLC must be used!     * **Remarks:​** Note that CABAC requires at least a "​Main"​ Profile capable H.264 decoder. If you are targeting for the "​Baseline"​ or "​Extended"​ Profile, then CAVLC must be used!
  
-  * **Pure Interlaced Mode:** This settings enables interlaced encoding, so enable this setting //only// if you video is [[http://​100fps.com/​|interlaced]]. In case your video is //​progressive//​ (that is: non-interlaced) or if you don't know what "​interlaced"​ means, keep away from this setting! Be aware that encoding an //​interlaced//​ video as //​progressive//​ will destroy the content! At the same time encoding a //​progressive//​ as //​interlace//​ is feasible, but significantly hurts encoding efficiency! Last but not least note that x264's implementation of //​interlaced//​ encoding is not as efficient as it could be. Hence if you are dealing with an //​interlaced//​ source, you are far better off using a [[Video_filters#​Interlacing|deinterlace]] filter and encode the video as //​progressive//​. +  * **Pure Interlaced Mode:** This settings enables interlaced encoding, so enable this setting //only// if you video is [[http://​100fps.com/​|interlaced]]. In case your video is //​progressive//​ (that is: non-interlaced) or if you don't know what "​interlaced"​ means, keep away from this setting! Be aware that encoding an //​interlaced//​ video as //​progressive//​ will destroy the content! At the same time encoding a //​progressive//​ as //​interlace//​ is feasible, but significantly hurts encoding efficiency! Last but not least note that x264's implementation of //​interlaced//​ encoding is not as efficient as it could be. Hence if you are dealing with an //​interlaced//​ source, you are far better off using a [[using:Video_filters#​Interlacing|deinterlace]] filter and encode the video as //​progressive//​. 
-    * **Remarks:​** Now that CRT screens are dying out and LCD/Plasma screens are dominating the world, //​interlaced//​ content needs to be deinterlaced at playback-time anyway. Unfortunately some screens use pretty poor deinterlaces,​ resulting in a jittery/​unsharp image. Therefore the preferred way is to deinterlace //before// encoding the video, using a high quality deinterlacer/​bobber,​ such as [[Video_filter_Yadif|Yadif]] or [[Video_filter_TDeint|TDeint]].+    * **Remarks:​** Now that CRT screens are dying out and LCD/Plasma screens are dominating the world, //​interlaced//​ content needs to be deinterlaced at playback-time anyway. Unfortunately some screens use pretty poor deinterlaces,​ resulting in a jittery/​unsharp image. Therefore the preferred way is to deinterlace //before// encoding the video, using a high quality deinterlacer/​bobber,​ such as [[using:Video filter Yadif|Yadif]] or [[using:Video filter TDeint|TDeint]].
  
   * **Loop Filter:** This setting controls one of x264' most important features: the **Inloop Deblocking** filter. In contrast to MPEG-4 ASP (DivX, Xvid, etc.) the Inloop Deblocking is a //​mandatory//​ feature of the H.264 standard. So the encoder, x264 in this case, can rely on the //decoder// to perform a proper deblocking. Furthermore all P- and B-Frames in H.264 streams refer to the //​deblocked//​ frames instead of the unprocessed ones, which improves the compressibility. There is absolutely **no** reason the completely disable the Inloop Deblocking, so it's highly recommended to keep it **enabled** in all cases. There are two settings available to configure the Inloop Deblocking filter:   * **Loop Filter:** This setting controls one of x264' most important features: the **Inloop Deblocking** filter. In contrast to MPEG-4 ASP (DivX, Xvid, etc.) the Inloop Deblocking is a //​mandatory//​ feature of the H.264 standard. So the encoder, x264 in this case, can rely on the //decoder// to perform a proper deblocking. Furthermore all P- and B-Frames in H.264 streams refer to the //​deblocked//​ frames instead of the unprocessed ones, which improves the compressibility. There is absolutely **no** reason the completely disable the Inloop Deblocking, so it's highly recommended to keep it **enabled** in all cases. There are two settings available to configure the Inloop Deblocking filter:
Line 185: Line 183:
   * **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!   * **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//!+  * **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 [[using:Video filter FluxSmooth|FluxSmooth]] or [[using: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 === === Psycho-visually optimized RDO & Trellis ===
Line 267: Line 265:
 === Slicing === === 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.+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 Blu-ray ​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 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.   * **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.
Line 288: Line 286:
  
   * **IDC Level:**   * **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!+    * By default x264 will detect the [[H.264#H.264/AVC 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:​**   * **Sequence Parameter Set Identifier:​**
Line 301: Line 299:
 === Pixel Aspect Ratio === === 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:+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 [[using: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     * **Custom:** Enter a user-defined PAR value
     * **Predefined Aspect Ratio:** Choose one of the most common PAR values from the list     * **Predefined Aspect Ratio:** Choose one of the most common PAR values from the list
Line 324: Line 322:
   * **Psy-Trellis** - currently Psy-Trellis will be //​disabled//​ in Avidemux (Psy-RDO //is// available though!)   * **Psy-Trellis** - currently Psy-Trellis will be //​disabled//​ in Avidemux (Psy-RDO //is// available though!)
   * **Progressive Intra Refresh**   * **Progressive Intra Refresh**
-  * [[http://​en.wikipedia.org/​wiki/​PSNR|PSNR]] and [[http://​en.wikipedia.org/​wiki/​SSIM|SSIM]] calculations+  * [[http://​en.wikipedia.org/​wiki/​Peak_signal-to-noise_ratio|PSNR]] and [[http://​en.wikipedia.org/​wiki/​Structural_similarity|SSIM]] calculations
  
 ==== Obsolete x264 options ==== ==== Obsolete x264 options ====
Line 399: Line 397:
 ===== GPU support ===== ===== 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!+Since [[http://en.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://en.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 =====
Line 423: Line 421:
 ===== See also ===== ===== See also =====
  
-  * [[Compiling ​H.264]]+  * [[build:Compiling ​x264]]
  
tutorial/h.264.1271481673.txt.gz · Last modified: 2012/11/11 08:51 (external edit)