AVTEXT Audio/Video Transport Extensions 16:20pm - 17:20pm July 19, 2016 Room: Charlottenburg I Chairs: Jonathan Lennox and Rachel Huang Responsible Area Director: Ben Campbell Notetakers: Peter Thatcher, Marc Petit-Huguenin. ============================= Agenda bash and status update Status of working group drafts: draft-ietf-avtext-sdes-hdr-ext-07 [RFC Editor Queue] draft-ietf-avtext-splicing-notification-08 [IESG Evaluation] draft-ietf-avtext-rid-05 [Publication Requested] draft-ietf-avtext-avpf-ccm-layered-00 [Ready for WGLC] draft-ietf-avtext-lrr-03 [Ready for WGLC] Jonathan: draft-ietf-avtext-lrr ready for last call, made some changes, may want to wait a little bit. Hear no objection. Jonathan: About draft-ietf-avtext-rid, Magnus please take a look at Adam's response. Magnus: Responded one hour ago, mostly fine but for two things that makes me uncomfortable. Jonathan: It is ready for Ben's review? Magnus: He can do the review. Jonathan: draft-ietf-avtext-sdes-hdr-ext in editor queue. Jonathan: draft-ietf-avtext-splicing-notification has one pending discuss. Rachel: The pending discuss was that she did not have enough time. Ben: Talk to me off-line. Jonathan: draft-ietf-avtext-avpf-ccm-layered will be shepherd by Rachel. Rachel: WGLC will start after this meeting, and reviews will be requested at this time. Jonathan: Please review documents. ================================================= Frame Marking RTP Header Extension (Mo Zanaty) Mo Zanaty: New working group draft. Mo: Discussion about adding a TL0PICIDX field. Consensus in previous meeting was to add it. Mo: One solution is to eliminate the Temporal ID (TID), Layer ID (LID) and TL0PICIDX because all these would be zeros. Jonathan(from the floor): Is there is scenario where having those 5 bits would be useful? Mo: These are critical for packet loss. Bernard Adoba: There is simulcast scenario where you can use this. Bernard : The way you describe SNI(???) it would not be in a layer but still make sense. ACTION ITEM: Double check that we spell out that S and E bits mark the start and end of a layer for layered codecs. Mo: Is it worth having that optimization? Jonathan: We should allow the TID, LID, and TL0PICIDX to be omitted. Colin: Is it worth removing bytes if we have padding? ? Mo: We're going to have lots of header extensions, so when they are stacked it does help. ACTION ITEM: Will put the bit reduced format in the draft. Mo: This draft is just about ready to go. Jonathan: ?What about layer refresh? Mo: The initial version of this draft had guidances on how to use these bits, but we backed off and pointed to Bernard's draft. Not sure where it should be. Jonathan: It should be in LLR. Mo: The concerns are larger than just these fields. Mo: It would make sense to have a "guide to implementing an SFU" Bernard: It's not obvious how to do spatial layer refesh with this ACTION ITEM: Jonathan and Bernard to meet offline to discuss that. Jonathan: If we can't do a layer refresh, that's a bad sign Bernard : The I bit would not be set, right? Jonathan: No, it would not. Bernard : That's the problem. ================================================= RTCP feedback for congestion control (Zahed) We'd like to have a common RTCP feedback message for sender-side congestion control. We're designing it. Join the design team. Mo: Colin just today explained why high frequency feedback is difficult with low bitrates. Colin: The design is figuring out what we should send back and how to represent it. ???We're still doing analysis for below 2.5mbps.? It's an accuracy vs. overhead tradeoff. Zahed: Everybody want perfect packet feedback, but it is not possible. Mo: Another aspect is trying to help define interactions between AVT feedback and RTCP header extension with this new acm feedback. Zahed: This is only related to condition control. Mo: I asked in RMCAT, does this mean you stop sending as a receiver, or stop sending NACKs, and the response was stop sending NACKs. But from a video perspective, the sender knows what it sends, but the receiver does not know the frame marking that is lost. Zahed: Agree with that. Mo: It would be nice to indicate "if you do this, we don't need NACKs" Colin: This is a lot different than typical RTCP use, since it's for each packet. ? Varun: ?The receiver doesn't know if the sender will do the right thing or not.? So it can't know that ?NACKs are unneeded. Randell: This gets complex. Stefan: To use this for loss recovery, we'll need some extensions, because these packets might be lost. Zahed: All this signalling could help each other, but do I really need to design condition control that also takes care of other things? I am not convinced. ACTION ITEM: We should discuss this more. Zahed: There should be some sort of informative text. Varun: When we send one at a higher frequency, do we also send SR/RR? Maybe a larger decision. Feedback from implementers. Zahed: Please help the design team. Jonathan: Colin was asking what bandwidth are you hoping this will work at? Colin: There is various combinations which where people want this to work at. ACTION ITEM: People to send suggestions about typical operation points.