凯亚利用直播推流技术请大家看电影

前言

劳动节在家下载dotnetty 代码添加到到kayak项目中,偶然看到项目https://github.com/cuteant/SpanNetty,然后参考了代码,然后spannetty 性能稳定性让我 非常惊讶,比dotnetty 靠谱多了,今天我用直播推流看了几部电影,内存一直稳定在80mb左右,然后放假期间,凯亚利用直播推流电影,大家闲暇之余可以看看。 几百块的服务器,流量带宽只有8mb ,下行速度只有1mb左右,只能支持2个人同时观看,等凯亚平台有流媒体管理会迁移到更好的服务器。到时候大家可以尽情观看。

HttpFlv:http://117.72.121.2:281/httpflv.html

rtmp:rtmp://117.72.121.2:76/live1/livestream2

播放时间: 5月3日至5月5日 21:00

凯亚 (Kayak) 是什么?

凯亚(Kayak)是基于.NET6.0软件环境下的surging微服务引擎进行开发的, 平台包含了微服务和物联网平台。支持异步和响应式编程开发,功能包含了物模型,设备,产品,网络组件的统一管理和微服务平台下的注册中心,服务路由,模块,中间服务等管理。还有多协议适配(TCP,MQTT,UDP,CoAP,HTTP,Grpc,websocket,rtmp,httpflv,webservice,等),通过灵活多样的配置适配能够接入不同厂家不同协议等设备。并且通过设备告警,消息通知,数据可视化等功能。能够让你能快速建立起微服务物联网平台系统。

凯亚物联网平台:http://117.72.121.2:3100(用户名:fanly 密码:123456)

链路跟踪Skywalking V8:http://117.72.121.2:8080/

surging 微服务引擎开源地址:https://github.com/fanliang11/surging(后面surging 会移动到microsurging进行维护)

常见的直播协议

国内常见的直播协议有几个:RTMP、HLS、HTTP-FLV,下面我们来一一介绍。

RTMP,全称 Real Time Messaging Protocol,即实时消息传送协议。Adobe 公司为 Flash 播放器和服务器之间音视频数据传输开发的私有协议。工作在 TCP 之上的明文协议,默认使用端口 1935。协议中的基本数据单元成为消息(Message),传输的过程中消息会被拆分为更小的消息块(Chunk)单元。最后将分割后的消息块通过 TCP 协议传输,接收端再反解接收的消息块恢复成流媒体数据。

RTMP 主要有以下几个优点:RTMP 是专为流媒体开发的协议,对底层的优化比其它协议更加优秀,同时它 Adobe Flash 支持好,基本上所有的编码器(摄像头之类)都支持 RTMP 输出。现在 PC 市场巨大,PC 主要是 Windows,Windows 的浏览器基本上都支持 Flash。另外RTMP适合长时间播放,曾经有过测试,连续 10 天多连续播放没有出现问题。最后 RTMP 的延迟相对较低,一般延时在 1-3s 之间,一般的视频会议,互动式直播,完全是够用的。

当然 RTMP 并没有尽善尽美,它也有不足的地方。一方面是它是基于 TCP 传输,非公共端口,可能会被防火墙阻拦;另一方面,也是比较坑的一方面是 RTMP 为 Adobe 私有协议,很多设备无法播放,特别是在 iOS 端,需要使用第三方解码器才能播放。

FLV (Flash Video) 是 Adobe 公司推出的另一种视频格式,是一种在网络上传输的流媒体数据存储容器格式。其格式相对简单轻量,不需要很大的媒体头部信息。整个 FLV 由 The FLV Header, The FLV Body 以及其它 Tag 组成。因此加载速度极快。采用 FLV 格式封装的文件后缀为 .flv。

而我们所说的 HTTP-FLV 即将流媒体数据封装成 FLV 格式,然后通过 HTTP 协议传输给客户端。

HTTP-FLV 依靠 MIME 的特性,根据协议中的 Content-Type 来选择相应的程序去处理相应的内容,使得流媒体可以通过 HTTP 传输。相较于 RTMP 协议,HTTP-FLV 能够好的穿透防火墙,它是基于 HTTP/80 传输,有效避免被防火墙拦截。除此之外,它可以通过 HTTP 302 跳转灵活调度/负载均衡,支持使用 HTTPS 加密传输,也能够兼容支持 Android,iOS 的移动端。

说了这么多优点,也来顺便说下 HTTP-FLV 的缺点,由于它的传输特性,会让流媒体资源缓存在本地客户端,在保密性方面不够好。因为网络流量较大,它也不适合做拉流协议。

上述两个协议都是有Adobe公司推出的,而下面要讲的 HLS (HTTP Live Streaming) 则是苹果公司基于 HTTP 的流媒体传输协议。主要应用于 iOS 设备,包含(iPhone, iPad, iPod touch) 以及 Mac OSX 提供音视频直播服务和录制内容(点播)等服务。

相对于常见的流媒体协议,HLS 最大的不同在于它并不是一下请求完整的数据流。它会在服务器端将流媒体数据切割成连续的时长较短的 ts 小文件,并通过 M3U8 索引文件按序访问 ts 文件。客户端只要不停的按序播放从服务器获取到的文件,从而实现播放音视频。

流媒体协议 RTMP, HTTP-FLV, HLS 简单对比

|----------|------|------|-------|
| 协议 | 传输协议 | 格式 | 延时 |
| rtmp | Tcp | flv | 1-3秒 |
| http-flv | http | flv | 1-3秒 |
| hls | http | m3u8 | 4-10秒 |

RTMP 协议为流媒体而设计,在推流中用的比较多,同时大多 CDN 厂商支持RTMP 协议。

HTTP-FLV 使用类似 RTMP流式的 HTTP 长连接,需由特定流媒体服务器分发的,兼顾两者的优点。以及可以复用现有 HTTP 分发资源的流式协议。它的实时性和 RTMP 相等,与 RTMP 相比又省去了部分协议交互时间,首屏时间更短,可拓展的功能也更多。

HLS 作为苹果提出的直播协议,在 iOS 端占据了不可撼动的地位,Android 端也同时提供相应的支持。

如何架构实现

rtmp 协议架构图

调度服务网关是针对于外网服务调用, , 提供基于rest 查询流对应的服务器地址。

直播终端通过调度服务网关获取的rtmp 服务地址,通过地址进行推流,rtmp服务获取到数据后,然后转推到其它的rtmp服务上,rtmp再把流推给订阅的客户端

http-flv 架构图

以上是通过rtmp 服务转推给http-flv 订阅的客户端

效果如下:

终端是ffmpeg进行视频推流

从以上图片可以看出,直播推流1小时零8分,内存占用83mb。

等后面迁移到好的服务器,有带宽了我会利用OBS直播讲课,它会推流到凯亚平台,然后再下发到客户端

httpflv 和rtmp 同时观看

建议用potplayer播放器观看rtmp 视频流,不卡顿,httflv缓冲做的不好,如果是服务器卡了一下,需要重新刷新

相关推荐
fanly115 天前
使用的架构是否满足微服务设计思想?
surging microservice·surging
fanly117 天前
凯亚IOT平台在线测试MQTT接入设备
surging microservice·surging
fanly1110 天前
凯亚物联网平台如何通过MQTT网络组件接入设备
surging microservice·surging
fanly1116 天前
.net clr 8年才修复的BUG,你让我损失太多了
surging microservice
fanly1120 天前
surging 集成SuperSocket预发布版本2.0
surging microservice
fanly111 个月前
通过jmeter压测surging
surging microservice
fanly111 个月前
帮客户解决基于surging的物流速运网关内存泄漏问题
surging microservice
fanly111 个月前
从木舟平台来庖丁解牛微服务
surging microservice
fanly111 个月前
针对于基于surging的dotnetty组件内存泄漏问题
surging microservice