xxxtest

 

1.      主流商用视频通讯方案

下面列举了三种主流视频通讯方案，其中WebRTC是用来取代Google talk的，Google在收购了GIPS后开源了此部分的代码。

Skype

音频：G.729与SVOPC，自Skype 4.0以后开始使用自己研发的SILK音频编码，采样率为8/12/16/24khz，比特率为5~40kbps。

视频：版本5.7以后使用VP8(Google)为标准视频编码640x480，而720p与1080p使用H264编码。

STUN和TURN检测NAT及防火墙环境。

基于P2P，通讯协议不公开，通讯内容加密。

 

FaceTime

音频：AAC

视频：H264，最高可至720p。

STUN+TURN+ICE检测NAT及防火墙。

RTP/SRTP传输。

 

WebRTC^[1]

音频：iSAC(16/24/32khz, 10~52kbps)/iLBC(8khz, 13.3/15.2kbps)

视频：VP8

基于P2P，RTP/SRTP传输，STUN+TURN+ICE检测NAT及防火墙。

 

2.      AMR与多种音频编码格式比较

	AMR	AAC	SILK	iSAC
Algorithm	ACELP（自适应多码率）	MDCT	LTP	Transform coding
Sample Rate	8kHz	8~192kHz	8, 12, 16, 24 kHz	16 , 32 kHz
Bit Rate	4.75, 5.15, 5.90, 6.70, 7.40, 7.95, 10.20, 12.20 kbit/s	8 ~ 529 kbit/s (stereo) 注：理论上可以是任意比特率	6 ~40 kbit/s	10 ~52 kbit/s
CBR	yes	yes	yes	yes
VBR	yes	yes	?	yes
Stereo	no	yes	?	no
Multichannel	no	48 channels	?	no

表2-1

AMR算法复杂度为5^[2]，支持自适应多码率调整，相比较G.711是1，G.729a是15。

目前我尚未找到这几种音频编码方案的横向对比，一般AMR多与G.7xx相比，而AAC多与MP3相比。

 

3.      方案选择

根据需求把数据流的方向分为上行和下行。

l  下行数据为两路RTP数据流进来，合成TS文件供live555 server调用；

l  上行数据把MediaRecorder录制成的MP4文件打包成两路RTP外发；

 

3.1 下行方案

3.1.1      下行方案数据流程图

由数据流程图3-1我们可以看出：

l  对RTP包先做demux再做mux，再做成TS RTP包存在着一定的效率损失；

l  对两路音视频流做TS mux，目前嵌入式平台的主流方案都是由硬件来做，如果软件来做，CPU占有率及功耗均有待测试，特别是针对V2版本1080p camera捕捉方案（我们的AP选用的是高通的方案，是否可以看一下有硬件TS MUX?）；

l  live555在嵌入式平台的performance也需要评估一下，目前就我观察到的资料，live555如果原生代码不做更改的话，CPU的占用率似乎不低，需要移植到EP680上缓冲一个ts文件做测试？

l  live555从pipe读取TS文件后，可以抛出一个标准的rtsp地址，接着走stagefright rtsp流程，也可供第三方APK来访问；

 

有可能提供改善的地方，两路RTP包进来后，直接作为源提供给stagefright框架，数据传递的效率可得到一定的改善，但也带来了一些问题。

l  开发工作量会上升很多，涉及到缓存读取等；

l  需要修改原有frameworks内libstagefright的代码(C/C++)，如果要移植到Android新版本，每次都需要修改这层的代码，破坏了代码的原生性；

l  第三方APK将无法通过标准途径获取RTP数据；

 

3.1.2      编码方案

方案一（H264+AMR）

AMR并不是TS支持的标准codec^[3]（见表3-1），即使在private方法里也未有列出（private可用format_identifier或是stream_type=0x06然后去找descriptor来标识），所以第三方播放器无法知道AMR在private streams里的16进制标识，除非是端到端的约定，通用性并不是很好（如调试过程中做TS dump）。

如果坚持要在TS中封装AMR并被第三方播放器所识别，则需要向SMPTE^[4]注册MPEG-2格式标识符，具体资格要求不详。

	Video codec	Audio codec
MPEG transport stream TS(.ts)	MPEG-1, MPEG-2 Part2, MPEG-4 ASP, H.264, other formats in private streams: VC-1, Dirac	MPEG-1 Layers 1, 2, 3(mp3), AAC, other formats in private streams: AC-3, LPCM, DTS

表3-1

结论：目前不会有一款通用型的TS muxer来帮助封装音频codec为AMR的TS文件（除非有另一端定制，双方私有），所以该方案可行性较小。

 

方案二（H264+AAC）

这两种编码目前使用较多，在MPEGTSWrite.cpp里有代码，可做一定的参考。

 

3.2 上行方案

3.2.1      上行方案数据流程图

由数据流程图3-2我们可以看出：

l  反复的进行mux和demux，效率的损失还是比较明显的；

l  MP4是MediaRecorder所支持音视频封装输出格式之一（另一个是3GP），在输出的时候MediaRecorder已经帮我们做好了PTS的同步，这正是我们选用MediaRecorderv录制成文件的原因；

 

有可能提供改善的地方:

l  如果从Video source和Audio source传上来的经过编码后的数据带pts，我们是否可以直接打包成两路RTP?这块需要验证；

l  如果从Video source和Audio source传上来的经过编码后的数据不带pts，我们是否可以根据帧率算出帧时间，然后主动给帧加上pts？再做打包成RTP，同样需要验证；

l  Android 2.3官方版本对应的API level 是10，尽管MediaRecorder在官方网站的MediaRecorder.OutputFormat只有MPEG_4与THREE_GPP（包含音视频），但我在2.3的代码里发现还支持如下格式，这块有待进一步验证，无论哪一种可以实现，应该都可以一定量的减轻工作量，同时live555可能要求做成多线程模式？需要验证。

    OUTPUT_FORMAT_RTP_AVP = 7, /* Stream over a socket, limited to a single stream */

    OUTPUT_FORMAT_MPEG2TS = 8, /* H.264/AAC data encapsulated in MPEG2/TS */

 

3.2.2      编码方案

MP4支持封装H264, AMR, AAC这三种codec，目前测试了三种主流视频播放器，vlc，kmplayer能正常播放，但WMP不支持AMR类型的编码，有图像无声音，需要额外的插件来解码。

 

4.      总结

l  目前初步确定的上行/下行数据方案在效率上有一定的改善空间，尤其是TS MUX的效率及功耗需要做一下测试。

l  AMR这种编码方式在下行数据（封装成TS）的可行性方面需要做进一步的评估。

l  如果采用既定方案，codec略做调整（AMR换做AAC），数据流程中效率和功耗会有一些损失，和上文中所提及的改善方案差异较大，后期（V3？）如果想进行性能优化，可能需要重写代码，时间上会有损失。

l  如果直接采用上文中提及的改善方案，代码改动量太大，时间根本无法保证。

l  无论上面采用哪种方案，在既定时间（2013.2.25）完成所有代码编写的难度太大。

l  由于经验所限，某些理解难免片面，若有偏差，望能指正，谢谢！

 

 

 

参考文献

[1] http://www.webrtc.org/

[2] http://en.wikipedia.org/wiki/Adaptive_Multi-Rate_audio_codec

[3] http://en.wikipedia.org/wiki/Comparison_of_container_formats

[4] http://smpte-ra.org/mpegreg/mpeg.html