Re: [codec] requirements #32 (new): Playout/Dejittering Buffer

"Christian Hoene" <hoene@uni-tuebingen.de> Fri, 25 March 2011 22:51 UTC

From: Christian Hoene <hoene@uni-tuebingen.de>
To: codec@ietf.org
References: <062.b8ceb20e92d29837ff18a0b34358b30a@tools.ietf.org> <071.24cc7558bd70fb6e318a0d645c5ad015@tools.ietf.org>
In-Reply-To: <071.24cc7558bd70fb6e318a0d645c5ad015@tools.ietf.org>
Date: Fri, 25 Mar 2011 23:53:27 +0100
Organization: Universität Tübingen
Message-ID: <001d01cbeb3f$7a5ea0c0$6f1be240$@uni-tuebingen.de>
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: quoted-printable
Thread-Index: AQFCC7KrRJVhEPojDARwIqHBCDXQLwKPcbh7lT3m11A=
Content-Language: de
Subject: Re: [codec] requirements #32 (new): Playout/Dejittering Buffer
Precedence: list

> -----Original Message-----
> From: codec issue tracker [mailto:trac@tools.ietf.org]
> Sent: Tuesday, January 25, 2011 12:51 AM
> To: gmaxwell@juniper.net; hoene@uni-tuebingen.de
> Cc: codec@ietf.org
> Subject: Re: [codec] requirements #32 (new): Playout/Dejittering Buffer
> 
> #32: Playout/Dejittering Buffer
> 
> 
> Comment(by gmaxwell@…):
> 
>  I believe the complete system requirements and detailed testing
>  methodology is out of scope for the CODEC requirements document.
> 
>  I believe the requirements stipulation on real world testing is satisfied
>  by whatever basically reasonable methodology is applied so long as it is
>  applied uniformly and does not offend the consensus of the working group.
>  In other words, I see no reason for our permissive testing requirement to
>  force us to import detailed systems requirements into the codec
>  requirement document, no more than does the mention of "quality" in the
>  document demand that we specific a particular headphone manufacturer for
>  listening tests in this document.
> 
>  Am I missing any reason why this ticket can't be closed?

[Christian Hoene] No, there are some reasons for an addition to the requirement draft.
Many playout buffer algorithms adapt the time of playout during silence. Thus, a codec API mentioning the VAD flag should be include. BTW, it is part of the Silk codec.

In addition, for dropping audio segments during voice activity, a voice/unvoiced indication and a parameter on the length of the current pitch period might be useful. Then, playout can be slowed down or fastened will preserving without clicks. 

In addition to the word document that I have sent out recently, I suggest to add a paragraph

"5.10.  Codec API to support playout rescheduling

 To allow a smooth interaction between playout scheduling and codec, a codec API must be included that provides information on voice activity, voicing, and the length of the current pitch period.  
In addition, the playout shall allow to drop audio segments of arbitrary length or extrapolate the audio signal not only a frame duration but also by arbitrary length, e.g. to add a pitch period."

Yes, if I can be a help I am willing to implement this feature.

Cheers, 

 Christian 








> 
> --
> ------------------------------------+---------------------------------------
>  Reporter:  hoene@…                 |       Owner:
>      Type:  enhancement             |      Status:  new
>  Priority:  major                   |   Milestone:
> Component:  requirements            |     Version:
>  Severity:  Active WG Document      |    Keywords:
> ------------------------------------+---------------------------------------
> 
> Ticket URL: <http://trac.tools.ietf.org/wg/codec/trac/ticket/32#comment:2>
> codec <http://tools.ietf.org/codec/>

[codec] #32: Playout/Dejittering Buffer codec issue tracker
Re: [codec] #32: Playout/Dejittering Buffer codec issue tracker
Re: [codec] requirements #32 (new): Playout/Dejit… codec issue tracker
Re: [codec] requirements #32 (new): Playout/Dejit… Christian Hoene
Re: [codec] #32: Playout/Dejittering Buffer codec issue tracker