Subject: [codec] Last Call: <draft-ietf-codec-opus-12.txt> (Definition of the Opus Audio Codec) to Proposed Standard

From: The IESG <[email-masked]>
Date: Thu, 26 Apr 2012 13:20:56 -0700

The IESG has received a request from the Internet Wideband Audio Codec WG
(codec) to consider the following document:
- 'Definition of the Opus Audio Codec'
  <draft-ietf-codec-opus-12.txt> as a Proposed Standard

The IESG plans to make a decision in the next few weeks, and solicits
final comments on this action. Please send substantive comments to the
[email-masked] mailing lists by 2012-05-10. Exceptionally, comments may be
sent to [email-masked] instead. In either case, please retain the
beginning of the Subject line to allow automated sorting.

Abstract

   This document defines the Opus interactive speech and audio codec.
   Opus is designed to handle a wide range of interactive audio
   applications, including Voice over IP, videoconferencing, in-game
   chat, and even live, distributed music performances.  It scales from
   low bitrate narrowband speech at 6 kb/s to very high quality stereo
   music at 510 kb/s.  Opus uses both linear prediction (LP) and the
   Modified Discrete Cosine Transform (MDCT) to achieve good compression
   of both speech and music.

The file can be obtained via
http://datatracker.ietf.org/doc/draft-ietf-codec-opus/

IESG discussion can be tracked via
http://datatracker.ietf.org/doc/draft-ietf-codec-opus/ballot/

The following IPR Declarations may be related to this I-D:

   http://datatracker.ietf.org/ipr/1712/
   http://datatracker.ietf.org/ipr/1602/
   http://datatracker.ietf.org/ipr/1445/
   http://datatracker.ietf.org/ipr/1446/
   http://datatracker.ietf.org/ipr/1447/
   http://datatracker.ietf.org/ipr/1741/
   http://datatracker.ietf.org/ipr/1670/
   http://datatracker.ietf.org/ipr/1520/
   http://datatracker.ietf.org/ipr/1524/
   http://datatracker.ietf.org/ipr/1525/
   http://datatracker.ietf.org/ipr/1526/

---

From: "Kevin P. Fleming" <[email-masked]>
Date: Thu, 26 Apr 2012 16:03:37 -0500

> beginning of the Subject line to allow automated sorting.

Now that this draft has reached IETF LC, is it time to resurrect the 
expired draft-spittka-payload-rtp-opus-00 and get it heading towards 
publication by the PAYLOAD WG as well?

-- 
Kevin P. Fleming
Digium, Inc. | Director of Software Technologies
Jabber: [email-masked] | SIP: [email-masked] | Skype: kpfleming
445 Jan Davis Drive NW - Huntsville, AL 35806 - USA
Check us out at www.digium.com & www.asterisk.org

---

From: Jean-Marc Valin <[email-masked]>
Date: Thu, 26 Apr 2012 18:24:20 -0400

> publication by the PAYLOAD WG as well?

Sounds like a good idea! Please send any comment you have.

	Jean-Marc

---

From: "Kevin P. Fleming" <[email-masked]>
Date: Thu, 26 Apr 2012 17:43:33 -0500

> Sounds like a good idea! Please send any comment you have.

Well, it seems like the first thing to do would be to request that 
PAYLOAD adopt it as a working document to meet the December 2012 milestone.

---

From: Cullen Jennings <[email-masked]>
Date: Sun, 29 Apr 2012 10:28:56 -0600

Yes, we should get draft-spittka-payload-rtp-opus-00 moving. 

One suggestion on it ... I suspect it would be easier to get both the RTP payload and storage format done quicker if they were separate into two drafts. Clearly the payload needs to be done in PAYLOAD WG but folks might want to ping the RAI and APPS ADs about where it makes sense to do the storage format - might want to consider Apps for that. 

On Apr 26, 2012, at 3:03 PM, Kevin P. Fleming wrote:

> Now that this draft has reached IETF LC, is it time to resurrect the expired draft-spittka-payload-rtp-opus-00 and get it heading towards publication by the PAYLOAD WG as well?
> 
> -- 
> Kevin P. Fleming
> _______________________________________________
> codec mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/codec

---

From: "Timothy B. Terriberry" <[email-masked]>
Date: Sun, 29 Apr 2012 09:46:43 -0700

Cullen Jennings wrote:
> One suggestion on it ... I suspect it would be easier to get both the RTP
 > payload and storage format done quicker if they were separate into 
two drafts.
 > Clearly the payload needs to be done in PAYLOAD WG but folks might 
want to
 > ping the RAI and APPS ADs about where it makes sense to do the 
storage format
 > - might want to consider Apps for that.

This makes a lot of sense. For the storage format, RFC 3533 (Ogg) was 
done in transport, IIRC. But Apps might be better. Should we be 
targeting standards-track or informational for it?

---

From: Cullen Jennings <[email-masked]>
Date: Sun, 29 Apr 2012 13:07:41 -0600

On Apr 29, 2012, at 10:46 AM, Timothy B. Terriberry wrote:

> > payload and storage format done quicker if they were separate into two drafts.
> > Clearly the payload needs to be done in PAYLOAD WG but folks might want to
> > ping the RAI and APPS ADs about where it makes sense to do the storage format
> This makes a lot of sense. For the storage format, RFC 3533 (Ogg) was done in transport, IIRC. But Apps might be better. Should we be targeting standards-track or informational for it?

The RTP payload needs to be standards track but for the storage format, I can't see much advantage of PS over Info and Info is typically faster but not a big deal either way. I really don't know where the best place to do it is because I suspect there are multiple places where it could be done. But in cases like this, I like to go ask the ADs what they want and then you don't have any later surprises and when people ask you why you choose X instead of Y, you can just tell them the ADs told you so and not have to spend time debating it.

---

From: "Timothy B. Terriberry" <[email-masked]>
Date: Sun, 29 Apr 2012 12:27:12 -0700

Cullen Jennings wrote:
> cases like this, I like to go ask the ADs what they want and then you don't
> have any later surprises and when people ask you why you choose X instead of
> Y, you can just tell them the ADs told you so and not have to spend time
> debating it.

Okay, I'll clean up the storage spec we have in our wiki today and ping 
the ADs about it to see what they think.