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

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

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

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

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.

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

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.

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

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)