class StreamBufferPartialSettings

Each buffer is associated with a `buffer_lifetime_ordinal` value.

There is a separate buffer_lifetime_ordinal for input vs. output.

Values must be odd. Values must only increase (increasing by more than 2

is permitted).

When using `SetInputBufferPartialSettings` or

`SetOutputBufferPartialSettings`, re-use of the same value (considering

input and output separately) for the new message is not allowed. Using

these messages, all the buffers of a given buffer_lifetime_ordinal value

are allocated as one sysmem buffer collection.

When a new buffer_lifetime_ordinal starts, that also automatically

starts un-registering and releasing any buffers associated with prior

buffer_lifetime_ordinal values, but does not force them to complete

un-registration (or release) if they're still used by the codec for

reference purposes (VP9 can do this across a mid-stream dimensions

switch). A buffer can still be output by the server (as indicated by an

output packet) until un-registration completes.

If the client wants the server to drop all buffers quickly, the client

can send `CloseCurrentStream` with `release_input_buffers` and/or

`release_output_buffers` set. This of course also stops decode of the

current stream. Closing the `StreamProcessor` client end is another

option.

Each buffer is associated with a `buffer_lifetime_ordinal` value.

There is a separate buffer_lifetime_ordinal for input vs. output.

Values must be odd. Values must only increase (increasing by more than 2

is permitted).

When using `SetInputBufferPartialSettings` or

`SetOutputBufferPartialSettings`, re-use of the same value (considering

input and output separately) for the new message is not allowed. Using

these messages, all the buffers of a given buffer_lifetime_ordinal value

are allocated as one sysmem buffer collection.

When a new buffer_lifetime_ordinal starts, that also automatically

starts un-registering and releasing any buffers associated with prior

buffer_lifetime_ordinal values, but does not force them to complete

un-registration (or release) if they're still used by the codec for

reference purposes (VP9 can do this across a mid-stream dimensions

switch). A buffer can still be output by the server (as indicated by an

output packet) until un-registration completes.

If the client wants the server to drop all buffers quickly, the client

can send `CloseCurrentStream` with `release_input_buffers` and/or

`release_output_buffers` set. This of course also stops decode of the

current stream. Closing the `StreamProcessor` client end is another

option.

Each buffer is associated with a `buffer_lifetime_ordinal` value.

There is a separate buffer_lifetime_ordinal for input vs. output.

Values must be odd. Values must only increase (increasing by more than 2

is permitted).

When using `SetInputBufferPartialSettings` or

`SetOutputBufferPartialSettings`, re-use of the same value (considering

input and output separately) for the new message is not allowed. Using

these messages, all the buffers of a given buffer_lifetime_ordinal value

are allocated as one sysmem buffer collection.

When a new buffer_lifetime_ordinal starts, that also automatically

starts un-registering and releasing any buffers associated with prior

buffer_lifetime_ordinal values, but does not force them to complete

un-registration (or release) if they're still used by the codec for

reference purposes (VP9 can do this across a mid-stream dimensions

switch). A buffer can still be output by the server (as indicated by an

output packet) until un-registration completes.

If the client wants the server to drop all buffers quickly, the client

can send `CloseCurrentStream` with `release_input_buffers` and/or

`release_output_buffers` set. This of course also stops decode of the

current stream. Closing the `StreamProcessor` client end is another

option.

This value indicates which version of constraints the client is/was

aware of so far.

For input, this must always be 0 because constraints don't change for

input (settings can change, but there's no settings vs current

constraints synchronization issue on input).

For output, this allows the server to know when the client is

sufficiently caught up before the server will generate any more output.

When there is no active stream, a client is permitted to re-configure

buffers again using the same buffer_constraints_version_ordinal.

This value indicates which version of constraints the client is/was

aware of so far.

For input, this must always be 0 because constraints don't change for

input (settings can change, but there's no settings vs current

constraints synchronization issue on input).

For output, this allows the server to know when the client is

sufficiently caught up before the server will generate any more output.

When there is no active stream, a client is permitted to re-configure

buffers again using the same buffer_constraints_version_ordinal.

This value indicates which version of constraints the client is/was

aware of so far.

For input, this must always be 0 because constraints don't change for

input (settings can change, but there's no settings vs current

constraints synchronization issue on input).

For output, this allows the server to know when the client is

sufficiently caught up before the server will generate any more output.

When there is no active stream, a client is permitted to re-configure

buffers again using the same buffer_constraints_version_ordinal.

Setter for single_buffer_mode.

Setter for packet_count_for_server.

Setter for packet_count_for_client.

Setter for sysmem_token.

The client end of a BufferCollectionToken channel, which the

StreamProcessor will use to deliver constraints to sysmem and learn of

buffers allocated by sysmem.

The client guarantees that the token is already known to sysmem (via

BufferCollectionToken.Sync(), BufferCollection.Sync(), or

BufferCollectionEvents.OnDuplicatedTokensKnownByServer()).

The client end of a BufferCollectionToken channel, which the

StreamProcessor will use to deliver constraints to sysmem and learn of

buffers allocated by sysmem.

The client guarantees that the token is already known to sysmem (via

BufferCollectionToken.Sync(), BufferCollection.Sync(), or

BufferCollectionEvents.OnDuplicatedTokensKnownByServer()).

The client end of a BufferCollectionToken channel, which the

StreamProcessor will use to deliver constraints to sysmem and learn of

buffers allocated by sysmem.

The client guarantees that the token is already known to sysmem (via

BufferCollectionToken.Sync(), BufferCollection.Sync(), or

BufferCollectionEvents.OnDuplicatedTokensKnownByServer()).