[AVTCORE] [Editorial Errata Reported] RFC9328 (8111)

RFC Errata System <rfc-editor@rfc-editor.org> Fri, 20 September 2024 14:35 UTC

Return-Path: <wwwrun@rfcpa.rfc-editor.org>
X-Original-To: avt@ietf.org
Delivered-To: avt@ietfa.amsl.com
Received: from rfcpa.rfc-editor.org (unknown [167.172.21.234]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature ECDSA (P-256) server-digest SHA256) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 91744C1519B8; Fri, 20 Sep 2024 07:35:50 -0700 (PDT)
Received: by rfcpa.rfc-editor.org (Postfix, from userid 461) id F10703B874; Fri, 20 Sep 2024 07:35:49 -0700 (PDT)
To: rfc-editor@rfc-editor.org
From: RFC Errata System <rfc-editor@rfc-editor.org>
Content-Type: text/plain; charset="UTF-8"
Message-Id: <20240920143549.F10703B874@rfcpa.rfc-editor.org>
Date: Fri, 20 Sep 2024 07:35:49 -0700
Message-ID-Hash: OY5FHLDLO2WTELF2L3PE76IO6AJU7DQZ
X-Message-ID-Hash: OY5FHLDLO2WTELF2L3PE76IO6AJU7DQZ
X-MailFrom: wwwrun@rfcpa.rfc-editor.org
X-Mailman-Rule-Misses: dmarc-mitigation; no-senders; approved; emergency; loop; banned-address; member-moderation; header-match-avt.ietf.org-0; nonmember-moderation; administrivia; implicit-dest; max-recipients; max-size; news-moderation; no-subject; digests; suspicious-header
CC: magnus.westerlund@ericsson.com, stewe@stewe.org, miska.hannuksela@nokia.com, avt@ietf.org
X-Mailman-Version: 3.3.9rc4
Precedence: list
Subject: [AVTCORE] [Editorial Errata Reported] RFC9328 (8111)
List-Id: Audio/Video Transport Core Maintenance <avt.ietf.org>
Archived-At: <https://mailarchive.ietf.org/arch/msg/avt/Vm1r3VKRY8uocKQUXQ3oI2TxxvU>
List-Archive: <https://mailarchive.ietf.org/arch/browse/avt>
List-Help: <mailto:avt-request@ietf.org?subject=help>
List-Owner: <mailto:avt-owner@ietf.org>
List-Post: <mailto:avt@ietf.org>
List-Subscribe: <mailto:avt-join@ietf.org>
List-Unsubscribe: <mailto:avt-leave@ietf.org>

The following errata report has been submitted for RFC9328,
"RTP Payload Format for Versatile Video Coding (VVC)".

--------------------------------------
You may review the report below and at:
https://www.rfc-editor.org/errata/eid8111

--------------------------------------
Type: Editorial
Reported by: Magnus Westerlund <magnus.westerlund@ericsson.com>

Section: 4.3.3

Original Text
-------------
The FU header consists of an S bit, an E bit, an R bit, and a 5-bit
   FuType field, as shown in Figure 10.

Corrected Text
--------------
The FU header consists of an S bit, an E bit, an P bit, and a 5-bit
   FuType field, as shown in Figure 10.

Notes
-----
The figure 10 and the explanation to Figure 10 calls it the P bit:


                             +---------------+
                             |0|1|2|3|4|5|6|7|
                             +-+-+-+-+-+-+-+-+
                             |S|E|P|  FuType |
                             +---------------+

                 Figure 10: The Structure of the FU Header

   The semantics of the FU header fields are as follows:

   S: 1 bit
      When set to 1, the S bit indicates the start of a fragmented NAL
      unit, i.e., the first byte of the FU payload is also the first
      byte of the payload of the fragmented NAL unit.  When the FU
      payload is not the start of the fragmented NAL unit payload, the S
      bit MUST be set to 0.

   E: 1 bit
      When set to 1, the E bit indicates the end of a fragmented NAL
      unit, i.e., the last byte of the payload is also the last byte of
      the fragmented NAL unit.  When the FU payload is not the last
      fragment of a fragmented NAL unit, the E bit MUST be set to 0.

   P: 1 bit
      When set to 1, the P bit indicates the last FU of the last VCL NAL
      unit of a coded picture, i.e., the last byte of the FU payload is
      also the last byte of the last VCL NAL unit of the coded picture.
      When the FU payload is not the last fragment of the last VCL NAL
      unit of a coded picture, the P bit MUST be set to 0.

Instructions:
-------------
This erratum is currently posted as "Reported". (If it is spam, it 
will be removed shortly by the RFC Production Center.) Please
use "Reply All" to discuss whether it should be verified or
rejected. When a decision is reached, the verifying party  
will log in to change the status and edit the report, if necessary.

--------------------------------------
RFC9328 (draft-ietf-avtcore-rtp-vvc-18)
--------------------------------------
Title               : RTP Payload Format for Versatile Video Coding (VVC)
Publication Date    : December 2022
Author(s)           : S. Zhao, S. Wenger, Y. Sanchez, Y.-K. Wang, M. M Hannuksela
Category            : PROPOSED STANDARD
Source              : Audio/Video Transport Core Maintenance
Stream              : IETF
Verifying Party     : IESG