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。（商业用途需付费使用）
示意图如下所示：
推流--------------服务器转发--------------拉流
方法一览：
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
如果是udp的话 发送方丢包可能性不大，可能是路由设备或者客户端接收逻辑垃圾 导致客户端丢码。但是rtp提供了tcp方式传输，如果你tcp方式发现也丢得话，那估计就是发送逻辑的问题。一般都是send的时候返回错误而没有判断造成的。建议使用多线程发送，将网络和其他逻辑分开，网络部分最好使用异步。我做过rtsp服务器，主要就是io线程不能干其他的，这样就能确保数据即时发送出去。当然如果tcp的话带宽限制你发送不了那么快可以适当的从数据源这里就丢一些非关键帧b或者p。这样就能有稍微好点的实时性。最后一句话，开发rtsp之前要计算好带宽，连接数，码流大小这些数据。
是，不过很多播放起不支持RTSP协议维金服务>>分类资讯>>技术应用
基于RTSP协议流媒体服务器的实现
文章类型：技术应用 文章收录时间：2002-11-11 10:39:03 此前阅读：8666
--------------------------------------------------------------------------------
RTSP，实时流协议，是一个C/S多媒体节目协议，它可以控制流媒体数据在IP网络上的发送，同时提供用于音频和视频流的“VCR模式”远程控制功能，如停止、快进、快退和定位。同时RTSP又是一个应用层协议
，用来与诸如RTP、RSVP等更低层的协议一起，提供基于Internet的整套流化服务。基于RTSP协议流媒体服务器的实现方案可以让流媒体在IP上自由翱翔。
RTSP协议
1．协议特点
RTSP协议具有如下的特点：
● 可扩展性：新方法和参数很容易加入RTSP。
● 易解析：RTSP可由标准 HTTP或MIME解析器解析。
● 安全：RTSP使用网页安全机制。
● 独立于传输：RTSP传输通道，可使用不可靠数据包协议（UDP）或可靠数据包协议（RDP），如要实现应用级可靠，可使用诸如TCP的可靠流协议。
● 记录设备控制：协议可控制记录和回放设备。
● 适合专业应用：通过SMPTE 时标，RTSP支持帧级精度，允许远程数字编辑。
● 演示描述中立：协议未强加特殊演示或元文件，可传送所用格式类型；然而，演示描述至少需包含一个RTSP URI。
● 代理与防火墙友好：协议可由应用和传输层防火墙处理。防火墙需要理解SETUP方法，为UDP媒体流打开一个“缺口”。
● 适当的服务器控制：如用户启动一个流，则也可以停止一个流。
● 传输协调：实际处理连续媒体流前，用户可协调传输方法。
● 性能协调：如基本特征无效，则必须有一些清理机制让用户决定那种方法不生效。这允许用户提出适合自己的界面。
2．同其他协议的关系
RTSP在功能上与HTTP有重叠，最明显的交叉是在流媒体内容的发布上——大多是通过网页进行的。目前的协议规范同时允许网页服务器和流媒体服务器支持RTSP实现。例如，演示描述可通过HTTP或RTSP获取，这样减少了基于浏览器情况下的往返传递时间，同时也支持独立的RTSP 服务器与不依赖HTTP的客户端通信。
但是，RTSP与HTTP 的本质差别在于以下五个方面
● RTSP和HTTP是两个不同的协议，它们采用不同的方法和协议标志符。
● RTSP协议的数据发送不占用协议带宽，并且以不同的协议发送。
● HTTP是一个不对称协议，客户端发出请求，服务器应答。在RTSP中，客户端和服务器都可发出请求，且请求是有状态的。
● HTTP是一个无状态协议，而RTSP在任何情况下，必须保持一定状态，以便在请求确认后的很长时间内，仍可设置参数，控制媒体流。
● RTSP使用ISO 10646（UTF-8）定义，而不使用ISO 8859-1定义，保持与当前的HTML一致。
虽然大多数实时媒体采用RTP作为传输协议，但RTSP并不绑定RTP。
重用HTTP的功能至少在两个方面有好处:安全和代理。由于要求非常接近，因此在缓存、代理和授权上采用HTTP功能是有价值的。
RTSP的实现
RTSP在流媒体传输过程中，仅仅为双方建立连接，并不具备任何智能，也就不能很好地应付难以预料的网络状态。因此，必须在它原有功能的基础上，进行改进。
1、初始化
在建立连接之前，客户端应向服务器提出测试请求，即要求服务器向客户端发送相应的测试数据包。初始化的目的，是为了获取客户端和服务器之间的一些网络参数，估测基本网络状况，并以此选择相应的网络传输协议，使客户端获得最佳观看效果。
接到这个请求之后，服务器将根据自身情况进行如下测试：
● 利用同客户端建立的RTSP通道，采用TCP协议，下发测试数据包。
● 采用UDP协议，向客户端下发测试数据包。
测试数据包仅做测试用，上面带有相应的时间和顺序信息，其内部数据并无任何意义。
需要向RTSP增加一个新的方法TEST，以支持这种传输前的测试工作。
2、TCP传输
如果在TCP测试中，客户端反馈良好，即丢包率在可承受范围之内，并且在规定时间内到达，那么就认为客户端同服务器之间的网络状况良好， 可以采用RTP over TCP的方式发送数据。由于TCP没有丢包（其自身具有重传机制），网络状况又属于良好，因此客户端将有较高的视听享受。
当子网内存在防火墙时，就需要采用RTSP附加数据传输方式。即把音视频数据直接打包，在RTSP通信信道内传输。这种传输方式也存在一定的问题：
● 传输过程中，只是把音视频文件当成一个普通文件来处理，而没有考虑到它的音视频特性，不利于以后的扩展。
● 音频与视频文件没有分离，不利于某些特殊需求的场合。例如，客户端需要对音、视频做不同的处理。
● 客户端的反馈和RTSP的控制信息也是通过同一条RTSP信道传送，因此控制效率不高。
因此，一般情况下，都默认使用RTP over TCP的方式发送数据。
3、UDP传输
如果在TCP测试中，客户端的反馈存在比较大的问题，即网络情况不理想，就应该考虑进行UDP测试。
目前初步采取的措施，在服务器端准备了两种码率的视频文件——高码率和低码率。
收到客户端的TEST方法后，将采用UDP协议下发测试包。采取的策略是每间隔2秒，下发一个1500字节的UDP数据包。当丢包率处于一定范围（75％～85％）之内，就认为客户端的网络状况基本良好，可以下发高码率的电影文件否则，认为测试不成功，由于网络状况的限制，仅对客户端下发低码率的电影文件。
在基于UDP的播放过程中，可能会出现轻微的马赛克，这是完全可以接受的。这些马赛克出现的主要原因是：
● 不可靠连接造成的网络丢包，为客户端被动丢包。
● 高质量文件（DVD－>MP4）的高数据量，使得客户端解码线程和显示线程出现拥塞，从而出现客户端主动丢包。
但从整体而言，UDP传输消耗的带宽，要比TCP小许多。在一般的视频点播要求下，使用基于UDP的传输线路，是完全可以满足要求的。
4、传输反馈
在传输过程中，主要采取的方式是RTP over TCP或RTP over UDP，因此，在RTP端口之外，还存在一个回传端口RTCP。
在服务器收到客户端的RTCP回传信息后，需要对其进行判断。如果客户端的丢包率、解码率等指标在一定限度之下，就认为目前传送的视频文件可令客户端获得最大程度的音视频享受否则，考虑改为传输更低码率的视频文件或放弃这次RTSP会话，以避免更大范围的拥塞。
5、实际效果
采取如上方法设计的系统，可以满足视频点播的基本要求，避免了服务器视频文件下发的盲目性，同时使客户端应用效果最好。
引入智能流技术
随着针对流媒体技术研究的不断深入，简单的流媒体实现已经不能满足人们日益增长的网络文化需求。即使在宽带条件下，当网络用户达到一定限额时，简单的流媒体技术将面临着网络拥塞、丢包等常见的网络问题。因此，如何在网络出现异常的情况下，依然保证客户端音视频享受的最大化，就成为现在研究的热点。
一种解决方法是服务器减少发送给客户端的数据而阻止再缓冲，在RealSystem 5.0中，这种方法称为“视频流瘦化”。这种方法的限制是RealVideo文件必须是一种数据速率设计，结果可通过抽取内部帧扩展到更低速率，导致质量较低，离原始数据速率越远，质量越差。
另一种解决方法是根据不同连接速率创建多个文件，根据用户连接，服务器发送相应文件，这种方法带来制作和管理上的困难，而且，用户连接是动态变化的，服务器也无法实时协调。
智能流技术通过两种途径克服带宽协调和流瘦化:首先，确立一个编码框架，允许不同速率的多个流同时编码，合并到同一个文件中；第二，采用一种复杂客户/服务器机制探测带宽变化。
针对软件、设备和数据传输速度上的差别，用户以不同带宽浏览音视频内容。为满足客户要求，Real Networks公司编码、记录不同速率下媒体数据，并保存在单一文件中，此文件被称为智能流文件，即创建可扩展流式文件。当客户端发出请求时，它将其带宽容量传给服务器，媒体服务器根据客户带宽将智能流文件相应部分传送给用户。以此方式，用户可使用最优质的传输，制作人员只需要压缩一次，管理员也只需要维护单一文件，而媒体服务器根据所得带宽自动切换。智能流通过描述Internet上变化的带宽特点来发送高质量媒体并保证其可靠性，并对混合连接环境的内容授权提供了解决方法。这样流媒体实现方式如下：对所有连接速率环境创建一个文件。在混合环境下以不同速率传送媒体。根据网络的变化情况，无缝切换到其他速率。关键帧优先，音频比部分视频帧数据更重要，向后兼容老版本RealPlayer。
