Subject: [codec] Updated Agenda for Codec BOF

From: Jason Fischl <[email-masked]>
Date: Wed, 08 Jul 2009 13:43:27 -0700

Based on the comments from the mailing list, Jean-Marc and I are proposing a
new agenda. Please let me know if we've missed any important topics.

Regards
Jason and Jean-Marc.

AGENDA:

1. Administrative (Chairs, 5 min)
- Note takers, Jabber scribes
- Agenda bashing

2. Introduction and Scoping of BOF (Chairs/ADs, 10 min)

3. What do users want? Goals of the working group. What would success look
like? (15 min)
- What is special about an Internet codec

4. What type of engineering work would this be? ( 25 min )
Have presentations on the two proposed codecs. Focus is to make sure it
looks feasible to do the technical  
work to meet the goals. This should also help clarify what type of work is
being considered.
- http://www.ietf.org/internet-drafts/draft-vos-silk-00.txt
- http://www.ietf.org/internet-drafts/draft-valin-celt-codec-00.txt

5. Do we have the expertise to specify and review Internet-specific codecs?
(15 min)

6. Is this work likely to succeed or fail? Reasons it would fail? (15 min)
- Discussion of odds of success of royalty free

7. HUM on if the IETF should form this WG (All, 15 min)

8. Charter Discussion [Time permitting] (All, 15 min)

9. Conclusions and Next Steps (Chairs/ADs, 5 min)

---

From: "Christian Hoene" <[email-masked]>
Date: Thu, 9 Jul 2009 08:18:00 +0200

> - http://www.ietf.org/internet-drafts/draft-valin-celt-codec-00.txt

I just like to remind the chairs that their is a third proposed codec which
will fulfill the assumed goals of this WG. SBC has a much lower complexity
than CELT and achieves nearly the some quality vs. rate performance
tradeoff. And it has been standardized already.

Christian

---

From: "Roni Even" <[email-masked]>
Date: Thu, 9 Jul 2009 09:56:08 +0300

Hi,
Seeing this comment is making me repeat my suggestion that we should not
present codecs in the BOF. Instead I would like to see a presentation on the
proposed work, will there be one codec from this WG or many codecs all
addressing wideband, open source and RF requirements, I am sure that having
many codecs will help developers choose the right one and achieve great
interoperability, so probably we are talking about one codec.
If you want to have one codec as the outcome than the proposed process
should be presented in the BOF. What are the criteria to decide on
requirements ( already saw some contradictions on the mailing list regarding
algorithmic delay and complexity) and how to select one.
Regards
Roni Even

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On Behalf
> Of Christian Hoene
> Sent: Thursday, July 09, 2009 9:18 AM
> To: 'Jason Fischl'; [email-masked]
> Subject: Re: [codec] Updated Agenda for Codec BOF
> 
> _______________________________________________
> codec mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/codec

---

From: Gregory Maxwell <[email-masked]>
Date: Thu, 9 Jul 2009 07:39:54 -0700

> tradeoff. And it has been standardized already.

You must have an odd definition of "almost equal" as your own publication (http://net.cs.uni-tuebingen.de/html/ristore2net/publications/papers/
hoene2008_itu.pdf) shows a >2:1 bitrate advantage for a year old version of CELT vs SBC.

Since, according to you, we're also a year out from the patents on SBC expiring there is still another year in which competing solutions can widen the performance gap before SBC meets even the most basic of the proposed goals.

I'm also a little confused by your citation of complexity. Just a day or two ago you seemed to be presenting complexity and size as irrelevant for the internet. Thats not a position I agree with, but if we're going to talk complexity we should have goals.  I believe that CELT (at least in low complexity mode) is within the bounds of what reasonable even for low end mobile devices and that going lower has few advantages, but this is a decision which is hard to navigate without some targets.   What do you believe the requirements are for computational complexity as well as static and dynamic memory?

I also agree with the position that Roni has taken in the past that this working group would provide no value as a rubber-stamping venue.  It's not at all clear to me that SBC will meet the eventual requirements. For example, independent coding of frames was considered to be an important 'internet optimization' in iLBC. As far as I know SBC does not provide this.  I'm not sure that that should be an eventual requirement, and I'd prefer some kind of criteria about robustness under loss since independence is only one way to achieve that end ... I think it's the robustness under packet loss which is actually the internet community requirement.  But it could quite reasonably be one.

Of course, that doesn't mean that the IETF should ignore SBC, your RTP draft for SBC seems quite reasonable, I am just far from convinced that it has much relevance here.

---

From: "Christian Hoene" <[email-masked]>
Date: Thu, 9 Jul 2009 17:00:24 +0200

> You must have an odd definition of "almost equal" as your own publication
> (http://net.cs.uni-tuebingen.de/html/ristore2net/publications/papers/
> hoene2008_itu.pdf) shows a >2:1 bitrate advantage for a year old version
of
> CELT vs SBC.

I have to admit that these results were based on a buggy BlueZ
implementation of SBC not on the reference implementation. The current
results look much better with the reference and the corrected BlueZ
implementation. At high rates SBC outperforms CELT 0.5. Currently the tests
for CELT 0.6 are running. However, these results are based all on PEAQ and
therefore are only an indication of quality.

 Christian

---

From: Gregory Maxwell <[email-masked]>
Date: Thu, 9 Jul 2009 08:08:41 -0700

> therefore are only an indication of quality.

If computational complexity is a consideration you should consider using the CELT encoder with complexity 1 (or otherwise without the long term predictor).  It makes the computational load much closer to SBC's and at higher bitrates it only makes a small difference in perceptual performance.

---

From: Henry Sinnreich <[email-masked]>
Date: Thu, 9 Jul 2009 13:30:20 -0700

Having the SBC as a 3rd candidate is good news, though I may have missed any email confirming it.

Given the choice of several candidate codecs, would it make sense to add the following agenda items:

1. IETF policy of taking ownership and change control (by an A-D or IETF legal expert)
2. Selection criteria for the Internet voice codec
3. Testing and evaluation procedure

Opinions?

Thanks, Henry

Christian

---

From: "Slava Borilin" <[email-masked]>
Date: Fri, 10 Jul 2009 00:49:01 +0400

I do support all 3, or at least 1 and 2

________________________________

From: [email-masked] [mailto:[email-masked]] On Behalf
Of Henry Sinnreich
Sent: Friday, July 10, 2009 12:30 AM
To: Christian Hoene; Jason Fischl; [email-masked]
Subject: [codec] Codec BOF agenda: Selection criteria and
evaluation/testing

Having the SBC as a 3rd candidate is good news, though I may have missed
any email confirming it.

Given the choice of several candidate codecs, would it make sense to add
the following agenda items:

1. IETF policy of taking ownership and change control (by an A-D or IETF
legal expert)
2. Selection criteria for the Internet voice codec
3. Testing and evaluation procedure

Opinions?

Thanks, Henry

> - http://www.ietf.org/internet-drafts/draft-valin-celt-codec-00.txt

I just like to remind the chairs that their is a third proposed codec
which
will fulfill the assumed goals of this WG. SBC has a much lower
complexity
than CELT and achieves nearly the some quality vs. rate performance
tradeoff. And it has been standardized already.

Christian