linphone 内部线程分析

以下分析基于我内部修改过的linphone版本。

linphone包含了sip协议解析,多媒体编解码和rtp传输等功能,这些功能是通过不同的组件分工合作完成的,下面我就来分析下linphone

生命中出现过的那些线程。

 

第一个登场的当然是主线程,也就是ui线程,通常可认为是一个Activity,这个Activity主要负责界面的绘制、linphone内核库的初始化以

及功能接口的调用。

 

第二个线程是sip协议处理线程,在主线程初始化linphone内部库时创建:

osip_thread_create(20000, _eXosip_thread, NULL);

此线程监听sip的socket接口,负责sip消息的发送、接收,分析sip消息并做协议上的处理,最后会调用各种业务的回调函数做进一步处理。

 

第三个线程是在初始化完linphone内部库之后由linphoneManager创建的一个loop,此线程循环调用linphone_core_iterate,处理各种

osip event和call状态变化。

 

第四个线程是音频流线程,在建立会话之后由loop线程创建。负责音频流的编解码,以及音频编码数据的rtp发送接收。

 

第五个线程是视频流线程,在建立会话之后由loop线程创建。负责视频流的编解码,以及视频编码数据的rtp发送接收。

 

下面通过分析一些常见的应用场景来分析这些线程是如何运作的。

++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++

场景一、在解码点击拨号键发起一个点对点呼叫

---------------------------------------------------------------

当用户点击拨号键后,主线程里的onclick函数执行,通过jni调用linphone库的呼叫函数,此函数会做一些初始化,然后调用sip的呼叫

接口,向sip的事务队列添加一个‘发起呼叫’的事务。

代码调用流程:

onclick()

      |

jni 调用的java方法

     |

jni调用的c方法

    |

linphone_core_invite_address_p2p()

    |

linphone_core_start_invite()

    |

sal_call()

    |

eXosip_call_send_initial_invite()

    |

osip_transaction_add_event()

    |

osip_fifo_add()

--------------------------------------------------------------------------   

接着,sip协议线程会检测到这个‘发起呼叫’的事务 ,并处理这个事务。

eXosip_execute()

    |

osip_ict_execute()

    |

osip_fifo_tryget()

osip_transaction_execute()

    |

__ict_get_fsm()

fsm_callmethod()

transition->method()

ict_snd_invite()

     |

__osip_message_callback(OSIP_ICT_INVITE_SENT, ict, ict->orig_request);

    |

cb_sndinvite()

 

在函数ict_snd_invite中把sip的invite消息发送到目地地址,接着调用回调函数cb_sndinvite(),此函数是用来通知linphone,‘发起呼

叫’的请求发送完毕。我们也可以在此回调里做一些我们自定义的处理。

---------------------------------------------------------------

当目标机接收到sip的invite消息后,如果按下接听按钮接听了电话,目标机就会回复一个200的消息给呼叫端(200表示ok),呼叫端

收到200的消息,就生成一个sip event,接着,loop线程会轮询到这个sip event,并处理。我们看代码流程。首先是sip协议线程:

---------------------------------------------------------------

eXosip_execute()

    |

osip_ict_execute()

    |

osip_fifo_tryget()

osip_transaction_execute()

    |

__ict_get_fsm()

fsm_callmethod()

transition->method()

ict_rcv_2xx()

    |

__osip_message_callback(OSIP_ICT_STATUS_2XX_RECEIVED, ict, evt->sip);

    |

cb_rcv2xx()

    |

report_event()

    |

eXosip_event_add();

---------------------------------------------------------------------

然后是loop线程:

sal_iterate()

    |

eXosip_event_wait();

process_event();

    |

call_accepted()

    |

sal->callbacks.call_accepted(op);

    ||

call_accepted()

    |

linphone_core_update_streams()

    |

linphone_call_start_media_streams()

                            |

     -------------------------------------------------------------------------------

    |                                                                                                        |

linphone_call_start_audio_stream()                                  linphone_call_start_video_stream()

    |                                                                                                       |

audio_stream_start_full()                                                     video_stream_start()

    |                                                                                                       |

stream->ticker=ms_ticker_new();                                      stream->ticker = ms_ticker_new();

 

函数ms_ticker_new()会创建一个线程(也就是音频流线程或视频流线程),此线程的实现方式是: 循环执行filter的process方法。

下面详细说明,以视频流线程为例。

-----------------------------------------------------------------------------------

linphone把视频通话看做一个流水线,流水线上的每一环负责一个步骤。那么视频通话的流水线有两条:

1. 摄像头采集 ----- 视频编码 ----- rtp 发送

2. rtp 接收 ----- 视频解码 ----- 视频显示

      每一环都以filter的形式实现,filter需要实现固定的几个接口:init 、pre_process、process、post_process、uninit 。filter的process

函数接收其他filter的输入,经过内部处理后传递给预定的filter。

      linphone根据需要把不同的filter link成一个流水线,一条流水线包含一个source filter、一个output filter(出口也可以有2个)和若干

个中间filter,数据从source filter产生,并在process方法里把数据流传递给下一个filter,下一个filter经过处理,将数据流传递给下下个

filter,如此直到最后一个output  filter。

      结合到视频采集就是camera插件完成视频的yuv数据的采集,并传递给encoder插件,encoder插件完成视频的编码,并将编码数据

传递给rtp发送插件,rtp发送插件将编码数据打包,然后通过socket传递到网络。

时间: 2024-12-02 07:20:18

linphone 内部线程分析的相关文章

linphone源码分析----初始化部分

这几天比较轻松,所以打算好好来看看linphone的代码,源码版本为3.5.2.从linphone初始化的过程开始,首先来看linphone_core_new函数.  LinphoneCore *linphone_core_new(const LinphoneCoreVTable *vtable, const char *config_path, const char *factory_config_path, void * userdata) { LinphoneCore *core=ms_n

python内部线程假死,有什么办法在进程内kill掉这个假死的线程呢

问题描述 python内部线程假死,有什么办法在进程内kill掉这个假死的线程呢 python内部线程假死,有什么办法在进程内kill掉这个假死的线程呢 解决方案 应该先解决你python代码怎么引起线程假死的. 解决方案二: 线程数比较少的时候,一个月都不假死,但超过一定的数量就会假死,而且每次假死,最后日志停止的位置都不一样,所以也是无所下手

Apache Storm内部原理分析

本文算是个人对Storm应用和学习的一个总结,由于不太懂Clojure语言,所以无法更多地从源码分析,但是参考了官网.好多朋友的文章,以及<Storm Applied: Strategies for real-time event processing>这本书,以及结合自己使用Storm的经历,希望对于想深入一点了解Storm原理的朋友能有所帮助,有不足之处欢迎拍砖交流. Storm集群架构 Storm集群采用主从架构方式,主节点是Nimbus,从节点是Supervisor,有关调度相关的信息

淘宝客网站优化之内部优化分析

在我做的那么多网站当中我觉得唯一一个我自己觉得比较重要,或者说可能以后会带给我收入的网站就是我的那个减肥的淘宝客网站(http://www.taoke13.com).然而对这个网站进行优化的时候我去忽略了网站优化最基本的优化方式,那就是网站的站内优化. 这个网站是10年十月低做的网站吧,到现在也将近三个月了,网站的推广一直做的不是很好,淘宝客成交的也很少,只是偶尔成交了几笔.但是一直都不赚钱,很多人都跟我说,做减肥药排行榜的网站如果你不能把关键字做到百度首页的话是很难赚到钱的,其实这个我也知道,

Android应用程序模型之应用程序,任务,进程,线程分析_Android

本文讲述了Android应用程序模型之应用程序,任务,进程,线程.分享给大家供大家参考,具体如下: 大多数操作系统,在应用程序所寄存的可执行程序映像(如Windows系统里的.exe).它所运行的进程以及和用户交互的图标和应用之间有一种严格的1对1关系.在Android系统里,这些关联要松散得多.并且重要的是要理解各种概念怎么样组成整体. 由于Android应用固有的灵活性,当实现这些不同方面的时候有一些基本术语需要加以理解: ① 一个Android包 (.apk)文件,其中包含一个应用程序的代

JVM:如何分析线程堆栈

英文原文:JVM: How to analyze Thread Dump 在这篇文章里我将教会你如何分析JVM的线程堆栈以及如何从堆栈信息中找出问题的根因.在我看来线程堆栈分析技术是Java EE产品支持工程师所必须掌握的一门技术.在线程堆栈中存储的信息,通常远超出你的想象,我们可以在工作中善加利用这些信息. 我的目标是分享我过去十几年来在线程分析中积累的知识和经验.这些知识和经验是在各种版本的JVM以及各厂商的JVM供应商的深入分析中获得的,在这个过程中我也总结出大量的通用问题模板. 那么,准

JVM致命错误日志(hs_err_pid.log)分析

当jvm出现致命错误时,会生成一个错误文件 hs_err_pid<pid>.log,其中包括了导致jvm crash的重要信息,可以通过分析该文件定位到导致crash的根源,从而改善以保证系统稳定.当出现crash时,该文件默认会生成到工作目录下,然 而可以通过jvm参数指定生成路径(JDK6中引入): -XX:ErrorFile=./hs_err_pid<pid>.log 该文件包含如下几类关键信息: 日志头文件 导致crash的线程信息 所有线程信息 安全点和锁信息 堆信息 本

深入JVM剖析Java的线程堆栈_java

在这篇文章里我将教会你如何分析JVM的线程堆栈以及如何从堆栈信息中找出问题的根因.在我看来线程堆栈分析技术是Java EE产品支持工程师所必须掌握的一门技术.在线程堆栈中存储的信息,通常远超出你的想象,我们可以在工作中善加利用这些信息. 我的目标是分享我过去十几年来在线程分析中积累的知识和经验.这些知识和经验是在各种版本的JVM以及各厂商的JVM供应商的深入分析中获得的,在这个过程中我也总结出大量的通用问题模板. 那么,准备好了么,现在就把这篇文章加入书签,在后续几周中我会给大家带来这一系列的专

MapReduce V1:Job提交流程之JobTracker端分析

我们基于Hadoop 1.2.1源码分析MapReduce V1的处理流程.MapReduce V1实现中,主要存在3个主要的分布式进程(角色):JobClient.JobTracker和TaskTracker,我们主要是以这三个角色的实际处理活动为主线,并结合源码,分析实际处理流程. 上一篇我们分析了Job提交过程中JobClient端的处理流程(详见文章 MapReduce V1:Job提交流程之JobClient端分析),这里我们继续详细分析Job提交在JobTracker端的具体流程.通