diff options
Diffstat (limited to 'win/CS/Controls/x264Panel.resx')
| -rw-r--r-- | win/CS/Controls/x264Panel.resx | 241 |
1 files changed, 241 insertions, 0 deletions
diff --git a/win/CS/Controls/x264Panel.resx b/win/CS/Controls/x264Panel.resx new file mode 100644 index 000000000..094e31ae0 --- /dev/null +++ b/win/CS/Controls/x264Panel.resx @@ -0,0 +1,241 @@ +<?xml version="1.0" encoding="utf-8"?>
+<root>
+ <!--
+ Microsoft ResX Schema
+
+ Version 2.0
+
+ The primary goals of this format is to allow a simple XML format
+ that is mostly human readable. The generation and parsing of the
+ various data types are done through the TypeConverter classes
+ associated with the data types.
+
+ Example:
+
+ ... ado.net/XML headers & schema ...
+ <resheader name="resmimetype">text/microsoft-resx</resheader>
+ <resheader name="version">2.0</resheader>
+ <resheader name="reader">System.Resources.ResXResourceReader, System.Windows.Forms, ...</resheader>
+ <resheader name="writer">System.Resources.ResXResourceWriter, System.Windows.Forms, ...</resheader>
+ <data name="Name1"><value>this is my long string</value><comment>this is a comment</comment></data>
+ <data name="Color1" type="System.Drawing.Color, System.Drawing">Blue</data>
+ <data name="Bitmap1" mimetype="application/x-microsoft.net.object.binary.base64">
+ <value>[base64 mime encoded serialized .NET Framework object]</value>
+ </data>
+ <data name="Icon1" type="System.Drawing.Icon, System.Drawing" mimetype="application/x-microsoft.net.object.bytearray.base64">
+ <value>[base64 mime encoded string representing a byte array form of the .NET Framework object]</value>
+ <comment>This is a comment</comment>
+ </data>
+
+ There are any number of "resheader" rows that contain simple
+ name/value pairs.
+
+ Each data row contains a name, and value. The row also contains a
+ type or mimetype. Type corresponds to a .NET class that support
+ text/value conversion through the TypeConverter architecture.
+ Classes that don't support this are serialized and stored with the
+ mimetype set.
+
+ The mimetype is used for serialized objects, and tells the
+ ResXResourceReader how to depersist the object. This is currently not
+ extensible. For a given mimetype the value must be set accordingly:
+
+ Note - application/x-microsoft.net.object.binary.base64 is the format
+ that the ResXResourceWriter will generate, however the reader can
+ read any of the formats listed below.
+
+ mimetype: application/x-microsoft.net.object.binary.base64
+ value : The object must be serialized with
+ : System.Runtime.Serialization.Formatters.Binary.BinaryFormatter
+ : and then encoded with base64 encoding.
+
+ mimetype: application/x-microsoft.net.object.soap.base64
+ value : The object must be serialized with
+ : System.Runtime.Serialization.Formatters.Soap.SoapFormatter
+ : and then encoded with base64 encoding.
+
+ mimetype: application/x-microsoft.net.object.bytearray.base64
+ value : The object must be serialized into a byte array
+ : using a System.ComponentModel.TypeConverter
+ : and then encoded with base64 encoding.
+ -->
+ <xsd:schema id="root" xmlns="" xmlns:xsd="http://www.w3.org/2001/XMLSchema" xmlns:msdata="urn:schemas-microsoft-com:xml-msdata">
+ <xsd:import namespace="http://www.w3.org/XML/1998/namespace" />
+ <xsd:element name="root" msdata:IsDataSet="true">
+ <xsd:complexType>
+ <xsd:choice maxOccurs="unbounded">
+ <xsd:element name="metadata">
+ <xsd:complexType>
+ <xsd:sequence>
+ <xsd:element name="value" type="xsd:string" minOccurs="0" />
+ </xsd:sequence>
+ <xsd:attribute name="name" use="required" type="xsd:string" />
+ <xsd:attribute name="type" type="xsd:string" />
+ <xsd:attribute name="mimetype" type="xsd:string" />
+ <xsd:attribute ref="xml:space" />
+ </xsd:complexType>
+ </xsd:element>
+ <xsd:element name="assembly">
+ <xsd:complexType>
+ <xsd:attribute name="alias" type="xsd:string" />
+ <xsd:attribute name="name" type="xsd:string" />
+ </xsd:complexType>
+ </xsd:element>
+ <xsd:element name="data">
+ <xsd:complexType>
+ <xsd:sequence>
+ <xsd:element name="value" type="xsd:string" minOccurs="0" msdata:Ordinal="1" />
+ <xsd:element name="comment" type="xsd:string" minOccurs="0" msdata:Ordinal="2" />
+ </xsd:sequence>
+ <xsd:attribute name="name" type="xsd:string" use="required" msdata:Ordinal="1" />
+ <xsd:attribute name="type" type="xsd:string" msdata:Ordinal="3" />
+ <xsd:attribute name="mimetype" type="xsd:string" msdata:Ordinal="4" />
+ <xsd:attribute ref="xml:space" />
+ </xsd:complexType>
+ </xsd:element>
+ <xsd:element name="resheader">
+ <xsd:complexType>
+ <xsd:sequence>
+ <xsd:element name="value" type="xsd:string" minOccurs="0" msdata:Ordinal="1" />
+ </xsd:sequence>
+ <xsd:attribute name="name" type="xsd:string" use="required" />
+ </xsd:complexType>
+ </xsd:element>
+ </xsd:choice>
+ </xsd:complexType>
+ </xsd:element>
+ </xsd:schema>
+ <resheader name="resmimetype">
+ <value>text/microsoft-resx</value>
+ </resheader>
+ <resheader name="version">
+ <value>2.0</value>
+ </resheader>
+ <resheader name="reader">
+ <value>System.Resources.ResXResourceReader, System.Windows.Forms, Version=2.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089</value>
+ </resheader>
+ <resheader name="writer">
+ <value>System.Resources.ResXResourceWriter, System.Windows.Forms, Version=2.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089</value>
+ </resheader>
+ <metadata name="ToolTip.TrayLocation" type="System.Drawing.Point, System.Drawing, Version=2.0.0.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a">
+ <value>17, 17</value>
+ </metadata>
+ <data name="slider_psyrd.ToolTip" xml:space="preserve">
+ <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,
+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>
+ </data>
+ <data name="drop_adaptBFrames.ToolTip" xml:space="preserve">
+ <value>x264 has a variety of algorithms to decide when to use B-frames and how many to use.
+
+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.
+
+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>
+ </data>
+ <data name="check_Cabac.ToolTip" xml:space="preserve">
+ <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.
+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.
+If you're looking to minimize CPU requirements for video playback, disable this option.
+Baseline profile, as required for iPods and similar devices, requires CABAC to be disabled.</value>
+ </data>
+ <data name="check_noDCTDecimate.ToolTip" xml:space="preserve">
+ <value>x264 normally zeroes out nearly-empty data blocks to save bits to be better used for some other purpose in the video.
+However, this can sometimes have slight negative effects on retention of subtle grain and dither.
+Don't touch this unless you're having banding issues or other such cases where you are having trouble keeping fine noise.</value>
+ </data>
+ <data name="drop_trellis.ToolTip" xml:space="preserve">
+ <value>Trellis fine-tunes the rounding of transform coefficients to squeeze out 3-5% more compression at the cost of some speed.
+"Always" uses trellis not only during the main encoding process, but also during analysis, which improves compression even
+more, albeit at great speed cost.
+
+Trellis costs more speed at higher bitrates</value>
+ </data>
+ <data name="drop_deblockBeta.ToolTip" xml:space="preserve">
+ <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.
+The deblocking filter takes a lot of CPU power, so if you're looking to minimize CPU requirements for video playback, disable it.
+
+The deblocking filter has two adjustable parameters, \"strength\" and \"threshold\".
+The former controls how strong (or weak) the deblocker is, while the latter controls how many (or few) edges it applies to.
+Lower values mean less deblocking, higher values mean more deblocking. The default is 0 (normal strength) for both parameters.</value>
+ </data>
+ <data name="drop_deblockAlpha.ToolTip" xml:space="preserve">
+ <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.
+The deblocking filter takes a lot of CPU power, so if you're looking to minimize CPU requirements for video playback, disable it.
+
+The deblocking filter has two adjustable parameters, \"strength\" and \"threshold\".
+The former controls how strong (or weak) the deblocker is, while the latter controls how many (or few) edges it applies to.
+Lower values mean less deblocking, higher values mean more deblocking. The default is 0 (normal strength) for both parameters.</value>
+ </data>
+ <data name="check_8x8DCT.ToolTip" xml:space="preserve">
+ <value>The 8x8 transform is the single most useful feature of x264 in terms of compression-per-speed.
+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.
+However, it requires High Profile, which many devices may not support.</value>
+ </data>
+ <data name="drop_analysis.ToolTip" xml:space="preserve">
+ <value>Mode decision picks from a variety of options to make its decision: this option chooses what options those are.
+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>
+ </data>
+ <data name="drop_subpixelMotionEstimation.ToolTip" xml:space="preserve">
+ <value>This setting controls both subpixel-precision motion estimation and mode decision methods.
+
+Subpixel motion estimation is used for refining motion estimates beyond mere pixel accuracy, improving compression.
+
+Mode decision is the method used to choose how to encode each block of the frame: a very important decision.
+
+SAD is the fastest method, followed by SATD, RD, RD refinement, and the slowest, QPRD.
+6 or higher is strongly recommended: Psy-RD, a very powerful psy optimization that helps retain detail, requires RD.
+10, the most powerful and slowest option, requires trellis=2.</value>
+ </data>
+ <data name="drop_MotionEstimationRange.ToolTip" xml:space="preserve">
+ <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.
+Doesn't apply to Diamond or Hexagon search options.
+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>
+ </data>
+ <data name="drop_MotionEstimationMethod.ToolTip" xml:space="preserve">
+ <value>Controls the motion estimation method. Motion estimation is how the encoder estimates how each block of pixels in a frame has moved.
+A better motion search method improves compression at the cost of speed.
+
+Diamond: performs an extremely fast and simple search using a diamond pattern.
+
+Hexagon: performs a somewhat more effective but slightly slower search using a hexagon pattern.
+
+Uneven Multi-Hex: performs a very wide search using a variety of patterns, more accurately capturing complex motion.
+
+Exhaustive: performs a \"dumb\" search of every pixel in a wide area. Significantly slower for only a small compression gain.
+
+Transformed Exhaustive: Like exhaustive, but makes even more accurate decisions. Accordingly, somewhat slower, also for only a small improvement.</value>
+ </data>
+ <data name="drop_directPrediction.ToolTip" xml:space="preserve">
+ <value>H.264 allows for two different prediction modes, spatial and temporal, in B-frames.
+
+Spatial, the default, is almost always better, but temporal is sometimes useful too.
+
+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>
+ </data>
+ <data name="drop_bFrames.ToolTip" xml:space="preserve">
+ <value>Sane values are ~2-5.
+This specifies the maximum number of sequential B-frames that the encoder can use.
+ Large numbers generally won't help significantly unless Adaptive B-frames is set to Optimal.
+Cel-animated source material and B-pyramid also significantly increase the usefulness of larger values.
+Baseline profile, as required for iPods and similar devices, requires B-frames to be set to 0 (off).</value>
+ </data>
+ <data name="drop_refFrames.ToolTip" xml:space="preserve">
+ <value>Sane values are ~1-6.
+The more you add, the better the compression, but the slower the encode.
+Cel animation tends to benefit from more reference frames a lot more than film content.
+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,
+don't touch this unless you're absolutely sure you know what you're doing!</value>
+ </data>
+ <data name="check_weightp.ToolTip" xml:space="preserve">
+ <value>Performs extra analysis to decide upon weighting parameters for each frame.
+This improves overall compression slightly and improves the quality of fades greatly.
+Baseline profile, as required for iPods and similar devices, requires weighted P-frame prediction to be disabled.
+Note that some devices and players, even those that support Main Profile,
+may have problems with Weighted P-frame prediction: the Apple TV is completely incompatible with it, for example.</value>
+ </data>
+ <data name="combo_pyrmidalBFrames.ToolTip" xml:space="preserve">
+ <value>B-pyramid improves compression by creating a pyramidal structure (hence the name) of B-frames, allowing B-frames to
+reference each other to improve compression.
+
+Requires Max B-frames greater than 1; optimal adaptive B-frames is strongly recommended for full compression benefit.</value>
+ </data>
+</root>
\ No newline at end of file |