testRTSPClient.cpp 位于live555源码目录 live/testprogs目录下，编译出来 testRTSPClient
可以直接用来接收流，不过这个流接受之后只是打印一下信息，然后丢弃，并没有存储到什么文件。接受流的函数，在DummySink::afterGettingFrame（); 有数据帧接受到会在这里，可以直接修改这个函数来使用live555
例如：
#testRTSPClient rtsp://192.168.43.154:8989/stream
分析源代码：
总的概括，这个类需要继承 MediaSink ，然后实现其中的虚函数：
virtual Boolean continuePlaying();//
依次发送 describe option setup play. 最后调用子类的sink->startPlaying（）.
testRTSPClient.cpp 中有宏定义：
#define DEBUG_PRINT_EACH_RECEIVED_FRAME 1 //每收到一帧就打印信息
#define REQUEST_STREAMING_OVER_TCP False //是否请求使用rtp-over-tcp 在sendSetupCommand 发送setup命令时候使用
RTSPClient.cpp 中封装有sendRequest这个方法，只要给一个请求，这个请求有成功之后的回调.
RTSPClient在openConnection连接成功之后会添加一个后台的任务来根据实际情况调用这个回调。所以整个main函数的流程驱动前期主要在这个 回调。后面的读数据的循环，主要在DummySink实现的 continuePlaying() 不断循环调用自身。
获取数据，就是在DummySink::continuePlaying() 这个子类实现的虚函数中。
fSource->getNextFrame(fReceiveBuffer, DUMMY_SINK_RECEIVE_BUFFER_SIZE,
afterGettingFrame, this,
onSourceClosure, this);
上图注释1：源码中有注释，这是一个异步任务。 其中内部，sendRequest有些包装的暗箱操作，因为第一次进来的时候socket没有创建，会调用openConnection()创建socket并connect到服务端，并且添加一个后台任务BackgroundHandlerProc，这个任务在socket有数据可读时读数据处理，然后根据服务器发过来的 respone 从sendRequest的等待回应队列中取request进行匹配，匹配到就会调用 请求成的回调，比如continueAfterDESCRIBE函数。 oop的设计思想，这些链接网络的操作都是封装起来的，按照调用过程来分析很是 ugly, 我觉得其主要目的是 testRTSPClient.cpp 的逻辑调用更加明确简单。其实只有
1.0 continueAfterDESCRIBE() 2.0 continueAfterSETUP() 3.0 continueAfterPLAY() 这三个逻辑调用。
注释二：
创建MediaSession，MediaSessong里面再创建MediaSubsession
setupNextSubsession()->
scs.subsession->initiate()-> createSourceObjects()->
fReadSource = fRTPSourc = H264VideoRTPSource::createNew 创建h264 source
注释三：
startPlaying会调用MediaSink的纯虚函数continuePlaying，由DummySink实现，其实现是一个 不断 调用continuePlaying的循环。补充：
continuePlaying()做的事情：
fSource->getNextFrame (**afterGettingFrame,*)
而这个afterGettingFrame, 会读完一帧数据后被回调。在DummySink中，其实现是：输出了一下收到的帧信息，然后又调用 continuePlaying(), 这样形成一个自身的循环，一直continuePlaying下去
简化一下流程：
**
补充一下，标准的rtsp会话，应该是 option describe setup play teardownwiki百科对rtsp的描述但这里的demo直接省略了 option
** [option 的作用是向服务器询问支持哪些命令，省略也并非错误]：
补充一个MediaSession的关系：（个人理解）
：
官方的一个图解连接
