class StreamProcessorAddBufferRequest

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

Must be set. Which port (input or output) the buffer is for.

Must be set. Which port (input or output) the buffer is for.

Must be set. Which port (input or output) the buffer is for.

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.

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.