Subject: [clue] Capture ID scope in a Configure

From: Christian Groves <[email-masked]>
Date: Thu, 28 Mar 2013 12:06:38 +1100

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

---

From: Andy Pepperell <[email-masked]>
Date: Thu, 28 Mar 2013 14:26:14 +0000

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...

>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. 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.

>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.

>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.

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]> 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
> Now if a Consumer sends a configure in response wanting Scene 1 CSE 1 and
> Scene 2 CSE 1 how does it respond?
> 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]
> https://www.ietf.org/mailman/**listinfo/clue<https://www.ietf.org/mailman/listinfo/clue>
>

---

From: Paul Kyzivat <[email-masked]>
Date: Fri, 29 Mar 2013 00:05:17 +0800

> and CSEs. A captureID may have multiple encodings.

I agree that CaptureIDs must be unique within an Advertisement.

I agree that a CaptureID may be used in more than one CSE.

AFAIK a CaptureID is bound to an encoding group which may contain 
multiple encodings. Those are *potential* encodings. The actual binding 
of CaptureIDs to encodings is defined by the Configure message. But yes, 
there it is possible to request multiple encodings of the same captureID 
as long as the encoding group supports that.

But I don't think it makes sense for the same captureID to be used to 
specify a capture that is to be delivered from more than one Scene. This 
seems a logical impossibility - the capture has spatial coordinates that 
are understood within the coordinate space of the Scene in which it 
appears. Having the same capture in different scenes would violate that 
logic.

If what I said is right, then there are two ways to approach encoding 
captureIDs:

- Require that each captureID be unique within the advertisement

- Require that each captureID be unique within a Scene in an 
Advertisement. When referenced from outside of the Scene, use a compound 
structure containing the SceneID and CaptureID.

That is really just a pure syntactical issue, not a fundamental one.

Regardless, there may be different needs for referencing CaptureIDs:
- in CSEs
- in Simultaneous Sets

We could potentially come up with additional reasons: e.g. to define a 
switched capture by reference to the captures it switches among.

> Scene 1 (CSE1(VC1,VC3),CSE2(VC1,VC2))

I disagree with the validity of including VC1 in both scenes, for the 
reasons given above.

> b) Does it include the complete reference? i.e. Scene1(CSE1(VC1,VC3),

You are asking how the Configure should be constructed?

IMO it lists the individual CaptureIDs it wants, each paired to one of 
the valid encodings for that capture.

AFAIK there is no need to mention scenes in Configure messages.

> it setup two RTP streams one for each scene?

I think we have a disconnect in understanding, at multiple levels.
We should be clarifying text to resolve such confusion.

	Thanks,
	Paul (as individual)