Mac client running Sequoia 15.2 (seen on M2/M3) no longer sends NTP time signal: use options "-vsync no -reset 0 " as workaround (was: Incorrect ntp_time (uses client uptime) prevents screen sharing)

[JJatOracle]

Hello!

I'm trying to use UxPlay to screen-mirror from a Macbook. On the same network, wired or wireless, when using Ubuntu (1.68 via apt) or Void Linux (1.71.1 via xbps) as the server, with an M3 Macbook Pro as the client, it fails with this error:

*** ERROR: *** invalid ntp_time < gst_video_pipeline_base_time
62.846508 ntp_time
1735850117.064202 base_time

The ntp_time listed is always the uptime of my client device, which is a 2023 M3 Macbook Pro (Sequoia 15.2).

Strangely, when using Linux Mint (1.46! via apt), mirroring works just fine from the same macbook. Even more strangely, when sharing a screen from my 2017 Macbook Air (Monterey 12.7.6) to those devices, mirroring works fine on all 3, leading me to suspect it's not a network issue; actually it seems similar to this issue. Is there some change to the protocol for AirPlay that would produce incompatible behavior, or some reason the older version seemed to be working fine?

I would be happy to provide more details as needed. Attached are uxplay -d debug output when connecting with the M3 mac and the 2017 Air:

debug_2017air.txt
debug_m3.txt

[fduncanh]

mirroring a macbook M2 client running Sequoia 15.1.1 on current UxPlay-github (essentially same as 1.71.1) seems to work fine on Ubuntu-24.04.1. Build 1.71.1 or (1.70) or guthub latest on Ubuntu. (There was GStreamer change in gstreamer-1.24.0 that was only seen after Ubuntu-24.04 was released that gave a possibly similar error.)

• Since you are mirroring a mac (presumably not to watch videos?) maybe using "uxplay -vsync no" will hide the problem, as the client ntptime is then not used for audio-video synchronizing.

Its possible there is regression between 1.70 and 1.71 (one such regression already got fixed in 1.71.1). This is because 1.71 adds a large amount of new code (for HLS streaming) that was developed from code earlier then 1.69, without the h265 code introduced in 1.70. So its possible that some fix in 1.70 was accidentally removed when the new code was merged. both 1.70 and 1.71 involved major new features (h265 and hls suppor,t respectively) which were developed in parallel.

It would be interesting if you could test uxplay-1.70. get the code here: https://github.com/FDH2/UxPlay/releases/tag/v1.70

[JJatOracle]

Running uxplay with -vsync no does seem like a viable workaround! With that flag, I can stream from Sequoia 15.2 to my macbook air running UxPlay 1.71 on Monterey 12.7.6.

I've checked out the code but haven't had the time yet to satisfy all the build dependencies for CMake. I'll post back here when I can build and compare versions! Thank you for the guidance.

[JJatOracle]

I was incorrect, it looks like this issue is not a regression, just a bug / feature mismatch: I can't cast from this M3 to any other device running uxplay except on 1.71.1, and that only when using -vsync no. I'll update with more results of testing when I have that prepared.

I've updated the title of this Issue to better reflect the nature of the bug.

[fduncanh]

Uxplay-1.70 : introduces support for h265 (4K) video with -h265 option https://github.com/FDH2/UxPlay/releases/tag/v1.70

UxPlay-1.71.1 introduces support for HLS live streaming (YouTube videos) https://github.com/FDH2/UxPlay/releases/tag/v1.71.1

can you confirm that 1.71.1 works (but only with -nosync) but 1.70 does not (this is very strange, and if true is an important clue).

We don't have an M3 mac for testing yet. Can you post uxplay -d output showing the failure ?

When the M2 mac came out, they added some more initial video codec stuff which only became apparent when we were able to test using an M2 mac client. It would be good to rule out such changes. The full uxplay -d output with an M3 client could help check for such changes.

[JJatOracle]

I took an hour or so to test out AirPlay mirroring with combinations of setups.
I've attached my test results. Please let me know if you'd like to see more data or more details! (E.g. gstreamer settings)

Testing methods

I started a unique uxplay -d process for each line in this table. Outputs from those are attached.

On each client macbook, I simply used the "Screen Mirroring" tool available in the system taskbar in the top-right of the screen, and shared a browser video with a youtube video.

Client machines

• M3 Mac, running Sequoia 15.2
• M1 Mac, running Sonoma 14.7.1
• 2017 Macbook Air, running Monterey 12.7.6

Host machines

• Dell Inspiron 3000 netbook, running Void Linux, with UxPlay 1.71 (installed via XBPS)
• AM4 desktop PC, running Ubuntu, with UxPlay 1.68 (installed via APT)
• AM4 desktop PC, running Ubuntu, with UxPlay 1.71 and 1.70 (each built locally via Nix)

Connectivity

I connected to all machines via wired ethernet on the same switch. I also connected to the netbook using wifi.

Test results

Client (Machine/OS)	Host (Machine/OS)	Host UxPlay Version	Settings used	Medium	Result	uxplay -d log
M3 Mac / Sequoia 15.2	Dell netbook / Void Linux	1.71	uxplay -d	Wifi	No video, mirroring session quits after a few seconds	debug_m3_void.txt
M3 Mac / Sequoia 15.2	Dell netbook / Void Linux	1.71	uxplay -d -vsync no -as 0	Wifi	Video, but stops after 10s	debug_m3_void_vsync_no.txt
M1 Mac / Sonoma 14.7.1	Dell netbook / Void Linux	1.71	uxplay -d	Wifi	Video and audio are stable	debug_m1_void.txt
2017 Mac / Monterey 12.7.6	Dell netbook / Void Linux	1.71	uxplay -d	Wifi	Video failed to stream on my first try, but were stable on all other attempts (Weirdly, video and audio CONTINUED after I stopped it on the client!)	debug_air_void.txt
---	---	---	---	---	---	---
M3 Mac / Sequoia 15.2	Dell netbook / Void Linux	1.71	uxplay -d	Wired Internet	No video, mirroring session quits after a few seconds	debug_m3_wired_void.txt
M3 Mac / Sequoia 15.2	Dell netbook / Void Linux	1.71	uxplay -d -vsync no	Wired Internet	Video and audio, but stops after 10s	debug_m3_wired_void_vsync_no.txt
M3 Mac / Sequoia 15.2	Dell netbook / Void Linux	1.71	uxplay -d -vsync no -as 0	Wired Internet	Video, but stops after 10s	debug_m3_wired_void_vsync_no_as_0.txt
M1 Mac / Sonoma 14.7.1	Dell netbook / Void Linux	1.71	uxplay -d	Wired Internet	Video and audio are stable	debug_m1_wired_void.txt
2017 Mac / Monterey 12.7.6	Dell netbook / Void Linux	1.71	uxplay -d	Wired Internet	Video and audio are stable (Weirdly, video and audio CONTINUED after I stopped it on the client!)	debug_air_wired_void.txt
---	---	---	---	---	---	---
M3 Mac / Sequoia 15.2	AM4 Desktop / Ubuntu	1.68	uxplay -d	Wired Internet	No video, audio worked for just a second, quits after a few seconds	debug_m3_ubuntu_68.txt
M3 Mac / Sequoia 15.2	AM4 Desktop / Ubuntu	1.68	uxplay -d -vsync no	Wired Internet	Video and audio, but stops after 10s	debug_m3_ubuntu_68_vsync_no.txt
M3 Mac / Sequoia 15.2	AM4 Desktop / Ubuntu	1.68	uxplay -d -vsync no -as 0	Wired Internet	Video, but stops after 10s	debug_m3_ubuntu_68_vsync_no_as_0.txt
M1 Mac / Sonoma 14.7.1	AM4 Desktop / Ubuntu	1.68	uxplay -d	Wired Internet	Video and audio are stable	debug_m1_ubuntu_68.txt
2017 Mac / Monterey 12.7.6	AM4 Desktop / Ubuntu	1.68	uxplay -d	Wired Internet	Video and audio are stable	debug_air_ubuntu_68.txt
---	---	---	---	---	---	---
M3 Mac / Sequoia 15.2	AM4 Desktop / Ubuntu	1.71	uxplay -d	Wired Internet	No video, audio worked for just a second, quits after a few seconds	debug_m3_ubuntu_71.txt
M3 Mac / Sequoia 15.2	AM4 Desktop / Ubuntu	1.71	uxplay -d -vsync no	Wired Internet	Video and audio, but stops after 10s	debug_m3_ubuntu_71_vsync_no.txt
M3 Mac / Sequoia 15.2	AM4 Desktop / Ubuntu	1.71	uxplay -d -vsync no -as 0	Wired Internet	Video, but stops after 10s	debug_m3_ubuntu_71_vsync_no_as_0.txt
M3 Mac / Sequoia 15.2	AM4 Desktop / Ubuntu	1.71	uxplay -d -vsync no -reset 0	Wired Internet	Video and audio are stable	debug_m3_ubuntu_71_vsync_no_reset_0.txt
M1 Mac / Sonoma 14.7.1	AM4 Desktop / Ubuntu	1.71	uxplay -d	Wired Internet	Video and audio are stable	debug_m1_ubuntu_71.txt
M1 Mac / Sonoma 14.7.1	AM4 Desktop / Ubuntu	1.71	uxplay -d -vsync no -reset 0	Wired Internet	Video and audio are stable	debug_m1_ubuntu_71_vsync_no_reset_0.txt
2017 Mac / Monterey 12.7.6	AM4 Desktop / Ubuntu	1.71	uxplay -d	Wired Internet	Video and audio are stable	debug_air_ubuntu_71.txt
---	---	---	---	---	---	---
M3 Mac / Sequoia 15.2	AM4 Desktop / Ubuntu	1.70	uxplay -d	Wired Internet	No video, session quits after 10s	debug_m3_ubuntu_70.txt
M3 Mac / Sequoia 15.2	AM4 Desktop / Ubuntu	1.70	uxplay -d -vsync no	Wired Internet	Video and audio, but stops after 10s	debug_m3_ubuntu_70_vsync_no.txt
M3 Mac / Sequoia 15.2	AM4 Desktop / Ubuntu	1.70	uxplay -d -vsync no -as 0	Wired Internet	Video, but stops after 10s	debug_m3_ubuntu_70_vsync_no_as_0.txt
M1 Mac / Sonoma 14.7.1	AM4 Desktop / Ubuntu	1.70	uxplay -d	Wired Internet	TBD	[log]
2017 Mac / Monterey 12.7.6	AM4 Desktop / Ubuntu	1.70	uxplay -d	Wired Internet	TBD	[log]

Notable Conclusions

ntp and timeout

On all of the M3 sessions, I was eventually kicked due to "timeout" after 5-10 seconds. The network time listed in the log is always the uptime of the M3 machine, whereas for both other clients the times matched the host's "now" timestamp.

Connection method

The results did not seem to change whether I used Wifi or wired ethernet.

MacOS bug

There seems to be a bug in Monterey 12.7.6 that continues sending AirPlay packets to the host after "disconnecting" the screen in MacOS. Is it possible there's a handshake that's being missed here? It doesn't seem to cause problems on the client end but was surprising to see.

[JJatOracle]

Ah, I've forgotten to try 1.70. I will add those test results!

[fduncanh]

• It looks like the source of the problem is that the timestamp (ts=...) on the video is not getting converted to unix time ("ntp=...") on the M3 mac, but is on the M1 mac.

• even with -vsync no, the ntp requests seem to fail.

• what happens with M3 client with the two options "-vsync no -reset 0"

m1 mac

raop_rtp audio: now = 1736787480.473528, ntp = 1736787480.521023, latency = -0.047495, rtp_time=280232517 seqnum = 25497
raop_rtp audio: now = 1736787480.483895, ntp = 1736787480.531907, latency = -0.048012, rtp_time=280232997 seqnum = 25498
raop_rtp audio: now = 1736787480.494426, ntp = 1736787480.542791, latency = -0.048365, rtp_time=280233477 seqnum = 25499
raop_rtp video: now = 1736787480.500986, ntp = 1736787480.545305, latency = -0.044319, ts = 288557.807167, 00 00 00 00 

m3 mac

raop_rtp audio: now = 1736788315.123153, ntp = 4025.350608, latency = 1736784289.772545, rtp_time=3594924795 seqnum = 56309
raop_rtp video: now = 1736788315.125362, ntp = 4025.373146, latency = 1736784289.752217, ts = 4025.373146, 00 00 00 00  h264
raop_rtp audio: now = 1736788315.132975, ntp = 4025.361492, latency = 1736784289.771483, rtp_time=3594925275 seqnum = 56310

[JJatOracle]

I've added those results to the table too. With -vsync no -reset 0, the stream is stable

[fduncanh]

OK : with -vsync = no, the ntp susbsystem is not in fact used for synchrnization of audio with video,

On the M3, ntp eventually fails, and when a failure is detected, after 5 consecutive failures (=15 sec) uxplay gives up on the client. the option -reset 0 means that the ntp failure is ignored. This will allow operation in "-vsync no" to continue.

The reason ntp is failing on the M3 needs to be tracked down.

• also, maybe -vsync no should trigger -reset 0 ? (as this mode does not use the ntp signals)??

[JJatOracle]

I would be happy to help :) I am not familiar yet with the uxplay codebase, but I would be happy to checkout and run individual commits until I can help more, if you do ever have a change or build with additional logging you'd like to try out. (I know that'd be a pretty tedious approach to debugging, sorry.)

[fduncanh]

• Comparing your M3 and M1 debug output, below the server sends a ntp time signal to the M1 client and the client responds.

• in the case of the M3 client, he client does not respond

Dont know why. Will test on an M2 client running sequoai 15.2 next week (can't do it before then)

Client identified as User-Agent: AirPlay/775.3.1
timing_rport = 50130
raop_ntp parse remote ip = 2601:0280:ca80:24d0:4c92:02a0:053c:c1c8
raop_ntp starting time
raop_ntp local timing port socket 31 port UDP 46125

raop_ntp send time type_t=82 packetlen = 32, now = 1736788443.934301
80 d2 00 07 00 00 00 00 00 00 00 00 00 00 00 00 
00 00 00 00 00 00 00 00 eb 2f c8 5b ef 2e 56 83 

<snip>

raop_ntp receive time type_t=83 packetlen = 32, now = 1736788443.935043 t1 = 289143.111446, t2 = 289143.111487
80 d3 00 07 00 00 00 00 eb 2f c8 5b ef 2e 56 83 
83 ae e7 f7 1c 87 b9 9d 83 ae e7 f7 1c 8a 69 7a 

raop_ntp sync correction = -1736499300823205311

[fduncanh]

Don't know why. Will test on an M2 client running Sequoia 15.2 next week (can't do it before then)

Tested on a macbook pro M2 running Sequoia 15.2: same issue.

• must be a change in Sequoia 15.2 (as opposed to a M2/M3 issue?) : I confirm that the macOS client does not respond to the NTP time request from uxplay. uxplay options -vsync no -reset 0 allow successful screen mirroring.

Not sure what to do. The reset purpose is so uxplay disconnects if the client has "disappeared". There are other ways to test for this (e.g. the client sends a video status report every second.)

The client does inform uxplay that it is using NTP time protocol, and running macOS 15.2, so this could be used to work around the issue, perhaps.

        <key>timingProtocol</key>
        <string>NTP</string>
        <key>osName</key>
        <string>macOS</string>
        <key>osBuildVersion</key>
        <string>24C101</string>
        <key>sourceVersion</key>
        <string>835.19.5</string>
        <key>timingPort</key>
        <integer>61384</integer>
        <key>isScreenMirroringSession</key>
        <true/>
        <key>osVersion</key>
        <string>15.2</string>

[thiccaxe]

Is it possible to wireshark an apple tv 3 to see how it behaves with 15.2?

[fduncanh]

Is it possible to wireshark an apple tv 3 to see how it behaves with 15.2?

could be. problem is encryption after pairing. I got wireshark working last year some time, but could only view the first setup request before that encryption. The NTP time request is afterwards.

Still I should check that 15.2 clients work with with apple tv 3. The issue with uxplay and 15.2 clients seems to be that the client just doesnt respond to the NTP request by uxplay on the UDP time channel. I dont know if this channel is encrypted, but think it is. Should check what channels the client transmits on.

#336

@connorh315 got a lot of the encryption support working, but didn't finish (I think he was motivated by using decryption for finding out why h265 wasn't working, but then we found out why before the decryption support was finished ....)

[Connor315]

Is it possible to wireshark an apple tv 3 to see how it behaves with 15.2?

could be. problem is encryption after pairing. I got wireshark working last year some time, but could only view the first setup request before that encryption. The NTP time request is afterwards.

Still I should check that 15.2 clients work with with apple tv 3. The issue with uxplay and 15.2 clients seems to be that the client just doesnt respond to the NTP request by uxplay on the UDP time channel. I dont know if this channel is encrypted, but think it is. Should check what channels the client transmits on.

#336

@Connor315 @connorh315 got a lot of the encryption support working, but didn't finish (I think he was motivated by using decryption for finding out why h265 wasn't working, but then we found out why before the decryption support was finished ....)

@fduncanh I think you @ the wrong person.
YES sorry, it was @connorh315 I meant...