Screen sharing with Adobe AIR not functioning

[David_Welch]

I have an Adobe AIR app that is using screen sharing, but, the broadcast (or reception by the subscriber) rarely sends updates.

For example, when a session first starts, the subscriber will get the appropriate screen (most of the time), but, any updates to the screen are intermittent, at best.  My app's ui has an accordion on the left and html windows in tabs on the right.  The html windows are using standard Air htmlloader component.

The AIR app is using Flex 3.4, and uses the latest 2.5 Runtime available from get.adobe.com/air.

Some examples where the sceen update is not received by the subscriber:

- changing areas on the accordion

- opening new tabs

- changing any content in the htmlloader component

- if sharing entire desktop, and then bringing up another app on the screen never shows the new app to the subscriber

I can tell that the session is live, because all of the cursor movement (even the clicks) are broadcast appropriately, it just doesn't send the screen also!  Also, I've tried sharing window, application and desktop, but, it see the similar results with all.

I've also seen similar results with being a subscriber on a Mac running OSX.  I've also run the Air app on a PC running Windows Server 2003, the Air app invokes the Adobe ScreenSharing addin, but, does not prompt for desktop/window/app to share, so, it never publishes.  I have an AddInLauncherEvent error handler for AddInLauncherEvent.FAIL, but, it's never fired.  This same behavior I've seen on my Mac. 

For most of my testing the host of the screen sharing session is running Windows Vista 64 bit.  The addin was by manually downloading from Acrobat Exchange (http://www.adobe.com/cfusion/exchange/index.cfm?event=extensionDetail&loc=en_us&extid=1802025#) for the PC and from acrobat.com on the Mac.  (the dll's seem to be updated everytime the addin runs, not sure why)

Can someone tell me if these are known issues ?  This feature is basically unusable to me in its current state.

Thanks,

David

[aponnusa]

Hi David,

Thanks for reporting the issues to us. ScreenSharing has a few issues around Adding not being launched. But we have never heard of issues that you have faced.

Also about Screen not being updated, what are your screen sharing settings. Also you must understand that ScreenSharing is both process and bandwidth intensive. So these constraints might result in a poor ScreenSharing performance.

So can you please share your code or PM it to me. I can take a look and see if its reproducible.

Thanks

Arun

[David_Welch]

Arun:

Thanks for the response...I'm surprised you haven't seen this behavior, but, that gives me hope that maybe it's just my code.

But, I believe most of my code is taken from your example code, but, maybe you can see something.  There is too much code to send everything, but, I can send you the basics (via PM) that shows the approach.

Also, not sure what you mean by "...your screen sharing settings...", do you mean what parameters am I using on ScreenSharePublisher/ScreenShareSubscriber?  If so, you can see it in the code attached.

The screen share is subscribed and published thru a simple LCCSScreenShare.mxml component (attached).  This is contained as one section of a standard accordion component.

I have a main top level component (that contains the accordion and the TabNavigator) that listens for a custom event and runs this code:

var displayArea:HBox = new HBox();

displayArea.percentHeight=100;

displayArea.percentWidth=100;

var sss:ScreenShareSubscriberComplex= new ScreenShareSubscriberComplex();

sss.connectSession = cSession;

sss.percentHeight=100;

sss.percentWidth=100;

displayArea.addChild(sss);

nav.addTab(

"Screen Share", displayArea, true);

where addTab() adds a new tab to a SuperTabNavigatorComponent (simple wrapper of the SuperTabNavigator, also attached, using latest from FlexLib project) by calling addChild(Container):

public function addTab(lbl:String, panel:Container, closeable:Boolean, contentString:String=null, icon:Class=null):Number {

var curNum:Number = tabs.numChildren;

panel.setStyle(

"closable", closeable);var displayObj:DisplayObject = tabs.addChild(panel);

displayObj.name = lbl;

return curNum;

}

Regarding bandwidth, I'm on a high speed DSL (6gb) line, and there really isn't anything else going on these machines or on the internal network where these pc's are located while I'm doing this testing.  Also, the LCCS video and audio components that I have within the same app perform fairly well (and I'm not using them at the same while testing screen sharing).  I have migrated the code to Flex 4.1 (using Flex 3 compatibility), but, still see the same issues in the screen sharing.

If you need more info, please let me know.

Thanks,

David

[David_Welch]

Arun:

Did you try the code?  I sent you an email yesterday to redownload the zip...any luck?

thanks,

David

[aponnusa]

Hi David,

Thanks for sharing your code. Would update you soon.

Thanks

Arun

[David_Welch]

Arun:
I received you pm that you didn't see anything wrong with the code...this is what I expected, but, it just means we have to dig a little deeper.  I'm sure you are 1) on a pretty fast network, and, 2) probably have all the right versions of the screen sharing addins installed.

I'm guessing the issue has to be related to one of these two things.  Either that, or, maye no one is actually be using LCCS screen sharing because it's not working?  I see lots of posts where people are having various problems, but, they seem to work thru them.

So, three questions:

1) If it's a slow network connection (which it could be), then, it should still work, even though it's slow, right?

2) Also, can you tell me how to ensure I have the right addins for both Mac and Windows (64 bit) and Windows 32 bit?  (No Windows 7)

3) How do you "Uninstall" the screen sharing addin on both Win and Mac?

I'd really like to add this feature to our product, but, when you can't even give a demo of it's features, it's obviously not going to work for actual users.

Thanks for your help,

David

[aponnusa]

David,

As a last resort. can you confirm if you still see performance issues when you run this app - http://blogs.adobe.com/arunpon/files/2011/02/SimpleScreenShare1.swf  . You can post us the logs in the app, if you see anything weird. For your assurance, ScreenSharing is part of a popular product called ConnectNow, and been used by a lot of customers under different platforms & settings. So we do know for sure that ScreenSharing works.

Also I would recommend digging around our forums for optimizations that might suit you - http://forums.adobe.com/message/3486500#3486500

As for updated addins, our code ensures that you have the latest addin. We update it for you if you dont have the latest one. Unfortunately due to security constraints we dont distribute the addin binary independently. AIR apps have an issue with launching the addin. But using a htmlloader with in an AIR app is a workaround.

Addin is an independent application, So they could be uninstalled like any other standard application ( Add/Remove applications in Windows, and deleting the addin from the applications directory mac should be good enough)

Sincerely

Arun

[David_Welch]

I tried to run the app you sent (download, then ran swf by double clicking it), it just hangs in the preloader.  I have Flash player 10,2,152,32 installed on this machine.  Did you want me to embed this swf or some other method?

This statement in the post regarding optimizations you referred to surprises me:

"Essentially we are integrating this into an application that is meant to have only a 1 to 1 connection (for the moment). We have a master and Slave interface, the Master is always in control and can only screen share with one and one user only. We are trying to figure out a way to have multiple publishers within one room and know who are their respective partners to connect to."

And this is from 8.3 of your developes guide:

"Upon accepting any download and the permissions dialog, the user in question will have video captured from the desktop screen (or specific app or window, as requested) and broadcast to any subscribers listening."

Which statement is true?  Is it 1-to-1 or 1-to-many?

And, do you think quality/fps will affect my problem?  If so, what settings do you recommend?

Regarding "But using a htmlloader with in an AIR app is a workaround." What is the workaround?

Thanks,

David

[Former Community Member]

Hi David,

Can you point me directly to the post you're referring to? I couldn't find

that statement, which is clearly wrong. The docs are the right source of

info here - screensharing is 1-to-many.

nigel

[Former Community Member]

Also, I think Arun would like for you to just try the SWF in your browser,

right from where it's hosted, and see how much latency/dropping you're

experiencing. Just click the link or copy it into a browser, and run it

directly. We'd like to see if it's AIR introducing issues or not.

So, I'd like to understand better what you're hitting here - the

description so far is vague. Are you saying that, while in the middle of

sharing, the sharing just stops? Does it ever catch up? Screensharing is

pretty dumb - all it does is capture pixels as they change on your screen,

and it doesn't know about you changing tabs or content, so it's not as

though it's missing some high-level events from you. What you're describing

seems to be that sharing is just stopping at some point.

One thing that might be useful is for you to take a couple of

screencapture videos (one for the publisher, one for the subscriber) and

send them our way.

As for the HTMLLoader suggestion, I think Arun was having a difficult time

expressing this (it's complicated, and we're just figuring it out

ourselves!) - the issue is that AIR isn't able to download and install your

addin automatically for you. For whatever reason, only the standard Flash

Player seems to have this capability. Arun's suggesting that you could use

an HTMLLoader component in AIR to load a Flash Player (with a

screensharePublisher in it), which will be able to do the install. Yup, it's

a workaround...

And I totally feel your pain regarding issues that you're having, but I'd

ask that you keep the tone a little more even here - blanket statements like

"woefully lacking" are both not very useful (what's lacking? Specifics,

please) and tend to cause those responding to you (very quickly, and for

free!) to feel like you're lashing out at them. We're all human here; let's

keep it cool.

respect!

nigel

[David_Welch]

Nigel:

I'll try to capture some video of the behavior and send it...it actually is kind of strange, as you get cursor movements immediately and even mouse clicks, but, no other screen changes.

I'll try to run Arun's example like you said and post back.

Regarding the tone, I think you need to check the post again...it was edited after original posting because after reading again, it did seem a little harsh...it's not meant to be personal. 

But, you have to admit, there's only a few sentences on Screen Sharing in the doc, and most of it describes the user experience, not much about what the developer should be concerned with or details about the API.  And, it's such a huge enhancement (at least in my eyes) to add to LCCS.

Thanks for the assistance,

David

[David_Welch]

Arun:

I tried using this link (finally) and screen sharing displays the updates appropriately (although pretty slow and sometimes not very clear screen painting).  And, when I share a screen that contains the Air app, it displays updates as expected.  So, it must be something with how I'm embedding the screen publisher.

So, just to prove if it's something within my code, can you send me the code used in this SimpleScreenShare1.swf so I can plug into my Air app to see if this works also?

My Air code basically includes ScreenSharePublisherExample.mxml and ScreenShareSubscriberExample.mxml (from the sampleApps/ScreenShareExample code) combined into one component.  Below is a link to the component.

LCCSScreenShare.mxml

I'm using the latest (April 2011) release of 10.1 Player LCCS and Flex 4.1.  Even with the updated LCCS api from earlier this month, I still get no updates from the screen subscriber after initial painting of the screen session.  I do get ALL mouse movement and mouse "clicks".

Thanks!

David

[aponnusa]

I took a cursory glance of your code, and nothing seems wrong. I am guessing something else with what you are doing.

Src of SimpleScreenShare1.swf

<?xml version="1.0" encoding="utf-8"?>

<mx:Application minWidth="955" minHeight="600"
                    xmlns:mx="http://www.adobe.com/2006/mxml"
                    xmlns:rtc="http://ns.adobe.com/rtc"
                    xmlns:authentication="com.adobe.rtc.authentication.*"
                    xmlns:session="com.adobe.rtc.session.*"
                    xmlns:collaboration="com.adobe.rtc.collaboration.*"
                    applicationComplete="init()"
                    >
     
     <mx:Script>
          <![CDATA[
               import com.adobe.rtc.events.ScreenShareEvent;
               import com.adobe.rtc.util.DebugUtil;
               
               import mx.core.Application;
               
               private var firstTime:Boolean=true;
               
               private function init():void {
                    DebugUtil.traceFunction = traceMessage;
                    //sSub.addEventListener(ScreenShareEvent.SCREEN_SHARE_STARTED,onScreenShare);
                    //sSub.addEventListener(ScreenShareEvent.SCREEN_SHARE_STOPPED,onScreenShare);
                    //cSession.login();
               }
               
               private function traceMessage(message:String):void {
                    messages.text += message + "\n";
               }
               
               private function startStop(event:MouseEvent):void
               {
                    if (sPub.isPublishing) {
                         sPub.stop();
                    } else {
                         if (firstTime)
                              firstTime == false;
                         else
                              messages.text = "";
                         
                         sPub.publish();
                    }               
               }
               
               protected function onScreenShare(p_Evt:ScreenShareEvent):void
               {
                    //sButton.enabled = !sSub.someoneElseIsSharing;
               }
          ]]>
     </mx:Script>
     
     <authentication:AdobeHSAuthenticator id="auth" userName="screenShareTester"/>
     
     <mx:VDividedBox width="100%" height="100%">
          <session:ConnectSessionContainer width="100%" height="100%" id="cSession" authenticator="{auth}" autoLogin="true" roomURL="https://collaboration.adobelivecycle.com/userName/ROOMNAME" suppressDebugTraces="false">
               <collaboration:ScreenSharePublisher id="sPub" playerVersion="10"/>
               <collaboration:ScreenShareSubscriber width="100%" height="100%" showMyStream="true" id="sSub"/>
          </session:ConnectSessionContainer>
          <mx:TextArea width="100%" height="100%" id="messages"/>
          <mx:HBox width="100%">
               <mx:Button label="{sPub.isPublishing ? 'Stop' : 'Start'}" click="startStop(event)" id="sButton" />
          </mx:HBox>
     </mx:VDividedBox>
     
</mx:Application>

Thanks

Arun

[David_Welch]

Arun:

I played around with various tuning settings both in the Air app and the ScreenSharePublisher component, finally leaving it at:

<rtc:ScreenSharePublisher

id="sspublisher" playerVersion="10" connectSession="{cSession}" enableHFSS="false" fps="15" quality="100" />

but not much change in behavior.

However, what I notice is that the screen updates are EVENTUALLY published, after waiting sometimes as long as two minutes.  So, I'm getting the screen updates, but, it's taking a very long time.

Is this what we should expect on performance, or, is this unusual?  All of these computers are within a small LAN (less than 5 computers) and we're on a 3gb DSL line (downstream isn't great though).

I've tried to use full screen, application, and window sharing, without any noticeable change in performance.  Also, I've even done full screen sharing and minimized the Air app, and just moved around browser windows (or any other Window app), and, it still takes more than a minute to update on the subscribing client.

I've also tried changing from using ScreenShareSubscriberComplex to ScreenShareSubscriber.

I could even send you my Air app if this would help.

Thanks,

David

[Raff_]

David, are you saying that the same (or similar) LCCS application on the same machines and network will connect and publish data fast if it doesn't contain the screen sharing modules but it will connect very slowly if it fad the screen sharing modules enabled ? That sound very strange and the debug logs would be helpful to diagnose the problem.

If instead you didn't try an application without screen sharing I'd suggest you try (and I would guess the problem is that your network blocks RTMFP and you are using the player 10+ swc that always tries to connect via RTMFP first and the flash player is taking its time before timing out and trying rtmps)

Sent from my iPhone

[David_Welch]

Arun:

The issue is only with Screen Sharing, using the same Air app on multiple machines, and they have audio/video and some other data access to custom collections in LCCS that work fine, but, the screen refresh for any Screen Sharing session is the issue.

The behavior for Screen Sharing is that the subscriber immediately sees the published screen, and immediately sees cursor movement, but, it takes sometimes minutes (and always at least 60 seconds) before showing screen updates.

I did bandwidth test on speedtest.net on the subscribing machine and it displayed download speed of 2.92 Mbps, which, seems pretty acceptable.  The upload speed is 0.27 Mbps, which seems pretty slow...but, not sure if this effects performance.

What seems to be a very telling test is that if I run your ScreenShare1.swf from the same two machines I'm testing from, screen updates (using full screen mode) are shown in approx 2 seconds every time!

So, could it be that when the Air app fires up the addin differently somehow from the Air app?  I'm going to put you code in a simple air wrapper and see if it displays same.

Thanks,

David

[David_Welch]

Created the Air app using the ScreenShare1.swf example you sent, and it works pretty well, screen updates in 2-4 seconds.

So, the issue seems to be something in the way my Air app has been coded or is configured.  I'm pasting in the logs from my Air app and from the test Air app using your code (from boot to starting screen sharing), maybe that will help.  Both apps connect to the same room.

thanks,

David

From my test Air app using your code:

08:03:59 GMT-0400    #TicketService# ticket received: 1vjorzm8dh10u
08:03:59 GMT-0400    Getting FMS at https://na2.collaboration.adobelivecycle.com/fms?ticket=1vjorzm8dh10u&proto=rtmfp, attempt #1/3
08:03:59 GMT-0400    result: <fms>
  <origin>fms6.acrobat.com</origin>
  <proto_ports>rtmfp:1935,rtmps:443</proto_ports>
  <retry_attempts>2</retry_attempts>
</fms>
08:03:59 GMT-0400    protocols: [object ProtocolPortPair],[object ProtocolPortPair]
08:03:59 GMT-0400    [attempt 1 of 2] Connecting to 0/1: rtmfp://fms6.acrobat.com/cocomo/na2-sdk-ee3b168c-e033-482b-9aba-9c5cea3e9abc/remedy #startProtosConnect#
08:04:01 GMT-0400    tempNetStatusHandler 0/2,NetConnection.Connect.Success
08:04:01 GMT-0400    isTunneling? false
08:04:01 GMT-0400    is using RTMPS? false
08:04:01 GMT-0400    RECEIVED LOGIN AT SESSION
08:04:01 GMT-0400      .user descriptor from server [object]
08:04:01 GMT-0400        \\
08:04:01 GMT-0400        .displayName [string]= screenShareTester
08:04:01 GMT-0400        .userID [string]= GUEST-655EE530-1509-49FE-9E84-56A4E869AA89
08:04:01 GMT-0400        .affiliation [number]= 5
08:04:01 GMT-0400        .role [number]= 50
08:04:01 GMT-0400    RECEIVENODES UserManager
08:04:01 GMT-0400    receiveAllSynchData UserManager
08:04:01 GMT-0400    RECEIVENODES FileManager
08:04:01 GMT-0400    receiveAllSynchData FileManager
08:04:01 GMT-0400    checkManagerSync:[object FileManager]
08:04:01 GMT-0400    RECEIVENODES AVManager
08:04:01 GMT-0400    receiveAllSynchData AVManager
08:04:01 GMT-0400    checkManagerSync:[object StreamManager]
08:04:01 GMT-0400    RECEIVENODES RoomManager
08:04:01 GMT-0400    receiveAllSynchData RoomManager
08:04:01 GMT-0400    checkManagerSync:[object RoomManager]
08:04:01 GMT-0400    checkManagerSync:[object UserManager]
08:05:22 GMT-0400    #AddInLocalConnection# connected to Cocomo0
08:05:24 GMT-0400    #AddinLocalConnection# calling installService: domain:app#ScreenShareTest, _lcName:Cocomo0, fuzzedDomain:app#ScreenShareTest, url:http://connectnow.acrobat.com/static/screenshare/screenshareshell_player9_sgn.swf, version:Windows
08:05:24 GMT-0400    #AddInLocalConnection# onStatus:null, status
08:05:24 GMT-0400    #AddInLocalConnection# InstallStatus: Open.Success, version:undefined
08:05:28 GMT-0400    [Event type="activate" bubbles=false cancelable=false eventPhase=2]
08:05:46 GMT-0400    [Event type="activate" bubbles=false cancelable=false eventPhase=2]
08:07:14 GMT-0400    [Event type="activate" bubbles=false cancelable=false eventPhase=2]

From my Air app:

FROM AIR APP:

Tue Apr 19 08:10:36 GMT-0400 2011    LCCS SDK Version : 1.4.0    Player Version : WIN 10,1,53,64
08:10:36 GMT-0400    requestInfo http://connectnow.acrobat.com/<myacct>/remedy?guk=ZzpBbGxlbiBBbGxicm9vazo=&mode=xml&x=0.710763009730...
08:10:38 GMT-0400    #TicketService# ticket received: 162w9r54lufg4
08:10:38 GMT-0400    Getting FMS at https://na2.collaboration.adobelivecycle.com/fms?ticket=162w9r54lufg4&proto=rtmfp, attempt #1/3
08:10:38 GMT-0400    result: <fms>
  <origin>fms6.acrobat.com</origin>
  <proto_ports>rtmfp:1935,rtmps:443</proto_ports>
  <retry_attempts>2</retry_attempts>
</fms>
08:10:38 GMT-0400    protocols: [object ProtocolPortPair],[object ProtocolPortPair]
08:10:38 GMT-0400    [attempt 1 of 2] Connecting to 0/1: rtmfp://fms6.acrobat.com/cocomo/na2-sdk-ee3b168c-e033-482b-9aba-9c5cea3e9abc/remedy #startProtosConnect#
08:10:38 GMT-0400    tempNetStatusHandler 0/2,NetConnection.Connect.Success
08:10:38 GMT-0400    isTunneling? false
08:10:38 GMT-0400    is using RTMPS? false
08:10:39 GMT-0400    RECEIVED LOGIN AT SESSION
08:10:39 GMT-0400      .user descriptor from server [object]
08:10:39 GMT-0400        \\
08:10:39 GMT-0400        .displayName [string]= Allen Allbrook
08:10:39 GMT-0400        .affiliation [number]= 5
08:10:39 GMT-0400        .userID [string]= GUEST-76FD12BB-66DF-420E-9861-5B7F13537EEF
08:10:39 GMT-0400        .role [number]= 50
08:10:39 GMT-0400    RECEIVENODES UserManager
08:10:39 GMT-0400    receiveAllSynchData UserManager
08:10:39 GMT-0400    RECEIVENODES FileManager
08:10:39 GMT-0400    receiveAllSynchData FileManager
08:10:39 GMT-0400    checkManagerSync:[object FileManager]
08:10:39 GMT-0400    RECEIVENODES AVManager
08:10:39 GMT-0400    receiveAllSynchData AVManager
08:10:39 GMT-0400    checkManagerSync:[object StreamManager]
08:10:39 GMT-0400    RECEIVENODES RoomManager
08:10:39 GMT-0400    receiveAllSynchData RoomManager
08:10:39 GMT-0400    checkManagerSync:[object RoomManager]
08:10:39 GMT-0400    checkManagerSync:[object UserManager]
08:10:39 GMT-0400    RECEIVENODES _CollaborationVideo_CollaborationWebCamera1
08:10:39 GMT-0400    receiveAllSynchData _CollaborationVideo_CollaborationWebCamera1
08:10:39 GMT-0400    RECEIVENODES default_SimpleChat
08:10:39 GMT-0400    receiveAllSynchData default_SimpleChat

...
08:13:11 GMT-0400    #AddInLocalConnection# connected to Cocomo0
08:13:11 GMT-0400    #AddinLocalConnection# calling installService: domain:app#REMDesk, _lcName:Cocomo0, fuzzedDomain:app#REMDesk, url:http://connectnow.acrobat.com/static/screenshare/screenshareshell_player9_sgn.swf, version:Windows
08:13:12 GMT-0400    #AddInLocalConnection# onStatus:null, status
08:13:12 GMT-0400    #AddInLocalConnection# InstallStatus: Open.Success, version:undefined
08:13:16 GMT-0400    [Event type="activate" bubbles=false cancelable=false eventPhase=2]

[Former Community Member]

Hi David,

When you describe the 30 second gap before pixels appear, is this gap

post-addin dialog? In other words, it's the time after you select what to

share and before you see anything on the subscriber?

Your uplink is a little slow, so this would likely have an impact, but I'm

guessing that the discrepancy between the 2 apps is that you're consuming

either a lot of bandwidth or CPU in your app, and it's slowing down the

capture or broadcast of the screen. Your next step should be, for both apps,

capturing the bandwidth and CPU utilization. Let us know what you find!

Hope that helps,

nigel

[David_Welch]

Nigel:

The gap is after the screen first appears, in the subscriber.  The subscriber eventually gets the updated screen, but, most times (95% maybe?) as much as 2 minutes later.

The addin dialog appears immediately in the publisher side.

Also, the subscriber gets all mouse movement and mouse clicks almost immediately, just no screen repainting.

There is almost no discernible CPU utilitization on either end (subscriber machine or publisher machine).  Not sure how to capture bandwidth on either end.  Open to suggestions though.

Regarding the uplink speed, I would agree, seems a bit slow, but, when I use Arun's web-based swf, everything works fine, screen updates are almost immediate, so, that would seem to rule out bandwidth issues.  And, I basically pasted his code into a new Air app and it still works fine.  So, seems to be specific to the way my Air app is using screen sharing components.

Thanks,

David

[David_Welch]

Some additional info:  I started screen sharing session (full screen) from Machine A using the Air App, and on Machine B, I subscribed to the session using both the same Air app, and, using a web application swf (code provided by Arun), connecting to the same room.  I get the same intermittent behavior, the subscribers paint the screen immediately, and, maybe a few screen updates for the next few seconds, then, I get no updates.  Both apps get a screen update in about 2 1/2 minutes, then, it stops again, repeats the cycle.

Again, I get IMMEDIATE cursor updates in both apps.  And, when I stop screen sharing in Machine A, both apps on Machine B IMMEDIATELY see this (containers go black).

This would seem to remove any issue in the application code from the subscriber's perspective, and, anything related to being an Air app vs. a web delivered swf.

So, can anyone help on how to resolve this?

Thanks,

David

[Raff_]

Just to know, what's the resolution of the publisher's screen ? (even if you have enough bandwidth I am wondering if you are saturation the client, that will then try to play catch up by continuously dropping frames).

You could try lowering the screen resolution, just to see if that improve the behavior. That would give us some ideas of what to do next.