Subject: [clue] Ticket #36 removing pixels per second from framework encoding and encoding group

From: "Duckworth, Mark" <[email-masked]>
Date: Mon, 30 Sep 2013 10:18:35 -0700

Ticket #36<http://trac.tools.ietf.org/wg/clue/trac/ticket/36> - Cleanup encoding parameters for pixels/sec (computational complexity)

Please comment on these specific changes I am proposing.

At the interim meeting, I said I would propose changes to remove some of this detail from the framework.  We agreed the framework should not itemize or give detail on codec specific parameters.

Here is what I will change in the framework regarding the pixels per second in an Encoding Group (section 7.2):

Change from:
"By grouping multiple individual Encodings together, an Encoding Group describes additional constraints on bandwidth and other parameters for the group."
To:
"By grouping multiple individual Encodings together, an Encoding Group describes additional constraints on bandwidth for the group."

Remove list item: "Maximum number of pixels per second for all video encodings of the group combined."

Remove sentence: "Likewise, the sum of the pixels per second of each instantiated encoding in the group must not exceed the group value."

Remove references to MaxGroupPps in section 11.1.1 and 11.1.2 examples.  Remove explanation about trading off between resolution and framerate among encodings in a group.  Keep something about trading off bandwidth according to maxBandwidth and maxGroupBandwidth parameters.

For individual encodings this is the current text in section 7.1:
==== begin current ========================================
   An Individual Encoding represents a way to encode a Media Capture to become a Capture Encoding, to be sent as an encoded media stream from the Provider to the Consumer.  An Individual Encoding has a set of parameters characterizing how the media is encoded.
   Different media types have different parameters, and different encoding algorithms may have different parameters.  An Individual Encoding can be assigned to at most one Capture Encoding at any given time.
   The parameters of an Individual Encoding represent the maximum values for certain aspects of the encoding.  A particular instantiation into a Capture Encoding might use lower values than these maximums.
   In general, the parameters of an Individual Encoding have been chosen to represent those negotiable parameters of media codecs of the media type that greatly influence computational complexity, while abstracting from details of particular media codecs used.  The parameters have been chosen with those media codecs in mind that have seen wide deployment in the video conferencing and Telepresence industry.
   For video codecs (using H.26x compression technologies), those parameters include:

*         Maximum bitrate;

*         Maximum picture size in pixels;

*         Maxmimum number of pixels to be processed per second; and

*         Clue-protocol internal information.
   For audio codecs, so far only one parameter has been identified:
Maximum bitrate.
==== end current ========================================

I propose keeping the first three paragraphs as is.  And change the rest to something like this:
==== begin proposed========================================
   <first three paragraphs unchanged>
   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;

*         Maxmimum 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.
==== end proposed ========================================

Regards,
Mark

---

From: Christian Groves <[email-masked]>
Date: Tue, 01 Oct 2013 12:17:05 +1000

Hello Mark,

Looks OK to me. I guess you'll also remove the two editor's notes at the 
bottom of section 7.1?

dt. note: the maximum number of pixel per second are currently
    expressed as H.264maxmbps.

    Edt. note: it would be desirable to make the computational
    complexity mechanism codec independent so to allow for expressing
    that, say, H.264 codecs are less complex than H.265 codecs, and,
    therefore, the same hardware can process higher pixel rates for
    H.264 than for H.265.  To be discussed in the WG.

Christian

On 1/10/2013 3:18 AM, Duckworth, Mark wrote:
>
> Ticket #36 <http://trac.tools.ietf.org/wg/clue/trac/ticket/36> - 
> Cleanup encoding parameters for pixels/sec (computational complexity)
>
> At the interim meeting, I said I would propose changes to remove some 
> of this detail from the framework. We agreed the framework should not 
> itemize or give detail on codec specific parameters.
>
> Here is what I will change in the framework regarding the pixels per 
> second in an Encoding Group (section 7.2):
>
> Change from:
>
> “By grouping multiple individual Encodings together, an Encoding Group 
> describes additional constraints on bandwidth and other parameters for 
> the group.”
>
> To:
>
> “By grouping multiple individual Encodings together, an Encoding Group 
> describes additional constraints on bandwidth for the group.”
>
> Remove list item: “Maximum number of pixels per second for all video 
> encodings of the group combined.”
>
> Remove sentence: “Likewise, the sum of the pixels per second of each 
> instantiated encoding in the group must not exceed the group value.”
>
> Remove references to MaxGroupPps in section 11.1.1 and 11.1.2 
> examples. Remove explanation about trading off between resolution and 
> framerate among encodings in a group. Keep something about trading off 
> bandwidth according to maxBandwidth and maxGroupBandwidth parameters.
>
> An Individual Encoding represents a way to encode a Media Capture to 
> become a Capture Encoding, to be sent as an encoded media stream from 
> the Provider to the Consumer. An Individual Encoding has a set of 
> parameters characterizing how the media is encoded.
>
> Different media types have different parameters, and different 
> encoding algorithms may have different parameters. An Individual 
> Encoding can be assigned to at most one Capture Encoding at any given 
> time.
>
> The parameters of an Individual Encoding represent the maximum values 
> for certain aspects of the encoding. A particular instantiation into a 
> Capture Encoding might use lower values than these maximums.
>
> In general, the parameters of an Individual Encoding have been chosen 
> to represent those negotiable parameters of media codecs of the media 
> type that greatly influence computational complexity, while 
> abstracting from details of particular media codecs used. The 
> parameters have been chosen with those media codecs in mind that have 
> seen wide deployment in the video conferencing and Telepresence industry.
>
> ·Maximum bitrate;
> ·Maximum picture size in pixels;
>
> ·Maxmimum number of pixels to be processed per second; and
>
> ·Clue-protocol internal information.
>
> 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;
>
> ·Maxmimum 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.
>
> _______________________________________________
> clue mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/clue