最新

我花了六年时间尝试构建一个电视频道服务器。重写了八次。Flask、FastAPI、FFmpeg、Gstreamer、命名管道。每个版本都变得更复杂，但没有一个能正常工作。 事实证明，我构建错了东西。我真正想要的是一个协议。 所以 tltv 就是这样的。一个频道是一个 ed25519 密钥对。你用它来签署你的元数据。你从任何你想要的地方提供 HLS 视频。你的公钥变成一个 tltv:// 地址，任何人都可以调入。 中继节点可以重新提供你的流，但它们不能修改它。它们会验证所有内容的签名。你可以移动服务器并保留你的频道，因为密钥是身份，而不是主机名。节点通过对等交换互相发现。没有中央注册中心。 命令行界面可能是了解我意思的最快方式： ```bash curl -fsSL timelooptv.org/install | sh tltv keygen tltv server test --name "my channel" -k TV*.key ``` 这是一个完全兼容的源服务器。纯 Go 语言，生成带有音频的 SMPTE 彩条，不需要 FFmpeg。一个二进制文件，大约 20MB 内存。 还有基于 Gstreamer 的完整服务器 (cathode)，一个 Web 观看器 (phosphor)，以及命令行界面中的桥接/中继服务器。所有内容都采用 MIT 许可证。 实时演示：[https://demo.timelooptv.org](https://demo.timelooptv.org) [https://github.com/tltv-org](https://github.com/tltv-org)

提交者在此，先简要介绍一下背景。我曾于 1998 年至 2001 年期间，独自设计了微软企业软件顾问 (ESA) 渠道架构。该模式将微软的企业授权渠道从基于利润的经销商结构转变为直接计费、顾问费结构。它于 2001 年 10 月作为 Licensing 6.0 的一部分推出，至今仍被微软在 2025 财年 10-K 报告中提及，距今已有二十四年。<p>本文将详细介绍最初的架构是什么样的，它为什么有效（在推出后的两年内，微软的批量授权承诺额几乎翻了三倍，从 19 亿美元增至 55 亿美元），以及为什么 2026 年的调整在结构上有所不同。2001 年的转型为合作伙伴提供了明确的顾问角色，并建立了可持续的经济模式。而 2026 年的转型则不然。<p>欢迎就架构、设计决策、哪些部分有效以及哪些部分我希望有所改进等问题进行提问，或者探讨它如何映射到相邻行业。保险经纪行业的并购目前正遵循类似的整合模式，这很有意思，因为在 1998 年设计 ESA 模型时，保险是我研究的两个行业之一。<p>如果需要对任何具体主张进行佐证，请指出来，我会提供第一手资料的引用。<p>Brendan