compiling H.323 client Ekiga from its SVN repository
guru at Sisis.de
Sat Mar 29 10:02:36 PDT 2008
El día Saturday, March 29, 2008 a las 11:49:57AM +0100, Luigi Rizzo escribió:
> 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.
yes, this (lack of h264) turned out later :-(
> > 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
thanks for the pointer to SVN; I've pulled it out and run ./configure
and there are dependencies of the (older) PWLib and the (dead) openh323
code; as well there is a port /usr/ports/net/asterisk
which trys to install asterisk-22.214.171.124 (don't know how far this is from
SVN trunk; will give it a try if it brings an H.323 client (what would
be its name in all that pile of pieces?)
> 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.
yes this is what I have found out as well when I ported Ekiga, OPAL and
PTLib to FreeBSD; not even the detection of audio and video devices was correct
in PTLib (it was hardcoded searching for the Linux major/minor) numbers,
for example; that's why I did the port, described all in detail and will
continue debugging until getting a working version;
> 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.
Manager Technical Support - OCLC GmbH
Gruenwalder Weg 28g - 82041 Oberhaching - Germany
t +49-89-61308 351 - f +49-89-61308 399 - m +49-170-4527211
e <matthias.apitz at oclc.org> - w http://www.oclc.org/ http://www.UnixArea.de/
Don't top-post, read RFC1855 http://www.faqs.org/rfcs/rfc1855.html
A: Because it messes up the order in which people normally read text.
Q: Why is it such a bad thing?
Q: What is the most annoying thing on Usenet and in e-mail?
More information about the freebsd-multimedia