Minutes IETF99: avtcore
minutes-99-avtcore-00

Meeting Minutes Audio/Video Transport Core Maintenance (avtcore) WG
Title Minutes IETF99: avtcore
State Active
Other versions plain text
Last updated 2017-07-26

Meeting Minutes
minutes-99-avtcore

   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