前言
劳动节在家下载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缓冲做的不好,如果是服务器卡了一下,需要重新刷新