IETF Logo Mail Archive

Re: [clue] contradiction in framework about simultaneous captures in a CSE

"Duckworth, Mark" <Mark.Duckworth@polycom.com> Fri, 21 February 2014 17:41 UTC

Return-Path: <Mark.Duckworth@polycom.com>
X-Original-To: clue@ietfa.amsl.com
Delivered-To: clue@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2A4951A02D0 for <clue@ietfa.amsl.com>; Fri, 21 Feb 2014 09:41:54 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.749
X-Spam-Level:
X-Spam-Status: No, score=-4.749 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.548, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wseLIW0Fy-R6 for <clue@ietfa.amsl.com>; Fri, 21 Feb 2014 09:41:52 -0800 (PST)
Received: from Crpehubprd01.polycom.com (crpehubprd01.polycom.com [140.242.64.158]) by ietfa.amsl.com (Postfix) with ESMTP id 2483F1A021C for <clue@ietf.org>; Fri, 21 Feb 2014 09:41:52 -0800 (PST)
Received: from PWEHUB01.polycom.com (10.236.2.221) by Crpehubprd01.polycom.com (10.236.0.158) with Microsoft SMTP Server (TLS) id 8.3.192.1; Fri, 21 Feb 2014 09:41:48 -0800
Received: from CRPMBOXPRD07.polycom.com ([fe80::91fc:8a0f:5258:aff0]) by PWEHUB01.polycom.com ([fe80::99a8:f785:3f0c:2bb6%17]) with mapi; Fri, 21 Feb 2014 09:41:47 -0800
From: "Duckworth, Mark" <Mark.Duckworth@polycom.com>
To: Paul Kyzivat <pkyzivat@alum.mit.edu>, "clue@ietf.org" <clue@ietf.org>
Date: Fri, 21 Feb 2014 09:41:47 -0800
Thread-Topic: [clue] contradiction in framework about simultaneous captures in a CSE
Thread-Index: Ac8vK+P2U5FN4mrCSG6qjXBB7W/BnwAAD36g
Message-ID: <49E45C59CA48264997FEBFB29B6BC2D60C9D5FDB47@CRPMBOXPRD07.polycom.com>
References: <49E45C59CA48264997FEBFB29B6BC2D60C9D5FDA32@CRPMBOXPRD07.polycom.com> <530784E1.7020100@alum.mit.edu> <49E45C59CA48264997FEBFB29B6BC2D60C9D5FDB2A@CRPMBOXPRD07.polycom.com> <53078F56.20804@alum.mit.edu>
In-Reply-To: <53078F56.20804@alum.mit.edu>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
acceptlanguage: en-US
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Archived-At: http://mailarchive.ietf.org/arch/msg/clue/4T0WlU4YBnvQa1pYdJRAtBsj4h8
Subject: Re: [clue] contradiction in framework about simultaneous captures in a CSE
X-BeenThere: clue@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: CLUE - ControLling mUltiple streams for TElepresence <clue.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/clue>, <mailto:clue-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/clue/>
List-Post: <mailto:clue@ietf.org>
List-Help: <mailto:clue-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/clue>, <mailto:clue-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 21 Feb 2014 17:41:54 -0000

That works for me.
Mark

> -----Original Message-----
> From: Paul Kyzivat [mailto:pkyzivat@alum.mit.edu]
> Sent: Friday, February 21, 2014 12:40 PM
> To: Duckworth, Mark; clue@ietf.org
> Subject: Re: [clue] contradiction in framework about simultaneous captures
> in a CSE
> 
> On 2/21/14 12:20 PM, Duckworth, Mark wrote:
> > Hi Paul,
> >
> > I thought of that possibility also.  But I think our intent was for the provider
> to be able to advertise the complete scene information for original sources,
> including CSEs, even if the provider didn't include encoding groups for those
> captures.  I think it is useful to include the CSEs for captures without encoding
> groups, because the consumer can use this information for choosing
> captures, or choosing subsets within MCCs.
> >
> > Another possibility is to say either all captures in a CSE must include an
> encoding group, or none of the captures in a CSE can include an encoding
> group.  I can't think of a case that makes sense to include a mixture.
> 
> We can just say that the provider must be capable of simultaneously
> delivering all those captures in a CSE *that have an encoding group*.
> 
> That would allow an CSE that has some captures with encoding groups and
> some without. I can't think of any reason to do that, but it seems easier than
> adding more arbitrary rules.
> 
> 	Thanks,
> 	Paul
> 
> > Mark
> >
> >> -----Original Message-----
> >> From: clue [mailto:clue-bounces@ietf.org] On Behalf Of Paul Kyzivat
> >> Sent: Friday, February 21, 2014 11:55 AM
> >> To: clue@ietf.org
> >> Subject: Re: [clue] contradiction in framework about simultaneous
> >> captures in a CSE
> >>
> >> On 2/21/14 10:06 AM, Duckworth, Mark wrote:
> >>
> >>> Here is a proposal for changing the sentence in 7.3:
> >>>
> >>> "If all the Captures in a single Capture Scene Entry have an
> >>> Encoding Group, then the Provider MUST be capable of encoding and
> >>> sending all those Captures simultaneously."
> >>>
> >>> Is that a good change?
> >>
> >> The above implies that if some but not all captures in a CSE have
> >> encoding groups, then there is no requirement for the provider to be
> >> able to send them simultaneously.
> >>
> >> Does it make sense to define a CSE containing captures without
> >> encoding groups?
> >>
> >> Is there any reason to do so?
> >>
> >> ISTM that we could instead say that a CSE MUST NOT reference a
> >> capture that has no encoding group. Then 7.3 would be ok as it is.
> >>
> >> 	Thanks,
> >> 	Paul
> >>
> >> _______________________________________________
> >> clue mailing list
> >> clue@ietf.org
> >> https://www.ietf.org/mailman/listinfo/clue
> >

v2.23.0 | Report a Bug | By Email