Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Adds a backpressure signal to the streaming protocol. #248

Merged
merged 3 commits into from
Mar 16, 2021
Merged
Show file tree
Hide file tree
Changes from all commits
Commits
File filter

Filter by extension

Filter by extension

Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
27 changes: 26 additions & 1 deletion index.bs
Original file line number Diff line number Diff line change
Expand Up @@ -2129,7 +2129,26 @@ Video encoding sender stats include the following fields:
During a streaming session, the receiver should send stats with the
[=streaming-session-receiver-stats-event=] at the interval the sender requested.
It should send all of the following stats for all of the media streams it is
receiving. The [=streaming-session-receiver-stats-event=] message contains the
receiving.

If the receiver is using a buffer to hold frames before playing them out, it
should also send the status of that buffer using the `remote-buffer-status` field.
It can have one of three values:

- `enough-data`: The buffer has neither too much data nor insufficient data.
- `insufficient-data`: The buffer will underrun and not have sufficient frame
data at the time it is scheduled to be played out.
- `too-much-data`: At the current send rate, the buffer will overrun and future
frame data will be discarded before it can be played out.

A sender that receives a status of `insufficient-data` should increase its send
rate, or switch to a more efficient encoding for future frames. A sender that
receives a status of `too-much-data` should decrease its send rate.

If the receiver is playing frames immediately without buffering, it should always
report a buffering status of `enough-data`.

The [=streaming-session-receiver-stats-event=] message contains the
following fields:

: streaming-session-id
Expand Down Expand Up @@ -2170,6 +2189,9 @@ present, that indicates the value has not changed since the last value.
: cumulative-decode-delay
:: The sum of the time spent decoding frames received.

: remote-buffer-status : streaming-buffer-status
:: The status of the remote buffer for this encoding.

Video encoding receiver stats include the following fields. If not
present, that indicates the value has not changed since the last
value.
Expand All @@ -2189,6 +2211,9 @@ value.
: cumulative-decode-delay
:: The sum of the time spent decoding frames received.

: remote-buffer-status : streaming-buffer-status
:: The status of the remote buffer for this encoding.


Requests, Responses, and Watches {#requests-responses-watches}
===============================================================
Expand Down
8 changes: 8 additions & 0 deletions messages_appendix.cddl
Original file line number Diff line number Diff line change
Expand Up @@ -706,6 +706,12 @@ streaming-session-sender-stats-event = {
}] ; video
}

streaming-buffer-status = &(
enough-data: 0
insufficient-data: 1
too-much-data: 2
)

; type key 132
streaming-session-receiver-stats-event = {
1: uint; streaming-session-id
Expand All @@ -716,13 +722,15 @@ streaming-session-receiver-stats-event = {
? 3: microseconds ; cumulative-lost-duration
? 3: microseconds ; cumulative-buffer-delay
? 4: microseconds ; cumulative-decode-delay
? 5: streaming-buffer-status ; remote-buffer-status
}] ; audio
? 4: [1* {
1: uint ; encoding-id
? 2: uint ; cumulative-decoded-frames
? 3: uint ; cumulative-lost-frames
? 4: microseconds ; cumulative-buffer-delay
? 5: microseconds ; cumulative-decode-delay
? 6: streaming-buffer-status ; remote-buffer-status
}] ; video
}