webview 依赖于本身平台的内核版本，一般 uniapp 打包后的都是用的宿主本身的内核，而这些机子大多数是支持 webrtc 的，但是有很多也是不支持的，每个厂商的比如小米的有时候你连摄像头都打不开，所以打包 APP 的时候需要额外换个独立内核，这样就能兼容 webrtc 的对应的 API 的，提到的 webrtc 就是视频通话的核心，无论哪个厂家的 web 端都是离不开这些 API 的，webview 一样

推荐本地化磁盘文件的 api ，最差就纯内存那就 MEMFS+Wasm.. 1 个 G 视频绰绰有余，有单独的 memfs npm 包，不过我因为视频有其他操作直接用的 ffmpeg 的
```
await ffmpeg.writeFile('input.mp4', inpf);
//读取视频数据

let memfsData = ffmpeg.FS('readFile', 'suke.mp4');

//创建虚拟 URL

this.transcodeUrl = URL.createObjectURL(new Blob([memfsData.buffer], { type: "video/mp4" }));

```

加油

rk356X 瑞芯微的 还有 3588 系列 rv 系列 系统 ubuntu arm64 ，这几天刚将 PPOCR3-4 部署到上面

@forgottenPerson 你没注意到题目里面说的：“有时问问题的时候不搭理他，或者回答他问题的时候态度不好(据我了解他一天可以产生几十个问题需要问人，简单到命令用法都是问人不百度、谷歌的)”？

@TenProX 。。。人和人是有区别的，有的人是教了愿意学，有的人是连基本的问题都不会问，教还得自己认识到是有人在教，而不是等着喂饭

微信小程序体验安卓端非常 nice ，切到后台也能打开微信，每个小程序都是独立的后台，ios 只能退出来

节哀

同，nginxWebUI ，https://github.com/cym1102/nginxWebUI

webrtc-stream 组件，https://github.com/mpromonet/webrtc-streamer 直接 RTSP 拉流,这个是直接 RTP 流到 webrtc 转换的，所以低延迟，消耗最少；如果你借助 ffmpeg 将 rtsp 转到 flv 或者 hls 流畅度上来说 HLS 要好点，但是 flv 会出现限制，也就是缓冲加载，所以建议 webrtc ；不想用 webrtc-stream ，那就剩下的 GB28181 推流到 ZLM 或者 SRS ，然后 webrtc 再从服务端拉流，目的还是低延迟但是中间还是 监控将流通过 RTP 的方式推流到 ZLM 或者 SRS 了，你提到的 GB+wvp 就是这个原理，通过 GB 协商 监控推流到 RTP 服务器，而 RTP 服务器就是 ZLM ； zlm 和 SRS 内部再将原始流转成 WebRTC 、RTMP 、RTSP 、HLS 、Flv 等格式

xrebel

webrtc 直接推流到 SRS 或者 ZLM ，SRS 部署一键 docker 直接运行，前端代码就十几行搞定

这个基本的文件发送都要付费吗

paddleocr 确实可以 已经做成服务了，比微信的强

感谢分享，看了下很不错的

还有就是 wasm 方案也不得行，浏览器没法提供 tcp/udp 裸流的，所有 over

node+websocket+flutte-ffmpeg ，简单易用，其他的处理降级浏览器版本使用 flash 都比这个方案复杂麻烦
https://i.v2ex.co/Z07f16twb.jpeg