From rem-conf-de-admin@mbone.de Wed Nov 26 23:41 MET 1997
Received: from faui45.informatik.uni-erlangen.de (daemon@faui45.informatik.uni-erlangen.de [131.188.2.45])
	by faui40.informatik.uni-erlangen.de (8.8.7/8.1.4-FAU) with ESMTP id XAA24294; Wed, 26 Nov 1997 23:40:59 +0100 (MET)
Received: (from daemon@localhost)
	by faui45.informatik.uni-erlangen.de (8.8.6/8.1.16-FAU) id XAA04775
	for rem-conf-de-members@mbone.de; Wed, 26 Nov 1997 23:40:52 +0100 (MET)
Received: from mail1.es.net (mail1.es.net [198.128.3.181])
	by faui45.informatik.uni-erlangen.de (8.8.6/8.1.16-FAU) with SMTP id XAA04755; Wed, 26 Nov 1997 23:40:36 +0100 (MET)
Received: from list by mail1.es.net with local (Exim 1.71 #1)
	id 0xapsX-0005HX-00; Wed, 26 Nov 1997 14:24:17 -0800
Date: Wed, 26 Nov 1997 17:20:42 -0500
From: garys@python.pictel.com (Gary Sullivan)
Message-Id: <9711262220.AA07310@python.pictel.com>
To: itu-adv-video@listserv.iterated.com, rem-conf@es.net
Subject: H.263+ RTP Packetization
X-Mailing-List: <rem-conf@es.net> 
X-Loop: rem-conf@es.net
Sender: owner-rem-conf-de@mbone.de
Precedence: bulk
Content-Type: text
Content-Length:  5690
Status: RO



To ITU-T Q.15/SG16 and IETF AVT Experts,

Attached is the plain-text version of some comments
I have written regarding the drafted RTP payload
packetization format specification for H.263+.

I understand that this topic will be discussed at
the IETF meeting on Dec 10&11 as well as at the ITU-T
Q.15/16 meeting Dec 2-5.

Best Wishes,

Gary Sullivan

PictureTel Corp. M/S 635    Tel:   +1 978 623 4324
100 Minuteman Road          Fax:   +1 978 749 2804
Andover MA 01810  USA       Email: garys@pictel.com
____________________________________________________



ITU - Telecommunications Standardization Sector
STUDY GROUP 16
Video Coding Experts Group
_________________
Third Meeting: Eibsee, Germany, 2-5 December 1997
Document: Q15-C-39
Filename: q15c39.txt
Date generated: 11/25/97

Question: Q.15/16

Source:   Gary Sullivan
  PictureTel Corporation
  100 Minuteman Rd.
  Andover, MA  01810

Tel:   +1 978 623 4324
Fax:   +1 978 749 2804
Email: garys@pictel.com

Title:   Comments on Draft RTP Payload Packetization
         Format Specification for H.263+

Purpose: Information
_____________________________

This contribution contains a few comments regarding the draft RTP
payload packetization document for H.263+ as circulated on the
itu-adv-video@listserv.iterated.com email reflector on 13 November
1997.  Some or all of these comments may be obsolete if the draft has
been revised since that time.

I first wish to say that I am very pleased to see that the work on
this topic is progressing and that it in fact appears to be reaching
a pretty stable specification.  However, I would like to express a
few (mostly minor) concerns.  Although the work toward the
specification of the packetization is being conducted primarily in
the IETF, the ITU-T video coding experts would also presumably be
interested in these remarks as well.  Please note that none of the
changes that I request below would have any effect of invalidating a
packetization process or a packetized bitstream designed according to
the existing draft [Oops - that's not true about item 2d].

1) The introduction (section 1) should mention Reference Picture
   Selection along with Slices and ISD  mode as a key aspect of
   H.263+ affecting packet-network transport use.   

2) The specified format seems a bit heavy on the amount of overhead
   recommended or required.   Specifically:

   a) It *requires* (Sec. 4.2, first sentence) a copy of the entire
      picture header to be attached to every packet that starts with
      a GOB or slice start code.  Although I think it is a *great*
      idea to allow such extra picture headers to be attached, I
      strongly suggest changing the text to *allow* and perhaps to 
      *encourage*, but not to require them.  The extra picture
      headers can be very repetitive and unnecessary in many
      circumstances, and can result in a great deal of extra data
      being sent.  

   b) It strongly recommends a header and a separate packet for every
      GOB.  But is it a bad idea, for example, to put two GOBs in
      each packet and only have a header on the first of each two
      (cutting the overhead in half)?  I think the wording on this
      could be softened a little bit (although the present wording
      does allow freedom for implementers as I read it).  

   c) It recommends a complete picture header (UFEP = '001') on every
      picture.  In some circumstances, this may be unnecessary since
      the OPPTYPE and its accompanying data may be the same for many,
      many pictures in a row and since GFID will let the decoder at
      least know when it changes (and since a complete picture header
      will appear periodically anyway).  I think the wording on this
      could be softened a little bit (although the present wording
      does allow freedom for implementers as I read it).

   d) When sending a redundant copy of a picture header, the first
      six bits ('100000') are always the same, and are therefore
      unnecessary.  I suggest not sending them.  I suppose the
      motivation is ease of byte-oriented processing, but it doesn't
      seem like that much of a burden to always shift the header by
      six bits.

3) The description of the TID and Trun fields is clearly inadequate
   (Sec. 4).  Their use is entirely undefined, and the reference
   given as a citation (draft 20 of H.263+) will be of little or no
   help to the reader trying to figure them out.  (Also, I suspect
   that TID and Trun will sometimes be present in INTRA pictures,
   although no INTRA picture will use the RPS mode of H.263+.) 

4) It may be useful to allow redundant picture headers to be attached
   to packets already containing picture headers, and to allow the
   redundant picture header attached to packets that begin with a GSC
   or SSC to be altered in one key way.  If the picture header in the
   H.263+ payload bitstream itself is an abbreviated picture header
   (UFEP = '000'), then it would be useful to allow the packetization
   process to construct and attach a redundant complete picture header
   (rather than attaching a copy of the abbreviated picture header).
   In this way, the error robustness of the system can be enhanced
   without increasing the bit rate of the payload or adding knowledge
   of the packetization process to the encoder which is generating the
   payload bitstream.

5) The draft as I have it appears not to be dated.  Dating the
   document would be helpful to establish when the draft has become
   obsolete or which of two versions is newer.

Again, however, I wish to say that my overarching sentiment is that
I am pleased with the progress of work on this topic.


