On Android 14, a separate process was spawn on every display mode
request (to turn the screen off or on).
But starting a java process takes time (a few hundred milliseconds),
causing a noticeable latency between the request to turn the screen off
(MOD+o) or on (MOD+Shift+o) and the actual power mode change.
To minimize this latency, keep the process alive between requests, so
that only the first one will have to spawn the process.
It would be possible to spawn the process in advance, so that even the
first request would be immediate, but any problem would impact all
Android 14 users even without using the "turn screen off" feature.
PR #4446 <https://github.com/Genymobile/scrcpy/pull/4446>
The server was unlinked (removed) just after it started.
In order to execute a new process using the server jarfile at any time
(typically to set the display power mode from another process), keep the
file until the server closes.
When scrcpy is run, a server is pushed to
/data/local/tmp/scrcpy-server.jar.
Running simultaneous scrcpy instances on the same device was not a
problem, because the file was unlinked (removed) almost immediately once
it started, avoiding any conflicts.
In order to support executing new process using the scrcpy-server.jar at
any time (to change the display power mode from a separate process), the
server file must not be unlinked, so using different names are necessary
to avoid conflicts.
Reuse the scid mechanism already used for generating device socket
names.
Refs 4315be164823d2c8fc44b475b52af79bfee98ff1
Refs 439a1fd4ed3d7ada4c5098a6d52893dd4e87082a
Add an option to store the orientation to apply in a recorded file.
Only rotations are supported (not flip), and most players correctly
handle it only for MP4 files (not MKV files).
For consistency with the new --display-orientation option, express the
--lock-video-orientation in degrees clockwise:
* --lock-video-orientation=0 -> --lock-video-orientation=0
* --lock-video-orientation=3 -> --lock-video-orientation=90
* --lock-video-orientation=2 -> --lock-video-orientation=180
* --lock-video-orientation=1 -> --lock-video-orientation=270
On Android 14 (Pixel 8), a device rotation while the camera app was
running resulted in an incorrect capture.
Destroying and recreating the display fixes the issue.
Audio PTS are retrieved by AudioRecord.getTimestamp(), so they do not
necessarily exactly match the number of samples (this allows to take
drift and lag into account).
As a consequence, two consecutive timestamps in microseconds may
sometimes end up within the same millisecond, causing the warning. This
is particularly true for the Matroska muxer which uses a timebase of
1/1000 (1 ms precision).
Since this is "expected", lower the log level from warning to debug.
If the difference of PTS between two consecutive blocks of audio is less
than 1 sample, then it will be considered as non-increasing by FFmpeg
muxers having a time_base of 1/sample_rate.
Increase the PTS by 1 sample instead.
If several reads are performed for a single captured audio block (e.g.
if the read size is smaller than the captured block), then the provided
timestamp was the same for all packets.
Recompute the timestamp for each of them.
In practice, the system captures audio samples by blocks of 1024
samples.
Remplace the hardcoded value of 5 milliseconds (240 samples), and let
AudioRecord fill the input buffer provided by MediaCodec (or by
AudioRawRecorder), with a maximum size of 1024 samples (just in case).
FLAC is not low latency: the default encoder produces blocks of 4096
samples, which represent ~85.333ms.
Increase the audio buffer by default so that audio playback works.
Clipboard synchronization requires SDL_INIT_VIDEO, so always initialize
the video subsystem, even if --no-video or --no-video-playback is
passed.
Refs caf594c90ef1b71ed844b2a9b42c3b3371215d6f
Fixes#4418 <https://github.com/Genymobile/scrcpy/issues/4418>
It is incorret to ever call:
streamer.writeDisableStream(...);
after:
streamer.writeAudioHeader();
Move the try-catch block so that it can never happen.
Some devices may provide invalid ranges, causing an
IllegalArgumentException "lower must be less than or equal to upper".
Catch the exception to list the cameras anyway.
Refs #4403 <https://github.com/Genymobile/scrcpy/issues/4403>
Interrupting async processors may require to shutdown the connection to
wake up blocking calls.
Therefore, shutdown the connection first, then join the threads, then
close the connection.
Refs commit 9c08eb79cb7941848882cb908cefee9933450de5
