Increasing Latency #2417
Comments
|
No, there is currently no setting to increase latency, there is no buffering at all (the goal was to get the smallest possible latency).
Do you use it over USB? On OBS, do you capture the scrcpy window (which might add more lags), or the new V4L2 feature (on Linux)? Note that if you record ( |
|
I typically use scrcpy with usb, works extremely well over USB. Unfortunately I do not own nor use Linux, so I cant try this V4L2 feature. But ever since buying my new phone, it does not have an audio jack. So I have been using a bluetooth audio receiver, which apparently has a big latency issue. sndcpy sadly does not work too for my game. So the idea is to prioritize audio latency, using the type-c port for audio, and wireless for screen sharing, in theory anyways. kinda like PTZ cameras. But no biggie if this does not work, its just something I will have to get used too. Thanks! |
|
Do you also notice "lag spikes" if you just run scrcpy without OBS? Or is it just when OBS is capturing the window? Are there "lag spikes" in the recorded file? (
You could try a LiveUSB on your computer (Ubuntu for example) 😉
The feature might make sense (it has already been requested btw), but currently there is no way to add buffering. |
Yup, there is noticeable lag spikes with scrcpy running without OBS. At lower bitrate and resolution too albeit lesser.
No spikes in the recorded file.
Ah I see. Probably best to consider a phone with a headphone jack, much easier fix in this situation haha. |
I don't understand, video jitter is independent of audio, so why would a phone with a headphone jack would fix your issue? |
Ah. Then I could use scrcpy via type-c, which would eliminate any lag spikes if it was wireless. And also fix the Bluetooth latency issue, since I can use the headphone jack for audio line-in into my PC. All would be in-sync without sacrificing visual quality. Since my current phone does not have headphone jack, the type-c can only be used for scrcpy or audio. So it's dealing with either Bluetooth latency via Bluetooth receiver, or lag spikes via wireless screen sharing. Hopefully that makes sense. |
Oh, so currently over USB, it works well without this issue for you? |
|
Yes, works really good via USB. Probably should have clarified that part in my original post. My bad haha, totally missed that part out. |
|
Same feature request (ability to manual add latency) but with different reason: Implementing a configurable setting to add latency would be much help, so that I can manual sync the video and audio. |
|
I plan to implement this feature in v1.19. This avoids the slight "laggy" effect due to incorrect presentation timing (on video playback for example). This is important for streaming quality. |
To minimize latency (at the cost of jitter), scrcpy always displays the latest device frame it receives, without waiting. However, when recording (--record), it still writes the captured timestamps to the output file, so that the recorded file can be played correctly without jitter. Some real-time use cases might benefit from adding a small latency to compensate for jitter too. For example, few tens of seconds of latency for live-streaming are not important, but jitter is noticeable. Therefore, implement a buffering mechanism (disabled by default) to add a configurable latency delay. PR #2417 <#2417>
To minimize latency (at the cost of jitter), scrcpy always displays a frame as soon as it available, without waiting. However, when recording (--record), it still writes the captured timestamps to the output file, so that the recorded file can be played correctly without jitter. Some real-time use cases might benefit from adding a small latency to compensate for jitter too. For example, few tens of seconds of latency for live-streaming are not important, but jitter is noticeable. Therefore, implement a buffering mechanism (disabled by default) to add a configurable latency delay. PR #2417 <#2417>
|
Implemented by #2464 |
To minimize latency (at the cost of jitter), scrcpy always displays a frame as soon as it available, without waiting. However, when recording (--record), it still writes the captured timestamps to the output file, so that the recorded file can be played correctly without jitter. Some real-time use cases might benefit from adding a small latency to compensate for jitter too. For example, few tens of seconds of latency for live-streaming are not important, but jitter is noticeable. Therefore, implement a buffering mechanism (disabled by default) to add a configurable latency delay. PR #2417 <#2417>
To minimize latency (at the cost of jitter), scrcpy always displays a frame as soon as it available, without waiting. However, when recording (--record), it still writes the captured timestamps to the output file, so that the recorded file can be played correctly without jitter. Some real-time use cases might benefit from adding a small latency to compensate for jitter too. For example, few tens of seconds of latency for live-streaming are not important, but jitter is noticeable. Therefore, implement a buffering mechanism (disabled by default) to add a configurable latency delay. PR #2417 <#2417>
To minimize latency (at the cost of jitter), scrcpy always displays a frame as soon as it available, without waiting. However, when recording (--record), it still writes the captured timestamps to the output file, so that the recorded file can be played correctly without jitter. Some real-time use cases might benefit from adding a small latency to compensate for jitter too. For example, few tens of seconds of latency for live-streaming are not important, but jitter is noticeable. Therefore, implement a buffering mechanism (disabled by default) to add a configurable latency delay. PR #2417 <#2417>
To minimize latency (at the cost of jitter), scrcpy always displays a frame as soon as it available, without waiting. However, when recording (--record), it still writes the captured timestamps to the output file, so that the recorded file can be played correctly without jitter. Some real-time use cases might benefit from adding a small latency to compensate for jitter too. For example, few tens of seconds of latency for live-streaming are not important, but jitter is noticeable. Therefore, implement a buffering mechanism (disabled by default) to add a configurable latency delay. PR #2417 <#2417>
To minimize latency (at the cost of jitter), scrcpy always displays a frame as soon as it available, without waiting. However, when recording (--record), it still writes the captured timestamps to the output file, so that the recorded file can be played correctly without jitter. Some real-time use cases might benefit from adding a small latency to compensate for jitter too. For example, few tens of seconds of latency for live-streaming are not important, but jitter is noticeable. Therefore, implement a buffering mechanism (disabled by default) to add a configurable latency delay. PR #2417 <#2417>
|
Merged into |
Is there a way to increase latency? Weird question but mainly because I dont need low latency, but instead smooth gameplay with minimal lag spikes. Since I will be streaming, I can always adjust audio to sync in OBS afterwards.
Thanks.
The text was updated successfully, but these errors were encountered: