对于直播中的用户交互大致可以分为：
送礼物
发表评论或者弹幕
对于送礼物，在 H5 端可以利用 DOM 和 CSS3 实现送礼物逻辑和一些特殊的礼物动画，实现技术难点不大。
对于弹幕来说，要稍微复杂一些，可能需要关注以下几点：
弹幕实时性，可以利用 webscoket 来实时发送和接收新的弹幕并渲染出来。
对于不支持 webscoket 的浏览器来说，只能降级为长轮询或者前端定时器发送请求来获取实时弹幕。
弹幕渲染时的动画和碰撞检测(即弹幕不重叠)等等
目前较为成熟的直播产品，大致都是以 Server 端和 H5 和 Native(android,ios)搭配实现直播：
基本是下图这个套路：
所以 H5 在整个直播中，还是有着重要的地位的！
最后，根据本次分享的内容，我这边实现了一个 iOS 端录制，推流，NGINX 接收流，同时分发的 HLS 直播流的一整套 Demo，感兴趣的同学可以看下面这个链接:
https://github.com/lvming6816077/LMVideoTest
好了，本次分享先到这里了，谢谢大家~
Q1: Demo 包含 iOS 端的 RTMP 播放不？
答：Demo 里面没有 RTMP 的播放，Demo 主要是提供录制，推流的。
Q2: 对于 H5 HLS 播放 卡顿问题，前端与 server 端，有什么配置上的优化吗？
答：server 端要做好分片策略，同时要将 ts 文件放在 CDN 上，前端这边可以尽量做到 DNS 缓存等，由于H5是使用的 video 标签，所以要修改 video 的播放优化，还是不那么容易。
Q3: 在手机推流时的码率是根据怎样的策略做选择的？不同机型和网络下如何保持流畅？
答：可以提供不同的视频码率来供用户选择，例如网速差的可以选择较为低清晰度的码率，网络好的用户可以选择更加清晰的码率，同时做好视频播放端的容错和异常处理等等。
Q4: RTMP 比起 HTTP 他的优势主要是几种在哪里？
答：RTMP 是基于 TCP 的保持的是长连接，而 HTTP 是一次性的，每次都要三次握手，所以对于直播来说还是 RTMP 好一些
Q5: 据我所知 nginx rtmp-module 好像性能不是很高…为什么会采用这个来作为后端服务？
答：这里只是 Demo 用了这个 nginx rtmp-module，其实也可已选择 SRS(simple-rtmp-server)都是可以的哈
Q6: 移动端这边怎么进行编码转码？用 ffmpeg 编译时很麻烦
答：关于 iOS 这边，其实不用关心转码问题，因为已经有了很多开源的库提供给我们了例如：x264 编码：https://github.com/kewlbear/x264-iosfaac 编码：https://github.com/fflydev/faac-ios-build
Q7: 您介绍的都是 Native 播放和还有 H5 的 video 标签播放, iOS 端有没有考虑过整个用原生的 OC 或者 Swift 实现?
答：关于播放端，其实真正体验好的还是要用 native 来实现的，而且 native 实现可以用 RTMP 来播放直播，延迟会好很多，H5 来播直播主要是考虑到易传播性好。
Q8: 在用户非常多的情况下，或者网络慢的情况下，有什么策略可以保证质量？
答：可以提供不同的视频码率来供用户选择，例如网速差的可以选择较为低清晰度的码率，网络好的用户可以选择更加清晰的码率，同时做好视频播放端的容错和异常处理等等。
Q9: 请问直播这块的测试中关注的几个指标是什么，有什么比较好的测试方法呢？
答：主要就是：
首次打开的白屏时间
直播中的卡顿和缓冲
直播的延时
Q10: 您提供的 Demo 为什么不是 H5 的呢 iOS 推流和 nginx 服务器都有，能不能提供一个前面第二张叶子美女直播那个页面的 Demo？
答：这个 Demo 你下载下拉运行的话，根据配置就可直接自己实现一个利用 H5 直播的页面，很简单，就像使用 video 标签一样，其他的样式你可以自己定制的。
Q11: HLS 的延时有没有比较好的方法解决？
答：HLS 确实是会有延迟，相对比较优的策略是调整好分片策略，在保证性能的情况下，和延迟达到平衡。
Q12: 如果加入视频电话功能，上面的结构需要作什么改变？视频电话的目的大概是：直播可以选择某一观众或者多个观众视频对话
答：视频电话，也就是说作为视频录制端的同时也作为视频播放端，所以实现实时电话简单就是：我在直播的同时观看别人的直播视频，别人在直播的同时观看我的直播视频，可以这样理解，上面的结构复制一份对调即可。
Q13: 如何实现滤镜功能？
答：一般是在视频录制之后，在转码前给视频数据增加滤镜功能，在 iOS 里可以使用一些滤镜库等等实现滤镜功能
Q14: 在 App 端如果不利用 H5 能实现直播吗？
答：可以啊，app 有更加丰富的播放接口，和开源播放器可以实现直播的。
Q15: 既然 HLS 有较高的延迟 为什么苹果推荐的的方式却是 HLS？
答：并不是说苹果主要推荐使用 HLS，对于 H5 来说目前只有这一种比较好的方式来播放直播视频，所以还是很期待苹果能对延迟问题做一些改进的。
Q16: 同滤镜问题，音频变声是如何实现的？
答：同样是可以在对音频转码前操作。
Q17: 如果针对网络较差的观看用户，是需要直播推流到服务器后做多份不同分辨率的拷贝，以适应不同网络的用户观看？如果是这样的话，对延迟会不会影响很大？ 毕竟编解码也是需要时间的.
答：这个其实本身就应该做的，对于网络差的用户，完全可以提供给他们较低码率的直播流来减少卡顿问题，延迟问题的话还是要根据具体使用哪种协议来定。
Q18: 推流目前大部分都是第三方在做，难度点在哪？然后目前业内比较成熟的主要哪些？
答：难点主要是服务器端的性能压力和分发直播流的效率，业界都已经有了较成熟的方案，例如腾讯云的直播。
