Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Added screen resolution and framerate support #191

Open
wants to merge 6 commits into
base: master
Choose a base branch
from

Conversation

seungjunProgramming
Copy link

@seungjunProgramming seungjunProgramming commented Dec 4, 2020

Added screen resolution and framerate support
-x: screen width
-y: screen height
-z: framerate

@seungjunProgramming
Copy link
Author

reopened PR after making it simpler

@seungjunProgramming
Copy link
Author

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)

Copy link

@laolux laolux left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Spurious ß in line 400, prevents building.
Just remove it and everything works fine.

@laolux
Copy link

laolux commented Jul 28, 2021

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 :-)

@seungjunProgramming
Copy link
Author

@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!

@fduncanh
Copy link

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?

@fduncanh
Copy link

fduncanh commented Aug 12, 2021

@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.

@samascience
Copy link

can we use two screens if we compile this on intel motherboard with two monitor support ?

@fduncanh
Copy link

@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?)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

5 participants