Audio/Video Transport Core Maintenance (avtcore) Working Group

CHAIRS: Jonathan Lennox (jury duty)
Bernard Aboba

Notes: Spencer Dawkins

Virtual Interim Agenda
Tuesday, October 8, 2024
8 AM - 10 AM Pacific Time

Meeting link:
https://datatracker.ietf.org/meeting/interim-2024-avtcore-03/session/avtcore

Notes:
https://notes.ietf.org/notes-ietf-interim-2024-avtcore-03-avtcore

Slides:
https://docs.google.com/presentation/d/12SV2xOyFC7vuSQLBI5W9V6eBNdDx7C5v25Bz5qjBny4/

-------------------------------------------------^M

1. Preliminaries (Chairs, 10 min)
   Note Well, Note Takers, Agenda Bashing, Draft status

• We have three documents in the RFC Editor Queue (yay!)
• RTCP-green-metadata is in WGLC, please comment.
• We want more of our drafts in the AVTCORE GitHub repository

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

• Has completed WGLC
• Is there a volunteer to serve as document shepherd?
• Action Item: chairs to recruit a document shepherd
• Action Item: Pierre-Anthony has offered to help find a shepherd

1. H.265 Profile for WebRTC (B. Aboba, 15 min)
   https://datatracker.ietf.org/doc/html/draft-ietf-avtcore-hevc-webrtc

• Issue 23/PR 24

  • This is changing "SHOULD NOT" to "SHOULD" with respect to
    tx-mode, which is what Chrome already does

• Issue 25/PR/ 28

  • There's a possibility of VCL NALUs being misrouted if they are
    aggregated in the same AP as non-VCL NALUs.
  • Need to give some advice here - PR 28 starts with RFC 7798
  • Jianlin - is it OK to aggregate VCL and non-VCL NALUs? Or should
    they be separate?
  • Bernard - Separating them will solve the problem, but it is not
    always required.
  • The problem occurs if non-VCL NALUs have lower TID than the VCL
    NALUs. That could result in video for an extension layer TID
    being routed to a participant who is only receiving the base
    layer. The VCL NALU would consume bandwidth that the participant
    may not have available and may not be decodable. But a non-VCL
    NALU with a higher TID than the VCL NALU is not a problem - that
    will just result in lower layers receiving SPS, PPS, VPS, etc.
  • Bernard - In WebRTC you can send the TID value in an RTCP header
    extension, so an SFM doesn't need to access the bitstream (which
    can be encrypted) to know what to do

• Issue 22

  • W3C WEBRTC WG is adding clarifications for sendonly and recvonly
    endpoints, consistent with
    RFC 3264. No action required from IETF.

• Issue 27

  • This is an issue for endpoints with asymmetric level
    encoding/decoding capabilities
  • Bernard discussed Jianlin's questions, with proposed answers.
  • We agree, more or less, on what the behavior should be, we just
    need a PR.

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

• Version 7 addresses WGLC and post-WGLC suggestions

• Closed Issue 24

  • any comments? none on the call.

• Do we need another WGLC?

• Action Item: Chairs to start second WGLC before IETF 121
• Has there been any testing on this?
• Lauri - have implemented some of the fallback mechanisms
• Action Item: move this draft into the AVTCORE organization

1. RTP over QUIC (Mathis Engelbart, 20 min)
   https://datatracker.ietf.org/doc/html/draft-ietf-avtcore-rtp-over-quic

• PR 226/PR 227

  • We can't actually figure out the precise RTCP overhead over
    QUIC, for various reasons
  • We can figure out a range (although things like ACKs in the same
    direction might add additional overhead)
  • Spencer - Magnus pointed out that the important thing is that we
    don't say RTCP overhead is approaching zero - because that makes
    sending RTCP almost "free"
  • Bernard - MoQ also has the same issues about stream and datagram
    prioritization - WebTransport is trying to figure out what to
    do, but we're not going to fix that in this draft.
  • Mathis - a lot of the MoQ discussion has been about control
    messages.
  • Bernard - it's really hard to give good advice, because not all
    datagrams are created equal, so simple heuristics probably
    aren't helpful
  • We can give a suggestion for an API with callbacks from the QUIC
    stack to help generate RTCP packets "just in time"

• Interop results

  • (details are in the wiki)
  • Bernard: RESET_STREAM is another thing we've seen QUIC stacks
    implementing differently.

1. RTCP Messages for Point Cloud Prioritization (Mathis Engelbart, 15
   min)
   https://datatracker.ietf.org/doc/html/draft-engelbart-avtcore-rtcp-point-cloud-roi

• This is a new draft - Mathis provided background
• The draft defines RTCP feedback messages and extensions to
  request/announce prioritization of certain regions and parameters

1. Absolute Capture Timetamp RTP Header Extension (Harald Alvestrand,
   10 min)
   https://datatracker.ietf.org/doc/html/draft-alvestrand-avtcore-abs-capture-time

• This is a new draft, based on discussions at IETF 120
• Harald provided background
• The problem is that no element has the full picture in a complex
  topology.
• SFMs that terminate RTP/RTCP provide timing information in RTP and
  RTCP SR - but they can inject delay that differs between media
• abs-capture-timestamp makes it possible to align media from
  participants on the SFM clock
• Experience from experimentation is that the approach in the draft is
  "good enough" to get synchronization of media over diverse paths
  working
• Harald is asking for feedback, and the level of interest, especially
  interest in standardizing a solution
• Bernard - need to understand the use cases. Is the goal to enable
  'lip sync' for individual participants? Is it also
  possible to align audio from multiple participants on the SFM clock
  (e.g. musicians playing together)?
• Bernard - For audio, are you talking about a mixer or a forwarder? A
  mixer can provide packets with multiple CSRCs,
  which requires timing alignment between participants.
• Harald - this is about synchronizing your audio and video, not
  everyone's audio and video, but this approach is a step in that
  direction. The "dominant CSRC" is used for alignment.
• Action Item: working group to have opinions about whether this is
  useful by IETF 121, and comment in GitHub. Not a call for adoption
  (yet)

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