Re: [AVTCORE] New Version Notification for draft-ietf-payload-rtp-jpegxs-02.txt

["Edwards, Thomas" <[e-mail]>]

Antonin,

I strongly agree that software applicability of JPEG XS is a must, and worthy of delay on the RTP I-D for study if it is a major issue.

If needed, we could give feedback to SMPTE regarding CBR/constant bytes in ST 2110-22 if that is a significant issue on quality.  I think there has to be some hard upper limits on bandwidth for planning purposes, but I don’t understand why a flow that fluctuates a little bit, say from 250 to 300 Mbps would be a problem.

I’m less concerned about TS to RTP conversion, but perhaps I am not aware of enough TS use cases for JPEG XS.

Thanks for all your work on this!

-Thomas

--
Thomas Edwards
VP Engineering & Development
Walt Disney Television


From: avt <[e-mail]> on behalf of Antonin Descampe <[e-mail]>
Date: Monday, December 16, 2019 at 7:51 AM
To: "Roni Even (A)" <[e-mail]>
Cc: "[e-mail]" <[e-mail]>
Subject: Re: [AVTCORE] New Version Notification for draft-ietf-payload-rtp-jpegxs-02.txt
Resent-From: Thomas Edwards <[e-mail]>
Resent-Date: Monday, December 16, 2019 at 7:51 AM

Hi Roni,

Thanks for the reminder.

We still plan to update the draft soon. We have extensively discussed the issue at the last JPEG meeting in November and it raised several related concerns. So we are currently trying to find the best tradeoff between goals that are sometimes antagonistic. Experiments are currently running here internally to allow us to move forward on this. We are aware that we need to freeze the spec very soon.

For people interested in this topic on this list, here is a small summary of the status.

The identified requirements for RTP transport are
1. Number of bytes and number of packets per frame needs to be constant (ST2110-22). This prevents a scenario with 1! slice per packet and vbr slices, as already mentioned.
2. No transcoding when changing the encapsulation: for instance, in a transcoding use case from MPEG-2 TS to ST2110-22, we would like to avoid the transcoder having to run a deep inspection of the codestream to build the RTP header (to look for slice boundaries for example). This also prevents a scenario with 1! slice per packet and vbr slices. With cbr slices, it could work but see requirement (4). With additional slice size markers, it could also work but see requirement (3).
3. Preserve low-latency behaviour. This prevents inserting the slice size in front of each slice, which would have been able to alleviate the codestream parsing.
4. No quality loss. Cbr slices induce a small quality loss, especially for desktop content.
5. Low complex HW and fast SW decoding. In particular, fast SW decoding seems to require being able to parse a RTP packet without having necessarily received the previous ones, which implies certain information to be found in the RTP header. This goes against requirement (2). Experiments are currently on going to confirm this.

Any comment is welcome of course.

I’ll keep you posted once we find the best tradeoff here.

Kind regards,

Antonin




Le 12 déc. 2019 à 14:35, Roni Even (A) <[e-mail]<mailto:[e-mail]>> a écrit :

Hi Antonin,
Any plans to update the draft soon?
Is this the only open issue that need to be resolved?
Regards
Roni Even
AVTCore co-chair

From: avt [mailto:[e-mail]] On Behalf Of Antonin Descampe
Sent: Wednesday, October 09, 2019 6:01 PM
To: [e-mail]<mailto:[e-mail]>
Subject: [AVTCORE] New Version Notification for draft-ietf-payload-rtp-jpegxs-02.txt

Dear all,

As indicated hereunder, a new version of the JPEG XS RTP payload has been submitted today.

The main difference with previous version is the removal of the EOC marker that shall be discarded from the JPEG XS codestream before RTP transport. Rationale behind this is to avoid having a RTP packet entirely dedicated to the EOC marker (as metadata and entropy coding data are transported in different packets).

There is still a remaining issue to be addressed and for which a new version will be submitted shortly: namely the fact that the current proposal might imply a different number of RTP packets from one frame to the other, which goes against one of the ST2110-22 requirements. One of the solutions we are currently envisioning to tackle this issue would be to allow more than one slice per RTP packet. I’ll keep the reflector informed of the path eventually selected to solve this issue.

Any comment on this matter is welcome.

Kind regards,

Antonin Descampe



Début du message réexpédié :

De: <[e-mail]<mailto:[e-mail]>>
Objet: New Version Notification for draft-ietf-payload-rtp-jpegxs-02.txt
Date: 9 octobre 2019 à 16:57:10 UTC+2
À: <[e-mail]<mailto:[e-mail]>>, Sebastien Lugan <[e-mail]<mailto:[e-mail]>>, Gael Rouvroy <[e-mail]<mailto:[e-mail]>>, Alexandre Willeme <[e-mail]<mailto:[e-mail]>>, Gaël Rouvroy <[e-mail]<mailto:[e-mail]>>, Sébastien Lugan <[e-mail]<mailto:[e-mail]>>, Antonin Descampe <[e-mail]<mailto:[e-mail]>>, Thomas Richter <[e-mail]<mailto:[e-mail]>>


A new version of I-D, draft-ietf-payload-rtp-jpegxs-02.txt
has been successfully submitted by Antonin Descampe and posted to the
IETF repository.

Name: draft-ietf-payload-rtp-jpegxs
Revision: 02
Title: RTP Payload Format for ISO/IEC 21122 (JPEG XS)
Document date: 2019-10-09
Group: avtcore
Pages: 19
URL:            https://www.ietf.org/internet-drafts/draft-ietf-payload-rtp-jpegxs-02.txt<https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Furldefense.proofpoint.com%2Fv2%2Furl%3Fu%3Dhttps-3A__www.ietf.org_internet-2Ddrafts_draft-2Dietf-2Dpayload-2Drtp-2Djpegxs-2D02.txt%26d%3DDwMGaQ%26c%3Duw6TLu4hwhHdiGJOgwcWD4AjKQx6zvFcGEsbfiY9-EI%26r%3DlekNOOM5noV61zrPH3rwPyhtNnLLWoLEHgd0quQxly8%26m%3DpuOt8JK_Q_GPkM9h5LZoybpLj6gPVvpYxHiVJ4aMV_Y%26s%3DbCRHW0aatctZ2MRun1p5IR1FrMssOICrOzJD93UIrEo%26e%3D&data=02%7C01%7CThomas.Edwards%40disney.com%7C9b172971ff6245a662cb08d7823fe046%7C56b731a8a2ac4c32bf6b616810e913c6%7C1%7C0%7C637121083172471458&sdata=VGBF3J%2FJQISh5hXZHUOirUFr5vmmaTan2RzWlm5JPk0%3D&reserved=0>
Status:         https://datatracker.ietf.org/doc/draft-ietf-payload-rtp-jpegxs/<https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Furldefense.proofpoint.com%2Fv2%2Furl%3Fu%3Dhttps-3A__datatracker.ietf.org_doc_draft-2Dietf-2Dpayload-2Drtp-2Djpegxs_%26d%3DDwMGaQ%26c%3Duw6TLu4hwhHdiGJOgwcWD4AjKQx6zvFcGEsbfiY9-EI%26r%3DlekNOOM5noV61zrPH3rwPyhtNnLLWoLEHgd0quQxly8%26m%3DpuOt8JK_Q_GPkM9h5LZoybpLj6gPVvpYxHiVJ4aMV_Y%26s%3DQQJ3-GCRWldcidmJZ_GVHgRaiUcV38CV9dsqQa45MHc%26e%3D&data=02%7C01%7CThomas.Edwards%40disney.com%7C9b172971ff6245a662cb08d7823fe046%7C56b731a8a2ac4c32bf6b616810e913c6%7C1%7C0%7C637121083172481408&sdata=r74mTaw%2F9Cv9rsxTix%2BokMpDd5D9a%2B4IW1xjkpK47k0%3D&reserved=0>
Htmlized:       https://tools.ietf.org/html/draft-ietf-payload-rtp-jpegxs-02<https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Furldefense.proofpoint.com%2Fv2%2Furl%3Fu%3Dhttps-3A__tools.ietf.org_html_draft-2Dietf-2Dpayload-2Drtp-2Djpegxs-2D02%26d%3DDwMGaQ%26c%3Duw6TLu4hwhHdiGJOgwcWD4AjKQx6zvFcGEsbfiY9-EI%26r%3DlekNOOM5noV61zrPH3rwPyhtNnLLWoLEHgd0quQxly8%26m%3DpuOt8JK_Q_GPkM9h5LZoybpLj6gPVvpYxHiVJ4aMV_Y%26s%3D_EckyWwFI-kZYI2_x65IfNwO8LI0tf0ryhmxQ-IhEt0%26e%3D&data=02%7C01%7CThomas.Edwards%40disney.com%7C9b172971ff6245a662cb08d7823fe046%7C56b731a8a2ac4c32bf6b616810e913c6%7C1%7C0%7C637121083172481408&sdata=96PX6qXSK9MtH%2F1H4Fgj%2BnpWpJ8fomGPjJJ%2Fm6kEvSU%3D&reserved=0>
Htmlized:       https://datatracker.ietf.org/doc/html/draft-ietf-payload-rtp-jpegxs<https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Furldefense.proofpoint.com%2Fv2%2Furl%3Fu%3Dhttps-3A__datatracker.ietf.org_doc_html_draft-2Dietf-2Dpayload-2Drtp-2Djpegxs%26d%3DDwMGaQ%26c%3Duw6TLu4hwhHdiGJOgwcWD4AjKQx6zvFcGEsbfiY9-EI%26r%3DlekNOOM5noV61zrPH3rwPyhtNnLLWoLEHgd0quQxly8%26m%3DpuOt8JK_Q_GPkM9h5LZoybpLj6gPVvpYxHiVJ4aMV_Y%26s%3DoaAsaeoQJPxS_oHnqLxzaQZST7Vnc7qZf83xhLqMzB0%26e%3D&data=02%7C01%7CThomas.Edwards%40disney.com%7C9b172971ff6245a662cb08d7823fe046%7C56b731a8a2ac4c32bf6b616810e913c6%7C1%7C0%7C637121083172481408&sdata=N0Ee5lgoWn6F5ZXrNN3Yr9t08xIBYTXYaLn2y1t9Tqk%3D&reserved=0>
Diff:           https://www.ietf.org/rfcdiff?url2=draft-ietf-payload-rtp-jpegxs-02<https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Furldefense.proofpoint.com%2Fv2%2Furl%3Fu%3Dhttps-3A__www.ietf.org_rfcdiff-3Furl2-3Ddraft-2Dietf-2Dpayload-2Drtp-2Djpegxs-2D02%26d%3DDwMGaQ%26c%3Duw6TLu4hwhHdiGJOgwcWD4AjKQx6zvFcGEsbfiY9-EI%26r%3DlekNOOM5noV61zrPH3rwPyhtNnLLWoLEHgd0quQxly8%26m%3DpuOt8JK_Q_GPkM9h5LZoybpLj6gPVvpYxHiVJ4aMV_Y%26s%3DLZnxE21urFyB9_X4PGcwiLEoUmHAGtqNIAAcwg_JOLg%26e%3D&data=02%7C01%7CThomas.Edwards%40disney.com%7C9b172971ff6245a662cb08d7823fe046%7C56b731a8a2ac4c32bf6b616810e913c6%7C1%7C0%7C637121083172491359&sdata=i2DRzCvl2pnxlOe2tUhcU%2B4ULh2kzgCO%2FSLCk6nVRLk%3D&reserved=0>

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.
  Compared to an uncompressed video use case, it allows higher
  resolutions and frame rates, while offering visually lossless
  quality, reduced power consumption, and end-to-end latency confined
  to a fraction of a frame.




Please note that it may take a couple of minutes from the time of submission
until the htmlized version and diff are available at tools.ietf.org<https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Furldefense.proofpoint.com%2Fv2%2Furl%3Fu%3Dhttp-3A__tools.ietf.org_%26d%3DDwMGaQ%26c%3Duw6TLu4hwhHdiGJOgwcWD4AjKQx6zvFcGEsbfiY9-EI%26r%3DlekNOOM5noV61zrPH3rwPyhtNnLLWoLEHgd0quQxly8%26m%3DpuOt8JK_Q_GPkM9h5LZoybpLj6gPVvpYxHiVJ4aMV_Y%26s%3DX6jj9oO4L3aHIhBvE0wabluG5VOmVUlxsu85vTyTIe0%26e%3D&data=02%7C01%7CThomas.Edwards%40disney.com%7C9b172971ff6245a662cb08d7823fe046%7C56b731a8a2ac4c32bf6b616810e913c6%7C1%7C0%7C637121083172491359&sdata=XYNe%2FbbSby5GDehC4x%2FpjXpopVX4fvD7G79wnhW7ynU%3D&reserved=0>.

The IETF Secretariat

--
Antonin Descampe - Ph.D.
Compression technologist

IntoPIX s.a.
[phone] (Office)
[e-mail]<mailto:[e-mail]>

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.


--
Antonin Descampe - Ph.D.
Compression technologist

IntoPIX s.a.
[phone] (Office)
[e-mail]<mailto:[e-mail]>

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.