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

"Fößel, Siegfried" <siegfried.foessel@iis.fraunhofer.de> Tue, 20 April 2021 07:53 UTC

Return-Path: <prvs=0737cb0f6d=siegfried.foessel@iis.fraunhofer.de>
X-Original-To: avt@ietfa.amsl.com
Delivered-To: avt@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EEDAA3A1616 for <avt@ietfa.amsl.com>; Tue, 20 Apr 2021 00:53:31 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.619
X-Spam-Level:
X-Spam-Status: No, score=-2.619 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sqYWL2wu_enh for <avt@ietfa.amsl.com>; Tue, 20 Apr 2021 00:53:27 -0700 (PDT)
Received: from mx-relay93-hz1.antispameurope.com (mx-relay93-hz1.antispameurope.com [94.100.132.93]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A55B73A1611 for <avt@ietf.org>; Tue, 20 Apr 2021 00:53:25 -0700 (PDT)
Received: from mailgw1.iis.fraunhofer.de ([153.96.172.4]) by mx-relay93-hz1.antispameurope.com; Tue, 20 Apr 2021 09:53:21 +0200
Received: from mail.iis.fraunhofer.de (mail01.iis.fhg.de [153.96.171.211]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by mailgw1.iis.fraunhofer.de (Postfix) with ESMTPS id 996732400087 for <avt@ietf.org>; Tue, 20 Apr 2021 09:53:16 +0200 (CEST)
Received: from mail03.iis.fhg.de (2001:638:a0a:1111:314f:f22c:4a37:b25a) by mail01.iis.fhg.de (2001:638:a0a:1111:fd91:8c2a:e4a5:e74e) with Microsoft SMTP Server (TLS) id 15.0.1497.2; Tue, 20 Apr 2021 09:53:16 +0200
Received: from mail03.iis.fhg.de ([fe80::314f:f22c:4a37:b25a]) by mail03.iis.fhg.de ([fe80::314f:f22c:4a37:b25a%12]) with mapi id 15.00.1497.012; Tue, 20 Apr 2021 09:53:16 +0200
From: =?iso-8859-1?Q?F=F6=DFel=2C_Siegfried?= <siegfried.foessel@iis.fraunhofer.de>
To: "avt@ietf.org" <avt@ietf.org>
Thread-Topic: avt Digest, Vol 203, Issue 13
Thread-Index: AQHXNbRYwXTGsVqrxk2HrSvk2+FbIKq9B8Tw
Date: Tue, 20 Apr 2021 07:53:15 +0000
Message-ID: <e5e91ab20d554811ad4921b1af5f11e5@mail03.iis.fhg.de>
References: <mailman.262.1618902644.7119.avt@ietf.org>
In-Reply-To: <mailman.262.1618902644.7119.avt@ietf.org>
Accept-Language: de-DE, en-US
Content-Language: de-DE
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-ms-exchange-transport-fromentityheader: Hosted
x-originating-ip: [153.96.171.210]
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-cloud-security-sender: siegfried.foessel@iis.fraunhofer.de
X-cloud-security-recipient: avt@ietf.org
X-cloud-security-crypt: load encryption module
X-cloud-security-Virusscan: CLEAN
X-cloud-security-disclaimer: This E-Mail was scanned by E-Mailservice on mx-relay93-hz1.antispameurope.com with B12D115457A4
X-cloud-security-connect: mailgw1.iis.fraunhofer.de[153.96.172.4], TLS=1, IP=153.96.172.4
X-cloud-security-Digest: 6e2ed5f316ea9ff3fd1741637caceee3
X-cloud-security: scantime:1.778
Archived-At: <https://mailarchive.ietf.org/arch/msg/avt/9Ly8QVfM096-f2iZdoJY6hktK4k>
Subject: Re: [AVTCORE] avt Digest, Vol 203, Issue 13
X-BeenThere: avt@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Audio/Video Transport Core Maintenance <avt.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/avt>, <mailto:avt-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/avt/>
List-Post: <mailto:avt@ietf.org>
List-Help: <mailto:avt-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/avt>, <mailto:avt-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 20 Apr 2021 07:53:32 -0000

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
>************************************