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: Note - this is a rough draft, although I have done some edits while adding this material. I do have notes for to-dos, and I'm pretty sure I want to figure out how to do the diagrams in some way that will format with straight lines, for starters.
I'm happy to just merge this in now as is just to unblock other work and make progress, and make any adjustments later because there's nothing that stands out as controversial, NAME are you okay with this?
We have a plan on how to resolve our terminology migration for in this PR
Based on review comments from NAME on the mailing list .
Draft is in suhasHere/moq-drafts.
NAME - NAME and I are starting with the scenarios from URL
NAME - I think it would be good to close this issue when we have a reasonable plan for where the material from the scenarios draft goes, and then handle further changes via issues and PRs as usual. Does that make sense? NAME NAME and NAME - I wanted to let you know that NAME and I are (finally, finally!) merging text from the scenarios draft in the requirements draft, as NAME suggested. I think I have homes for almost all of the text from the requirements draft, but I do have some work to do, so that the material is in the right place, and that it flows with text from the previous version of the requirements draft. I am, of course, always interested in comments. And thank you each for the work you did on this material.
Awesome - let me know if something I can do to help
Thanks NAME .. look forward to the updates. +1 to NAME , please let me know if we can be of any help Here is my review. Firstly, I'd like to say that this document is badly needed. The requirements document doesn't get into the level of detail that this document does, and I think that this level of detail is important to make progress on the design. Terminology I think it would be useful to define some of the terminology, including terms like "track" and "media switch". Section 2.2 A few questions: Are the trackIDs "t1, t2, t3" separate MediaStreamTracks, or are they just multiple encodings of the same track?