一次webrtc视频拉流的摸爬滚打全纪录

简介: 上周五的上午突然接到了一个需求,要在前端页面中增加的摄像头的画面预览功能,要在周一(昨天)完成,我本来以为接入视频流并不会很困难,毕竟之前也做过视频相关的需求。

1682516723(1).png

上周五的上午突然接到了一个需求,要在前端页面中增加的摄像头的画面预览功能,要在周一(昨天)完成,我本来以为接入视频流并不会很困难,毕竟之前也做过视频相关的需求。

但是,真正做起来却不是那么简单。因为底层的同学给的视频流地址是一个rtsp协议的(例:rtsp://192.168.0.123:8081),在跟百娘“缠绵”了一番之后,最终得出结论——前端无法直接使用rtsp流播放(可能有,如果知道的大佬请评论区告知)。

在告知底层同学之后,过了一会我收到了一个链接

1682516775(1).png

他们吧rtsp流转成了WebRTC,乍一看我还有点兴奋,因为不久前刚看过WebRTC,感觉这回“简单”了。打开这个链接看到了监控的实时画面

1682516799(1).png

但是,给提供的材料有且仅有这一个链接,这我又摸不着头脑了,我了解的WebRTC是P2P的啊,需要双方的SDP进行协商连接,但这只有一个链接我怎么玩?!

一筹莫展之际,刻在前端开发DNA中的记忆被唤醒了——F12,然后发现了一个东西,直觉告诉我,真相就在不远处

1682516814(1).png

找到这个文件之后,一段段我熟悉的代码映入眼帘,我悟了。(suuid对应的就是摄像头的设备名称)

1682516876(1).png

最关键的在于下面那两个jquery请求,最后一个请求正是获取对端SDP的请求,一般使用P2P获取SDP都是用的socket,这里因为只有一端能够发起会话,所以用了http的形式。

事后我找到了他们rtsp转WebRTC所使用的工具RTSPtoWebRTC,打开github的第一眼我就认出来了

1682516900(1).png

书归正题,看懂了这段代码之后,我结合项目将这段代码转化为了我们项目中能用的形式

import { getRTCCodec, getRTCReceiver } from '@/services/camera';
/**
 * 预览摄像头
 * @param ele 要播放视频的video 标签元素
 * @param ip 视频流IP 地址
 * @param port 视频流端口
 * @param cameraName 摄像头名称
 */
export async function preview(ele, ip, port, cameraName) {
  // 创建新的媒体流
  let stream = new MediaStream();
  // 初始化 ice 配置
  let config = {
    iceServers: [
      {
        // stun 服务器地址, P2P打洞需要
        urls: ['stun:stun.l.google.com:19302'],
      },
    ],
  };
  // 兼容不同的浏览器
  const PeerConnection =
    window.RTCPeerConnection ||
    // @ts-ignore
    window.mozRTCPeerConnection ||
    window.webkitRTCPeerConnection;
  // 新建RTC连接
  const pc = new PeerConnection(config);
  // 需要协商时触发事件
  pc.onnegotiationneeded = handleNegotiationNeededEvent;
  pc.ontrack = function (event) {
    stream.addTrack(event.track);
    // 设置srcObject
    ele.srcObject = stream;
  };
  // 获取codec
  const codec = await getRTCCodec(ip, port, cameraName);
  codec.forEach((c) =>
    pc.addTransceiver(c.Type, {
      direction: 'sendrecv',
    }),
  );
  // 协商事件
  async function handleNegotiationNeededEvent() {
    // 生成本地Offer
    let offer = await pc.createOffer();
    // 设置本地Offer
    await pc.setLocalDescription(offer);
    let receiver;
    try {
      // 获取远端 answer
      receiver = await getRTCReceiver(
        ip,
        port,
        cameraName,
        pc.localDescription?.sdp,
      );
      // 设置远端 answer
      await pc.setRemoteDescription(
        new RTCSessionDescription({
          type: 'answer',
          // 解码远端answer
          sdp: atob(receiver),
        }),
      );
    } catch (e) {
      console.log(e);
    }
  }
}
复制代码

这里有个小坑,我一开始没太注意,这里卡了一段时间:获取对端answer的post请求参数,是一个字符串,类似于get请求的query格式参数,只不过挪到了body中,并不是使用json

/**
 * 获取摄像头的receiver
 * @param ip
 * @param port
 * @param cameraName
 */
export async function getRTCReceiver(
  ip: string,
  port: string,
  cameraName: string,
  sdp: any,
): Promise<any> {
  return await basePost(
    `http://${ip}:${port}/stream/receiver/${cameraName}`,
    // base64 sdp
    `suuid=${cameraName}&data=${btoa(sdp)}`,
    {
      'Content-Type': 'application/x-www-form-urlencoded',
    },
    true,
    true,
  );
}
复制代码

效果展示

1682516929(1).png


相关文章
|
7月前
|
网络协议 Linux
音视频学习之rtsp推拉流学习2(流媒体服务器ZLMediaKit)
音视频学习之rtsp推拉流学习2(流媒体服务器ZLMediaKit)
669 0
|
Web App开发 前端开发
ZLMediaKit解决webrtc前端replaceTrack断流问题
ZLMediaKit解决webrtc前端replaceTrack断流问题
|
7月前
|
Ubuntu
SRS RTMP流媒体服务器搭建
SRS RTMP流媒体服务器搭建
307 0
|
Web App开发 数据采集 物联网
Android平台基于RTMP或RTSP的一对一音视频互动技术方案探讨
随着智能门禁等物联网产品的普及,越来越多的开发者对音视频互动体验提出了更高的要求。目前市面上大多一对一互动都是基于WebRTC,优点不再赘述,我们这里先说说可能需要面临的问题:WebRTC的服务器部署非常复杂,可以私有部署,但是非常复杂。传输基于UDP,很难保证传输质量,由于UDP是不可靠的传输协议,在复杂的公网网络环境下,各种突发流量、偶尔的传输错误、网络抖动、超时等等都会引起丢包异常,都会在一定程度上影响音视频通信的质量,难以应对复杂的互联网环境,如跨区跨运营商、低带宽、高丢包等场景,行话说的好:从demo到实用,中间还差1万个WebRTC。
165 0
|
1月前
|
Web App开发 网络协议 算法
WebRTC 和一些常见的直播方案
【10月更文挑战第25天】
|
3月前
|
Web App开发 网络协议 Android开发
Android平台一对一音视频通话方案大比拼:WebRTC VS RTMP VS RTSP,谁才是王者?
【9月更文挑战第4天】本文详细对比了在Android平台上实现一对一音视频通话时常用的WebRTC、RTMP及RTSP三种技术方案。从技术原理、性能表现与开发难度等方面进行了深入分析,并提供了示例代码。WebRTC适合追求低延迟和高质量的场景,但开发成本较高;RTMP和RTSP则在简化开发流程的同时仍能保持较好的传输效果,适用于不同需求的应用场景。
193 1
|
4月前
|
Linux 开发工具 图形学
Unity下实现跨平台的RTMP推流|轻量级RTSP服务|RTMP播放|RTSP播放低延迟解决方案
自2018年起,我们成功实现了Unity环境下的低延迟RTSP|RTMP播放,达到毫秒级延迟,获得业界广泛认可。现已覆盖Windows、Android、iOS与Linux平台的RTMP推送、轻量级RTSP服务及RTSP|RTMP播放。通过高效采集Unity窗口或摄像头数据,并利用原生SDK进行编码与推送,确保了数据传输的高速性。此外,播放器支持多路视频同时播放,适应不同分辨率,并保持长时间运行稳定。更多技术细节和技术博文,请参考相关链接。
265 1
|
4月前
|
监控 开发工具 Android开发
Android平台实现RTSP拉流转发至轻量级RTSP服务
为满足Android平台上从外部RTSP摄像头拉流并提供轻量级RTSP服务的需求,利用大牛直播SDK实现了相关功能。SDK支持开始与停止拉流、音频视频数据回调处理及RTSP服务的启动与发布等操作。拉流仅需将未解码数据回调,对性能影响小。音频和视频数据经由特定接口传递给发布端进行处理。此外,SDK还提供了获取RTSP会话数量的功能。此方案适用于监控和巡检等低延迟应用场景,并支持二次水印添加等功能。
|
4月前
|
编解码 网络协议 开发工具
Android平台RTSP|RTMP直播播放器技术接入说明
大牛直播SDK自2015年发布RTSP、RTMP直播播放模块,迭代从未停止,SmartPlayer功能强大、性能强劲、高稳定、超低延迟、超低资源占用。无需赘述,全自研内核,行业内一致认可的跨平台RTSP、RTMP直播播放器。本文以Android平台为例,介绍下如何集成RTSP、RTMP播放模块。
179 0
|
网络协议 算法 网络性能优化
【流媒体】推流与拉流简介
【流媒体】推流与拉流简介
511 0