@qile11 嗯呢 我调下样式

@flyqie 内网项目里面我做的是 MCU+SFU 配合的利用流媒体服务器，毕竟宽带服务器资源都够的

@flyqie 走 sfu/mcu 服务器遭不住，而且视频数据会过服务端这样同样录制下来，泄露数据的，所以暂定就这种 mesh 模式了

@io0 是的，只能作为玩玩，然后内网区域网搭建部署使用，公司内部使用也行。😭

@zhaopengme follow you d75076b1a31a330ecb0dc969829ee83074da26417b614b667205e6af3d837ee7

@duke807 打错字了 主观意愿

@duke807 主要是转码这个需要刻意的等待，如果非主观医院转码，在不同的用户体验中 估计马上秒退，就算是低帧率低分辨率，如果遇到视频长一点的，在提示转码🀄️的时候说不定就离开网页了。

@lsrnb 所以问题出在你的理解上啊，任何客户端都可以修改，你无法控制客户端的行为，你能做的只有保证谁入库谁为主，如果第一个因为网络有问题没有修改完成，但是此时第二个用户可以任何操作的，他有这个权利，如果他的行为 db 提交，不管是不是在上一个用户之前都是正确✅的，完成后第一个用户提交自然就因为版本不对失败

。。。。常见的乐观锁不就搞定了

@gimp 你看我例子里面那个玫瑰花🌹也很好看

@gimp 🫣🫣

@shenhuilin0 对的 我也在探索这个 毕竟按照以往的方式 要么直接 websocket 要么 自己搭建流媒体服务端 ，如果后期真的出来 wasm 的 websocket 库+ffmpeg-stream 的 我觉得可行性非常高

@Aloento wasm 公用的 MEMFS 。ffmpeg.wasm 对接的 FS 的基本 API ，按照实际情况判断下啥时候启用，然后用完删除即可，很灵活，就担心不删除然后浏览器直接崩了

@littlewing 和本地肯定有差别的，但是比纯 JS 处理同等的事要强的多，官方描述是和接近本地的速度，所以优化的好的话可以接近，但是完美的和本地媲美是不行的

@ByteCat 是的 ，期待后面这个的发展

@humbass ffmpeg.wasm 对的 推流暂时还不支持，作者也在探索，感兴趣的话看看这个 https://github.com/davedoesdev/streamana

@Aloento 这个包我也看了下 对于 MEMFS 中文件的管理不太灵活，对 FS 的 API 对接没得 ffmpeg.wasm 灵活

@Actrace 配合 webgl 可以 谷歌那个 mediapiple 就是的 不清楚具体怎么弄的

@xuanyuanaosheng 😘