Re: [Ekiga-list] Building OPAL with H.263

[Eugen Dedu <Eugen Dedu pu-pm univ-fcomte fr>]

On 23/09/11 13:23, Steve Hill wrote:
> On 09/22/2011 11:54 AM, Eugen Dedu wrote:
>
> > > Thanks. Does that mean that for Ekiga 3.3.2 you can just install ffmpeg
> > > > 0.6.2 (rpmfusion packages 0.7-0.3.20110612git, so presumably that is
> > > ok) and Ekiga will just use it directly without needing Opal to provide
> > > H.263+ support?
> >
> > ekiga 3.3.2 depends on opal 3.10.2 anyway, which works with those codecs.
>
> I'm having some significant problems with Ekiga 3.3.2 on Opal 3.10.2.

Thank you very much for sharing them with us.

> 1. Opal wouldn't build against ffmpeg-0.7-0.3.20110612git. This appeared
> to be a problem with a line in mpeg4.cxx:
> m_avpicture->pict_type = 0;
> After some googling, the suggested fix appeared to be to add a cast:
> m_avpicture->pict_type = (AVPictureType) 0;
> Once I'd done that it built ok.

This is fixed in the branch, since I currently have:
            m_avpicture->pict_type = AV_PICTURE_TYPE_NONE;

> 2. Ekiga 3.3.2 doesn't seem to want to register against my Callweaver
> server (Ekiga 3.3.0 works fine). I can't really tell if this is Ekiga at
> fault or Callweaver. I've compared the network traffic between the two
> Ekigas, and the only thing I can really note is that Ekiga 3.3.0 sends a
> REGISTER and waits for that to succeed (including extra round-trips for
> authentication) before doing anything else. Ekiga 3.3.2 sends REGISTER,
> SUBSCRIBE and PUBLISH packets all at the same time. REGISTER and
> SUBSCRIBE both have the same sequence number (CSeq=1) - is this allowed?
> Callweaver appears to respond to 3.3.2's SUBSCRIBE with "489 Bad Event",
> which it didn't do under 3.3.0.
>
> In any case, there's something completely crazy going on at the
> Callweaver end because it _does_ return a "200 OK" in response to the
> register, but doesn't actually record the registration in its peers
> list. I'm guessing it is getting confused by the SUBSCRIBE packet.

Could you send us the two logs to analyse them?

> 3. The H.264 codec appears to completely ignore the bandwidth limit set
> in Ekiga's configuration. The limit is set to 300Kbps and (according to
> the stats in Ekiga's status bar) it was trying to send about 7Mbps
> (750KB/s). The video I got back from an echo test was completely
> trashed, but that is quite possibly due to it massively exceeding my
> ADSL upstream bandwidth and hence dropping most of the traffic.

This is strange...  We will get some info in the log below.

> 4. H.263 and H.263-1998 both resulted in me just getting a static image
> when I dialled an echo test. When I terminated the call, Ekiga bombed
> with a segfault.

Please send us a gdb with -d 4 report, see 
http://wiki.ekiga.org/index.php/Debugging_Ekiga#Getting_the_stack_backtrace.

> I'll try to make time to do some more debugging next week.

We will release ekiga on Monday!

--
Eugen