[codec] All requirements fulfilled?

"Christian Hoene" <hoene@uni-tuebingen.de> Thu, 28 July 2011 15:20 UTC

Return-Path: <hoene@uni-tuebingen.de>
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 6819521F8C58 for <codec@ietfa.amsl.com>; Thu, 28 Jul 2011 08:20:59 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.248
X-Spam-Level:
X-Spam-Status: No, score=-6.248 tagged_above=-999 required=5 tests=[AWL=-0.001, BAYES_00=-2.599, HELO_EQ_DE=0.35, HTML_MESSAGE=0.001, 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 fj3hrpP1Y0LY for <codec@ietfa.amsl.com>; Thu, 28 Jul 2011 08:20:56 -0700 (PDT)
Received: from mx05.uni-tuebingen.de (mx05.uni-tuebingen.de [134.2.3.4]) by ietfa.amsl.com (Postfix) with ESMTP id 19D0721F8C3F for <codec@ietf.org>; Thu, 28 Jul 2011 08:20:53 -0700 (PDT)
Received: from hoeneT60 (dhcp-134c.meeting.ietf.org [130.129.19.76]) (authenticated bits=0) by mx05.uni-tuebingen.de (8.13.6/8.13.6) with ESMTP id p6SFKgVH003033 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO) for <codec@ietf.org>; Thu, 28 Jul 2011 17:20:50 +0200
From: "Christian Hoene" <hoene@uni-tuebingen.de>
To: <codec@ietf.org>
Date: Thu, 28 Jul 2011 11:20:42 -0400
Organization: =?iso-8859-1?Q?Universit=E4t_T=FCbingen?=
Message-ID: <005001cc4d39$ef62b580$ce282080$@uni-tuebingen.de>
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="----=_NextPart_000_0051_01CC4D18.6864C490"
X-Mailer: Microsoft Outlook 14.0
Thread-Index: AcxNOd+Yi83fs0vWRIKjGLmIaR72bw==
Content-Language: de
X-AntiVirus: NOT checked by Avira MailGate (version: 3.2.1.23; host: mx05)
Subject: [codec] All requirements fulfilled?
X-BeenThere: codec@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Codec WG <codec.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/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: Thu, 28 Jul 2011 15:20:59 -0000

Hi all,

 

I just went thru the list of requirements to see which of them have been met
and have been tested. I marked them with colors.

 

1 Point to point calls

1.      wideband speech with 12- 32 kbps, delay less than 40ms

2.      narrowband speech with 8-16 kbps, delay between 20-30ms

3.      background (on-hold) music acceptable

4.      robust to noise at low bit rates

2 Conferencing

1.      variable bit rate

2.      super-wideband 24 to 64 kbps

3.      delay lower than 30ms

4.      two voices at the same time                    ð any formal test for
stereo voices? 

5.      easy mixing                                                      ð
solution given but not in draft 

6.      VAD without full decoding                       ð using DTX and RTP
sequence no.

7.      low complexity mixing                               ð dito

3 Telepresence

1.      super-wide to fullband audio

2.      32-80 kb/s full band

3.      speech and music

4.      support for stereo

5.      support for multichannel                          ð needs to be
defined payload draft 

4 Teleoperation

1.      full band audio with delay lower than 10ms

5 In-game voice chat

1.      low delay <10ms

2.      VBR

3.      super-wide band 30 to 80 kb/s

6 Live distributed music performances

1.      near-transparent to transparent coding

2.      delay between 2 and 10ms

3.      48 kbps to 128 kbps

7 Delay tolerant networking

1.      high delays >120ms                                      ð needs to
be defined payload draft  

8 Security

1.      limited time to decode packet                

2.      CBR mode

9 Packet loss

1.      interpret packet after loss

2.      decoding re-synchronize quickly

3.      frame size smaller than MTU 

4.      no inter packet dependencies

5.      FEC

6.      testing using real packet loss traces     ð not done formally / no
tools

7.      up to 5% loss having acceptable quality

8.      up to 15% loss having acceptable intelligibility              ð not
tested 

10 Computational resource

1.      Narrowband: 40 Mhz (2% of a 2 GHz CPU core)               

2.      Wideband: 80 Mhz (4% of a 2 GHz CPU core)   ð no results published

3.      SWB/Full: 200 Mhz (10% of a 2 GHz CPU core)                

4.      VAD detection at 10% of above values                               ð
if using RTP

5.      Limited use of hardware saturation

11 Internet characteristics

1.      Smooth bit rate changes                            ð no test results
published / no tools

2.      Adaptive VBR based on signal

3.      no artifacts at mode changes                   ð no test results
published / no tools

4.      codec should produce byte aligned frames

5.      Support of ECN                                               ð task
of AVT/RTP

6.      Support of RTP Payload                              ð see my recent
emails

7.      Codec parameter negotiation easy with SDP/Jingle

12 Additional optional features

1.      Low-complexity audio mixing                 ð a simple appendix to
the draft

2.      Encoder side improvements                    ð no need to
standardize them

3.      Layered bit-stream                                       ð
important?

4.      Partial redundancy

5.      Stereo support

6.      Bit error robustness                                     ð no test
results / no tools

7.      Time stretching and shortening              ð important but missing

8.      Input robustness                                           ð any
hacker around?

9.      Audio forensics

 

And finally, the high level requirements:

Charter (2011-03-31):

1.      Designed for use in interactive applications

2.      Addressing the real transport conditions of the Internet           ð
referring to 9.6. No test results / no tools 

3.      Ensuring interoperability and clean integration
ð referring to my emails made some days ago
with the Real-time Transport Protocol (RTP)

4.      Ensuring interoperability with Internet signaling technologies

Draft-ietf-codec-guidelines-02:

1.      minimum allowing interoperable implementations

2.      tool to compare decoder implementations

3.      decoder must be able to decode all "features" of the bit stream

4.      test vectors for the decoder                                    ð
URL is missing

5.      minimal quality of encoder

Draft-ietf-codec-requirements-05:

1.      designed specifically for use over the Internet

5.      attempt to address the needs of the
ð referring to 12.7. 
most common Internet interactive audio transmission applications

 

 

Based on this list of requirements, I want to raise the following questions
in respect to WGLC Opus (in addition to my previously made comments).

 

1.       Remove framing and padding from codec draft (or move it as
non-normalize to the appendix) and add it to RTP Payload framing (also small
and large packets) and multichannel support

2.       Discuss whether to add Time stretching and shortening to the codec

•       GIPS is using this feature heavily and Opus shall replace iSAC… 

3.       Add low-complexity audio mixing as appendix (I will sent you some
text soon)

4.       Provide a pointer to a URL to download test vectors

 

Koen and Jean-Marc, may you update your slides accordingly? Thanks.

 

With best regards,

 

Christian 

 

----------------------------------------------------------------------------
-----

Dr.-Ing. Christian Hoene, University of Tübingen, Computer Science, Chair of

Communication Networks, Research Group Interactive Communication Systems
(ICS)

Sand 13, 72076 Tübingen, Germany, Tel +49 7071 2970532,
www.net.uni-tuebingen.de