Skip to content

Added screen resolution and framerate support#191

Open
seungjunProgramming wants to merge 6 commits into
FD-:masterfrom
seungjunProgramming:master
Open

Added screen resolution and framerate support#191
seungjunProgramming wants to merge 6 commits into
FD-:masterfrom
seungjunProgramming:master

Conversation

@seungjunProgramming

@seungjunProgramming seungjunProgramming commented Dec 4, 2020

Copy link
Copy Markdown

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

@seungjunProgramming

Copy link
Copy Markdown
Author

reopened PR after making it simpler

@seungjunProgramming

Copy link
Copy Markdown
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)

@laolux laolux left a comment

Copy link
Copy Markdown

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

laolux commented Jul 28, 2021

Copy link
Copy Markdown

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
Copy Markdown
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
Copy Markdown

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

fduncanh commented Aug 12, 2021

Copy link
Copy Markdown

@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
Copy Markdown

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

@fduncanh

Copy link
Copy Markdown

@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