Hi All,
May it have been that the determination code in h.261codec.cxx had the
values for I-bit and V-bit switched?
Original:
if ((*header & 2) && !(*header & 1))
-> shouldn't it be like:
if((*header & 1) && !(header & 2))
since the I-bit precedes the V-bit. Otherwise, the old code checked for
a 0 I-bit and a 1 V-bit and then chose the IntraP64Decoder, which
obviously produced garbage
Hannes
Am 24. Feb 2005 um 19:15 schrieb Mark Blake:
Hi,
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).
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 ;)
Regards,
Mark
-----Original Message-----
From: Hannes Friederich [mailto:hannesf@xxxxxxxxxx]
Sent: 24 February 2005 17:57
To: Guilhem Tardy
Cc: Damien Sandras; Mark Blake; openh323@xxxxxxxxxxxx
Subject: Re: H.261 video problems - fixed
Guilhem,
Am 24. Feb 2005 um 18:31 schrieb Guilhem Tardy:
Hi Hannes,
I believe this is the sign of a buggy / non standard compliant
3rd-party
endpoint (see extract from RFC2032 below). What maker / model? Any
trace file
to confirm?
The 3rd-party endpoints where I observed this problems were all MCU's,
Radvision ViaIP 400 MCU-60 3... and
Codian MCU 4210
so I believe they are not just "any" 3rd-party endpoints...
I've also cc: ed this mail to Mark Blake from Codian. I guess you can
discuss the technical details from expert to expert...
I have currently no trace file, but I can do some ethereal-diagnosis
if
you wish. However, I still think that I lack the required technical
knowledge, although my learning-curve is steep at the moment...
If this was your first find, congratulations!
Well, the patch itself was not a big deal. It took a considerable
amount of time until I looked at the correct portion of the code,
though. (including some early attempts to utilise the ffmpeg codec,
but
this hasn't got far)
Indeed, it would make nearly no difference in terms of performance
(decoding is
much easier than encoding, no motion estimation).
Damien, please apply.
Guilhem.
---
INTRA-frame encoded data (I): 1 bit
Set to 1 if this stream contains only INTRA-frame coded
blocks. Set to 0 if this stream may or may not contain
INTRA-frame coded blocks. The sense of this bit may not
change during the course of the RTP session.
__________________________________
Do you Yahoo!?
Yahoo! Mail - Easier than ever with enhanced search. Learn more.
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
------------------------------------------------------------------------
