Re: [clue] Consensus call: Encoding Limits - SDP or CLUE signaling?

[Mary Barnes <[e-mail]>]

On Wed, Dec 4, 2013 at 7:17 PM, Christian Groves <
[e-mail]> wrote:

> Hello Mark,
>
> Yes it seems we're on the same page. With regards to the examples I agree
> that we decided to keep the framework at a higher level. Perhaps we could
> show the encoding information in a table based structure as we do elsewhere
> in CLUE?, i.e.
>
> +=======================+=================================+
> | EncodingGroup #1 | ENC0,ENC1 |
> +=======================+=================================+
>
> +=======================+=================================+
> | Encodings | Parameters|
> +-----------------------|---------------------------------+
> | ENC0 | Media=Video |
> | | maxWidth=1920|
> | | maxHeight=1088|
> +-----------------------|---------------------------------+
> | ENC1 | Media=Video |
> | | maxWidth=1200|
> | | maxHeight=720 |
> +=======================+=================================+
>
> We could have a note at the start of the examples indicating that the
> information in the "encoding group" table is carried by CLUE and the
> information in the Encodings tables are expected to be carried outside CLUE
> (e.g. via SDP). I think that would make it clear.
>
[MB] As an individual I do not believe we want this note in the framework
document. This level of detail should be reflected in the signaling
solution document.
[/MB]

>
> Regards, Christian
>
>
> On 5/12/2013 11:03 AM, Duckworth, Mark wrote:
>
>> Hi Christian,
>>
>> I think we have same understanding about the concept, but are having
>> trouble with terminology.  In any case, I think we are both agreeing on
>> using SDP to express encoding limits, but are now discussing possible
>> impact to the framework document.
>>
>> Comments inline.
>>
>> Mark
>>
>>  -----Original Message-----
>>> From: Christian Groves [mailto:[e-mail]]
>>> Sent: Wednesday, December 04, 2013 6:43 PM
>>> To: Duckworth, Mark; [e-mail]
>>> Subject: Re: [clue] Consensus call: Encoding Limits - SDP or CLUE
>>> signaling?
>>>
>>> Hello Mark,
>>>
>>> Please see my response below.
>>>
>>> Regards, Christian
>>>
>>> On 5/12/2013 4:15 AM, Duckworth, Mark wrote:
>>>
>>>> Hi Christian,
>>>>
>>>> Maybe there is confusion about "encoding limits" vs. "encoding
>>>>
>>> parameters".  I think we have been talking about "limits" and
>>> "parameters"
>>> as being the same thing.  Here is my understanding.  A CLUE encoding has
>>> "encoding limits" (see draft-ietf-clue-framework-12 section 8.1 and
>>> draft-
>>> kyzivat-clue-signaling-05 section 4.2).  For the sender (encoder side),
>>> these
>>> are expressed in SDP (a=sendonly), and referenced in a CLUE
>>> advertisement.
>>> Similarly, for the receiver (decoder side) the limits are expressed in
>>> SDP
>>> (a=recvonly) and referenced in a CLUE configure message.
>>> [CNG] This is where I'm confused. You say CLUE has "encoding limits" but
>>> the
>>> decision is that SDP has the encoding limits. I would say CLUE
>>> references an
>>> encoding defined by SDP. It is up to SDP to define that encoding in
>>> whatever
>>> way. I.e. it may have a specific encoding and/or may also have
>>> attributes that
>>> define limits. CLUE groups the encodings.
>>>
>> [Duckworth, Mark] Sorry, I wasn't clear.  I meant the CLUE framework
>> includes  encoding limits.  A CLUE encoding has encoding limits.  These
>> encoding limits are expressed in SDP and referenced by CLUE protocol
>> messages.  Does that make more sense?
>>
>>  Framework section 8.1 mentions the possibility of the codec actually
>>>> using
>>>>
>>> lower values for some of these parameters, and gives example of how
>>> certain parameters for certain codecs can be considered limits with
>>> possibility
>>> of using lower values.  It seems to me that in general this isn't CLUE
>>> specific.
>>> This is just how these parameters are meant to be used in SDP
>>> offer/answer
>>> (and maybe also in H.323 protocol?).  CLUE isn't trying to change this,
>>> it is just
>>> adding the ability to reference these existing codec parameters in CLUE
>>> messages.
>>> [CNG] OK this is another thing I didn't understand from the proposal.
>>> Again I thought we just reference the SDP encoding, not the individual
>>> SDP
>>> parameters in the CLUE messages?
>>>
>> [Duckworth, Mark] I didn't mean there are references to individual
>> parameters.  I think your first idea is correct, a CLUE message associates
>> a CLUE encoding with an SDP m-line and other information in SDP included
>> with the m-line, and this includes the encoding parameters.
>>
>>  I disagree with you about the consistency of the framework examples.  The
>>>>
>>> "maxWidth/maxHeight/maxFramerate/maxPps/maxBandwidth" parameters
>>> you mentioned are all still part of the framework.  Whether they are
>>> expressed directly in CLUE messages or references to SDP is not relevant
>>> to
>>> these examples.  If we eventually add more examples (in the signaling
>>> document?) for CLUE protocol and/or using the data model, then these
>>> lower level details should appear in those examples.
>>> [CNG] I think the issue is that the start of the text of section 8.1 and
>>> the
>>> examples was when the encoding parameters were present in CLUE itself. If
>>> we now say SDP contains the encoding information its not up to CLUE to
>>> say
>>> how these SDP parameters are interpreted. i.e. section
>>> 8.1 says "The parameters of an Individual Encoding represent the maximum
>>> values for certain aspects of the encoding." This is not the case for
>>> all SDP
>>> parameters/attributes. What they represent is up to the semantics of the
>>> SDP parameter itself.
>>>
>> [Duckworth, Mark] Okay, I understand that.  Further down in section 8.1 I
>> think it explains it better, but maybe we can clean it up further.
>>
>>  Also when I look at the example it certainly implies that the parameters
>>> are
>>> part of CLUE i.e. associated with the encoding rather than CLUE
>>> referencing
>>> an encoding defined elsewhere.
>>> E.g. CLUE has:
>>>     encodeGroupID=EG0, maxGroupBandwidth=6000000
>>>          encodeID=ENC0, maxWidth=1920, maxHeight=1088, maxFrameRate=60,
>>>                         maxPps=124416000, maxBandwidth=4000000
>>>          encodeID=ENC1, maxWidth=1280, maxHeight=720, maxFrameRate=30,
>>>                         maxPps=27648000, maxBandwidth=4000000
>>>          encodeID=ENC2, maxWidth=960, maxHeight=544, maxFrameRate=30,
>>>                         maxPps=15552000, maxBandwidth=4000000
>>>
>>> Which to me at least implies they are all part of the same syntax
>>> definition.
>>>
>>> Whereas to show that the parameters are defined outside CLUE I would
>>> expect something like:
>>> Encoding Groups:
>>> encodeGroupID=EG0, maxGroupBandwidth=6000000
>>>          encodeID=ENC0
>>>          encodeID=ENC1
>>>          encodeID=ENC2
>>>
>>> Encodings:
>>>          m=video
>>>          label=ENC0
>>>          a=maxWidth:1920
>>>          a=maxHeight:1088
>>>          ...
>>>          m=video
>>>          label=ENC1
>>>          a=maxWidth:1280
>>>          a=maxHeight:720
>>>          ...
>>>          etc.
>>>
>>> The above SDP isn't correct but I'm just try to illustrate that it would
>>> be good
>>> to show the define of the parameters separate from the definition of the
>>> encoding groups. It could be abstracted not to have SDP.
>>>
>> [Duckworth, Mark] I understand.  I guess it depends on how much "syntax
>> detail" you want to show in the examples, even though it isn't really
>> proper CLUE data model or protocol or SDP syntax at all.  My view is the
>> example is okay as is, without adding more syntax detail.  I thought the
>> working group agreed in general these framework examples should be fairly
>> high level and not get bogged down in syntax.
>> [Duckworth, Mark] Does anybody else have input about this?
>>
>>  Regards,
>>>> Mark
>>>>
>>>>  -----Original Message-----
>>>>> From: Christian Groves [mailto:[e-mail]]
>>>>> Sent: Tuesday, December 03, 2013 5:50 PM
>>>>> To: Duckworth, Mark; [e-mail]
>>>>> Subject: Re: [clue] Consensus call: Encoding Limits - SDP or CLUE
>>>>> signaling?
>>>>>
>>>>> Hello Mark,
>>>>>
>>>>> I guess what I found confusing is that the decision was with regards
>>>>> to "Encoding Limits" (i.e. maximums) not encoding parameters which I
>>>>> agree we've previously thought as being in SDP. The examples in the
>>>>> framework also shows
>>>>> maxWidth/maxHeight/maxFramerate/maxPps/maxBandwidth
>>>>> against individual encodes. So the framework isn't consistent on this.
>>>>>
>>>>> Regards, Christian
>>>>>
>>>>> On 4/12/2013 1:17 AM, Duckworth, Mark wrote:
>>>>>
>>>>>> Hello Christian,
>>>>>>
>>>>>> I agree with Rob, and even further, I think the Framework document
>>>>>> is
>>>>>>
>>>>> already consistent with this approach, because it has been our
>>>>> working understanding for quite a while.
>>>>>
>>>>>> This text from section 8.1 sums it up nicely:
>>>>>>        "Individual Encoding parameters are represented in SDP
>>>>>> [RFC4566],
>>>>>>        not in CLUE messages. For example, for a video encoding using
>>>>>>        H.26x compression technologies, this can include parameters
>>>>>> such
>>>>>>        as:
>>>>>>        . Maximum bandwidth;
>>>>>>        . Maximum picture size in pixels;
>>>>>>        . Maximum number of pixels to be processed per second;
>>>>>>        The bandwidth parameter is the only one that specifically
>>>>>> relates
>>>>>>        to a CLUE Advertisement, as it can be further constrained by
>>>>>> the
>>>>>>        maximum group bandwidth in an Encoding Group."
>>>>>>
>>>>>> Mark
>>>>>>
>>>>>>  -----Original Message-----
>>>>>>> From: clue [mailto:[e-mail]] On Behalf Of Christian
>>>>>>> Groves
>>>>>>> Sent: Monday, December 02, 2013 5:55 PM
>>>>>>> To: [e-mail]
>>>>>>> Subject: Re: [clue] Consensus call: Encoding Limits - SDP or CLUE
>>>>>>>
>>>>>> signaling?
>>>
>>>> Hello Rob,
>>>>>>>
>>>>>>> So we'll keep the encoding group concept but there will be no CLUE
>>>>>>> encoding parameters (i.e. no maxGroupBandwidth, maxWidth, maxPps
>>>>>>>
>>>>>> etc)?
>>>>>
>>>>>> Regards, Christian
>>>>>>>
>>>>>>> On 3/12/2013 3:29 AM, Robert Hansen wrote:
>>>>>>>
>>>>>>>> Hi Christian,
>>>>>>>>
>>>>>>>> I don't think this affects Encoding Groups - that concept will
>>>>>>>> still be in the framework and will need to be expressed in CLUE
>>>>>>>> ADVERTISMENT messages, as that's something that isn't well
>>>>>>>> expressible in SDP. The encoding limits referred to are the
>>>>>>>> per-encoding
>>>>>>>>
>>>>>>> limits.
>>>>>
>>>>>> This reflects what we had been taking as our working understanding
>>>>>>>> so far in things like the signalling document, so shouldn't
>>>>>>>> involve a radical rethink.
>>>>>>>>
>>>>>>>> Rob
>>>>>>>>
>>>>>>>> On 02/12/2013 01:04, Christian Groves wrote:
>>>>>>>>
>>>>>>>>> Hello Mary, all,
>>>>>>>>>
>>>>>>>>> In general I'm OK with expressing coding limits in SDP. However
>>>>>>>>> I'm trying to understand what the impact is to the CLUE framework
>>>>>>>>> as a result of that decision. Does that then mean the entire
>>>>>>>>> encoding group concept (i.e. section 8 and 9 (and relevant
>>>>>>>>> examples)) are removed from the framework and that a Capture
>>>>>>>>> Encoding is now effectively a CaptureID and reference to an SDP m-
>>>>>>>>>
>>>>>>>> line? or?
>>>
>>>> Regards, Christian
>>>>>>>>>
>>>>>>>>> On 30/11/2013 8:24 AM, Mary Barnes wrote:
>>>>>>>>>
>>>>>>>>>> HI all,
>>>>>>>>>>
>>>>>>>>>> As mentioned in the email about the November 26th design team
>>>>>>>>>> meeting, there was consensus amongst those on the call that SDP
>>>>>>>>>> should be used for expressing encoding limits for CLUE.  Rob's
>>>>>>>>>> presentation had details as to how it could be done using the
>>>>>>>>>> CLUE protocol, but it was decided (amongst those on the call)
>>>>>>>>>> that we should go with the SDP approach for now and IF an issue
>>>>>>>>>> is encountered with that approach as details are worked we could
>>>>>>>>>> go back to the alternative proposal outlined in those charts.
>>>>>>>>>>
>>>>>>>>>> To move forward, we want to ensure that there is WG consensus
>>>>>>>>>> for using SDP for the encoding limits.  If anyone has any
>>>>>>>>>> concerns about that approach, please post a note explaining why
>>>>>>>>>> no later than
>>>>>>>>>>
>>>>>>>>> Dec
>>>>>
>>>>>> 9th, 2013.   If you weren't at the design team meeting and would
>>>>>>>>>>
>>>>>>>>> like
>>>
>>>> to express your support for the approach, that's also a good idea.
>>>>>>>>>>
>>>>>>>>>> Regards,
>>>>>>>>>> Mary
>>>>>>>>>> As WG co-chair
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> _______________________________________________
>>>>>>>>>> clue mailing list
>>>>>>>>>> [e-mail]
>>>>>>>>>> https://www.ietf.org/mailman/listinfo/clue
>>>>>>>>>>
>>>>>>>>> _______________________________________________
>>>>>>>>> clue mailing list
>>>>>>>>> [e-mail]
>>>>>>>>> https://www.ietf.org/mailman/listinfo/clue
>>>>>>>>>
>>>>>>>> _______________________________________________
>>>>>>>> clue mailing list
>>>>>>>> [e-mail]
>>>>>>>> https://www.ietf.org/mailman/listinfo/clue
>>>>>>>>
>>>>>>>>  _______________________________________________
>>>>>>> clue mailing list
>>>>>>> [e-mail]
>>>>>>> https://www.ietf.org/mailman/listinfo/clue
>>>>>>>
>>>>>>
>>
> _______________________________________________
> clue mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/clue
>