RE: H.261 video problems - fixed

Hi Mark,

> Regarding the comment on the H.261 header (RFC2032),
> I personally wrote the Codian H.261 codec and (de)packetization code
> (also H.263 and H.264).

With the information that I have now at hand, I would like apologies for
implying that the remote endpoint was at fault.

Please be sure that next time I will ask for a trace, and only then make such a
claim (rather than at the same time).

> All our H.261 packets have the I-bit set to 0 (may or may not contain
> intra macroblocks) and the V-bit set to 1 (may or may not use
> motionvectors). I'm not aware of any endpoints that set these bits
> incorrectly but our decoder does not explicitly check them so we
> probably wouldn't notice ;)

You said 2 very important things:

Indeed, the H.261 standard is much better followed (than the H.263 crap).

And most (all) decoders do not care for the RTP bits because encoders do not
set them right in the first place. This has been a long lasting frustration for
me ( see my list of bugs found so far, http://www.salyens.com/?page=interop ),
because using the RTP bits properly is essential for better coping with error /
packet loss on the Internet. That on top of obvious marketing crap (e.g.
implementing only 1 easy H.263+ optional mode to claim H.263+ functionality).

Regards,
Guilhem.



                
__________________________________ 
Do you Yahoo!? 
Yahoo! Mail - Find what you need with new enhanced search.
http://info.mail.yahoo.com/mail_250
------------------------------------------------------------------------
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
------------------------------------------------------------------------