Re: [AVTCORE] avt Digest, Vol 203, Issue 13

Hi Bernard,
a publicly known implementation is the pilot project of Fraunhofer with NHK
see 
https://www.broadbandtvnews.com/2020/09/15/fraunhofer-works-with-nhk-on-new-jpeg-xs-codec/
or also SMPTE presentation at Annual Tech Conference
https://2020.smpte.org/home/session/372934/jpeg-xs-codec-adapted-to-8k-and-st-2110

Best regards
Siegfried


>-----Ursprüngliche Nachricht-----
>Von: avt <avt-bounces@ietf.org> Im Auftrag von avt-request@ietf.org
>Gesendet: Dienstag, 20. April 2021 09:11
>An: avt@ietf.org
>Betreff: avt Digest, Vol 203, Issue 13
>
>Send avt mailing list submissions to
>	avt@ietf.org
>
>To subscribe or unsubscribe via the World Wide Web, visit
>	https://www.ietf.org/mailman/listinfo/avt
>or, via email, send a message with subject or body 'help' to
>	avt-request@ietf.org
>
>You can reach the person managing the list at
>	avt-owner@ietf.org
>
>When replying, please edit your Subject line so it is more specific
>than "Re: Contents of avt digest..."
>
>
>Today's Topics:
>
>   1. Implementation/Deployment experience with "RTP Payload Format
>      for ISO/IEC 21122 (JPEG XS)" (Bernard Aboba)
>   2. AD Review of draft-ietf-payload-vp9-12 (Murray S. Kucherawy)
>   3. Last Call: <draft-ietf-avtcore-multi-party-rtt-mix-14.txt>
>      (RTP-mixer formatting of multi-party Real-time text) to Proposed
>      Standard (The IESG)
>   4. Re: Implementation/Deployment experience with "RTP Payload
>      Format for ISO/IEC 21122 (JPEG XS)" (Thomas Richter)
>   5. Re: Implementation/Deployment experience with "RTP Payload
>      Format for ISO/IEC 21122 (JPEG XS)" (Tim Bruylants)
>
>
>----------------------------------------------------------------------
>
>Message: 1
>Date: Mon, 19 Apr 2021 13:22:24 -0700
>From: Bernard Aboba <bernard.aboba@gmail.com>
>To: IETF AVTCore WG <avt@ietf.org>
>Subject: [AVTCORE] Implementation/Deployment experience with "RTP
>	Payload Format for ISO/IEC 21122 (JPEG XS)"
>Message-ID:
>	<CAOW+2ds951GzUS3_pcLyas4QV4sgim=zYxNDxNND8w3Mok-
>sUg@mail.gmail.com>
>Content-Type: text/plain; charset="utf-8"
>
>As part of the pre-publication request review, we need to provide
>information relating to implementation and/or deployment experience.
>
>Are there implementations and/or deployments of the JPEG XS RTP Payload
>format?
>-------------- next part --------------
>An HTML attachment was scrubbed...
>URL:
><https://mailarchive.ietf.org/arch/browse/avt/attachments/20210419/6a43a
>a19/attachment.htm>
>
>------------------------------
>
>Message: 2
>Date: Mon, 19 Apr 2021 15:32:36 -0700
>From: "Murray S. Kucherawy" <superuser@gmail.com>
>To: IETF AVTCore WG <avt@ietf.org>
>Subject: [AVTCORE] AD Review of draft-ietf-payload-vp9-12
>Message-ID:
>	<CAL0qLwZhFSG=zciLMt=USudw-
>YGPWXmNka84oeS=rWagbC5WFA@mail.gmail.com>
>Content-Type: text/plain; charset="utf-8"
>
>This is my review of draft-ietf-payload-vp9-12.
>
>Video codecs are not exactly my strong suit, so finding technical errors
>wasn't an expected part of my mission here.  I'm going on faith that this
>is all technically correct, and just looking for editorial or procedural
>things.
>
>-MSK
>
>--
>
>Shepherd writeup:
>
>* We should probably explain why a document coming out of AVTCORE bears
>a
>name that doesn't start with "draft-ietf-avtcore-...".  The shepherd
>writeup should mention this.  Or if you don't want to do that, please let
>me know what the history is there so I can include it in a note to the IESG.
>
>* The writeup identifies draft-ietf-avtext-lrr as a downward reference, but
>that document is in the queue already for Proposed Standard status, and
>this one is going for the same, so I don't believe this is a downward
>reference (once both are published).
>
>General nits:
>
>* Referring to an I-D as a "memo" is a little outdated.  Suggest "document"
>or "specification" instead.
>
>Section 1:
>
>* Should this document obsolete VP8 (RFC 6386)?
>
>Section 3:
>
>* The Editor's Note seems like it should've been resolved by now.  If no
>suggestion for improved terminology arrives by the end of IESG Evaluation,
>should that paragraph be removed?
>
>Section 4.1:
>
>* For "Timestamp", did you mean to say "alternately" (i.e., every other
>one; alternating) or "alternatively" (i.e., presenting a different choice)?
>
>Section 4.2:
>
>* First sentence, "The" shouldn't be capitalized.
>
>* The use of CONDITIONALLY RECOMMENDED or CONDITIONALLY REQUIRED
>is
>puzzling because one of them is a BCP 14 word and one isn't, but both look
>like they're supposed to be.  This might be better described in the prose
>for each of these fields, and just use the BCP 14 words here (or omit them
>entirely).
>
>* The description of PID refers to a "maximum ID", but that's not specified
>anywhere.  Is it simply the largest PID that will fit in the available
>bits, or is there some other maximum to be observed?
>
>* For the "D:" bullet, I think "MUST be set to one if current spatial layer
>SID frame depends on spatial layer SID-1 frame of the same picture. MUST
>only be set to zero if current spatial layer SID frame does not depend on
>spatial layer SID-1 frame of the same picture." can be reduced to "MUST be
>set to one if and only if the current spatial layer SID frame depends on
>spatial layer SID-1 frame of the same picture."
>
>Section 6.1:
>
>* Does the media type's subtype name have to be "VP9", in specifically that
>case?
>
>* Per RFC 6838, please change Required Parameters to "N/A" instead of
>"None".
>
>* I think it's unusual for the BCP 14 text to appear in a media type
>registration (specifically, the Optional Parameters).  You might consider
>moving that discussion to some other prose section, and in the media type
>registration just list the supported parameters and their syntaxes.
>-------------- next part --------------
>An HTML attachment was scrubbed...
>URL:
><https://mailarchive.ietf.org/arch/browse/avt/attachments/20210419/44397
>9bf/attachment.htm>
>
>------------------------------
>
>Message: 3
>Date: Mon, 19 Apr 2021 15:49:31 -0700
>From: The IESG <iesg-secretary@ietf.org>
>To: "IETF-Announce" <ietf-announce@ietf.org>
>Cc: avt@ietf.org, avtcore-chairs@ietf.org, bernard.aboba@gmail.com,
>	draft-ietf-avtcore-multi-party-rtt-mix@ietf.org, superuser@gmail.com
>Subject: [AVTCORE] Last Call:
>	<draft-ietf-avtcore-multi-party-rtt-mix-14.txt> (RTP-mixer formatting
>	of multi-party Real-time text) to Proposed Standard
>Message-ID: <161887257137.22201.10884394710889779710@ietfa.amsl.com>
>Content-Type: text/plain; charset="utf-8"
>
>
>The IESG has received a request from the Audio/Video Transport Core
>Maintenance WG (avtcore) to consider the following document: - 'RTP-mixer
>formatting of multi-party Real-time text'
>  <draft-ietf-avtcore-multi-party-rtt-mix-14.txt> as Proposed Standard
>
>The IESG plans to make a decision in the next few weeks, and solicits final
>comments on this action. Please send substantive comments to the
>last-call@ietf.org mailing lists by 2021-05-03. Exceptionally, comments may
>be sent to iesg@ietf.org instead. In either case, please retain the beginning
>of the Subject line to allow automated sorting.
>
>Abstract
>
>
>   Enhancements for RFC 4103 real-time text mixing are provided in this
>   document, suitable for a centralized conference model that enables
>   source identification and rapidly interleaved transmission of text
>   from different sources.  The intended use is for real-time text
>   mixers and participant endpoints capable of providing an efficient
>   presentation or other treatment of a multi-party real-time text
>   session.  The specified mechanism builds on the standard use of the
>   CSRC list in the RTP packet for source identification.  The method
>   makes use of the same "text/t140" and "text/red" formats as for two-
>   party sessions.
>
>   Solutions using multiple RTP streams in the same RTP session are
>   briefly mentioned, as they could have some benefits over the RTP-
>   mixer model.  The possibility to implement the solution in a wide
>   range of existing RTP implementations made the RTP-mixer model be
>   selected to be fully specified in this document.
>
>   A capability exchange is specified so that it can be verified that a
>   mixer and a participant can handle the multi-party coded real-time
>   text stream using the RTP-mixer method.  The capability is indicated
>   by use of an SDP media attribute "rtt-mixer".
>
>   The document updates RFC 4103 "RTP Payload for Text Conversation".
>
>   A specification of how a mixer can format text for the case when the
>   endpoint is not multi-party aware is also provided.
>
>
>
>
>The file can be obtained via
>https://datatracker.ietf.org/doc/draft-ietf-avtcore-multi-party-rtt-mix/
>
>
>
>No IPR declarations have been submitted directly on this I-D.
>
>
>
>
>
>
>
>------------------------------
>
>Message: 4
>Date: Tue, 20 Apr 2021 08:25:05 +0200
>From: Thomas Richter <thomas.richter@iis.fraunhofer.de>
>To: <avt@ietf.org>
>Subject: Re: [AVTCORE] Implementation/Deployment experience with "RTP
>	Payload Format for ISO/IEC 21122 (JPEG XS)"
>Message-ID: <1b9fc28a-1b3b-3af1-d3b9-689c9ca3a468@iis.fraunhofer.de>
>Content-Type: text/plain; charset="utf-8"; format=flowed
>
>
>
>Am 19.04.2021 um 22:22 schrieb Bernard Aboba:
>> As part of the pre-publication request review, we need to provide
>> information relating to implementation and/or deployment experience.
>>
>> Are there implementations and/or deployments of the JPEG XS RTP Payload
>> format?
>
>There certainly is an implementation from Fraunhofer IIS. Our XS
>implementation supports this transport format.
>
>Greetings,
>	Thomas
>
>
>
>------------------------------
>
>Message: 5
>Date: Tue, 20 Apr 2021 07:10:32 +0000
>From: Tim Bruylants <TBR@intopix.com>
>To: "avt@ietf.org" <avt@ietf.org>
>Subject: Re: [AVTCORE] Implementation/Deployment experience with "RTP
>	Payload Format for ISO/IEC 21122 (JPEG XS)"
>Message-ID:
>	<PR3P192MB07486FDB558435B6838A4F65AC489@PR3P192MB0748.E
>URP192.PROD.OUTLOOK.COM>
>
>Content-Type: text/plain; charset="us-ascii"
>
>Hi Bernard,
>
>There is also an implementation from intoPIX that implements the RTP
>Payload specification for XS. We also have customers that have deployed or
>are in the progress of deploying XS over RTP (based on this spec).
>
>Kind regards,
>Tim.
>
>-----Original Message-----
>From: avt <avt-bounces@ietf.org> On Behalf Of Thomas Richter
>Sent: Tuesday 20 April 2021 08:25
>To: avt@ietf.org
>Subject: Re: [AVTCORE] Implementation/Deployment experience with "RTP
>Payload Format for ISO/IEC 21122 (JPEG XS)"
>
>
>
>Am 19.04.2021 um 22:22 schrieb Bernard Aboba:
>> As part of the pre-publication request review, we need to provide
>> information relating to implementation and/or deployment experience.
>>
>> Are there implementations and/or deployments of the JPEG XS RTP
>> Payload format?
>
>There certainly is an implementation from Fraunhofer IIS. Our XS
>implementation supports this transport format.
>
>Greetings,
>	Thomas
>
>_______________________________________________
>Audio/Video Transport Core Maintenance
>avt@ietf.org
>https://urldefense.proofpoint.com/v2/url?u=https-
>3A__www.ietf.org_mailman_listinfo_avt&d=DwICAg&c=euGZstcaTDllvimEN8b
>7jXrwqOf-
>v5A_CdpgnVfiiMM&r=LTxUGukLCEfEUdo_bq048Q&m=RXGKlgMmO9r8I7QzE2
>c-
>YnYicL7iPbQ_MX9S6ppY7Jw&s=k1v8EjLJjSKVvDb5Tp6jQTqaTcRDwUjhFtLM_V4
>r0lc&e=
>
>
>
>------------------------------
>
>Subject: Digest Footer
>
>_______________________________________________
>Audio/Video Transport Core Maintenance
>avt@ietf.org
>https://www.ietf.org/mailman/listinfo/avt
>
>
>------------------------------
>
>End of avt Digest, Vol 203, Issue 13
>************************************