关于直播平台的技术实现

国内的好像都是 flash ？ youtube 好像有用 HTML5 实现的

百度一下 red 5
不过自己做效果不好，网络优化太差。有很多供应商。

我就发现服务器只是一个流量中转功能，压缩视频非常耗费 cpu ，所以一般都是直播间压缩好 h264 分片包，再上传到服务器缓存起来，然后再分发给每个手机客户端。

类似斗鱼直播间，用同一款手机，有些直播间兼容好，超清可以硬件解压，有些直播间兼容性不好，只能软件解压，一卡一卡的，和直播软件关系很大。

个人觉得，直播技术重点，还是在于 c++那种本地直播软件开发吧，视频压缩什么都是大坑。

https://www.v2ex.com/t/213713
自己搭可以看看 RTMP 相关的东西

搭着玩~
用 rtmp/rtsp
不在意延迟用 hls 分发(复用 http 基础

商业
还是买吧~

国内的直播、视频网站什么时候能换成 HTML5+H265 啊 0.0

@lisonfan 我觉得有点困难，我自己压着玩的 h265 片子，播放时都要用掉 50%的 cpu ，现在普通电脑的算力不是很适合 h265 ，而且个人测试的时候， h265 要比 h264 慢 5 倍。
ffmpeg 压片， windows 自带播放器解码， i5-4200h 笔记本 cpu 。

腾讯云的 互动直播 ILVB 可以做类似于 花椒，映客等这样的直播 App 吗？

注意看我之前的一篇帖子

七牛有相关的服务

有篇文章可以参考

鏖战双十一-阿里直播平台面临的技术挑战
http://www.infoq.com/cn/articles/alibaba-broadcast-platform-technology-challenges

最近折腾了一个手机直播，使用 RTMP ，服务端使用 SRS （ Github 搜一下就能找到）。

优点：技术方案相对简单，愿意的话，可以接入各种云平台（七牛、腾讯、百度等），可以使用云平台提供的播放器和录制端；也可以直接使用 CDN 的 RTMP 加速服务

缺点： RTMP 感觉更适合视频会议等场景，本身为 TCP/IP 协议; 相对 YY 、 QQ 视频，等互动较丰富的应用场景，实时性方面仍然有一定差距

我问过 YY 直播的前 CTO ，最开始的时候是用 red5 改的，后来完全跟 red5 没关系了。开源的方案基本上很难解决大规模的问题。

不知道是不是可以试试 WebRTC 的方法。

如果自己玩： red 5 的性能不太好，开源的方案推荐 https://github.com/j0sh/crtmpserver ，性能很好，网卡（千兆）全跑满时 CPU 和内存都无压力，不过要改东西就要求对 rtmp 协议和 C++编程都比较熟悉；网络优化（视频加速）自己搞就更麻烦了

如果有钱准备快铺：国内的 CDN 厂商基本都有 rtmp/rtsp 的加速服务，视频流都不用回源，也就是你自己不用准备视频服务器，视频流量全从 CDN 上走，自己准备一个播放器（ flash 、 H5 ）就行了

@wupher RTMP 是不是延时比较大？
YY ， QQ 视频好像都是自己开发的协议

另外，网络视频教学自己做用什么方案比较好？

自己搞很简单。 RMTP 就可以了。
rtmp 延迟是最小的了， 开源的里面， 另外还有 hls 。快速出活.
然后应该会有针对直播端的一些效果美化啊什么的吧， 好像现在很多美女主播网站就是这么干的， 估计干的狠的， 一个凤姐坐那里，出来就是半个林志玲了。

自己开发的肯定是大厂才这么搞吧。

感谢以上各位的耐心解答，基本心中了解了

chrome 开个直播， cpu 占用 50%+。

@livepps 在开个游戏， CPU 直接 100%，主频低根本没法流畅的直播游戏

@lisonfan 由于 h265 版权费高昂，目前世界上还没有一款支持 html5 h265 播放的浏览器，例如 Google 要在全套产品支持 h265 ，每年需要支付很数亿美元的版权费用。


@livepps
@vicence 国内直播占 CPU 的原因有两个：
1. Flash 本身就费 CPU ，用了别想低。。除了某些魔改过的 flash ，全部都是软解的。软解就软解，还没有任何优化，比起 ffmpeg 那一堆库出来的效率不知道低到哪里去了
2. 那些直播站还带弹幕，用 Flash 来实现弹幕本身就是一件非常蠢的事情， Flash 的文字渲染性能处在一种不可接受的程度。


HTML 5 直播有几种方案：
（当然为了照顾国内大环境， Flash fallback 还是得有的）
1. HLS
ajax 读分片， JS 转一下容器，加上 mp4 的 header/box ，用 media source extension 来播放，在移动端上可以直接播放。
优点： HTTP 协议， CDN 友好，还可以跟 iOS 必备的 HLS 用一套源，免得服务器切片一堆东西，支持所有主流浏览器。
缺点：比 dash 占用稍微高一点点，延迟至少一个 GOP + 网络传输时间。

2. DASH
ajax 读分片，利用 media source extension 来播放
优点： HTTP 协议， CDN 友好，比 HLS 稍快点，支持所有主流浏览器。
缺点：服务器需要切片 hls + dash 两套，降低 cdn 缓存利用率，延迟至少一个 GOP + 网络传输时间。

3. Matroska
真正意义上的流，<video> 标签直接播放，具体看这里： https://matroska.org/technical/streaming/index.html
注意别转码，别转码，别转码，直接封装 rtmp 推上来的 h264 进去，每个请求来的时候生成一份 metadata ，做重传，不用等到一个关键帧就可以播放。
优点：速度最快占用最低，延迟可以做到跟 rtmp 一个级别
缺点：只支持 Chromium-based 浏览器，没法用 CDN


直播不需要什么配置，大部分情况下都是重新封装一下视频容器，树莓派也能扛几千人。
除非你要转码，或者你用的 Java 写的媒体服务器。

有开源的 OBS 系统，在 github 上很多

学习

@dellch 延时还好，关键看用户量级和网络质量。我们的直播端使用手机源，并且人在国外。观看的用户主要在国内，人数大约才刚过百。视网络质量，有时确实会有卡顿情况，但总体能接受。我也去研究了一下 YY 的手机端直播，坦白的说也是有卡顿，声音延迟等问题。当然 YY 的服务量级远远超出我们。

如果真的对实时性要求非常高，也可以考虑不使用 RTMP 协议，比如基于 UDP 协议上自己进行封装（个人怀疑 QQ 视频的实现可能是这种方式）。但是这样做一来开发难度与周期会加大，二来也无法使用 CDN 通用的 RTMP 加速，可能视服务情况需要自己构建 CDN 加速服务。

希望能帮上你。话说如果你们打算自已研发 UDP 协议，能开源让我学习一下就更好了

^_^

可以看看这个 http://www.meilibo.net

mark 现在用阿里云
以后看看能不能去自己实现！？