RE: H.261 video problems - fixed

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