0 Fork 0

Files

T

AAA cdd503a98d feat: improve feedback and App lifecycle reliability (#404 )

Waiting feedback and tooltips now share consistent presentation lifecycles, while App shutdown and native-media operation failures stay within their owning session or output. This phase also consolidates the project standards and publishes searchable English/Chinese reader documentation alongside the homepage.

Validation: repository hygiene and Markdown links; TypeScript, 971 Web tests and production build; website/documentation build; Go tests, vet and Windows/Linux builds with Windows capture checks; desktop/mobile UI and documentation review. Linux race, container and three-platform packaging checks run in the release pipeline. Physical macOS/Linux capture and broader network coverage remain outside this acceptance.

The owner approved v1.4.0 publication. Existing empty-source, Windows URL-handler and public-invitation timeout reports remain tracked; this release makes no claim to resolve those device/network reports. The Windows capture-border request is next-phase work.

## Release notes

### 中文

这是一次以稳定性和交互一致性为重点的功能更新。等待与提示更有反馈，App 启动、原生分享和连接恢复的边界处理得到改善，使用与部署指南也有了统一的文档中心。

#### 新增与改进

- 欢迎语、等待短句和六类可轮换的标签页标题共用一致的显示规则。等待短句从一开始就出现，并在停留时轮换；明确的错误与操作提示保持固定。
- 房间准入等漫画采用更克制的小人物与循环动效。改进 tooltip 的定位与指向，减少对播放器的遮挡；状态、图标和文案保持相同含义。
- 新增中英文文档中心，提供搜索、手机目录、使用教程、问题排查与自部署指南。官网 FAQ 聚焦开始使用前的问题，详细排查统一进入文档中心。

#### 修复

- 使用 `--local` 启动不再清空已保存的 Piik 站点地址。
- 打开系统浏览器不再阻塞 App 的退出流程；改进临时公网邀请、终端和诊断导出在关闭时的清理及错误反馈。
- 单条原生媒体连接的操作失败不再被误判为整个会话的协议错误；重复停止分享保持幂等。
- 修复连接替换、转发停止和异常退出时的部分资源清理问题，避免迟到结果影响当前连接。
- Windows 原生采集中，单个输出的编码错误只结束对应输出；共享采集源本身的错误仍会结束分享。

#### 升级与已知边界

本次保持现有协议版本与配置格式。更新 App 或自托管 Server 后，重新打开页面即可使用对应的新界面。

个别设备的空窗口列表、Windows 浏览器启动异常，以及 Linux 编码输出的故障隔离仍在跟进。macOS/Linux 的物理采集和更广泛的公网网络场景仍需实机验证；本次不宣称这些问题已经解决，也不承诺所有网络都能直连。

### English

This feature update focuses on stability and consistent feedback. Waiting states are easier to follow, App startup and native sharing handle several failure cases more reliably, and the new documentation center brings usage and deployment guides together.

#### New and improved

- Welcome lines, waiting captions and six groups of rotating tab titles follow one presentation lifecycle. Waiting captions appear immediately and rotate while visible; actionable errors and instructions remain fixed.
- Room-admission comics use restrained characters and looping motion. Tooltips point more accurately to their controls and interfere less with the player, with consistent meanings across illustrations, icons and copy.
- A new English/Chinese documentation center includes search, mobile navigation, usage guides, troubleshooting and self-hosting. The homepage FAQ covers questions before getting started and links to the documentation for detailed help.

#### Fixes

- Starting with `--local` no longer clears a saved Piik site address.
- Opening the system browser no longer blocks App shutdown. Temporary public invitations, the terminal and diagnostic exports handle cleanup and exit errors more consistently.
- An operation failure on one native media connection no longer becomes a protocol failure for the entire session. Repeated stop-sharing requests are safe.
- Fixed cleanup cases during connection replacement, relay shutdown and unexpected exits, preventing late results from affecting the current connection.
- On Windows, an encoder failure for one native output stops that output only. A failure of the shared capture source still ends sharing.

#### Updating and known limits

Protocol versions and configuration formats are unchanged. After updating the App or your self-hosted Server, reopen the page to use its updated interface.

Empty source lists on some devices, Windows browser-launch failures and Linux output-failure isolation remain under investigation. Physical macOS/Linux capture and broader public-network coverage still need device testing; this update does not claim to resolve those cases or guarantee a direct connection on every network.

2026-09-16 13:13:06 +08:00

8.2 KiB

Raw Permalink Blame History

Native Sender And Shared-Encode Evidence

Reviewed: 2026-08-27
Scope: Windows capture, one hardware H.264 encoder, bounded WebRTC fanout
Status: historical evidence; obsolete sender implementation deleted

Current product scope is owned by media quality. ADR-0006 owns the stop line.

Conclusion

A native sender can plausibly capture and encode once while serving bounded independent WebRTC transports. Shared encoding can reduce capture/encode work; it cannot remove each child's RTP, congestion, retransmission, encryption, and network copy.

The retained measurements prove:

Pion can fan one encoded source into two independent transport bindings;
one WebCodecs encoder object fed two Browser sessions in a bounded fixture;
one Windows Graphics Capture/Media Foundation H.264 path used an adapter- bound hardware MFT with matching process/LUID VideoEncode activity; and
the product helper delivered H.264 video and process-tree audio to one Chrome Viewer.

It does not prove two-Viewer product fanout, heterogeneous congestion feedback, loss/retransmission correctness, audio synchronization, reconnect isolation, public networks, endurance, packaging, update/signing, cross-platform behavior, or distribution licensing. Native remains outside the current release.

Candidate Shape

The smallest measured Windows pipeline was:

opaque window target
  -> Windows Graphics Capture BGRA surface
  -> one D3D11 conversion to NV12
  -> one adapter-bound hardware Media Foundation H.264 encoder
  -> one generation-bound Go/Pion RTP source
  -> at most two independent PeerConnections

Each PeerConnection must keep independent ICE, DTLS-SRTP, SSRC/sequence/TWCC, pacing, RTCP, congestion, and retransmission state. PLI/FIR from any child may be coalesced into one shared SPS/PPS/IDR request, but a weak child's bitrate request cannot silently become a room-wide minimum policy. A third Viewer must wait under the same endpoint capacity as Web Hosts.

Local target identity, HWND/PID, process creation time, adapter/MFT identity, PCM, and hardware diagnostics never enter signaling. The helper revalidates the selected window/process before capture. There is no software, codec, monitor, or audio fallback hidden behind a hardware-only source choice.

Browser And Pion Fixtures

A stack of bounded fixtures established progressively narrower facts:

Gate	Retained result	Missing proof
One Pion RTP source, two bindings	Equivalent payload reached two transport-local SSRCs.	No encoder or Browser.
WebCodecs VP8, two Chrome receivers	One encoder object produced 120 outputs; both decoded.	Physical/hardware encoder identity.
12-second live bridge	360 inputs/outputs; both Viewers rendered 331 frames; queues remained bounded.	Product rooms/capture/audio.
Pion GCC plus negotiated RTX	Failed with unknown RTX SSRC.	Valid shared congestion/retransmission composition.
No-RTX replay	One leg recovered without disturbing the other.	Accurate retransmission-specific loss accounting.
Two-leg stock GCC	Both estimates happened to be 600 kbps; one shared reconfiguration and keyframe recovery succeeded.	Heterogeneous estimates and product policy.

The stock-GCC/RTX composition remains no-go. Do not replace it with a custom pacer, congestion controller, interceptor fork, SRTP, or private transport. No-RTX replay remains research-only because it can distort RTP/RTCP loss accounting.

Hardware Encoder Evidence

WebCodecs

Chrome accepted H.264 Annex-B 1280x720@30 with prefer-hardware and produced 360/360 frames, but Browser-process GPU samples showed no attributed VideoEncode activity. The emitted SPS was 42041f, not the requested codec string. This proves usable chunks and in-band recovery units, not hardware selection or exact WebRTC fmtp compatibility. VP8 prefer-hardware was rejected on the same Windows system.

Media Foundation Fixture

One MSVC/D3D11 fixture selected the NVIDIA H.264 Encoder MFT on an RTX 4070 SUPER by exact DXGI LUID, required hardware enumeration, D3D11 awareness, low-latency mode, CBR readback, 3 Mbps, a 60-frame GOP, and forced keyframes.

Measure	Retained result
Inputs / outputs	360 / 360
Recovery units	6 / 6 with Annex-B SPS, PPS, and IDR
Maximum in flight	1
Wall time	12.106 s
Input-to-output p95	11.575 ms
Process+adapter VideoEncode	45 samples; mean 2.949%, max 4.863%
Emitted profile	`42c01f`

The MFT was physically attributed by hardware-only activation, accepted device manager, exact process/LUID GPU engine, and output progress. Its 42c01f Constrained Baseline profile was absent from Pion's default exact mode-1 list, so the fixture correctly stopped before claiming transport interoperability. The later opt-in fixture registered that exact profile and proved one Browser loopback; it did not alter the wider stop line.

Product Helper Smoke

The Windows helper reuses the same encoder source with WGC capture and process-tree WASAPI loopback. One bounded run delivered 203 rendered 1280x720 frames and 500 Opus packets to a Chrome Viewer. The exact helper PID and adapter LUID matched nonzero VideoEncode. This is a one-Viewer functional proof, not a resource or product release claim.

Remaining Gates

Before native product consideration, one current-wire candidate must prove:

current room/Host authorization and source-generation cleanup;
exact emitted H.264 profile negotiation and unmodified Chrome, Edge, Firefox, and Safari decode/render;
two independent transports with one physical encoder and compatible source, codec, cadence, and rate requests;
correct PLI/FIR, NACK/RTX, TWCC, burst/sustained loss, and reconnect isolation;
process audio, A/V synchronization, source switch, pause, and failure;
bounded CPU/GPU, memory, latency, quality, upload, queues, and thermals under real games and public networks;
evaluation packaging followed by installer, signing, update, and recovery; and
project, dependency, H.264 patent, and distribution license decisions.

No native experiment may preserve an obsolete Piik wire, create another room/topology model, loosen endpoint capacity, or become production merely to make a diagnostic gate pass.

License Boundary

Pion is MIT and coder/websocket is ISC. The Windows APIs use installed hardware MFTs; vendor codec binaries are not redistributed. Direct NVENC would require a separate NVIDIA Video Codec SDK and redistribution review. H.264 patent and project licensing remain unresolved before executable distribution. No proprietary Oopz/Agora or GPL/AGPL code was copied.

8.2 KiB Raw Permalink Blame History