search

FD- / RPiPlay

An open-source AirPlay mirroring server for the Raspberry Pi. Supports iOS 9 and up.
GNU General Public License v3.0
4.94k stars 353 forks source link

fix incorrect/missing server plist entries in lib/raop_handlers.c; add API extension to set some #301

Closed fduncanh closed 2 years ago

fduncanh commented 2 years ago

This is a backport from UxPlay 1.42.

some of the plist entries in raop_handlers.h (get INFO) had incorrect type, and maxFPS was missing. Also added API extension that can be used to let users set certain server plist variables such as maxFPS.

fduncanh commented 2 years ago

see dsafa22's paper in https://github.com/FDH2/UxPlay/wiki/AirPlay2 or https://github.com/SteeBono/airplayreceiver/wiki/AirPlay2-Protocol for documentation.

maxFPS (default value 30 fps) is a very useful plist variable as it can be used to throttle the streaming rate from the client to less than 30fps.

Note FD- sets "overscanned" to 1; true default is 0, but left its default as FD-'s value; was there any reason for his choice?

FD- commented 2 years ago

I have no idea why I set overscanned to 0. Do these modifications actually change anything in the client device's behaviour?

fduncanh commented 2 years ago

@FD- (You actually set overscanned to 1 (true) in rpiplay).

but while it has an effect in reducing width_source x width_height below width x height (as reported in the apple 128 byte header to the PPS/SPS video frame),

example overscanned = true: raop_rtp_mirror width_source = 1296.000000 height_source = 972.000000 width = 1354.000000 height = 1016.000000

overscanned=false: raop_rtp_mirror width_source = 1440.000000 height_source = 1080.000000 width = 1440.000000 height = 1080.00000

strange that both height and height source get reduced below 1080.

This is with X11.

Now I have got uxplay working with RPi v4l2 GPU decoding, I was surprised to see that the reported height and height_source were the same (overscanned=true was being ignored) in framebuffer mode (kmssink) on Pi OS Lite without X, when I would have expected to see overscanned mode to have an effect at the screen edges.

To be frank, you can just close these PR's for my enhancements to RPiPlay which are backports from UxPlay . (The feature for setting network ports is simple, though, and could be useful to Pi users with a firewall; it's what got me started on this, and I finally understood the raop code enough to get it right.)

I wanted to keep the RAOP libraries on the two projects the same, but I have fixed various of dsafa22's obscure bugs that emerged from user issues, and gave up on the idea of keeping the same code in lib.

If I find major bugs that affect both codes I'll give you a PR, but no more enhancements.

I suspect that my updated version of the raop library could be transplanted back unchanged into RPiPlay but haven't tried the experiment.

Uxplay is aimed at Desktop users, not RPi. But because of Bullseye issues, RPi Users have started to drift in, and after I had some interactions with RPi OS and GStreamer devs, the solution for GStreamer v4l2 GPU support on RPi then emerged.

It would be interesting to have someone compare the v4l2/GStreamer results to what omx has been giving. I couldn't test omx on Buster with gstreamer since its omxh264dec plugin has been broken on RPi with a "wont fix" status for a while.

fduncanh commented 2 years ago

Features incorporated into UxPlay: no need to modify RPiPlay