summaryrefslogtreecommitdiffstats
path: root/DOCS/tech-overview.txt
diff options
context:
space:
mode:
authorwm4 <wm4@nowhere>2013-10-30 22:35:48 +0100
committerwm4 <wm4@nowhere>2013-10-30 22:35:48 +0100
commit2c48a16e991dd4597db8ada05fc1122038873676 (patch)
treedd93c50afa6c4dbfb5f2825d04eb8065cb7efa78 /DOCS/tech-overview.txt
parent03ec49be8fd43ea2dda3e14da506fb5fdacc2faf (diff)
downloadmpv-2c48a16e991dd4597db8ada05fc1122038873676.tar.bz2
mpv-2c48a16e991dd4597db8ada05fc1122038873676.tar.xz
tech-overview.txt: reflect recent updates
mplayer.c split, and some other things.
Diffstat (limited to 'DOCS/tech-overview.txt')
-rw-r--r--DOCS/tech-overview.txt53
1 files changed, 32 insertions, 21 deletions
diff --git a/DOCS/tech-overview.txt b/DOCS/tech-overview.txt
index cc4c8ecaae..f283f26a7b 100644
--- a/DOCS/tech-overview.txt
+++ b/DOCS/tech-overview.txt
@@ -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
picture of how mpv is structured.
-mpvcore/mplayer.c:
- This contains the main play loop, anything related to mpv and playback
- related initializations. It also contains the main function. Generally, it
- accesses all other subsystems, initializes them, and pushes data between
- them during playback.
+mpvcore/player/*.c:
+ Essentially makes up the player applications, including the main() function
+ and the playback loop.
+
+ Generally, it accesses all other subsystems, initializes them, and pushes
+ data between them during playback.
The structure is as follows (as of commit e13c05366557cb):
* main():
@@ -42,7 +43,7 @@ mpvcore/mplayer.c:
- the other subsystems rarely call back into the frontend, and the frontend
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:
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.
(See ta/README for details.)
-mpvcore/mp_core.h:
- Data structures for mplayer.c and command.c. They are usually not accessed
- by other parts of mpv for the sake of modularization.
+mpvcore/player/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 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
else. This is an ongoing transition, and eventually there should be no
global variables anymore.
- options.h contains the global option struct MPOpts, and its default values
- are in defaultopts.c for some reason.
+mpvcore/options.h, mpvcore/options.c
+ 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:
This translates keyboard input comming from libvo and other sources (such
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
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
things. Just looking at input.conf should make this clear. (The other
direction of slave mode communication, mpv to application, consists of
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:
All terminal output should go through mp_msg().
@@ -229,8 +240,8 @@ sub/:
detection as well as timing postprocessing work. (Timing postprocessing
removes tiny gaps or overlaps between subtitle events.)
-mpvcore/timeline/:
- A timeline is the abstraction used by mplayer.c to combine several files
+mpvcore/player/timeline/:
+ 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
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.