2012-12-12 22:55:34 +00:00
|
|
|
/*
|
|
|
|
* This file is part of mpv.
|
|
|
|
*
|
|
|
|
* mpv is free software; you can redistribute it and/or modify
|
|
|
|
* it under the terms of the GNU General Public License as published by
|
|
|
|
* the Free Software Foundation; either version 2 of the License, or
|
|
|
|
* (at your option) any later version.
|
|
|
|
*
|
|
|
|
* mpv is distributed in the hope that it will be useful,
|
|
|
|
* but WITHOUT ANY WARRANTY; without even the implied warranty of
|
|
|
|
* MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
|
|
|
|
* GNU General Public License for more details.
|
|
|
|
*
|
|
|
|
* You should have received a copy of the GNU General Public License along
|
2015-04-13 07:36:54 +00:00
|
|
|
* with mpv. If not, see <http://www.gnu.org/licenses/>.
|
2012-12-12 22:55:34 +00:00
|
|
|
*/
|
|
|
|
|
2013-07-27 22:10:58 +00:00
|
|
|
#include "config.h"
|
|
|
|
|
|
|
|
#include <stddef.h>
|
|
|
|
#include <stdbool.h>
|
2013-11-28 18:28:38 +00:00
|
|
|
#include <pthread.h>
|
2012-12-12 22:55:34 +00:00
|
|
|
#include <assert.h>
|
|
|
|
|
video: replace our own refcounting with libavutil's
mpv had refcounted frames before libav*, so we were not using
libavutil's facilities. Change this and drop our own code.
Since AVFrames are not actually refcounted, and only the image data
they reference, the semantics change a bit. This affects mainly
mp_image_pool, which was operating on whole images instead of buffers.
While we could work on AVBufferRefs instead (and use AVBufferPool),
this doesn't work for use with hardware decoding, which doesn't
map cleanly to FFmpeg's reference counting. But it worked out. One
weird consequence is that we still need our custom image data
allocation function (for normal image data), because AVFrame's uses
multiple buffers.
There also seems to be a timing-dependent problem with vaapi (the
pool appears to be "leaking" surfaces). I don't know if this is a new
problem, or whether the code changes just happened to cause it more
often. Raising the number of reserved surfaces seemed to fix it, but
since it appears to be timing dependent, and I couldn't find anything
wrong with the code, I'm just going to assume it's not a new bug.
2015-07-05 21:56:00 +00:00
|
|
|
#include <libavutil/buffer.h>
|
|
|
|
|
2012-12-12 22:55:34 +00:00
|
|
|
#include "talloc.h"
|
|
|
|
|
2013-12-17 01:39:45 +00:00
|
|
|
#include "common/common.h"
|
2012-12-12 22:55:34 +00:00
|
|
|
#include "video/mp_image.h"
|
|
|
|
|
|
|
|
#include "mp_image_pool.h"
|
|
|
|
|
2013-07-27 22:10:58 +00:00
|
|
|
static pthread_mutex_t pool_mutex = PTHREAD_MUTEX_INITIALIZER;
|
|
|
|
#define pool_lock() pthread_mutex_lock(&pool_mutex)
|
|
|
|
#define pool_unlock() pthread_mutex_unlock(&pool_mutex)
|
|
|
|
|
|
|
|
// Thread-safety: the pool itself is not thread-safe, but pool-allocated images
|
2013-11-28 18:28:38 +00:00
|
|
|
// can be referenced and unreferenced from other threads. (As long as the image
|
|
|
|
// destructors are thread-safe.)
|
2013-07-27 22:10:58 +00:00
|
|
|
|
|
|
|
struct mp_image_pool {
|
|
|
|
int max_count;
|
|
|
|
|
|
|
|
struct mp_image **images;
|
|
|
|
int num_images;
|
2014-03-17 17:21:29 +00:00
|
|
|
|
|
|
|
mp_image_allocator allocator;
|
|
|
|
void *allocator_ctx;
|
|
|
|
|
|
|
|
bool use_lru;
|
|
|
|
unsigned int lru_counter;
|
2013-07-27 22:10:58 +00:00
|
|
|
};
|
|
|
|
|
|
|
|
// Used to gracefully handle the case when the pool is freed while image
|
|
|
|
// references allocated from the image pool are still held by someone.
|
|
|
|
struct image_flags {
|
|
|
|
// If both of these are false, the image must be freed.
|
|
|
|
bool referenced; // outside mp_image reference exists
|
|
|
|
bool pool_alive; // the mp_image_pool references this
|
2014-03-17 17:21:29 +00:00
|
|
|
unsigned int order; // for LRU allocation (basically a timestamp)
|
2012-12-12 22:55:34 +00:00
|
|
|
};
|
|
|
|
|
2013-10-12 23:16:30 +00:00
|
|
|
static void image_pool_destructor(void *ptr)
|
2012-12-12 22:55:34 +00:00
|
|
|
{
|
|
|
|
struct mp_image_pool *pool = ptr;
|
|
|
|
mp_image_pool_clear(pool);
|
|
|
|
}
|
|
|
|
|
|
|
|
struct mp_image_pool *mp_image_pool_new(int max_count)
|
|
|
|
{
|
|
|
|
struct mp_image_pool *pool = talloc_ptrtype(NULL, pool);
|
|
|
|
talloc_set_destructor(pool, image_pool_destructor);
|
|
|
|
*pool = (struct mp_image_pool) {
|
|
|
|
.max_count = max_count,
|
|
|
|
};
|
|
|
|
return pool;
|
|
|
|
}
|
|
|
|
|
|
|
|
void mp_image_pool_clear(struct mp_image_pool *pool)
|
|
|
|
{
|
|
|
|
for (int n = 0; n < pool->num_images; n++) {
|
|
|
|
struct mp_image *img = pool->images[n];
|
2013-07-27 22:10:58 +00:00
|
|
|
struct image_flags *it = img->priv;
|
|
|
|
bool referenced;
|
|
|
|
pool_lock();
|
|
|
|
assert(it->pool_alive);
|
|
|
|
it->pool_alive = false;
|
|
|
|
referenced = it->referenced;
|
|
|
|
pool_unlock();
|
|
|
|
if (!referenced)
|
2012-12-12 22:55:34 +00:00
|
|
|
talloc_free(img);
|
|
|
|
}
|
|
|
|
pool->num_images = 0;
|
|
|
|
}
|
|
|
|
|
2013-07-27 22:10:58 +00:00
|
|
|
// This is the only function that is allowed to run in a different thread.
|
|
|
|
// (Consider passing an image to another thread, which frees it.)
|
video: replace our own refcounting with libavutil's
mpv had refcounted frames before libav*, so we were not using
libavutil's facilities. Change this and drop our own code.
Since AVFrames are not actually refcounted, and only the image data
they reference, the semantics change a bit. This affects mainly
mp_image_pool, which was operating on whole images instead of buffers.
While we could work on AVBufferRefs instead (and use AVBufferPool),
this doesn't work for use with hardware decoding, which doesn't
map cleanly to FFmpeg's reference counting. But it worked out. One
weird consequence is that we still need our custom image data
allocation function (for normal image data), because AVFrame's uses
multiple buffers.
There also seems to be a timing-dependent problem with vaapi (the
pool appears to be "leaking" surfaces). I don't know if this is a new
problem, or whether the code changes just happened to cause it more
often. Raising the number of reserved surfaces seemed to fix it, but
since it appears to be timing dependent, and I couldn't find anything
wrong with the code, I'm just going to assume it's not a new bug.
2015-07-05 21:56:00 +00:00
|
|
|
static void unref_image(void *opaque, uint8_t *data)
|
2012-12-12 22:55:34 +00:00
|
|
|
{
|
video: replace our own refcounting with libavutil's
mpv had refcounted frames before libav*, so we were not using
libavutil's facilities. Change this and drop our own code.
Since AVFrames are not actually refcounted, and only the image data
they reference, the semantics change a bit. This affects mainly
mp_image_pool, which was operating on whole images instead of buffers.
While we could work on AVBufferRefs instead (and use AVBufferPool),
this doesn't work for use with hardware decoding, which doesn't
map cleanly to FFmpeg's reference counting. But it worked out. One
weird consequence is that we still need our custom image data
allocation function (for normal image data), because AVFrame's uses
multiple buffers.
There also seems to be a timing-dependent problem with vaapi (the
pool appears to be "leaking" surfaces). I don't know if this is a new
problem, or whether the code changes just happened to cause it more
often. Raising the number of reserved surfaces seemed to fix it, but
since it appears to be timing dependent, and I couldn't find anything
wrong with the code, I'm just going to assume it's not a new bug.
2015-07-05 21:56:00 +00:00
|
|
|
struct mp_image *img = opaque;
|
2013-07-27 22:10:58 +00:00
|
|
|
struct image_flags *it = img->priv;
|
|
|
|
bool alive;
|
|
|
|
pool_lock();
|
|
|
|
assert(it->referenced);
|
|
|
|
it->referenced = false;
|
|
|
|
alive = it->pool_alive;
|
|
|
|
pool_unlock();
|
|
|
|
if (!alive)
|
2012-12-12 22:55:34 +00:00
|
|
|
talloc_free(img);
|
|
|
|
}
|
|
|
|
|
2014-03-17 17:21:29 +00:00
|
|
|
// Return a new image of given format/size. Unlike mp_image_pool_get(), this
|
|
|
|
// returns NULL if there is no free image of this format/size.
|
|
|
|
struct mp_image *mp_image_pool_get_no_alloc(struct mp_image_pool *pool, int fmt,
|
|
|
|
int w, int h)
|
2012-12-12 22:55:34 +00:00
|
|
|
{
|
|
|
|
struct mp_image *new = NULL;
|
2013-07-27 22:10:58 +00:00
|
|
|
pool_lock();
|
2012-12-12 22:55:34 +00:00
|
|
|
for (int n = 0; n < pool->num_images; n++) {
|
|
|
|
struct mp_image *img = pool->images[n];
|
2014-03-17 17:21:29 +00:00
|
|
|
struct image_flags *img_it = img->priv;
|
|
|
|
assert(img_it->pool_alive);
|
|
|
|
if (!img_it->referenced) {
|
2013-07-27 22:10:58 +00:00
|
|
|
if (img->imgfmt == fmt && img->w == w && img->h == h) {
|
2014-03-17 17:21:29 +00:00
|
|
|
if (pool->use_lru) {
|
|
|
|
struct image_flags *new_it = new ? new->priv : NULL;
|
|
|
|
if (!new_it || new_it->order > img_it->order)
|
|
|
|
new = img;
|
|
|
|
} else {
|
|
|
|
new = img;
|
|
|
|
break;
|
|
|
|
}
|
2013-07-27 22:10:58 +00:00
|
|
|
}
|
2012-12-12 22:55:34 +00:00
|
|
|
}
|
|
|
|
}
|
2013-07-27 22:10:58 +00:00
|
|
|
pool_unlock();
|
2014-03-17 17:21:29 +00:00
|
|
|
if (!new)
|
|
|
|
return NULL;
|
video: replace our own refcounting with libavutil's
mpv had refcounted frames before libav*, so we were not using
libavutil's facilities. Change this and drop our own code.
Since AVFrames are not actually refcounted, and only the image data
they reference, the semantics change a bit. This affects mainly
mp_image_pool, which was operating on whole images instead of buffers.
While we could work on AVBufferRefs instead (and use AVBufferPool),
this doesn't work for use with hardware decoding, which doesn't
map cleanly to FFmpeg's reference counting. But it worked out. One
weird consequence is that we still need our custom image data
allocation function (for normal image data), because AVFrame's uses
multiple buffers.
There also seems to be a timing-dependent problem with vaapi (the
pool appears to be "leaking" surfaces). I don't know if this is a new
problem, or whether the code changes just happened to cause it more
often. Raising the number of reserved surfaces seemed to fix it, but
since it appears to be timing dependent, and I couldn't find anything
wrong with the code, I'm just going to assume it's not a new bug.
2015-07-05 21:56:00 +00:00
|
|
|
|
|
|
|
// Reference the new image. Since mp_image_pool is not declared thread-safe,
|
|
|
|
// and unreffing images from other threads does not allocate new images,
|
|
|
|
// no synchronization is required here.
|
|
|
|
for (int p = 0; p < MP_MAX_PLANES; p++)
|
|
|
|
assert(!!new->bufs[p] == !p); // only 1 AVBufferRef
|
|
|
|
|
|
|
|
struct mp_image *ref = mp_image_new_dummy_ref(new);
|
|
|
|
|
|
|
|
// This assumes the buffer is at this point exclusively owned by us: we
|
|
|
|
// can't track whether the buffer is unique otherwise.
|
|
|
|
// (av_buffer_is_writable() checks the refcount of the new buffer only.)
|
|
|
|
int flags = av_buffer_is_writable(new->bufs[0]) ? 0 : AV_BUFFER_FLAG_READONLY;
|
|
|
|
ref->bufs[0] = av_buffer_create(new->bufs[0]->data, new->bufs[0]->size,
|
|
|
|
unref_image, new, flags);
|
|
|
|
if (!ref->bufs[0]) {
|
|
|
|
talloc_free(ref);
|
|
|
|
return NULL;
|
|
|
|
}
|
|
|
|
|
2014-03-17 17:21:29 +00:00
|
|
|
struct image_flags *it = new->priv;
|
|
|
|
assert(!it->referenced && it->pool_alive);
|
|
|
|
it->referenced = true;
|
|
|
|
it->order = ++pool->lru_counter;
|
video: replace our own refcounting with libavutil's
mpv had refcounted frames before libav*, so we were not using
libavutil's facilities. Change this and drop our own code.
Since AVFrames are not actually refcounted, and only the image data
they reference, the semantics change a bit. This affects mainly
mp_image_pool, which was operating on whole images instead of buffers.
While we could work on AVBufferRefs instead (and use AVBufferPool),
this doesn't work for use with hardware decoding, which doesn't
map cleanly to FFmpeg's reference counting. But it worked out. One
weird consequence is that we still need our custom image data
allocation function (for normal image data), because AVFrame's uses
multiple buffers.
There also seems to be a timing-dependent problem with vaapi (the
pool appears to be "leaking" surfaces). I don't know if this is a new
problem, or whether the code changes just happened to cause it more
often. Raising the number of reserved surfaces seemed to fix it, but
since it appears to be timing dependent, and I couldn't find anything
wrong with the code, I'm just going to assume it's not a new bug.
2015-07-05 21:56:00 +00:00
|
|
|
return ref;
|
2014-03-17 17:21:29 +00:00
|
|
|
}
|
2013-07-27 22:10:58 +00:00
|
|
|
|
2014-03-17 17:21:29 +00:00
|
|
|
// Return a new image of given format/size. The only difference to
|
|
|
|
// mp_image_alloc() is that there is a transparent mechanism to recycle image
|
|
|
|
// data allocations through this pool.
|
2015-01-22 16:37:40 +00:00
|
|
|
// If pool==NULL, mp_image_alloc() is called (for convenience).
|
2014-03-17 17:21:29 +00:00
|
|
|
// The image can be free'd with talloc_free().
|
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
|
|
|
// Returns NULL on OOM.
|
2014-03-17 17:21:29 +00:00
|
|
|
struct mp_image *mp_image_pool_get(struct mp_image_pool *pool, int fmt,
|
|
|
|
int w, int h)
|
|
|
|
{
|
2015-01-22 16:37:40 +00:00
|
|
|
if (!pool)
|
|
|
|
return mp_image_alloc(fmt, w, h);
|
2014-03-17 17:21:29 +00:00
|
|
|
struct mp_image *new = mp_image_pool_get_no_alloc(pool, fmt, w, h);
|
2012-12-12 22:55:34 +00:00
|
|
|
if (!new) {
|
|
|
|
if (pool->num_images >= pool->max_count)
|
|
|
|
mp_image_pool_clear(pool);
|
2014-03-17 17:21:29 +00:00
|
|
|
if (pool->allocator) {
|
|
|
|
new = pool->allocator(pool->allocator_ctx, fmt, w, h);
|
|
|
|
} else {
|
|
|
|
new = mp_image_alloc(fmt, w, h);
|
|
|
|
}
|
|
|
|
if (!new)
|
|
|
|
return NULL;
|
2013-07-27 22:10:58 +00:00
|
|
|
struct image_flags *it = talloc_ptrtype(new, it);
|
|
|
|
*it = (struct image_flags) { .pool_alive = true };
|
|
|
|
new->priv = it;
|
2012-12-12 22:55:34 +00:00
|
|
|
MP_TARRAY_APPEND(pool, pool->images, pool->num_images, new);
|
2014-03-17 17:21:29 +00:00
|
|
|
new = mp_image_pool_get_no_alloc(pool, fmt, w, h);
|
2012-12-12 22:55:34 +00:00
|
|
|
}
|
2014-03-17 17:21:29 +00:00
|
|
|
return new;
|
2012-12-12 22:55:34 +00:00
|
|
|
}
|
|
|
|
|
|
|
|
// Like mp_image_new_copy(), but allocate the image out of the pool.
|
2015-01-22 16:37:40 +00:00
|
|
|
// If pool==NULL, a plain copy is made (for convenience).
|
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
|
|
|
// Returns NULL on OOM.
|
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)
|
|
|
|
{
|
|
|
|
struct mp_image *new = mp_image_pool_get(pool, img->imgfmt, img->w, img->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
|
|
|
if (new) {
|
|
|
|
mp_image_copy(new, img);
|
|
|
|
mp_image_copy_attributes(new, img);
|
|
|
|
}
|
2012-12-12 22:55:34 +00:00
|
|
|
return new;
|
|
|
|
}
|
|
|
|
|
|
|
|
// Like mp_image_make_writeable(), but if a copy has to be made, allocate it
|
|
|
|
// out of the pool.
|
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
|
|
|
// If pool==NULL, mp_image_make_writeable() is called (for convenience).
|
|
|
|
// Returns false on failure (see mp_image_make_writeable()).
|
|
|
|
bool mp_image_pool_make_writeable(struct mp_image_pool *pool,
|
2012-12-12 22:55:34 +00:00
|
|
|
struct mp_image *img)
|
|
|
|
{
|
|
|
|
if (mp_image_is_writeable(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
|
|
|
return true;
|
|
|
|
struct mp_image *new = mp_image_pool_new_copy(pool, img);
|
|
|
|
if (!new)
|
|
|
|
return false;
|
|
|
|
mp_image_steal_data(img, new);
|
2012-12-12 22:55:34 +00:00
|
|
|
assert(mp_image_is_writeable(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
|
|
|
return true;
|
2012-12-12 22:55:34 +00:00
|
|
|
}
|
2014-03-17 17:21:29 +00:00
|
|
|
|
video: replace our own refcounting with libavutil's
mpv had refcounted frames before libav*, so we were not using
libavutil's facilities. Change this and drop our own code.
Since AVFrames are not actually refcounted, and only the image data
they reference, the semantics change a bit. This affects mainly
mp_image_pool, which was operating on whole images instead of buffers.
While we could work on AVBufferRefs instead (and use AVBufferPool),
this doesn't work for use with hardware decoding, which doesn't
map cleanly to FFmpeg's reference counting. But it worked out. One
weird consequence is that we still need our custom image data
allocation function (for normal image data), because AVFrame's uses
multiple buffers.
There also seems to be a timing-dependent problem with vaapi (the
pool appears to be "leaking" surfaces). I don't know if this is a new
problem, or whether the code changes just happened to cause it more
often. Raising the number of reserved surfaces seemed to fix it, but
since it appears to be timing dependent, and I couldn't find anything
wrong with the code, I'm just going to assume it's not a new bug.
2015-07-05 21:56:00 +00:00
|
|
|
// Call cb(cb_data, fmt, w, h) to allocate an image. Note that the resulting
|
|
|
|
// image must use only 1 AVBufferRef. The returned image must also be owned
|
|
|
|
// exclusively by the image pool, otherwise mp_image_is_writeable() will not
|
|
|
|
// work due to FFmpeg restrictions.
|
2014-03-17 17:21:29 +00:00
|
|
|
void mp_image_pool_set_allocator(struct mp_image_pool *pool,
|
|
|
|
mp_image_allocator cb, void *cb_data)
|
|
|
|
{
|
|
|
|
pool->allocator = cb;
|
|
|
|
pool->allocator_ctx = cb_data;
|
|
|
|
}
|
|
|
|
|
|
|
|
// Put into LRU mode. (Likely better for hwaccel surfaces, but worse for memory.)
|
|
|
|
void mp_image_pool_set_lru(struct mp_image_pool *pool)
|
|
|
|
{
|
|
|
|
pool->use_lru = true;
|
|
|
|
}
|