RE: H.261 video problems - fixed

Hi Guilhem,

> because using the RTP bits properly is essential for better coping
with
> error / packet loss on the Internet.

I completely agree that these bits should be set correctly - if there is
a standard in place then it should be followed.

However I wouldn't agree that these bits help much for error resilience
- with modern video endpoints at least. Any "good" encoder should
generate packets where the media payload starts with a GOB/Slice header
anyway and in this case the extra information in the rtp header is
mostly redundant or easily guessable (in any case a complete gob or
slice is almost always independently decodable). 

The most important way (IMHO) to cope with packet loss on the internet
is for the decoder / receiver to implement an algorithm that uses flow
control messages to dynamically lower the bit rate that the far end
(encoder) is transmitting at in response to packet loss / network
congestion. This makes a HUGE difference in real world performance.

The Tandbergs & Polycoms (and Codians!) of this world all do both of the
above. 

> That on top of obvious marketing crap (e.g.
> implementing only 1 easy H.263+ optional mode to claim H.263+
> functionality).

Well... the truth is that it's generally agreed that most of the (very
many) H.263+ annexes are overcomplicated and, on the whole, pretty
useless. The only ones that have a good cost/benefit tradeoff are I & T
(and T mainly because it works around a design flaw in baseline H.263
that VLE escape codes are not capable of encoding all levels). The other
main annexes that are for "compression efficiency" e.g. F & J, only get
you a few percent bitrate reduction for a lot of work. A good
post-processing filter (e.g. applying the mpeg-4 deblocking / deringing
filter to the H.263 decoder output) can provide the same improvement in
quality but is much easier to implement and because it's just
post-processing it has no interoperability issues. 

Another point is that for compression efficiency I don't think the
H.263+ annexes are relevant any more - since all the major vendors have
moved to H.264 which is much better and much cleaner to implement.

The bits of H.263+ that are really useful are the parts that introduce
new features : e.g. the custom picture formats (which everyone supports)
- for instance encoding at the native resolution of the camera (perhaps
352x240) rather than scaling / clipping and encoding at CIF is a big
win. Also the use of H.263+ (and ++) annexes N+W or U+W to implement 60
fields per second interlaced CIF (all the main vendors support this).

Just my 2 cents!

Best regards,
Mark



> -----Original Message-----
> From: Guilhem Tardy [mailto:gravsten@xxxxxxxxx]
> Sent: 25 February 2005 01:02
> To: Mark Blake; 'Hannes Friederich'
> Cc: 'Damien Sandras'; openh323@xxxxxxxxxxxx
> Subject: 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
------------------------------------------------------------------------