AVTEXT Audio/Video Transport Extensions Tuesday 24 March 2015, 17:30 - 18:30 CDT (Room: Far East) Chairs: Keith Drage / Jonathan Lennox Notetakers: Roni Even / Peter Thatcher Agenda bash and status update: Note Well Presented Agenda Bash - No Agenda Changes Status of Working Group Documents: draft-ietf-avtext-rtp-grouping-taxonomy-06: Publication Request Sent   draft-ietf-avtext-splicing-notification-01: No concerns presented about late IPR declaration Working Group Last Call will be sent after the meeting   draft-ietf-avtext-rtp-stream-pause-07 No need for second WGLC Will send to publication, Jonathan Lennox will be Document Shepherd   draft-westerlund-avtext-sdes-hdr-ext-03 Already submitted as a WG document Monday morning Authors will update document based on comments on previous individual draft, early May Another update before July meeting, WGLC in August. Thank you to Richard Barnes, stepping down as AD.           The Layer Refresh Request (LRR) RTCP Feedback Message - Jonathan Lennox draft-lennox-avtext-lrr-00           Outcome: Consensus that the IETF should be doing this work; 8 or 9 willing to work on it or review. Discussion: Roni Even: Usually definition of feedback messages (FIR, etc) is done with payload formats. Jonathan: Yes, but H.264-SVC (only current multi-stream case) doesn’t define what FIR means in multi-stream mode. Bernard Aboba: Sending FIR for higher temporal layers doesn’t make much sense. Jonathan: Yes; it’s for multi-stream spatial scalability that FIR confuses me. Bernard: It wasn’t clear what you wanted. Would you want an IDR to happen in response to this? Jonathan: No, the point is to avoid IDR. For temporal scalability, turn on temporal nesting for this frame, even if you’re not usually using it. For spatial, reference only a lower spatial layer of this frame, not this spatial layer in earlier frames. Roni: What’s the assumption about the current state of decoders? Jonathan: Message indicates current layer being received. Decoder can say “I can decode layer 0, give me layer 1”, in which case layer 1 is refreshed. Or decoder can say “I can’t decode anything, give me layer 0”, in which case layer 0 is Intra encoded, but layer 1 can continue referencing earlier frames uninterrupted, without the bandwidth hit of a full IDR. Details of what’s allowed is codec-dependent. Colin Perkins: Should be clear how this relates to the FIR. Jonathan: Yes, what FIR for a base layer for multi-stream is unclear to me. For LRR, the layers you’re not talking about continue uninterrupted. The draft should probably have a lot more pictures explaining this. Colin: It’s unfortunate that this is codec-dependent. Jonathan: Yes, but that’s inherent — different codecs have different properties about how scalability works. Steve Botzko: Message indicates a request to create a refresh point. Do you need to define how a decoder recognizes a refresh point? Jonathan: Yes, and it’s codec dependent. Draft currently has text for VP9. Keith Drage: You’d put it in the payload document? Jonathan: For anything in the future you’d put it in the payload document. For anything already a published RFC we’d put it in this document. For things that are currently in progress, it depends where we are in the process.            Frame Marking RTP Header Extension - Mo Zanaty draft-berger-avtext-framemarking-00 Outcome: Consensus that this is something that IETF should be working on, but more discussion needed on the list to understand its scope. Discussion: Justin Uberti: When would discardable be set? Is it the same as TID > 0? Mo: No, it means truly discardable, never used for reference. Some codecs distinguish discardable-for-flow vs. discardable-for-whole-stream; we could explore whether that’s a useful distinction to make. Stephan Wenger: It is useful in some cases to have a discardable base layer. Also, you have no space for extensions in here. Mo: The final version might look very different than this, we don’t need to keep it to one byte. Keith: Please send such comments to the list; today, we want to decide whether to do this work. Roni Even: Marker bit as specified today is consistent across video. Mo: Not for layers. Also says decoders must not rely on it. Justin: It seems like everything that would be in a packetization would also be in a header. Would it make sense to just put the whole payload header in this? Mo: Goal is to abstract out what’s common among payload formats, just what’s needed for middleboxes. Bernard Aboba: For H.264 you definitely don’t want the whole payload header. But certain fields are needed that aren’t here yet. We can work these out as we work on this.   Jonathan Lennox: While this is solid for temporal scalability, not fully baked for spatial. Mo: Yes, harder to get uniformity for spatial scalability, and less used. Bernard: Agree with Jonathan, need to provide more information about how to use. Need much more detail of what implementations use. But this is a good start. Steve Botzko: It’s a good start. I see a connection to Jonathan’s draft. I think it would be a good working group item. Colin: needed for the end to end secure switching and it is an option. However, that may require changes to SRTP, so exposing payload header directly would be an alternative, would be lower overhead. Should perhaps have that discussion first. Mo: Authors would prefer codec-agnostic forwarding even without private media.   Colin Perkins: I think this is a problem the IETF needs to solve, but it’s not clear that this is the right solution. Keith: Please post that to the list, to initiate discussion. Stephan Wenger: Vidyo may have IPR on this, need to draft up a claim chart.                     Reference Picture Verification Information in AVPF - Bo Burman      draft-samuelsson-avtext-rpvi-00 Outcome: Needs more discussion, another round of author draft. Discussion: Bernard Aboba: RPSI is typically not used for conferencing, are you thinking of this for person-to-person rather than conferencing? Bo: Yes. Mo: Suggest using RTP-level information rather than codec-level, as in what’s being done for congestion control. Cullen Jennings: Suggest the WG should find a non-IPR-encumbered solution to this problem if they can. Steve Botzko: To use this at the source the information has to get to the encoder very quickly. Encoders have no good way to repair information that was lost 10 frames ago. Bo: Same problem exists with RTP-based mechanisms. Steve: I wasn’t advocating them. Magnus Westerlund: Difference today is codecs have bigger frame buffers, more depth, old reference pictures are actually there. Steve: Difference between theory and what you can do with third-party encoders. Steve: Don’t want another solution that’s codec-specific, we have an explosion of codecs. Bo: This is definitely intended to be usable codec-agnostically. Mo: suggests RTP level and not codec level. Cullen: find non IPR encumbered solution. Steve: works if get to decoder fast enough   Chairs: need a clear view of what this solution solved. (round trip time, will decoder use it, what topology)   Action: need more discussion              Encoded Stream ID Header Extension - Peter Thatcher         draft-pthatcher-avtext-esid-00 Outcome: Needs more discussion, particularly talking to the specific people who objected. Needs a new spin of the author draft following that discussion. Discussion: Colin Perkins: You can’t use PT for most of these things, you’re doing it wrong. Suhas Nandakumar: At RTP level demux is based on SSRC, the question is how do you associate this with SDP. Peter: This isn’t really relevant to where I’m going with this presentation. Magnus Westerlund: I think you’re presenting this in the wrong group, you should go to MMUSIC and discuss the identifiers in SDP. Putting an identifier in a header extension is trivial. Peter: This can be useful even if you’re not using SDP; perhaps this needs to be something used by MMUSIC. Emil Ivov: This is a real problem we’re facing, I support this work. Some part of it may need to be in MMUSIC, but part of it needs to be here too. Also, can the same ESID be used by multiple sources? Peter: Yes. Colin Perkins: No objection to defining identifiers to correlate streams; I have strong objections to the way this draft works, the way it overloads SDP format descriptions is completely broken. But the general idea of identifying streams is fine. The header extension is trivial. Roni Even: I agree with Colin, the header extension doesn’t make sense without the other part. Colin Perkins: The identifier needs to be defined. Once you do that, how you put it in SDP and header extensions should be straightforward. Bernard Aboba: I think everything in this draft could go in frame marking.