109
计算机与多媒体技术
汽车尾气处理装置图Computer And Multimedia Technology
电子技术与软件工程
Electronic Technology & Software Engineering
视频监控，作为远程监控最基本、最直观的方式，得到了广泛的应用，无论在川流不息的高速公路、人声鼎沸的街边路口，还是戒备森严的科研院所，到处都有摄像头的身影。 传统的高速公路视频监控方案多以C/S 架构为基础，通过客户端与服务端进行连接，实现摄像头的控制，视频的查看以及录像的调阅等操作，此种方式虽功能强大却需要为每台终端安装客户端，且客户端对终端的操作系统、硬件配置等有一定要求，无法实现方便的即时视频查看。此外，随着物联网的广泛应用，基于移动的视频直播、视频查看等也逐渐被大众所接受，相关的应用需求也越来越多。 随着全国高速公路视频云联网的逐步铺开，各地高速公路管理单位均面临着视频数据联网和共享的需求，省级高速公路视频资源需要全部汇聚分发，并与部级监控平台实现无缝对接。
本文通过对视频数据采集传输的各个流程进行简要介绍，并对目前较为主流的实时视频传输方案进行研究，结合高速公路视频云联网技术要求，针对不同的使用场景提出较为合理的视频采集、分发、传输以及播放方案。1 视频数据的采集与分发1.1 视频采集 目前，视频数据多采用数字方式进行采集、传输和存储。前端数字摄像机采集视频信号后，以标准视频格式（如主流的H.264标准）或厂商私有格式进行编码压缩，视频流数据以推（摄像头主动发送）或拉（后端服务器向摄像头请求）的方式传送至位于监控中心视频服务器中。
对于无法提供标准格式的数字视频摄像机，可通过开发软件，以设备SDK 调用的方式实时获取视频流数据，再将其以标准视频流协议格式封装，传输至服务器。 而较老的模拟视频设备，则可采用视频采集卡等硬件设备，实时将模拟视频信号转换成数字视频信号进行传输。
随着物联网的普及，移动视频采集也得到了越来越广泛的应用。此外，部分高速公路管理部门配备了移动指挥车，由现场摄像头采集的实时视频通过无线网络传输至控制大厅。对于不提供标准视频流协议的摄像头和移动设备，通常采用系统SDK 来进行交互，获取视频数据，经过标准协议编码封装后传输至服务器。
在《全国高速公路视频云联网技术要求》中，定义了“视频上云网关”的前置应用设备。通过网关，适配各个厂家的私有协议，将采集到的视频以“统一、标准”的视频格式推送至云平台。1.2 视频分发
医用呼叫器视频流数据到达视频服务器后，可进行存储及分发。目前视频分发采用的方式有如下几种：1.2.1 组播方式
视频组播方式是采用IP 组播（multicast ），将视频流数据封装在组播数据包中进行传输和分发的一种技术。
高速公路监控中心视频方案研究
李翔
（中远海运科技股份有限公司 上海市 200135）
相较于单播（unicast ）与广播（broadcast ）方式而言，组播方式解决了数据传输效率低的问题。当用户请求特定信息时，组播源仅向单一地址发送一次信息，相关网络设备（路由器、交换机等）借助组播路由协议为组播数据包建立树型路由，被传递的信息在尽可能远的分叉路口才开始复制和分发。故在组播方式中，在线客户端数量的增长对服务端基本没有压力。
但是，组播方式自身也存在一定的局限性：由于需要相关网络设备的支持，组播一般被应用于局域网内，组播数据包无法穿透防火墙，也就无法为Internet 上的用户提供服务。此外，组播是基于无连接的UDP 协议，在网络条件较差的环境中，阻塞控制、延迟控制等相关问题均无法获得满意的效果。1.2.2 流媒体服务器方式
流媒体服务器方式的视频分发是流媒体服务器在获取到原始视频流后，以相应的流媒体传输协议重新封装视频流数据，然后将数据以TCP 或者UDP 方式点对点（即单播方式，unicast ）传输至客户端。
由于支持TCP 协议，在网络较差的环境中，系统可以较好地进行阻塞控制、延迟控制等调节，保证视频的传输质量，此外，部分实时视频协议也支持跨防火墙进行传输，为Internet 上的视频发布提供了支持。
此外，由于视频数据流是通过服务器进行中转，视频格式转换、分辨率、码率等的调整均可在服务器端进行。
由于所有的客户端均直接与流媒体服务器直接连接，相较于组播方式而言，此种方案对服务器的性能要求较高。
两种方式的比较参见表1。
表1
方案灵活性服务端性能压力防火墙穿透
延时
组播低低否低流媒体服务器高
高是
高
根据视频上云的要求，视频流经采集并在省级云平台汇聚后，需要通过互联网接入部级云平台。故省部级云平台直接，需要采用流媒体方式传输视频。而在省级云平台内部，流媒体方式与组播方式均可采用。
1.3 常见视频流传输协议
目前，行业中使用较为普遍的视频流传输协议有如下几种：1.3.1 RTSP
实时流协议（Real Time Streaming Protocol ，RTSP ）是一种网络应用协议，用以控制流媒体服务器。
该协议创建和控制终端之间的媒体会话，媒体服务器的客户端使用RTSP 协议发送VCR 命令（如播放、暂停等），实时控制从服务器到客户端（视频点播）或从客户端到服务器（语音录音）的媒体流。
流数据本身的传输不是RTSP 的任务。大多数RTSP 服务器使用实时传输协议（RTP ）和实时控制协议（RTCP ）结合媒体流传输。由于RTP 协议是基于UDP 构建，RTSP 一般用于在局域网等网络
摘 要：本文针对高速公路视频监控需求，结合目前主流的视频采集、传输和播放方案，参照《全国高速公路视频云联网技术要求》，为不同的应用场景提出相应的参考方案。
关键词：视频监控；视频采集；云联网
计算机与多媒体技术
Computer And Multimedia Technology
电子技术与软件工程Electronic Technology & Software Engineering
条件较好的环境中进行视频流传输。
1.3.2 RTMP
RTMP协议是Real Time Message Protocol(实时信息传输协议)的缩写，它是由Macromedia公司（后被Adobe公司收购）提出的一种应用层的协议，用来解决多媒体数据传输流的多路复用（Multiplexing）和分包（packetizing）的问题。
RTMP基于TCP协议构建，在此协议中，通讯双方建立了一个持续性的低延迟通信通路。为了将视频流畅、高效地传输，RTMP 将视频流分割成片段（fragments），而片段的大小通常由服务端和客户端商讨来确定。通常，对于音频内容，片段的大小为64字节，而对于视频以及其他内容则为128字节。切片之后，来自不同流的片段会在一个长连接中交叉传输。
1.3.3 HLS
HTTP Live Streaming（HLS）是一个由苹果公司提出的基于HTTP的流媒体网络传输协议。相对于常见的流媒体直播协议（如RTMP协议、RTSP协议、MMS协议等），HLS直播最大的不同在于，直播客户端获取到的并不是一个完整的数据流。HLS协议在服务器端将直播数据流存储为连续的、很短时长的媒体文件（MPEG-TS 格式），而客户端则不断下载并播放这些小文件。因为服务器端总是会将最新的直播数据生成新的小文件，这样客户端只需不断按顺序播放从服务器获取到的文件，就实现了流的实时播放。
在一个流媒体会话开始时，客户端会下载一个包含元数据的extended M3U (m3u8) playlist文件，用于
寻可用的媒体流。在播放过程中，客户端可以选择从其他备用源中以不同的速率下载同样的资源，来适应变化的网络速率。受益于分段文件时长较短的特点，客户端可以很快的选择和切换码率，保障播放的连续性。
由于HLS只请求基本的HTTP报文，与实时传输协议（RTP）不同，HLS可以穿过任何允许HTTP数据通过的防火墙或者代理服务器，也能使用内容分发网络(CDN)来传输。
由于HLS的技术特点，它的延迟会高于普通的流媒体直播协议，故对于实时性要求非常高的场合，不采用HLS方式。
侧翻手机
1.3.4 HTTP FLV Live Streaming
基于HTTP的FLV视频流则是Adobe公司的标准，通过将视频流数据以H.264进行编码后，以HTTP包的格式进行网络传输。其实现与HLS类似。目前大量的视频网站均采用此种方式进行视频的直播和点播。
1.3.5 WebRTC
WebRTC(Web Real-Time Communication)协议不仅仅用于传输视频，此协议支持通过简单API传输视频、语音以及通用数据。此协议基于浏览器，且主流浏览器均支持，具有较强的跨平台能力。此外，
协议支持STUN、ICE、TURN等NAT和防火墙穿透技术。
WebRTC的传输设计基于P2P，在复杂网络环境中，故传输质量难以得到保证，需要采用CDN技术等来辅助提升传输体验。也正是由于其P2P的传输特点，对于视频监控这种1对多的场景，需要借助服务端方案。
根据各协议的特点，在不同的应用场景中，应选择不同的协议来保证视频传输效果、服务器压力等各方面的相对均衡，以期在有限的成本下获取最佳的效果。在视频联网的技术要求中，省级云平台采用RTMP协议向部级云平台推送低码率实时视频，同时，省级监控平台需要提供HTTP-FLV、HLS等协议支持，便于部级云平台调阅所有摄像机的高码率实时视频。
1.4 视频转码
根据高速公路视频云联网要求，各路监控视频需要以不同码率和协议进行传输分发。这就涉及到了视频的转码问题。结合目前公有云技术的发展，视频转码可采用租用公有云计算资源的“云端转码”和使用自有硬件资源的“本地转码”两种方式。
无纺布面膜
“本地转码”方式前期建设资金投入较高，但运维期间投入费用较低，结合机电设备的使用寿命周期，本地转码方案的经济效益要高于云端转码[1]。同时，目前的监控中心，大都基于服务器+IPSAN的架
构，这种以流媒体服务器为核心的架构，提供了前所未有的流媒体转发能力[2]，足以满足视频联网规范中对于视频转码的需求。
2 视频的展示
2.1 B/S架构下的视频展示
2.1.1 视频播放
在IE浏览器“一统江湖”的时代，在浏览器中查看视频是通过ActiveX控件来实现的。因为ActiveX极易被黑客利用，目前IE 浏览器对于ActiveX控件的管控非常严格，特别是对于没有数字签名的控件，在默认安全级别下将无法安装。因此，控件的部署变得较为困难。此外，由于IE的稳定性欠佳，浏览器常常被ActiveX 控件影响而失去响应。
随着HTML5技术的广泛普及，各主流浏览器已经基本完成了flv及mp4视频的原生播放支持。为此，可以采用基于rtmp方式的flv方式、基于HTTP方式的flv方式或者hls方式进行视频展示。
对于原生支持hls的浏览器，可以直接以HTML5的<video>标签来播放hls视频流；对于无法提供原生支持的浏览器，可以通过开发相应的flash播放器组件来播放视频。目前，网络上存在开源免费与收费的各种flash视频播放器，均可实现实时视频流的播放。
依靠目前主流浏览器JavaScript引擎性能的大幅进步，对于http flv streaming方式的实时视频，除了通过flash播放器方式来实现播放以外，还可以通过JavaScript脚本，将视频转换成html5视频标签支持的格式，实现浏览器直接播放。2021年1月1日开始，FlashPlayer的生命周期正式结束。对于实时性要求较高的监控场景，基于RTMP的视频流是唯一的选择。为此，可以考虑使用WebRTC 的方式进行数据传输。
2.1.2 视频墙
在高速公路视频监控领域，还存在一类典型的视频应用：视频墙，即以多画面的形式在同一界面上同时展示不同来源的视频。在基于C/S的架构中，此种应用不存在任何问题，仅需将多个视频播放控件放在一个界面即可。但在B/S架构下，多路flash视频同时播放会对浏览器带来巨大的运行压力，并最终导致浏览器失去响应。
为此，在并发视频数量较大，视频码率较高的场景中，可以考虑两种方案：
（1）后端视频合成+前台热区操作。在此方案中，需要后端系统（服务器或者视频合成硬件）等直接将需要集中展示的各路视频合成为一路视频，然后传输至前端展示。前端采用flash播放器或者原生视频展示，同时在合成视频的各自视频区域叠加相应的操作热区，当用户点击相应热区时将视频源切换至对应的单路视频。
（2）前端直接多视频展示。考虑视频墙是大批量视频的监控，其对于视频实时性的要求较单路监控视频而言较低；而视频播放的原理，是从视频流中解码出视频画面，并绘制到用户界面上。
依托于开源的力量，目前已经存在此类的解决方案(如jsmpeg)，通过websocket，后台服务器将视频流传输至前端，再由JavaScript引擎进行视频的解码，通过WebGL & Canvas2D将图像绘制到屏幕中。由于WebGL & Canvas2D在文档对象模型(DOM)树中是一个div对象，通过JavaScript很容易实现点击选择的操作。
110
111
计算机与多媒体技术
Computer And Multimedia Technology
电子技术与软件工程
Electronic Technology & Software Engineering
2.1.3 控制指令交互
在传统的B/S 架构中，浏览器在向服务器请求完数据后，连接即被断开，当需要进行数据交换时需要重新建立连接。而在视频监控应用中，类似摄像头PTZ 操作等需要非常短传输延迟，以期获得迅速的反馈。为此，需要在浏览器与服务器之间建立类似TCP 的长连接。
节能玻璃贴膜WebSocket 通过在通信两端建立基于TCP 连接的双向通道，实现在支持HTML5 的浏览器客户端与服务端之间双全工通信的网络技术。在WebSocket 通信实现过程中，当客户端向服务器发出建立连接请求后，服务器端应答建立连接，这时通信协议由 HTTP 协议升级成为WebSocket 协议，两端就可以直接交换数据，该双向通道会持续保持连接，服务器端的最新数据能够实时推送给客户端，实现实时通信[3]。
除了WebSocket ，还可以采用WebRTC 来传输控制指令，实现多种数据的单一通道传输。
视频云联网技术要求中，对于控制指令通道的要求是采用基于HTTPS 的控制接口，通信报文采用json 格式。由于部级云平台对于设备的控制实时性要求不高，在保证网络延迟的前提下，采用HTTPS 协议来传输控制指令能够满足需求。同时，采用HTTP/2的长连接技术，也有助于降低整体的控制指令交互延迟。2.2 移动架构下的视频展示
对于采用原生代码开发的APP ，可采用各种现有的视频控件来实现视频的播放。对于画面延迟性要求较高的应用，一般采用rtmp 协议或者私有化UDP 协议进行视频的传输。
对于HTML5混合编程的APP ，可参考B/S 架构下的视频播放章节中的方案，采用已被iOS/Android 平台原生支持的MP4格式视频，在WebView 中进行直接展示。此方案的缺点是延迟较大，如
果使用 RTMP 或者 HTTP-FLV ，延迟会在 1 秒到 3 秒之间，如果用 HLS 延迟会大于 8 秒甚至 10 秒[4]。故在低延迟场景下，可以考虑采用WebRTC 协议来传输实时视频流。由于此协议基于P2P ，需要自行开发或采用第三方的解决方案实现流媒体服务。3 结语
本文通过对主流视频流媒体传输协议的分析，结合B/S 架构以及移动应用环境的特点，提出了针对不同环境的视频监控解决方案。结合目前全国高速公路视频联网的要求，对视频的采集方式，视频传输的协议要求等均进行了阐述。随着全国高速公路联网工作的铺开，各地的高速高速公路监控将变得更加可视化和智能化，这不仅为全国高速公路的统一管理提供了有力保证，也为人民众的出行提供了更大的便利。
参考文献
[1]刘攀.基于公共云平台部署的升级视频云系统方案[J].中国
交通信息化,2020(07):85.
[2]高航远.视频监控技术的发展及在高速公路中的应用[J].科
技创新与应用,2020(04):180.
[3]张志明，柯卫.基于HTML5的视频通信云服务应用技术研究[J].
电信科学,2012,28(10):31-37.
[4]冼牛.实时视频直播客户端技术盘点：Native、HTML5、
WebRTC、小程序，/p/36322946作者简介
李翔，大学本科学历，工程师。主要负责信息系统架构设计、关键技术研究以及云原生和DevOps 相关工作。研究方向为架构师职务。
1 引言
基于旅游业的基于移动的虚拟体验被认为是改变当前消费者的旅行前、途中和旅行后体验的一种潜在形式。博物馆已经开始保存广播，电影剪辑和摄影等媒体以增强游客的体验，而推动信息传播的方法缺乏游客和技术的互动方面。增强现实一直是现代技术的流行语，并且在许多行业中都在快速发展和实施，尤其是计划于2014年启动的Google Glass 项目。但是，尽管尝试了将增强现实用于旅游，例如室外导航，通过覆盖交互式信息和重建考古信息的旅游双筒望远镜，至今仍未得到充分研究。此外，
在旅游业AR 的发展过程中，最终用户的观点已被广泛忽略。因此，本研究是在旅游环境中进行的，旨在识别和分析游客需求，以在旅游型特小镇中实施增强现实技术。2 旅游的增强现实
人工智能在旅游型特小镇当中的应用
陆莎
（海南热带海洋学院 海南省三亚市 572022）
增强现实是指通过计算机生成的内容来增强真实环境，而最新的内容主要
防盗手机套是图形内容。尽管该技术已经存在了10多年，但它在旅游业中仍是一个相当新的概念，尚未得到充分开发。学术界和行业从业者都认为增强现实技术需要与旅游业紧密结合，并与即时位置相关联，拥有巨大潜力。根据研究，用户界面不仅应该能够查明用户的位置，而且还应该提供可能感兴趣的区域的背景信息。截至2013年，大多数智能手机都提供基于GPS map 的导航系统，这些系统可以查明用户的确切位置。移动电话能够访问最新内容，可以灵活地传递文本，图像和视频数据，并且可以在基于地图的系统上提供其他信息。但是，由于这些应用程序的功能非常有限并且不允许多用户同时使用，因此仍在改进中。在旅游业中，AR 的当前实施缺乏用户的有效参与。此外，它尚未被完善，并且包含许多错误，在将其提供给公众之前需要加以克服。另一个挑战是对此类设备的接受和
摘 要：本文的目的是调查游客在旅游过程中对AR 应用程序的需求。 对海南的主要旅游景点和国内热门景点进行了深度调研，并通过主题分类来分析调研的结果。调查结果表明，尽管虚拟现实技术和增强现实技术等人工智能技术都已经过了炒作阶段，但它们正处于在旅游业中应用的边缘。此外，我们还发现多语言功能，易操作性和个性化的应用程序是吸引游客的主要需求。
关键词：增强现实技术；特小镇；旅游体验；用户需求
