Subject: letter from ITU video coding experts group

From: Barry Haskell <[email-masked]>
Date: Wed, 12 Jul 2000 16:11:49 -0400

To IETF AVT group

Here's a communication from the ITU-T SG16 Q15 experts group on video
coding.  They are responsible for the H.263 video coding algorithm.  The
latest version, to be finalized in November, contains optional profiles
and levels, which is the subject of this communication.  It proposes a
MIME registration with optional parameters "profile" and "level" in
order to enable their use in SDP.

--
 Barry G. Haskell         AT&T Labs - Research
 [email-masked]     http://www.research.att.com/info/bgh
(also  [email-masked])

AT&T Labs  NSL 3-223                  tel: +1 732 345 3300
100 Schultz Drive - Middletown        fax: +1 732 345 3033
Red Bank, NJ 07701-7033

ITU - Telecommunications Standardization Sector
STUDY GROUP 16
Video Coding Experts Group (Question 15/16)

Document  Q15-J-76
Filename: q15j76.doc
Generated: 11 July 00

Source:
Video Coding Experts Group (Question 15/16)

ITU 
Contact:
Gary Sullivan,
ITU-T Rapporteur of Advanced Video Coding 
(Q.15/16)
Microsoft Corporation
One Microsoft Way
Redmond, CA 98052 USA
Tel:
Fax:
Email:
+1 425 703 5308
+1 425 936 7329
[email-masked]
Title:
Specifying H.263 Profiles in IETF Environments
Purpose:
Liaison and Collaboration with IETF AVT 
IETF 
Contacts
Stephen Casner, Colin Perkins, Joerg Ott

Specifying H.263 Profiles in IETF Environments
1.	Introduction
We understand that the IETF is progressing rapidly with the latest revision of the Session Initiation Protocol (SIP), 
formally known as RFC 2543bis.  In order to specify the multimedia streams that may be used during the session, 
SIP uses the Session Description Protocol (SDP), formally known as RFC 2327.  For real-time streams, the IETF 
uses the Real Time Protocol (RTP) [formally known as RFC 1889], and for this, several RTP “payload formats” 
were defined [RFC 1890, draft-ietf-avt-profile-new-08], including one for the original version of H.263 [RFC 
2190].  Later a payload format for the 1998 version of H.263 (known as H.263+) was also defined [RFC 2429], 
which was sufficient for use with capability exchange using ITU-T’s H.245.  However, RFC 2429 had no mention 
of H.263 profiles.  
For email attachments the MIME specification is used to describe the content.  MIME descriptions are registered 
with IANA (Internet Assigned Numbers Authority).
At the ITU-T  SG16  Q15 meeting concluded in May, we prepared a nearly final draft of definitions of profiles and 
levels for H263 video coding.  These will appear in the next version of H263 (aka H263-2000) to be finalized in 
November.  Currently we have drafted definitions of profiles numbered 0 through 4, and levels 0 through 2.  The 
most recent tentative version is in Table II.2/H.263 below.
For maximum interoperability with simplified capability exchange, this contribution proposes that H.263 profile 
and level specification be included in MIME and SDP messages.  In particular, the profile designed specifically for 
Broadband Internet use is profile 4.

2. Possible Ways of Proceeding
The most visible way to proceed would be to define a new RTP payload formats for each H.263 profile and level as 
it comes to be used in the market.  But that's a lot of payload formats – and also, the process for progressing from 
draft to RFC is fairly lengthy in the IETF.  And as far as the packetization format is concerned, RFC 2429 appears 
adequate for all of these profiles.  H.263 bitstreams themselves are also self-contained in that they contain all 
information necessary to decode them.  An alternative would be to define new SDP attributes "profile" and "level". 
Again, however, revising SDP would be a long process and might have backward compatibility implications.
Still another way would be to register optional parameters "profile" and "level" under MIME, and use them in the 
existing SDP fmtp attribute.  This has the benefit of backward compatibility, and can be implemented easily.  They 
could also be useful in specifying MPEG profiles and levels.

3. Proposal for MIME registration
We therefore propose consideration of registering with IANA the new optional parameters "profile" and "level" to 
be used with the MIME subtype H263-2000.  A current IETF draft [draft-ietf-avt-rtp-mime-02.txt] is in the process 
of registering many multimedia payload formats, including H263+ (aka H263-1998).  Perhaps two optional 
parameters, "profile" and "level", could be added to a H263-2000 registration.  
A typical MIME specification for say profile 4, level 2 would look like…
	video/H263-2000;profile=4;level=2

4. Proposal for SDP to use fmtp attributes profile and level
We ask consideration of using the MIME optional parameters "profile" and "level" under the existing SDP fmtp 
attribute as described in draft-ietf-avt-rtp-mime-02.txt.  For example, to specify profile 4, level 2 the SDP entries 
would be (using say dynamic payload number 98 and UDP port 49232)
	m=video 49232 RTP/AVP 98
	a=rtpmap:98 H263-2000
	a=fmtp:98 profile=4;level=2
For interactive sessions, an endpoint could indicate all profiles and levels it was capable of handling by including 
multiple entries.  For example, a coder that could handle profiles 3 and 4 at level 2 could indicate this by…
	m=video 49232 RTP/AVP 98 99
	a=rtpmap:98 H263-2000
	a=rtpmap:99 H263-2000
	a=fmtp:98 profile=3;level=2
	a=fmtp:99 profile=4;level=2

5. Conclusion
 We look forward to progress on these issues.

---

From: Stephen Casner <[email-masked]>
Date: Thu, 13 Jul 2000 20:54:43 -0700 (Pacific Daylight Time)

> order to enable their use in SDP.

I have added the optional parameters proposed above into the next
revision of draft-ietf-avt-rtp-mime-03.txt which I will submit for
posting tomorrow morning before the deadline.  The new next is
included below for your review.

Please note that I have added these optional parameters to the
existing registration for media type video/H263-1998 rather than
adding a registration for a new media type video/H263-2000.  I did so
because video/H263-1998 indicates the payload format specified in RFC
2429, and that payload format will continue to be used with the
November, 2000 version of the H.263 specification.  If we defined a
new media type, that might prevent interoperation between a 1998 and a
2000 implementation even though they are operating at a profile and
level which is common to both.  That is, my understanding is that the
2000 version is the same as the 1998 version with additional annexes.
I assume that some of the profiles reduce to the 1998 version.

If you disagree with this reasoning, please speak up.

							-- Steve

4.2.6.  Registration of MIME media type video/H263-1998

     MIME media type name: video

     MIME subtype name: H263-1998

     Required parameters: None

     Optional parameters:
          profile: H.263 profile number, in the range 0 through 4, spec-
          ifying the supported H.263 annexes/subparts.

          level: Level of bitstream operation, in the range 0 through 2.

     Published specification: RFC 2429

          Profile and level specifications may be found in the November,
          2000 version of ITU Recommendation H.263, "Video coding for
          low bit rate communication".

							-- Steve

---

From: Stephan Wenger <[email-masked]>
Date: Fri, 14 Jul 2000 10:44:07 +0200

Steve, Group,

>adding a registration for a new media type video/H263-2000.

>If you disagree with this reasoning, please speak up.

The problem here is that H.263's Appendix 1 of 1998 (which defines
recommended mode combinations) was replaced by a new
Appendix 1 in H.263 of 2000 (which defines profiles/levels).
The reason why I asked Barry to change to H.263-2000 was to
avoid confusion by people, who see in their copy of H.263-1998
the recommended mode combos, say "hmm, the keyword
profile/level does not appear here, but the Appendix implements
something very similar" and implement those mode combos,
which are not compatible with the mode combos of H.263-2000.
Interoperability would not be achieved.

I understand that you clarify the issue in the descriptions, but
the source of confusion remains.

This is, by the way, just an example for the problem of registering/
referencing non-normative information in a normative document.
I hope, Steve, that you are aware that ITU-T's Appendixes are non
normative, and can be changed in a non compatible way at any
working party meeting.  For several reasons Q.15/16 of the ITU-T
decided against making the profile/level Appendix a normative
Annex (which would have solved the problem completely).  Even
referencing explicitly the November 2000 version of H.263 does
not solve the problem, because people who buy H.263 in 2001 (with a
potentially changed Appendix 1) would still receive a paper with
the identical title, but containing the changed Appendix.

Stephan

---

From: Barry Haskell <[email-masked]>
Date: Fri, 14 Jul 2000 10:30:30 -0400

Stephan Wenger wrote:

> recommended mode combinations) was replaced by a new Appendix 1 in H.263 of
> 2000 (which defines profiles/levels).

Actually, it's Appendix II

> The reason why I asked Barry to change to H.263-2000 was to avoid confusion
> by people, who see in their copy of H.263-1998 the recommended mode combos,
> say "hmm, the keyword profile/level does not appear here,

Yes, the problem is that the term "H.263-1998" is overloaded.  Sometimes it
means packetization, and sometimes it means both packetization and video
coding.  For this reason, Stephen's registration says look in the 2000 version
of H.263 for definitions of profile and level.  If more profiles and levels
are added, the registration would have to be updated to point to the latest
version, which would be backward compatible.

> but the Appendix implements something very similar" and implement those mode
> combos, which are not compatible with the mode combos of H.263-2000.

The "mode combinations" of 1998 are exactly the same as profiles 1-3 of 2000,
so they are compatible.   However, there are no levels of bitrate, picture
size, etc. specified in 1998, so it's not very useful for SDP capability
exchange.

> I hope, Steve, that you are aware that ITU-T's Appendixes are non normative,
> and can be changed in a non compatible way at any working party meeting.

Well it's a little harder than that, but so far, the changes are compatible.
We certainly expect that to continue if more profiles and levels are added.

>  Even referencing explicitly the November 2000 version of H.263 does not
> solve the problem, because people who buy H.263 in 2001 (with a potentially
> changed Appendix 1) would still receive a paper with the identical title,
> but containing the changed Appendix.

Perhaps, but it would be backward compatible.

PS Any thought of adding profile & level to MPEG2?

---

From: Stephen Casner <[email-masked]>
Date: Fri, 14 Jul 2000 14:06:43 -0700 (Pacific Daylight Time)

Stephan, Barry,

OK, perhaps I looked at the interoperability question from the wrong
direction.  If there are bitstreams that an H.263-2000 encoder would
send that an H.263-1998 decoder can't handle because of additional
appendices / annexes, then a new encoding name is required.

I will add H263-2000 in the RTP MIME draft.

> > but containing the changed Appendix.

If necessary, we can continue to define additional MIME types.  That
is why we reached the conclusion that we should make no more static
RTP payload type number assignments.

> PS Any thought of adding profile & level to MPEG2?

Not sure what you are asking.  There are some parameters specified for
the MPEG audio and video MIME registrations in the rtp-mime draft.

							-- Steve

---

From: Stephan Wenger <[email-masked]>
Date: Fri, 14 Jul 2000 23:47:02 +0200

Dear Steve, Group,

>RTP payload type number assignments.

I fail to see the point here.  Of course you can add MIME types.  But
what happens if WP3/16 decides to change Appendix II, but not to issue
a 2001 version of H.263?  They can do that any time they want.
And you buy in 2002 something from the ITU-T that is still called
H.263-2000, but is different from what was H.263-2000 in 2000.
I agree with Barry and others that this is VERY unlikely to happen,
but no procedure is in place to prevent such a change.

Changes to appendices don't need to be upward/downward compatible
or anything.  They are in their very nature like informational RFCs or
even less.

For all those reasons there is no simplified negotiation system for H.32x
systems.  Well, there is one, sort of:  In H.320's cap exchange
protocol H.242, there is a shortcut for certain mode combinations that
correspond to some of the profiles/levels.  But the optional modes identified
by those profiles/levels are spelled out again here, in a normative and
unchangeable way.

Stephan