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 <
jean-marc(_dot_)valin(_at_)octasic(_dot_)com> 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
codec(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/codec
_______________________________________________
codec mailing list
codec(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/codec
_______________________________________________
Ietf mailing list
Ietf(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/ietf