While the Ctrl key is held, the first left-click adds an immobile
"virtual finger" at this position.
Moving the mouse moves another cursor. The left click may be released
and pressed as necessary to control the second finger.
Releasing Ctrl releases the virtual finger.
Enable the attribute "console" of custom_target() introduced in meson
0.48. This allows to get a feedback of what gradle does (which can takes
a very long time).
This produces warnings because we declare to support meson >= 0.37, but
we don't want to stop supporting older versions for that. Older versions
just ignore the option:
> WARNING: Unknown keyword arguments in target scrcpy-server: console
Newer meson versions use it, but warn because we declare supporting
older versions:
> WARNING: Project targetting '>= 0.37' but tried to use feature
> introduced in '0.48.0': console arg in custom_target
Meson does not support conditional branches to suppress such warnings,
so just keep the warnings.
We need several FIFO queues (a queue of packets, a queue of messages,
etc.).
Some of them are implemented using cbuf, a generic circular buffer. But
for recording, we need to store the packets in an unbounded queue until
they are written, so the queue was implemented manually.
Create a generic implementation (using macros) to avoid reimplementing
it every time.
The record file was written from the stream thread. As a consequence,
any blocking I/O to write the file delayed the decoder.
For maximum performance even when recording is enabled, send
(refcounted) packets to a separate recording thread.
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>
Recent versions of meson complain about an option having name starting
with "build_":
> DEPRECATION: Option uses prefix "build_", which is reserved for Meson.
> This will become an error in the future.
Use "compile_" instead.
If --no-control is set, then the controller is not initialized (both in
the client and the server), so it is not possible to control the device
to turn its screen off.
See <https://github.com/Genymobile/scrcpy/issues/608>.
Now that scrcpy-server.jar is found in the same directory as the
scrcpy executable, using SCRCPY_SERVER_PATH is not particularly useful
on Windows anymore
In portable builds, scrcpy-server.jar was supposed to be present in the
current directory, so in practice it worked only if scrcpy was launched
from its own directory.
Instead, find the absolute path of the executable and build a suitable
path to use scrcpy-server.jar from the same directory.
There was already utf8_to_wide_char(), used to correctly execute
commands on Windows.
Add the reverse converter: utf8_from_wide_char(). We will need it to
build the scrcpy-server path based on the executable directory.
To create a portable build (with scrcpy-server.jar accessible from the
scrcpy directory), replace OVERRIDE_SERVER_PATH by a simple compilation
flag: PORTABLE.
This paves the way to use more complex rules to determine the path of
scrcpy-server.jar in portable builds.
On socket disconnection, on Linux, recv() returns -1 and errno is set.
But on Windows, errno is 0.
In that case, AVERROR(errno) == 0, leading to the warning:
> Invalid return value 0 for stream protocol
To avoid the problem, if errno is 0, return AVERROR_EOF.
Ref: commit 2876463d39
The FPS counter was called only on new frames, so it could not print
values regularly, especially when there are very few FPS (when the
device surface does not change).
To the extreme, it was never able to display 0 fps.
Add a separate thread to print framerate every second.
Here is the description of the adb package in Debian:
> Description: Android Debug Bridge
>
> A versatile command line tool that lets you communicate with an
> emulator instance or connected Android-powered device.
>
> This package recommends "android-sdk-platform-tools-common" which
> contains the udev rules for Android devices. Without this package, adb
> and fastboot need to be running with root permission.
And android-tools-adb:
> Description: transitional package
>
> This is a transitional package. It can safely be removed.
Romain Vimont