search

FDH2 / UxPlay

AirPlay Unix mirroring server
GNU General Public License v3.0
1.34k stars 72 forks source link

FPS drop with vertical orientation of the iOS client #246

Closed socketa4techx7 closed 6 months ago

socketa4techx7 commented 6 months ago

Hi, I'm trying to build a CarPC based on Uxplay.

Current setup: RPi 4B, 1024x600 screen, 60 hz. iPhone 15 Pro, latest iOS.

During screen mirroring with WiFi, on the horizontally-oriented YouTube app FPS can reach 60fps (according both "visual 60fps test videos" and -FPSData results). But with iPhone vertical orientation, I see significant quality drops and freezes.

I assumed that it may be related to real-time decoding which RPi has to do to rotate screen, but it seems to me that rPi is not doing anything heavy at this moment (Load Average < 0.8, small CPU load percentage on the uxplay process, etc.).

Inputs:

What would you recommend?

fduncanh commented 6 months ago

bit 8 of features (server supports screenrotations) is currently turned on in dnssdint.h ...E6 = 1110 0110

https://openairplay.github.io/airplay-spec/features.html

define FEATURES_1 "0x5A7FFEE6" / first 32 bits of features, with bit 27 ("supports legacy pairing") ON /

You could experiment with switching it off. (..E6 -> ..66) I dont know what would happen. Maybe ioS would do the work? This was set in the RPiPlay past, or perhaps earlier. One could look at old RPiPlay code history on github.

or play with -s wxh (try 1080x1080?) I don't really know. I guess experiment with these things

socketa4techx7 commented 6 months ago

Finally I realized, that for some reasons hardware acceleration was broken on my system (gst-inspect-1.0 was saying that video4linux2 has only 3 plugins, and there were no decoders/encoders), so the whole pipeline was trying to process my rotated video without hw acceleration.

v4l2-ctl --list-devices didn't show me "bcm2835-codec-decode (platform:bcm2835-codec)" devices.

I've fixed gstreamer plugins / kernel modules part on my rPi, and now it runs much smoothly.

Also, I'm not sure if -s 1200x1200@60 changed anything, but I don't see any negative impact of that option, so I'll keep it. It seems to me like modern iOS can ignore resolution information from server at all.

I think this topic can be closed, thank you!

fduncanh commented 6 months ago

-s wxh is the server telling the client not to send anything bigger than that.

The client decides what resolution to send