From wwwrun@rfc-editor.org Mon Sep 10 17:18:29 2012 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 84AE321F8705; Mon, 10 Sep 2012 17:18:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.341 X-Spam-Level: X-Spam-Status: No, score=-101.341 tagged_above=-999 required=5 tests=[AWL=0.659, BAYES_00=-2.599, J_CHICKENPOX_93=0.6, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] 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 Eo+hK1TwHmPR; Mon, 10 Sep 2012 17:18:29 -0700 (PDT) Received: from rfc-editor.org (rfc-editor.org [IPv6:2001:1890:123a::1:2f]) by ietfa.amsl.com (Postfix) with ESMTP id 2023B21F8702; Mon, 10 Sep 2012 17:18:29 -0700 (PDT) Received: by rfc-editor.org (Postfix, from userid 30) id 196EEB1E006; Mon, 10 Sep 2012 17:15:25 -0700 (PDT) To: ietf-announce@ietf.org, rfc-dist@rfc-editor.org From: rfc-editor@rfc-editor.org Message-Id: <20120911001525.196EEB1E006@rfc-editor.org> Date: Mon, 10 Sep 2012 17:15:25 -0700 (PDT) Cc: codec@ietf.org, rfc-editor@rfc-editor.org Subject: [codec] RFC 6716 on Definition of the Opus Audio Codec 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, 11 Sep 2012 00:18:29 -0000 A new Request for Comments is now available in online RFC libraries. RFC 6716 Title: Definition of the Opus Audio Codec Author: JM. Valin, K. Vos, T. Terriberry Status: Standards Track Stream: IETF Date: September 2012 Mailbox: jmvalin@jmvalin.ca, koenvos74@gmail.com, tterriberry@mozilla.com Pages: 326 Characters: 977743 Updates/Obsoletes/SeeAlso: None I-D Tag: draft-ietf-codec-opus-16.txt URL: http://www.rfc-editor.org/rfc/rfc6716.txt This document defines the Opus interactive speech and audio codec. Opus is designed to handle a wide range of interactive audio applications, including Voice over IP, videoconferencing, in-game chat, and even live, distributed music performances. It scales from low bitrate narrowband speech at 6 kbit/s to very high quality stereo music at 510 kbit/s. Opus uses both Linear Prediction (LP) and the Modified Discrete Cosine Transform (MDCT) to achieve good compression of both speech and music. [STANDARDS-TRACK] This document is a product of the Internet Wideband Audio Codec Working Group of the IETF. This is now a Proposed Standard Protocol. STANDARDS TRACK: This document specifies an Internet standards track protocol for the Internet community,and requests discussion and suggestions for improvements. Please refer to the current edition of the Internet Official Protocol Standards (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited. This announcement is sent to the IETF-Announce and rfc-dist lists. To subscribe or unsubscribe, see http://www.ietf.org/mailman/listinfo/ietf-announce http://mailman.rfc-editor.org/mailman/listinfo/rfc-dist For searching the RFC series, see http://www.rfc-editor.org/rfcsearch.html. For downloading RFCs, see http://www.rfc-editor.org/rfc.html. Requests for special distribution should be addressed to either the author of the RFC in question, or to rfc-editor@rfc-editor.org. Unless specifically noted otherwise on the RFC itself, all RFCs are for unlimited distribution. The RFC Editor Team Association Management Solutions, LLC From hoene@uni-tuebingen.de Mon Sep 10 23:31:53 2012 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 7B00521F867B for ; Mon, 10 Sep 2012 23:31:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.649 X-Spam-Level: X-Spam-Status: No, score=-5.649 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_DE=0.35, J_CHICKENPOX_93=0.6, RCVD_IN_DNSWL_MED=-4] 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 9DOtNrS5Nhmu for ; Mon, 10 Sep 2012 23:31:52 -0700 (PDT) Received: from mx08.uni-tuebingen.de (mx08.uni-tuebingen.de [134.2.3.6]) by ietfa.amsl.com (Postfix) with ESMTP id 5068521F869F for ; Mon, 10 Sep 2012 23:31:50 -0700 (PDT) Received: from ChristianHoene (158.77.146.216.biz.sta.networkgci.net [216.146.77.158] (may be forged)) (authenticated bits=0) by mx08.uni-tuebingen.de (8.13.6/8.13.6) with ESMTP id q8B6VUXr026420 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO) for ; Tue, 11 Sep 2012 08:31:43 +0200 From: "Hoene" To: References: <20120911001525.196EEB1E006@rfc-editor.org> In-Reply-To: <20120911001525.196EEB1E006@rfc-editor.org> Date: Tue, 11 Sep 2012 08:31:30 +0200 Message-ID: <000701cd8fe7$1ca0ccd0$55e26670$@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: AQKlxqKf+Ls8rLi0cNcj7g68HL8kgJXUPrDw Content-Language: de X-AntiVirus-Spam-Check: clean (checked by Avira MailGate: version: 3.2.1.23; spam filter version: 3.2.0/2.3; host: mx08) X-AntiVirus: checked by Avira MailGate (version: 3.2.1.23; AVE: 8.2.5.34; VDF: 7.11.10.215; host: mx08); id=17487-LRwlv7 Subject: Re: [codec] RFC 6716 on Definition of the Opus Audio Codec 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, 11 Sep 2012 06:31:53 -0000 Congratulations! -----Urspr=FCngliche Nachricht----- Von: codec-bounces@ietf.org [mailto:codec-bounces@ietf.org] Im Auftrag = von rfc-editor@rfc-editor.org Gesendet: Dienstag, 11. September 2012 02:15 An: ietf-announce@ietf.org; rfc-dist@rfc-editor.org Cc: codec@ietf.org; rfc-editor@rfc-editor.org Betreff: [codec] RFC 6716 on Definition of the Opus Audio Codec A new Request for Comments is now available in online RFC libraries. =20 RFC 6716 Title: Definition of the Opus Audio Codec=20 Author: JM. Valin, K. Vos, T. Terriberry Status: Standards Track Stream: IETF Date: September 2012 Mailbox: jmvalin@jmvalin.ca,=20 koenvos74@gmail.com,=20 tterriberry@mozilla.com Pages: 326 Characters: 977743 Updates/Obsoletes/SeeAlso: None I-D Tag: draft-ietf-codec-opus-16.txt URL: http://www.rfc-editor.org/rfc/rfc6716.txt This document defines the Opus interactive speech and audio codec. Opus is designed to handle a wide range of interactive audio applications, including Voice over IP, videoconferencing, in-game chat, and even live, distributed music performances. It scales from low bitrate narrowband speech at 6 kbit/s to very high quality stereo music at 510 kbit/s. Opus uses both Linear Prediction (LP) and the Modified Discrete Cosine Transform (MDCT) to achieve good compression of both speech and music. [STANDARDS-TRACK] This document is a product of the Internet Wideband Audio Codec Working Group of the IETF. This is now a Proposed Standard Protocol. STANDARDS TRACK: This document specifies an Internet standards track protocol for the Internet community,and requests discussion and = suggestions for improvements. Please refer to the current edition of the Internet Official Protocol Standards (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited. This announcement is sent to the IETF-Announce and rfc-dist lists. To subscribe or unsubscribe, see http://www.ietf.org/mailman/listinfo/ietf-announce http://mailman.rfc-editor.org/mailman/listinfo/rfc-dist For searching the RFC series, see = http://www.rfc-editor.org/rfcsearch.html. For downloading RFCs, see http://www.rfc-editor.org/rfc.html. Requests for special distribution should be addressed to either the author of the RFC in question, or to rfc-editor@rfc-editor.org. Unless specifically noted otherwise on the RFC itself, all RFCs are for unlimited distribution. The RFC Editor Team Association Management Solutions, LLC _______________________________________________ codec mailing list codec@ietf.org https://www.ietf.org/mailman/listinfo/codec From rjsparks@nostrum.com Mon Sep 17 07:33:15 2012 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 DE08221F8557 for ; Mon, 17 Sep 2012 07:33:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.6 X-Spam-Level: X-Spam-Status: No, score=-102.6 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, SPF_PASS=-0.001, USER_IN_WHITELIST=-100] 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 6WOxXTZomPl6 for ; Mon, 17 Sep 2012 07:33:15 -0700 (PDT) Received: from nostrum.com (nostrum-pt.tunnel.tserv2.fmt.ipv6.he.net [IPv6:2001:470:1f03:267::2]) by ietfa.amsl.com (Postfix) with ESMTP id 77B0F21F8534 for ; Mon, 17 Sep 2012 07:33:15 -0700 (PDT) Received: from unnumerable.local ([4.30.77.1]) (authenticated bits=0) by nostrum.com (8.14.3/8.14.3) with ESMTP id q8HEXE0e029087 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO) for ; Mon, 17 Sep 2012 09:33:14 -0500 (CDT) (envelope-from rjsparks@nostrum.com) Message-ID: <505734AB.7000106@nostrum.com> Date: Mon, 17 Sep 2012 09:33:15 -0500 From: Robert Sparks User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:15.0) Gecko/20120907 Thunderbird/15.0.1 MIME-Version: 1.0 To: codec@ietf.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Received-SPF: pass (nostrum.com: 4.30.77.1 is authenticated by a trusted mechanism) Subject: [codec] Adding Tim Terriberry as a CODEC cochair 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: Mon, 17 Sep 2012 14:33:16 -0000 All - We've asked Tim to take on the co-chair role for CODEC to help lead the group through completing its charter. Please join me in thanking him for agreeing to serve. Jonathan and Cullen are both continuing as co-chairs. RjS From hoene@uni-tuebingen.de Tue Sep 18 23:53:30 2012 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 E45FA21F855F for ; Tue, 18 Sep 2012 23:53:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -8.249 X-Spam-Level: X-Spam-Status: No, score=-8.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, GB_I_LETTER=-2, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_MED=-4] 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 g+4Ir7DAiTXk for ; Tue, 18 Sep 2012 23:53:30 -0700 (PDT) Received: from mx08.uni-tuebingen.de (mx08.uni-tuebingen.de [134.2.3.6]) by ietfa.amsl.com (Postfix) with ESMTP id BAEF621F8557 for ; Tue, 18 Sep 2012 23:53:29 -0700 (PDT) Received: from ChristianHoene (ext-42-227.eduroam.rwth-aachen.de [134.61.42.227]) (authenticated bits=0) by mx08.uni-tuebingen.de (8.13.6/8.13.6) with ESMTP id q8J6r9Ci001046 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Wed, 19 Sep 2012 08:53:17 +0200 From: "Hoene" To: "'Robert Sparks'" , Date: Wed, 19 Sep 2012 08:53:13 +0200 Message-ID: <001a01cd9633$7580b480$60821d80$@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: Ac2WLhtaGO09QnvCQZOaXnsCmtoO7w== Content-Language: de X-AntiVirus-Spam-Check: clean (checked by Avira MailGate: version: 3.2.1.23; spam filter version: 3.2.0/2.3; host: mx08) X-AntiVirus: checked by Avira MailGate (version: 3.2.1.23; AVE: 8.2.5.34; VDF: 7.11.10.215; host: mx08); id=27108-kZdgvg Subject: [codec] Opus characterisation tests. 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: Wed, 19 Sep 2012 06:53:31 -0000 Welcome Tim! The next steps in this WG are on making neutral characterisation tests = of the final Opus. We (Universit=E4t T=FCbingen) plan to conduct MUSHRA tests in October. = Please send me your wishes on what aspect you would like to see tested, e.g. = packet losses? Also, the question of complexity has not been studied well. I would like = to make some relative complexity comparison, e.g. Opus vs. AMR-WB on a i386 system using some profiling tools.=20 I would be also happy to see a contest between the new upcoming 3G codec EVC(?) and Opus but the 3G codec is not yet finished, isn't it? The next meeting of ITU-T study group 16 is going to be in January 2013. Till then, the draft on the quality of Opus shall be finished in order = to be able to write a letter to them. Any other thoughts and wishes? Comments are especially appreciated from = all the expert who are skeptical about Opus. Thanks Christian -----Urspr=FCngliche Nachricht----- Von: codec-bounces@ietf.org [mailto:codec-bounces@ietf.org] Im Auftrag = von Robert Sparks Gesendet: Montag, 17. September 2012 16:33 An: codec@ietf.org Betreff: [codec] Adding Tim Terriberry as a CODEC cochair All - We've asked Tim to take on the co-chair role for CODEC to help lead the group through completing its charter. Please join me in thanking him for agreeing to serve. Jonathan and Cullen are both continuing as co-chairs. RjS _______________________________________________ codec mailing list codec@ietf.org https://www.ietf.org/mailman/listinfo/codec From jmvalin@jmvalin.ca Mon Sep 24 10:33:21 2012 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 B77E521F8805 for ; Mon, 24 Sep 2012 10:33:21 -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 BLJExWT4-1eN for ; Mon, 24 Sep 2012 10:33:21 -0700 (PDT) Received: from relais.videotron.ca (relais.videotron.ca [24.201.245.36]) by ietfa.amsl.com (Postfix) with ESMTP id 298B621F87F3 for ; Mon, 24 Sep 2012 10:33:20 -0700 (PDT) MIME-version: 1.0 Content-type: multipart/mixed; boundary="Boundary_(ID_AQAdkOTiEhuoHvsSOj44Ww)" Received: from [192.168.1.14] ([96.21.20.94]) by VL-VM-MR003.ip.videotron.ca (Oracle Communications Messaging Exchange Server 7u4-22.01 64bit (built Apr 21 2011)) with ESMTP id <0MAV0061M7F8PPC0@VL-VM-MR003.ip.videotron.ca> for codec@ietf.org; Mon, 24 Sep 2012 13:33:08 -0400 (EDT) Message-id: <50609935.3080900@jmvalin.ca> Date: Mon, 24 Sep 2012 13:32:37 -0400 From: Jean-Marc Valin User-Agent: Mozilla/5.0 (X11; Linux i686 on x86_64; rv:15.0) Gecko/20120907 Thunderbird/15.0.1 To: "codec@ietf.org" X-Enigmail-Version: 1.4.4 Subject: [codec] Suggestions for OggOpus draft 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: Mon, 24 Sep 2012 17:33:21 -0000 This is a multi-part message in MIME format. --Boundary_(ID_AQAdkOTiEhuoHvsSOj44Ww) Content-type: text/plain; CHARSET=US-ASCII Content-transfer-encoding: 7BIT Hi, I suggest adding these two sections to the OggOpus draft, one that describes how to handle chaining and one that has recommendations for encoders. I'm sure there's still more things an encoder can do that I haven't listed. Jean-Marc --Boundary_(ID_AQAdkOTiEhuoHvsSOj44Ww) Content-type: text/x-diff; CHARSET=US-ASCII; name=oggopus_changes.patch Content-transfer-encoding: 7BIT Content-disposition: attachment; filename=oggopus_changes.patch diff --git a/doc/draft-terriberry-oggopus.xml b/doc/draft-terriberry-oggopus.xml index 14f962a..6abe788 100644 --- a/doc/draft-terriberry-oggopus.xml +++ b/doc/draft-terriberry-oggopus.xml @@ -951,6 +951,47 @@ An implementation could reasonably choose any of these numbers for its internal +
+ +Like all Ogg streams, Opus streams can be "chained", i.e. contatenated +together. Although it is possible to simply decode the streams +independently and concatenate the resulting audio, this results in a +discontinuity in the audio, which may be audible. Such discontinuity can be +avoided by obtaining more audio from the stream before the boundary, and +"cross-fading" that audio with the new stream. The extra audio can be +obtained in two ways: + +If there are sufficient usable "trimmed" samples past the end of the audio and those trimmed +samples represent the actual audio past the end of the file, then these samples +can be used. These trimmed samples may come from the a +If trimmed samples cannot be used, use linear prediction on the end of the first +stream to predict about 2.5 ms of audio at the beginning of the second stream. + + +Opus streams do not explicitly contain sufficient information to tell case 1 +from case 2. One way of deciding whether to use the trimmed samples or +extrapolated samples is to evaluate the mean squared error between the trimmed +samples and the first samples of the second stream. This error can be compared +either to a fixed percentage of the signal's mean square, or to the mean squared +error between the extrapolated signal and the beginning of the second stream. + +
+ +
+ +This section makes a few recommendations for encoders to produce optimal Ogg +Opus files. To make gapless files possible, it is RECOMMENDED that encoders +use linear extrapolation for a duration of at least 2.5 ms at the beginning +of the file (which can be trimmed using the preskip field). For the end of the +file, the RECOMMENDED extrapolation duration is at +least equal to the encoder's look-ahead at the end of the file (7 ms for the +reference encoder), plus 2.5 ms to facilitate chaining. +To make the extrapolated samples at the end usable to all decoders, it is +RECOMMENDED that these samples be part of the same packet as the last +non-trimmed samples (possibly by merging multiple frames in a single packet). + +
+
Implementations of the Opus codec need to take appropriate security --Boundary_(ID_AQAdkOTiEhuoHvsSOj44Ww)-- From giles@thaumas.net Mon Sep 24 11:03:05 2012 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 E7CCD21F880D for ; Mon, 24 Sep 2012 11:03:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] 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 O2ZNnv6yvXcS for ; Mon, 24 Sep 2012 11:03:05 -0700 (PDT) Received: from mail-da0-f44.google.com (mail-da0-f44.google.com [209.85.210.44]) by ietfa.amsl.com (Postfix) with ESMTP id 738F921F8803 for ; Mon, 24 Sep 2012 11:03:05 -0700 (PDT) Received: by danh15 with SMTP id h15so196692dan.31 for ; Mon, 24 Sep 2012 11:03:05 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding :x-gm-message-state; bh=uYASA5a9DubfdMdigBlKOnEe8/YBxkwEBvtHnfx6UoI=; b=VLOqnBD6XVx3Hqj1Hfm/ZMEDelmzD1knIg8iC6vRl09hd4G7g204kS8Q0kLcWtvrsD A70GrmjRZKs8S7PlV9LE9FaOg45+a/7CIp+RnBXW8qdJdG2P9guJvL/KDbxOmz5PX/wU ZY43DHwrli8WSPvUocv3QPBI1yDjp1gcR7Nizej4YadvJBElsLMUGb2fW/1WiCRI7Ngs nn09br7CuVU1aVORZBsVc5cyEf7Y3dFMDJxXkU7v7g50Us5UBYUc03fU7A5zk29hbbTn 2upQgRb7Tinum6d4uzNDbjCdiYMVexZa+3/VzvJ2rz8kC+6dCmIC6OiYftlDoUOtRBdD Pl7A== Received: by 10.68.197.194 with SMTP id iw2mr38785594pbc.121.1348509785178; Mon, 24 Sep 2012 11:03:05 -0700 (PDT) Received: from Glaucomys.local (static-68-179-67-73.ptr.terago.net. [68.179.67.73]) by mx.google.com with ESMTPS id pj10sm9959629pbb.46.2012.09.24.11.03.03 (version=SSLv3 cipher=OTHER); Mon, 24 Sep 2012 11:03:04 -0700 (PDT) Message-ID: <5060A056.4000307@thaumas.net> Date: Mon, 24 Sep 2012 11:03:02 -0700 From: Ralph Giles User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:15.0) Gecko/20120907 Thunderbird/15.0.1 MIME-Version: 1.0 To: Jean-Marc Valin References: <50609935.3080900@jmvalin.ca> In-Reply-To: <50609935.3080900@jmvalin.ca> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Gm-Message-State: ALoCoQnZct1PVRXloKQE/GjArdA22ehLdKyU3+y9B3vlE/9SIP6toGQe+EdoBNKCzV74wcvHuduS Cc: "codec@ietf.org" Subject: Re: [codec] Suggestions for OggOpus draft 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: Mon, 24 Sep 2012 18:03:06 -0000 On 12-09-24 10:32 AM, Jean-Marc Valin wrote: > I suggest adding these two sections to the OggOpus draft, one that > describes how to handle chaining and one that has recommendations for > encoders. I'm sure there's still more things an encoder can do that I > haven't listed. Thanks for writing this up. A couple of questions: By 'linear prediction' do you mean the LPC-based lapping the opusenc utility already uses on the final packet? Is having the encoder supply predicted audio only to help decoders which don't do a cross-fade, or does it also help preserve fidelity across the boundary even in the case that the decoder does something to mitigate the discontinuity? I guess the issue is that if the encoder is processing a section of a larger stream, with the intention that the output will generally be concatenated, like tracks within an album with continuous audio, it should pad with the actual earlier and later samples. Prediction should therefore be used to smooth the transition only if adjacent audio isn't available? Or does that decision depend on the quality of the adjacent audio. E.g. a large transient would disturb the transition when the next segment *isn't* the expected one, in shuffle play or a custom playlist, for example? These don't seem like they're practices decoders can rely on, so they need to handle dicontinuities regardless. I think it is useful to give some suggestions in the draft, though if we can reduce the emphasis a bit. -r From gmaxwell@juniper.net Mon Sep 24 11:36:42 2012 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 1788D21F886C for ; Mon, 24 Sep 2012 11:36:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] 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 ESNw7h0R--3Y for ; Mon, 24 Sep 2012 11:36:41 -0700 (PDT) Received: from exprod7og112.obsmtp.com (exprod7og112.obsmtp.com [64.18.2.177]) by ietfa.amsl.com (Postfix) with ESMTP id 5C84421F8869 for ; Mon, 24 Sep 2012 11:36:41 -0700 (PDT) Received: from P-EMHUB01-HQ.jnpr.net ([66.129.224.36]) (using TLSv1) by exprod7ob112.postini.com ([64.18.6.12]) with SMTP ID DSNKUGCoN+I/Jb7YM8n+xyhag24rGrc51wzu@postini.com; Mon, 24 Sep 2012 11:36:41 PDT Received: from EMBX01-HQ.jnpr.net ([fe80::c821:7c81:f21f:8bc7]) by P-EMHUB01-HQ.jnpr.net ([fe80::fc92:eb1:759:2c72%11]) with mapi; Mon, 24 Sep 2012 11:33:42 -0700 From: Gregory Maxwell To: Jean-Marc Valin , "codec@ietf.org" Date: Mon, 24 Sep 2012 11:33:42 -0700 Thread-Topic: [codec] Suggestions for OggOpus draft Thread-Index: Ac2aerNx4FYH+XhsTZmdxAV2SuPSAAABLbRq Message-ID: References: <50609935.3080900@jmvalin.ca> In-Reply-To: <50609935.3080900@jmvalin.ca> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [codec] Suggestions for OggOpus draft 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: Mon, 24 Sep 2012 18:36:42 -0000 Jean-Marc Valin [jmvalin@jmvalin.ca]: > I suggest adding these two sections to the OggOpus draft, one that > describes how to handle chaining and one that has recommendations for > encoders. I'm sure there's still more things an encoder can do that I > haven't listed. The recommendations here are quite complex in terms of container handling =97 complex enough that alone their implementation would be comparable to a whole implementation of a basic encoder / decoder (not including the codec itself). This complexity is hidden by the fact that it uses DSP terminology like 'LPC' in place of what would be a dozen step procedure. It also doesn't address the multitude of corner cases that can arise: like what should an encoder do if the minimum 2.5ms padding requirement means two frames must be trimmed, so they need to be repacketized, but they have different toc's and so can't be repacketized. I expect many implementations would end up outputting two packets that need to be trimmed= , which may break some decoders. Opus-tools's encoder does LPC extrapolation for end-padding, it doesn't bot= her with the beginning because doing it at the beginning added latency and was somewhat messy and I wasn't able to find any originally gapless streams tha= t weren't gapless without it (which surprised me).=20 Since even with only a half-padding encoder and no decoder splice handling= =20 I was unable to find any gaplesness issues for originally gappless audio, I= =20 suspect the decoder part of this advice is just not needed. It's also unli= kely to be implemented: it's complicated, requires DSP coding (admittedly modest= ) which will take some implementers out of their comfort zone, and can be quite difficult to implement in some architectures (e.g. if separate links = in a chain are decoded independently=97 as is common in existing mediaframe works). Recommending encoder extrapolation to prevent pre/post leakage of the discontinuity to silence seems prudent to me. But I think the decoder advice is unlikely to be followed especially if written as a recommendation= . If it turns out to actually be important it should probably be a requiremen= t not a recommendation. If it's not important then I think it should be omitt= ed because reduced implementation behavior diversity is more important than theoretical improvements. Chain itself is not widely supported by implementations of Vorbis. Only bas= ic audio only tools commonly support it. I fear adding a bunch of complexity = to handle them the recommended way will further encourage implementations which opt not to work with chaining at all. (My opinion would be revised with examples which aren't gapless without it, or by the existence patches for gstreamer / vlc / and or Firefox, all of=20 which will, I think, have problems implementing these recommendations.)