Re: [codec] Discussion around ITU LS

Jean-Marc Valin <jmvalin@mozilla.com> Wed, 07 September 2011 04:18 UTC

Return-Path: <jmvalin@mozilla.com>
X-Original-To: codec@ietfa.amsl.com
Delivered-To: codec@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6D74C21F8BEB for <codec@ietfa.amsl.com>; Tue, 6 Sep 2011 21:18:33 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Level:
X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mOnXmABXJ1Io for <codec@ietfa.amsl.com>; Tue, 6 Sep 2011 21:18:32 -0700 (PDT)
Received: from dm-mail03.mozilla.org (dm-mail03.mozilla.org [63.245.208.213]) by ietfa.amsl.com (Postfix) with ESMTP id 9138921F8C0F for <codec@ietf.org>; Tue, 6 Sep 2011 21:18:31 -0700 (PDT)
Received: from [192.168.1.142] (modemcable239.192-178-173.mc.videotron.ca [173.178.192.239]) (Authenticated sender: jvalin@mozilla.com) by dm-mail03.mozilla.org (Postfix) with ESMTP id 3A1634AED58; Tue, 6 Sep 2011 21:20:19 -0700 (PDT)
Message-ID: <4E66F111.9070008@mozilla.com>
Date: Wed, 07 Sep 2011 00:20:33 -0400
From: Jean-Marc Valin <jmvalin@mozilla.com>
User-Agent: Mozilla/5.0 (X11; Linux i686 on x86_64; rv:6.0) Gecko/20110812 Thunderbird/6.0
MIME-Version: 1.0
To: Cullen Jennings <fluffy@cisco.com>
References: <35921B63-3FBC-411D-B587-4AB81F218E57@cisco.com>
In-Reply-To: <35921B63-3FBC-411D-B587-4AB81F218E57@cisco.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Cc: Jonathan Rosenberg <jonathan.rosenberg@skype.net>, codec@ietf.org
Subject: Re: [codec] Discussion around ITU LS
X-BeenThere: codec@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Codec WG <codec.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/codec>, <mailto:codec-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/codec>
List-Post: <mailto:codec@ietf.org>
List-Help: <mailto:codec-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/codec>, <mailto:codec-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 07 Sep 2011 04:18:33 -0000

On 06/09/11 04:54 PM, Cullen Jennings wrote:
> Some issues are pointed out with the example code. Can these be
> fixed?

We have been working on addressing the comments that were raised during
the WGLC. We should be done within the next few days.

> WIll the implementation include switching between SILK and CELT
> modes.

Seamless mode switching between all three modes has been part of the
bit-stream (i.e. the decoder) since the initial "freeze". The current
reference encoder includes some simple heuristics that work well in
practice. However, there is no plan right now for optimal encoder-side
mode switching decisions based on automatic speech/music. This can
always be added later in an improved encoder (without any compatibility
issue). Keep in mind that this is much harder to do for a low-delay
real-time codec than it can be for a streaming/archival codec.

> My understanding is the reference code is not meant to be an
> optimized version or work on a wide variety of platforms. It is
> simply supposed to be one implementation that defines the algorithm
> on a given architecture. Is this correct?

The current code actually works reasonably well/fast on a wide variety
of platforms. To make the code simpler, it does not include
architecture-specific optimizations, which are up to the implementers. I
believe the comment about portability was mostly referring to Windows
project files. for the sake of simplicity, those are not included in the
draft, though there is a separate package that includes them. As a note
on portability, Opus has been successfully compiled and run on quite a
few architectures. I think Greg is in a better position to comment on this.

> What would people like to see with respect to test vectors?

Again, Greg's been working on that.

> Does the WG consider  time shortening / stretching functionality they
> would want to include in opus as a technique to use for PLC?

While time stretching/shortening is something that can be useful, I
don't think it's really necessary for a codec *specification*. In fact
even the PLC is provided only as an example.

Cheers,

	Jean-Marc