Re: [xrblock] Multiple channels in RTP streams

[Qin Wu <[e-mail]>]

Multiple channels in RTP streamsIt looks multichannel in 3 cases has different meaning and not sure we can interpret or abstract it into the channel concept.
E.g., In multiple channel audio case(i.e., stereo audio application), multi-channel can be categorize into left audio channel, right audio channel, etc.
In Multiview video case, multiview can be catorized into left view, right view, etc.
I am not sure we can unify multiview video and multi-channel audio into channel concept.

In MPEG Transport Stream case, a transport stream used in digital television might contain multiple programs, to represent multiple television channels
each channel may consists of multiple video streams, multiple audio streams, and any necessary metadata, if we take 13 bits PID as channel ID or identity for each elementary stream(e.g.,
video stream, audio stream), channel ID is quite confusing with television channels. But I assume you are refering to the identity for each elementary stream.

As for these three use cases, I am not convinced that the 2nd case and 3rd case are two valid cases.
In multiview video case, follow the rules specifed in the section 5.2 of RFC3550, each view
SHOULD be carried in a separate RTP session/RTP stream. This allow the receiver use SSRC to identify each view
and use CNAME to group all the view belong to the same source together.
In according to RFC3550, put the all the views in the same RTP stream is a good design. 

In MPEG Transport Streams, I think we should more focus RTP stream or how MPEG TS is carried over RTP, how RTP reciever 
demultiplex the RTP streams using Session multiplexing specified
in RFC3550 and SSRC multiplexing specified in RFC4588. I am not aware that RTP define any other mechanim to demultiplex each elementary 
stream in one MPEG Transport stream. I am not sure this is XRBLock or AVTCore scope to specify PID multiplexing mechanism or use 
such mechanism specified somewhere else to differenitate each elementary stream in the MPEG Transport Stream?
Also I am not sure we can identify which PID beong to which source unless we have out band signaling specified to indicate such mapping.

So It will be more sensible to limit channel concept only to audio application if we do have ways to identify each channel in the audio application and map each channel to RTP stream.

Regards!
-Qin
  ----- Original Message ----- 
  From: Alan Clark 
  To: [e-mail] 
  Sent: Thursday, November 17, 2011 10:46 AM
  Subject: [xrblock] Multiple channels in RTP streams



  On the question of multiple channels in RTP streams - it may be helpful to have some practical examples to use for reference and as examples.  This may also answer one question in the XRBLOCK session which related to the numbering of the channels in the case of multichannel audio.

  (i) Multichannel Audio
  RFC3551 defines an RTP profile for Audio and Video Conferences.  Section 4 describes the convention for multichannel sample based audio encodings - which is to interleave samples using the orderings

  Channels        1    2    3    4    5    6
  2                      L    R
  3                      L    R    C
  4                      L    C    R    S
  5                      FL  FR  FC  SL  SR
  6                      L    LC   C   R    RC    S

  This is generally consistent with the AIFF-C format, which is widely used for multichannel audio - and uses this interleaved approach.  Note that this does define an ordering, and hence channels 1, 2, 3, 4.. can be interpreted in terms of Left, RIght etc.  Other IETF RFC's that relate to multichannel audio include RFC3190, RFC4184, RFC5691 .....

  (ii) MPEG Transport Streams
  An MPEG Transport stream comprises multiple channels of video and/or audio carried in MPEG Transport packets, with each media stream identified by PID.  A typical single program stream might have, for example, one video stream and two audio streams (for two languages) plus additional streams for captions, contents (PAT/PMT).  This MPEG Transport Stream is carried in a single RTP session.  A typical use case would require the reporting of a Video MOS for the video stream and an Audio MOS for each of the audio streams.
   
  (iii) Multi-view Video
  Multi-view video generally covers 3D, multiple viewpoint video and other similar applications.  Work on this has been performed within MPEG/VCEG as extensions to H.264 and an RTP payload format was proposed in draft-ietf-avt-rtp-mvc. 

  Best Regards

  Alan






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


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