Subject: Re: [clue] Capture ID scope in a Configure

From: Christian Groves <[email-masked]>
Date: Tue, 02 Apr 2013 12:08:31 +1100

Hello Andy,

Please see my reply below [CNG].

Regards, Christian

On 29/03/2013 1:26 AM, Andy Pepperell wrote:
> Hi Christian,
>
> I'm happy to have a go at answering your question with my opinion as 
> to how this relates to the CLUE framework...
[CNG] This is what I was after as the framework is a bit vague here. The 
questions aren't necessarily my opinion just what could be assumed by 
reading the framework.
>
> >From the framework it seems that it is assumed CaptureIDs are unique 
> in an Advertisement and the same CaptureID can be used in multiple 
> scenes and CSEs. A captureID may have multiple encodings.
>
> Yes, I think that's a good summary of the uniqueness of CaptureIDs. I 
> would, though, say that personally I consider the presence of a 
> CaptureID in more than one scene more the exception than the rule - 
> while it may be valid I don't think the majority of normal cases would 
> use this.
[CNG] I also think having a CaptureID in multiple scenes is not 
necessarily a good thing. It does complicate things. I not sure that we 
actually need to allow it. If a provider really wanted a particular 
capture in two scenes it could use two CaptureIDs and duplicate the 
attributes. I would propose that we add something to the framework to 
indicate that a particular Capture (indicated by its identity) can on be 
used in one Scene description.

> The "multiple encodings" aspect of media captures is designed to be 
> orthogonal to media captures' presence in one or more CSEs - it may be 
> valid to receive multiple encodings of a media capture even if it were 
> present in just one capture scene or capture scene entry, for 
> instance, and on the flip side, depending on the provider's 
> advertisement, it may only be possible to receive a single encodings 
> of a media capture which appears in multiple capture scene entries.
[CNG] I agree that the encodings is designed to be orthogonal but I 
think that perhaps there needs to be a tie between then encoding and the 
CSE/CaptureID. For example: as a provider I can see the case where it 
offer CSE1,CaptureID1 which uses a high quality encoding or 
CSE2,CaptureID1,CaptureID2 which uses a lower quality encoding. 
Currently we have a link between the CaptureID and encoding. How does it 
relate a CSE to a particular encoding instance when the CaptureID is the 
same?
>
> >Now if a Consumer sends a configure in response wanting Scene 1 CSE 1 
> and Scene 2 CSE 1 how does it respond?
>
> To my mind, the phrasing is slightly misleading here in that it could 
> be said that the Consumer doesn't really want "Scene 1 CSE 1" and 
> "Scene 2 CSE 1" but in fact wants a single encoding or multiple 
> encodings of the more fundamental "VC1", which it can put to whatever 
> use, post decoding, that it chooses.
[CNG] OK.
>
> >a) Does it include only the CaptureIDs? i.e. VC1,VC3,VC4
>
> That's what I believe to be the answer to your question. As per the 
> above, if it has multiple "uses" for VC1, perhaps a very high quality 
> encoding to switch out to certain other consumers and a lower quality 
> version to transcode (if it's a middle box, for instance) it may 
> choose to use more than one of the provider's Individual Encodings for 
> VC1, but fundamentally this can be considered orthogonal to the choice 
> of which media captures are needed, or the reason, based on their CSE 
> membership, why those media captures are being requested.
[CNG] Can it be completely orthogonal if a CSE is constructed based on 
some encoding considerations?
>
> >In response to the Configure what does the Provider do? The consumer 
> has indicated it wants two scenes and there's a duplicate of VC1. 
> Should the provider send the SDP to establish only one RTP stream for 
> VC1 or should it setup two RTP streams one for each scene?
>
> The idea behind the Encoding Group and Individual Encoding concepts 
> was that the provider can be fairly dumb here, and need to take no 
> view or action explicitly based on the "duplication" of VC1. SDP / RTP 
> relationships should be made according to the encoding configuration, 
> mostly determined by the consumer's configuration message. One RTP 
> stream per configured encoding would seem fairly straightforward, but 
> the multiplexing relationship of those streams with respect to "m 
> lines", SSRCs, multiplex IDs within RTP extension headers hasn't, to 
> my knowledge, been completely thrashed out to everyone's satisfaction 
> as yet (though I am forced to confess to a certain amount of ignorance 
> as to the latest state of this discussion).
>
> Regards,
>
> Andy
>
>
> On Thu, Mar 28, 2013 at 1:06 AM, Christian Groves 
> <[email-masked] <mailto:[email-masked]>> 
> wrote:
>
>     Hello,
>
>     >From the framework it seems that it is assumed CaptureIDs are
>     unique in an Advertisement and the same CaptureID can be used in
>     multiple scenes and CSEs. A captureID may have multiple encodings.
>
>     I.e.
>     Advertisement
>     VC1 (capture attributes 1)
>     VC2 (capture attributes 2)
>     VC3 (capture attributes 3)
>     VC4 (capture attributes 4)
>     Scene 1 (CSE1(VC1,VC3),CSE2(VC1,VC2))
>     Scene 2 (CSE1(VC1,VC4))
>
>     Now if a Consumer sends a configure in response wanting Scene 1
>     CSE 1 and Scene 2 CSE 1 how does it respond?
>     a) Does it include only the CaptureIDs? i.e. VC1,VC3,VC4
>     b) Does it include the complete reference? i.e.
>     Scene1(CSE1(VC1,VC3), Scene2(CSE1(VC1,VC4))
>     c) Both?
>     d) ?
>
>     In response to the Configure what does the Provider do? The
>     consumer has indicated it wants two scenes and there's a duplicate
>     of VC1. Should the provider send the SDP to establish only one RTP
>     stream for VC1 or should it setup two RTP streams one for each scene?
>
>     Any thoughts?
>
>     Regards, Christian
>     _______________________________________________
>     clue mailing list
>     [email-masked] <mailto:[email-masked]>
>     https://www.ietf.org/mailman/listinfo/clue
>
>

---

From: "Roni Even" <[email-masked]>
Date: Tue, 2 Apr 2013 15:35:12 +0300

Christian,
>From the framework

Some key points about Media Captures:

     . A Media Capture is of a single media type (e.g. audio or  video)
     . A Media Capture is associated with exactly one Capture Scene
     . A Media Capture has exactly one set of spatial information
     . A Media Capture may be the source of one or more Capture
Encodings

Note the second bullet
Roni

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of
Christian Groves
Sent: 28 March, 2013 3:07 AM
To: [email-masked]
Subject: [clue] Capture ID scope in a Configure

Hello,

 From the framework it seems that it is assumed CaptureIDs are unique in an
Advertisement and the same CaptureID can be used in multiple scenes and
CSEs. A captureID may have multiple encodings.

I.e.
Advertisement

Now if a Consumer sends a configure in response wanting Scene 1 CSE 1 and
Scene 2 CSE 1 how does it respond?
a) Does it include only the CaptureIDs? i.e. VC1,VC3,VC4
b) Does it include the complete reference? i.e. Scene1(CSE1(VC1,VC3),
Scene2(CSE1(VC1,VC4))
c) Both?
d) ?

In response to the Configure what does the Provider do? The consumer has
indicated it wants two scenes and there's a duplicate of VC1. Should the
provider send the SDP to establish only one RTP stream for VC1 or should it
setup two RTP streams one for each scene?

Any thoughts?

Regards, Christian
[email-masked]

---

From: Christian Groves <[email-masked]>
Date: Wed, 03 Apr 2013 14:56:52 +1100

Hello Roni,

OK thanks I missed that bullet. I was looking at 6.2 on capture scenes. 
In that section its says that a media capture can be used in multiple 
CSEs. That's missing from the bullet list in 6.1. 6.2 missing the facts 
that a capture can only be used by one scene. It would be good to align 
these two sections.

Regards, Christian

---

From: Roberta Presta <[email-masked]>
Date: Wed, 03 Apr 2013 19:22:16 +0200

Hi all,

it seems to me that capture scenes and capture scene entries are 
semantical abstractions that are useful only to make a media provider 
able to show the organization of the available media captures to the 
media consumer via an advertisement message.
I don't believe they should be used within a configure message.
The media consumer should specify only *capture encodings*, i.e., the 
associations of a media capture with an individual encoding with the 
desired parameters.
If the media consumer wants both VC1 encoded with ENC0 and VC1 encoded 
with ENC1, he should put in the configure message the specification of 
two capture encodings.
<captureEncoding id=...>
  <mediaCaptureID>VC1...
  <encodingID>ENC1...
  <encodingParameters>...
If he wants all the captures within a capture scene, he should specify 
in the configure a capture encoding for each capture of the scene, since 
he should be forced to associate a desired encoding to each desired capture.
Do you think this interpretation is correct?

Thanks,

Roberta

Il 02/04/2013 03:08, Christian Groves ha scritto:
>> orthogonal to media captures' presence in one or more CSEs - it may 
>> be valid to receive multiple encodings of a media capture even if it 
>> were present in just one capture scene or capture scene entry, for 
> think that perhaps there needs to be a tie between then encoding and 
> the CSE/CaptureID. For example: as a provider I can see the case where 
> it offer CSE1,CaptureID1 which uses a high quality encoding or 
> Currently we have a link between the CaptureID and encoding. How does 
> it relate a CSE to a particular encoding instance when the CaptureID 
> is the same?
>>
>> >Now if a Consumer sends a configure in response wanting Scene 1 CSE 
>> 1 and Scene 2 CSE 1 how does it respond?
>>
>> choose to use more than one of the provider's Individual Encodings 
>> for VC1, but fundamentally this can be considered orthogonal to the 
>> choice of which media captures are needed, or the reason, based on 
>> their CSE membership, why those media captures are being requested.
>> view or action explicitly based on the "duplication" of VC1. SDP / 
>> RTP relationships should be made according to the encoding 
>> configuration, mostly determined by the consumer's configuration 
>> message. One RTP stream per configured encoding would seem fairly 
>> straightforward, but the multiplexing relationship of those streams 
>> with respect to "m lines", SSRCs, multiplex IDs within RTP extension 
>> headers hasn't, to my knowledge, been completely thrashed out to 
>> everyone's satisfaction as yet (though I am forced to confess to a 
>> certain amount of ignorance as to the latest state of this discussion).
>>
>> Regards,
>>
>> Andy
>>
>>
>> <[email-masked] 
>> <mailto:[email-masked]>> wrote:
>>
>>     Hello,
>>

-- 
Roberta Presta, Ph.D. Student
Dipartimento di Ingegneria Elettrica e delle Tecnologie dell'Informazione (DIETI)
Universita' degli Studi di Napoli "Federico II"
Via Claudio 21 -- 80125 Napoli (Italy)
Phone: +390817683821 - Fax: +390817683816

---

From: Paul Kyzivat <[email-masked]>
Date: Thu, 04 Apr 2013 02:45:36 +0800

> Do you think this interpretation is correct?

Yes, this is exactly what I am thinking!

	Thanks,
	Paul

---

From: "Duckworth, Mark" <[email-masked]>
Date: Wed, 3 Apr 2013 11:49:33 -0700

+1

> Paul Kyzivat
> Sent: Wednesday, April 03, 2013 2:46 PM
> To: [email-masked]
> Subject: Re: [clue] Capture ID scope in a Configure
> 
> > in the configure a capture encoding for each capture of the scene,
> > since he should be forced to associate a desired encoding to each
> > desired capture.

---

From: Christian Groves <[email-masked]>
Date: Thu, 04 Apr 2013 10:52:40 +1100

Yes, can we have Roberta's text (or similar) in the framework so its 
100% clear?

Christian