Android/scrcpy
1
0
Fork 0
Code Issues Pull requests Projects Releases 1 Packages Wiki Activity
scrcpy/app/src/clock.h

44 lines
1 KiB
C
Raw Normal View History

Implement buffering 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 <https://github.com/Genymobile/scrcpy/issues/2417>
2021-07-04 21:24:51 +08:00
#ifndef SC_CLOCK_H
#define SC_CLOCK_H
#include "common.h"
#include "util/tick.h"
struct sc_clock_point {
sc_tick system;
sc_tick stream;
};
/**
* The clock aims to estimate the affine relation between the stream (device)
* time and the system time:
*
* f(stream) = slope * stream + offset
*
Simplify clock estimation The slope encodes the drift between the device clock and the computer clock. Its real value is expected very close to 1. To estimate it, just assume it is exactly 1. Since the clock is used to estimate very close points in the future, the error caused by clock drift is totally negligible, and in practice it is way lower than the slope estimation error. Therefore, only estimate the offset.
2023-03-27 08:12:59 +08:00
* Theoretically, the slope encodes the drift between the device clock and the
* computer clock. It is expected to be very close to 1.
Implement buffering 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 <https://github.com/Genymobile/scrcpy/issues/2417>
2021-07-04 21:24:51 +08:00
*
Simplify clock estimation The slope encodes the drift between the device clock and the computer clock. Its real value is expected very close to 1. To estimate it, just assume it is exactly 1. Since the clock is used to estimate very close points in the future, the error caused by clock drift is totally negligible, and in practice it is way lower than the slope estimation error. Therefore, only estimate the offset.
2023-03-27 08:12:59 +08:00
* Since the clock is used to estimate very close points in the future (which
* are reestimated on every clock update, see delay_buffer), the error caused
* by clock drift is totally negligible, so it is better to assume that the
* slope is 1 than to estimate it (the estimation error would be larger).
Implement buffering 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 <https://github.com/Genymobile/scrcpy/issues/2417>
2021-07-04 21:24:51 +08:00
*
Simplify clock estimation The slope encodes the drift between the device clock and the computer clock. Its real value is expected very close to 1. To estimate it, just assume it is exactly 1. Since the clock is used to estimate very close points in the future, the error caused by clock drift is totally negligible, and in practice it is way lower than the slope estimation error. Therefore, only estimate the offset.
2023-03-27 08:12:59 +08:00
* Therefore, only the offset is estimated.
Implement buffering 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 <https://github.com/Genymobile/scrcpy/issues/2417>
2021-07-04 21:24:51 +08:00
*/
struct sc_clock {
Simplify clock estimation The slope encodes the drift between the device clock and the computer clock. Its real value is expected very close to 1. To estimate it, just assume it is exactly 1. Since the clock is used to estimate very close points in the future, the error caused by clock drift is totally negligible, and in practice it is way lower than the slope estimation error. Therefore, only estimate the offset.
2023-03-27 08:12:59 +08:00
unsigned range;
Implement buffering 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 <https://github.com/Genymobile/scrcpy/issues/2417>
2021-07-04 21:24:51 +08:00
sc_tick offset;
};
void
sc_clock_init(struct sc_clock *clock);
void
sc_clock_update(struct sc_clock *clock, sc_tick system, sc_tick stream);
sc_tick
sc_clock_to_system_time(struct sc_clock *clock, sc_tick stream);
#endif
Reference in a new issue Copy permalink