win/C#/Controls/x264Panel.resx

   1 <?xml version="1.0" encoding="utf-8"?>\r
   2 <root>\r
   3   <!-- \r
   4     Microsoft ResX Schema \r
   5     \r
   6     Version 2.0\r
   7     \r
   8     The primary goals of this format is to allow a simple XML format \r
   9     that is mostly human readable. The generation and parsing of the \r
  10     various data types are done through the TypeConverter classes \r
  11     associated with the data types.\r
  12     \r
  13     Example:\r
  14     \r
  15     ... ado.net/XML headers & schema ...\r
  16     <resheader name="resmimetype">text/microsoft-resx</resheader>\r
  17     <resheader name="version">2.0</resheader>\r
  18     <resheader name="reader">System.Resources.ResXResourceReader, System.Windows.Forms, ...</resheader>\r
  19     <resheader name="writer">System.Resources.ResXResourceWriter, System.Windows.Forms, ...</resheader>\r
  20     <data name="Name1"><value>this is my long string</value><comment>this is a comment</comment></data>\r
  21     <data name="Color1" type="System.Drawing.Color, System.Drawing">Blue</data>\r
  22     <data name="Bitmap1" mimetype="application/x-microsoft.net.object.binary.base64">\r
  23         <value>[base64 mime encoded serialized .NET Framework object]</value>\r
  24     </data>\r
  25     <data name="Icon1" type="System.Drawing.Icon, System.Drawing" mimetype="application/x-microsoft.net.object.bytearray.base64">\r
  26         <value>[base64 mime encoded string representing a byte array form of the .NET Framework object]</value>\r
  27         <comment>This is a comment</comment>\r
  28     </data>\r
  29                 \r
  30     There are any number of "resheader" rows that contain simple \r
  31     name/value pairs.\r
  32     \r
  33     Each data row contains a name, and value. The row also contains a \r
  34     type or mimetype. Type corresponds to a .NET class that support \r
  35     text/value conversion through the TypeConverter architecture. \r
  36     Classes that don't support this are serialized and stored with the \r
  37     mimetype set.\r
  38     \r
  39     The mimetype is used for serialized objects, and tells the \r
  40     ResXResourceReader how to depersist the object. This is currently not \r
  41     extensible. For a given mimetype the value must be set accordingly:\r
  42     \r
  43     Note - application/x-microsoft.net.object.binary.base64 is the format \r
  44     that the ResXResourceWriter will generate, however the reader can \r
  45     read any of the formats listed below.\r
  46     \r
  47     mimetype: application/x-microsoft.net.object.binary.base64\r
  48     value   : The object must be serialized with \r
  49             : System.Runtime.Serialization.Formatters.Binary.BinaryFormatter\r
  50             : and then encoded with base64 encoding.\r
  51     \r
  52     mimetype: application/x-microsoft.net.object.soap.base64\r
  53     value   : The object must be serialized with \r
  54             : System.Runtime.Serialization.Formatters.Soap.SoapFormatter\r
  55             : and then encoded with base64 encoding.\r
  56 \r
  57     mimetype: application/x-microsoft.net.object.bytearray.base64\r
  58     value   : The object must be serialized into a byte array \r
  59             : using a System.ComponentModel.TypeConverter\r
  60             : and then encoded with base64 encoding.\r
  61     -->\r
  62   <xsd:schema id="root" xmlns="" xmlns:xsd="http://www.w3.org/2001/XMLSchema" xmlns:msdata="urn:schemas-microsoft-com:xml-msdata">\r
  63     <xsd:import namespace="http://www.w3.org/XML/1998/namespace" />\r
  64     <xsd:element name="root" msdata:IsDataSet="true">\r
  65       <xsd:complexType>\r
  66         <xsd:choice maxOccurs="unbounded">\r
  67           <xsd:element name="metadata">\r
  68             <xsd:complexType>\r
  69               <xsd:sequence>\r
  70                 <xsd:element name="value" type="xsd:string" minOccurs="0" />\r
  71               </xsd:sequence>\r
  72               <xsd:attribute name="name" use="required" type="xsd:string" />\r
  73               <xsd:attribute name="type" type="xsd:string" />\r
  74               <xsd:attribute name="mimetype" type="xsd:string" />\r
  75               <xsd:attribute ref="xml:space" />\r
  76             </xsd:complexType>\r
  77           </xsd:element>\r
  78           <xsd:element name="assembly">\r
  79             <xsd:complexType>\r
  80               <xsd:attribute name="alias" type="xsd:string" />\r
  81               <xsd:attribute name="name" type="xsd:string" />\r
  82             </xsd:complexType>\r
  83           </xsd:element>\r
  84           <xsd:element name="data">\r
  85             <xsd:complexType>\r
  86               <xsd:sequence>\r
  87                 <xsd:element name="value" type="xsd:string" minOccurs="0" msdata:Ordinal="1" />\r
  88                 <xsd:element name="comment" type="xsd:string" minOccurs="0" msdata:Ordinal="2" />\r
  89               </xsd:sequence>\r
  90               <xsd:attribute name="name" type="xsd:string" use="required" msdata:Ordinal="1" />\r
  91               <xsd:attribute name="type" type="xsd:string" msdata:Ordinal="3" />\r
  92               <xsd:attribute name="mimetype" type="xsd:string" msdata:Ordinal="4" />\r
  93               <xsd:attribute ref="xml:space" />\r
  94             </xsd:complexType>\r
  95           </xsd:element>\r
  96           <xsd:element name="resheader">\r
  97             <xsd:complexType>\r
  98               <xsd:sequence>\r
  99                 <xsd:element name="value" type="xsd:string" minOccurs="0" msdata:Ordinal="1" />\r
 100               </xsd:sequence>\r
 101               <xsd:attribute name="name" type="xsd:string" use="required" />\r
 102             </xsd:complexType>\r
 103           </xsd:element>\r
 104         </xsd:choice>\r
 105       </xsd:complexType>\r
 106     </xsd:element>\r
 107   </xsd:schema>\r
 108   <resheader name="resmimetype">\r
 109     <value>text/microsoft-resx</value>\r
 110   </resheader>\r
 111   <resheader name="version">\r
 112     <value>2.0</value>\r
 113   </resheader>\r
 114   <resheader name="reader">\r
 115     <value>System.Resources.ResXResourceReader, System.Windows.Forms, Version=2.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089</value>\r
 116   </resheader>\r
 117   <resheader name="writer">\r
 118     <value>System.Resources.ResXResourceWriter, System.Windows.Forms, Version=2.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089</value>\r
 119   </resheader>\r
 120   <metadata name="ToolTip.TrayLocation" type="System.Drawing.Point, System.Drawing, Version=2.0.0.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a">\r
 121     <value>17, 17</value>\r
 122   </metadata>\r
 123   <data name="slider_psyrd.ToolTip" xml:space="preserve">\r
 124     <value>Psychovisual Rate Distortion Optimization sure is a mouthful, isn't it? Basically, it means x264 tries to retain detail, for better quality to the human eye, \r
 125 as opposed to trying to maximize quality the way a computer understands it, through signal-to-noise ratios that have trouble telling apart fine detail and noise.</value>\r
 126   </data>\r
 127   <data name="drop_adaptBFrames.ToolTip" xml:space="preserve">\r
 128     <value>x264 has a variety of algorithms to decide when to use B-frames and how many to use.\r
 129 \r
 130 Fast mode takes roughly the same amount of time no matter how many B-frames you specify.  However, while fast, its decisions are often suboptimal.\r
 131 \r
 132 Optimal mode gets slower as the maximum number of B-Frames increases, but makes much more accurate decisions, especially when used with B-pyramid.</value>\r
 133   </data>\r
 134   <data name="check_Cabac.ToolTip" xml:space="preserve">\r
 135     <value>After the encoder has done its work, it has a bunch of data that needs to be compressed losslessly, similar to ZIP or RAR.  \r
 136 H.264 provides two options for this: CAVLC and CABAC.  CABAC decodes a lot slower but compresses significantly better (10-30%), especially at lower bitrates.  \r
 137 If you're looking to minimize CPU requirements for video playback, disable this option.\r
 138 Baseline profile, as required for iPods and similar devices, requires CABAC to be disabled.</value>\r
 139   </data>\r
 140   <data name="check_noDCTDecimate.ToolTip" xml:space="preserve">\r
 141     <value>x264 normally zeroes out nearly-empty data blocks to save bits to be better used for some other purpose in the video.  \r
 142 However, this can sometimes have slight negative effects on retention of subtle grain and dither.  \r
 143 Don't touch this unless you're having banding issues or other such cases where you are having trouble keeping fine noise.</value>\r
 144   </data>\r
 145   <data name="drop_trellis.ToolTip" xml:space="preserve">\r
 146     <value>Trellis fine-tunes the rounding of transform coefficients to squeeze out 3-5% more compression at the cost of some speed. \r
 147 \"Always\" uses trellis not only during the main encoding process, but also during analysis, \r
 148 which improves compression even more, albeit at great speed cost.  \r
 149 \r
 150 Trellis costs more speed at higher bitrates and requires CABAC.</value>\r
 151   </data>\r
 152   <data name="drop_deblockBeta.ToolTip" xml:space="preserve">\r
 153     <value>H.264 has a built-in deblocking filter that smooths out blocking artifacts after decoding each frame.  This not only improves visual quality, but also helps compression significantly. \r
 154 The deblocking filter takes a lot of CPU power, so if you're looking to minimize CPU requirements for video playback, disable it.\r
 155 \r
 156 The deblocking filter has two adjustable parameters, \"strength\" and \"threshold\". \r
 157 The former controls how strong (or weak) the deblocker is, while the latter controls how many (or few)  edges it applies to. \r
 158 Lower values mean less deblocking, higher values mean more deblocking. The default is 0 (normal strength) for both parameters.</value>\r
 159   </data>\r
 160   <data name="drop_deblockAlpha.ToolTip" xml:space="preserve">\r
 161     <value>H.264 has a built-in deblocking filter that smooths out blocking artifacts after decoding each frame.  This not only improves visual quality, but also helps compression significantly. \r
 162 The deblocking filter takes a lot of CPU power, so if you're looking to minimize CPU requirements for video playback, disable it.\r
 163 \r
 164 The deblocking filter has two adjustable parameters, \"strength\" and \"threshold\". \r
 165 The former controls how strong (or weak) the deblocker is, while the latter controls how many (or few)  edges it applies to. \r
 166 Lower values mean less deblocking, higher values mean more deblocking. The default is 0 (normal strength) for both parameters.</value>\r
 167   </data>\r
 168   <data name="check_8x8DCT.ToolTip" xml:space="preserve">\r
 169     <value>The 8x8 transform is the single most useful feature of x264 in terms of compression-per-speed.  \r
 170 It improves compression by at least 5% at a very small speed cost and may provide an unusually high visual quality benefit compared to its compression gain.  \r
 171 However, it requires High Profile, which many devices may not support.</value>\r
 172   </data>\r
 173   <data name="drop_analysis.ToolTip" xml:space="preserve">\r
 174     <value>Mode decision picks from a variety of options to make its decision: this option chooses what options those are.  \r
 175 Fewer partitions to check means faster encoding, at the cost of worse decisions, since the best option might have been one that was turned off.</value>\r
 176   </data>\r
 177   <data name="drop_subpixelMotionEstimation.ToolTip" xml:space="preserve">\r
 178     <value>This setting controls both subpixel-precision motion estimation and mode decision methods.\r
 179 \r
 180 Subpixel motion estimation is used for refining motion estimates beyond mere pixel accuracy, improving compression.\r
 181 \r
 182 Mode decision is the method used to choose how to encode each block of the frame: a very important decision.\r
 183 \r
 184 SAD is the fastest method, followed by SATD, RD, RD refinement, and the slowest, QPRD.\r
 185 6 or higher is strongly recommended: Psy-RD, a very powerful psy optimization that helps retain detail, requires RD.\r
 186 10, the most powerful and slowest option, requires trellis=2.</value>\r
 187   </data>\r
 188   <data name="drop_MotionEstimationRange.ToolTip" xml:space="preserve">\r
 189     <value>This is the distance x264 searches from its best guess at the motion of a block in order to try to find its actual motion.  \r
 190 Doesn't apply to Diamond or Hexagon search options.  \r
 191 The default is fine for most content, but extremely high motion video, especially at HD resolutions, may benefit from higher ranges, albeit at a high speed cost.</value>\r
 192   </data>\r
 193   <data name="drop_MotionEstimationMethod.ToolTip" xml:space="preserve">\r
 194     <value>Controls the motion estimation method. Motion estimation is how the encoder estimates how each block of pixels in a frame has moved.  \r
 195 A better motion search method improves compression at the cost of speed.\r
 196 \r
 197 Diamond: performs an extremely fast and simple search using a diamond pattern.\r
 198 \r
 199 Hexagon: performs a somewhat more effective but slightly slower search using a hexagon pattern.\r
 200 \r
 201 Uneven Multi-Hex: performs a very wide search using a variety of patterns, more accurately capturing complex motion.\r
 202 \r
 203 Exhaustive: performs a \"dumb\" search of every pixel in a wide area.  Significantly slower for only a small compression gain.\r
 204 \r
 205 Transformed Exhaustive: Like exhaustive, but makes even more accurate decisions. Accordingly, somewhat slower, also for only a small improvement.</value>\r
 206   </data>\r
 207   <data name="drop_directPrediction.ToolTip" xml:space="preserve">\r
 208     <value>H.264 allows for two different prediction modes, spatial and temporal, in B-frames.\r
 209 \r
 210 Spatial, the default, is almost always better, but temporal is sometimes useful too.\r
 211 \r
 212 x264 can, at the cost of a small amount of speed (and accordingly for a small compression gain), adaptively select which is better for each particular frame.</value>\r
 213   </data>\r
 214   <data name="drop_bFrames.ToolTip" xml:space="preserve">\r
 215     <value>Sane values are ~2-5.  \r
 216 This specifies the maximum number of sequential B-frames that the encoder can use. \r
 217  Large numbers generally won't help significantly unless Adaptive B-frames is set to Optimal.  \r
 218 Cel-animated source material and B-pyramid also significantly increase the usefulness of larger values. \r
 219 Baseline profile, as required for iPods and similar devices, requires B-frames to be set to 0 (off).</value>\r
 220   </data>\r
 221   <data name="drop_refFrames.ToolTip" xml:space="preserve">\r
 222     <value>Sane values are ~1-6.  \r
 223 The more you add, the better the compression, but the slower the encode.  \r
 224 Cel animation tends to benefit from more reference frames a lot more than film content. \r
 225 Note that many hardware devices have limitations on the number of supported reference frames, so if you're encoding for a handheld or standalone player, \r
 226 don't touch this unless you're absolutely sure you know what you're doing!</value>\r
 227   </data>\r
 228   <data name="check_weightp.ToolTip" xml:space="preserve">\r
 229     <value>Performs extra analysis to decide upon weighting parameters for each frame.  \r
 230 This improves overall compression slightly and improves the quality of fades greatly. \r
 231 Baseline profile, as required for iPods and similar devices, requires weighted P-frame prediction to be disabled.  \r
 232 Note that some devices and players, even those that support Main Profile, \r
 233 may have problems with Weighted P-frame prediction: the Apple TV is completely incompatible with it, for example.</value>\r
 234   </data>\r
 235   <data name="slider_adaptiveQuantStrength.ToolTip" xml:space="preserve">\r
 236     <value>Psychovisual Rate Distortion Optimization sure is a mouthful, isn't it? Basically, it means x264 tries to retain detail, for better quality to the human eye, \r
 237 as opposed to trying to maximize quality the way a computer understands it, through signal-to-noise ratios that have trouble telling apart fine detail and noise.</value>\r
 238   </data>\r
 239   <data name="combo_pyrmidalBFrames.ToolTip" xml:space="preserve">\r
 240     <value>This is the distance x264 searches from its best guess at the motion of a block in order to try to find its actual motion.  \r
 241 Doesn't apply to Diamond or Hexagon search options.  \r
 242 The default is fine for most content, but extremely high motion video, especially at HD resolutions, \r
 243 may benefit from higher ranges, albeit at a high speed cost.</value>\r
 244   </data>\r
 245 </root>