音视频处理的一些流程：客户端编译、采集、推流、拉流、美化特效、水印、延时优化、音视频同步、p2p等等。当然还可能包括一些信号处理的知识，比如滤波，傅里叶变换（FFT）。

> 熊猫TV技术架构
聚光灯下的熊猫TV技术架构演进-- http://geek.csdn.net/news/detail/99651
 直播面临的核心问题是网站稳定可用、视频流畅清晰、弹幕互动效果稳定。
 端:Web页、iOS、Android、各种Pad端、网吧弹窗合作、电视盒子合作App、游戏主机合作App，从各个渠道扩展业务。
  负责短链接、微博Card对象、网游页游平台业务。
  需要满足用户登录注册、关注主播、看视频、发弹幕、加房管、领任务、送免费竹子等核心功能，采用了复用模块＋主业务全新开发的策略。
  复用模块得益于团队的前360技术背景，根据直播秀场类项目上的技术积累，利用PHP框架Pylon、发版工具Rigger，在老战友的帮助下，重新搭建了一套QBus消息组件，长连接系统，改进的Redis、MongoDB和MySQL集群，视频云服务，敏感词服务，搜索服务
  视频模块——从新搭建视频云，RTMP推流拉流，接入三家CDN作为互备。这其中需要自己实现统一调用接口和服务，方便切换CDN： 推流地址、拉流地址、转码规定、开播断流回调、一键断流、连接数查询、流截图、直播时长查询。基本上每个接口都很重要！例如一键断流万一失效，则可能面临停业整顿风险；人数不准，主播挂人气刷榜，则可能导致不公平竞争而影响平台的体验与口碑。
  分布式基本组件：复用Syslog-ng日志收集系统、Kafka消息队列QBus、MySQL主从库、Redis主从库、MongoDB、SSDB大容量存储。
  长连消息：单机百万长连，支持千万用户同时在线，性能够用，保证聊天弹幕稳定性。
  图床：很重要的一环，房间截图，用户头像。
  CMS系统：配置各种推荐位，直播间的CDN调度

-- 熊猫TV架构第一原则是高可用
 网     络：需要应对国内复杂的网络环境，使用内网光纤互联的多IDC来覆盖多运营商。
 资     源：DB和缓存都是集群化，配置Virtual IP方便切换。
 隔 离 性：不同业务不同机器，防止雪崩效应；核心和非核心业务隔离，流量扛不住情况保重点业务。
 降     级：从Nginx和API层设置接口开关、Cache开关、DB开关，出问题一键切换。
 超时控制：主站每个依赖业务设置5秒超时，并有报警和错误日志。
 异       步：用户不关心实时结果的大写入量业务使用异步方式更新，提高核心服务性能。
 监       控：服务器错误设置log监控、接口监控报警，随时处理线上异常。

-- 架构选型
  Web层：Nginx＋PHP-FPM，开发迅速，适合团队技术现状，但需要针对服务器，做一定的调优配置。
  缓存层：Redis主从库、SSDB大容量存储，会在各个业务块儿使用，增加系统性能。
  存储层：MySQL主从库存储重要业务数据，属性变化不大。MongoDB数据库存储字段不固定变更较多的数值明细记录。SSDB存储观看记录关注等列表较长，且性能要求较高的数据。分表分库上考虑用户注册量和主播播放频率，用户中心、主播播放时长采用了按用户ID Sharding和 按年Sharding两种策略。业务初期暂时没有分库需求。
  消息队列：实现业务解耦，使用当前较流行的Kafka队列。

  安全性上：所有80接口做XSS校验，CSRF token防范，对接口做几十道安全检测，防止被拖库，防止Cookie被盗用；反垃圾反盗号反外挂：含敏感词聊天信息过滤，垃圾IP封禁；注册和任务都增加图片验证码，识别机器刷用户刷竹子；房间人气值采用复杂策略，用算法综合判断确认合理性，防刷防挂；主播审核更加严格，身份证银行卡姓名等信息都要求录入，可以追究责任到真人，甚至有视频验证，严防色情内容。
  功能上：建立游戏娱乐户外等分类模块，运营自助增加分类；部署并自行运维第三方搜索服务，支持主播昵称、标题、房间号等维度搜索，过滤直播状态、主播地区、封禁状态等条件；礼物系统抽奖投票等系统上线，增加主播收益渠道，增加互动。
  优化效果：全年未出现过白页、首页不可访问情况，支撑千万级PV，百万级日活，单房间最高达到百万级在线，视频流量近TB级；接口平均响应时间20ms左右，99.9%在1s内；各个系统数据存储量破千万，MongoDB、SSDB等大容量库很好地支持了业务。

-- 熊猫TV架构改进思路是应对峰值流量高度集中的直播需求，总结几条经验：
 1.不能依赖单个CDN。可自建，可用第三方，但中国网络环境太复杂，必须高度重视容灾。海外推拉流也需要十分关注。
 2.弹幕消息一定要做策略优化。广播蝴蝶效应明显，峰值可能将机房整体带宽打满。区分弹幕优先级，做好降级预案。
 3.提高金钱敏感度。直播网站由于有很清晰的变现模式，要严防褥羊毛，严防色情内容，火速响应监管，支付礼物交互一定是高可用、严监控。
 4.N个大主播 ＝ 半个网站峰值。必须考虑某些特殊主播的火爆人气，做好视频弹幕房间信息上的峰值应对。

-- 未来我们会在以下方面继续努力：
  自助式运营处理：帮助运营自助处理问题，直接和CDN对接，帮助技术人员从简单重复问题处理中脱身。
  反作弊：基于大数据处理体系的用户画像、设备画像、IP画像、内容画像，多维度构建反垃圾反盗号功能 。
  长连优化：支撑千万用户在线的高并发实时弹幕和聊天。
  礼物商城：优化计数对账，幂等处理整个支付到特效抽奖、弹幕消息、消费记录、统计等流程。
Golang、NodeJS服务化：替代性能较差需要各种优化的PHP，服务端接口全面Golang化，前端也在合适的场景使用NodeJS提高服务性能。此外需针对KV存储做value压缩，节省流量，提高接口速度。
数据挖掘和机器学习：渠道分析、用户分析等便于产品和高层决策，甚至开发出机器人主播互动。
  推荐：在综艺化娱乐化多元化的内容基础上，个性化推荐用户感兴趣的直播内容。
  搜索：自建搜索，从用户维度、聊天维度更好服务用户。
  日志收集分析：高性能日志方案探索，更快更迅速发现业务问题，分析流量变化。
  广告系统：友好娱乐化的广告展现，精准推送，严禁的计费系统。
  支付：国际化支持，多种银行卡信用卡接入，多种货币支持。
  NewSQL：引入TiDB等新SQL技术到某些业务，替换Redis、MongoDB、MySQL，更方便友好地进行技术开发。

> 直播技术
 直播技术（从服务端到客户端）-- http://blog.csdn.net/xwl198937/article/details/52371726
nginx下载地址：
  官方release：http://nginx.org/en/download.html
  gitHub地址：https://github.com/nginx/nginx
ffmpeg下载地址：
  官方release：https://ffmpeg.org/download.html
  gitHub地址：https://github.com/FFmpeg/FFmpeg
nginx-rtmp-module下载地址：https://github.com/arut/nginx-rtmp-module
在部署服务端环境其实包含很多东西的，最常用的web服务nginx，数据库Mysql、Nosql，api开发最多的三种选择：
  java环境，需要jdk，tomcat/jboss
  php环境，需要安装php，odp
  lua环境，需要安装lua、luajit
考虑使用缓存技术，则主要包含redis和memcached。如果还要其他的日志统计（kafka什么的）需求则还需要更多的环境

-- 美丽播 手机直播APP源码
1、ffmpeg源码、处理音视频编码
2、gpuimage源码、处理美颜功能
3、ffmpeg、gpuimage只提供sdk集成，不提供源码
4、ios使用oc原生开发，android使用java原生开发，后端采用php+mysql+redis
5、消息推送走第三方推送平台
视频流压缩传输。
程序首先会对接收到的视频流进行压缩及转换，让视频流更适合网络传输，减少直播传输所需要的带宽。当然程序是可以根据自己的要求来修改压缩比例以及视频播放的分辨率。
  
视频直播的传输协议是rtmp，视频编码是x264，音频编码是aac。
标清的码率在300~400kb，高清的码率在500kb~800kb。
视频分发走CDN加速。
聊天： 聊天走自己的聊天服务，支持Websocket传输协议。单台服务并发1万路以上。
网站：网站逻辑基于php、mysql、redis。
均衡负载功能<很强大的功能>
此功能可以无限添加FMS直播服务器，来分摊视频流的带宽负担。
首先，程序完全可以将网站程序与FMS视频流来分开，也就是说，网站可以单独使用一台服务器或者虚拟主机，FMS则使用另外一台独立的服务器，这样就不会因为视频直播流量大影响网站的访问速度。
  一个完整的直播过程，包括采集、处理、编码、封包、推流、传输、转码、分发、拉流、解码、播放，从推流到播放，再经过中间转发环节，延迟越低，用户体验越好。 RTMP推流模式.HLS/RTMP视频服务器 —— HLS/RTMP拉流模式.

iOS开发之直播App流程介绍，直播资料收集汇总，视频推流，视频拉流，SMTP、RTMP、HLS、 PLPlayerKit-- http://blog.csdn.net/zhonggaorong/article/details/51483282

  对直播的后台来说，用户管理、礼物管理、充值提现管理、房间管理、运营策略和数据，这几个功能是必不可少的。在用户管理上，有些用户可能在管理员巡查时发现存在问题，系统可以对他进行禁言和封禁。还有就是礼物的管理。直播平台礼物分大礼物和小礼物，大礼物是一出来之后有一个大动画，比如我们看映客中的飞机、法拉利、保时捷，这些属于大礼物，很贵，甚至有一些平台有土豪套装，比如说帝王套，一个要花费几千人民币。还有小礼物，一毛两毛这样的礼物，可以连发，一发 99 个或者 520 个。 
  互动直播的基本产品架构， 分为：视频系统、互动系统、用户系统，包括管理后台。视频系统包括直播和点播 2 大块；互动系统，就是在直播间里的一些消息，包括评论、弹幕、点亮、礼物、对主播的关注和粉丝的关注，还有就是把当前的直播分享出去；用户系统包括用户资料（头像、性别、年龄）、充值、好友关系等。

> 直播中可用的音视频数据涉及技术或协议：编码方式：CBR、VBR编码格式
视频：H.265、H.264、MPEG-4等，封装容器有TS、MKV、AVI、MP4等
音频：G.711μ、AAC、Opus等，封装有MP3、OGG、AAC等

  直播：RTMP RTSP RTP RTCP等。
  一个完整的直播技术架构由推流端（采集、前处理、编码、推流），服务端处理（转码、录制、截图、鉴黄），播放器（拉流、解码、渲染）、互动系统（聊天室、礼物系统、赞）组成。
 -- 媒体&活动直播
特点：单向，无交互，流数少，延迟容忍度高 >10s；包含电视转流、演唱会直播等。这类目前对于直播的技术要求较低，低上行，高下行。游戏直播特点：单向，无交互，流数多，延迟容忍度高 >5s；目前国内CDN产商抢得最激烈的一块。
 -- 秀场直播
特点：单向，文字交互，流数量多，延迟容忍度低 2~5s；这个是目前大家都能看得到盈利模式的一种。除了主播在播外，观众可以点赞，文字，送礼物，有一定的交互性。所以对直播的延迟要求苛刻，越低越好。
  -- 社交直播
特点：单向，文字交互，流数量非常多，延迟容忍度低 2~5s；社交直播和秀场直播，在交互上类似，区别比较大有两点：1. 秀场一般都是有限的主播把内容运营起来，推流的数量较少，一般是<100路；2. 社交直播是路人即可产生内容，所以直播的流数会上升到1000，甚至10000。
  -- 教育在线直播
特点：双向，师生直接交互，流数少，延迟容忍度2~5秒。总的来说，教育直播的要求是低延迟、交互频繁。一个高效的课堂应该是师生互动频繁，老师的提问学生应该立刻能进行解答，学生的问题老师也能及时给出反馈。

 -- 服务器端通常有两种技术来平衡和优化这两个指标。
  1.一是服务端提供灵活的配置策略，对于延时要求更敏感的，则在服务端在保证关键帧的情况下，对每个连接维持一个较小的缓冲队列；对于卡顿要求更高的直播，则适当增加缓冲队列的长度，保证播放的流畅。
  2.二是服务端对所有连接的网络情况进行智能检测，当网络状况良好时，服务端会缩小该连接的缓冲队列的大小，降低延迟；而当网络状况较差时，特别是检测到抖动较为明显时，服务端对该连接增加缓冲队列长度，优先保证播放的流畅性。