The header scrcpy.h is intended to be the "public" API. It should not
depend on other internal headers.
Therefore, declare all required structs in this header and adapt
internal code.
Add a command-line option to force "adb forward", without attempting
"adb reverse" first.
This is especially useful for using SSH tunnels without enabling remote
port forwarding.
The verbosity was set either to info (in release mode) or debug (in
debug mode).
Add a command-line argument to change it, so that users can enable debug
logs using the release:
scrcpy -Vdebug
The field lock_video_orientation may only take values between -1 and 3
(included). But the compiler may trigger a warning on the sprintf()
call, because its type could represent values which could overflow the
string (like "-128"):
> warning: ‘%i’ directive writing between 1 and 4 bytes into a region of
> size 3 [-Wformat-overflow=]
Increase the buffer size to remove the warning.
Now that the server can access the Android settings and clean up
properly, handle the "show touches" option from the server.
The initial state is now correctly restored, even on device
disconnection.
The server may die before connecting to the client. In that case, the
client was blocked indefinitely (until Ctrl+C) on accept().
To avoid the problem, close the server socket once the server process is
dead.
Accept a range of ports to listen to, so that it does not fail if
another instance of scrcpy is currently starting.
The range can be passed via the command line:
scrcpy -p 27183:27186
scrcpy -p 27183 # implicitly 27183:27183, as before
The default is 27183:27199.
Closes#951 <https://github.com/Genymobile/scrcpy/issues/951>
Start the server socket in enable_tunnel() directly.
For the caller point of view, enabling the tunnel opens a port (either
the server socket locally or the "adb forward" process).
The function get_server_path() sometimes returned an owned string,
sometimes a non-owned string.
Always return an allocated (owned) string, and free it after usage.
If SCRCPY_SERVER_PATH points to a directory, then a directory will be
pushed to /data/local/tmp/scrcpy-server.jar.
When executing it, app_process will just abort and leave the directory
on the device, causing scrcpy to always fail.
To avoid the problem, check that the server is a regular file before
pushing it.
Closes#956 <https://github.com/Genymobile/scrcpy/issues/956>
Commit 3da95b52bd renamed
'scrcpy-server.jar' to 'scrcpy-server' to avoid issues on the client
side.
However, removing the extension may cause issues with app_process, so
restore the extension only on the device side.
Fixes <https://github.com/Genymobile/scrcpy/issues/944>
Send client version as first parameter and check it at server start.
Signed-off-by: Yu-Chen Lin <npes87184@gmail.com>
Signed-off-by: Romain Vimont <rom@rom1v.com>
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>
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.
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.
The socket used the device-to-computer direction to stream the video and
the computer-to-device direction to send control events.
Some features, like copy-paste from device to computer, require to send
non-video data from the device to the computer.
To make them possible, use two sockets:
- one for streaming the video from the device to the client;
- one for control/events in both directions.
