Re: [AVTCORE] [IANA #1287105] [Errata Verified] RFC9134 (6752)

[Tim Bruylants <[e-mail]>]

Hi,

I was one of the authors of the RFC and I submitted the errata.

I don’t think that an additional reference for video/jxsv is needed for this erratum (it concerns a more internal detail of the RFC and has no impact on the media type).

Best regards,
Tim Bruylants.

From: avt <[e-mail]> on behalf of Amanda Baber via RT <[e-mail]>
Date: Saturday, 25 November 2023 at 04:27
To: [e-mail] <[e-mail]>
Cc: Tim Bruylants <[e-mail]>, [e-mail] <[e-mail]>, Corentin Damman <[e-mail]>
Subject: [AVTCORE] [IANA #1287105] [Errata Verified] RFC9134 (6752)
[You don't often get email from [e-mail]. Learn why this is important at https://aka.ms/LearnAboutSenderIdentification ]

Hi,

Should this errata report be listed as an additional reference for video/jxsv? See

https://urldefense.proofpoint.com/v2/url?u=https-3A__www.iana.org_assignments_media-2Dtypes&d=DwICAg&c=euGZstcaTDllvimEN8b7jXrwqOf-v5A_CdpgnVfiiMM&r=LTxUGukLCEfEUdo_bq048Q&m=mPIeaYf363P5NbhcK6HZfoeslUMQxB21XNIQUX0y0HIZfZ8fRlKiZrsx0WW2Tfdk&s=0z2dF9QrMJyJETNxcn4XaztiLpcpE4hkPBS9ahrnPck&e=
https://urldefense.proofpoint.com/v2/url?u=https-3A__www.iana.org_assignments_rtp-2Dparameters&d=DwICAg&c=euGZstcaTDllvimEN8b7jXrwqOf-v5A_CdpgnVfiiMM&r=LTxUGukLCEfEUdo_bq048Q&m=mPIeaYf363P5NbhcK6HZfoeslUMQxB21XNIQUX0y0HIZfZ8fRlKiZrsx0WW2Tfdk&s=oTWgEQMYnnyFHYnSvL_I2AsAYXoC-pJ8dBx-o0GFTbo&e=

thanks,

Amanda Baber
IANA Operations Manager

On Wed Nov 08 08:42:33 2023, [e-mail] wrote:
> 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://urldefense.proofpoint.com/v2/url?u=https-3A__www.rfc-2Deditor.org_errata_eid6752&d=DwICAg&c=euGZstcaTDllvimEN8b7jXrwqOf-v5A_CdpgnVfiiMM&r=LTxUGukLCEfEUdo_bq048Q&m=mPIeaYf363P5NbhcK6HZfoeslUMQxB21XNIQUX0y0HIZfZ8fRlKiZrsx0WW2Tfdk&s=SNDVfOxKA4U-_6lX0sxdhVSGB9jA2rPndVMTg_UcDtI&e=
>
> --------------------------------------
> Status: Verified
> Type: Technical
>
> Reported by: Tim Bruylants <https://urldefense.proofpoint.com/v2/url?u=http-3A__t.bruylants-40intopix.com&d=DwICAg&c=euGZstcaTDllvimEN8b7jXrwqOf-v5A_CdpgnVfiiMM&r=LTxUGukLCEfEUdo_bq048Q&m=mPIeaYf363P5NbhcK6HZfoeslUMQxB21XNIQUX0y0HIZfZ8fRlKiZrsx0WW2Tfdk&s=5bHiQTHGssKXM-su-i8OHrQCuaeP3H1CdYFhsqgPPFw&e=>
> 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

_______________________________________________
Audio/Video Transport Core Maintenance
[e-mail]
https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mailman_listinfo_avt&d=DwICAg&c=euGZstcaTDllvimEN8b7jXrwqOf-v5A_CdpgnVfiiMM&r=LTxUGukLCEfEUdo_bq048Q&m=mPIeaYf363P5NbhcK6HZfoeslUMQxB21XNIQUX0y0HIZfZ8fRlKiZrsx0WW2Tfdk&s=fMmqlJJGB9GqS6gqKGft21AteWzCe_sPDXhkyVme-bE&e=