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.

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

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

This is unless you are dealing with non-standard codecs such as IBM's JMF one
and RadVision's eConf that can't decode mode B. Funnily enough, some endpoints
actually encode in mode B only.

Regards,
Guilhem.


                
__________________________________ 
Do you Yahoo!? 
Read only the mail you want - Yahoo! Mail SpamGuard. 
http://promotions.yahoo.com/new_mail 
------------------------------------------------------------------------
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
------------------------------------------------------------------------