Date: Sat, 29 Mar 2008 11:49:57 +0100 From: Luigi Rizzo <rizzo@iet.unipi.it> To: Matthias Apitz <matthias.apitz@oclc.org> Cc: freebsd-multimedia@freebsd.org Subject: Re: compiling H.323 client Ekiga from its SVN repository Message-ID: <20080329104957.GA53187@onelab2.iet.unipi.it> In-Reply-To: <20080329071341.GA17726@rebelion.Sisis.de> References: <20080328152226.GA43549@rebelion.Sisis.de> <20080328160126.GA45021@onelab2.iet.unipi.it> <20080329071341.GA17726@rebelion.Sisis.de>
next in thread | previous in thread | raw e-mail | index | archive | help
On Sat, Mar 29, 2008 at 08:13:41AM +0100, Matthias Apitz wrote: > El d?a Friday, March 28, 2008 a las 05:01:26PM +0100, Luigi Rizzo escribi?: ... > As I said, what I urgently need is a H.323 client (of course on FreeBSD) > which: > - supports H.264 codec > - works with 'pwc' or any other webcam interface in FreeBSD > - and is compatible with our Polycom VSX7000 video conference system; cannot tell about the H323 part (but on your page you say that ekiga does not support h264 on h323 yet), nor the polycom compatibility. > how could I fetch asterisk (trunk version, 'chan_oss' driver)? svn co http://svn.digium.com/svn/asterisk/trunk you need to have SDL, SDL_Image, v4lcompat, ffmpeg installed, then configure should detect and build the VIDEO_CONSOLE support. maybe the version in ports/asterisk also has the VIDEO_CONSOLE code (the one that supports video calls), i have not checked it in a while. i don't know how well the h323 part works or is easy to build, because i believe it relies on the same third party code (ptlib, oh323 etc.) that ekiga uses, which is a pain to compile in general, my concern with all those linphone/ekiga/etc apps is that they use a large set of external toolkits, which more often than not are full of assumptions on the platform they have been developed for, and have zero error checking. On FreeBSD usually the assumption don't hold, and the code crashes or misbehaves badly. I have tracked some easy bugs such as null pointer dereferences, but others (such as passing bogus pointers or uninitialized data structs to the codec, or deadlocks, etc.) are non-trivial to find even in self-contained C code, so you can imagine how hard it becomes in heavily Obfusc^H^H^H^Hject Oriented code. cheers luigi
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20080329104957.GA53187>