Subject: SDP format for H.263 options

From: [email-masked] (Koskelainen Petri NRC/Tre)
Date: Fri, 12 Sep 1997 11:36:09 +0200

Hi,

Currently it is not possible to specify any codec specific options
in SIP/SDP architecture. For example, H.263 has many options and
parameters which are almost mandatory (it makes no sense to say
"lets use H.263" without knowledge of its capabilities).

Best place to include these codec specific parameters in SDP is:
a=fmtp:<format> <format specific parameters>

So, these format speficic parameters must be defined somewhere
and it seems (like Henning proposed) that the best place to do it,
is in corresponding RTP mapping draft as an annex.
Another solution is to make new internet-draft (for every codec).

Below is a proposal for H.263 SDP format specific parameter mapping,
to be included into "RTP Payload Format for H.263 Video Streams" draft.

This proposal assumes:
(needs to be said also in the SIP draft)

In the case of SIP, these codec options mean decoder capabilities.
The idea is, that when making an INVITE, it includes the codec (H.263) and
those codec options (e.g. SAC, PB-frames) which are decodeable by
this decoder.

Example excerpt from SIP INVITE message:
...
m=video 55514 RTP/AVP 34
a=fmtp 34 CIF=4 QCIF=2/MaxBitRate=1000/SAC/AP

Syntax above means that H.263 codec with preferred picture size of CIF (with 
min picture interval of 4) and secondary picture size is QCIF and arithmetic 
coding and advance prediction are in use and max bitrate decoable by decoder 
is 100 kbit/s.

If caller does not want to receive all options (perhaps because
his pc is a slow 486) then he just tells what options he wishes to receive.

Other end, may (or may not) use them in the encoder.

Any comments about mapping or the right place to define these ?

 --------------------------------------- clip clip----------------------

                              Harri Honko
                              Petri Koskelainen
                              Jouni Salonen
                              Nokia Research Center

ANNEX A  (in "RTP payload format for H.263 video")

SDP syntax for H.263 video

This annex defines the SDP [2] syntax for H.263 codec options
and parameters. It is often useful to know beforehand (in call setup phase)
what features of H.263 the other end supports. This annex defines
the <format spefic parameters> for H.263, which exists in
a=fmtp:<format> <format specific parameters> as defined in the SDP document.
Actual usage and negotiation of attributes is specified in SIP [3] and SAP 
[4] documents. These options are especially useful in SIP.  In SAP it is not 
clear whether they have any use.
In SIP, these format specific parameters are decoder properties, and in SAP 
they are encoder capabilities.  The SAP rules are applied also if a 
multicast session is advertized in a web page in SDP format.

Following text assumes that SIP is used. In the end of this annex, there is 
a short chapter which discusses how these options and parameters are used 
with SAP.

A.1 H.263 Codec Options
Following words describe 4 options defined for H.263. Later versions
of H.263 (e.g. so called H.263+, currently a ITU-T draft) defines more 
options and they should be specified later for SDP. These options are 
separated by single slash ("/") between them.

For further description about these parameters, please refer to
ITU documents [1].

Word: URV
Explanation: UnRestricted motion Vector option.

Word: SAC
Explanation: Syntax based Arithmetic Coding.

Word: AP
Explanation: Advanced Prediction.

Word: PB
Explanation: PB Frames.

These words exist only if the sender of this SDP message is able or willing 
to decode those. E.g. If a terminal is capable of decoding SAC and AP 
options, it can put SAC/AP in the beginning of <format specific parameters>. 
Then the other party knows it, and can use those options in its encoder.

A.2 Other H.263 codec parameters

This chapter describes parameters in H.263 to be used with SIP

Supported picture sizes and their corresponding minimum picture interval 
(MPI) information can be combined. All picture sizes can be advertised to 
other party, or only some subset of it.  Terminal announces only those 
picture sizes (with their MPIs) which it is willing to receive.
MPI is an integer value (1..32) and it means that maximum picture (frame) 
rate is  29.97/MPI value/s. MPI value may be bigger, meaning that picture 
rate is slower. For example, MPI=2 means that maximum (decodeable) picture 
rate per sec is about 15.

Parameter occurring first is the preferred picture mode to be received, and 
last is the least preferred (but still supported) one. Following words are 
presented with no slash ("/") symbol between them, and are separated by 
space.

Following words are present in SDP list only if a terminal is willing to 
decode the picture size. If terminal is not willing to receive some size, it 
is not present in the list.

Word: SQCIF=MPI(1..32)
Explanation: SQCIF picture size and its MPI value. Means that sender can 
decode SQCIF resolution with this MPI value.

Word: QCIF=MPI(1..32)
Explanation:  QCIF picture size and its MPI value. Means that sender can 
decode QCIF resolution with this MPI value.

Word: CIF=MPI(1..32)
Explanation: CIF picture size and its MPI value. If present, means that 
sender can decode CIF  resolution with this MPI value.

Word: CIF4=MPI(1..32)
Explanation: CIF4 picture size and its MPI value. If present, means that 
sender can decode this resolution with this MPI value.

Word: CIF16=MPI(1..32)
Explanation: CIF16 picture size and its MPI value. If present, means that 
sender can decode this resolution with this MPI value.

Word: XMAX=maximum_x_size YMAX=maximum_y_size MPI=MPI(1..32)
This list of  words means that terminal is capable and willing to receive 
arbitrary picture sizes. These X and Y values are the maximum of allowed 
picture sizes with corresponding MPI value. All these three words must exist 
together in this order, or none is allowed to exist. Both picture sizes must 
be divisible by 4.

Example of the usage of these words:

CIF=4  QCIF=3 SQCIF=2 XMAX=360 YMAX=240 MPI=2

This means that sender hopes to receive CIF picture size, which it can
decode at MPI=4. If that is not possible, then QCIF with MPI value 3, if 
that is neither possible, then SQCIF with MPI value =2.  It is also allowed 
(but least preferred) to send arbitrary picture sizes (max 360x240) with 
MPI=2.
Note that most encoders support at least QCIF and CIF fixed resolutions and 
they are expected to be available almost in every H.263-based video 
application.

Following two parameters are used only with SIP.

MaxBitRate=INTEGER(1..19200)
Explanation: maximum video stream bitrate receivable by the sending 
terminals H.263 decoder, presented at 100 bits/s.

BitsPerPictureMaxKb=INTEGER(0..65536)
Explanation: Maximum amount of kilobits allowed to represent a single 
picture frame, value is specified by largest supported picture resolution, 
see [1]. If  this parameter is not present, then default value, that is 
based on the maximum supported resolution, is used.

All these parameters must be presented in SDP a=fmtp line exactly in this 
order if they are present.

Example: (in SIP)
a=fmtp 34 CIF=4 QCIF=2/MaxBitRate=1000/SAC/AP

This means that the sender of this message can decode H.263 (RTP payload 
type 34) bitstream with following options and parameters:
Preferred resolution is CIF (its MPI is 4), but if that is not possible then
QCIF size is ok. Maximum receivable bitrate is 100 kbit/s (1000*100 bit/s) 
and SAC and AP options can be used.

A.3 Use of SDP H.263 options and parameters with SAP

SAP announcements are one-way only. H.263 options (like SAC) mean that 
sending terminal (host) is going to use these options in its transmitted 
H.263 stream. It is just an informal message.

Usually only one picture size (with its MPI) exists. However, since it is 
possible for a video source (terminal) to change its picture size during 
session, several picture sizes can exist in the parameter list. First one is 
the original picture size to be used in the beginning of the session.
Other H.263 parameters are not used with SAP (nor when announced in 
web-page).

Example (with SAP):
a=fmtp 34 CIF=2 URV/SAC

The video source is sending an H.263 bitstream and picture size is CIF, 
MPI=2 and URV and SAC options are used. This kind of announcement can be 
used, e.g., in the MBone.

Authors' Addresses

Harri Honko, Petri Koskelainen, Jouni Salonen
Nokia Research Center
P.O.Box 100
FIN-33721 Tampere
Finland
e-mail:
[email-masked],
petri [email-masked],
[email-masked]

 References:

 [1]  International Telecommunication Union.
 Video Coding for Low Bitrate Communication, ITU-T Recommendation  H.263, 
1996

 [2]  Handley et al, ``SDP - Session Description Protocol'', INTERNET-DRAFT, 
 IETF 1997.

 [3]  Handley et al, ``SIP - Session Initiation  Protocol'',
 INTERNET-DRAFT, IETF 1997.

[4]  ``SAP - Session Announcement  Protocol'',
 INTERNET-DRAFT, IETF 1997.

---

From: Stephen Casner <[email-masked]>
Date: Tue, 16 Sep 1997 16:51:15 -0700 ()

> a=fmtp:<format> <format specific parameters>

I agree that this is the right place to convey additional H.263
parameters for a session.  I presume that these parameter are
instructions to the encoder; that is, except for performance or
implementation constraints, the decoder can tell from the headers what
functions are in use and can decode can decode the stream without
knowing these option settings.

> Another solution is to make new internet-draft (for every codec).

Not sure what you mean by "mapping draft".  The only example use of
a=fmtp I know of so far is in the Redundant Audio payload format,
recently published as RFC 2198.

> to be included into "RTP Payload Format for H.263 Video Streams" draft.

Since the H.263 payload format spec has also been published now as RFC
2190, it would be necessary to produce a revised RFC to add the format
mapping info.  The way to start that process would be to write an
Internet-Draft specifying the details of the format parameters.  That
could be published as a separate RFC, but more likely it would be
better to publish a new combined RFC.  Since the additional
information would be specifying part of the standard, it would
probably not be an annex or appendix but rather an additional section
of the document.

> coding and advance prediction are in use and max bitrate decoable by decoder 

There are already SDP fields to specify maximum bandwidth, so I
suspect that should not be included as a codec parameter.  I don't
know enough about the options in H.263 to say whether what you have
proposed is appropriate/sufficient/etc.  Those who know more about
H.263 should chime in.

One simple comment on the text structure is that I think it would be
better to define the options independent of the protocol in which they
would be used (SIP, SAP or something else) and then state the
applicability to particular scenarios.

The SIP spec should address the capability negotiation (or capability
statement if negotiation does not really occur) in an
encoding-independent manner.
							-- Steve