Open abdullah2993 opened 8 years ago
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. :smile:
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
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.