You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
I know we're not allowed to talk about priorities any longer but I wanted to float another option.
The subscriber is in charge of prioritization:
Add order to SUBSCRIBE: ASC or DESC
Add priority to SUBSCRIBE: VarInt?
Remove send_order from OBJECT.
The publisher prioritizes streams based on:
let order = subscribe.order == DESC ? 1: -1;
subscribe.priority > object.group* order > -object.id
Depending on the QUIC API, publisher still needs to compute a send order for each stream. It can do this by inserting each stream into a priority queue based on the above comparison, using the resulting position in the queue as the send order. This was already a requirement for QUIC APIs that did not support a u64 send order.
Alternatively, a QUIC API could implement nested priority groups, perhaps something like sendGroup.
Pros: Order
The benefits of order=ASC are similar to the proposed FETCH API in #368.
Supports HLS/DASH-like experiences, where playback buffers instead of skips.
Supports VOD playback.
Supports advertisement playback.
Note that you could perform head-of-line blocking today* by issuing a SUBSCRIBE per group. However this is quite verbose, and it creates an RTT at the end of each group where the network is not being utilized.
Pros: Priority
Supports prioritizing unrelated tracks (from different encoders).
Supports prioritizing based on focus state (sideline cam > main cam)
Supports prioritizing high bitrate (main cam > sideline cam)
The encoder is dumb, unaware of network priorities.
These could only be performed today by rewriting send order at a relay, which is impossible without catalog access.
Cons
SUBSCRIBE is even more complicated.
No interleaved prioritizes between tracks/groups. (who cares?)
Publisher has to compute/update send order on each stream/datagram created.
Relay has to deduplicate conflicting SUBSCRIBEs
The main challenge is the last one. For example, two viewers could issue:
One dumb idea for the publisher prioritization dilemma is to put the "preferred" priority and order for each track in ANNOUNCE. A relay could choose to use this information when fetching upstream, instead of relying on the values provided by N subscribers.
However this would require switching ANNOUNCE to be per-track instead of per-namespace as it is currently.
I know we're not allowed to talk about priorities any longer but I wanted to float another option.
The subscriber is in charge of prioritization:
order
to SUBSCRIBE:ASC
orDESC
priority
to SUBSCRIBE:VarInt
?send_order
from OBJECT.The publisher prioritizes streams based on:
Depending on the QUIC API, publisher still needs to compute a send order for each stream. It can do this by inserting each stream into a priority queue based on the above comparison, using the resulting position in the queue as the send order. This was already a requirement for QUIC APIs that did not support a u64 send order.
Alternatively, a QUIC API could implement nested priority groups, perhaps something like sendGroup.
Pros: Order
The benefits of
order=ASC
are similar to the proposedFETCH
API in #368.Note that you could perform head-of-line blocking today* by issuing a SUBSCRIBE per group. However this is quite verbose, and it creates an RTT at the end of each group where the network is not being utilized.
Pros: Priority
These could only be performed today by rewriting send order at a relay, which is impossible without catalog access.
Cons
The main challenge is the last one. For example, two viewers could issue:
What does the relay send upstream? The idea behind publisher prioritization was to avoid this dilemma, but maybe there's another way we can solve it.
The text was updated successfully, but these errors were encountered: