Struct DecoderProfileDescription

pub struct DecoderProfileDescription {
    pub profile: Option<CodecProfile>,
    pub min_image_size: Option<SizeU>,
    pub max_image_size: Option<SizeU>,
    pub allow_encryption: Option<bool>,
    pub require_encryption: Option<bool>,
    pub allow_input_protection: Option<bool>,
    pub require_input_protection: Option<bool>,
    pub can_stream_bytes_input: Option<bool>,
    pub can_find_start: Option<bool>,
    pub can_re_sync: Option<bool>,
    pub will_report_all_detected_errors: Option<bool>,
    pub split_header_handling: Option<bool>,
    /* private fields */
}

Specification of the supported parameters of a given video decoder.

Fields in this table with the same name as fields in CodecDescription have the same meaning as the fields in the CodecDescription struct when the corresponding field in this table is set.

When a corresponding field is un-set, each of these fields is interpreted according to the corresponding doc comment on the field in this table (doc comments on fields in the CodecDescription struct re. struct field defaults are not relevant to the interpretation of un-set fields of this table).

For video decoders, the following is always required:

• Handling split input payload (distinct from split header), when an input frame is too large for a single input buffer. The next portion (possibly the remainder) of the timstamped input chunk is delivered in the next input packet.

For audio decoders, the following is always required:

• Concatenation of multiple compressed audio chunks via the input is always permitted.

Fields

profile: Option<CodecProfile>

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.

min_image_size: Option<SizeU>

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.

max_image_size: Option<SizeU>

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.

allow_encryption: Option<bool>

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.

require_encryption: Option<bool>

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.

allow_input_protection: Option<bool>

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.

require_input_protection: Option<bool>

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.

can_stream_bytes_input: Option<bool>

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.

can_find_start: Option<bool>

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.

can_re_sync: Option<bool>

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.

will_report_all_detected_errors: Option<bool>

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.

split_header_handling: Option<bool>

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.

Trait Implementations

impl Clone for DecoderProfileDescription

fn clone(&self) -> DecoderProfileDescription

Returns a copy of the value.

fn clone_from(&mut self, source: &Self)

Performs copy-assignment from source.

impl Debug for DecoderProfileDescription

fn fmt(&self, f: &mut Formatter<'_>) -> Result

Formats the value using the given formatter.

impl<D: ResourceDialect> Decode<DecoderProfileDescription, D> for DecoderProfileDescription

fn new_empty() -> Self

Creates a valid instance of Self. The specific value does not matter, since it will be overwritten by decode.

unsafe fn decode( &mut self, decoder: &mut Decoder<'_, D>, offset: usize, depth: Depth, ) -> Result<()>

Decodes an object of type T from the decoder’s buffers into self.

impl Default for DecoderProfileDescription

fn default() -> DecoderProfileDescription

Returns the “default value” for a type.

impl<D: ResourceDialect> Encode<DecoderProfileDescription, D> for &DecoderProfileDescription

unsafe fn encode( self, encoder: &mut Encoder<'_, D>, offset: usize, depth: Depth, ) -> Result<()>

Encodes the object into the encoder’s buffers. Any handles stored in the object are swapped for Handle::INVALID.

impl PartialEq for DecoderProfileDescription

fn eq(&self, other: &DecoderProfileDescription) -> bool

Tests for self and other values to be equal, and is used by ==.

fn ne(&self, other: &Rhs) -> bool

Tests for !=. The default implementation is almost always sufficient, and should not be overridden without very good reason.

impl TypeMarker for DecoderProfileDescription

type Owned = DecoderProfileDescription

The owned Rust type which this FIDL type decodes into.

fn inline_align(_context: Context) -> usize

Returns the minimum required alignment of the inline portion of the encoded object. It must be a (nonzero) power of two.

fn inline_size(_context: Context) -> usize

Returns the size of the inline portion of the encoded object, including padding for alignment. Must be a multiple of inline_align.

fn encode_is_copy() -> bool

Returns true if the memory layout of Self::Owned matches the FIDL wire format and encoding requires no validation. When true, we can optimize encoding arrays and vectors of Self::Owned to a single memcpy.

fn decode_is_copy() -> bool

Returns true if the memory layout of Self::Owned matches the FIDL wire format and decoding requires no validation. When true, we can optimize decoding arrays and vectors of Self::Owned to a single memcpy.

impl ValueTypeMarker for DecoderProfileDescription

type Borrowed<'a> = &'a DecoderProfileDescription

The Rust type to use for encoding. This is a particular Encode<Self> type cheaply obtainable from &Self::Owned. There are three cases:

fn borrow(value: &<Self as TypeMarker>::Owned) -> Self::Borrowed<'_>

Cheaply converts from &Self::Owned to Self::Borrowed.

impl Persistable for DecoderProfileDescription

impl StructuralPartialEq for DecoderProfileDescription