class DecoderProfileDescription

Returns whether no field is set.

The codec profile that this decoder supports. If the client wants to use this

profile, the requirements specified in this table must be adhered to.

The codec profile that this decoder supports. If the client wants to use this

profile, the requirements specified in this table must be adhered to.

The minimum image size this decoder supports for the given |profile|.

Decoders must set this field, and this field must specify a size that is

>= the min size defined for the profile in the codec spec.

This size refers to the pixel layout in memory, not the display_rect which can be smaller

than the fuchsia.Images2.ImageFormat.size / fuchsia.sysmem.ImageFormat2.coded_width/height.

The minimum image size this decoder supports for the given |profile|.

Decoders must set this field, and this field must specify a size that is

>= the min size defined for the profile in the codec spec.

This size refers to the pixel layout in memory, not the display_rect which can be smaller

than the fuchsia.Images2.ImageFormat.size / fuchsia.sysmem.ImageFormat2.coded_width/height.

The maximum image size this decoder supports for the given |profile|.

Decoders must set this field, and this field must specify a size that is

<

= the max size

defined for the profile in the codec spec.

This size refers to the pixel layout in memory, not the display_rect which can be smaller

than the fuchsia.Images2.ImageFormat.size / fuchsia.sysmem.ImageFormat2.coded_width/height.

By setting this field, a decoder is not required to fail to decode a stream that specifies a

size that is larger than the profile of the stream would normally allow. The decoder may or

may not fail to decode a stream which is not a listed profile or not within the size bounds

of a listed profile.

The maximum image size this decoder supports for the given |profile|.

Decoders must set this field, and this field must specify a size that is

<

= the max size

defined for the profile in the codec spec.

This size refers to the pixel layout in memory, not the display_rect which can be smaller

than the fuchsia.Images2.ImageFormat.size / fuchsia.sysmem.ImageFormat2.coded_width/height.

By setting this field, a decoder is not required to fail to decode a stream that specifies a

size that is larger than the profile of the stream would normally allow. The decoder may or

may not fail to decode a stream which is not a listed profile or not within the size bounds

of a listed profile.

This |profile| entry can apply to encrypted input data. If require_encryption is false or

unset, this |profile| entry can also apply to unencrypted input data.

This will be un-set (even when allow_input_protection or require_input_protection are true)

until Fuchsia supports decryption as part of decode (in contrast to it being a separate step

involving protected memory in between). When allow_encryption is false/un-set but

allow_input_protection is true, a client setting up DRM decode should set up decryption as a

separate step prior to decode with protected memory in between the decrypt and decode.

This |profile| entry can apply to encrypted input data. If require_encryption is false or

unset, this |profile| entry can also apply to unencrypted input data.

This will be un-set (even when allow_input_protection or require_input_protection are true)

until Fuchsia supports decryption as part of decode (in contrast to it being a separate step

involving protected memory in between). When allow_encryption is false/un-set but

allow_input_protection is true, a client setting up DRM decode should set up decryption as a

separate step prior to decode with protected memory in between the decrypt and decode.

This |profile| entry applies only when input data is encrypted. This |profile| entry does

not apply for unencrypted input data. Un-set is interepted as false.

If this is set to true and there is no profile with require_encryption false in the same

DetailedCodecDescription, then this decoder only supports encrypted input.

This will be un-set until Fuchsia supports decryption as part of decode (even when

allow_input_protection or require_input_protection are true). See also allow_encryption,

allow_input_protection, require_input_protection.

This |profile| entry applies only when input data is encrypted. This |profile| entry does

not apply for unencrypted input data. Un-set is interepted as false.

If this is set to true and there is no profile with require_encryption false in the same

DetailedCodecDescription, then this decoder only supports encrypted input.

This will be un-set until Fuchsia supports decryption as part of decode (even when

allow_input_protection or require_input_protection are true). See also allow_encryption,

allow_input_protection, require_input_protection.

This |profile| entry can apply when input data delivered via protected memory. Whether to

protect input and which protected "heap" to use (if protecting input) is determined during

sysmem constraints aggregation and via DRM mechanisms. See also require_input_protection,

allow_encryption, require_encryption.

This |profile| entry can apply when input data delivered via protected memory. Whether to

protect input and which protected "heap" to use (if protecting input) is determined during

sysmem constraints aggregation and via DRM mechanisms. See also require_input_protection,

allow_encryption, require_encryption.

This |profile| entry applies only when input data is delivered via protected memory. Whether

to protect input and which protected "heap" to use (if protecting input) is determined

during sysmem constraints aggregation, and by separate DRM mechanisms.

If this is set to true and there is no profile with require_input_protection false in the

same DetailedCodecDescription, then this decoder only supports protected input.

Output protection is negotiated separately during output buffer constraints aggregation in

sysmem, and via DRM mechanisms.

See also allow_input_protection, allow_encryption, require_encryption.

This |profile| entry applies only when input data is delivered via protected memory. Whether

to protect input and which protected "heap" to use (if protecting input) is determined

during sysmem constraints aggregation, and by separate DRM mechanisms.

If this is set to true and there is no profile with require_input_protection false in the

same DetailedCodecDescription, then this decoder only supports protected input.

Output protection is negotiated separately during output buffer constraints aggregation in

sysmem, and via DRM mechanisms.

See also allow_input_protection, allow_encryption, require_encryption.

If set to true, the decoder can handle an input chunk payload (containing compressed data)

that's split across a packet boundary (between header and payload, or between payload

bytes), and the decoder can also handle more than one input chunk containing compressed

input data in a single input packet. See also split_header_handling to determine if the

decoder can also handle split headers.

Un-set means false.

While this field always indicates whether it's ok to split an input chunk across a packet

boundary or not, and this field being set always implies it's ok to have a single input

packet with bytes from more than one input chunk including when the input chunks contain

compressed input data, there is some additional somewhat-subtle meaning that differs between

video and audio decoders.

Audio decoders are always required to permit more than one input chunk in a single input

packet, including mulitple input chunks which each contain compressed input data (not just

prepended "context" headers), regardless of this field being set or unset. For audio

decoders, this field only indicates whether splitting an input chunk across packets is

allowed.

Audio decoders shouldn't set split_header_handling to true unless they also set

can_stream_bytes_input to true, since allowing splitting header bytes is meaningless unless

it's allowed to split an input chunk.

For video decoders, if this field is un-set or false, the decoder may not be able to handle

bytes of more than one input chunk in a single input packet. However, for all decoders

(both video and audio) it's always ok for preceding "context" headers such as the h264 SPS

and PPS headers to be in the same input packet as the following input chunk containing

compressed input data such as an h264 slice (for example). A video decoder is always

required to permit continuation of an input chunk in the next packet, with the split between

header byte and compressed input data byte or between two compressed input data bytes (but

not necessarily between two header bytes; see also split_header_handling).

It's expected to be fairly common for a decoder to set can_stream_bytes_input to true, but

leave split_header_handling un-set or set split_header_handling to false, due to parsing

limitations in the HW, FW, or driver. Decoders which set can_stream_bytes_input false or

leave can_stream_bytes_input un-set may be forcing input data to be re-packed in some

scenarios. Profiles which set allow_encryption are encouraged to also set

can_stream_bytes_input if feasible, as re-packing input data can be more difficult in some

scenarios involving encryption.

If set to true, the decoder can handle an input chunk payload (containing compressed data)

that's split across a packet boundary (between header and payload, or between payload

bytes), and the decoder can also handle more than one input chunk containing compressed

input data in a single input packet. See also split_header_handling to determine if the

decoder can also handle split headers.

Un-set means false.

While this field always indicates whether it's ok to split an input chunk across a packet

boundary or not, and this field being set always implies it's ok to have a single input

packet with bytes from more than one input chunk including when the input chunks contain

compressed input data, there is some additional somewhat-subtle meaning that differs between

video and audio decoders.

Audio decoders are always required to permit more than one input chunk in a single input

packet, including mulitple input chunks which each contain compressed input data (not just

prepended "context" headers), regardless of this field being set or unset. For audio

decoders, this field only indicates whether splitting an input chunk across packets is

allowed.

Audio decoders shouldn't set split_header_handling to true unless they also set

can_stream_bytes_input to true, since allowing splitting header bytes is meaningless unless

it's allowed to split an input chunk.

For video decoders, if this field is un-set or false, the decoder may not be able to handle

bytes of more than one input chunk in a single input packet. However, for all decoders

(both video and audio) it's always ok for preceding "context" headers such as the h264 SPS

and PPS headers to be in the same input packet as the following input chunk containing

compressed input data such as an h264 slice (for example). A video decoder is always

required to permit continuation of an input chunk in the next packet, with the split between

header byte and compressed input data byte or between two compressed input data bytes (but

not necessarily between two header bytes; see also split_header_handling).

It's expected to be fairly common for a decoder to set can_stream_bytes_input to true, but

leave split_header_handling un-set or set split_header_handling to false, due to parsing

limitations in the HW, FW, or driver. Decoders which set can_stream_bytes_input false or

leave can_stream_bytes_input un-set may be forcing input data to be re-packed in some

scenarios. Profiles which set allow_encryption are encouraged to also set

can_stream_bytes_input if feasible, as re-packing input data can be more difficult in some

scenarios involving encryption.

If set to true, the decoder can scan forward at the start of a stream to find the start of

the first fully-present input chunk, even if the input data starts at a byte that's in the

middle of a chunk.

For both video and audio decoders, setting this field to true also indicates the ability to

handle (skip or only partly use) any input chunks that are not possible to decode (or not

possible to fully decode) due to lack of referenced prior data.

If un-set or false, the decoder may not be able to scan forward to sync up with the input

stream unless the input stream starts with the beginning of a suitable chunk.

If set to true, the decoder can scan forward at the start of a stream to find the start of

the first fully-present input chunk, even if the input data starts at a byte that's in the

middle of a chunk.

For both video and audio decoders, setting this field to true also indicates the ability to

handle (skip or only partly use) any input chunks that are not possible to decode (or not

possible to fully decode) due to lack of referenced prior data.

If un-set or false, the decoder may not be able to scan forward to sync up with the input

stream unless the input stream starts with the beginning of a suitable chunk.

If set to true, the decoder can resynchronize with the input stream (eventually) despite a

missing input chunk, and can handle partial input chunks without failing the stream or the

StreamProcessor control connection.

If set to true, the decoder can resynchronize with the input stream (eventually) despite a

missing input chunk, and can handle partial input chunks without failing the stream or the

StreamProcessor control connection.

If set to true, the decoder makes efforts to indicate partial or detected-as-missing or

detected-as-corrupt input chunks by setting error_detected_before and/or

error_detected_during as appropriate. Even when this field is set to true, it is worth

noting that in general it is not possible for a decoder to detect all possible data

corruptions, as codecs generally aren't inclined to include error detection bits within the

stream. This is not a replacment for a real (as in robust with high probability against

random bit flips and bit insertion/deletion) data integrity check.

If set to true, the decoder can handle the bytes of any header being split across packet

boundaries. If false or un-set, the decoder requires all header bytes of a header to be

within the same packet.

Starting a new packet at the spec-defined boundary between two headers that are officially

in separate input chunks is always permitted.

For purposes of this field, headers like the h264 SPS and PPS headers are considered

separate input chunks, and so such headers that have their own input chunk can be delivered

in a separate packet regardless of the setting of this field, and a subsequent h264 slice

header can be in yet another packet.

It is always permissible regardless of the setting of this field for "context" headers (such

as h264 SPS and PPS headers) to be delivered in the same packet as the subsequent chunk

which conveys compressed image data (such as an h264 slice).

Splitting a single header between codec_oob_bytes and the stream data is never supported (as

in, never to be relied on by clients), not even when this field is set to true.

See also can_stream_bytes_input.

Video decoders with can_stream_bytes_input true but split_header_handling false can handle

continuing an chunk in the next packet when split between header and payload or between

payload bytes, and can handle bytes of more than one input chunk in a single input packet,

but cannot handle splitting a header across packets. Video decoders with

can_stream_bytes_input false and split_header_handling true cannot tolerate bytes of more

than one input chunk in a single packet, but can tolerate continuation of an input chunk in

a following packet regardless of where the split occurs (such as in the middle of an h264

SPS, PPS, or slice header).

Audio decoders shouldn't set split_header_handling to true unless they also set

can_stream_bytes_input to true, since for an audio decoder, allowing splitting header bytes

is meaningless (for audio decoders) unless also allowing splitting an input chunk.

If set to true, the decoder makes efforts to indicate partial or detected-as-missing or

detected-as-corrupt input chunks by setting error_detected_before and/or

error_detected_during as appropriate. Even when this field is set to true, it is worth

noting that in general it is not possible for a decoder to detect all possible data

corruptions, as codecs generally aren't inclined to include error detection bits within the

stream. This is not a replacment for a real (as in robust with high probability against

random bit flips and bit insertion/deletion) data integrity check.

If set to true, the decoder can handle the bytes of any header being split across packet

boundaries. If false or un-set, the decoder requires all header bytes of a header to be

within the same packet.

Starting a new packet at the spec-defined boundary between two headers that are officially

in separate input chunks is always permitted.

For purposes of this field, headers like the h264 SPS and PPS headers are considered

separate input chunks, and so such headers that have their own input chunk can be delivered

in a separate packet regardless of the setting of this field, and a subsequent h264 slice

header can be in yet another packet.

It is always permissible regardless of the setting of this field for "context" headers (such

as h264 SPS and PPS headers) to be delivered in the same packet as the subsequent chunk

which conveys compressed image data (such as an h264 slice).

Splitting a single header between codec_oob_bytes and the stream data is never supported (as

in, never to be relied on by clients), not even when this field is set to true.

See also can_stream_bytes_input.

Video decoders with can_stream_bytes_input true but split_header_handling false can handle

continuing an chunk in the next packet when split between header and payload or between

payload bytes, and can handle bytes of more than one input chunk in a single input packet,

but cannot handle splitting a header across packets. Video decoders with

can_stream_bytes_input false and split_header_handling true cannot tolerate bytes of more

than one input chunk in a single packet, but can tolerate continuation of an input chunk in

a following packet regardless of where the split occurs (such as in the middle of an h264

SPS, PPS, or slice header).

Audio decoders shouldn't set split_header_handling to true unless they also set

can_stream_bytes_input to true, since for an audio decoder, allowing splitting header bytes

is meaningless (for audio decoders) unless also allowing splitting an input chunk.