Subject: Re: [payload] [xrblock] QoE draft submitted

From: Qin Wu <[email-masked]>
Date: Wed, 30 Nov 2011 14:53:58 +0800

Hi,
----- Original Message ----- 
From: "Colin Perkins" <[email-masked]>
To: "Qin Wu" <[email-masked]>
Cc: "Alan Clark" <[email-masked]>; "Schwarz, Albrecht (Albrecht)" <[email-masked]>; <[email-masked]>
Sent: Tuesday, November 29, 2011 1:08 AM
Subject: Re: [xrblock] QoE draft submitted

On 16 Nov 2011, at 03:16, Qin Wu wrote:
...
> So for the more precise granularity of MOS, e.g., narrowband, wideband, ultra wideband, why not just use signaling or out band mechanism to indicate that?
...

How much of this can be inferred from the RTP payload type being used in the session, without additional signalling?

[Qin]: AFAIK,
a. the narrowband, wideband and ultrawideband only apply to audio applications or audio codecs.
b. audio codecs tend evolving from narrowband to wideband, or from wideband to ultra wideband.
c. most audio codec only support one mode, e.g.,
G.729 only supports narrowband, G.729.1 only supports wideband and G.729.1 SWB  ony support ultra wideband.
AMR-NB support narrowband, AMR-WB support wideband and AMR-WB+ support ultra wideband.
but this doesn't mean that one RTP payload for audio application is not possible to support both narrowband and wideband, e.g., EVRC-NW, EV-VBR.
In EVRC-NW, Encoding capability identification in the payload header is used to indicate if wideband or narrowband is used.
In EV-VBR, Layer identificiation value in the payload format can be used to indicate if narrowband or wideband is used.

So to my understanding, in most cases, payload type can be used to indicate if narrowband or wideband is used in the audio applications.
However in very few other cases, you may need additional information in the payload format to faciliate your identification.
For all the video applications, we don't need such feature.

-- 
Colin Perkins
http://csperkins.org/