视频采集要简单（点几下鼠标，自动发现或输入连接信息）

不管是 USB 摄像头还是 IPC 网络摄像头，要很 方便 的管理和视频采集。

• USB 摄像头一般都是 WebCam，通过 USB 接在网关或主机上，比如 Linux 下： /dev/video0, /dev/video1
• IPC 网络摄像头：
  1. 绝大部分都支持 ONVIF 协议，对接相对便捷，输入用户名和密码，自动获取 StreamURI；
  2. 不支持 ONVIF 协议，可以采用 RTSP 协议进行对接，配置起来相对比较麻烦些，必须要知道摄像头流播放地址，就是 StreamURI ；
  3. 最好是支持 POE 供电的网络摄像头，这样就不需要为摄像头拉电源线和转换器；

在 Web 浏览器查看视频流（谁还愿意安装一个 App 来看视频呢？）

• 坚决抵制（客户要求）安装 App 来查看视频，是不是太原始了；
• 能够兼容绝大部分的浏览器（对不起：IE 不支持  ）；

查看视频流延迟尽量小（< 1 秒）

客户需求肯定是希望视频流越快越好，最好没有延迟和卡顿（ 基本做不到 ，那就尽量提高查看视频效率吧

• 人眼感知度在 1秒 内，还是可以忍受的范围，市面上大部分摄像头也就能达到这个级别；
• 视频和音频同步播放，怕就怕在声音来了图像还没有到，那种感觉太难受了；
• 不同的播放终端设备，其实延迟都不一样，比如 HLS 协议相对就比较延迟一些；
• 采用更高效的 WebRTC 协议，的确效果改善不少（需要浏览器支持）；

按需点播/直播，空闲时节省服务器资源

占着茅坑不拉屎，就是形容某些没有点播/直播的时候网关/服务器还占着资源不释放，所以 按需 才是王道。

• 没有点播/直播时，要处于 suspend 或 standby 的状态，以便节省计算和网络资源；
• 即点即播，一旦有客户端发起点播指令，应该在 几百毫秒 之内完成 采集->编码->解码->视频流 这一系列工作；
• 按需，根据需要来驱动视频流的相关流程和处理，是客户所认同的观点。