[jitsi-users] audio/video desync


#1

Hi,

I've tried a couple of video calls over XMPP between a WinXP and a Linux
box using Jitsi. The audio part is working fine, but incoming video at
the Linux box is severely lagged behind the audio with a delay of up to
one minute. The incoming video at the WinXP box is fine as well. I've
tried experimenting with various bandwidth allocations but to no avail.

Any ideas what could be the cause of this?

With regards,
Michal Svoboda


#2

I've tried a couple of video calls over XMPP between a WinXP and a Linux
box using Jitsi. The audio part is working fine, but incoming video at
the Linux box is severely lagged behind the audio with a delay of up to
one minute.

Since Jitsi does not explicitly synchronize the audio and the video,
it is indeed possible to have the video lag behind the audio.

The incoming video at the WinXP box is fine as well. I've
tried experimenting with various bandwidth allocations but to no avail.

Any ideas what could be the cause of this?

One thing you could try is to have video streaming from the Windows XP
machine to the Linux machine but not in the reverse direction in order
to relieve the load on the network and the Linux machine.

···

On Tue, Jul 5, 2011 at 11:20 PM, Michal Svoboda <pht@spatium.org> wrote:


#3

Adding to what Lyubomir said, forcing down the bandwidth is only likely
to increase your sync issues since it does not really reduce the
bandwidth. It simply buffers packets locally before sending them.

The best way of reducing CPU use and bandwidth is to move to a lower
resolution or framerate.

Hope this helps,
Emil

На 06.07.11 09:12, Lyubomir Marinov написа:

···

On Tue, Jul 5, 2011 at 11:20 PM, Michal Svoboda <pht@spatium.org> wrote:

I've tried a couple of video calls over XMPP between a WinXP and a Linux
box using Jitsi. The audio part is working fine, but incoming video at
the Linux box is severely lagged behind the audio with a delay of up to
one minute.

Since Jitsi does not explicitly synchronize the audio and the video,
it is indeed possible to have the video lag behind the audio.

The incoming video at the WinXP box is fine as well. I've
tried experimenting with various bandwidth allocations but to no avail.

Any ideas what could be the cause of this?

One thing you could try is to have video streaming from the Windows XP
machine to the Linux machine but not in the reverse direction in order
to relieve the load on the network and the Linux machine.

--
Emil Ivov, Ph.D. 67000 Strasbourg,
Project Lead France
Jitsi
emcho@jitsi.org PHONE: +33.1.77.62.43.30
http://jitsi.org FAX: +33.1.77.62.47.31


#4

Emil Ivov wrote:

Adding to what Lyubomir said, forcing down the bandwidth is only likely
to increase your sync issues since it does not really reduce the
bandwidth. It simply buffers packets locally before sending them.

The best way of reducing CPU use and bandwidth is to move to a lower
resolution or framerate.

Hi,

CPU use seems to be okay on both ends (with the Linux box being
significantly better off). Bandwidth is limited to 40K on the Linux side
and to 15K on the Win side, resolution being 320x200 on both ends and
frame rate unset. Can that be the issue? I thought the bandwidth limiter
would force down video quality and/or framerate to match the limit.
I see no adjustment knobs for the video quality, can that be altered?

Michal Svoboda


#5

На 06.07.11 18:51, Michal Svoboda написа:

Emil Ivov wrote:

Adding to what Lyubomir said, forcing down the bandwidth is only likely
to increase your sync issues since it does not really reduce the
bandwidth. It simply buffers packets locally before sending them.

The best way of reducing CPU use and bandwidth is to move to a lower
resolution or framerate.

Hi,

CPU use seems to be okay on both ends (with the Linux box being
significantly better off). Bandwidth is limited to 40K on the Linux side
and to 15K on the Win side,

You should bring both of those back to 100K. Again, the bandwidth param
does not cause less traffic to be generated. It simply delays traffic
that goes above the bandwidth cap and causes desync. The more you lower
the values in there, the more you would be causing desync.

resolution being 320x200 on both ends and

That sounds ok.

frame rate unset. Can that be the issue?

No, I don't think so. You most probably experience desync because the
bandwidth caps you have set are too low.

I thought the bandwidth limiter
would force down video quality and/or framerate to match the limit.

No. It only affects bandwidth. Nothing else.

I see no adjustment knobs for the video quality, can that be altered?

Only by lowering resolution and fps.

Cheers,
Emil


#6

Emil Ivov wrote:

You should bring both of those back to 100K. Again, the bandwidth param
does not cause less traffic to be generated. It simply delays traffic
that goes above the bandwidth cap and causes desync. The more you lower
the values in there, the more you would be causing desync.

Thanks, I'll try that.

So when the line simple can't send that much bps then the packets will
be lost and I should see smears on the video, is that correct?

> I thought the bandwidth limiter
> would force down video quality and/or framerate to match the limit.

No. It only affects bandwidth. Nothing else.

I see. That's a little counter-intuitive for me. Is there any practical
reason why it works this way? If the deal is that it needs to be at
least 100K then it seems to be of very little use :wink:

> I see no adjustment knobs for the video quality, can that be altered?

Only by lowering resolution and fps.

Just out of curiosity: almost all video encoding applications derive the
video quality from a bps/average bps parameter. So how does Jitsi
determine the parameters for the encoder if not via bps?

Michal Svoboda


#7

На 06.07.11 19:08, Michal Svoboda написа:

Emil Ivov wrote:

You should bring both of those back to 100K. Again, the bandwidth param
does not cause less traffic to be generated. It simply delays traffic
that goes above the bandwidth cap and causes desync. The more you lower
the values in there, the more you would be causing desync.

Thanks, I'll try that.

So when the line simple can't send that much bps then the packets will
be lost and I should see smears on the video, is that correct?

We'll first buffer them for a while and start discarding them when that
buffer reaches a limit.

I thought the bandwidth limiter
would force down video quality and/or framerate to match the limit.

No. It only affects bandwidth. Nothing else.

I see. That's a little counter-intuitive for me.

It is indeed. Couldn't find a better name though.

Is there any practical
reason why it works this way? If the deal is that it needs to be at
least 100K then it seems to be of very little use :wink:

The bandwidth cap is meant as a solution to handling data bursts that
happen with key frames for example. If your home upstream bandwidth
allows for outgoing video to flow out undisturbed most of the time, you
are still likely to reach its limits when sending key frames (all the
more so with desktop sharing). In such cases a temporary desync is
better than artefacts and smearing.

The point of having a field that allows you to change the cap, is only
so that you could bring it up in case you'd like to have HD calls for
example.

I see no adjustment knobs for the video quality, can that be altered?

Only by lowering resolution and fps.

Just out of curiosity: almost all video encoding applications derive the
video quality from a bps/average bps parameter. So how does Jitsi
determine the parameters for the encoder if not via bps?

Limiting frame rate and resolution has little to do with the encoder.
They simply regulate the size and the number of frames per second that
we are passing to it. The parameters would hence work regardless of what
codec is being used.

Cheers,
Emil