Subject: [clue] Do we need the encodings as secified in the framework document - proposal to remove them from the framework

From: "Roni Even" <[email-masked]>
Date: Wed, 31 Oct 2012 11:49:45 +0200

Hi,

>From the email discussion it looks to me that the concept of the encoding as
specified in the framework document is not clear. I will try to describe my
understanding of sections 7 and 8 of the framework document and explain why
I think that it is not important to CLUE as specified. I am looking for
response if my understanding of the encoding based on the framework is
correct and how it will work for the examples I will provide bellow

The purpose of the Encodings is to provide INFORMATION about the provider
abilities to send streams. This relates to the available resources (compute
and BW) of the providers.

The encodings are constructed from encoding groups and each encoding group
is include individual encodes. 

The encoding group provide a value for the total maximum BW and compute
H264Mbps (note that it is H.264 specific) of all the individual encodes in
the group that the provider can use to send audio and video.

Each encoding group include a list of individual encodes  (audio and /or
video). These provide maximum values that can be used to instantiate a media
stream by the provider.

Each video individual encodes identified by an encodeID provides maximum
values  for BW, compute, resolution and frame rate for H.264. (BTW: the
maxH264Mbps can be computed from the resolution and frame rate as defined in
table 2 making it redundant). 

Each audio encode has only a BW value (no identifier).

A media capture is associated with an encoding group !!!!! not an individual
encoding.

The provider can use one of the individual encoding to instantiate a media
capture, each individual encoding can be used by one media capture, the
decision of which one to use according to the framework is by the provider.
The consumer does not select an individual encode.

The maximum number of streams that can result from a particular encoding
group is equal to the number of individual encodings in the group (note that
this is why the example in the current data model allows only for one video
and one audio streams).

Section 8 of the framework talk about having more than one individual
encoding assigned to a media capture (simulcast) and also claims that it can
be done by the consumer but there is no way to do it since the media capture
is associated only with an encoding group. There is no way for a consumer
even to assign a specific individual encoding to a group.

My view is that this mechanism does not work and can be removed. The reasons
are given bellow

The encoding as currently specified is provided as information since there
is no way to map one or more individual encoding to a specific media capture

The video is H.264 specific and not general

The relation between the individual encode and encoding group makes it
difficult to achieve a reasonable set even if the consumer will be able to
select the mapping. This is due to the fact the total defined by the group
limits the usage for individual encoding. For example if  we have a three
camera system and we set a value in the  group for maxGroupH264Mbps and want
to allow for simulcast (two resolutions), we will need to define six
individual encodes, three with high resolution ( also high maxH264Mbps) and
three lower resolution with lower maxH264Mbps. If the compute resource can
do all six it will  reflected in the value of maxGroupH264Mbps but I assume
that there is a constrain (otherwise why have encodings) making it lower. So
if the consumer will ask for all six what will happen. Since there is more
than one degree of freedom he will not be able to predict if he will get all
or part on lower frame rate , if he will get only a subset of the streams,
if he will get different resolutions. 

On the other hand if the 6 individual encodes will include lower values to
allow for the group limit it will mean that a consumer not doing simulcast
is limited by the fact the simulcast and ask (if possible) for only three
streams, the individual encodes limit will be low so he will not be able to
use the full compute resources.

Section 8 concludes that the number of individual encodes in a group must
allow for all media capture in a capture scene entry to be used
simultaneously.

So it look like this system does not work well for simulcast. What about no
simulcast, is it needed. For example a three camera system that also have
one presentation. My view that the cameras will be one capture scene and the
presentation will be a second one. The question is if they all belong to one
encoding group, here my view is "no" since they have different priority and
should not compete for compute resources. So we will have two encoding
groups one for presentation and one for the three cameras. For the three
cameras each sending one stream I assume that the resource allocation will
be a third for each so we will have three individual encode with the same
values, this is the basic one and if it is a third than no need for
advertising or configuring. Now if we also want to have an individual encode
that has higher compute if the consumer wants only one capture (of the whole
room), the group will have fourth one with higher value. So if there is way
for consumer to configure individual encode when using three media captures,
he may select the higher capability one with two lower ones. The total will
be limited by the encoding group value and again it is not clear how the
actual streams will be encoded to address the group limit since there are
multiple options.

To summarize I do not see value in the encoding as currently specified since
they only provide information and no option for configuration. The value of
it as information does not justify specifying them and if the intention is
to allow configurations of individual encoding it must be reflected and the
explained how it works.

My proposal is at the moment to remove the encoding until we get some text
that defines how to use it for configuring encoding to media captures
including for the simulcast case

Thanks

Roni Even