Re: [codec] WGLC of draft-ietf-codec-opus-07
Jean-Marc Valin <jmvalin@jmvalin.ca> Sun, 24 July 2011 16:59 UTC
Return-Path: <jmvalin@jmvalin.ca>
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 2778C21F8551 for <codec@ietfa.amsl.com>; Sun, 24 Jul 2011 09:59:20 -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 ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TyG5j8xZZBse for <codec@ietfa.amsl.com>; Sun, 24 Jul 2011 09:59:19 -0700 (PDT)
Received: from smtpi4.usherbrooke.ca (smtpi4.USherbrooke.ca [132.210.236.3]) by ietfa.amsl.com (Postfix) with ESMTP id 866E921F8A23 for <codec@ietf.org>; Sun, 24 Jul 2011 09:59:19 -0700 (PDT)
Received: from localhost (www10.sti.USherbrooke.ca [132.210.244.217]) by smtpi4.usherbrooke.ca (8.13.8/8.13.8) with ESMTP id p6OGx3R2020491; Sun, 24 Jul 2011 12:59:04 -0400
Received: from 75.98.19.132 ([75.98.19.132]) by www.usherbrooke.ca (Horde Framework) with HTTP; Sun, 24 Jul 2011 12:59:03 -0400
Message-ID: <20110724125903.652252xb8cn9af0g@www.usherbrooke.ca>
Date: Sun, 24 Jul 2011 12:59:03 -0400
From: Jean-Marc Valin <jmvalin@jmvalin.ca>
To: codec@ietf.org
References: <D0DF9C6A-8344-46CF-A8E3-E2BA90EC2149@cisco.com> <4E26B5E3.8070107@jdrosen.net> <000001cc4920$4a72cb40$df5861c0$@uni-tuebingen.de> <000001cc49a3$328ed4a0$97ac7de0$@uni-tuebingen.de> <CAFgjPJ9svm+UXGEhoc4j=jQ0AGUqLJ_wDpW+mYenS36nZiAg5g@mail.gmail.com>
In-Reply-To: <CAFgjPJ9svm+UXGEhoc4j=jQ0AGUqLJ_wDpW+mYenS36nZiAg5g@mail.gmail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset="UTF-8"; DelSp="Yes"; format="flowed"
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
User-Agent: Internet Messaging Program (IMP) H3 (4.3.7)
X-Originating-IP: 75.98.19.132
X-UdeS-MailScanner-Information:
X-UdeS-MailScanner-ID: p6OGx3R2020491
X-UdeS-MailScanner: Aucun code suspect détecté
X-MailScanner-SpamCheck: n'est pas un polluriel, SpamAssassin (not cached, score=-7.499, requis 5, autolearn=not spam, BAYES_00 -2.60, RDNS_NONE 0.10, UDES_MONBUREAU02 -5.00)
X-UdeS-MailScanner-From: jmvalin@jmvalin.ca
Subject: Re: [codec] WGLC of draft-ietf-codec-opus-07
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: Sun, 24 Jul 2011 16:59:20 -0000
Hi Jehan, Thanks for the feedback. See below. Jehan Pagès <jehan.marmottard@gmail.com> a écrit : > * Section "3. Codec Modes" (page 11): > « For code 2 packets, the TOC byte is followed by a one or two byte > sequence indicating the the length of the first frame (marked N1 in > the figure below), followed by N1 bytes of compressed data for the > first frame. » > => there is a "the the" repetition. Will fix. > * Just below, in the same paragraph: > « > The > length of the first frame, N1, MUST be no larger than the size of the > payload remaining after decoding that length for all code 2 packets. > » > => I am not sure what it means? Aren't we simply telling that the > advertised length must not be larger than the actual length (which > appears logical to be by "definition" of "length")? Pretty much. It means that if a packet contains two frames, then the first can't be bigger than the packet. > * At the beginning of section "4. Opus decoder", the little graph has > a block which says "SILK encoder". I think it was supposed to say > "SILK decoder", no? Will fix. > Also probably a stupid question for someone new here, but I wondered: > what is exactly the role of padding? Is there an interest to have a > fixed size of packets on some platform for instance? There's many potential uses. One example is that in some cases, it may be desirable to take an existing VBR stream and turn it into a CBR stream. For example, this can be done to prevent information leakage over SRTP as suggested in http://tools.ietf.org/html/draft-perkins-avt-srtp-vbr-audio . Now, this could be done via RTP padding *except* that the RTP padding bit is not encrypted. So if we wanted to use RTP padding, we'd have to pad *every* frame to avoid leaking information. Keep in mind that the padding feature is also using a single bit that would otherwise be unused. > That's all from me. Sorry for not being more helpful. Any review is useful. Cheers, Jean-Marc
- [codec] WGLC of draft-ietf-codec-opus-07 Cullen Jennings
- Re: [codec] WGLC of draft-ietf-codec-opus-07 Jonathan Rosenberg
- Re: [codec] WGLC of draft-ietf-codec-opus-07 Jehan Pagès
- Re: [codec] WGLC of draft-ietf-codec-opus-07 Peter Saint-Andre
- Re: [codec] WGLC of draft-ietf-codec-opus-07 Christian Hoene
- Re: [codec] WGLC of draft-ietf-codec-opus-07 Stephan Wenger
- Re: [codec] WGLC of draft-ietf-codec-opus-07 Cullen Jennings
- Re: [codec] WGLC of draft-ietf-codec-opus-07 Christian Hoene
- Re: [codec] WGLC of draft-ietf-codec-opus-07 Christian Hoene
- Re: [codec] WGLC of draft-ietf-codec-opus-07 Jehan Pagès
- Re: [codec] WGLC of draft-ietf-codec-opus-07 Jehan Pagès
- Re: [codec] WGLC of draft-ietf-codec-opus-07 Christian Hoene
- Re: [codec] WGLC of draft-ietf-codec-opus-07 Jehan Pagès
- Re: [codec] WGLC of draft-ietf-codec-opus-07 Jean-Marc Valin
- Re: [codec] WGLC of draft-ietf-codec-opus-07 Timothy B. Terriberry
- Re: [codec] WGLC of draft-ietf-codec-opus-07 Peter Saint-Andre