从 Github 上拉取最新的源码,目录结构大体以下:javascript
H:\MPV ├─.github ├─audio │ ├─decode │ ├─filter │ └─out ├─ci ├─common ├─demux ├─DOCS │ └─man ├─etc ├─filters ├─input ├─libmpv ├─misc ├─options ├─osdep │ ├─android │ ├─ar │ ├─macos │ └─win32 │ └─include ├─player │ ├─javascript │ └─lua ├─stream ├─sub ├─ta ├─test │ └─ref ├─TOOLS │ ├─lua │ ├─mpv-osd-symbols.sfdir │ └─osxbundle │ └─mpv.app │ └─Contents │ ├─MacOS │ │ └─lib │ └─Resources ├─video │ ├─decode │ ├─filter │ └─out │ ├─cocoa │ ├─cocoa-cb │ ├─d3d11 │ ├─gpu │ ├─hwdec │ ├─opengl │ ├─placebo │ ├─vulkan │ └─win32 └─waftools ├─checks ├─detections ├─fragments └─generators
libmpv/mpv.def
里面。可是这个 .def 文件不是标准的导出文件。若是是启动播放器进行播放,则首先会进行一个内部状态的初始化,主要是初始化了MPContext
这个结构体。这个结构体是一个大杂烩,全部播放相关的参数、动态变化的属性都绑定到这上面。而后内核进入 idle 状态,等待播放视频。java
打开第一个媒体文件的时候,会开始进行视频/音频播放链路(video_output_chain)初始化,其中就包括初始化解码和渲染模块。渲染模块由结构体 vo_driver
定义,(mpv 内部使用结构体来定义接口),例如 vo_gpu 的定义以下:android
const struct vo_driver video_out_gpu = { .description = "Shader-based GPU Renderer", .name = "gpu", .caps = VO_CAP_ROTATE90, .preinit = preinit, .query_format = query_format, .reconfig = reconfig, .control = control, .get_image = get_image, .draw_frame = draw_frame, .flip_page = flip_page, .get_vsync = get_vsync, .wait_events = wait_events, .wakeup = wakeup, .uninit = uninit, .priv_size = sizeof(struct gpu_priv), .options = options, };
接下来咱们都以这个 Windows 下最经常使用的 vo 驱动器——vo_gpu 为例。在 /video/out/vo.c 中,你能够看到全部支持的 vo_driver:git
const struct vo_driver *const video_out_drivers[] = { &video_out_libmpv, #if HAVE_ANDROID &video_out_mediacodec_embed, #endif &video_out_gpu, #if HAVE_VDPAU &video_out_vdpau, #endif ...省略多个driver
Mpv 会根据系统、编译状况、传入参数决定使用哪一个具体的视频输出驱动。以后,调用该驱动的preinit
方法。对于 vo_gpu 来讲,它的下层还依赖于不一样的 render_context
,对应了在不一样系统环境上的渲染接口。这也是 Mpv 跨平台兼容的关键。全部 gpu 支持的渲染接口定义在 video/out/gpu/context.cgithub
static const struct ra_ctx_fns *contexts[] = { #if HAVE_D3D11 &ra_ctx_d3d11, #endif // OpenGL contexts: #if HAVE_EGL_ANDROID &ra_ctx_android, #endif #if HAVE_RPI &ra_ctx_rpi, #endif #if HAVE_GL_COCOA &ra_ctx_cocoa, #endif #if HAVE_EGL_ANGLE_WIN32 &ra_ctx_angle, #endif #if HAVE_GL_WIN32 &ra_ctx_wgl, #endif ...省略大量接口 };
每一个底层接口都由结构体 ra_ctx_fns 定义。这个结构体暴露了一组用于配置的具体方法:macos
const struct ra_ctx_fns ra_ctx_d3d11 = { .type = "d3d11", .name = "d3d11", .reconfig = d3d11_reconfig, .control = d3d11_control, .init = d3d11_init, .uninit = d3d11_uninit, };
所以在 gpu 渲染驱动的 preinit
函数中一大任务就是调用具体渲染接口的 init
方法。app
视频、音频播放驱动初始化完毕后,就开始视频播放。整个播放的流程(render loop)以下伪代码:ide
for video in Videos { while(1) { render_frame(video); wait for next frame; } }
对的,就是这么简单粗暴。这里有意忽略了时间同步、音视频同步等具体细节,实际上 Mpv 内部大量依赖于锁和信号量进行线程间同步。函数
总结一下,一个初始化的流程涉及以下接口的调用:oop
下一篇文章,咱们顺着官方播放器的具体代码,看看 Mpv 具体初始化了哪些东西,并试图捋清楚 libmpv 又是如何进行初始化的。