pub struct StreamProcessorAddBufferRequest {
pub port: Option<Port>,
pub buffer_constraints_version_ordinal: Option<u64>,
pub buffer_lifetime_ordinal: Option<u64>,
pub buffer_index: Option<u32>,
pub buffer: Option<Vmo>,
/* private fields */
}Fields§
§port: Option<Port>Must be set. Which port (input or output) the buffer is for.
buffer_constraints_version_ordinal: Option<u64>Typically this is the latest buffer_constraints_version_ordinal known to the client based on OnInputConstraints/OnOutputConstraints. Older values are not harmful to correctness.
The server will ignore this message if the server has already created a later buffer_constraints_version_ordinal value that has action_required true. If the server ignores this message, a later RemoveBuffer for this buffer will complete quickly and without creating an error.
A client is not required to ensure that every call to AddBuffer with the same buffer_lifetime_ordinal uses the same buffer_constraints_version_ordinal, but the client must ensure that all buffer_constraints_version_ordinal values which share the same buffer_lifetime_ordinal are within the same action_required true interval. Each such interval starts with a value that has action_required true, and lasts until but not including the next value with action_required true, or until the current value if there is not yet a next value with action_required true. If this would create a problem for a server, that server should set action_required true instead of false.
buffer_lifetime_ordinal: Option<u64>These values are scoped to input/output separately.
The first message from the client with a new (higher) buffer_lifetime_ordinal value begins removing all buffers on the same port with lower buffer_lifetime_ordinal. However, until removal is complete, the older buffers can still be used by the codec.
The AddBuffer message adds the buffer to this buffer_lifetime_ordinal.
buffer_index: Option<u32>The buffer_index values under a buffer_lifetime_ordinal must be unique among all added but not yet fully removed buffers. This value is initially allocated/specified by the client using this field, and then both the client and the server will then refer to a this added buffer uniquely using input vs output, buffer_lifetime_ordinal, and the buffer_index (all three parts are needed to unambiguously specify this buffer).
See RemoveBuffer doc comments for how to safely remove a buffer and potentially re-use a buffer_index value.
In contrast to using SetInputBufferPartialSettings/SetOutputBufferPartialSettings, when using AddBuffer and RemoveBuffer, the StreamProcessor buffer_index value has no relation to the sysmem buffer_index (under the sysmem buffer_collection_id). Instead, the StreamProcessor buffer_index is specified by this field, not by using sysmem’s buffer_index. This way, two buffers from two sysmem collections having the same sysmem buffer_index (under separate buffer_collection_id(s)) can be specified unambiguously in StreamProcessor messages.
buffer: Option<Vmo>This is a VMO handle that the server can use to access the sysmem buffer.
This VMO is required to have been provided by sysmem, and required to be compatible with the server’s sysmem constraints.
The buffer_constraints_version_ordinal check occurs first, and failure of that check just silently ignores the remainder of this message without checking the buffer field (buffer is just dropped).
If the buffer_constraints_version_ordinal check passes, but buffer
isn’t a sysmem-provided VMO or isn’t consistent with the server’s
sysmem constraints, the server will close the StreamProcessor
server_end. The client can avoid triggering this failure case by
allocating the buffers per the following.
For video decoder input buffers, the client can allocate the buffer using sysmem, with participation of this or another instance of the same codec implementation, using ParticipateInBufferAllocation with Port.INPUT. The same StreamProcessor instance isn’t required in this case, only the same codec implementation. If using a different StreamProcessor instance (but still from the same codec implementation), the client should take care to create the two StreamProcessor instances with the same requirements specified to CodecFactory (for example with secure_input_mode and secure_output_mode set the same way). Video decoder server implementations with supports_dynamic_buffers true are required to support allocating input buffers using one StreamProcessor instance then using them with a different StreamProcessor instance (in contrast, for output buffers, this is not required).
For video decoder output buffers, this can be achieved by allocating the buffer using sysmem, with participation of the same StreamProcessor instance, using ParticipateInBufferAllocation with Port.OUTPUT.
Servers should verify that this VMO is (a) provided by sysmem, and (b) meets the server’s current sysmem constraints. The server can verify both (a) and (b) by checking the result of sysmem’s CheckVmoConstraints before using this VMO. If that check fails, the server can close the StreamProcessor server_end.
Trait Implementations§
Source§impl Decode<StreamProcessorAddBufferRequest, DefaultFuchsiaResourceDialect> for StreamProcessorAddBufferRequest
impl Decode<StreamProcessorAddBufferRequest, DefaultFuchsiaResourceDialect> for StreamProcessorAddBufferRequest
Source§impl Default for StreamProcessorAddBufferRequest
impl Default for StreamProcessorAddBufferRequest
Source§fn default() -> StreamProcessorAddBufferRequest
fn default() -> StreamProcessorAddBufferRequest
Source§impl Encode<StreamProcessorAddBufferRequest, DefaultFuchsiaResourceDialect> for &mut StreamProcessorAddBufferRequest
impl Encode<StreamProcessorAddBufferRequest, DefaultFuchsiaResourceDialect> for &mut StreamProcessorAddBufferRequest
Source§impl PartialEq for StreamProcessorAddBufferRequest
impl PartialEq for StreamProcessorAddBufferRequest
Source§fn eq(&self, other: &StreamProcessorAddBufferRequest) -> bool
fn eq(&self, other: &StreamProcessorAddBufferRequest) -> bool
self and other values to be equal, and is used by ==.Source§impl ResourceTypeMarker for StreamProcessorAddBufferRequest
impl ResourceTypeMarker for StreamProcessorAddBufferRequest
Source§type Borrowed<'a> = &'a mut StreamProcessorAddBufferRequest
type Borrowed<'a> = &'a mut StreamProcessorAddBufferRequest
Encode<Self>
type cheaply obtainable from &mut Self::Owned. There are three cases: Read moreSource§fn take_or_borrow<'a>(
value: &'a mut <Self as TypeMarker>::Owned,
) -> Self::Borrowed<'a>
fn take_or_borrow<'a>( value: &'a mut <Self as TypeMarker>::Owned, ) -> Self::Borrowed<'a>
&mut Self::Owned to Self::Borrowed. For
HandleBased types this is “take” (it returns an owned handle and
replaces value with Handle::invalid), and for all other types it is
“borrow” (just converts from one reference to another).Source§impl TypeMarker for StreamProcessorAddBufferRequest
impl TypeMarker for StreamProcessorAddBufferRequest
Source§type Owned = StreamProcessorAddBufferRequest
type Owned = StreamProcessorAddBufferRequest
Source§fn inline_align(_context: Context) -> usize
fn inline_align(_context: Context) -> usize
Source§fn inline_size(_context: Context) -> usize
fn inline_size(_context: Context) -> usize
inline_align.Source§fn encode_is_copy() -> bool
fn encode_is_copy() -> bool
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. Read moreSource§fn decode_is_copy() -> bool
fn decode_is_copy() -> bool
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.