Re: [codec] requirements #23 (new): Impact of packet headers and header compression

["Christian Hoene" <[e-mail]>]

Hi 

> -----Original Message-----
> From: codec issue tracker [mailto:[e-mail]]
> Sent: Tuesday, January 25, 2011 12:43 AM
> To: [e-mail]; [e-mail]
> Cc: [e-mail]
> Subject: Re: [codec] requirements #23 (new): Impact of packet headers and
> header compression
> 
> #23: Impact of packet headers and header compression
> 
> 
> Comment(by gmaxwell@…):
> 
>  Vaguely related: http://tools.ietf.org/id/draft-ietf-codec-
>  requirements-02.txt
>  Section 1. "Codec bit-rates in bits per second (b/s) will be considered
>  without counting any overhead (IP/UDP/RTP headers, padding, ...)." and
>  Section 4.2 " When comparing the bit-rate of codecs, the overhead of
>  IP/UDP/RTP headers should not be considered, but any additional bits
>  required in the RTP payload format after the header (e.g. required
>  signalling) should be considered. "
> 
>  Because header overhead is generally dependent on the transport, and not
>  our activities I don't believe that we really have much to require here
>  from the codec itself.
> 
>  Unless someone has some specific proposed requirement language to
> suggest,
>  I propose that we close this ticket and leave any requirements related to
>  RTP packetization to the specific RFCs describing the packetization.
[Christian Hoene] 

I think that it is important to note that a single optimization criteria is not enough to cope with the effect of packet overhead.

Thus, I suggest that the codec shall not be tested nor optimized against bit rate but also consider frame rates (as latter reduces the packet overhead).
Thus, the codec is a multi-parameter optimization problems which audio quality, bit rate, frame rate, complexity, and latency (among others).

Bringing this down to the contest of audio quality vs. bit rate is somewhat simplistic albeit it has a long tradition in the codec developers' community. Also, this contest cannot be won by Opus (nor it should), as some recent publications at AES San Francisco have shown.

However, as already mentioned in the Word document, this view (bit rate vs. quality) is still to be found in the requirements document.  IMHO, this makes no sense.

With best regards,

 Christian