移动端多人视频通话软件开发(四) -- 原型开发阶段

1.      开发过程

a)        主要任务,主要的任务梳理如下:

l  Live555代码移植(Android已经移植过,之前有基础)

l  Ffmpeg中的H264编解码模块移植(之前有基础,直接拿来用)

l  添加呼叫流程和控制流程

l  增加多股视频流分解流程

l  添加音频发送流程

l  添加视频发送流程

l  添加音频收流程、视频收流程(之前有基础)

l  JNI接口

l  界面设计,原型图,素材制作

l  界面代码添加

l  音频采集、放音功能,视频采集和呈现功能

l  游戏流程SDK集成、JNI接口集成

l  游戏相关内容呈现

b)        风险点,主要风险点梳理如下:

l  和服务器信令调测风险, 和服务器端有2套信令体系, 一套是呼叫信令体系,一套是游戏信令体系,都属于新开发的

l  和服务器媒体调测风险,由于服务器端是新开发的,媒体也是新开发的,况且多股流也是公司之前没有接触过的

l  某开发人员对live555接触不是很多,可能会导致进度和技术偏差

c)        项目管理:

l  迭代,每周一个版本

l  调测阶段,人员集中调试

l  根据优先级和风险调整计划,风险较高的事情提交做

l  T0+4周:和服务器开始调测信令

l  T0+6周:和服务器开始调测媒体

l  T0+8周:完成信令调测

l  T0+8周:开始和服务器调试游戏流程

l  T0+10周:完成媒体调测,完成游戏流程调试

l  T0+12周:搭建完成演示环境


2.      遇到问题

a)        不稳定,

l  容易crash,主要是同步问题,解决办法:

1.        Log打印和流程解读

2.        代码走读

3.        代码评审

l  功能有不成功的地方

1.        通过测试、服务器端、终端侧集中在一起,不停重现、定位、解决

b)        音视频质量,这部分放在下一讲集中阐述

3.      总结和教训

a)        成功的在T0+12之后进行了演示

b)        架构太仓促,导致crash问题和可扩展性、可维护性很低

c)        音视频投入不够,导致走了很多弯路

你可能感兴趣的:(游戏,视频,移动,h264,视频流)