RepoMirrors
/
mpv
mirror of https://github.com/mpv-player/mpv
1
0
Fork 0
Code Issues Releases Wiki Activity
mpv/video/mp_image_pool.h

45 lines
1.7 KiB
C
Raw Permalink Normal View History

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
video: introduce failure path for image allocations Until now, failure to allocate image data resulted in a crash (i.e. abort() was called). This was intentional, because it's pretty silly to degrade playback, and in almost all situations, the OOM will probably kill you anyway. (And then there's the standard Linux overcommit behavior, which also will kill you at some point.) But I changed my opinion, so here we go. This change does not affect _all_ memory allocations, just image data. Now in most failure cases, the output will just be skipped. For video filters, this coincidentally means that failure is treated as EOF (because the playback core assumes EOF if nothing comes out of the video filter chain). In other situations, output might be in some way degraded, like skipping frames, not scaling OSD, and such. Functions whose return values changed semantics: mp_image_alloc mp_image_new_copy mp_image_new_ref mp_image_make_writeable mp_image_setrefp mp_image_to_av_frame_and_unref mp_image_from_av_frame mp_image_new_external_ref mp_image_new_custom_ref mp_image_pool_make_writeable mp_image_pool_get mp_image_pool_new_copy mp_vdpau_mixed_frame_create vf_alloc_out_image vf_make_out_image_writeable glGetWindowScreenshot
2014-06-17 20:43:43 +00:00
#include <stdbool.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
video: change some mp_image_pool semantics Remove the max_count creation parameter, because it's pointless and rarely ever did anything. Add a talloc parent parameter instead (which is something completely different, but convenient, and all callers needs to be changed anyway). Instead of clearing the pool when the now removed maximum is reached, clear it on image parameter changes instead.
2018-01-12 00:40:01 +00:00
struct mp_image_pool *mp_image_pool_new(void *tparent);
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);
mp_image_pool: add mp_image_pool_add Provide a way for the user to add mp_images to the pool. This is required for dxva2, for which using set_allocator is extremely awkward since all the d3d9 surfaces must be allocated in advance and all together.
2016-02-16 00:04:52 +00:00
// the reference to "new" is transferred to the pool
void mp_image_pool_add(struct mp_image_pool *pool, struct mp_image *new);
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
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);
video: introduce failure path for image allocations Until now, failure to allocate image data resulted in a crash (i.e. abort() was called). This was intentional, because it's pretty silly to degrade playback, and in almost all situations, the OOM will probably kill you anyway. (And then there's the standard Linux overcommit behavior, which also will kill you at some point.) But I changed my opinion, so here we go. This change does not affect _all_ memory allocations, just image data. Now in most failure cases, the output will just be skipped. For video filters, this coincidentally means that failure is treated as EOF (because the playback core assumes EOF if nothing comes out of the video filter chain). In other situations, output might be in some way degraded, like skipping frames, not scaling OSD, and such. Functions whose return values changed semantics: mp_image_alloc mp_image_new_copy mp_image_new_ref mp_image_make_writeable mp_image_setrefp mp_image_to_av_frame_and_unref mp_image_from_av_frame mp_image_new_external_ref mp_image_new_custom_ref mp_image_pool_make_writeable mp_image_pool_get mp_image_pool_new_copy mp_vdpau_mixed_frame_create vf_alloc_out_image vf_make_out_image_writeable glGetWindowScreenshot
2014-06-17 20:43:43 +00:00
bool mp_image_pool_make_writeable(struct mp_image_pool *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 *img);
vaapi: use libavutil functions for copying hw surfaces to memory Makes va_surface_download() call mp_image_hw_download() for libavutil-allocated surfaces, which in turn calls av_hwframe_transfer_data(). mp_image_hw_download() is actually not specific to vaapi, and can be used for any hw surface allocated by libavutil.
2017-01-12 11:51:55 +00:00
struct mp_image *mp_image_hw_download(struct mp_image *img,
struct mp_image_pool *swpool);
mp_image_pool: expose a function for reporting hw download format Basically predicts what mp_image_hw_download() will do. It's pretty simple if it gets the full mp_image. (Taking just a imgfmt would make this pretty hard/impossible or inaccurate.) Used in one of the following commits.
2019-10-02 19:07:14 +00:00
int mp_image_hw_download_get_sw_format(struct mp_image *img);
vf_vavpp: use libavutil hw frames API for frame pool and upload Another step to get rid of the legacy crap in vaapi.c. (Most is still kept, because it's in use by vo_vaapi.c.)
2017-09-29 15:54:21 +00:00
bool mp_image_hw_upload(struct mp_image *hw_img, struct mp_image *src);
mp_image_pool: add helper functions for FFmpeg hw frames pools FFmpeg has its own rather "special" image pools (AVHWFramesContext) specifically for hardware decoding. So it's not really practical to use our own pool implementation. Add these helpers, which make it easier to use FFmpeg's code in mpv.
2018-01-16 10:46:16 +00:00
struct AVBufferRef;
bool mp_update_av_hw_frames_pool(struct AVBufferRef **hw_frames_ctx,
struct AVBufferRef *hw_device_ctx,
int imgfmt, int sw_imgfmt, int w, int h);
struct mp_image *mp_av_pool_image_hw_upload(struct AVBufferRef *hw_frames_ctx,
struct mp_image *src);
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
#endif