Re: [payload] Review request for JPEG XS RTP payload format I-D

Some comments:

In section 2, the definitions of SOC and EOC seem the wrong way round to me.  I would have expected SOC to correspond to the start and that seems to be what is shown in Figure 3.

In section 4, "Each of those RTP streams is divided into Application Data Units", is it not the JPEG XS stream that is divided into ADUs?

In section 4, "Each ADU is split into packets" is confusing because these are not the RTP packets but the payloads of RTP packets?

In general, I don't find it very clear how the JPEG XS stream is split into payloads for RTP packets.

In section 4.1, the timestamp definition seems to imply that the timestamp is derived from a globally synchronised clock rather than the media clock.  It's not clear what to do if the media clock is not synchronous with a global reference clock.  RFC 3550 states: If RTP packets are generated periodically, the nominal sampling instant as determined from the sampling clock is to be used, not a reading of the system clock.  I think it would be better to omit the text about time since epoch and say instead that if the media clock is derived directly from a globally synchronised reference with origin at the SMPTE Epoch, the offset should be zero (as in RFC 7273 a=mediaclk:direct=0).

Section 6.2, Mapping to SDP, does not say where to put the required and optional parameters, i.e. in the a=fmtp line.  You should probably say that the mapping to SDP shall be in accordance with RFC 4855.

In 6.2.3, it is suggested to use the SMPTE ST 2110-21 TP parameter, i.e. with values such as 2110TPNL.  That is a reasonable thing to do but the draft SMPTE ST 2110-22 uses values such as 2110-22TPNL, the reason being that ST 2110-21 is for uncompressed video and ST 2110-22 is for compressed video and it was thought useful to make a distinction because in -22 (and in this ID) only the Network Compatibility model applies.  Maybe it would have been better for ST 2110-22 just to use 2110TPNL but I think we should aim for consistency between draft ST 2110-22 and this ID.

Regards,
John Fletcher

-----Original Message-----
From: payload <payload-bounces@ietf.org> On Behalf Of Sébastien Lugan
Sent: 14 November 2018 17:57
To: payload@ietf.org
Cc: Alexandre Willème <alexandre.willeme@uclouvain.be>; Gaël Rouvroy <g.rouvroy@intopix.com>
Subject: Re: [payload] Review request for JPEG XS RTP payload format I-D

Dear IETF Payload WG,

We recently uploaded a new version of our RTP payload format I-D for transporting JPEG XS encoded video:

   RTP Payload Format for ISO/IEC 21122 (JPEG XS)
   https://datatracker.ietf.org/doc/draft-lugan-payload-rtp-jpegxs/

Authors:
   S. Lugan, G. Rouvroy, A. Descampe (intoPIX)
   T. Richter (Fraunhofer IIS)
   A. Willeme (Université catholique de Louvain)

Filename: draft-lugan-payload-rtp-jpegxs-01.txt

Abstract:
    This document specifies a Real-Time Transport Protocol (RTP) payload
    format to be used for transporting JPEG XS (ISO/IEC 21122) encoded
    video.  JPEG XS is a low-latency, lightweight image coding system
    allowing for an increased resolution and frame rate, while offering
    visually lossless quality with reduced amount of resources such as
    power and bandwidth.

This new version includes corrections suggested on this list and directly by e-mail.

Might we kindly ask you to review this I-D and send your comments regarding its possible formal adoption by the WG?

Many thanks in advance,

Best regards,

Sébastien Lugan

_______________________________________________
payload mailing list
payload@ietf.org
https://www.ietf.org/mailman/listinfo/payload

-----------------------------
http://www.bbc.co.uk
This e-mail (and any attachments) is confidential and
may contain personal views which are not the views of the BBC unless specifically stated.
If you have received it in
error, please delete it from your system.
Do not use, copy or disclose the
information in any way nor act in reliance on it and notify the sender
immediately.
Please note that the BBC monitors e-mails
sent or received.
Further communication will signify your consent to
this.
-----------------------------