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)
- Re: [dispatch] Dispatch outcome: Opus codec updat… Jean-Marc Valin
- Re: [dispatch] Dispatch outcome: Opus codec updat… Murray S. Kucherawy