[sip-comm-dev] Skype and its screen sharing + update on bandwidth/artefacts problems


#1

Hi all,

Yesterday evening I tested screen sharing feature of Skype in LAN and through VPN.

Basically it has good quality in LAN/VPN. In LAN bandwidth can be high (> 100 kB/s) depending of what we do (scrolling on full screen PDF text for example).

Through VPN, bandwidth was very low (seems to be limited to 45/50 kB/s), quality was still good but delay happen on receiver. If I take my example of scrolling in PDF, it can be more than 4-5 seconds. I think they limit bandwidth like us (MaxPacketPerMillis).

For information CPU usage was high on my desktop computer (with big screen): arround 92% (I tested the latest Linux 2.1 beta version). By the way it seems that Skype streams resolutions as is (1920x1200 in my case) and receiver side can rescale (or the desktop is windowed with horizontal and vertical elevators).

So yesterday I made another test on SIP Communicator by reactivating MaxPacketPerMillis feature and in LAN/internet there are still visual artefacts... Today I find why. In DePacketizer we assume that a new NAL happens when timestamp of RTP packet change. But JMF change this RTP timestamp before present it to our DePacketizer. So it think that NAL is not finished (no end bit) as it receive another packet with different timestamp (but in Wireshark RTP timestamps are the same).

A possible fix is to truly set packet's timestamp in JMF's Buffer.

To summarize Skype limit bandwidth "manually" (not by codec/compression, ...) like us and JMF does not set RTP timestamp in buffer so we can have problem with our H264 DePacketizer and cause visual artefacts if we enable bandwidth limit.

What do you think ?

···

--
Seb

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@sip-communicator.dev.java.net
For additional commands, e-mail: dev-help@sip-communicator.dev.java.net


#2

After an offline talk with Lubomir, I test another thing, if we ignore timestamp check in DePacketizer (which should reset the buffer, i.e. setLength(0) and set fuaStartedButNotEnded to false), it works like a charm without any visual artefacts.

Even when there is a new NAL unit (which should pass this timestamp check and reset), the reset is useless since fuaStartedButNotEnded is already set to false (if no packets loss, the last packet contains end bit which set the flag) and setLength is also useless since the next packet (first packet of a NAL which contains start bit) will initialize its value. And if packet loss occured, DePacketizer automatically reset Buffer.

Comments ?

Regards,

···

--
Seb

Le 27/05/2010 10:14, Sebastien Vincent a �crit :

Hi all,

Yesterday evening I tested screen sharing feature of Skype in LAN and through VPN.

Basically it has good quality in LAN/VPN. In LAN bandwidth can be high (> 100 kB/s) depending of what we do (scrolling on full screen PDF text for example).

Through VPN, bandwidth was very low (seems to be limited to 45/50 kB/s), quality was still good but delay happen on receiver. If I take my example of scrolling in PDF, it can be more than 4-5 seconds. I think they limit bandwidth like us (MaxPacketPerMillis).

For information CPU usage was high on my desktop computer (with big screen): arround 92% (I tested the latest Linux 2.1 beta version). By the way it seems that Skype streams resolutions as is (1920x1200 in my case) and receiver side can rescale (or the desktop is windowed with horizontal and vertical elevators).

So yesterday I made another test on SIP Communicator by reactivating MaxPacketPerMillis feature and in LAN/internet there are still visual artefacts... Today I find why. In DePacketizer we assume that a new NAL happens when timestamp of RTP packet change. But JMF change this RTP timestamp before present it to our DePacketizer. So it think that NAL is not finished (no end bit) as it receive another packet with different timestamp (but in Wireshark RTP timestamps are the same).

A possible fix is to truly set packet's timestamp in JMF's Buffer.

To summarize Skype limit bandwidth "manually" (not by codec/compression, ...) like us and JMF does not set RTP timestamp in buffer so we can have problem with our H264 DePacketizer and cause visual artefacts if we enable bandwidth limit.

What do you think ?

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@sip-communicator.dev.java.net
For additional commands, e-mail: dev-help@sip-communicator.dev.java.net