RepoMirrors/mpv
1
0
Fork 0
mirror of https://github.com/mpv-player/mpv synced 2025-01-20 14:20:55 +00:00
Code Issues Releases Wiki Activity

tech-overview.txt: reflect recent updates

Browse Source 
mplayer.c split, and some other things.
This commit is contained in:
wm4 2013-10-30 22:35:48 +01:00
parent 03ec49be8f
commit 2c48a16e99
1 changed files with 32 additions and 21 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

53
DOCS/tech-overview.txt
View File

@ -2,11 +2,12 @@ NOTE: DOCS/OUTDATED-tech/* may contain more detailed information, but most of it
is possibly or definitely outdated. This file intends to give a big is possibly or definitely outdated. This file intends to give a big
picture of how mpv is structured. picture of how mpv is structured.
mpvcore/mplayer.c: mpvcore/player/*.c:
This contains the main play loop, anything related to mpv and playback Essentially makes up the player applications, including the main() function
related initializations. It also contains the main function. Generally, it and the playback loop.
accesses all other subsystems, initializes them, and pushes data between
them during playback. Generally, it accesses all other subsystems, initializes them, and pushes
data between them during playback.
The structure is as follows (as of commit e13c05366557cb): The structure is as follows (as of commit e13c05366557cb):
* main(): * main():
@ -42,7 +43,7 @@ mpvcore/mplayer.c:
- the other subsystems rarely call back into the frontend, and the frontend - the other subsystems rarely call back into the frontend, and the frontend
polls them instead (probably a good thing) polls them instead (probably a good thing)
I like to call mplayer.c (and some other files) the "frontend". I like to call the player/*.c files the "frontend".
talloc.h & talloc.c: talloc.h & talloc.c:
Hierarchical memory manager copied from Samba. It's like a malloc() with Hierarchical memory manager copied from Samba. It's like a malloc() with
@ -82,36 +83,46 @@ talloc.h & talloc.c:
rid of the talloc emulation later and use TA natively. rid of the talloc emulation later and use TA natively.
(See ta/README for details.) (See ta/README for details.)
mpvcore/mp_core.h: mpvcore/player/command.c:
Data structures for mplayer.c and command.c. They are usually not accessed This contains the implementation for slave commands and properties.
by other parts of mpv for the sake of modularization. Properties are essentially dynamic variables changed by certain commands.
This is basically responsible for all user commands, like initiating
seeking, switching tracks, etc. It calls into other player/*.c files,
where most of the work is done, but also calls other parts of mpv.
mpvcore/player/mp_core.h:
Data structures and function prototypes for most of player/*.c. They are
usually not accessed by other parts of mpv for the sake of modularization.
Note that there are lots of global variables floating around everywhere Note that there are lots of global variables floating around everywhere
else. This is an ongoing transition, and eventually there should be no else. This is an ongoing transition, and eventually there should be no
global variables anymore. global variables anymore.
options.h contains the global option struct MPOpts, and its default values mpvcore/options.h, mpvcore/options.c
are in defaultopts.c for some reason. options.h contains the global option struct MPOpts. The option declarations
(option names, types, and MPOpts offsets for the option parser) are in
options.c. Most default values for options and MPOpts are in
mp_default_opts at the end of options.c.
MPOpts is unfortunarely quite monolithic, and virtually accessed by
everything.But some components (like video outputs and video filters) have
their own sub-option tables separate from MPOpts.
The actual option parser is spread over m_option.c, m_config.c, and
parser-mpcmd.c, and uses the option table in options.c.
mpvcore/input/input.c: mpvcore/input/input.c:
This translates keyboard input comming from libvo and other sources (such This translates keyboard input comming from libvo and other sources (such
as remote control devices like Apple IR or slave mode commands) to the as remote control devices like Apple IR or slave mode commands) to the
key bindings listed in the user's (or the builtin) input.conf and turns key bindings listed in the user's (or the builtin) input.conf and turns
them into items of type struct mp_cmd. These commands are queued, and read them into items of type struct mp_cmd. These commands are queued, and read
by mplayer.c. They get pushed with run_command() to command.c. by playloop.c. They get pushed with run_command() to command.c.
Note that keyboard input and slave mode input are essentially the same Note that keyboard input and slave mode input are essentially the same
things. Just looking at input.conf should make this clear. (The other things. Just looking at input.conf should make this clear. (The other
direction of slave mode communication, mpv to application, consists of direction of slave mode communication, mpv to application, consists of
random mp_msg() calls all over the code in all parts of the player.) random mp_msg() calls all over the code in all parts of the player.)
mpvcore/command.c:
This contains the implementation for slave commands and properties.
Properties are essentially dynamic variables changed by certain commands.
This is basically responsible for all user commands, like initiating
seeking, switching tracks, etc. It calls into mplayer.c, where most of the
work is done, but also into other parts of mpv.
mpvcore/mp_msg.h: mpvcore/mp_msg.h:
All terminal output should go through mp_msg(). All terminal output should go through mp_msg().
@ -229,8 +240,8 @@ sub/:
detection as well as timing postprocessing work. (Timing postprocessing detection as well as timing postprocessing work. (Timing postprocessing
removes tiny gaps or overlaps between subtitle events.) removes tiny gaps or overlaps between subtitle events.)
mpvcore/timeline/: mpvcore/player/timeline/:
A timeline is the abstraction used by mplayer.c to combine several files A timeline is the abstraction used by loadfile.c to combine several files
into one seemingly linear video. It's mainly used for ordered chapters into one seemingly linear video. It's mainly used for ordered chapters
playback. The high level code to find and load other files containing the playback. The high level code to find and load other files containing the
segments for playing an ordered chapters file is in tl_matroska.c. segments for playing an ordered chapters file is in tl_matroska.c.