Skip to main content

SRS - AI如何让SRS 8支持原生Windows

· 13 分钟

SRS支持原生Windows，这是AI完成的一个超级大的功能，1.5万行代码，1天完成，关键没引入问题，没改坏现有代码。

什么是原生Windows？​

srs.exe使用MSVC编译，支持Windows x64，是一个控制台程序，不需要Cygwin，也不需要WSL。原生Windows版本，支持了所有现有协议和功能：

  • RTMP、RTMPS、HTTP-FLV、HTTP-TS、HTTPS、HLS（TS和fMP4）和DASH。
  • WebRTC WHIP和WHEP，以及AAC和Opus转码。
  • SRT，包括SRT转RTMP，还有RTSP和GB28181。
  • DVR、VOD、HTTP API、回调、Exporter、Edge和Forward。
  • 使用ffmpeg.exe的Ingest和Transcode。

还能用Visual Studio编译、运行和调试代码，甚至能单步调试State Threads的协程切换，这部分是汇编代码。

改了多少代码？​

如果只看直接的变更大概是1.5万行代码，最直接的是两个PullRequest：

  • ST#40：State Threads协程库支持原生Windows，0.5万行左右。
  • SRS#4787：SRS 8.0适配支持原生Windows，1万行左右。

如果看之前的准备工作，大概是12万行测试代码：

  • State Threads测试覆盖提升到96%，1万行左右。
  • SRS#4785：Perf性能分析与测试，1.6万行。
  • SRS#4780：OBS自动测试，0.6万行。
  • SRS#4772：Integration集成测试，7.8万行。
  • SRS#4746：基本功能测试，0.9万行。

实际上，即使是直接的变更的1.5万行代码，也绝大部分都是测试代码，如果只看非测试代码，只有不到3千行：

  • SRS：0.15万行，主要是srs_core_platform.cpp平台适配。
  • ST：0.12万行，主要是event.c、io.c和md_win64.asm平台适配。

这是为何AI可以持续工作一个晚上，以及几百个变更，也不会改坏代码：测试覆盖已经可以保证大概率不会有问题，AI改不坏，人类也改不坏了。当然，大概率可以是99.9%但不是100%。

花了多少成本？​

我是买的Claude的100美元月套餐，所以总成本就是100美元每个月，和人工成本相比，几乎可以忽略不计了。

但每次AI都会给我折算的Token的价值或成本。完成Windows这个功能分了两次，中间有一次凭证过期重启了下任务：

  • 第一次是152美元，完成了大概1/3任务，凭证过期了。
  • 重新登录，更新凭证后，继续做任务，大概花了226美元。

总共等价值370美元，消耗了我大概42%的周额度。

我经常会听到朋友说，跑一个任务就消耗光了额度。我想可能有几个原因：

  • 要用月套餐，不要用API。 比如，我月套餐100美元，换成API估计得花几千美元了。
  • 起码得换成100美元的月套餐，别用20美元的。 总想着1元钱做一个微信出来，空手套白狼的，咱成熟点。
  • 减少AI的工作量。 参考下srs-autopilot和srs-develop，其中使用了一些减少AI工作量的方法，比如代码和文档索引，使用subagent降低历史上下文，基于任务文件重启Agent减少窗口消耗。

即使是使用AI，也不是直接用聊天窗口，和AI说一句造个原子弹出来，第二天你就发现门口给你快递了一个造好的原子弹。我在我两周没搞定的ST，AI九小时全自动搞定了中分享过这些基本的工具和准备工作，供你参考。

我不想说我的工作流就很好，AI还在快速进步中，或许明年这时候，这些工具和工作流，有些就过时了。但我也不觉得明年这时候，你就可以一句话让AI造个原子弹出来。

是否是100%完美？​

明显不可能做到100%完美，即使是花足够多的时间，足够多的高级工程师，写出来的代码也不是100%没问题，何况AI在一天完成的工作呢。在Review AI代码过程中，也偶然会发现一些问题。

为了通过不完善的测试走捷径。 实现RTSP回调功能时，AI调用了on_client，然后马上调用on_disconnect，这明显不是正常逻辑，即使你不知道正常是什么，也知道这是不正常的。这种低级错误，是因为AI写的测试代码，没有验证协议的完整性，只验证了回调的结果，协议必须的中间步骤没考虑。一个不太完善的测试，AI就想到了一个"捷径"来让测试通过。这种问题当然是可以用AI自己纠正的，即使让另外一个AI来检查代码变更，而不考虑上下文，也可以发现这种逻辑错误。所以我改进了Skill，新增了一个audit的工作流，避免这种问题。

奇怪的冗余代码。 另外一个变更，代码是正确的，也没有缺陷，但是很奇怪的冗余代码。实际上只需要一次调用就可以，应该把后续的代码删除。但不删除也不会有问题，至少从测试上看也没问题。这种问题，似乎很难通过AI自我检查发现，或许随着模型越来越聪明，是可以纠正这种问题。但这种代码，人也可以一眼就看出问题来，要Review这种变更也不是难事。

让结果更好看的测试视频。 做性能优化时，AI最初是使用SRS的默认测试视频，也就是阿凡达那个视频，但那个是VBR的，而对性能分析而言，码率波动本来就会干扰性能结果，所以应该使用CBR。AI最初并没有发现这个问题，所以它自动优化代码后，报告提升了9%的性能。实际上换成CBR视频后，去掉码率波动，只有大概5%的性能提升。这算不算是AI夸大自己的业绩？我也不觉得AI未来可以解决这种问题，这是需要挺奇怪的冷门的行业知识，才可以避免这种问题。训练AI变成无所不知的神，也不是AI公司的目标，能解决绝大部分问题就挺好，这种冷门的边边角角可以让人帮AI解决，综合成本就很低了。

看起来有收益的坏设计。 AI做性能优化时，给出的一个方案，大概可以提升10%左右的并发，但实际上是个坑。因为它在Read时，触发缓存数据发送，只要是有经验的程序员，就可以知道是个坏的设计。深入和AI交流后，AI也认为这种性能优化是一种很奇怪的设计，不值得做，所以我撤销了这个修改。

你不用Windows？​

或许有些朋友说：我又不用Windows，这个功能对我也没啥用。我想，一个更有意思的问题是：从AI实现Windows这个任务中，你有什么启发呢？以下是我的感受。

当写代码不再重要，想法就会很重要。 想法就是取舍，取舍决定于价值观，即你觉得什么东西是值得的。我觉得做原生Windows是很值得，因为有大量的Windows程序员，并非每个人都可以负担起昂贵的Mac，也不是每个人都习惯使用Mac工具链。这些人就不值得支持咩？即使这些人不是流媒体服务器开发，他们可能只是做业务开发甚至运维，要用SRS就要用WSL也很麻烦了。可能只是调试或者测试下，如果能有原生Windows支持，那么使用SRS就会方便很多。举手之劳，方便他人，这怎么会不值得呢？如果值得只是方便自己，或者只看到自己能看懂的经济价值，我想你可能误解了值得的意义。

支持原生Windows是非常有挑战的事情，而我并不熟悉Windows。 即使最终只有3千行代码变更，那可是对ST和SRS做3千行代码变更啊，不是一个简单的事情。我一般在Linux下编程，平常也多使用Mac，算算已经十多年不用Windows了。如果我不是Windows专家，如何能纠正AI在Windows上犯的错误？如何避免AI引入问题？反过来说，如果AI只能干我所擅长的事情，那AI会有很大的局限性。我觉得有趣的是，AI可以帮我干我也不擅长的事情，但我还有办法能交付高质量的结果，同时获得长进。在这个过程中，我发现AI已经不是助手，而是一个同伴，或许它和我很不相同，甚至都不是一个人类同伴，但可以一起工作，交付超越个人能力的高质量的结果，这个或许更有趣。

这么难的Windows都支持了，你觉得其他问题还远嘛？ 我回首看之前列出的SRS的那些重要缺陷，似乎都只是一个晚上的AI工作量，或许有些难一点吧，那就三个晚上。

春宵一刻值千金，当AI替你通宵达旦，或许你会感到些许恐慌。

应该恐慌什么？​

当AI干了我的工作，走了我以前走的路，我以后的路该怎么走？我是不是应该有职业焦虑？

确实，我两年前还挺焦虑，看着AI写的代码越来越好，害怕自己以后都没代码可以写了。现在我倒越来越不焦虑，因为已经接受了无代码可写了。当死亡到来，除了接纳，你还能怎样？诈尸么。但我真的不在乎是不是能自己敲出来代码，也没有功夫顾影自怜自怨自艾，因为很多有趣的事情还在发生。即使临近死亡，也可以抽身事外，看看自己飘向何方。

实际上，当我逐渐用AI管理这个开源项目和社区，我也发觉了一些更有趣的机会，即使AI把所有的活儿都干了，我还是可以干点别的：

  • 写文章分享怎么让AI替代自己维护这个项目。 其他人依然需要一些分享，AI本身不能告诉你如何替代你，还是需要人主动探索退出之路，如何和AI一起维护项目，即使是开源项目，也挺有借鉴意义。
  • 做取舍。 AI已经可以实现所有的功能，但依然需要我做取舍。比如多线程，即使AI能实现，也有非常多的方案，总不能把所有方案都实现吧？也不能先随机选一个，然后推倒重来吧？这时候选择就很重要，AI并不能替你做选择，因为选择是基于不同的价值判断。
  • Review代码，依然在长进。 当我看一眼AI写的代码，即使我没写，我也能一眼感觉到，这里不太好，那里不太对，哪些做法会有潜在问题。而且，即使是其他我不太熟悉的语言，一样有效，我只是没写代码，但Review代码时，我依然也在长进。
  • 更有空和人分享。 之前我也没空写这些文章，因为我要弄那些琐碎的代码。现在我不需要弄那些琐碎的脏活累活，就有心思和时间来亲自敲每个文字了。当网络充满大量的AI生成的文章，是不是觉得，还是不如人敲的文章有味道？

社区有什么变化？​

除了实现功能，AI还在帮我维护这个社区，社区的参与度也更加活跃了。如果你看Issues和PR，比之前都要活跃。

当然，大伙儿也是用AI提交的Issue和PR。这也肯定是未来的趋势，没有人会真的一点点的写这些了。如果你使用肉身看这些AI生成的Issue和PR，那就肯定要疯掉了。我有专门的Skill处理这些，所以我发现AI处理得会更好。我会让我的AI避免对方AI的干扰，先让AI提取这些Issue和PR中的想法，然后按照我的AI的想法来实现，最终看看对方的AI的代码变更，借鉴一些没考虑到的地方。

这个项目和社区，已经成为了一个试验场，看我们和AI一起是否能活到下一个十年。我并不能确定，就算项目死了也没关系，不过就是个开源项目而已，不必可惜。

后续有什么计划？​

AI大概找到了135个Bug，稳定性比之前要高了，年底估计会发布7.0的稳定版本。之前大概是2年发一个版本，或许未来会变成半年或一年一个版本。当主要的功能完成，就会进入一个版本周期，这样可以获得一个相对稳定的版本，在线上服务可用。

SRS 8.0的功能已经完成了绝大部分了，估计还会把WebRTC Edge做进来，这样就完成了所有的集群的能力。如果你单机部署Origin+Proxy+Edge集群，那就是一个多进程扩展方案，比多线程强多了。

或许还会将SRT协议重写了，或许还实现一个MoQ协议，或许还引入一个Rust的Proxy Server。这些会是试验性的功能，也可能会放在9.0了。也或许会完善上下游的应用，比如DJI对接或对应的App。

但比较明确的是，今年会把之前缺的一些重要的复杂功能做完了，全方位验证AI是可以维护这个项目的。明年的主要方向，是如何让AI可以维护你线上的SRS服务。写代码和维护服务，是两个完全不同的话题。

这不代表事情可以做完，实际上永远都做不完，有趣的项目会更有趣。

试一试​

在带有MSVC x64环境的Git Bash中，从源码编译SRS：

git clone -b develop https://github.com/ossrs/srs.git
cd srs
bash skills/srs-develop/scripts/srs-windows-runner.sh build
cd trunk
./objs/windows/srs.exe -c conf/console.conf

从下一个SRS 8.0版本开始，Releases页面的每个版本都会附带Windows压缩包SRS-Windows-x86_64-<version>.zip，不依赖任何DLL。工具安装、Visual Studio、控制台控制和限制，请参考Windows文档。