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 ?