Session Date/Time: 28 May 2026 15:00
Here is the complete verbatim transcript of the meeting:
Marius Kleidl: ... a bit?
Jonathan Lennox: Yeah, I think so, probably. We don't need to do... maybe we don't need to be doing interims as much. So.
Marius Kleidl: Well, we'll see.
Jonathan Lennox: Yeah. Thank you for doing all the work.
Marius Kleidl: No worries. Do you already know if you are going to be in Vienna?
Jonathan Lennox: I am, yes, I will be there. I assume you will be, because it's relatively close to you.
Marius Kleidl: Um, yeah, I still have to figure out a few arrangements. Um, I'm definitely going to try because it's basically next door.
Jonathan Lennox: Yes. Remind me where you are again, exactly?
Marius Kleidl: Um, I'm in Munich.
Jonathan Lennox: Oh, Munich, oh yeah, that's, that's, that's close.
Marius Kleidl: And Vienna is just, um, I think a 3-hour train ride or something.
Jonathan Lennox: Yeah, yeah, that's pretty easy.
Jonathan Lennox: Let's give it a few more minutes to see if people join as well.
Marius Kleidl: Yeah.
Jonathan Lennox: And then we'll start.
Jonathan Lennox: Yeah, I pinged Fippo because I think he had... he was... got some thoughts on multistream at some point.
Tim Bruylants: Hello everybody.
Marius Kleidl: Hi, Tim.
Jonathan Lennox: Hi, Tim.
Tim Bruylants: So, I'm just joining to listen. I'm... I was not... planning on presenting anything, but just out of interest. Thank you.
Jonathan Lennox: Sure, sure, yeah, please.
Tim Bruylants: Yep.
Jonathan Lennox: Marius, we should wait a few more minutes. Did you send the email out?
Marius Kleidl: All right, shall we start with the introduction already? The chair slides?
Jonathan Lennox: Sure, yeah, yeah.
Marius Kleidl: All right, so welcome everybody to our virtual interim meeting. Please note that this is recorded. If you don't want to be in the recording, please stay silent. But if you want to speak up, please enter the queue with the hand icon at the bottom of your screen. Please remain muted unless you want to speak, and also please use a headset, that is greatly appreciated, to improve the audio quality.
This meeting runs under the IETF Note Well. If you are not familiar with the Note Well, please go look it up. It covers topics like intellectual property and anti-harassment procedures.
Let's start with a brief update or look over our current draft status. We have one draft that is in the RFC Editor queue, that's the RTP payload format for VP9. It has passed through IESG already and is now, I think, still probably still a few more weeks in the editor queue. We also have three drafts that are with the IESG now, that is V3C that has been with them for some time already, and since of yesterday, also the RTCP Feedback Message and Request Mechanism for Frame-level Acknowledgement, which is draft-ietf-avtcore-frame-acknowledgement for feedback messages, and JPEG XS as well. We also newly adopted the frame acknowledgement draft. The draft name is now outdated since 10 minutes ago, it's now in the new name, but it is adopted now as well.
We then also have a few drafts which are kind of sitting in an adopted state. The work on RTP over QUIC has been come a bit silent over the past months, but we'll see where it goes. draft-ietf-avtcore-rtp-apv is also rather newly adopted, we'll see where this goes. We... yeah, WebRTC HEVC (draft-ietf-avtcore-hevc-webrtc), we'll probably still see some activity there. Volumetric media (draft-ietf-avtcore-rtp-vdmc), I'm not sure, also seems a bit quiet. And for the absolute capture time, I think that was also developed by Harald, who I think has retired now, so... we'll see.
Jonathan Lennox: Either now or within the next month, yes.
Marius Kleidl: Yeah, so, it's quite likely this document will be parked or we'll see how to continue with that.
Jonathan Lennox: Yeah. Oh, just one other thing I wanted to comment. For frame acknowledgement, Erik, if you want to move your repo into the AVTCORE organization, get in touch and we will.
Marius Kleidl: Yeah, I already invited him and sent those instructions over.
Jonathan Lennox: Oh, okay, you did. Okay, good. Sorry.
Marius Kleidl: Yep.
Jonathan Lennox: Okay, you are on top of things, thank you.
Marius Kleidl: Yeah, SFrame (draft-ietf-avtcore-rtp-sframe) also has some activity still from time to time, maybe we'll see a presentation at the next IETF meeting. Um, yeah. That's our current draft overview. Documents are progressing, which is nice.
On our agenda today, we only have one item besides our chair duties, unless somebody else wants to present something spontaneously, we'll also look into that, but other than that, we are going to hear a presentation from Sun Shin, I'm sorry if I mispronounced your name, about Opus multistream. Yeah, so, let's start with that. Let me switch the presentations and then I can hand you over the slide control.
Sun Shin: Okay, thank you for giving me a chance to present this idea once again. First of all, my name is Sun Shin, I work at NVIDIA. We are working on making cloud gaming services, so we are quite relying on WebRTC implementation.
So, as a next slide, we are considering to use multi-Opus because we have already supported surround sound for the cloud gaming. So, it's a slightly dedicated use case for the gaming, unlike video conferencing. In case of gaming, we need a high-quality audio streaming for giving the player to have a more, like, spatial experiences. So that is our intention to use multi-Opus through the WebRTC. We have already announced the surround sound support back in 2022, so which is already there, but we need some more standard support.
And the goal of this proposal is to have Opus multi-stream into the standard, especially for the SDP syntax, which is not available as of today. So, our basic idea is to provide a syntax for surround sound support through the WebRTC. This is the last presentation at IETF, and today I'm going to share a little bit more details on the implementations and about the update from the last IETF meeting.
So, first thing, I think Harald last time asked me about what is the current status of the Chromium and other browser implementation. That's why I prepared this slide. So, as a current status, as I shared before, libwebrtc already implemented the multi-Opus as an audio encoder and decoder support, but it's not yet available by the SDP layer. So, which is the current status, I just captured the Chromium code review page. There was a discussion at that time when they enabled the multi-Opus, so multi-Opus is implemented as not advertised, even though the behind of the browser implementation, they have the capability. So, as of today, we have multi-Opus, but to use multi-Opus, like this discussion, we need to have a local modification of the SDP stream. So, that is the discussion, even at that time, the code reviewer mentioned about standard activities as a follow-up, follow-up as an implementation, but the standardization activity has not yet been discussed as of today. That's why I need to bring this idea back to the current discussion.
So, a little bit about the actual real-world situation of multi-channel audio support. So, in our case, the server has multi-Opus support. So, our cloud gaming server sends the offer to the browser client with multi-Opus syntax, and browser will receive this remote description as an offer, and store and validate the remote offer. When browser tries to create an answer, it will check the user agent capability, and when it detects multi-Opus stream, it marks as rejected. So, when browser creates the answer, it will be removed. And after that, when we need to set description, the multi-channel is not available.
So, this is an example of our actual SDP streaming. The server side sends the offer with this multi-Opus information with media ID 0, and we send other video-related syntax as media ID 1 and other data channel and audio as a backup. So, when we send this information to the browser, when browser trying to create an answer, it just removes the multi-channel information like this, so completely disabled when we create the answer. But other information will be adjusted, but most of the information will be preserved unlike the audio information.
And for the actual implementation in the field, we are using a local changing, which is called SDP munging. And we are, as of today, we are using this implementation, like, after create the answer, we know that browser will remove this multi-channel information, and when we detect the removal, we put it back before set local description. That's how we support multi-channel as of today, but we know this is not a standard approach, so we want to have more official or explicit support from the browser side.
So, the summary of proposal is, again, we are trying to standardize RTP SDP signaling, we want to define offer/answer rule, but we don't want to change any codec, any other behind implementation. Any questions before I move to the IETF feedback?
Okay, sounds good. And last time when I presented this idea, I got several feedback from the team. The first one, received by Timothy, and I made... I addressed this as a follow-up. Also, Mo asked about defined scope, I can explain a little bit more, also Timothy asked the offer and answer clarity.
First thing, by the feedback from the Timothy, I made a semantic interpretation and mapping the Opus family 1 as clarification, like this. So, I added this section as mapping family and extensibility. We are not... I'm not using any other mapping beyond family 1, but I just mentioned we can extend it by the spec, that's how I addressed the feedback.
Also, last time Mo asked about the scope and then also asked about how we can align with MMUSIC working group, so as, by addressing this feedback, I have added this section into the introduction. So, we made these changes to align with the feedback. So, I just added we are, we are not changing any Opus spec, but we just want to have a syntax. So, this is the information I got the update.
And then, yeah, improve the answer and offer clarity, I just made a whole renew statement, so I didn't add on this slide, but I updated the feedback. So, if anyone want to see the detail of the revision, feel free to visit this site and then leave any comment, so that I can update other feedbacks. But other than that, from last meeting, I haven't received any other feedback so far. So, I would like to get the feedback from the team today and then we can continue our discussion. That's the last slide.
Marius Kleidl: Thank you very much for the presentation, and for the updates that you've made to the draft based on the feedback from the last meeting.
If anybody has a question, feel free to join the queue, but my first question would be, where do you... how do you personally want to progress with this draft? Do you want to seek adoption soon, or still develop it a bit more on your own and then tackle adoption at a later stage?
Sun Shin: Uh, yeah, that's a great question. I believe this proposal is very, like, has very small changes, so if there are no objection, I want to pursue the adoption.
Marius Kleidl: Yep. I think that would be doable, since you also presented this at a previous IETF, it's not something entirely new to the working group.
Jonathan Lennox: Yeah, I have one question on the technical side, so, is your proposal here what exactly what Chrome is already, Chromium is already implementing, or are there changes from...?
Sun Shin: So, when you click this link from the slide, you can see that Chrome just mark the multi-Opus as unadvertised. I just need to change that, yeah, that's it.
Jonathan Lennox: Right, so I mean, so is what you're describing in this spec, if we if you enable multi-Opus in Chrome, is it exactly this, or have you extended it with things like the channel mappings and things like that?
Sun Shin: No, we just want to, like, have this multi-Opus support from the browser.
Jonathan Lennox: Okay, yeah, so, so if this is what's already implemented, that certainly is encouraging, but you know, if it's, if it's, if it's different in any way, then it would be, you know, a little more complicated. But yeah, okay.
Sun Shin: Yeah.
Jonathan Lennox: I think, yeah. All right. So, yeah, Marius, sorry for interrupting.
Marius Kleidl: No, no worries, that's all I had anyways. I think then we, we can also see if we start a call for this soon, maybe even before the next IETF meeting, I'm not sure if we have to wait for that.
Jonathan Lennox: Sorry, I was muted. Yeah, you don't have to wait for that, you should be able to do things whenever on the mailing, on the mailing list.
Marius Kleidl: Yep. All right. Um, any other feedback for the presentation or any other topic that people want to discuss now?
If not, then that concludes our interim meeting again.
Jonathan Lennox: Yeah, yeah, yep. All right, thank you, Sun.
Sun Shin: Thank you.
Tim Bruylants: Thank you.
Marius Kleidl: Thank you for the presentation.
Jonathan Lennox: All right, and hope to see you all, and hopefully many more people, in Vienna.
Marius Kleidl: Yep, in Vienna. All right, thank you very much all for joining, and then see you on the list and hopefully in Vienna.
Tim Bruylants: See you, thank you.
Jonathan Lennox: Thank you. Bye.
Marius Kleidl: See you. Bye.