RE: H.261 video problems - fixed

> > For baseline H.263 since you have ~18 GOBs per frame you can get to
> > around 6Mbps at 30fps without having to generate mode B packets or
> > exceed the MTU of Ethernet. You are right that when you get to these
> > very high bitrates you do need to generate mode B packets - but on
> > the other hand you should not be transmitting at high rate if there
> > is any significant packet loss, so again the extra information in
> > the RTP header is not that useful.
> 
> I conclude from the above that your codec keeps track of the last GOB
> boundary
> (with bit position and other variables to fill the RTP payload header)
in
> the
> encoding loop. At least, that's how I did get around the issue.

Yes, the simplest and most common way is to generate a whole frame of
bitstream together with some side-band data that gives the positions of
the MB/GOB boundaries, you then do packetization separately after the
encode. 

You don't have to though- a method that is lower latency (on average) is
to directly generate the RTP packets on the fly as you encode. As you
finish each GOB it either fits into the packet you're generating in
which case you add it in, or it doesn't, in which case you send the old
packet and start a new one. You only need mode B packets if one gob
exceeds your max packet size (and even then you don't have to use mode
B, you can just recode the gob with greater quantization.

> Still, GOB vary greatly in size (and I have seen some MBs > 100
bytes). So
> if
> what you say is right, you oversimplify.

This depends on how you have implemented ratecontrol. If, in H.263, you
have implemented the ability to change the quantizer on a per-macroblock
basis then there is no need to have a greatly varying or unpredictable
GOB size. Most encoders estimate the activity of the frame in advance of
encoding and are able to reasonably accurately determine a bound on the
number of bits required for a given macroblock with a given choice of
quantizer.

> I see mode B as a compelling solution for packets of (almost) the same
> size.

Agreed, if your design objective is to create packets that are almost
the same size.

However if your objective is to create packets that are maximally
compatible with other people's decoders, and with the best error
resilience properties, then I believe that mode A should be used
whenever possible (which is almost always, except at very high
bitrates). RFC2190 itself agrees "We strongly recommend use of mode A
whenever possible".

In Codian products the max video packet size is user configurable. We
always strictly obey this. Whilst we always try to produce packets that
are as big as possible (without exceeding the max) this is a secondary
consideration and has a lower priority than starting each packet with a
GOB/slice header.

Regards,
Mark



------------------------------------------------------------------------
Check the FAQ before asking! - http://www.openh323.org/~openh323/fom.cgi
The OpenH323 Project mailing list, using Mailman. To unsubscribe or
change your subscription options, goto
http://www.openh323.org/mailman/listinfo/openh323
Maintained by Quicknet Technologies, Inc - http://www.quicknet.net
------------------------------------------------------------------------