Subject: [xrblock] QoE draft and Channels

From: Alan Clark <[email-masked]>
Date: Tue, 15 Nov 2011 18:45:40 -0500

I reviewed some of last night¹s XRBLOCK discussion on the video recordings -
and noted that there was some confusion around the use of channels in (the
former AVT WG draft reverted to ) my QoE draft.  The concept is very simple.
In some cases the media stream carried within a single RTP session (same
SSRC) may carry multiple channels of audio and/or video. Examples include

- Stereo audio or audio/ surround sound streams with 4-5 channels

- Multiprogram MPEG Transport Stream encapsulated in a single RTP stream
- A single program MPEG Transport Streams encapsulated in a single RTP
stream 
   - As MPEG transport streams do of course carry multiple audio and video
streams identified by PID

- Multiview video streams ?

Since this can result in more than one MOS score for the same media stream
it makes sense to allow for a report block to contain a set of related QoE
metrics.  While you could of course simply have a report block that
contained one MOS value and repeat it - you simply end up repeating the
block header many times, which is inefficient.

Alan

---

From: Qin Wu <[email-masked]>
Date: Wed, 16 Nov 2011 02:40:33 +0000

Hi, Alan:
Do we really need to distinguish different channels of  audio or video carried in one single RTP session?
If audio channel and video use the same channel namespace? How to understand the channel? left audio channel, right audio channel?
e.g.,
Option 1: audio stream 1 is corresponding to channel 1, audio stream 2 is corresponding to channel 1, video stream is corresponding to channel 1
Option 2: audio stream 1,2, and video stream 3 are corresponding to channel 1, 2, 3 respectively?
which option is the one you think in the mind?

Suppose  3 channels of audio and one channel of video carried in the same RTP stream?
How do you identify each audio channel or video channel at the RTP layer?
Do we have channel id that can be obtained from the RTP packets or just gather these information
from terminal end point? since I am not sure we really carry these information using RTP packet?

So I think if you really want to know  which audio channel data is related to which video channel data
and try to keep audio channel and video channel data together, the best way is to use SSRC.
If you think it is necessary to distinct audio channel from video channel, I think RTP packet doesn't
define any clue for the channel?

Since MOS is used to reflect the comprehensive user experience, why do we need to report MOS score for each channel?
why not put the related channel together and report comprehensive MOS value?

Regards!
-Qin
________________________________
发件人: [email-masked] [[email-masked]] 代表 Alan Clark [[email-masked]]
发送时间: 2011年11月16日 7:45
到: [email-masked]
主题: [xrblock] QoE draft and Channels

I reviewed some of last night’s XRBLOCK discussion on the video recordings - and noted that there was some confusion around the use of channels in (the former AVT WG draft reverted to ) my QoE draft.  The concept is very simple.  In some cases the media stream carried within a single RTP session (same SSRC) may carry multiple channels of audio and/or video. Examples include

- Multiprogram MPEG Transport Stream encapsulated in a single RTP stream
- A single program MPEG Transport Streams encapsulated in a single RTP stream
   - As MPEG transport streams do of course carry multiple audio and video streams identified by PID

Since this can result in more than one MOS score for the same media stream it makes sense to allow for a report block to contain a set of related QoE metrics.  While you could of course simply have a report block that contained one MOS value and repeat it - you simply end up repeating the block header many times, which is inefficient.

Alan

---

From: Alan Clark <[email-masked]>
Date: Tue, 15 Nov 2011 22:09:21 -0500

Hi Qin

I’m not trying to dictate how audio and video streams should be carried -
only pointing out that there are common use cases in which the media stream
transported within a single RTP session may have multiple audio and video
streams.

(a) MPEG Transport
In this case the audio and video streams are carried within separate MPEG
transport packets identified by PID however the entire MPEG transport stream
may be carried within a single RTP session.  In this case the PID could be
used as a channel identifier.

(b) Multichannel audio
The audio streams are in general going to the same destination and it may be
sufficient to identify them as streams 1, 2, 3...  It is useful to know that
one of the streams is degraded in quality - and it is more helpful to know
that audio channel 1 has a MOS of 2.0 and channel 2 a MOS of 4.0 than to
know that the combined MOS is 3.0.

The goal should always be to provide information that helps the service
provider or network manager to understand what the problem is - providing an
overall audio/video score is useful to give an overall indicator of
performance but you still need the individual audio and video scores in
order to know what is broken.

Best Regards

Alan

On 11/15/11 9:40 PM, "Qin Wu" <[email-masked]> wrote:

> If audio channel and video use the same channel namespace? How to understand
> the channel? left audio channel, right audio channel?
> e.g., 
> Option 1: audio stream 1 is corresponding to channel 1, audio stream 2 is
> corresponding to channel 1, video stream is corresponding to channel 1
> I reviewed some of last night’s XRBLOCK discussion on the video recordings -
> In some cases the media stream carried within a single RTP session (same SSRC)
> may carry multiple channels of audio and/or video. Examples include
> 
> Since this can result in more than one MOS score for the same media stream it
> makes sense to allow for a report block to contain a set of related QoE
> metrics.  While you could of course simply have a report block that contained
> one MOS value and repeat it - you simply end up repeating the block header
> many times, which is inefficient.
> 
> Alan
> 
> 
> 
>

---

From: "Romascanu, Dan (Dan)" <[email-masked]>
Date: Wed, 16 Nov 2011 04:27:17 +0100

Hi Alan,

The confusion we had in the meeting was related to how channels are
identified, and whether there is any connection / mapping with channels
on stereo (L, R) for example. You seem to say this is one of the cases -
then how do we identify L is 1 and R is 2 for example. 

Dan

From: [email-masked] [mailto:[email-masked]] On
Behalf Of Alan Clark
Sent: Wednesday, November 16, 2011 1:46 AM
To: [email-masked]
Subject: [xrblock] QoE draft and Channels

I reviewed some of last night's XRBLOCK discussion on the video
recordings - and noted that there was some confusion around the use of
channels in (the former AVT WG draft reverted to ) my QoE draft.  The
concept is very simple.  In some cases the media stream carried within a
single RTP session (same SSRC) may carry multiple channels of audio
and/or video. Examples include 

- Multiprogram MPEG Transport Stream encapsulated in a single RTP stream
- A single program MPEG Transport Streams encapsulated in a single RTP
stream 
   - As MPEG transport streams do of course carry multiple audio and
video streams identified by PID

Since this can result in more than one MOS score for the same media
stream it makes sense to allow for a report block to contain a set of
related QoE metrics.  While you could of course simply have a report
block that contained one MOS value and repeat it - you simply end up
repeating the block header many times, which is inefficient. 

Alan

---

From: Qin Wu <[email-masked]>
Date: Wed, 16 Nov 2011 03:45:52 +0000

Hi, Alan:
I know it is beneficial for troubleshooting and fault precise location.
But if we take MPEG TS as transport, it looks to me that we are looking for TS specific solution for MOS calculation.
However what about the audio and video take other transport rather than MPEG TS transport?
Another argument is I think when we have multiple channel audios, the multiple channels of  audio in most cases will be
transported in the same RTP stream, if audio in the channel 1 is lost, it also means audio in the channel 2 is lost.
In other  words, if audio channel 1 and channel 2 both degrade, they will degrade in the same level.

So the question is:
Do we have other more general ways?

Regards!
-Qin
________________________________
发件人: [email-masked] [[email-masked]] 代表 Alan Clark [[email-masked]]
发送时间: 2011年11月16日 11:09
到: Qin Wu; [email-masked]
主题: Re: [xrblock] 答复: QoE draft and Channels

Hi Qin

I’m not trying to dictate how audio and video streams should be carried - only pointing out that there are common use cases in which the media stream transported within a single RTP session may have multiple audio and video streams.

(a) MPEG Transport
In this case the audio and video streams are carried within separate MPEG transport packets identified by PID however the entire MPEG transport stream may be carried within a single RTP session.  In this case the PID could be used as a channel identifier.

(b) Multichannel audio
The audio streams are in general going to the same destination and it may be sufficient to identify them as streams 1, 2, 3...  It is useful to know that one of the streams is degraded in quality - and it is more helpful to know that audio channel 1 has a MOS of 2.0 and channel 2 a MOS of 4.0 than to know that the combined MOS is 3.0.

The goal should always be to provide information that helps the service provider or network manager to understand what the problem is - providing an overall audio/video score is useful to give an overall indicator of performance but you still need the individual audio and video scores in order to know what is broken.

Best Regards

Alan

On 11/15/11 9:40 PM, "Qin Wu" <[email-masked]<UrlBlockedError.aspx>> wrote:

Hi, Alan:

Regards!
-Qin
________________________________
发件人: [email-masked]<UrlBlockedError.aspx> [[email-masked]<UrlBlockedError.aspx>] 代表 Alan Clark [[email-masked]<UrlBlockedError.aspx>]
发送时间: 2011年11月16日 7:45
到: [email-masked]<UrlBlockedError.aspx>
主题: [xrblock] QoE draft and Channels

Alan

---

From: Alan Clark <[email-masked]>
Date: Tue, 15 Nov 2011 23:11:24 -0500

Hi Qin

I don’t think you understood the point - there are a number of use cases in
which multiple channels of audio and/or video can be carried within a single
RTP session.  No-one is trying to find a custom MPEG TS solution - this is
just one of a number of cases in which there are multiple channels to deal
with.

With regard to your comments about loss in audio on channel 1 vs 2 - you
should think about this one a little more.  For example, what if there is an
issue with the audio source and one channel has a high noise level but the
other is ok?

Alan

On 11/15/11 10:45 PM, "Qin Wu" <[email-masked]> wrote:

> I’m not trying to dictate how audio and video streams should be carried - only
> pointing out that there are common use cases in which the media stream
> that audio channel 1 has a MOS of 2.0 and channel 2 a MOS of 4.0 than to know
> that the combined MOS is 3.0.
> 
> performance but you still need the individual audio and video scores in order
> to know what is broken.
> 
> Best Regards
> 
> Alan
> 
> On 11/15/11 9:40 PM, "Qin Wu" <[email-masked] <UrlBlockedError.aspx> >
> wrote:
> 
>> Hi, Alan: 
>> Since MOS is used to reflect the comprehensive user experience, why do we
>> need to report MOS score for each channel?
>> 发件人: [email-masked] <UrlBlockedError.aspx>
>> [[email-masked] <UrlBlockedError.aspx> ] 代表 Alan Clark
>> [[email-masked] <UrlBlockedError.aspx> ]
>> 发送时间: 2011年11月16日 7:45
>> 到: [email-masked] <UrlBlockedError.aspx>

---

From: Qin Wu <[email-masked]>
Date: Wed, 16 Nov 2011 07:25:46 +0000

Except MPEG TS solution(i.e., channel is viewed as program and choose PID as channel id), would you like to point me other possible solutions?

Suppose each channel/program in the Transport stream consists of one video stream, one or two audio streams, I think we still use SSRC to keep these related streams together.

Even each stream use different SSRC, we can use CNAME to group them together. do we really need channel id to group them together?

For each stream,  MOS value can be easily calculated based on algorithms specified in ITU-T.

For each channel, I am wondering how to set the weight of each stream?

Regards!

-Qin

________________________________
发件人: Alan Clark [[email-masked]]
发送时间: 2011年11月16日 12:11
到: Qin Wu; [email-masked]
主题: Re: 答复: 答复: QoE draft and Channels

Hi Qin

I don’t think you understood the point - there are a number of use cases in which multiple channels of audio and/or video can be carried within a single RTP session.  No-one is trying to find a custom MPEG TS solution - this is just one of a number of cases in which there are multiple channels to deal with.

With regard to your comments about loss in audio on channel 1 vs 2 - you should think about this one a little more.  For example, what if there is an issue with the audio source and one channel has a high noise level but the other is ok?

Alan

On 11/15/11 10:45 PM, "Qin Wu" <[email-masked]<https://imail.huawei.com/OWA/UrlBlockedError.aspx>> wrote:

Hi, Alan:

So the question is:

Regards!
-Qin
________________________________
发件人: [email-masked]<https://imail.huawei.com/OWA/UrlBlockedError.aspx> [[email-masked]<https://imail.huawei.com/OWA/UrlBlockedError.aspx>] 代表 Alan Clark [[email-masked]<https://imail.huawei.com/OWA/UrlBlockedError.aspx>]
发送时间: 2011年11月16日 11:09
到: Qin Wu; [email-masked]<https://imail.huawei.com/OWA/UrlBlockedError.aspx>
主题: Re: [xrblock] 答复: QoE draft and Channels

Hi Qin

(a) MPEG Transport

(b) Multichannel audio

Best Regards

Alan

On 11/15/11 9:40 PM, "Qin Wu" <[email-masked]<https://imail.huawei.com/OWA/UrlBlockedError.aspx> <UrlBlockedError.aspx> > wrote:

Hi, Alan:

Regards!
-Qin
________________________________
发件人: [email-masked]<https://imail.huawei.com/OWA/UrlBlockedError.aspx> <UrlBlockedError.aspx>  [[email-masked]<https://imail.huawei.com/OWA/UrlBlockedError.aspx> <UrlBlockedError.aspx> ] 代表 Alan Clark [[email-masked]<https://imail.huawei.com/OWA/UrlBlockedError.aspx> <UrlBlockedError.aspx> ]
发送时间: 2011年11月16日 7:45
到: [email-masked]<https://imail.huawei.com/OWA/UrlBlockedError.aspx> <UrlBlockedError.aspx>
主题: [xrblock] QoE draft and Channels

Alan

---

From: Colin Perkins <[email-masked]>
Date: Mon, 28 Nov 2011 17:04:08 +0000

Alan,

I agree that these are potentially useful things to report, but I'm not convinced that a single mechanism is appropriate. The requirements for QoE reporting on multi-channel audio, where the RTP payload format supports multiple channels, with a static ordering, and signalled during session setup, would seem to be quite different from those for an MPEG TS where the channel setup is opaque to the RTP layer, and can change over time.

Colin

On 16 Nov 2011, at 04:11, Alan Clark wrote:
>> On 11/15/11 9:40 PM, "Qin Wu" <[email-masked] <UrlBlockedError.aspx> > wrote:
>> 
>>> Hi, Alan: 
>>> 发件人: [email-masked] <UrlBlockedError.aspx>  [[email-masked] <UrlBlockedError.aspx> ] 代表 Alan Clark [[email-masked] <UrlBlockedError.aspx> ]
>>> 发送时间: 2011年11月16日 7:45

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