2001-02-24 21:28:24 +01:00
|
|
|
/*
|
2009-02-08 04:27:30 +01:00
|
|
|
* Copyright (C) Aaron Holtzman - Aug 1999
|
|
|
|
* Strongly modified, most parts rewritten: A'rpi/ESP-team - 2000-2001
|
|
|
|
* (C) MPlayer developers
|
2001-02-24 21:28:24 +01:00
|
|
|
*
|
2009-02-08 04:27:30 +01:00
|
|
|
* This file is part of MPlayer.
|
2001-02-24 21:28:24 +01:00
|
|
|
*
|
2009-02-08 04:27:30 +01:00
|
|
|
* MPlayer is free software; you can redistribute it and/or modify
|
|
|
|
* it under the terms of the GNU General Public License as published by
|
|
|
|
* the Free Software Foundation; either version 2 of the License, or
|
|
|
|
* (at your option) any later version.
|
|
|
|
*
|
|
|
|
* MPlayer is distributed in the hope that it will be useful,
|
|
|
|
* but WITHOUT ANY WARRANTY; without even the implied warranty of
|
|
|
|
* MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
|
|
|
|
* GNU General Public License for more details.
|
|
|
|
*
|
|
|
|
* You should have received a copy of the GNU General Public License along
|
|
|
|
* with MPlayer; if not, write to the Free Software Foundation, Inc.,
|
|
|
|
* 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301 USA.
|
2001-02-24 21:28:24 +01:00
|
|
|
*/
|
2009-02-08 04:27:30 +01:00
|
|
|
|
2008-02-22 10:09:46 +01:00
|
|
|
#ifndef MPLAYER_VIDEO_OUT_H
|
|
|
|
#define MPLAYER_VIDEO_OUT_H
|
2001-02-24 21:28:24 +01:00
|
|
|
|
|
|
|
#include <inttypes.h>
|
2009-09-17 16:52:09 +02:00
|
|
|
#include <stdbool.h>
|
2001-02-24 21:28:24 +01:00
|
|
|
|
2012-11-09 01:06:43 +01:00
|
|
|
#include "video/img_format.h"
|
2013-12-17 02:39:45 +01:00
|
|
|
#include "common/common.h"
|
2013-12-17 02:02:25 +01:00
|
|
|
#include "options/options.h"
|
2009-10-14 03:12:10 +02:00
|
|
|
|
2014-11-02 20:26:51 +01:00
|
|
|
// VO needs to redraw
|
2001-03-03 22:46:39 +01:00
|
|
|
#define VO_EVENT_EXPOSE 1
|
2014-11-02 20:26:51 +01:00
|
|
|
// VO needs to update state to a new window size
|
2001-03-03 22:46:39 +01:00
|
|
|
#define VO_EVENT_RESIZE 2
|
2014-11-02 20:26:51 +01:00
|
|
|
// The ICC profile needs to be reloaded
|
2014-02-25 00:04:30 +01:00
|
|
|
#define VO_EVENT_ICC_PROFILE_PATH_CHANGED 4
|
2014-11-02 20:48:45 +01:00
|
|
|
// Some other window state changed
|
|
|
|
#define VO_EVENT_WIN_STATE 8
|
2001-03-03 22:46:39 +01:00
|
|
|
|
2014-11-02 20:26:51 +01:00
|
|
|
// Set of events the player core may be interested in.
|
2014-11-02 20:48:45 +01:00
|
|
|
#define VO_EVENTS_USER (VO_EVENT_RESIZE | VO_EVENT_WIN_STATE)
|
2014-11-02 20:26:51 +01:00
|
|
|
|
2011-08-22 22:24:07 +02:00
|
|
|
enum mp_voctrl {
|
|
|
|
/* signal a device reset seek */
|
2012-11-04 16:24:18 +01:00
|
|
|
VOCTRL_RESET = 1,
|
2013-05-15 18:17:18 +02:00
|
|
|
/* Handle input and redraw events, called by vo_check_events() */
|
|
|
|
VOCTRL_CHECK_EVENTS,
|
2011-08-22 22:24:07 +02:00
|
|
|
/* used to switch to fullscreen */
|
|
|
|
VOCTRL_FULLSCREEN,
|
|
|
|
/* signal a device pause */
|
|
|
|
VOCTRL_PAUSE,
|
|
|
|
/* start/resume playback */
|
|
|
|
VOCTRL_RESUME,
|
2012-11-06 15:27:44 +01:00
|
|
|
|
2011-08-22 22:24:07 +02:00
|
|
|
VOCTRL_GET_PANSCAN,
|
|
|
|
VOCTRL_SET_PANSCAN,
|
2013-06-08 01:35:44 +02:00
|
|
|
VOCTRL_SET_EQUALIZER, // struct voctrl_set_equalizer_args*
|
|
|
|
VOCTRL_GET_EQUALIZER, // struct voctrl_get_equalizer_args*
|
2011-08-22 22:24:07 +02:00
|
|
|
|
video: add vaapi decode and output support
This is based on the MPlayer VA API patches. To be exact it's based on
a very stripped down version of commit f1ad459a263f8537f6c from
git://gitorious.org/vaapi/mplayer.git.
This doesn't contain useless things like benchmarking hacks and the
demo code for GLX interop. Also, unlike in the original patch, decoding
and video output are split into separate source files (the separation
between decoding and display also makes pixel format hacks unnecessary).
On the other hand, some features not present in the original patch were
added, like screenshot support.
VA API is rather bad for actual video output. Dealing with older libva
versions or the completely broken vdpau backend doesn't help. OSD is
low quality and should be rather slow. In some cases, only either OSD
or subtitles can be shown at the same time (because OSD is drawn first,
OSD is prefered).
Also, libva can't decide whether it accepts straight or premultiplied
alpha for OSD sub-pictures: the vdpau backend seems to assume
premultiplied, while a native vaapi driver uses straight. So I picked
straight alpha. It doesn't matter much, because the blending code for
straight alpha I added to img_convert.c is probably buggy, and ASS
subtitles might be blended incorrectly.
Really good video output with VA API would probably use OpenGL and the
GL interop features, but at this point you might just use vo_opengl.
(Patches for making HW decoding with vo_opengl have a chance of being
accepted.)
Despite these issues, decoding seems to work ok. I still got tearing
on the Intel system I tested (Intel(R) Core(TM) i3-2350M). It was also
tested with the vdpau vaapi wrapper on a nvidia system; however this
was rather broken. (Fortunately, there is no reason to use mpv's VAAPI
support over native VDPAU.)
2013-08-09 14:01:30 +02:00
|
|
|
/* for hardware decoding */
|
2014-08-11 23:08:35 +02:00
|
|
|
VOCTRL_GET_HWDEC_INFO, // struct mp_hwdec_info**
|
video: move display and timing to a separate thread
The VO is run inside its own thread. It also does most of video timing.
The playloop hands the image data and a realtime timestamp to the VO,
and the VO does the rest.
In particular, this allows the playloop to do other things, instead of
blocking for video redraw. But if anything accesses the VO during video
timing, it will block.
This also fixes vo_sdl.c event handling; but that is only a side-effect,
since reimplementing the broken way would require more effort.
Also drop --softsleep. In theory, this option helps if the kernel's
sleeping mechanism is too inaccurate for video timing. In practice, I
haven't ever encountered a situation where it helps, and it just burns
CPU cycles. On the other hand it's probably actively harmful, because
it prevents the libavcodec decoder threads from doing real work.
Side note:
Originally, I intended that multiple frames can be queued to the VO. But
this is not done, due to problems with OSD and other certain features.
OSD in particular is simply designed in a way that it can be neither
timed nor copied, so you do have to render it into the video frame
before you can draw the next frame. (Subtitles have no such restriction.
sd_lavc was even updated to fix this.) It seems the right solution to
queuing multiple VO frames is rendering on VO-backed framebuffers, like
vo_vdpau.c does. This requires VO driver support, and is out of scope
of this commit.
As consequence, the VO has a queue size of 1. The existing video queue
is just needed to compute frame duration, and will be moved out in the
next commit.
2014-08-12 23:02:08 +02:00
|
|
|
VOCTRL_LOAD_HWDEC_API, // private to vo_opengl
|
2012-11-04 17:17:11 +01:00
|
|
|
|
2014-06-15 20:46:57 +02:00
|
|
|
// Redraw the image previously passed to draw_image() (basically, repeat
|
|
|
|
// the previous draw_image call). If this is handled, the OSD should also
|
|
|
|
// be updated and redrawn.
|
2011-12-05 04:24:18 +01:00
|
|
|
VOCTRL_REDRAW_FRAME,
|
2011-08-22 22:24:07 +02:00
|
|
|
|
|
|
|
VOCTRL_ONTOP,
|
|
|
|
VOCTRL_BORDER,
|
2013-06-15 19:04:20 +02:00
|
|
|
VOCTRL_UPDATE_WINDOW_TITLE, // char*
|
2011-08-22 22:24:07 +02:00
|
|
|
|
2013-06-08 01:35:44 +02:00
|
|
|
VOCTRL_SET_CURSOR_VISIBILITY, // bool*
|
2013-05-16 23:17:46 +02:00
|
|
|
|
2013-06-14 00:03:32 +02:00
|
|
|
VOCTRL_KILL_SCREENSAVER,
|
|
|
|
VOCTRL_RESTORE_SCREENSAVER,
|
|
|
|
|
2011-08-22 22:24:07 +02:00
|
|
|
VOCTRL_SET_DEINTERLACE,
|
|
|
|
VOCTRL_GET_DEINTERLACE,
|
|
|
|
|
2014-09-04 22:53:50 +02:00
|
|
|
// Return or set window size (not-fullscreen mode only - if fullscreened,
|
|
|
|
// these must access the not-fullscreened window size only).
|
|
|
|
VOCTRL_GET_UNFS_WINDOW_SIZE, // int[2] (w/h)
|
|
|
|
VOCTRL_SET_UNFS_WINDOW_SIZE, // int[2] (w/h)
|
2011-08-22 22:24:07 +02:00
|
|
|
|
2014-11-02 20:48:45 +01:00
|
|
|
VOCTRL_GET_WIN_STATE, // int* (VO_WIN_STATE_* flags)
|
|
|
|
|
2014-11-06 00:58:24 +01:00
|
|
|
// char *** (NULL terminated array compatible with CONF_TYPE_STRING_LIST)
|
|
|
|
// names for displays the window is on
|
|
|
|
VOCTRL_GET_DISPLAY_NAMES,
|
|
|
|
|
2014-03-29 00:25:08 +01:00
|
|
|
// The VO is supposed to set "known" fields, and leave the others
|
|
|
|
// untouched or set to 0.
|
|
|
|
// imgfmt/w/h/d_w/d_h can be omitted for convenience.
|
|
|
|
VOCTRL_GET_COLORSPACE, // struct mp_image_params*
|
2011-10-06 20:46:01 +02:00
|
|
|
|
2013-06-08 01:35:44 +02:00
|
|
|
VOCTRL_SCREENSHOT, // struct voctrl_screenshot_args*
|
2012-08-01 01:06:59 +02:00
|
|
|
|
2013-06-08 01:35:44 +02:00
|
|
|
VOCTRL_SET_COMMAND_LINE, // char**
|
2014-02-25 00:04:30 +01:00
|
|
|
|
|
|
|
VOCTRL_GET_ICC_PROFILE_PATH, // char**
|
video: add VO framedropping mode
This mostly uses the same idea as with vo_vdpau.c, but much simplified.
On X11, it tries to get the display framerate with XF86VM, and limits
the frequency of new video frames against it. Note that this is an old
extension, and is confirmed not to work correctly with multi-monitor
setups. But we're using it because it was already around (it is also
used by vo_vdpau).
This attempts to predict the next vsync event by using the time of the
last frame and the display FPS. Even if that goes completely wrong,
the results are still relatively good.
On other systems, or if the X11 code doesn't return a display FPS, a
framerate of 1000 is assumed. This is infinite for all practical
purposes, and means that only frames which are definitely too late are
dropped. This probably has worse results, but is still useful.
"--framedrop=yes" is basically replaced with "--framedrop=decoder". The
old framedropping mode is kept around, and should perhaps be improved.
Dropping on the decoder level is still useful if decoding itself is too
slow.
2014-08-15 23:33:33 +02:00
|
|
|
VOCTRL_GET_DISPLAY_FPS, // double*
|
2014-08-18 23:01:13 +02:00
|
|
|
VOCTRL_GET_RECENT_FLIP_TIME, // int64_t* (using mp_time_us())
|
2014-04-29 15:18:19 +02:00
|
|
|
|
|
|
|
VOCTRL_GET_PREF_DEINT, // int*
|
2011-08-22 22:24:07 +02:00
|
|
|
};
|
|
|
|
|
|
|
|
// VOCTRL_SET_EQUALIZER
|
2008-04-02 17:51:38 +02:00
|
|
|
struct voctrl_set_equalizer_args {
|
|
|
|
const char *name;
|
|
|
|
int value;
|
|
|
|
};
|
2011-08-22 22:24:07 +02:00
|
|
|
|
|
|
|
// VOCTRL_GET_EQUALIZER
|
2008-04-02 17:51:38 +02:00
|
|
|
struct voctrl_get_equalizer_args {
|
|
|
|
const char *name;
|
|
|
|
int *valueptr;
|
|
|
|
};
|
2006-11-17 19:16:21 +01:00
|
|
|
|
2011-10-06 20:46:01 +02:00
|
|
|
// VOCTRL_SCREENSHOT
|
|
|
|
struct voctrl_screenshot_args {
|
2011-10-06 20:46:01 +02:00
|
|
|
// 0: Save image of the currently displayed video frame, in original
|
|
|
|
// resolution.
|
|
|
|
// 1: Save full screenshot of the window. Should contain OSD, EOSD, and the
|
|
|
|
// scaled video.
|
|
|
|
// The value of this variable can be ignored if only a single method is
|
|
|
|
// implemented.
|
|
|
|
int full_window;
|
2011-10-06 20:46:01 +02:00
|
|
|
// Will be set to a newly allocated image, that contains the screenshot.
|
2012-12-22 21:46:22 +01:00
|
|
|
// The caller has to free the image with talloc_free().
|
2011-10-06 20:46:01 +02:00
|
|
|
// It is not specified whether the image data is a copy or references the
|
|
|
|
// image data directly.
|
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
|
|
|
// Can be NULL on failure.
|
2011-10-06 20:46:01 +02:00
|
|
|
struct mp_image *out_image;
|
2012-10-20 23:32:45 +02:00
|
|
|
// Whether the VO rendered OSD/subtitles into out_image
|
|
|
|
bool has_osd;
|
2011-10-06 20:46:01 +02:00
|
|
|
};
|
|
|
|
|
2014-11-02 20:48:45 +01:00
|
|
|
// VOCTRL_GET_WIN_STATE
|
|
|
|
#define VO_WIN_STATE_MINIMIZED 1
|
|
|
|
|
2013-06-15 18:59:52 +02:00
|
|
|
#define VO_TRUE true
|
|
|
|
#define VO_FALSE false
|
2014-04-13 18:00:51 +02:00
|
|
|
#define VO_ERROR -1
|
|
|
|
#define VO_NOTAVAIL -2
|
|
|
|
#define VO_NOTIMPL -3
|
2002-02-09 01:47:26 +01:00
|
|
|
|
2014-04-13 18:00:51 +02:00
|
|
|
#define VOFLAG_FLIPPING 0x08
|
|
|
|
#define VOFLAG_HIDDEN 0x10 //< Use to create a hidden window
|
|
|
|
#define VOFLAG_STEREO 0x20 //< Use to create a stereo-capable window
|
2012-10-03 01:54:13 +02:00
|
|
|
#define VOFLAG_GL_DEBUG 0x40 // Hint to request debug OpenGL context
|
2013-03-28 21:44:27 +01:00
|
|
|
#define VOFLAG_ALPHA 0x80 // Hint to request alpha framebuffer
|
2002-02-17 04:06:38 +01:00
|
|
|
|
2014-04-20 21:36:56 +02:00
|
|
|
// VO does handle mp_image_params.rotate in 90 degree steps
|
|
|
|
#define VO_CAP_ROTATE90 1
|
video: add VO framedropping mode
This mostly uses the same idea as with vo_vdpau.c, but much simplified.
On X11, it tries to get the display framerate with XF86VM, and limits
the frequency of new video frames against it. Note that this is an old
extension, and is confirmed not to work correctly with multi-monitor
setups. But we're using it because it was already around (it is also
used by vo_vdpau).
This attempts to predict the next vsync event by using the time of the
last frame and the display FPS. Even if that goes completely wrong,
the results are still relatively good.
On other systems, or if the X11 code doesn't return a display FPS, a
framerate of 1000 is assumed. This is infinite for all practical
purposes, and means that only frames which are definitely too late are
dropped. This probably has worse results, but is still useful.
"--framedrop=yes" is basically replaced with "--framedrop=decoder". The
old framedropping mode is kept around, and should perhaps be improved.
Dropping on the decoder level is still useful if decoding itself is too
slow.
2014-08-15 23:33:33 +02:00
|
|
|
// VO does framedrop itself (vo_vdpau). Untimed/encoding VOs never drop.
|
|
|
|
#define VO_CAP_FRAMEDROP 2
|
2014-04-20 21:36:56 +02:00
|
|
|
|
2008-04-03 05:25:41 +02:00
|
|
|
struct vo;
|
2008-06-24 00:53:58 +02:00
|
|
|
struct osd_state;
|
2009-09-18 15:27:55 +02:00
|
|
|
struct mp_image;
|
2013-06-08 01:35:44 +02:00
|
|
|
struct mp_image_params;
|
2008-04-03 05:25:41 +02:00
|
|
|
|
2014-12-31 19:01:28 +01:00
|
|
|
struct vo_extra {
|
|
|
|
struct input_ctx *input_ctx;
|
|
|
|
struct osd_state *osd;
|
|
|
|
struct encode_lavc_context *encode_lavc_ctx;
|
2014-12-31 19:12:44 +01:00
|
|
|
struct mpv_opengl_cb_context *opengl_cb_context;
|
2014-12-31 19:01:28 +01:00
|
|
|
};
|
|
|
|
|
2008-04-03 05:25:41 +02:00
|
|
|
struct vo_driver {
|
2013-02-06 22:54:03 +01:00
|
|
|
// Encoding functionality, which can be invoked via --o only.
|
|
|
|
bool encode;
|
|
|
|
|
2014-04-20 21:36:56 +02:00
|
|
|
// VO_CAP_* bits
|
|
|
|
int caps;
|
|
|
|
|
video: move display and timing to a separate thread
The VO is run inside its own thread. It also does most of video timing.
The playloop hands the image data and a realtime timestamp to the VO,
and the VO does the rest.
In particular, this allows the playloop to do other things, instead of
blocking for video redraw. But if anything accesses the VO during video
timing, it will block.
This also fixes vo_sdl.c event handling; but that is only a side-effect,
since reimplementing the broken way would require more effort.
Also drop --softsleep. In theory, this option helps if the kernel's
sleeping mechanism is too inaccurate for video timing. In practice, I
haven't ever encountered a situation where it helps, and it just burns
CPU cycles. On the other hand it's probably actively harmful, because
it prevents the libavcodec decoder threads from doing real work.
Side note:
Originally, I intended that multiple frames can be queued to the VO. But
this is not done, due to problems with OSD and other certain features.
OSD in particular is simply designed in a way that it can be neither
timed nor copied, so you do have to render it into the video frame
before you can draw the next frame. (Subtitles have no such restriction.
sd_lavc was even updated to fix this.) It seems the right solution to
queuing multiple VO frames is rendering on VO-backed framebuffers, like
vo_vdpau.c does. This requires VO driver support, and is out of scope
of this commit.
As consequence, the VO has a queue size of 1. The existing video queue
is just needed to compute frame duration, and will be moved out in the
next commit.
2014-08-12 23:02:08 +02:00
|
|
|
// Disable video timing, push frames as quickly as possible.
|
|
|
|
bool untimed;
|
|
|
|
|
2013-10-23 19:06:14 +02:00
|
|
|
const char *name;
|
|
|
|
const char *description;
|
|
|
|
|
2009-09-17 16:52:09 +02:00
|
|
|
/*
|
|
|
|
* returns: zero on successful initialization, non-zero on error.
|
|
|
|
*/
|
2013-07-22 22:52:42 +02:00
|
|
|
int (*preinit)(struct vo *vo);
|
2012-11-04 16:24:18 +01:00
|
|
|
|
|
|
|
/*
|
|
|
|
* Whether the given image format is supported and config() will succeed.
|
video: decouple internal pixel formats from FourCCs
mplayer's video chain traditionally used FourCCs for pixel formats. For
example, it used IMGFMT_YV12 for 4:2:0 YUV, which was defined to the
string 'YV12' interpreted as unsigned int. Additionally, it used to
encode information into the numeric values of some formats. The RGB
formats had their bit depth and endian encoded into the least
significant byte. Extended planar formats (420P10 etc.) had chroma
shift, endian, and component bit depth encoded. (This has been removed
in recent commits.)
Replace the FourCC mess with a simple enum. Remove all the redundant
formats like YV12/I420/IYUV. Replace some image format names by
something more intuitive, most importantly IMGFMT_YV12 -> IMGFMT_420P.
Add img_fourcc.h, which contains the old IDs for code that actually uses
FourCCs. Change the way demuxers, that output raw video, identify the
video format: they set either MP_FOURCC_RAWVIDEO or MP_FOURCC_IMGFMT to
request the rawvideo decoder, and sh_video->imgfmt specifies the pixel
format. Like the previous hack, this is supposed to avoid the need for
a complete codecs.cfg entry per format, or other lookup tables. (Note
that the RGB raw video FourCCs mostly rely on ffmpeg's mappings for NUT
raw video, but this is still considered better than adding a raw video
decoder - even if trivial, it would be full of annoying lookup tables.)
The TV code has not been tested.
Some corrective changes regarding endian and other image format flags
creep in.
2012-12-23 20:03:30 +01:00
|
|
|
* format: one of IMGFMT_*
|
2012-11-04 16:24:18 +01:00
|
|
|
* returns: 0 on not supported, otherwise a bitmask of VFCAP_* values
|
|
|
|
*/
|
|
|
|
int (*query_format)(struct vo *vo, uint32_t format);
|
|
|
|
|
2009-09-17 16:52:09 +02:00
|
|
|
/*
|
2013-06-08 01:35:44 +02:00
|
|
|
* Initialize or reconfigure the display driver.
|
|
|
|
* params: video parameters, like pixel format and frame size
|
|
|
|
* flags: combination of VOFLAG_ values
|
|
|
|
* returns: < 0 on error, >= 0 on success
|
|
|
|
*/
|
|
|
|
int (*reconfig)(struct vo *vo, struct mp_image_params *params, int flags);
|
|
|
|
|
2009-09-17 16:52:09 +02:00
|
|
|
/*
|
|
|
|
* Control interface
|
|
|
|
*/
|
|
|
|
int (*control)(struct vo *vo, uint32_t request, void *data);
|
|
|
|
|
2014-04-30 22:25:11 +02:00
|
|
|
/*
|
|
|
|
* Render the given frame to the VO's backbuffer. This operation will be
|
|
|
|
* followed by a draw_osd and a flip_page[_timed] call.
|
2014-06-17 23:05:50 +02:00
|
|
|
* mpi belongs to the VO; the VO must free it eventually.
|
2014-06-15 20:46:57 +02:00
|
|
|
*
|
|
|
|
* This also should draw the OSD.
|
2014-04-30 22:25:11 +02:00
|
|
|
*/
|
2012-11-04 15:56:04 +01:00
|
|
|
void (*draw_image)(struct vo *vo, struct mp_image *mpi);
|
2009-09-18 15:27:55 +02:00
|
|
|
|
2009-09-17 16:52:09 +02:00
|
|
|
/*
|
|
|
|
* Blit/Flip buffer to the screen. Must be called after each frame!
|
2014-09-20 15:14:43 +02:00
|
|
|
*/
|
|
|
|
void (*flip_page)(struct vo *vo);
|
|
|
|
|
|
|
|
/*
|
|
|
|
* Timed version of flip_page (optional).
|
2013-05-25 18:31:06 +02:00
|
|
|
* pts_us is the frame presentation time, linked to mp_time_us().
|
|
|
|
* pts_us is 0 if the frame should be presented immediately.
|
|
|
|
* duration is estimated time in us until the next frame is shown.
|
2014-09-20 15:14:43 +02:00
|
|
|
* duration is -1 if it is unknown or unset (also: disable framedrop).
|
|
|
|
* If the VO does manual framedropping, VO_CAP_FRAMEDROP should be set.
|
|
|
|
* Returns 1 on display, or 0 if the frame was dropped.
|
2009-09-17 16:52:09 +02:00
|
|
|
*/
|
2014-09-20 15:14:43 +02:00
|
|
|
int (*flip_page_timed)(struct vo *vo, int64_t pts_us, int duration);
|
2009-09-17 16:52:09 +02:00
|
|
|
|
video: move display and timing to a separate thread
The VO is run inside its own thread. It also does most of video timing.
The playloop hands the image data and a realtime timestamp to the VO,
and the VO does the rest.
In particular, this allows the playloop to do other things, instead of
blocking for video redraw. But if anything accesses the VO during video
timing, it will block.
This also fixes vo_sdl.c event handling; but that is only a side-effect,
since reimplementing the broken way would require more effort.
Also drop --softsleep. In theory, this option helps if the kernel's
sleeping mechanism is too inaccurate for video timing. In practice, I
haven't ever encountered a situation where it helps, and it just burns
CPU cycles. On the other hand it's probably actively harmful, because
it prevents the libavcodec decoder threads from doing real work.
Side note:
Originally, I intended that multiple frames can be queued to the VO. But
this is not done, due to problems with OSD and other certain features.
OSD in particular is simply designed in a way that it can be neither
timed nor copied, so you do have to render it into the video frame
before you can draw the next frame. (Subtitles have no such restriction.
sd_lavc was even updated to fix this.) It seems the right solution to
queuing multiple VO frames is rendering on VO-backed framebuffers, like
vo_vdpau.c does. This requires VO driver support, and is out of scope
of this commit.
As consequence, the VO has a queue size of 1. The existing video queue
is just needed to compute frame duration, and will be moved out in the
next commit.
2014-08-12 23:02:08 +02:00
|
|
|
/* These optional callbacks can be provided if the GUI framework used by
|
|
|
|
* the VO requires entering a message loop for receiving events, does not
|
|
|
|
* provide event_fd, and does not call vo_wakeup() from a separate thread
|
|
|
|
* when there are new events.
|
|
|
|
*
|
|
|
|
* wait_events() will wait for new events, until the timeout expires, or the
|
|
|
|
* function is interrupted. wakeup() is used to possibly interrupt the
|
|
|
|
* event loop (wakeup() itself must be thread-safe, and not call any other
|
|
|
|
* VO functions; it's the only vo_driver function with this requirement).
|
|
|
|
* wakeup() should behave like a binary semaphore; if wait_events() is not
|
|
|
|
* being called while wakeup() is, the next wait_events() call should exit
|
|
|
|
* immediately.
|
|
|
|
*/
|
|
|
|
void (*wakeup)(struct vo *vo);
|
|
|
|
int (*wait_events)(struct vo *vo, int64_t until_time_us);
|
|
|
|
|
2009-09-17 16:52:09 +02:00
|
|
|
/*
|
|
|
|
* Closes driver. Should restore the original state of the system.
|
|
|
|
*/
|
|
|
|
void (*uninit)(struct vo *vo);
|
2012-06-25 22:12:03 +02:00
|
|
|
|
2012-08-06 17:51:53 +02:00
|
|
|
// Size of private struct for automatic allocation (0 doesn't allocate)
|
|
|
|
int priv_size;
|
2012-06-25 22:12:03 +02:00
|
|
|
|
2012-08-06 17:52:17 +02:00
|
|
|
// If not NULL, it's copied into the newly allocated private struct.
|
|
|
|
const void *priv_defaults;
|
|
|
|
|
video: move display and timing to a separate thread
The VO is run inside its own thread. It also does most of video timing.
The playloop hands the image data and a realtime timestamp to the VO,
and the VO does the rest.
In particular, this allows the playloop to do other things, instead of
blocking for video redraw. But if anything accesses the VO during video
timing, it will block.
This also fixes vo_sdl.c event handling; but that is only a side-effect,
since reimplementing the broken way would require more effort.
Also drop --softsleep. In theory, this option helps if the kernel's
sleeping mechanism is too inaccurate for video timing. In practice, I
haven't ever encountered a situation where it helps, and it just burns
CPU cycles. On the other hand it's probably actively harmful, because
it prevents the libavcodec decoder threads from doing real work.
Side note:
Originally, I intended that multiple frames can be queued to the VO. But
this is not done, due to problems with OSD and other certain features.
OSD in particular is simply designed in a way that it can be neither
timed nor copied, so you do have to render it into the video frame
before you can draw the next frame. (Subtitles have no such restriction.
sd_lavc was even updated to fix this.) It seems the right solution to
queuing multiple VO frames is rendering on VO-backed framebuffers, like
vo_vdpau.c does. This requires VO driver support, and is out of scope
of this commit.
As consequence, the VO has a queue size of 1. The existing video queue
is just needed to compute frame duration, and will be moved out in the
next commit.
2014-08-12 23:02:08 +02:00
|
|
|
// List of options to parse into priv struct (requires priv_size to be set)
|
2012-06-25 22:12:03 +02:00
|
|
|
const struct m_option *options;
|
2008-04-03 05:25:41 +02:00
|
|
|
};
|
2001-02-24 21:28:24 +01:00
|
|
|
|
2008-04-03 05:25:41 +02:00
|
|
|
struct vo {
|
|
|
|
const struct vo_driver *driver;
|
video: move display and timing to a separate thread
The VO is run inside its own thread. It also does most of video timing.
The playloop hands the image data and a realtime timestamp to the VO,
and the VO does the rest.
In particular, this allows the playloop to do other things, instead of
blocking for video redraw. But if anything accesses the VO during video
timing, it will block.
This also fixes vo_sdl.c event handling; but that is only a side-effect,
since reimplementing the broken way would require more effort.
Also drop --softsleep. In theory, this option helps if the kernel's
sleeping mechanism is too inaccurate for video timing. In practice, I
haven't ever encountered a situation where it helps, and it just burns
CPU cycles. On the other hand it's probably actively harmful, because
it prevents the libavcodec decoder threads from doing real work.
Side note:
Originally, I intended that multiple frames can be queued to the VO. But
this is not done, due to problems with OSD and other certain features.
OSD in particular is simply designed in a way that it can be neither
timed nor copied, so you do have to render it into the video frame
before you can draw the next frame. (Subtitles have no such restriction.
sd_lavc was even updated to fix this.) It seems the right solution to
queuing multiple VO frames is rendering on VO-backed framebuffers, like
vo_vdpau.c does. This requires VO driver support, and is out of scope
of this commit.
As consequence, the VO has a queue size of 1. The existing video queue
is just needed to compute frame duration, and will be moved out in the
next commit.
2014-08-12 23:02:08 +02:00
|
|
|
struct mp_log *log; // Using e.g. "[vo/vdpau]" as prefix
|
2008-04-03 05:25:41 +02:00
|
|
|
void *priv;
|
2013-12-21 17:51:20 +01:00
|
|
|
struct mpv_global *global;
|
2008-04-20 06:36:34 +02:00
|
|
|
struct vo_x11_state *x11;
|
2012-04-14 13:39:53 +02:00
|
|
|
struct vo_w32_state *w32;
|
2012-09-13 09:32:59 +02:00
|
|
|
struct vo_cocoa_state *cocoa;
|
2013-02-28 19:55:02 +01:00
|
|
|
struct vo_wayland_state *wayland;
|
2008-04-30 10:06:55 +02:00
|
|
|
struct input_ctx *input_ctx;
|
2014-06-15 20:46:57 +02:00
|
|
|
struct osd_state *osd;
|
video: move display and timing to a separate thread
The VO is run inside its own thread. It also does most of video timing.
The playloop hands the image data and a realtime timestamp to the VO,
and the VO does the rest.
In particular, this allows the playloop to do other things, instead of
blocking for video redraw. But if anything accesses the VO during video
timing, it will block.
This also fixes vo_sdl.c event handling; but that is only a side-effect,
since reimplementing the broken way would require more effort.
Also drop --softsleep. In theory, this option helps if the kernel's
sleeping mechanism is too inaccurate for video timing. In practice, I
haven't ever encountered a situation where it helps, and it just burns
CPU cycles. On the other hand it's probably actively harmful, because
it prevents the libavcodec decoder threads from doing real work.
Side note:
Originally, I intended that multiple frames can be queued to the VO. But
this is not done, due to problems with OSD and other certain features.
OSD in particular is simply designed in a way that it can be neither
timed nor copied, so you do have to render it into the video frame
before you can draw the next frame. (Subtitles have no such restriction.
sd_lavc was even updated to fix this.) It seems the right solution to
queuing multiple VO frames is rendering on VO-backed framebuffers, like
vo_vdpau.c does. This requires VO driver support, and is out of scope
of this commit.
As consequence, the VO has a queue size of 1. The existing video queue
is just needed to compute frame duration, and will be moved out in the
next commit.
2014-08-12 23:02:08 +02:00
|
|
|
struct encode_lavc_context *encode_lavc_ctx;
|
|
|
|
struct vo_internal *in;
|
|
|
|
struct mp_vo_opts *opts;
|
2014-12-31 19:01:28 +01:00
|
|
|
struct vo_extra extra;
|
video: move display and timing to a separate thread
The VO is run inside its own thread. It also does most of video timing.
The playloop hands the image data and a realtime timestamp to the VO,
and the VO does the rest.
In particular, this allows the playloop to do other things, instead of
blocking for video redraw. But if anything accesses the VO during video
timing, it will block.
This also fixes vo_sdl.c event handling; but that is only a side-effect,
since reimplementing the broken way would require more effort.
Also drop --softsleep. In theory, this option helps if the kernel's
sleeping mechanism is too inaccurate for video timing. In practice, I
haven't ever encountered a situation where it helps, and it just burns
CPU cycles. On the other hand it's probably actively harmful, because
it prevents the libavcodec decoder threads from doing real work.
Side note:
Originally, I intended that multiple frames can be queued to the VO. But
this is not done, due to problems with OSD and other certain features.
OSD in particular is simply designed in a way that it can be neither
timed nor copied, so you do have to render it into the video frame
before you can draw the next frame. (Subtitles have no such restriction.
sd_lavc was even updated to fix this.) It seems the right solution to
queuing multiple VO frames is rendering on VO-backed framebuffers, like
vo_vdpau.c does. This requires VO driver support, and is out of scope
of this commit.
As consequence, the VO has a queue size of 1. The existing video queue
is just needed to compute frame duration, and will be moved out in the
next commit.
2014-08-12 23:02:08 +02:00
|
|
|
|
|
|
|
// --- The following fields are generally only changed during initialization.
|
|
|
|
|
2010-12-14 20:58:47 +01:00
|
|
|
int event_fd; // check_events() should be called when this has input
|
video: move display and timing to a separate thread
The VO is run inside its own thread. It also does most of video timing.
The playloop hands the image data and a realtime timestamp to the VO,
and the VO does the rest.
In particular, this allows the playloop to do other things, instead of
blocking for video redraw. But if anything accesses the VO during video
timing, it will block.
This also fixes vo_sdl.c event handling; but that is only a side-effect,
since reimplementing the broken way would require more effort.
Also drop --softsleep. In theory, this option helps if the kernel's
sleeping mechanism is too inaccurate for video timing. In practice, I
haven't ever encountered a situation where it helps, and it just burns
CPU cycles. On the other hand it's probably actively harmful, because
it prevents the libavcodec decoder threads from doing real work.
Side note:
Originally, I intended that multiple frames can be queued to the VO. But
this is not done, due to problems with OSD and other certain features.
OSD in particular is simply designed in a way that it can be neither
timed nor copied, so you do have to render it into the video frame
before you can draw the next frame. (Subtitles have no such restriction.
sd_lavc was even updated to fix this.) It seems the right solution to
queuing multiple VO frames is rendering on VO-backed framebuffers, like
vo_vdpau.c does. This requires VO driver support, and is out of scope
of this commit.
As consequence, the VO has a queue size of 1. The existing video queue
is just needed to compute frame duration, and will be moved out in the
next commit.
2014-08-12 23:02:08 +02:00
|
|
|
bool probing;
|
|
|
|
|
|
|
|
// --- The following fields are only changed with vo_reconfig(), and can
|
|
|
|
// be accessed unsynchronized (read-only).
|
|
|
|
|
|
|
|
int config_ok; // Last config call was successful?
|
|
|
|
struct mp_image_params *params; // Configured parameters (as in vo_reconfig)
|
|
|
|
|
|
|
|
// --- The following fields can be accessed only by the VO thread, or from
|
|
|
|
// anywhere _if_ the VO thread is suspended (use vo->dispatch).
|
|
|
|
|
|
|
|
bool want_redraw; // redraw as soon as possible
|
2008-04-20 23:37:12 +02:00
|
|
|
|
2014-01-22 00:26:01 +01:00
|
|
|
// current window state
|
|
|
|
int dwidth;
|
|
|
|
int dheight;
|
|
|
|
float monitor_par;
|
2008-04-03 05:25:41 +02:00
|
|
|
};
|
2001-02-24 21:28:24 +01:00
|
|
|
|
2013-07-31 21:44:21 +02:00
|
|
|
struct mpv_global;
|
2014-12-31 19:01:28 +01:00
|
|
|
struct vo *init_best_video_out(struct mpv_global *global, struct vo_extra *ex);
|
2013-06-08 01:35:44 +02:00
|
|
|
int vo_reconfig(struct vo *vo, struct mp_image_params *p, int flags);
|
2002-09-29 23:53:05 +02:00
|
|
|
|
2008-04-03 05:25:41 +02:00
|
|
|
int vo_control(struct vo *vo, uint32_t request, void *data);
|
video: move display and timing to a separate thread
The VO is run inside its own thread. It also does most of video timing.
The playloop hands the image data and a realtime timestamp to the VO,
and the VO does the rest.
In particular, this allows the playloop to do other things, instead of
blocking for video redraw. But if anything accesses the VO during video
timing, it will block.
This also fixes vo_sdl.c event handling; but that is only a side-effect,
since reimplementing the broken way would require more effort.
Also drop --softsleep. In theory, this option helps if the kernel's
sleeping mechanism is too inaccurate for video timing. In practice, I
haven't ever encountered a situation where it helps, and it just burns
CPU cycles. On the other hand it's probably actively harmful, because
it prevents the libavcodec decoder threads from doing real work.
Side note:
Originally, I intended that multiple frames can be queued to the VO. But
this is not done, due to problems with OSD and other certain features.
OSD in particular is simply designed in a way that it can be neither
timed nor copied, so you do have to render it into the video frame
before you can draw the next frame. (Subtitles have no such restriction.
sd_lavc was even updated to fix this.) It seems the right solution to
queuing multiple VO frames is rendering on VO-backed framebuffers, like
vo_vdpau.c does. This requires VO driver support, and is out of scope
of this commit.
As consequence, the VO has a queue size of 1. The existing video queue
is just needed to compute frame duration, and will be moved out in the
next commit.
2014-08-12 23:02:08 +02:00
|
|
|
bool vo_is_ready_for_frame(struct vo *vo, int64_t next_pts);
|
video: fix and simplify video format changes and last frame display
The previous commit broke these things, and fixing them is separate in
this commit in order to reduce the volume of changes.
Move the image queue from the VO to the playback core. The image queue
is a remnant of the old way how vdpau was implemented, and increasingly
became more and more an artifact. In the end, it did only one thing:
computing the duration of the current frame. This was done by taking the
PTS difference between the current and the future frame. We keep this,
but by moving it out of the VO, we don't have to special-case format
changes anymore. This simplifies the code a lot.
Since we need the queue to compute the duration only, a queue size
larger than 2 makes no sense, and we can hardcode that.
Also change how the last frame is handled. The last frame is a bit of a
problem, because video timing works by showing one frame after another,
which makes it a special case. Make the VO provide a function to notify
us when the frame is done, instead. The frame duration is used for that.
This is not perfect. For example, changing playback speed during the
last frame doesn't update the end time. Pausing will not stop the clock
that times the last frame. But I don't think this matters for such a
corner case.
2014-08-12 23:17:35 +02:00
|
|
|
void vo_queue_frame(struct vo *vo, struct mp_image *image,
|
|
|
|
int64_t pts_us, int64_t duration);
|
video: move display and timing to a separate thread
The VO is run inside its own thread. It also does most of video timing.
The playloop hands the image data and a realtime timestamp to the VO,
and the VO does the rest.
In particular, this allows the playloop to do other things, instead of
blocking for video redraw. But if anything accesses the VO during video
timing, it will block.
This also fixes vo_sdl.c event handling; but that is only a side-effect,
since reimplementing the broken way would require more effort.
Also drop --softsleep. In theory, this option helps if the kernel's
sleeping mechanism is too inaccurate for video timing. In practice, I
haven't ever encountered a situation where it helps, and it just burns
CPU cycles. On the other hand it's probably actively harmful, because
it prevents the libavcodec decoder threads from doing real work.
Side note:
Originally, I intended that multiple frames can be queued to the VO. But
this is not done, due to problems with OSD and other certain features.
OSD in particular is simply designed in a way that it can be neither
timed nor copied, so you do have to render it into the video frame
before you can draw the next frame. (Subtitles have no such restriction.
sd_lavc was even updated to fix this.) It seems the right solution to
queuing multiple VO frames is rendering on VO-backed framebuffers, like
vo_vdpau.c does. This requires VO driver support, and is out of scope
of this commit.
As consequence, the VO has a queue size of 1. The existing video queue
is just needed to compute frame duration, and will be moved out in the
next commit.
2014-08-12 23:02:08 +02:00
|
|
|
void vo_wait_frame(struct vo *vo);
|
video: fix and simplify video format changes and last frame display
The previous commit broke these things, and fixing them is separate in
this commit in order to reduce the volume of changes.
Move the image queue from the VO to the playback core. The image queue
is a remnant of the old way how vdpau was implemented, and increasingly
became more and more an artifact. In the end, it did only one thing:
computing the duration of the current frame. This was done by taking the
PTS difference between the current and the future frame. We keep this,
but by moving it out of the VO, we don't have to special-case format
changes anymore. This simplifies the code a lot.
Since we need the queue to compute the duration only, a queue size
larger than 2 makes no sense, and we can hardcode that.
Also change how the last frame is handled. The last frame is a bit of a
problem, because video timing works by showing one frame after another,
which makes it a special case. Make the VO provide a function to notify
us when the frame is done, instead. The frame duration is used for that.
This is not perfect. For example, changing playback speed during the
last frame doesn't update the end time. Pausing will not stop the clock
that times the last frame. But I don't think this matters for such a
corner case.
2014-08-12 23:17:35 +02:00
|
|
|
bool vo_still_displaying(struct vo *vo);
|
|
|
|
bool vo_has_frame(struct vo *vo);
|
2014-06-15 20:46:57 +02:00
|
|
|
void vo_redraw(struct vo *vo);
|
2014-10-03 21:53:32 +02:00
|
|
|
bool vo_want_redraw(struct vo *vo);
|
2009-09-18 15:27:55 +02:00
|
|
|
void vo_seek_reset(struct vo *vo);
|
2008-04-03 05:25:41 +02:00
|
|
|
void vo_destroy(struct vo *vo);
|
video: add VO framedropping mode
This mostly uses the same idea as with vo_vdpau.c, but much simplified.
On X11, it tries to get the display framerate with XF86VM, and limits
the frequency of new video frames against it. Note that this is an old
extension, and is confirmed not to work correctly with multi-monitor
setups. But we're using it because it was already around (it is also
used by vo_vdpau).
This attempts to predict the next vsync event by using the time of the
last frame and the display FPS. Even if that goes completely wrong,
the results are still relatively good.
On other systems, or if the X11 code doesn't return a display FPS, a
framerate of 1000 is assumed. This is infinite for all practical
purposes, and means that only frames which are definitely too late are
dropped. This probably has worse results, but is still useful.
"--framedrop=yes" is basically replaced with "--framedrop=decoder". The
old framedropping mode is kept around, and should perhaps be improved.
Dropping on the decoder level is still useful if decoding itself is too
slow.
2014-08-15 23:33:33 +02:00
|
|
|
void vo_set_paused(struct vo *vo, bool paused);
|
|
|
|
int64_t vo_get_drop_count(struct vo *vo);
|
2014-08-20 21:35:45 +02:00
|
|
|
int vo_query_format(struct vo *vo, int format);
|
2014-11-02 20:26:51 +01:00
|
|
|
void vo_event(struct vo *vo, int event);
|
2014-11-09 10:00:21 +01:00
|
|
|
int vo_query_and_reset_events(struct vo *vo, int events);
|
2008-04-03 05:25:41 +02:00
|
|
|
|
video: move display and timing to a separate thread
The VO is run inside its own thread. It also does most of video timing.
The playloop hands the image data and a realtime timestamp to the VO,
and the VO does the rest.
In particular, this allows the playloop to do other things, instead of
blocking for video redraw. But if anything accesses the VO during video
timing, it will block.
This also fixes vo_sdl.c event handling; but that is only a side-effect,
since reimplementing the broken way would require more effort.
Also drop --softsleep. In theory, this option helps if the kernel's
sleeping mechanism is too inaccurate for video timing. In practice, I
haven't ever encountered a situation where it helps, and it just burns
CPU cycles. On the other hand it's probably actively harmful, because
it prevents the libavcodec decoder threads from doing real work.
Side note:
Originally, I intended that multiple frames can be queued to the VO. But
this is not done, due to problems with OSD and other certain features.
OSD in particular is simply designed in a way that it can be neither
timed nor copied, so you do have to render it into the video frame
before you can draw the next frame. (Subtitles have no such restriction.
sd_lavc was even updated to fix this.) It seems the right solution to
queuing multiple VO frames is rendering on VO-backed framebuffers, like
vo_vdpau.c does. This requires VO driver support, and is out of scope
of this commit.
As consequence, the VO has a queue size of 1. The existing video queue
is just needed to compute frame duration, and will be moved out in the
next commit.
2014-08-12 23:02:08 +02:00
|
|
|
void vo_set_flip_queue_offset(struct vo *vo, int64_t us);
|
2014-08-17 02:50:59 +02:00
|
|
|
int64_t vo_get_vsync_interval(struct vo *vo);
|
video: move display and timing to a separate thread
The VO is run inside its own thread. It also does most of video timing.
The playloop hands the image data and a realtime timestamp to the VO,
and the VO does the rest.
In particular, this allows the playloop to do other things, instead of
blocking for video redraw. But if anything accesses the VO during video
timing, it will block.
This also fixes vo_sdl.c event handling; but that is only a side-effect,
since reimplementing the broken way would require more effort.
Also drop --softsleep. In theory, this option helps if the kernel's
sleeping mechanism is too inaccurate for video timing. In practice, I
haven't ever encountered a situation where it helps, and it just burns
CPU cycles. On the other hand it's probably actively harmful, because
it prevents the libavcodec decoder threads from doing real work.
Side note:
Originally, I intended that multiple frames can be queued to the VO. But
this is not done, due to problems with OSD and other certain features.
OSD in particular is simply designed in a way that it can be neither
timed nor copied, so you do have to render it into the video frame
before you can draw the next frame. (Subtitles have no such restriction.
sd_lavc was even updated to fix this.) It seems the right solution to
queuing multiple VO frames is rendering on VO-backed framebuffers, like
vo_vdpau.c does. This requires VO driver support, and is out of scope
of this commit.
As consequence, the VO has a queue size of 1. The existing video queue
is just needed to compute frame duration, and will be moved out in the
next commit.
2014-08-12 23:02:08 +02:00
|
|
|
void vo_wakeup(struct vo *vo);
|
|
|
|
|
2011-12-06 20:23:54 +01:00
|
|
|
const char *vo_get_window_title(struct vo *vo);
|
2008-04-03 05:25:41 +02:00
|
|
|
|
2010-04-23 12:22:44 +02:00
|
|
|
struct mp_keymap {
|
2008-12-20 12:52:11 +01:00
|
|
|
int from;
|
|
|
|
int to;
|
|
|
|
};
|
2010-04-23 12:22:44 +02:00
|
|
|
int lookup_keymap_table(const struct mp_keymap *map, int key);
|
2012-10-27 22:10:32 +02:00
|
|
|
|
|
|
|
struct mp_osd_res;
|
|
|
|
void vo_get_src_dst_rects(struct vo *vo, struct mp_rect *out_src,
|
|
|
|
struct mp_rect *out_dst, struct mp_osd_res *out_osd);
|
|
|
|
|
2008-02-22 10:09:46 +01:00
|
|
|
#endif /* MPLAYER_VIDEO_OUT_H */
|