Re: [Ekiga-list] Building OPAL with H.263
- From: Eugen Dedu <Eugen Dedu pu-pm univ-fcomte fr>
- To: Ekiga mailing list <ekiga-list gnome org>
- Subject: Re: [Ekiga-list] Building OPAL with H.263
- Date: Fri, 23 Sep 2011 14:56:00 +0200
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
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
I'll try to make time to do some more debugging next week.
We will release ekiga on Monday!
] [Thread Prev