1
mirror of https://github.com/mpv-player/mpv synced 2024-10-26 07:22:17 +02:00
mpv/libvo/video_out.c

513 lines
15 KiB
C
Raw Normal View History

/*
* libvo common functions, variables used by many/all drivers.
*
* 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.
*/
#include <stdio.h>
#include <stdlib.h>
#include <string.h>
#include <assert.h>
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
#include <stdbool.h>
#include <unistd.h>
//#include <sys/mman.h>
#include "config.h"
2008-04-19 06:04:55 +02:00
#include "options.h"
#include "talloc.h"
#include "bstr.h"
#include "video_out.h"
#include "aspect.h"
#include "geometry.h"
2010-04-26 18:22:56 +02:00
#include "input/input.h"
#include "mp_fifo.h"
#include "m_config.h"
#include "mp_msg.h"
#include "osdep/shmem.h"
#ifdef CONFIG_X11
#include "x11_common.h"
#endif
int xinerama_screen = -1;
int xinerama_x;
int xinerama_y;
int vo_nomouse_input = 0;
int vo_grabpointer = 1;
int vo_vsync = 1;
int vo_fs = 0;
int vo_fsmode = 0;
float vo_panscan = 0.0f;
int vo_adapter_num=0;
int vo_refresh_rate=0;
int vo_keepaspect=1;
int vo_rootwin=0;
int vo_border=1;
int64_t WinID = -1;
int vo_pts=0; // for hw decoding
float vo_fps=0;
int vo_colorkey = 0x0000ff00; // default colorkey is green
// (0xff000000 means that colorkey has been disabled)
//
// Externally visible list of all vo drivers
//
extern struct vo_driver video_out_x11;
extern struct vo_driver video_out_vdpau;
extern struct vo_driver video_out_xv;
extern struct vo_driver video_out_opengl;
extern struct vo_driver video_out_opengl_hq;
extern struct vo_driver video_out_opengl_old;
extern struct vo_driver video_out_null;
extern struct vo_driver video_out_image;
extern struct vo_driver video_out_lavc;
extern struct vo_driver video_out_caca;
2008-11-22 18:16:43 +01:00
extern struct vo_driver video_out_direct3d;
extern struct vo_driver video_out_direct3d_shaders;
2009-05-08 22:50:26 +02:00
extern struct vo_driver video_out_corevideo;
const struct vo_driver *video_out_drivers[] =
{
#ifdef CONFIG_DIRECT3D
&video_out_direct3d_shaders,
&video_out_direct3d,
#endif
#ifdef CONFIG_GL_COCOA
&video_out_opengl,
&video_out_opengl_old,
#endif
#ifdef CONFIG_COREVIDEO
&video_out_corevideo,
#endif
#if CONFIG_VDPAU
&video_out_vdpau,
#endif
#ifdef CONFIG_XV
&video_out_xv,
#endif
#ifdef CONFIG_GL
#if !defined CONFIG_GL_COCOA
&video_out_opengl,
&video_out_opengl_old,
#endif
#endif
#ifdef CONFIG_X11
&video_out_x11,
#endif
#ifdef CONFIG_CACA
&video_out_caca,
#endif
&video_out_null,
// should not be auto-selected
&video_out_image,
#ifdef CONFIG_ENCODING
&video_out_lavc,
#endif
#ifdef CONFIG_GL
&video_out_opengl_hq,
#endif
NULL
};
static int vo_preinit(struct vo *vo, char *arg)
{
if (vo->driver->priv_size) {
vo->priv = talloc_zero_size(vo, vo->driver->priv_size);
if (vo->driver->priv_defaults)
memcpy(vo->priv, vo->driver->priv_defaults, vo->driver->priv_size);
}
if (vo->driver->options) {
struct m_config *cfg = m_config_simple(vo->priv);
talloc_steal(vo->priv, cfg);
m_config_register_options(cfg, vo->driver->options);
char n[50];
int l = snprintf(n, sizeof(n), "vo/%s", vo->driver->info->short_name);
assert(l < sizeof(n));
mplayer: turn playtree into a list, and change per-file option handling Summary: - There is no playtree anymore. It's reduced to a simple list. - Options are now always global. You can still have per-file options, but these are optional and require special syntax. - The slave command pt_step has been removed, and playlist_next and playlist_prev added. (See etc/input.conf changes.) This is a user visible incompatible change, and will break slave-mode applications. - The pt_clear slave command is renamed to playlist_clear. - Playtree entries could have multiple files. This is not the case anymore, and playlist entries have always exactly one entry. Whenever something adds more than one file (like ASX playlists or dvd:// or dvdnav:// on the command line), all files are added as separate playlist entries. Note that some of the changes are quite deep and violent. Expect regressions. The playlist parsing code in particular is of low quality. I didn't try to improve it, and merely spent to least effort necessary to keep it somehow working. (Especially ASX playlist handling.) The playtree code was complicated and bloated. It was also barely used. Most users don't even know that mplayer manages the playlist as tree, or how to use it. The most obscure features was probably specifying a tree on command line (with '{' and '}' to create/close tree nodes). It filled the player code with complexity and confused users with weird slave commands like pt_up. Replace the playtree with a simple flat playlist. Playlist parsers that actually return trees are changed to append all files to the playlist pre-order. It used to be the responsibility of the playtree code to change per-file config options. Now this is done by the player core, and the playlist code is free of such details. Options are not per-file by default anymore. This was a very obscure and complicated feature that confused even experienced users. Consider the following command line: mplayer file1.mkv file2.mkv --no-audio file3.mkv This will disable the audio for file2.mkv only, because options are per-file by default. To make the option affect all files, you're supposed to put it before the first file. This is bad, because normally you don't need per-file options. They are very rarely needed, and the only reasonable use cases I can imagine are use of the encode backend (mplayer encode branch), or for debugging. The normal use case is made harder, and the feature is perceived as bug. Even worse, correct usage is hard to explain for users. Make all options global by default. The position of an option isn't significant anymore (except for options that compensate each other, consider --shuffle --no-shuffle). One other important change is that no options are reset anymore if a new file is started. If you change settings with slave mode commands, they will not be changed by playing a new file. (Exceptions include settings that are too file specific, like audio/subtitle stream selection.) There is still some need for per-file options. Debugging and encoding are use cases that profit from per-file options. Per-file profiles (as well as per-protocol and per-VO/AO options) need the implementation related mechanisms to backup and restore options when the playback file changes. Simplify the save-slot stuff, which is possible because there is no hierarchical play tree anymore. Now there's a simple backup field. Add a way to specify per-file options on command line. Example: mplayer f1.mkv -o0 --{ -o1 f2.mkv -o2 f3.mkv --} f4.mkv -o3 will have the following options per file set: f1.mkv, f4.mkv: -o0 -o3 f2.mkv, f3.mkv: -o0 -o3 -o1 -o2 The options --{ and --} start and end per-file options. All files inside the { } will be affected by the options equally (similar to how global options and multiple files are handled). When playback of a file starts, the per-file options are set according to the command line. When playback ends, the per-file options are restored to the values when playback started.
2012-07-31 21:33:26 +02:00
int r = m_config_parse_suboptions(cfg, n, arg);
if (r < 0)
return r;
}
return vo->driver->preinit(vo, arg);
}
int vo_control(struct vo *vo, uint32_t request, void *data)
{
return vo->driver->control(vo, request, data);
}
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
// Return -1 if driver appears not to support a draw_image interface,
// 0 otherwise (whether the driver actually drew something or not).
int vo_draw_image(struct vo *vo, struct mp_image *mpi, double pts)
{
if (!vo->config_ok)
return 0;
if (vo->driver->buffer_frames) {
vo->driver->draw_image(vo, mpi, pts);
return 0;
}
vo->frame_loaded = true;
vo->next_pts = pts;
// Guaranteed to support at least DRAW_IMAGE later
if (vo->driver->is_new) {
vo->waiting_mpi = mpi;
return 0;
}
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
if (vo_control(vo, VOCTRL_DRAW_IMAGE, mpi) == VO_NOTIMPL)
return -1;
return 0;
}
int vo_redraw_frame(struct vo *vo)
{
if (!vo->config_ok || !vo->hasframe)
return -1;
if (vo_control(vo, VOCTRL_REDRAW_FRAME, NULL) == true) {
vo->redrawing = true;
return 0;
}
return -1;
}
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)
{
if (!vo->config_ok)
return -1;
if (vo->frame_loaded)
return 0;
if (!vo->driver->buffer_frames)
return -1;
vo->driver->get_buffered_frame(vo, eof);
return vo->frame_loaded ? 0 : -1;
}
void vo_skip_frame(struct vo *vo)
{
vo_control(vo, VOCTRL_SKIPFRAME, NULL);
vo->frame_loaded = false;
}
int vo_draw_slice(struct vo *vo, uint8_t *src[], int stride[], int w, int h, int x, int y)
{
return vo->driver->draw_slice(vo, src, stride, w, h, x, y);
}
void vo_new_frame_imminent(struct vo *vo)
{
if (!vo->driver->is_new)
return;
if (vo->driver->buffer_frames)
vo_control(vo, VOCTRL_NEWFRAME, NULL);
else {
vo_control(vo, VOCTRL_DRAW_IMAGE, vo->waiting_mpi);
vo->waiting_mpi = NULL;
}
}
void vo_draw_osd(struct vo *vo, struct osd_state *osd)
{
if (!vo->config_ok)
return;
vo->driver->draw_osd(vo, 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)
{
if (!vo->config_ok)
return;
if (!vo->redrawing) {
vo->frame_loaded = false;
vo->next_pts = MP_NOPTS_VALUE;
}
vo->want_redraw = false;
vo->redrawing = false;
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
if (vo->driver->flip_page_timed)
vo->driver->flip_page_timed(vo, pts_us, duration);
else
vo->driver->flip_page(vo);
vo->hasframe = true;
}
void vo_check_events(struct vo *vo)
{
if (!vo->config_ok) {
if (vo->registered_fd != -1)
mp_input_rm_key_fd(vo->input_ctx, vo->registered_fd);
vo->registered_fd = -1;
return;
}
vo->driver->check_events(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)
{
vo_control(vo, VOCTRL_RESET, NULL);
vo->frame_loaded = false;
vo->hasframe = false;
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_destroy(struct vo *vo)
{
if (vo->registered_fd != -1)
mp_input_rm_key_fd(vo->input_ctx, vo->registered_fd);
vo->driver->uninit(vo);
talloc_free(vo);
}
void list_video_out(void)
{
int i = 0;
mp_tmsg(MSGT_CPLAYER, MSGL_INFO, "Available video output drivers:\n");
mp_msg(MSGT_IDENTIFY, MSGL_INFO, "ID_VIDEO_OUTPUTS\n");
while (video_out_drivers[i]) {
const vo_info_t *info = video_out_drivers[i++]->info;
mp_msg(MSGT_GLOBAL, MSGL_INFO,"\t%s\t%s\n", info->short_name, info->name);
}
mp_msg(MSGT_GLOBAL, MSGL_INFO,"\n");
}
static void replace_legacy_vo_name(bstr *name)
{
bstr new = *name;
if (bstr_equals0(*name, "gl"))
new = bstr0("opengl");
if (bstr_equals0(*name, "gl3"))
new = bstr0("opengl-hq");
if (!bstr_equals(*name, new)) {
mp_tmsg(MSGT_CPLAYER, MSGL_ERR, "VO driver '%.*s' has been replaced "
"with '%.*s'!\n", BSTR_P(*name), BSTR_P(new));
}
*name = new;
}
struct vo *init_best_video_out(struct MPOpts *opts,
struct mp_fifo *key_fifo,
struct input_ctx *input_ctx,
struct encode_lavc_context *encode_lavc_ctx)
{
2008-04-19 06:04:55 +02:00
char **vo_list = opts->video_driver_list;
int i;
struct vo *vo = talloc_ptrtype(NULL, vo);
struct vo initial_values = {
.opts = opts,
.key_fifo = key_fifo,
.encode_lavc_ctx = encode_lavc_ctx,
.input_ctx = input_ctx,
.event_fd = -1,
.registered_fd = -1,
};
// first try the preferred drivers, with their optional subdevice param:
if (vo_list && vo_list[0])
while (vo_list[0][0]) {
char *arg = vo_list[0];
bstr name = bstr0(arg);
char *params = strchr(arg, ':');
if (params) {
name = bstr_splice(name, 0, params - arg);
params++;
}
replace_legacy_vo_name(&name);
for (i = 0; video_out_drivers[i]; i++) {
const struct vo_driver *video_driver = video_out_drivers[i];
const vo_info_t *info = video_driver->info;
if (bstr_equals0(name, info->short_name)) {
// name matches, try it
*vo = initial_values;
vo->driver = video_driver;
if (!vo_preinit(vo, params))
return vo; // success!
talloc_free_children(vo);
}
}
// continue...
++vo_list;
if (!(vo_list[0])) {
talloc_free(vo);
return NULL; // do NOT fallback to others
}
}
// now try the rest...
for (i = 0; video_out_drivers[i]; i++) {
const struct vo_driver *video_driver = video_out_drivers[i];
*vo = initial_values;
vo->driver = video_driver;
if (!vo_preinit(vo, NULL))
return vo; // success!
talloc_free_children(vo);
}
talloc_free(vo);
return NULL;
}
static int event_fd_callback(void *ctx, int fd)
{
struct vo *vo = ctx;
vo_check_events(vo);
input: rework event reading and command queuing Rework much of the logic related to reading from event sources and queuing commands. The two biggest architecture changes are: - The code buffering keycodes in mp_fifo.c is gone. Instead key input is now immediately fed to input.c and interpreted as commands, and then the commands are buffered instead. - mp_input_get_cmd() now always tries to read every available event from every event source and convert them to (buffered) commands. Before it would only process new events until one new command became available. Some relevant behavior changes: - Before commands could be lost when stream code called mp_input_check_interrupt() which read commands (to see if they were of types that triggered aborts during slow IO tasks) and then threw them away. This was especially an issue if cache was enabled and slow to read. Fixed - now it's possible to check whether there are queued commands which will abort playback of the current file without throwing other commands away. - mp_input_check_interrupt() now prints a message if it returns true. This is especially useful because the failures caused by aborted stream reads can trigger error messages from other code that was doing the read; the new message makes it more obvious what the cause of the subsequent error messages is. - It's now possible to again avoid making stdin non-blocking (which caused some issues) without reintroducing extra latency. The change will be done in a subsequent commit. - Event sources that do not support select() should now have somewhat lower latency in certain situations as they will be checked both before and after select()/sleep in input reading; before the sleep always happened first even if such sources already had queued input. Before the key fifo was also handled in this manner (first key triggered select, but if multiple were read then rest could be delayed; however in most cases this didn't add latency in practice as after central code started doing command handling it queried for further commands with a max sleep time of 0). - Key fifo limiting is more accurate now: it now counts actual commands intead of keycodes, and all queued keys are read immediately from input devices so they can be counted correctly. - Since keypresses are now interpreted immediately, commands which change keybindings will no longer affect following keypresses that have already been read before the command is executed. This should not be an issue in practice with current keybinding behavior.
2011-07-17 03:47:50 +02:00
return MP_INPUT_NOTHING;
}
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)
{
struct MPOpts *opts = vo->opts;
panscan_init(vo);
aspect_save_orig(vo, width, height);
aspect_save_prescale(vo, d_width, d_height);
if (vo_control(vo, VOCTRL_UPDATE_SCREENINFO, NULL) == VO_TRUE) {
aspect(vo, &d_width, &d_height, A_NOZOOM);
vo->dx = (int)(opts->vo_screenwidth - d_width) / 2;
vo->dy = (int)(opts->vo_screenheight - d_height) / 2;
geometry(&vo->dx, &vo->dy, &d_width, &d_height,
opts->vo_screenwidth, opts->vo_screenheight);
2010-06-05 22:23:18 +02:00
geometry_xy_changed |= xinerama_screen >= 0;
vo->dx += xinerama_x;
vo->dy += xinerama_y;
vo->dwidth = d_width;
vo->dheight = d_height;
}
int ret = vo->driver->config(vo, width, height, d_width, d_height, flags,
format);
vo->config_ok = (ret == 0);
vo->config_count += vo->config_ok;
if (vo->registered_fd == -1 && vo->event_fd != -1 && vo->config_ok) {
mp_input_add_key_fd(vo->input_ctx, vo->event_fd, 1, event_fd_callback,
NULL, vo);
vo->registered_fd = vo->event_fd;
}
vo->frame_loaded = false;
vo->waiting_mpi = NULL;
vo->redrawing = false;
vo->hasframe = false;
return ret;
}
/**
* \brief lookup an integer in a table, table must have 0 as the last key
* \param key key to search for
* \result translation corresponding to key or "to" value of last mapping
* if not found.
*/
int lookup_keymap_table(const struct mp_keymap *map, int key) {
while (map->from && map->from != key) map++;
return map->to;
}
/**
* \brief helper function for the kind of panscan-scaling that needs a source
* and destination rectangle like Direct3D and VDPAU
*/
static void src_dst_split_scaling(int src_size, int dst_size, int scaled_src_size,
int *src_start, int *src_end, int *dst_start, int *dst_end) {
if (scaled_src_size > dst_size) {
int border = src_size * (scaled_src_size - dst_size) / scaled_src_size;
// round to a multiple of 2, this is at least needed for vo_direct3d and ATI cards
border = (border / 2 + 1) & ~1;
*src_start = border;
*src_end = src_size - border;
*dst_start = 0;
*dst_end = dst_size;
} else {
*src_start = 0;
*src_end = src_size;
*dst_start = (dst_size - scaled_src_size) / 2;
*dst_end = *dst_start + scaled_src_size;
}
}
/**
* Calculate the appropriate source and destination rectangle to
* get a correctly scaled picture, including pan-scan.
* Can be extended to take future cropping support into account.
*
* \param crop specifies the cropping border size in the left, right, top and bottom members, may be NULL
* \param borders the border values as e.g. EOSD (ASS) and properly placed DVD highlight support requires,
* may be NULL and only left and top are currently valid.
*/
void calc_src_dst_rects(struct vo *vo, int src_width, int src_height,
struct vo_rect *src, struct vo_rect *dst,
struct vo_rect *borders, const struct vo_rect *crop)
{
static const struct vo_rect no_crop = {0, 0, 0, 0, 0, 0};
int scaled_width = 0;
int scaled_height = 0;
if (!crop) crop = &no_crop;
src_width -= crop->left + crop->right;
src_height -= crop->top + crop->bottom;
if (src_width < 2) src_width = 2;
if (src_height < 2) src_height = 2;
2009-02-13 02:52:51 +01:00
dst->left = 0; dst->right = vo->dwidth;
dst->top = 0; dst->bottom = vo->dheight;
src->left = 0; src->right = src_width;
src->top = 0; src->bottom = src_height;
if (borders) {
borders->left = 0; borders->top = 0;
}
if (aspect_scaling()) {
2009-09-04 18:49:35 +02:00
aspect(vo, &scaled_width, &scaled_height, A_WINZOOM);
panscan_calc_windowed(vo);
2009-02-13 02:52:51 +01:00
scaled_width += vo->panscan_x;
scaled_height += vo->panscan_y;
if (borders) {
borders->left = (vo->dwidth - scaled_width ) / 2;
borders->top = (vo->dheight - scaled_height) / 2;
}
2009-02-13 02:52:51 +01:00
src_dst_split_scaling(src_width, vo->dwidth, scaled_width,
&src->left, &src->right, &dst->left, &dst->right);
2009-02-13 02:52:51 +01:00
src_dst_split_scaling(src_height, vo->dheight, scaled_height,
&src->top, &src->bottom, &dst->top, &dst->bottom);
}
src->left += crop->left; src->right += crop->left;
src->top += crop->top; src->bottom += crop->top;
src->width = src->right - src->left;
src->height = src->bottom - src->top;
dst->width = dst->right - dst->left;
dst->height = dst->bottom - dst->top;
}
// Return the window title the VO should set. Always returns a null terminated
// string. The string is valid until frontend code is invoked again. Copy it if
// you need to keep the string for an extended period of time.
const char *vo_get_window_title(struct vo *vo)
{
if (!vo->window_title)
vo->window_title = talloc_strdup(vo, "");
return vo->window_title;
}
/**
* Generates a mouse movement message if those are enable and sends it
* to the "main" MPlayer.
*
* \param posx new x position of mouse
* \param posy new y position of mouse
*/
2010-04-26 18:22:56 +02:00
void vo_mouse_movement(struct vo *vo, int posx, int posy)
{
char cmd_str[40];
if (!enable_mouse_movements)
return;
snprintf(cmd_str, sizeof(cmd_str), "set_mouse_pos %i %i", posx, posy);
mp_input_queue_cmd(vo->input_ctx, mp_input_parse_cmd(bstr0(cmd_str), ""));
}