[{"author": "Adam Roach", "text": "<p>Sounds good to me</p>", "time": "2022-11-10T17:12:42Z"}, {"author": "Jonathan Lennox", "text": "<p>Adam, are you remote?</p>", "time": "2022-11-10T17:13:23Z"}, {"author": "Adam Roach", "text": "<p>Sergio -- I do see your email from yesterday about the \"Accept\" issue, and I'm going to have to poke at it a little bit and reply in a little bit.</p>", "time": "2022-11-10T17:13:23Z"}, {"author": "Adam Roach", "text": "<p>I'm remote</p>", "time": "2022-11-10T17:13:28Z"}, {"author": "Jonathan Lennox", "text": "<p>Ok.</p>", "time": "2022-11-10T17:13:31Z"}, {"author": "Adam Roach", "text": "<p>I'm going to reload</p>", "time": "2022-11-10T17:20:43Z"}, {"author": "Varun Singh", "text": "<p>I am in support the work as well. If there is editorial or review effort needed, I am happy to help.</p>", "time": "2022-11-10T17:24:03Z"}, {"author": "Adam Roach", "text": "<p>...and rechartering takes a while. Like, probably won't happen much before IETF 116</p>", "time": "2022-11-10T17:26:11Z"}, {"author": "Jonathan Lennox", "text": "<p>That doesn't stop people from doing work on WHEP though.</p>", "time": "2022-11-10T17:26:33Z"}, {"author": "Adam Roach", "text": "<p>Right! What I heard Tim talking about was sequencing of formal relics, like WISH versus charter change</p>", "time": "2022-11-10T17:27:10Z"}, {"author": "Mike English", "text": "<p>Is there hope that getting WHIP to a published RFC might draw more interest for participation in work on WHEP?</p>", "time": "2022-11-10T17:27:13Z"}, {"author": "Adam Roach", "text": "<p>Re: the WG name -- the recharter can (I believe) change it to \"WebRTC Initiation Signaling over HTTPS\" so that it matches what we're actually doing. :)</p>", "time": "2022-11-10T17:29:56Z"}, {"author": "Mike English", "text": "<p>Adam++ :)</p>", "time": "2022-11-10T17:30:38Z"}, {"author": "Kirill Pugin", "text": "<p>It's not extensive list it seems: DASH uses fMP4 - you can have A LOT of different things in MP4</p>", "time": "2022-11-10T17:35:23Z"}, {"author": "Kirill Pugin", "text": "<p>not just languages, subtitles, events</p>", "time": "2022-11-10T17:35:37Z"}, {"author": "Kirill Pugin", "text": "<p>conceptually, DASH is bunch of fMP4 segments</p>", "time": "2022-11-10T17:36:01Z"}, {"author": "Jonathan Lennox", "text": "<p>Which are the ones we want?</p>", "time": "2022-11-10T17:36:04Z"}, {"author": "Lorenzo Miniero", "text": "<p>I don't think it was meant to be an exhaustive list, but mostly an overview of some macro things that it might make sense to have</p>", "time": "2022-11-10T17:36:15Z"}, {"author": "Adam Roach", "text": "<p>To be clear, our problem in WebRTC isn't that we don't have a way to do subtitles -- it's that we have too many to choose from. I'd think RFC 8759 is our best bet, but this is the outcome of a <a href=\"https://xkcd.com/927/\">https://xkcd.com/927/</a> kind of situation.</p>", "time": "2022-11-10T17:36:21Z"}, {"author": "Kirill Pugin", "text": "<p>but then someone who uses DASH over regular HTTP will try to use it with WebRTC and find that some of the things they CAN do with regular DASH - they can't do with WebRTC...</p>", "time": "2022-11-10T17:37:19Z"}, {"author": "Kirill Pugin", "text": "<p>unless WebRTC is just used to do fetch</p>", "time": "2022-11-10T17:37:32Z"}, {"author": "Jonathan Lennox", "text": "<p>Any hope of doing 8759 in browsers?</p>", "time": "2022-11-10T17:38:27Z"}, {"author": "Jonathan Lennox", "text": "<p>Maybe doing something with insertable streams, but I doubt any of them handle m=application</p>", "time": "2022-11-10T17:39:44Z"}, {"author": "Lorenzo Miniero", "text": "<p>WHEP to WHIP sounds quite easy actually, and a good pro to have</p>", "time": "2022-11-10T17:40:12Z"}, {"author": "Adam Roach", "text": "<p>@Jonathan -- Good point re browser support. If you're getting all the way to insertable streams, then you could leverage something like H.264 and H.264 SEI messages to embed CTA-708 captions. And I cast back to the XKCD.</p>", "time": "2022-11-10T17:45:54Z"}, {"author": "Adam Roach", "text": "<p>But fundamentally, I agree with the recent mic comment (I think it was Harald) pointing out that these kinds of problems have far more applicability than WHEP, and should be solved elsewhere first, and adopted by WHEP</p>", "time": "2022-11-10T17:47:54Z"}, {"author": "Lorenzo Miniero", "text": "<p>DC can be unreliable, which might be a better option if you need to keep up (WS/TCP may lag behind)</p>", "time": "2022-11-10T17:48:28Z"}, {"author": "Adam Roach", "text": "<p>So my vote would be to keep WHEP simple -- at least for now -- and iterate with extensions on solutions after they're hammered out in their respective other working groups</p>", "time": "2022-11-10T17:49:19Z"}, {"author": "Mike English", "text": "<p>Thanks!</p>", "time": "2022-11-10T17:49:54Z"}, {"author": "Sergio Garcia Murillo", "text": "<p>+1 to keep WHEP simple Adam.. :)</p>", "time": "2022-11-10T17:50:20Z"}]