一次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


相关文章
|
8月前
|
缓存 网络协议 开发工具
庖丁解牛之-Android平台RTSP|RTMP播放器设计
我们在做Android平台RTSP或者RTMP播放器开发的时候,需要注意的点非常多,以下,以大牛直播SDK(官方)的接口为例,大概介绍下相关接口设计:
113 0
|
8月前
|
Web App开发 数据采集 物联网
Android平台基于RTMP或RTSP的一对一音视频互动技术方案探讨
随着智能门禁等物联网产品的普及,越来越多的开发者对音视频互动体验提出了更高的要求。目前市面上大多一对一互动都是基于WebRTC,优点不再赘述,我们这里先说说可能需要面临的问题:WebRTC的服务器部署非常复杂,可以私有部署,但是非常复杂。传输基于UDP,很难保证传输质量,由于UDP是不可靠的传输协议,在复杂的公网网络环境下,各种突发流量、偶尔的传输错误、网络抖动、超时等等都会引起丢包异常,都会在一定程度上影响音视频通信的质量,难以应对复杂的互联网环境,如跨区跨运营商、低带宽、高丢包等场景,行话说的好:从demo到实用,中间还差1万个WebRTC。
|
网络协议 编译器 Linux
FFMPEG音视频开发: 发布RTSP流(采用EasyDarwin作为流媒体服务器)
FFMPEG音视频开发: 发布RTSP流(采用EasyDarwin作为流媒体服务器)
761 1
FFMPEG音视频开发: 发布RTSP流(采用EasyDarwin作为流媒体服务器)
|
5月前
|
Web App开发 API
ZLMediaKit webrtc录像
ZLMediaKit webrtc录像
|
8月前
|
编解码 网络协议 Android开发
Android平台RTMP|RTSP直播播放器功能进阶探讨
很多开发者在跟我聊天的时候,经常问我,为什么一个RTMP或RTSP播放器,你们需要设计那么多的接口,真的有必要吗?带着这样的疑惑,我们今天聊聊Android平台RTMP、RTSP播放器常规功能,如软硬解码设置、实时音量调节、实时快照、实时录像、视频view翻转和旋转、画面填充模式设定、解码后YUV、RGB数据回调等:
108 0
|
8月前
|
Web App开发 编解码 应用服务中间件
Windows平台基于RTMP实现一对一互动直播
目前市面上大多一对一互动都是基于WebRTC,缺点如下: 1. 服务器部署非常复杂,不利于私有部署,在一些私密性高的场景下,无法使用,如公安、市政等体系; 2. 传输基于UDP,很难保证传输质量,由于UDP是不可靠的传输协议,在复杂的公网网络环境下,各种突发流量、偶尔的传输错误、网络抖动、超时等等都会引起丢包异常,都会在一定程度上影响音视频通信的质量; 3. 难以应对复杂的互联网环境,如跨区跨运营商、低带宽、高丢包等场景; 4. 整个框架体系不够灵活,代码复杂度高,行话说的好:从demo到实用,中间还差1万个WebRTC。
|
8月前
|
Web App开发 开发工具 Android开发
利用RTMP或RTSP实现跨平台一对一互动功能
目前市面上大多一对一互动都是基于WebRTC,缺点如下: 1. 服务器部署非常复杂,不利于私有部署,在一些私密性高的场景下,无法使用,如公安、市政等体系; 2. 传输基于UDP,很难保证传输质量,由于UDP是不可靠的传输协议,在复杂的公网网络环境下,各种突发流量、偶尔的传输错误、网络抖动、超时等等都会引起丢包异常,都会在一定程度上影响音视频通信的质量; 3. 难以应对复杂的互联网环境,如跨区跨运营商、低带宽、高丢包等场景; 4. 整个框架体系不够灵活,代码复杂度高,行话说的好:从demo到实用,中间还差1万个WebRTC。
|
9月前
|
Web App开发 编解码 网络协议
Android平台一对一音视频通话方案对比:WebRTC VS RTMP VS RTSP
Android平台一对一音视频通话方案对比:WebRTC VS RTMP VS RTSP
285 0
|
12月前
|
Web App开发 编解码 安全
WebRTC的应用
WebRTC的应用
|
Web App开发 人工智能 移动开发
什么是WebRTC
什么是WebRTC
246 0