2010-01-30 17:57:40 +01:00
|
|
|
/*
|
2015-04-13 09:36:54 +02:00
|
|
|
* This file is part of mpv.
|
2010-01-30 17:57:40 +01:00
|
|
|
*
|
2017-09-21 13:50:18 +02:00
|
|
|
* mpv is free software; you can redistribute it and/or
|
|
|
|
* modify it under the terms of the GNU Lesser General Public
|
|
|
|
* License as published by the Free Software Foundation; either
|
|
|
|
* version 2.1 of the License, or (at your option) any later version.
|
2010-01-30 17:57:40 +01:00
|
|
|
*
|
2015-04-13 09:36:54 +02:00
|
|
|
* mpv is distributed in the hope that it will be useful,
|
2010-01-30 17:57:40 +01:00
|
|
|
* but WITHOUT ANY WARRANTY; without even the implied warranty of
|
|
|
|
* MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
|
2017-09-21 13:50:18 +02:00
|
|
|
* GNU Lesser General Public License for more details.
|
2010-01-30 17:57:40 +01:00
|
|
|
*
|
2017-09-21 13:50:18 +02:00
|
|
|
* You should have received a copy of the GNU Lesser General Public
|
|
|
|
* License along with mpv. If not, see <http://www.gnu.org/licenses/>.
|
2010-01-30 17:57:40 +01:00
|
|
|
*/
|
|
|
|
|
2008-02-22 10:09:46 +01:00
|
|
|
#ifndef MPLAYER_MP_IMAGE_H
|
|
|
|
#define MPLAYER_MP_IMAGE_H
|
2002-01-16 01:14:59 +01:00
|
|
|
|
2012-12-12 00:43:36 +01:00
|
|
|
#include <stdbool.h>
|
2008-03-06 09:34:50 +01:00
|
|
|
#include <stdio.h>
|
|
|
|
#include <stdlib.h>
|
|
|
|
#include <string.h>
|
2012-10-27 17:59:16 +02:00
|
|
|
#include <inttypes.h>
|
2013-12-18 17:12:21 +01:00
|
|
|
#include "common/common.h"
|
2013-12-17 02:39:45 +01:00
|
|
|
#include "common/msg.h"
|
2012-11-09 01:06:43 +01:00
|
|
|
#include "csputils.h"
|
2012-12-31 01:58:25 +01:00
|
|
|
#include "video/img_format.h"
|
2008-03-06 09:34:50 +01:00
|
|
|
|
2003-08-18 16:49:06 +02:00
|
|
|
#define MP_IMGFIELD_TOP_FIRST 0x02
|
|
|
|
#define MP_IMGFIELD_REPEAT_FIRST 0x04
|
2003-12-22 18:26:19 +01:00
|
|
|
#define MP_IMGFIELD_INTERLACED 0x20
|
2003-08-03 14:09:58 +02:00
|
|
|
|
2017-08-21 14:56:07 +02:00
|
|
|
enum mp_spherical_type {
|
|
|
|
MP_SPHERICAL_AUTO = 0,
|
|
|
|
MP_SPHERICAL_NONE, // normal video
|
|
|
|
MP_SPHERICAL_UNKNOWN, // unknown projection
|
|
|
|
MP_SPHERICAL_EQUIRECTANGULAR, // (untiled)
|
|
|
|
};
|
|
|
|
|
|
|
|
extern const struct m_opt_choice_alternatives mp_spherical_names[];
|
|
|
|
|
|
|
|
struct mp_spherical_params {
|
|
|
|
enum mp_spherical_type type;
|
|
|
|
float ref_angles[3]; // yaw/pitch/roll, refer to AVSphericalMapping
|
|
|
|
};
|
|
|
|
|
video: add mp_image_params.hw_flags and add an example
It seems this will be useful for Rokchip DRM hwcontext integration.
DRM hwcontexts have additional internal structure which can be different
depending on the decoder, and which is not part of the generic hwcontext
API. Rockchip has 1 layer, which EGL interop happens to translate to a
RGB texture, while VAAPI (mapped as DRM hwcontext) will use multiple
layers. Both will use sw_format=nv12, and thus are indistinguishable on
the mp_image_params level. But this is needed to initialize the EGL
mapping and the vo_gpu video renderer correctly.
We hope that the layer count is enough to tell whether EGL will
translate the data to a RGB texture (vs. 2 texture resembling raw nv12
data). For that we introduce MP_IMAGE_HW_FLAG_OPAQUE.
This commit adds the flag, infrastructure to set it, and an "example"
for D3D11.
The D3D11 addition is quite useless at this point. But later we want to
get rid of d3d11_update_image_attribs() anyway, while we still need a
way to force d3d11vpp filter insertion, so maybe it has some
justification (who knows). In any case it makes testing this easier.
Obviously it also adds some basic support for triggering the opaque
format for decoding, which will use a driver-specific format, but which
is not supported in shaders. The opaque flag is not used to determine
whether d3d11vpp needs to be inserted, though.
2017-10-16 14:44:59 +02:00
|
|
|
enum mp_image_hw_flags {
|
|
|
|
MP_IMAGE_HW_FLAG_OPAQUE = 1, // an opaque hw format is used - the exact
|
|
|
|
// format is subject to hwctx internals
|
|
|
|
};
|
|
|
|
|
2013-08-24 19:37:34 +02:00
|
|
|
// Describes image parameters that usually stay constant.
|
|
|
|
// New fields can be added in the future. Code changing the parameters should
|
|
|
|
// usually copy the whole struct, so that fields added later will be preserved.
|
2013-06-08 01:35:44 +02:00
|
|
|
struct mp_image_params {
|
|
|
|
enum mp_imgfmt imgfmt; // pixel format
|
2016-07-15 11:54:44 +02:00
|
|
|
enum mp_imgfmt hw_subfmt; // underlying format for some hwaccel pixfmts
|
video: add mp_image_params.hw_flags and add an example
It seems this will be useful for Rokchip DRM hwcontext integration.
DRM hwcontexts have additional internal structure which can be different
depending on the decoder, and which is not part of the generic hwcontext
API. Rockchip has 1 layer, which EGL interop happens to translate to a
RGB texture, while VAAPI (mapped as DRM hwcontext) will use multiple
layers. Both will use sw_format=nv12, and thus are indistinguishable on
the mp_image_params level. But this is needed to initialize the EGL
mapping and the vo_gpu video renderer correctly.
We hope that the layer count is enough to tell whether EGL will
translate the data to a RGB texture (vs. 2 texture resembling raw nv12
data). For that we introduce MP_IMAGE_HW_FLAG_OPAQUE.
This commit adds the flag, infrastructure to set it, and an "example"
for D3D11.
The D3D11 addition is quite useless at this point. But later we want to
get rid of d3d11_update_image_attribs() anyway, while we still need a
way to force d3d11vpp filter insertion, so maybe it has some
justification (who knows). In any case it makes testing this easier.
Obviously it also adds some basic support for triggering the opaque
format for decoding, which will use a driver-specific format, but which
is not supported in shaders. The opaque flag is not used to determine
whether d3d11vpp needs to be inserted, though.
2017-10-16 14:44:59 +02:00
|
|
|
unsigned hw_flags; // bit mask of mp_image_hw_flags
|
2013-06-08 01:35:44 +02:00
|
|
|
int w, h; // image dimensions
|
2016-05-30 19:07:09 +02:00
|
|
|
int p_w, p_h; // define pixel aspect ratio (undefined: 0/0)
|
2016-06-29 09:16:13 +02:00
|
|
|
struct mp_colorspace color;
|
vo_opengl: handle chroma location
Use the video decoder chroma location flags and render chroma locations
other than centered. Until now, we've always used the intuitive and
obvious centered chroma location, but H.264 uses something else.
FFmpeg provides a small overview in libavcodec/avcodec.h:
-----------
/**
* X X 3 4 X X are luma samples,
* 1 2 1-6 are possible chroma positions
* X X 5 6 X 0 is undefined/unknown position
*/
enum AVChromaLocation{
AVCHROMA_LOC_UNSPECIFIED = 0,
AVCHROMA_LOC_LEFT = 1, ///< mpeg2/4, h264 default
AVCHROMA_LOC_CENTER = 2, ///< mpeg1, jpeg, h263
AVCHROMA_LOC_TOPLEFT = 3, ///< DV
AVCHROMA_LOC_TOP = 4,
AVCHROMA_LOC_BOTTOMLEFT = 5,
AVCHROMA_LOC_BOTTOM = 6,
AVCHROMA_LOC_NB , ///< Not part of ABI
};
-----------
The visual difference is literally minimal, but since videophiles
apparently consider this detail as quality mark of a video renderer,
support it anyway. We don't bother with chroma locations other than
centered and left, though.
Not sure about correctness, but it's probably ok.
2013-06-08 02:15:24 +02:00
|
|
|
enum mp_chroma_location chroma_location;
|
2014-04-20 21:28:09 +02:00
|
|
|
// The image should be rotated clockwise (0-359 degrees).
|
|
|
|
int rotate;
|
2014-08-30 23:24:46 +02:00
|
|
|
enum mp_stereo3d_mode stereo_in; // image is encoded with this mode
|
|
|
|
enum mp_stereo3d_mode stereo_out; // should be displayed with this mode
|
2017-08-21 14:56:07 +02:00
|
|
|
struct mp_spherical_params spherical;
|
2013-06-08 01:35:44 +02:00
|
|
|
};
|
|
|
|
|
2012-12-12 00:43:36 +01:00
|
|
|
/* Memory management:
|
|
|
|
* - mp_image is a light-weight reference to the actual image data (pixels).
|
|
|
|
* The actual image data is reference counted and can outlive mp_image
|
|
|
|
* allocations. mp_image references can be created with mp_image_new_ref()
|
|
|
|
* and free'd with talloc_free() (the helpers mp_image_setrefp() and
|
|
|
|
* mp_image_unrefp() can also be used). The actual image data is free'd when
|
|
|
|
* the last mp_image reference to it is free'd.
|
|
|
|
* - Each mp_image has a clear owner. The owner can do anything with it, such
|
|
|
|
* as changing mp_image fields. Instead of making ownership ambiguous by
|
|
|
|
* sharing a mp_image reference, new references should be created.
|
|
|
|
* - Write access to the actual image data is allowed only after calling
|
|
|
|
* mp_image_make_writeable(), or if mp_image_is_writeable() returns true.
|
|
|
|
* Conceptually, images can be changed by their owner only, and copy-on-write
|
|
|
|
* is used to ensure that other references do not see any changes to the
|
|
|
|
* image data. mp_image_make_writeable() will do that copy if required.
|
|
|
|
*/
|
2008-04-24 04:49:44 +02:00
|
|
|
typedef struct mp_image {
|
2015-04-10 21:06:18 +02:00
|
|
|
int w, h; // visible dimensions (redundant with params.w/h)
|
2012-12-31 01:58:25 +01:00
|
|
|
|
2014-04-20 21:27:45 +02:00
|
|
|
struct mp_image_params params;
|
|
|
|
|
|
|
|
// fields redundant to params.imgfmt, for convenience or compatibility
|
|
|
|
struct mp_imgfmt_desc fmt;
|
2013-06-08 01:35:44 +02:00
|
|
|
enum mp_imgfmt imgfmt;
|
2012-12-31 01:58:25 +01:00
|
|
|
int num_planes;
|
|
|
|
|
2012-10-27 17:59:16 +02:00
|
|
|
uint8_t *planes[MP_MAX_PLANES];
|
2005-02-24 17:52:18 +01:00
|
|
|
int stride[MP_MAX_PLANES];
|
2012-12-31 01:58:25 +01:00
|
|
|
|
2002-10-29 12:26:26 +01:00
|
|
|
int pict_type; // 0->unknown, 1->I, 2->P, 3->B
|
2003-08-18 16:49:06 +02:00
|
|
|
int fields;
|
2012-12-31 01:58:25 +01:00
|
|
|
|
video/filter: change filter API, use refcounting, remove filter DR
Change the entire filter API to use reference counted images instead
of vf_get_image().
Remove filter "direct rendering". This was useful for vf_expand and (in
rare cases) vf_sub: DR allowed these filters to pass a cropped image to
the filters before them. Then, on filtering, the image was "uncropped",
so that black bars could be added around the image without copying. This
means that in some cases, vf_expand will be slower (-vf gradfun,expand
for example).
Note that another form of DR used for in-place filters has been replaced
by simpler logic. Instead of trying to do DR, filters can check if the
image is writeable (with mp_image_is_writeable()), and do true in-place
if that's the case. This affects filters like vf_gradfun and vf_sub.
Everything has to support strides now. If something doesn't, making a
copy of the image data is required.
2012-11-05 14:25:04 +01:00
|
|
|
/* only inside filter chain */
|
|
|
|
double pts;
|
2016-01-25 20:47:13 +01:00
|
|
|
/* only after decoder */
|
2016-12-21 18:18:24 +01:00
|
|
|
double dts, pkt_duration;
|
2018-04-19 17:42:14 +02:00
|
|
|
/* container reported FPS; can be incorrect, or 0 if unknown */
|
|
|
|
double nominal_fps;
|
2012-12-12 23:55:41 +01:00
|
|
|
/* for private use */
|
2002-07-20 18:26:49 +02:00
|
|
|
void* priv;
|
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 23:56:00 +02:00
|
|
|
|
|
|
|
// Reference-counted data references.
|
|
|
|
// These do not necessarily map directly to planes[]. They can have
|
|
|
|
// different order or count. There shouldn't be more buffers than planes.
|
|
|
|
// If bufs[n] is NULL, bufs[n+1] must also be NULL.
|
|
|
|
// All mp_* functions manage this automatically; do not mess with it.
|
|
|
|
// (See also AVFrame.buf.)
|
|
|
|
struct AVBufferRef *bufs[MP_MAX_PLANES];
|
2016-04-15 15:07:02 +02:00
|
|
|
// Points to AVHWFramesContext* (same as AVFrame.hw_frames_ctx)
|
|
|
|
struct AVBufferRef *hwctx;
|
2017-07-25 23:06:27 +02:00
|
|
|
// Embedded ICC profile, if any
|
|
|
|
struct AVBufferRef *icc_profile;
|
2018-01-29 13:49:39 +01:00
|
|
|
// Closed captions packet, if any (only after decoder)
|
|
|
|
struct AVBufferRef *a53_cc;
|
2018-03-01 13:58:15 +01:00
|
|
|
// Other side data we don't care about.
|
|
|
|
struct mp_ff_side_data *ff_side_data;
|
|
|
|
int num_ff_side_data;
|
2002-01-16 01:14:59 +01:00
|
|
|
} mp_image_t;
|
|
|
|
|
2018-03-01 13:58:15 +01:00
|
|
|
struct mp_ff_side_data {
|
|
|
|
int type;
|
|
|
|
struct AVBufferRef *buf;
|
|
|
|
};
|
|
|
|
|
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 18:08:42 +01:00
|
|
|
int mp_chroma_div_up(int size, int shift);
|
|
|
|
|
2017-07-23 09:31:27 +02:00
|
|
|
int mp_image_get_alloc_size(int imgfmt, int w, int h, int stride_align);
|
|
|
|
struct mp_image *mp_image_from_buffer(int imgfmt, int w, int h, int stride_align,
|
|
|
|
uint8_t *buffer, int buffer_size,
|
|
|
|
void *free_opaque,
|
|
|
|
void (*free)(void *opaque, uint8_t *data));
|
|
|
|
|
2014-03-17 18:19:57 +01:00
|
|
|
struct mp_image *mp_image_alloc(int fmt, int w, int h);
|
2012-12-12 00:43:36 +01:00
|
|
|
void mp_image_copy(struct mp_image *dmpi, struct mp_image *mpi);
|
|
|
|
void mp_image_copy_attributes(struct mp_image *dmpi, struct mp_image *mpi);
|
|
|
|
struct mp_image *mp_image_new_copy(struct mp_image *img);
|
|
|
|
struct mp_image *mp_image_new_ref(struct mp_image *img);
|
|
|
|
bool mp_image_is_writeable(struct mp_image *img);
|
video: introduce failure path for image allocations
Until now, failure to allocate image data resulted in a crash (i.e.
abort() was called). This was intentional, because it's pretty silly to
degrade playback, and in almost all situations, the OOM will probably
kill you anyway. (And then there's the standard Linux overcommit
behavior, which also will kill you at some point.)
But I changed my opinion, so here we go. This change does not affect
_all_ memory allocations, just image data. Now in most failure cases,
the output will just be skipped. For video filters, this coincidentally
means that failure is treated as EOF (because the playback core assumes
EOF if nothing comes out of the video filter chain). In other
situations, output might be in some way degraded, like skipping frames,
not scaling OSD, and such.
Functions whose return values changed semantics:
mp_image_alloc
mp_image_new_copy
mp_image_new_ref
mp_image_make_writeable
mp_image_setrefp
mp_image_to_av_frame_and_unref
mp_image_from_av_frame
mp_image_new_external_ref
mp_image_new_custom_ref
mp_image_pool_make_writeable
mp_image_pool_get
mp_image_pool_new_copy
mp_vdpau_mixed_frame_create
vf_alloc_out_image
vf_make_out_image_writeable
glGetWindowScreenshot
2014-06-17 22:43:43 +02:00
|
|
|
bool mp_image_make_writeable(struct mp_image *img);
|
2012-12-12 00:43:36 +01:00
|
|
|
void mp_image_setrefp(struct mp_image **p_img, struct mp_image *new_value);
|
|
|
|
void mp_image_unrefp(struct mp_image **p_img);
|
|
|
|
|
2012-12-26 21:13:58 +01:00
|
|
|
void mp_image_clear(struct mp_image *mpi, int x0, int y0, int x1, int y1);
|
2012-12-25 22:29:49 +01:00
|
|
|
void mp_image_crop(struct mp_image *img, int x0, int y0, int x1, int y1);
|
|
|
|
void mp_image_crop_rc(struct mp_image *img, struct mp_rect rc);
|
2013-03-01 11:28:59 +01:00
|
|
|
void mp_image_vflip(struct mp_image *img);
|
2012-12-25 22:29:49 +01:00
|
|
|
|
2012-11-10 02:02:24 +01:00
|
|
|
void mp_image_set_size(struct mp_image *mpi, int w, int h);
|
2015-04-10 20:58:26 +02:00
|
|
|
int mp_image_plane_w(struct mp_image *mpi, int plane);
|
|
|
|
int mp_image_plane_h(struct mp_image *mpi, int plane);
|
2012-11-10 02:02:24 +01:00
|
|
|
|
2014-03-17 18:19:57 +01:00
|
|
|
void mp_image_setfmt(mp_image_t* mpi, int out_fmt);
|
2012-12-12 00:43:36 +01:00
|
|
|
void mp_image_steal_data(struct mp_image *dst, struct mp_image *src);
|
2017-02-20 13:15:50 +01:00
|
|
|
void mp_image_unref_data(struct mp_image *img);
|
2012-12-12 00:43:36 +01: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 23:56:00 +02:00
|
|
|
struct mp_image *mp_image_new_dummy_ref(struct mp_image *img);
|
2012-12-12 00:43:36 +01:00
|
|
|
struct mp_image *mp_image_new_custom_ref(struct mp_image *img, void *arg,
|
|
|
|
void (*free)(void *arg));
|
2002-04-21 00:24:19 +02:00
|
|
|
|
2013-06-30 00:27:50 +02:00
|
|
|
void mp_image_params_guess_csp(struct mp_image_params *params);
|
|
|
|
|
2014-11-12 19:19:16 +01:00
|
|
|
char *mp_image_params_to_str_buf(char *b, size_t bs,
|
|
|
|
const struct mp_image_params *p);
|
2017-08-21 14:56:07 +02:00
|
|
|
#define mp_image_params_to_str(p) mp_image_params_to_str_buf((char[256]){0}, 256, p)
|
2014-11-12 19:19:16 +01:00
|
|
|
|
2014-06-17 22:44:13 +02:00
|
|
|
bool mp_image_params_valid(const struct mp_image_params *p);
|
2014-06-17 23:30:16 +02:00
|
|
|
bool mp_image_params_equal(const struct mp_image_params *p1,
|
|
|
|
const struct mp_image_params *p2);
|
2013-07-18 13:17:56 +02:00
|
|
|
|
2015-12-19 20:04:31 +01:00
|
|
|
void mp_image_params_get_dsize(const struct mp_image_params *p,
|
|
|
|
int *d_w, int *d_h);
|
|
|
|
void mp_image_params_set_dsize(struct mp_image_params *p, int d_w, int d_h);
|
|
|
|
|
2013-07-18 13:42:57 +02:00
|
|
|
void mp_image_set_params(struct mp_image *image,
|
|
|
|
const struct mp_image_params *params);
|
|
|
|
|
2013-11-03 23:55:16 +01:00
|
|
|
void mp_image_set_attributes(struct mp_image *image,
|
|
|
|
const struct mp_image_params *params);
|
|
|
|
|
2013-03-09 20:21:12 +01:00
|
|
|
struct AVFrame;
|
2013-03-09 20:50:06 +01:00
|
|
|
struct mp_image *mp_image_from_av_frame(struct AVFrame *av_frame);
|
2016-04-15 15:33:53 +02:00
|
|
|
struct AVFrame *mp_image_to_av_frame(struct mp_image *img);
|
2013-03-10 19:30:48 +01:00
|
|
|
struct AVFrame *mp_image_to_av_frame_and_unref(struct mp_image *img);
|
2013-03-09 20:21:12 +01:00
|
|
|
|
2015-03-20 00:21:23 +01:00
|
|
|
void memcpy_pic(void *dst, const void *src, int bytesPerLine, int height,
|
|
|
|
int dstStride, int srcStride);
|
|
|
|
void memset_pic(void *dst, int fill, int bytesPerLine, int height, int stride);
|
|
|
|
void memset16_pic(void *dst, int fill, int unitsPerLine, int height, int stride);
|
|
|
|
|
2008-02-22 10:09:46 +01:00
|
|
|
#endif /* MPLAYER_MP_IMAGE_H */
|