0933f12d28
There are multiple reasons to do this. One big reason is the license:
talloc is LGPLv3+, which forces mpv to be licensed as GPLv3+.
Another one is that our talloc copy contains modifications, which makes
it essentially incompatible with upstream talloc (in particular, our
version aborts on out of memory conditions - well, it wasn't my idea).
Updating from upstream is also a bit involved - the talloc source is
not really organized in a way to allow copying it into projects (and
this isn't an intended use-case).
Finally, talloc is kind of big and bloated. The replacement halves the
amount of code - mainly because we didn't use all talloc features. It's
even more extreme if you compare upstream talloc (~4700 lines) and the
new allocator without talloc compat (~900 lines).
The replacement provides all features we need. It also doesn't clash
with talloc. (The talloc compatibility wrapper uses macros to avoid
introducing linker-level symbols which could clash with libtalloc.)
It also tries to lower the overhead (only 4 words opposed to 10 words
in talloc for leaf nodes in release mode). Debugging features like leak
reporting can be enabled at compile time and add somewhat more overhead.
Though I'm not sure whether the overhead reduction was actually
successful: allocations with children need an "extra" header, which adds
plenty of overhead, and it turns out that almost half of all allocations
have children. Maybe the implementation could be simplified and the
extra header removed - even then, overhead would be lower than talloc's.
Currently, debugging features can be entirely deactivated by defining
NDEBUG - I'm not sure if anything defines this directly yet, though.
Unlike in talloc, the leak reporting stuff is thread-safe. (That's also
why it's far less elegant, and requires extra list pointers.)
Comes with a compatibility layer, so no changes to mpv source code
are needed. The idea is that we will pretend to be using talloc for
a while, so that we can revert to our old talloc implementation at
any time for debugging purposes.
Some inspiration was taken from Mesa's ralloc:
http://cgit.freedesktop.org/mesa/mesa/tree/src/glsl/ralloc.h
This is another talloc replacement, but lacks some features we need
(getting size of an allocation, debugging features, being able to
access children in the dtor).
There's some information in ta/README what will happen next and how the
transition is expected to progress.
|
||
|---|---|---|
| audio | ||
| compat | ||
| demux | ||
| DOCS | ||
| etc | ||
| mpvcore | ||
| osdep | ||
| stream | ||
| sub | ||
| ta | ||
| TOOLS | ||
| video | ||
| .gitignore | ||
| .travis.yml | ||
| configure | ||
| Copyright | ||
| LICENSE | ||
| Makefile | ||
| README.md | ||
| talloc.h | ||
| travis-deps | ||
| version.sh | ||
mpv
Overview
mpv is a movie player based on MPlayer and mplayer2. It supports a wide variety of video file formats, audio and video codecs, and subtitle types.
If you are wondering what's different from mplayer2 and MPlayer you can read more about the changes.
Compilation
Compiling with full features requires development files for several
external libraries. Below is a list of some important requirements. For
more information see the output of ./configure --help for a list of options,
or look at the list of enabled and disabled features printed after running
./configure. If you think you have support for some feature installed
but configure fails to detect it, the file config.log may contain
information about the reasons for the failure.
Essential dependencies (incomplete list):
- gcc or clang
- X development headers (xlib, X extensions, libvdpau, libGL, libXv, ...)
- Audio output development headers (libasound, pulseaudio)
- fribidi, freetype, fontconfig development headers (for libass)
- libass
- FFmpeg libraries (libavutil libavcodec libavformat libswscale libpostproc)
- libjpeg
- libquvi if you want to play Youtube videos directly
- libx264/libmp3lame/libfdk-aac if you want to use encoding (has to be explicitly enabled when compiling ffmpeg)
Most of the above libraries are available in suitable versions on normal Linux distributions. However FFmpeg is an exception (distro versions may be too old to work at all or work well). For that reason you may want to use the separately available build wrapper (mpv-build) that first compiles FFmpeg libraries and libass, and then compiles the player statically linked against those.
If you are running Mac OSX and using homebrew we provide homebrew-mpv, an up to date formula that compiles mpv with sensible dependencies and defaults for OSX.
configure --enable-* parameters
The --enable-* parameters unconditionally force options on, completely
skipping autodetection. This behavior is unlike what you may be used to from
autoconf-based configure scripts that can decide to override you. This greater
level of control comes at a price. You may have to provide the correct compiler
and linker flags yourself.
If you used one of these options and experience a compilation or linking failure, make sure you have passed the necessary compiler/linker flags to configure.
mpv's configure script is greedy and automatically enables features as a result
of autodetection. The cases where you may want to use --enable-* are very
limited.
Bug reports
Please use the issue tracker provided by GitHub to send us bug reports or feature requests.
Contributing
For small changes you can just send us pull requests through GitHub. For bigger changes come and talk to us on IRC before you start working on them. It will make code review easier for both parties later on.
Contacts
These forms of contact are meant to ask questions about mpv usage, give feedback on mpv and discuss it's development.
If possible, please avoid posting bugs here and use the issue tracker instead.
- Users IRC Channel:
#mpv-playeronirc.freenode.net - Users Mailing List:
mpv-users@googlegroups.com(Archive / Subscribe). - Devel Mailing List:
mpv-devel@googlegroups.com(Archive / Subscribe)
To contact the mpv team in private write to mpv-team@googlegroups.com.