Subject: [codec] All requirements fulfilled?

From: "Christian Hoene" <[email-masked]>
Date: Thu, 28 Jul 2011 11:20:42 -0400

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

---

From: Ralph Giles <[email-masked]>
Date: Thu, 28 Jul 2011 09:02:37 -0700

> and large packets) and multichannel support

We don't have a specification for multichannel Opus either in raw
codec packets or in any encapsulation format. Is there a standard way
to build multichannel out of a series of mono or stereo streams in RTP
playloads?

 -r

---

From: Gregory Maxwell <[email-masked]>
Date: Thu, 28 Jul 2011 09:15:20 -0700

Christian Hoene [[email-masked]]:
>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.

Thank you for the point by point, however at some points your comparison appears to be more or less completely uncorrelated with the requirements draft.

For example,

7 Delay tolerant networking
1.      high delays >120ms                                      => needs to be defined payload draft

The text in the requirements draft states (in entirety):

3.7. Delay Tolerant Networking or Push-to-Talk Services

   Internet transmissions are subjected to interruptions of connectivity
   that severely disturb a phone call.  This may happen in cases of
   route changes, handovers, slow fading, or device failures.  To
   overcome this distortion, the phone call can be halted and resumed
   after the connectivity has been reestablished again.

   Also, if transmission capacity is lower than the minimal coding rate,
   switching to a push-to-talk mode still allows for effective
   communication.  In that situation, voice is transmitted at slower-
   than-real-time bitrate and conversations are interrupted until the
   speech has been transmitted.

   These modes require interrupting the audio playout and continuing
   after a pause of arbitrary duration.

In what universe is _adding_ enormous amounts of delay
in the codec a requirement of being delay tolerant?

I would have stridently objected to a requirement of having high 
delays in the codec as a requirement (though it might make
sense as a consequence of some other worth-while tradeoff or
as something simply permitted where it doesn't add overhead).  

It's also worth pointing out that the packet duration will usually
translate to a one way delay of at 3x or more larger due to
buffering at various points.  Even if you are already on the moon
I doubt you would welcome an additional one second round trip
delay from the codec.

---

From: "Christian Hoene" <[email-masked]>
Date: Thu, 28 Jul 2011 13:20:37 -0400

Hi Greg,

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

To state it clearly: Due to a variety of reasons, it makes perfectly sense
to support large RTP packets transmitting multiple Opus frames.

My point is that at least the payload specification shall allow large
packets (>120ms). What is the problem with this requirement? In the end,
it's a payload requirement not a codec requirement...

Christian

---

From: Stephen Botzko <[email-masked]>
Date: Thu, 28 Jul 2011 13:31:01 -0400

-inline
Stephen Botzko

On Thu, Jul 28, 2011 at 12:02 PM, Ralph Giles <[email-masked]> wrote:

> rfc 3551 section 4.4

Though often payload RFCs specify this.

 -r
______________________________
> _________________
> codec mailing list
> [email-masked]

On Thu, Jul 28, 2011 at 12:02 PM, Ralph Giles <[email-masked]> wrote:

> _______________________________________________
> codec mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/codec
>

---

From: Paul Beaumont <[email-masked]>
Date: Thu, 28 Jul 2011 18:31:21 +0100

All

Apologies, being first time to IETF and its mailing lists, if this is not the right mailing list to post this request to.

On initial inspection it looks like it is not possible to specify in SDP the specific packetisation period associated with a codec that is available through negotiation. Specific case I am concerned with is to support (1) G.711 @ PP=10ms and (2) G.711 @ PP=20ms; prioritised in that order. The ptime parameter would appear to apply to both.

Please can you advise where I should submit this question or if this is the right frum then whether the above observation is correct and any supplemental information/comments you may have? 

Thanks
Paul Beaumont

---

From: Ralph Giles <[email-masked]>
Date: Thu, 28 Jul 2011 12:38:30 -0700

On 28 July 2011 10:30, Stephen Botzko <[email-masked]> wrote:

>> Is there a standard way

Thanks.

> Though often payload RFCs specify this.

I presume it would need to at least specify the channel map?

 -r

---

From: Stephen Botzko <[email-masked]>
Date: Thu, 28 Jul 2011 15:58:20 -0400

In line,
Stephen Botzko

> I presume it would need to at least specify the channel map?
[SB] You can review RFC 5404 as one example.  Section 4.2 has some
information. There are also some implications on having suitable pointers to
frame starts.  RFC 5404 (for example) also has some other modes
(interleaved, etc), so it needs to ensure that it is clear what the multiple
frames in the packet are for.

---

From: "Schwarz, Albrecht (Albrecht)" <[email-masked]>
Date: Fri, 29 Jul 2011 11:31:08 +0200

Paul,

1) SDP => IETF MMUSIC

2) ptime problem statement ("well known"), see

Multiple Packetization Times in the Session Description Protocol (SDP):
Problem Statement, Requirements & Solution
draft-garcia-mmusic-multiple-ptimes-problem-03.txt
http://tools.ietf.org/html/draft-garcia-mmusic-multiple-ptimes-problem-03

3) Solution:
= revised SDP Offer/Answer
see
a) SDP) Capability Negotiation RFC 5939
   http://tools.ietf.org/html/rfc5939
b) SDP Media Mapabilities Negotiation
   http://tools.ietf.org/wg/mmusic/draft-ietf-mmusic-sdp-media-capabilities/

Thus, revised SDP Offer/Answer must be used (instead of legacy SDP Offer/Answer RFC 3264).

-Albrecht

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] 
> On Behalf Of Paul Beaumont
> Sent: Donnerstag, 28. Juli 2011 19:31
> To: [email-masked]
> Subject: [codec] SDP Support for Multiple Packetisation Periods
> 
> All
> 
> Apologies, being first time to IETF and its mailing lists, if 
> this is not the right mailing list to post this request to.
> 
> On initial inspection it looks like it is not possible to 
> specify in SDP the specific packetisation period associated 
> with a codec that is available through negotiation. Specific 
> case I am concerned with is to support (1) G.711 @ PP=10ms 
> and (2) G.711 @ PP=20ms; prioritised in that order. The ptime 
> parameter would appear to apply to both.
> 
> Please can you advise where I should submit this question or 
> if this is the right frum then whether the above observation 
> is correct and any supplemental information/comments you may have? 
> 
> Thanks
> Paul Beaumont
> 
> 
>

---

From: "Miguel A. Garcia" <[email-masked]>
Date: Sun, 31 Jul 2011 10:33:32 +0200

Yeap, I was also going to point to the (already expired) I-D on multiple 
packetization problem draft,

http://tools.ietf.org/id/draft-garcia-mmusic-multiple-ptimes-problem-03.txt

The authors didn't see much interest in solving this problem, so the 
draft was abandoned. If the community realizes that the problem still 
persists, we can easily resurrect it.

/Miguel

On 29/07/2011 11:31, Schwarz, Albrecht (Albrecht) wrote:
> Problem Statement, Requirements&  Solution
> mmusic mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/mmusic
>

-- 
Miguel A. Garcia
+34-91-339-3608
Ericsson Spain