Source structure and call hierarchy

Source structure

Pulling the latest source from Github, the directory structure as follows:

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>: This folder placement method (header) as libmpv link library exposed concrete implementations in other folder. In fact compiled into a dynamic link library when exposed method names are defined in the libmpv/mpv.definside. But the .def file is not a standard export file .
<Audio>: As the name suggests, the audio decoder source associated.
<Video>: video decoding, separation, rendering the relevant documents, respectively decode, filter, out folder.
<Player>: to achieve a particular player, the calling module interior sections above.
wscript: compile the script. Newly added to the file thus added to the compilation process.

Internal call hierarchy

The core context initialization

If the player starts to play, first initializes an internal state, mainly initialized MPContextthis structure. This structure is a hodgepodge, all players relevant parameters, dynamic properties that are bound to it. The kernel then enter idle state, waiting for the video.

Rendering drive initialization

Open the first media file, it will start the video / audio player link (video_output_chain) initialization, including initialization decoding and rendering modules. Rendering module by the structure vo_driverdefined, (MPV internal structure to define an interface), e.g. vo_gpu defined as follows:

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,
};

Next to this we are the most commonly used Windows vo drive --vo_gpu example. In /video/out/vo.c, you can see all supported vo_driver:

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 based systems, compilers, the incoming parameter determines which specific video output driver. After that, the driver calls the preinitmethod. For vo_gpu, it also depends on the lower layer of different render_context, corresponding to different rendering interface system environment. This is also the key to cross-platform compatible Mpv. All gpu rendering support interfaces defined in the video / out / gpu / context.c

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
...省略大量接口
};

Each body ra_ctx_fns by underlying interface definition structure. This structure exposes a set of methods for specific configuration:

const struct ra_ctx_fns ra_ctx_d3d11 = {
    .type = "d3d11",
    .name = "d3d11",
    .reconfig = d3d11_reconfig,
    .control = d3d11_control,
    .init = d3d11_init,
    .uninit = d3d11_uninit,
};

So gpu rendering driving preinita big task is to render specific call interface function initmethod.

Video playback cycle

After the video, audio playback drive initialization is complete, start video playback. The entire process of playback (render loop) the following pseudocode:

for video in Videos {
    while(1) {
        render_frame(video);
        wait for next frame;
    }
}

Right, it is so simple and crude. Here deliberately ignores the time synchronization, audio and video synchronization and other details, in fact, a lot depends on the internal Mpv locks and semaphores inter-thread synchronization.

TL;DR

To sum up, a call initialization process involves the following interfaces:

MPContext initialization
vo_driver initialization
render_backend initialized (i.e., specific, associated with the underlying interface system environment)

The next article, we follow specific code official players and see what things Mpv specific initialization and tried to stroke clear libmpv how is initialized.

MPV explore the source: source structure and call hierarchy