From hoene@uni-tuebingen.de Tue Mar 26 07:22:38 2013 Return-Path: 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 4C0BC21F8BBA for ; Tue, 26 Mar 2013 07:22:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.649 X-Spam-Level: X-Spam-Status: No, score=-3.649 tagged_above=-999 required=5 tests=[BAYES_50=0.001, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_MED=-4] 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 vze+ewbnDtCU for ; Tue, 26 Mar 2013 07:22:37 -0700 (PDT) Received: from mx08.uni-tuebingen.de (mx08.uni-tuebingen.de [134.2.3.6]) by ietfa.amsl.com (Postfix) with ESMTP id E6B5021F8B98 for ; Tue, 26 Mar 2013 07:22:36 -0700 (PDT) Received: from ChristianHoene (u-173-c016.cs.uni-tuebingen.de [134.2.173.16]) (authenticated bits=0) by mx08.uni-tuebingen.de (8.13.6/8.13.6) with ESMTP id r2QEMZiC008046 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO) for ; Tue, 26 Mar 2013 15:22:35 +0100 From: "Hoene" To: Date: Tue, 26 Mar 2013 15:22:43 +0100 Message-ID: <016101ce2a2d$61d02950$25707bf0$@uni-tuebingen.de> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Outlook 14.0 Thread-Index: Ac4qLVv0RzXb48JhSNWOm3uGD2Yw7Q== Content-Language: de X-AntiVirus-Spam-Check: clean (checked by Avira MailGate: version: 3.2.1.26; spam filter version: 3.2.0/2.3; host: mx08) X-AntiVirus: checked by Avira MailGate (version: 3.2.1.26; AVE: 8.2.12.20; VDF: 7.11.67.26; host: mx08); id=9768-PciASK Subject: [codec] MUSHRA testings from April 22 to 27 X-BeenThere: codec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Codec WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 26 Mar 2013 14:22:38 -0000 Hello, we will do some MUSHRA testing in the week of April 22 in T=FCbingen, = Germany. If someone is around and want to participate, please register here: https://www.doodle.com/symonics With best regards, Christian Hoene -- Universit=E4t T=FCbingen, Sand 13, 72076 T=FCbingen, Germany Tel +49 7071 2970532, Fax +49 7071 5220 http://kn.inf.uni-tuebingen.de/staff/hoene.html From coverdale@sympatico.ca Tue Mar 26 07:32:02 2013 Return-Path: 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 82A2021F8C08 for ; Tue, 26 Mar 2013 07:32:02 -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 E6lMNMtgPepu for ; Tue, 26 Mar 2013 07:32:01 -0700 (PDT) Received: from mail8.itu.ch (mail8.itu.ch [156.106.192.38]) by ietfa.amsl.com (Postfix) with ESMTP id E35C121F8A08 for ; Tue, 26 Mar 2013 07:32:00 -0700 (PDT) Received: from PaulNewPC ([156.106.247.10]) by mail8.itu.ch (8.13.8/8.14.4) with SMTP id r2QEVxNK027924 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Tue, 26 Mar 2013 15:31:59 +0100 From: "Paul Coverdale" To: "'Hoene'" , References: <016101ce2a2d$61d02950$25707bf0$@uni-tuebingen.de> In-Reply-To: <016101ce2a2d$61d02950$25707bf0$@uni-tuebingen.de> Date: Tue, 26 Mar 2013 15:31:58 +0100 Message-ID: <001f01ce2a2e$aca52790$05ef76b0$@ca> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: Ac4qLVv0RzXb48JhSNWOm3uGD2Yw7QAAOCww Content-Language: en-us X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.4.3 (mail8.itu.ch [156.106.192.38]); Tue, 26 Mar 2013 15:31:59 +0100 (CET) Subject: Re: [codec] MUSHRA testings from April 22 to 27 X-BeenThere: codec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Codec WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 26 Mar 2013 14:32:02 -0000 Hi Christian, What is the test plan? ...Paul >-----Original Message----- >From: codec-bounces@ietf.org [mailto:codec-bounces@ietf.org] On Behalf >Of Hoene >Sent: Tuesday, March 26, 2013 3:23 PM >To: codec@ietf.org >Subject: [codec] MUSHRA testings from April 22 to 27 > >Hello, > >we will do some MUSHRA testing in the week of April 22 in T=FCbingen, >Germany. >If someone is around and want to participate, please register here: >https://www.doodle.com/symonics > >With best regards, > > Christian Hoene > >-- >Universit=E4t T=FCbingen, Sand 13, 72076 T=FCbingen, Germany Tel +49 = 7071 >2970532, Fax +49 7071 5220 http://kn.inf.uni- >tuebingen.de/staff/hoene.html > > >_______________________________________________ >codec mailing list >codec@ietf.org >https://www.ietf.org/mailman/listinfo/codec From jmvalin@jmvalin.ca Fri Mar 29 14:39:13 2013 Return-Path: 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 E768421F95FF for ; Fri, 29 Mar 2013 14:39:13 -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 UVcbI9NdTYWn for ; Fri, 29 Mar 2013 14:39:13 -0700 (PDT) Received: from smtp.mozilla.org (mx2.corp.phx1.mozilla.com [63.245.216.70]) by ietfa.amsl.com (Postfix) with ESMTP id 05F8B21E805E for ; Fri, 29 Mar 2013 14:39:09 -0700 (PDT) Received: from [192.168.1.15] (modemcable094.20-21-96.mc.videotron.ca [96.21.20.94]) (Authenticated sender: jvalin@mozilla.com) by mx2.mail.corp.phx1.mozilla.com (Postfix) with ESMTPSA id C5B94F250B; Fri, 29 Mar 2013 14:39:04 -0700 (PDT) Message-ID: <515609F7.7090402@jmvalin.ca> Date: Fri, 29 Mar 2013 17:39:03 -0400 From: Jean-Marc Valin User-Agent: Mozilla/5.0 (X11; Linux i686 on x86_64; rv:17.0) Gecko/20130307 Thunderbird/17.0.4 MIME-Version: 1.0 To: "Timothy B. Terriberry" References: <20121119225213.13225.30835.idtracker@ietfa.amsl.com> <50AABA00.6030102@xiph.org> In-Reply-To: <50AABA00.6030102@xiph.org> Content-Type: multipart/mixed; boundary="------------060406000908070304060903" Cc: codec@ietf.org Subject: Re: [codec] I-D Action: draft-ietf-codec-oggopus-00.txt X-BeenThere: codec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Codec WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 29 Mar 2013 21:39:14 -0000 This is a multi-part message in MIME format. --------------060406000908070304060903 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Hi Tim, Here's a revised patch that describes guidelines for encoders. These guidelines are related to gapless support, but I'm sure there's other recommendations we should give encoder implementers. The general idea is to minimize the number of broken or suboptimal encoders. Cheers, Jean-Marc On 11/19/2012 06:00 PM, Timothy B. Terriberry wrote: > internet-drafts@ietf.org wrote: >> A New Internet-Draft is available from the on-line Internet-Drafts >> directories. >> This draft is a work item of the Internet Wideband Audio Codec >> Working Group of the IETF. > > The (other) chairs declared there was consensus to adopt this draft as a > WG item and asked me to upload a new version of it. > > I have made a few minor edits from draft-terriberry-oggopus-01: > 1) Fixed up the references. > 2) Fixed a couple of typos. > 3) Replaced a "should" with a "SHOULD" in Section 4.1. > 4) Clarified the language around the starting granule position in the > case that a) there is more audio in packets that complete on the first > audio data page with a completed packet than the granule position > indicates and b) the EOS flag is set on the same page (in this case you > should not count forwards from 0, but should work backwards to figure > out the real starting granule position). > 5) Updated the acknowledgments. > > I have not incorporated any of the proposals that have been made to the > list since the initial draft was posted (e.g., seamless chaining, > replaygain tags, etc.). > _______________________________________________ > codec mailing list > codec@ietf.org > https://www.ietf.org/mailman/listinfo/codec > > --------------060406000908070304060903 Content-Type: text/x-patch; name="oggopus_encoder_guidelines.patch" Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="oggopus_encoder_guidelines.patch" diff --git a/doc/draft-ietf-codec-oggopus.xml b/doc/draft-ietf-codec-oggopus.xml index ab20be5..9c23cbf 100644 --- a/doc/draft-ietf-codec-oggopus.xml +++ b/doc/draft-ietf-codec-oggopus.xml @@ -1138,6 +1138,74 @@ An implementation could reasonably choose any of these numbers for its internal +
+ +When encoding Opus files, Ogg encoders should take into account the +algorithmic delay of the Opus encoder. In encoders derived from the reference +implementation, the number of samples can be queried with: +opus_encoder_ctl(encoder_state, OPUS_GET_LOOKAHEAD, &samples_delay); +To achieve good quality in the very first samples of a stream, the Ogg encoder +MAY use LPC extrapolation to generate at least 120 extra samples +(extra_samples) at the beginning to avoid the Opus encoder having to encode +a discontinuous signal. +For an input file containing length samples, the Ogg encoder, SHOULD set the +preskip header flag to samples_delay+extra_samples, encode at least +length+samples_delay+extra_samples samples, and set the granulepos of the last +page to length+samples_delay+extra_samples. +This ensures that the encoded file has the same duration as the original, with +no time offset. The best way to pad the end of the stream is to also use LPC +extrapolation, but zero-padding is also acceptable. + + +
+ +The first step in LPC extrapolation is to compute linear prediction coefficients. +When extending the end of the signal, order-N (typically with N ranging from 8 +to 40) LPC analysis is performed on a window near the end of the signal. The last +N samples are used as memory to an infinite impulse response (IIR) filter. The +filter is then applied on a zero input to extrapolate the end of the signal. Let +a(k) be the kth LPC coefficient and x(n) be the nth sample of the signal, each +new sample past the end of the signal is computed as: + +The process is repeated independently for each channel. It is possible to extend +the beginning of the signal by applying the same process backward in time. When +extending the beginning of the signal, it is best to apply a "fade in" to the +extrapolated signal, e.g. by multiplying it by a half-Hanning window. + + +
+ +
+ +In some applications, such as Internet radio, it is desirable to cut a long +streams into smaller chains, e.g. so the comment header can be updated. +This can be done simply by separating the input streams into segments and +encoding each segment independenty. +The ony drawback of this approach is that it creates a small discontinuity +at the boundary due to the lossy nature of Opus. +An encoder MAY avoid this discontinuity by using the following procedure: + +On the last frame of the first stream, encoding an independent frame by +turning off all forms of inter-frame prediction (de-emphasis is allowed). +setting the granulepos of the past page to a point near the end of the last +frame. +Beginning the new stream with a copy of the last frame of the first +stream. +Setting the preskip flag of the second stream in such a way as to properly +join the two streams. +Continuing the encoding process normally from there, without any reset to +the encoder. + + +
+
What follows is a brief summary of major implementations of this --------------060406000908070304060903-- From ron@debian.org Sat Mar 30 00:28:05 2013 Return-Path: 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 7DF2821F8B25 for ; Sat, 30 Mar 2013 00:28:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.423 X-Spam-Level: X-Spam-Status: No, score=-1.423 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_HOST_EQ_D_D_D_D=0.765, HOST_MISMATCH_NET=0.311, RDNS_DYNAMIC=0.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 PFlWCxmdBwfs for ; Sat, 30 Mar 2013 00:28:04 -0700 (PDT) Received: from ipmail05.adl6.internode.on.net (ipmail05.adl6.internode.on.net [IPv6:2001:44b8:8060:ff02:300:1:6:5]) by ietfa.amsl.com (Postfix) with ESMTP id 46D6A21F8B18 for ; Sat, 30 Mar 2013 00:28:03 -0700 (PDT) Received: from ppp121-45-66-146.lns20.adl6.internode.on.net (HELO audi.shelbyville.oz) ([121.45.66.146]) by ipmail05.adl6.internode.on.net with ESMTP; 30 Mar 2013 17:58:02 +1030 Received: from localhost (localhost [127.0.0.1]) by audi.shelbyville.oz (Postfix) with ESMTP id 9F16E4F8F3 for ; Sat, 30 Mar 2013 17:58:01 +1030 (CST) X-Virus-Scanned: Debian amavisd-new at audi.shelbyville.oz Received: from audi.shelbyville.oz ([127.0.0.1]) by localhost (audi.shelbyville.oz [127.0.0.1]) (amavisd-new, port 10024) with LMTP id GomxKO4HPh3R for ; Sat, 30 Mar 2013 17:58:00 +1030 (CST) Received: by audi.shelbyville.oz (Postfix, from userid 1000) id B36774F902; Sat, 30 Mar 2013 17:58:00 +1030 (CST) Date: Sat, 30 Mar 2013 17:58:00 +1030 From: Ron To: codec@ietf.org Message-ID: <20130330072800.GU19099@audi.shelbyville.oz> References: <20121119225213.13225.30835.idtracker@ietfa.amsl.com> <50AABA00.6030102@xiph.org> <515609F7.7090402@jmvalin.ca> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <515609F7.7090402@jmvalin.ca> User-Agent: Mutt/1.5.20 (2009-06-14) Subject: Re: [codec] I-D Action: draft-ietf-codec-oggopus-00.txt X-BeenThere: codec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Codec WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 30 Mar 2013 07:28:05 -0000 Hi Jean-Marc, A few quick "first-reading" comments on this ... On Fri, Mar 29, 2013 at 05:39:03PM -0400, Jean-Marc Valin wrote: > Hi Tim, > > Here's a revised patch that describes guidelines for encoders. These > guidelines are related to gapless support, but I'm sure there's other > recommendations we should give encoder implementers. The general idea is > to minimize the number of broken or suboptimal encoders. > diff --git a/doc/draft-ietf-codec-oggopus.xml b/doc/draft-ietf-codec-oggopus.xml > index ab20be5..9c23cbf 100644 > --- a/doc/draft-ietf-codec-oggopus.xml > +++ b/doc/draft-ietf-codec-oggopus.xml > @@ -1138,6 +1138,74 @@ An implementation could reasonably choose any of these numbers for its internal > >
> > +
> + > +When encoding Opus files, Ogg encoders should take into account the > +algorithmic delay of the Opus encoder. In encoders derived from the reference > +implementation, the number of samples can be queried with: > +opus_encoder_ctl(encoder_state, OPUS_GET_LOOKAHEAD, &samples_delay); > +To achieve good quality in the very first samples of a stream, the Ogg encoder > +MAY use LPC extrapolation to generate at least 120 extra samples > +(extra_samples) at the beginning to avoid the Opus encoder having to encode > +a discontinuous signal. > +For an input file containing length samples, the Ogg encoder, SHOULD set the > +preskip header flag to samples_delay+extra_samples, encode at least > +length+samples_delay+extra_samples samples, and set the granulepos of the last > +page to length+samples_delay+extra_samples. > +This ensures that the encoded file has the same duration as the original, with > +no time offset. The best way to pad the end of the stream is to also use LPC > +extrapolation, but zero-padding is also acceptable. > + > + > +
> + > +The first step in LPC extrapolation is to compute linear prediction coefficients. > +When extending the end of the signal, order-N (typically with N ranging from 8 > +to 40) LPC analysis is performed on a window near the end of the signal. The last > +N samples are used as memory to an infinite impulse response (IIR) filter. The > +filter is then applied on a zero input to extrapolate the end of the signal. Let > +a(k) be the kth LPC coefficient and x(n) be the nth sample of the signal, each > +new sample past the end of the signal is computed as: > + + N > + --- > +x(n) = \ a(k)*x(n-k) > + / > + --- > + k=1 > +]]> > +The process is repeated independently for each channel. It is possible to extend > +the beginning of the signal by applying the same process backward in time. When > +extending the beginning of the signal, it is best to apply a "fade in" to the > +extrapolated signal, e.g. by multiplying it by a half-Hanning window. > + If this is going to be generally recommended, I wonder if we shouldn't provide a 'reference implementation' of it in libopus, and also make some reference to that here? In the following section, I wonder if we need to provide a few more specifics (and also possibly some API support in libopus), since this draft primarily is focussed on an encapsulation format, and many people implementing it will likely be using a separate encoder library, quite possibly without having, or otherwise needing, a very detailed knowledge of the Opus spec itself or the internals of the encoder they are using. The issues you raise here, while important, do kind of blur the lines between "encapsulating the output of an encoder" and "doing additional encoding above and beyond what the encoder you may be using does". And they aren't specific to the Ogg encapsulation, other mechanisms would surely get the same benefits from them too. > +
> + > +
> + > +In some applications, such as Internet radio, it is desirable to cut a long > +streams into smaller chains, e.g. so the comment header can be updated. > +This can be done simply by separating the input streams into segments and > +encoding each segment independenty. s/independenty/independently/ > +The ony drawback of this approach is that it creates a small discontinuity > +at the boundary due to the lossy nature of Opus. > +An encoder MAY avoid this discontinuity by using the following procedure: > + > +On the last frame of the first stream, encoding an independent frame by > +turning off all forms of inter-frame prediction (de-emphasis is allowed). How do people turn that off? > +setting the granulepos of the past page to a point near the end of the last > +frame. How do they determine where that point should be? > +Beginning the new stream with a copy of the last frame of the first > +stream. > +Setting the preskip flag of the second stream in such a way as to properly > +join the two streams. What such ways would ensure this is done properly? > +Continuing the encoding process normally from there, without any reset to > +the encoder. > + > + > +
The answers to these questions may be obvious to someone who has studied the Opus spec and the encoder that they are using in detail, but in the context of this draft I suspect we should probably offer slightly stronger guidance about how to get this right, if we are going to include these concerns here. Cheers, Ron From jmvalin@jmvalin.ca Sat Mar 30 18:20:46 2013 Return-Path: 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 97F6221F8640 for ; Sat, 30 Mar 2013 18:20:46 -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 E+uKsOb+ikCt for ; Sat, 30 Mar 2013 18:20:45 -0700 (PDT) Received: from smtp.mozilla.org (mx2.corp.phx1.mozilla.com [63.245.216.70]) by ietfa.amsl.com (Postfix) with ESMTP id 7B58821F8632 for ; Sat, 30 Mar 2013 18:20:45 -0700 (PDT) Received: from [192.168.1.15] (modemcable094.20-21-96.mc.videotron.ca [96.21.20.94]) (Authenticated sender: jvalin@mozilla.com) by mx2.mail.corp.phx1.mozilla.com (Postfix) with ESMTPSA id 7FB65F24D6; Sat, 30 Mar 2013 18:20:44 -0700 (PDT) Message-ID: <51578F6B.6010202@jmvalin.ca> Date: Sat, 30 Mar 2013 21:20:43 -0400 From: Jean-Marc Valin User-Agent: Mozilla/5.0 (X11; Linux i686 on x86_64; rv:17.0) Gecko/20130307 Thunderbird/17.0.4 MIME-Version: 1.0 To: Ron References: <20121119225213.13225.30835.idtracker@ietfa.amsl.com> <50AABA00.6030102@xiph.org> <515609F7.7090402@jmvalin.ca> <20130330072800.GU19099@audi.shelbyville.oz> In-Reply-To: <20130330072800.GU19099@audi.shelbyville.oz> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: codec@ietf.org Subject: Re: [codec] I-D Action: draft-ietf-codec-oggopus-00.txt X-BeenThere: codec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Codec WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 31 Mar 2013 01:20:46 -0000 Hi Ron, On 03/30/2013 03:28 AM, Ron wrote: >> +The process is repeated independently for each channel. It is possible to extend >> +the beginning of the signal by applying the same process backward in time. When >> +extending the beginning of the signal, it is best to apply a "fade in" to the >> +extrapolated signal, e.g. by multiplying it by a half-Hanning window. >> + > > If this is going to be generally recommended, I wonder if we shouldn't provide > a 'reference implementation' of it in libopus, and also make some reference to > that here? I'm not sure this really belongs in libopus -- maybe in libopusfile once it gets encoder support? > In the following section, I wonder if we need to provide a few more specifics > (and also possibly some API support in libopus), since this draft primarily > is focussed on an encapsulation format, and many people implementing it will > likely be using a separate encoder library, quite possibly without having, or > otherwise needing, a very detailed knowledge of the Opus spec itself or the > internals of the encoder they are using. I'd rather minimize references to the libopus API because it's not normative and it may be different many years from now. > The issues you raise here, while important, do kind of blur the lines between > "encapsulating the output of an encoder" and "doing additional encoding above > and beyond what the encoder you may be using does". And they aren't specific > to the Ogg encapsulation, other mechanisms would surely get the same benefits > from them too. It's not specific to Ogg, but it's still useful knowledge for someone generating an Ogg file. In theory, you should be able to create an encoder using just this draft and the Opus and Ogg RFCs. >> +The ony drawback of this approach is that it creates a small discontinuity >> +at the boundary due to the lossy nature of Opus. >> +An encoder MAY avoid this discontinuity by using the following procedure: >> + >> +On the last frame of the first stream, encoding an independent frame by >> +turning off all forms of inter-frame prediction (de-emphasis is allowed). > > How do people turn that off? That's actually something that needs to be cleanly exposed in the libopus API. The functionality is already there and you can probably get it to work by specifying 100% packet loss, but it needs to be a dedicated setting. >> +setting the granulepos of the past page to a point near the end of the last >> +frame. > > How do they determine where that point should be? I mean that any point near the end would work. Any thoughts on how to make this clearer? >> +Beginning the new stream with a copy of the last frame of the first >> +stream. >> +Setting the preskip flag of the second stream in such a way as to properly >> +join the two streams. > > What such ways would ensure this is done properly? Well, properly as in avoiding hole or duplicated samples, i.e. the preskip should be such that the first sample of the second stream is the one that follows the last sample of the first stream. Any suggestion on the wording? Cheers, Jean-Marc