sgzed的博客

按 `q`，mpv 立刻退出。可此时 demux 线程可能正卡在 `recv()` 里，curl 线程卡在 `mp_cond_wait` 里，解码线程在等新的 packet——它们没被 `kill`，也没读键盘输入。是谁，在什么时刻，用什么方式通知它们的？

一个看似平凡的问题：播放中拖进度条到 10 分钟后，播放器要做什么？

前文结束时，demux 线程已经启动、轨道已选好、decoder 已经就位——一切准备就绪。从这一刻起，事情变得有趣了：你点击播放，demux 线程开始往队列里塞 packet。塞多快？塞多少？什么时候该停下来？这些问题没有一个"标准答案"——每个播放器的答案都不一样，而 mpv 的答案是所有开源播放器里最精打细算的一个。

当敲下 mpv video.mp4，回车。在第一个画面出现在屏幕上之前，mpv 已经做了一系列精密的初始化：打开文件、探测格式、创建 FFmpeg 上下文、解析轨道——这些在 demux 线程启动之前完成。选轨和建解码器则在 demux 线程启动之后、预读开始之前。你品品这个细节：mpv 甚至还没开始解码，就已经知道这个文件有几条视频轨、各自的分辨率和帧率、每条音轨的采样率。它是怎么在几百毫秒内完成这些判断的？

用 mpv video.mp4 播放本地文件，中途按 q。退出几乎在瞬间完成——用户看到的是"快"，但真正值得琢磨的是背后的设计问题：demux 线程可能正阻塞在 read() 或 recv() 上，播放器凭什么既能随时打断它，又能在平时不空转浪费 CPU？

几乎所有播放器都有一个"主循环"。OpenCV 用 `cv::waitKey(30)` 凑合；ffplay 把逻辑塞进 SDL 事件回调里。mpv 呢？你正看着视频，按一下空格暂停——**mpv 的 CPU 瞬间掉到接近 0%**，像一台熄火的发动机。可你再按一次空格，它又能瞬间恢复、逐帧精准地接着播。

上一篇文章把 `mp` 模块比作脚本的"操作系统"，C 层的 `mp.get_property`、`mp.wait_event` 等函数就是"系统调用"。但系统调用本身怎么实现的？为什么 `mp.get_property("volume")` 能拿到播放器的音量？

在 mpv 里写了一个 Lua 脚本，只需要 `mp.register_event("start-file", fn)`，播放新文件时 `fn` 就自动被调用。这背后，是 `mp` 模块提供的**一整套运行时环境**在默默运转。本文用"操作系统"类比，从设计层面讲清楚这套环境做了什么、怎么实现的。

你有没有好奇过：mpv 启动时，Lua 脚本里写 local utils = require("mp.utils") 就能拿到 readdir、split_path 这些 C 函数——这些函数是怎么从 C 侧注册到 Lua 侧的？require 又是怎么知道去哪个表里找的？

从一个疑惑开始：为什么 mpv 的 Lua 绑定函数（如 mp.utils.readdir）打开目录、分配临时内存后，从不写 closedir 或 free，却从不泄漏？

闭包不是"函数套函数"的语法糖。在 Lua 的 C API 中，它是函数实例 + 被捕获上值的运行时组合体——理解了这一点，才能看懂 mpv 那种"三层闭包自动管理资源"的精妙设计。本文用最小可运行的 C 代码，把闭包和上值在 C API 层的本质讲清楚，为后续 mpv 源码拆解打下基础。

先到处抄一堆参数再去猜为什么播放器打不开最后把“MPV 很难用”归因到软件本身先用本文把基础体验搭好。再理解idlekeep-opengeometry这些窗口行为。最后再进入vogpu-apihwdec、Lua 脚本、IPC 这些底层主题。这样学 MPV，不会乱，也更容易建立长期可维护的配置。下一步读什么？如果你现在已经把 MPV 配得顺手了，下一篇最适合读的是《Article_MPV_Pseudo_GUI与Idle机制剖析.md。

万事开头难，把 MPV 从源码编译起来并在 IDE 中跑通断点，为我们提供了深入探究 MPV 渲染架构的透视镜，这也是掌握硬核音视频底层技术的第一步。在后续的文章中，我们将利用搭建好的调试环境，逐步拆解 MPV 从 Demuxer 到 Decoder，再到最终高阶 GPU 渲染流水线的全链路源码，敬请期待！