Open seungjunProgramming opened 3 years ago
reopened PR after making it simpler
Updated to support -z parm. which is used to change frame rate. (Not tested Yet, but will work since it's made the same way with -x, -y)
This PR works great for me. Rebased to master without issues. Only complaint: It is not documented in the help. If you want me to I can try to add that, but I am not sure of how to add a commit to this PR.
Anyways, thanks for the great work, it actually does fix my issue #255, so it makes me very happy :-)
@laolux Oh, I actually didn't know there was a typo in the commit. Thank you! Also, I will check the help too. Thank you so much!
does changing the framerate from 60-.0 to anything else actually change anything? setting it to 1 fps doesnt seen to give anything different to 60 fps....
changing x and y definitely changes things usefully, but what about the (norminal) framerate setting
Seungjun, did you actually see any changes in how the video is rendered when this "z" setting is changed?
@seungjunProgramming the framerate setting you were using was broken in the current rpiplay. I investigated, and found it wasn't working because it was mistranscribed from the original binary plist file taken from an Apple TV two years ago, that was used in earlier versions of rpiplay. "refreshRate" should not be a real 1.0/60.0 but should be an integer 60 (60 Hz). There was also a plist setting "maxFPS" = 30 (30fps) that was completely missed out by mistake in the transscription. That one tells the the AirPlay client not to send video at more than maxFPS fps, and when properly included in rpiplay does indeed slow down the video stream. The default maxFPS is one half of the default refresh rate.
I added the ability to set refreshRate and maxFPS as well as widthPixel and heighPixel to the proposed API change PR #257
I also implemented them in an updated UxPlay https://github.com/FDH2/UxPlay which is a gstreamer-only (no rpi) fork of RPiPlay.
These settings don't affect rpiplay directly, but they are sent to the iPad client when it request details about the Airplay server (this is why Apples's plist format is needed) Based on what it was told, it seems that the client decides the pixel width height and framerate of the streamed video it sends.
can we use two screens if we compile this on intel motherboard with two monitor support ?
@samascience post a new issue. This is a very old thread. (answer to your question: uxplay has no explicit control on which screen it is displayed, maybe the window manager can be used to specify this?)
Added screen resolution and framerate support -x: screen width -y: screen height -z: framerate