H.323 Overhead

[Gary Sullivan]

I don't entirely agree with the video comments below.
Video codecs operating at low bit rates typically vary
their frame rate (and thus their GOB rate) depending on
the degree of visual activity in the scene.  The overhead
from H.323 packetization is far from negligible.

Packetization schemes for video often allow the encoder
to decide how much data to place in each packet.
For example, RFC 2429 for H.263 allows up to a full picture
in one packet.  (It also allows the picture to be chopped
into multiple packets if desired.)  The larger the packet size,
the lower the overhead (and the higher the delay).

The overhead is *not* negligible -- I believe each H.323 packet
adds a minimum of 40 bytes of overhead.

(Stephan Wenger would be the authority on the packet overhead.)

Some packetization schemes (see RFC 2190) advocate using
a packet for every GOB.  That's a bad idea.  If you're running
CIF resolution H.263 (18 GOBs per picture) at 15 frames per
second, and if I'm right about the 40 bytes overhead per GOB,
then that seems to work out to 86.4 kbits per second just for
the overhead if you send each GOB in its own packet.  That
overhead rate is enough to send a second CIF resolution H.263
video stream!

-Gary Sullivan




+> -----Original Message-----
+> From: Ami Amir [mailto:Amir at TLV.RADVISION.COM]
+> Sent: Friday, February 11, 2000 11:46 PM
+> To: ITU-SG16 at MAILBAG.INTEL.COM
+> Subject: Re: H.323 Overhead
+>
+>
+> Hi Steve and All
+>
+> Video does not gain from silence suppression. The equivalent
+> to "silence" is
+> no motion. H.261 was really designed for constant GOBS per
+> second (Group of
+> Blocks). The number of GOBs varies by the level of
+> compression and quality
+> (CIF vs QCIF). No motion = a  GOB which is practically empty
+> - which creates
+> a packet that is only overhead => not very efficient. Since
+> this the 'best
+> case" situation as far as total bandwidth taken up by the
+> video stream, I
+> would not worry about it.
+>
+> When there is lots of motion - the GOBS are very big, and
+> the frame size is
+> really the maximum  RTP frame allowed by the network. When
+> this occurs, the
+> overhad is negligible.
+>
+> To summarize - for H.323 (it is really for RTP - since all
+> protocols i.e.
+> SIP and MEGACO/MGCP/.... use RTP) the more data you send -
+> the lower the
+> overhead.
+>
+> H.323 signaling overhead is practically nill (again like SIP
+> and MGCP).
+> Signaling information is sent only when there are changes -
+> e.g. call set up
+> or tear down.
+>
+> As Steve correctly states - the only real issue is at the
+> edge (say PPP
+> connections via RAS - remote access modems). This is the
+> place where the
+> attention needs to be placed, i.e. header compression etc.
+>
+> H.320 (H.221 really) was designed for maximum efficiency in
+> TDM circuits.
+> H.221 sacrifices simplicity for bandwidth. The data is NOT
+> organized in
+> bytes and requires a lot of bit manipulation. Overhead is
+> really neglible.
+> As far as I remember - for 128kbps - it is less than 5%.
+>
+> Ami
+>
+> -----Original Message-----
+> From: Stephen Casner [mailto:casner at CISCO.COM]
+> Sent: Friday, February 11, 2000 6:34 PM
+> To: ITU-SG16 at MAILBAG.INTEL.COM
+> Subject: Re: H.323 Overhead
+>
+>
+> On Fri, 11 Feb 2000, Francois Menard List Account wrote:
+>
+> > In terms of the overhead related to
+> > packets transmission, it is RTP encapsulation which is
+> causing a lot of
+> > overhead.
+>
+> Actually, the 12 bytes of RTP aren't the biggest part.
+> There's also 8
+> for UDP, 20 for IP, and some more for a link-level header.  But the
+> IP/UDP/RTP part can be compressed down to a few bytes across links
+> where that matters.
+>
+> This compares to the H.221 overhead for H.323 -- I don't
+> know that number.
+>
+> But in the IP case, you also gain from silence suppression, which I
+> believe is only done on specialized links in the circuit case.
+>
+> In my opinion, the focus on transmission overhead is misguided.  If
+> you believe predictions that voice bandwidth will be a small fraction
+> of the converged IP network, then that overhead in the
+> backbone should
+> not be an issue.  Header ompression can be used on narrow
+> links at the
+> edges.
+>                                                         -- Steve
+>