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

From: Sébastien Lugan <[email-masked]>
Date: Mon, 11 Jun 2018 00:28:35 +0200

Dear IETF Payload WG,

We recently uploaded a new 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-00.txt

Abstract:
   This document specifies a Real-Time Transport Protocol (RTP) payload
   format to be used for transporting ISO/IEC 21122 (JPEG XS) encoded
   video.  ISO/IEC 21122 (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.

Might we kindly ask you to review this I-D and send your comments?

Many thanks in advance,

Best regards,
-- 
Sébastien Lugan

---

From: Antonin Descampe <[email-masked]>
Date: Thu, 14 Jun 2018 08:34:54 +0000

Dear IETF Payload WG,

Following the mail from Sebastien Lugan hereunder, we would also like with this email to launch the process of a formal adoption of this I-D by the Payload WG.

Please let us know if anything needs to be done at this stage on our side to move forward with this process.

Kind regards,

Antonin

Le 11 juin 2018 à 00:28, Sébastien Lugan <[email-masked]<mailto:[email-masked]>> a écrit :

Dear IETF Payload WG,

Authors:

Abstract:

Many thanks in advance,

Best regards,
--
Sébastien Lugan

--
Antonin Descampe - Ph.D.
Compression technologist

IntoPIX s.a.
+32 10 23 84 70 (Office)
[email-masked]<mailto:[email-masked]>

CONFIDENTIALITY NOTICE: Unless otherwise explicitly or implictly stated, this email message and any of its attachments are the property of intoPIX SA and are strictly confidential.
If you are an unintended recipient, please notify the sender immediately.

---

From: "Roni Even (A)" <[email-masked]>
Date: Tue, 19 Jun 2018 13:52:08 +0000

Hi,
I did an initial review, in general the document is in line with the WG charter so we can ask the WG to adopt the document.
Yet, after reviewing the document I suggest that you will provide another revision of the individual draft.

My comments are editorial in order to have the document follow the RTP payload structure

1. I suggest you look at RFC 8088 (RTP howto) and also at recent RTP payload for video codecs (RFC7741 and draft-ietf-payload-rtp-vc2hq)
2.  The media type definition should use the template defined in [RFC6838] and  following [RFC4855]. See one of the above RTP payloads
3. Any parameter that goes into the fmtp line should be in the media type definition as required or optional. 
4. The offer answer consideration should have an example (I am not sure what is the "encode" parameter).
5. I suggest that the header fields in table 1 should be as a list and not as a table
6. In the RTP header according to RFRC3550 "The initial value of the timestamp SHOULD be random" , the wallclock should be in the RTCP SR and RR reports. (BTW: you can look at RFC7273 about clock sources)
7.The RTP header in figure 2 is missing the CSRC field and the place holder for RTP header extensions
8. Section 1 should include at least the content of the abstract
9. In section 2 there is no need to have a subsection for each term.
10. In section 2.10 [see there], where is there?
11. you do not need section 4.1 and the start of 4.2  I suggest "This section describes how the jepeg xs video stream is encapsulated
   in RTP.  To handle network losses, usage of RTP/AVPF [RFC4585] is   RECOMMENDED.  "
12.  A general comment , the document defines slice, slice group, fragment and frame multiple times, please define just once (section 2 or 3) and use the terms later.

If you have any questions I am here to help

Thanks
Roni Even 
Payload WG co-chair

-----Original Message-----
From: payload [mailto:[email-masked]] On Behalf Of Sébastien Lugan
Sent: Monday, June 11, 2018 1:29 AM
To: [email-masked]
Cc: Alexandre Willème; Gaël Rouvroy
Subject: [payload] Review request for JPEG XS RTP payload format I-D

Dear IETF Payload WG,

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

Authors:

Abstract:

Many thanks in advance,

Best regards,
--
Sébastien Lugan

_______________________________________________
payload mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/payload

---

From: Antonin Descampe <[email-masked]>
Date: Tue, 19 Jun 2018 15:06:55 +0000

Hi,

Many thanks for the review. We will update the document accordingly and upload a new version.

Let us know if anything else needs to be done for the WG to formally adopt it.

Kind regards,

Antonin

> Le 19 juin 2018 à 15:52, Roni Even (A) <[email-masked]> a écrit :
> 
> Hi,

---

From: John Fletcher <[email-masked]>
Date: Tue, 19 Jun 2018 15:26:04 +0000

A comment from me about this section:

    timestamp = floor((now - epoch)*90000) % 2^32

   where now and epoch are real numbers expressed in seconds, now being
   the current timestamp and epoch the reference timestamp

The term "timestamp" seems to be used for two different things, one the RTP timestamp in units of 1/90000 of a second, and the other in seconds on an unspecified timescale.

How about saying:

    timestamp = floor(time-since-epoch * 90000) % 2^32

    where time-since-epoch is the time elapsed since the SMPTE Epoch, expressed in seconds as a real number

Regards,
John Fletcher

-----Original Message-----
From: payload [mailto:[email-masked]] On Behalf Of Antonin Descampe
Sent: 19 June 2018 16:07
To: Roni Even (A) <[email-masked]>
Cc: Alexandre Willème <[email-masked]>; Gael Rouvroy <[email-masked]>; [email-masked]
Subject: Re: [payload] Review request for JPEG XS RTP payload format I-D

Hi,

Kind regards,

Antonin

> 1. I suggest you look at RFC 8088 (RTP howto) and also at recent RTP 
> payload for video codecs (RFC7741 and draft-ietf-payload-rtp-vc2hq) 2.  
> The media type definition should use the template defined in [RFC6838] and  following [RFC4855]. See one of the above RTP payloads 3. Any parameter that goes into the fmtp line should be in the media type definition as required or optional.
> 5. I suggest that the header fields in table 1 should be as a list and 
> not as a table 6. In the RTP header according to RFRC3550 "The initial 
> value of the timestamp SHOULD be random" , the wallclock should be in 
> the RTCP SR and RR reports. (BTW: you can look at RFC7273 about clock 
> sources) 7.The RTP header in figure 2 is missing the CSRC field and the place holder for RTP header extensions 8. Section 1 should include at least the content of the abstract 9. In section 2 there is no need to have a subsection for each term.
>  S. Lugan, G. Rouvroy, A. Descampe (intoPIX)  T. Richter (Fraunhofer 
> IIS)  A. Willeme (Université catholique de Louvain)
>