暂时未有相关云产品技术能力~
牛哥@大牛直播SDK,致力于跨平台RTMP|RTSP推流、播放、轻量级RTSP服务和GB28181设备接入
好多开发者在做AR、VR或者教育类产品时,苦于如何在windows平台构建一个稳定且低延迟的RTSP或者RTMP播放器,如果基于Unity3d完全重新开发一个播放器,代价大、而且周期长,不适合快速出产品,我们认为当前最好的方式就是集成现有Native平台上成熟稳定播放器,回调rgb/yuv数据到上层,上层做绘制即可。
GOM player 是一款本身装有视频播放所需的解码,及占用系统资源少,并且能以最优秀的画质来观看多种格式影片的播放程序。
介绍移动端RTMP、RTSP播放器实时音量调节之前,我们之前也写过,为什么windows播放端加这样的接口,windows端播放器在多窗口大屏显示的场景下尤其需要,尽管我们老早就有了实时静音接口,相对实时静音来说,播放端实时音量调节粒度更细,从[0, 100],用户体验更好。
首先,虽然本文是介绍IE浏览器下OCX控件播放RTSP或RTMP,但这种方式并不推荐,毕竟它只能用于IE浏览器环境下,局限太大,而且随着微软IE浏览器的更新,不确定后续支持情况。当然,话说回来,如果是在特定的使用场景下,只需要某些版本IE浏览器支持,但对延迟和稳定性要求非常高,OCX控件方式也不失为一个好的选择。
在Google 推出Android 5.0的时候, Android Camera API 版本升级到了API2(android.hardware.camera2), 之前使用的API1(android.hardware.camera)就被标为 Deprecated 了。
RTMP或RTSP直播播放音量调节,主要用于多实例(多窗口)播放场景下,比如同时播放4路RTMP或RTSP流,如果音频全部打开,几路audio同时打开,可能会影响用户体验,我们通用的做法是支持播放端实时静音,更细粒度的做法是可以实时调节每一路RTMP/RTSP流的音量。
许多开发者在做智慧教室同屏亦或会议同屏时,基于Andriod平台采集屏幕并编码推送,往往遇到各种各样的问题,以下就我们开发过程中的一些技术考量做个分享,权当抛砖引玉:
内网环境下,为了满足内网无纸化/电子教室等内网超低延迟需求,避免让用户配置单独的服务器,好多开发者希望有RTSP的技术方案,用于小并发场景,特别是在组网环境好的有线环境下,使用RTSP服务配合组播,是也是好多开发者考量的因素之一。
好多开发者认为,无论是RTSP/RTMP推送端还是RTSP/RTMP播放端,涉及到录像,只要2个接口足矣:开始录像、停止录像。
好多开发者问道,既然有了OBS,你们为什么还要开发SmartPublisher? 的确,在我们进行Windows平台RTMP推送模块开发之前,市面上为数不多的Windows平台RTMP推流工具当属OBS了,不得不说,OBS是一款很好用的直播软件,它的优势在于,几乎可以直播所有直播平台,不需要每个直播平台都下载相关平台的专用直播软件,可以直播游戏,显示器,word,浏览器等。
好多开发者跟我们交流的时候提到,为什么有了VLC这种开源播放器,大牛直播SDK还要开发SmartPlayer?以下就针对VLC和SmartPlayer功能支持和涉及侧重,做个大概的比较:
RTSP认证类型 1. 基本认证(basic authentication):http 1.0提出的认证方案,其消息传输不经过加密转换因此存在严重的安全隐患; 1. 摘要认证(digest authentication):http 1.1提出的基本认证的替代方案,其消息经过MD5哈希转换因此具有更高的安全性。
随着手机淘汰的速度越来越快,大多数手机功能性能很强劲就不再使用了,以大牛直播SDK现有方案为例,本文探讨下,如何用废旧手机实现实时监控方案(把手机当摄像头做监控之用): 本方案需要准备一个手机作为采集手机(要求摄像头完好就行),采集到的数据,编码,然后推送到服务器,本地也可以实时录像,其他终端,作为远程监控端设备,拉取采集手机的实时音视频即可。
好多开发者提到,为什么大牛直播SDK的Android平台RTMP推送接口怎么这么多?不像一些开源或者商业RTMP推送一样,就几个接口,简单明了。
本文主要抛砖引玉,粗略介绍下Android平台RTMP/RTSP播放器中解码和绘制相关的部分(Github)。
好多开发者提到,RTMP播放器,不知道有哪些对标和考察指标,以下大概聊聊我们的一点经验,感兴趣的,可以关注 github: 1. 低延迟:大多数RTMP的播放都面向直播场景,如果延迟过大,严重影响体验,所以,低延迟是衡量一个好的RTMP播放器非常重要的指标,目前大牛直播SDK的RTMP直播播放延迟比开源播放器更优异(大牛直播SDK延迟在1秒左右,开源播放器如VLC,延迟在5-7秒),而且长时间运行下,大牛直播SDK播放端不会造成延迟累积,开源或第三方播放器,长时间运行,容易产生延迟累积;
很多开发者在做Android平台RTMP推流或轻量级RTSP服务(摄像头或同屏)时,总感觉接口不够用,以大牛直播SDK为例 (Github) 我们来总结下,我们常规需要支持的编码前音视频数据有哪些类型:
介绍:Ijkplayer 是Bilibili发布的基于 FFplay 的轻量级 Android/iOS 视频播放器。实现了跨平台功能,API 易于集成;编译配置可裁剪,方便控制安装包大小;支持硬件加速解码,更加省电;提供 Android 平台下应用弹幕集成的解决方案。
YU12(I420):
★目前海康录像机、网络摄像机,网络球机的RTSP单播取流格式如下(车载录像机不支持RTSP取流):
很多开发者提到,拉取的摄像机(一般RTSP流)或RTMP流,如果需要录制,需要考虑哪些因素,本文以大牛直播SDK的Windows平台拉流端录像为例(github),做个简单的介绍:
许多开发者,在做智慧教室同屏、会议同屏之类的方案时,基于Andriod平台的采集,往往遇到各种各样的问题,以下就几个点,抛砖引玉:
随着无纸化、智慧教室等场景的普及,好多企业或者开发者开始寻求更高效稳定低延迟的RTMP同屏方案,本文以大牛直播SDK(Github)的同屏demo(对应工程:SmartServicePublisherV2)为例,介绍下如何采集编码推送RTMP数据到流媒体服务器。
好多开发者苦于很难在unity3d下实现RTMP直播推送,本次以大牛直播SDK(Github)的Windows平台RTMP推送模块(以推摄像头为例,如需推屏幕数据,设置相关参数即可)为例,介绍下unity3d的RTMP推送集成。
前段时间,我们在 https://blog.csdn.net/renhui1112/article/details/104143794 提到“RTSP播放器开发过程中需要考虑哪些关键因素”,本次主要介绍,如何调用SDK实现RTSP/RTMP播放能力。
在Google 推出Android 5.0的时候, Android Camera API 版本升级到了API2(android.hardware.camera2), 之前使用的API1(android.hardware.camera)就被标为 Deprecated 了。
2015年,当我们试图在市面上找一款专供直播播放使用的低延迟播放器,来配合测试我们的RTMP推送模块使用时,居然发现没有一款好用的,市面上的,如VLC或Vitamio,说白了都是基于FFMPEG,在点播这块支持格式很多,也非常优异,但是直播这块,特别是RTMP,延迟要几秒钟,对如纯音频、纯视频播放,快速启播、网络异常状态处理、集成复杂度等各方面,支持非常差,而且因为功能强大,bug很多,除了行业内资深的开发者能驾驭,好多开发者甚至连编译整体环境,都要耗费很大的精力。
好多开发者一直反馈,Windows平台,做个推屏或者推摄像头,推RTMP或者RTSP出去,不知道哪些功能是必须的,哪些设计是可有可无的,还有就是,不知道如何选技术方案,以下是基于我们设计的Windows平台RTSP、RTMP直播推送模块,设计和使用说明,供大家参考。
为什么要设计轻量级RTSP服务 轻量级RTSP服务解决的核心痛点是避免用户或者开发者单独部署RTSP或者RTMP服务。 轻量级RTSP服务可满足内网无纸化/电子教室等内网超低延迟的低并发需求,避免让用户配置单独的服务器,大牛直播SDK在推送端发布了轻量级RTSP服务模块。
随着VR类、工业仿真、智慧城市等场景的快速发展,开发者对Unity3d低延迟的直播需求量越来越大,前两年,大牛直播SDK发布了Windows平台、Android平台和iOS平台的Unity3d RTMP和RTSP的播放,好多公司用起来体验都非常好,以下介绍大概实现流程。
好多情况下,一路RTSP或RTMP网络流过来后,想共享给更多局域网内的客户端播放,一般来说,有两种设计方案: 1. 拉取的RTSP或RTMP流,回调后的数据,转推RTMP服务器,内网部署一台RTMP服务器(如NGINX或者SRS)即可; 2. 拉取后的RTSP或RTMP流,回调后的数据,汇聚到内置RTSP服务模块,内网其他终端,只要拉RTSP流即可,无需再二次部署流媒体服务器。
好多开发者,在自研或者选择市面上的播放器的时候,除了常规的播放功能,还有很多点值得关注,如延迟、资源占用、网络异常处理、多实例支持、长时间运行稳定性等。以下是我们开发直播播放器过程中,考虑的部分关键因素(以Windows平台RTSP直播播放为例,如需下载demo源码,可以到 Github 下载):
在直播系统中,除了直播音视频之外,有时候还想从主播端发布文本信息等,这些信息可以不通过视频传输通道发送给用户播放端,但如果传输的数据想和视频保持精准同步,那最好的办法就是这些信息和视频数据打包在一起传输,并通过h264 sei方式就可以把数据放入h264 Access Unit中传输。
一个好的转发模块,首先要低延迟!其次足够稳定、灵活、有状态反馈机制、资源占用低,跨平台,最好以接口形式提供,便于第三方系统集成。
好多开发者一直搞不清轻量级RTSP服务SDK和RTSP推流SDK的区别(Github下载地址),以下是相关区别:
基于智慧教室或是会议的技术方案,一般主要是涉及到屏幕采集和推送,整体技术方案这块,一般建议走RTMP,说到这里,好人开发者提到,市面上也有RTSP的技术方案,甚至RTSP组播方案,这块,大牛直播SDK Github 也做过相关对比,总的来说60人智慧教室或类似同屏场景下,最可靠的还是RTMP的解决方案(不赘述,具体可自行测试对比)。
大牛直播SDK多路RTMP/RTSP转RTMP转发软件,系原有转发SDK基础上,官方推出的Windows平台定制版。在秉承低延迟、灵活稳定、低资源占用的前提下,客户无需关注开发细节,只需图形化配置转发等各类参数,实现产品快速上线目的。
为满足内网无纸化/电子教室等内网超低延迟需求,避免让用户配置单独的服务器,大牛直播SDK在推送端发布了轻量级RTSP服务SDK: 简单来说,之前推送端SDK支持的功能,内置轻量级RTSP服务SDK后,功能继续支持。
很多开发者希望Android播放端实现视频窗口的放大缩小功能,为此,我们做了个简单的demo,通过播放端回调RGB数据,直接在上层view操作处理即可,Github:https://github.com/daniulive/SmarterStreaming
HTTP将数据作为文件处理,所以HTTP不是流媒体协议,RTMP和RTSP是流媒体协议。 RTMP是Adobe的私有协议,未完全公开,RTSP和HTTP是共有协议。 RTMP一般传输flv,f4v格式流,RTSP传输ts,MP4格式流,HTTP没有特定的流。 RTSP一般需要2-3个通道,数据和命令通道分开,RTMP和HTTP在一个通道上传输命令和数据。
来源:https://github.com/daniulive/SmarterStreaming
一个好的转发模块,首先要低延迟!其次足够稳定、灵活、有状态反馈机制、资源占用低,如果可以跨平台,还能以SDK形式提供,会给开发者提供更大的便利!
好多开发者一直苦恼于如何在IE浏览器环境下,构建低延迟的RTSP或RTMP播放,对于RTSP流来说,好多公司通常的做法是把RTSP转RTMP,然后分发到RTMP服务器,然后服务器转http-flv出来,浏览器直接播放http-flv流,亦或通过flash控件直接播放RTMP流,还有就是,转hls流出来,缺点是hls流延迟更大。
相信大家在做rtmp、rtsp直播的时候,最大的困惑就是选个靠谱的播放器,直播的延迟,一定意义上说,90%的取决于播放器的好坏。
细心的开发者会发现,海康大华之类摄像机厂商,除了常规的H.264、H.265(HEVC)编码外,主码流或子码流依然会有MJPEG编码选项。
大牛直播录像SDK可作为单独功能模块使用(如同时多路录像存档),亦分布于以下模块,和其他模块组合调用: windows/android/iOS推送端SDK Demo; windows/android/iOS播放端SDK Demo;
好多企业或开发者给我们反映,他们期望能把外网的rtsp或rtmp流,直接拉取注入到内网流媒体服务器,保证内网用户,无需访问,直接链接到内网服务器就可以观看到公网rtmp/rtsp流。
MQTT代理服务器特性对比
二话不说,NO 图 NO BB(以大牛直播SDK播放海康摄像机RTSP H.265流为例):
为满足内网无纸化/电子教室等内网超低延迟需求,避免让用户配置单独的服务器,大牛直播SDK在推送端发布了轻量级RTSP服务SDK。 内置轻量级RTSP服务后,延迟更低,体验更好(内网环境下,200-400毫秒)。