So far, scrcpy always resized the window whenever a frame with a new
size was received. However, with the upcoming "flex display" feature,
the size of the virtual display can change either on its own (e.g.,
due to app rotation) or as a result of a client window resize.
Track the cause of each resize and signal it in the session metadata.
Resize the window only if the change was not triggered by a client
request to prevent resize loops and stuttering.
After initialization or an explicit display resize, a specific display
event is expected and must be ignored to avoid triggering a capture
reset.
A capture reset should occur only when the display size changes
independently, for example on app rotation.
`DisplayMonitor` listens for system display events. Move the
event-handling logic into a separate class (`DisplayPropertiesTracker`),
as it will become more complex in the following commit.
Expose `CaptureControl` directly in `SurfaceCapture` to remove a layer
of indirection (`CaptureListener`).
This will make it easier to expose other methods without boilerplate.
When the virtual display size is not aligned, a resize filter may be
inserted to compensate for small dimension mismatches, increasing
processing and resulting in a blurry image.
PR #6771 <https://github.com/Genymobile/scrcpy/pull/6771>
`DisplayMonitor` previously only triggered a capture reset when the
display size changed. In most cases, rotation also changes dimensions,
so the behavior was correct… except for square displays where width and
height remain unchanged.
However, rotation still requires a capture reset even when dimensions do
not change, to ensure the orientation filter is applied so virtual
displays are rendered correctly.
To reproduce the issue:
scrcpy --new-display=600x600 --start-app=com.android.settings
Then press Alt+r to rotate the Settings app.
PR #6770 <https://github.com/Genymobile/scrcpy/pull/6770>
Encoders require a minimum video size.
Use video capabilities to constrain a given size by the declared minimum
size of the selected encoder.
Contrary to the maximum size constraints (but like the alignment
constraint), use the same value in both directions for simplicity and so
that rotating the device does not change the shape of the video.
PR #6766 <https://github.com/Genymobile/scrcpy/pull/6766>
Encoders cannot encode at any resolution.
Use video capabilities to constrain a given size by the limits of the
selected encoder.
These video capabilities describe the range of supported widths and
heights, as well as the supported heights for a given width (and
vice-versa). Use this information to compute the maximum portrait size
and the maximum landscape size.
PR #6766 <https://github.com/Genymobile/scrcpy/pull/6766>
Group video constraints into a dedicated class. For now it only contains
the `alignment` field; additional constraints will be added in further
commits.
PR #6766 <https://github.com/Genymobile/scrcpy/pull/6766>
Previously, the size was scaled to fit the requested maximum size and
then aligned. If the maximum size was not a multiple of the alignment,
the resulting size was suboptimal as it preserved the aspect ratio less
accurately.
This also prepares for additional video constraints.
PR #6766 <https://github.com/Genymobile/scrcpy/pull/6766>
A mechanism was introduced to retry capture at a lower resolution to
support devices unable to encode at the device screen resolution.
While useful, this approach is inherently limited and will not be able
to handle the dynamic resizing required for resizable virtual displays.
Disable this mechanism entirely. Further commits will add support for
adjusting the size in advance according to video encoder capabilities.
Refs #2947 <https://github.com/Genymobile/scrcpy/pull/2947>
PR #6766 <https://github.com/Genymobile/scrcpy/pull/6766>
Add --min-size-alignment to force a minimal size alignment.
This is a power-of-2 value (1, 2, 4, 8 or 16) that the video width and
height must be multiples of.
The actual alignment will be the maximum of this value and the video
codec's alignment requirement.
PR #6746 <https://github.com/Genymobile/scrcpy/pull/6746>
Only an AudioCaptureException should disable the audio stream without
making scrcpy exit (it is not a fatal error).
A ConfigurationException or any other Throwable must be considered a
fatal error.
BEFORE AFTER
AudioCaptureException: non-fatal non-fatal
ConfigurationException: fatal fatal
any other Throwable: non-fatal fatal
Refs #6600 comment <https://github.com/Genymobile/scrcpy/issues/6600#issuecomment-3744934826>
Replace "fps=[15, 30, 60]" with "fps={15, 30, 60}".
The default toString() implementation for a SortedSet uses '[]', but
it is more correct to use '{}' to denote a set.
PR #6243 <https://github.com/Genymobile/scrcpy/pull/6243>
Introduce a new packet type, a "session" packet, containing metadata
about the encoding session. It is used only for the video stream and
currently includes the video resolution.
For illustration, here is a sequence of packets on the video stream:
device rotation
v
CODEC | SESSION | MEDIA | MEDIA | … | SESSION | MEDIA | MEDIA | …
1920x1080 <-----------------> 1080x1920 <------------------
encoding session 1 encoding session 2
This metadata is not strictly necessary, since the video resolution can
be determined after decoding. However, it allows detection of cases
where the encoder does not respect the requested size (and logs a
warning), even without decoding (e.g., when there is no video playback).
Additional metadata could be added later if necessary, for example the
actual device rotation.
Refs #5918 <https://github.com/Genymobile/scrcpy/pull/5918>
Refs #5894 <https://github.com/Genymobile/scrcpy/pull/5894>
PR #6159 <https://github.com/Genymobile/scrcpy/pull/6159>
Co-authored-by: gz0119 <liyong2@4399.com>
The stream metadata will contain both:
- the codec ID at the start of the stream
- the session metadata (video width and height) at the start of each
"session" (typically on rotation)
PR #6159 <https://github.com/Genymobile/scrcpy/pull/6159>
