1
mirror of https://github.com/mpv-player/mpv synced 2024-11-14 22:48:35 +01:00
mpv/video/out/vo.h

322 lines
10 KiB
C
Raw Normal View History

/*
* Copyright (C) Aaron Holtzman - Aug 1999
* Strongly modified, most parts rewritten: A'rpi/ESP-team - 2000-2001
* (C) MPlayer developers
*
* This file is part of MPlayer.
*
* 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.
*/
#ifndef MPLAYER_VIDEO_OUT_H
#define MPLAYER_VIDEO_OUT_H
#include <inttypes.h>
#include <stdbool.h>
#include "video/img_format.h"
#include "core/mp_common.h"
#include "core/options.h"
#define VO_EVENT_EXPOSE 1
#define VO_EVENT_RESIZE 2
enum mp_voctrl {
/* signal a device reset seek */
VOCTRL_RESET = 1,
/* Handle input and redraw events, called by vo_check_events() */
VOCTRL_CHECK_EVENTS,
/* used to switch to fullscreen */
VOCTRL_FULLSCREEN,
/* signal a device pause */
VOCTRL_PAUSE,
/* start/resume playback */
VOCTRL_RESUME,
VOCTRL_GET_PANSCAN,
VOCTRL_SET_PANSCAN,
VOCTRL_SET_EQUALIZER, // struct voctrl_set_equalizer_args
VOCTRL_GET_EQUALIZER, // struct voctrl_get_equalizer_args
/* for vdpau hardware decoding */
VOCTRL_HWDEC_DECODER_RENDER, // pointer to hw state
VOCTRL_HWDEC_ALLOC_SURFACE, // struct mp_image**
VOCTRL_NEWFRAME,
VOCTRL_SKIPFRAME,
VOCTRL_REDRAW_FRAME,
VOCTRL_ONTOP,
VOCTRL_BORDER,
VOCTRL_SET_CURSOR_VISIBILITY, // bool
VOCTRL_KILL_SCREENSAVER,
VOCTRL_RESTORE_SCREENSAVER,
VOCTRL_SET_DEINTERLACE,
VOCTRL_GET_DEINTERLACE,
VOCTRL_UPDATE_SCREENINFO,
video, options: implement better YUV->RGB conversion control Rewrite control of the colorspace and input/output level parameters used in YUV-RGB conversions, replacing VO-specific suboptions with new common options and adding configuration support to more cases. Add new option --colormatrix which selects the colorspace the original video is assumed to have in YUV->RGB conversions. The default behavior changes from assuming BT.601 to colorspace autoselection between BT.601 and BT.709 using a simple heuristic based on video size. Add new options --colormatrix-input-range and --colormatrix-output-range which select input YUV and output RGB range. Disable the previously existing VO-specific colorspace and level conversion suboptions in vo_gl and vo_vdpau. Remove the "yuv_colorspace" property and replace it with one named "colormatrix" and semantics matching the new option. Add new properties matching the options for level conversion. Colorspace selection is currently supported by vo_gl, vo_vdpau, vo_xv and vf_scale, and all can change it at runtime (previously only vo_vdpau and vo_xv could). vo_vdpau now uses the same conversion matrix generation as vo_gl instead of libvdpau functionality; the main functional difference is that the "contrast" equalizer control behaves somewhat differently (it scales the Y component around 1/2 instead of around 0, so that contrast 0 makes the image gray rather than black). vo_xv does not support level conversion. vf_scale supports range setting for input, but always outputs full-range RGB. The value of the slave properties is the policy setting used for conversions. This means they can be set to any value regardless of whether the current VO supports that value or whether there currently even is any video. Possibly separate properties could be added to query the conversion actually used at the moment, if any. Because the colorspace and level settings are now set with a single VF/VO control call, the return value of that is no longer used to signal whether all the settings are actually supported. Instead code should set all the details it can support, and ignore the rest. The core will use GET_YUV_COLORSPACE to check which colorspace details have been set and which not. In other words, the return value for SET_YUV_COLORSPACE only signals whether any kind of YUV colorspace conversion handling exists at all, and VOs have to take care to return the actual state with GET_YUV_COLORSPACE instead. To be changed in later commits: add missing option documentation.
2011-10-15 23:50:21 +02:00
VOCTRL_SET_YUV_COLORSPACE, // struct mp_csp_details
VOCTRL_GET_YUV_COLORSPACE, // struct mp_csp_details
VOCTRL_SCREENSHOT, // struct voctrl_screenshot_args
VOCTRL_SET_COMMAND_LINE, // char*
};
// VOCTRL_SET_EQUALIZER
struct voctrl_set_equalizer_args {
const char *name;
int value;
};
// VOCTRL_GET_EQUALIZER
struct voctrl_get_equalizer_args {
const char *name;
int *valueptr;
};
// VOCTRL_SCREENSHOT
struct voctrl_screenshot_args {
// 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;
// Will be set to a newly allocated image, that contains the screenshot.
// The caller has to free the image with talloc_free().
// It is not specified whether the image data is a copy or references the
// image data directly.
// Is never NULL. (Failure has to be indicated by returning VO_FALSE.)
struct mp_image *out_image;
// Whether the VO rendered OSD/subtitles into out_image
bool has_osd;
};
#define VO_TRUE 1
#define VO_FALSE 0
#define VO_ERROR -1
#define VO_NOTAVAIL -2
#define VO_NOTIMPL -3
#define VOFLAG_FULLSCREEN 0x01
#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
#define VOFLAG_GL_DEBUG 0x40 // Hint to request debug OpenGL context
#define VOFLAG_ALPHA 0x80 // Hint to request alpha framebuffer
typedef struct vo_info_s
{
/* driver name ("Matrox Millennium G200/G400" */
const char *name;
libvo, libao: remove useless video and audio output drivers Some of these have only limited use, and some of these have no use at all. Remove them. They make maintainance harder and nobody needs them. It's possible that many of the removed drivers were very useful a dozen of years ago, but now it's 2012. Note that some of these could be added back, in case they were more useful than I thought. But right now, they are just a burden. Reason for removal for each module: vo_3dfx, vo_dfbmga, vo_dxr3, vo_ivtv, vo_mga, vo_s3fb, vo_tdfxfb, vo_xmga, vo_tdfx_vid: All of these are for very specific and outdated hardware. Some of them require non-standard kernel drivers or do direct HW access. vo_dga: the most crappy and ancient way to get fast output on X. vo_aa: there's vo_caca for the same purpose. vo_ggi: this never lived, and is entirely useless. vo_mpegpes: for DVB cards, I can't test this and it's crappy. vo_fbdev, vo_fbdev2: there's vo_directfb2 vo_bl: what is this even? But it's neither important, nor alive. vo_svga, vo_vesa: you want to use this? You can't be serious. vo_wii: I can't test this, and who the hell uses this? vo_xvr100: some Sun thing. vo_xover: only useful in connection with xvr100. ao_nas: still alive, but I doubt it has any meaning today. ao_sun: Sun. ao_win32: use ao_dsound or ao_portaudio instead. ao_ivtv: removed along vo_ivtv. Also get rid of anything SDL related. SDL 1.x is total crap for video output, and will be replaced with SDL 2.x soon (perhaps), so if you want to use SDL, write output drivers for SDL 2.x. Additionally, I accidentally damaged Sun support, which made me completely remove Sun/Solaris support. Nobody cares about this anyway. Some left overs from previous commits removing modules were cleaned up.
2012-07-28 20:20:17 +02:00
/* short name (for config strings) ("vdpau") */
const char *short_name;
/* author ("Aaron Holtzman <aholtzma@ess.engr.uvic.ca>") */
const char *author;
/* any additional comments */
const char *comment;
} vo_info_t;
struct vo;
struct osd_state;
core/VO: Allow VO drivers to add/modify frames Add interfaces to allow VO drivers to add or remove frames from the video stream and to alter timestamps. Currently this functionality only works with in correct-pts mode. Use the new functionality in vo_vdpau to properly support frame-adding deinterlace modes. Frames added by the VDPAU deinterlacing code are now properly timed. Before every second frame was always shown immediately (probably next monitor refresh) after the previous one, even if you were watching things in slow motion, and framestepping didn't stop at them at all. When seeking the deinterlace algorithm is no longer fed a mix of frames from old and new positions. As a side effect of the changes a problem with resize events was also fixed. Resizing calls video_to_output_surface() to render the frame at the new resolution, but before this function also changed the list of history frames, so resizing could give an image different from the original one, and also corrupt next frames due to them seeing the wrong history. Now the function has no such side effects. There are more resize-related problems though that will be fixed in a later commit. The deint_mpi[] list of reserved frames is increased from 2 to 3 entries for reasons related to the above. Having 2 entries is enough when you initially get a new frame in draw_image() because then you'll have those two entries plus the new one for a total of 3 (the code relied on the oldest mpi implicitly staying reserved for the duration of the call even after usage count was decreased). However if you want to be able to reproduce the rendering outside draw_image(), relying on the explicitly reserved list only, then it needs to store 3 entries.
2009-09-18 15:27:55 +02:00
struct mp_image;
struct vo_driver {
core/VO: Allow VO drivers to add/modify frames Add interfaces to allow VO drivers to add or remove frames from the video stream and to alter timestamps. Currently this functionality only works with in correct-pts mode. Use the new functionality in vo_vdpau to properly support frame-adding deinterlace modes. Frames added by the VDPAU deinterlacing code are now properly timed. Before every second frame was always shown immediately (probably next monitor refresh) after the previous one, even if you were watching things in slow motion, and framestepping didn't stop at them at all. When seeking the deinterlace algorithm is no longer fed a mix of frames from old and new positions. As a side effect of the changes a problem with resize events was also fixed. Resizing calls video_to_output_surface() to render the frame at the new resolution, but before this function also changed the list of history frames, so resizing could give an image different from the original one, and also corrupt next frames due to them seeing the wrong history. Now the function has no such side effects. There are more resize-related problems though that will be fixed in a later commit. The deint_mpi[] list of reserved frames is increased from 2 to 3 entries for reasons related to the above. Having 2 entries is enough when you initially get a new frame in draw_image() because then you'll have those two entries plus the new one for a total of 3 (the code relied on the oldest mpi implicitly staying reserved for the duration of the call even after usage count was decreased). However if you want to be able to reproduce the rendering outside draw_image(), relying on the explicitly reserved list only, then it needs to store 3 entries.
2009-09-18 15:27:55 +02:00
// Driver buffers or adds (deinterlace) frames and will keep track
// of pts values itself
bool buffer_frames;
// Encoding functionality, which can be invoked via --o only.
bool encode;
const vo_info_t *info;
/*
* Preinitializes driver (real INITIALIZATION)
* arg - currently it's vo_subdevice
* returns: zero on successful initialization, non-zero on error.
*/
int (*preinit)(struct vo *vo, const char *arg);
/*
* 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_*
* returns: 0 on not supported, otherwise a bitmask of VFCAP_* values
*/
int (*query_format)(struct vo *vo, uint32_t format);
/*
* Initialize (means CONFIGURE) the display driver.
* params:
* width,height: image source size
* d_width,d_height: size of the requested window size, just a hint
* fullscreen: flag, 0=windowd 1=fullscreen, just a hint
* title: window title, if available
* format: fourcc of pixel format
* returns : zero on successful initialization, non-zero on error.
*/
int (*config)(struct vo *vo, uint32_t width, uint32_t height,
uint32_t d_width, uint32_t d_height, uint32_t fullscreen,
uint32_t format);
/*
* Control interface
*/
int (*control)(struct vo *vo, uint32_t request, void *data);
void (*draw_image)(struct vo *vo, struct mp_image *mpi);
core/VO: Allow VO drivers to add/modify frames Add interfaces to allow VO drivers to add or remove frames from the video stream and to alter timestamps. Currently this functionality only works with in correct-pts mode. Use the new functionality in vo_vdpau to properly support frame-adding deinterlace modes. Frames added by the VDPAU deinterlacing code are now properly timed. Before every second frame was always shown immediately (probably next monitor refresh) after the previous one, even if you were watching things in slow motion, and framestepping didn't stop at them at all. When seeking the deinterlace algorithm is no longer fed a mix of frames from old and new positions. As a side effect of the changes a problem with resize events was also fixed. Resizing calls video_to_output_surface() to render the frame at the new resolution, but before this function also changed the list of history frames, so resizing could give an image different from the original one, and also corrupt next frames due to them seeing the wrong history. Now the function has no such side effects. There are more resize-related problems though that will be fixed in a later commit. The deint_mpi[] list of reserved frames is increased from 2 to 3 entries for reasons related to the above. Having 2 entries is enough when you initially get a new frame in draw_image() because then you'll have those two entries plus the new one for a total of 3 (the code relied on the oldest mpi implicitly staying reserved for the duration of the call even after usage count was decreased). However if you want to be able to reproduce the rendering outside draw_image(), relying on the explicitly reserved list only, then it needs to store 3 entries.
2009-09-18 15:27:55 +02:00
/*
* Get extra frames from the VO, such as those added by VDPAU
* deinterlace. Preparing the next such frame if any could be done
* automatically by the VO after a previous flip_page(), but having
* it as a separate step seems to allow making code more robust.
*/
void (*get_buffered_frame)(struct vo *vo, bool eof);
/*
* Draws OSD to the screen buffer
*/
void (*draw_osd)(struct vo *vo, struct osd_state *osd);
/*
* Blit/Flip buffer to the screen. Must be called after each frame!
* 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.
* duration is -1 if it is unknown or unset.
*/
void (*flip_page)(struct vo *vo);
void (*flip_page_timed)(struct vo *vo, int64_t pts_us, int duration);
/*
* Closes driver. Should restore the original state of the system.
*/
void (*uninit)(struct vo *vo);
// Size of private struct for automatic allocation (0 doesn't allocate)
int priv_size;
// If not NULL, it's copied into the newly allocated private struct.
const void *priv_defaults;
// List of options to parse into priv struct (requires privsize to be set)
const struct m_option *options;
// Help text to print when option parsing fails
const char *help_text;
// Parse these options before parsing user options
const char *init_option_string;
};
struct vo {
int config_ok; // Last config call was successful?
int config_count; // Total number of successful config calls
core/VO: Allow VO drivers to add/modify frames Add interfaces to allow VO drivers to add or remove frames from the video stream and to alter timestamps. Currently this functionality only works with in correct-pts mode. Use the new functionality in vo_vdpau to properly support frame-adding deinterlace modes. Frames added by the VDPAU deinterlacing code are now properly timed. Before every second frame was always shown immediately (probably next monitor refresh) after the previous one, even if you were watching things in slow motion, and framestepping didn't stop at them at all. When seeking the deinterlace algorithm is no longer fed a mix of frames from old and new positions. As a side effect of the changes a problem with resize events was also fixed. Resizing calls video_to_output_surface() to render the frame at the new resolution, but before this function also changed the list of history frames, so resizing could give an image different from the original one, and also corrupt next frames due to them seeing the wrong history. Now the function has no such side effects. There are more resize-related problems though that will be fixed in a later commit. The deint_mpi[] list of reserved frames is increased from 2 to 3 entries for reasons related to the above. Having 2 entries is enough when you initially get a new frame in draw_image() because then you'll have those two entries plus the new one for a total of 3 (the code relied on the oldest mpi implicitly staying reserved for the duration of the call even after usage count was decreased). However if you want to be able to reproduce the rendering outside draw_image(), relying on the explicitly reserved list only, then it needs to store 3 entries.
2009-09-18 15:27:55 +02:00
bool untimed; // non-interactive, don't do sleep calls in playloop
core/VO: Allow VO drivers to add/modify frames Add interfaces to allow VO drivers to add or remove frames from the video stream and to alter timestamps. Currently this functionality only works with in correct-pts mode. Use the new functionality in vo_vdpau to properly support frame-adding deinterlace modes. Frames added by the VDPAU deinterlacing code are now properly timed. Before every second frame was always shown immediately (probably next monitor refresh) after the previous one, even if you were watching things in slow motion, and framestepping didn't stop at them at all. When seeking the deinterlace algorithm is no longer fed a mix of frames from old and new positions. As a side effect of the changes a problem with resize events was also fixed. Resizing calls video_to_output_surface() to render the frame at the new resolution, but before this function also changed the list of history frames, so resizing could give an image different from the original one, and also corrupt next frames due to them seeing the wrong history. Now the function has no such side effects. There are more resize-related problems though that will be fixed in a later commit. The deint_mpi[] list of reserved frames is increased from 2 to 3 entries for reasons related to the above. Having 2 entries is enough when you initially get a new frame in draw_image() because then you'll have those two entries plus the new one for a total of 3 (the code relied on the oldest mpi implicitly staying reserved for the duration of the call even after usage count was decreased). However if you want to be able to reproduce the rendering outside draw_image(), relying on the explicitly reserved list only, then it needs to store 3 entries.
2009-09-18 15:27:55 +02:00
bool frame_loaded; // Is there a next frame the VO could flip to?
struct mp_image *waiting_mpi;
core/VO: Allow VO drivers to add/modify frames Add interfaces to allow VO drivers to add or remove frames from the video stream and to alter timestamps. Currently this functionality only works with in correct-pts mode. Use the new functionality in vo_vdpau to properly support frame-adding deinterlace modes. Frames added by the VDPAU deinterlacing code are now properly timed. Before every second frame was always shown immediately (probably next monitor refresh) after the previous one, even if you were watching things in slow motion, and framestepping didn't stop at them at all. When seeking the deinterlace algorithm is no longer fed a mix of frames from old and new positions. As a side effect of the changes a problem with resize events was also fixed. Resizing calls video_to_output_surface() to render the frame at the new resolution, but before this function also changed the list of history frames, so resizing could give an image different from the original one, and also corrupt next frames due to them seeing the wrong history. Now the function has no such side effects. There are more resize-related problems though that will be fixed in a later commit. The deint_mpi[] list of reserved frames is increased from 2 to 3 entries for reasons related to the above. Having 2 entries is enough when you initially get a new frame in draw_image() because then you'll have those two entries plus the new one for a total of 3 (the code relied on the oldest mpi implicitly staying reserved for the duration of the call even after usage count was decreased). However if you want to be able to reproduce the rendering outside draw_image(), relying on the explicitly reserved list only, then it needs to store 3 entries.
2009-09-18 15:27:55 +02:00
double next_pts; // pts value of the next frame if any
double next_pts2; // optional pts of frame after that
bool want_redraw; // visible frame wrong (window resize), needs refresh
bool redrawing; // between redrawing frame and flipping it
bool hasframe; // >= 1 frame has been drawn, so redraw is possible
double wakeup_period; // if > 0, this sets the maximum wakeup period for event polling
core/VO: Allow VO drivers to add/modify frames Add interfaces to allow VO drivers to add or remove frames from the video stream and to alter timestamps. Currently this functionality only works with in correct-pts mode. Use the new functionality in vo_vdpau to properly support frame-adding deinterlace modes. Frames added by the VDPAU deinterlacing code are now properly timed. Before every second frame was always shown immediately (probably next monitor refresh) after the previous one, even if you were watching things in slow motion, and framestepping didn't stop at them at all. When seeking the deinterlace algorithm is no longer fed a mix of frames from old and new positions. As a side effect of the changes a problem with resize events was also fixed. Resizing calls video_to_output_surface() to render the frame at the new resolution, but before this function also changed the list of history frames, so resizing could give an image different from the original one, and also corrupt next frames due to them seeing the wrong history. Now the function has no such side effects. There are more resize-related problems though that will be fixed in a later commit. The deint_mpi[] list of reserved frames is increased from 2 to 3 entries for reasons related to the above. Having 2 entries is enough when you initially get a new frame in draw_image() because then you'll have those two entries plus the new one for a total of 3 (the code relied on the oldest mpi implicitly staying reserved for the duration of the call even after usage count was decreased). However if you want to be able to reproduce the rendering outside draw_image(), relying on the explicitly reserved list only, then it needs to store 3 entries.
2009-09-18 15:27:55 +02:00
double flip_queue_offset; // queue flip events at most this much in advance
const struct vo_driver *driver;
void *priv;
struct mp_vo_opts *opts;
struct vo_x11_state *x11;
struct vo_w32_state *w32;
struct vo_cocoa_state *cocoa;
struct vo_wayland_state *wayland;
struct mp_fifo *key_fifo;
struct encode_lavc_context *encode_lavc_ctx;
struct input_ctx *input_ctx;
int event_fd; // check_events() should be called when this has input
int registered_fd; // set to event_fd when registered in input system
2008-04-20 23:37:12 +02:00
// requested position/resolution (usually window position/window size)
int dx;
int dy;
int dwidth;
int dheight;
int xinerama_x;
int xinerama_y;
struct aspect_data {
float monitor_par; // out of screen size or from options
int orgw; // real width
int orgh; // real height
int prew; // prescaled width
int preh; // prescaled height
float par; // pixel aspect ratio out of orgw/orgh and prew/preh
float asp; // final video display aspect
} aspdat;
char *window_title;
};
struct vo *init_best_video_out(struct mp_vo_opts *opts,
struct mp_fifo *key_fifo,
struct input_ctx *input_ctx,
struct encode_lavc_context *encode_lavc_ctx);
int vo_config(struct vo *vo, uint32_t width, uint32_t height,
uint32_t d_width, uint32_t d_height, uint32_t flags,
uint32_t format);
void list_video_out(void);
int vo_control(struct vo *vo, uint32_t request, void *data);
void vo_queue_image(struct vo *vo, struct mp_image *mpi);
int vo_redraw_frame(struct vo *vo);
bool vo_get_want_redraw(struct vo *vo);
core/VO: Allow VO drivers to add/modify frames Add interfaces to allow VO drivers to add or remove frames from the video stream and to alter timestamps. Currently this functionality only works with in correct-pts mode. Use the new functionality in vo_vdpau to properly support frame-adding deinterlace modes. Frames added by the VDPAU deinterlacing code are now properly timed. Before every second frame was always shown immediately (probably next monitor refresh) after the previous one, even if you were watching things in slow motion, and framestepping didn't stop at them at all. When seeking the deinterlace algorithm is no longer fed a mix of frames from old and new positions. As a side effect of the changes a problem with resize events was also fixed. Resizing calls video_to_output_surface() to render the frame at the new resolution, but before this function also changed the list of history frames, so resizing could give an image different from the original one, and also corrupt next frames due to them seeing the wrong history. Now the function has no such side effects. There are more resize-related problems though that will be fixed in a later commit. The deint_mpi[] list of reserved frames is increased from 2 to 3 entries for reasons related to the above. Having 2 entries is enough when you initially get a new frame in draw_image() because then you'll have those two entries plus the new one for a total of 3 (the code relied on the oldest mpi implicitly staying reserved for the duration of the call even after usage count was decreased). However if you want to be able to reproduce the rendering outside draw_image(), relying on the explicitly reserved list only, then it needs to store 3 entries.
2009-09-18 15:27:55 +02:00
int vo_get_buffered_frame(struct vo *vo, bool eof);
void vo_skip_frame(struct vo *vo);
void vo_new_frame_imminent(struct vo *vo);
void vo_draw_osd(struct vo *vo, struct osd_state *osd);
Implement vsync-aware frame timing for VDPAU Main things added are custom frame dropping for VDPAU to work around the display FPS limit, frame timing adjustment to avoid jitter when video frame times keep falling near vsyncs, and use of VDPAU's timing feature to keep one future frame queued in advance. NVIDIA's VDPAU implementation refuses to change the displayed frame more than once per vsync. This set a limit on how much video could be sped up, and caused problems for nearly all videos on low-FPS video projectors (playing 24 FPS video on a 24 FPS projector would not work reliably as MPlayer may need to slightly speed up the video for AV sync). This commit adds a framedrop mechanism that drops some frames so that no more than one is sent for display per vsync. The code tries to select the dropped frames smartly, selecting the best one to show for each vsync. Because of the timing features needed the drop functionality currently does not work if the correct-pts option is disabled. The code also adjusts frame timing slightly to avoid jitter. If you for example play 24 FPS video content on a 72 FPS display then normally a frame would be shown for 3 vsyncs, but if the frame times happen to fall near vsyncs and change between just before and just after then there could be frames alternating between 2 and 4 vsyncs. The code changes frame timing by up to one quarter vsync interval to avoid this. The above functionality depends on having reliable vsync timing information available. The display refresh rate is not directly provided by the VDPAU API. The current code uses information from the XF86VidMode extension if available; I'm not sure how common cases where that is inaccurate are. The refresh rate can be specified manually if necessary. After the changes in this commit MPlayer now always tries to keep one frame queued for future display using VDPAU's internal timing mechanism (however no more than 50 ms to the future). This should make video playback somewhat more robust against timing inaccuracies caused by system load.
2009-11-15 03:39:22 +01:00
void vo_flip_page(struct vo *vo, unsigned int pts_us, int duration);
void vo_check_events(struct vo *vo);
core/VO: Allow VO drivers to add/modify frames Add interfaces to allow VO drivers to add or remove frames from the video stream and to alter timestamps. Currently this functionality only works with in correct-pts mode. Use the new functionality in vo_vdpau to properly support frame-adding deinterlace modes. Frames added by the VDPAU deinterlacing code are now properly timed. Before every second frame was always shown immediately (probably next monitor refresh) after the previous one, even if you were watching things in slow motion, and framestepping didn't stop at them at all. When seeking the deinterlace algorithm is no longer fed a mix of frames from old and new positions. As a side effect of the changes a problem with resize events was also fixed. Resizing calls video_to_output_surface() to render the frame at the new resolution, but before this function also changed the list of history frames, so resizing could give an image different from the original one, and also corrupt next frames due to them seeing the wrong history. Now the function has no such side effects. There are more resize-related problems though that will be fixed in a later commit. The deint_mpi[] list of reserved frames is increased from 2 to 3 entries for reasons related to the above. Having 2 entries is enough when you initially get a new frame in draw_image() because then you'll have those two entries plus the new one for a total of 3 (the code relied on the oldest mpi implicitly staying reserved for the duration of the call even after usage count was decreased). However if you want to be able to reproduce the rendering outside draw_image(), relying on the explicitly reserved list only, then it needs to store 3 entries.
2009-09-18 15:27:55 +02:00
void vo_seek_reset(struct vo *vo);
void vo_destroy(struct vo *vo);
const char *vo_get_window_title(struct vo *vo);
// NULL terminated array of all drivers
extern const struct vo_driver *video_out_drivers[];
struct mp_keymap {
int from;
int to;
};
int lookup_keymap_table(const struct mp_keymap *map, int key);
2010-04-26 18:22:56 +02:00
void vo_mouse_movement(struct vo *vo, int posx, int posy);
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);
#endif /* MPLAYER_VIDEO_OUT_H */