视频直播推流技术（MediaCodec硬编码+libRTMP，编码器），Demo - Android

 - aac audio_codec; h264,video_codec;25 framerate 25帧;

 - Camera-YUV帧序列-YUV帧预处理（镜像 缩放 旋转）-编码器-H264数据
从摄像头输出的YUV帧经过预处理之后，送入编码器，获得编码好的h264视频流。

> 直播，编码器SDK

1.直播 SDK 的开发，尤其是音视频录制、处理、编码、推流等核心功能的研发； 
2.优化直播 SDK，包括但不限于：弱网优化、流畅度优化、画质优化、码控优化、功耗优化等； 
3.直播 SDK 问题定位与解决；
4.直播传输技术，有拥塞控制、码率自适应、实时音视频传输控制和流媒体系统；

  直播相关的业务-包括视频直播、音频直播、PGC直播(知识答题、专业网红的高清直播)以及接入第三方的连麦厂商做互动直播; 低延时、高并发、高清晰度的流媒体应用,音视频与多媒体方向。
  直播的盈利（变现）点：直播打赏抽成、商品交易分红、付费直播提成（CCTV、PPTV）、会员增值服务（VIP用户）、广告收入（拉广告），道具礼物（购买，平台分成）等。
  Web端直播产品主要的运营方式有歌唱，会议、讲课，靠送花、广告等赢利。
  直播场景：连麦直播、在线抓娃娃、直播问答、远程狼人杀等，依赖视频通话和全互动直播技术。游戏行业的培养、弹幕文化 ；实时互动：文字>图片>视频.
  直播平台：斗鱼、NOW直播、美拍直播、淘宝直播、新浪直播、映客、me直播等，花椒和一直播；映客、me直播有互动连麦.
  直播SDK：阿里云； 腾讯云； 欢聚云； 金山云； UCloud； 七牛云； 声网；AnyRTC云平台。
  RTMP协议、私有协议或UDP直播解决方案。实时音视频直播，从刚开始的游戏直播和秀场娱乐开始。WebRTC在互动直播领域已经独树一帜。开源AAC解码器faad，音频编码效果：AAC+ > MP3PRO > AAC> RealAudio > WMA > MP3。
  流媒体传输层相关的兼容问题，以及连麦业务开发。教育行业（录播，点播，图像识别）的创业项目。给 Chromium 内核增加RTMP/FLV的播放以及推流支持。

-- 谈到音视频直播就会想到花椒、映客等娱乐直播，还有斗鱼、熊猫等游戏直播，这两种直播我们将它们统称为泛娱乐化直播。其实音视频直播技术不光应用于这类泛娱乐直播，还有很多其它类型的直播，如音视频会议、教育直播等，这两种我们称之为实时互动直播。
1.泛娱乐化直播主要有音频，视频，聊天，打赏等功能。
2.实时互动直播除了具有音频，视频，聊天，打赏功能外，一般还包括 文档共享、桌面共享、白板共享、批注等功能。

  在直播应用的开发过程中，如果把主播端消息事件传递到观众端，一般会以Instant Messaging（即时通讯）的方式传递过去，但因为消息分发通道和直播通道是分开的，因此消息与直播音视频数据的同步性就会出现很多问题。那么有没有在音视频内部传递消息的方法呢？答案是SEI。
  金山云目前推出的直播问答解决方案中，就用到了SEI。当前火爆的直播问答模式，就是通过SEI传递较多和答题业务相关的信息，通过SEI承载的信息，极大地优化了题目显示和观众音视频观看的同步性。

-- 直播五个方向：
 1.UGC互动直播：不仅提供推流到播放的全套直播解决方案，而且集成成熟的互动解决方案，包括IM，连麦等功能。例如：一直播、映客等直播互动平台。
 2.电商直播：为电商直播提供全套直播解决方案，支持动态扩展的直播技术架构，无需担心直播促销涌入的峰值流量担忧。例如：手淘等电商直播平台。
 3.体育赛事／大型综艺节目直播：为热门的赛事和综艺直播提供动态扩展的直播服务，通过CDN和PCDN的分发，用户无需为突然涌入的流量担忧。例如：CCTV5，等电视直播平台。
 4.游戏直播：对游戏直播提供各种采集设备的接入，以及直播的录制功能，便于游戏直播平台提供点播服务。例如：全民，熊猫，等游戏直播平台。
 5.在线教育／财经直播：提供直播鉴权、直播防盗链、URL加密等功能，为教育、财经类的直播提供安全保障。例如：第一财经等财经平台和知图教育等教育类直播平台。

   Android视频直播的数据流程：原始数据的采集—>转换成标准的I420格式数据—>编码成标准的H.264视频码流和ACC标准的音频码流—>将音视频数据封装成FLV文件—>套上RTMP协议发送流媒体服务器。播放端则刚好反过来，需要最原始的数据，视频由视频驱动播放，音频由音频驱动播放！

-- 视频推流协议主要有三种：
 RTSP（Real Time Streaming Protocol）：实时流传送协议，是用来控制声音或影像的多媒体串流协议, 由Real Networks和Netscape共同提出的；
 RTMP(Real Time Messaging Protocol)：实时消息传送协议，是Adobe公司为Flash播放器和服务器之间音频、视频和数据传输 开发的开放协议；
 HLS(HTTP Live Streaming)：是苹果公司(Apple Inc.)实现的基于HTTP的流媒体传输协议；

--  图像的采集过程主要由摄像头等设备拍摄成 YUV 编码的原始数据，然后经过编码压缩成 H.264 等格式的数据分发
出去。常见的视频封装格式有：MP4、3GP、AVI、MKV、WMV、MPG、VOB、FLV、SWF、MOV、RMVB 和 WebM 等。 
 图像采集和编码面临的主要挑战在于：设备兼容性差、延时敏感、卡顿敏感以及各种对图像的处理操作如美颜和水印
等。
 音频采集和编码主要面临的挑战在于：延时敏感、卡顿敏感、噪声消除（Denoise）、回声消除（AEC）、静音检测（VAD）和各种混音算法等。
 音频处理中具体包含混音、降噪和声音特效等处理;视频处理中包含美颜、水印、以及各种自定义滤镜等处理。

直播，推流协议：RTMP HLS ；拉流协议：Http-flv。

视频直播的流程可以分为如下几步： 采集 —>处理—>编码和封装—>推流到服务器—>服务器流分发—>播放器流播放 。

一个视频 ( Video ) ，其图像部分的数据是一组 GOP 的集合, 而单个 GOP 则是一组 I / P / B 帧图像的集合。

  一般来说，如果应用只需要支持Android 4.3及以上，只需要做录制视频、播放Mp4文件，硬编解码方案优于软编解码方案。但是如果应用需要支持4.1以前的系统，或者要求支持其他音视频格式，比如rmvb之类的，可能就不得不使用软编方案了。
  1.MediaCodec是Android4.1新增API，MediaMuxer是Android4.3新增API。硬编码和硬解码的话，最低SDK支持是API 18即Android 4.3.

> 直播可以研究和做的： 
 1.直播体验与成本优化的探索，涉及P2P、H.265、防盗链等技术的应用。流媒体、多媒体领域的技术研究；重写过一些常见的网络协议。弱网下直播不流畅的问题,使用RTMP+UDP传输的方式来优化网络拥塞和带宽不足的问题；
 2.喷泉码，使用很少量的冗余数据来完成丢包恢复，主要用来解决网络丢包导致的花屏问题；数字水印，主要用来计算直播延时。
 3.对于直播行业来说，最为常见场景有几个，人脸识别以及增强现实、机器鉴黄、视频内容自动分类。
 4.美颜滤镜等

> 直播客户端和服务器端
-- 直播客户端
 1.直播客户端编译、采集、推流、拉流、美化特效、水印、延时优化、音视频同步、p2p等

-- 服务器端
  业内主流的流媒体开源服务器有两家，SRS 和 nginx-rtmp，两者都是基于 C/C++。问题有很多：底层 I/O 库以及 I/O 模型的都和 Go 差距较大，业务编写困难。Go 的定位就是解决 C/C++ 这些问题，对于 I/O 密集的流媒体服务器也是有用的。
  基于WebRTC，基于 licode 搭建的 SFU。剥离了它的 Nodejs 层，仅使用 C++ 层。七牛云直播团队在从零开始使用 licode 开源项目构建连麦服务端的经验，如何利用 GPU 完成高效的服务端合流，以及如何实现基于 TURN 的边缘加速方案。

 1.在部署服务端环境其实包含很多东西的，最常用的web服务nginx，数据库Mysql、Nosql，api开发最多的三种选择：
-java环境，需要jdk，tomcat/jboss
-php环境，需要安装php，odp
-lua环境，需要安装lua、luajit

 2.开源下载
  - nginx下载地址：
官方release：http://nginx.org/en/download.html
gitHub地址：https://github.com/nginx/nginx
nginx-rtmp-module下载地址：https://github.com/arut/nginx-rtmp-module
  - ffmpeg下载地址：
官方release：https://ffmpeg.org/download.html
gitHub地址：https://github.com/FFmpeg/FFmpeg

-- 搭建服务器如：直播server
  国内：福建泉州（联通）、广东佛山、肇庆（电信）
国外：如果ss登陆韩国，则访问韩国机房
-- 直播拉流CDN
  国内：潮州（联通）、揭阳（电信）
  国外：如果ss登陆韩国，则访问韩国机房

> 连麦直播，直播文字聊天 ，平台：web、android、ios、windows。
移动视频直播、实时互动连麦视频(音频)直播、视频会议等解决方案- https://github.com/AnyRTC
基于RTMP协议的推流拉流anyRTC-RTMP-OpenSource- https://github.com/AnyRTC/anyRTC-RTMP-OpenSource
Android Demo连麦互动直播 地址：https://github.com/AnyRTC/RTMPCHybirdEngine-Android
iOS Demo 地址：https://github.com/AnyRTC/RTMPCHybirdEngine-IOS
Android互动直播APP开发入门笔记- https://blog.csdn.net/zhoumushui/article/details/79534709
WebRTC-Native 源码导读（二）：安卓预览实现分析- https://blog.piasy.com/2017/07/26/WebRTC-Android-Render-Video/#glrectdrawer
直播答题辅助实现- https://github.com/duanyuGit/AoLaiDaTi

-- 连麦是互动直播中常见的需求。互动直播的主要技术难点在于：
 1）低延迟互动：保证主播和互动观众之间能够实时互动，两者之间就像电话沟通，因此必须保证两者能在秒级以内听到对方的声音，看到对方的视频；
 2）音画同步：互动直播中对音画同步的需求和单向直播中类似，只不过互动直播中的延迟要求更高，必须保证在音视频秒级传输情况下的秒级同步。
 3）音视频实时合成：其他观众需要实时观看到对话结果，因此需要在客户端或者服务端将画面和声音实时合成，然后以低成本高品质的方式传输观众端。
  对于互动人数比较少的互动直播，目前市场上比较成熟的方案是使用基于 WebRTC 的实时通讯方案。基于该方案可以轻松实现多人（14 人以下）的多方实时通信。
  在视频和电话会议领域，目前比较成熟的方案是使用思科或者 WebEx 的方案，但这些商用的方案一不开源，二比较封闭，三成本比较高。对于互动人数比较少的互动直播，目前市场上比较成熟的方案是使用基于 WebRTC 的实时通讯方案。

-- 互动直播星形通信网络采用UDP 协议传输：
1.通过 UDP 降低传输延迟。
2.在 UDP 之上进行传输控制，保证用户互动体验 QoS。

 视频本质上讲是一系列图片连续快速的播放，最简单的压缩方式就是对每一帧图片进行压缩。
 视频推流协议：RTMP；WebRTC；基于 UDP 的私有协议。视频延迟和卡顿的原因和相应的优化原理。

-- 移动直播连麦
移动直播连麦实现——A端合成- https://blog.csdn.net/sinat_14921509/article/details/80127709
移动直播连麦实现——Server端合成- https://blog.csdn.net/sinat_14921509/article/details/80127674
移动直播连麦实现思路：整体篇- https://blog.csdn.net/sinat_14921509/article/details/80127059

-- Android 硬编码流控,码率控制模式有三种：
 1.CQ  表示完全不控制码率，尽最大可能保证图像质量；
 2.CBR 表示编码器会尽量把输出码率控制为设定值，即我们前面提到的“不为所动”；
 3.VBR 表示编码器会根据图像内容的复杂度（实际上是帧间变化量的大小）来动态调整输出码率，图像复杂则码率高，图像简单则码率低；
FFMpeg的码率控制 - CBR or VBR.H264三种码率控制方法(CBR, VBR, CVBR).

 分辨率：分辨率指的是视频的尺寸。例如常见的分辨率有3840x2160 (4K), 1920x1080 (HD), 1280x720 (720P), 640x360 (360P)等。
 码率：码率是影响视频质量最主要的参数之一。其它条件形同的情况下，码率越大，视频质量越好。例如一个640x360的1Mbps的的视频的质量肯定好于一个640x360的500kbps的视频。但是不同分辨率的视频码率差别很大。例如我们很难断定一个1280x720的1Mbps的视频的质量是否高于一个640x360的500kbps的视频。

> 弹幕
Android上专为视频直播打造的轻量级弹幕库（100多kb）- https://github.com/hpdx/DanmukuLight
android上开源弹幕解析绘制引擎项目。- https://github.com/Bilibili/DanmakuFlameMaster

-- 自定义弹幕
Android 自定义View修炼-自定义弹幕效果View- https://www.cnblogs.com/JczmDeveloper/p/4872460.html
弹幕实现原理方案：
 1、自定义ViewGroup-XCDanmuView，继承RelativeLayout来实现，当然也可以继承其他三大布局类哈；
 2、初始化若干个TextView（弹幕的item View，这里以TextView 为例，当然也可以其他了~），然后通过addView添加到自定义View中；
 3、通过addView添加到XCDanmuView中，位置在坐标，为了实现 从屏幕外移动进来的效果；我们还需要修改添加进来TextView的位置，以从右向左移动方向来说，addView后必须将该TextView的位置设置到右边的屏幕外；这样我们采用的方法，是在onLayout（）方法中对childView进行layout重新布局设置位置；
 4、随机冲左侧或右侧出来弹幕itemView，移动采用属性动画来实现平移，从屏幕的一端移动到另一端，当动画结束后，就将该child从XCDanmuView中remove掉。并重新new 一个弹幕itemView ，并addView到XCDanmuView中，并开始动画移动；
 5、本自定义弹幕View支持从左到右和从右到左两个方向，支持自定义设置屏幕弹幕最多显示个数。

> 音视频的帧速率fps、GOP、码率分辨率
-- 几个对视频的质量和大小影响最大的参数：帧率、码率和分辨率，优化
  1）如何制定帧率
一帧就是一副静止的画面，连续的帧就形成动画，如电视图象等。我们通常说帧数，简单地说，就是在 1 秒钟时间里传输的图片的数，也可以理解为图形处理器每秒钟能够刷新几次，通常用 fps（Frames Per Second）表示。每一帧都是静止的图象，快速连续地显示帧便形成了运动的假象。高的帧率可以得到更流畅、更逼真的动画。每秒钟帧数 (fps) 愈多，所显示的动作就会愈流畅。
  2）如何制定码率
每个 GOP 组只有 1 个 I 帧。如：每秒 25 帧画面，GOP 组长度为 5，那么帧格式为 IBPBP,那么 1 秒钟有 5 个 I 帧，10 个 B 帧，10 个 P 帧，如果 GOP 组长度为 15，帧格式就是 IBBPBBPBBPBBPBB，那么 1 秒钟内会有 2 个 I 帧和 16 个 B 帧和 7 个 P 帧，那么 5 个 I 帧比 2 个 I 帧占用的数据信息量大，所以 GOP 组的长度格式也决定了码流的大小。
  3）如何指定分辨率
分辨率概念视频分辨率是指视频成像产品所成图像的大小或尺寸。常见的视像分辨率有 640×480，1088×720，1920×1088。在成像的两组数字中，前者为图片长度，后者为图片的宽度，两者相乘得出的是图片的像素。

-- //推流可以优化的：设置 帧速率fps、GOP、码率分辨率;
//推流宽高：640*360  ; 推流的时候需要将推流端的Activity设为横屏（640*360），拉流端菜显示满屏
public static final int DEFAULT_VIDEO_WIDTH = 640;
public static final int DEFAULT_VIDEO_HEIGHT = 360;
public static final int DEFAULT_VIDEO_BITRATE = 600 * 1024; // 码率默认是600 * 1024 码率600 ；720 * 1280
public static final int DEFAULT_VIDEO_FPS = 20;// 帧速率 fps
public static final int DEFAULT_VIDEO_GOP = 2;//（gop 关键帧间隔）

1)影响视频清晰度的指标：帧率；码率；分辨率；量化参数（压缩比）
2)影响视频流畅度的指标：码率；帧率
3)其他重要指标，直播是流量和性能的消耗大户：耗电量；发热（不好量化，大部分情况发热和耗电量正比，可以使用耗电量暂时替代）。

 音频格式：
private static final String MIME_TYPE = "audio/mp4a-latm";
 视频格式：
private static final String MIME_TYPE = "video/avc";

推流过程中，重新设置帧率和重新设置码率；

> WSLiveDemo推流的时候需要将推流端的Activity设为横屏（推流宽高：640*360 ），拉流端才显示满屏
(推荐)Android 音视频，直播SDK，rtmp推流，录制视频，滤镜。- https://github.com/WangShuo1143368701/WSLiveDemo 
Android ffmpeg实现直播功能- https://github.com/WangShuo1143368701/FFmpegandroidWSLive
安卓实时滤镜RTMP推流库- https://github.com/lakeinchina/librestreaming
(声音采集)来疯直播安卓控件，支持flv，支持rtmp，支持添加视频特效等- https://github.com/LaiFeng-Android/SopCastComponent

RTMP流媒体技术零基础学习方法- https://blog.csdn.net/leixiaohua1020/article/details/15814587
实现了录制直播流（RTMP、RTSP、HTTP）可以参考：https://github.com/lm3515/RLIJKPlayer
android视音频硬编码，软编码rtmp推流器，包含ffmpeg- https://github.com/dengzhi00/Live_Rtmp2
使用librtmp进行H264与AAC直播- https://my.oschina.net/jerikc/blog/501948
大牛直播SDK，跨平台(windows/android/iOS)推送(rtmp)、直播播放器(rtmp/rtsp)-https://github.com/daniulive/SmarterStreaming
iOS直播推流LaiFengiOS/LFLiveKit- https://github.com/LaiFengiOS/LFLiveKit
android rtmp push sdk- https://github.com/runner365/android_rtmppush_sdk
-- It is probably the smallest(~60KB) rtmp client for android. It calls librtmp functions over JNI interface. With all cpu architectures(arm, arm7, arm8, x86, x86-64, mips) its size is getting about 300KB
In version 0.2, it supports FLV muxing and sending stream via RTMP. FLV muxing is based on this repo- https://github.com/rainfly123/flvmuxer
LibRtmp-Client-for-Android- https://github.com/ant-media/LibRtmp-Client-for-Android
Google Android多媒体和图形图像- https://github.com/google/grafika
-- Android 使用Rtmp音视频推流- https://blog.csdn.net/a992036795/article/details/54583571
Android 使用Rtmp音视频推流- https://github.com/blueberryCoder/LiveStream 
-- 轻松入门Android直播相关技术 从0搭建直播系统- https://blog.csdn.net/lmj623565791/article/details/77937483
支持直接运行ffmpeg的命令，利用ffmpeg推流- https://github.com/WritingMinds/ffmpeg-android-java

> libRTMP 直播推流
  A solution for streaming H.264, H.263, AMR, AAC using RTP on Android.(powered device using RTP over UDP).Libstreaming是spydroid的抽象与升华.
 RTMP 协议栈的实现，Bill 直接使用的 libRTMP。 https://github.com/blueberryCoder/LiveStream
  It uses OpenSSL by default, but you can also use GnuTLS or PolarSSL
  rtmpdump is a toolkit for RTMP streams- git://git.ffmpeg.org/rtmpdump http://rtmpdump.mplayerhq.hu/
RTMP协议可用于实现直播、点播应用，通过FMLE（Flash Media Live Encoder）推送音视频数据至RtmpServer，可实现摄像头实时直播。
  使用MediaCodec和RTMP做直播推流- https://github.com/ChillingVan/AndroidInstantVideo  https://www.jianshu.com/p/3c479c0f4876?open_source=weibo_search  
rtmpdump 是一个可以通过RTMP协议下载流媒体的工具:https://github.com/AnyRTC/AnyRTC-RTMP
rtmpdump 是一个可以通过RTMP协议下载流媒体的工具:https://git.oschina.net/dynctm/AnyRTC-RTMP

  不论向 RTMP 服务器推送音频还是视频，都需要按照 FLV 的格式进行封包。因此，在我们向服务器推送第一个 AAC 或 H264 数据包之前，需要首先推送一个音频 Tag [AAC Sequence Header] 以下简称“音频同步包”，或者视频 Tag [AVC Sequence Header] 以下简称“视频同步包”。
  所谓的H264数据，其实只是一堆堆的byte[]数组。RTMP流本质上是FLV格式的音视频。
视频帧的图像处理- https://github.com/ChillingVan/android-openGL-canvas

-- librestreaming  libresrtmp
rtmp推流库.直播推流的过程,主要包括:音视频采集, 音视频编码, 数据打包, RTMP协议等.
最简单的基于LibRTMP的例子- https://github.com/leixiaohua1020/simplest_librtmp_example
-- 安卓实时滤镜RTMP推流库- https://github.com/lakeinchina/librestreaming
安卓实时滤镜 RTMP 推流库；支持 cpu 滤镜，gpu 滤镜；音频滤镜。使用RTMP推流。
-- Libstreaming是一个开源的流媒体框架- https://github.com/fyhertz/libstreaming
C++实现RTMP协议发送H.264编码及AAC编码的音视频- http://www.cnblogs.com/haibindev/archive/2011/12/29/2305712.html
RTMPdump（libRTMP） 源代码分析- https://blog.csdn.net/leixiaohua1020/article/details/12971635

-- 直播推流实现RTMP协议的一些注意事项- https://www.jianshu.com/p/00aceabce944
RTMP推流及协议学习- https://blog.csdn.net/lory17/article/details/61916351
带你吃透RTMP- http://mingyangshang.github.io/2016/03/06/RTMP%E5%8D%8F%E8%AE%AE/
Android直播客户端主要是用ffmpeg来实现推流的- https://github.com/ChillingVan/AndroidInstantVideo
Android平台视频采集压缩编码RTMP推流实现- https://github.com/gezhaoyou/SimpleLivePublisherLite
Simple Live Publisher 是简洁的 Android 平台直播推流工程，基本都是Java代码写的，H264 和 AAC的编码使用的是Android的mediacodec, 网络部分Java重写了RTMP协议，方便阅读定位，YUV处理考虑性能采用了LibYUV。延时在1-3秒左右。

1小时学会：最简单的iOS直播推流（一）介绍- https://www.jianshu.com/p/30b82f1e61a9
iOS GPU-based image and video processing- https://github.com/BradLarson/GPUImage
美颜滤镜使用的是：https://github.com/Guikunzhi/BeautifyFaceDemo
iOS直播推流 librtmp使用- https://github.com/hardman/AWLive
 视频捕获，软编码(faac，x264)，硬编码（aac，h264），美颜，flv编码，rtmp协议。
- 使用rtmp协议（其他协议也类似）推流的大体流程如下：
1.通过系统相机捕获视频及声音，该美颜的美颜，该滤镜的滤镜。

2.捕获的视频帧为yuv格式，音频帧为pcm格式。

3.将捕获的音视频数据，传入一个串行队列(编码队列)，在队列中进行编码操作。

4.将yuv格式视频数据，转成h264格式视频帧；将pcm格式音频数据，转成aac格式音频帧。

5.将转好的h264及aac格式数据，转成flv视频帧。放入编码缓冲区，待发送。继续获取视频帧并编码。

6.建立rtmp连接到服务器，成功后，创建另一个串行队列（发送队列）。

7.rtmp协议，需要在首帧发送 sps/pps和AudioSpecificConfig这2种特别的帧数据。

8.发送了首帧之后，发送队列不停从编码队列中获取flv视频帧，发送至rtmp服务端。

9.结束直播，关闭推流，释放资源。

视频是由一帧一帧的数据连接而成，而一帧视频数据其实就是一张图片。所有的音频编码器，都支持pcm编码，而且录制的声音，默认也是PCM格式。很多视频编码器最初是不支持rgb格式的。但是所有的视频编码器都支持yuv格式。
video tag 中 存储的是完整的视频压缩格式的一帧数据，如h264数据。
audio tag 中 存储的是完整的音频压缩格式的一帧数据，如 aac数据。

 硬编码是系统提供的，由系统专门嵌入的硬件设备处理音视频编码，主要计算操作在对应的硬件中。硬编码的特点是，速度快，cpu占用少，但是不够灵活，只能使用一些特定的功能。
 软编码是指，通过代码计算进行数据编码，主要计算操作在cpu中。软编码的特点是，灵活，多样，功能丰富可扩展，但是cpu占用较多。

使用MediaCodec和RTMP做直播推流- https://www.aliyun.com/jiaocheng/13311.html
* 视频数据流可以这样看 
Camera -> SurfaceTexture -> Surface -> MediaCodec -> encode data(byte[]) -> RTMPMuxer -> Server 
* 音频数据: 
相对简单一些,就是从AudioRecord里获取原始音频数据(byte[]),编码成AAC数据(也是byte[]),然后给RTMPMuxer,封装成RTMP包,发到服务器 ；麦克风MIC -> AudioRecord -> voice data(就是byte[]) -> MediaCodec -> encode data(就是byte[]) -> RTMPMuxer -> Server* Muxer 

librtmp的推送流程主要包括：握手、分块、Connect、Metadata、SendStream（Video&Audio）、Close等等流程。整个程序包含3个接口函数： 
1.RTMP264_Connect()：建立RTMP连接。 
2.RTMP264_Send()：发送数据。 
3.RTMP264_Close()：关闭RTMP连接。 
按照顺序调用上述3个接口函数就可以完成H.264码流的发送。

结构图中关键函数的作用如下所列。
1.RTMP264_Connect()中包含以下函数： 
InitSockets()：初始化Socket 
RTMP_Alloc()：为结构体“RTMP”分配内存。 
RTMP_Init()：初始化结构体“RTMP”中的成员变量。 
RTMP_SetupURL()：设置输入的RTMP连接的URL。 
RTMP_EnableWrite()：发布流的时候必须要使用。如果不使用则代表接收流。 
RTMP_Connect()：建立RTMP连接，创建一个RTMP协议规范中的NetConnection。 
RTMP_ConnectStream()：创建一个RTMP协议规范中的NetStream。

2.RTMP264_Send()中包含以下函数： 
ReadFirstNaluFromBuf()：从内存中读取出第一个NAL单元 
ReadOneNaluFromBuf()：从内存中读取出一个NAL单元 
h264_decode_sps()：解码SPS，获取视频的宽，高，帧率信息 
SendH264Packet()：发送一个NAL单元

SendH264Packet()中包含以下函数： 
SendVideoSpsPps()：如果是关键帧，则在发送该帧之前先发送SPS和PPS 
SendPacket()：组装一个RTMPPacket，调用RTMP_SendPacket()发送出去 
RTMP_SendPacket()：发送一个RTMP数据RTMPPacket

3.RTMP264_Close()中包含以下函数： 
RTMP_Close()：关闭RTMP连接 
RTMP_Free()：释放结构体“RTMP” 
CleanupSockets()：关闭Socket

librtmp提供了推流的API，可以在rtmp.h文件中查看所有API。我们只需要使用常用的几个API就可以将streaming推送到服务器。 
- RTMP_Init()//初始化结构体 
- RTMP_Free() 
- RTMP_Alloc() 
- RTMP_SetupURL()//设置rtmp server地址 
- RTMP_EnableWrite()//打开可写选项，设定为推流状态 
- RTMP_Connect()//建立NetConnection 
- RTMP_Close()//关闭连接 
- RTMP_ConnectStream()//建立NetStream 
- RTMP_DeleteStream()//删除NetStream 
- RTMP_SendPacket()//发送数据

pts表示展示时间戳，表示这一帧什么时候展示。
说cts之前有必要介绍一下dts，dts表示解码时间戳。rtmp连接成功后，一定要先发送sps&pps和AudioSpecificConfig这两个数据对应的tag，否则视频是播放不出来的。

> 快手直播是如何设计全链路质量监控方案、如何搭建大数据处理Pipeline 、如何解决开播跳帧、首屏卡顿优化等问题的？
 首屏启动、流畅播放、网络拥塞、延时追赶的？实时视音频传输优化？
语音视频技术团队，视频图像相关的技术研发
  一般大家使用的是MediaPlayer来播放音频，它的创建和销毁都是非常消耗资源的，如果我们的需求是播放一些短促而且频繁播放的音频的话MediaPlayer就有些不合适了，我们来讲讲SoundPool来播放短促的音频
  即时通讯应用中的实时音视频技术，几乎是IM开发中的最后一道高墙。原因在于：实时音视频技术 = 音视频处理技术 + 网络传输技术 的横向技术应用集合体，而公共互联网不是为了实时通信设计的。
  H.264是在MPEG-4技术的基础之上建立起来的，其编解码流程主要包括5个部分：帧间和帧内预测、变换和反变换、量化和反量化、环路滤波、熵编码。
  H.264标准的关键技术：1帧内预测编码；2帧间预测编码；3整数变换；4量化；5熵编码。
  不同于MPEG-4中采用的精细分级编码FGS（Fine Granular Scalability）的方法（效率比较低），H.264采用流切换的SP帧来代替分级编码。H.264已被广泛应用于实时视频应用中，相比以往的方案使得在同等速率下，H.264能够比H.263减小50%的码率。也就是说，用户即使是只利用 384kbit/s的带宽，就可以享受H.263下高达 768kbit/s的高质量视频服务。H.264 不但有助于节省庞大开支，还可以提高资源的使用效率，同时令达到商业质量的实时视频服务拥有更多的潜在客户。

> 七牛云视频直播技术详解- https://www.jianshu.com/nb/5638906
 七牛云视频直播技术详解包括采集/处理/编码与封装/推流与传输/延迟优化/现代播放器原理/SDK性能测试模型。。
  音视频编码器与解码器。
  视频的采集涉及两方面数据的采集：音频采集和图像采集，它们分别对应两种完全不同的输入源和数据格式。 
  音频数据既能与图像结合组合成视频数据，也能以纯音频的方式采集播放，后者在很多成熟的应用场景如在线电台和语音电台等起着非常重要的作用。音频的采集过程主要通过设备将环境中的模拟信号采集成 PCM 编码的原始数据，然后编码压缩成 MP3 等格式的数据分发出去。
  音频跟视频很不一样，视频每一帧就是一张图像，而从上面的正玄波可以看出，音频数据是流式的，本身没有明确的一帧帧的概念，在实际的应用中，为了音频算法处理/传输的方便，一般约定俗成取 2.5ms~60ms 为单位的数据量为一帧音频。这个时间被称之为“采样时间”，其长度没有特别的标准，它是根据编解码器和具体应用的需求来决定的；
  音频的采集过程主要通过设备将环境中的模拟信号采集成 PCM 编码的原始数据，然后编码压缩成 MP3 等格式的数据分发出去。
  常见的音频压缩格式有：MP3，AAC，OGG，WMA，Opus，FLAC，APE，m4a 和 AMR 等。
  音频采集和编码主要面临的挑战在于：延时敏感、卡顿敏感、噪声消除（Denoise）、回声消除（AEC）、静音检测（VAD）和各种混音算法等。
  视频采集，对于专业摄像机或者摄像头，此SDK提供了兼容适合嵌入式系统的 C 语言采集模块的实现，仅供参考：https://github.com/pili-engineering/ipcam_sdk
  图像的采集过程主要由摄像头等设备拍摄成 YUV 编码的原始数据，然后经过编码压缩成 H.264 等格式的数据分发出去。
  常见的视频封装格式有：MP4、3GP、AVI、MKV、WMV、MPG、VOB、FLV、SWF、MOV、RMVB 和 WebM 等。
  图像采集和编码面临的主要挑战在于：设备兼容性差、延时敏感、卡顿敏感以及各种对图像的处理操作如美颜和水印等。
  满足市场上主播的各种需求如美颜、水印、连麦互动等，如美颜、视频水印、滤镜、连麦等。如打上时间戳或者公司 Logo 的水印，祛斑美颜和声音混淆等处理。
  视频采集针对音频采集和图像采集以及它们分别对应两种完全不同的输入源和数据格式。

  屏幕录制采集的方式在游戏直播场景中非常常见。
  常见视频处理功能如美颜、视频水印、滤镜、连麦等。主播和观众连麦场景。水印是图片和视频内容中常见的功能之一，它可用于简单是版权保护，或者进行广告设置。视频水印包括播放器水印和视频内嵌水印两种方式可供选择.滤镜效果GPUImage.
  美颜的主要原理是通过「磨皮+美白」来达到整体美颜的效果。磨皮的技术术语是「去噪」，也即对图像中的噪点进行去除或者模糊化处理，常见的去噪算法有均值模糊、高斯模糊和中值滤波等。也涉及到人脸和皮肤检测技术。

  水印是图片和视频内容中常见的功能之一，它可用于简单是版权保护，或者进行广告设置。处于监管的需求，国家相关部门也规定视频直播过程中必须打上水印，同时直播的视频必须录制存储下来保存一定的时间，并在录制的视频上打上水印。
   视频水印包括播放器水印和视频内嵌水印两种方式可供选择，对于播放器水印来说，如果没有有效的防盗措施，对于没有播放鉴权的推流，客户端拿到直播流之后可以在任何一个不带水印的播放器里面播放，因此也就失去了视频保护的能力。综合考虑云端录制对于水印的需求，一般来说会选择「视频内嵌水印」的方式打水印。

  多平台适配需求的增长导致了流媒体自适应码率播放的兴起。播放器（解码器）与多媒体引擎。
  视频压缩算法变得越来越复杂，解码过程是一个需要密集计算的过程，并且为了保证解码性能和流畅的播放体验，解码过程需要强依赖于操作系统和硬件。现在的大部分解码都依赖于 GPU 加速解码的帮助（这也是为什么免费而更强大的 VP9 解码器没有赢得 H.264 市场地位的原因之一）。如果没有 GPU 的加速，解码一个 1080P 的视频就会占去 70% 左右的 CPU 计算量，并且丢帧率还可能很严重。
  每个平台都有它自己的渲染引擎和相应的 API：Flash 平台有 Netstream，Android 平台有 Media Codec API，而 Web 上则有标准的 Media Sources Extensions。MSE 越来越吸引眼球，将来可能会成为继浏览器之后其它平台上的事实标准。在 Web 平台，得益于多媒体引擎如 dash.js、Shaka Player 和 hls.js 这些趋于成熟库的帮助， MSE 和 EME 正在成为播放的新标准，同时也越来越多有影响力的厂家使用这些播放引擎。

--  ffmpeg开发,Android视频直播核心技术(架构)详解- https://www.2cto.com/kf/201708/667730.html
  主流的直播架构中主要有两种方案，即流媒体转发、P2P。流媒体转发，是一种在视频直播中以流的方式将连续的音、视频数据经编码压缩后传输到流媒体服务器，用户实时从服务器获取流媒体资源，而不必要等待整个文件下载文件完毕的C/S架构视频直播方案；P2P直播，是一种建立在P2P技术基础上的视频直播方案，它规定客户端之间使用一定协议来交换和共享直播数据，通过减少对服务器的数据请求，以降低服务端的I/O带宽等方面压力，从而削减服务器带宽成本，降低客户端卡播率。
  YUV是一种亮度信号Y和色度信号U、V是分离的色彩空间，它主要用于优化彩色视频信号的传输，使其向后相容老式黑白电视，且与RGB要求三个独立的视频信号同时传输相比，它最大的优点在于只需占用极少的频宽，非常适用于流媒体传输。
  YUV格式分为两种类型，即Packet(包)和Plannar(平面)。Packet类型是将Y、U、V分量存储在同一个数组中，每个像素点的Y、U、V是连续交错存储的，常见的采样格式有NV21、NV12；Plannar类型是将Y、U、V分量分别存储在三个独立的数组中，且先连续存储所有像素点的Y分量，紧接着存储所有像素点的U分量，最后存储所有像素点的V分量，常见的采样格式有YV12、I420。
  H.264编码框架分为两层：VCL、NAL。VCL(Video Coding Layer，视频编码层)，负责高效的视频内容表示；NAL(Network Abstraction Layer，网络抽象层)，负责以网络所要求的恰当的方式对数据进行打包和传送。在H.264协议里定义了三种帧，完整编码的帧叫I帧(关键帧)，参考之前的I帧生成的只包含差异部分编码的帧叫P帧，还有一种参考前后的帧编码的帧叫B帧。H.264编码采用的核心算法是帧内压缩和帧间压缩。其中，帧内压缩是生成I帧的算法，它的原理是当压缩一帧图像时，仅考虑本帧的数据而不用考虑相邻帧之间的冗余信息，由于帧内压缩是编码一个完整的图像，所以可以独立的解码显示；帧间压缩是生成P、B帧的算法，它的原理是通过对比相邻两帧之间的数据进行压缩，进一步提高压缩量，减少压缩比。

-- 流媒体：实时流传输协议 RTP 详细说明了在互联网上传递音频和视频的标准数据包格式，它与传输控制协议 RTCP 配合使用，成为流媒体技术最普遍采用的协议之一。 
  在技术上，模式识别（人脸识别）、语音识别与分析、VR技术、图像处理等技术的加入.
  音视频直播一般都分为五大步： 数据采集，编码，传输，解码和渲染。然后是IM聊天，这主要是服务端的工作。IM主要解决的问题是大负载问题以及消息丢失和消息重复问题。桌面共享，桌面共享可以用视频技术实现，也可以用VNC技术实现，相较而言，VNC优势更大。文档共享，比较简单的方式是将各种文档都转成jpg格式，更好点的可以转成矢量图，这样图片进行放大，缩小时不会失真。传输，对于实时性不高的产品可以使用RTMP, 对于实时性比较高的必须使用UDP，一般会选用RUDP（可靠性UDP），既可以保证传输速度，又可以防止丢包。

-- 视频采集播放过程：
  1.数据采集。对于音频来说采集到的数据是PCM格式，对于视频数据采集的格式是YUV格式。
  2.数据压缩编码。数据采集完成之后，需要对数据进行压缩编码。音视频使用的压缩技术称为有损压缩技术。而像我们平RAR，ZIP工具进行的压缩都是无损压缩。就是说解压后的数据与原始数据一样叫做无损压缩，解压后和原始数据高度接近称为有损压缩，音视频编码属于后者。对于音频来讲，常用的编码格式有speex, AAC, OPUS, G.711等。现在比较常用的是AAC，一是它音质比较好，二是RTMP对AAC支持的比较好。对于视频编码格式有H.264, H.265, VP8, VP9等，目常基本上都是使用H.264。注意，衡量有损压缩好坏的指标就是看同等压缩率的情况下，解压后的数据与原始数据之间差别的大小，差别越小证明压缩的算法越优。当然在实时互动直播中，我们为了实时性就需要牺牲一部分质量或者也有可能为了质量而牺牲一些实时性，这需要仔细的权衡。
  3.传输。数据压缩完之后通过网络传输。对于泛娱乐化的直播平台一般都使用RTMP协议进行数据的传输，RTMP是在TCP之上的网络协议。对于实时互动直播则必须使用UDP进行数据传输。 UDP数据的传输速度上比TCP有天然的优势。RTMP是Adobe公司发明一种传输协议，目前所有的CDN网络对RTMP的支持是非常好的，但它的问题就是延迟性比较大。使用RTMP造成延迟主要有两个方面原因，一是RTMP网络协议由于是基于TCP协议的，本身延迟就比UDP大，另一方面是CDN架构造成的。CDN首先从顶级结点接收数据，然后以树状形式分发到端结点，这个过程链条比较长，导致整体的延迟非常大。而且延迟时间不固定，有可能某段时间延迟3､5秒，也有可能过一段时间延迟就达到了30秒这都是有可能的。
  4.解码。就是将对编码数据做反向操作。如音频是AAC编码，则它再解为PCM格式数据。视频是H.264再解为YUV数据。
  5.播放和渲染。对于音频直接将PCM数据放入到音频驱动缓冲驱，驱动程序就会将音频播放出来。对于视频一般会通过 opengl利用 GPU进行图像渲染。
  视频编码的主要作用是将视频像素数据(RGB，YUV等)压缩成为视频码流，从而降低视频的数据量。