diff options
Diffstat (limited to 'win/CS/Controls/x264Panel.resx')
| -rw-r--r-- | win/CS/Controls/x264Panel.resx | 241 |
1 files changed, 0 insertions, 241 deletions
diff --git a/win/CS/Controls/x264Panel.resx b/win/CS/Controls/x264Panel.resx deleted file mode 100644 index 41e3ec5c7..000000000 --- a/win/CS/Controls/x264Panel.resx +++ /dev/null @@ -1,241 +0,0 @@ -<?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=4.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089</value>
- </resheader>
- <resheader name="writer">
- <value>System.Resources.ResXResourceWriter, System.Windows.Forms, Version=4.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089</value>
- </resheader>
- <metadata name="ToolTip.TrayLocation" type="System.Drawing.Point, System.Drawing, Version=4.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 |