The audio player had 2 roles:
- handle the SDL audio output device;
- resample input samples to maintain a target latency.
Extract the latter to a separate component (an "audio regulator"),
independent of SDL.
Similar to UHID keyboard and mouse, but for gamepads.
Can be enabled with --gamepad=uhid or -G.
It is not enabled by default because not all devices support UHID
(there is a permission error on old Android versions).
PR #5270 <https://github.com/Genymobile/scrcpy/pull/5270>
Rename {keyboard,mouse}_inject to {keyboard,mouse}_sdk.
All implementations "inject" key events and mouse events, what differs
is the mechanism. For these implementations, the Android SDK API is used
to inject events.
Note that the input mode enum variants were already renamed
(SC_KEYBOARD_INPUT_MODE_SDK and SC_MOUSE_INPUT_MODE_SDK).
PR #4473 <https://github.com/Genymobile/scrcpy/pull/4473>
The audio output thread only reads samples from the buffer, and most of
the time, the audio receiver thread only writes samples to the buffer.
In these cases, using atomics avoids lock contention.
There are still corner cases where the audio receiver thread needs to
"read" samples (and drop them), so lock only in these cases.
PR #4572 <https://github.com/Genymobile/scrcpy/pull/4572>
Install all the prebuilt dependencies for Windows to a specific folder,
and use meson command line options to specify their location.
This removes crossbuild-specific code from the meson scripts and will
simplify dependency upgrades.
PR #4460 <https://github.com/Genymobile/scrcpy/pull/4460>
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.
Play the decoded audio using SDL.
The audio player frame sink receives the audio frames, resample them
and write them to a byte buffer (introduced by this commit).
On SDL audio callback (from an internal SDL thread), copy samples from
this byte buffer to the SDL audio buffer.
The byte buffer is protected by the SDL_AudioDeviceLock(), but it has
been designed so that the producer and the consumer may write and read
in parallel, provided that they don't access the same slices of the
ring-buffer buffer.
PR #3757 <https://github.com/Genymobile/scrcpy/pull/3757>
Co-authored-by: Simon Chan <1330321+yume-chan@users.noreply.github.com>
The components needing delayed frames (sc_screen and sc_v4l2_sink)
managed a sc_video_buffer instance, which itself embedded a
sc_frame_buffer instance (to keep only the most recent frame).
In theory, these components should not be aware of delaying: they should
just receive AVFrames later, and only handle a sc_frame_buffer.
Therefore, refactor sc_delay_buffer as a frame source (it consumes)
frames) and a frame sink (it produces frames, after some delay), and
plug an instance in the pipeline only when a delay is requested.
This also removes the need for a specific sc_video_buffer.
PR #3757 <https://github.com/Genymobile/scrcpy/pull/3757>
There was a frame sink trait, implemented by components able to receive
AVFrames, but each frame source had to manually send frame to sinks.
In order to mutualise sink management, add a frame sink trait.
There was a packet sink trait, implemented by components able to
receive AVPackets, but each packet source had to manually send packets
to sinks.
In order to mutualise sink management, add a packet source trait.
A video buffer had 2 responsibilities:
- handle the frame delaying mechanism (queuing packets and pushing them
after the expected delay);
- keep only the most recent frame (using a sc_frame_buffer).
In order to be able to reuse only the frame delaying mechanism, extract
it to a separate component, sc_delay_buffer.
If no bit-rate is passed, let the server use the default value (8Mbps).
This avoids to define a default value on both sides, and to pass the
default bit-rate as an argument when starting the server.
PR #3757 <https://github.com/Genymobile/scrcpy/pull/3757>
On the scrcpy-deps repo, I built FFmpeg 5.1.2 binaries for Windows with
only the features used by scrcpy.
For comparison, here are the sizes of the dll for FFmpeg 5.1.2:
- before: 89M
- after: 4.7M
It also allows to upgrade the old FFmpeg version (4.3.1) used for win32.
Refs <https://github.com/rom1v/scrcpy-deps>
Refs <https://github.com/Genymobile/scrcpy/issues/1753>
Add a launcher which opens a terminal, and keep it open in case of
errors (so that the user has time to read error messages).
The behavior is the same as scrcpy-console.bat on Windows.
PR #3351 <https://github.com/Genymobile/scrcpy/pull/3351>
The files in data/ are specific to the client app (not the server).
This also avoids to reference the parent directory (../) from
app/meson.build.
Refs 8d583d36e2