Subject: Re: [codec] Architectural Considerations

From: Mikael Abrahamsson <[email-masked]>
Date: Sat, 1 Aug 2009 10:09:14 +0200 (CEST)

On Fri, 31 Jul 2009, stephen botzko wrote:

> Today, adaptation to network conditions is a shared responsibility, with 
> some requirements on the codec layer, others on the transport layer, and 
> still others on the application.  Several comments (mostly criticism) of 
> the ITU-T codecs indicate that many of the posters here have a different 
> view of how this architecture is supposed to work.  Many comments are 
> about inadequate response to jitter for instance are not relevant to the 
> codec. They *are* relevant to the RTP transport and to the application's 
> implementation choices, but not to the codec itself.

It's my experience in my professional life that things get more efficient 
if you look at end-to-end, in this case thru all the layers (IP, transport 
and codec) than if you just focus on your "own" layer and blame problems 
on the other layers.

It might be that there indeed are codecs out there that indeed can be 
properly transported in the conditions I have described, but I'd like to 
be able to test this in my lab (which also brings in the RF factor) to 
actually judge whether I personally think it's enough. So what I'd like 
*a* or *several* IETF WG is to come out with a "whole picture" document 
that selects codec, transport and settings/parameters/values for these two 
with firm use cases and recommendations for these, so that it will *work*.

As stated before, I'm *tired* of vendors implementing non-resiliant 
applications and then putting all the requirements on the packet network.

We all need to do our share to make it work, codec, transport and network.

-- 
Mikael Abrahamsson    email: [email-masked]

---

From: stephen botzko <[email-masked]>
Date: Sat, 1 Aug 2009 07:23:41 -0400

We all need to do our share to make it work, codec, transport and
network.
No disagreement here, though I'd add application to the list too.  In fact I
think its what I said.

I do think that we need to understand what the proposed codec group can (and
cannot) fix though, and make sure we set the charter accordingly.  It may be
that Gerard is right when he says that there is no technical reason to form
this group. Maybe there is even consensus on that point, I don't know.

I would like to think that are technical problems that the codec group will
solve, I'd like to see the case presented, in the context of the larger
end-to-end context.  That way we can maybe reach some consensus on the
problem we are trying to solve, and whether the codec is really the issue or
not.

Regards,
Stephen Botzko
Polycom

On Sat, Aug 1, 2009 at 4:09 AM, Mikael Abrahamsson <[email-masked]> wrote:

>> still others on the application.  Several comments (mostly criticism) of the
>> ITU-T codecs indicate that many of the posters here have a different view of
>> how this architecture is supposed to work.  Many comments are about
>> inadequate response to jitter for instance are not relevant to the codec.
>> They *are* relevant to the RTP transport and to the application's
> and codec) than if you just focus on your "own" layer and blame problems on
> the other layers.
>
> properly transported in the conditions I have described, but I'd like to be
> able to test this in my lab (which also brings in the RF factor) to actually
> judge whether I personally think it's enough. So what I'd like *a* or
> *several* IETF WG is to come out with a "whole picture" document that
> selects codec, transport and settings/parameters/values for these two with
> firm use cases and recommendations for these, so that it will *work*.
>

---

From: "Benjamin M. Schwartz" <[email-masked]>
Date: Sat, 01 Aug 2009 13:00:12 -0400

stephen botzko wrote:
> It may be
> this group.

Standards are never written for technical reasons.  Code is written for
technical reasons.  Standards are written for social reasons.

Examples of technical reasons for writing this code can be found on
http://www.celt-codec.org/comparison/

We should also not forget the possibility, emphasized by the SILK, CELT,
and BV32 developers, of further improvement beyond the state of the art by
collaborative technical development within the group.

--Ben