mpv - video player based on MPlayer/mplayer2

	Commit message (Collapse)	Author	Age
*	ta: add another array helper macro	wm4	2015-06-01
\| \| \| \|	Stupid C.
*	ta: memcpy(ptr, NULL, 0) is undefined	wm4	2015-03-23
\|
*	ta: rename MP_TALLOC_ELEMS to MP_TALLOC_AVAIL	Ben Boeckel	2015-01-27
\| \| \| \| \|	The macro actually returns the available space in the array, not how much is actually filled in.
*	Remove some superfluous NULL checks	wm4	2014-11-21
\| \| \| \| \| \| \| \|	In all of these situations, NULL is logically not allowed, making the checks redundant. Coverity complained about accessing the pointers before checking them for NULL later.
*	ta/README: fix typos	wm4	2014-10-13
\|
*	talloc README: more human readible api reference	Kevin Mitchell	2014-04-13
\|
*	ta: fix comment	wm4	2014-02-23
\| \| \| \| \| \|	If this function could return the input value (i.e. the == case was correct), then macros like MP_GROW_ARRAY would have been incorrect. The implementation was correct though, so there's no bug.
*	ta: clarify a corner case	wm4	2014-02-23
\|
*	ta: check overflow in array realloc macros	wm4	2014-01-02
\|
*	ta: fix compilation with NDEBUG	wm4	2013-12-19
\|
*	Merge mp_talloc.h into ta/ta_talloc.h	wm4	2013-12-17
\|
*	ta: fix typo in comment	wm4	2013-11-20
\|
*	ta: re-add MinGW cargo culting	wm4	2013-11-02
\| \| \| \| \| \| \| \|	Not really cargo cult, but an unexplainable, needless difference that just exists to annoy us. Fixes that gcc on MinGW treats format specifiers in MSVC mode. Just why? Why?
*	ta: track location debug info in 2 more cases	wm4	2013-10-30
\| \| \| \|	Was overlooked.
*	Replace talloc	wm4	2013-10-13
	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.