RE: H.261 video problems - fixed

> 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.

You pretty much described the Salyens solution, except that it never recodes
anything (for speed efficiency).

And since it is all in software, whether mode B packets are allowed or not,
along with maximum packet size and many other things is settable on-the-fly.

> > 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.

Right, and this is the only feature that I wanted and had to cancel. Currently
my priorities are elsewhere, but maybe in the future?

> 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

Knowing whether 3rd-party endpoints do or don't support mode B allows me to
select this option in the encoder at run time (currently on a maker
granularity).

This was a rare pleasure discussing such things with you. Too bad that I cannot
sell you something to top it off! (But I will sure get in touch if I ever need
to buy an H.264 codec.)

Regards,
Guilhem.


        
                
__________________________________ 
Do you Yahoo!? 
Yahoo! Mail - You care about security. So do we. 
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
------------------------------------------------------------------------