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

Mark Harris <mark.hsj@gmail.com> Thu, 29 August 2013 23:21 UTC

Return-Path: <markh.sj@gmail.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 0DBC911E818B for <codec@ietfa.amsl.com>; Thu, 29 Aug 2013 16:21:46 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.6
X-Spam-Level:
X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, NO_RELAYS=-0.001]
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 cq0ROR4s+c67 for <codec@ietfa.amsl.com>; Thu, 29 Aug 2013 16:21:45 -0700 (PDT)
Received: from mail-qa0-x233.google.com (mail-qa0-x233.google.com [IPv6:2607:f8b0:400d:c00::233]) by ietfa.amsl.com (Postfix) with ESMTP id 748B311E817D for <codec@ietf.org>; Thu, 29 Aug 2013 16:21:45 -0700 (PDT)
Received: by mail-qa0-f51.google.com with SMTP id bv4so800040qab.17 for <codec@ietf.org>; Thu, 29 Aug 2013 16:21:45 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:date:message-id:subject:from:to:content-type; bh=M6IZH78xI41PDKvvJzaeQzIP9yQ/cn3YCG4Zk6sFrqo=; b=y4ePDbKJ1WdqYoZ8cOLTeTDFjpN3zxn4PVC4y1b7dh/qzxNaDRX68MdzpbBi96u1FP U7IeXNoHVfryGbZsKng1sQpfsNwfTKHpOfEcxc0E9/yEoGP1cV6L/lxarksf0fGB/SEU mvCkKlAi7YawqlZg/aT1QbH3CXH9eWrExcmneUA4+sOxrERFenm0/NdflyNAJM3/Npfj 5fqtEHxfJgWE1DQ7YnTp1nvpMcg0Td2dEPxVvgaXjQj+CHgDm1vBubglcIctCTtzXFz+ 47rZM8IeIJu9jmHWybJDbrldMD9UNGRxBe/o3IQZZwVxeR6LWCCCFdH0/RPSlJc6dIjg rf/g==
MIME-Version: 1.0
X-Received: by 10.224.12.146 with SMTP id x18mr51051qax.110.1377818504977; Thu, 29 Aug 2013 16:21:44 -0700 (PDT)
Sender: markh.sj@gmail.com
Received: by 10.49.101.40 with HTTP; Thu, 29 Aug 2013 16:21:44 -0700 (PDT)
Date: Thu, 29 Aug 2013 16:21:44 -0700
X-Google-Sender-Auth: Mrp48fABhgWz9pehiCqhUBhfJJ8
Message-ID: <CAMdZqKE6Z3NWN=igExUNZ8SaQ=xeR468-Mdxj1DObD9DhaztbQ@mail.gmail.com>
From: Mark Harris <mark.hsj@gmail.com>
To: codec@ietf.org
Content-Type: text/plain; charset=UTF-8
Subject: [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: Thu, 29 Aug 2013 23:21:46 -0000

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)