Re: [maitai] draft-romanow-dispatch-telepresence-use-cases-01

[Peter Musgrave <[e-mail]>]

Inline...

Peter

On 2010-12-13, at 6:43 PM, Allyn Romanow (allyn) wrote:

> Hi Peter, 
> 
> Indeed, the use cases are not complete. I'm trying to find time to
> propose a couple of additional cases. The thing about it is whether the
> different use cases would cause us to need to describe more or
> differently in order to be interoperable.
> 
>> -----Original Message-----
>> From: Peter Musgrave [mailto:[e-mail]]
>> Sent: Saturday, December 11, 2010 1:36 PM
>> To: [e-mail] list; Allyn Romanow (allyn)
>> Subject: Re: draft-romanow-dispatch-telepresence-use-cases-01
>> 
>> Hi Allyn,
>> 
>> I was re-reading this and thought of a couple of additions I think
>> might be useful.
>> 
>> In section 4.2 - asymmetric, the discussion focuses on 3d3c (three
>> display, 3 camera) to 1d1c.
>> 
>> I think that it would be useful to consider 3p3c to 2p2c - since this
>> brings up some interesting decisions which do not occur otherwise.
>> e.g If room 1 had cameras A, B, C (l to r) and room 2 has displays D
>> and E (l to r) there are now issues about maintaining gaze angle in
> the
>> views from room A when rendering on D and E which do not occur in the
>> 3d3c-1d1c example...
>> 
> [AR]  I'm not sure what "3p3c" and "2p2c" means, but I assume it's a
> typo and you meant 3displays 3 cameras to 2 displays 2 cameras? If you
> feel that there are dynamics that are involved going from 3 to 3 that
> would not be in play going between 3 and 1, then please, by all means
> write them up. If the differences would impact what needs to be
> described between different systems, then it's worth adding.

Sorry, 3d3c (I use panel and display interchangeably). 

The issue I am trying to encompass is that when a room with cameras (L to R, facing displays) A B C is rendered on two displays the sensible choices are CB, BA and (maybe) CA (again L to R facing displays in receiving room) so that when the people on camera C turn towards the others in the room the gaze angles are maintained on the far end displays and they turn towards the image of the people provided by camera B.

I agree this is not necessarily impacting how the physical setup of the rooms is conveyed, but does affect decisions made about what to render where. This specific decision does not arise in the examples of 3 to 1 and 3 to 3 in the existing doc. 

> 
>> Also, in the section 4.3 about multipoint, there are alternatives to a
>> classic, central MCU:
>> 1) An endpoint may elect to act as an MCU and allow a 2-party call to
>> grow to include a third party. In this case the mixing point has it's
>> own content it wishes to inject/select. (We may decide this is best
>> though of as an independent MCU - although it may have impact on the
>> signalling if a call which started as a point-to-point suddenly
> becomes
>> point-to-MCU).
> How does this effect what info needs to be passed?
I think it raises an issue about the fact that what may start as a description of endpoint (which is describing only it's cameras as a video source) then changes when that endpoint choses to act as an MCU. It either needs to change it's description mid-call - or find some way of conveying the additional video it has from the third endpoint within the stream it has already described. (In some cases it may elect to send both it's camera and the video from the third endpoint - so it will in effect have an additional "camera")

This starts to become word soup...I will try and make some pictures and see if I can express the idea better in that form.

>> 
>> 2) Three endpoints may elect to make a mesh of calls (each calls the
>> other) - so each endpoint maintains two active calls and no MCU is
>> present.
>> 
> Okay, again, we need to make sure that necessary info is passed. I'm not
> sure how these architectural difference impact that.
> 
> Best,
> Allyn
>> Regards,
>> 
>> Peter Musgrave
>> 
>> 
>