这是一个创建于 758 天前的主题，其中的信息可能已经有所发展或是发生改变。
最近做一个基于 react 的直播类型项目， 已经完成了拉流部分，本地使用 node media server 推流，再在前端用 react-flv-player 加载直播流地址播放就行。 现在要实现前端采集音频数据并推流的功能，不知道是该如何完成？ 应该是要前端启动麦克风进行录音，并将采集到的实时片段数据传给后端的收流服务器吧， 但是如何进行录音的切割？ 怎样传输给后端？应该和普通的文件上传很不一样吧？ 请教大家！
第 1 条附言 2023-09-17 00:11:14 +08:00
谢谢大家的慷慨回复！补充一下，我这个只是做一个简单的 demo ，实现功能就行，用最简单省事的功能完成就行，开发速度要快，webrtc 不知道是不是学习周期会长一点？ web 上 rmtp 是可以通过后端转换成 http 协议的 flv 进行拉流的，我现在的拉流源最初就是 rmtp 的，
感谢大家赐教，请问哪种方法最单肩迅速？？
感谢大家赐教，请问哪种方法最单肩迅速？？
第 2 条附言 2023-09-17 04:36:55 +08:00
再次感谢大家讨论，我也再次补充一下我之前可能没说清楚的方面，
我要做的功能其实是很简单的，
就是前端录音，发送给后端，后端接受录音之后提供一个推流地址，就行了。
所以我想的是，前端录音以 blob 形式通过 websocket 传输到 nodejs 搭建的简单 ws 服务器，接受到的 blob 在本地存储为（多个？）本地文件，然后再用 ffmpeg 命令实时将这个本地文件推流出去？
问题是这个本地文件如何保证存储时自动分块和推送时自动拼接？
我要做的功能其实是很简单的，
就是前端录音，发送给后端，后端接受录音之后提供一个推流地址，就行了。
所以我想的是，前端录音以 blob 形式通过 websocket 传输到 nodejs 搭建的简单 ws 服务器，接受到的 blob 在本地存储为（多个？）本地文件，然后再用 ffmpeg 命令实时将这个本地文件推流出去？
问题是这个本地文件如何保证存储时自动分块和推送时自动拼接？
第 3 条附言 2023-09-18 13:03:34 +08:00
使用 getUserMedia 获取用户音频，
通过 ws 发送到后端，在 ws 后端将实时收到的 message 作为 ffmpeg stdin 输入，再通过 ngnix 里配置好的 rtmp 协议推流出。跑通了。
通过 ws 发送到后端，在 ws 后端将实时收到的 message 作为 ffmpeg stdin 输入，再通过 ngnix 里配置好的 rtmp 协议推流出。跑通了。
 | 1 Masoud2023 2023-09-14 10:02:12 +08:00 webrtc? |
 | 2 YYYMagic 2023-09-14 10:07:30 +08:00  1 前端采集麦克风声音和摄像头画面，编码之后通过 RTMP 协议建立长连接，将音视频数据实时传输给服务器 服务器可以自己搭建，也可以用云厂商的直播 CDN 服务 服务端会做把直播流切成小文件，拉流客户端用 HLS 协议拉流；或者服务端转封装 FLV ，拉流客户端通过 HTTP 长连接拉流 |
 | 3 NessajCN 2023-09-14 10:16:55 +08:00 前端用 navigator.mediaDevices.getUserMedia() 采集好了推给 mediamtx https://github.com/bluenviron/mediamtx/blob/main/internal/core/webrtc_publish_index.html |
 | 4 56rhcrivs55TVKdX 2023-09-14 10:19:25 +08:00 webrtc, 好几个直播平台早就支持网页推流了 |
 | 5 israinbow 2023-09-14 11:05:45 +08:00 同楼上用 webrtc, 可以参考 livekit.io |
 | 6 darkengine 2023-09-14 11:08:28 +08:00 不考虑第三方的推拉流服务? 这整套从 0 开始工作量太大了 |
 | 7 mightybruce 2023-09-14 11:25:35 +08:00 这个项目还是建议用靠谱的音视频厂家服务，你自己做不现实，没有 CDN, 也不懂音视频编码（最起码 ffmpeg 编程要会），况且你还是个做前端的。 推荐直接购买阿里云，腾讯云的直播或点播云服务 或者从声网买专门的音视频服务 RTMP flv 现在已经属于落后的技术， 了解一下 HLS 配合 FMP4 (flv 压缩率太低） DASH 协议吧 不推荐 webrtc, 这个技术虽然先进，但是对你编程要求很高， 谷歌对这个客户端更新慢得很，你还要自己搞定信令服务器 webrtc 更好的用途是视频会议 和通话 的双向通信。 |
 | 8 xiuxian 2023-09-14 11:31:32 +08:00 webrtc 你值得拥有。说 rtmp 的都不靠谱，你浏览器怎么连 tcp socket ？ flash 插件早就被禁用了。 |
 | 9 suke119 2023-09-14 11:41:46 +08:00 webrtc 直接推流到 SRS 或者 ZLM ，SRS 部署一键 docker 直接运行，前端代码就十几行搞定 |
 | 10 flyqie 2023-09-14 17:52:00 +08:00 via Android webrtc 是你需求最优的方案。 上面发 rtmp 的。。确定干过 web ？ web 能连 rtmp ？？ |
| 11 flyqie 2023-09-14 17:54:28 +08:00 via Android |
 | 12 chnwillliu 2023-09-15 05:06:08 +08:00 via Android 狭义地讲，Media Capture and Streams API 是独立于 WebRTC 的，往往 WebRTC 都会用到 getUserMedia 。 其实要获取媒体流话，用得到 Media Capture 的 getUserMedia API ，编解码方面可以用 WebCodecs API ，不一定要用 WebRTC 传数据，WebRTC 的核心是多端双向通信，略复杂。 做推流，有个比较新的东西是 WebSocket 的升级版， 叫 WebTransport , 基于 HTTP3 的，JS 侧的 API 都是基于 Stream 的，可以进行可靠传输和类似 UDP 一样的不可靠传输。API 还比较新，不一定能在生产环境用。 这里有一个用 getUserMedia + WebCodecs+ WebTransport 做的 video echo 的 demo https://webrtc.internaut.com/wc/wtSender4/ |
| 13 mightybruce 2023-09-15 07:41:09 +08:00 这些人各个装着对 webrtc 很了解，估计都是些前端。 “WebRTC 是通信的能力，从技术上看是两个或多个客户端，让用户具备互动的能力。 人对于延迟的感知是 400ms ，也就是一般的对话能顺利进行，这是 RTC 的核心指标。 由于端和端之间有关联，导致系统复杂度比直播高了多个数量级，这是很多问题的根源。"（ https://ossrs.net/lts/zh-cn/docs/v4/doc/webrtc ） web 又不是直接连 rtmp, 那个方案没有大问题， rtmp 转 HLS ，HLS 就是 http 的。 |
| 14 mightybruce 2023-09-15 07:50:46 +08:00 另外 webrtc 中每个节点是对等的，直播不需要对等的，也不需要信令服务器 和 NAT 打洞。 |
Select Language