Audio/Video Transport Core Maintenance (avtcore) Working Group

CHAIRS: Jonathan Lennox
Bernard Aboba

Virtual Interim Meeting

Date: February 13, 2024
Time: 9:00 AM - 11:00 AM Pacific Time

Meeting Info:
https://datatracker.ietf.org/meeting/interim-2024-avtcore-01/session/avtcore

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

Slides:
https://docs.google.com/presentation/d/1gSOrVyB9jK32fynJUx2O-noJCvcTMQrvvFqlkFhfTV8/

Notetakers: Stephan Wenger, Spencer Dawkins

1. Preliminaries (Chairs, 20 min)
   Note Well, Note Takers, Agenda Bashing, Draft status, IANA
   registries, Action items (Chairs, 10 min)
   9:00-9:12
   Presented slides: meeting tips, Note Well
   No progress on IANA registry, Magnus was supposed to work on a draft
   retirung IANA type registry.
   Draft Status (slide 6):
   V3C status--very little feedback on WGLC, Bernard shepherd.
   Christer found a problem in the SDP.
   Nokia/Interdigital indicated that they have demos/implementations
   and open source.
   One implementation of the V3C RTP is here:
   https://github.com/nokiatech/v3crtp
   SCIP: meeting with IESG, technical issues resolved, 1 DISCUSS left.

   AI: WG call for adoption of Viewport and
   Region-of-Interest-Dependent Delivery of Visual Volumetric Media.

2. RTP Payload Format for the SCIP Codec (D. Hanson & M. Faller, 15
   min)
   https://datatracker.ietf.org/doc/html/draft-ietf-avtcore-rtp-scip
   9:12-9:20
   Slides were presented.
   Chair advice regarding text changes requested by Eric: do what IESG
   wants, no more.
   Important to schedule IESG vote before IETF 119 as ballot positions
   expire when ADs leave the IESG (Wednesday of IETF 119). At that
   point the IESG will change.

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

   9:20-9:23
   Slides were presented
   Authors looking for independent receiver implementation
   AI for chairs: figure out WG github repos. Need place for test
   vectors and the like.

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

   9:23-9:44
   Slides were presented
   Browser support improving, but Chromium and Firefox support HEVC
   decoding (w/ HW) only.
   Safari will probably support both sending and receiving. So
   potential for bugs negotiating with other browsers.
   Re Issue 20: are you overengineering? Who uses open GOBs in a webrtc
   environment? Someone to put the comment into github
   Re Issue 22: (codec preferences). Browsers have historically
   supported different profiles/levels for encode
   and decode. Also, with HEVC we have receive-only codecs.

As noted in RFC 3264 codecs/formats that can only be sent need to be on
send-only m-lines;
codecs/formats that can only be received need to be on recv-only
m-lines; only codecs/formats that can both
be sent and received can be on send/recv m-lines.

This leads to a question about whether Safari TP talking to Chromium can
negotiate successfully using
send/recv m-lines. Ideally, you would want Safar TP to send HEVC to
Chromium and Chromium to send H.264
to Safari TP.

Not clear it can work without separate send-only and recv-only m-lines.

JSEPbis (erroneously) suggests that setCodecPreferences() only affects
the preference for receive codecs.
This is true for send/recv and recv-only m-lines, but is not true for
send-only m-lines.
Changes to RFC 8829bis may still be possible (it is in RFC Editor's
Queue)

Stephan: document what's right and hope implementations catch up.

AI Next step: discuss with rtcweb. is rtcweb closed? no. JSEP issues
should go to rtcweb.

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

   • 9:45-Slides were presented
   • Slide 30, Issue #50, proposed donotfix, as dependent on external
     NAT traversal.
   • Peter Thatcher: how would RoQ work if QUIC defines a way to do
     ICE that isn't compatible with RoQ's ALPN?
   • Victor: are there any alternatives to using ALPNs to say that an
     application will be doing RoQ multiplexing?
   • We might close the current QUIC over ICE issue Conclusion:
     Issue #50 closed, reopen pending (lack of) work in QUIC.
   • Slide 31, multipath QUIC support, suggest to close issue with
     donotfix.
   • We will open a new issue for multiplexing, and Mathis will post
     the PR to the mailing list. Agreed.
   • Slide 32: Issue #65, propose to close this issue as donotfix,
     but add new issue on multiplexing.
   • Bernard: Can this be done by IETF 119? Yes.
   • Peter: it makes sense to do this if RoQ is the only thing on the
     QUIC connection. Conclusion: implement both.
     Jonathan notes that we're deferring sharing connections with
     other protocols, so deferring discussion of what happens when
     you do that makes sense.
   • Slide 44 - we still think that doing the SDP specification in
     AVTCORE and then asking for MMUSIC review is the right thing to
     do
   • Slide 45 - next steps - this specification might be more
     reasonably published as Experimental (and the chairs will
     discuss this with the ADs).
   • Spencer said that some people would need a standards-track
     specification, and others would need a stable reference (so an
     Experimental RFC would be fine, especially in the short run).
   • The chairs noted that an Experimental RFC could be moved to
     Proposed Standard without publishing another RFC (this uses the
     Status Change process).
   • Bernard said to file an Issue to identify interesting things to
     look at during an experiment.

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

   10:19-10:26
   Slides were presented
   Slide 48: According to Peter, Harald's issue from the last meeting
   is already addressed by having the media PT in the "outer" packet
   header. Hence Harald's issue should be a non-issue. No one
   disagreed.
   Slide 49, header extensions, what to copy? Stephan: everything.
   Jonathan: allow for flexibility.
   Slide 50: implementation plans: Google interested in implementing,
   but no time frame.

3. RTP Control Messages (RTCP) for Green Metadata (Y. He, 10 min)
   https://datatracker.ietf.org/doc/html/draft-ietf-avtcore-rtcp-green-metadata

   10:27-10:30
   Slides were presented, contained draft updates. Jonathan: sounds
   good.
   Next step: if open issues are resolved, WGLC.
   AI: Chairs to consider timing. No github.

4. RTCP feedback Message Timing Confirmation (Shridhar Majali, 10 min)
   https://datatracker.ietf.org/doc/html/draft-majali-avtcore-rtcp-fb-timing-cfg

10:30-10:38
SLides were presented.
New draft, addressing configurable feedback timing for RTCP
Jonathan: send "at least x milliseconds" or "at most x milliseconds".
Answers unclear, may be presentation problem.
Everyone to review the draft.
No pending IPR.

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

   10:38-10:44
   Slides were presented
   Jonathan: ready for adoption
   AI chairs: discuss timing for adoption call
   Authors reminded about the existing IPR declaration

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

AI review: Missing entries in notes were corrected.