Print

Please login or register.
1 Hour 1 Day 1 Week 1 Month Forever
Login with username, password and session length

[bluephoenix]

Hi, I am curios if anyone can help me with this.
I looked through google but that didn't help me much.

Basically I am skyping with a friend, his camera is crystal clear and then always a few seconds into the convo, his cam freezes.
It stays frozen for 2 seconds and then once it is working again the quality is absolutely terrible and nothing fixes it.
Drivers and software are fine and the camera itself is okay if a bit old.

[Ameablable]

My guess would be a slow internet connection.

Also, i think "Life Advice" would suit this better!

[Aptus]

This does sound at first glance like a basic network congestion problem. Basically some packet switch along the way is getting overwhelmed and starts dropping segments. I don't know if skype runs on TCP or UDP (but I assume UDP since skype is an asshole) but if it is running TCP and you know how to use Wireshark or a similar software you can try to confirm if its congestion by looking for duplicate ACK's.

[alway]

This does sound at first glance like a basic network congestion problem. Basically some packet switch along the way is getting overwhelmed and starts dropping segments. I don't know if skype runs on TCP or UDP (but I assume UDP since skype is an asshole) but if it is running TCP and you know how to use Wireshark or a similar software you can try to confirm if its congestion by looking for duplicate ACK's.

It's UDP. It should always be UDP for any real-time video transmission. TCP is terrible for that sort of thing, as it waits for confirmation before continuing; when streaming video or other media this is very bad behavior. You don't want a dropped packet to spend time being sent 100% of the time; you simply send the next one along. In the time it takes the network to confirm that a packet has been lost, a new piece of data will be ready which renders the dropped packet obsolete. Any time-critical application in which new data replaces old data in a very short period of time should be UDP, not TCP.

[Aptus]

This does sound at first glance like a basic network congestion problem. Basically some packet switch along the way is getting overwhelmed and starts dropping segments. I don't know if skype runs on TCP or UDP (but I assume UDP since skype is an asshole) but if it is running TCP and you know how to use Wireshark or a similar software you can try to confirm if its congestion by looking for duplicate ACK's.

It's UDP. It should always be UDP for any real-time video transmission. TCP is terrible for that sort of thing, as it waits for confirmation before continuing; when streaming video or other media this is very bad behavior. You don't want a dropped packet to spend time being sent 100% of the time; you simply send the next one along. In the time it takes the network to confirm that a packet has been lost, a new piece of data will be ready which renders the dropped packet obsolete. Any time-critical application in which new data replaces old data in a very short period of time should be UDP, not TCP.

Yes UDP is preferable but no it is not always UDP. Many routers block UDP traffic so most major real time transmission applications have to run both. First they try UDP and if that does not work they switch to TCP and try to compensate for it on the app layer. I do not know exactly how skype does it since it is a proprietary protocol.