Android Live555

如何让Android支持C++异常机制

Android不支持C++异常机制,如果需要用到的话,则需要在编译的时候加入比较完整的C++库.

Android支持的C++库可以在Android NDK中找到(解压后找到libsupc++.a放到代码环境中即可):

http://www.crystax.net/en/android/ndk/7

编译时加上参数:

-fexceptions -lstdc++

还需要将libsupc++.a链接上

移植live555到Android的例子

https://github.com/boltonli/ohbee/tree/master/android/streamer/jni

RTSP协议

参考: rfc2326, rfc3550, rfc3984
RTP Header结构[#0]

?

H.264视频格式

参考: rfc3984, 『H.264中的NAL技术』, 『H.264 NAL层解析』

ACC音频格式

参考: ISO_IEC_13818-7.pdf

live555架构分析

0 总述

0.1 这里主要以H264+ACC为基础作介绍
0.2 live555中的demo说明，RTSP服务端为live555MediaServer，openRTSP为调试用客户端。
0.3 可以在live555中实现一个trace_bin的函数跟踪流媒体数据的处理过程。

?

1 宏观流程

1.1 对每个播放请求建立一个session，并对应音视频建立subsession,subsession则是具体处理流媒体的单位。

?
1.2 数据处理流程:

?
1.3 BasicTaskScheduler::SingleStep()

BasicTaskScheduler是live555的任务处理器，他的主要工作都是在SingleStep()中完成的.

在SingleStep()中主要完成下面三种工作:

?
RTSP请求、链接建立、开始播放处理主要是在1中完成的，而视频播放主要是在3中完成。

以ACC播放为例：

?
1.4 DelayQueue

fDelayQueue是一个需要处理的任务的队列，每次SingleStep()只会执行第一个任务head()，这里的任务对应DelayQueue的元素，DelayQueue的各个元素都会有自己的DelayTime，用来表示延时多久后执行。而队列中的元素便是按照DelayTime有小到大排列的，元素中fDeltaTimeRemaining记录的是该元素相对于它之前元素的延时。参照函数DelayQueue::addEntry()便可看出是如何入队列的。

例如([]中的数字便是相对延时(fDeltaTimeRemaining))：

?
在处理DelayQueue时往往都要先做一次计时同步操作synchronize()，因为DelayQueue中元素的延时都是相对的，所以一般只要处理首元素即可，不过如果同步之后延时有小于0的，便都会改为DELAY_ZERO(即表示需要立即执行的)。

执行任务：

?
任务在处理完成后便会被删除。

2 类关系

* live555的流程分析主要就放在这个章节中，如果有需要参考函数关系或者对象关系的请参考3, 4两个章节。

2.1 涉及到的主要类的关系图:

?
我们看下FramedFilter和FramedFileSource相对于FramedSource增加了哪些成员:

?
从两者的命名和增加的成员可以看出各自的作用。FramedFilter便是对应着[#2]中的filter，而FramedFileSource则是以本地文件为输入的source。
2.2 如何实现带有filter流程:

这便用到了FramedFilter中的fInputSource成员，以H264为例，

?
将上游source赋值到下游filter的fInputSource即可，对于H264便可以得到下面的一个处理流程:

?
在H264VideoStreamFramer的父类MPEGVideoStreamFramer中也有新增成员，

?
H264VideoStreamParser是用来filter过程中处理视频数据的。
在MultiFramedRTPSink::buildAndSendPacket()中添加RTP头[#0]。

3 函数关系

3.1 H264函数调用关系

?

4 对象关系

4.1 H264对象关系图

?
4.2 AAC对象关系图

?

5 RTSP

5.1 RTSP命令和处理函数的对应关系:

?
5.2 RTSP播放交互示例(openRTSP)

?