class ImageFormatConstraints

Default constructs a |ImageFormatConstraints| only if all of its members are default constructible.

The PixelFormat for which the following constraints apply. A

participant may have more than one PixelFormat that's supported, in

which case that participant can use a list of ImageFormatConstraints

with an entry per PixelFormat. It's not uncommon for the other fields

of ImageFormatConstraints to vary by PixelFormat - for example for a

linear format to support smaller max size than a tiled format.

The PixelFormat for which the following constraints apply. A

participant may have more than one PixelFormat that's supported, in

which case that participant can use a list of ImageFormatConstraints

with an entry per PixelFormat. It's not uncommon for the other fields

of ImageFormatConstraints to vary by PixelFormat - for example for a

linear format to support smaller max size than a tiled format.

The PixelFormat for which the following constraints apply. A

participant may have more than one PixelFormat that's supported, in

which case that participant can use a list of ImageFormatConstraints

with an entry per PixelFormat. It's not uncommon for the other fields

of ImageFormatConstraints to vary by PixelFormat - for example for a

linear format to support smaller max size than a tiled format.

Empty is an error. Redundant entries are an error. Arbitrary ordering

is not an error.

Empty is an error. Redundant entries are an error. Arbitrary ordering

is not an error.

Empty is an error. Redundant entries are an error. Arbitrary ordering

is not an error.

Setter for color_space.

Minimum permitted width in pixels.

For example a video decoder participant may set this field to the

minimum coded_width that might potentially be specified by a stream. In

contrast, required_min_coded_width would be set to the current

coded_width specified by the stream. While min_coded_width aggregates

by taking the max, required_min_coded_width aggregates by taking the

min.

See also required_min_coded_width.

Minimum permitted width in pixels.

For example a video decoder participant may set this field to the

minimum coded_width that might potentially be specified by a stream. In

contrast, required_min_coded_width would be set to the current

coded_width specified by the stream. While min_coded_width aggregates

by taking the max, required_min_coded_width aggregates by taking the

min.

See also required_min_coded_width.

Minimum permitted width in pixels.

For example a video decoder participant may set this field to the

minimum coded_width that might potentially be specified by a stream. In

contrast, required_min_coded_width would be set to the current

coded_width specified by the stream. While min_coded_width aggregates

by taking the max, required_min_coded_width aggregates by taking the

min.

See also required_min_coded_width.

Maximum width in pixels. For example Scenic may set this field

(directly or via sub-participants) to the maximum width that can be

composited.

0 is treated as 0xFFFFFFFF.

Maximum width in pixels. For example Scenic may set this field

(directly or via sub-participants) to the maximum width that can be

composited.

0 is treated as 0xFFFFFFFF.

Maximum width in pixels. For example Scenic may set this field

(directly or via sub-participants) to the maximum width that can be

composited.

0 is treated as 0xFFFFFFFF.

Minimum height in pixels. For example a video decoder participant may

set this field to the coded_height specified by a stream.

Minimum height in pixels. For example a video decoder participant may

set this field to the coded_height specified by a stream.

Minimum height in pixels. For example a video decoder participant may

set this field to the coded_height specified by a stream.

Maximum height in pixels. For example Scenic may set this field

(directly or via sub-participants) to the maximum height that can be

composited.

0 is treated as 0xFFFFFFFF.

Maximum height in pixels. For example Scenic may set this field

(directly or via sub-participants) to the maximum height that can be

composited.

0 is treated as 0xFFFFFFFF.

Maximum height in pixels. For example Scenic may set this field

(directly or via sub-participants) to the maximum height that can be

composited.

0 is treated as 0xFFFFFFFF.

Must be >= the value implied by min_coded_width for plane 0.

Must be >= the value implied by min_coded_width for plane 0.

Must be >= the value implied by min_coded_width for plane 0.

Must be >= the value implied by max_coded_width for plane 0.

0 is treated as 0xFFFFFFFF.

Must be >= the value implied by max_coded_width for plane 0.

0 is treated as 0xFFFFFFFF.

Must be >= the value implied by max_coded_width for plane 0.

0 is treated as 0xFFFFFFFF.

The max image area in pixels is limited indirectly via

BufferSettings.size_bytes, and can also be enforced directly via this

field.

0 is treated as 0xFFFFFFFF.

The max image area in pixels is limited indirectly via

BufferSettings.size_bytes, and can also be enforced directly via this

field.

0 is treated as 0xFFFFFFFF.

The max image area in pixels is limited indirectly via

BufferSettings.size_bytes, and can also be enforced directly via this

field.

0 is treated as 0xFFFFFFFF.

Number of layers within a multi-layered image.

0 is treated as 1.

Number of layers within a multi-layered image.

0 is treated as 1.

Number of layers within a multi-layered image.

0 is treated as 1.

coded_width % width_divisor must be 0.

0 is treated as 1.

coded_width % width_divisor must be 0.

0 is treated as 1.

coded_width % width_divisor must be 0.

0 is treated as 1.

coded_height % height_divisor must be 0.

0 is treated as 1.

coded_height % height_divisor must be 0.

0 is treated as 1.

coded_height % height_divisor must be 0.

0 is treated as 1.

bytes_per_row % bytes_per_row_divisor must be 0.

0 is treated as 1.

bytes_per_row % bytes_per_row_divisor must be 0.

0 is treated as 1.

bytes_per_row % bytes_per_row_divisor must be 0.

0 is treated as 1.

vmo_usable_start % start_offset_divisor must be 0.

0 is treated as 1.

vmo_usable_start % start_offset_divisor must be 0.

0 is treated as 1.

vmo_usable_start % start_offset_divisor must be 0.

0 is treated as 1.

display_width % display_width_divisor must be 0.

0 is treated as 1.

display_width % display_width_divisor must be 0.

0 is treated as 1.

display_width % display_width_divisor must be 0.

0 is treated as 1.

display_height % display_height_divisor must be 0.

0 is treated as 1.

display_height % display_height_divisor must be 0.

0 is treated as 1.

display_height % display_height_divisor must be 0.

0 is treated as 1.

required_ dimension bounds.

In contrast to the corresponding fields without "required_" at the

start, these fields (when set to non-zero values) express a requirement

that the resulting aggregated non-required_ fields specify a space that

fully contain the space expressed by each participant's required_

fields.

For example, a producer video decoder is perfectly happy for the

consumer to be willing to accept anything, and the video decoder doesn't

really want to constrain the potential space of dimensions that might be

seen in a stream and may be acceptable to the consumer, but the video

decoder needs to ensure that the resulting dimension ranges contain

at least the current dimensions decoded from the stream.

Similarly, an initiator with a particular dynamic-dimension scenario in

mind may wish to require up front that participants agree to handle at

least the range of dimensions expected by the initiator in that

scenario (else fail earlier rather than later, maybe trying again with

smaller required_ space).

It's much more common for a producer or initiator to set these fields

than for a consumer to set these fields.

While the non-required_ fields aggregate by taking the intersection, the

required_ fields aggregate by taking the union.

If set, the required_max_coded_width and required_max_coded_height will

cause the allocated buffers to be large enough to hold an image that is

required_max_coded_width * required_max_coded_height.

TODO(dustingreen): Make it easier to allocate buffers of minimal size

that can (optionally) also handle 90 degree rotated version of the max

dimensions / alternate required bounds for another main aspect ratio.

0 is treated as 0xFFFFFFFF.

required_ dimension bounds.

In contrast to the corresponding fields without "required_" at the

start, these fields (when set to non-zero values) express a requirement

that the resulting aggregated non-required_ fields specify a space that

fully contain the space expressed by each participant's required_

fields.

For example, a producer video decoder is perfectly happy for the

consumer to be willing to accept anything, and the video decoder doesn't

really want to constrain the potential space of dimensions that might be

seen in a stream and may be acceptable to the consumer, but the video

decoder needs to ensure that the resulting dimension ranges contain

at least the current dimensions decoded from the stream.

Similarly, an initiator with a particular dynamic-dimension scenario in

mind may wish to require up front that participants agree to handle at

least the range of dimensions expected by the initiator in that

scenario (else fail earlier rather than later, maybe trying again with

smaller required_ space).

It's much more common for a producer or initiator to set these fields

than for a consumer to set these fields.

While the non-required_ fields aggregate by taking the intersection, the

required_ fields aggregate by taking the union.

If set, the required_max_coded_width and required_max_coded_height will

cause the allocated buffers to be large enough to hold an image that is

required_max_coded_width * required_max_coded_height.

TODO(dustingreen): Make it easier to allocate buffers of minimal size

that can (optionally) also handle 90 degree rotated version of the max

dimensions / alternate required bounds for another main aspect ratio.

0 is treated as 0xFFFFFFFF.

required_ dimension bounds.

In contrast to the corresponding fields without "required_" at the

start, these fields (when set to non-zero values) express a requirement

that the resulting aggregated non-required_ fields specify a space that

fully contain the space expressed by each participant's required_

fields.

For example, a producer video decoder is perfectly happy for the

consumer to be willing to accept anything, and the video decoder doesn't

really want to constrain the potential space of dimensions that might be

seen in a stream and may be acceptable to the consumer, but the video

decoder needs to ensure that the resulting dimension ranges contain

at least the current dimensions decoded from the stream.

Similarly, an initiator with a particular dynamic-dimension scenario in

mind may wish to require up front that participants agree to handle at

least the range of dimensions expected by the initiator in that

scenario (else fail earlier rather than later, maybe trying again with

smaller required_ space).

It's much more common for a producer or initiator to set these fields

than for a consumer to set these fields.

While the non-required_ fields aggregate by taking the intersection, the

required_ fields aggregate by taking the union.

If set, the required_max_coded_width and required_max_coded_height will

cause the allocated buffers to be large enough to hold an image that is

required_max_coded_width * required_max_coded_height.

TODO(dustingreen): Make it easier to allocate buffers of minimal size

that can (optionally) also handle 90 degree rotated version of the max

dimensions / alternate required bounds for another main aspect ratio.

0 is treated as 0xFFFFFFFF.

Setter for required_max_coded_width.

0 is treated as 0xFFFFFFFF.

0 is treated as 0xFFFFFFFF.

0 is treated as 0xFFFFFFFF.

Setter for required_max_coded_height.

0 is treated as 0xFFFFFFFF.

0 is treated as 0xFFFFFFFF.

0 is treated as 0xFFFFFFFF.

Setter for required_max_bytes_per_row.