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