1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
218
219
220
221
222
223
224
225
226
227
228
229
230
231
232
233
234
235
236
237
238
239
240
241
242
243
|
<?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>When adaptive B-Frames are disabled, the number of B-Frames you specify is the constant length of every B-Frame sequence.
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.
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.
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>
</data>
<data name="check_Cabac.ToolTip" xml:space="preserve">
<value>CABAC, or context adaptive binary arithmetic coding, is used by x264 to reduce the bitrate needed for a given quality by 15\%.
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.
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.
When you disable CABAC, another entropy coding scheme gets enabled, called CAVLC (context adaptive variable-length coding).
CAVLC is a lot less efficient, which is why it needs 15\% more bitrate to achieve the same quality as CABAC.</value>
</data>
<data name="check_noDCTDecimate.ToolTip" xml:space="preserve">
<value>To save space, x264 will \"zero out\" blocks when it thinks they won't be perceptible by the viewer.
This negligibly reduces quality, but in rare cases it can mess up and produce visible artifacts.
This situation can be alleviated by telling x264 not to decimate DCT blocks.
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.
However, when used with constant quality encoding, or if you boost the average bitrate to compensate, you might get a better result.</value>
</data>
<data name="drop_trellis.ToolTip" xml:space="preserve">
<value>Trellis fine-tunes how bitrate is doled out, so it can reduce file size/bitrate or increase quality.
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>
</data>
<data name="drop_deblockBeta.ToolTip" xml:space="preserve">
<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.
It has two settings: strength and threshold, just like a simple filter in Photoshop.
Strength controls the amount of deblocking applied to the whole frame. If you drop down below 0, you reduce the amount of blurring.
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.
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.
The default deblocking values are 0 and 0.
This does not mean zero deblocking.
It means x264 will apply the regular deblocking strength and thresholds the codec authors have selected as working the best in most cases.
While many, many people stick with the default deblocking values of 0,0, and you should never change the deblocking without disabling adaptive quantization,
other people disagree.
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.
While the values for each setting extend from -6 to 6, the consensus is that going below -3 or above 3 is worthless.</value>
</data>
<data name="drop_deblockAlpha.ToolTip" xml:space="preserve">
<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.
It has two settings: strength and threshold, just like a simple filter in Photoshop.
Strength controls the amount of deblocking applied to the whole frame. If you drop down below 0, you reduce the amount of blurring.
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.
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.
The default deblocking values are 0 and 0.
This does not mean zero deblocking.
It means x264 will apply the regular deblocking strength and thresholds the codec authors have selected as working the best in most cases.
While many, many people stick with the default deblocking values of 0,0, and you should never change the deblocking without disabling adaptive quantization,
other people disagree.
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.
While the values for each setting extend from -6 to 6, the consensus is that going below -3 or above 3 is worthless.</value>
</data>
<data name="check_8x8DCT.ToolTip" xml:space="preserve">
<value>Checking this box lets x264 break key frames down into 8x8 blocks of pixels for analysis.
This is a high profile feature of H.264, which makes it less compatible. It should slightly decrease bitrate or improve quality.
Turn it on whenever possible.</value>
</data>
<data name="drop_analysis.ToolTip" xml:space="preserve">
<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.
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.
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>
</data>
<data name="drop_subpixelMotionEstimation.ToolTip" xml:space="preserve">
<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).
Higher levels increase quality by further refining the motion prediction for these quarter pixels, but take longer to encode.
The default, 6, turns on a feature called rate distortion optimization, including psychovisual enhancements.
7 enables that rate distortion for B-frames. 8 refines those decisions for I and P frames, and 9 adds on refinement for B-frames as well.</value>
</data>
<data name="drop_MotionEstimationRange.ToolTip" xml:space="preserve">
<value>This range is the radius, in pixels, x264 should use for motion estimation searches.
It only has an effect when you use Uneven Multi-Hexagonal, Exhaustive, or Transformed Exhaustive searching.
24, 32, and 64 are good values, with each being progressively smaller for progressively less improvement to picture quality.</value>
</data>
<data name="drop_MotionEstimationMethod.ToolTip" xml:space="preserve">
<value>Controls the motion estimation method.
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.
There are many ways of finding the most similar blocks, with varying speeds and accuracy.
At the most basic setting, dia, x264 will only consider a diamond-shaped region around each pixel.
The default setting, hex, is similar to dia but uses a hexagon shape.
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.
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.
tesa, transformed exhaustive search, which performs just as thorough a search, is slower still but offers further slight improvements to quality.</value>
</data>
<data name="check_pyrmidalBFrames.ToolTip" xml:space="preserve">
<value>B-frame pyramids are a High Profile feature. Pyramidal B-frames mean that B-frames don't just reference surrounding reference frames -
instead, it also treats a previous B-frame as a reference, improving quality/lowering bitrate at the expense of complexity.
Logically, to reference an earlier B-frame, you must tell x264 to use at least 2 B-frames.</value>
</data>
<data name="check_weightedBFrames.ToolTip" xml:space="preserve">
<value>Sometimes x264 will base a B-frame's motion compensation on frames both before and after.
With weighted B-frames, the amount of influence each frame has is related to its distance from the frame being encoded, instead of both having equal influence.</value>
</data>
<data name="drop_directPrediction.ToolTip" xml:space="preserve">
<value>Direct prediction tells x264 what method to use when guessing motion for certain parts of a B-frame.
It can either look at other parts of the current frame (spatial) or compare against the following P-frameframe (temporal).
You're best off setting this to automatic, so x264 decides which method is best on its own.
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>
</data>
</root>
|
