FFmpeg 中的多线程解码

最新推荐文章于 2024-09-29 11:20:51 发布

音视频开发进阶

最新推荐文章于 2024-09-29 11:20:51 发布

阅读量1.3k

点赞数

文章标签：多线程 java python 编程语言 android

版权

ffmpeg 中使用到的多线程的概念：

互斥锁（mutex-lock）是一种信号量，用来防止两个线程在同一时刻访问相同的共享资源，它有锁定状态和非锁定状态。

在任意时刻，一个线程要想存取共享数据，线程必须首先获得mutex-lock，当此线程释放此共享数据的时候必须对mutex-lock解锁，在一个任意的时间内，只有一个线程能锁定互斥锁，通过函数pthread_mutex_lock上锁，通过函数pthread_mutex_unlock解锁。

条件变量用来提供另一种线程同步的方法，其基于实际的变量值来实现线程的同步操作，设置了条件变量的情况下，线程就不需要通过不停的轮询来查询条件是否满足，也不需要不停的忙等，从而能够节省很多系统资源。

一个条件变量总是和一个mutex-lock对应，系统通过pthread_cond_await函数来阻塞调用的线程，一直到条件变量得到满足。

当这个线程阻塞的时候对应的mutex-lock会自动解锁，但当该线程运行的时候，其对应的mutex-lock会被加锁。

使用函数pthread_cond_signal来唤醒等待在条件变量的另一个线程，当用来唤醒多个处于阻塞状态线程时通过pthread_cond_broadcast函数来完成。

Thread List，线程列表，线程列表中的每一项都映射一个解码线程。

主线程会从线程列表中按照序号由小到大（循环）提取解码线程，并把解码任务提交到该解码线程。

同时主线程在提交完解码任务后也会从线程列表中按照序号由小到大（循环）提取解码线程，并尝试从该解码线程获取解码完成的帧。

M，主线程，主要目的有两个：

向解码线程提交解码任务。FFmpeg中是以packet为单位进行解码任务的提交的，按照前一小节的描述，FFmpeg就是以frame为单位进行解码任务的提交的。
从解码线程获取解码所得的帧并进行返回。
不过在第一轮进行任务提交的时候是不会去获取帧，在第一轮任务提交完成后，此时所有解码线程都已经开始进行了解码作业，那么主线程就可以开始等待第一个线程解码完成，然后尝试去获得解码完成的帧。
这里的“尝试”，是因为就像单线程解码时那样，并不一定是每次调用解码API都会返回一帧的。由于h264编码的视频中常常包含B帧，这会使得码流的解码顺序并非帧的播放顺序，但是解码API必须按照帧的播放顺序进行返回，因此在进行帧的返回时会进行相应的调整。
接下来每次向一个线程提交一个解码任务后，都需要等待下一个线程空闲并尝试返回帧。
T，解码线程，接收解码任务并进行解码。解码线程是以frame为单位进行处理的。解码线程解码主线程所提交的packet，执行与单线程时一样的解码作业。

ffmpeg中的多线程解码主要分为片 Slice级别的多线程解码和帧Frame级别的多线程解码：

Slice级的解码效率比Frame级的解码效率要低，故，本文先考虑Frame级的多线程解码。

通过查看ffmpeg源码，了解到Frame级的多线程解码流程大致如下：

其中右侧的frame_worker_thread为解码线程，在open解码器时就已经创建，随后阻塞在pthread_cond_wait(&p->input_cond, &p->mutex)函数。等待被主线程唤醒。

当主线程运行到ff_thread_decode_frame函数时，会调用submit_packet函数，这个函数的目的就是将packet包交给解码线程。

submit_packet函数会调用pthread_cond_signal(&p->input_cond)函数，这个函数就是为唤醒刚才阻塞的解码线程。

当主线程唤醒解码线程后，其pthread_cond_wait(&p->output_cond, &p->progress_mutex)函数会进入阻塞状态，等待解码线程唤醒。

如果Codec未实现update_thread_context()和线程安全的get_buffer()，则必须在解码完成后才能将状态转换为STATUS_SETUP_FINISHED，意味着下一个线程只能在当前线程解码完成后才能开始解码。当解码线程解码完成后，会用pthread_cond_signal(&p->output_cond)将主线程唤醒，其中会通过回调函数将解码线程解码出来的frame获取，从而输出。