[GH-ISSUE #502] Reason for sending Redundent packets for stream operations? #272

New issue

Open

opened 2026-02-27 15:49:38 +03:00 by kerem · 2 comments

kerem commented

2026-02-27 15:49:38 +03:00

Owner

Originally created by @abdullah2993 on GitHub (Aug 9, 2016).
Original GitHub issue: https://github.com/quasar/Quasar/issues/502

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.

Originally created by @abdullah2993 on GitHub (Aug 9, 2016). Original GitHub issue: https://github.com/quasar/Quasar/issues/502 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.

kerem added the

question

label

2026-02-27 15:49:38 +03:00

kerem commented

2026-02-27 15:49:39 +03:00

Author

Owner

@MaxXor commented on GitHub (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 commented on GitHub (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. :smile:

kerem commented

2026-02-27 15:49:39 +03:00

Author

Owner

@d3agle commented on GitHub (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

@d3agle commented on GitHub (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