Re: [AVTCORE] [Editorial Errata Reported] RFC9134 (6752)

[Chris Smiley <[e-mail]>]

Greetings,

We are unable to verify this erratum that the submitter marked as editorial.  
Please note that we have changed the “Type” of the following errata 
report to “Technical”.  As Stream Approver, please review and set the 
Status and Type accordingly (see the definitions at 
https://www.rfc-editor.org/errata-definitions/).

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

Please see https://www.rfc-editor.org/how-to-verify/ for further 
information on how to verify errata reports.

Further information on errata can be found at: 
https://www.rfc-editor.org/errata.php.

Thank you.

RFC Editor/cs



> On Nov 24, 2021, at 4:10 AM, RFC Errata System <[e-mail]> wrote:
> 
> The following errata report has been submitted 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
> 
> --------------------------------------
> Type: Editorial
> Reported by: Tim Bruylants <[e-mail]>
> 
> 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.
> 
> Instructions:
> -------------
> This erratum is currently posted as "Reported". If necessary, please
> use "Reply All" to discuss whether it should be verified or
> rejected. When a decision is reached, the verifying party  
> can log in to change the status and edit the report, if necessary. 
> 
> --------------------------------------
> 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
>