GStreamer管道autovideosrc!queue!fakesink的线程数及功能查询

预估准确性判断 #

你最初预估的4线程结论不完全正确，除了GStreamer核心、queue元素生成的线程外，还存在三类额外的线程生成机制：

• 各类元素内部自带的工作线程：例如视频采集源类元素默认会启动独立线程拉取硬件数据
• 平台依赖、第三方依赖库生成的线程：例如系统IPC线程、依赖库的线程池线程
• 临时初始化辅助线程：初始化阶段启动的临时工作线程，初始化完成后自动销毁

实测线程逐一解释 #

排除grep进程后，你实测到的8个初始线程对应功能如下：

• 3681：gst-launch-1.0主进程主线程，负责管道初始化、状态切换管理、全局信号处理
• 3702/3703/3704：Android平台Binder IPC线程池线程，你当前运行环境为Android，autovideosrc调用底层摄像头服务需要走Binder跨进程通信，这三个线程是Android runtime自动创建的IPC处理线程，不属于GStreamer核心逻辑线程
• 3716 {queue0:src}：queue元素的出队工作线程，负责从队列中取出缓冲区推送到下游fakesink，和你预估的queue线程对应
• 3717 {fake-auto-video}：autovideosrc的采集工作线程，负责从底层摄像头硬件定时拉取视频帧，推送到queue的入队端，属于你预估遗漏的源元素自带线程
• 3718 {gmain}：GLib主循环线程，负责处理GStreamer消息总线事件、异步回调、定时器任务，对应你预估的主循环线程
• 3719 {pool}：GStreamer初始化阶段启动的临时线程池工作线程，负责管道资源预分配、插件加载等一次性初始化任务

线程数变化原因 #

运行一段时间后线程数从8变为7，是因为3719这个临时初始化线程完成所有初始化任务后自动退出，属于正常行为。

strace结果对应含义 #

• 3681的ppoll调用：主线程等待管道控制事件输入
• 3702/3703/3704的BINDER_WRITE_READ ioctl调用：处理和系统摄像头服务的跨进程通信，拉取采集参数、帧数据
• 3716的futex等待：queue的出队线程等待队列中有新的缓冲区可推送
• 3717的ppoll超时+唤醒futex：采集线程按帧率定时醒来拉取新帧，拉取完成后唤醒queue的出队线程处理新数据
• 3718的ppoll调用：GLib主循环等待消息总线事件、异步回调触发

内容的提问来源于stack exchange，提问作者abirusabil