Re: [xrblock] QoE draft and Channels

[Qin Wu <[e-mail]>]

Agree, as you said, stereo auido signal should rely on the static order, while elementary stream doesn't. So the elementary stream concept may be only apply to multi-view or layered video.

Regards!
-Qin
  ----- Original Message ----- 
  From: Colin Perkins 
  To: Qin Wu 
  Cc: [e-mail] 
  Sent: Thursday, December 08, 2011 7:00 AM
  Subject: Re: [xrblock] QoE draft and Channels


  Qin,


  It's not clear that the components of a stereo audio signal, for example, can be treated like elementary streams. They're certainly carried in RTP in a very different manner.


  Colin






  On 7 Dec 2011, at 12:52, Qin Wu wrote:
    +1
    I believe we should distinguish multiple channnels of audio from multi-views. They are not same thing.
    But one common thing between each other is each channel of audio of each view can be regarded as elementary stream.
    That is to say they both can refer to multiple elementary streams carried in the same RTP stream.
    However for multi-view:
    we also allow each view  carried in the different RTP stream. Just like what it described in the section 1.2 of draft-ietf-payload-rtp-mvc-01:
    "
       This specification allows, in a given RTP packet stream, to
       encapsulate NAL units belonging to

         o the base view only, detailed specification in [RFC6184], or

         o one or more non-base views, or

         o the base view and one or non-base views
    "

    Regards!
    -Qin

      ----- Original Message -----
      From: Colin Perkins
      To: Alan Clark
      Cc: [e-mail]
      Sent: Tuesday, November 29, 2011 1:04 AM
      Subject: Re: [xrblock] 答复: QoE draft and Channels


      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:
        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" <[e-mail]> wrote:


          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

----------------------------------------------------------------------
          发件人: [e-mail] [[e-mail]] 代表 Alan Clark [[e-mail]]
          发送时间: 2011年11月16日 11:09
          到: Qin Wu; [e-mail]
          主题: 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" <[e-mail]<UrlBlockedError.aspx> > wrote:


            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

--------------------------------------------------------------------
            发件人: [e-mail] <UrlBlockedError.aspx>  [[e-mail] <UrlBlockedError.aspx> ] 代表 Alan Clark [[e-mail]<UrlBlockedError.aspx> ]
            发送时间: 2011年11月16日 7:45
            到: [e-mail] <UrlBlockedError.aspx> 
            主题: [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 

            - 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



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








--------------------------------------------------------------------------



      _______________________________________________
      xrblock mailing list
      [e-mail]
      https://www.ietf.org/mailman/listinfo/xrblock


------------------------------------------------------------------------------


  _______________________________________________
  xrblock mailing list
  [e-mail]
  https://www.ietf.org/mailman/listinfo/xrblock