Deprecate --lock-video-orientation in favor of a more general option
--capture-orientation, which supports all possible orientations
(0, 90, 180, 270, flip0, flip90, flip180, flip270), and a "locked" flag
via a '@' prefix.
All the old "locked video orientations" are supported:
- --lock-video-orientation -> --capture-orientation=@
- --lock-video-orientation=0 -> --capture-orientation=@0
- --lock-video-orientation=90 -> --capture-orientation=@90
- --lock-video-orientation=180 -> --capture-orientation=@180
- --lock-video-orientation=270 -> --capture-orientation=@270
In addition, --capture-orientation can rotate/flip the display without
locking, so that it follows the physical device rotation.
For example:
scrcpy --capture-orientation=flip90
always flips and rotates the capture by 90° clockwise.
The arguments are consistent with --orientation (which provides a
separate client-side orientation).
The server params were passed from the main thread to the server thread,
so a deep copy was performed in case the caller instance was destroyed.
But in practice, it only contains memory that lives until the end of the
program (command line arguments), so simply reference it. Several copies
of string fields were missing anyway.
It is better to disable Nagle's algorithm to avoid unnecessary latency
for control messages. (I'm not sure this has any impact for a local TCP
socket though.)
Many parsing and formatting C functions like strtof() and asprintf() are
locale-dependent. Forcing a C locale just for the conversions in a way
that works on all platforms is a mess.
In practice, this is not a problem, scrcpy always uses the C locale,
because it never calls:
setlocale(LC_ALL, "");
But the max-fps option should not depend on the locale configuration
anyway.
Since the value is parsed by the client in Java anyway, just forward the
string value as is.
Android accepts a float value, there is no reason to limit the option
to be an integer.
In particular, it allows to capture at a rate lower than 1 fps. For
example, to capture 1 frame every 5 seconds:
scrcpy --video-source=camera --max-fps=0.2
It was already possible to pass a float manually:
scrcpy --video-source=camera \
--video-codec-options=max-fps-to-encoder:float=0.2
But accepting a float directly for --max-fps is more convenient.
Refs <https://developer.android.com/reference/android/media/MediaFormat#KEY_MAX_FPS_TO_ENCODER>
By default, the audio source is initialized to SC_AUDIO_SOURCE_AUTO, and
is "resolved" only if audio is enabled.
But the server arguments were built assuming that the audio source was
never SC_AUDIO_SOURCE_AUTO (even with audio disabled), causing a crash.
Regression introduced by a10f8cd798.
Passing an unknown enum value to convert them to string would return
NULL without any error, possibly causing undefined behavior later.
Add assertions to catch such programming errors early.
In addition to --camera-size to specify an explicit size, make it
possible to select the camera size automatically, respecting the maximum
size (already used for display mirroring) and an aspect ratio.
For example, "scrcpy --video-source=camera" followed by:
- (no additional arguments)
: mirrors at the maximum size, any a-r
- -m1920
: only consider valid sizes having both dimensions not above 1920
- --camera-ar=4:3
: only consider valid sizes having an aspect ratio of 4:3 (+/- 10%)
- -m2048 --camera-ar=1.6
: only consider valid sizes having both dimensions not above 2048
and an aspect ratio of 1.6 (+/- 10%)
PR #4213 <https://github.com/Genymobile/scrcpy/pull/4213>
Co-authored-by: Simon Chan <1330321+yume-chan@users.noreply.github.com>
If --audio-source is not specified, select the default value
according to the video source:
- for display mirroring, use device audio by default;
- for camera mirroring, use microphone by default.
PR #4213 <https://github.com/Genymobile/scrcpy/pull/4213>
Some server parameters may depend on one another. For example,
audio_bit_rate is meaningless if audio is false.
But it is inconsistent to disable some parameters based on these
dependencies checks, but not others. Handling all dependencies between
parameters would add too much complexity for no benefit.
So just pass individual parameters independently.
PR #3978 <https://github.com/Genymobile/scrcpy/pull/3978>
On initial connection, scrcpy sent some device metadata:
- the device name (to be used as window title)
- the initial video size (before any frame or even SPS/PPS)
But it is better to provide the initial video size as part as the video
stream, so that it can be demuxed and exposed via AVCodecContext to
sinks.
This avoids to pass an explicit "initial frame size" for the screen, the
recorder and the v4l2 sink.
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>
