[jitsi-dev] XMPP Video/Audio Issues from Linux to MacOSX


#1

My system: Openfire XMPP-Server, Ubuntu 10.04 64bit, Intel i5 CPU, 4GB
Ram, Sun Java package

···

---

Hi list,

i got another problem with calling from ubuntu based jitsi-client
(latest build 3351) to MacOSX based jitsi-client (latest build 3350).

1. Ubuntu -> MacOSX:
No audio or video call possible. The MacOSX client accepts the call, but
it keeps ringing (unfortunately no obvious logging entries).

2. MacOSX -> Ubuntu:
Audio and video call are possible, but the video has a delay of about
2-3 seconds and the audio has a delay of about 1-2 seconds. This problem
does not occur with a windows jitsi client.

As soon as i change the codecs to H263-1998 the delay gets better, but
the video itself has a bad quality. Again a wider range of codecs would
be nice :slight_smile:

3. Bad error message with incompatible video codecs
Ubuntu codec settings: H264 only
MacOSX codec settings: H263-1998 only

Error while trying to call: "Call ended by remote side. Reason:
incompatible-parameters. Error: null"

The message should at least contain something like "no supported video
codec"

Thx
Ben


#2

Hi Ben,

1. Ubuntu -> MacOSX:
No audio or video call possible. The MacOSX client accepts the call, but
it keeps ringing (unfortunately no obvious logging entries).

If the *.log.* and *.pcap files in the ~/Library/Application
Support/SIP Communicator/log don't show the cause, could you please
create a full Wireshark dump of the whole session and a heap dump and
a thread dump when SIP Communicator/Jitsi keeps on ringing?

2. MacOSX -> Ubuntu:
Audio and video call are possible, but the video has a delay of about
2-3 seconds and the audio has a delay of about 1-2 seconds.

Too big a delay on the side of Mac OS X is not what I've experienced.
Is it possible that the delay occurs while or after it is received on
the side of Ubuntu?

This problem
does not occur with a windows jitsi client.

Is the Windows side the sender or the receiver?

As soon as i change the codecs to H263-1998 the delay gets better, but
the video itself has a bad quality.

The H.264 implementation in use should generally be more CPU intensive
than the H.263 one so no surprises the delay gets better after the
switch. And, of course, one cannot practically get any better than
H.264 so there are again no surprises that the video quality gets
worse after the switch.

Again a wider range of codecs would
be nice :slight_smile:

Could you please list the codecs that you consider better in terms of
quality and performance than the current H.263 implementation? Is
their encoding and decoding supported by FFmpeg? If not, do they have
open-source implementations that we can use? Of course, contributing
their integration in SIP Communicator/Jitsi will speed up their
adoption in comparison to submitting a feature request

3. Bad error message with incompatible video codecs
Ubuntu codec settings: H264 only
MacOSX codec settings: H263-1998 only

Error while trying to call: "Call ended by remote side. Reason:
incompatible-parameters. Error: null"

The message should at least contain something like "no supported video
codec"

I guess an enhancement request may be submitted in our issue tracker.
Please be sure to attach patches that implement the requested
enhancement in order to make sure that your request is handled sooner
rather than later.

Thank you,
Lyubomir

···

On Tue, Mar 15, 2011 at 2:01 PM, Ben <taris@gamersplace.de> wrote:


#3

Hi Lyubomir,

i had not much time to investigate any further, but i was able to try a Jitsi-Call with a second MacOSX client (to make sure it isn't system dependent).
Same problem with calling from Ubuntu to OSX - i try to make a wireshark recording the next days.

The call from OSX to Ubuntu works (both with the latest build - 3357), but is quite laggy as well.
After about 1-2 minutes of the call the OSX-Jitsi client was eating more and more memory and CPU (i5) and ended with roughly 1.2 GB of memory and 130% CPU usage ..after that point the system simply crashed/freezed.
The Macbook got a i5 CPU and 8GB Ram - the XMPP server and both clients are in the same local company network.

Since the first OSX client was lagging pretty bad as well, i guess the calls weren't long enough to crash the system there.
I will stick to it and send more.

Thanks
Ben

···

Hi Ben,

On Tue, Mar 15, 2011 at 2:01 PM, Ben<taris@gamersplace.de> wrote:

1. Ubuntu -> MacOSX:
No audio or video call possible. The MacOSX client accepts the call, but
it keeps ringing (unfortunately no obvious logging entries).

If the *.log.* and *.pcap files in the ~/Library/Application
Support/SIP Communicator/log don't show the cause, could you please
create a full Wireshark dump of the whole session and a heap dump and
a thread dump when SIP Communicator/Jitsi keeps on ringing?

2. MacOSX -> Ubuntu:
Audio and video call are possible, but the video has a delay of about
2-3 seconds and the audio has a delay of about 1-2 seconds.

Too big a delay on the side of Mac OS X is not what I've experienced.
Is it possible that the delay occurs while or after it is received on
the side of Ubuntu?

This problem
does not occur with a windows jitsi client.

Is the Windows side the sender or the receiver?

As soon as i change the codecs to H263-1998 the delay gets better, but
the video itself has a bad quality.

The H.264 implementation in use should generally be more CPU intensive
than the H.263 one so no surprises the delay gets better after the
switch. And, of course, one cannot practically get any better than
H.264 so there are again no surprises that the video quality gets
worse after the switch.

Again a wider range of codecs would
be nice :slight_smile:

Could you please list the codecs that you consider better in terms of
quality and performance than the current H.263 implementation? Is
their encoding and decoding supported by FFmpeg? If not, do they have
open-source implementations that we can use? Of course, contributing
their integration in SIP Communicator/Jitsi will speed up their
adoption in comparison to submitting a feature request

3. Bad error message with incompatible video codecs
Ubuntu codec settings: H264 only
MacOSX codec settings: H263-1998 only

Error while trying to call: "Call ended by remote side. Reason:
incompatible-parameters. Error: null"

The message should at least contain something like "no supported video
codec"

I guess an enhancement request may be submitted in our issue tracker.
Please be sure to attach patches that implement the requested
enhancement in order to make sure that your request is handled sooner
rather than later.

Thank you,
Lyubomir


#4

Running out of memory does not sound good so, after you send us the
Wireshark dump and we examine it, I may ask you to create a heap dump
as well because it may give us more hints. Anyway, thank you very much
for your support!

···

On Thu, Mar 17, 2011 at 8:59 PM, Ben <taris@gamersplace.de> wrote:

The call from OSX to Ubuntu works (both with the latest build - 3357), but
is quite laggy as well.
After about 1-2 minutes of the call the OSX-Jitsi client was eating more and
more memory and CPU (i5) and ended with roughly 1.2 GB of memory and 130%
CPU usage ..after that point the system simply crashed/freezed.
The Macbook got a i5 CPU and 8GB Ram - the XMPP server and both clients are
in the same local company network.