[AVTCORE] [Errata Verified] RFC9134 (6752)
RFC Errata System <rfc-editor@rfc-editor.org> Wed, 08 November 2023 08:42 UTC
Return-Path: <wwwrun@rfcpa.amsl.com>
X-Original-To: avt@ietfa.amsl.com
Delivered-To: avt@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9F435C1CAFE7; Wed, 8 Nov 2023 00:42:46 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.468
X-Spam-Level:
X-Spam-Status: No, score=-4.468 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HEADER_FROM_DIFFERENT_DOMAINS=0.249, RCVD_IN_DNSWL_HI=-5, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, RDNS_NONE=0.793, SPF_HELO_SOFTFAIL=0.732, SPF_SOFTFAIL=0.665, T_SCC_BODY_TEXT_LINE=-0.01, URIBL_DBL_BLOCKED_OPENDNS=0.001, URIBL_ZEN_BLOCKED_OPENDNS=0.001] autolearn=unavailable autolearn_force=no
Received: from mail.ietf.org ([50.223.129.194]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id S3Bu63LSo09U; Wed, 8 Nov 2023 00:42:42 -0800 (PST)
Received: from rfcpa.amsl.com (unknown [50.223.129.200]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D197DC17C539; Wed, 8 Nov 2023 00:42:12 -0800 (PST)
Received: by rfcpa.amsl.com (Postfix, from userid 499) id BD1E2AE80; Wed, 8 Nov 2023 00:42:12 -0800 (PST)
To: t.bruylants@intopix.com, t.bruylants@intopix.com, antonin.descampe@uclouvain.be, c.damman@intopix.com, thomas.richter@iis.fraunhofer.de
From: RFC Errata System <rfc-editor@rfc-editor.org>
Cc: superuser@gmail.com, iesg@ietf.org, avt@ietf.org, iana@iana.org, rfc-editor@rfc-editor.org
Content-Type: text/plain; charset="UTF-8"
Message-Id: <20231108084212.BD1E2AE80@rfcpa.amsl.com>
Date: Wed, 08 Nov 2023 00:42:12 -0800
Archived-At: <https://mailarchive.ietf.org/arch/msg/avt/JbKKejhtzChasYo5ZwsVZP2qYHY>
X-Mailman-Approved-At: Thu, 09 Nov 2023 14:06:58 -0800
Subject: [AVTCORE] [Errata Verified] RFC9134 (6752)
X-BeenThere: avt@ietf.org
X-Mailman-Version: 2.1.39
Precedence: list
List-Id: Audio/Video Transport Core Maintenance <avt.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/avt>, <mailto:avt-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/avt/>
List-Post: <mailto:avt@ietf.org>
List-Help: <mailto:avt-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/avt>, <mailto:avt-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 08 Nov 2023 08:42:46 -0000
The following errata report has been verified for RFC9134, "RTP Payload Format for ISO/IEC 21122 (JPEG XS)". -------------------------------------- You may review the report below and at: https://www.rfc-editor.org/errata/eid6752 -------------------------------------- Status: Verified Type: Technical Reported by: Tim Bruylants <t.bruylants@intopix.com> Date Reported: 2021-11-24 Verified by: Murray Kucherawy (IESG) Section: 4.2 Original Text ------------- As specified in [RFC3550] and [RFC4175], the RTP timestamp designates the sampling instant of the first octet of the video frame to which the RTP packet belongs. Packets SHALL NOT include data from multiple video frames, and all packets belonging to the same video frame SHALL have the same timestamp. Several successive RTP packets will consequently have equal timestamps if they belong to the same video frame (that is until the marker bit is set to 1, marking the last packet of the video frame), and the timestamp is only increased when a new video frame begins. Corrected Text -------------- As specified in [RFC3550] and [RFC4175], the RTP timestamp designates the sampling instant of the first octet of the video frame/field to which the RTP packet belongs. Packets SHALL NOT include data from multiple video frames/fields, and all packets belonging to the same video frame/field SHALL have the same timestamp. Several successive RTP packets will consequently have equal timestamps if they belong to the same video frame/field (that is until the marker bit is set to 1, marking the last packet of the video frame/field), and the timestamp is only increased when a new video frame/field begins. Notes ----- This RFC follows RFC4175 (and also SMPTE2110) for timestamping RTP packets. The intent has always been to have unique timestamps per progressive video frame and/or per interlaced video field (two fields of a frame MUST be allowed to have different timestamps). This is correctly reflected by the marker bit (M) that is used to indicate the last packet of a frame/field (which is correctly explained in this RFC). However, the accompanied text about the timestamp in section 4.2 does not properly formulate this for the interlaced mode case (it was an editorial oversight), which can cause confusion to implementers of this RFC. -------------------------------------- RFC9134 (draft-ietf-payload-rtp-jpegxs-18) -------------------------------------- Title : RTP Payload Format for ISO/IEC 21122 (JPEG XS) Publication Date : October 2021 Author(s) : T. Bruylants, A. Descampe, C. Damman, T. Richter Category : PROPOSED STANDARD Source : Audio/Video Transport Core Maintenance Area : Applications and Real-Time Stream : IETF Verifying Party : IESG
- [AVTCORE] [Errata Verified] RFC9134 (6752) RFC Errata System
- [AVTCORE] [IANA #1287105] [Errata Verified] RFC91… Amanda Baber via RT
- Re: [AVTCORE] [IANA #1287105] [Errata Verified] R… Tim Bruylants