Join GitHub today
GitHub is home to over 50 million developers working together to host and review code, manage projects, and build software together.
Sign upReduce latency by 1 frame #646
Closed
+241
−195
Conversation
0f0ccf4
to
0aa9828
To packetize the H.264 raw stream, av_parser_parse2() (called by av_read_frame()) knows that it has received a full frame only after it has received some data for the next frame. As a consequence, the client always waited until the next frame before sending the current frame to the decoder! On the device side, we know packets boundaries. To reduce latency, make the device always transmit the "frame meta" to packetize the stream manually (it was already implemented to send PTS, but only enabled on recording). On the client side, replace av_read_frame() by manual packetizing and parsing. <https://stackoverflow.com/questions/50682518/replacing-av-read-frame-to-reduce-delay> <https://trac.ffmpeg.org/ticket/3354>
Closed
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
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.
rom1v commentedJul 12, 2019
•
edited
This PR contains unrelated commit after I pushed force it (I cannot change the base branch). The relevant commit is 63af7fb.
To packetize the H.264 raw stream, av_parser_parse2() (called by
av_read_frame()) knows that it has received a full frame only after it has received some data for the next frame. As a consequence, the client always waited until the next frame before sending the current frame to the decoder!On the device side, we know packets boundaries. To reduce latency, make the device always transmit the "frame meta" to packetize the stream manually (it was already implemented to send PTS, but only enabled on recording).
On the client side, replace
av_read_frame()by manual packetizing and parsing.https://stackoverflow.com/questions/50682518/replacing-av-read-frame-to-reduce-delay
https://trac.ffmpeg.org/ticket/3354
I'm opening a pull request to get more tests before merging (the changes are quite sensitive), to avoid regressions.
To confirm that it actually reduces the end-to-end latency by 1 frame, I created a video which increments a number at 30fps (every 33.3ms):
I run this video in VLC on Android, and start scrcpy.
I compared the current master with this PR for both 1080x1920 (just running
scrcpy) and 448x800 (runningscrcpy -m800).1080x1920
on
masterEnd-to-end latency is about 3 frames (~100ms).
on
lowlatencyEnd-to-end latency is about 2 frames (~67ms).
Once a packet is received by the client, on average, the frame is rendered 12ms later.
(with "skip frames" disabled, i.e.
--render-expired-frames)448x800
on
masterEnd-to-end latency is about 2 frames (~67ms).
on
lowlatencyEnd-to-end latency is about 1 frame (~33ms).
Once a packet is received by the client, on average, the frame is rendered 8ms later.
(with "skip frames" disabled, i.e.
-m800 --render-expired-frames)For now, I preserved the compatibility with prebuilt server v1.9, so you can just:
git fetch origin && git checkout lowlatencythen build as usual.
For windows users, I built a binary (replace the one from v1.9):
scrcpy.exe.SHA-256: 6b8eae4eb4df811b6aa194320f00b51102cf3a254e432f353963863c82f362ea
Thank you for your feedbacks😉