class OnOutputTimestampHasNoOutput

Most clients can ignore the `OnOutputTimestampHasNoOutput` message.

`OnOutputTimestampHasNoOutput` is only sent by `StreamProcessor` servers

with `supports_dynamic_buffers` true.

When the server determines that a previous input packet with a given

`timestamp_ish` value will never generate any output, the server will

send this message with the `timestamp_ish` value.

This message can be thought of as a stand-in for `OnOutputPacket` when

the server eventually determines that the timestamp will never generate

any output; this is why the name starts with "OnOutput". Similar to

messages indicating output, the server will not send this message when

there is an in-progress stream-driven output re-config in progress (as

occurs starting with `OnOutputConstraints`).

While servers should send this message as soon as allowed, feasible, and

practical, there is no specific timeliness guarantee regarding when this

message will be sent by a server. For some input packets that don't

generate any output, the server may send this message fairly soon after

consuming the corresponding input packet. For other input packets that

don't generate any output, the server may not send this message until

the server can prove that the corresponding input packet will never

generate any output via delayed means such as, for example, logic

involving `max_num_reorder_frames`, or any relevant

bitstream-format-specific logic. The server is allowed to not send this

message until substantially more input is received and processed by the

server. The client must not attempt to wait on reception of this message

before sending more input, as that would create a potential deadlock.

When sent, this message will be sent at some time after the

`OnFreeInputPacket` message for the corresponding input packet that had

the same `timestamp_ish` value. The client must not delay re-use of the

input buffer until after reception of `OnOutputTimestampHasNoOutput`

because that would create a potential deadlock.

When sent, this message will be sent before the `OnOutputEndOfStream`

message for the `stream_lifetime_ordinal` stream. A server is not

required to send `OnOutputTimestampHasNoOutput` for all unresolved (in

terms of output yes/no) input timestamp_ish values prior to sending

`OnOutputEndOfStream`, and the `OnOutputEndOfStream` unambiguously

resolves the (output yes/no) status of any remaining input timestamp_ish

values tracked by the client.

The server must not output the indicated timestamp_ish value in a later

OnOutputPacket, unless the client is not ensuring that timestamp_ish

values are unique and the client is re-using the timestamp_ish value on

another input packet. The server-side mechanism to achieve this robustly

can be bitstream format specific and codec implementation specific.

This message is not required to be sent by the server when the reason

for an input packet not generating output is the client switching to a

new stream without FlushEndOfStreamAndCloseStream, stream failure, or

codec failure.

If the client is ensuring that all input packets with a given

`stream_lifetime_ordinal` have unique `timestamp_ish` values, then the

client can use this message to determine which input packet will never

generate any output.

If the client is not ensuring that all input packets have a unique

timestamp_ish value, then the client should always ignore this message,

as the protocol makes no particular gaurantees regarding this message in

this case (it may not be possible for any such client to disambiguate

which input packet is meant, the server may not send this message as

many times as there were input packets with the same `timestamp_ish`

value, the server may not send this message at all once it notices any

non-unique `timestamp_ish` values, etc).

Effective and robust use of this message may require the client to

assign timestamp_ish values as sequential unsigned 64 bit numbers, and

keep any corresponding real timestamps locally in the client.

If a client doesn't have any specific reason to pay attention to this

event, the client should ignore this event. Most clients can completely

ignore this event with no adverse impact.