C100 云游戏芯片，手把手跑通一条串流链路

我花了两天试了一下 C100 这块云游戏芯片。做法是把它装进一台小主机，做成局域网里的串流服务端，再从笔记本连过去打游戏。目标很朴素，画面不糊，操作不飘。术语第一次出现我会掰开讲。

先说清楚 C100 是干什么的。它是一块专为云游戏做的加速芯片，主要干三件事：把游戏画面压成视频流、把压缩解压这段延迟压下去、顺手把画质修一修。你可以把它想成一台专门负责传画面的小工。游戏本体还是在你机器上跑，它负责把画面又快又清楚地送到另一台设备。

云游戏听着玄，本质就是串流加远程操作。串流就是 A 机器把画面实时压成视频发给 B 机器，B 机器一边收一边解。延迟就是这条链路上每一段耗时的总和。

准备的东西就三样。一台带 C100 的主机或者开发板，我这边用的是朋友公司的现成板子，芯片已经焊在上面。一根网线，千兆最好。再一台客户端设备，笔记本、平板、电视盒子都行，装一个能解码视频流的播放端。网线这一步别省，我第一天图省事走了 Wi-Fi，后面会讲后果。

上手：四步跑通

1. 给主机装系统。我这边是 Linux，装完进桌面，用 ip addr 看有没有拿到 IP 地址，看到 192.168 开头的一串就对了。没拿到就低头看网口灯亮不亮。

2. 装 C100 的驱动和运行库。厂商给的是一个安装包，解压后跑里面的 install.sh。装完重启，用 lsmod | grep c100 确认驱动挂上了。没有输出就是没装成，回去翻日志，多半是缺依赖。

3. 配串流服务。这一步是重点。服务端要选编码方式，通俗说就是用哪套算法压画面。C100 走硬件编码，比软件编码省 CPU，延迟也低一截。码率先给中档，码率就是每秒传多少数据，别一上来拉满。

4. 客户端连接。笔记本上打开播放端，填服务端的 IP，选分辨率，点连接。正常的话两三秒出画面。

我第一次连上，画面是出来了，手感发飘，鼠标移过去有半拍滞后。下面这几段就是那时候找出来的问题。

踩坑：容易翻车的几个地方

第一个坑是网络。走 Wi-Fi 的时候延迟忽高忽低，这东西跟量化里的滑点一个道理，看平均值没用，要看尾部。你测十次都挺稳，第十一次突然蹦一下，体验就毁了。换成网线之后曲线立刻平了。所以别用无线，尤其别用 2.4G 频段。

第二个坑是编码参数。码率调太高，网络扛不住，画面卡顿甚至花屏；调太低，画面糊成一片。我的做法是从中档起步往上加，加到开始卡就往回退一格。分辨率同理，先 1080p 跑顺了再往上试。

第三个坑在客户端。有些老设备解码跟不上，服务端明明没问题，客户端这边先掉帧。换个新一点的设备对比一下就知道是谁的锅。我一开始以为是 C100 不行，换台笔记本立刻好了，纯粹是旧设备拖后腿。

还有个隐性的坑，音画不同步，多半是缓冲区设太大。缓冲区就是先攒一小段数据再播，攒得多不容易断，但延迟会涨。调小延迟降，网络一抖又容易断。这里没有完美解，只有取舍。

有人在网上说 GeForce Now 那种方案能压到十几毫秒。我这边没复现过，环境差太多，看看就好。

跑通之后我连着打了几个晚上。整体感觉，C100 在压画面这件事上是省心的，硬件编码确实把 CPU 解放了出来，主机跑游戏的同时还能干别的。延迟我这边测下来，有线局域网内基本稳，具体数字跟网络环境关系太大，我就不报了，你自己测更准。

真正卡住体验的通常是网线和客户端，芯片本身反倒不是问题。这跟做策略一样，模型再好，执行环节掉链子，收益照样被吃掉。我前阵子写过一句，共用技术栈不等于同一套风险，放这儿也成立，别看到都是加速卡就默认体验一致。

接下来我打算试两件事。一是把客户端换成手机或者电视盒子，试跨房间、跨楼层的效果，这测的是链路稳定性。二是在同一台主机上跑两个客户端，看 C100 能不能同时扛住两路编码，这测的是并发能力。

跑起来不难，难的是把抖动压住。延迟尾部压不下去，前面那些参数调得再漂亮也没用。