192.168.10.129/cam/realmonitor?channel=1&subtype=0，用vlc可以直接播放。但在浏览器会报ERR_UNKNOWN_URL_SCHEME。那如何在浏览器中播放呢。
以下列出几种方案。
1、安装插件（chrome最新版基本都不支持）
类如：kurento，vlc插件（谷歌浏览器版本41以下),vgx插件(不支持高版本，chrome72.0版本可用)等。
2、安装软件（中间件，基本都付费）
类如：Appemit（调用vlc插件播放rtsp），可以免安装的，目前只能windows,免费版会有提示。
猿大师中间件（底层调用VLC的ActiveX控件，实现在主流浏览器网页中内嵌播放多路RTSP的实时视频流），中间件收费的。
PluginOK(牛插)中间件。底层调用ActiveX控件VlcOcx.dll。（商业用途需付费使用）
3、服务器拉流转发及协议转换
示意图如下所示：
推流--------------服务器转发--------------拉流
方法一览：
a,vlc软件串流到http协议 ，网页显示几个视频需启动几个vlc,只适合应急场景。
b,html5 + websocket_rtsp_proxy 实现视频流直播 ，基于MSE（Media Source Extensions,W3C），扩展H5的功能。
步骤：服务器安装streamedian服务器，客户端通过video标签播放。
原型图：
价格：
c.基于nginx的rsmp转发
基于nginx实现rtmp转化，用flash实现播放。由于flash目前大多浏览器默认禁用，不推荐此方式。
步骤：安装ffmpeg工具,安装nginx。
另外nginx-rtmp-module也支持HLS协议,可以搭建基于hls的直播服务器。
d.rtsp转hls播放,通过ffmpeg转码
步骤：安装ffmpeg工具，ffmpeg转码。
形如：
ffmpeg -i "rtsp://admin:[email protected]/cam/realmonitor?channel=1&subtype=0" -c copy -f hls -hls_time 2.0 -hls_list_size 0 -hls_wrap 15 "D:/hls/test.m3u8"
缺点是直播流延时很大，对实时要求比较高的不满足要求。
案例：基于EasyDarwin拾建转码服务器。参考地址:https://blog.csdn.net/jyt0551/article/details/84189498
通过存储的m3u8去读取。
e.websocket代理推送，FFMPEG转码
此方法与a，b类似。但更实用。
以下提供两种方案：
（1）Gin+WebSocket+FFMPEG实现rtsp转码,参考：https://juejin.cn/post/6844904024072798216
通过FFMPEG把rstp转成http，ginrtsp作为转发服务器，但需要自己写相应接口，需要了解go语言。
（2）node + ffmpeg + websocket + flv.js，参考：https://juejin.cn/post/6908641550046068744
步骤：在node服务中建立websocket；通过fluent-ffmpeg转码，将RTSP 流转为flv格式；通过flv.js连接websocket，并对获取的flv格式视频数据进行渲染播放。
import WebSocket from 'ws'import webSocketStream from 'websocket-stream/stream'import ffmpeg from 'fluent-ffmpeg'// 建立WebSocket服务const wss = new WebSocket.Server({ port: 8888, perMessageDeflate: false })// 监听连接wss.on('connection', handleConnection)// 连接时触发事件function handleConnection (ws, req) { // 获取前端请求的流地址（前端websocket连接时后面带上流地址） const url = req.url.slice(1) // 传入连接的ws客户端 实例化一个流 const stream = webSocketStream(ws, { binary: true }) // 通过ffmpeg命令 对实时流进行格式转换 输出flv格式 const ffmpegCommand = ffmpeg(url) .addInputOption('-analyzeduration', '100000', '-max_delay', '1000000') .on('start', function () { console.log('Stream started.') }) .on('codecData', function () { console.log('Stream codecData.') }) .on('error', function (err) { console.log('An error occured: ', err.message) stream.end() }) .on('end', function () { console.log('Stream end!') stream.end() }) .outputFormat('flv').videoCodec('copy').noAudio() stream.on('close', function () { ffmpegCommand.kill('SIGKILL') }) try { // 执行命令 传输到实例流中返回给客户端 ffmpegCommand.pipe(stream) } catch (error) { console.log(error) }}
优点全部基于js。前端即可搞定。
参考:https://www.zhihu.com/question/29973696
队列的概念在 顺序队列 中，而使用循环队列的目的主要是规避假溢出造成的空间浪费，在使用循环队列处理假溢出时，主要有三种解决方案
本文提供后两种解决方案。
顺序队和循环队列是一种特殊的线性表，与顺序栈类似，都是使用一组地址连续的存储单元依次存放自队头到队尾的数据元素，同时附设队头(front)和队尾(rear)两个指针，但我们要明白一点，这个指针并不是指针变量，而是用来表示数组当中元素下标的位置。
本文使用切片来完成的循环队列，由于一开始使用三个参数的make关键字创建切片，在输出的结果中不包含nil值(看起来很舒服)，而且在验证的过程中发现使用append()函数时切片内置的cap会发生变化，在消除了种种障碍后得到了一个四不像的循环队列，即设置的指针是顺序队列的指针，但实际上进行的操作是顺序队列的操作。最后是对make()函数和append()函数的一些使用体验和小结，队列的应用放在链队好了。
官方描述(片段)
即切片是一个抽象层，底层是对数组的引用。
当我们使用
构建出来的切片的每个位置的值都被赋为interface类型的初始值nil，但是nil值也是有大小的。
而使用
来进行初始化时，虽然生成的切片中不包含nil值，但是无法通过设置的指针变量来完成入队和出队的操作，只能使用append()函数来进行操作
在go语言中，切片是一片连续的内存空间加上长度与容量的标识，比数组更为常用。使用 append 关键字向切片中追加元素也是常见的切片操作
正是基于此，在使用go语言完成循环队列时，首先想到的就是使用make(type, len, cap)关键字方式完成切片初始化，然后使用append()函数来操作该切片，但这一方式出现了很多问题。在使用append()函数时，切片的cap可能会发生变化，用不好就会发生扩容或收缩。最终造成的结果是一个四不像的结果，入队和出队操作变得与指针变量无关，失去了作为循环队列的意义，用在顺序队列还算合适。
参考博客：
Go语言中的Nil
Golang之nil
Go 语言设计与实现
学完了 net/http 和 fasthttp 两个HTTP协议接口的客户端实现，接下来就要开始Server的开发，不学不知道一学吓一跳，居然这两个库还支持Server的开发，太方便了。
相比于Java的HTTPServer开发基本上都是使用Spring或者Springboot框架，总是要配置各种配置类，各种 handle 对象。Golang的Server开发显得非常简单，就是因为特别简单，或者说没有形成特别统一的规范或者框架，我发现了很多实现方式，HTTP协议基于还是 net/http 和 fasthttp ，但是 handle 语法就多种多样了。
先复习一下： Golang语言HTTP客户端实践 、 Golang fasthttp实践 。
在Golang语言方面，实现某个功能的库可能会比较多，有机会还是要多跟同行交流，指不定就发现了更好用的库。下面我分享我学到的六种Server开发的实现Demo。
基于 net/http 实现，这是一种比较基础的，对于接口和 handle 映射关系处理并不优雅，不推荐使用。
第二种也是基于 net/http ，这种编写语法可以很好地解决第一种的问题，handle和path有了类似配置的语法，可读性提高了很多。
第三个基于 net/http 和 github.com/labstack/echo ，后者主要提供了 Echo 对象用来处理各类配置包括接口和handle映射，功能很丰富，可读性最佳。
第四种依然基于 net/http 实现，引入了 github.com/gin-gonic/gin 的路由，看起来接口和 handle 映射关系比较明晰了。
第五种基于 fasthttp 开发，使用都是 fasthttp 提供的API，可读性尚可，handle配置倒是更像Java了。
第六种依然基于 fasthttp ，用到了 github.com/buaazp/fasthttprouter ，有点奇怪两个居然不在一个GitHub仓库里。使用语法跟第三种方式有点类似，比较有条理，有利于阅读。
