Re: [codec] draft-valin-codec-opus-update-00 minor nits

Jean-Marc Valin <jmvalin@mozilla.com> Fri, 06 September 2013 18:52 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 CCC0311E81DC for <codec@ietfa.amsl.com>; Fri, 6 Sep 2013 11:52:24 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.677
X-Spam-Level:
X-Spam-Status: No, score=-2.677 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_MISMATCH_ORG=0.611, HOST_MISMATCH_COM=0.311, RCVD_IN_DNSWL_LOW=-1]
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 FVOsttdPtAV5 for <codec@ietfa.amsl.com>; Fri, 6 Sep 2013 11:52:20 -0700 (PDT)
Received: from smtp.mozilla.org (mx1.corp.phx1.mozilla.com [63.245.216.69]) by ietfa.amsl.com (Postfix) with ESMTP id 6E8EF11E8178 for <codec@ietf.org>; Fri, 6 Sep 2013 11:52:20 -0700 (PDT)
Received: from [192.168.1.15] (modemcable130.97-201-24.mc.videotron.ca [24.201.97.130]) (Authenticated sender: jvalin@mozilla.com) by mx1.mail.corp.phx1.mozilla.com (Postfix) with ESMTPSA id B39B1F258E; Fri, 6 Sep 2013 11:52:19 -0700 (PDT)
Message-ID: <522A2462.2010700@mozilla.com>
Date: Fri, 06 Sep 2013 14:52:18 -0400
From: Jean-Marc Valin <jmvalin@mozilla.com>
User-Agent: Mozilla/5.0 (X11; Linux i686 on x86_64; rv:17.0) Gecko/20130801 Thunderbird/17.0.8
MIME-Version: 1.0
To: Mark Harris <mark.hsj@gmail.com>
References: <CAMdZqKE6Z3NWN=igExUNZ8SaQ=xeR468-Mdxj1DObD9DhaztbQ@mail.gmail.com>
In-Reply-To: <CAMdZqKE6Z3NWN=igExUNZ8SaQ=xeR468-Mdxj1DObD9DhaztbQ@mail.gmail.com>
X-Enigmail-Version: 1.5.2
Content-Type: text/plain; charset="ISO-8859-1"
Content-Transfer-Encoding: 7bit
Cc: codec@ietf.org
Subject: Re: [codec] draft-valin-codec-opus-update-00 minor nits
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: Fri, 06 Sep 2013 18:52:28 -0000

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Hi Mark,

Thanks for the feedback. I'll apply the changes. The only one I'm not
sure what to do about is the >72 column patches that I'm including.
Does anyone have a suggestion for how to include those cleanly in the
document?

Cheers,

	Jean-Marc

On 08/29/2013 07:21 PM, Mark Harris wrote:
> Some minor formatting/grammar nits in
> draft-valin-codec-opus-update-00:
> 
> 
> This document address minor issues that were discovered in the
> 
> s/address/addresses/
> 
> impulse (i.e.  single sample) in the decoded audio.  This can be
> 
> s/i.e.  /i.e. /
> 
> This packet parsing issue is limited to reading memory up to about
> 60 kB beyond the compressed buffer.  This can only be triggered by
> a
> 
> incorrect line break between quantity and its unit
> 
> for RTP.  In theory, it _could_ crash a file decoder (e.g.  Opus
> in
> 
> s/e.g.  /e.g. /
> 
> 2.  Because the size was wrong, this potentially allowed the
> source and destination regions of the memcpy overlap.  We _believe_
> that nSamplesIn is at least fs_in_khZ, which is at least 8.  Since 
> RESAMPLER_ORDER_FIR_12 is only 8,that should not be a problem once
> the type size is fixed.
> 
> s/memcpy overlap/memcpy() to overlap/ s/8,that/8, that/
> 
> The fact that the code never produced any error in testing
> (including when run under the Valgrind memory debugger), suggests
> that in practice the batch sizes are reasonable enough that none of
> the issues above was ever a problem.  However, proving that is
> non- obvious.
> 
> s/was/were/
> 
> The code can be fixed by applying the following changes to like 70
> of silk/resampler_private_IIR_FIR.c:
> 
> s/like/line/
> 
> The last issue is not strictly a bug, but it is an issue that has 
> been reported when downmixing Opus decoded stream to mono, whether 
> this is done inside the decoder or as a post-processing on the
> stereo decoder output.  Opus intensity stereo allows optionally
> coding the
> 
> s/downmixing/downmixing an/ s/post-processing/post-processing
> step/
> 
> some source lines exceed 72 columns (rfc max) 
> _______________________________________________ codec mailing list 
> codec@ietf.org https://www.ietf.org/mailman/listinfo/codec
> 

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.13 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

iQEcBAEBAgAGBQJSKiRiAAoJEJ6/8sItn9q9758H/0xoQB5vnrxWXfmjXXqclAam
aP9O1D3MgPSpqgcueTSUUlJKmuDNkisjeys4UHC+ftaqY/zoTMYzq2dDuLSb+7cN
IExZeuN19Cz2EysHYwKUV11bcu/OwKp2/1hQsxsGcnaDbS5FMmFwcbhWyU9eSiJD
X003zFTZJi345THVDykm8yvcIaPid9ZS3OIzY40WJPSHPtobyhtlEufmwfehJ/hJ
GpZGFPabSaKbecXoNyMC6EzhzEYsc7WZHb/DgPCEggnkrQkwq+jBZfagmbMYLPK/
PH87qMf0FgJj9Ajz5Rlkd3aXo4MWuCPHZX4PMB6QJyYMROWHhTS37cyWQm9igQ8=
=bMwJ
-----END PGP SIGNATURE-----