Closed mastastealth closed 2 years ago
Exactly which model iPad Pro? What linux or other system is running uxplay
It should be fixable with -s wxh for suitable w and h but you report it isn't
try changing the videosink "-vs .... " option.
try ... = gtksink, glimagesink, waylandsink, vaapisink, ximagesink, xvimagesink etc. (not all will work on your system)
(see README (Usage) or the manpage.)
I believe it's Gen 1? The 2015 12.9 (ML0N2LL/A). Running Kubuntu 21.10, I'm on an Nvidia card.
Swapping syncs worked, fwiw:
ximagesink
- fails
xvimagesink
- squishes (regardless of -s)
glimagesink
- Works! (without needing -s)
Thanks!
Its good it now works for you.
iPad Pro gen 1 11 inch should probably use
uxplay -s 2388x1668
As an aid to maintaining uxplay, please provide some more info.
I'd be interested to see what the uxplay -d (debug) terminal output says with and without this option. (try in both portrait and landscape orientations) (... is other options like -vs)
Stop uxplay just after the video starts, or capture to a file ( "uxplay -d .... >out 2>&1") as there is a lot of output with -d
Just after the initial setup, when mirroring starts you will see something like
raop_rtp_mirror accepting client
video packet header: 25 00 00 00 01 00 16 01 2b 15 d4 ac 1d 07 02 00
payload_size = 37, type = 1
begin video stream wxh = 1440x1080; source 1440x1080
raop_rtp_mirror width_source = 1440.000000 height_source = 1080.000000 width = 1440.000000 height = 1080.000000
raop_rtp_mirror sps size = 18
raop_rtp_mirror pps size = 4
Please report back with what this says. This won't depend on which videosink you use, but see if -s 2388x1668 helps for xvimagesink.
Also try -s 1168x2388 (portrait) and -s 584x1194 (portrait) and -s 1194x584 (landscape) just to see what happens with xvimagesink (and glimagesink)
thanks.
Let's see, so I believe xvimagesink
is my default so:
uxplay -s 2388x1668 -d | Landscape
video packet header: 26 00 00 00 01 00 16 01 a7 56 df 68 bc 1b 02 00
begin video stream wxh = 2226x1668; source 2226x1668
raop_rtp_mirror width_source = 2226.000000 height_source = 1668.000000 width = 2226.000000 height = 1668.000000
raop_rtp_mirror sps size = 19
raop_rtp_mirror pps size = 4
uxplay -s 2388x1668 -d | Portrait
video packet header: 26 00 00 00 01 00 16 01 a7 56 df 68 bc 1b 02 00
begin video stream wxh = 2226x1668; source 2226x1668
raop_rtp_mirror width_source = 2226.000000 height_source = 1668.000000 width = 2226.000000 height = 1668.000000
raop_rtp_mirror sps size = 19
raop_rtp_mirror pps size = 4
uxplay -s 1194x584 -d | Landscape
video packet header: 24 00 00 00 01 00 56 01 73 28 43 1f 59 22 02 00
begin video stream wxh = 780x584; source 780x584
raop_rtp_mirror width_source = 780.000000 height_source = 584.000000 width = 780.000000 height = 584.000000
raop_rtp_mirror sps size = 17
raop_rtp_mirror pps size = 4
video packet header: d2 1f 00 00 00 10 00 00 26 70 6b 53 47 22 02 00
None of these help fix the ratio issue, I'll report back tomorrow with more and then the same set on glimagesink
. :+1:
@mastastealth
Did the -s wxh option affect the size of the mirror window, even if it didnt fix the aspect ratio?
if you change the shape of the mirror window do the incorrect aspect ratio (xvimagesink) stay? (I would think it does).
If you could capture the beginning part of the output for uxplay -d and post it here (you can add the file as a .txt file to the issues page) it would be useful to see what the iPad Pro reports about itself during the setup process.
(See the debug output in the uxplay Wiki)
@fduncanh Yes, the size of the mirror window did change despite busted ratio, it just letter boxes as I try to resize it. glimagesink
similarly works on resizes with letterbox. I've attached the uxplay -d
outputs with both sinks.
When I Airplay from an early gen iPad Pro, my desktop image is squished into this:
Altering the resolution via the
-s
flag doesn't seem to affect this ratio, is there a way to correct this?