Subject: [AVTCORE] Minor editorial issue in RFC9134 regarding timestamp with interlaced content

From: Tim Bruylants <[email-masked]>
Date: Thu, 18 Nov 2021 11:46:02 +0000

Dear AVTcore experts,

I received some feedback from industry implementers that pointed me to a minor inconsistency in RFC9134 (RTP Payload for JPEG XS) which was just recently published. With this message I want to foremost inform the group and ask if issuing an editorial errata to rfc-editor.org would be advisable. The issue is in my opinion editorial in nature, but might cause confusion for implementors, hence a clarification would be welcome.

To the point: The issue is that the text that describes the 32-bit timestamp in the RTP Header (section 4.2) does not take interlaced content into account correctly.

The RFC currently says (under the "Timestamp" item):
"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."

As you can all read, it talks about "video frame". However, the intent of this RFC was always to follow RFC4175 and SMPTE2110-10 w.r.t. timestamps. This means that the packets and timestamps are to be linked to "video frames" for progressive content, and "video fields" for interlaced content. That's why it explicitly mentions "(that is until the marker bit is set to 1, marking the last packet of the video frame),".

The correct text should be:
"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."

Doing so would change the text to use similar wording like in the Marker (M) text.

If anyone has feedback on this, please let me know. Do you agree that I file an errata to clarify this?

Kind regards,
Tim Bruylants -- intoPIX