Adding a congestion control option for "Group based + priorities(3)". It is the same as group based, but in WARP transport mode, it also marks down the priorities of all but the last group (last uni stream).
The combination of group based + priorities will actually degrade performance, unless the receiver selects the option "quicrq_subscribe_in_order_skip_to_group_ahead", which cause receivers to process the next group as soon as reception begins, ignoring the tail of the previous group. If that option is selected, performance is actually better than the simple group based option.
The graph above shows the end to end delay per frame for the "basic warp" a "warp + priority" options. The use of priorities limits the possible delay increase caused by the large I-frames at the beginning of a UNI stream. This appears to be a very robust solution, with just one downside: in case of congestion, the delay will increase gradually, until the "jump ahead" at the beginning of the next GOP. That may not be the best visual experience. If we want to fix that, we probably need to design a combination of this "group based" strategy with the "delay base" strategy, to drop low priority frames and reduce delays without waiting for the next block.
Adding a congestion control option for "Group based + priorities(3)". It is the same as group based, but in WARP transport mode, it also marks down the priorities of all but the last group (last uni stream).
The combination of group based + priorities will actually degrade performance, unless the receiver selects the option "quicrq_subscribe_in_order_skip_to_group_ahead", which cause receivers to process the next group as soon as reception begins, ignoring the tail of the previous group. If that option is selected, performance is actually better than the simple group based option.
The graph above shows the end to end delay per frame for the "basic warp" a "warp + priority" options. The use of priorities limits the possible delay increase caused by the large I-frames at the beginning of a UNI stream. This appears to be a very robust solution, with just one downside: in case of congestion, the delay will increase gradually, until the "jump ahead" at the beginning of the next GOP. That may not be the best visual experience. If we want to fix that, we probably need to design a combination of this "group based" strategy with the "delay base" strategy, to drop low priority frames and reduce delays without waiting for the next block.