Re: [AVTCORE] SDP directorate review of draft-ietf-payload-rtp-jpegxs-13

Thomas Richter <thomas.richter@iis.fraunhofer.de> Tue, 25 May 2021 07:37 UTC

Return-Path: <prvs=077296fc06=thomas.richter@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 E55483A1942 for <avt@ietfa.amsl.com>; Tue, 25 May 2021 00:37:14 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.901
X-Spam-Level:
X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, NICE_REPLY_A=-0.001, RCVD_IN_DNSWL_BLOCKED=0.001, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_NONE=0.001, SPF_PASS=-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 Z0GQk4KcuBwA for <avt@ietfa.amsl.com>; Tue, 25 May 2021 00:37:09 -0700 (PDT)
Received: from mx-relay57-hz1.antispameurope.com (mx-relay57-hz1.antispameurope.com [94.100.132.229]) (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 5801E3A1946 for <avt@ietf.org>; Tue, 25 May 2021 00:37:00 -0700 (PDT)
Received: from mailgw1.iis.fraunhofer.de ([153.96.172.4]) by mx-relay57-hz1.antispameurope.com; Tue, 25 May 2021 09:36:53 +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 09A302400081 for <avt@ietf.org>; Tue, 25 May 2021 09:36:50 +0200 (CEST)
Received: from [10.54.246.103] (153.96.171.210) by mail01.iis.fhg.de (2001:638:a0a:1111:fd91:8c2a:e4a5:e74e) with Microsoft SMTP Server (TLS) id 15.0.1497.2; Tue, 25 May 2021 09:36:49 +0200
To: <avt@ietf.org>
References: <AM0PR07MB38605C82DE3B4A8F677C8557932D9@AM0PR07MB3860.eurprd07.prod.outlook.com> <PR3P192MB0748357C78FECBB3CA63BE93AC269@PR3P192MB0748.EURP192.PROD.OUTLOOK.COM> <AM0PR07MB38607E9DDEB4FC8B86FC3FBB93269@AM0PR07MB3860.eurprd07.prod.outlook.com>
From: Thomas Richter <thomas.richter@iis.fraunhofer.de>
Message-ID: <7aa5e890-47c5-cdb7-5657-26864cec3d4c@iis.fraunhofer.de>
Date: Tue, 25 May 2021 09:36:49 +0200
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:78.0) Gecko/20100101 Thunderbird/78.10.2
MIME-Version: 1.0
In-Reply-To: <AM0PR07MB38607E9DDEB4FC8B86FC3FBB93269@AM0PR07MB3860.eurprd07.prod.outlook.com>
Content-Type: text/plain; charset="windows-1252"; format=flowed
Content-Transfer-Encoding: 8bit
X-Originating-IP: [153.96.171.210]
X-ClientProxiedBy: mail03.iis.fhg.de (2001:638:a0a:1111:314f:f22c:4a37:b25a) To mail01.iis.fhg.de (2001:638:a0a:1111:fd91:8c2a:e4a5:e74e)
X-cloud-security-sender: thomas.richter@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-relay57-hz1.antispameurope.com with 1ECE11EC7A5
X-cloud-security-connect: mailgw1.iis.fraunhofer.de[153.96.172.4], TLS=1, IP=153.96.172.4
X-cloud-security-Digest: 7f116abaca5eb8551ce546fb2e0df88b
X-cloud-security: scantime:1.733
Archived-At: <https://mailarchive.ietf.org/arch/msg/avt/5fr9JctPJ3gIa1MBrEIpy4QkhwY>
Subject: Re: [AVTCORE] SDP directorate review of draft-ietf-payload-rtp-jpegxs-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, 25 May 2021 07:37:23 -0000

Hi Christer, hi Tim,

> Unfortunately I don’t think what you explain above is very clear in the 
> text.
> 
> Consider the following.
> 
> The offerer sends an offer. The offerer specifies the characteristics 
> that the offerer wants to receive. Similarly, the answer specifies the 
> characteristics that the answerer wants to receive – the answerer does 
> NOT specify what it is going to send. which I think the text is 
> currently describing.

Sorry to sound confused, but maybe you could explain a bit better. To my 
understanding, it is the offerer that describes what it offers to send, 
and not the other way around? Maybe I misunderstand something very 
fundamental? Sorry to ask these elementary questions, but this is 
important for the text.

> “The receiver SHALL ignore any unrecognized parameter or invalid 
> parameter value.”
> 
> First, In my opinion invalid parameters values shall trigger an error.
> 
> Second, what is an unrecognized parameter?

I wonder why we need to specify this, i.e. what a receive does about 
parameters it does not recognize? Essentially, this is a problem of 
"foreward compatibility". Wouldn't it be a matter of implementation 
whether the receiver accepts an offer (note well, the receiver), and 
attempts to decode a stream on a "best effort" basis, keeping in mind 
that the stream itself includes additional means to identify required 
capabilities necessary for a successful decode.

If that is not an option, we would/could need means to identify the type 
of parameters in a foreward compatible way. I.e., conventions by which 
we would identify in the future parameters a receiver can safely ignore 
and attempt to decode, and parameters a receiver cannot safely ignore.

However, I believe this is getting a bit out of hands...

> Also, the text does not say what restrictions (if any) there are when it 
> comes to modify the stream during a session. Is it allowed to modify 
> any/all characteristics?

My understanding is that you cannot modify characteristics during a 
session. If you need to modify, you need to setup a new session and 
cancel the current one. For JPEG XS stream decoders, one cannot expect 
that an instanciated decoder can decode from modified parameters in 
mid-stream level. That is, if you start decoding in full-HD, and then 
stream parameters become 8K, the decoder will have to abort.

Thanks for helping and clarifying,

Greetings,
	Thomas