Code change:
MOQ protocol specifications will provide details on the supported media encapsulation(s). <ins> 4.6.1. Some video codecs have a complex structure.  Consider an application using both temporal layering and spatial layering.  It would send for example: an object representing the 30 fps frame at 720p an object representing the spatial enhancement of that frame to 1080p an object representing the 60 fps frame at 720p an object representing the spatial enhancement of that 60 fps frame to 1080p The encoding of the 30 fps frame depends on the previous 30 fps frames, but not on any 60 fps frame.  The encoding of the 60 fps depends on the previous 30 fps frames, and possibly also on the previous 60 fps frames (there are options).  The encoding of the spatial enhancement depends on the corresponding 720p frames, and also on the previous 1080p enhancements.  Add a couple of layers, and the expression of dependencies can be very complex.  The AV1 documentation for example provides schematics of a video stream with 3 frame rate options at 15, 30 and 60 fps, and two definition options, with a complex graph of dependencies.  Other video encodings have similar provisions.  They may differ in details, but there are constants: if some object is dropped, then all objects that have a dependency on it are useless. 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. 4.6.2. The conversion from dependency graph to linear ordering is not unique.  The simple graph in our example could be ordered either "frame rate first" versus "definition first".  If the application chooses frame rate first, the policy is expressed as "in case of congestion, drop the spatial enhancement objects first, and if that is not enough drop the 60 fps frames".  If the application chooses "definition first", the policy becomes "drop the 60 fps frames and their corresponding 1080p enhancement first, and if that is not enough also drop the 1080p enhancement of the 30 fps frames". More complex graphs will allow for more complex policies, maybe for example "15 fps at 720p as a minimum, but try to ensure at least 30fps, then try to ensure 1080p, and if there is bandwidth available forward 60 fps at 1080p".  Such linearization requires choices, and the choices should be made by the application, based on the user experience requirements of the application. The relays will not understand all the variation of what the media is but the applications will need a way to indicate to the relays the information they will need to correctly order which data is sent first. 4.6.3. We propose to express dependencies using a combination of object number and object priority. Let's consider our example of an encoding providing both spatial enhancement and frame rate enhancement options, and suppose that the application has expressed a preference for frame rate.  We can express that policy as follow: the frames are ordered first by time and when the time is the same by resolution.  This determines the "object number" property. the frame priority will be set to 1 for the 720p 30 fps frame, 2 for the 720p 60 fps frames, and 3 for all the enhancement frames. If the application did instead express a preference for definition, object numbers will be assigned in the same way, but the priorities will be different: the frame priority will be set to 1 for the 720p 30 fps I frames and 2 for the 720p 30 fps P and B frames, 3 and 4 for the 1080p enhancements of the 60 fps frames, and 5 and 6 for the 60 fps frames and their enhancements. Object numbers and priorities will be set by the publisher of the track, and will not be modified by the relays. </ins> 4.7. Receivers SHOULD be able to as part of negotiation of a session MOQ-

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?