Subject: [codec] questions to be answered

From: Peter Saint-Andre <[email-masked]>
Date: Fri, 30 Oct 2009 14:11:46 -0600

RFC 5434 has a list of questions that need to be answered before a WG is
formed, and I think we have fairly clear answers to these questions:

1. Is there a problem that needs solving?

(Yes, see problem statement in charter.)

2. Is the scope of the problem well defined and understood?

(Yes, see objectives in charter, guidelines I-D, and requirements I-D.)

3. Is there agreement on what the WG needs to deliver?

(Yes, see deliverables in charter, guidelines I-D, and requirements I-D.)

4. Are there enough IETF participants to do the work?

(Yes, see codec I-Ds, poll at Stockholm BoF, and list discussion.)

5. Does the WG have a reasonable probability of success?

(Yes, see codec I-Ds, guidelines I-D, and list discussion, with an
emphasis on "reasonable" because we won't know until we try.)

6. Is the IETF is the right place to do the work?

(Maybe. I think this is the major item to clarify at the BoF.)

Peter

- --
Peter Saint-Andre
https://stpeter.im/

---

From: "Roni Even" <[email-masked]>
Date: Sat, 31 Oct 2009 00:34:09 +0200

Hi Peter,
I am not sure that there is a consensus about what the group need to
deliver. I do not feel that the issue of the number of codecs and how to
decide which codecs are in scope for this working group is agreed. My view
that this issue is not addressed since I assume that all the parties that
submitted candidate codecs would like their codecs to be approved at the
IETF which will make this group a rubber stamping WG.
I think that the if the charter describes a list of applications it need to
have a separate requirement for each application on which this proposed
group is going to develop a separate codec. If there is one requirement
document for all apllications there should be one codec to address it.

Thanks
Roni Even

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On Behalf
> Of Peter Saint-Andre
> Sent: Friday, October 30, 2009 10:12 PM
> To: [email-masked]
> Subject: [codec] questions to be answered
> 
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
> 
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.4.8 (Darwin)
> Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
> 
> iEYEARECAAYFAkrrSIIACgkQNL8k5A2w/vxzmQCeINOY/RWKd924HGWH8p4BJmUz
> lHIAnAwhO+Htb6Cxne9b9w/1WEnaRlgP
> =9vPK
> -----END PGP SIGNATURE-----
> _______________________________________________
> codec mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/codec

---

From: Michael Knappe <[email-masked]>
Date: Fri, 30 Oct 2009 16:15:48 -0700

Roni,

On your latter points, how about a set of general benchmark requirements that all codecs must meet, followed by more stringent or more specific criteria to meet narrower requirements of a target application? This could be all coupled together in a single requirements document. A single doc would make it easier to lay out common test methodologies just once, followed by specific application requirements broken out into separate subsequent sections.

Mike

On 10/30/09 3:34 PM, "Roni Even" <[email-masked]> wrote:

Hi Peter,

Thanks
Roni Even

---

From: Michael Knappe <[email-masked]>
Date: Fri, 30 Oct 2009 16:31:38 -0700

Also, I would suggest before Hiroshima we take a stab on email at writing out a short list of both critical and non-critical technical criteria for each application (gaming, interactive music, voice communication, etc). By going through this exercise it will help us all mentally group requirements and should help simplify the overall problem definition (e.g. a) Which application's requirements are supersets of another, b) which application's requirements would have fundamental technical tradeoffs vs another, etc.). If we can narrow down the problem to a couple of fundamental codec 'descriptions', that will be a big help, and if a one-size-fits-all codec is at all possible, it should become easier to recognize.

Mike

On 10/30/09 4:15 PM, "Michael Knappe" <[email-masked]> wrote:

Roni,

Mike

Hi Peter,

Thanks
Roni Even

---

From: Jean-Marc Valin <[email-masked]>
Date: Fri, 30 Oct 2009 20:42:36 -0400

Roni,

I don't believe anyone here intends the WG to produce more than one
codec unless it turns out that doing so is the only way to achieve good
coverage of the requirements. Would you like to see such a statement in
the charter? Personally, I tend to see this question mostly as a
technical issue that will be settled once the technical work gets
started. Believe me, there's nothing I would like more than being able
to address all the requirements we have with a single, unified codec. I
also believe that's what you would also like so see, so we agree on
this. Now technically, I am not yet sure that it is feasible to have a
single codec that does everything we want to do. So I believe it is a
possibility that we would end up with one codec (A) addressing one part
of the requirements and another codec (B) addressing a second part of
the requirements. Sure, we could decide to take those two codecs, put
them in the same proposal and call that one big codec with two
"profiles", but I don't think we would be gaining anything. At this
point in time, saying that we will have a single codec would be assuming
the output of the technical work before it has begun.

It is the same issue with separating requirements. I assume that if we
end up going with two codecs (which is not my first choice), we may need
to split the requirements into two parts. However, at this point not
only is it not clear that we will have more than one codec, but it is
not clear where the split would be if there were to be more than one
codec. I have a few ideas on how the split could be done, but I do not
see how we could be choosing that split before actually working on the code.

Cheers,

	Jean-Marc

---

From: "Gregory M. Lebovitz" <[email-masked]>
Date: Sat, 31 Oct 2009 08:36:55 -0700

I would be comfortable with chartering for 1 or 2 
codecs, under the assumption that one-size does 
not fit all in the world of codecs, and believing 
that we could define one or two application 
spaces that cover a very large need and market 
demand for a application or group of 
applications. Sure, there are probably a handful 
or so different applications that in order to 
cover excellently would require different and 
specific codec technologies, but I think we need 
to focus, deploy, evaluate, and then determine next steps here.

I would oppose a charter that tries to do more 
than one or two applications with corresponding codecs.

I'm most comfortable with one, but could see the 
need for two, and would be willing to live with a charter that included two.

Gregory

---

From: Michael Knappe <[email-masked]>
Date: Sat, 31 Oct 2009 08:42:59 -0700

I will take a rough first crack at a codec application vs criteria table and have it out to the list for discussion on Monday Nov 2nd.

Cheers,

Mike

On 10/30/09 4:31 PM, "Michael Knappe" <[email-masked]> wrote:

Mike

Roni,

Mike

Hi Peter,

Thanks
Roni Even