From internet-drafts@ietf.org Fri May 17 05:03:07 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 7A69721F937B; Fri, 17 May 2013 05:03:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.512 X-Spam-Level: X-Spam-Status: No, score=-102.512 tagged_above=-999 required=5 tests=[AWL=0.089, BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] 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 s8cpJqUyDZg5; Fri, 17 May 2013 05:03:04 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id E844621F91BF; Fri, 17 May 2013 05:02:47 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 4.45 Message-ID: <20130517120247.29103.5210.idtracker@ietfa.amsl.com> Date: Fri, 17 May 2013 05:02:47 -0700 Cc: codec@ietf.org Subject: [codec] I-D Action: draft-ietf-codec-results-03.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, 17 May 2013 12:03:07 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Internet Wideband Audio Codec Working Gro= up of the IETF. Title : Summary of Opus listening test results Author(s) : Christian Hoene Jean-Marc Valin Koen Vos Jan Skoglund Filename : draft-ietf-codec-results-03.txt Pages : 23 Date : 2013-05-17 Abstract: This document describes and examines listening test results obtained for the Opus codec and how they relate to the requirements. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-codec-results There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-codec-results-03 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-codec-results-03 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From internet-drafts@ietf.org Fri May 24 03:31:12 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 4BD0C21F8CF4; Fri, 24 May 2013 03:31:12 -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, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] 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 xEX9maqGYFug; Fri, 24 May 2013 03:31:11 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id C0EF121F8746; Fri, 24 May 2013 03:31:11 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 4.50 Message-ID: <20130524103111.28366.57802.idtracker@ietfa.amsl.com> Date: Fri, 24 May 2013 03:31:11 -0700 Cc: codec@ietf.org Subject: [codec] I-D Action: draft-ietf-codec-oggopus-01.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, 24 May 2013 10:31:12 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Internet Wideband Audio Codec Working Gro= up of the IETF. Title : Ogg Encapsulation for the Opus Audio Codec Author(s) : Timothy B. Terriberry Ron Lee Ralph Giles Filename : draft-ietf-codec-oggopus-01.txt Pages : 24 Date : 2013-05-24 Abstract: This document defines the Ogg encapsulation for the Opus interactive speech and audio codec. This allows data encoded in the Opus format to be stored in an Ogg logical bitstream. Ogg encapsulation provides Opus with a long-term storage format supporting all of the essential features, including metadata, fast and accurate seeking, corruption detection, recapture after errors, low overhead, and the ability to multiplex Opus with other codecs (including video) with minimal buffering. It also provides a live streamable format, capable of delivery over a reliable stream-oriented transport, without requiring all the data, or even the total length of the data, up-front, in a form that is identical to the on-disk storage format. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-codec-oggopus There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-codec-oggopus-01 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-codec-oggopus-01 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From giles@thaumas.net Fri May 24 08:45:35 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 E811B21F9413 for ; Fri, 24 May 2013 08:45:35 -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 rmiy5St7q27g for ; Fri, 24 May 2013 08:45:31 -0700 (PDT) Received: from mail-pb0-x229.google.com (mail-pb0-x229.google.com [IPv6:2607:f8b0:400e:c01::229]) by ietfa.amsl.com (Postfix) with ESMTP id D79BC21F940B for ; Fri, 24 May 2013 08:45:31 -0700 (PDT) Received: by mail-pb0-f41.google.com with SMTP id xb12so4405792pbc.28 for ; Fri, 24 May 2013 08:45:31 -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:subject:references :in-reply-to:x-forwarded-message-id:content-type :content-transfer-encoding:x-gm-message-state; bh=RNnmlk9iZIl2RgcERS8Kcy7HPnPe8ZIMqd2RX7epOT8=; b=C533vce+LW7EHNOQvELTu5JulvLJntD4cWlnUnnrwW80XwwO4fdehi75n3cKzNiS9t Qd0qr8/Pr/n5tg9q9n3KXGGFvFKZ/ukT1C25sFACZi3Fr92BUaHdpinlPtvv/2t2RjM3 FKMXyTPZ8WXEf3MbbKUxVqDl3T2dxWujkECaFgua3cZOMNsu9eBnoyZbXtya2gSKxUuS OgWALhA3f/Uno5qxi6il1wyTZ/DFZ9tFlyYCEOdlMoY98zFQil7kQ/XlqmEW+YekQMO4 EX3f82cTDLEZUdqTDK7vEy24XkrUibXeURBJwkW+x8+m+zYTSEyQ51LnylBE6urCQjZH BHbQ== X-Received: by 10.66.51.165 with SMTP id l5mr12248287pao.73.1369410331365; Fri, 24 May 2013 08:45:31 -0700 (PDT) Received: from Glaucomys.local ([203.69.99.17]) by mx.google.com with ESMTPSA id ea15sm17911219pad.16.2013.05.24.08.45.29 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Fri, 24 May 2013 08:45:30 -0700 (PDT) Message-ID: <519F8B18.9020101@thaumas.net> Date: Fri, 24 May 2013 23:45:28 +0800 From: Ralph Giles User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:17.0) Gecko/20130509 Thunderbird/17.0.6 MIME-Version: 1.0 To: "codec@ietf.org" References: <519F8A40.3080105@mozilla.com> In-Reply-To: <519F8A40.3080105@mozilla.com> X-Forwarded-Message-Id: <519F8A40.3080105@mozilla.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Gm-Message-State: ALoCoQkOhlAShJhUClBtVd6wO4Q8akuueN6M+I5zF1jfRYmPprHgFzVhDpXpn1U+6Fv+7IBJ4jQn Subject: [codec] draft-ietf-codec-oggopus-01 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, 24 May 2013 15:45:36 -0000 I've updated the Ogg Opus encapsulation draft. https://tools.ietf.org/html/draft-ietf-codec-oggopus-01 Changes since the -00 version: - Surround speaker labels for channel mapping family 1 are described directly in the draft. They still match those used by the Vorbis codec, but it's better to have them explicit. - The surround section now documents the stereo downmix matrices we're using in opus-tools and Firefox, as an aid to consistent implementation. - An Implementation Status section has been added, with a link to https://wiki.xiph.org/OggOpusImplementation. Assistance updating and expanding this wiki page is welcome. - The Content Type section now makes clear that the '.opus' filename extention maps to 'audio/ogg', and that any use of this spec for video or other file types using Ogg encapsulation is separate from that. - Several small formatting changes and wording improvements. This version does not include Jean-Marc's suggested encoder guidelines for stream splicing, but we expect to incorporate them after further discussion. -r From tterribe@xiph.org Fri May 24 10:05:18 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 18C6821F92EB for ; Fri, 24 May 2013 10:05:18 -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 QeZoTgKyCNdO for ; Fri, 24 May 2013 10:05:00 -0700 (PDT) Received: from smtp.mozilla.org (mx1.corp.phx1.mozilla.com [63.245.216.69]) by ietfa.amsl.com (Postfix) with ESMTP id 3544621F8B15 for ; Fri, 24 May 2013 10:04:53 -0700 (PDT) Received: from [10.250.6.54] (unknown [63.245.220.240]) (Authenticated sender: tterriberry@mozilla.com) by mx1.mail.corp.phx1.mozilla.com (Postfix) with ESMTPSA id 7BE9CF25D7 for ; Fri, 24 May 2013 10:04:52 -0700 (PDT) Message-ID: <519F9DB4.8000809@xiph.org> Date: Fri, 24 May 2013 10:04:52 -0700 From: "Timothy B. Terriberry" User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:19.0) Gecko/20100101 SeaMonkey/2.16.2 MIME-Version: 1.0 To: "codec@ietf.org" References: <519F8A40.3080105@mozilla.com> <519F8B18.9020101@thaumas.net> In-Reply-To: <519F8B18.9020101@thaumas.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [codec] draft-ietf-codec-oggopus-01 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, 24 May 2013 17:05:18 -0000 Ralph Giles wrote: > This version does not include Jean-Marc's suggested encoder guidelines > for stream splicing, but we expect to incorporate them after further > discussion. Yes, apologies for taking so long to get to reviewing them. I'll reply to the other thread. From tterribe@xiph.org Fri May 24 10:11:17 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 4E1E621F9617 for ; Fri, 24 May 2013 10:11:17 -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 A0+03vktxNgx for ; Fri, 24 May 2013 10:11:11 -0700 (PDT) Received: from smtp.mozilla.org (mx2.corp.phx1.mozilla.com [63.245.216.70]) by ietfa.amsl.com (Postfix) with ESMTP id 8187321F9497 for ; Fri, 24 May 2013 10:11:11 -0700 (PDT) Received: from [10.250.6.54] (unknown [63.245.220.240]) (Authenticated sender: tterriberry@mozilla.com) by mx2.mail.corp.phx1.mozilla.com (Postfix) with ESMTPSA id BC1A7F25E8 for ; Fri, 24 May 2013 10:11:10 -0700 (PDT) Message-ID: <519F9F2E.8060001@xiph.org> Date: Fri, 24 May 2013 10:11:10 -0700 From: "Timothy B. Terriberry" User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:19.0) Gecko/20100101 SeaMonkey/2.16.2 MIME-Version: 1.0 To: codec@ietf.org References: <20121119225213.13225.30835.idtracker@ietfa.amsl.com> <50AABA00.6030102@xiph.org> <515609F7.7090402@jmvalin.ca> In-Reply-To: <515609F7.7090402@jmvalin.ca> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit 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, 24 May 2013 17:11:17 -0000 Jean-Marc Valin wrote: > 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. (as an individual contributor) I like this much better than your earlier proposal that required special handling in the decoder, since it doesn't require any changes to already-deployed decoders, and keeps the decoding process (relatively) simple. A few minor points: - The start of the Encoder Guidelines section should forward-reference the LPC Extrapolation section. - Need a reference on how to actually compute the linear prediction coefficients. We have references to both the Burg method and the Schur algorithm in RFC 6716, and source code in libvorbis. Some implementation guidance wouldn't be amiss. - The language in general needs a little word-smithing. We can coordinate on that in git. From tterribe@xiph.org Fri May 24 10:19:43 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 B5ECA21F9635 for ; Fri, 24 May 2013 10:19:43 -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 Lscbzf9tOZqy for ; Fri, 24 May 2013 10:19:20 -0700 (PDT) Received: from smtp.mozilla.org (mx2.corp.phx1.mozilla.com [63.245.216.70]) by ietfa.amsl.com (Postfix) with ESMTP id E270221F96A4 for ; Fri, 24 May 2013 10:19:16 -0700 (PDT) Received: from [10.250.6.54] (unknown [63.245.220.240]) (Authenticated sender: tterriberry@mozilla.com) by mx2.mail.corp.phx1.mozilla.com (Postfix) with ESMTPSA id 93742F210D for ; Fri, 24 May 2013 10:19:16 -0700 (PDT) Message-ID: <519FA114.9050002@xiph.org> Date: Fri, 24 May 2013 10:19:16 -0700 From: "Timothy B. Terriberry" User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:19.0) Gecko/20100101 SeaMonkey/2.16.2 MIME-Version: 1.0 To: codec@ietf.org References: <20121119225213.13225.30835.idtracker@ietfa.amsl.com> <50AABA00.6030102@xiph.org> <515609F7.7090402@jmvalin.ca> <20130330072800.GU19099@audi.shelbyville.oz> <51578F6B.6010202@jmvalin.ca> In-Reply-To: <51578F6B.6010202@jmvalin.ca> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit 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, 24 May 2013 17:19:44 -0000 Jean-Marc Valin wrote: >>> +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. Well, I still think you need to explicitly list the SILK and CELT features that should be disabled (since, as you say, you don't want to refer to the libopus API), not just one feature that you shouldn't disable. >>> +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? I think you need to say more than this. In some contexts you may not be able to choose how many samples are in the file (encoding a CD with no inter-track gaps, but where you wish to preserve sample-accurate track boundaries, for example). That means you may need to do some frame size juggling to ensure the end of the track lies at "a point near the end of the last frame". How near is enough? The last half? The last quarter? In what size frame? Someone without intimate DSP knowledge and knowledge of the Opus format is not going to be able to make informed decisions here, so we should provide some guidance. From oej@edvina.net Thu May 30 00:14:20 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 0B6A621F974F for ; Thu, 30 May 2013 00:14:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.001 X-Spam-Level: X-Spam-Status: No, score=0.001 tagged_above=-999 required=5 tests=[BAYES_50=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 bM2B65H12m+V for ; Thu, 30 May 2013 00:14:15 -0700 (PDT) Received: from smtp7.webway.se (smtp7.webway.se [IPv6:2a02:920:212e::205]) by ietfa.amsl.com (Postfix) with ESMTP id 4843F21F9758 for ; Thu, 30 May 2013 00:14:12 -0700 (PDT) Received: from [192.168.40.5] (h87-96-134-129.dynamic.se.alltele.net [87.96.134.129]) by smtp7.webway.se (Postfix) with ESMTPA id 8476F93C2A1; Thu, 30 May 2013 07:14:10 +0000 (UTC) Content-Type: text/plain; charset=iso-8859-1 Mime-Version: 1.0 (Mac OS X Mail 6.3 \(1503\)) From: "Olle E. Johansson" Date: Thu, 30 May 2013 09:14:10 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <8E24D629-1D4C-431A-B466-4DD5F0273F9A@edvina.net> References: <51A64F3E.5040002@digium.com> To: codec@ietf.org X-Mailer: Apple Mail (2.1503) Subject: [codec] Fwd: [asterisk-dev] Opus and VP8 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: Thu, 30 May 2013 07:14:20 -0000 Please comment on this statement about Opus from Matt Jordan, the=20 project leader for the Asterisk project. Regards, /Olle Vidarebefordrat brev: > Fr=E5n: Matthew Jordan > =C4mne: Re: [asterisk-dev] Opus and VP8 > Datum: 29 maj 2013 20:55:58 CEST > Till: asterisk-dev@lists.digium.com > Svara till: Asterisk Developers Mailing List = >=20 > On 05/25/2013 05:19 AM, Hans Witvliet wrote: >> -----Original Message----- >> From: Olle E. Johansson >> Reply-to: Asterisk Developers Mailing List >> >> To: Asterisk Developers Mailing List >> Cc: Olle E. Johansson >> Subject: Re: [asterisk-dev] Opus and VP8 >> Date: Fri, 24 May 2013 13:26:29 +0200 >>=20 >>=20 >> 24 maj 2013 kl. 12:51 skrev Lorenzo Miniero : >>=20 >>> PS: a few months ago I also talked, on the #asterisk-dev IRC, about >>> the support I added for both Opus (transcoding) and VP8 = (passthrough) >>> in Asterisk, codecs that are currently the default ones used in >>> WebRTC. I checked whether there was an interest in a patch for them, >>> but at the time there were some concerns about the copyright status = of >>> Opus that prevented it to be considered for integration in Asterisk. >>> Has this situation changed in the meanwhile? I can open a separate >>> thread for this if needed. >>>=20 >> Lorenzo, >>=20 >>=20 >> Good seeing you here! >>=20 >>=20 >> Due to legal issues I don't think Digium can accept a contribution of >> Opus and VP8 in the svn repositories today. >>=20 >>=20 >> I would encourage you, if you have these patches, to publish them on = a >> web site like github or sourceforge so w all can help you test it. I >> really would like for these to be available for the community in an = easy >> form. >>=20 >=20 > >=20 > Hello! I'm going to comment here specifically to clarify Digium's > position on Opus and VP8 as codecs and their inclusion in Asterisk. >=20 > To start, pass through support in the form of a format module is fine > for both Opus and VP8. It involves no transcoding and hence cannot > violate any claims against their technology. We'd be happy to see = format > modules in Asterisk. >=20 > VP8 is the easier of the two to clarify. A codec for VP8 is probably = not > appropriate, regardless of any patent or IPR issues. Asterisk doesn't > perform video transcoding. Video transcoding is an intensive operation > that performs poorly without hardware augmentation. We've always taken > the stance that software video transcoding in Asterisk would cause = more > problems then it would solve; as such, VP8 as a codec is best left > outside of Asterisk. >=20 > The real question is: what about Opus? >=20 > Before that, a word about the American patent system. >=20 > The American patent system has devolved into what can only be = charitably > described as mafia-inspired extortion. Non-practicing entities (NPEs) > are groups of lawyers who have not and never will produce, market, or > sell a product. The only actions they perform are filing infringement > claims against businesses and individuals, regardless of whether or = not > that business or individual actually violates a patent, with the sole > purpose of extracting as much money out of said business or individual > as they can. The cost of fighting these claims is enormous. The cost = of > losing a fight against even one of these claims is crippling. The NPEs > know this. Technical merit, logic, rationale, or any kind of morality > has no applicability here: these folks exist solely to find new and = more > creative ways to make claims against you and take your money. >=20 > They'd be happy to put you out of business in the process. >=20 > Back to Opus. >=20 > There are several IPRs filed against Opus with the unfortunate = licensing > declaration of "Reasonable and Non-Discriminatory License to All > Implementers with Possible Royalty/Fee." These IPRs have not been > clarified, and the entities making these claims have not moved one way > or the other regarding their claims. If any one of these entities > decides to play the NPE game (see: Alcatel-Lucent), they could crush > Digium like a bug. They could go after every user, integrator, and > developer of Asterisk as well. It has the potential of spelling the = end > of the Asterisk project. The risk of this unfortunately does not = justify > the inclusion of Opus as a codec in Asterisk. >=20 > Question: I am a user, integrator, and developer of Asterisk that does > not work for Digium. Since Digium holds the copyright of Asterisk, how > am I at risk? >=20 > Answer: I have no idea. I do know that logic and reasoning does not > apply where patents are concerned. Caveat emptor. >=20 > Question: Asterisk is an open source project. Doesn't that protect me > somehow? >=20 > Answer: No. The GPLv2 specifically states "that any patent must be > licensed for everyone's free use or not licensed at all". There are > additional sections that further explain how patents affect software > licensed under GPLv2; suffice to say that the sections exist to = protect > the freedom of the software; not to protect you from patent trolls. >=20 > Question: If all of this is true, why does Google, Mozilla, Xiph.org, > and others implement Opus? >=20 > Answer: They either have an army of lawyers, are willing to roll the > dice on their future, or are ignorant of how the patent system works. >=20 > Question: This is messed up. If all of this is true, how can we ever > innovate in areas where patents have ever been filed? >=20 > Answer: You can't. The system is broken. >=20 > Question: What can I do about it? >=20 > Answer: Contact your government officials. Complain. The only way this > situation will get fixed is if the laws are changed. Note that there = is > at least one bill being brought up in the U.S. Senate to address these > exact deficiencies in the American patent system (and possibly more in > the House); if you are a U.S. citizen I highly recommend you contact > your elected Senators/Representatives and express your opinion(s). >=20 > I hope this helps everyone understand why we've made our decision. We > all hope that this situation changes in the near future, but until = then, > we'll have to limit our support of these codecs in Asterisk to > pass-through only. >=20 > Thanks >=20 > Matt >=20 > --=20 > Matthew Jordan > Digium, Inc. | Engineering Manager > 445 Jan Davis Drive NW - Huntsville, AL 35806 - USA > Check us out at: http://digium.com & http://asterisk.org >=20