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

Thomas Richter <> Tue, 25 May 2021 07:37 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id E55483A1942 for <>; Tue, 25 May 2021 00:37:14 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.901
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 ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id Z0GQk4KcuBwA for <>; Tue, 25 May 2021 00:37:09 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 5801E3A1946 for <>; Tue, 25 May 2021 00:37:00 -0700 (PDT)
Received: from ([]) by; Tue, 25 May 2021 09:36:53 +0200
Received: from ( []) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 09A302400081 for <>; Tue, 25 May 2021 09:36:50 +0200 (CEST)
Received: from [] ( by (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: <>
References: <> <PR3P192MB0748357C78FECBB3CA63BE93AC269@PR3P192MB0748.EURP192.PROD.OUTLOOK.COM> <>
From: Thomas Richter <>
Message-ID: <>
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: <>
Content-Type: text/plain; charset="windows-1252"; format=flowed
Content-Transfer-Encoding: 8bit
X-Originating-IP: []
X-ClientProxiedBy: (2001:638:a0a:1111:314f:f22c:4a37:b25a) To (2001:638:a0a:1111:fd91:8c2a:e4a5:e74e)
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 with 1ECE11EC7A5
X-cloud-security-connect:[], TLS=1, IP=
X-cloud-security-Digest: 7f116abaca5eb8551ce546fb2e0df88b
X-cloud-security: scantime:1.733
Archived-At: <>
Subject: Re: [AVTCORE] SDP directorate review of draft-ietf-payload-rtp-jpegxs-13
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Audio/Video Transport Core Maintenance <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-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,