NOTE: Most authors will be best served by using the default of
- {{HardwareAcceleration/allow}}. This gives the user agent flexibility to
+ {{HardwareAcceleration/allow}}. This gives the User Agent flexibility to
optimize based on its knowledge of the system and configuration. A common
strategy will be to prioritize hardware acceleration at higher resolutions
with a fallback to software codecs if hardware acceleration fails.
@@ -1880,12 +1886,12 @@
- allow
-
- Indicates that the user agent may use hardware acceleration if it is
+ Indicates that the User Agent may use hardware acceleration if it is
available and compatible with other aspects of the codec configuration.
- deny
-
- Indicates that the user agent must not use hardware acceleration.
+ Indicates that the User Agent must not use hardware acceleration.
NOTE: This will cause the configuration to be unsupported on platforms where
an unaccelerated codec is unavailable or is incompatible with other aspects
@@ -1893,7 +1899,7 @@
- require
-
- Indicates that the user agent must use hardware acceleration.
+ Indicates that the User Agent must use hardware acceleration.
NOTE: This will cause the configuration to be unsupported on platforms where
an accelerated codec is unavailable or is incompatible with other aspects of
@@ -1901,6 +1907,29 @@
+Latency Mode{#latency-mode}
+---------------------------
+
<![CDATA[
+enum LatencyMode {
+ "quality",
+ "realtime"
+};
+]]>
+
+:
quality
+:: Indicates that the User Agent should optimize for encoding quality. In
+ this mode:
+ * User Agents may increase encoding latency to improve quality.
+ * User Agents must not drop frames to achieve the target
+ {{VideoEncoderConfig/bitrate}}.
+
+:
realtime
+:: Indicates that the User Agent should optimize for low latency. In this
+ mode:
+ * User Agents may sacrifice quality to improve latency.
+ * User Agents may drop frames to achieve the target
+ {{VideoEncoderConfig/bitrate}}.
+
Configuration Equivalence{#config-equivalence}
----------------------------------------------
Two dictionaries are
equal dictionaries if they contain the same
@@ -1920,7 +1949,7 @@
keyFrame
A value of `true` indicates that the given frame MUST be encoded as a key
- frame. A value of `false` indicates that the user agent has flexibility to
+ frame. A value of `false` indicates that the User Agent has flexibility to
decide whether the frame will be encoded as a [=key frame=].
@@ -2146,7 +2175,7 @@
referenced by a `[[resource reference]]`.
NOTE: When a [=media resource=] is no longer referenced by a
- `[[resource reference]]`, the resource may be destroyed. User agents are
+ `[[resource reference]]`, the resource may be destroyed. User Agents are
encouraged to destroy such resources quickly to reduce memory pressure and
facilitate resource reuse.
@@ -2787,7 +2816,7 @@
{{PixelFormat}} and reference them in the steps above. See
[#165](https://github.com/w3c/webcodecs/issues/165).
- NOTE: The user agent may choose to allocate resource with a larger coded
+ NOTE: The User Agent may choose to allocate resource with a larger coded
size and plane strides to improve memory alignment. Increases will be
reflected by {{VideoFrame/codedWidth}} and {{VideoFrame/codedHeight}}.
@@ -2808,7 +2837,7 @@
the byte positioned at |dataOffset| and stopping after
{{PlaneInit/stride}} bytes have been copied.
- NOTE: The user agent may use {{VideoFramePlaneInit/visibleRect}}
+ NOTE: The User Agent may use {{VideoFramePlaneInit/visibleRect}}
to copy only the visible rectangle. It may also reposition
the visible rectangle within |resource|. The final position
will be reflected by {{VideoFrame/visibleRect}}.
@@ -3392,7 +3421,7 @@
specify how the plane is laid out in the destination {{BufferSource}}}.
Alternatively, callers can inspect {{VideoFrame/copyTo()}}'s returned sequence
of {{PlaneLayout}}s to learn the the offset and stride for planes as decided by
-the user agent.
+the User Agent.
<![CDATA[
dictionary PlaneLayout {
@@ -3525,9 +3554,9 @@
ImageDecoder(init)
</dfn>
:: NOTE: Calling {{ImageDecoder/decode()}} on the constructed {{ImageDecoder}}
- will trigger a {{NotSupportedError}} if the user agent does not support
+ will trigger a {{NotSupportedError}} if the User Agent does not support
|type|. Authors should first check support by calling
- {{ImageDecoder/isTypeSupported()}} with |type|. User agents are not
+ {{ImageDecoder/isTypeSupported()}} with |type|. User Agents are not
required to support any particular type.
When invoked, run these steps:
@@ -3632,7 +3661,7 @@
steps:
1. Wait for {{ImageDecoder/[[tracks established]]}} to become `true`.
2. If |options|.{{ImageDecodeOptions/completeFramesOnly}} is `false` and
- the image is a [=Progressive Image=] for which the user agent supports
+ the image is a [=Progressive Image=] for which the User Agent supports
progressive decoding, run the [=Decode Progressive Frame=] algorithm with |options|.{{ImageDecodeOptions/frameIndex}} and |promise|.
3. Otherwise, run the [=Decode Complete Frame=] algorithm with
|options|.{{ImageDecodeOptions/frameIndex}} and |promise|.
@@ -3652,7 +3681,7 @@
: <dfn method for=ImageDecoder>isTypeSupported(type)</dfn>
:: Returns a promise indicating whether the provided config is supported by the
- user agent.
+ User Agent.
When invoked, run these steps:
1. If |type| is not a [=valid image MIME type=], return a {{Promise}}
@@ -3933,7 +3962,7 @@
{{EncodingError}} {{DOMException}}.
: <dfn for=ImageDecoder>Check Type Support</dfn> (with |type|)
-:: 1. If the user agent can provide a codec to support decoding |type|, return
+:: 1. If the User Agent can provide a codec to support decoding |type|, return
`true`.
2. Otherwise, return `false`.
@@ -4048,7 +4077,7 @@
previous call, until finally the full-detail image is produced.
If {{ImageDecodeOptions/completeFramesOnly}} is assigned `true`, or if the
- image is not a [=Progressive Image=], or if the user agent does not support
+ image is not a [=Progressive Image=], or if the User Agent does not support
progressive decoding for the given image type, calls to
{{ImageDecoder/decode()}} will only resolve once the full detail image is
decoded.
@@ -4263,9 +4292,9 @@
affords attackers the ability to invoke sequences of control methods that were
not previously possible via the higher level APIs.
-User agents should mitigate this risk by extensively fuzzing their
+User Agents should mitigate this risk by extensively fuzzing their
implementation with random inputs and control method invocations. Additionally,
-user agents are encouraged to isolate their underlying codecs in processes with
+User Agents are encouraged to isolate their underlying codecs in processes with
restricted privileges (sandbox) as a barrier against successful exploits being
able to read user data.
@@ -4299,7 +4328,7 @@
expose some additional information in the form of low level codec features.
A codec feature profile alone is unlikely to be uniquely identifying. Underlying
-codecs are often implemented entirely in software (be it part of the user agent
+codecs are often implemented entirely in software (be it part of the User Agent
binary or part of the operating system), such that all users who run that
software will have a common set of capabilities. Additionally, underlying codecs
are often implemented with hardware acceleration, but such hardware is mass
@@ -4311,8 +4340,8 @@
Segmenting groups of users by codec feature profile still amounts to a bit of
entropy that can be combined with other metrics to uniquely identify a user.
-User agents may partially mitigate this by returning an error whenever a site
-attempts to exhaustively probe for codec capabilities. Additionally, user agents
+User Agents may partially mitigate this by returning an error whenever a site
+attempts to exhaustively probe for codec capabilities. Additionally, User Agents
may implement a "privacy budget", which depletes as authors use WebCodecs and
other identifying APIs. Upon exhaustion of the privacy budget, codec
capabilities could be reduced to a common baseline or prompt for user approval.
]]>