Re: [dispatch] Dispatch outcome: Opus codec updates

Jean-Marc Valin <jmvalin@amazon.com> Tue, 18 April 2023 22:29 UTC

Return-Path: <prvs=465c3286c=jmvalin@amazon.com>
X-Original-To: dispatch@ietfa.amsl.com
Delivered-To: dispatch@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1B631C151541; Tue, 18 Apr 2023 15:29:33 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -11.9
X-Spam-Level:
X-Spam-Status: No, score=-11.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, NICE_REPLY_A=-0.001, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H2=-0.001, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_DBL_BLOCKED_OPENDNS=0.001, URIBL_ZEN_BLOCKED_OPENDNS=0.001, USER_IN_DEF_SPF_WL=-7.5] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=amazon.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 HYGQylHMOKZq; Tue, 18 Apr 2023 15:29:29 -0700 (PDT)
Received: from smtp-fw-33001.amazon.com (smtp-fw-33001.amazon.com [207.171.190.10]) (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 30863C151530; Tue, 18 Apr 2023 15:29:29 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=amazon.com; i=@amazon.com; q=dns/txt; s=amazon201209; t=1681856969; x=1713392969; h=message-id:date:mime-version:from:subject:to:cc: references:in-reply-to:content-transfer-encoding; bh=xxLlyjPi7Wv65c6S2btpiHl3SFu6K2WL/769aEg0t5I=; b=r+qLyUnth9VZjMXA80e3ThYPt44jrF68uqlrM021HPcs766ijd+zQiB+ CV5C0Kj1QfxnIb0HJQ4HrK4UZyZRVVCXCVlXkirLwGmrZNTwS9icGJtO8 MkDCdxF4UpohgALG0jm87/DXPwanTZeaBersVqKWw8Xy2bwko4skWifRA E=;
X-IronPort-AV: E=Sophos;i="5.99,207,1677542400"; d="scan'208";a="278193434"
Received: from iad12-co-svc-p1-lb1-vlan3.amazon.com (HELO email-inbound-relay-iad-1e-m6i4x-b538c141.us-east-1.amazon.com) ([10.43.8.6]) by smtp-border-fw-33001.sea14.amazon.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 18 Apr 2023 22:29:28 +0000
Received: from EX19MTAUEC001.ant.amazon.com (iad12-ws-svc-p26-lb9-vlan2.iad.amazon.com [10.40.163.34]) by email-inbound-relay-iad-1e-m6i4x-b538c141.us-east-1.amazon.com (Postfix) with ESMTPS id 2303EA2E8B; Tue, 18 Apr 2023 22:29:25 +0000 (UTC)
Received: from EX19D015UEA003.ant.amazon.com (10.252.134.165) by EX19MTAUEC001.ant.amazon.com (10.252.135.222) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.2.1118.26; Tue, 18 Apr 2023 22:29:25 +0000
Received: from [192.168.22.173] (10.187.171.36) by EX19D015UEA003.ant.amazon.com (10.252.134.165) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.2.1118.26; Tue, 18 Apr 2023 22:29:24 +0000
Message-ID: <49d511eb-3561-52c3-2b0e-bfe5a4e361b6@amazon.com>
Date: Tue, 18 Apr 2023 18:29:21 -0400
MIME-Version: 1.0
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101 Thunderbird/102.10.0
From: Jean-Marc Valin <jmvalin@amazon.com>
To: "dispatch@ietf.org" <dispatch@ietf.org>
CC: "dispatch-chairs@ietf.org" <dispatch-chairs@ietf.org>, dispatch-ads@ietf.org
References: <ab1a97c9cd1d4490b3713a92fe4f40cd@huawei.com> <CAC9wnY_=rYw46rD8wMsVOt-zOkYgb5T618rcBsX2q9huMza-GQ@mail.gmail.com>
Content-Language: en-US
In-Reply-To: <CAC9wnY_=rYw46rD8wMsVOt-zOkYgb5T618rcBsX2q9huMza-GQ@mail.gmail.com>
Content-Type: text/plain; charset="UTF-8"; format="flowed"
Content-Transfer-Encoding: 8bit
X-Originating-IP: [10.187.171.36]
X-ClientProxiedBy: EX19D032UWB002.ant.amazon.com (10.13.139.190) To EX19D015UEA003.ant.amazon.com (10.252.134.165)
Archived-At: <https://mailarchive.ietf.org/arch/msg/dispatch/jHVHesRogCCXOFrkOwQ0FbVYi2Q>
Subject: Re: [dispatch] Dispatch outcome: Opus codec updates
X-BeenThere: dispatch@ietf.org
X-Mailman-Version: 2.1.39
Precedence: list
List-Id: DISPATCH Working Group Mail List <dispatch.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/dispatch>, <mailto:dispatch-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/dispatch/>
List-Post: <mailto:dispatch@ietf.org>
List-Help: <mailto:dispatch-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dispatch>, <mailto:dispatch-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 18 Apr 2023 22:29:33 -0000

Hi,

Here is the charter we are proposing for the new mlcodec WG:


Problem Statement

The Opus codec (RFC 6716) was adopted by the IETF in 2012. Since then,
speech and audio processing technology has made significant progress,
thanks in large part to deep learning techniques. It is desirable to
update the existing Opus codec to benefit from recent advances without
breaking compatibility with RFC 6716. Opus has achieved a wide degree of
interoperability by using in-band signaling to avoid negotiation
failure. Implementing new coding technology within Opus would allow
incremental compatible deployment of the updated specification, while
preserving interoperability with the existing billions of Opus-enabled
devices.

In doing so, we wish to retain the original qualities that drove the
original Opus development to develop codecs that (quoting from codec WG 
charter):

1. Are optimized for use in interactive Internet applications.
2. Are published by a recognized standards development organization
(SDO) and therefore subject to clear change control.
3. Can be widely implemented and easily distributed among application
developers, service operators, and end users.

Objectives

The goals of this working group are:

1) Improving the robustness to packet loss of Opus through efficient
redundancy transmission
2) Improving the speech coding quality at low bitrates
3) Improving the music coding quality at low bitrates

The working group may also consider other improvements to Opus. The
group will only consider solutions that result in bitstreams that are
forwards and backwards compatible with RFC6716, and thus decodable by
any decoder. Although it is likely that machine learning will be
required to meet the objectives above, classical solutions will also be
considered if they can achieve similar performance.

As was the case with the original codec WG, this work will primarily
focus on interactive, real-time applications over the Internet and will
ensure interoperability with existing IETF real-time protocols,
including RTP, SIP/SDP, and WebRTC. Given the widespread deployment of
WebRTC, ensuring that the work improves WebRTC experience is of
particular importance. Other applications, such as non-real-time
streaming will be considered too, but only so long as their requirements
do not interfere with those of real-time applications.

The working group cannot explicitly rule out the possibility of adopting
encumbered technologies; however, consistent with BCP 78 and BCP 79, the
working group will try to avoid encumbered technologies that require
royalties or other encumbrances that would prevent such technologies
from being easy to redistribute and use.

Deliverables

1. A specification for a generic Opus extension mechanism that can be
used not only for the other proposed deliverables, but can also sustain
further extensions to Opus in the future. This document shall be a
Proposed Standard document.

2. A specification for coding large amounts of very low bitrate
redundancy information for the purpose of significantly improving the
robustness of Opus to bursts of packet loss. This document shall be a
Proposed Standard document.

3. A specification for improving the quality of SILK- and hybrid-coded
speech through decoder changes, with and without side information
provided by the encoder. This will be done in a way that does not affect
interoperability between original and extended implementations. This
document shall be a Proposed Standard document.

4. A specification for improving the quality of CELT-coded audio (both
speech and music) through decoder changes, with and without side
information provided by the encoder. This will be done in a way that
does not affect interoperability between original and extended
implementations. This document shall be a Proposed Standard document.

Milestones

TBD



On 3/27/23 01:13, Kirsty Paine wrote:
>
> Hi Jean-Marc,
>
> Thank you for your presentation this morning at dispatch! I hope you 
> found the discussion and feedback useful, and I think your audio file 
> went down a storm. We recorded the dispatch outcome as follows:
> /Strong interest in the work; create a new WG rather than re-open the 
> existing one, charter to be worked out with ADs and shared on list./
>
> As for next steps, this seems clear - you need to make a WG charter, 
> and share it with Murray to refine it, before sharing on the dispatch 
> list for info and on the new WG mailing list too. There were a couple 
> of volunteers for the WG chair too (notes on Zulip); I would advise 
> reaching out to these folks for some help in crafting a charter. If 
> you've not done that before, take a look at some other groups' 
> charters for inspiration and an idea of style. The one for dispatch is 
> here, for example: https://datatracker.ietf.org/doc/charter-ietf-dispatch/
>
> Additionally, I would advise taking a look through the Zulip stream 
> for dispatch 
> <https://zulip.ietf.org/#narrow/stream/43-dispatch/topic/ietf-116> to 
> see what feedback and questions were asked there. If you want to come 
> back on any of the discussion, where we didn't have time in the 
> meeting, please feel free to continue that discussion on the dispatch 
> list.
>
> Thank you again for your time and please revert to the chairs if you 
> have any further questions on next steps - Shuping and I are around 
> this week if you want to meet up.
>
> Kirsty & Shuping (& Jim, as the new co-chair)