Dynamic frame delay based on maxClientFrameRate in IPVideoRoute #47
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
In regards to:
The code in this PR updates the way the
handleRequest
thread sleeps to attempt to keep a steady fps with shorter waits for an empty queue.I looked at the vars in IPVideoConnection and tried to guess at what the original design was, but saw that a few of them aren't being used anyway.
With this code I get smoother streaming with less delay. For many frames, the sending takes more time than
1000 / FPS ms
, so thewait()
is skipped entirely; this in contrast to the old code that always waits 30ms.