mpv/video/mp_image_pool.h

#ifndef MPV_MP_IMAGE_POOL_H
#define MPV_MP_IMAGE_POOL_H

struct mp_image_pool;

struct mp_image_pool *mp_image_pool_new(int max_count);
struct mp_image *mp_image_pool_get(struct mp_image_pool *pool, int fmt,
                                   int w, int h);
void mp_image_pool_clear(struct mp_image_pool *pool);

void mp_image_pool_set_lru(struct mp_image_pool *pool);

struct mp_image *mp_image_pool_get_no_alloc(struct mp_image_pool *pool, int fmt,
                                            int w, int h);

typedef struct mp_image *(*mp_image_allocator)(void *data, int fmt, int w, int h);
void mp_image_pool_set_allocator(struct mp_image_pool *pool,
                                 mp_image_allocator cb, void  *cb_data);

struct mp_image *mp_image_pool_new_copy(struct mp_image_pool *pool,
                                        struct mp_image *img);
void mp_image_pool_make_writeable(struct mp_image_pool *pool,
                                  struct mp_image *img);

#endif
mp_image_pool: add pool to avoid frequent image reallocations Refcounting will conceptually allocate and free images all the time when using the filter chain. Add a pool that makes these reallocations cheap. This only affects the image data, not mp_image structs and similar small allocations. Small allocations are always fast with reasonable memory managers, while large image data will trigger mmap/munmap calls each time. 2012-12-12 22:55:34 +00:00			`#ifndef MPV_MP_IMAGE_POOL_H`
			`#define MPV_MP_IMAGE_POOL_H`

mp_image_pool: make reference counting thread-safe See previous commits. Also simplify this thing: 2 flags per pool image are enough to avoid a weird central refcount and an associated shared object keeping the refcount. We could even just store these two flags in the mp_image itself (like in mp_image.flags or mp_image.priv), but let's not for the sake of readability. 2013-07-27 22:10:58 +00:00			`struct mp_image_pool;`
mp_image_pool: add pool to avoid frequent image reallocations Refcounting will conceptually allocate and free images all the time when using the filter chain. Add a pool that makes these reallocations cheap. This only affects the image data, not mp_image structs and similar small allocations. Small allocations are always fast with reasonable memory managers, while large image data will trigger mmap/munmap calls each time. 2012-12-12 22:55:34 +00:00
			`struct mp_image_pool *mp_image_pool_new(int max_count);`
video: change image format from unsigned int to int in some places Image formats used to be FourCCs, so unsigned int was better. But now it's annoying and the only difference is that unsigned int is more to type than int. 2014-03-17 17:19:57 +00:00			`struct mp_image mp_image_pool_get(struct mp_image_pool pool, int fmt,`
mp_image_pool: add pool to avoid frequent image reallocations Refcounting will conceptually allocate and free images all the time when using the filter chain. Add a pool that makes these reallocations cheap. This only affects the image data, not mp_image structs and similar small allocations. Small allocations are always fast with reasonable memory managers, while large image data will trigger mmap/munmap calls each time. 2012-12-12 22:55:34 +00:00			`int w, int h);`
			`void mp_image_pool_clear(struct mp_image_pool *pool);`

mp_image_pool: add features needed for use with hwaccel The plan is to get rid of the custom VAAPI and possibly VDPAU surface allocators. Add custom surface allocation, because hwaccel surfaces are allocated completely differently from software surfaces. Add optional LRU allocation, which is (probably) helpful for hwaccel, but (probably) less optimal for software surfaces. mp_image_pool_get_no_alloc() is specifically for VAAPI, which can't allocate new decoder surfaces after decoder init. 2014-03-17 17:21:29 +00:00			`void mp_image_pool_set_lru(struct mp_image_pool *pool);`

			`struct mp_image mp_image_pool_get_no_alloc(struct mp_image_pool pool, int fmt,`
			`int w, int h);`

			`typedef struct mp_image (mp_image_allocator)(void *data, int fmt, int w, int h);`
			`void mp_image_pool_set_allocator(struct mp_image_pool *pool,`
			`mp_image_allocator cb, void *cb_data);`

mp_image_pool: add pool to avoid frequent image reallocations Refcounting will conceptually allocate and free images all the time when using the filter chain. Add a pool that makes these reallocations cheap. This only affects the image data, not mp_image structs and similar small allocations. Small allocations are always fast with reasonable memory managers, while large image data will trigger mmap/munmap calls each time. 2012-12-12 22:55:34 +00:00			`struct mp_image mp_image_pool_new_copy(struct mp_image_pool pool,`
			`struct mp_image *img);`
			`void mp_image_pool_make_writeable(struct mp_image_pool *pool,`
			`struct mp_image *img);`

			`#endif`