1 <?xml version="1.0" encoding="utf-8"?>
\r
4 Microsoft ResX Schema
\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
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
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
30 There are any number of "resheader" rows that contain simple
\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
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
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
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
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
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
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
66 <xsd:choice maxOccurs="unbounded">
\r
67 <xsd:element name="metadata">
\r
70 <xsd:element name="value" type="xsd:string" minOccurs="0" />
\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
78 <xsd:element name="assembly">
\r
80 <xsd:attribute name="alias" type="xsd:string" />
\r
81 <xsd:attribute name="name" type="xsd:string" />
\r
84 <xsd:element name="data">
\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
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
96 <xsd:element name="resheader">
\r
99 <xsd:element name="value" type="xsd:string" minOccurs="0" msdata:Ordinal="1" />
\r
101 <xsd:attribute name="name" type="xsd:string" use="required" />
\r
108 <resheader name="resmimetype">
\r
109 <value>text/microsoft-resx</value>
\r
111 <resheader name="version">
\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
117 <resheader name="writer">
\r
118 <value>System.Resources.ResXResourceWriter, System.Windows.Forms, Version=2.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089</value>
\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
123 <metadata name="ToolTip.TrayLocation" type="System.Drawing.Point, System.Drawing, Version=2.0.0.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a">
\r
124 <value>17, 17</value>
\r
126 <data name="slider_psyrd.ToolTip" xml:space="preserve">
\r
127 <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
128 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
130 <data name="drop_adaptBFrames.ToolTip" xml:space="preserve">
\r
131 <value>When adaptive B-Frames are disabled, the number of B-Frames you specify is the constant length of every B-Frame sequence.
\r
132 When one of the adaptive modes is enabled, the number of B-Frames is treated as a maximum, with the length of each sequence varying, but never exceeding the max.
\r
134 Fast mode takes the same amount of time no matter how many B-frames you specify. However, it doesn't always make the best decisions on how many B-Frames to use in a sequence.
\r
136 Optimal mode gets slower as the maximum number of B-Frames increases, but does a much better job at deciding sequence length, which can mean smaller file sizes and better quality.</value>
\r
138 <data name="check_Cabac.ToolTip" xml:space="preserve">
\r
139 <value>CABAC, or context adaptive binary arithmetic coding, is used by x264 to reduce the bitrate needed for a given quality by 15\%.
\r
140 This makes it very cool and very useful, and it should be left on whenever possible. However, it is incompatible with the iPod, and makes the AppleTV struggle. So turn it off for those.
\r
142 CABAC is a kind of entropy coding, which means that it compresses data by making shorthand symbols to represent long streams of data. The \"entropy\" part means that the symbols it uses the most often are the smallest.
\r
143 When you disable CABAC, another entropy coding scheme gets enabled, called CAVLC (context adaptive variable-length coding).
\r
144 CAVLC is a lot less efficient, which is why it needs 15\% more bitrate to achieve the same quality as CABAC.</value>
\r
146 <data name="check_noDCTDecimate.ToolTip" xml:space="preserve">
\r
147 <value>To save space, x264 will \"zero out\" blocks when it thinks they won't be perceptible by the viewer.
\r
148 This negligibly reduces quality, but in rare cases it can mess up and produce visible artifacts.
\r
149 This situation can be alleviated by telling x264 not to decimate DCT blocks.
\r
151 It increases quality but also bitrate/file size, so if you use it when you've specified a target bitrate you will end up with a worse picture than without it.
\r
152 However, when used with constant quality encoding, or if you boost the average bitrate to compensate, you might get a better result.</value>
\r
154 <data name="drop_trellis.ToolTip" xml:space="preserve">
\r
155 <value>Trellis fine-tunes how bitrate is doled out, so it can reduce file size/bitrate or increase quality.
\r
156 A value of 1 means it only fine-tunes the final encode of a block of pixels, while 2 means it is considered during earlier phases of the decision-making process as well.</value>
\r
158 <data name="drop_deblockBeta.ToolTip" xml:space="preserve">
\r
159 <value>x264 includes an in-loop deblocking filter. What this means is that blocky compression artifacts are smoothed away when you play back the video.
\r
160 It has two settings: strength and threshold, just like a simple filter in Photoshop.
\r
162 Strength controls the amount of deblocking applied to the whole frame. If you drop down below 0, you reduce the amount of blurring.
\r
163 Go too negative, and you'll get an effect somewhat like oversharpening an image. Go into positive values, and the image may become too soft.
\r
165 Threshold controls how sensitive the filter is to whether something in a block is detail that needs to be preserved: lower numbers blur details less.
\r
167 The default deblocking values are 0 and 0.
\r
168 This does not mean zero deblocking.
\r
169 It means x264 will apply the regular deblocking strength and thresholds the codec authors have selected as working the best in most cases.
\r
171 While many, many people stick with the default deblocking values of 0,0, and you should never change the deblocking without disabling adaptive quantization,
\r
172 other people disagree.
\r
173 Some prefer a slightly less blurred image for live action material, and use values like -2,-1 or -2,-2. Others will raise it to 1,1 or even 3,3 for animation.
\r
174 While the values for each setting extend from -6 to 6, the consensus is that going below -3 or above 3 is worthless.</value>
\r
176 <data name="drop_deblockAlpha.ToolTip" xml:space="preserve">
\r
177 <value>x264 includes an in-loop deblocking filter. What this means is that blocky compression artifacts are smoothed away when you play back the video.
\r
178 It has two settings: strength and threshold, just like a simple filter in Photoshop.
\r
180 Strength controls the amount of deblocking applied to the whole frame. If you drop down below 0, you reduce the amount of blurring.
\r
181 Go too negative, and you'll get an effect somewhat like oversharpening an image. Go into positive values, and the image may become too soft.
\r
183 Threshold controls how sensitive the filter is to whether something in a block is detail that needs to be preserved: lower numbers blur details less.
\r
185 The default deblocking values are 0 and 0.
\r
186 This does not mean zero deblocking.
\r
187 It means x264 will apply the regular deblocking strength and thresholds the codec authors have selected as working the best in most cases.
\r
189 While many, many people stick with the default deblocking values of 0,0, and you should never change the deblocking without disabling adaptive quantization,
\r
190 other people disagree.
\r
191 Some prefer a slightly less blurred image for live action material, and use values like -2,-1 or -2,-2. Others will raise it to 1,1 or even 3,3 for animation.
\r
192 While the values for each setting extend from -6 to 6, the consensus is that going below -3 or above 3 is worthless.</value>
\r
194 <data name="check_8x8DCT.ToolTip" xml:space="preserve">
\r
195 <value>Checking this box lets x264 break key frames down into 8x8 blocks of pixels for analysis.
\r
196 This is a high profile feature of H.264, which makes it less compatible. It should slightly decrease bitrate or improve quality.
\r
197 Turn it on whenever possible.</value>
\r
199 <data name="drop_analysis.ToolTip" xml:space="preserve">
\r
200 <value>Analysis controls how finely x264 divides up a frame to capture detail. Full macroblocks are 16x16 pixels, but x264 can go down all the way to 4x4 blocks if it judges it necessary.
\r
201 By default it only breaks up key frames that much. To give x264 the freedom to make the best decisions for all frames, use \"all\" analysis.
\r
202 If you want to create a high profile H.264 video (which is less compatible with the world at large than main profile), also check the \"8x8 DCT blocks\" box to add yet another block size for analysis.</value>
\r
204 <data name="drop_subpixelMotionEstimation.ToolTip" xml:space="preserve">
\r
205 <value>This setting is finer-grained than the motion estimation settings above. Instead of dealing with whole pixels, it deals with 4 fractional pixels, or quarter pixels (qpel).
\r
206 Higher levels increase quality by further refining the motion prediction for these quarter pixels, but take longer to encode.
\r
208 Level 6, turns on a feature called rate distortion optimization, including psychovisual enhancements.
\r
209 7, the default, enables that rate distortion for B-frames.
\r
210 8 refines those decisions for I and P frames, and 9 adds on refinement for B-frames as well.</value>
\r
212 <data name="drop_MotionEstimationRange.ToolTip" xml:space="preserve">
\r
213 <value>This range is the radius, in pixels, x264 should use for motion estimation searches.
\r
214 It only has an effect when you use Uneven Multi-Hexagonal, Exhaustive, or Transformed Exhaustive searching.
\r
215 24, 32, and 64 are good values, with each being progressively smaller for progressively less improvement to picture quality.</value>
\r
217 <data name="drop_MotionEstimationMethod.ToolTip" xml:space="preserve">
\r
218 <value>Controls the motion estimation method.
\r
219 Motion estimation is how the encoder decides how each block of pixels in a frame has moved, compared to most similar blocks in the other frames it references.
\r
220 There are many ways of finding the most similar blocks, with varying speeds and accuracy.
\r
222 At the most basic setting, dia, x264 will only consider a diamond-shaped region around each pixel.
\r
224 The default setting, hex, is similar to dia but uses a hexagon shape.
\r
226 Uneven multi-hexagon, umh, searches a number of different patterns across a wider area and thus is slower than hex and dia but further increases compression efficiency and quality.
\r
228 esa, an exhaustive search of a square around each pixel (whose size is controlled by the me-range parameter), is much slower and offers only minimal quality gains.
\r
230 tesa, transformed exhaustive search, which performs just as thorough a search, is slower still but offers further slight improvements to quality.</value>
\r
232 <data name="check_pyrmidalBFrames.ToolTip" xml:space="preserve">
\r
233 <value>B-frame pyramids are a High Profile feature. Pyramidal B-frames mean that B-frames don't just reference surrounding reference frames -
\r
234 instead, it also treats a previous B-frame as a reference, improving quality/lowering bitrate at the expense of complexity.
\r
235 Logically, to reference an earlier B-frame, you must tell x264 to use at least 2 B-frames.</value>
\r
237 <data name="check_weightedBFrames.ToolTip" xml:space="preserve">
\r
238 <value>Sometimes x264 will base a B-frame's motion compensation on frames both before and after.
\r
239 With weighted B-frames, the amount of influence each frame has is related to its distance from the frame being encoded,
\r
240 instead of both having equal influence.
\r
241 The AppleTV can have issues with this.</value>
\r
243 <data name="drop_directPrediction.ToolTip" xml:space="preserve">
\r
244 <value>Direct prediction tells x264 what method to use when guessing motion for certain parts of a B-frame.
\r
245 It can either look at other parts of the current frame (spatial) or compare against the following P-frameframe (temporal).
\r
246 You're best off setting this to automatic, so x264 decides which method is best on its own.
\r
247 Don't select none assuming it will be faster; instead it will take longer and look worse. If you're going to choose between spatial and temporal, spatial is usually better.</value>
\r
OSDN Git Service
