class StreamOutputConstraints

A client which always immediately re-configures output buffers on

receipt of OnOutputConstraints() with buffer_constraints_action_required

true can safely ignore this field.

A client is permitted to ignore an OnOutputConstraints() message even with

buffer_constraints_action_required true if the client knows the server

has already been told to discard the remainder of the stream with the

same stream_lifetime_ordinal or if this stream_lifetime_ordinal field is

set to 0. The server is required to re-send needed output config via

OnOutputConstraints() with new stream_lifetime_ordinal and

buffer_constraints_action_required true, if the most recent completed

server-side output config isn't what the server wants/needs yet for the

new stream.

A client which always immediately re-configures output buffers on

receipt of OnOutputConstraints() with buffer_constraints_action_required

true can safely ignore this field.

A client is permitted to ignore an OnOutputConstraints() message even with

buffer_constraints_action_required true if the client knows the server

has already been told to discard the remainder of the stream with the

same stream_lifetime_ordinal or if this stream_lifetime_ordinal field is

set to 0. The server is required to re-send needed output config via

OnOutputConstraints() with new stream_lifetime_ordinal and

buffer_constraints_action_required true, if the most recent completed

server-side output config isn't what the server wants/needs yet for the

new stream.

A client which always immediately re-configures output buffers on

receipt of OnOutputConstraints() with buffer_constraints_action_required

true can safely ignore this field.

A client is permitted to ignore an OnOutputConstraints() message even with

buffer_constraints_action_required true if the client knows the server

has already been told to discard the remainder of the stream with the

same stream_lifetime_ordinal or if this stream_lifetime_ordinal field is

set to 0. The server is required to re-send needed output config via

OnOutputConstraints() with new stream_lifetime_ordinal and

buffer_constraints_action_required true, if the most recent completed

server-side output config isn't what the server wants/needs yet for the

new stream.

When the buffer constraints are delivered, they indicate whether action

is required. A false value here permits delivery of constraints which

are fresher without forcing a buffer reconfiguration. If this is false,

a client cannot assume that it's safe to immediately re-configure output

buffers. If this is true, the client can assume it's safe to immediately

configure output buffers once.

When not using dynamic buffers, a false value is deprecated and not sent

by any known servers.

When using dynamic buffers, a false value can be sent by the server to

update buffer_count_for_server_current, but that value will always be

less than or equal to dynamic_buffers_video_decoder_output_safe. A

client that prefers to just use

dynamic_buffers_video_decoder_output_safe can ignore new

StreamOutputConstraints if buffer_constraints_action_required false

(assuming the client has no other reason to pay attention to the

message). If a client is using buffer_count_for_server_current to

potentially save a few buffers for streams that explicitly allow for

that (unfortunately streams which specify a lower required DPB size are

fairly rare AFAICT), the client must pay attention to new values of

buffer_count_for_server_current even when

buffer_constraints_action_required false, and ensure that the codec will

have a buffer count available for the codec's use that's consistent with

the new value. The codec will not set true or false depending on how

many buffers the codec currently has available / free / seemingly for

the codec's use, because there's no way for the codec to reliably detect

that, as buffers can be opportunistically handed to the codec, yet

actually reserved for potential use (and potential "camping") by the

downstream pipeline (or similar).

A client is permitted to ignore buffer constraint versions which have

buffer_constraints_action_required false. The server is not permitted

to change buffer_constraints_action_required from false to true for the

same buffer_constraints_version_ordinal.

For each configuration, a client must use new buffers, never buffers

that were previously used for anything else, and never buffers

previously used for any other StreamProcessor purposes. This rule

exists for multiple good reasons, relevant to both mid-stream changes,

and changes on stream boundaries. A client should just use new buffers

each time.

When this is true, the server has already de-refed as many low-level

output buffers as the server can while still performing efficient

transition to the new buffers and will de-ref the rest asap. A Sync()

is not necessary to achieve non-overlap of resource usage to the extent

efficiently permitted by the formats involved.

If buffer_constraints_action_required is true, the server _must_ not

deliver more output data until after output buffers have been configured

(or re-configured) by the client.

When the buffer constraints are delivered, they indicate whether action

is required. A false value here permits delivery of constraints which

are fresher without forcing a buffer reconfiguration. If this is false,

a client cannot assume that it's safe to immediately re-configure output

buffers. If this is true, the client can assume it's safe to immediately

configure output buffers once.

When not using dynamic buffers, a false value is deprecated and not sent

by any known servers.

When using dynamic buffers, a false value can be sent by the server to

update buffer_count_for_server_current, but that value will always be

less than or equal to dynamic_buffers_video_decoder_output_safe. A

client that prefers to just use

dynamic_buffers_video_decoder_output_safe can ignore new

StreamOutputConstraints if buffer_constraints_action_required false

(assuming the client has no other reason to pay attention to the

message). If a client is using buffer_count_for_server_current to

potentially save a few buffers for streams that explicitly allow for

that (unfortunately streams which specify a lower required DPB size are

fairly rare AFAICT), the client must pay attention to new values of

buffer_count_for_server_current even when

buffer_constraints_action_required false, and ensure that the codec will

have a buffer count available for the codec's use that's consistent with

the new value. The codec will not set true or false depending on how

many buffers the codec currently has available / free / seemingly for

the codec's use, because there's no way for the codec to reliably detect

that, as buffers can be opportunistically handed to the codec, yet

actually reserved for potential use (and potential "camping") by the

downstream pipeline (or similar).

A client is permitted to ignore buffer constraint versions which have

buffer_constraints_action_required false. The server is not permitted

to change buffer_constraints_action_required from false to true for the

same buffer_constraints_version_ordinal.

For each configuration, a client must use new buffers, never buffers

that were previously used for anything else, and never buffers

previously used for any other StreamProcessor purposes. This rule

exists for multiple good reasons, relevant to both mid-stream changes,

and changes on stream boundaries. A client should just use new buffers

each time.

When this is true, the server has already de-refed as many low-level

output buffers as the server can while still performing efficient

transition to the new buffers and will de-ref the rest asap. A Sync()

is not necessary to achieve non-overlap of resource usage to the extent

efficiently permitted by the formats involved.

If buffer_constraints_action_required is true, the server _must_ not

deliver more output data until after output buffers have been configured

(or re-configured) by the client.

When the buffer constraints are delivered, they indicate whether action

is required. A false value here permits delivery of constraints which

are fresher without forcing a buffer reconfiguration. If this is false,

a client cannot assume that it's safe to immediately re-configure output

buffers. If this is true, the client can assume it's safe to immediately

configure output buffers once.

When not using dynamic buffers, a false value is deprecated and not sent

by any known servers.

When using dynamic buffers, a false value can be sent by the server to

update buffer_count_for_server_current, but that value will always be

less than or equal to dynamic_buffers_video_decoder_output_safe. A

client that prefers to just use

dynamic_buffers_video_decoder_output_safe can ignore new

StreamOutputConstraints if buffer_constraints_action_required false

(assuming the client has no other reason to pay attention to the

message). If a client is using buffer_count_for_server_current to

potentially save a few buffers for streams that explicitly allow for

that (unfortunately streams which specify a lower required DPB size are

fairly rare AFAICT), the client must pay attention to new values of

buffer_count_for_server_current even when

buffer_constraints_action_required false, and ensure that the codec will

have a buffer count available for the codec's use that's consistent with

the new value. The codec will not set true or false depending on how

many buffers the codec currently has available / free / seemingly for

the codec's use, because there's no way for the codec to reliably detect

that, as buffers can be opportunistically handed to the codec, yet

actually reserved for potential use (and potential "camping") by the

downstream pipeline (or similar).

A client is permitted to ignore buffer constraint versions which have

buffer_constraints_action_required false. The server is not permitted

to change buffer_constraints_action_required from false to true for the

same buffer_constraints_version_ordinal.

For each configuration, a client must use new buffers, never buffers

that were previously used for anything else, and never buffers

previously used for any other StreamProcessor purposes. This rule

exists for multiple good reasons, relevant to both mid-stream changes,

and changes on stream boundaries. A client should just use new buffers

each time.

When this is true, the server has already de-refed as many low-level

output buffers as the server can while still performing efficient

transition to the new buffers and will de-ref the rest asap. A Sync()

is not necessary to achieve non-overlap of resource usage to the extent

efficiently permitted by the formats involved.

If buffer_constraints_action_required is true, the server _must_ not

deliver more output data until after output buffers have been configured

(or re-configured) by the client.

Setter for buffer_constraints.