Code change:
control of packetization and transmission, with addtional support for retransmission as an optional extension. <ins> To provide an overview of interactive use cases, we can consider a conferencing session comprised of: Multiple emitters, publishing on multiple tracks (audio, video tracks and at different qualities) A media switch, sourcing tracks that represent a subset of tracks from across all the emitters.  Such subset may represent tracks representing top 5 speakers at higher qualities and lot of other tracks for rest of the emitters at lower qualities. Multiple receivers, with varied receiving capacity (bandwidth limited), subscribing to subset of the tracks This setup relies on the following functionalities: Media Switches source new tracks but retain the media payload from the original emitters.  This implies publishing new Track IDs sourced from the SFU, with object payload unchanged from the original emitters. Media Switches propagate a subset of tracks as-is from the emitters to the subscribers.  This implies Track IDs to be unchanged between the emitters and the receivers. Subscribers explictly request one or more media tracks in appropriate qualities and dynamically move between the qualtiies during the course of the session. Another topology for the conferencing use-case is to use multiple distribution networks for delivering the media, with media switching functionality running across distribution networks and these media functions as part of the core distribution network as shown below. Such a topology needs to meet all the properties listed in the homogenous topology setup, however having multiple distribution networks, and relying on the distribution networks to carry out the media delivery, brings in further requirements towards a data model that enables tracks to be uniquely identifiable across the distribution networks and not just within a single distribution network. </ins> 3.1.1. In this use case the computation for running a video game (single or

Related discussion:
text: I think you're referring to the scalabilty mode known as "L2T2h": URL Of course, we could encode these dependencies as properties of the object being sent, stating for example that "object 17 can only be decoded if objects 16, 11 and 7 are available." However, this approach leads to a lot of complexity in relays. We believe that a linear approach is preferable, using attributes of objects like delivery order or priorities. [BA] Why would this lead to complexity in relays in a receiver-driven scenario? The relay would only forward the layers that the receiver asked for, and wouldn't have to store state relating to the receivers. Also, the real issue here isn't dropping layers, which can occur at any point. The reason dependencies (and more) are needed (and why the "linear approach" doesn't work) comes when it is desired to add layers. It is of course possible just to start forwarding additional layers, but that doesn't improve quality unless the forwarded frames can actually be decoded. To figure this out, whoever is in charge (receiver or relay) needs to be able to determine the "upswitch points". This also implies feedback from the receivers to the encoder (e.g. LRR). Section 4.2 We propose to express dependencies using a combination of object number and object priority. [BA] How would this permit restoration of video quality after congestion clears up? I don't think you have enough information. Section 4.3 . Relay behavior In case of congestion, the relay will use the priorities to selectively drop the "least important" objects: [BA] Dropping is easy, it's adding layers back (and decoding them) that's hard.