AVTCORE Audio/Video Transport Core Maintenance 11:50pm - 13:20pm July21, 2017 Room: Berlin/Brussels Chairs: Jonathan Lennox and Rachel Huang Responsible Area Director: Ben Campbell Notetakers: Varun Singh ============================= Agenda bash and status update RFC5285bis: mux-category be of extmap-allowed-mixed: Normal or Identical Roni: if you do normal, you can do idenentical, but not vice-versa Magnus: This represents an RTP session, and there is no reason why all implementations need to pay the price for this complexity Jonathan: We want to move to mixed. I would argue for identical because the goal is to move everyone to do this. Mo: not add the attribute and have everyone do this. All RTP stacks with bundled, we have to do this, because the stack needs to handle this any way. Roni: just to respond to the criticism, i.e., if you have the problem, then the burden of implementation is on the endpoint, but it will break a few of the existing products. Chairs: Is there a strong objection to Identical? None, so Lets go with IDENTICAL DECISION: Roni will update the to IDENTICAL ARIA SDES Roni will confirm if ARIA needs SDES or not... (??? confirm with roni) MPRTP (Varun): Security needs some help Chairs: more people should review it Multiplex guidelines Roni: needs to do some work, not blocked on anything ================================================= Frame Marking RTP Header Extension (Mo Zanaty) Use only H.264 and VP8, the new codecs will add this to their respective payload formats. So VP9 LID mapping moved to their own draft Mo: so we can clarify that they should depend on the temporal layers Slide ??? Jonathan: make sure we say it applies to future codecs that use spatial and temporal scalable. Discard Priority Complex Scalability Structure: it is not recommended Bernard: will need more guidance on what is considered more complex, for example, the ones in LRR diagrams? Jonathan: Not the ones in the draft but maybe the ones I had in the slide, yet. So maybe we need to define this Bernard: spatial diagrams in LRR are not hierarchical. so??? Jonathan: the higher frams depend on the frames on the same layers and not the lower layers. need to specifically say what an endpoint can depend on Colin: the problem with the text, is that it is not specific, then ideally, it should say that we should do X if these characteristics exist, else not do it. Mo: slamdunk for temporal layers, we do not have names for the other complexities. Colin: we know the following things work, so lets document that instead of saying what does not. Jonathan: "these are things it is for" +1 VP9 P and U bits vs I and B bits bernard: related to the previous bits on spatial... when we drop a higher spatial layer, when do you get it back? that is where the P and U bits come in. Especially when you have multiple spatial layers Jonathan: In the temporal hierarchical structure, the U bit needs to be set. Jonathan/Bernard: P is more interesting, and the B bit could be redefined for (non-spatial base layer)??. Mo: it has no temporal dependency on another layer. Jonathan: LRR calls it, Layer refresh, and that is what is marked? Other issue Roni: we are missing a priority request for the non-scalable codecs,1 bit for: low motion vs high motion. Some B-frames are droppable? maybe need two bits ... (was at the mic) hum for the additional bits do the people think in the need a priority bit for non-scalable DECISION: moderately opposed, no concensus. Not do it now, and use colin's proposal: progress the current draft as it is, if there's any interest in the priority, submit another draft to extend it. ================================================= RTCP feedback for congestion control (Zahed) no objections to doing the work no objection to adopting the draft 205 vs XR vs new RTCP --> leaning towards 205? DECISION: submit a new version and use that as the starting point of the WG draft for avtcore