Android 直播概念一二

    Android上目前直播使用的传输协议一般有如下几种：RTP（real time protocol）、RTCP（real time control protocol）、RTSP（real time streaming protocol）、RTMP（real time messaging protocol）、HLS（http live streaming），其中用得最多的是RTMP和HLS，RTMP延迟小、HLS兼容性强。

RTSP、 RTMP、HTTP的共同点、区别
共同点：
1：RTSP 、RTMP 、HTTP都是在应用层。
2： 理论上RTSP、 RTMP、HTTP都可以做直播和点播，但一般做直播用RTSP 、RTMP，做点播用HTTP。做视频会议的时候原来用SIP协议，现在基本上被RTMP协议取代了。

区别：
1：HTTP: 即超文本传送协议(FTP即文件传输协议)。
      RTSP:（Real Time Streaming Protocol），实时流传输协议。
      RTMP:（Real Time Messaging Protocol），实时消息传输协议。
2：HTTP将所有的数据作为文件做处理，它不是流媒体协议。RTMP和RTSP协议是流媒体协议。
3：RTMP协议是Adobe的私有协议,未完全公开，RTSP协议和HTTP协议是共有协议，并有专门机构做维护。
4：RTMP协议一般传输的是flv，f4v格式流，RTSP协议一般传输的是ts,mp4格式的流。HTTP没有特定的流。
5：RTSP传输一般需要2-3个通道，命令和数据通道分离，HTTP和RTMP一般在TCP一个通道上传输命令和数据。

RTSP、RTCP、RTP区别
1：RTSP实时流协议
作为一个应用层协议，RTSP提供了一个可供扩展的框架，它的意义在于使得实时流媒体数据的受控和点播变得可能。总的说来，RTSP是一个流媒体表示 协议，主要用来控制具有实时特性的数据发送，但它本身并不传输数据，而是必须依赖于下层传输协议所提供的某些服务。RTSP可以对流媒体提供诸如播放、暂 停、快进等操作，它负责定义具体的控制消息、操作方法、状态码等，此外还描述了与RTP间的交互操作（RFC2326）。

2：RTCP控制协议
RTCP控制协议需要与RTP数据协议一起配合使用，当应用程序启动一个RTP会话时将同时占用两个端口，分别供RTP和RTCP使用。RTP本身并 不能为按序传输数据包提供可靠的保证，也不提供流量控制和拥塞控制，这些都由RTCP来负责完成。通常RTCP会采用与RTP相同的分发机制，向会话中的 所有成员周期性地发送控制信息，应用程序通过接收这些数据，从中获取会话参与者的相关资料，以及网络状况、分组丢失概率等反馈信息，从而能够对服务质量进 行控制或者对网络状况进行诊断。
RTCP协议的功能是通过不同的RTCP数据报来实现的，主要有如下几种类型：
SR：发送端报告，所谓发送端是指发出RTP数据报的应用程序或者终端，发送端同时也可以是接收端。(SERVER定时间发送给CLIENT)。
RR：接收端报告，所谓接收端是指仅接收但不发送RTP数据报的应用程序或者终端。(SERVER接收CLIENT端发送过来的响应)。
SDES：源描述，主要功能是作为会话成员有关标识信息的载体，如用户名、邮件地址、电话号码等，此外还具有向会话成员传达会话控制信息的功能。
BYE：通知离开，主要功能是指示某一个或者几个源不再有效，即通知会话中的其他成员自己将退出会话。
APP：由应用程序自己定义，解决了RTCP的扩展性问题，并且为协议的实现者提供了很大的灵活性。

3：RTP数据协议
RTP数据协议负责对流媒体数据进行封包并实现媒体流的实时传输，每一个RTP数据报都由头部（Header）和负载（Payload）两个部分组成，其中头部前12个字节的含义是固定的，而负载则可以是音频或者视频数据。
RTP用到的地方就是 PLAY ，服务器往客户端传输数据用UDP协议，RTP是在传输数据的前面加了个12字节的头(描述信息)。
RTP载荷封装设计本文的网络传输是基于IP协议，所以最大传输单元(MTU)最大为1500字节，在使用IP／UDP／RTP的协议层次结构的时候，这 其中包括至少20字节的IP头，8字节的UDP头，以及12字节的RTP头。这样，头信息至少要占用40个字节，那么RTP载荷的最大尺寸为1460字 节。以H264 为例，如果一帧数据大于1460，则需要分片打包，然后到接收端再拆包，组合成一帧数据，进行解码播放。

直播数据源的获取有以下几种，

    1：通过Camera的setPreviewCallback或者setPreviewCallbackWithBuffer来获取一帧帧的数据，获取到的数据为YUV格式，常用格式有两种：NV21 / YV12，默认格式为NV21的，可调用setPreviewFormat()方法设置为我们需要的格式（需系统支持）。

    2：通过MediaRecoder来获取数据。

一般来说，通过Camera获取到的是YUV格式的数据，需要将它转化为H264等高压缩比格式（通过MediaCodec或者ffmpeg之类）再利用RTMP等协议进行传送，而通过MediaRecorder录制时，因为可以设置编码格式，所以获取到的直接是H264等高压缩比格式，无需转换。

YUV数据格式：

YUV，分为三个分量，“Y”表示明亮度（Luminance或Luma），也就是灰度值；而“U”和“V” 表示的则是色度（Chrominance或Chroma），作用是描述影像色彩及饱和度，用于指定像素的颜色。

与我们熟知的RGB类似，YUV也是一种颜色编码方法，主要用于电视系统以及模拟视频领域，它将亮度信息（Y）与色彩信息（UV）分离，没有UV信息一样可以显示完整的图像，只不过是黑白的，这样的设计很好地解决了彩色电视机与黑白电视的兼容问题。并且，YUV不像RGB那样要求三个独立的视频信号同时传输，所以用YUV方式传送占用极少的频宽。
YUV码流的存储格式其实与其采样的方式密切相关，主流的采样方式有三种，YUV4:4:4，YUV4:2:2，YUV4:2:0

YUV格式有三大类：planar、semi-planar和packed。
对于planar的YUV格式，先连续存储所有像素点的Y，紧接着存储所有像素点的U，随后是所有像素点的V。每个分量占一块地方，其中Y为width*height，而U、V合占Y的一半，该种格式每个像素占12比特。根据U、V的顺序，分出2种格式，U前V后即YUV420P，也叫I420，V前U后，叫YV12(YV表示Y后面跟着V，12表示12bit)。

对于semi-planar的YUV格式，Y和UV是分开存放的，但UV共享一个planar,即先存储所有像素点的Y数据，然后存储UV数据。U/V数据是交替存储在同一块内存区域。根据U、V的顺序，又有2种，U前V后叫NV12，在国内好像很多人叫它为YUV420SP格式；V前U后叫NV21。这种格式似乎比NV16稍受欢迎。

对于packed的YUV格式，每个像素点的Y,U,V是连续交替存储的。

视频数据的常用编码格式一般有H264、MPEG4等等。H.264，MPEG-4,MPEG-2等这些都是压缩算法，毕竟带宽是有限的，为了获得更好的图像的传输和显示效果，就不断的想办法去掉一些信息，转换一些信息等等，这就是这些压缩算法的做的事情。H.264最大的优势是具有很高的数据压缩比率，在同等图像质量的条件下，H.264的压缩比是MPEG-2的2倍以上，是MPEG-4的1.5～2倍。举个例子，原始文件的大小如果为88GB，采用MPEG-2压缩标准压缩后变成3.5GB，压缩比为25∶1，而采用H.264压缩标准压缩后变为879MB，从88GB到879MB，H.264的压缩比达到惊人的102∶1！H.264为什么有那么高的压缩比？低码率（Low Bit Rate）起了重要的作用，和MPEG-2和MPEG-4 ASP等压缩技术相比，H.264压缩技术将大大节省用户的下载时间和数据流量收费。尤其值得一提的是，H.264在具有高压缩比的同时还拥有高质量流畅的图像。写了这么多，举个例来说下，比如移动电视，我们接收的到的图像信号一般是H.264格式的，移动设备接收到后，需要先解码成原始的YUV码流，然后又转换成RGB码流，将一帧一帧的RGB数据放到显存上才能显示出图像。虽然传输快了，但是增加了设备的解码成本，不过总体来讲肯定是值得的。现在PC上的显卡慢慢都要集成H.264的硬件解码，据说苹果的最新产品IPAD也是有了这个硬解码。而YUV到RGB的转换，很多ARM芯片上都有了。