Subject: Re: comments on SDP draft-03

From: Valerie Lasker <[email-masked]>
Date: Thu, 21 Nov 1996 19:52:41 -0200

At 12:54 PM 11/21/96 -0500, Mark Handley wrote:
>>a=framerate:<frame rate>
>>This gives the frame rate in frames/sec. It is intended as a recommendation
>>for the encoding of video data. It is a media attribute.
>
>Did you intend this to always be an integer, or are fractional values
>allowed?  If fractional, we'd better state whether the alternative
>notation of 3,1415 is allowed (as opposed to 3.1415).
>
>I suggest the wording:
>
>This gives the maximum frame rate in frames/sec.  It is intended as a
>recommendation for the encoding of video data.  Decimal
>representations of fractional values using the notation
>"<integer>.<fraction>" are allowed.  It is a media attribute.

Yes, fractional values do make sense. So does your wording.

>
>>a=quality:<quality>
>>This gives the compression quality. For H.261, it is a number between 1 and
>>10. It is intended as as recommendation for the encoding of the video data.
>>It is a media attribute.
>
>Is 1 or 10 intended to be best quality?
10 is.
>
>Do you intend to specify anywhere how this is to be mapped onto H.261
>quantisers? Personally I'd prefer to specify the largest quantiser
>permissible as vic does (the app is always free to choose smaller
>quantisers if it has sufficient bandwidth available)

Yes, our implementation does dynamically quantization.

I didn't realize, but do now, that we map 1-10 to H.261's 31-1.

I do still think it makes sense to have an attribute that everyone can use
for compression quality, but it needs to be codec and implementation
specific. How about something like:

a=quality:<quality>
This can be used to provide information about compression quality to the
video codec. It is a media attribute.
>Mark

-- Valerie

---

From: Mark Handley<[email-masked]>
Date: Fri, 22 Nov 96 08:37:50 -0500

>video codec. It is a media attribute.

It seems we have a few choices
 
1. specify a "quality" attribute and specify that it is defined how to
map this onto codec parameters elsewhere (where?)

2. specify a "quality" attribute (say 0-10) and state that 10 is the
best still-image quality the compression scheme can give, 0 is the
worst still-image quality the codec implementor thought was usable,
and 5 is the default setting for the codec.

3. not specify a "quality" attribute at all, but specify attributes
like "h261-max-quantiser" or whatever you wish to call it.

Either 2. or 3. seem reasonable to me.  With 2, at least setting a
value of "7" means I care more about image quality than frame rate,
and "3" means the opposite.  Option 1. seems to punt the issue to
some as yet undefined place, and I'm not really happy about that.

What do people think?

Mark

---

From: "Lucia Gradinariu" <[email-masked]>
Date: Sat, 23 Nov 1996 22:16:46 +0100 (MET)

some comments related to an eventual quality attribute but not only...

when someone has to announce a more complex session (using more then
one instanciation of each media, a local session manager to offer
a friendly user interface and to do a certain quality management, etc)

- could he declare a=media_tool:name to let the local session manager 
disseminate which application to start in the case where there are two (say 
video) channels reclaiming different applications (say for quality consideration)

- if a local session manager has to change media format or media quality during
the session ( while trading bandwidth, quality and priority to fit declared
CT) how could this be announced ? consequently is a=quality easy to manage
in a complex session announce?

- a conference control protocol should not be consider like a media as a 
conference is or it is not under control. if control appears like an m=
then somebody can start some other media declared also like m= without starting
the local control tool and escape from the control policy (unless there are
some means to declare all media under control and to disable their reception
until the control tool is started) This is also unclear from the draft spec.

- the draft does not propose how can someone negociate a session & media description
(actually there is sdr cilent but  mailing a description file to the server
might be helpful when you need to announce a session and you have no sdr client
at home; + a verification procedure)

- there is (i think) no mean to connect to a session otherwise than starting
tools for each media + a communication control (eventually). the problem is
if one session uses a local session manager which starts tools only when and
with the quality users need to accomplish a common task, then how this local
manager could be advertised in SDP?

thanks for your time,

--------------------------------------------------------------------------------
Lucia GRADINARIU, Eng.
CISM-Univ. Cl. Bernard Lyon1			voice:(33).72.43.13.69
Bat. 101 Bd. du 11 Novembre 1918		fax:(33).72.44.84.10
69622 Villeurbanne FRANCE			email:[email-masked]
		http://www.univ-lyon1.fr/CISM/lucia
---------------------------------------------------------------------------------

---

From: Mark Handley<[email-masked]>
Date: Sun, 24 Nov 96 00:06:27 -0500

>video) channels reclaiming different applications (say for quality considerati

It's not illegal, but I'd really want to discourage this strongly.  If
the description doesn't provide functional reasons to choose between
potential tools, then I believe it should be a local choice not
dictated by the session initiator.

>in a complex session announce?

This is not a property of the description protocol, but of the context
in which you might use the description protocol.  Consequently it's
outside the scope of this draft.  It might be appropriate to do this
in SCCP or RTSP or some other persistent stream control protocol.

>until the control tool is started) This is also unclear from the draft spec.

I'm not sure I understand you.  You can never enforce legal compliance
with aprotocol or any recommendation in any networking context -
people will alwasy try to break the rules.  

>at home; + a verification procedure)

Again, this is a description format.  How you do negotiation is
outside the context of this draft.  See teh SIP and SCIP drafts for
ways you might choose to do limited negotiation (or H.245 if you have
a lot of spare time).

>manager could be advertised in SDP?

See SIP, SAP, SCIP, H.323/Q.321 and T.124 for five diffrent ways to do this.
The first three can easily use SDP.  

Mark