视频、直播等基础知识什么是视频？首先我们需要理解一个最基本的概念：视频。从感性的角度来看，视频就是一部充满趣味的影片，可以是电影，可以是短片，是一连贯的视觉冲击力表现丰富的画面和音频。但从理性的角度来看，视频是一种有结构的数据，用工程的语言解释，我们可以把视频剖析成如下结构：
内容元素(Content)
编码格式(Codec)
容器封装(Container)
任何一个视频Video文件，从结构上讲，都是这样一种组成方式：
视频的实时传输简而言之，理性的认知视频的结构后，有助于我们理解视频直播。如果视频是一种“有结构的数据”，那么视频直播无疑是实时传输这种“有结构的数据”（视频）的方式。那么一个显而易见的问题是：如何实时（Real-Time）传输这种“有结构的数据”（视频）呢？这里边一个悖论是：一个经过容器（Container）封装后的视频，一定是不可变的(Immutable)视频文件，不可变的(Immutable)的视频文件已经是一个生产结果，根据“相对论”，而这个生产结果显然不可能精确到实时的程度，它已经是一段时空的记忆。因此视频直播，一定是一个“边生产，边传输，边消费”的过程。这意味着，我们需要更近一步了解视频从原始的内容元素(图像和音频)到成品(视频文件)之前的中间过程(编码)。
GOP(GroupofPictures)是一组连续的画面，由一张I帧和数张B/P帧组成，是视频图像编码器和解码器存取的基本单位，它的排列顺序将会一直重复到影像结束。
I帧是内部编码帧（也称为关键帧），P帧是前向预测帧（前向参考帧），B帧是双向内插帧（双向参考帧）。简单地讲，I帧是一个完整的画面，而P帧和B帧记录的是相对于I帧的变化。如果没有I帧，P帧和B帧就无法解码。
小结一下，一个视频(Video)，其图像部分的数据是一组GOP的集合,而单个GOP则是一组I/P/B帧图像的集合。在这样的一种几何关系中，Video好比一个“物体”，GOP好比“分子”，I/P/B帧的图像则好比“原子”。想象一下，如果我们把传输一个“物体”，改成传输一个一个的“原子”，将最小颗粒以光速传送，那么以人的生物肉眼来感知，将是一种怎样的体验？
直播的业务逻辑如下是一个最精简的一对多直播业务模型，以及各个层级之间的协议。
各协议差异对比如下
根据爱因斯坦的狭义相对论，光速是所有能量、物质和信息运动所能达到的最高速度，这个结论给传播速度设定了上限。因此，即便我们肉眼感觉到的实时，实际上也是有一定的延迟。
于RTMP/HLS是基于TCP之上的应用层协议，TCP三次握手，四次挥手，慢启动过程中的每一次往返来回，都会加上一次往返耗时(RTT)，这些交互过程都会增加延迟。
其次根据TCP丢包重传特性，网络抖动可能导致丢包重传，也会间接导致延迟加大。
移动直播场景的坑与规避措施不同芯片平台上的编码差异
低端设备如何上高性能地采集和编码？
例如Camera采集输出的可能是图片，一张图的体积并不会小，如果采集的频次很高，编码的帧率很高，每张图都经过编码器，那么编码器又可能会出现过载。这个时候，可以考虑在编码前，不影响画质的前提下（前面我们讲过帧率的微观意义），进行选择性丢帧，以此降低编码环节的功耗开销。弱网下如何保障高清流畅推流
移动网络下，通常容易遇到网络不稳定，连接被重置，断线重连，一方面频繁重连，建立连接需要开销。另一方面尤其是发生GPRS/2G/3G/4G切换时，带宽可能出现瓶颈。当带宽不够，帧率较高/码率较高的内容较难发送出去，这个时候就需要可变码率支持。即在推流端，可检测网络状态和简单测速，动态来切换码率，以保障网络切换时的推流流畅。其次编码、封包、推流这一部分的逻辑也可以做微调，可以尝试选择性丢帧，比如优先丢视频参考帧（不丢I帧和音频帧)，这样也可以减少要传输的数据内容，但同时又达到了不影响画质和版视听流畅的目的。需要区分直播流的状态和业务状态直播是媒体流、APP的交互是API信令流，两者的状态不能混为一谈。尤其是不能基于APP的交互的API状态来判断直播流的状态。