Signed versus unsigned

[aboba]

is timestamp really intended to be a signed long long? Typically, timestamps are unsigned.

Had the same question about decodeQueueSize and encodeQueueSize. Those can't be negative, right?

[wolenetz]

In various container formats, negative frame timestamps can sometimes be useful to indicate stream cropping or decoder preroll. For example, in WebM: https://bugs.chromium.org/p/chromium/issues/detail?id=271794#c14.

[sandersdan]

timestamp is signed because timestamps have an arbitrary origin and can therefore be negative. Typically they start at zero, but even then it's common for some intermediate timestamps to be negative (eg. negative DTS with zero PTS). It seemed that forcing non-negative here would make those situations unnecessarily complex for apps to handle.

duration is unsigned because a negative value there isn't well defined. There are reasonable interpretations available but nothing I am aware of that simplifies API usage.

Queue sizes can't be negative. They were originally modelled after the Streams API which can have negative queue space available, but differ enough now that there is no reason for them to be signed still.

[dalecurtis]

signed timestamps were resolved here #122 (comment)

[aboba]

@sandersdan Thanks! Would it make sense to provide a PR to make the queue sizes unsigned?

[chcunningham]

Editors call: WebAudio and WebRTC seem to use unsigned for these types of counts. SGTM