Re: [codec] #28: Layered bit-stream
"codec issue tracker" <trac@tools.ietf.org> Sun, 09 May 2010 17:32 UTC
Return-Path: <trac@tools.ietf.org>
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 674E43A688F for <codec@core3.amsl.com>; Sun, 9 May 2010 10:32:03 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -101.124
X-Spam-Level:
X-Spam-Status: No, score=-101.124 tagged_above=-999 required=5 tests=[AWL=-1.124, BAYES_50=0.001, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100]
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 JHuJTSI7uhpq for <codec@core3.amsl.com>; Sun, 9 May 2010 10:32:02 -0700 (PDT)
Received: from zinfandel.tools.ietf.org (unknown [IPv6:2001:1890:1112:1::2a]) by core3.amsl.com (Postfix) with ESMTP id 589033A6817 for <codec@ietf.org>; Sun, 9 May 2010 10:32:02 -0700 (PDT)
Received: from localhost ([::1] helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.69) (envelope-from <trac@tools.ietf.org>) id 1OBAM3-0007Mi-AS; Sun, 09 May 2010 10:31:51 -0700
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 8bit
From: codec issue tracker <trac@tools.ietf.org>
X-Trac-Version: 0.11.6
Precedence: bulk
Auto-Submitted: auto-generated
X-Mailer: Trac 0.11.6, by Edgewall Software
To: hoene@uni-tuebingen.de
X-Trac-Project: codec
Date: Sun, 09 May 2010 17:31:51 -0000
X-URL: http://tools.ietf.org/codec/
X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/codec/trac/ticket/28#comment:1
Message-ID: <071.ae971d97e4ce49d214b97c95cb88df4b@tools.ietf.org>
References: <062.23d5df12c0b3d27cb5b6b25801ab2a4d@tools.ietf.org>
X-Trac-Ticket-ID: 28
In-Reply-To: <062.23d5df12c0b3d27cb5b6b25801ab2a4d@tools.ietf.org>
X-SA-Exim-Connect-IP: ::1
X-SA-Exim-Rcpt-To: hoene@uni-tuebingen.de, codec@ietf.org
X-SA-Exim-Mail-From: trac@tools.ietf.org
X-SA-Exim-Scanned: No (on zinfandel.tools.ietf.org); SAEximRunCond expanded to false
Cc: codec@ietf.org
Subject: Re: [codec] #28: Layered bit-stream
X-BeenThere: codec@ietf.org
X-Mailman-Version: 2.1.9
Reply-To: codec@ietf.org
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: Sun, 09 May 2010 17:32:03 -0000
#28: Layered bit-stream ------------------------------------+--------------------------------------- Reporter: hoene@… | Owner: Type: defect | Status: new Priority: minor | Milestone: Component: requirements | Version: Severity: Active WG Document | Keywords: ------------------------------------+--------------------------------------- Comment(by hoene@…): [Vladimir]: We'd like to express SPIRIT's point of view on the topic. It is as follows: 1/ we support layered coding in our IPMR-codec. Such approach is used by ITU-T Recs G.711.1 and G.718, for example. 2/ we think that VoIP and Videoconferencing systems are users of such codecs. 3/ we consider that it is not needed to drop scalability and layered coding. [Christian]: As far as I understand, layered coding helps if multiple streams having the sample content but different rates must be generated. For example, if a conferencing system stream the same audio stream to N users but each users has a different bandwidth. Just encode all layers and drop the higher layers for the low bandwidth users. This approach is easy and efficient and reduces the encoding complexity. The arguments against are simple. a) First, this use case is a local optimization only. Thus, the must not be standardized. b) Second, instead of layered coding one can use other ways of tweaking the implementation performance. For example, if you calculate a 512 FFT do get two 256 FFTs for free. I bet there are thousand other shortcuts which I am not aware of. Thus, I have the opinion that layered coding is not worth the extra bandwidth of 20 or more percentage. It is just good locally but not needed for interoperability. [Dmitry]: From application point of view, the layered stream structure allows server manipulate channel bandwidth individually for each user with zero performance overhead. Obviously, conferencing is the most important use- case. […] Shall layered coding be supported? - we think "yes", because ... (see my first sentence) Who needs it? - answered Can we drop this requirement? - only if we have real good reasons for it. Do we have them? [Christian]: Because […] an application programmer want[s] to have an easy life, the codec designer shall develop a more complicated codec? In addition, everybody should suffer from a higher bit rate? No, that is not fair. > Obviously, conferencing is the most important use-case. No, end-to-end connections are more frequent than conference calls. > "local optimization" of what? I mean that the layered coding is only used within one computer. It is not important in-between computers. And, it is only a performance optimization that makes the conference gateway faster. [Stephen]: A couple of observations on this (a) I agree with Christian that layered codecs usually need higher bitrates to achieve the same quality. Of course we do want good quality over our desired bitrate range, and it is likely to be more difficult to achieve that with a layered codec. (b) I agree with Dimity that layered codecs reduce the complexity of VOIP gateways and perhaps conference bridges. Also, with layered codec designs you get wire-speed management of channel bandwidth, so there can be a delay benefit as well as a complexity reduction. (c) Arguing about the relative priority of multipoint conferences vs point to point calls is pointless, because they are clearly both MUSTS. I am not sure if Christian is arguing that layered codecs SHALL NOT be considered, or if the requirements allow but are not biased towards layered proposals. If might be useful to clarify this point. [Christian]: Let me explain my arguments a bit more by discussion point b. (b) I agree with Dimity that layered codecs reduce the complexity of VOIP gateways and perhaps conference bridges. I see that there is an important need to reduce the computational complexity at gateways and conference bridges. Layered coding is an easy solution that helps to reduce complexity. However, I think that there are many other ways to achieve similar complexity reduction WITHOUT requiring layered coding. One example is a special encoder that encodes multiple streams at the same time. Also, with layered codec designs you get wire-speed management of channel bandwidth, so there can be a delay benefit as well as a complexity reduction. Also, a fast management of channel bandwidth can be achieved by controlling the encoder (via a feedback channel not locally) Thus, I would vote for a NEED NOT or even MUST NOT because the costs of layered encoding are imposed to all users of the codec but the benefit is only to the gateways. [Dimitry]: Definitely, there are number of applications that can (more or less efficiently) utilize layered stream structure. At the same time, scalability makes codec more complex and cause bitrate penalty due to a simple fact that entropy(a+b)<=entropy(a)+entropy(b). The only question is: what penalty is acceptable and what is not? Based on IP-MR codec experience I consider the price for scalability as not too high. > I mean that the layered coding is only used within one computer. > It is not important in-between computers. And, it is only a > performance optimization that make the conference gateway faster. This is correct. No other benefits except performance saving. [Dimitry]: […] But the thing is that this is not a point we should stand on. Let’s stay on a point of problems and solutions. The problem is: gateways have to recompress data to fit user bandwidth and it would be very desired to decrease recompression cost: Does this problem live only in my mind? - any considerations are welcome. Possible solution : The layered stream structure allows zero cost recompression (but increases bitrate/quality ratio). All other solutions are also welcome. -- Ticket URL: <http://trac.tools.ietf.org/wg/codec/trac/ticket/28#comment:1> codec <http://tools.ietf.org/codec/>
- [codec] #28: Layered bit-stream codec issue tracker
- Re: [codec] #28: Layered bit-stream Christian Hoene
- Re: [codec] #28: Layered bit-stream Christian Hoene
- Re: [codec] #28: Layered bit-stream stephen botzko
- Re: [codec] #28: Layered bit-stream Christian Hoene
- Re: [codec] #28: Layered bit-stream Dmitry Yudin
- Re: [codec] #28: Layered bit-stream Dmitry Yudin
- Re: [codec] #28: Layered bit-stream Dmitry Yudin
- Re: [codec] #28: Layered bit-stream codec issue tracker
- Re: [codec] #28: Layered bit-stream codec issue tracker
- Re: [codec] requirements #28 (closed): Layered bi… codec issue tracker