# Audio/Video Transport Core Maintenance (avtcore) Working Group {#audiovideo-transport-core-maintenance-avtcore-working-group} CHAIRS: Jonathan Lennox Bernard Aboba IETF 116 Agenda Location: Yokohama, Japan Session: Tuesday Session II Room: G314 - G315, 3F Date: Tuesday, March 28 Time: 00:00 - 02:00 Eastern Time 04:00 - 06:00 UTC IETF 116 info: https://www.ietf.org/how/meetings/116 Meeting link: https://meetecho.ietf.org/conference/?group=avtcore Notes: https://notes.ietf.org/notes-ietf-116-avtcore Slides: https://docs.google.com/presentation/d/1LG-NOLbH3drMPki4JQuW5vAgljBYLky\_Zs6nwnVTVlc/ Note taker and onsite chair: Harald Alvestrand * * * 1. Preliminaries (Chairs, 10 min) Note Well, Note Takers, Agenda Bashing, Draft status 4 RFCs published, rfc 7983bis now in RFC Editor queue. One in RFC Editor queue (vp9) with missref (framemarking) now resolved. 4 new drafts adopted 2. RTP Payload Format for the SCIP Codec (M. Faller, 10 min) https://datatracker.ietf.org/doc/html/draft-ietf-avtcore-rtp-scip Dan Hanson presenting. Draft -05 distributed by email, to be submitted after the meeting. Changes suggested at the meeting on feb 23 have been incorporated. Main point is that network devices MUST NOT filter or modify Packetizing and depacketizing procedure is made clearer. Figure added, showing the architecture. Packetization is handled within the underlying codec, then passed to the SCIP layer which encrypts them. SCIP also provides its own messages, which are in cleartext prior to key negotiation, and are encrypted afterwards. SCIP packetizes the control traffic as well and passes this to the RTP packetizer. Roman (discuss holder): still don't understand why there can't be a normative reference to SCIP describing the content. Bernard: The VVC RTP payload format had the VVC bitstream spec as a normative reference. However in this case, the payloads are (with the exception of the initial key negotiation) encrypted. This means that there is nothing for the packetizer to parse, it just places the opaque blobs handed to it by the SCIP codec into the RTP payload field. Similarly, on reception the RTP de-packetizer hands the opaque payloads to SCIP which decrypts them. Dan: Since the packetizer and depacketizer aren't parsing the opaque payloads, there was no need for a normative reference to the SCIP specifications. There is nothing in the SCIP specifications that needs to be understood by the packetizer and depacketizer, or by intermediaries. That is the major point of the document - intermediaries have been attempting to modify the payloads, with disasterous results. For the specification to operate correctly, the payloads must be treated as opaque. We have discussed this in multiple meetings. Decision: Authors will publish the -05 document and ask for IESG feedback. 3. RTP Payload Format for Essential Video Coding (EVC) (S. Wenger, 10 min) https://datatracker.ietf.org/doc/html/draft-ietf-avtcore-rtp-evc Stefan Wenger: want to remind people that this draft is still around. We had suspended work on it while completing work on VVC, so that we could base the EVC document text on the published VVC RTP Payload specification (RFC 9328). From there we removed text referring to features (such as spatial scalability) that VVC supports but EVC does not. Since EVC is a subset of VVC, once the feature set was scaled back we were able to produce a draft ready for WGLC. -03 was technically ready for WG Last Call, an -04 is coming with some editorial improvements but no changes affecting bits on the wire. Authors request WGLC on -04. Chairs agree that this is appropriate. Bernard volunteers to be document shepherd, and will start WGLC once -04 is submitted. 4. RTP Payload Format for Visual Volumetric Video-based Coding (V3C) (L. Ilola, 10 min) (13:39) https://datatracker.ietf.org/doc/html/draft-ietf-avtcore-rtp-v3c Version -01 missed the deadline, will be out shortly. No technical or normative changes. Authors are calling for technical reviews of the document. 3GPP work wants to refer to this document; their practice is to not refer to IETF documents that haven't reached Last Call. Next action: Chairs will review doc, more reviewers encouraged. 5. RTP over QUIC (M. Engelbarat, J. Ott, S. Dawkins, 30 min) (13:46) https://datatracker.ietf.org/doc/html/draft-ietf-avtcore-rtp-over-quic We will discuss the major open issues. Expect an -03 version of the document to issue after the meeting. With respect to congestion control, the current direction is to phrase things as guidance rather than requirements. RMCAT produced experimental specifications, so there are no low latency congestion control algorithms at BCP or Proposed Standard yet. In some cases, rate control or even congestion control behavior could be application-specific. So we focus on guidance about what to look for in CC. Discussing stream-per-frame and stream-per-layer behavior with respect to STOP\_SENDING sent by a receiver. This requires the receiver to know the stream layout. If SVC layers are sent on their own streams, the receiver can use STOP\_SENDING to unsubscribe from a layer as well as all layers that depend on the unsubscribed layers (since those layers will no longer be decodable). Some question about how a sender should interpret STOP\_SENDING. Is it meant to apply only to a particular frame? Bernard: STOP\_SENDING applies only to a stream, it is not an application layer construct. Jonathan: What happens if the receive sends a STOP\_SENDING and the sender has already begun to send the next frame? Bernard: The sender can't stop sending on a stream that has already been closed. But if the stream is still open and the sender is sending another frame on that stream, it can stop sending that. Peter Thatcher: After the sender receives the STOP\_SENDING, should it open another stream and keep sending? Bernard: In the absence of an indication from the receiver that it has lost interest in a source (e.g. a PAUSE), the sender has no reason to stop sending. If the goal is to cause the sender to drop a layer, the question is whether this should be handled at the QUIC layer (via STOP\_SENDING) or via an RTCP message (e.g. TSRR) There is a PR in progress that contains tables of RFC 7667 topologies and RTCP packet/feedback types, and evaluates how the same things can be done with QUIC. More feedback invited, no specific action at this time. 6. RTP Control Protocol (RTCP) Messages for Decoder Energy Reduction (S. Gudumasu, 10 min) (14:32) https://datatracker.ietf.org/doc/html/draft-gudumasu-avtcore-decoder-energy-reduction Presentation of message format. Not clear if asked-for rates are achievable. Seeking support for adoption of the draft, which extends the Green Metadata document. 7. RTP Payload Format for SFrame (P. Thatcher, 20 min) (14:46) https://datatracker.ietf.org/doc/html/draft-ietf-sframe-enc Reference: draft-ietf-sframe-enc-01 At a previous meeting, we discussed the problem of fragmentation of an RTP over QUIC packet when translating to RTP. This requires codec-specific knowledge in the translator. For SFrame, Peter, Youenn and Jonathan Lennox are propsing the following for the RTP Payload Format: a. Use SDP similar to SCIP (e.g. audio/sframe 48000, video/sframe 90000). Open question how the underlying codec is negotiated since SFrame (unlike SCIP) does not have its own codec negotiation messages. b. Instruct the underlying codec packetizer to use an "infinite MTU" (similar to RTP over a QUIC stream). c. Apply SFrame to the RTP payload. d. Carry fragments of the "big RTP payload" within the sframe media type. e. RTP packets containing the fragments carry fields from the "big RTP" frame. Do all the RTP header extensions need to be repeated in each packet? What do people think? Harald Alvestrand: This seems workable. Magnus Westerlund: I think you should go ahead and write it up. Next action: Write the draft, and discuss on the list. 8. Wrapup and Next Steps (Chairs, 10 min) (15:01)