Code change:
3.2.3. <del> Where media is received from a live broadcast or stream either as a broadcast with fixed duration or as ongoing 24/7 output.  The number of receivers may vary depending on the type of content; breaking news events may see sharp, sudden spikes, whereas sporting and entertainment events may see a more gradual ramp up with a higher sustained peak with some changes based on match breaks or interludes. </del> <ins> In a reference live streaming example shown below, the emitter streams one or more tracks as part of the application operated under a provider domain, which is then distributed to multiple clients using some form of distribution server operating under the same provider domain, over a content distribution network. In this setup, one can visualize the ingest and distribution as two separate systems operating within a given provider domain.  One implication of this organization is that the Track Ids used by the emitter need not match the ones referred to by the subscribers.  This can be the case because the distribution server sources the media as new tracks (for instance, if the media is transcoded after ingest) In Live Media Streaming, media might be received from a live broadcast or stream either as a broadcast with fixed duration or as ongoing 24/7 output.  The number of receivers may vary depending on the type of content; breaking news events may see sharp, sudden spikes, whereas sporting and entertainment events may see a more gradual ramp up with a higher sustained peak with some changes based on match breaks or interludes. </ins> Such broadcasts may comprise of multiple audio or video outputs with different codecs or bitrates, and may also include other types of

Related discussion:
text: Section 3.1 For example, rather than waiting for 30 seconds before connecting, the user might quickly download the "key" frames of the past 30 seconds and replay them in order to "synchronize" the video decoder. [BA] I think this sentence points out that the term "access point" may need to be clarified, because in such a scenario, the term "access point" may have a different meaning in stored media than in media transmitted over the wire to speed up join latency. Section 3.2 It is possible to use groups as units of congestion control. When the sending strategy is understoud, the objects in the group can be assigned sequence numbers and drop priorities that capture the encoding dependencies, such that: an object can only have dependencies with other objects in the same group, an object can only have dependencies with other objects with lower sequence numbers, an object can only have dependencies with other objects with lower or equal drop priorities. [BA] This text seems to be mixing distinct concepts such as dependencies and layering. In layered coding, there is typically only a requirement not to depend on higher layers, but it's possible to depend on frames in lower layers. Mixing drop priority (a transport concept) with groups seems confusing to me. The main drawback is that if a packet with a given drop priority is actually dropped, all objects with higher sequence numbers and higher or equal drop priorities in the same group must be dropped. [BA] Leaving gaps in the sequence number space does seem problematic, but that's a choice, not a requirement. If the group duration is long, this means that the quality of experience may be lowered for a long time after a brief congestion. If the group duration is short, this can produce a jarring effect in which the quality of experience drops perdiodically at the tail of the group. [BA] What does "group duration" mean? Are you referring to time between I-frames? This paragraph seems to assume that group duration is a constant rather than something which can be set dynamically. Section 4 Some video codecs have a complex structure. [BA] Are you referring to codecs, or encodings? It would send for example: [BA] A picture might help here.