Re: [codec] Suggested summary...

["Christian Hoene" <[e-mail]>]

Hi Raymond,

Inline some comments of mine are inline

Christian

 
-----Original Message-----
From: Raymond (Juin-Hwey) Chen [mailto:[e-mail]] 

Hi Christian,

Thanks for your summary.  Some comments on 2) and 3) below.

2) low complexity mode: 
All else being equal or comparable, the lower the complexity, the 
better.  Besides MIPS or WMOPS, the memory footprint is another 
important aspect of complexity that should be considered.  

[Christian Hoene] Any suggested minimal and median values? 

Furthermore, if we want to specify a complexity target, then in 
addition to a target for the full-band 48 kHz sampling rate, it would 
be useful to specify also the complexity targets for lower sampling 
rates such as 16 and 8 kHz, since the codec may operate at these 
lower sampling rates in some important voice-centric applications.

[Christian Hoene] Upps, the minimal complexity values were meant regardless of the sampling rate

3) How latency sums up: 
Thanks for mentioning the ITU-T G.114, which has a good discussion of 
the codec-related one-way delay along the line of what we discussed 
in the emails. 

[Christian Hoene] Yes, but I forgot to mention that is was industry consensus ten years ago. Things have changed.

However, I disagree with the statement that "Typical 
values are range from a factor faster of 100 (smart phones) to 1000 
(PCs). A device working at full load is a rare case." It is not at 
all a rare case to find devices running at or close to full load.  A 
good example is VoIP gateways.  

[Christian Hoene] Sorry, a telecommunication network overrating at full load is a rare case. For example, around  New Year's Eve networks tend to become overloaded: 2h per one year. Typically, the network shall be loaded somewhere between 5 and 20% or less. Even if you assume that all traffic is between end device and gateway (which is not the case - end to end IP is a more reasonable scenario), then the gateway is fully loaded less than 1<% of the time.

Also, in numerous occasions I have 
seen engineers trying very hard to cut the complexity of algorithms 
to make them fit the processing power of existing DSPs or host 
processors. That means the resulting implementations would have the 
processor essentially fully loaded.  

The fastest processors in current smart phones and PCs are about 1 
GHz and slightly more than 3 GHz, respectively.  A factor of 100 and 
1000 faster would require that the codec complexity be less than 
about 10 MHz and 3 MHz, respectively.  Most contemporary codecs today 
have higher complexity than that.  

[Christian Hoene] Then take the value 10 and 100. It still does not matter.

Even if the codec complexity were 
lower than these numbers, to achieve a delay reduction factor of 100 
and 1000, the encoding and decoding operations would each have to be 
the only real-time task or the highest-priority task so the processor 
will get to it right away without any delay.  This is not the case in 
general, since having a full-duplex channel will requires at least a 
real-time encoding task and a real-time decoding task running at the 
same time. Both cannot be the only real-time task or the highest-
priority real-time task at the same time; furthermore, there are 
almost always some other real-time tasks in the system.  As I 
discussed in length in my previous email about Real-Time Scheduling 
(RTS) delay, most audio/video communication systems have many 
real-time tasks running at the same time; substantial delay needs 
to be added to ensure that none of such real-time tasks will run out 
of real time.  This often leads to an RTS delay of one frame.

[Christian Hoene] Let me cite from TI specs of the TNETV3020 carrier grade voice gateway: "Processing delay in the Telogy Software solution is minimized by a staggered processing schedule". TI engineers do not have the same technical problems as Broadcom engineers. This paper (or any other) on the topic of staggered scheduling might be helpful http://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.143.7213&rep=rep1&type=pdf 




Best Regards,

Raymond

-----Original Message-----
From: [e-mail] [mailto:[e-mail]] On Behalf Of Christian Hoene
Sent: Friday, July 02, 2010 3:09 AM
To: 'Cullen Jennings'
Cc: [e-mail]
Subject: [codec] Suggested summary...

Hello,

taking Cullen advise, I would like to suggest the following summary.

> 1) low delay mode

The codec shall be able to operated at a mode having an algorithmic delay of 8ms or less while having a frame duration of 5 1/3 ms or less. This is require to support ensemble performances over the Internet and other highly interactive conversational tasks.

> 2) low complexity mode (whatever this means)

The codec shall be able to operate at a low complexity mode while requiring less computational resources than a AMR-WB codec 
(< 38 WMOPS if measured with ITU-T STL2005 BaseOP (ITU-T G.192)).

> 3) technical understanding on how latency sums up on different platforms

Standard ITU-T G.114 (05/00 and 05/03) describes how different system components contribute to the one-way transmission delay. It states that the processing time of the codec contributes with an additional delay as large as the frame duration.

However, it is common consensus that plenty computational resources will be available most of the time. Then, the codec processing will be much faster than one frame duration. Typical values are range from a factor faster of 100 (smart phones) to 1000 (PCs). A device working at full load is a rare case.

Any suggestion to improve it?

With best regards,

 Christian 



---------------------------------------------------------------
Dr.-Ing. Christian Hoene
Interactive Communication Systems (ICS), University of Tübingen 
Sand 13, 72076 Tübingen, Germany, Phone [phone] 
http://www.net.uni-tuebingen.de/


-----Original Message-----
From: Cullen Jennings [mailto:[e-mail]] 
Sent: Monday, June 21, 2010 7:21 PM
To: Christian Hoene
Cc: [e-mail]
Subject: Re: [codec] #16: Multicast?


On May 27, 2010, at 9:48 AM, Christian Hoene wrote:

> So, we have consensus on 
> 1) low delay mode
> 2) low complexity mode (whatever this means)
> 3) technical understanding on how latency sums up on different platforms

>From a Chair point of view, I don't think the Chairs could summarize or call consensus on these three - however, I'm not sure that matters. If you think a key piece of consensus has come out of this conversation and that it needs to captured in the archive, can you summarize what you think it is folks agree with and then the chairs can make some sort of consensus call.

Thanks, Cullen <with my chair hat on>
 =

_______________________________________________
codec mailing list
[e-mail]
https://www.ietf.org/mailman/listinfo/codec