@linkshell/mac 0.1.7 → 0.1.8
This diff represents the content of publicly available package versions that have been released to one of the supported registries. The information contained in this diff is provided for informational purposes only and reflects changes between package versions as they appear in their respective public registries.
- package/README.md +6 -4
- package/build/LinkShell.app.tar.gz +0 -0
- package/package.json +1 -1
package/README.md
CHANGED
|
@@ -32,8 +32,10 @@ thermal state and adaptation; standard receivers retain the 60/30 defaults. No v
|
|
|
32
32
|
cross JS. Display-link callbacks, texture mapping and GPU submission now run on a dedicated
|
|
33
33
|
iOS render thread; UIKit publishes small layout snapshots. This removes dependence on UI
|
|
34
34
|
event processing, without establishing a phone latency or sustained-frame-rate result.
|
|
35
|
-
The native module
|
|
36
|
-
|
|
35
|
+
The native module and this sender use M154; react-native-webrtc shares the same iOS framework.
|
|
36
|
+
HEVC is offered to capable native receivers only after the Mac's low-latency hardware encoder
|
|
37
|
+
passes an availability probe; other viewers keep H.264. Codec/extension support still depends
|
|
38
|
+
on the actual negotiation.
|
|
37
39
|
|
|
38
40
|
Failed media falls back to the host's H.264 byte stream. iOS first tries the standard WebView
|
|
39
41
|
receiver and then bypasses the bulk direct channel for that screen, using RPC. Android/Web
|
|
@@ -187,7 +189,7 @@ already, and stop if it is not rather than have the system ask.
|
|
|
187
189
|
| `flexfec-check.mjs` | A short functional check over its own loopback UDP proxy: 60 ms each way, every twentieth original video packet dropped. Checks real FlexFEC packet receipt, then successful video without FlexFEC when the test receiver declines it. `--json <file>` saves the evidence. No system network changes or latency claims. |
|
|
188
190
|
| `network-check.mjs` | A 48-second congestion/recovery scenario: an owned UDP proxy changes media capacity from 20 to 0.7 to 20 Mbps, with 10 ms propagation each way and a 200 ms router queue. Includes RTX/FEC in the budget. `--screen`, `--maxFps`, `--maxWidth`, `--app`, repeatable `--trial`, `--json`; passing proves traversal and decoding, not acceptable latency or iPhone performance. |
|
|
189
191
|
| `media-lab.mjs` | Loopback-only encrypted UDP experiment using the same capture, VT H.264 and native decoder. `--network` uses the congestion scenario above; `--no-ltr` checks recovery without acknowledged long-term references. Requires `--loopback --media-lab` in the helper. Not a remote transport. |
|
|
190
|
-
| `codec-check.mjs` | Encode-only H.264/HEVC hardware comparison with fixed `--fps`, `--bitrate`, `--maxWidth` and raw input bound `--pending`. No transport, decoder, picture-quality or display result. HEVC
|
|
192
|
+
| `codec-check.mjs` | Encode-only H.264/HEVC hardware comparison with fixed `--fps`, `--bitrate`, `--maxWidth` and raw input bound `--pending`. No transport, decoder, picture-quality or display result. Shipping HEVC additionally uses WebRTC and the shared VideoToolbox decoder. |
|
|
191
193
|
| `setup-shots.mjs` | The setup window drawn into PNG files in every state, light and dark, Chinese and English (24 of them, in `build/setup-shots` or the directory named), with nothing shown and nothing asked of the system. For looking at the window after changing it. |
|
|
192
194
|
| `app.mjs`, `h264.mjs`, `pointer-shapes.swift` | Shared by the above: opening the app, reading H.264, changing the pointer's picture. |
|
|
193
195
|
|
|
@@ -365,7 +367,7 @@ NACK/RTX. There is no SDP rewriting to pretend a viewer supports it. See M154's
|
|
|
365
367
|
[FEC sender creation](https://webrtc.googlesource.com/src/+/refs/branch-heads/8037/call/rtp_video_sender.cc).
|
|
366
368
|
|
|
367
369
|
Upstream [M124](https://webrtc.googlesource.com/src/+/refs/branch-heads/6367/media/engine/webrtc_video_engine.cc)
|
|
368
|
-
already exposes FlexFEC receive support unless explicitly disabled; the
|
|
370
|
+
already exposes FlexFEC receive support unless explicitly disabled; the native M154 receiver
|
|
369
371
|
and WKWebView still have to prove their capability in their actual answers. A clean network
|
|
370
372
|
can negotiate FlexFEC and send no repair packets, because M154's protection controller uses
|
|
371
373
|
loss and RTT to choose redundancy. The advertised `repair-window=10000000` is a required
|
|
Binary file
|
package/package.json
CHANGED