Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Option for video buffer/delay #300

Open
disdiq2 opened this issue Mar 22, 2025 · 1 comment
Open

Option for video buffer/delay #300

disdiq2 opened this issue Mar 22, 2025 · 1 comment

Comments

@disdiq2
Copy link

disdiq2 commented Mar 22, 2025

I want to preface this by saying how fantastic this project is, as I was looking for an alternative to scrcpy which would easily allow direct streaming to a browser, OBS etc. One feature of scrcpy(as far as video only streaming) which would benefit my use case would be the ability to delay the video stream. Scrcpy uses the video buffer as a method of "dejittering" the stream (Genymobile/scrcpy#2464) on the PC/client side. A major advantage of ScreenStream for me is the lack of a client software, in lieu of a direct mjpeg/wrtc stream, however the lack of an integrated buffer/delay option means that it must be added after (OBS render delay is limited to 500ms & resource intensive). Would it be possible to implement a similar buffer, but on the phone side?

@dkrivoruchko
Copy link
Owner

Thanks for the feedback and new ideas.
The main problem you want to solve is jitter caused by encoding, network and decoding.
Most of the problem is caused by network, not encoding/decoding.
MJPEG mode has no jitter compensation mechanism, so adding it on source and consumer side can only be done outside MJPEG standard (meaning - we need custom client).
WebRTC has some buffers to compensate for jitter, so there is no reason to add any on top of the standard.
Bottom line - I don't see how to solve the jitter problem and keep compatibility/simplicity.

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

No branches or pull requests

2 participants