[{"author": "Suhas Nandakumar", "text": "
i can hear and see fine
", "time": "2023-03-07T14:05:08Z"}, {"author": "Alan Frindell", "text": "Perhaps there's a prize for the scribe
", "time": "2023-03-07T14:06:28Z"}, {"author": "Martin Duke", "text": "I can do it
", "time": "2023-03-07T14:06:51Z"}, {"author": "Alan Frindell", "text": "We can use this in Yokohama: https://wheelofnames.com/
", "time": "2023-03-07T14:07:20Z"}, {"author": "Martin Duke", "text": "When you say something at the mic, I suggest you have a look to make sure I captured it correctly
", "time": "2023-03-07T14:07:30Z"}, {"author": "Cullen Jennings", "text": "Our others getting static / clipping from Ted's mic ?
", "time": "2023-03-07T14:07:59Z"}, {"author": "Alan Frindell", "text": "yes
", "time": "2023-03-07T14:08:04Z"}, {"author": "Suhas Nandakumar", "text": "yes
", "time": "2023-03-07T14:08:08Z"}, {"author": "Mo Zanaty", "text": "Yes
", "time": "2023-03-07T14:08:19Z"}, {"author": "Hang Shi", "text": "Yes
", "time": "2023-03-07T14:08:30Z"}, {"author": "Jordi Cenzano", "text": "Yes, I rejoined in case it was me and the static is still there
", "time": "2023-03-07T14:08:46Z"}, {"author": "Mo Zanaty", "text": "Very low audio level too.
", "time": "2023-03-07T14:08:47Z"}, {"author": "Mirja K\u00fchlewind", "text": "seems to be meet echo problem...?
", "time": "2023-03-07T14:09:11Z"}, {"author": "Mirja K\u00fchlewind", "text": "gone for me now
", "time": "2023-03-07T14:09:23Z"}, {"author": "Alan Frindell", "text": "me too
", "time": "2023-03-07T14:09:29Z"}, {"author": "Cullen Jennings", "text": "Yah , I am hearing same as Mirja
", "time": "2023-03-07T14:09:36Z"}, {"author": "Jordi Cenzano", "text": "Yes, now is ok. But I heard that from Spencer
", "time": "2023-03-07T14:09:38Z"}, {"author": "Jordi Cenzano", "text": "too
", "time": "2023-03-07T14:09:45Z"}, {"author": "Victor Vasiliev", "text": "I don't believe we have an architecture draft
", "time": "2023-03-07T14:10:01Z"}, {"author": "Suhas Nandakumar", "text": "I have some work in progress on it , inspired by comments on the data model PR ..
", "time": "2023-03-07T14:11:50Z"}, {"author": "Mirja K\u00fchlewind", "text": "@ted audio is fine again. I don't think it was your mic
", "time": "2023-03-07T14:12:10Z"}, {"author": "Suhas Nandakumar", "text": "it above meant architecture draft !
", "time": "2023-03-07T14:12:41Z"}, {"author": "Spencer Dawkins", "text": "Victor Vasiliev said:
\n\n\nI don't believe we have an architecture draft
\n
I agree. One theory is that at least some of the stuff I'm presenting would go in an architecture draft, but James is likely to put that in the (use case and) requirements draft, because we do have that draft ...
", "time": "2023-03-07T14:13:54Z"}, {"author": "Will Law", "text": "MoQ at needs to convey the selection criteria so that clients can choose the tracks they want to subscribe to. This will most likely be contained within the catalog.
", "time": "2023-03-07T14:17:47Z"}, {"author": "Spencer Dawkins", "text": "Will Law said:
\n\n\nMoQ at needs to convey the selection criteria so that clients can choose the tracks they want to subscribe to. This will most likely be contained within the catalog.
\n
I agree. ISTM that we are still deciding where MOQ starts and where MOQ stops. :grinning_face_with_smiling_eyes:
", "time": "2023-03-07T14:21:10Z"}, {"author": "Cullen Jennings", "text": "If I was doing layered encoding, are two different layers the same track or two ?
", "time": "2023-03-07T14:21:18Z"}, {"author": "Ali Begen", "text": "meetecho gets disconnected and only a refresh brings it back. any others having issues?
", "time": "2023-03-07T14:21:18Z"}, {"author": "Victor Vasiliev", "text": "For what it's worth, the current WARP draft does not require objects to be atomic, I believe it actually asks for partial object delivery
", "time": "2023-03-07T14:21:34Z"}, {"author": "Victor Vasiliev", "text": "Atomic objects are nice for video, but it's kind of hard to do audio this way without too much overhead
", "time": "2023-03-07T14:21:52Z"}, {"author": "Suhas Nandakumar", "text": "we need to describe what a object is and it is pretty open today
", "time": "2023-03-07T14:22:00Z"}, {"author": "Luke Curley", "text": "@cullen not sure, ex. a 360p base layer and a 720p enhancement layer
", "time": "2023-03-07T14:23:16Z"}, {"author": "Suhas Nandakumar", "text": "+1 that for encrypted media, partial object data is not useful
", "time": "2023-03-07T14:23:18Z"}, {"author": "Luke Curley", "text": "partial object data is absolutely useful when media is encrypted using a stream cipher
", "time": "2023-03-07T14:23:43Z"}, {"author": "Alan Frindell", "text": "can the partial usability be a property of an object?
", "time": "2023-03-07T14:24:20Z"}, {"author": "Luke Curley", "text": "ex. a CTR cipher can even be decrypted in the presense of gaps
", "time": "2023-03-07T14:24:35Z"}, {"author": "Victor Vasiliev", "text": "You still need to read the auth tag, though
", "time": "2023-03-07T14:25:11Z"}, {"author": "Luke Curley", "text": "^ depends on the cipher, and how frequently the auth tag is emitted (ex. every frame?)
", "time": "2023-03-07T14:25:31Z"}, {"author": "Luke Curley", "text": "I'm just saying that encryption doesn't require atomic delivery
", "time": "2023-03-07T14:26:05Z"}, {"author": "Spencer Dawkins", "text": "\"a little bit of architecture\" - I think we're going to see a lot of little bits of architecture today (I'm sure that we will in the relays presentation as well!
", "time": "2023-03-07T14:27:58Z"}, {"author": "Richard Barnes", "text": "@Luke encryption absolutely requires atomic delivery
", "time": "2023-03-07T14:29:46Z"}, {"author": "Richard Barnes", "text": "we are definitely going to use AEAD encryption, and a partial AEAD ciphertext is useless
", "time": "2023-03-07T14:30:03Z"}, {"author": "Victor Vasiliev", "text": "It only requires atomic delivery if your encryption boundaries are object boundaries
", "time": "2023-03-07T14:30:13Z"}, {"author": "Richard Barnes", "text": "it requires atomic delivery at the level of ciphertexts, yes
", "time": "2023-03-07T14:30:30Z"}, {"author": "Alan Frindell", "text": "Will there be media conveyed that might not require end-to-end encryption or atomicity?
", "time": "2023-03-07T14:30:33Z"}, {"author": "Richard Barnes", "text": "to be clear @Luke, ciphers like CTR are not going to be acceptable here
", "time": "2023-03-07T14:30:42Z"}, {"author": "Suhas Nandakumar", "text": "if we scope object to be unit of video frame and that as input to encryption, then we deal away with partial object issue .. we need to keep this simple
", "time": "2023-03-07T14:31:34Z"}, {"author": "Ted Hardie", "text": "I think if we called this a \"trackset\" or something, this might be clearer, since \"emission\" is as overloaded as everything else.
", "time": "2023-03-07T14:32:14Z"}, {"author": "Luke Curley", "text": "so we're talking about DRM, and existing schemes typically are encrypted on a frame-by-frame basis, which means you don't need the entire segment
", "time": "2023-03-07T14:32:16Z"}, {"author": "Victor Vasiliev", "text": "Sure, but if you scope it to an audio frame, and your audio frame is 20ms, you get 50 object headers per second, which might be problematic for low-bitrate audio codecs
", "time": "2023-03-07T14:32:38Z"}, {"author": "Luke Curley", "text": "and yeah, AEAD is ideal, but for example HLS supports AES-CBC...
", "time": "2023-03-07T14:32:40Z"}, {"author": "Alan Frindell", "text": "is there a common property for all tracks in a \"trackset\"?
", "time": "2023-03-07T14:33:23Z"}, {"author": "Richard Barnes", "text": "let me put it this way -- you're going to need a very good reason to do anything non-AEAD :)
", "time": "2023-03-07T14:33:28Z"}, {"author": "Richard Barnes", "text": "and i don't think \"but HLS does it\" really counts
", "time": "2023-03-07T14:33:46Z"}, {"author": "Cullen Jennings", "text": "I think before we spend a long time gretting to the point that the object was the smallest thing you can use. So if there is some sub part of them, I would prefer call the smallest thing object and make new name for larger thing.
", "time": "2023-03-07T14:33:51Z"}, {"author": "Luke Curley", "text": "keep in mind that TLS is already used to ensure confidentially; this extra layer of encryption is meant to be annoying (DRM) or provide some basic authenticity
", "time": "2023-03-07T14:33:55Z"}, {"author": "Suhas Nandakumar", "text": "+1 cullen
", "time": "2023-03-07T14:34:18Z"}, {"author": "Ted Hardie", "text": "@Alan in this context \"A trackset is any set of tracks authorized together\" (but think of it as a \"fleen\"--a to-be-defined term, rather than a set theory thing.
", "time": "2023-03-07T14:34:41Z"}, {"author": "Victor Vasiliev", "text": "@Luke -- well, the confidentiality is confidentiality against the relays in this case, so it's within TLS
", "time": "2023-03-07T14:34:53Z"}, {"author": "Luke Curley", "text": "yeah okay, that's true
", "time": "2023-03-07T14:35:05Z"}, {"author": "Victor Vasiliev", "text": "@Cullen -- well, the unit lower than object in this case is just \"byte\"
", "time": "2023-03-07T14:36:01Z"}, {"author": "Cullen Jennings", "text": "I think the confidentially Mo was talking about was actualy in the end to end media case. So DRM for some cases, but for meeetings it is not so much DRM as more something like MLS or other end to end crypto.
", "time": "2023-03-07T14:36:23Z"}, {"author": "Martin Duke", "text": "going downstairs for coffee: you're losing scribe support for ~1min
", "time": "2023-03-07T14:36:51Z"}, {"author": "Ali Begen", "text": "Synchronization is really the worst term for this
", "time": "2023-03-07T14:37:28Z"}, {"author": "Ali Begen", "text": "Call it stream access point or something
", "time": "2023-03-07T14:37:39Z"}, {"author": "Suhas Nandakumar", "text": "@cullen what is object from your definition, @victor what is object from your point of video
", "time": "2023-03-07T14:37:57Z"}, {"author": "Will Law", "text": "Agree. Sychroniation implies timeline matching. THis is aboiut a \"join point\" or \"access point\"
", "time": "2023-03-07T14:37:59Z"}, {"author": "Jordi Cenzano", "text": "+1 Ali,Will
", "time": "2023-03-07T14:38:28Z"}, {"author": "Martin Duke", "text": "the scribe is back
", "time": "2023-03-07T14:38:35Z"}, {"author": "Cullen Jennings", "text": "what would people think of \"checkpoint\" in the sense of a decode checkpoint ?
", "time": "2023-03-07T14:38:43Z"}, {"author": "Victor Vasiliev", "text": "My proposal was \"join point\", fwiw
", "time": "2023-03-07T14:38:59Z"}, {"author": "Ali Begen", "text": "lets not really create personal favorites if possible
", "time": "2023-03-07T14:39:26Z"}, {"author": "Jordi Cenzano", "text": "IDR (Instantaneous Decoder Refresh) is already a used term
", "time": "2023-03-07T14:39:43Z"}, {"author": "Ali Begen", "text": "SAP is the proper term used in many mpeg standards
", "time": "2023-03-07T14:39:45Z"}, {"author": "Ali Begen", "text": "IDR is different Jordi
", "time": "2023-03-07T14:40:02Z"}, {"author": "Luke Curley", "text": "yeah, to Jordi's point, the important property is that a GROUP is independently decodable
", "time": "2023-03-07T14:40:08Z"}, {"author": "Cullen Jennings", "text": "+1 to Luke, more important what the properties of this thing is that what we call it.
", "time": "2023-03-07T14:40:49Z"}, {"author": "Jordi Cenzano", "text": "I had to lookup SAP, but know that I found the definition I agree with Ali
\nSAP: Stream Access Point (SAP), which is a random access or \u201cswitch-to\u201d point in the media stream where decoding can start using only data from that point forward.
", "time": "2023-03-07T14:43:02Z"}, {"author": "Alan Frindell", "text": "Is a group ever usable if it is missing an object?
", "time": "2023-03-07T14:43:27Z"}, {"author": "Luke Curley", "text": "@alan \"it depends\"
", "time": "2023-03-07T14:43:43Z"}, {"author": "Luke Curley", "text": "I would like to remove the ambiguity
", "time": "2023-03-07T14:44:11Z"}, {"author": "Spencer Dawkins", "text": "Jordi Cenzano said:
\n\n", "time": "2023-03-07T14:45:34Z"}, {"author": "Spencer Dawkins", "text": "SAP: Stream Access Point (SAP), which is a random access or \u201cswitch-to\u201d point in the media stream where decoding can start using only data from that point forward.
\n
Thank you, Jordi - that's helpful.
", "time": "2023-03-07T14:45:47Z"}, {"author": "Suhas Nandakumar", "text": "@alan .. if group is a set of objects made up of GOP, then yes .. it can be pixelated experience depending on which object is missing
", "time": "2023-03-07T14:46:13Z"}, {"author": "Suhas Nandakumar", "text": "agree we need to make it clear
", "time": "2023-03-07T14:46:36Z"}, {"author": "Will Law", "text": "TAP - track access point
", "time": "2023-03-07T14:46:39Z"}, {"author": "Will Law", "text": "And it works semantically i.e \"tap into the stream\" :)
", "time": "2023-03-07T14:47:12Z"}, {"author": "Spencer Dawkins", "text": "Alan Frindell said:
\n\n\nIs a group ever usable if it is missing an object?
\n
(Chuckles evilly.) That depends on the definition of \"usable\", doesn't it?
", "time": "2023-03-07T14:47:37Z"}, {"author": "Luke Curley", "text": "yeah it really depends on the video encoding, and ideally that information is conveyed on the transport
", "time": "2023-03-07T14:48:47Z"}, {"author": "Cullen Jennings", "text": "+1 all of what will said
", "time": "2023-03-07T14:51:11Z"}, {"author": "Alan Frindell", "text": "to clarify Will's point - groups are ordered within a track
", "time": "2023-03-07T14:51:12Z"}, {"author": "Suhas Nandakumar", "text": "+1 TAP
", "time": "2023-03-07T14:52:37Z"}, {"author": "Jordi Cenzano", "text": "+100 What luke said
", "time": "2023-03-07T14:53:28Z"}, {"author": "Alan Frindell", "text": "So Luke is saying that an emission is also a prioritization domain.
", "time": "2023-03-07T14:54:53Z"}, {"author": "Luke Curley", "text": "+2 @cullen, either design could work
", "time": "2023-03-07T14:57:44Z"}, {"author": "Jordi Cenzano", "text": "@Luke I got a bit confused at the end, Did I understood correctly:
\nyeah Jordi, and they share a prioritization space (delivery order)
", "time": "2023-03-07T15:00:36Z"}, {"author": "Jordi Cenzano", "text": "Got it! Thanks
", "time": "2023-03-07T15:00:59Z"}, {"author": "Mo Zanaty", "text": "RTP allows layers in the same or different tracks/SSRCs.
", "time": "2023-03-07T15:01:11Z"}, {"author": "Luke Curley", "text": "I would not constrain OBJECT to a single frame; it's a media payload with the specified properties, and that's all the relay needs to know
", "time": "2023-03-07T15:03:44Z"}, {"author": "Alan Frindell", "text": "This seems to be a point where there's still disagreement: ^
", "time": "2023-03-07T15:04:12Z"}, {"author": "Alan Frindell", "text": "Saying an OBJECT is a video frame is overly constraining perhaps, since moq is intended to convey non-video media.
", "time": "2023-03-07T15:05:39Z"}, {"author": "Cullen Jennings", "text": "+1
", "time": "2023-03-07T15:05:54Z"}, {"author": "Hang Shi", "text": "Dependency graph can become very complex and hard to implement
", "time": "2023-03-07T15:06:35Z"}, {"author": "Luke Curley", "text": "+1 to Christian, we should make the transport simple but powerful \"enough\"
", "time": "2023-03-07T15:06:39Z"}, {"author": "Jordi Cenzano", "text": "Just sharing my thoughts
\nGroup: group of objects in the same track (PERHAPS frames) that depends on each other (SIMILAR to GOP), that starts with TAP (so decodable). Ideally they have a monotonically increasing ID (easier for relays)
\nObjects: (more or less) minimal unit of information that COULD be identified with monotonically increasing ID (easier for relays)
\n+1 to Luke
", "time": "2023-03-07T15:06:48Z"}, {"author": "Cullen Jennings", "text": "I view an object as the smallest block of media that makes sense to independently decode
", "time": "2023-03-07T15:06:50Z"}, {"author": "Alan Frindell", "text": "It wasn't impossible to implement H2 priorities -- but it was very complicated for an application to actually build and maintain the tree that reflected what they wanted.
", "time": "2023-03-07T15:07:08Z"}, {"author": "Luke Curley", "text": "@cullen technically that's a slice, but the relay does not need to know about slices to deliver them
", "time": "2023-03-07T15:07:15Z"}, {"author": "Hang Shi", "text": "@Cullen, is a P frame independently decodable?
", "time": "2023-03-07T15:07:18Z"}, {"author": "Cullen Jennings", "text": "sorry - I did not mean independently decodable, I mean decodable given you had the other objects in the group that are needed
", "time": "2023-03-07T15:08:00Z"}, {"author": "Luke Curley", "text": "oh sorry, I misread, yeah
", "time": "2023-03-07T15:08:25Z"}, {"author": "Cullen Jennings", "text": "So a P frame could be an object, or the app might send slices as objects.
", "time": "2023-03-07T15:08:27Z"}, {"author": "Suhas Nandakumar", "text": "for video media, objects are vide frames , but for audio it is audio frame .. whatever we call object , we need to define what its properties are
", "time": "2023-03-07T15:08:30Z"}, {"author": "Cullen Jennings", "text": "When you loose part of a video frame, some apps display the part of the frame that is still decodable, some apps skip the whole frame.
", "time": "2023-03-07T15:09:36Z"}, {"author": "Luke Curley", "text": "@cullen that was my exact intent; the encoder chooses fragmentation based on what is decodable
", "time": "2023-03-07T15:09:44Z"}, {"author": "Luke Curley", "text": "if nothing can be decoded out of order, then it's perfectly valid to send the entire GoP as an OBJECT
", "time": "2023-03-07T15:10:50Z"}, {"author": "Cullen Jennings", "text": "@luke - Right - that makes sense to me that some app might different ways of deciding what goes in an object.
", "time": "2023-03-07T15:10:53Z"}, {"author": "Luke Curley", "text": "if slices can be decoded out of order, then it's perfectly valid to send slices as OBJECTs
", "time": "2023-03-07T15:11:12Z"}, {"author": "Cullen Jennings", "text": "+1
", "time": "2023-03-07T15:11:24Z"}, {"author": "Alan Frindell", "text": "prioritization between audio and video tracks of the same video is important for managing the bandwidth in meta's apps at least
", "time": "2023-03-07T15:11:49Z"}, {"author": "Cullen Jennings", "text": "I think that is key requirement for pretty much everyone
", "time": "2023-03-07T15:12:09Z"}, {"author": "Hang Shi", "text": "+1 to Alan.
", "time": "2023-03-07T15:12:14Z"}, {"author": "Cullen Jennings", "text": "But I am assuming there will be something in metadata of the objects that lets the relays know how to prioritize between audio / video or other things.
", "time": "2023-03-07T15:13:18Z"}, {"author": "Luke Curley", "text": "@jordi if you use a flag to indicate IDRs, then packet loss can wreck your group detection (happens often in RTP)
", "time": "2023-03-07T15:14:12Z"}, {"author": "Alan Frindell", "text": "i think having prioritization domains is important -- sending N videos and letting them each express the priorities of the tracks that make them up, without interfering with each other.
", "time": "2023-03-07T15:14:16Z"}, {"author": "Hang Shi", "text": "Yes, the prioritization needs to be confined
", "time": "2023-03-07T15:14:40Z"}, {"author": "Chuan Ma", "text": "+1
", "time": "2023-03-07T15:15:05Z"}, {"author": "Luke Curley", "text": "@cullen yeah that's \"delivery order\" which effectively creates a priority queue of OBJECTs a relay should deliver, and it's scoped to an emission/broadcast
", "time": "2023-03-07T15:15:07Z"}, {"author": "Hang Shi", "text": "Benard raised a good point: Are moq push-based or pull-based?
", "time": "2023-03-07T15:15:33Z"}, {"author": "Ali Begen", "text": "Meetecho is trying to make it up for us Mo
", "time": "2023-03-07T15:17:57Z"}, {"author": "Jordi Cenzano", "text": "\n\nBenard raised a good point: Are moq push-based or pull-based?
\n
I would love a clear answer to that question
\nIMHO
\nIngest: Encoder -> Server (PUSH)
\nDelivery: Server <- Player (PUSH?)
\nWell, the individual objects are hopefully always pushed directly from one side to another, but the subscriptions are a form of pull
", "time": "2023-03-07T15:20:00Z"}, {"author": "Jordi Cenzano", "text": "+1 Victor
\nNote: Delivery push can complicate relays, but I think is more powerful
", "time": "2023-03-07T15:20:41Z"}, {"author": "Martin Duke", "text": "Another 90 sec scribe break -- please cover me
", "time": "2023-03-07T15:20:50Z"}, {"author": "Hang Shi", "text": "For delivery side, it seems like the pull is more scalable than push
", "time": "2023-03-07T15:21:03Z"}, {"author": "Luke Curley", "text": "Warp-02 briefly called OBJECTs \"LAYERS\" in an effort to support layered encoding; yeh it's tough
", "time": "2023-03-07T15:21:18Z"}, {"author": "Martin Duke", "text": "scribe is back
", "time": "2023-03-07T15:22:58Z"}, {"author": "Alan Frindell", "text": "It seems like there's several different ways to represent layers on the wire, and having a protocol that allows for multiple options may serve us in the near term (and maybe the long term)
", "time": "2023-03-07T15:23:11Z"}, {"author": "Suhas Nandakumar", "text": "We need to keep receiver role in mind when deciding on layered codec .. and what fucntionality is useful
", "time": "2023-03-07T15:23:54Z"}, {"author": "Luke Curley", "text": "@alan IMO it simplifies down to a few primitives if you focus on properties
", "time": "2023-03-07T15:25:05Z"}, {"author": "Luke Curley", "text": "I'd like to avoid separate \"modes\" at the very least
", "time": "2023-03-07T15:26:55Z"}, {"author": "Alan Frindell", "text": "I think I heard that it could be done as track-per-layer or embed one or more layers together in a single track. I don't think I see it as \"modes\" necessarily
", "time": "2023-03-07T15:27:50Z"}, {"author": "Luke Curley", "text": "I think we pick one of those two for layered encoding
", "time": "2023-03-07T15:28:26Z"}, {"author": "Alan Frindell", "text": "I don't disagree - but it might be useful to have a protocol that allows both so we can run experiments and let implementation experience help choose
", "time": "2023-03-07T15:30:13Z"}, {"author": "Will Law", "text": "An SFU would not not be a media source or sink. A MCU would.
", "time": "2023-03-07T15:35:58Z"}, {"author": "Suhas Nandakumar", "text": "@will agree ..
", "time": "2023-03-07T15:36:57Z"}, {"author": "Hang Shi", "text": "Is origin the relay or endpoint or something else?
", "time": "2023-03-07T15:37:11Z"}, {"author": "Cullen Jennings", "text": "So for people reading this later and trying to sort all of this out. What I thought we were getting some agreement on was:
\nObject is smallest unit that makes sense to decode. May not be independently decodable. Could be an H.264 P frame. Could be just a single slice from inside the P Frame.
\nMore work to be done on layered codecs but just considering non layered codecs. An group has all the things needed to decode the objects in it.
\nIt would never make sense to decode part of object. The end to end encryption and authentication can be done on an object. The authentication would be computed across the whole object when doing end to end encryption.
", "time": "2023-03-07T15:38:57Z"}, {"author": "Martin Duke", "text": "@cullen feel free to add that to the end of Christian's segment in the notes
", "time": "2023-03-07T15:39:29Z"}, {"author": "Yaakov Stein", "text": "so, a multiparty conferencing unit is not a relay ?
", "time": "2023-03-07T15:40:18Z"}, {"author": "Hang Shi", "text": "relay should not touch the media payload(which maybe end-to-end encrypted)
", "time": "2023-03-07T15:41:10Z"}, {"author": "Luke Curley", "text": "@cullen I want the ability to send a GoP as a single OBJECT (literally a GROUP of size 1), which is to say than an OBJECT might be partially decodable even when reset early
", "time": "2023-03-07T15:41:39Z"}, {"author": "Suhas Nandakumar", "text": "Agree with what @cullen said .. we need to capture that in the data model PR
", "time": "2023-03-07T15:41:45Z"}, {"author": "Luke Curley", "text": "really an OBJECT is just a media payload with the given properties (delivery order, group, etc)
", "time": "2023-03-07T15:42:06Z"}, {"author": "Yaakov Stein", "text": "OK, so we need another picture where several endpoints communicate with a MCU which is also trusted
", "time": "2023-03-07T15:42:06Z"}, {"author": "Victor Vasiliev", "text": "FWIW, I object to use of term \"middlebox\" for network entities which are explicitly connected to by the endpoints
", "time": "2023-03-07T15:42:12Z"}, {"author": "Alan Frindell", "text": "Can we accomplish both just by adding a property of OBJECT indicating whether it can be tail dropped at a relay?
", "time": "2023-03-07T15:42:30Z"}, {"author": "James Gruessing", "text": "@Hang Shi: There's a few use cases where deployments may want Relays to manipulate media. We really should be clear on the authentication model between entities, and encryption of media to give deployments options.
", "time": "2023-03-07T15:42:34Z"}, {"author": "Alan Frindell", "text": "no echo on our end
", "time": "2023-03-07T15:43:01Z"}, {"author": "Luke Curley", "text": "yeh @alan, that works, kind of like \"incremental\" in HTTP/3 priorities
", "time": "2023-03-07T15:43:13Z"}, {"author": "Suhas Nandakumar", "text": "i think meetecho, echoes if you don't use the mic .. I hjad this experience once
", "time": "2023-03-07T15:44:03Z"}, {"author": "Luke Curley", "text": "\n", "time": "2023-03-07T15:45:00Z"}, {"author": "Luke Curley", "text": "\"Incremental\" indicates if an HTTP response can be processed incrementally, i.e., provide some meaningful output as chunks of the response arrive.
\n
even if you send each frame as an OBJECT, it's can still be incremental if it consists of multiple slices
", "time": "2023-03-07T15:45:27Z"}, {"author": "Victor Vasiliev", "text": "My worry about saying that objects are \"atomic\" is that the endpoints would assume they can buffer an entire object instead of streaming it
", "time": "2023-03-07T15:45:41Z"}, {"author": "Suhas Nandakumar", "text": "i think anything that needs access to raw media, should not be called Relay .. since we are at the terminology section
", "time": "2023-03-07T15:45:43Z"}, {"author": "Hang Shi", "text": "@James why not using the endpoint to manipulate the media?
", "time": "2023-03-07T15:46:04Z"}, {"author": "Hang Shi", "text": "+1 to Suhas
", "time": "2023-03-07T15:46:13Z"}, {"author": "Martin Duke", "text": "another 90 sec scribe break... need a bigger coffee mug
", "time": "2023-03-07T15:46:17Z"}, {"author": "Suhas Nandakumar", "text": "@victor .. i don't think that's true .. anything can be fragmented and delivered .. but consumption needs it to be atomic
", "time": "2023-03-07T15:46:41Z"}, {"author": "Suhas Nandakumar", "text": "if i were to use Datagrams , then everything is partial on delivery
", "time": "2023-03-07T15:47:04Z"}, {"author": "Victor Vasiliev", "text": "If we say that \"consumption of objects is atomic\", what would this mean for the protocol?
", "time": "2023-03-07T15:47:44Z"}, {"author": "Martin Duke", "text": "scribe is back
", "time": "2023-03-07T15:48:10Z"}, {"author": "Suhas Nandakumar", "text": "an partial delivered encrypted video frame cannot be consumed ... for example
", "time": "2023-03-07T15:48:14Z"}, {"author": "Luke Curley", "text": "I would even argue that media encoding is intended to be a produced and consumed as a stream, not atomic messages
", "time": "2023-03-07T15:48:31Z"}, {"author": "Suhas Nandakumar", "text": "its useless ..
", "time": "2023-03-07T15:48:31Z"}, {"author": "Victor Vasiliev", "text": "I understand that point; I am trying to understand how that would change your behavior, as a MoQ endpoint sending media
", "time": "2023-03-07T15:49:09Z"}, {"author": "Victor Vasiliev", "text": "We can make one of two assumptions: either \"an object needs to be fully received to be useful\", or \"a partially available object is useful\". We're trying to pick one, but I am not sure that picking either of those would actually change the protocol
", "time": "2023-03-07T15:51:36Z"}, {"author": "Hang Shi", "text": "But the encoder does produce slices/frames/gop one by one
", "time": "2023-03-07T15:51:40Z"}, {"author": "Suhas Nandakumar", "text": "on the sender side, to keep the latencies low, an encoded video frame or a slice of it, it sent as an object - reflecting on cullen's conclusion
", "time": "2023-03-07T15:55:22Z"}, {"author": "Victor Vasiliev", "text": "If you require objects to be always streamed and partially delivered, that would reduce latency
", "time": "2023-03-07T15:56:06Z"}, {"author": "Victor Vasiliev", "text": "Because any instance where you buffer an entire object would cause delays
", "time": "2023-03-07T15:56:28Z"}, {"author": "Martin Duke", "text": "I am far from convinced that DATAGRAM is broadly useful for MoQ
", "time": "2023-03-07T15:56:30Z"}, {"author": "Martin Duke", "text": "which IIUC is the only case where MTU matters
", "time": "2023-03-07T15:56:48Z"}, {"author": "Suhas Nandakumar", "text": "@victor, agree one should not buffer anything larger than a single frame before sending ..they can go smaller than video frame too if the encoder provides an option ..
", "time": "2023-03-07T15:57:47Z"}, {"author": "Christian Huitema", "text": "In any case, all transport variants (Rush, Warp, datagrams) are capable of sending fragments of objects over several packets. QUIC Streams do that naturally. The Datagram implementation in the QUICR prototype does that too.
", "time": "2023-03-07T15:57:58Z"}, {"author": "Mirja K\u00fchlewind", "text": "Sorry need to leave. Thanks!
", "time": "2023-03-07T15:58:28Z"}, {"author": "Luke Curley", "text": "@martin +1 no datagrams
", "time": "2023-03-07T15:58:42Z"}, {"author": "Victor Vasiliev", "text": "The problem I have with \"any atomically decodable thing should be its own object\" is that the logical conclusion of this is that when you're streaming raw unencrypted s16 wav stream, your objects have to be two bytes long
", "time": "2023-03-07T15:59:01Z"}, {"author": "Luke Curley", "text": "there's a fundamental discussion missing here; why am I fragmenting in the first place?
", "time": "2023-03-07T15:59:20Z"}, {"author": "Martin Duke", "text": "@Christian one certainly can use DATAGRAM, I just have not heard a convincing value proposition for including them
", "time": "2023-03-07T15:59:23Z"}, {"author": "Luke Curley", "text": "for example, in the current definition of GROUP, where OBJECT N+1 depends on OBJECT 1..N, why not deliver them over a single stream, and why even split them into separate objects in the first place?
", "time": "2023-03-07T16:00:38Z"}, {"author": "Alan Frindell", "text": "@Will, I think that definition is ok for a place like Meta, where we have our own edge and don't necessarily require a standard between the edge and origin. But will it work for third-party origins and CDNs that want to pre-seed content?
", "time": "2023-03-07T16:00:55Z"}, {"author": "Luke Curley", "text": "(note the definition of GROUP will change to support intra-group priorities)
", "time": "2023-03-07T16:01:07Z"}, {"author": "Xavier de Foy", "text": "Question for relay design team: in some cases, will it be possible to use a relay that is trusted by the client, but not necessarily known to the origin? A bit similar to an HTTP browser accessing the web through a proxy.
", "time": "2023-03-07T16:02:24Z"}, {"author": "Suhas Nandakumar", "text": "object carry priority and when they are put in a group. intra-group priorities are supported ..
", "time": "2023-03-07T16:03:02Z"}, {"author": "Luke Curley", "text": "@suhas if all frames in a group are the same priority, can they be merged into a single OBJECT?
", "time": "2023-03-07T16:04:13Z"}, {"author": "Alan Frindell", "text": "We were supposed to wait to go crazy?
", "time": "2023-03-07T16:06:25Z"}, {"author": "Will Law", "text": "@Alan - yes, it will work for CDNs. IN the vast majority of cases, we don;t want to pre-seed content. If we have 200,000 edge relays, we don't want to push every track to every one of them. That would be prohibitively expensive and also inefficient. We would rather move traffic only in response to where it is being consumed. Thats why the end-point would originate the subscribe, and the relays would simply propagate it back to the origin.
", "time": "2023-03-07T16:07:03Z"}, {"author": "Luke Curley", "text": "pre-seeding is complicated, and really depends on how the CDN routes/assigns traffic
", "time": "2023-03-07T16:10:30Z"}, {"author": "Ted Hardie", "text": "I agree; pre-seeding seems like it brings a bunch of CDNi style complexity. Can we put that off until a later round?
", "time": "2023-03-07T16:11:33Z"}, {"author": "Alan Frindell", "text": "sounds good
", "time": "2023-03-07T16:11:39Z"}, {"author": "Thomas Higdon", "text": "maybe the pre-seeding idea is similar to HTTP server push. maybe it's useful, but standardizing it turned out to not really be a useful exercise in retrospect.
", "time": "2023-03-07T16:12:10Z"}, {"author": "Luke Curley", "text": "the content is encrypted using a shared key; this is DRM
", "time": "2023-03-07T16:13:32Z"}, {"author": "Luke Curley", "text": "what Will said is true too
", "time": "2023-03-07T16:15:04Z"}, {"author": "Christian Huitema", "text": "Actually, if you want efficient DRM, you need way more than encrypting the content with the same key for 1 million subscribers...
", "time": "2023-03-07T16:15:06Z"}, {"author": "Christian Huitema", "text": "For example, you need per-user watermarks so you can track who leaked the video...
", "time": "2023-03-07T16:15:56Z"}, {"author": "Ali Begen", "text": "key distribution is a different problem and I don't think MOQ should deal with that
", "time": "2023-03-07T16:16:14Z"}, {"author": "Martin Duke", "text": "@luke I think that implies an out-of-band key distribution, which is fine; but that implies a direct relationship between origin and subscriber that maybe answers some of the other relay questions
", "time": "2023-03-07T16:17:43Z"}, {"author": "Christian Huitema", "text": "I think the main purpose of encryption is to prevent the relays from leaking the content -- something mostly valuable in relatively small groups.
", "time": "2023-03-07T16:17:51Z"}, {"author": "Ali Begen", "text": "For forensic watermarking (session based not user), content variants are needed which implies more \"stuff\" being relayed in the network
", "time": "2023-03-07T16:17:55Z"}, {"author": "Luke Curley", "text": "@martin yeah, that's how it typically works today, especially because it requires a \"trusted\" 3rd party to provide the key (ex. Widevine) to both the encoder and decoder(s)
", "time": "2023-03-07T16:19:08Z"}, {"author": "Luke Curley", "text": "not to suggest that DRM is the only reason why you would encrypt the media
", "time": "2023-03-07T16:20:29Z"}, {"author": "Hang Shi", "text": "+1 to Ted
", "time": "2023-03-07T16:20:55Z"}, {"author": "Suhas Nandakumar", "text": "+1 to Ted
", "time": "2023-03-07T16:21:42Z"}, {"author": "Suhas Nandakumar", "text": "+1 on pain with p2p topology discoverability ...
", "time": "2023-03-07T16:27:23Z"}, {"author": "Martin Duke", "text": "It sounds like relays will have different use cases for different encryption models
", "time": "2023-03-07T16:27:47Z"}, {"author": "Martin Duke", "text": "or at least, 1:1 encryption means that tracks need to be uniquely named for each subscriber
", "time": "2023-03-07T16:28:17Z"}, {"author": "James Gruessing", "text": "So... a MoQ Relay is ICE for QUIC?
", "time": "2023-03-07T16:29:01Z"}, {"author": "Martin Duke", "text": "another scribe coffee break...\\
", "time": "2023-03-07T16:32:12Z"}, {"author": "Luke Curley", "text": "#66 had some concrete proposals near the end on how to send CATALOG over OBJECT frames
", "time": "2023-03-07T16:33:11Z"}, {"author": "Martin Duke", "text": "scribe is back
", "time": "2023-03-07T16:33:37Z"}, {"author": "Will Law", "text": "I'd like to discuss \"Relax the CATALOG definition to decouple the base protocol from the streaming format #66\" and
", "time": "2023-03-07T16:33:41Z"}, {"author": "Spencer Dawkins", "text": "James Gruessing said:
\n\n\nSo... a MoQ Relay is ICE for QUIC?
\n
Apparently, I'm not the only one chuckling evilly on this call, huh? :smiling_devil:
", "time": "2023-03-07T16:34:21Z"}, {"author": "Peter Thatcher", "text": "What does \"ICE for QUIC\" mean?
", "time": "2023-03-07T16:38:30Z"}, {"author": "Luke Curley", "text": "after 50 delta catalog updates or something you decide to make an independently decodable catalog
", "time": "2023-03-07T16:40:40Z"}, {"author": "Hang Shi", "text": "Yes that is the idea
", "time": "2023-03-07T16:41:02Z"}, {"author": "Martin Duke", "text": "is https:// really the scheme?
", "time": "2023-03-07T16:45:37Z"}, {"author": "Luke Curley", "text": "yeah that's WebTransport
", "time": "2023-03-07T16:45:49Z"}, {"author": "James Gruessing", "text": "@Peter Thatcher: in WebRTC ICE, STUN, and TURN provide means of dealing with users that have NAT. My point is that if we keep Relays being a simple as possible, punching through NAT is going to be a huge part of what they'll be doing.
", "time": "2023-03-07T16:46:04Z"}, {"author": "Luke Curley", "text": "+1 Alan
", "time": "2023-03-07T16:46:31Z"}, {"author": "Jordi Cenzano", "text": "From Luke: Composition coming from multiple places seems out of scope of transport protocol
\n+1
It may need to be in scope for the header design, even if we grant that it will be specialized intermediaries rather than fan-out style relays that use those.
", "time": "2023-03-07T16:47:32Z"}, {"author": "Jordi Cenzano", "text": "If we want compositions we can build an Application that subscribes to N emissions, composes them, and create another emission
", "time": "2023-03-07T16:47:38Z"}, {"author": "Suhas Nandakumar", "text": "in conf call, each particioant is an emission .. i don't see why would one want to set up a WT session per participant
", "time": "2023-03-07T16:48:11Z"}, {"author": "Ted Hardie", "text": "Simple questions, like where uniqueness comes from, get different answers depending on whether we anticipate these uses or not.
", "time": "2023-03-07T16:48:46Z"}, {"author": "Alan Frindell", "text": "if it's peer to peer, you have a connection to each one. if they are all coming through a relay, you can pool the wt sessions on a quic connection
", "time": "2023-03-07T16:48:52Z"}, {"author": "Luke Curley", "text": "@suhas quite the opposite, I don't see why you would want to coalesce all participants over a single WT session, because it increases latency and possibly bottlenecks your bandwidth
", "time": "2023-03-07T16:49:46Z"}, {"author": "Luke Curley", "text": "ex. if one participant is on the west coast, one participant is on the east coast, and you're in the middle of the country
", "time": "2023-03-07T16:50:24Z"}, {"author": "Luke Curley", "text": "you want to pull the west coast participant from a west-ward edge and you want to pull the east coast participant from a east-ward edge
", "time": "2023-03-07T16:51:01Z"}, {"author": "Peter Thatcher", "text": "I would recommend not relying on WebTransport connection pooling. It's a much better idea to have just allow tracks from different emissions to flow over the same transport.
", "time": "2023-03-07T16:51:17Z"}, {"author": "Will Law", "text": "@luke - in that scenario, you'ld still be talking to your local edge. That local edge would then pull traffic form the east edge and the est edge.
", "time": "2023-03-07T16:51:47Z"}, {"author": "Victor Vasiliev", "text": "@Peter the difficult thing with having multiple emissions on the same connection is that now you have to prioritize those
", "time": "2023-03-07T16:52:09Z"}, {"author": "Peter Thatcher", "text": "If you have to use multiple WebTranpsport connections because you're hitting different servers, fine. But if you're hitting the same server, it's silly to not just reuse the same WebTransport connection.
", "time": "2023-03-07T16:52:20Z"}, {"author": "Luke Curley", "text": "@Will possibly, although that assumes your CDN has a wide deployment
", "time": "2023-03-07T16:52:33Z"}, {"author": "Luke Curley", "text": "let's say the CDN only has a west coast edge and east coast edge
", "time": "2023-03-07T16:52:48Z"}, {"author": "Peter Thatcher", "text": "Prioritization is going to be easier within one WebTransport context rather than across multiple WebTransport contexts.
", "time": "2023-03-07T16:53:06Z"}, {"author": "Luke Curley", "text": "pulling all participants through the same edge will cause tromboning
", "time": "2023-03-07T16:53:20Z"}, {"author": "Martin Duke", "text": "where's my prize?
", "time": "2023-03-07T16:54:00Z"}]