Fwd: H.261 codec improvements

I'll just forward the reply from Guilhem Tardy to the mailing list...

Anfang der weitergeleiteten E-Mail:

> Von: Guilhem Tardy <gravsten@xxxxxxxxx>
> Datum: 22. Februar 2005 02:58:52 GMT+01:00
> An: hannesf@xxxxxxxxxx
> Cc: hannesf@xxxxxxxxxx
> Betreff: Re: [OpenH323]H.261 codec improvements
>
> Hannes,
>
> > The current h.261 codec used in openh323/OPAL (vic) is from the
> > early-90's and has some problems dealing with advanced h.261 streams 
> > (often coming from MCU's). This is probably due to the fact that the 
> > vic-codec has problems with frames containing non-I-macroblocks (Poor 
> > quality when there is much movement in the frame)
>
> It would be good to see in the code what the problem is.
>
> Another possibility is that your MCU is not completely standard compliant (a
> rather common item with solutions from Polycom, Tandberg and the likes as my
> work with H.263 codecs has shown).
>
> > I recently visited the ffmpeg project page and noticed that the have
> > added some h.261 support (dec 10, 2004)
> > Since the openh323 libraries already utilise libavcodec.so to make
> > use of H.263, I just wonder whether using the ffmpeg h.261 codec
> > would be an improvement. Does anybody know more about that?
>
> Could you try the ffmpeg codec on a file, and tell us of the quality? (A very
> subjective thing, I know.)
>
> It would be fairly easy to integrate, given the current support for ffmpeg in
> OpenH323. Take the H.261 capability and graph it over. Depending on your
> timing, I could even help you with it.
>
> Unless there is a strong quality argument for it, I would advise against it on
> the grounds that H.261 is a REQUIRED item of H.323 (without it, you are not
> compliant) and thus relying on an external library for it is quite unappealing.
> What if your DLL got misplaced?
>
> But it may be an option at compile time anyway.
>
> Guilhem.
>
>
>
>
> __________________________________ 
> Do you Yahoo!? 
> Meet the all-new My Yahoo! - Try it today! 
> http://my.yahoo.com