Subject: Re: [clue] Framework tickets to be closed - simulcast support

From: "Roni Even" <[email-masked]>
Date: Tue, 27 Nov 2012 16:53:55 +0200

Hi,

I agree on the first two tickets

As for ticket #18 the meeting minutes say 

"Roni - Not sure this is enough as does not provide info on which can be
simulcast if for example there is a limit of two which two does it mean.

Rob Hanson - Not so convinced that this is a problem we need to solve in
clue (sorry some missing).

Roni - Can agree with the previous speaker that does not need to be solved
in clue."

This are partial notes but clearly this parameter does not solve simulcast.
So I am not sure why it was added.

So in my view if we take this ticket out we agree that 

1.       simulcast should not be addressed in CLUE (until we have a
different solution) 

2.       There is no need for the new Max Capture Encoding attribute.

Roni

From: [email-masked] [mailto:[email-masked]] On Behalf Of
Duckworth, Mark
Sent: 27 November, 2012 3:57 PM
To: [email-masked]
Subject: [clue] Framework tickets to be closed

Hello Mary and Paul,

I think a few open tickets can be closed based on
draft-ietf-clue-framework-07.

Ticket #9 <http://trac.tools.ietf.org/wg/clue/trac/ticket/9>  - axis of
capture description

Ticket #17 <http://trac.tools.ietf.org/wg/clue/trac/ticket/17>  - capture
encoding term

Ticket #18 <http://trac.tools.ietf.org/wg/clue/trac/ticket/18>  -
limitations on simulcast

If you agree, can you please mark these tickets as closed?

Notes in the "Changes" section of draft-ietf-clue-framework-07:

-          Ticket #9. Rename Axis of Capture Point attribute to Point on
Line of Capture. Clarify the description of this attribute.

-          Ticket #17. Add "capture encoding" definition. Use this new term
throughout document as appropriate, replacing some usage of the terms
"stream" and "encoding".

-          Ticket #18. Add Max Capture Encodings media capture attribute.

Thanks,
Mark Duckworth

---

From: "Duckworth, Mark" <[email-masked]>
Date: Tue, 27 Nov 2012 07:19:17 -0800

Hi Roni,
Ticket #18 says "Need to define the mechanism to indicate limitations on simulcast in the advertisement."
It sounds like you are saying you disagree with the premise of Ticket #18, and we should not need to indicate any limitation on simulcast in the advertisement.  Is that what you mean?
Mark

From: Roni Even [mailto:[email-masked]]
Sent: Tuesday, November 27, 2012 9:54 AM
To: Duckworth, Mark; [email-masked]
Subject: RE: [clue] Framework tickets to be closed - simulcast support

Hi,

"Roni - Not sure this is enough as does not provide info on which can be simulcast if for example there is a limit of two which two does it mean.
Rob Hanson - Not so convinced that this is a problem we need to solve in clue (sorry some missing).
Roni - Can agree with the previous speaker that does not need to be solved in clue."

This are partial notes but clearly this parameter does not solve simulcast. So I am not sure why it was added.

1.       simulcast should not be addressed in CLUE (until we have a different solution)

Roni

From: [email-masked] [mailto:[email-masked]] On Behalf Of Duckworth, Mark
Sent: 27 November, 2012 3:57 PM
To: [email-masked]
Subject: [clue] Framework tickets to be closed

Hello Mary and Paul,

I think a few open tickets can be closed based on draft-ietf-clue-framework-07.

Ticket #9<http://trac.tools.ietf.org/wg/clue/trac/ticket/9> - axis of capture description
Ticket #17<http://trac.tools.ietf.org/wg/clue/trac/ticket/17> - capture encoding term
Ticket #18<http://trac.tools.ietf.org/wg/clue/trac/ticket/18> - limitations on simulcast

-          Ticket #9. Rename Axis of Capture Point attribute to Point on Line of Capture. Clarify the description of this attribute.

-          Ticket #17. Add "capture encoding" definition. Use this new term throughout document as appropriate, replacing some usage of the terms "stream" and "encoding".

Thanks,
Mark Duckworth

---

From: "Roni Even" <[email-masked]>
Date: Tue, 27 Nov 2012 17:49:17 +0200

Mark,

What I was saying is that the Max capture Encoding attribute does not
address the simulcast issue. For example if there are 6 different individual
encodes in the group 2 HD 2 SD and 2 CIF and the Max Capture encode for a
media capture is 2. Which two can the provider send ( HD +SD or HD + CIF or
SD+CIF or 2HD .)

So there is no solution yet for simulcast which I think other agreed in the
meeting.

Rob proposed that support for simulcast should not be discussed in CLUE.

This is the reason for the two points I made.

So we can remove ticket #18 and the Max Capture Encoding

If need max capture encoding then need to specify the usage and it is not to
address simulcast. Note that the same issue I mentioned in the example above
still holds.

Roni

From: [email-masked] [mailto:[email-masked]] On Behalf Of
Duckworth, Mark
Sent: 27 November, 2012 5:19 PM
To: [email-masked]
Subject: Re: [clue] Framework tickets to be closed - simulcast support

Hi Roni,

Ticket #18 says "Need to define the mechanism to indicate limitations on
simulcast in the advertisement."

It sounds like you are saying you disagree with the premise of Ticket #18,
and we should not need to indicate any limitation on simulcast in the
advertisement.  Is that what you mean?

Mark

Hi,

Roni

Hello Mary and Paul,

Thanks,
Mark Duckworth

---

From: Paul Kyzivat <[email-masked]>
Date: Wed, 28 Nov 2012 13:27:28 -0500

(speaking as an individual for now)

I think I see Roni's point about Max Capture Encoding not being sufficient.

But regarding whether we need to address this in CLUE, I'm not ready to 
sweep this away yet. It *may* be that this can be sufficiently addressed 
using existing SDP mechanisms and so need not be explicitly addressed by 
CLUE. But until this is demonstrated I would like to keep the issue open.

I have been thinking that in general a receiver will be able to look at 
an advertisement and decide on a configuration that will be mutually 
supported - that it is known before sending the configuration that it 
will "work". It *might* be necessary to do an O/A first, to prepare for 
the configuration. But it also ought to be possible to construct that 
O/A so that it doesn't harm the *current* configuration, even if it 
can't be fully honored by the advertiser. I can't see how the details of 
this will play out yet.

	Thanks,
	Paul

On 11/27/12 10:49 AM, Roni Even wrote:
> address the simulcast issue. For example if there are 6 different
> individual encodes in the group 2 HD 2 SD and 2 CIF and the Max Capture
> encode for a media capture is 2. Which two can the provider send ( HD
> +SD or HD + CIF or SD+CIF or 2HD …)
>
> So there is no solution yet for simulcast which I think other agreed in
> the meeting.
>
> If need max capture encoding then need to specify the usage and it is
> not to address simulcast. Note that the same issue I mentioned in the
> example above still holds.
>
> Roni
>
> *From:[email-masked] [mailto:[email-masked]] *On Behalf
> Of *Duckworth, Mark
> *Sent:* 27 November, 2012 5:19 PM
> *To:* [email-masked]
> *Subject:* Re: [clue] Framework tickets to be closed - simulcast support
>
> Hi Roni,
>
> Ticket #18 says “Need to define the mechanism to indicate limitations on
> simulcast in the advertisement.”
>
> It sounds like you are saying you disagree with the premise of Ticket
> #18, and we should not need to indicate any limitation on simulcast in
> the advertisement.  Is that what you mean?
>
> Mark
>
> *From:*Roni Even [mailto:[email-masked]]
> *Sent:* Tuesday, November 27, 2012 9:54 AM
> *To:* Duckworth, Mark; [email-masked] <mailto:[email-masked]>
> *Subject:* RE: [clue] Framework tickets to be closed - simulcast support
>
> Hi,
>
> “Roni - Not sure this is enough as does not provide info on which can be simulcast if for example there is a limit of two which two does it mean.
>
> Roni - Can agree with the previous speaker that does not need to be
> solved in clue.”
>
> This are partial notes but clearly this parameter does not solve
> simulcast. So I am not sure why it was added.
>
> 1.simulcast should not be addressed in CLUE (until we have a different
> solution)
>
> 2.There is no need for the new Max Capture Encoding attribute.
>
> Roni
>
> *From:[email-masked] <mailto:[email-masked]>
> [mailto:[email-masked]] *On Behalf Of *Duckworth, Mark
> *Sent:* 27 November, 2012 3:57 PM
> *To:* [email-masked] <mailto:[email-masked]>
> *Subject:* [clue] Framework tickets to be closed
>
> Hello Mary and Paul,
>
> Ticket #9 <http://trac.tools.ietf.org/wg/clue/trac/ticket/9> – axis of
> capture description
>
> Ticket #17 <http://trac.tools.ietf.org/wg/clue/trac/ticket/17> – capture
> encoding term
>
> Ticket #18 <http://trac.tools.ietf.org/wg/clue/trac/ticket/18> –
> limitations on simulcast
>
> Notes in the “Changes” section of draft-ietf-clue-framework-07:
>
> -Ticket #9. Rename Axis of Capture Point attribute to Point on Line of
> Capture. Clarify the description of this attribute.
>
> -Ticket #17. Add "capture encoding" definition. Use this new term
> -Ticket #18. Add Max Capture Encodings media capture attribute.
>
> Thanks,
> Mark Duckworth
>
>
>
> _______________________________________________
> clue mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/clue
>

---

From: "Duckworth, Mark" <[email-masked]>
Date: Wed, 28 Nov 2012 12:36:24 -0800

Roni,
I agree your example is not supported by the current framework.  But in my view, your example shows a media provider restriction that is not intended to be supported by the framework, regardless of any simulcast consideration.

For example, consider this other case, using the same encoding group of 6 different individual encodes in the group 2 HD 2 SD and 2 CIF.  And suppose media captures VC1, VC2, VC3, and VC4 all use that encoding group.  But the media provider has a restriction that VC2 cannot be encoded in HD.  The framework does not support this case, and it wasn't intended to.  In my view, this is the same sort of restriction as in your simulcast example.

The solution for both examples is that the media provider must use a different set of encodings in different encoding groups in order to express an advertisement it can actually support.  The media provider may not be able to express all possible flexibility of the different combinations it can support, but that's okay, the framework isn't trying to enable all conceivable combinations.  More specifically, for your example, suppose the media provider can support only HD + CIF for the media capture in question, then the media provider should use an encoding group with 1 HD and 1 CIF for this capture.

Mark

From: Roni Even [mailto:[email-masked]]
Sent: Tuesday, November 27, 2012 10:49 AM
To: Duckworth, Mark; [email-masked]
Subject: RE: [clue] Framework tickets to be closed - simulcast support

Mark,
What I was saying is that the Max capture Encoding attribute does not address the simulcast issue. For example if there are 6 different individual encodes in the group 2 HD 2 SD and 2 CIF and the Max Capture encode for a media capture is 2. Which two can the provider send ( HD +SD or HD + CIF or SD+CIF or 2HD ...)
So there is no solution yet for simulcast which I think other agreed in the meeting.
Rob proposed that support for simulcast should not be discussed in CLUE.
This is the reason for the two points I made.
So we can remove ticket #18 and the Max Capture Encoding

If need max capture encoding then need to specify the usage and it is not to address simulcast. Note that the same issue I mentioned in the example above still holds.

Roni

Hi Roni,

From: Roni Even [mailto:[email-masked]]
Sent: Tuesday, November 27, 2012 9:54 AM
To: Duckworth, Mark; [email-masked]<mailto:[email-masked]>
Subject: RE: [clue] Framework tickets to be closed - simulcast support

Hi,

Roni

From: [email-masked]<mailto:[email-masked]> [mailto:[email-masked]] On Behalf Of Duckworth, Mark
Sent: 27 November, 2012 3:57 PM
To: [email-masked]<mailto:[email-masked]>
Subject: [clue] Framework tickets to be closed

Hello Mary and Paul,

Thanks,
Mark Duckworth