Re: [codec] #15: Efficiently combine pre-encoded audio

"codec issue tracker" <> Sat, 01 May 2010 14:24 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 3F50A28C15D for <>; Sat, 1 May 2010 07:24:43 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -101.2
X-Spam-Status: No, score=-101.2 tagged_above=-999 required=5 tests=[AWL=-1.200, BAYES_50=0.001, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id 1S0uiA8VPJAO for <>; Sat, 1 May 2010 07:24:41 -0700 (PDT)
Received: from (unknown [IPv6:2001:1890:1112:1::2a]) by (Postfix) with ESMTP id 955343A6BBE for <>; Sat, 1 May 2010 07:24:26 -0700 (PDT)
Received: from localhost ([::1] by with esmtp (Exim 4.69) (envelope-from <>) id 1O8Dc4-0006nx-Pa; Sat, 01 May 2010 07:24:12 -0700
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 8bit
From: codec issue tracker <>
X-Trac-Version: 0.11.6
Precedence: bulk
Auto-Submitted: auto-generated
X-Mailer: Trac 0.11.6, by Edgewall Software
X-Trac-Project: codec
Date: Sat, 01 May 2010 14:24:12 -0000
Message-ID: <>
References: <>
X-Trac-Ticket-ID: 15
In-Reply-To: <>
X-SA-Exim-Connect-IP: ::1
X-SA-Exim-Scanned: No (on; SAEximRunCond expanded to false
Subject: Re: [codec] #15: Efficiently combine pre-encoded audio
X-Mailman-Version: 2.1.9
List-Id: Codec WG <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Sat, 01 May 2010 14:24:43 -0000

#15: Efficiently combine pre-encoded audio
 Reporter:  hoene@…                 |       Owner:     
     Type:  enhancement             |      Status:  new
 Priority:  minor                   |   Milestone:     
Component:  requirements            |     Version:     
 Severity:  Active WG Document      |    Keywords:     

Comment(by hoene@…):

 > [...] conferences implemented using multicast require
 > end system mixing of potentially large numbers of active audio
 > streams, whereas those implemented using conference bridges do the
 > mixing in a single central location, and generally suppress all but
 > one speaker. The differences in mixing and the number of simultaneous
 > active streams that might be received potentially affect the design of
 > the codec.

 [Raymond]: I would like to take this opportunity to express my view that
 although codec complexity isn’t much of an issue for PC-to-PC calls where
 there are GHz of processing power available, the codec complexity is an
 important issue in certain application scenarios.  The following are just
 some examples.
 1) If a conference bridge has to decode a large number of voice channels,
 mix, and re-encode, and if compressed-domain mixing cannot be done (which
 is usually the case), then it is important to keep the decoder complexity

 [JM]: The decoder complexity is very important. Not only because of mixing
 issue, but also because the decoder is generally not allowed to take
 shortcuts to save on complexity (unlike the encoder). As for compressed-
 domain mixing, as you say it is not always available, but *if* we can do
 it (even if only partially), then that can result in a "free" reduction in
 decoder complexity for mixing.

 [Christian]: Scalable [conferencing]
 -       Receiver side activity detection for music and voice having low
 complexity (for the conference bridge)
 -       Efficient mixing of two to four(?) active flows (is this
 achievable without the complete process of decoding and encoding again?)

Ticket URL: <>
codec <>