From bernard.aboba@gmail.com  Tue Oct  3 07:33:51 2023
Return-Path: <bernard.aboba@gmail.com>
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 DEB3FC180EA7
 for <avt@ietfa.amsl.com>; Tue,  3 Oct 2023 07:33:51 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.106
X-Spam-Level: 
X-Spam-Status: No, score=-2.106 tagged_above=-999 required=5
 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1,
 DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001,
 HTML_MESSAGE=0.001, RCVD_IN_DNSWL_BLOCKED=0.001,
 RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_HELO_NONE=0.001,
 SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01]
 autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key)
 header.d=gmail.com
Received: from mail.ietf.org ([50.223.129.194])
 by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024)
 with ESMTP id tZAW9lyv3yhT for <avt@ietfa.amsl.com>;
 Tue,  3 Oct 2023 07:33:50 -0700 (PDT)
Received: from mail-pj1-x1032.google.com (mail-pj1-x1032.google.com
 [IPv6:2607:f8b0:4864:20::1032])
 (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits)
 key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256)
 (No client certificate requested)
 by ietfa.amsl.com (Postfix) with ESMTPS id EEBEBC13AE2E
 for <avt@ietf.org>; Tue,  3 Oct 2023 07:33:50 -0700 (PDT)
Received: by mail-pj1-x1032.google.com with SMTP id
 98e67ed59e1d1-277504a23a1so749545a91.0
 for <avt@ietf.org>; Tue, 03 Oct 2023 07:33:50 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
 d=gmail.com; s=20230601; t=1696343630; x=1696948430; darn=ietf.org;
 h=cc:to:subject:message-id:date:from:mime-version:from:to:cc:subject
 :date:message-id:reply-to;
 bh=t4fHG4kdr9RghAxxNUjTOfW5YSt+iemw6Szwx+SAhP4=;
 b=fI81/8+zS92S+S877ZUO6+xJQuEgrpeh7DttUsUh2ayuTm8RI20OayKlCOB0flizWh
 ZIAx/DqpFp3ZvHKLWrRwddBLHKnSe2zk26ALeb1TXhweQZiaH+kWESrphOLD2g5gGqyC
 aGg8FNh4JEFwqf3GZxmqI5GWYtGENmwY8kzBPPDvYa3X5Sw+rj7Egy2lUQZvDECQ7mIj
 0kt32BRspyu0elAbmvhZ0tRxjl4iTP1St3dNVgxdcqffBdEvqYfiMrTlILLRpr9ABsFN
 65XN1gCnPN7fhSjlLagp0LGzx1VVuRaGH4b9Vt0Kd1i3Uj9DkrZmH7hBWxLH4Sn2qHcm
 E3hg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
 d=1e100.net; s=20230601; t=1696343630; x=1696948430;
 h=cc:to:subject:message-id:date:from:mime-version:x-gm-message-state
 :from:to:cc:subject:date:message-id:reply-to;
 bh=t4fHG4kdr9RghAxxNUjTOfW5YSt+iemw6Szwx+SAhP4=;
 b=AhnDem/18aMPcOohnZjv/hnE7+riVmXcUqPx9nc01eoZWdWSdhVpQvg9Pzdq0uOE6U
 HE71WjU+DsMsqEOEwbDgsPDmSh1T5o7q3J52vb/75rP37XvOq+hEp1WzhGR7/8ibBiSU
 1n+0jcqpEvNvyGrUVbemfMMDe6objfu8iaFnSGCcpKYNiZTKK42MVExIro8iTLStmi54
 iTePGi3BrcjcNND4S0ndfwfEEwqw8eGCS87Wax5UCM/a4P0biVGSvbxM2ZSYsoQHbbiy
 UXZHMFgQ6cKjA58XmnVXAqSqe3+9UORwpaU8UAo3UjlGqvD5wtPVrb4hfG7FMou40AWo
 uZAg==
X-Gm-Message-State: AOJu0YxSRGMtYqgIhV8b2uYBNxztOs1ZX7EGTpJruw5zWPFEYnQqUE/O
 Kb+pfvkFIEG8V067VniNeqk02YjqiSjdYdq0ccudgRVKvxZikw==
X-Google-Smtp-Source: AGHT+IEc8SxDseYF8NtDzdgU8BTyh4YVo05a3roHXoKQyXuavsUwUAyyCAOfbqC7qQbYgc+hUc+d1PJ23W5aKshkSXE=
X-Received: by 2002:a17:90a:b706:b0:276:78f2:5d31 with SMTP id
 l6-20020a17090ab70600b0027678f25d31mr4255473pjr.21.1696343630120; Tue, 03 Oct
 2023 07:33:50 -0700 (PDT)
MIME-Version: 1.0
From: Bernard Aboba <bernard.aboba@gmail.com>
Date: Tue, 3 Oct 2023 07:33:39 -0700
Message-ID: <CAOW+2dsnKY2o=A69Dhb84VJUHemKJJYShDYBvGz5XaVcH5aX8g@mail.gmail.com>
To: IETF AVTCore WG <avt@ietf.org>
Cc: jianlin.qiu@intel.com, Philipp Hancke <philipp.hancke@gmail.com>
Content-Type: multipart/alternative; boundary="0000000000007d8dd30606d0c76a"
Archived-At: <https://mailarchive.ietf.org/arch/msg/avt/Tm6sd9kTx6Xt6cMXRKM_0vjCzBo>
Subject: [AVTCORE] draft-ietf-avtcore-hevc-webrtc: Updated PR #17 (RPSI)
X-BeenThere: avt@ietf.org
X-Mailman-Version: 2.1.39
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, 03 Oct 2023 14:33:52 -0000

--0000000000007d8dd30606d0c76a
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

Based on Stephan's suggestions, I have modified PR #17 ( Guidance on RPSI
implementation by aboba =C2=B7 Pull Request #17 =C2=B7 aboba/hevc-webrtc (g=
ithub.com)
<https://github.com/aboba/hevc-webrtc/pull/17>  ) to read as follows:

[RFC7798] Section 8.3 specifies the use of the Reference Picture Selection
Indication (RPSI) in H.265. Receivers that detect that H.265 encoder-decode=
r
synchronization has been lost SHOULD generate an RPSI feedback message if
support for RPSI has been negotiated, unless the receiver has knowledge tha=
t
the sender does not support RPSI. Such knowledge can be established during
capability exchange or through previously sent RPSI requests that were
not replied to by the sender through the use of a non-IRAP picture.
An RTP packet-stream sender that receives an RPSI message MUST act
on that message, and SHOULD change the reference picture.

--0000000000007d8dd30606d0c76a
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">Based on Stephan&#39;s suggestions, I have modified PR #17=
 (

<a href=3D"https://github.com/aboba/hevc-webrtc/pull/17">Guidance on RPSI i=
mplementation by aboba =C2=B7 Pull Request #17 =C2=B7 aboba/hevc-webrtc (gi=
thub.com)</a>=C2=A0 ) to read as follows:=C2=A0<div><br></div><div>[RFC7798=
] Section 8.3 specifies the use of the Reference Picture Selection<br>Indic=
ation (RPSI) in H.265. Receivers that detect that H.265 encoder-decoder<br>=
synchronization has been lost SHOULD generate an RPSI feedback message if<b=
r>support for RPSI has been negotiated, unless the receiver has knowledge t=
hat<br>the sender does not support RPSI. Such knowledge can be established =
during<br>capability exchange or through previously sent RPSI requests that=
 were<br>not replied to by the sender through the use of a non-IRAP picture=
.<br>An RTP packet-stream sender that receives an RPSI message MUST act<br>=
on that message, and SHOULD change the reference picture.<br></div></div>

--0000000000007d8dd30606d0c76a--

