1 / 19

Christian Groves

Describing Captures in CLUE and relation to multipoint conferencing draft-groves-clue-multi-content-00 CLUE Interim meeting (09/13). Christian Groves. Introduction. One major objective for Telepresence is to be able to preserve the "Being there" user experience.

walden
Télécharger la présentation

Christian Groves

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. Describing Captures in CLUE and relation to multipoint conferencing draft-groves-clue-multi-content-00 CLUE Interim meeting (09/13) • Christian Groves

  2. Introduction • One major objective for Telepresence is to be able to preserve the "Being there" user experience. • However, in multi-site conferences it is often (in fact usually) not possible to simultaneously provide full size video, eye contact, common perception of gestures and gaze by all participants. • Several policies (i.e. switched / composed) can be used for stream distribution and display: all provide good results but they all make different compromises. • CLUE currently describes the policies for the multisite case but not much else. 2

  3. Issues 1 • Role of an MCU in a multipoint conference • It provides a central control point, providing information to participants. • Several methods have been defined around this functionality: • Conference Event Package RFC4575 • Extension to Conference Event Package RFC6501 • Centralized Conferencing Manipulation Protocol (CCMP) RFC6503 • There is no direct relation to CLUE captures/scenes etc. • Note: it should be possible to have a CLUE multipoint conference without these. 3

  4. Issues 2 • Relation to scene • The current “switched” and “composed” attributes are specified at capture level, but • They effectively describe how remote scenes are mixed into a capture. • CLUE currently doesn’t allow information about these remote scenes to be described when “switched” or “composed” is used. 4

  5. Issues 3 • Description of switched/composed capture contents • CLUE allows attributes to be associated with a capture. • If multiple captures are aggregated into a composed or switched capture it becomes difficult to relate capture common attributes: • Ie. (role=speaker,language=English),(role=audience,language=french) • becomes: • (role=speaker,audience,language=french,english) • It’s not clear what the intent of this construction would be. 5

  6. Issues 4 • Attribute Interactions • Its not clear in the current specification what the interaction is between the “switched” and “composed” attribute. • Policy • "Scene-switch-policy“ allows the indication of whether switched captures are “site” or “segment” switched. • No indication of the trigger, e.g. “loudest speaker, round robin” • Media Stream Composition and encoding • Needs to be clarified whether single or multiple streams are used for switched captures. 6

  7. Issues 5 • Simultaneous Transmission Sets • Potential confusion between “switched” capture scene entry and the requirement in section 8 that indicates that all captures in a CSE can be used simultaneously. • Conveying Spatial Information • It is unclear how spatial information would be utilised with switched captures. • Consumer selection • This issue seems to have been agreed. No consumer selection. 7

  8. Proposal • Principles • It should be possible to advertise the individual captures that make up a single switched/composed media stream before receiving the actual media stream. • It should be possible to describe the relationship between captures that make up a single switched/composed media stream. • It should be possible to describe this using CLUE semantics rather than with terms such as "site" or "segment" which need their own definition. • Whether media is composed, segment switched, site switched the common element is that the media stream contains multiple captures from potentially multiple sources. 8

  9. Proposal cont. 1 • New Capture Type “Multiple Content Capture (MCC)” • Its function is to indicate that multiple captures are combined into a single capture. • Definition: MCC - Media capture for audio or video that indicates the capture contains multiple audio or video captures. Individual media captures may or may not be present in the resultant capture encoding depending on time or space. • Captures in an MCC may be from different scenes. • Example: • CS#1(VC1,VC2) • CS#2(VC3,VC4) • CS#3(MCC1(VC1,VC3)) 9

  10. Proposal cont. 2 • Multiple Content Capture Details • Each MCC has a unique id (as per other captures). This allows also captures within the MCC to be referenced by a single ID. • Only one media type allowed in a MCC • If used within a CSE that CSE may also reference another scene • More than one MCC is allowed in a CSE. This allows several MCC captures to represent a scene. • May have MCC only attributes associated with it. • MaxCaptures: Indicates the maximum number of captures that may appear in a MCC capture encoding. • CompositionPolicy: Indicates the algorithm/policy for determining what appears in a MCC capture encoding. • Synchronisation: This attributes synchronises the switching of multiple MCCs. 10

  11. Proposal cont. 3 • Encodings • MCCs shall be assigned an encoding group. • Captures referenced by a MCC do not need an encoding. • Allows an advertiser to indicate Capture attributes without the need to provide an encoding. • However it may also provide an encoding for individual captures also • Signalling Transmission Sets • MCCs may be used an STS indicating which MCCs may be used together. 11

  12. Proposal cont. 4 • Consumer Behaviour • On receipt of an advertisement with an MCC the Consumer treats the MCC as per other individual captures with the following differences: • The Consumer would understand that the MCC is a capture that includes the referenced individual captures and that these individual captures would be delivered as part of the MCC's capture encoding. • The Consumer may utilise any of the attributes associated with the referenced individual captures and any capture scene attributes from where the individual capture was defined to choose the captures. • The Consumer may or may not want to receive all the indicated captures. Therefore it can choose to receive a sub-set of captures indicated by the MCC. 12

  13. MCU Behavior Examples • Received Advertisements • Four endpoints are involved in a CLUE session. To formulate an Advertisement to endpoint 4 the following Advertisements received from endpoint 1 to 3 and used by the MCU. Note: The IDs overlap in the incoming advertisements. The MCU is responsible for making these unique in the outgoing advertisement. • Endpoint 1 CaptureScene1[Description=AustralianConfRoom, VC1(role=audience)] • Endpoint 2 CaptureScene1[Description=ChinaConfRoom, VC1(role=speaker),VC2(role=audience), CSE1(VC1,VC2)] • Endpoint 3 CaptureScene1[Description=USAConfRoom, VC1(role=audience)] 13

  14. MCU Behavior Example 1 -MCC with multiple audience and speaker • Outgoing Advertisement • If the MCU wanted to provide a multiple content capture containing the audience of the 3 endpoints and the speaker it could construct the following advertisement: • CaptureScene1[Description=AustralianConfRoom, VC1(role=audience)] • CaptureScene2[Description=ChinaConfRoom, VC2(role=speaker),VC3(role=audience), CSE1(VC2,VC3)] • CaptureScene3[Description=USAConfRoom, VC4(role=audience)] • CaptureScene4[MCC1(VC1,VC2,VC3,VC4){encodinggroup1}] 14

  15. MCU Behavior Example 2 -MCC with audience and separate speaker • Outgoing Advertisement • Alternatively if the MCU wanted to provide the speaker as one stream and the audiences as another it could assign an encoding group to VC2 in Capture Scene 2 and provide a CSE in Capture Scene 4: • CaptureScene1[Description=AustralianConfRoom, VC1(role=audience)] CaptureScene2[Description=ChinaConfRoom, VC2(role=speaker){encodinggroup2}, VC3(role=audience), CSE1(VC2,VC3)] • CaptureScene3[Description=USAConfRoom, VC4(role=audience)] CaptureScene4[MCC1(VC1,VC3,VC4){encodinggroup1}, CSE2(MCC1,VC2)] 15

  16. MCU Behavior Example 3 -Multiple captures from multiple endpoints • Incoming Advertisements • A conference has three endpoints D,E and F, each end point has three video captures covering the left, middle and right regions of each conference room. The MCU receives the following advertisements from D and E: • Endpoint D CaptureScene1[Description=AustralianConfRoom, VC1(left){encodinggroup1}, VC2(middle){encodinggroup2}, VC3(right){encodinggroup3}, CSE1(VC1,VC2,VC3)] • Endpoint E CaptureScene1[Description=ChinaConfRoom, VC1(left){encodinggroup1}, VC2(middle){encodinggroup2}, VC3(right){encodinggroup3}, CSE1(VC1,VC2,VC3)] 16

  17. MCU Behavior Example 3 -Multiple captures from multiple endpoints (cont.) • Outgoing Advertisement • The MCU wants to offer Endpoint F three capture encodings. Each capture encoding would contain a capture from either Endpoint D or Endpoint E depending on the policy. The MCU would send the following: • CaptureScene1[Description=AustralianConfRoom, VC1(left),VC2(middle),VC3(right), CSE1(VC1,VC2,VC3)] CaptureScene2[Description=ChinaConfRoom, VC4(left),VC5(middle),VC6(right), CSE2(VC4,VC5,VC6)] CaptureScene3[MCC1(VC1,VC4){encodinggroup1}, MCC2(VC2,VC5){encodinggroup2}, MCC3(VC3,VC6){encodinggroup3}, CSE3(MCC1,MCC2,MCC3)] 17

  18. Benefits • Meets the principles of slide 8 • Addresses most of the highlighting issues • Allows simple or complex captures/interactions to be described. 18

  19. Other • The draft describes updates to existing attributes (switched and composed) and associated text. This clarifies some issues but does not enable description of the capture sources. Not a full solution. • This draft mentions impacts to the multipoint conferencing framework. The introduction of MCC doesn’t really impact this. Work is needed in any case on mapping CLUE concepts to the framework. 19

More Related