1、直播的大致流程： APP端调用摄像头 -》 拍摄视频 -》 实时上传视频 -》 服务器端获取视频并解码 -》 存储成一小段一小段视频 -》服务器端进行推流 -》 H5或者app端通过一个url拉取视频流进行播放 实际的直播和用户播放的直播会有10秒左右或者更高的延迟，这一点对于后面开发比较重要，一定要注意这个点。
3、② 评论消息监听： 我们也通过websocket拉取评论消息，这里主要的问题在服务端压力上，有可能用户评论量很大的时候，服务器压力过大，出现断连的情况。也可能是用户网络断开，造成的断连。一方面后端通过他们的优化来提高承载力，一方面前端和后端进行配合优化。 我们每次连接websocket服务器的时候，前端会通过接口，拿到当前承载量最小的服务器地址进行连接。 websocket如果断连了的话，是不会获得任何消息的，所以保证功能可以使用，我们还会针对websocket进行心跳检测（检查是否断开连接）。
5、④ video 关于video，总结起来我们要解决的那些问题，或者有些不能解决的问题，归根到底是一个问题：兼容。兼容问题又可以分为两种：标签事件的兼容问题和浏览器表现的兼容问题。 先说video的事件兼容问题，之前测试过这一块，总之比较稳定和兼容性好点的事件如下图片圈出来的：
7、⑥ video推流监听 在文章最开始我们提到，推流会有一些不可控的情况，主播关闭摄像头，推送断流等，客户端断网。 这个时候在H5端的表现就是卡住，肯定会卡住。 一旦卡住之后，就算推流又重新开始了，video依然会卡在那里，不会有任何重新播放的样子。 如果推流重新开始，用户自己点击控制条的暂停，再点击播放，又可以正常播放了。 可我们不可能让用户一直点，因为你也不知道推流什么时候重新开始，或者什么时候不再是断网状态。 通过点击控制条的暂停，再点击播放便可以播放的规律，我们可以自己检查当前的状态，再用JS控制video暂停，再播放。
