latency between screen capture and update in web app

[isolver]

GF:

I am running on a 100BaseT router ... the video update takes about 5 seconds. I eye-balled it by moving the mouse and counted when the cursor in the videolink catches up with the red cursor. This is fine ... hope it can be better with faster network.

[isolver]

Given it sounds like updating the gaze cursor overlay on the web app is very fast (must be much faster than 5 seconds based on previous note), then I am not sure this is a network latency issue, as the gaze position is using the same network connection between the 2 PCs.

Instead it may be due to delays from the slow computers ( and maybe graphics cards) being used; delay can come from both sides:

• delay in time it takes to take the screen cap and encode it for transmission to webserver PC.
• delay in time taken by server PC to decode the video frame so it can be drawn.

My guess is the network speed has almost nothing to do with the 5 sec delay you are seeing. I get it is a processing speed issue (on both ends of the pipe).

On 2 desktops (each cost < $1000 CAD to buy, they are not high end really), the delay I am seeing is more like 1second. Can test this with 2 light keys, but not sure if that really would help anything.

I'm not saying we should not look at making it better, but there will be a limit based on the underlying HW being used.

Suggest we get functionality implemented and bugs fixed first. Then with whatever time is left improving performance can be looked at.

[garyfeng]

I will first disable the virus scanner and see how things go. Will report.

Do you think it has something to do with some ffmpeg setting? I thought it was faster in the last version.

Sent from my iPhone

On Apr 9, 2014, at 6:21 PM, Sol Simpson notifications@github.com wrote:

Given it sounds like updating the gaze cursor overlay on the web app is very fast (must be much faster than 5 seconds based on previous note), then I am not sure this is a network latency issue, as the gaze position is using the same network connection between the 2 PCs.

Instead it may be due to delays from the slow computers ( and maybe graphics cards) being used; delay can come from both sides:

delay in time it takes to take the screen cap and encode it for transmission to webserver PC. delay in time taken by server PC to decode the video frame so it can be drawn. My guess is the network speed has almost nothing to do with the 5 sec delay you are seeing. I get it is a processing speed issue (on both ends of the pipe).

On 2 desktops (each cost < $1000 CAD to buy, they are not high end really), the delay I am seeing is more like 1second. Can test this with 2 light keys, but not sure if that really would help anything.

I'm not saying we should not look at making it better, but there will be a limit based on the underlying HW being used.

Suggest we get functionality implemented and bugs fixed first. Then with whatever time is left improving performance can be looked at.

— Reply to this email directly or view it on GitHub.

[isolver]

It may.

I guess the current software will be effected more by the speed of the CPU being used, since it is encoding the screen frames into 2 different codecs; one for the web stream and another for the file stream, and then decoding the webstream on the other PC so it can be drawn. In your original app it likely did not have to encode-decode to have it display in the wxwindow, it just had to decode.

The settings I changed in this version resulted in almost 50% decrease in CPU usage on my 2 data collection PCs (an i3 and i7 desktop cpu, 2nd gen so 3 - 4 years old now.) without any notable change is delay.(which is ~ 1 sec eye balling it).

Q: If you disable audio stream saving by setting the following on the data collection app app_config:

screen_capture->dshow_filters->audio:

is now:

audio: virtual-audio-capturer

change to:

audio:

Does that make a difference in the delay?

Thanks,

Sol

[garyfeng]

the answer will be to get a faster computer. Now much we can do now. Let's leave it as a low priority.