Subject: [codec] Codec BOF approved, much work needed

From: Cullen Jennings <[email-masked]>
Date: Fri, 12 Jun 2009 11:31:52 -0600

I have approved the CODEC BOF proposal. However, we need a bunch of  
work to get ready.  Various people on IESG/IAB were not comfortable  
with the current charter and agenda so we need to work on theses  
before the meeting.

A draft agenda/charter Jason provided are at

Agenda: http://svn.resiprocate.org/rep/ietf-drafts/codec-bof/agenda.txt

Charter: http://svn.resiprocate.org/rep/ietf-drafts/codec-bof/charter.txt

After discussion with the IESG/IAB:

I'd like to remove the "as Proposed Standard" from the charter text  
for both milestones and see how the discussion goes in the BOF before  
deciding which way this should go.

I'd like to see more consideration around the issues of designing a  
codec that did a good job of mapping a real time stream onto IP  
packets. The way IP deals with packet loss and congestion has  
implications for designing a codec that works well over IP. I know  
some of the discussion I have had off list people talked about how we  
wanted a codec that supported adaptive bit rates that could change on  
the fly to be able to work well on an IP network.

I will be working the folks to make sure the agenda has time to  
directly address the key topics which include (more may be coming):

Will we be able to get qualified people to do and review the work?

Key design goals of a new codec?

Do we need a new codec or are there already ones defined that meet the  
needs?

I have asked Jason Fischl  and Jean-Marc Valin to co-chair this BOF.

Thanks,

Cullen <RAI AD>

---

From: Roni Even <[email-masked]>
Date: Fri, 12 Jun 2009 21:56:14 +0300

Hi,
I would like to suggest other key topics for the BOF

1. Why should the IETF start a codec WG - why not do it as ITU / MPEG /
others

2. Describe the process of defining a codec in other standard bodies - my
view is that not everyone knows what is required to create a quality codec.

3. Is the purpose of the WG to publish one codec or multiple codecs based on
different requirements.

4. If a WG will be formed there are more decision to make like, what is the
selection criteria if there is more than one candidate or do we require some
cooperation, what are the deliverable - source code, encoder specification
(do we require bit exactness ), how to defines the quality tests and
evaluate the results to check if the codec addresses the requirements.

Roni Even 

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of
Cullen Jennings
Sent: Friday, June 12, 2009 8:32 PM
To: [email-masked]
Subject: [codec] Codec BOF approved, much work needed

Thanks,

Cullen <RAI AD>

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

---

From: Koen Vos <[email-masked]>
Date: Fri, 12 Jun 2009 14:32:09 -0700

> 1. Why should the IETF start a codec WG - why not do it as ITU / MPEG /

Also: discuss goals about licensing cost and complexity ?

regards,
Koen Vos

---

From: "Slava Borilin" <[email-masked]>
Date: Wed, 17 Jun 2009 00:56:04 +0400

Roni, and whole international team,

I have one more question here - sorry if this is naïve- but still please advice.

Background: all of us do wish wish wish (vendors, customers, end-users, etc) to have ONE IWAC (internet wideband audio codec) for all.

But assuming we (IETF) will come to the agreement which codec we like best (existing or new one) and make RFC.
What will then be the destiny of the that RFC? 
And who and why should be choosing the certain codec into their app?

Afaik IETF, like ITU just "agree on the specs", while industry or country-specific organizations are enforcing using or not using certain standards, like CableLabs (Vertical market + geography).

The major driver for agreeing on the standard is interop, as I see. 
Currently in the internet communications (web collaboration, voip services, videoconferencing) - do you believe is there any force to push interop, or everyone "plays in his own walled garden"?

Should we:
- agree on RFC and then dig into smaller (geographical or vertical industry) communities to push them to force using this RFC (IWAC) as part of certification to make sure they do enforce the IWAC?
- or we should just have IWAC RFC and believe "better staff will find its way to the market itself"?

regards,
Slava Borilin

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Roni Even
Sent: Friday, June 12, 2009 10:56 PM
To: [email-masked]
Subject: Re: [codec] Codec BOF approved, much work needed

Hi,

Roni Even 

-----Original Message-----

Thanks,

Cullen <RAI AD>

---

From: Jean-Marc Valin <[email-masked]>
Date: Tue, 16 Jun 2009 17:30:07 -0400

Hi,

> Background: all of us do wish wish wish (vendors, customers, end-users, etc) to have ONE IWAC (internet wideband audio codec) for all.

Well, technically it doesn't have to be a single codec. Just like the 
ITU, we can have more than one codec as long as there is no overlap 
between them (i.e. making sure the codecs aren't "competing" one against 
the other). Of course, this is to be further discussed in the BOF.

> Afaik IETF, like ITU just "agree on the specs", while industry or country-specific organizations are enforcing using or not using certain standards, like CableLabs (Vertical market + geography).

As you say, neither the IETF, nor the ITU can force anyone to use a 
codec. The idea would be to come up with a codec that really meets the 
needs of "Internet users". This can be achieved by addressing the issues 
Jason mentioned in his original post (loss robustness, scalability, low 
delay, no IPR, ...). Again, the exact requirements should be further 
discussed, but there are certainly many issues that the current 
ITU/ETSI/MPEG codecs do not address.

> - or we should just have IWAC RFC and believe "better staff will find its way to the market itself"?

Well, the IETF can't force anyone to use anything, but making a codec an 
IETF standard will hopefully convince some people to adopt it. Of 
course, the codec will first have to meet the users' needs.

Cheers,

    Jean-Marc

---

From: Henry Sinnreich <[email-masked]>
Date: Tue, 16 Jun 2009 14:33:15 -0700

Hi Slava,

>Currently in the internet communications (web collaboration, voip services, videoconferencing) -
>do you believe is there any force to push interop, or everyone "plays in his own walled garden"?

IMO one of the main the strengths of the Internet is its global reach. The user can be anywhere and reach content from and communicate with anyone, anywhere. Just like we are doing here with email.
The Internet codec will hopefully do for voice the same as text communications + attachments work in email.

>sorry if this is naïve
This applies to my message as well :-)

Henry

On 6/16/09 3:56 PM, "Slava Borilin" <[email-masked]> wrote:

Should we:

regards,
Slava Borilin

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Roni Even
Sent: Friday, June 12, 2009 10:56 PM
To: [email-masked]
Subject: Re: [codec] Codec BOF approved, much work needed

Hi,

Roni Even

-----Original Message-----

Thanks,

Cullen <RAI AD>

---

From: "Slava Borilin" <[email-masked]>
Date: Wed, 17 Jun 2009 01:56:23 +0400

Dear Henry,

It is probably not the same as with email (or maybe just timing is different).

We are talking not about "enabling technology" to make everyone understand each other (email case), but "enhancement" -  everyone can today understand each other via 711 or 722, but we want to push the quality bar while keeping the interop.

So really the magic question is that once we have the agreement on "recommended" IWAC- either one or several (agree with Jean-Marc), who is to enforce?

PROBABLY the force to enforce are telecom operators?

As telco, against internet companies (Cisco, Skype, MSFT, etc), do not like walled gardens by definition:

 - The telco landscape is not (well, not only) Skype/cheap IP calls versus Cellular or Wireline.

 - The mid-term battle is between internet and its rich communication techniques (web conferencing, social networking) and  telco's phone-only service.

 - Battle is not only for call $$, but for the time spent on the media (trend is users spending more minutes on internet comms then on phones)

 - so carriers have to move from NGN core networks to offer IP-based "social network-like" communication models to subscribers, therefore, have IP-service at the last mile for the user, and not only for enterprise IP-phones, but every consumer.

- And as Telco need subscribers to pay for the service, here comes the HD(=wideband + packet loss robustness), as the necessary step to keep user satisfied with the carrier IP-service.

- So actually, HD sounds to be the cornerstone for keeping the landscape of whole Telco industry versus Internet communications (or vice versa).

- so for telcos it will be really important to have IWAC RFC and telcos have the power to enforce using it (via geo or industry forums - examples are PAL/NTSC in geo, industry - CableLabs), and they are used to the standard/certification process?

Again, apart from the ambitions, what all of us (as vendors and as users) would like to achieve, is interop.

And interop should, probably, be enforced, not "recommended" via some sort of certification?

Everyone, please advice.

regards,

Slava Borilin

________________________________

From: Henry Sinnreich [mailto:[email-masked]] 
Sent: Wednesday, June 17, 2009 1:33 AM
To: Slava Borilin; Roni Even; [email-masked]
Subject: Re: [codec] Codec BOF approved, much work needed

Hi Slava,

Henry

Should we:

regards,
Slava Borilin

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Roni Even
Sent: Friday, June 12, 2009 10:56 PM
To: [email-masked]
Subject: Re: [codec] Codec BOF approved, much work needed

Hi,

Roni Even

-----Original Message-----

Thanks,

Cullen <RAI AD>

---

From: Henry Sinnreich <[email-masked]>
Date: Tue, 16 Jun 2009 15:14:57 -0700

Dear Slava,

>We are talking not about "enabling technology" to make everyone understand each other (email case),
>but "enhancement" -  everyone can today understand each other via 711 or 722, but we want to push the quality bar while keeping the interop.

This is an excellent point. We are talking about the Internet here in in the IETF.

Henry

On 6/16/09 4:56 PM, "Slava Borilin" <[email-masked]> wrote:

Dear Henry,

Everyone, please advice.

regards,
Slava Borilin

Hi Slava,

Henry

Should we:

regards,
Slava Borilin

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Roni Even
Sent: Friday, June 12, 2009 10:56 PM
To: [email-masked]
Subject: Re: [codec] Codec BOF approved, much work needed

Hi,

Roni Even

-----Original Message-----

Thanks,

Cullen <RAI AD>

---

From: "Sandy (Alexander) MacInnis" <[email-masked]>
Date: Tue, 16 Jun 2009 15:18:59 -0700

Are we talking here about speech, or generic audio?

There's a difference in terms of coding (bit rate, quality, etc.) and in terms of applicability.

Or do we want both, i.e. two codecs?

--Sandy

________________________________
From: [email-masked] [mailto:[email-masked]] On Behalf Of Henry Sinnreich
Sent: Tuesday, June 16, 2009 6:15 PM
To: Slava Borilin; Roni Even; [email-masked]
Subject: Re: [codec] Codec BOF approved, much work needed

Dear Slava,

Henry

Dear Henry,

Everyone, please advice.

regards,
Slava Borilin

Hi Slava,

Henry

Should we:

regards,
Slava Borilin

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Roni Even
Sent: Friday, June 12, 2009 10:56 PM
To: [email-masked]
Subject: Re: [codec] Codec BOF approved, much work needed

Hi,

Roni Even

-----Original Message-----

Thanks,

Cullen <RAI AD>

---

From: "Slava Borilin" <[email-masked]>
Date: Wed, 17 Jun 2009 02:22:23 +0400

Not necessarily two - examples are of combined codecs.

Primarily, however, I believe we are about VOICE (wideband, or higher).

regards,

Slava Borilin

From: Sandy (Alexander) MacInnis [mailto:[email-masked]] 
Sent: Wednesday, June 17, 2009 2:19 AM
To: [email-masked]; Henry Sinnreich; Slava Borilin; Roni Even
Subject: RE: [codec] Codec BOF approved, much work needed

--Sandy

Dear Slava,

Henry

Dear Henry,

 
 
Everyone, please advice.

regards,
Slava Borilin

Hi Slava,

Henry

Should we:

regards,
Slava Borilin

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Roni Even
Sent: Friday, June 12, 2009 10:56 PM
To: [email-masked]
Subject: Re: [codec] Codec BOF approved, much work needed

Hi,

Roni Even

-----Original Message-----

Thanks,

Cullen <RAI AD>

---

From: Henry Sinnreich <[email-masked]>
Date: Tue, 16 Jun 2009 15:31:56 -0700

>Are we talking here about speech, or generic audio?

As Slava has pointed out it is about wideband speech, that is the low latency (150ms or so) still applies, but having wideband audio (8-16 kHz audio BW) and why not, stereo. All this and many other however is to be worked out in the proposed Internet Codec WG.

Henry

On 6/16/09 5:18 PM, "Sandy (Alexander) MacInnis" <[email-masked]> wrote:

--Sandy

Dear Slava,

Henry

Dear Henry,

Everyone, please  advice.

regards,
Slava  Borilin

Hi  Slava,

Henry

Should we:

regards,
Slava Borilin

-----Original  Message-----
From: [email-masked] [mailto:[email-masked]] On  Behalf Of Roni Even
Sent: Friday, June 12, 2009 10:56 PM
To: [email-masked]
Subject: Re: [codec] Codec BOF  approved, much work needed

Hi,

Roni Even

-----Original  Message-----

Thanks,

Cullen <RAI  AD>

---

From: Marshall Eubanks <[email-masked]>
Date: Tue, 16 Jun 2009 20:02:49 -0400

Has anyone written up why OGG/Vorbis is not an acceptable solution for  
this ?

Regards
Marshall

On Jun 16, 2009, at 6:31 PM, Henry Sinnreich wrote:

> As Slava has pointed out it is about wideband speech, that is the  
> low latency (150ms or so) still applies, but having wideband audio  
> (8-16 kHz audio BW) and why not, stereo. All this and many other  
> however is to be worked out in the proposed Internet Codec WG.
>
> Henry
>
>
> On 6/16/09 5:18 PM, "Sandy (Alexander) MacInnis" <[email-masked] 
> > wrote:
>
> >We are talking not about “enabling technology” to make everyone  
> understand each other (email case),
> >but “enhancement” -  everyone can today understand each other via  
> 711 or 722, but we want to push the quality bar while keeping the  
> interop.
>
> We are talking not about  “enabling technology” to make everyone  
> understand each other (email case), but  “enhancement” -  everyone  
> can today understand each other via 711 or 722,  but we want to push  
> the quality bar while keeping the interop.
>
> So  really the magic question is that once we have the agreement on  
> “recommended”  IWAC- either one or several (agree with Jean-Marc),  
> who is to  enforce?
>  - The  mid-term battle is between internet and its rich  
> communication techniques (web  conferencing, social networking) and   
> telco's phone-only  service.
>  - Battle is not only for call $$, but for the time spent on  the  
> media (trend is users spending more minutes on internet comms then  
> on  phones)
>  - so carriers have to move from NGN core networks to offer  IP- 
> based "social network-like" communication models to subscribers,  
> therefore,  have IP-service at the last mile for the user, and not  
> only for enterprise  IP-phones, but every consumer.
> - And as Telco need subscribers to pay for  the service, here comes  
> the HD(=wideband + packet loss robustness), as the  necessary step  
> to keep user satisfied with the carrier IP-service.
> - So  actually, HD sounds to be the cornerstone for keeping the  
> landscape of whole  Telco industry versus Internet communications  
> (or vice versa).
> - so for  telcos it will be really important to have IWAC RFC and  
> telcos have the power  to enforce using it (via geo or industry  
> forums – examples are PAL/NTSC in  geo, industry – CableLabs), and  
> they are used to the standard/certification  process?
>
> Again, apart from the ambitions, what all of us (as  vendors and as  
> users) would like to achieve, is interop.
> And interop  should, probably, be enforced, not “recommended” via  
> some sort of  certification?
>
> Everyone, please  advice.
>
>
> regards,
> Slava  Borilin
>
>
>
> IMO one  of the main the strengths of the Internet is its global  
> reach. The user can be  anywhere and reach content from and  
> communicate with anyone, anywhere. Just  like we are doing here with  
> email.
> The Internet codec will hopefully do for  voice the same as text  
> communications + attachments work in  email.
>
> >sorry if this is naïve
> Background: all of us do wish wish  wish (vendors, customers, end- 
> users, etc) to have ONE IWAC (internet wideband  audio codec) for all.
>
> But assuming we (IETF) will come to the agreement  which codec we  
> like best (existing or new one) and make RFC.
> Afaik IETF, like ITU just "agree on the  specs", while industry or  
> country-specific organizations are enforcing using  or not using  
> certain standards, like CableLabs (Vertical market +  geography).
>
> Currently in the internet communications (web collaboration, voip   
> services, videoconferencing) - do you believe is there any force to  
> push  interop, or everyone "plays in his own walled garden"?
>
> Should we:
> -  agree on RFC and then dig into smaller (geographical or vertical  
> industry)  communities to push them to force using this RFC (IWAC)  
> as part of  certification to make sure they do enforce the IWAC?

---

From: Koen Vos <[email-masked]>
Date: Tue, 16 Jun 2009 19:13:02 -0700

Quoting Marshall Eubanks:
> Has anyone written up why OGG/Vorbis is not an acceptable solution for this ?

Several reasons:
- Vorbis runs at bitrates that are higher than a good speech codec.
- Vorbis is not very efficient at coding speech: at a given bitrate it  
delivers worse quality than a good speech codec.
- Vorbis' algorithmic delay seems on the high side for real-time  
communcations.

best,
koen.

>> can today understand each other via 711 or 722,  but we want to  
>> push the quality bar while keeping the interop.
>>
>> - so carriers have to move from NGN core networks to offer   
>> IP-based "social network-like" communication models to subscribers,  
>>> services, videoconferencing) -
>> communicate with anyone, anywhere. Just  like we are doing here  
>> with email.
>> Background: all of us do wish wish  wish (vendors, customers,  
>> end-users, etc) to have ONE IWAC (internet wideband  audio codec)  
>> for all.
>>

---

From: "Jean-Marc Valin" <[email-masked]>
Date: Tue, 16 Jun 2009 22:41:22 -0400

For wideband (16 kHz sampling), I think speech-only (ideally without mutilating background music) is sufficient. However, for super wideband (32 kHz and up), I think it's important to start supporting music. When it comes to latency (by that I mean the codec's algorithmic delay), the lower the better. I consider anything above ~40 ms to be unacceptable (ruling out Vorbis, MP3 and standard AAC), but it should ideally be lower than that. The lower the delay, the less problems you have with acoustic echo. 

   Jean-Marc

-------- Message d'origine--------
De: [email-masked] de la part de Henry Sinnreich
Date: mar. 16/06/2009 18:31
À: Sandy (Alexander) MacInnis; [email-masked]; Slava Borilin; Roni Even
Objet : Re: [codec] Codec BOF approved, much work needed

Henry

--Sandy

Dear Slava,

Henry

Dear Henry,

Everyone, please  advice.

regards,
Slava  Borilin

Hi  Slava,

Henry

Should we:

regards,
Slava Borilin

-----Original  Message-----
From: [email-masked] [mailto:[email-masked]] On  Behalf Of Roni Even
Sent: Friday, June 12, 2009 10:56 PM
To: [email-masked]
Subject: Re: [codec] Codec BOF  approved, much work needed

Hi,

Roni Even

-----Original  Message-----

Thanks,

Cullen <RAI  AD>

---

From: "Christian Hoene" <[email-masked]>
Date: Wed, 17 Jun 2009 08:32:45 +0200

Hi all,

in case of SBC, we are considering it using it for wide-band speech, too.
Then we run it at a lower sampling and bit rate. It outperforms other wide
band speech codecs such as G.722. 

I would suggest that a future audio codec shall be able to work at very low
bit and frame rates, at which it can transmit only speech. This feature
might be quite useful to increase the codec’s robustness in cases of limited
bandwidth and congestion. Also, the codec shall adapt itself to limited
bandwidth automatically.

With best regards,

 Christian 

 

From: [email-masked] [mailto:[email-masked]] On Behalf Of
Sandy (Alexander) MacInnis
Sent: Wednesday, June 17, 2009 12:19 AM
To: [email-masked]; Henry Sinnreich; Slava Borilin; Roni Even
Subject: Re: [codec] Codec BOF approved, much work needed

There's a difference in terms of coding (bit rate, quality, etc.) and in
terms of applicability.

--Sandy

  _____  

Henry Sinnreich

Dear Slava,
 
>We are talking not about “enabling technology” to make everyone understand
each other (email case), 
>but “enhancement” -  everyone can today understand each other via 711 or
722, but we want to push the quality bar while keeping the interop.

This is an excellent point. We are talking about the Internet here in in the
IETF.

Henry

Dear Henry,
 
It is probably not the same as with email (or maybe just timing is
different).
We are talking not about “enabling technology” to make everyone understand
each other (email case), but “enhancement” -  everyone can today understand
each other via 711 or 722, but we want to push the quality bar while keeping
the interop.
 
So really the magic question is that once we have the agreement on
“recommended” IWAC- either one or several (agree with Jean-Marc), who is to
enforce?
PROBABLY the force to enforce are telecom operators?
As telco, against internet companies (Cisco, Skype, MSFT, etc), do not like
walled gardens by definition:
 - The telco landscape is not (well, not only) Skype/cheap IP calls versus
Cellular or Wireline.
 - The mid-term battle is between internet and its rich communication
techniques (web conferencing, social networking) and  telco's phone-only
service.
 - Battle is not only for call $$, but for the time spent on the media
(trend is users spending more minutes on internet comms then on phones)
 - so carriers have to move from NGN core networks to offer IP-based "social
network-like" communication models to subscribers, therefore, have
IP-service at the last mile for the user, and not only for enterprise
IP-phones, but every consumer.
- And as Telco need subscribers to pay for the service, here comes the
HD(=wideband + packet loss robustness), as the necessary step to keep user
satisfied with the carrier IP-service.
- So actually, HD sounds to be the cornerstone for keeping the landscape of
whole Telco industry versus Internet communications (or vice versa).
- so for telcos it will be really important to have IWAC RFC and telcos have
the power to enforce using it (via geo or industry forums – examples are
PAL/NTSC in geo, industry – CableLabs), and they are used to the
standard/certification process?
 
Again, apart from the ambitions, what all of us (as vendors and as users)
would like to achieve, is interop.
And interop should, probably, be enforced, not “recommended” via some sort
of certification?
 
Everyone, please advice.

regards,
Slava Borilin

  _____  

Hi Slava,

>do you believe is there any force to push interop, or everyone "plays in
his own walled garden"?

IMO one of the main the strengths of the Internet is its global reach. The
user can be anywhere and reach content from and communicate with anyone,
anywhere. Just like we are doing here with email.
The Internet codec will hopefully do for voice the same as text
communications + attachments work in email.

Henry

I have one more question here - sorry if this is naïve- but still please
advice.

Background: all of us do wish wish wish (vendors, customers, end-users, etc)
to have ONE IWAC (internet wideband audio codec) for all.

But assuming we (IETF) will come to the agreement which codec we like best
(existing or new one) and make RFC.
What will then be the destiny of the that RFC?
And who and why should be choosing the certain codec into their app?

Afaik IETF, like ITU just "agree on the specs", while industry or
country-specific organizations are enforcing using or not using certain
standards, like CableLabs (Vertical market + geography).

The major driver for agreeing on the standard is interop, as I see.
Currently in the internet communications (web collaboration, voip services,
videoconferencing) - do you believe is there any force to push interop, or
everyone "plays in his own walled garden"?

Should we:
- agree on RFC and then dig into smaller (geographical or vertical industry)
communities to push them to force using this RFC (IWAC) as part of
certification to make sure they do enforce the IWAC?
- or we should just have IWAC RFC and believe "better staff will find its
way to the market itself"?

regards,
Slava Borilin

-----Original Message-----

Hi,

Roni Even

-----Original Message-----

Thanks,

Cullen <RAI AD>

---

From: Christopher Montgomery <[email-masked]>
Date: Wed, 17 Jun 2009 05:54:26 -0400

> - Vorbis' algorithmic delay seems on the high side for real-time

Piping up as the designer of Vorbis, these points are correct.  It is
meant to be a high-latency highest-possible-fidelity codec for general
audio.

Monty

---

From: Henry Sinnreich <[email-masked]>
Date: Wed, 17 Jun 2009 07:36:56 -0700

Supporting music is a good point in case, given the emergence of Telepresence and the Digital Living room.

As for supporting bandwidth constrained links, where congestion can occur, I believe the mobile phone industry has already done a good job that we need not duplicate.

Given the choice between designing for narrowband links and broadband Internet, let's chose therefore broadband.

Henry

On 6/16/09 9:41 PM, "Jean-Marc Valin" <[email-masked]> wrote:

   Jean-Marc

-------- Message d'origine--------
De: [email-masked] de la part de Henry Sinnreich
Date: mar. 16/06/2009 18:31
À: Sandy (Alexander) MacInnis; [email-masked]; Slava Borilin; Roni Even
Objet : Re: [codec] Codec BOF approved, much work needed

Henry

--Sandy

Dear Slava,

Henry

Dear Henry,

Everyone, please  advice.

regards,
Slava  Borilin

Hi  Slava,

Henry

Should we:

regards,
Slava Borilin

-----Original  Message-----
From: [email-masked] [mailto:[email-masked]] On  Behalf Of Roni Even
Sent: Friday, June 12, 2009 10:56 PM
To: [email-masked]
Subject: Re: [codec] Codec BOF  approved, much work needed

Hi,

Roni Even

-----Original  Message-----

Thanks,

Cullen <RAI  AD>

---

From: Marshall Eubanks <[email-masked]>
Date: Wed, 17 Jun 2009 10:41:43 -0400

On Jun 17, 2009, at 10:36 AM, Henry Sinnreich wrote:

> Supporting music is a good point in case, given the emergence of  
> Telepresence and the Digital Living room.
>
> As for supporting bandwidth constrained links, where congestion can  
> occur, I believe the mobile phone industry has already done a good  
> job that we need not duplicate.
>
> Given the choice between designing for narrowband links and  
> broadband Internet, let’s chose therefore broadband.
>

I would agree. I work in Telepresence, by the way, and there is  
interest there in  good quality, high bit rate, audio codec with low  
latency and support for surround sound. Saving bandwidth is not the  
issue there.

Regards
Marshall

> For wideband (16 kHz sampling), I think speech-only (ideally without  
> mutilating background music) is sufficient. However, for super  
> wideband (32 kHz and up), I think it's important to start supporting  
> music. When it comes to latency (by that I mean the codec's  
> algorithmic delay), the lower the better. I consider anything above  
> ~40 ms to be unacceptable (ruling out Vorbis, MP3 and standard AAC),  
> but it should ideally be lower than that. The lower the delay, the  
> less problems you have with acoustic echo.
>
>    Jean-Marc
>
> >but "enhancement" -  everyone can today understand each other via  
> We are talking not about  "enabling technology" to make everyone  
> understand each other (email case), but  "enhancement" -  everyone  
> "recommended"  IWAC- either one or several (agree with Jean-Marc),  
> who is to  enforce?
> forums - examples are PAL/NTSC in  geo, industry - CableLabs), and

---

From: David Singer <[email-masked]>
Date: Wed, 17 Jun 2009 10:41:06 -0700

note that combined speech and audio at moderately low bit-rates is 
fairly cutting edge.  The 3GPP experiments with AMR wideband plus, 
and HE-AACv2, were good, a few years ago, and MPEG has unified speech 
and audio coding under way (with very encouraging early results).
-- 
David Singer
Multimedia Standards, Apple Inc.

---

From: Marshall Eubanks <[email-masked]>
Date: Wed, 17 Jun 2009 13:47:19 -0400

Note also that MP3 can't do this, not with low latency.

Marshall

On Jun 17, 2009, at 1:41 PM, David Singer wrote:

> and HE-AACv2, were good, a few years ago, and MPEG has unified  
> speech and audio coding under way (with very encouraging early  
> results).
> -- 
> David Singer

---

From: "Slava Borilin" <[email-masked]>
Date: Wed, 17 Jun 2009 21:48:45 +0400

We at SPIRIT have done the design of mixed speech+audio codec 5years
ago.

regards,
Slava Borilin

---

From: Jean-Marc Valin <[email-masked]>
Date: Wed, 17 Jun 2009 14:09:08 -0400

David Singer wrote:
> fairly cutting edge.  The 3GPP experiments with AMR wideband plus, and 
> HE-AACv2, were good, a few years ago, and MPEG has unified speech and 
> audio coding under way (with very encouraging early results).

I don't think we want something like AMR-WB+ or HE-AAC. As far as I 
know, AMR-WB+ has around 100 ms delay and HE-AACv2 is probably similar. 
As far as I know, these codecs are mostly designed for streaming music 
on mobile networks, rather than bi-directional communication. I think 
it's worth increasing the bit-rate to have (much!) lower delay, and 
possibly higher quality too. After all, bandwidth on the Internet isn't 
as expensive as it is on 3G wireless networks. I would tend to target a 
range of bitrates that are appropriate for a low- to medium-range ADSL 
connection.

    Jean-Marc

---

From: "Slava Borilin" <[email-masked]>
Date: Wed, 17 Jun 2009 22:21:55 +0400

Right.
100ms is too much. 
SPIRIT's mentioned combined speech+audio codec have 25ms delay.

regards,
Slava Borilin

-----Original Message-----
From: Jean-Marc Valin [mailto:[email-masked]] 
Sent: Wednesday, June 17, 2009 10:09 PM
To: David Singer
Cc: Marshall Eubanks; Henry Sinnreich; Slava Borilin; [email-masked];
Roni Even

    Jean-Marc

---

From: Koen Vos <[email-masked]>
Date: Wed, 17 Jun 2009 16:21:49 -0700

> job that we need not duplicate.

Mobile phones use codecs that are expensive and complex to license though.
And audio quality on mobile phones is mediocre or worse.

koen.

> broadband Internet, let's chose therefore broadband.
>
> Henry
>

---

From: "Dr. Christian Hoene" <[email-masked]>
Date: Thu, 18 Jun 2009 10:34:04 +0200

In order to support a high degree of reliability and available, I  
think the audio codec should support an acceptable operation mode even  
if the bandwidth is low. If the ultra low delay music transmission is  
not possible, the codec shall degrade to 25ms delayed music  
transmission and further degrade to speech quality.

Jean-Marc: What is the coding rate of CELT, if it shall transmit voice  
at a quality of about MOS 3.5?

>> For wideband (16 kHz sampling), I think speech-only (ideally  
>> without mutilating background music) is sufficient. However, for  
>> super wideband (32 kHz and up), I think it's important to start  
>> supporting music. When it comes to latency (by that I mean the  
>> codec's algorithmic delay), the lower the better. I consider  
>> anything above ~40 ms to be unacceptable (ruling out Vorbis, MP3  
>> and standard AAC), but it should ideally be lower than that. The  
>> lower the delay, the less problems you have with acoustic echo.
>>
>>   Jean-Marc
>>

---

From: Henry Sinnreich <[email-masked]>
Date: Thu, 18 Jun 2009 06:33:35 -0700

>MOS 3.5?

It appears MOS metrics are obsolete and inadequate for BB Internet, Telepresence (mostly for business) and Digital Living Room (mostly for consumer). The highest MOS is 5.0 aspired for 3.1 kHz telephony :-)

Also, how do you accommodate metrics for cut-offs of entire sentences, as is the case for congested narrowband channels?

Are there better metrics?

Henry

On 6/18/09 3:34 AM, "Dr. Christian Hoene" <[email-masked]> wrote:

---

From: "Christian Hoene" <[email-masked]>
Date: Thu, 18 Jun 2009 15:51:35 +0200

I do have the opinion that a main design metric beside audio quality,
complexity, costs, and delay shall be reliability. 

We all know that the PSTN has a reliability of about 99.999%. If designing a
reliable Audio over IP codec, we shall consider to make it as robust as
possible. Robust not only against packet losses but also for periods of low
bandwidth.

To make a system reliability, you must make it aware of this failures and
try to cope smartly with them. Thus, a codec which is aware of the packet
loss rate, shall decrease its bit/frame rates. Also, if it operates in the
presence of very high packet losses it stops, it make sense to switch off
the sending of the audio stream. (The encoder might then send a busy signal)

The mean availability of the audio transmissions, calculated over all users,
might be one of the metrics for assessing the performance of an Internet
audio codec.

Christian

From: Henry Sinnreich [mailto:[email-masked]] 
Sent: Thursday, June 18, 2009 3:34 PM
To: Dr. Christian Hoene; Koen Vos
Cc: [email-masked]
Subject: Re: [codec] RE : Codec BOF approved, much work needed

>MOS 3.5?

It appears MOS metrics are obsolete and inadequate for BB Internet,
Telepresence (mostly for business) and Digital Living Room (mostly for
consumer). The highest MOS is 5.0 aspired for 3.1 kHz telephony :-)

Also, how do you accommodate metrics for cut-offs of entire sentences, as is
the case for congested narrowband channels?

Henry

>> Charter:
http://svn.resiprocate.org/rep/ietf-drafts/codec-bof/charter.txt

---

From: "Slava Borilin" <[email-masked]>
Date: Thu, 18 Jun 2009 17:56:42 +0400

For congested networks - I assume that the way to judge the codec is to judge the MOS over TIA-921 network profiles (that's what we use) which covers realistic packet loss and congestion scenarios, and not just "average normally distributed XX% packet loss".

However, the reality is that while making the comparison, one will actually test the whole voice engine, not just the codec inside it.

And normally codec and voiceengine are separate potions of the voip solution.

It is probably possible to test different codecs within the same voiceeenigne, to get the comparative data.

I doubt however, that we can have a codec which does "adapt" to network itself, without upper level (signaling, statistics, etc)

And the scope of designing the complete voiceengine and not just codec part of it, is so much more complex that I do not believe we should even try it.

regards,

Slava Borilin

From: [email-masked] [mailto:[email-masked]] On Behalf Of Henry Sinnreich
Sent: Thursday, June 18, 2009 5:34 PM
To: Dr. Christian Hoene; Koen Vos
Cc: [email-masked]
Subject: Re: [codec]RE : Codec BOF approved, much work needed

Henry

---

From: Henry Sinnreich <[email-masked]>
Date: Thu, 18 Jun 2009 07:11:51 -0700

My sincere apology for continuing this discussion, but this I cannot let this pass:

>We all know that the PSTN has a reliability of about 99.999%.

During the major catastrophes here in the last 10 years the PSTN was out of service for days and weeks and the only communications that worked were over the Internet.
During the 1st few days of the hurricane Katrina the mayor of New Orleans talked to the president using VoIP with WiFi access.

Thanks, Henry

On 6/18/09 8:51 AM, "Christian Hoene" <[email-masked]> wrote:

I do have the opinion that a main design metric beside audio quality, complexity, costs, and delay shall be reliability.

We all know that the PSTN has a reliability of about 99.999%. If designing a reliable Audio over IP codec, we shall consider to make it as robust as possible. Robust not only against packet losses but also for periods of low bandwidth.

To make a system reliability, you must make it aware of this failures and try to cope smartly with them. Thus, a codec which is aware of the packet loss rate, shall decrease its bit/frame rates. Also, if it operates in the presence of very high packet losses it stops, it make sense to switch off the sending of the audio stream. (The encoder might then send a busy signal)

The mean availability of the audio transmissions, calculated over all users, might be one of the metrics for assessing the performance of an Internet audio codec.

Christian

Henry

---

From: Marshall Eubanks <[email-masked]>
Date: Thu, 18 Jun 2009 10:23:44 -0400

> >We all know that the PSTN has a reliability of about 99.999%.

Every time my phone service has been out in the last decade, I was  
told that that didn't count against 99.999%, so I regard
that as marketing, not engineering.

Regards
Marshall

> During the major catastrophes here in the last 10 years the PSTN was  
> out of service for days and weeks and the only communications that  
> worked were over the Internet.
> During the 1st few days of the hurricane Katrina the mayor of New  
> Orleans talked to the president using VoIP with WiFi access.
>
> Thanks, Henry
>
>
> I do have the opinion that a main design metric beside audio  
> quality, complexity, costs, and delay shall be reliability.
>
> We all know that the PSTN has a reliability of about 99.999%. If  
> designing a reliable Audio over IP codec, we shall consider to make  
> it as robust as possible. Robust not only against packet losses but  
> also for periods of low bandwidth.
>
> To make a system reliability, you must make it aware of this  
> failures and try to cope smartly with them. Thus, a codec which is  
> aware of the packet loss rate, shall decrease its bit/frame rates.  
> Also, if it operates in the presence of very high packet losses it  
> stops, it make sense to switch off the sending of the audio stream.  
> (The encoder might then send a busy signal)
>
> The mean availability of the audio transmissions, calculated over  
> all users, might be one of the metrics for assessing the performance  
> of an Internet audio codec.
>
> Christian
>
>
>
> Telepresence (mostly for business) and Digital Living Room (mostly  
> for consumer). The highest MOS is 5.0 aspired for 3.1 kHz  
> telephony :-)
>
> Also, how do you accommodate metrics for cut-offs of entire  
> sentences, as is the case for congested narrowband channels?
>

---

From: Henry Sinnreich <[email-masked]>
Date: Thu, 18 Jun 2009 07:28:20 -0700

Does it make sense to discuss the possible control channel inside the codec?
Henry

On 6/18/09 8:56 AM, "Slava Borilin" <[email-masked]> wrote:

regards,
Slava Borilin

Henry

---

From: "Christian Hoene" <[email-masked]>
Date: Thu, 18 Jun 2009 17:39:23 +0200

It make perfectly sense. For the type of usage scenarios we have in mind
(namely interactive or even simultaneous), audio is transmitted in both
directions. Adding a control channel would give a real advantage to existing
codec designs. 

Adding a voice engine to the codec, it not really any big issue. It has been
describe couple of time in research literature. I bet the IETF have many
experts in this field.

I just like to remind that the RFC 3550 suggests in chapter 10 somewhere
that the RTP profile SHOULD care of rate adaptation. I am wondering why it
is constantly ignored. Of course, we shall discuss whether to include it
into the RTP profile or in the CODEC specification.

Christian

 

From: Henry Sinnreich [mailto:[email-masked]] 
Sent: Thursday, June 18, 2009 4:28 PM
To: Slava Borilin; Dr. Christian Hoene; Koen Vos
Cc: [email-masked]
Subject: Re: [codec]RE : Codec BOF approved, much work needed

For congested networks - I assume that the way to judge the codec is to
judge the MOS over TIA-921 network profiles (that’s what we use) which
covers realistic packet loss and congestion scenarios, and not just “average
normally distributed XX% packet loss”.
 
However, the reality is that while making the comparison, one will actually
test the whole voice engine, not just the codec inside it.
And normally codec and voiceengine are separate potions of the voip
solution.
 
It is probably possible to test different codecs within the same
voiceeenigne, to get the comparative data.
 
I doubt however, that we can have a codec which does “adapt” to network
itself, without upper level (signaling, statistics, etc)
And the scope of designing the complete voiceengine and not just codec part
of it, is so much more complex that I do not believe we should even try it.

regards,
Slava Borilin

  _____  

Henry

---

From: Gregory Maxwell <[email-masked]>
Date: Thu, 18 Jun 2009 09:24:48 -0700

Christian Hoene [[email-masked]] wrote:
> We all know that the PSTN has a reliability of about 99.999%. If designing a reliable Audio over IP codec, we shall 
> consider to make it as robust as possible. Robust not only against packet losses but also for periods of low bandwidth.
> To make a system reliability, you must make it aware of this failures and try to cope smartly with them. Thus, a codec
> which is aware of the packet loss rate, shall decrease its bit/frame rates. Also, if it operates in the presence of very
> high packet losses it stops, it make sense to switch off the sending of the audio stream. (The encoder might then send a
> busy signal) The mean availability of the audio transmissions, calculated over all users, might be one of the metrics for
> assessing the performance of an Internet audio codec.

I agree with this.  This is why good rate adaptability for the total system is important.  I also believe that codes themselves must be adaptable, because switching among multiple codecs is difficult to negotiate and unlikely to work well in situations of inter-operation.

I have found that frames of very short temporal duration are very useful for improving intelligibility in the face of random loss (Tail-drop like loss reduces the advantage of tiny duration frames). With ~4-8ms frames you can take sustained >30% packet loss and still deliver intelligible speech, even without sophisticated packet loss concealment.   For example, with 50% uniform random loss: http://myrandomnode.dyndns.org:8080/~gmaxwell/celt/celt_diner_64kbit_128samp_50pct_loss.wav

Responding to congestion is a more complex issue than simply detecting loss and changing bitrate/framesize.  I think congestion control itself is outside of the scope of this working group, but providing the mechanisms that congestion control requires from the codec (i.e. bitrate/framerate adaptability) is very much on-topic and an important requirement which existing solutions address poorly.   

I'm not generally in favor of achieving congestion control using a codec side channel because congestion should be managed for all streams concurrently and because the codec will not usually have visibility to all congestion related information, such as ECN.

---

From: "Christian Hoene" <[email-masked]>
Date: Thu, 18 Jun 2009 19:42:56 +0200

Hello JM,

> > It make perfectly sense. For the type of usage scenarios we have in
> > mind (namely interactive or even simultaneous), audio is transmitted
> > in both directions. Adding a control channel would give a real
> > advantage to existing codec designs.
> >
> 
> It's generally easy to add such a "side channel" to a codec's bit-stream
> and it only costs a fraction of a bit (e.g. by reserving one combination
> of N bits) when you're not using it. That being said, I tend to think
> there are better solutions, such as handling that communication in
> SIP/SDP and later with RTP/RTCP. This allows to have mechanisms that
> works for all codecs, rather than one mechanism per codec. In any case,
> this is something on which the AVT people should have an input.

Currently, I am not sure what kind of data we need to transmit in a side
channel (some indications on congestion?). Maybe, the loss rates and delay
variation given by RTCP are enough for controlling the sending rate.

> 
> > Adding a voice engine to the codec, it not really any big issue. It
> > has been describe couple of time in research literature. I bet the
> > IETF have many experts in this field.
> >
> Not sure exactly what you mean by "voice engine", but if you mean the
> jitter buffer, echo canceller, and all other algorithms you may need,
> then again I don't see why we would want to include that in a codec
> definition unless there is a very compelling reason. Even assuming we
> add topics like jitter buffers to the new WG's charter (don't know if
> it's a good idea?), any "improved jitter buffer" we would come up with
> would likely also be applicable to other codecs.

Similar to the classic joint-source/channel coding approach for increasing
the efficiency of multimedia transmission, a rate control in the codec makes
sense. In some sense, then the "Internet" is considered as the "channel".

I am not sure whether to include a dejittering buffer. Again, it is a topic
which has been well studied in research and that is fairly well understood.
Also, it should not be many lines of code because CELT does already support
loss and time concealment (as far as I remember).
For example, if a packet has not been arrived, CELT start a loss
concealment. After loss concealment, it might consider to still playout a
packet arrived too late. In such as way. Similar, if many packets (2 or 3)
have been arrived but are not played out, then CELT fastens the playout by
skipping some pitch periods.
If we add something like an very simple jitter buffer algorithm into the
specification, we should assure that all phones using CELT have a minimal
quality. Otherwise, some phones would include a sophisticated jitter buffer,
others none. We should keep in mind to raise the quality of ALL internet
users, not only those who can buy an extensive phone having sophisticated
algorithms.

> > I just like to remind that the RFC 3550 suggests in chapter 10
> > somewhere that the RTP profile SHOULD care of rate adaptation. I am
> > wondering why it is constantly ignored. Of course, we shall discuss
> > whether to include it into the RTP profile or in the CODEC
specification.
> >
> 
> Again, I would tend to side on "include in the RTP profile". Even then,
> assuming one has the loss/bandwidth statistics, I'm not sure what's even
> needed in the RTP profile to allow rate adaptation. One of the main
> issues I've seen seen though is that estimating the network capacity is
> automatically is hard. For example, how do you know if the lost packets
> you see are caused by an excessive bit-rate or if the packets would be
> lost anyway (regardless of the rate). Similarly, how do you know that
> you can increase the bit-rate without causing lost packets?

This should not be an big issue. TCP does these decisions in every
connection. We should ask the IETF expert on congestion control to give us
advice. Or, we can use some simple TCP formula, which calculates the sending
rate taking into account the former sending rate, the losses, the delays and
the packet sizes. 

Cheers,

 Christian

---

From: Koen Vos <[email-masked]>
Date: Thu, 18 Jun 2009 12:49:48 -0700

> describe couple of time in research literature. I bet the IETF have many

The reason for standardizing a codec is to ensure interoperability  
between different parties using that codec. The voice engine has no  
impact on interoperability, and therefore needs no standard.

koen.

---

From: "Slava Borilin" <[email-masked]>
Date: Thu, 18 Jun 2009 23:50:49 +0400

Absolutely.

regards,
Slava Borilin
 
-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Koen Vos
Sent: Thursday, June 18, 2009 11:50 PM
To: [email-masked]
Subject: Re: [codec] RE : Codec BOF approved, much work needed

koen.

---

From: Randell Jesup <[email-masked]>
Date: Thu, 18 Jun 2009 16:46:01 -0400

Gregory Maxwell <[email-masked]> writes:
>I agree with this.  This is why good rate adaptability for the total
>system is important.  I also believe that codes themselves must be
>adaptable, because switching among multiple codecs is difficult to
>negotiate and unlikely to work well in situations of inter-operation. 

It could work ok in theory, but in practice it's unlikely to work well,
especially if done frequently.

>Responding to congestion is a more complex issue than simply detecting
>loss and changing bitrate/framesize.  I think congestion control itself
>is outside of the scope of this working group, but providing the
>mechanisms that congestion control requires from the codec
>(i.e. bitrate/framerate adaptability) is very much on-topic and an
>important requirement which existing solutions address poorly.    

I think the congestion control per se is outside the perview of this
group, but providing the hooks for a congestion-control mechanism to
interact with the codec is quite important.  For example, running this
codec on a TFRC-enabled or DCCP RTP stream - TFRC and DCCP need to be
able to adjust (via the application) the bitrate of the codec in order
to implement congestion control, and perhaps adjust packetization
periods/packet-rates.

Most current voice/audio codecs have no adjustment in-call available, or
at best a very coarse adjustment.

>I'm not generally in favor of achieving congestion control using a
>codec side channel because congestion should be managed for all streams
>concurrently and because the codec will not usually have visibility to
>all congestion related information, such as ECN. 

Right: for example, if you're sending multiple streams, then the
application may have more options for how to adjust packet rates or
bandwidth depending on the characteristics of each stream, and to
balance the tradeoffs (for example, between audio and video streams in
the same session).

-- 
Randell Jesup, Worldgate (developers of the Ojo videophone), ex-Amiga OS team
[email-masked]
"The fetters imposed on liberty at home have ever been forged out of the weapons
provided for defence against real, pretended, or imaginary dangers from abroad."
		- James Madison, 4th US president (1751-1836)

---

From: Henry Sinnreich <[email-masked]>
Date: Thu, 18 Jun 2009 14:59:44 -0700

This and previous contributions lead to a matrix,  such as the following:

Columns: (Place for dealing with congestion):
   Column 1: Application (proprietary, must eat, etc.), or
   Column 2: Protocol standards machinery
Rows:
   Row 1: Codec in-band channel,
  Row 2: RTP machinery,
  Row3:  Network infrastructure (routers, SBC, etc.)

This gives 6 choices to evaluate. Plenty of work for the Codec WG.

Henry

On 6/18/09 3:46 PM, "Randell Jesup" <[email-masked]> wrote:

---

From: "Christian Hoene" <[email-masked]>
Date: Fri, 19 Jun 2009 00:24:14 +0200

Dear Jean-Marc,

> I agree with those goals (having a good jitter buffer, optimising use of
> late packets), but I don't see how specifying them in a codec helps in
> any way. For example, I'm shipping a jitter buffer, an AEC and a noise
> suppressor along with the Speex package, but these are still generic
> algorithms that are not part of the Speex specification and that can be
> used with any other codec. My belief is that when you specify a codec,
> you should specify the least amount that is necessary to ensure
> inter-operability. Otherwise, you end up with kitchen-sink standards
> that prevent further improvements (what if you find a better jitter
> buffer algorithm than the one specified in the standard?). On the other
> hand, if you find an improved jitter buffer algorithm that depends on
> having a certain feature in the codec, you can specify that particular
> feature without specifying the whole jitter buffer.

Jean-Marc, I am sorry, but I cannot understand your argumentation. Let me
explain why: Dejittering buffers and PLCs are both essential components to
ensure high quality. Let's compare the dejittering buffer with the packet
loss concealment (PLC):

The ITU, 3GPP and others have standardized PLC algorithms for many codecs.
PLC is only important for the receiving side and is not required for the
interoperability with the encoder. For example, an encoder using G.711
really does not care whether the receiving side implement the G.711 appendix
1 PLC. Anyhow, the PLC has been standardized. More important than the
algorithm is the interface between protocol stack and decoder. If the
protocol stack can indicate that a packet has not arrived, any PLC algorithm
can start working. Similar, if a packet arrives too late or too early, any
dejittering buffer or time concealment algorithm can try to cope with it.

Thus, I would suggest to define
1. An additional interface between the RTP protocol and the decoder to
indicate lost, late and early packets.
2. Some basic algorithm that conducts loss and time concealment. (Let the
Skypes and SpiritDSPs provide better algorithms than those described in the
standard.)

> Here's a practical example of that from CELT. CELT has two types of
> prediction that can use information from previous frame(s). However, the
> bit-stream includes flags to turn those predictors on or off on a
> frame-by-frame basis. So in good conditions, you can use the prediction,
> but in bad conditions with high losses, you can turn it off and code all
> frames independently (at the cost of a slightly higher bitrate). This is
> the kind of feature that is useful to have in an "Internet codec",
> without the need to specify exactly how the application has to use it.

If a feature is not standardized, some will not implement it. If a feature
is not implemented everywhere, all users will suffer because all users can
call each other.

> The rate adaptation method used by TCP is essentially "keep increasing
> the rate until you start losing packets, at which point, you decrease
> the rate". This is bad for VoIP for (at least) two reasons: 1) it means
> you're guaranteed to end up losing packets and 

Instead of indicating congestion with packet loss, the ECN flag can be used.

> 2) if you have losses
> that are *not* caused by congestion, you end up using the lowest bitrate
> available.

If you have losses not caused by congestion, something is going severely
wrong. Wireless links tend to be quite lossy. However, most wireless links
have FEC and/or ARQ to cope with transmission errors.

Best regards,
  Christian

---

From: Cullen Jennings <[email-masked]>
Date: Thu, 25 Jun 2009 20:49:38 -0700

On Jun 18, 2009, at 6:56 , Slava Borilin wrote:

> For congested networks - I assume that the way to judge the codec is  
> to judge the MOS over TIA-921 network profiles (that’s what we use)  
> which covers realistic packet loss and congestion scenarios, and not  
> just “average normally distributed XX% packet loss”.

Roni brought up and interesting point about looking at how other  
groups doing codec design did the design and evaluation. Just out of  
curiosity, are the TIA-921 profiles what folks doing codec design at  
the ITU use as the basis of design for codecs to run over IP networks?