Internet Engineering Task Force Interim Meetings, 28 Jan 2021

Previous Meeting Next Meeting

⏯

youtube image

►

From YouTube: AVTCORE WG Interim Meeting, 2021-01-28

Description

AVTCORE WG Interim Meeting, 2021-01-28

A

um Hopefully, oh there.

B

A

Great okay, thank you. So uh we have been reminding people please sign in to the virtual blue sheets, uh which are at this cody md link. um We have a note taker, uh just here's. The note well is the reminder: invite tf policies such as the patent policy and then sorry.

C

A

Asking a question: yeah.

D

This is barry is the link posted anywhere. I can click on it.

E

In the chat here, if you open the chat window.

C

Chat here, where do I find it.

E

uh Lower lower left, you see, you should see a thing that looks like a dialog box.

C

Okay, doesn't look chatty to me. Thank you.

A

um So about more about the notewell, uh it's set forth in bcp 79. As a reminder you, when you're participating, you agree to follow it processes and policies. Definitive information is in the documents listed below and other itf bcps.

A

If you want advice, please talk to the chairs or the id's all right. So a few tips about this virtual meeting it is session, is being recorded.

A

We've turned that on there's no registration required to attend the meeting, so hopefully you've gotten in, um but you do need to fill in the virtual blue sheets and uh actually, actually you can just fill in the virtual blue sheets without a data tracker login, so that's not needed, I don't think could be wrong and then, if you want to join the session jabber room, you can do that via the itf data tracker meeting icon by clicking on that that will get you in the jabber room.

A

Please use headphones or an echo cancelling speakerphone uh state, your full name before speaking, a few other little things to enter the queue you type plus q. In the chat. I guess jonathan you'll handle the queue and you leave it by typing. Minus q, if we do have a home, I'm not sure we will you raise your hand with a hand, raising tool and lower it by clicking on the hand resin tool again um and when you're called on.

A

You need to enable your audio, if you've, muted yourself and uh do that you click on the mute, unmute icon. um You don't have to use video.

A

If you don't want to, and many of you are not so that's. I think you've got that okay, so the agenda has been uploaded um and there's this kodi md thing, which also has the agenda. If you want to look at it, I mentioned the jabber room, the secretariat. uh We have a jabber scribe and notetakers okay. So here's the agenda for the meeting um we've gone through the preliminaries. Hopefully um we'll do the jpeg xs payload format, we'll talk about the framework marking working group, let's call uh the bp9 payload format.

A

Let's call ben un and sergio we'll talk about the s frame, rtp encapsulation. We have a presentation on qrt, quick, rtp, tunneling and then we'll do wrap up. So I'm going to a little bit about draft status.

A

We've published a whole ton of rfcs. Many of them were in cluster 238, so those on our out are now out yay. um We have four drafts that have completed working group last call three which we're going to talk about today. We have one expired draft. I guess we have an action item jonathan to follow up on that. um We've adopted three documents: uh the evc draft, cryptex and 7983 bis, and that's about it for documents all right. So I'm going to turn it over to tim.

F

Hi everybody, my name, is tim brelands from intupix, so I am one of the authors of the xs payload format for rtp, and so in december there was a last call wglc, but no response was given on the reflector to the to the last call, and uh so uh it was said that during this meeting we would uh see what we had to do to proceed uh further.

F

In the meantime, I have taken some actions, so uh people from fraunhofer actually joined the avidecor mailing list and people from vsf the vo services foundation also joined this mailing list in order to be able to respond to a future wglc.

F

If, if it's still required and then from jpeg committee, I asked them to draft a liaison letter to idf to the avid core working group. So this letter was issued last week and will be uh yeah will be sent by the secretariat of iso. I do not, I don't know when it will arrive here at the ietf, but I hope it's soon. So it's just a letter that actually the committee would also very appreciate the support of the rtp spec.

F

So in the the next slide, please, so my question is a little bit: uh what is the next to do in order to move the the draft forward? That's uh what I want to ask here.

A

Yeah, I think the action item which you should note in the notes would be to issue the new working group. Last call, as you note.

F

E

Possibly the chairs to actually call out to some specific people, possibly including themselves, actually yeah.

F

Because, of course, uh I don't know the quality of the text, it would be very much appreciated if, if people with a lot of uh knowledge on writing, this kind of text and specifications uh can also read it and verify if everything is okay. Okay,.

A

So I guess two action items one is uh to reissue the working last call, and uh I guess jonathan and I to review it and any other volunteers.

A

Anyway, we'll we'll harangue you later.

F

So so just a question for the other volunteers: does that mean anybody from the from the avitae core members are the ones that are subscribed to the.

A

Well, anybody on the mailing list.

F

Yes, so I I I know for at least two other people will uh also uh cross, read and normally respond. I hope they will approve, of course, that we'll see okay, so.

A

That's that's good sounds like we have a plan.

F

Okay, thank you very much for your time. Yep.

A

All right uh next item is the frame marking working group last call so a little bit of detail about that. That was announced on the 21st of november and concluded on december 6th.

A

We had stefan wenger, who um provided an initial response and then a more detailed one, uh sergio and dr alex uh basically plus one that and we'll talk a little bit about what uh stefan posted and I posted a review, which is mostly uh nits and a few other things. But um the main comment came from stefan, and this is what he said. I won't read all of it, but you can get the general idea. He basically inquired who's.

A

Anyone out there who continued to think frame marking as originally proposed, is still a good idea and will see implementations and also questioned whether it was necessary for future kodak payload formats to have a mandatory section on how to how to do frame marking it's obviously a non-trivial cost and effort and and could grow over time.

A

um So that was stefan's question and that's what dr alex and sergio uh also plus ones um and stefan provided a little bit more detail on his opinion, saying that the problem is to try to provide the main or sfu with sufficient information to do its job for selective forwarding, and to do that you have to abstract from the syntax of various codecs.

A

It's something the sfu maker wants, because they want to reuse the same logic independent of codec, but it's hard to do, and then staphon provides some historical info on the fact that this has been tried, starting in 2000. I didn't realize it was that old uh and has we got it wrong every time, despite many many, my our eyes looking into this?

A

So that's that's the basic comment from stefan so based on that we decided to call for implementation experience to try to fill in what stephan was asking. You know what were the implementer experiences? What has happened uh what's gone wrong, what's gone right, so we got a couple of responses.

A

I'll try to paraphrase here. If people think I haven't gotten, this quite right uh feel free to get in the queue and speak up, but we got one response from sergio, which was with respect to vp8 and vp9 experience, um as I I believe, one issue with vp8 was the picture. Id needs to be consecutive, and so, if a forwarder drops a frame, basically they need to rewrite it and that created a problem because it meant that the picture id you couldn't just have end-to-end encryption over the entire frame with vp8.

A

You would need to modify the tl0 pick index and the picture id. This is not a problem specific to framarking. That is, it would occur with any other rtp header extension as well. There was an issue with vp so because of that it wasn't clean to implement this with vp8, and I don't believe others can speak up. I don't believe it was ever frameworking was not supported with vp8 and chrome. I believe that's true.

A

There was also an issue with the vp9 pu bit for the temporal up: switch temporal and spatial up switch um at least sergio had issues, mapping that into frame marking and figure out what to do, uh and in addition, there, the more complex vp9, ksvc scalability modes were not suitable for use with frame markings, so basically issues with vp8 and vp9, and then jonathan replied back with h.264, which was implemented in chrome for to basically offer support for temporal scalability. The three layers in h264 abc in chrome, uh it assumed temporal nesting.

A

So every frame was a valid up switch point. So you didn't have the issue with the p and the? U bit. It was contributed to the webrtc.org base and I guess it was used by video and perhaps some other folks. That code was subsequently removed. I think because it wasn't as universally applicable wasn't used for vp8 and vp9.

A

I see mo in the queue okay.

A

D

All right just to clarify that um the vp9, p and ubit issues were what triggered the update to frame marking uh to uh to add the restriction of temporal nesting. So that was, I think at least four or five versions ago. um So I guess the real question is: do we think that that the temporal nesting restriction is too severe and in, in which case there needs to be a? uh You know, a solution to a more generic uh form of marking?

D

Or do we believe that stefan's objections mean that no form of marking will ever uh truly be relevant for for coding, because they're, just naturally um you know, every codec has its. You know naturally expressible ways and it's not right to try to club them all together in some generic abstract way. I think those are the two main issues that we need to address. Yeah.

A

Those that that's great great summary mo um just a question on my part, um all the the temporal modes, I'm aware of like l1 t2 and all that stuff they're all temporally nested right.

E

I think so I I mean.

A

I'm a little bit confused about what the issue was with.

E

A

I don't think I've.

E

Seen too many temporal nodes that did not have temporal nesting, it's sort of you know, temporal nesting is kind of a you know way of saying: don't do anything crazy right.

B

E

Modes are not very useful for all kinds of things. You want to use temporal layers for.

A

Right, I think the point uh on the previous slide and sergio can correct me, but uh so it was really more with a spatial up switch than with a temporal. I think that's true right yeah. I need.

E

To double check whether that issue got resolved in vp9, if we again, if we can so.

A

Bp8, the vp8 issue was unique to vp8 and wasn't really related to frame marking. The pu thing was more for the spatial um anyway. Other people want to talk about implementation experience sergio. Do you want to provide more detail here.

G

uh Well, I don't recall the details because it was a long time ago, but it was mainly that I had the the dc lion solution for vp9 and when I tried to move to frame marking, I didn't have all the information so I have to.

G

As I was not going to change the vp9 encoding in chrome, I just had to map those those bits in order to be able to have the same, to use the same logic that I was using before I don't know if there could be some encoding tricks that would allow to use frame marking with that, but.

B

G

Want to go into that detail when I implemented it and of course now that we have the case the the ksbc and things like that, I don't think that it is possible to do that with a with fred martin.

A

Yeah um justin: do you want to say anything about the experience in chrome.

H

Yeah, to be honest, like I don't remember, I'm not as close to this anymore, and I don't remember the exact issues um you know I think they might. My overall understanding is that s frame and the sort of uh approach there has largely obsolated this uh you know from from the chrome perspective.

H

um It doesn't surprise me that you know that some of the things like ksbc and such you know are just explicitly not covered here. Yeah.

A

Yeah a goal to cover something that complex but anyway go ahead. Mom.

E

Sorry, I know I think that was me. What I was saying was, I feel like what I found. You know the most, the only the most, which would say the primary useful case I saw for it. I think, which is also says on my slide, is the h64 case, where you're actually retrofitting information that the codec, the payload format, doesn't carry.

E

So you know so to actually provide information that you otherwise don't have, um but trying to it is compared to compared to the things that do try to do this natively.

E

It's not it's very hard to make it as rich as the payload uh specs do, especially for anything scalable yeah yeah. So I mean I guess my question is: is this something that we can still consider useful for this one use case of um of basically retrofitting temporal scalability onto abc.

A

Yeah, I think the reason why it was so useful is that chrome only had h.264 abc, so it was a way of kind of sneaking in the svc stuff, the most popular modes you know without having to implement the full uh h264 sbc stuff.

A

So um I think basically, the questions are those that mo just said. You know where we, where do we go from here? I would just.

E

Say I saw another plug queue from you in the okay.

A

E

You come up again.

D

Yeah yeah, just uh um just to address the comments about different codecs. uh I don't, I don't believe we've ever had anything where the different codecs have ever caused anything in frame marking to not uh you know to work differently. I don't believe, there's anything different between 264 vp8 or vp9 uh on either temporal or spatial scalability that that prevent uh effective marking.

D

The only problem is whether or not the streams are temporarily nested and, like jonathan mentioned, I think you know in practice, most implementations are temporarily nested, um but it's it's not to say that that more creative things could, you know, could be done with it with a codec.

D

So I don't think it's really a question of which codec you're carrying it's really more a question of whether you're carrying a a complex, dynamic, uh scalability structure or whether you're carrying a common, um simple static, scalability, structure and frameworking is it was updated to only represent the simplest. You know most basic temporally nested scalability structure, but it could do that for any codec. It could do that for even 81.. um It doesn't matter whether you're using 264, vp8 or vp9 or 81.

D

As long as you're not doing a dynamic, uh complex, scalability structure, what it conveys is still the same. The real question, I think, is stefan's point of whether or not that little bit of information is useful uh or not um with with a complex codec and with complex scalability structures.

D

You may want a lot more information and in which case you know you you're better off trying to just expose. You know the first few bytes of the codec payload and maybe that's something that could be done for s-frame. Instead of trying to normalize uh some format, common format across all the codecs just expose the the payload headers of the codecs, the first you know whatever bytes um and maybe maybe that's a better direction. If people think that they need all the flexibility that the codec provides.

D

If they don't, if people don't expect to really, you know, innovate on their, you know scalability structures in the codec, then I don't see why we couldn't just keep a simple uh static, uh normalized uh descriptor like either frame marking or the 81 dd, or something like or whatever s frame decides to come up with. um So I think that's really.

D

The quest of the issue is whether we want to normalize something in a few simple bits that will never be able to capture the full complexity of all codex or if we would give up on that and say, let's, let's just expose what the codecs have um in some. You know, codec specific uh blob.

G

I see sergio look, you yeah that's, but there is a small thing that I don't agree is that we say that this is this word for every codic and there is a part that is specific and has to be specified for each other. So we don't have a even a mechanism that works for our codex. It works different for our coders, so we have to implement it in an svu.

G

I have to implement frame marking for its sus4. I have to implement a smart game for vp9. I have to implement frame marking for vp8. I have to implement the frame marking for ab1, so even if it is, can be applied to any codec, its implementation is different, so this is even less helpful thing that the regard.

A

Yeah, but that's not a statement only about frame marking right. It would be true for any rtp extension. I guess that's an important issue to kind of tease out here. Right is it it would be true for anything, not just frameworking. It would be. You know whatever we would do right.

G

um Well, I mean I'm not sure about that. I mean just about framework and I think that and for example, the and the one dependency in the creator is meant to be used without or being kind of cateching. Another thing is, if it is, will be able to to match all the different codecs in the future, but at least it is not something that it is specific or is different to implement for each of the color. I mean.

A

Well it, but I think that it well, the the rtp extension may not be different, but this vp8 issue, for example, right basically says that you can't encrypt an integrity, protect this, this payload stuff, right or else, or else you when you.

G

A

Not going to be valid.

G

A

G

An implementation, a specific issue that prevent me from implementing, so I have not, it will happen to any, but it is something that that is specific to is also to to to chrome, to legume rtc so, and but this is what I would did not implemented. The frame marking for bp8 is not that it could not be implemented.

A

Well, I think I think yeah I mean jonathan's had some suggestions about how to make vpn implementations more uh robust, so they wouldn't create this issue. But I think if the issue is there in the implementation, um you know if the idea is to support end-to-end encryption, you're you're going to have an issue with any rtp header extension.

G

Yeah, I I even think I I submitted about that was not, but it was possible to implement ppad without having to rewrite this. This. This ideas.

D

Well, yeah, so the goal uh original goal behind frame marking and this same same goal for the 81 dependency descriptor, uh is for receivers of this. uh Of this payload. uh To be able to, you know, do things uh without digging deep into the actual uh um codec payload uh and, and that does that always uh helps the people receiving it, but it never helps the person that has to generate the the actual marking the right.

D

The codec, the encoder to packetizer layer always has to incur the complexity of understanding the payload format and building the right uh header. Even if we came up with a perfect normalized header right, there's always going to be that complexity of understanding the codec bits and and and lifting them up into this into this header. So I think we should abstract that out and- and um I think stefan was arguing that no matter how well you think, you're doing that, it's never going to be good enough. um So don't even bother doing that.

D

Just expose the codec bits as they are, don't try to normalize them into something uh agnostic.

A

Yeah, I guess the other issue, though mo was, if you're not encrypting stuff, I mean in some codecs it's clear what you wouldn't encrypt right, like vpa vp9, but in others right you can have you know in av1 you can have the you can have scalability information right deep inside not always so easy to know what you're not encrypting.

A

um So I guess you could build that in somehow at s frame, but that that's something to think about um sergio again.

G

Yeah, I completely agree about the center side. The only thing is that frame marking, even and if I had to to add a new code codec in my svu that uses frame marking, I will have to implement something at the svu. It's not because the there is a codec specific part that it is not a it's not the same for bp8 or vp9 or sus4. So, um even in that you have to do something I mean it is not complex it just for you to support new things.

A

Yeah absolutely.

E

A

Go ahead, jonathan yeah.

E

So I mean, I guess, seems to me the questions are you know, do we want to do we do we think frame marking is useful or do we want to abandon it, and if we do think it's useful, do we want to keep the requirement that new codecs um uh are, must have a section describing how it's used.

A

Yeah also, I think, there's a little bit of an issue in that. um I think we've discovered that, at least in the case of epa, the having an rtp header extension may not be sufficient to do forwarding, in other words, if you're. If you know it, should be clear that if the idea was that you didn't have to parse, the payload didn't have to touch it and didn't have to know anything about it. I think we've demonstrated at least in vp8 that that's not realistic.

E

The part of that is to do you know what consideration when you're, designing a payload format right right.

A

Yeah um so yeah, I think so uh maybe we can get people to opine on which, on the questions, you've just asked uh jonathan, uh I mean I I my personal opinion is. It doesn't make sense to throw away the document. There's. Definitely something we've learned there.

A

You know so at least we should document what what what we learned in implementing it and the issues involved do others have opinions on what we should do next.

D

Well, I guess I would uh I would tend to side with the use more than uh um than anything else. So if people think that they're going to use this or something like this, then I think it makes sense to continue work on it. If no one expects to use this, and no one expects to use something like this, then it's not worth you know uh iterating the doc anymore.

D

um So I guess the real question is that um and with all the activity happening you know in in, in both the 81 dependency descriptor and eventually with s frame, you know I I struggle with. You know, uh stefan's argument that this just can't be done, because everyone is still trying to do this. um Yeah, there's still energy in trying to do this. The question is whether or not the the restrictions of having you know a simple payload, scalability structure uh or not is it would be the next level question.

A

Yeah, I mean one of the weird things about follow-on efforts. Is they seem to have some of this same beliefs that we've, I think, we've shown, aren't true for for framarking and then that the dependency descriptor? You know it was designed for ab1, and I think it does work for that. But um you know one of the reasons for developing it was to solve the vpa problem, which I think we've just demonstrated. It does not do so. um I think there are things we've learned.

A

We've learned about issues with trying to solve to do everything, and if we make that demand of some future thing, I'm not sure any future thing can solve that either.

D

Yeah- and I would also highlight the the recent uh issue and frameworking for vvc- uh for whether or not um a gradual decoder refresh, can be signaled right exactly and that that same problem would exist with maybe one dependency descriptor and currently there's no solution for this frame either. So you know it's inevitable that that interesting things in the codec may, you know, may come up and surface that aren't captured in in uh in any normalized descriptors.

A

So so let me ask you something, though: you know what what do you think is actually doable in any rtp extension right. I mean, I think, you're making a good case that if you, if you're trying to solve you, know create a generic descriptor that prevent you know, says you never have to parse the payload of any codec right that and you'll get full functionality right. That's that's on an unrealistic expectation, not just for frame marking, but for anything um so, but people want to do this.

A

I think there's multiple motivations for wanting to do it. One is you know if you're an sfu developer, you really don't want to write parsers for every codec.

A

That's just not fun, um so you know is there a trade-off of you know optimal, forwarding versus amount of work for for parsing everything right I mean it could be some place where you say yes, I acknowledge that I can't handle everything, but you know I've saved myself enough work and you know I get enough agility where it's fine. I accept that trade-off.

E

I see q is building up so magnus.

I

Yes, magnus westland there um yeah. I I think this is very interesting because I think, especially with s frame you're gonna have to do something.

I

You're gonna have to select which information you expose, because you're gonna have to evaluate that information for its privacy impact and and actually in some cases you I mean scalability normally shouldn't probably hopefully doesn't say anything about it, but you need to evaluate it and go forward with that, and I also think if you're going to have random puncture of the encryption to support formats to be able to read this, I mean I think we end up in a situation where we also need to think about how people package the data inside this frame.

I

If you're going to have a blob of saying. Okay, this is code. Specific information, I think, is valuable to expose that still mainly need to be gathered.

I

So I don't see you getting away in that environment from selecting implementing some support, etc and therefore, I think generalizing as much as possible for what, for those use cases we know we can get. Work is probably the best here and then I don't know if the answer is saying, can we close down the scope on framework saying that this is a good enough support for this, or are we already now moving on to?

I

No, we try this, it's not good enough, but if we clarify the scope and do another extension, we can do a version two which actually works for our intended purpose. It's not going to take all the crisis, but yeah that's we're dealing with. So I think it's something to think about how we deal with this.

A

Do you have opinions if you give us direct your recommendation.

I

I

I might be I mean if no one really implemented frameworking. It might be that the best step is actually to go to v2, directly and say: okay, let's try another approach here, which we think will and and be clear on which scope of functionality we want to cover. It might be the simplest here and then we actually get better implementation support for that version too, with them having two different in the market and therefore not publishing this we other than maybe at the informational.

I

At the same time as v2 comes out.

E

Justin is next.

H

Yeah, I think my comments are largely uh aligned with what magnus uh you know was indicating uh I I do think that stefan's comment of there's always going to be header stuff, that you know we can't fit in this generic framework, and I do think that means we have to package our stuff.

H

You know differently of, like you could imagine you know s frame, just allowing uh you know essentially a way to send like that metadata in the clear um and then like well, the sv would still have to parse it like it wouldn't have to. I puncture the encryption or you know it. Wouldn't you know, interfere with the encryption functionality, which I think is really the the fundamental piece here, um and so I think what that suggests is like you know there there's some sort of frame marking thing where you get.

H

I think you know 90 of what you want from this generic thing and then, if you want to do more, you know you can just basically send the bits, and that means the sfu or the metadata. You know for the codec you know in the cleaner and the svg will then have to parse that, like I, I think that you know would really be a useful framework for a solution. You know. I think, then, that the question that comes to us is you know, is that really 90 that you get from this generic?

H

You know setup or is it like 10, and I don't have a good read on that and I think that's kind of where uh you know I'd love to get. You know the folks who worked on you know implementing this at google to to weigh in um you know we could pull in harold or some of the folks there and just try to get a sense like. Is this the 10 or is the 90?

H

You know, I think, if we're on the you know the 10 spectrum, then waiting for the v2 is probably the right call.

A

Yeah I mean um my understanding is the kind of at this point. The bar is being able to be useful for multiple codecs right. I mean, if you're going to do this, you want it to be useful usable for bpa, vp9 and h.264 and ab1 kind of if you got that subset, that would that would be a bar. That would certainly would get it into chrome. I believe that's that's what people believe can be done in chrome. If that is, I think, that's accurate.

A

You know ab2 or whatever ebc. We don't know about that, but I, I think yeah. My personal view is that h.264 alone is not is not enough of a bar to uh to take off.

G

Sergio's yeah. I want to make one a small comment, I'm regarding because, as I we are working on it on on this frame and the generic packet decision, I think that the the goal should never be to try to have something that is generated for all future video codecs. I mean because we don't know what.

B

G

Quantum encoder for whatever is going to look like, but I think that there are realistic goals should be to to at least make it work for all the cool rendering video you can mainly s264, especially five bpa, bp9 and ab1. I think that should be a really a realistic goal. I mean obviously having we don't know, what's going to happen in the future, but at least.

A

So while we've got you sergio, um what is your opinion on what to do with the document.

G

I think that I don't see the trademarking to be useful at this stage. I just think that removing it is not. I mean it's something that we have done so yes, the lighting is doesn't seem nice. I think that the idea of having it last an information and probably removing the bb9 part from the framework for bp9 and not into this to this document, so it is, it is there's at least for historical reason. I think it will be fine, but keeping removing the regarding furnace pilot specs.

G

I think that it is something that should be in, because we see that there is no reason for for supporting it. I'm probably just publishing the document. I don't know if I are physical, informational or maybe not sure what to do with that. Editorially.

E

uh Tim is next.

J

Yeah um tim hansen, I just tracking back to what justin said. I mostly agree with the idea that something useful here is would be useful, but as a somebody, who's implemented the thing that looks a lot like an sfu. There are two problems that you're trying to solve here, one of which is define the bits that you need and that's actually sometimes more difficult than interpreting them. So I think like if we skip the interpreting step and actually just did found the bits that would be relevant.

J

That would be a huge help, and maybe that simplifies the problem that doesn't answer the question as to what to do with the document.

K

D

I'm yeah answering the question about uh you know: is this uh 90 or or 10 of what you need? um uh Of course you know uh the authors are going to be biased, because uh you know we wouldn't have created this if we didn't think it already captured at least 80 of what we need.

D

um So I think when you, when you compare it to other things like what's going to happen eventually for s frame or what's you know already, you know in in progress for av1 um 90 of uh you know, the actual use of the codec is already captured in this simple uh frameworking extension. So I I think it already covers. 90 of uh you know, common meeting services, uh certainly all the ones that that I've ever either used or or worked on, um that that doesn't mean that it uh it should.

D

It should dumb down implementations to only use those features, so I'm I'm struggling with whether or not uh we should. If we publish anything, should we add text to say that you know uh um if you need to use these, you know these types of advanced features.

D

um You know here: here's how you should do it or or here's how you can do it in addition to frameworking it's not that you can't use frameworking, it's the in order to get the extra semantics you need. You can use frameworking and and this, um but I think, if you look at the core of this, the the exact same one bite thing is going to be in all in any implementation.

D

You know in any other proposal, you're going to have that same one bite thing you know frame start a frame into frame, uh independent or not. uh All those same things exist in any kind of abstraction. You could ever come up with.

A

Right, and in fact they are in all of those things are in the dependency descriptor.

E

G

Yeah, I just that I disagreed with. I mean this. Obviously, yes, we cannot be scientific here, but I disagree with the with the percentage about how useful framework is because, for example, ksbc is not supported and, for example, we are using it now for screen sharing. If I recall really how what how uh well I don't know if we were in google mid and we will be using for screencasts, I mean so it is uh something that it is not implemented and it is widely used. So it is.

G

uh I said that using the the basic sbc types is not cover 80 of the of the cases, but I mean it's just minor minor command.

A

Yeah, so I I think, certainly it's possible to you know, upgrade the document to discuss more. I mean a document already says what it's usable for right, temporally nested, which is not ksvc, so you could add some more info on that. um That would be easy to do. um Maybe.

B

D

Oh yeah, sorry I can. I couldn't hear what you were saying earlier. uh The the reason we didn't add information about vp9 in the spec was: was the workgroup didn't want to add uh uh stuff for uh just drafts? um But uh if, if people want the, you know the details about how to how to use uh vp9 modes, including ksvc, and how do you how you set the p? And u bits? uh We could certainly add that to the document.

D

If, if you know people don't have an objection to having that documented in in this spec, um but the updates were made specifically to add those those things um to to allow those things. But we didn't document how to use them with vp9, because we were told to remove the vp9 section from the spec.

E

I mean, I think the issue is that framework can't distinguish in ksdc at least it's currently in kscc and regular svc, and thus provide a sfu information as to what it needs to forward.

E

E

You know any description is going to need to include the information framework and the question is: is there ever a case where the information and frame marking is sufficient? And I think that's you know you know, and if, if you can have framework, if you need to have framework plus some other information you get somewhere else, I think it's not um terribly useful.

A

E

I mean you know other than having them. You know you know not having to rewrite your parsers all the time, which is you know, moderately useful, but not you know terribly.

A

Exciting, so um just trying to come up with what the next steps are, um what do you think we ought to do jonathan? Do you want to have some hums or where do you think we should go from here.

E

Yeah, I guess now we need to have homes.

A

um What would the first one be? Would that be on something like the publication status.

E

I mean, I guess you know baby just do you think we should still go ahead with publishing frame marking as something.

A

Okay, uh did everyone get that hum, so the first question is: should should we publish this stock document at all? Is that the hum jonathan yeah? I.

E

A

So, okay, so that's our first comment: should we publish this document at all uh and uh how about.

E

I got a whole bunch before that. I see ronnie running in the queue so, okay.

K

E

To say that before.

K

Yeah yeah, but if you change this.

K

Something then, how quiet.

A

I think your question ronnie was about uh whether future codex should be required to support it. You'd like to yeah.

E

Well, I think what I mean, but after we do you know we decide whether to publish we do decide to publish it. Then we can decide. You know if we know what we want require a future codex.

A

E

So we're going to try to use the hand raised tool for the hum which is kind of misusing the tool, because it's actually meant to ask to speak but whatever. So. I guess, if you think this should be published as something click the hand raise tool which is in the lower left.

E

A

Can you see uh every who's raising their hand? Jonathan, I I can't from where.

E

I am but yeah I can, because I'm I'm gonna tell you.

L

E

One two three, four five. I think I see six people saying we published and you think we should not publish this. Well, everybody please clear your ray's hand if you're voted for that and now, if you think we should not publish this, raise your hand.

M

M

E

I think I see because of three that's they're sort of coming and going bernard. Are you raising your hand? That's not published.

A

uh No, I raised it for publishing.

A

Okay, now I can't hear you.

E

Oh sorry, I was, I was doing push the talking pushing um yeah. Now it sounded like there was. I saw a six for for publish and two for not published, so it sounds, like you know, weak rough consensus, for we should still publish this yeah. Of course,.

A

We will verify in the mailing line yeah.

E

K

A

Where we are now okay, so what's the next um uh publication status yeah, do we still want to do this as ps.

E

So I guess, if you still want to do this as if, if you want to do this, as proposed post proposed standard, raise your hand now.

E

I think we probably should okay, I'm actually magnus. Do you have something to say before we.

I

Yes, I think it's hard to answer this question, because I think we need to actually figure out if we have something better than frameworking to publish or not.

E

I mean the tricky thing there is. I think the thing that you know we have in the broad sense is not the thing that we have in the ietf sense, because it's better.

A

And also right, and also until things are actually implemented magnus we don't know if the bird in the hand may not be better than the one in the bush right.

I

No and then- and maybe yes from that perspective, it might be better to yes, this is basically done ship it and then we get to replace it. If you find something better, that might be a way but yeah.

I

um I just wonder if it sends the wrong message somewhere or not, but that's this is.

E

I mean there are potential.

I

Should be published as experimental.

I

um I didn't know if you had experimental on your list of intended status. I.

E

Did I wasn't thinking I I would have been thinking informational, but experimental might also work.

A

So what is uh what hum do you want to go ahead with? I, I guess I don't know, I'm I'm well what why don't we hum on proposed standard and then, if see where.

B

A

With that proposed.

E

A

No okay propose standard.

E

Yes, all right, I only see one and uh something other than proposed.

G

E

I think I saw seven so yeah. It sounds like consensus for something other than proposed standard. I mean whether that's people want to speak as to experimental versus informational, or is that just uh or is that getting too much into the weeds for uh for bombs?.

A

It's a bunch of people on the queue I think.

E

uh Are they are they? Are they? Oh? Are you still? Are you in the queue yeah? Okay, yeah. You are sorry. I'm kidding.

D

Yeah, um just a procedural issue are we are we humming on? um Are we discussing the current revision of the document? Are we discussing any possible future revision? You know including changes.

D

um It wasn't clear whether or not we're saying what's in there now just publish that or we want to document some things or maybe even make a normative change to enhance something that way. That part wasn't clear to me.

E

No, no, that's cause, I didn't ask: does anybody want to speak to.

E

E

E

Ronnie, are you raising your hand for the hom? Are you raising your hand, because you want to speak.

E

You want us if you want to speak. Please give us the plus q and minus q, yeah yeah.

E

um Apparently, nobody has an opinion on that um yeah I mean, I guess I mean. Obviously you know we could take this and you know completely rewrite it to be. You know the heavy one dd for if you know in an extreme case, but um that's.

A

Yeah, I'm just just my personal opinion. um I think it's important to publish it and document the issues, because if we don't at least do that that we have learned things and that will get lost and that would be bad, um so I think we have to document what we have. I wouldn't personally try to fix every issue with it, because I think that would turn it into something else. We have something that was implemented. We learned from it and just try to encapsulate that document, publish it.

A

And make it clear what it does do and what it doesn't do right. Just leave it at that.

E

I

Yeah, I I think that's the right way forward of it. Looking okay, what's the easiest, if uh smaller, if there's small, easy fixes, roll them in otherwise just document push it out and I would say experimental with the same, we know certain parts of this might work. Fine other parts is a bit shaky and we're saying that the experiment to see if, if there's actually anything that I mean getting some experience made it potentially and otherwise we're working on.

I

Why we're looking at other designs too so, but I think, that's probably the reason so not hold it up too long, then get it out.

B

I

And then we can replace it later if we find something better.

A

Okay, so I think we may have exhausted this topic. We have a bunch of other things to try to get to in the meeting and.

E

We're about 20 minutes over for this slot in the agenda. Yeah.

A

I think uh thank you, everybody. I think we we will bring it to the list, obviously, um and try to. uh I think we have good guidance all right, so the vp9 payload format, uh jonathan.

E

uh Yeah so, fortunately the only open issue with this was a lot to do with frame markings, which is why I wasn't too worried about rolling frame marking over. um So it sounds like I I would say and I'll ask if people agree with me that maybe the thing to do is move the description of how to do bb-9 with framework into the frameworking document.

E

um Take it out of the vp9 spec and go ahead and publish 59.. Does anybody disagree with that plan sounds good to me.

A

And you know, and also include within that you know your experience with vp9 implementation or lack of same.

E

Yeah right so uh yeah exactly, but I mean, but especially because, like I said this ep9 as as written as what's been shipping in chrome, for I think at least four years now or something so we want to get that published and I apologize for it. Taking so long sounds like a lot of looks like a lot of plus ones in the chat room. So yeah we'll go ahead and do that. um I guess if uh make sure that let's get the notes and we can sort of catch up on time.

A

Okay, all right so uh we're gonna turn this over. I guess you n you'll, be presenting on s frame, rpp encapsulation,.

N

Hi um bernard, can you share the slides or I believe I am, can you see them? No, no, I'm not seeing them! Okay! Well, that's! Okay! um Are you seeing it now.

E

I think you you might need to explicitly click on bernard in the in the um so you're.

M

Seeing the slides.

E

Jonathan right, I am single, slides, yeah, okay, okay,.

B

I am seeing the slides too.

N

Okay, I think I think I need to switch to chrome. There might be I'm seeing the slide, but not always so.

N

Okay, in the meantime, um so sergio- and I based on our last meeting.

M

Started to okay join the.

M

A

Are you okay, you win.

E

We're not hearing you you, yuan. Are you trying to get something working.

E

I think you might be trying to join from chrome. Oh okay,.

N

Okay, I'm seeing with slides now.

B

N

Okay, let's go to yeah the goals um so from the last meeting uh sergio and I started to dive into how to support headframe and modularly instability, which both are breaking the assumption that uh from the encoder to the packetizer, nothing happens so that the pythagorea can no longer assume that uh encoded data is correct, and um certainly we could try to update ace frame or install streams to try to handle that. But it does not. It's not really tractable uh to handle that with existing codecs and future codecs as well.

N

So it might be better to find with a solution that that is more generic and meaning that minimize impact on the intermediaries, like it's a fuse or browser, and maybe if we have a good solution, it can actually get us some bonus like simplification like no need for new packetizer implementation in it. If you are in browsers that is for web access next slide.

N

So what what we broke? The things in three parts? First, uh given the change of s frame or installable streams, um we need to change a bit of a processing model. The packet packetizer can no longer really split frames. uh So it's really up to the application that is doing the transform to actually do it on the wire, of course, some changes.

N

Some changes are needed, um so we thought of using a generic participation uh with side channel information so that intermediaries can still do uh their current processing like with packets or even process packets, because somehow a browser that is receiving content is also an intermediary to the web page, and if we change what gets on the network, of course, we we need a way to negotiate. So, let's look at all these three things, starting with processing model next slide.

N

So the proposal there is, hopefully simple and straightforward, so the encoder is generating a frame. The application is modifying the frame and the idea would be that the application may be able to split the encoder frame in individual subframes and the packetizer. The generic practicalizer would then work on each individual subframe as an independent frame to transmit.

N

If we look at uh an example like using h264 with this frame, it's almost like today, h2c4 encoder encodes, a frame we encrypt it and then packetizer sends it as one frame uh in other applications like svc.

N

Where, on the decoding side, you might actually want to decrypt different layers independently, it's good if the application is splitting each layer in its own individual frame, but the packetizer will then process independently and the same could be applied to even h364. If, for whatever reason, an application wants to split frames and http for frame uh in two, because there are good reasons for that, then it can be done. uh It's really up to the application to to do it um next slide.

N

So once we have uh individual frames, uh we need to send them on the network and there the idea would be to uh given the frame is just opaque data and metadata. uh We could put the opaque data in the uh in the as a payload, and the packetizer would do nothing on the payload. Would not prepare data would not depend. We wouldn't do nothing, but except splitting it into rtb packets. So we we get a very dummy, packetizer, very simple, to implement.

N

Of course, it works with any codec, and all the complexity is less is uh left to the frame metadata that is sent as an rtp header extension. So if you look at sframe, the idea would be that what is double encrypted very high, highly protected it's in the payload and what is still necessary to leak to intermediaries.

N

Then it's an rtp head extension with sergio. We started to enumerate what's needed and it's really similar to what frame marking is actually doing like codec profile frame type. uh We think we think it's interesting to look at what instable streams is also exposing prior transform as a source of inspiration as well.

N

That does not mean that the proposal define its own ltp head extension, maybe there's a place where things can be split like a base, rtb head extension and application specific attribute extensions as well for advanced cases.

N

We have not yet flowed deeply deeply. There.

M

Injecting myself.

E

Individual, so you describe that you know things are very flexible for the packetizer. Does that mean things are complicated for the d-packetizer because it has to be prepared for any possible thing. The packetizer could have done, and it might be helpful to describe this in terms of what a fever.

N

Okay, go ahead, so the dedicatizer processing is very simple. It needs to know when there's a new frame that is started, so it's just rtp processing and when it ends, that's that's about it and then what it will do is concatenate all all these blobs into one big frame and pass it to the transform pass it over to a transform, but we'll do processing before sending it to the decoder.

G

Also, I think that I would like to to add that, as we wanted to clarify some some grounds before going to today tell about what a frame is because it's not, we can get lost about deciding if we should go to slices or whatever and or frames. So I think that there is a lot of work that we can agree on before going to to that fine detail that it will be easy, it will be difficult to agree on, but will be easy to implement.

G

So I think that that it is um our goal now is to try to to to not.

B

G

What gets into the packetizer, but just define how the packet ourselves will work and and with the splitting, then what comes into into several packets and how the metadata is sent and how it is negotiated.

G

When we agree to that, we can just decide how we apply that to the codex if we want to go to deeper to a slices or we want to just have frames or whatever, but in we felt that if we start discussing about the specific this specific topic, we might escape all the other things that will allow us to progress further. Okay,.

E

You see magnus in the queue.

I

Yes, so I I think, that's actually quite reasonable to look at because in some sense, this r2p payload format is going to be so possible to misuse or as a misuse of misuse. You can use it in any way and you could even throw multiple sources, multiple streams into one single ssrc and and be done with all the things about how efficient the repair mechanism works, etc.

I

But- and- and I think that's where this becomes goes from- the very basic payload format that I agree would probably be fairly straightforward to that generic designs and what responsibility falls on the packetizer above the s frame and and how that describes and how you get that interaction between that level and rtp and what it implies for rtp- and I I mean that's probably a separate- or it's at least the side part of this document or maybe model for s frames and rtp usage, because that's just going to be needed because that what's been spent.

I

What we are spending time has been spending time in every core about payload formats to understand. What's the best we are doing that suddenly ends up in that high level discussion, what you put in this frame and not in this rtp payload format, specifics.

O

Hi, can you hear me? Yes, yes, um yeah, a kind of echoing magnus's comment. um It's not clear how much if any of our tp is left once you've done this and you know, maybe it is time to to replace it, but you.

B

O

This seems to be just saying that you know all of this effort we've put into payload formats and um signaling and different source identifiers and different recovery mechanisms, and all of that isn't isn't important and we can just do it all in a generic way.

O

um So this seems like a really quite startlingly large change to be proposing as a payload format. So I'm a little nervous about scope here.

G

Well, but again, I'm not sure if we should discover the scope, because I mean it was already agreed that we were going to go with. We were already going to to work on this, but anyway there. uh This only er is for the.

O

I don't, I don't think you can say that it's out of uh that we.

G

Cannot, and but I mean that not regarding I mean about this- and this is these slides, because I mean what we were talk is to present this. Ladies, I mean discussing about. If this is relevant or not I mean we did it last time and we agreed that we were going to present this anyway. Regarding the what rtp, we are only talking about replacing the the codec specific rtp packetization for its packet, I mean the knack, the fake everything else is still rtp, so I would say that it's.

O

But that's fundamental to the way rtp works. That's that's been in there as a fundamental feature of the way we handle codex in rtp and the way we handle recovery in rtp and the way we handle signaling in rtp since day, one and you're saying to replace it all. That's that's! Not a small change.

G

It's probably not that there is no other word to suit this. There is no other way to support this frame, so I mean I would love to support this frame with current mechanisms, but it is not needed.

O

So I I'm not sure I necessarily believe that, um but I think my more fundamental point is, if you have decided the mechanisms by which rtp supports this are not appropriate, maybe rather than building something which isn't actually you using 90 percent of rtp's features uh and calling it rtp. Maybe we should just do the the new thing.

N

I I I don't agree that we are using like no rtp at all. We are still planning to use rtp headers, we're still playing to to to use what's available. It's um if.

O

You look at implementations.

N

So I, um if you look at how, for instance, it's done for audio it's done in a certain way and video is different. But for sure- and I agree that, uh like all the work work that was done to do codex, specific participation has some benefits and with this approach we lose some of these benefits. So we need to document this and compare with the benefits, and if we, if we're seeing that we we're getting more with this approach than we are losing, then I think we should go ahead.

N

So it's why it would be uh very beneficial, there's a github repo, where we could start discussing all the benefits and what we are losing and it would be great if you could provide input input there raise issues and precise exactly what we are losing there. um So I I.

O

Am raising issues and I can raise the issues in the working group. Thank you. We don't have to go to github to do them. We have the working group sessions such as this to raise the issues.

N

Yeah but it's good to be able to continue discussion uh during having them. And I mean.

E

Having them in writing rather than speech so explosive is probably helpful, so whether that's on github or.

N

You know, invest.

E

N

But probably the other thing is I. I completely agree that it's a change and we should not do it lightly.

N

But we need to to get to uh precise issues uh if, if it's like, oh, we we've not done this. We decided to not go there during uh uh 20 years and now we are planning to to go there and we should not try to do it because that's not how we we've done it. That's not great, if it's more to say, hey, there's this issue there and you cannot solve it with what you're proposing then even it's great to uh to try to tackle this besides issues and we can make.

O

Progress on what I'm saying is not um don't consider this. What I'm saying is that, if you're going to build something which basically throws away most of rtp, then throw away rtp and do it different use a different base because you're not using most of rtp's features here, you know the result, isn't really rtp anymore. So.

B

O

Than trying to shoehorn it in, I don't understand that.

A

Yeah, so what might be helpful- and I I don't think we'll do be able to do it here, but at some point, maybe in the next meeting you end would be to talk about how insertable streams work. So I guess everyone's on the same page because- uh and this may be in fact another issue, but insertable streams does use, try to use the rtp infrastructure, um whether you know it has its own issues, but that might be a useful thing just to get everyone on the same page. At some future meeting.

E

See justin in the queue.

A

Justin justin you're muted, if you're talking.

H

Sorry my headset cut out raise you prompted me. I didn't hear the prompt. uh I was going to agree with you and that uh you know we are using a a significant amount of features of rtp. You know everything from the header to recovery mechanisms to ssrcs.

H

You know the features that are used for like recovery. uh You know in video, I think, is a pretty small fraction, and so anyway, I agree. We should try to get the issues documented here on the mailing list or on github or whatever, and then we can try to understand. Like you know, are these like really critical issues? um You know and there's a lot of great. You know stuff.

H

You know even just the encryption mechanism that we're getting for the outer encryption encapsulation, you know, is providing a lot of value so like I think we're actually getting a lot of benefit rather than trying to go. Do a new thing, which would you know, have a lot.

E

E

uh Magnus you're next.

I

Yes, so I I I I'm quite convinced that this great possibility to use a lot of the rtv functionality with s frames.

I

What I see as the issue here is, is that calling and the others you're talking past the child, because you haven't, you need a document that actually describes how you can utilize them. I know that some stupid implementations will not use it, but at least have something describes he's here. This is the features of r2p.

I

Here is how you actually use them, so you can get this benefit because of what existing rtp, for example, repair and all these other things, but that's needs to be described, um and I mean looking, for example, at some of the grouping etc and how the streams relates to codecs, etc, and especially for the scalable codecs, and you can actually maybe have some flexibility to do things which wasn't that easy to do with rtp here and for experimentation etc in this framework in the end, but I think we need something which actually talks a little bit about the texture of this change and how you use rtp from that higher level.

I

When you have the flexibility here, which s frames is gonna, because estrogen is gonna, hide things and you're gonna write your own code for this potentially.

G

I I agree with that. I mean we have to have it. The only thing is that I think that it is too early to to have it and also because it depends on the some discussions that are happening in s frames so and at the end we will have to have this this this for sure, because we cannot expect to have any interoperability between the endpoints.

G

If we don't write that document, the only thing is that I would prefer to start this, that it is easier and also get feedback from this frame and to advance that document in a later stage. When we also note how s frame is, is going to look like okay, is it reasonable.

A

To expect that we'd have that by itf 110 sergio okay.

E

I asked moses less than the q at the moment.

D

Yeah, I think the the mental model that I have uh for for s frame um impact rtp is similar to red or effect or other things that also impact packetization. So I think if we don't look at this as we're redefining the packetization of the fundamental codec, we look at this as we're we're a wrapper. We're providing a privacy wrapper just like red provides. A redundancy wrapper in fact provides. You know a resilience wrapper. um I think.

D

If we look at it that way, then there probably are still a lot of pieces of rtp that can still be used, um and we just define the extra bits that these uh that these extra transforms do in the same way that red or feck would have defined them, and we still have the fundamental rtp packetization described in whatever uh you know: negotiation you're, using if you're using sdp, you still negotiate the actual codec and its actual payload format parameters.

D

But then this transform is an additional payload type that you're that you're sending that transforms it, and maybe you send none of the original payload type, and only this transformed one, but I think that's that's doable and workable.

N

Yep um we have some slides just after that, but uh tries to give examples of uh how we could we could do that with sdp and how it would relate with payload types. So.

A

N

A

Go there uh just wondering.

E

A

What to do with your.

E

A

Is he calling in.

E

The queue do you want, I mean we're getting yeah.

O

Yeah, so I was just going to say that I mean maybe mo what mo is suggesting matches, what what's being proposed. But it's not. You know that. That's not what I'm getting from this description.

O

So so I do think we need to have that architectural discussion and sort of you know sort of get a clear description of what was you know that the high level description of what's being proposed before we dive into the details, because I think some of us are looking from one angle and some are looking from another angle as magnus said and we're talking, you know we're very much talking past each other, and you know that the people proposing this perhaps have a different view of what's being proposed to to some people who who are sort of coming at it from from different viewpoints.

O

A

um John jonathan, a question: we have the rest of this presentation plus another one. How do you propose to manage the time.

E

E

I don't know I was just wondering that um what do people take? Do you want to do this and skip quick, rdp tunneling, or do you want to go quick, rdp, tunneling.

A

Can always schedule another interim if.

E

Yeah, I'm useful absolutely or you know it's not that long to march either. um Let's I think that's we seem to be having an active discussion on this, which is, I think, how much how many more slides are there on this.

N

A

N

Yeah a few like there are various options, but maybe I can skip for them. uh Yeah.

E

I mean it sounds like maybe we need like better fundamentals, clarification which it sounds like is somewhat missing some more over. Yes, maybe we should say you know, encourage the. You know, authors of this, to give more of that general overview and then.

A

Yeah, I think that would make more sense, rather than getting into a whole sdp negotiation discussion right now.

E

You should have a side conversation, you know privately with the people who don't seem to you know I mean.

G

To present to president here in this meeting, because we provided our viewing last one, so we want to, we are going to stop this this draft now and wait. I have next meeting to present the same thing that we are. We present the last one.

N

Yeah, I'm still not exactly sure how we could, uh what what is it exactly asked for for us to to provide yeah uh what initial information is requested, so it would be good to clarify uh precisely the next steps. Then, what did we ask there? uh Certainly one next step is to have a draft.

O

Right I mean I mean that that was what I I was going to say. I think we need a draft that describes how this fits to the rest of our tp, because um you know you know clearly the people who are pushing this think they have provided on every view, but um I I am, I still have a bunch of um you know it doesn't seem like we. We have a clear understanding of how this works. From my point of view.

N

Which just says there are a lot of assumptions.

O

Here, which don't seem to be written down anyway,.

N

Yeah, so that's: okay,.

O

N

Maybe we can, we can start an email thread.

E

N

You know an email thread.

E

Or maybe even a side discussion between maybe the authors of this- and it sounds like colin and maybe magnus are the ones who are most have the architectural question. So.

N

Yeah, I'm not quite sure exactly what I should clarify, so it would be good if you could like provide. uh We.

E

Need to clarify.

M

The clarification.

N

M

Sorry about that.

G

Yeah, if we know what I mean, I would be very I mean I would love to to clarify, but I would need to to know exactly what are the doubts without that we can. So we can answer that.

O

I mean I have, I haven't seen anything which describes how this fits into the itp architecture and so.

M

Do you want an implementation.

A

Well, that that might be.

N

M

N

Well, if you have an implementation, you have a spec really, so I can. I can provide you an implementation. If that's what it's needed.

B

You and sergio- I I think I think I know, or we can move forward with that. uh I propose in the spirit of time that we take that offline. The three of us speak a little bit and then we come back to colleen.

A

B

A

All right, so we have six minutes left. um Is that enough time to talk about quick, rtp tunneling, I suspect maybe not.

L

I I can probably do my talk in about five minutes. If.

A

I talk quickly you're willing to do that. uh Why don't we go to that then, okay, samuel! You have the floor.

L

Thank you very much uh yes, so uh hello, my name is sam hurst and I'd like to talk today about myself for carrying rtp sessions of a quick transport which I'm calling qrt uh next slide. Please.

L

uh Yeah, so for some context, I have recently doing a lot of work in the form of doing ip contribution for broadcasting events. uh So how do we get video from remote production, crews back to a base used to be using live events?

L

uh We currently use rtmps, which is a little archaic at this point, with no support for more modern video and audio codecs, which, thanks to the hard work of everyone in the avt core, we can do things like hebc and vvc and vp9 whatever we wanted to do so. We've been looking at other protocols such as hivision's udt, based srt and the video services forum's rtv based rest.

L

uh Our requirements for an ip contribution protocol include strong encryption for authenticity protection, as well as a good codex support and latency streaming uh in order to carry multiple rtp sessions on one sort of logical packet flow. uh We noticed that ripst wraps rtp sessions in a set of gre over udp sessions uh and quick's concept of streams gave me the idea of doing this over quick instead next slide. Please.

L

uh For those I'm familiar with quick, quickest built on top of udp uh with, and it has selective acknowledgement for lost detection uh and has uh full tls 1.3 encryption built right into the protocol.

L

In addition, it has other features like connection migration, which allows quick client to move between different networks for reliability and performance reasons, and while quick is normally a fully reliable protocol, there is a datagram extension which allows you to carry data that is acknowledged by the protocol, but the application can control any arq behavior or for re-transmissions, and that sort of thing on top next slide, please so with quick state of ground extension frame. uh Qrt is a relatively simple mapping of rtp.

L

On top of the datagram frame uh within quick transport, I've deliberately designed the system with the goal of supporting the carriage of several rtp sessions uh down a single rtp tunnel, as as it is, uh and I'm replacing the traditional rtp rtcp port pair uh with an opaque flow identifier, which is similar to how the quick streams work if you're familiar with that uh and qrt uses quick selective acknowledgement to satisfy the conditions of the rtcp generic mac framework.

L

uh So it the uh application, will feed that information back in for that uh next slide please. uh So. This is just an example use case uh to show how qrt can carry several independent rtp sessions over uh several qrt flow identifiers uh and there's just an example, remote production that I came up with so everything in the blue box is a single tunnel and we're just doing multiple rtp sessions down there uh next slide. Please.

L

And this is another example which shows one of quick's beneficial features which is connection migration, uh so once the client comes into the range of another network which has fewer hops or potentially more bandwidth, they can swap to the other network without interrupting the connection. As far as the client application is aware, this can also be used in the case of one network, connection, dies or becomes usable for any other reason.

L

Next slide, please.

L

And finally, the status of the qrt draft I've published a new draft one earlier today and I'm starting to work on a first step, implementation to use for some experiments and knowledge gathering.

L

As for the future of the draft, I've got a list of different things which I'm looking into adding to the draft which I've got on screen there um I'm happy to consider any other features as well. I noticed that there's a few questions that have just popped up on the screen, um so.

E

We don't have very much time, but I see spencer first in the queue.

C

Yeah, so this is just a a uh silly question, but I should ask it for the chairs, uh so this draft is uh the draft file. Name is uh targeted to the quick working group. Is this is avt core the right place for this, so that uh uh refiling it with a different draft name would get this more attention for the right people. Thank you.

E

um I mean, I think, it's it's probably sort of an open issue. What's the right working group, but I'd be kind to say it's probably in scope, though, possibly with some pressure tweaking if necessary, we need to look over about the current charter says um I mean.

C

This seems very timely because quick has got open activity to uh do new chartered activity. uh You know now that they're getting ver be won out, so it seems like an excellent time to have that conversation. Thank you.

I

Yeah, may I clarify as transport id here sure the the intention here really for quick working group is to focus on quick extension etc, and it's not clear here what's if it's just protocol mappings mapping onto quick for protocol like this, I would say: that's mostly related to the working group where that pro original protocols, let's get the mapping it should be. So I would say this is probably abt course matter more than it's quick if there's need for extension, etc for to realize this, then it's it's a matter of interacting with quick working group.

L

Yeah so so far, there's no actual uh interaction on that side, with any extra extension frames in quick or anything that it's it's purely a protocol mapping at the moment um it depends.

E

L

E

It might be a good idea to republish this as a draft. Your name avt core, rather than draft your name quick.

L

Okay, right, that's fine! uh I I think the name mainly came from quick rtb tunneling and just has to have happened to have questions.

L

Yeah, I can do that.

E

After we're done with topic,.

H

uh So we've looked into this uh several times over the past. You know five years and uh one of the key sort of underlying problems ends up being that both quick has congestion control, and uh you know the rtp has its own congestion control ideas, and these things, like uh are hard to kind of decouple like. Is this something that you have been able to solve?.

L

uh So, by using the datagram frame uh we saw we don't entirely negate any uh sort of connection or flow control in the quick space, but it we're just sending udp packets and using uh the the quick transport encryption uh right, real estate yeah. So data.

H

Isn't extension right, but that's still subject to the quick congestion control envelope so like that ends up being a pretty fundamental.

L

Problem uh yeah, I I think with I've, been trying to keep up to speed with with exactly what congestion control in the datagram frame uh is uh means at the moment, uh and it this is sort of something which I'm really hoping to experiment with when I get that far, uh I'm sort of just lobbing backwards, packets backwards and forwards at the moment.

L

uh So I don't really have a firm answer on that. Just yet.

A

um Since we're almost all out of time, I just want to get clear on what the next steps are. I guess jonathan you suggested republication as an avt court document. Well,.

E

I mean as a document. It still is an individual document, but.

A

It's an individual document, but yeah targeted. um Are there other next steps? Should we assuming that's done? Would you are you interested in review comments.

L

Absolutely yeah, so any and all review comments on this uh are great uh uh on the next slide, which is my last one. I've actually got a link to a github project uh where I've I I collate issues and things on it. So if you can raise stuff there or you can send me an email directly or do it on the mailing list and I'll see it, I'm more than happy to take any feedback uh from anyone uh on it.

E

All right, as I've mentioned we're out of time, but I think I think we can probably you know this is probably see there seems to be interest in this. So probably, I suspect, we'll you know, have this on the agenda at our next at either. You know the march meeting or if you have another interim.

L

Perfect yeah I'll I'll do that thanks.

A

Very much okay, thank you, uh everybody.

A

I think we're done for the day.

E

Well and uh there's one comment uh also on the chat: please make sure that the you know try to attract um attend. You know probably bring it to the attention of the quick working group as well, even if this is going to be the group that probably owns the any subsequent work on that just so that that group is aware of it. That's janna, pointing that out in the chat.

E

All right well, thank you, everybody, um and we will see you whenever our next meeting is have a good day.

E

L

F

Thank you very much.

F