# Audio/Video Transport Core Maintenance (avtcore) Working Group {#audiovideo-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.