Subject: [clue] MCU Advertising swtiched captures, and spatial relation

From: "Duckworth, Mark" <[email-masked]>
Date: Wed, 17 Jul 2013 14:15:24 -0700

This is a follow up to the discussion from the last interim meeting, about handling advertisements and spatial relations in a multipoint conference using the media switching variety of the Topo-Mixer topology.  The example and issues for discussion are in draft-duckworth-clue-switching-example-01.  I'd like to have some discussion on the list prior to Berlin.

At the interim meeting, people seemed to prefer the "one big scene" approach, rather than the "multiple scenes" approach, so let's start with my draft section 3.1 Advertising one big scene.   I think everybody agreed it is okay for the MCU Provider to advertise many (12 in this example) video captures in a single CSE, with some way to indicate the Consumer can pick a subset of them and still get a "complete" representation of the scene.  The issue we still have is how does the Consumer know how to render the received encodings with correct spatial relationships?

It can't be just based on the Provider's advertised spatial coordinates, because the provider doesn't know how the Consumer wants to organize it's layout (figures 1 and 2 for examples).  And the advertised coordinates are overconstrained and not clear how it is useful as described in issue 4.

I come back to the consumer layout draft [draft-hansen-clue-consumer-layout] which proposes a solution.  I think we should consider that proposal, for enabling the Consumer to send "Area of Display" information to the Provider, so the Provider can make switching decisions based on how the Consumer wants to arrange its rendering.

What other ideas or comments do you have about section 3.1 in my draft?  Do the issues 1 through 4 make sense?  Is there an easier way to solve the problem for this use case example?

Regards,
Mark

---

From: Christian Groves <[email-masked]>
Date: Thu, 18 Jul 2013 11:26:30 +1000

Hello Mark,

I'm still trying to get closure on the my draft with my other co-authors 
which discusses this switching issue. Unfortunately it wasn't ready for 
the draft cut-off deadline. Effectively it proposes a way to maintain 
the source Scene/Capture from the originating endpoints through the MCU 
to the receiving endpoint. Both multiple scenes and single scenes could 
be used depending on the mixing/switching scenario and it allows the 
ability to describe the composition of a single capture.

Regards, Christian

On 18/07/2013 7:15 AM, Duckworth, Mark wrote:
>
> This is a follow up to the discussion from the last interim meeting, 
> about handling advertisements and spatial relations in a multipoint 
> conference using the media switching variety of the Topo-Mixer 
> topology. The example and issues for discussion are in 
> draft-duckworth-clue-switching-example-01. I’d like to have some 
> discussion on the list prior to Berlin.
>
> At the interim meeting, people seemed to prefer the “one big scene” 
> approach, rather than the “multiple scenes” approach, so let’s start 
> with my draft section 3.1 Advertising one big scene. I think everybody 
> agreed it is okay for the MCU Provider to advertise many (12 in this 
> example) video captures in a single CSE, with some way to indicate the 
> Consumer can pick a subset of them and still get a “complete” 
> representation of the scene. The issue we still have is how does the 
> Consumer know how to render the received encodings with correct 
> spatial relationships?
>
> It can’t be just based on the Provider’s advertised spatial 
> coordinates, because the provider doesn’t know how the Consumer wants 
> to organize it’s layout (figures 1 and 2 for examples). And the 
> advertised coordinates are overconstrained and not clear how it is 
> useful as described in issue 4.
>
> I come back to the consumer layout draft 
> [draft-hansen-clue-consumer-layout] which proposes a solution. I think 
> we should consider that proposal, for enabling the Consumer to send 
> “Area of Display” information to the Provider, so the Provider can 
> make switching decisions based on how the Consumer wants to arrange 
> its rendering.
>
> What other ideas or comments do you have about section 3.1 in my 
> draft? Do the issues 1 through 4 make sense? Is there an easier way to 
> solve the problem for this use case example?
>
> Regards,
>
> Mark
>
>
>
> _______________________________________________
> clue mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/clue

---

From: "Duckworth, Mark" <[email-masked]>
Date: Wed, 17 Jul 2013 18:33:54 -0700

Hi Christian,

That sounds interesting.  Can you tell us more?  Will you be in Berlin to talk about it?

Mark

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On Behalf Of
> Christian Groves
> Sent: Wednesday, July 17, 2013 9:27 PM
> To: [email-masked]
> Subject: Re: [clue] MCU Advertising swtiched captures, and spatial relation
> 
> Hello Mark,
> 
> I'm still trying to get closure on the my draft with my other co-authors which
> discusses this switching issue. Unfortunately it wasn't ready for the draft cut-
> off deadline. Effectively it proposes a way to maintain the source
> Scene/Capture from the originating endpoints through the MCU to the
> receiving endpoint. Both multiple scenes and single scenes could be used
> depending on the mixing/switching scenario and it allows the ability to
> describe the composition of a single capture.
> 
> Regards, Christian
> 
> > draft-duckworth-clue-switching-example-01. I'd like to have some
> > At the interim meeting, people seemed to prefer the "one big scene"
> > approach, rather than the "multiple scenes" approach, so let's start
> > Consumer can pick a subset of them and still get a "complete"
> > It can't be just based on the Provider's advertised spatial
> > coordinates, because the provider doesn't know how the Consumer wants
> > to organize it's layout (figures 1 and 2 for examples). And the
> > "Area of Display" information to the Provider, so the Provider can