On Linux, socket functions are unblocked by shutdown(), but on Windows
they are unblocked by closesocket().
Expose net_interrupt() and net_close() to abstract these differences:
- net_interrupt() calls shutdown() on Linux and closesocket() on
Windows (if not already called);
- net_close() calls close() on Linux and closesocket() on Windows (if
not already called).
This simplifies the server code, and prevents a data race on close
(reported by TSAN) on Linux (but does not fix it on Windows):
WARNING: ThreadSanitizer: data race (pid=836124)
Write of size 8 at 0x7ba0000000d0 by main thread:
#0 close ../../../../src/libsanitizer/tsan/tsan_interceptors_posix.cpp:1690 (libtsan.so.0+0x359d8)
#1 net_close ../app/src/util/net.c:211 (scrcpy+0x1c76b)
#2 close_socket ../app/src/server.c:330 (scrcpy+0x19442)
#3 server_stop ../app/src/server.c:522 (scrcpy+0x19e33)
#4 scrcpy ../app/src/scrcpy.c:532 (scrcpy+0x156fc)
#5 main ../app/src/main.c:92 (scrcpy+0x622a)
Previous read of size 8 at 0x7ba0000000d0 by thread T6:
#0 recv ../../../../src/libsanitizer/sanitizer_common/sanitizer_common_interceptors.inc:6603 (libtsan.so.0+0x4f4a6)
#1 net_recv ../app/src/util/net.c:167 (scrcpy+0x1c5a7)
#2 run_receiver ../app/src/receiver.c:76 (scrcpy+0x12819)
#3 <null> <null> (libSDL2-2.0.so.0+0x84f40)
When Ctrl+v is pressed, a control is sent to the device to set the
device clipboard before injecting Ctrl+v.
With the InputManager method, it is guaranteed that the device
synchronization is executed before handling Ctrl+v, since the commands
are executed on the device in sequence.
However, HID are injected from the computer, so there is no such
guarantee. As a consequence, on Android, Ctrl+v triggers a paste with
the old clipboard content.
To workaround the issue, wait a bit (2 milliseconds) from the AOA
thread before injecting the event, to leave enough time for the
clipboard to be set before injecting Ctrl+v.
When an AOA HID keyboard is registered, CAPSLOCK and NUMLOCK are both
disabled, regardless of the state of the computer keyboard.
To synchronize the state, on first key event, inject CAPSLOCK and/or
NUMLOCK if necessary.
The serial is necessary to find the correct Android device for AOA.
If it is not explicitly provided by the user via -s, then execute "adb
getserialno" to retrieve it.
The AVOutputFormat name is a comma-separated list. In theory, possible
names for V4L2 are:
- "video4linux2,v4l2"
- "v4l2,video4linux2"
- "v4l2"
- "video4linux2"
To find the muxer in all cases, we must request exactly one muxer name
at a time.
PR #2718 <https://github.com/Genymobile/scrcpy/pull/2718>
Co-authored-by: Romain Vimont <rom@rom1v.com>
Signed-off-by: Romain Vimont <rom@rom1v.com>
The first frames are typically received and decoded with more delay than
the others, causing a wrong slope estimation on start.
To compensate, assume an initial slope of 1, then progressively use the
estimated slope.
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>
Currently, a frame is available to the consumer as soon as it is pushed
by the producer (which can detect if the previous frame is skipped).
Notify the new frames (and frame skipped) via callbacks instead.
This paves the way to add (optional) buffering, which will introduce a
delay between the time when the frame is produced and the time it is
available to be consumed.
The current video buffer only stores one pending frame.
In order to add a new buffering feature, move this part to a separate
"frame buffer". Keep the video_buffer, which currently delegates all its
calls to the frame_buffer.
To fix a data race, commit 5caeab5f6d
called video_buffer_push() and video_buffer_consume() under the
v4l2_sink lock.
Instead, use the previous_skipped indication (initialized with video
buffer locked) to lock only for protecting the has_frame flag.
This enables the possibility for the video_buffer to notify new frames
via callbacks without lock inversion issues.
The function sc_cond_timedwait() accepted a parameter representing the
max duration to wait, because it internally uses SDL_CondWaitTimeout().
Instead, accept a deadline, to be consistent with
pthread_cond_timedwait().
The v4l2_sink implementation directly read the internal video_buffer
field "pending_frame_consumed", which is protected by the internal
video_buffer mutex. But this mutex was not locked, so reads were racy.
Lock using the v4l2_sink mutex in addition, and use a separate field to
avoid depending on the video_buffer internal data.
Commit 21d206f360 added mutex assertions.
However, the "locker" variable to trace the locker thread id was read
and written by several threads without any protection, so it was racy.
Reported by TSAN.
The options --no-display and --no-control are independent.
The controller was not initialized when no display was requested,
because it was assumed that no control could occur without display. But
that's not true (anymore): for example, it is possible to pass
--turn-screen-off.
Fixes#2426 <https://github.com/Genymobile/scrcpy/issues/2426>
Mouse motion events were forwarded as soon as any mouse button was
pressed.
Instead, only consider left-click (and also middle-click and right-click
if --forward-all-clicks is enabled).
Change the default push target from /sdcard/ to /sdcard/Download/.
Pushing to the root of /sdcard/ is not very convenient, many apps do not
expose its content directly.
It can still be changed by --push-target.
PR #2384 <https://github.com/Genymobile/scrcpy/pull/2384>
When removing the black borders (by double-clicking on them, or by
pressing MOD+w), the window is resized to fit the device screen, but its
top-left position was left unchanged.
Instead, move the window so that the new window area is at the center of
the old window area.
Refs #2387 <https://github.com/Genymobile/scrcpy/issues/2387>
It should not be necessary, since screen_render() is called just after
on SDL_WINDOWEVENT_EXPOSED, but in practice the window content might not
be correctly displayed on restored if a rotation occurred while
minimized.
Note that calling screen_render() twice in a row on
SDL_WINDOWEVENT_EXPOSED also "fixes" the issue.
From FFmpeg/doc/APIchanges:
2021-03-17 - f7db77bd87 - lavc 58.133.100 - codec.h
Deprecated av_init_packet(). Once removed, sizeof(AVPacket) will
no longer be a part of the public ABI.
Refs #2302 <https://github.com/Genymobile/scrcpy/issues/2302>
From FFmpeg/doc/APIchanges:
2021-03-17 - f7db77bd87 - lavc 58.133.100 - codec.h
Deprecated av_init_packet(). Once removed, sizeof(AVPacket) will
no longer be a part of the public ABI.
Refs #2302 <https://github.com/Genymobile/scrcpy/issues/2302>
From FFmpeg/doc/APIchanges:
2021-03-17 - f7db77bd87 - lavc 58.133.100 - codec.h
Deprecated av_init_packet(). Once removed, sizeof(AVPacket) will
no longer be a part of the public ABI.
Refs #2302 <https://github.com/Genymobile/scrcpy/issues/2302>
From FFmpeg/doc/APIchanges:
2021-03-17 - f7db77bd87 - lavc 58.133.100 - codec.h
Deprecated av_init_packet(). Once removed, sizeof(AVPacket) will
no longer be a part of the public ABI.
Remove the has_pending boolean, which can be replaced by:
stream->pending != NULL
Refs #2302 <https://github.com/Genymobile/scrcpy/issues/2302>
The argument for option --lock-video-orientation has been made optional
by 5af9d0ee0f.
With getopt_long(), contrary to mandatory arguments, optional arguments
must be given with a '=':
--lock-video-orientation 2 # wrong, parse error
--lock-video-orientation=2 # correct
The input manager was partially initialized statically, but a call to
input_manager_init() was needed anyway, so initialize all the fields
from the "constructor".
This is consistent with the initialization of the other structs.
The frame can be unref immediately after it is pushed to the frame
sinks.
It was not really a memory leak because the frame was unref every time
by avcodec_receive_frame() (and freed on close), but a reference was
unnecessarily kept for too long.
Add a new mode to the --lock-video-orientation option, to lock the
initial orientation of the device.
This avoids to pass an explicit value (0, 1, 2 or 3) and think about
which is the right one.
