[{"author": "Lucas Pardue", "text": "<p>sorry to say but those colours choices for boxes and text in boxes are really bad</p>", "time": "2023-07-26T22:37:53Z"}, {"author": "Ali Begen", "text": "<p>projector is the bad thing in this room plus the lighting</p>", "time": "2023-07-26T22:39:13Z"}, {"author": "Lucas Pardue", "text": "<p>agree but more mind for accessibility would be appreciated</p>", "time": "2023-07-26T22:39:33Z"}, {"author": "Mike English", "text": "<p>or the WHEP endpoint, ... ;)</p>", "time": "2023-07-26T22:39:46Z"}, {"author": "Mike English", "text": "<p>Fallback between formats at that level seems like an application concern</p>", "time": "2023-07-26T22:40:35Z"}, {"author": "Mike English", "text": "<p>Counterpoint would be to optimize for the \"best\" format a client can support and minimize TTFF</p>", "time": "2023-07-26T22:41:45Z"}, {"author": "Mike English", "text": "<p>i.e. if you have a client that supports multiple formats, but has a preference order, you don't want to impose extra round trips</p>", "time": "2023-07-26T22:42:35Z"}, {"author": "Ted Hardie", "text": "<p>It seems like you make that a media type, and have the client request that media type if you want that design.</p>", "time": "2023-07-26T22:43:01Z"}, {"author": "James Gruessing", "text": "<p>+1 to Ali, deployments may limit certain types of media for certain formats so players should be able to ask for the entire menu OR be able to ask for only a specific format it knows how to deal with</p>", "time": "2023-07-26T22:43:55Z"}, {"author": "Jonathan Lennox", "text": "<p>metalogue?</p>", "time": "2023-07-26T22:46:04Z"}, {"author": "Lucas Pardue", "text": "<p>catalog(N)</p>", "time": "2023-07-26T22:46:10Z"}, {"author": "Juliusz Chroboczek", "text": "<p>All problems in computer science can be solved by another level of indirection.  Except the problem of too many levels of indirection.</p>", "time": "2023-07-26T22:46:35Z"}, {"author": "Alan Frindell", "text": "<p>maybe using chat isn't the best example here, since it seems unlikely you would ever have both warp and chat for the same namespace?</p>", "time": "2023-07-26T22:47:19Z"}, {"author": "Mike English", "text": "<p>What about a catalog of catalogs, but only as an optional hint if a client does need to retry something else?</p>", "time": "2023-07-26T22:48:14Z"}, {"author": "Lucas Pardue", "text": "<p>not sure Alan, <a href=\"https://lifehacker.com/watch-star-wars-in-text-via-telnet-373571\">https://lifehacker.com/watch-star-wars-in-text-via-telnet-373571</a> is a thing</p>", "time": "2023-07-26T22:48:20Z"}, {"author": "Ted Hardie", "text": "<p>@Suhas except if we support a meta format</p>", "time": "2023-07-26T22:49:24Z"}, {"author": "Alan Frindell", "text": "<p>text may be part of broadcast, but chat is different type of application</p>", "time": "2023-07-26T22:49:34Z"}, {"author": "Mike English", "text": "<p>To clarify what I'm thinking: you could do 4 (+2)</p>", "time": "2023-07-26T22:50:39Z"}, {"author": "Mike English", "text": "<p>Maybe Phillip is saying the same</p>", "time": "2023-07-26T22:51:19Z"}, {"author": "Ali Begen", "text": "<p>+1 to Luke</p>", "time": "2023-07-26T22:51:34Z"}, {"author": "Hang Shi", "text": "<p>I prefer 1 too, +1 to Will</p>", "time": "2023-07-26T22:58:59Z"}, {"author": "Lucas Pardue", "text": "<p>to use HTTP model, the content-type is separate from the content-encoding - why are we mixing them here?</p>", "time": "2023-07-26T22:59:02Z"}, {"author": "James Gruessing", "text": "<p>Lucas: Because we aren't thinking about accept and accept-encoding in the same way</p>", "time": "2023-07-26T22:59:46Z"}, {"author": "Lucas Pardue", "text": "<p>why not?</p>", "time": "2023-07-26T23:00:02Z"}, {"author": "James Gruessing", "text": "<p>good question!</p>", "time": "2023-07-26T23:00:49Z"}, {"author": "Jonathan Lennox", "text": "<p>I feel like the \"blind client\" use case is also the \"future format upgrades\" use case.</p>", "time": "2023-07-26T23:01:04Z"}, {"author": "Juliusz Chroboczek", "text": "<p>(We need a choice \"abstain\", so the chairs can distinguish people who are participating but don't have an opinion from people who are not following.)</p>", "time": "2023-07-26T23:01:15Z"}, {"author": "Ali Begen", "text": "<p>yeah the vote is misleading</p>", "time": "2023-07-26T23:01:48Z"}, {"author": "Mike English", "text": "<p>Jonathan++</p>", "time": "2023-07-26T23:02:55Z"}, {"author": "Lucas Pardue", "text": "<p>I have also never seen a prodcution use case</p>", "time": "2023-07-26T23:05:28Z"}, {"author": "Ali Begen", "text": "<p>SVC does not belong to thw warpdraft</p>", "time": "2023-07-26T23:05:29Z"}, {"author": "Juliusz Chroboczek", "text": "<p>Isn't Meetecho using SVC right now?</p>", "time": "2023-07-26T23:05:33Z"}, {"author": "Lorenzo Miniero", "text": "<p>Juliusz: no SVC isn't used here</p>", "time": "2023-07-26T23:05:48Z"}, {"author": "Juliusz Chroboczek", "text": "<p>Grumble.</p>", "time": "2023-07-26T23:05:55Z"}, {"author": "Lorenzo Miniero", "text": "<p>Janus does support it though</p>", "time": "2023-07-26T23:05:57Z"}, {"author": "Juliusz Chroboczek", "text": "<p>Yeah, I've studied your code in detail :-)</p>", "time": "2023-07-26T23:06:11Z"}, {"author": "Lorenzo Miniero", "text": "<p>:D</p>", "time": "2023-07-26T23:06:30Z"}, {"author": "Mike English", "text": "<p>Right, I have seen limited use of SVC in the RTC domain, but not for other use cases yet</p>", "time": "2023-07-26T23:06:33Z"}, {"author": "Hang Shi", "text": "<p>+1 to Cullen</p>", "time": "2023-07-26T23:07:13Z"}, {"author": "Juliusz Chroboczek", "text": "<p>Pity.  It's not difficult to implement (if your codec supports it), and it gives excellent switching granularity.</p>", "time": "2023-07-26T23:08:04Z"}, {"author": "Spencer Dawkins", "text": "<p>+1 Victor, and the container makes sense.</p>", "time": "2023-07-26T23:10:28Z"}, {"author": "Peter Thatcher", "text": "<p>SVC relationships can get way more complicated than track A depends on track B.  Putting that into a cataglog can get pretty complicated.</p>", "time": "2023-07-26T23:10:59Z"}, {"author": "Mike English", "text": "<p>Maybe academic at this point, but the main reason you'd want to put layers in their own tracks would be to have more control over send order..?</p>", "time": "2023-07-26T23:11:44Z"}, {"author": "Ali Begen", "text": "<p>plus setting the priorities right.</p>", "time": "2023-07-26T23:12:26Z"}, {"author": "Jonathan Lennox", "text": "<p>I think more because it allows clients to select which layers they want to receive.</p>", "time": "2023-07-26T23:12:27Z"}, {"author": "Peter Thatcher", "text": "<p>I think it's because you can control subscriptions.  But you could just have a track include things it depends on automatically when it subscribes.</p>", "time": "2023-07-26T23:12:30Z"}, {"author": "Juliusz Chroboczek", "text": "<p>You'd want to give layers different priorities, so that the congestion controller can discard the upper layers with no knowledge of the codec.  Not sure whether that means you need them in the catalog, though.</p>", "time": "2023-07-26T23:12:51Z"}, {"author": "Peter Thatcher", "text": "<p>(just like most RTC SFUs work today)</p>", "time": "2023-07-26T23:12:52Z"}, {"author": "Mike English", "text": "<p>Layers give you a level to pull in the face of congestion (whether that's server or client side or whatever), right?</p>", "time": "2023-07-26T23:12:59Z"}, {"author": "Mike English", "text": "<p>Err, layers in separate tracks, I mean</p>", "time": "2023-07-26T23:13:12Z"}, {"author": "Jonathan Lennox", "text": "<p>Peter: that requires knowledge of this property in the MoQ transport though.</p>", "time": "2023-07-26T23:13:16Z"}, {"author": "Jonathan Lennox", "text": "<p>Like how all SFUs have to understand SVC.</p>", "time": "2023-07-26T23:13:33Z"}, {"author": "Mike English", "text": "<p>^</p>", "time": "2023-07-26T23:13:41Z"}, {"author": "Harald Alvestrand", "text": "<p>I don't think we have done any serious modelling of how track transmission is controlled - whether it's just on/off or can be more complex. If it's possible to tell a track sender to start dropping SVC layers, then putting SVC layers inside a track should be workable / useful.</p>", "time": "2023-07-26T23:14:58Z"}, {"author": "Timothy Terriberry", "text": "<p>Layers give you a lever to pull in face of (a) congestion, (b) changing display size, and (c) available compute resources.</p>", "time": "2023-07-26T23:15:33Z"}, {"author": "Jonathan Lennox", "text": "<p>A lot of this is a tradeoff between MoQ transport complexity and catalog complexity.</p>", "time": "2023-07-26T23:15:46Z"}, {"author": "Timothy Terriberry", "text": "<p>No one side has all of that information (unless you are still using receiver-side congestion control).</p>", "time": "2023-07-26T23:15:51Z"}, {"author": "Peter Thatcher", "text": "<p>Forwarding SVC well from a client to a server to a client while keeping the server \"dumb\" is not very easy.</p>", "time": "2023-07-26T23:16:27Z"}, {"author": "Phillip Hallam-Baker", "text": "<p>Seems to me like negotiating the level of SVC service is something different to picking a stream. Catalog might want to give hints as to what the levels are.</p>", "time": "2023-07-26T23:16:54Z"}, {"author": "Juliusz Chroboczek", "text": "<p>Nobody said it was going to be easy :-)</p>", "time": "2023-07-26T23:16:57Z"}, {"author": "Cullen Jennings", "text": "<p>I worry that in trying to pick DRM parameters, that would force content that was stored on the CDN to be recoded and stored twice if we choose a different one. So we will run into the same problem of not being able to agree on parameters for DRM</p>", "time": "2023-07-26T23:17:03Z"}, {"author": "Juliusz Chroboczek", "text": "<p>Could you please clarify?</p>", "time": "2023-07-26T23:17:30Z"}, {"author": "Peter Thatcher", "text": "<p>I guess if you split SVC into separate tracks, the client could say \"give me A and then B if there is bandwidth for it\" and the server can be dumb and not know about the dependency.  Then only the clients need to know about the dependency.  That might not support all the possible complex SVC setups, but probably the most common ones.</p>", "time": "2023-07-26T23:22:56Z"}, {"author": "Jonathan Lennox", "text": "<p>For at least some cases the client needs to know the server's decision about whether or not there was enough bandwidth, though.  (I.e. whether to render the base-layer frame or wait for the enhancement layer.)</p>", "time": "2023-07-26T23:24:06Z"}, {"author": "Jonathan Lennox", "text": "<p>That's doable but it'd be another requirement on the transport.</p>", "time": "2023-07-26T23:24:25Z"}, {"author": "Peter Thatcher", "text": "<p>Isn't that something we want anyway?  Even without SVC, if you're not getting the video for someone in a conference, you'd like to know it's because the server chose not to forward it, so don't bother trying to render it (or render profile pic)</p>", "time": "2023-07-26T23:25:14Z"}, {"author": "Jonathan Lennox", "text": "<p>Yeah, true.</p>", "time": "2023-07-26T23:25:26Z"}, {"author": "Lucas Pardue", "text": "<p>chairs: can you increase the size of the text in Githbu issue body? It's illegible on the in-room projector</p>", "time": "2023-07-26T23:26:20Z"}, {"author": "Timothy Terriberry", "text": "<p>You also need it anyway, because even if you put the client in complete control over whether you are sending B in addition to A, that can change periodically, and you don't know on exactly which frame the server processed your request.</p>", "time": "2023-07-26T23:26:28Z"}, {"author": "Lucas Pardue", "text": "<p>thnx</p>", "time": "2023-07-26T23:28:07Z"}, {"author": "Spencer Dawkins", "text": "<p>+1 <span class=\"user-mention\" data-user-id=\"71\">@Cullen Jennings</span>  - there are a lot of things we declared out of scope that are kind of important for real deployments.</p>", "time": "2023-07-26T23:31:28Z"}, {"author": "Hang Shi", "text": "<p>Lots of detail missing for interop</p>", "time": "2023-07-26T23:32:29Z"}, {"author": "Cullen Jennings", "text": "<p>I do think an open issue is how authorization to relays works</p>", "time": "2023-07-26T23:33:02Z"}, {"author": "Hang Shi", "text": "<p>+1 to Christian. From producer to consumer there may exist multiple relay service providers</p>", "time": "2023-07-26T23:34:50Z"}, {"author": "Jonathan Lennox", "text": "<p>@Ian Swett: there was discussion here in the chat that resulted in some requirements for MoQ transport so do take a look at the chat when you get a chance?</p>", "time": "2023-07-26T23:35:50Z"}, {"author": "Lucas Pardue", "text": "<p>the QUIC WG has no opinion on stream priority levels. QUIC implementations on the other hand...</p>", "time": "2023-07-26T23:37:49Z"}, {"author": "Juliusz Chroboczek", "text": "<p>Is one CMAF equivalent to a GOP?</p>", "time": "2023-07-26T23:40:27Z"}, {"author": "Juliusz Chroboczek", "text": "<p>*CMAF segment</p>", "time": "2023-07-26T23:40:33Z"}, {"author": "Ali Begen", "text": "<p>nope</p>", "time": "2023-07-26T23:40:40Z"}, {"author": "Juliusz Chroboczek", "text": "<p>Larger?</p>", "time": "2023-07-26T23:40:44Z"}, {"author": "Ali Begen", "text": "<p>at least one gop but usually larger</p>", "time": "2023-07-26T23:40:56Z"}, {"author": "Juliusz Chroboczek", "text": "<p>clear, thanks.</p>", "time": "2023-07-26T23:41:02Z"}, {"author": "Ali Begen", "text": "<p>cmaf fragment is usually a gop. segment is one or more fragments.</p>", "time": "2023-07-26T23:41:13Z"}, {"author": "Ali Begen", "text": "<p>the mapping indeed needs to be flexible and futureproof</p>", "time": "2023-07-26T23:43:59Z"}, {"author": "Magnus Westerlund", "text": "<p>What about 360 video viewport consisting of a dynamically changing set of tiles over time based on head movement?  Sorry, can't help you making things harder.</p>", "time": "2023-07-26T23:44:21Z"}, {"author": "Hang Shi", "text": "<p>+1 to datagram</p>", "time": "2023-07-26T23:45:05Z"}, {"author": "Juliusz Chroboczek", "text": "<p>What's the max size of a QUIC datagram?</p>", "time": "2023-07-26T23:45:23Z"}, {"author": "Magnus Westerlund", "text": "<p><span class=\"user-mention silent\" data-user-id=\"896\">Juliusz Chroboczek</span> <a href=\"#narrow/stream/304-moq/topic/ietf-117/near/83941\">said</a>:</p>\n<blockquote>\n<p>What's the max size of a QUIC datagram?</p>\n</blockquote>\n<p>What is left of the UDP payload MTU after the QUIC packet headers.</p>", "time": "2023-07-26T23:45:52Z"}, {"author": "Ali Begen", "text": "<p>@Magnus, tiles will likely be separate tracks.</p>", "time": "2023-07-26T23:45:57Z"}, {"author": "Juliusz Chroboczek", "text": "<p>ty</p>", "time": "2023-07-26T23:46:07Z"}, {"author": "Lucas Pardue", "text": "<p>a QUIC peer can also state a max DATAGRAM frame payload size that it is willing to receive, smaller than PMTU-overheads</p>", "time": "2023-07-26T23:46:27Z"}, {"author": "Juliusz Chroboczek", "text": "<p>Thanks.  I keep forgetting that QUIC does not necessarily work like SCTP :-/</p>", "time": "2023-07-26T23:48:49Z"}, {"author": "Lucas Pardue", "text": "<p>in practice, many stack just set a max DATAGRAM frame payload zie of MAX_VAL, and let the PMTU figure it out</p>", "time": "2023-07-26T23:49:29Z"}, {"author": "Ali Begen", "text": "<p>@Cullen, I hope to have some answers to some of your questions, if I get some air time. Otherwise we will do it on the mailing list</p>", "time": "2023-07-26T23:49:38Z"}, {"author": "James Gruessing", "text": "<p>+1 to remote only</p>", "time": "2023-07-26T23:56:37Z"}, {"author": "Peter Thatcher", "text": "<p>Remote only</p>", "time": "2023-07-26T23:56:43Z"}, {"author": "Hang Shi", "text": "<p>where is the location?</p>", "time": "2023-07-26T23:56:50Z"}, {"author": "Jonathan Lennox", "text": "<p>Tentatively Boston, MA, USA</p>", "time": "2023-07-26T23:57:04Z"}, {"author": "Hang Shi", "text": "<p>Remote only for USA</p>", "time": "2023-07-26T23:57:29Z"}, {"author": "Ali Begen", "text": "<p><a href=\"https://www.meetup.com/sf-video-technology/events/291949739/\">https://www.meetup.com/sf-video-technology/events/291949739/</a></p>", "time": "2023-07-26T23:58:59Z"}, {"author": "Ali Begen", "text": "<p>For those who are interested, talk is tomorrow at 6pm at Mux office (walking distance)</p>", "time": "2023-07-26T23:59:20Z"}, {"author": "Luke Curley", "text": "<p>I'm flying out Sep 25th</p>", "time": "2023-07-26T23:59:23Z"}]