2010-01-30 16:57:40 +00:00
|
|
|
/*
|
2015-04-13 07:36:54 +00:00
|
|
|
* This file is part of mpv.
|
2010-01-30 16:57:40 +00:00
|
|
|
*
|
2015-04-13 07:36:54 +00:00
|
|
|
* mpv is free software; you can redistribute it and/or modify
|
2010-01-30 16:57:40 +00:00
|
|
|
* 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.
|
|
|
|
*
|
2015-04-13 07:36:54 +00:00
|
|
|
* mpv is distributed in the hope that it will be useful,
|
2010-01-30 16:57:40 +00:00
|
|
|
* 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/>.
|
2010-01-30 16:57:40 +00:00
|
|
|
*/
|
2007-08-04 22:12:49 +00:00
|
|
|
|
|
|
|
#include "config.h"
|
|
|
|
|
|
|
|
#include <stdio.h>
|
|
|
|
#include <stdlib.h>
|
|
|
|
#include <string.h>
|
2014-06-17 20:44:13 +00:00
|
|
|
#include <limits.h>
|
2013-11-28 18:28:38 +00:00
|
|
|
#include <pthread.h>
|
2012-12-11 23:43:36 +00:00
|
|
|
#include <assert.h>
|
2007-08-04 22:12:49 +00:00
|
|
|
|
2012-12-31 00:58:25 +00:00
|
|
|
#include <libavutil/mem.h>
|
|
|
|
#include <libavutil/common.h>
|
2012-12-26 20:13:58 +00:00
|
|
|
#include <libavutil/bswap.h>
|
2015-12-19 19:04:31 +00:00
|
|
|
#include <libavutil/rational.h>
|
2013-06-28 19:14:43 +00:00
|
|
|
#include <libavcodec/avcodec.h>
|
2012-12-31 00:58:25 +00:00
|
|
|
|
2016-01-11 18:03:40 +00:00
|
|
|
#include "mpv_talloc.h"
|
2007-08-04 22:12:49 +00:00
|
|
|
|
2013-03-09 19:21:12 +00:00
|
|
|
#include "img_format.h"
|
|
|
|
#include "mp_image.h"
|
|
|
|
#include "sws_utils.h"
|
|
|
|
#include "fmt-conversion.h"
|
2015-09-25 16:58:17 +00:00
|
|
|
#include "gpu_memcpy.h"
|
2007-08-04 22:12:49 +00:00
|
|
|
|
2013-11-03 22:55:16 +00:00
|
|
|
#include "video/filter/vf.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
|
|
|
static bool mp_image_alloc_planes(struct mp_image *mpi)
|
mp_image: simplify image allocation
mp_image_alloc_planes() allocated images with minimal stride, even if
the resulting stride was unaligned. It was the responsibility of
vf_get_image() to set an image's width to something larger than
required to get an aligned stride, and then crop it. Always allocate
with aligned strides instead.
Get rid of IMGFMT_IF09 special handling. This format is not used
anymore. (IF09 has 4x4 chroma sub-sampling, and that is what it was
mainly used for - this is still supported.) Get rid of swapped chroma
plane allocation. This is not used anywhere, and VOs like vo_xv,
vo_direct3d and vo_sdl do their own swapping.
Always round chroma width/height up instead of down. Consider 4:2:0 and
an uneven image size. For luma, the size was left uneven, and the chroma
size was rounded down. This doesn't make sense, because chroma would be
missing for the bottom/right border.
Remove mp_image_new_empty() and mp_image_alloc_planes(), they were not
used anymore, except in draw_bmp.c. (It's still allowed to setup
mp_images manually, you just can't allocate image data with them
anymore - this is also done in draw_bmp.c.)
2012-12-19 11:04:32 +00:00
|
|
|
{
|
|
|
|
assert(!mpi->planes[0]);
|
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
|
|
|
assert(!mpi->bufs[0]);
|
2012-12-11 23:43:36 +00:00
|
|
|
|
2014-11-04 21:43:34 +00:00
|
|
|
if (!mp_image_params_valid(&mpi->params) || mpi->fmt.flags & MP_IMGFLAG_HWACCEL)
|
2014-06-17 20:44:13 +00:00
|
|
|
return false;
|
|
|
|
|
2013-08-06 18:09:31 +00:00
|
|
|
// Note: for non-mod-2 4:2:0 YUV frames, we have to allocate an additional
|
|
|
|
// top/right border. This is needed for correct handling of such
|
|
|
|
// images in filter and VO code (e.g. vo_vdpau or vo_opengl).
|
|
|
|
|
mp_image: simplify image allocation
mp_image_alloc_planes() allocated images with minimal stride, even if
the resulting stride was unaligned. It was the responsibility of
vf_get_image() to set an image's width to something larger than
required to get an aligned stride, and then crop it. Always allocate
with aligned strides instead.
Get rid of IMGFMT_IF09 special handling. This format is not used
anymore. (IF09 has 4x4 chroma sub-sampling, and that is what it was
mainly used for - this is still supported.) Get rid of swapped chroma
plane allocation. This is not used anywhere, and VOs like vo_xv,
vo_direct3d and vo_sdl do their own swapping.
Always round chroma width/height up instead of down. Consider 4:2:0 and
an uneven image size. For luma, the size was left uneven, and the chroma
size was rounded down. This doesn't make sense, because chroma would be
missing for the bottom/right border.
Remove mp_image_new_empty() and mp_image_alloc_planes(), they were not
used anymore, except in draw_bmp.c. (It's still allowed to setup
mp_images manually, you just can't allocate image data with them
anymore - this is also done in draw_bmp.c.)
2012-12-19 11:04:32 +00:00
|
|
|
size_t plane_size[MP_MAX_PLANES];
|
|
|
|
for (int n = 0; n < MP_MAX_PLANES; n++) {
|
2013-05-17 21:45:55 +00:00
|
|
|
int alloc_h = MP_ALIGN_UP(mpi->h, 32) >> mpi->fmt.ys[n];
|
2015-04-10 18:58:26 +00:00
|
|
|
int line_bytes = (mp_image_plane_w(mpi, n) * mpi->fmt.bpp[n] + 7) / 8;
|
mp_image: simplify image allocation
mp_image_alloc_planes() allocated images with minimal stride, even if
the resulting stride was unaligned. It was the responsibility of
vf_get_image() to set an image's width to something larger than
required to get an aligned stride, and then crop it. Always allocate
with aligned strides instead.
Get rid of IMGFMT_IF09 special handling. This format is not used
anymore. (IF09 has 4x4 chroma sub-sampling, and that is what it was
mainly used for - this is still supported.) Get rid of swapped chroma
plane allocation. This is not used anywhere, and VOs like vo_xv,
vo_direct3d and vo_sdl do their own swapping.
Always round chroma width/height up instead of down. Consider 4:2:0 and
an uneven image size. For luma, the size was left uneven, and the chroma
size was rounded down. This doesn't make sense, because chroma would be
missing for the bottom/right border.
Remove mp_image_new_empty() and mp_image_alloc_planes(), they were not
used anymore, except in draw_bmp.c. (It's still allowed to setup
mp_images manually, you just can't allocate image data with them
anymore - this is also done in draw_bmp.c.)
2012-12-19 11:04:32 +00:00
|
|
|
mpi->stride[n] = FFALIGN(line_bytes, SWS_MIN_BYTE_ALIGN);
|
2013-05-17 21:45:55 +00:00
|
|
|
plane_size[n] = mpi->stride[n] * alloc_h;
|
2007-08-04 22:12:49 +00:00
|
|
|
}
|
2013-12-01 19:45:44 +00:00
|
|
|
if (mpi->fmt.flags & MP_IMGFLAG_PAL)
|
mp_image: simplify image allocation
mp_image_alloc_planes() allocated images with minimal stride, even if
the resulting stride was unaligned. It was the responsibility of
vf_get_image() to set an image's width to something larger than
required to get an aligned stride, and then crop it. Always allocate
with aligned strides instead.
Get rid of IMGFMT_IF09 special handling. This format is not used
anymore. (IF09 has 4x4 chroma sub-sampling, and that is what it was
mainly used for - this is still supported.) Get rid of swapped chroma
plane allocation. This is not used anywhere, and VOs like vo_xv,
vo_direct3d and vo_sdl do their own swapping.
Always round chroma width/height up instead of down. Consider 4:2:0 and
an uneven image size. For luma, the size was left uneven, and the chroma
size was rounded down. This doesn't make sense, because chroma would be
missing for the bottom/right border.
Remove mp_image_new_empty() and mp_image_alloc_planes(), they were not
used anymore, except in draw_bmp.c. (It's still allowed to setup
mp_images manually, you just can't allocate image data with them
anymore - this is also done in draw_bmp.c.)
2012-12-19 11:04:32 +00:00
|
|
|
plane_size[1] = MP_PALETTE_SIZE;
|
2009-12-31 23:09:35 +00:00
|
|
|
|
mp_image: simplify image allocation
mp_image_alloc_planes() allocated images with minimal stride, even if
the resulting stride was unaligned. It was the responsibility of
vf_get_image() to set an image's width to something larger than
required to get an aligned stride, and then crop it. Always allocate
with aligned strides instead.
Get rid of IMGFMT_IF09 special handling. This format is not used
anymore. (IF09 has 4x4 chroma sub-sampling, and that is what it was
mainly used for - this is still supported.) Get rid of swapped chroma
plane allocation. This is not used anywhere, and VOs like vo_xv,
vo_direct3d and vo_sdl do their own swapping.
Always round chroma width/height up instead of down. Consider 4:2:0 and
an uneven image size. For luma, the size was left uneven, and the chroma
size was rounded down. This doesn't make sense, because chroma would be
missing for the bottom/right border.
Remove mp_image_new_empty() and mp_image_alloc_planes(), they were not
used anymore, except in draw_bmp.c. (It's still allowed to setup
mp_images manually, you just can't allocate image data with them
anymore - this is also done in draw_bmp.c.)
2012-12-19 11:04:32 +00:00
|
|
|
size_t sum = 0;
|
|
|
|
for (int n = 0; n < MP_MAX_PLANES; n++)
|
|
|
|
sum += plane_size[n];
|
|
|
|
|
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
|
|
|
// Note: mp_image_pool assumes this creates only 1 AVBufferRef.
|
|
|
|
mpi->bufs[0] = av_buffer_alloc(FFMAX(sum, 1));
|
|
|
|
if (!mpi->bufs[0])
|
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 false;
|
mp_image: simplify image allocation
mp_image_alloc_planes() allocated images with minimal stride, even if
the resulting stride was unaligned. It was the responsibility of
vf_get_image() to set an image's width to something larger than
required to get an aligned stride, and then crop it. Always allocate
with aligned strides instead.
Get rid of IMGFMT_IF09 special handling. This format is not used
anymore. (IF09 has 4x4 chroma sub-sampling, and that is what it was
mainly used for - this is still supported.) Get rid of swapped chroma
plane allocation. This is not used anywhere, and VOs like vo_xv,
vo_direct3d and vo_sdl do their own swapping.
Always round chroma width/height up instead of down. Consider 4:2:0 and
an uneven image size. For luma, the size was left uneven, and the chroma
size was rounded down. This doesn't make sense, because chroma would be
missing for the bottom/right border.
Remove mp_image_new_empty() and mp_image_alloc_planes(), they were not
used anymore, except in draw_bmp.c. (It's still allowed to setup
mp_images manually, you just can't allocate image data with them
anymore - this is also done in draw_bmp.c.)
2012-12-19 11:04:32 +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
|
|
|
uint8_t *data = mpi->bufs[0]->data;
|
mp_image: simplify image allocation
mp_image_alloc_planes() allocated images with minimal stride, even if
the resulting stride was unaligned. It was the responsibility of
vf_get_image() to set an image's width to something larger than
required to get an aligned stride, and then crop it. Always allocate
with aligned strides instead.
Get rid of IMGFMT_IF09 special handling. This format is not used
anymore. (IF09 has 4x4 chroma sub-sampling, and that is what it was
mainly used for - this is still supported.) Get rid of swapped chroma
plane allocation. This is not used anywhere, and VOs like vo_xv,
vo_direct3d and vo_sdl do their own swapping.
Always round chroma width/height up instead of down. Consider 4:2:0 and
an uneven image size. For luma, the size was left uneven, and the chroma
size was rounded down. This doesn't make sense, because chroma would be
missing for the bottom/right border.
Remove mp_image_new_empty() and mp_image_alloc_planes(), they were not
used anymore, except in draw_bmp.c. (It's still allowed to setup
mp_images manually, you just can't allocate image data with them
anymore - this is also done in draw_bmp.c.)
2012-12-19 11:04:32 +00:00
|
|
|
for (int n = 0; n < MP_MAX_PLANES; n++) {
|
|
|
|
mpi->planes[n] = plane_size[n] ? data : NULL;
|
|
|
|
data += plane_size[n];
|
|
|
|
}
|
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;
|
2007-08-04 22:12:49 +00:00
|
|
|
}
|
2010-04-15 05:39:36 +00:00
|
|
|
|
2014-03-17 17:19:57 +00:00
|
|
|
void mp_image_setfmt(struct mp_image *mpi, int out_fmt)
|
2012-12-31 00:58:25 +00:00
|
|
|
{
|
|
|
|
struct mp_imgfmt_desc fmt = mp_imgfmt_get_desc(out_fmt);
|
2014-04-20 19:27:45 +00:00
|
|
|
mpi->params.imgfmt = fmt.id;
|
2012-12-31 00:58:25 +00:00
|
|
|
mpi->fmt = fmt;
|
|
|
|
mpi->imgfmt = fmt.id;
|
|
|
|
mpi->num_planes = fmt.num_planes;
|
|
|
|
mp_image_set_size(mpi, mpi->w, mpi->h);
|
2010-04-15 05:39:36 +00:00
|
|
|
}
|
|
|
|
|
2013-10-12 23:16:30 +00:00
|
|
|
static void mp_image_destructor(void *ptr)
|
2011-10-06 18:46:01 +00:00
|
|
|
{
|
|
|
|
mp_image_t *mpi = ptr;
|
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
|
|
|
for (int p = 0; p < MP_MAX_PLANES; p++)
|
|
|
|
av_buffer_unref(&mpi->bufs[p]);
|
2011-10-06 18:46:01 +00:00
|
|
|
}
|
|
|
|
|
vo_opengl: change the way unaligned chroma size is handled
This deals with subsampled YUV video that has odd sizes, for example a
5x5 image with 4:2:0 subsampling.
It would be easy to handle if we actually passed separate texture
coordinates for each plane to the shader, but as of now the luma
coordinates are implicitly rescaled to chroma one. If luma and chroma
sizes don't match up, and this is not handled, you'd get a chroma shift
by 1 pixel.
The existing hack worked, but broke separable scaling. This was exposed
by a recent commit which switched to GL_NEAREST sampling for FBOs. The
rendering was accidentally scaled by 1 pixel, because the FBO size used
the original video size, while textures_sizes[0] was set to the padded
texture size (i.e. one pixel larger).
It could be fixed by setting the padded texture size only on the first
shader. But somehow that is annoying, so do something else. Don't pad
textures anymore, and rescale the chroma coordinates in the shader
instead.
Seems like this somehow doesn't work with rectangle textures (and
introduces a chroma shift), but since it's only used when doing VDA
hardware decoding, and the bug occurs only with unaligned video sizes, I
don't care much.
Fixes #1523.
2015-01-27 17:08:42 +00:00
|
|
|
int mp_chroma_div_up(int size, int shift)
|
2012-12-11 23:43:36 +00:00
|
|
|
{
|
mp_image: simplify image allocation
mp_image_alloc_planes() allocated images with minimal stride, even if
the resulting stride was unaligned. It was the responsibility of
vf_get_image() to set an image's width to something larger than
required to get an aligned stride, and then crop it. Always allocate
with aligned strides instead.
Get rid of IMGFMT_IF09 special handling. This format is not used
anymore. (IF09 has 4x4 chroma sub-sampling, and that is what it was
mainly used for - this is still supported.) Get rid of swapped chroma
plane allocation. This is not used anywhere, and VOs like vo_xv,
vo_direct3d and vo_sdl do their own swapping.
Always round chroma width/height up instead of down. Consider 4:2:0 and
an uneven image size. For luma, the size was left uneven, and the chroma
size was rounded down. This doesn't make sense, because chroma would be
missing for the bottom/right border.
Remove mp_image_new_empty() and mp_image_alloc_planes(), they were not
used anymore, except in draw_bmp.c. (It's still allowed to setup
mp_images manually, you just can't allocate image data with them
anymore - this is also done in draw_bmp.c.)
2012-12-19 11:04:32 +00:00
|
|
|
return (size + (1 << shift) - 1) >> shift;
|
2010-04-15 05:39:36 +00:00
|
|
|
}
|
|
|
|
|
2015-04-10 18:58:26 +00:00
|
|
|
// Return the storage width in pixels of the given plane.
|
|
|
|
int mp_image_plane_w(struct mp_image *mpi, int plane)
|
|
|
|
{
|
|
|
|
return mp_chroma_div_up(mpi->w, mpi->fmt.xs[plane]);
|
|
|
|
}
|
|
|
|
|
|
|
|
// Return the storage height in pixels of the given plane.
|
|
|
|
int mp_image_plane_h(struct mp_image *mpi, int plane)
|
|
|
|
{
|
|
|
|
return mp_chroma_div_up(mpi->h, mpi->fmt.ys[plane]);
|
|
|
|
}
|
|
|
|
|
2012-11-10 01:02:24 +00:00
|
|
|
// Caller has to make sure this doesn't exceed the allocated plane data/strides.
|
|
|
|
void mp_image_set_size(struct mp_image *mpi, int w, int h)
|
|
|
|
{
|
2014-06-17 20:44:13 +00:00
|
|
|
assert(w >= 0 && h >= 0);
|
2015-12-19 19:04:31 +00:00
|
|
|
mpi->w = mpi->params.w = w;
|
|
|
|
mpi->h = mpi->params.h = h;
|
|
|
|
mpi->params.p_w = mpi->params.p_h = 1;
|
2012-11-10 01:02:24 +00:00
|
|
|
}
|
|
|
|
|
2014-04-20 19:27:45 +00:00
|
|
|
void mp_image_set_params(struct mp_image *image,
|
|
|
|
const struct mp_image_params *params)
|
|
|
|
{
|
2014-05-01 12:24:20 +00:00
|
|
|
// possibly initialize other stuff
|
2014-04-20 19:27:45 +00:00
|
|
|
mp_image_setfmt(image, params->imgfmt);
|
|
|
|
mp_image_set_size(image, params->w, params->h);
|
2014-05-01 12:24:20 +00:00
|
|
|
image->params = *params;
|
2014-04-20 19:27:45 +00:00
|
|
|
}
|
|
|
|
|
2014-03-17 17:19:57 +00:00
|
|
|
struct mp_image *mp_image_alloc(int imgfmt, int w, int h)
|
2012-12-11 23:43:36 +00:00
|
|
|
{
|
mp_image: simplify image allocation
mp_image_alloc_planes() allocated images with minimal stride, even if
the resulting stride was unaligned. It was the responsibility of
vf_get_image() to set an image's width to something larger than
required to get an aligned stride, and then crop it. Always allocate
with aligned strides instead.
Get rid of IMGFMT_IF09 special handling. This format is not used
anymore. (IF09 has 4x4 chroma sub-sampling, and that is what it was
mainly used for - this is still supported.) Get rid of swapped chroma
plane allocation. This is not used anywhere, and VOs like vo_xv,
vo_direct3d and vo_sdl do their own swapping.
Always round chroma width/height up instead of down. Consider 4:2:0 and
an uneven image size. For luma, the size was left uneven, and the chroma
size was rounded down. This doesn't make sense, because chroma would be
missing for the bottom/right border.
Remove mp_image_new_empty() and mp_image_alloc_planes(), they were not
used anymore, except in draw_bmp.c. (It's still allowed to setup
mp_images manually, you just can't allocate image data with them
anymore - this is also done in draw_bmp.c.)
2012-12-19 11:04:32 +00:00
|
|
|
struct mp_image *mpi = talloc_zero(NULL, struct mp_image);
|
|
|
|
talloc_set_destructor(mpi, mp_image_destructor);
|
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
|
|
|
|
mp_image: simplify image allocation
mp_image_alloc_planes() allocated images with minimal stride, even if
the resulting stride was unaligned. It was the responsibility of
vf_get_image() to set an image's width to something larger than
required to get an aligned stride, and then crop it. Always allocate
with aligned strides instead.
Get rid of IMGFMT_IF09 special handling. This format is not used
anymore. (IF09 has 4x4 chroma sub-sampling, and that is what it was
mainly used for - this is still supported.) Get rid of swapped chroma
plane allocation. This is not used anywhere, and VOs like vo_xv,
vo_direct3d and vo_sdl do their own swapping.
Always round chroma width/height up instead of down. Consider 4:2:0 and
an uneven image size. For luma, the size was left uneven, and the chroma
size was rounded down. This doesn't make sense, because chroma would be
missing for the bottom/right border.
Remove mp_image_new_empty() and mp_image_alloc_planes(), they were not
used anymore, except in draw_bmp.c. (It's still allowed to setup
mp_images manually, you just can't allocate image data with them
anymore - this is also done in draw_bmp.c.)
2012-12-19 11:04:32 +00:00
|
|
|
mp_image_set_size(mpi, w, h);
|
2012-12-11 23:43:36 +00:00
|
|
|
mp_image_setfmt(mpi, imgfmt);
|
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 (!mp_image_alloc_planes(mpi)) {
|
|
|
|
talloc_free(mpi);
|
|
|
|
return NULL;
|
|
|
|
}
|
2012-12-11 23:43:36 +00:00
|
|
|
return mpi;
|
|
|
|
}
|
|
|
|
|
|
|
|
struct mp_image *mp_image_new_copy(struct mp_image *img)
|
|
|
|
{
|
|
|
|
struct mp_image *new = mp_image_alloc(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)
|
|
|
|
return NULL;
|
2012-12-11 23:43:36 +00:00
|
|
|
mp_image_copy(new, img);
|
|
|
|
mp_image_copy_attributes(new, img);
|
|
|
|
return new;
|
|
|
|
}
|
|
|
|
|
|
|
|
// Make dst take over the image data of src, and free src.
|
|
|
|
// This is basically a safe version of *dst = *src; free(src);
|
|
|
|
// Only works with ref-counted images, and can't change image size/format.
|
|
|
|
void mp_image_steal_data(struct mp_image *dst, struct mp_image *src)
|
|
|
|
{
|
|
|
|
assert(dst->imgfmt == src->imgfmt && dst->w == src->w && dst->h == src->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
|
|
|
assert(dst->bufs[0] && src->bufs[0]);
|
2012-12-11 23:43:36 +00:00
|
|
|
|
|
|
|
for (int p = 0; p < MP_MAX_PLANES; p++) {
|
|
|
|
dst->planes[p] = src->planes[p];
|
|
|
|
dst->stride[p] = src->stride[p];
|
|
|
|
}
|
|
|
|
mp_image_copy_attributes(dst, src);
|
|
|
|
|
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
|
|
|
for (int p = 0; p < MP_MAX_PLANES; p++) {
|
|
|
|
av_buffer_unref(&dst->bufs[p]);
|
|
|
|
dst->bufs[p] = src->bufs[p];
|
|
|
|
src->bufs[p] = NULL;
|
|
|
|
}
|
2012-12-11 23:43:36 +00:00
|
|
|
talloc_free(src);
|
|
|
|
}
|
|
|
|
|
|
|
|
// Return a new reference to img. The returned reference is owned by the caller,
|
|
|
|
// while img is left untouched.
|
|
|
|
struct mp_image *mp_image_new_ref(struct mp_image *img)
|
|
|
|
{
|
2015-01-24 21:56:02 +00:00
|
|
|
if (!img)
|
|
|
|
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
|
|
|
if (!img->bufs[0])
|
2012-12-11 23:43:36 +00:00
|
|
|
return mp_image_new_copy(img);
|
|
|
|
|
|
|
|
struct mp_image *new = talloc_ptrtype(NULL, new);
|
|
|
|
talloc_set_destructor(new, mp_image_destructor);
|
|
|
|
*new = *img;
|
|
|
|
|
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
|
|
|
bool fail = false;
|
|
|
|
for (int p = 0; p < MP_MAX_PLANES; p++) {
|
|
|
|
if (new->bufs[p]) {
|
|
|
|
new->bufs[p] = av_buffer_ref(new->bufs[p]);
|
|
|
|
if (!new->bufs[p])
|
|
|
|
fail = true;
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
|
|
|
if (!fail)
|
|
|
|
return new;
|
|
|
|
|
|
|
|
// Do this after _all_ bufs were changed; we don't want it to free bufs
|
|
|
|
// from the original image if this fails.
|
|
|
|
talloc_free(new);
|
|
|
|
return NULL;
|
2012-12-11 23:43:36 +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 free_args {
|
|
|
|
void *arg;
|
|
|
|
void (*free)(void *arg);
|
|
|
|
};
|
|
|
|
|
|
|
|
static void call_free(void *opaque, uint8_t *data)
|
|
|
|
{
|
|
|
|
struct free_args *args = opaque;
|
|
|
|
args->free(args->arg);
|
|
|
|
talloc_free(args);
|
|
|
|
}
|
|
|
|
|
|
|
|
// Create a new mp_image based on img, but don't set any buffers.
|
|
|
|
// Using this is only valid until the original img is unreferenced (including
|
|
|
|
// implicit unreferencing of the data by mp_image_make_writeable()), unless
|
|
|
|
// a new reference is set.
|
|
|
|
struct mp_image *mp_image_new_dummy_ref(struct mp_image *img)
|
2012-12-11 23:43:36 +00:00
|
|
|
{
|
|
|
|
struct mp_image *new = talloc_ptrtype(NULL, new);
|
|
|
|
talloc_set_destructor(new, mp_image_destructor);
|
|
|
|
*new = *img;
|
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
|
|
|
for (int p = 0; p < MP_MAX_PLANES; p++)
|
|
|
|
new->bufs[p] = NULL;
|
2012-12-11 23:43:36 +00:00
|
|
|
return new;
|
|
|
|
}
|
|
|
|
|
2015-03-19 22:59:30 +00:00
|
|
|
// Return a reference counted reference to img. If the reference count reaches
|
|
|
|
// 0, call free(free_arg). The data passed by img must not be free'd before
|
|
|
|
// that. The new reference will be writeable.
|
|
|
|
// On allocation failure, unref the frame and 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
|
|
|
// This is only used for hw decoding; this is important, because libav* expects
|
|
|
|
// all plane data to be accounted for by AVBufferRefs.
|
2015-03-19 22:59:30 +00:00
|
|
|
struct mp_image *mp_image_new_custom_ref(struct mp_image *img, void *free_arg,
|
|
|
|
void (*free)(void *arg))
|
|
|
|
{
|
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 *new = mp_image_new_dummy_ref(img);
|
|
|
|
|
|
|
|
struct free_args *args = talloc_ptrtype(NULL, args);
|
|
|
|
*args = (struct free_args){free_arg, free};
|
|
|
|
new->bufs[0] = av_buffer_create(NULL, 0, call_free, args,
|
|
|
|
AV_BUFFER_FLAG_READONLY);
|
|
|
|
if (new->bufs[0])
|
|
|
|
return new;
|
|
|
|
talloc_free(new);
|
|
|
|
return NULL;
|
2015-03-19 22:59:30 +00:00
|
|
|
}
|
|
|
|
|
2012-12-11 23:43:36 +00:00
|
|
|
bool mp_image_is_writeable(struct mp_image *img)
|
|
|
|
{
|
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
|
|
|
if (!img->bufs[0])
|
mp_image: simplify image allocation
mp_image_alloc_planes() allocated images with minimal stride, even if
the resulting stride was unaligned. It was the responsibility of
vf_get_image() to set an image's width to something larger than
required to get an aligned stride, and then crop it. Always allocate
with aligned strides instead.
Get rid of IMGFMT_IF09 special handling. This format is not used
anymore. (IF09 has 4x4 chroma sub-sampling, and that is what it was
mainly used for - this is still supported.) Get rid of swapped chroma
plane allocation. This is not used anywhere, and VOs like vo_xv,
vo_direct3d and vo_sdl do their own swapping.
Always round chroma width/height up instead of down. Consider 4:2:0 and
an uneven image size. For luma, the size was left uneven, and the chroma
size was rounded down. This doesn't make sense, because chroma would be
missing for the bottom/right border.
Remove mp_image_new_empty() and mp_image_alloc_planes(), they were not
used anymore, except in draw_bmp.c. (It's still allowed to setup
mp_images manually, you just can't allocate image data with them
anymore - this is also done in draw_bmp.c.)
2012-12-19 11:04:32 +00:00
|
|
|
return true; // not ref-counted => always considered writeable
|
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
|
|
|
for (int p = 0; p < MP_MAX_PLANES; p++) {
|
|
|
|
if (!img->bufs[p])
|
|
|
|
break;
|
|
|
|
if (!av_buffer_is_writable(img->bufs[p]))
|
|
|
|
return false;
|
|
|
|
}
|
|
|
|
return true;
|
2012-12-11 23:43:36 +00:00
|
|
|
}
|
|
|
|
|
|
|
|
// Make the image data referenced by img writeable. This allocates new data
|
|
|
|
// if the data wasn't already writeable, and img->planes[] and img->stride[]
|
|
|
|
// will be set to the copy.
|
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 success; if false is returned, the image could not be made writeable.
|
|
|
|
bool mp_image_make_writeable(struct mp_image *img)
|
2012-12-11 23:43:36 +00:00
|
|
|
{
|
|
|
|
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;
|
2012-12-11 23:43:36 +00:00
|
|
|
|
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
|
|
|
struct mp_image *new = mp_image_new_copy(img);
|
|
|
|
if (!new)
|
|
|
|
return false;
|
|
|
|
mp_image_steal_data(img, new);
|
2012-12-11 23:43:36 +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-11 23:43:36 +00:00
|
|
|
}
|
|
|
|
|
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
|
|
|
// Helper function: unrefs *p_img, and sets *p_img to a new ref of new_value.
|
|
|
|
// Only unrefs *p_img and sets it to NULL if out of memory.
|
2012-12-11 23:43:36 +00:00
|
|
|
void mp_image_setrefp(struct mp_image **p_img, struct mp_image *new_value)
|
|
|
|
{
|
|
|
|
if (*p_img != new_value) {
|
|
|
|
talloc_free(*p_img);
|
|
|
|
*p_img = new_value ? mp_image_new_ref(new_value) : NULL;
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
|
|
|
// Mere helper function (mp_image can be directly free'd with talloc_free)
|
|
|
|
void mp_image_unrefp(struct mp_image **p_img)
|
|
|
|
{
|
|
|
|
talloc_free(*p_img);
|
|
|
|
*p_img = NULL;
|
2010-04-15 05:39:36 +00:00
|
|
|
}
|
|
|
|
|
2015-09-25 16:58:17 +00:00
|
|
|
typedef void *(*memcpy_fn)(void *d, const void *s, size_t size);
|
|
|
|
|
|
|
|
static void memcpy_pic_cb(void *dst, const void *src, int bytesPerLine, int height,
|
|
|
|
int dstStride, int srcStride, memcpy_fn cpy)
|
|
|
|
{
|
|
|
|
if (bytesPerLine == dstStride && dstStride == srcStride && height) {
|
|
|
|
if (srcStride < 0) {
|
|
|
|
src = (uint8_t*)src + (height - 1) * srcStride;
|
|
|
|
dst = (uint8_t*)dst + (height - 1) * dstStride;
|
|
|
|
srcStride = -srcStride;
|
|
|
|
}
|
|
|
|
|
|
|
|
cpy(dst, src, srcStride * (height - 1) + bytesPerLine);
|
|
|
|
} else {
|
|
|
|
for (int i = 0; i < height; i++) {
|
|
|
|
cpy(dst, src, bytesPerLine);
|
|
|
|
src = (uint8_t*)src + srcStride;
|
|
|
|
dst = (uint8_t*)dst + dstStride;
|
|
|
|
}
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
|
|
|
static void mp_image_copy_cb(struct mp_image *dst, struct mp_image *src,
|
|
|
|
memcpy_fn cpy)
|
mp_image: simplify image allocation
mp_image_alloc_planes() allocated images with minimal stride, even if
the resulting stride was unaligned. It was the responsibility of
vf_get_image() to set an image's width to something larger than
required to get an aligned stride, and then crop it. Always allocate
with aligned strides instead.
Get rid of IMGFMT_IF09 special handling. This format is not used
anymore. (IF09 has 4x4 chroma sub-sampling, and that is what it was
mainly used for - this is still supported.) Get rid of swapped chroma
plane allocation. This is not used anywhere, and VOs like vo_xv,
vo_direct3d and vo_sdl do their own swapping.
Always round chroma width/height up instead of down. Consider 4:2:0 and
an uneven image size. For luma, the size was left uneven, and the chroma
size was rounded down. This doesn't make sense, because chroma would be
missing for the bottom/right border.
Remove mp_image_new_empty() and mp_image_alloc_planes(), they were not
used anymore, except in draw_bmp.c. (It's still allowed to setup
mp_images manually, you just can't allocate image data with them
anymore - this is also done in draw_bmp.c.)
2012-12-19 11:04:32 +00:00
|
|
|
{
|
|
|
|
assert(dst->imgfmt == src->imgfmt);
|
|
|
|
assert(dst->w == src->w && dst->h == src->h);
|
|
|
|
assert(mp_image_is_writeable(dst));
|
|
|
|
for (int n = 0; n < dst->num_planes; n++) {
|
2015-04-10 18:58:26 +00:00
|
|
|
int line_bytes = (mp_image_plane_w(dst, n) * dst->fmt.bpp[n] + 7) / 8;
|
|
|
|
int plane_h = mp_image_plane_h(dst, n);
|
2015-09-25 16:58:17 +00:00
|
|
|
memcpy_pic_cb(dst->planes[n], src->planes[n], line_bytes, plane_h,
|
|
|
|
dst->stride[n], src->stride[n], cpy);
|
mp_image: simplify image allocation
mp_image_alloc_planes() allocated images with minimal stride, even if
the resulting stride was unaligned. It was the responsibility of
vf_get_image() to set an image's width to something larger than
required to get an aligned stride, and then crop it. Always allocate
with aligned strides instead.
Get rid of IMGFMT_IF09 special handling. This format is not used
anymore. (IF09 has 4x4 chroma sub-sampling, and that is what it was
mainly used for - this is still supported.) Get rid of swapped chroma
plane allocation. This is not used anywhere, and VOs like vo_xv,
vo_direct3d and vo_sdl do their own swapping.
Always round chroma width/height up instead of down. Consider 4:2:0 and
an uneven image size. For luma, the size was left uneven, and the chroma
size was rounded down. This doesn't make sense, because chroma would be
missing for the bottom/right border.
Remove mp_image_new_empty() and mp_image_alloc_planes(), they were not
used anymore, except in draw_bmp.c. (It's still allowed to setup
mp_images manually, you just can't allocate image data with them
anymore - this is also done in draw_bmp.c.)
2012-12-19 11:04:32 +00:00
|
|
|
}
|
2014-09-21 07:33:51 +00:00
|
|
|
// Watch out for AV_PIX_FMT_FLAG_PSEUDOPAL retardation
|
|
|
|
if ((dst->fmt.flags & MP_IMGFLAG_PAL) && dst->planes[1] && src->planes[1])
|
2012-12-19 11:04:38 +00:00
|
|
|
memcpy(dst->planes[1], src->planes[1], MP_PALETTE_SIZE);
|
mp_image: simplify image allocation
mp_image_alloc_planes() allocated images with minimal stride, even if
the resulting stride was unaligned. It was the responsibility of
vf_get_image() to set an image's width to something larger than
required to get an aligned stride, and then crop it. Always allocate
with aligned strides instead.
Get rid of IMGFMT_IF09 special handling. This format is not used
anymore. (IF09 has 4x4 chroma sub-sampling, and that is what it was
mainly used for - this is still supported.) Get rid of swapped chroma
plane allocation. This is not used anywhere, and VOs like vo_xv,
vo_direct3d and vo_sdl do their own swapping.
Always round chroma width/height up instead of down. Consider 4:2:0 and
an uneven image size. For luma, the size was left uneven, and the chroma
size was rounded down. This doesn't make sense, because chroma would be
missing for the bottom/right border.
Remove mp_image_new_empty() and mp_image_alloc_planes(), they were not
used anymore, except in draw_bmp.c. (It's still allowed to setup
mp_images manually, you just can't allocate image data with them
anymore - this is also done in draw_bmp.c.)
2012-12-19 11:04:32 +00:00
|
|
|
}
|
|
|
|
|
2015-09-25 16:58:17 +00:00
|
|
|
void mp_image_copy(struct mp_image *dst, struct mp_image *src)
|
|
|
|
{
|
|
|
|
mp_image_copy_cb(dst, src, memcpy);
|
|
|
|
}
|
|
|
|
|
|
|
|
void mp_image_copy_gpu(struct mp_image *dst, struct mp_image *src)
|
|
|
|
{
|
|
|
|
#if HAVE_SSE4_INTRINSICS
|
|
|
|
if (av_get_cpu_flags() & AV_CPU_FLAG_SSE4) {
|
|
|
|
mp_image_copy_cb(dst, src, gpu_memcpy);
|
|
|
|
return;
|
|
|
|
}
|
|
|
|
#endif
|
|
|
|
mp_image_copy(dst, src);
|
|
|
|
}
|
|
|
|
|
|
|
|
// Helper, only for outputting some log info.
|
|
|
|
void mp_check_gpu_memcpy(struct mp_log *log, bool *once)
|
|
|
|
{
|
|
|
|
if (once) {
|
|
|
|
if (*once)
|
|
|
|
return;
|
|
|
|
*once = true;
|
|
|
|
}
|
|
|
|
|
|
|
|
bool have_sse = false;
|
|
|
|
#if HAVE_SSE4_INTRINSICS
|
|
|
|
have_sse = av_get_cpu_flags() & AV_CPU_FLAG_SSE4;
|
|
|
|
#endif
|
|
|
|
if (have_sse) {
|
|
|
|
mp_verbose(log, "Using SSE4 memcpy\n");
|
|
|
|
} else {
|
|
|
|
mp_warn(log, "Using fallback memcpy (slow)\n");
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
2012-12-19 11:04:57 +00:00
|
|
|
void mp_image_copy_attributes(struct mp_image *dst, struct mp_image *src)
|
|
|
|
{
|
|
|
|
dst->pict_type = src->pict_type;
|
|
|
|
dst->fields = src->fields;
|
|
|
|
dst->pts = src->pts;
|
2015-01-07 03:46:14 +00:00
|
|
|
dst->params.rotate = src->params.rotate;
|
2014-08-30 21:24:46 +00:00
|
|
|
dst->params.stereo_in = src->params.stereo_in;
|
|
|
|
dst->params.stereo_out = src->params.stereo_out;
|
2012-12-19 11:04:57 +00:00
|
|
|
if (dst->w == src->w && dst->h == src->h) {
|
2015-12-19 19:04:31 +00:00
|
|
|
dst->params.p_w = src->params.p_w;
|
|
|
|
dst->params.p_h = src->params.p_h;
|
2012-12-19 11:04:57 +00:00
|
|
|
}
|
Revert "Revert recent vo_opengl related commits"
Omitted a simple, but devastasting check. Fixed the relevant commits
now.
This reverts commit 8d24e9d9b8ad1b5d82139980eca148dc0f4a1eab.
diff --git a/video/out/gl_video.c b/video/out/gl_video.c
index 9c8a643..f1ea03e 100644
--- a/video/out/gl_video.c
+++ b/video/out/gl_video.c
@@ -1034,9 +1034,9 @@ static void compile_shaders(struct gl_video *p)
shader_def_opt(&header_conv, "USE_CONV_GAMMA", use_conv_gamma);
shader_def_opt(&header_conv, "USE_CONST_LUMA", use_const_luma);
shader_def_opt(&header_conv, "USE_LINEAR_LIGHT_BT1886",
- gamma_fun == MP_CSP_TRC_BT_1886);
+ use_linear_light && gamma_fun == MP_CSP_TRC_BT_1886);
shader_def_opt(&header_conv, "USE_LINEAR_LIGHT_SRGB",
- gamma_fun == MP_CSP_TRC_SRGB);
+ use_linear_light && gamma_fun == MP_CSP_TRC_SRGB);
shader_def_opt(&header_conv, "USE_SIGMOID", use_sigmoid);
if (p->opts.alpha_mode > 0 && p->has_alpha && p->plane_count > 3)
shader_def(&header_conv, "USE_ALPHA_PLANE", "3");
2015-02-28 19:15:12 +00:00
|
|
|
dst->params.primaries = src->params.primaries;
|
|
|
|
dst->params.gamma = src->params.gamma;
|
2015-04-10 19:06:18 +00:00
|
|
|
if ((dst->fmt.flags & MP_IMGFLAG_YUV) == (src->fmt.flags & MP_IMGFLAG_YUV)) {
|
2014-04-20 19:27:45 +00:00
|
|
|
dst->params.colorspace = src->params.colorspace;
|
|
|
|
dst->params.colorlevels = src->params.colorlevels;
|
|
|
|
dst->params.chroma_location = src->params.chroma_location;
|
2012-12-19 11:04:57 +00:00
|
|
|
}
|
2015-01-22 16:47:14 +00:00
|
|
|
mp_image_params_guess_csp(&dst->params); // ensure colorspace consistency
|
2013-12-01 19:45:44 +00:00
|
|
|
if ((dst->fmt.flags & MP_IMGFLAG_PAL) && (src->fmt.flags & MP_IMGFLAG_PAL)) {
|
2015-07-05 21:55:47 +00:00
|
|
|
if (dst->planes[1] && src->planes[1]) {
|
|
|
|
if (mp_image_make_writeable(dst))
|
|
|
|
memcpy(dst->planes[1], src->planes[1], MP_PALETTE_SIZE);
|
|
|
|
}
|
2012-12-19 11:04:57 +00:00
|
|
|
}
|
|
|
|
}
|
|
|
|
|
2012-12-25 21:29:49 +00:00
|
|
|
// Crop the given image to (x0, y0)-(x1, y1) (bottom/right border exclusive)
|
|
|
|
// x0/y0 must be naturally aligned.
|
|
|
|
void mp_image_crop(struct mp_image *img, int x0, int y0, int x1, int y1)
|
|
|
|
{
|
|
|
|
assert(x0 >= 0 && y0 >= 0);
|
|
|
|
assert(x0 <= x1 && y0 <= y1);
|
|
|
|
assert(x1 <= img->w && y1 <= img->h);
|
|
|
|
assert(!(x0 & (img->fmt.align_x - 1)));
|
|
|
|
assert(!(y0 & (img->fmt.align_y - 1)));
|
|
|
|
|
|
|
|
for (int p = 0; p < img->num_planes; ++p) {
|
|
|
|
img->planes[p] += (y0 >> img->fmt.ys[p]) * img->stride[p] +
|
|
|
|
(x0 >> img->fmt.xs[p]) * img->fmt.bpp[p] / 8;
|
|
|
|
}
|
|
|
|
mp_image_set_size(img, x1 - x0, y1 - y0);
|
|
|
|
}
|
|
|
|
|
|
|
|
void mp_image_crop_rc(struct mp_image *img, struct mp_rect rc)
|
|
|
|
{
|
|
|
|
mp_image_crop(img, rc.x0, rc.y0, rc.x1, rc.y1);
|
|
|
|
}
|
|
|
|
|
2012-12-26 20:13:58 +00:00
|
|
|
// Bottom/right border is allowed not to be aligned, but it might implicitly
|
|
|
|
// overwrite pixel data until the alignment (align_x/align_y) is reached.
|
|
|
|
void mp_image_clear(struct mp_image *img, int x0, int y0, int x1, int y1)
|
2012-12-19 11:04:57 +00:00
|
|
|
{
|
2012-12-26 20:13:58 +00:00
|
|
|
assert(x0 >= 0 && y0 >= 0);
|
|
|
|
assert(x0 <= x1 && y0 <= y1);
|
|
|
|
assert(x1 <= img->w && y1 <= img->h);
|
|
|
|
assert(!(x0 & (img->fmt.align_x - 1)));
|
|
|
|
assert(!(y0 & (img->fmt.align_y - 1)));
|
|
|
|
|
|
|
|
struct mp_image area = *img;
|
|
|
|
mp_image_crop(&area, x0, y0, x1, y1);
|
|
|
|
|
|
|
|
uint32_t plane_clear[MP_MAX_PLANES] = {0};
|
|
|
|
|
|
|
|
if (area.imgfmt == IMGFMT_YUYV) {
|
|
|
|
plane_clear[0] = av_le2ne16(0x8000);
|
|
|
|
} else if (area.imgfmt == IMGFMT_UYVY) {
|
|
|
|
plane_clear[0] = av_le2ne16(0x0080);
|
|
|
|
} else if (area.imgfmt == IMGFMT_NV12 || area.imgfmt == IMGFMT_NV21) {
|
|
|
|
plane_clear[1] = 0x8080;
|
2015-04-10 19:06:18 +00:00
|
|
|
} else if (area.fmt.flags & MP_IMGFLAG_YUV_P) {
|
2012-12-26 20:13:58 +00:00
|
|
|
uint16_t chroma_clear = (1 << area.fmt.plane_bits) / 2;
|
2015-04-10 19:06:18 +00:00
|
|
|
if (!(area.fmt.flags & MP_IMGFLAG_NE))
|
2012-12-26 20:13:58 +00:00
|
|
|
chroma_clear = av_bswap16(chroma_clear);
|
|
|
|
if (area.num_planes > 2)
|
|
|
|
plane_clear[1] = plane_clear[2] = chroma_clear;
|
2012-12-19 11:04:57 +00:00
|
|
|
}
|
2012-12-26 20:13:58 +00:00
|
|
|
|
|
|
|
for (int p = 0; p < area.num_planes; p++) {
|
|
|
|
int bpp = area.fmt.bpp[p];
|
2015-04-10 18:58:26 +00:00
|
|
|
int bytes = (mp_image_plane_w(&area, p) * bpp + 7) / 8;
|
2012-12-26 20:13:58 +00:00
|
|
|
if (bpp <= 8) {
|
|
|
|
memset_pic(area.planes[p], plane_clear[p], bytes,
|
2015-04-10 18:58:26 +00:00
|
|
|
mp_image_plane_h(&area, p), area.stride[p]);
|
2012-12-26 20:13:58 +00:00
|
|
|
} else {
|
|
|
|
memset16_pic(area.planes[p], plane_clear[p], (bytes + 1) / 2,
|
2015-04-10 18:58:26 +00:00
|
|
|
mp_image_plane_h(&area, p), area.stride[p]);
|
2012-12-26 20:13:58 +00:00
|
|
|
}
|
2012-12-19 11:04:57 +00:00
|
|
|
}
|
|
|
|
}
|
|
|
|
|
2013-03-01 10:28:59 +00:00
|
|
|
void mp_image_vflip(struct mp_image *img)
|
|
|
|
{
|
|
|
|
for (int p = 0; p < img->num_planes; p++) {
|
2015-04-10 18:58:26 +00:00
|
|
|
int plane_h = mp_image_plane_h(img, p);
|
|
|
|
img->planes[p] = img->planes[p] + img->stride[p] * (plane_h - 1);
|
2013-03-01 10:28:59 +00:00
|
|
|
img->stride[p] = -img->stride[p];
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
2015-12-19 19:04:31 +00:00
|
|
|
// Display size derived from image size and pixel aspect ratio.
|
|
|
|
void mp_image_params_get_dsize(const struct mp_image_params *p,
|
|
|
|
int *d_w, int *d_h)
|
|
|
|
{
|
|
|
|
*d_w = p->w;
|
|
|
|
*d_h = p->h;
|
|
|
|
if (p->p_w > p->p_h && p->p_h >= 1)
|
|
|
|
*d_w = MPCLAMP(*d_w * (int64_t)p->p_w / p->p_h, 0, INT_MAX);
|
|
|
|
if (p->p_h > p->p_w && p->p_w >= 1)
|
|
|
|
*d_h = MPCLAMP(*d_h * (int64_t)p->p_h / p->p_w, 0, INT_MAX);
|
|
|
|
}
|
|
|
|
|
|
|
|
void mp_image_params_set_dsize(struct mp_image_params *p, int d_w, int d_h)
|
|
|
|
{
|
|
|
|
AVRational ds = av_div_q((AVRational){d_w, d_h}, (AVRational){p->w, p->h});
|
|
|
|
p->p_w = ds.num;
|
|
|
|
p->p_h = ds.den;
|
|
|
|
}
|
|
|
|
|
2014-11-12 18:19:16 +00:00
|
|
|
char *mp_image_params_to_str_buf(char *b, size_t bs,
|
|
|
|
const struct mp_image_params *p)
|
|
|
|
{
|
|
|
|
if (p && p->imgfmt) {
|
|
|
|
snprintf(b, bs, "%dx%d", p->w, p->h);
|
2015-12-19 19:04:31 +00:00
|
|
|
if (p->p_w != p->p_h || !p->p_w)
|
|
|
|
mp_snprintf_cat(b, bs, " [%d:%d]", p->p_w, p->p_h);
|
2014-11-12 18:19:16 +00:00
|
|
|
mp_snprintf_cat(b, bs, " %s", mp_imgfmt_to_name(p->imgfmt));
|
2015-03-30 21:52:28 +00:00
|
|
|
mp_snprintf_cat(b, bs, " %s/%s",
|
|
|
|
m_opt_choice_str(mp_csp_names, p->colorspace),
|
|
|
|
m_opt_choice_str(mp_csp_levels_names, p->colorlevels));
|
|
|
|
mp_snprintf_cat(b, bs, " CL=%s",
|
|
|
|
m_opt_choice_str(mp_chroma_names, p->chroma_location));
|
2014-11-12 18:19:16 +00:00
|
|
|
if (p->rotate)
|
|
|
|
mp_snprintf_cat(b, bs, " rot=%d", p->rotate);
|
2014-11-12 18:30:34 +00:00
|
|
|
if (p->stereo_in > 0 || p->stereo_out > 0) {
|
|
|
|
mp_snprintf_cat(b, bs, " stereo=%s/%s",
|
|
|
|
MP_STEREO3D_NAME_DEF(p->stereo_in, "?"),
|
|
|
|
MP_STEREO3D_NAME_DEF(p->stereo_out, "?"));
|
|
|
|
}
|
2014-11-12 18:19:16 +00:00
|
|
|
} else {
|
|
|
|
snprintf(b, bs, "???");
|
|
|
|
}
|
|
|
|
return b;
|
|
|
|
}
|
|
|
|
|
2014-06-17 20:44:13 +00:00
|
|
|
// Return whether the image parameters are valid.
|
|
|
|
// Some non-essential fields are allowed to be unset (like colorspace flags).
|
|
|
|
bool mp_image_params_valid(const struct mp_image_params *p)
|
|
|
|
{
|
|
|
|
// av_image_check_size has similar checks and triggers around 16000*16000
|
|
|
|
// It's mostly needed to deal with the fact that offsets are sometimes
|
|
|
|
// ints. We also should (for now) do the same as FFmpeg, to be sure large
|
|
|
|
// images don't crash with libswscale or when wrapping with AVFrame and
|
|
|
|
// passing the result to filters.
|
2015-03-23 17:38:19 +00:00
|
|
|
if (p->w <= 0 || p->h <= 0 || (p->w + 128LL) * (p->h + 128LL) >= INT_MAX / 8)
|
2014-06-17 20:44:13 +00:00
|
|
|
return false;
|
|
|
|
|
2015-12-19 19:04:31 +00:00
|
|
|
if (p->p_w <= 0 || p->p_h <= 0)
|
2014-06-17 20:44:13 +00:00
|
|
|
return false;
|
|
|
|
|
|
|
|
if (p->rotate < 0 || p->rotate >= 360)
|
|
|
|
return false;
|
|
|
|
|
|
|
|
struct mp_imgfmt_desc desc = mp_imgfmt_get_desc(p->imgfmt);
|
|
|
|
if (!desc.id)
|
|
|
|
return false;
|
|
|
|
|
|
|
|
return true;
|
|
|
|
}
|
|
|
|
|
2014-06-17 21:30:16 +00:00
|
|
|
bool mp_image_params_equal(const struct mp_image_params *p1,
|
|
|
|
const struct mp_image_params *p2)
|
2012-10-27 16:01:51 +00:00
|
|
|
{
|
2013-07-18 11:17:56 +00:00
|
|
|
return p1->imgfmt == p2->imgfmt &&
|
|
|
|
p1->w == p2->w && p1->h == p2->h &&
|
2015-12-19 19:04:31 +00:00
|
|
|
p1->p_w == p2->p_w && p1->p_h == p2->p_h &&
|
2013-07-18 11:17:56 +00:00
|
|
|
p1->colorspace == p2->colorspace &&
|
2013-07-25 21:02:23 +00:00
|
|
|
p1->colorlevels == p2->colorlevels &&
|
2014-03-26 00:46:38 +00:00
|
|
|
p1->primaries == p2->primaries &&
|
Revert "Revert recent vo_opengl related commits"
Omitted a simple, but devastasting check. Fixed the relevant commits
now.
This reverts commit 8d24e9d9b8ad1b5d82139980eca148dc0f4a1eab.
diff --git a/video/out/gl_video.c b/video/out/gl_video.c
index 9c8a643..f1ea03e 100644
--- a/video/out/gl_video.c
+++ b/video/out/gl_video.c
@@ -1034,9 +1034,9 @@ static void compile_shaders(struct gl_video *p)
shader_def_opt(&header_conv, "USE_CONV_GAMMA", use_conv_gamma);
shader_def_opt(&header_conv, "USE_CONST_LUMA", use_const_luma);
shader_def_opt(&header_conv, "USE_LINEAR_LIGHT_BT1886",
- gamma_fun == MP_CSP_TRC_BT_1886);
+ use_linear_light && gamma_fun == MP_CSP_TRC_BT_1886);
shader_def_opt(&header_conv, "USE_LINEAR_LIGHT_SRGB",
- gamma_fun == MP_CSP_TRC_SRGB);
+ use_linear_light && gamma_fun == MP_CSP_TRC_SRGB);
shader_def_opt(&header_conv, "USE_SIGMOID", use_sigmoid);
if (p->opts.alpha_mode > 0 && p->has_alpha && p->plane_count > 3)
shader_def(&header_conv, "USE_ALPHA_PLANE", "3");
2015-02-28 19:15:12 +00:00
|
|
|
p1->gamma == p2->gamma &&
|
2014-04-20 19:28:09 +00:00
|
|
|
p1->chroma_location == p2->chroma_location &&
|
2014-08-30 21:24:46 +00:00
|
|
|
p1->rotate == p2->rotate &&
|
|
|
|
p1->stereo_in == p2->stereo_in &&
|
|
|
|
p1->stereo_out == p2->stereo_out;
|
2012-10-27 16:01:51 +00:00
|
|
|
}
|
|
|
|
|
2013-11-03 22:55:16 +00:00
|
|
|
// Set most image parameters, but not image format or size.
|
|
|
|
// Display size is used to set the PAR.
|
|
|
|
void mp_image_set_attributes(struct mp_image *image,
|
|
|
|
const struct mp_image_params *params)
|
|
|
|
{
|
|
|
|
struct mp_image_params nparams = *params;
|
|
|
|
nparams.imgfmt = image->imgfmt;
|
|
|
|
nparams.w = image->w;
|
|
|
|
nparams.h = image->h;
|
|
|
|
if (nparams.imgfmt != params->imgfmt)
|
|
|
|
mp_image_params_guess_csp(&nparams);
|
|
|
|
mp_image_set_params(image, &nparams);
|
|
|
|
}
|
|
|
|
|
2013-06-29 22:27:50 +00:00
|
|
|
// If details like params->colorspace/colorlevels are missing, guess them from
|
|
|
|
// the other settings. Also, even if they are set, make them consistent with
|
|
|
|
// the colorspace as implied by the pixel format.
|
|
|
|
void mp_image_params_guess_csp(struct mp_image_params *params)
|
|
|
|
{
|
|
|
|
struct mp_imgfmt_desc fmt = mp_imgfmt_get_desc(params->imgfmt);
|
|
|
|
if (!fmt.id)
|
|
|
|
return;
|
|
|
|
if (fmt.flags & MP_IMGFLAG_YUV) {
|
2013-07-14 22:50:01 +00:00
|
|
|
if (params->colorspace != MP_CSP_BT_601 &&
|
|
|
|
params->colorspace != MP_CSP_BT_709 &&
|
2014-03-25 17:45:08 +00:00
|
|
|
params->colorspace != MP_CSP_BT_2020_NC &&
|
2014-03-26 22:00:09 +00:00
|
|
|
params->colorspace != MP_CSP_BT_2020_C &&
|
2013-07-14 22:50:01 +00:00
|
|
|
params->colorspace != MP_CSP_SMPTE_240M &&
|
|
|
|
params->colorspace != MP_CSP_YCGCO)
|
|
|
|
{
|
|
|
|
// Makes no sense, so guess instead
|
|
|
|
// YCGCO should be separate, but libavcodec disagrees
|
|
|
|
params->colorspace = MP_CSP_AUTO;
|
|
|
|
}
|
2013-06-29 22:27:50 +00:00
|
|
|
if (params->colorspace == MP_CSP_AUTO)
|
|
|
|
params->colorspace = mp_csp_guess_colorspace(params->w, params->h);
|
|
|
|
if (params->colorlevels == MP_CSP_LEVELS_AUTO)
|
|
|
|
params->colorlevels = MP_CSP_LEVELS_TV;
|
2014-03-26 00:46:38 +00:00
|
|
|
if (params->primaries == MP_CSP_PRIM_AUTO) {
|
2014-04-01 22:40:36 +00:00
|
|
|
// Guess based on the colormatrix as a first priority
|
2014-03-26 22:00:09 +00:00
|
|
|
if (params->colorspace == MP_CSP_BT_2020_NC ||
|
|
|
|
params->colorspace == MP_CSP_BT_2020_C) {
|
2014-03-26 00:46:38 +00:00
|
|
|
params->primaries = MP_CSP_PRIM_BT_2020;
|
2014-04-01 22:40:36 +00:00
|
|
|
} else if (params->colorspace == MP_CSP_BT_709) {
|
2014-03-26 00:46:38 +00:00
|
|
|
params->primaries = MP_CSP_PRIM_BT_709;
|
2014-04-01 22:40:36 +00:00
|
|
|
} else {
|
|
|
|
// Ambiguous colormatrix for BT.601, guess based on res
|
|
|
|
params->primaries = mp_csp_guess_primaries(params->w, params->h);
|
2014-03-26 00:46:38 +00:00
|
|
|
}
|
|
|
|
}
|
Revert "Revert recent vo_opengl related commits"
Omitted a simple, but devastasting check. Fixed the relevant commits
now.
This reverts commit 8d24e9d9b8ad1b5d82139980eca148dc0f4a1eab.
diff --git a/video/out/gl_video.c b/video/out/gl_video.c
index 9c8a643..f1ea03e 100644
--- a/video/out/gl_video.c
+++ b/video/out/gl_video.c
@@ -1034,9 +1034,9 @@ static void compile_shaders(struct gl_video *p)
shader_def_opt(&header_conv, "USE_CONV_GAMMA", use_conv_gamma);
shader_def_opt(&header_conv, "USE_CONST_LUMA", use_const_luma);
shader_def_opt(&header_conv, "USE_LINEAR_LIGHT_BT1886",
- gamma_fun == MP_CSP_TRC_BT_1886);
+ use_linear_light && gamma_fun == MP_CSP_TRC_BT_1886);
shader_def_opt(&header_conv, "USE_LINEAR_LIGHT_SRGB",
- gamma_fun == MP_CSP_TRC_SRGB);
+ use_linear_light && gamma_fun == MP_CSP_TRC_SRGB);
shader_def_opt(&header_conv, "USE_SIGMOID", use_sigmoid);
if (p->opts.alpha_mode > 0 && p->has_alpha && p->plane_count > 3)
shader_def(&header_conv, "USE_ALPHA_PLANE", "3");
2015-02-28 19:15:12 +00:00
|
|
|
if (params->gamma == MP_CSP_TRC_AUTO)
|
|
|
|
params->gamma = MP_CSP_TRC_BT_1886;
|
2013-06-29 22:27:50 +00:00
|
|
|
} else if (fmt.flags & MP_IMGFLAG_RGB) {
|
|
|
|
params->colorspace = MP_CSP_RGB;
|
|
|
|
params->colorlevels = MP_CSP_LEVELS_PC;
|
2014-03-26 00:46:38 +00:00
|
|
|
|
|
|
|
// The majority of RGB content is either sRGB or (rarely) some other
|
|
|
|
// color space which we don't even handle, like AdobeRGB or
|
|
|
|
// ProPhotoRGB. The only reasonable thing we can do is assume it's
|
|
|
|
// sRGB and hope for the best, which should usually just work out fine.
|
|
|
|
// Note: sRGB primaries = BT.709 primaries
|
|
|
|
if (params->primaries == MP_CSP_PRIM_AUTO)
|
|
|
|
params->primaries = MP_CSP_PRIM_BT_709;
|
Revert "Revert recent vo_opengl related commits"
Omitted a simple, but devastasting check. Fixed the relevant commits
now.
This reverts commit 8d24e9d9b8ad1b5d82139980eca148dc0f4a1eab.
diff --git a/video/out/gl_video.c b/video/out/gl_video.c
index 9c8a643..f1ea03e 100644
--- a/video/out/gl_video.c
+++ b/video/out/gl_video.c
@@ -1034,9 +1034,9 @@ static void compile_shaders(struct gl_video *p)
shader_def_opt(&header_conv, "USE_CONV_GAMMA", use_conv_gamma);
shader_def_opt(&header_conv, "USE_CONST_LUMA", use_const_luma);
shader_def_opt(&header_conv, "USE_LINEAR_LIGHT_BT1886",
- gamma_fun == MP_CSP_TRC_BT_1886);
+ use_linear_light && gamma_fun == MP_CSP_TRC_BT_1886);
shader_def_opt(&header_conv, "USE_LINEAR_LIGHT_SRGB",
- gamma_fun == MP_CSP_TRC_SRGB);
+ use_linear_light && gamma_fun == MP_CSP_TRC_SRGB);
shader_def_opt(&header_conv, "USE_SIGMOID", use_sigmoid);
if (p->opts.alpha_mode > 0 && p->has_alpha && p->plane_count > 3)
shader_def(&header_conv, "USE_ALPHA_PLANE", "3");
2015-02-28 19:15:12 +00:00
|
|
|
if (params->gamma == MP_CSP_TRC_AUTO)
|
|
|
|
params->gamma = MP_CSP_TRC_SRGB;
|
2013-06-29 22:27:50 +00:00
|
|
|
} else if (fmt.flags & MP_IMGFLAG_XYZ) {
|
|
|
|
params->colorspace = MP_CSP_XYZ;
|
|
|
|
params->colorlevels = MP_CSP_LEVELS_PC;
|
2014-03-26 00:46:38 +00:00
|
|
|
|
|
|
|
// The default XYZ matrix converts it to BT.709 color space
|
|
|
|
// since that's the most likely scenario. Proper VOs should ignore
|
|
|
|
// this field as well as the matrix and treat XYZ input as absolute,
|
|
|
|
// but for VOs which use the matrix (and hence, consult this field)
|
2014-03-31 02:51:47 +00:00
|
|
|
// this is the correct parameter. This doubles as a reasonable output
|
|
|
|
// gamut for VOs which *do* use the specialized XYZ matrix but don't
|
|
|
|
// know any better output gamut other than whatever the source is
|
|
|
|
// tagged with.
|
2014-03-26 00:46:38 +00:00
|
|
|
if (params->primaries == MP_CSP_PRIM_AUTO)
|
|
|
|
params->primaries = MP_CSP_PRIM_BT_709;
|
Revert "Revert recent vo_opengl related commits"
Omitted a simple, but devastasting check. Fixed the relevant commits
now.
This reverts commit 8d24e9d9b8ad1b5d82139980eca148dc0f4a1eab.
diff --git a/video/out/gl_video.c b/video/out/gl_video.c
index 9c8a643..f1ea03e 100644
--- a/video/out/gl_video.c
+++ b/video/out/gl_video.c
@@ -1034,9 +1034,9 @@ static void compile_shaders(struct gl_video *p)
shader_def_opt(&header_conv, "USE_CONV_GAMMA", use_conv_gamma);
shader_def_opt(&header_conv, "USE_CONST_LUMA", use_const_luma);
shader_def_opt(&header_conv, "USE_LINEAR_LIGHT_BT1886",
- gamma_fun == MP_CSP_TRC_BT_1886);
+ use_linear_light && gamma_fun == MP_CSP_TRC_BT_1886);
shader_def_opt(&header_conv, "USE_LINEAR_LIGHT_SRGB",
- gamma_fun == MP_CSP_TRC_SRGB);
+ use_linear_light && gamma_fun == MP_CSP_TRC_SRGB);
shader_def_opt(&header_conv, "USE_SIGMOID", use_sigmoid);
if (p->opts.alpha_mode > 0 && p->has_alpha && p->plane_count > 3)
shader_def(&header_conv, "USE_ALPHA_PLANE", "3");
2015-02-28 19:15:12 +00:00
|
|
|
if (params->gamma == MP_CSP_TRC_AUTO)
|
|
|
|
params->gamma = MP_CSP_TRC_LINEAR;
|
2012-10-27 16:01:51 +00:00
|
|
|
} else {
|
2013-06-29 22:27:50 +00:00
|
|
|
// We have no clue.
|
|
|
|
params->colorspace = MP_CSP_AUTO;
|
|
|
|
params->colorlevels = MP_CSP_LEVELS_AUTO;
|
2014-03-26 00:46:38 +00:00
|
|
|
params->primaries = MP_CSP_PRIM_AUTO;
|
Revert "Revert recent vo_opengl related commits"
Omitted a simple, but devastasting check. Fixed the relevant commits
now.
This reverts commit 8d24e9d9b8ad1b5d82139980eca148dc0f4a1eab.
diff --git a/video/out/gl_video.c b/video/out/gl_video.c
index 9c8a643..f1ea03e 100644
--- a/video/out/gl_video.c
+++ b/video/out/gl_video.c
@@ -1034,9 +1034,9 @@ static void compile_shaders(struct gl_video *p)
shader_def_opt(&header_conv, "USE_CONV_GAMMA", use_conv_gamma);
shader_def_opt(&header_conv, "USE_CONST_LUMA", use_const_luma);
shader_def_opt(&header_conv, "USE_LINEAR_LIGHT_BT1886",
- gamma_fun == MP_CSP_TRC_BT_1886);
+ use_linear_light && gamma_fun == MP_CSP_TRC_BT_1886);
shader_def_opt(&header_conv, "USE_LINEAR_LIGHT_SRGB",
- gamma_fun == MP_CSP_TRC_SRGB);
+ use_linear_light && gamma_fun == MP_CSP_TRC_SRGB);
shader_def_opt(&header_conv, "USE_SIGMOID", use_sigmoid);
if (p->opts.alpha_mode > 0 && p->has_alpha && p->plane_count > 3)
shader_def(&header_conv, "USE_ALPHA_PLANE", "3");
2015-02-28 19:15:12 +00:00
|
|
|
params->gamma = MP_CSP_TRC_AUTO;
|
2012-10-27 16:01:51 +00:00
|
|
|
}
|
|
|
|
}
|
2013-03-09 19:21:12 +00:00
|
|
|
|
|
|
|
// Copy properties and data of the AVFrame into the mp_image, without taking
|
|
|
|
// care of memory management issues.
|
|
|
|
void mp_image_copy_fields_from_av_frame(struct mp_image *dst,
|
|
|
|
struct AVFrame *src)
|
|
|
|
{
|
|
|
|
mp_image_setfmt(dst, pixfmt2imgfmt(src->format));
|
|
|
|
mp_image_set_size(dst, src->width, src->height);
|
|
|
|
|
|
|
|
for (int i = 0; i < 4; i++) {
|
|
|
|
dst->planes[i] = src->data[i];
|
|
|
|
dst->stride[i] = src->linesize[i];
|
|
|
|
}
|
|
|
|
|
|
|
|
dst->pict_type = src->pict_type;
|
2013-03-15 13:21:42 +00:00
|
|
|
|
2015-04-23 20:06:14 +00:00
|
|
|
dst->fields = 0;
|
2013-03-09 19:21:12 +00:00
|
|
|
if (src->interlaced_frame)
|
|
|
|
dst->fields |= MP_IMGFIELD_INTERLACED;
|
|
|
|
if (src->top_field_first)
|
|
|
|
dst->fields |= MP_IMGFIELD_TOP_FIRST;
|
|
|
|
if (src->repeat_pict == 1)
|
|
|
|
dst->fields |= MP_IMGFIELD_REPEAT_FIRST;
|
|
|
|
}
|
2013-03-09 19:50:06 +00:00
|
|
|
|
2013-03-10 18:30:48 +00:00
|
|
|
// Copy properties and data of the mp_image into the AVFrame, without taking
|
|
|
|
// care of memory management issues.
|
|
|
|
void mp_image_copy_fields_to_av_frame(struct AVFrame *dst,
|
|
|
|
struct mp_image *src)
|
|
|
|
{
|
|
|
|
dst->format = imgfmt2pixfmt(src->imgfmt);
|
|
|
|
dst->width = src->w;
|
|
|
|
dst->height = src->h;
|
|
|
|
|
|
|
|
for (int i = 0; i < 4; i++) {
|
|
|
|
dst->data[i] = src->planes[i];
|
|
|
|
dst->linesize[i] = src->stride[i];
|
|
|
|
}
|
|
|
|
dst->extended_data = dst->data;
|
|
|
|
|
|
|
|
dst->pict_type = src->pict_type;
|
|
|
|
if (src->fields & MP_IMGFIELD_INTERLACED)
|
|
|
|
dst->interlaced_frame = 1;
|
|
|
|
if (src->fields & MP_IMGFIELD_TOP_FIRST)
|
|
|
|
dst->top_field_first = 1;
|
|
|
|
if (src->fields & MP_IMGFIELD_REPEAT_FIRST)
|
|
|
|
dst->repeat_pict = 1;
|
2013-07-27 19:17:31 +00:00
|
|
|
|
2014-04-20 19:27:45 +00:00
|
|
|
dst->colorspace = mp_csp_to_avcol_spc(src->params.colorspace);
|
|
|
|
dst->color_range = mp_csp_levels_to_avcol_range(src->params.colorlevels);
|
2013-03-10 18:30:48 +00:00
|
|
|
}
|
|
|
|
|
2013-03-09 19:50:06 +00:00
|
|
|
// Create a new mp_image reference to av_frame.
|
|
|
|
struct mp_image *mp_image_from_av_frame(struct AVFrame *av_frame)
|
|
|
|
{
|
|
|
|
struct mp_image t = {0};
|
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
|
|
|
mp_image_copy_fields_from_av_frame(&t, av_frame);
|
|
|
|
for (int p = 0; p < MP_MAX_PLANES; p++)
|
|
|
|
t.bufs[p] = av_frame->buf[p];
|
|
|
|
return mp_image_new_ref(&t);
|
2013-03-10 18:30:48 +00:00
|
|
|
}
|
|
|
|
|
|
|
|
// Convert the mp_image reference to a AVFrame reference.
|
|
|
|
// Warning: img is unreferenced (i.e. free'd). This is asymmetric to
|
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
|
|
|
// mp_image_from_av_frame(). It was done as some sort of optimization,
|
|
|
|
// but now these semantics are pointless.
|
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
|
|
|
// On failure, img is only unreffed.
|
2013-03-10 18:30:48 +00:00
|
|
|
struct AVFrame *mp_image_to_av_frame_and_unref(struct mp_image *img)
|
|
|
|
{
|
|
|
|
struct mp_image *new_ref = mp_image_new_ref(img); // ensure it's refcounted
|
|
|
|
talloc_free(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
|
|
|
if (!new_ref)
|
|
|
|
return NULL;
|
2013-03-10 18:30:48 +00:00
|
|
|
AVFrame *frame = av_frame_alloc();
|
2014-11-08 15:10:04 +00:00
|
|
|
if (!frame) {
|
|
|
|
talloc_free(new_ref);
|
|
|
|
return NULL;
|
|
|
|
}
|
2013-03-10 18:30:48 +00:00
|
|
|
mp_image_copy_fields_to_av_frame(frame, new_ref);
|
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
|
|
|
for (int p = 0; p < MP_MAX_PLANES; p++) {
|
|
|
|
frame->buf[p] = new_ref->bufs[p];
|
|
|
|
new_ref->bufs[p] = NULL;
|
2013-07-24 17:47:05 +00:00
|
|
|
}
|
|
|
|
talloc_free(new_ref);
|
2013-03-10 18:30:48 +00:00
|
|
|
return frame;
|
|
|
|
}
|
2015-03-19 23:21:23 +00:00
|
|
|
|
|
|
|
void memcpy_pic(void *dst, const void *src, int bytesPerLine, int height,
|
|
|
|
int dstStride, int srcStride)
|
|
|
|
{
|
2015-09-25 16:58:17 +00:00
|
|
|
memcpy_pic_cb(dst, src, bytesPerLine, height, dstStride, srcStride, memcpy);
|
2015-03-19 23:21:23 +00:00
|
|
|
}
|
|
|
|
|
|
|
|
void memset_pic(void *dst, int fill, int bytesPerLine, int height, int stride)
|
|
|
|
{
|
2015-03-19 23:34:15 +00:00
|
|
|
if (bytesPerLine == stride && height) {
|
|
|
|
memset(dst, fill, stride * (height - 1) + bytesPerLine);
|
2015-03-19 23:21:23 +00:00
|
|
|
} else {
|
|
|
|
for (int i = 0; i < height; i++) {
|
|
|
|
memset(dst, fill, bytesPerLine);
|
|
|
|
dst = (uint8_t *)dst + stride;
|
|
|
|
}
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
|
|
|
void memset16_pic(void *dst, int fill, int unitsPerLine, int height, int stride)
|
|
|
|
{
|
|
|
|
if (fill == 0) {
|
|
|
|
memset_pic(dst, 0, unitsPerLine * 2, height, stride);
|
|
|
|
} else {
|
|
|
|
for (int i = 0; i < height; i++) {
|
|
|
|
uint16_t *line = dst;
|
|
|
|
uint16_t *end = line + unitsPerLine;
|
|
|
|
while (line < end)
|
|
|
|
*line++ = fill;
|
|
|
|
dst = (uint8_t *)dst + stride;
|
|
|
|
}
|
|
|
|
}
|
|
|
|
}
|