Display streaming freezes in phone standby

[SamuelBlickle]

When my S24+ goes into standby (aka enables the always on display), the display streaming to my PC freezes after a few seconds. If I right-click to wake up the display again, the phone physically turns on again and receives all inputs regularly, but the fps on the PC stay at 0 and the video stream remains frozen.

This does not happen if I use the c2.android.avc.encoder instead of the default c2.exynos.h264.encoder (but the android encoder is very laggy in comparison).

If I let scrcpy record the session as a video in the background and watch it afterwards, the recorded video is never frozen but continuously up-to-date.

adb logs show nothing of interest, neither the console output.

Environment

• OS: Windows, macOS
• Scrcpy version: 2.4, 2.6.1
• Device model: Samsung S24+
• Android version: 14, stock

[rom1v]

the phone physically turns on again and receives all inputs regularly, but the fps on the PC stay at 0 and the video stream remains frozen.

If I let scrcpy record the session as a video in the background and watch it afterwards, the recorded video is never frozen but continuously up-to-date.

Weird, I can't explain how this is possible.

At first, I assumed that in "standby" mode, MediaCodec stopped producing frames (that would explain the freeze), but on wake up, if your recording is ok, then the frames are sent to the client which should display them (even if most of them are skipped). 🤔

[SamuelBlickle]

Weird, I can't explain how this is possible.

Want me to make it a bit more weird? No problem:

Recently I've discovered that the mirroring with the default encoder only freezes, when using --no-audio. Connecting without this parameter results in perfectly normal scrcpy behaviour.

[rom1v]

Looks like an encoder issue then :)

--no-audio fixing video capture was already reported for some devices (see #4639 (comment) #3859 (comment)), but it these cases video initially did not work at all.

[SamuelBlickle]

Yeah but this time it seems to be exactly the other way round. NOT using --no-audio fixing video capture here...

[rom1v]

Ah yeah, that's weird. 😄