Skip to content
This repository has been archived by the owner on Mar 17, 2024. It is now read-only.

Reason for sending Redundent packets for stream operations? #502

Open
abdullah2993 opened this issue Aug 9, 2016 · 2 comments
Open

Reason for sending Redundent packets for stream operations? #502

abdullah2993 opened this issue Aug 9, 2016 · 2 comments
Labels

Comments

@abdullah2993
Copy link
Contributor

abdullah2993 commented Aug 9, 2016

What is the reason for sending redundant packets in case if Desktop/Webcam streaming? After processing every frame a new packet is sent to get the new frame instead the client should keep sending frames untill ti received a stop packet.

@MaxXor
Copy link
Contributor

MaxXor commented Aug 9, 2016

The reason was that the server will receive the frames too fast and does not come afterwards with updating the remote desktop/webcam window which causes huge cpu load. This is a limitation due to the win32 message loop as this processes currently the redrawing of the frames in the window. One way to fix this is draw the frames with the gpu via directx/opengl.
So, at the moment the server requests the next frame when it's ready. 😄

@MaxXor MaxXor added the question label Aug 9, 2016
@d3agle
Copy link
Contributor

d3agle commented Aug 9, 2016

This post seems to be very informative with tips regarding this issue: http://stackoverflow.com/a/11025428

It would be really nice to have some sort of surface that is rendered utilizing GPU capabilities, so the packets wouldn't have to be throttled in this case

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
Projects
None yet
Development

No branches or pull requests

3 participants