Bug 135929

Summary:	Kopete/MSN 7.5 - Slow bandwidth or bug leads to huge delay/lag in MSN webcam picture - No resynchronisation is ever attempted
Product:	[Unmaintained] kopete	Reporter:	John Doe <DetunizedGravity>
Component:	WLM Plugin	Assignee:	Kopete Developers <kopete-bugs-null>
Status:	RESOLVED UNMAINTAINED
Severity:	wishlist	CC:	kde
Priority:	NOR
Version:	unspecified
Target Milestone:	---
Platform:	Ubuntu
OS:	Linux
Latest Commit:		Version Fixed In:
Sentry Crash Report:

Description John Doe 2006-10-18 21:35:38 UTC

Version: 0.12.2 (compiled from sources, unlike the rest of KDE) (using KDE KDE 3.5.3)
Installed from: Ubuntu Packages
Compiler: gcc 4.1.1
OS: Linux

I am not sure wether this is really a bug or not, and it is more a "it doesn't work well" than a "it doesn't work" issue, so I'm filing this under "wishlist". Anyway, here goes...

I often chat with a far away friend, with MSN 7.5 and a slooow DSL connection, while I have a 5Mbits/1Mbits one. We use our webcams (which is the reason I compiled kopete 0.12.2 from sources, as previous versions would not allow both webcams to be open at the same time).

When receiving her cam, quickly the picture starts lagging. As I am typing this, I see what she has done in front of her cam HALF AN HOUR ago. We just timed it. We have been using the cams without interruption for a little more than an hour. Even though it's still nice to see her beautiful face on my screen, it does not help being unable to correlate what she writes to me with her facial expression, which is the very goal of a webcam after all.

*** Hypothesis #1 ***

Her bandwidth is not high enough to send the frames at the required rate, even though the negotiated picture quality is way lower than the one I send. Nothing seems to be implemented to keep the two computers in sync. Or if it had, then this feature doesn't work. I would expect the protocol to provide some way of telling "ok, there is too much lag between the two clients, let's drop the whole "unsent frames" queue and start anew".

I know that in my case it would be the job of the MSN client to drop the queue, not of Kopete. And I know that you can't change the design of the MSN protocol if does not propose such a mechanism. But, well, the issue might be kopete's fault, for not complaining about the lag for example. I don't know how it does work under the hood...

*** Hypothesis #2 ***

The displayed framerate on the kopete side is much slower than it should, and the data is buffered on my side. Big bug. Needs fixin'. Now. ^_^

Anyway, I just wanted to make you aware of the whole issue, even if it is not a critical one. It does not seem to be a known one if I believe the result of my searches on this bug tracking system. You may not be able to do anything about it but well...

Best regards,
Xavier

Comment 1 John Doe 2006-12-19 21:02:38 UTC

I have experimented with other Linux distros since I filled this report, only to come back to Debian...

We discovered that the behaviour described here had apparently been fixed: the framerate would occasionally accelerate to prevent lag. The bad news is that, surprisingly, establishing full duplex video became difficult, and then impossible. We did not try for a long time, and KDE went from 3.5.4 to 3.5.5 since, so maybe it works now. Dunno... We shall try soon.

Comment 2 Lionel Besson 2007-03-07 16:55:50 UTC

I can confirm this behavior on Kubuntu edgy with Kopete 0.12.4. But this only happens for the cam images that i send

Comment 3 alancio 2008-07-31 06:29:24 UTC

This bug is still present in KDE 3.5.9

Comment 4 Nicolas L. 2008-11-24 21:27:06 UTC

moving this wish to the WLM plugin

Comment 5 Andrew Crouthamel 2018-11-08 14:10:31 UTC

Hi there, sorry for the bad news, but WLM has been discontinued by Microsoft, so this bug will be closed.

Thank you for helping us make KDE software even better for everyone!