Re: [codec] Next Steps for WG
Koen Vos <koen.vos@skype.net> Fri, 14 January 2011 21:38 UTC
Return-Path: <koen.vos@skype.net>
X-Original-To: codec@core3.amsl.com
Delivered-To: codec@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0A5613A6C87 for <codec@core3.amsl.com>; Fri, 14 Jan 2011 13:38:49 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.571
X-Spam-Level:
X-Spam-Status: No, score=-2.571 tagged_above=-999 required=5 tests=[AWL=0.028, BAYES_00=-2.599]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KPEfcQ17xMgD for <codec@core3.amsl.com>; Fri, 14 Jan 2011 13:38:47 -0800 (PST)
Received: from mx.skype.net (mx.skype.net [78.141.177.88]) by core3.amsl.com (Postfix) with ESMTP id 4A81B3A6BD4 for <codec@ietf.org>; Fri, 14 Jan 2011 13:38:47 -0800 (PST)
Received: from mx.skype.net (localhost [127.0.0.1]) by mx.skype.net (Postfix) with ESMTP id A778D16F7; Fri, 14 Jan 2011 22:41:12 +0100 (CET)
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=skype.net; h=date:from:to :cc:message-id:in-reply-to:subject:mime-version:content-type: content-transfer-encoding; s=mx; bh=oA7kW7CIt+oFxUZ/NgNsCjozK+o= ; b=VqacI2kVDcldRJpI09xXObwlEXBdUSohX7SpmJZ2Pc2huQjKpV9OfQ3iZucF kbIq+FmPCbXoyzOYL2UVT8G4TpcP4WbLKcsntGvvWBcAEI0OmMyTHvTTyAiS3Q3d eK5/AloUyPqsuM0Ds4UkH3gikmH8VOW5DzQYWJFdjA9n+bo=
DomainKey-Signature: a=rsa-sha1; c=nofws; d=skype.net; h=date:from:to:cc :message-id:in-reply-to:subject:mime-version:content-type: content-transfer-encoding; q=dns; s=mx; b=jRWlcZEEOeEfZRrehbMgZO gKmaxqw4HqRJeOJ8m15d89/Eyks+DusGw0FA6dA+3Hmjffc9DbPcpIVT+aKjlr+M RnEwwAS0vHgJUFHDkSjWfifTe41GoWhblpzAsRpG2fc1xgfzqLTd1VmRK6ZgFo+E ra1CKA1g4hU4D/vNUsfUw=
Received: from zimbra.skype.net (zimbra.skype.net [78.141.177.82]) by mx.skype.net (Postfix) with ESMTP id 9C8FB7F3; Fri, 14 Jan 2011 22:41:12 +0100 (CET)
Received: from localhost (localhost [127.0.0.1]) by zimbra.skype.net (Postfix) with ESMTP id 7904E3507791; Fri, 14 Jan 2011 22:41:12 +0100 (CET)
X-Virus-Scanned: amavisd-new at lu2-zimbra.skype.net
Received: from zimbra.skype.net ([127.0.0.1]) by localhost (zimbra.skype.net [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id O7FmkM8CMjzo; Fri, 14 Jan 2011 22:41:10 +0100 (CET)
Received: from zimbra.skype.net (lu2-zimbra.skype.net [78.141.177.82]) by zimbra.skype.net (Postfix) with ESMTP id 8509B3506F82; Fri, 14 Jan 2011 22:41:10 +0100 (CET)
Date: Fri, 14 Jan 2011 22:41:10 +0100
From: Koen Vos <koen.vos@skype.net>
To: Christian Hoene <hoene@uni-tuebingen.de>
Message-ID: <276344716.988745.1295041270412.JavaMail.root@lu2-zimbra>
In-Reply-To: <006601cbb3c4$d2cd6870$78683950$@uni-tuebingen.de>
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
X-Originating-IP: [69.181.192.115]
X-Mailer: Zimbra 6.0.9_GA_2686 (ZimbraWebClient - FF3.0 (Win)/6.0.9_GA_2686)
Cc: codec@ietf.org
Subject: Re: [codec] Next Steps for WG
X-BeenThere: codec@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Codec WG <codec.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/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: Fri, 14 Jan 2011 21:38:49 -0000
Even without DTX, the Voice modes will expose a Voice Activity flag in the decoder API. This will reveal without any decoding whether a payload contains active speech. And all decoder modes have low CPU demands, so decoding all streams to determine which ones are most active is relatively cheap. koen. ----- Original Message ----- From: "Christian Hoene" <hoene@uni-tuebingen.de> To: "Jean-Marc Valin" <jmvalin@jmvalin.ca>, "Roman Shpount" <roman@telurix.com> Cc: codec@ietf.org Sent: Friday, January 14, 2011 12:27:02 AM Subject: Re: [codec] Next Steps for WG The easiest way to mix the multiple streams is to take advantage of the DTX feature, which is available in the Silk and hybrid mode. However, I am not aware whether DTX or VAD is supported in the CELT mode. Christian > -----Original Message----- > From: codec-bounces@ietf.org [mailto:codec-bounces@ietf.org] On Behalf > Of Jean-Marc Valin > Sent: Friday, January 14, 2011 3:51 AM > To: Roman Shpount > Cc: codec@ietf.org > Subject: Re: [codec] Next Steps for WG > > Hi Roman, > > We believe that we meet all requirements that were identified. As for mixing > multiple encoded streams, that was marked as desirable in the draft because > it's very hard to achieve without sacrificing efficiency. > To some extent, if you constrain the Opus encoder to a subset of the > available options (CELT only without short blocks or post-filter), then you can > create streams that can be mixed at roughly half the normal complexity. I > think that's about as much as we can do here. > > Cheers, > > Jean-Marc > > On 11-01-13 07:34 PM, Roman Shpount wrote: > > Just out of curiosity, have the OPUS codec been review against the > > list of requirements that we put together? > > > > In particular, I raised the requirement that multiple encoded streams > > form different sources can be efficiently combined. Is it possible > > with OPUS? If it is, then how? > > _____________________________ > > Roman Shpount - www.telurix.com <http://www.telurix.com> > > > > > > On Thu, Jan 13, 2011 at 5:29 PM, Cullen Jennings <fluffy@cisco.com > > <mailto:fluffy@cisco.com>> wrote: > > > > > > The OPUS draft authors believe the bitstream for OPUS will be ready > > to be "frozen" by the end of the month. At that point we plan to > > spend the following month testing and, baring any surprises, will > > likely go to WGLC after that. > > > > There has been some questions about what "frozen" means in IETF > > context. The bitstream could change any time up to when the IESG > > approves it which is after Working Group Last call and after IETF > > Last Call so there is no guarantee that nothing will change but ... > > by "frozen" we mean that we believe no changes are needed and > > don't plan to make changes unless some significant problem is found. > > > > Thanks, > > Cullen, Jonathan, and Mike > > > > > > _______________________________________________ > > codec mailing list > > codec@ietf.org <mailto:codec@ietf.org> > > https://www.ietf.org/mailman/listinfo/codec > > > > > > > > > > _______________________________________________ > > codec mailing list > > codec@ietf.org > > https://www.ietf.org/mailman/listinfo/codec > _______________________________________________ > codec mailing list > codec@ietf.org > https://www.ietf.org/mailman/listinfo/codec _______________________________________________ codec mailing list codec@ietf.org https://www.ietf.org/mailman/listinfo/codec
- Re: [codec] Next Steps for WG Roman Shpount
- [codec] Next Steps for WG Cullen Jennings
- Re: [codec] Next Steps for WG Jean-Marc Valin
- Re: [codec] Next Steps for WG Christian Hoene
- Re: [codec] Next Steps for WG Koen Vos
- Re: [codec] Next Steps for WG Roman Shpount
- Re: [codec] Next Steps for WG Kevin P. Fleming
- Re: [codec] Next Steps for WG Roman Shpount
- Re: [codec] Next Steps for WG Colin Perkins
- Re: [codec] Next Steps for WG Koen Vos
- Re: [codec] Next Steps for WG Roman Shpount
- Re: [codec] Next Steps for WG Koen Vos