Audio/Video Transport Core Maintenance (avtcore) Working Group

CHAIRS: Jonathan Lennox
Bernard Aboba

IETF 118 Agenda
Location: Prague, CZ
Session: Wednesday, Session I
Room: Berlin 1/2

Date: Wednesday, November 8, 2023
Time: 09:30 - 11:30 Prague time
00:30 - 02:30 Pacific time

IETF 118 info: https://www.ietf.org/how/meetings/118
Meeting link: https://meetecho.ietf.org/client/?session=31566
Notes: https://notes.ietf.org/notes-ietf-118-avtcore
Slides:
https://docs.google.com/presentation/d/1kgWtK2yV3Y2JKgmVDgvK1klaLtrm6lQ88zxXy8FbAq4/

Notetakers: Mo Zanaty, Spencer Dawkins

1. Preliminaries (Chairs, 15 min)
   Note Well, Note Takers, Agenda Bashing, Draft status, Errata, IANA
   registries

Errata: #4873 verified, #4938 hold for doc update, #6752 verified

IANA Registry for RTP Payload Format Media Types:

• Bernard: Suggestion from Magnus was to update and then close the RTP
  payload registry.
• Harald Alvestrand: MediaMan WG has not discussed yet.
• Magnus Westerlund: Will write a short doc to update both RFCs on
  IANA Considerations and close the RTP payload registry.

1. RTP Payload Format for sub-codestream J2K streaming (P. Lemieux, 10
   min)
   https://datatracker.ietf.org/doc/html/draft-lemieux-avtcore-rtp-j2k-scl

   • PTSTAMP: Differs from RFC 5450 enough to be independent.
   • Will submit draft-ietf-avtore-rtp-j2k-scl-00

2. RTP Payload Format for the SCIP Codec (D. Hanson & M. Faller, 10
   min)
   https://datatracker.ietf.org/doc/html/draft-ietf-avtcore-rtp-scip

   • Three DISCUSSes, but no comments on -06 revision from IESG
     reviewers(!)
   • Bernard: The document was evaluated as an RTP Payload format
     document, according to the considerations in RFC 8088. The
     problem is that the document does not include material that RFC
     8088 indicates is expected, such as details of
     packetiztion/depacketization, RTP/RTCP transport, profiles and
     feedback. More details are also needed in Security
     Considerations.
   • Zahed Sarker: (as AD with open DISCUSS) Need to clarify why core
     RTP aspects (like profile) are not relevant in this spec.
   • Authors agree to add appropriate Security Considerations and
     Profile (AVPF) Considerations.

3. RTP Payload Format for Visual Volumetric Video-based Coding (V3C)
   (L. Ilola, 10 min)
   https://datatracker.ietf.org/doc/html/draft-ietf-avtcore-rtp-v3c

   • WGLC ended Nov 7. 3 open editorial issues. Nothing substantive.
   • Bernard will write up the WGLC summary.
   • Chairs will decide on a document shepard, likely not a chair.

4. RTP over QUIC (M. Engelbart, J. Ott, S. Dawkins, 15 min)
   https://datatracker.ietf.org/doc/html/draft-ietf-avtcore-rtp-over-quic

https://github.com/mengelbart/rtp-over-quic-draft/issues/84

• Spencer Dawkins: Based on discussions in CCWG session yesterday, not
  much to say on throughput-maximizing applications sharing
  connections with delay-minimizing applications, other than "do the
  right thing".

https://github.com/mengelbart/rtp-over-quic-draft/issues/87

• Bernard: both COPA and L4S have been implemented in QUIC, although
  we're not sure whether they've been deployed
• Randell Jesup: This draft should say "should use real-time
  congestion control" but can't say much more. This isn't something we
  can mandate, we can only request that the implementation does
  something appropriate.
• Peter Thatcher: Should also recommend using timestamp extensions for
  better congestion control.
• Zahed Sarker: Need some considerations on rate control/adaptation
  part, rather than just congestion control.
• Bernard Aboba: Per frame QP (quantization parameters) can respond
  fast to congestion, but need to know if such mechanisms are useful
  here.
• Joerg Ott: General suggestions on CC, or some specific text?
• Mathis: We've been trying to avoid including normative text about
  this topic in the draft, for reasons that are given in the draft
• Bernard Aboba: General suggestions.

https://github.com/mengelbart/rtp-over-quic-draft/issues/114

• Spencer Dawkins: Would it be useful to give guidance on using
  streams vs datagrams? Or even switching from streams to datagrams
  after STOP_SENDING on a stream?
• Bernard Aboba: Sending video over streams and audio over datagrams,
  for example, makes sense. However, switching doesn't make sense.
  What should a receiver do if it receives a video frame over a QUIC
  stream, and packets from the same frame over datagrams?
• Spencer (echoing Bernard): maybe the guidance should include "pick
  either streams or datagrams for a media flow, but don't plan on
  doing both, or switching between them"
• Mo: MoQ is doing something similar here, and decided to allow
  senders to decide how to deliver media over streams or datagrams,
  not constrained by receiver preferences. But that may reflect MoQ
  almost always doing fan-out to many receivers, and we're probably
  talking about 1:1 here. But Mo agrees with Bernard that both streams
  and datagrams are useful.
• Peter Thatcher: Another use case is FEC over datagrams for media
  over datagrams, with reliable media sent over streams. Agree this
  should be a sender optimization not dictated by receivers.

1. HEVC Profile for WebRTC (B. Aboba, 10 min)
   https://datatracker.ietf.org/doc/html/draft-ietf-avtcore-hevc-webrtc
   • Implementations proceeding in Chrome, Edge and Safari. Not
     enabled by default in any browser yet.
   • Issue 3/PR 18 (tx-mode): No objection to suggested resolution.
   • Issue 12/PR 16 (PACI packet): No objection to suggested
     resolution.
   • Issue 13/PR 17 (RPSI): No objection to suggested resolution.

RPSI has been implemented for 1-1 use cases. But there are
implementation difficulties in supporting RPSI in conferencing
scenarios.

SFU forwards the RPSI to the encoder. No need to parse the RPSI, so SFU
doesn't need codec-specific knowledge.
Encoder generates a P-frame based on the LTR, includes info on
dependencies and chains in the Dependency Descriptor.

But how does the SFU know if the newly geerated P-frame can be decoded
by conference participants?
SFU can check if it forwarded the LTR to a participant. A participant
that recently joined may not have gotten it.
But even if it was sent, that doesn't necessarily imply that the LTR was
received, decoded and kept in the participant's buffer, available for
use in decoding the P-frame.

Proprietary LNTF RTCP message indicates last seqno received and decoded.
But that doesn't tell you whether the LTR is still in the buffer.

1. RTP Payload Format for SFrame (P. Thatcher, 10 min)
   https://datatracker.ietf.org/doc/html/draft-ietf-avtcore-rtp-sframe

   • Harald Alvestrand: Payload type is negotiated hop by hop, so
     must relays rewrite this at each hop?
   • Magnus Westerlund: You have no choice but to rewrite it.
   • Mo Zanaty: PERC had a simmilar issue and carried both inner
     (end-to-end) PT and outer (hop-by-hop) PT.
   • Harald Alvestrand: Google is interested in implementing this,
     but unsure of timeframe.
   • Jonathan Lennox: Some bits like DD (AV1 Dependency Descriptor)
     may need to be handled differently.
   • Mo Zanaty: Header extensions are negotiated hop by hop like PTs,
     so similar issues with remapping them end-to-end. PERC used a
     header extension (OHB, original header block) to signal the
     original end-to-end RTP header values.

2. Viewport and Region-of-Interest-Dependent Delivery of Visual
   Volumetric Media (S. Gudumasu, 10 min)
   https://datatracker.ietf.org/doc/html/draft-gudumasu-avtcore-rtp-volumetric-media-roi

   • Ready for WG adoption. Chairs will call for adoption on the
     list.

3. RTP Payload for Haptics (H. Yang, 10 min)
   https://datatracker.ietf.org/doc/html/draft-hsyang-avtcore-rtp-haptics

   • Jonathan as individual - this will require registering haptics
     as an RTP media type as well
   • Looking for people to review this draft, because MPEG is
     finalizing an initial version of their specification
   • Joerg: is MPEG the only group that has been working on
     specifications in this space?
   • Hyunsik: yes, others are proprietary
   • Stephan: aware of a related effort in IEEE, think there is a
     quasi-open specification at Apple, but MPEG does have a history
     of taking over technology specifications, and people think this
     is the best effort in this space
   • Harald: mediaman specification registers at least 4 formats, but
     all are from ISO/IEC and stable references
   • Jonathan: there's no problem defining multiple formats - this is
     like video codecs, we have a lot of them
   • Jonathan: is this draft ready to poll for adoption?
   • Hyunsik: want to revise based on email comments to the list
     first
   • Stephan: it's pretty good already
   • Jonathan: we can do adoption call for the next version of
     the draft

4. RTP Payload Format for Geometry-based Point Cloud Compression (M.
   Engelbart, 10 min)
   https://datatracker.ietf.org/doc/html/draft-engelbart-avtcore-rtp-gpcc

   • Magnus: none of these parameters will change over time, is that
     right? point cloud is stable over time?
   • Mathis: right. We're thinking about how to signal changes, but
     that's not in the draft yet.
   • Srinivas: The geometry point cloud data can be static or
     changing over time. The MPEG I Part 18 specification specifies
     the encapsulation of both static and timed coded G-PCC data.
   • Jonathan: is this video?
   • Mathis: application, for now
   • Magnus: media type is interesting, video could work, but
     application is probably OK for now. We've had proposals for RTP
     application media types, but nothing has gone forward yet
   • Jonathan: status?
   • Mathis: this is an early draft, just wanted to provide for WG
     awareness

5. Wrapup and Next Steps (Chairs, 10 min)

   • V3C: Bernard will summarize WGLC feedback and pick a shepherd.
   • SCIP: Bernard will work with the authors on clarifications to
     address IESG DISCUSS comments.