I kind of like the joint body idea. One reason is that it brings the ITU codec characterization/testing strengths into the process.
Though it might take a little longer to get going, it could save a lot of time at the end (IMHO). Stephen Botzko Polycom On Tue, Jan 12, 2010 at 12:03 PM, Jean-Marc Valin < [email protected]> wrote: > Hi Adrian, > > During the last BoF in Hiroshima, there was a very useful presentation by > Yusuke Hiwasaki (SG16-Q10 Associate Rapporteur) about how the ITU-T works > (slides at: http://www.ietf.org/proceedings/76/slides/codec-2.pdf). From > what I understand, there are two main reasons why the ITU-T cannot take on > this work by itself: > 1) Membership isn't open like the IETF, but most importantly > 2) IPR/licensing issues cannot be discussed during the development period > > There were two proposed workarounds to these (see slide 15). First a focus > group was proposed to allow non-ITU members to discuss. Unfortunately, that > solution does not address the IPR issue, nor does it address the fact that > ITU focus groups cannot create standards in the first place. So the only > alternative that was left was to do a joint body with an IETF WG (similar > to the JVT between MPEG and ITU that led to H.264). That means we need an > IETF WG that can actually develop codecs to begin with. > > In general, I think it's really time to get the work going and, as Monty > put it, not get into meeting pre-meetings to discuss whether we will hold > future meetings. At this point, there is significant interest, there are > people willing to do the work and there are even four proposals on the > table. Right now, the only concern that has been expressed over this work > was about having one more codec that vendors would have to support. I don't > think that's a very strong argument considering the existing number of > codecs out there and especially the fact that what we are proposing here is > to take *four* non-standard codecs and make one standard codec out of them. > I can't see how that would be a bad thing. > > Cheers, > > Jean-Marc > > > > Adrian Farrel wrote: > > Stefan, > > > >> until now other SDOs have failed to produce a widely distributed good > >> quality wideband and full-band codec that would be suitable for the > >> Internet - especially one that is easily distributable - even though the > >> necessary technology has been available for a long time. Further, > nothing > >> has substantially changed lately to make it likely that other SDOs are > >> now > >> suddenly willing to or capable of doing that. > >> > >> The proposal to make IETF CODEC development depend on other SDOs is thus > >> not a constructive one and should not be followed. > > > > Your logic may be flawed. > > > > Until now the IETF has failed to produce a widely distributed good > > quality wideband and full-band codec that would be suitable for the > > Internet - especially one that is easily distributable - even though the > > necessary technology has been available for a long time. > > > > But you don't suggest that as a reason not to do the work in the IETF. > > > > The proposed draft charter does not state that the IETF work should be > > gated > > on other SDOs nor that the IETF shall not develop a Codec. Rather, it > > states > > the value of sharing the requirements work developed in the IETF with > other > > SDOs, and it notes the benefits of listening to other SDOs if they point > to > > existing Codecs that meet or nearly meet the requirements. > > > > In the unlikely event that another SDO says "thanks for the requirements > we > > would like to develop a solution in our SDO" we will need to examine the > > feasibility of their proposal and how people can best work on a solution. > > There does not seem to be any benefit in developing two Codecs to meet > the > > same set of requirements. > > > > As to Xavier's point: I think he is right that the wording in the charter > > could be usefully re-ordered so that the consultation is mentioned before > > the determination to develop a new solution. > > > > Cheers, > > Adrian > > > > _______________________________________________ > > codec mailing list > > [email protected] > > https://www.ietf.org/mailman/listinfo/codec > > _______________________________________________ > codec mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/codec >
_______________________________________________ Ietf mailing list [email protected] https://www.ietf.org/mailman/listinfo/ietf
