github/mpv
1
Fork 0
mirror of https://github.com/mpv-player/mpv synced 2024-10-30 04:46:41 +01:00
Code Releases Activity
203be26588
mpv/video/out/vo_vdpau.c

1253 lines
44 KiB
C
Raw Normal View History

Add support for VDPAU video out, including hardware decoding. git-svn-id: svn://svn.mplayerhq.hu/mplayer/trunk@28617 b3059339-0415-0410-9bf9-f77b7e298cf2
2009-02-16 21:58:13 +01:00
/*
* VDPAU video output driver
*
video/out: remove useless info struct and redundant fields The author and comment fields were printed only in -v mode.
2013-10-23 19:06:14 +02:00
* Copyright (C) 2008 NVIDIA (Rajib Mahapatra <rmahapatra@nvidia.com>)
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
* Copyright (C) 2009 Uoti Urpala
Add support for VDPAU video out, including hardware decoding. git-svn-id: svn://svn.mplayerhq.hu/mplayer/trunk@28617 b3059339-0415-0410-9bf9-f77b7e298cf2
2009-02-16 21:58:13 +01:00
*
* 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.
*/
vo_vdpau.c: cosmetics
2009-05-09 17:08:30 +02:00
/*
vdpau: split off decoder parts, use "new" libavcodec vdpau hwaccel API Move the decoder parts from vo_vdpau.c to a new file vdpau_old.c. This file is named so because because it's written against the "old" libavcodec vdpau pseudo-decoder (e.g. "h264_vdpau"). Add support for the "new" libavcodec vdpau support. This was recently added and replaces the "old" vdpau parts. (In fact, Libav is about to deprecate and remove the "old" API without deprecation grace period, so we have to support it now. Moreover, there will probably be no Libav release which supports both, so the transition is even less smooth than we could hope, and we have to support both the old and new API.) Whether the old or new API is used is checked by a configure test: if the new API is found, it is used, otherwise the old API is assumed. Some details might be handled differently. Especially display preemption is a bit problematic with the "new" libavcodec vdpau support: it wants to keep a pointer to a specific vdpau API function (which can be driver specific, because preemption might switch drivers). Also, surface IDs are now directly stored in AVFrames (and mp_images), so they can't be forced to VDP_INVALID_HANDLE on preemption. (This changes even with older libavcodec versions, because mp_image always uses the newer representation to make vo_vdpau.c simpler.) Decoder initialization in the new code tries to deal with codec profiles, while the old code always uses the highest profile per codec. Surface allocation changes. Since the decoder won't call config() in vo_vdpau.c on video size change anymore, we allow allocating surfaces of arbitrary size instead of locking it to what the VO was configured. The non-hwdec code also has slightly different allocation behavior now. Enabling the old vdpau special decoders via e.g. --vd=lavc:h264_vdpau doesn't work anymore (a warning suggesting the --hwdec option is printed instead).
2013-07-28 01:49:45 +02:00
* Actual decoding is done in video/decode/vdpau.c
Add support for VDPAU video out, including hardware decoding. git-svn-id: svn://svn.mplayerhq.hu/mplayer/trunk@28617 b3059339-0415-0410-9bf9-f77b7e298cf2
2009-02-16 21:58:13 +01:00
*/
#include <stdio.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 <stdlib.h>
vo_vdpau: Move all remaining static/global variables to context
2009-05-06 22:49:51 +02:00
#include <stdint.h>
#include <stdbool.h>
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
#include <limits.h>
vo_vdpau: split bitmap packing code into a separate file Split the vo_vdpau code that calculates how to pack all subtitle bitmaps into a larger surface into a separate file. This will allow using it in other VOs. Conflicts: Makefile libvo/vo_vdpau.c Note: this commit does the same as an earlier commit by me (4010dd0b1a27e3996). My commit added the vo_vdpau packer code as eosd_packer.c, while this commit by uau uses bitmap_packer.c. Since bitmap_packer.c has a different interface, and because there are more commits changing OSD rendering coming, I will pick uau's version. However, vo_gl, vo_gl3 and vo_direct3d are still using eosd_packer.c, so to make the transition easier, don't delete eosd_packer.c yet.
2012-08-26 18:00:26 +02:00
#include <assert.h>
#include <libavutil/common.h>
Add support for VDPAU video out, including hardware decoding. git-svn-id: svn://svn.mplayerhq.hu/mplayer/trunk@28617 b3059339-0415-0410-9bf9-f77b7e298cf2
2009-02-16 21:58:13 +01:00
#include "config.h"
vdpau: split off decoder parts, use "new" libavcodec vdpau hwaccel API Move the decoder parts from vo_vdpau.c to a new file vdpau_old.c. This file is named so because because it's written against the "old" libavcodec vdpau pseudo-decoder (e.g. "h264_vdpau"). Add support for the "new" libavcodec vdpau support. This was recently added and replaces the "old" vdpau parts. (In fact, Libav is about to deprecate and remove the "old" API without deprecation grace period, so we have to support it now. Moreover, there will probably be no Libav release which supports both, so the transition is even less smooth than we could hope, and we have to support both the old and new API.) Whether the old or new API is used is checked by a configure test: if the new API is found, it is used, otherwise the old API is assumed. Some details might be handled differently. Especially display preemption is a bit problematic with the "new" libavcodec vdpau support: it wants to keep a pointer to a specific vdpau API function (which can be driver specific, because preemption might switch drivers). Also, surface IDs are now directly stored in AVFrames (and mp_images), so they can't be forced to VDP_INVALID_HANDLE on preemption. (This changes even with older libavcodec versions, because mp_image always uses the newer representation to make vo_vdpau.c simpler.) Decoder initialization in the new code tries to deal with codec profiles, while the old code always uses the highest profile per codec. Surface allocation changes. Since the decoder won't call config() in vo_vdpau.c on video size change anymore, we allow allocating surfaces of arbitrary size instead of locking it to what the VO was configured. The non-hwdec code also has slightly different allocation behavior now. Enabling the old vdpau special decoders via e.g. --vd=lavc:h264_vdpau doesn't work anymore (a warning suggesting the --hwdec option is printed instead).
2013-07-28 01:49:45 +02:00
#include "video/vdpau.h"
vo_vdpau: support vf_vdpaupp This is slightly incomplete: the mixer options, such as sharpen and especially deinterlacing, are ignored. This also breaks automatic enabling of interlacing with 'D' or --deinterlace. These issues will be fixed later in the following commits. Note that we keep all the custom vdpau queue stuff. This will also be simplified later.
2014-04-29 15:11:44 +02:00
#include "video/vdpau_mixer.h"
video: move struct mp_hwdec_info into its own header file This means most code accessing this struct must now include hwdec.h instead of dec_video.h. I just put it into dec_video.h at first because I thought a separate file would be a waste, but it's more proper to do it this way, as there are too many files which include dec_video.h only to get the mp_hwdec_info definition.
2013-11-23 21:26:31 +01:00
#include "video/hwdec.h"
Split mpvcore/ into common/, misc/, bstr/
2013-12-17 02:39:45 +01:00
#include "common/msg.h"
Move options/config related files from mpvcore/ to options/ Since m_option.h and options.h are extremely often included, a lot of files have to be changed. Moving path.c/h to options/ is a bit questionable, but since this is mainly about access to config files (which are also handled in options/), it's probably ok.
2013-12-17 02:02:25 +01:00
#include "options/options.h"
vo_vdpau: Replace global function table with context variable
2009-05-06 20:04:37 +02:00
#include "talloc.h"
Rename directories, move files (step 2 of 2) Finish renaming directories and moving files. Adjust all include statements to make the previous commit compile. The two commits are separate, because git is bad at tracking renames and content changes at the same time. Also take this as an opportunity to remove the separation between "common" and "mplayer" sources in the Makefile. ("common" used to be shared between mplayer and mencoder.)
2012-11-09 01:06:43 +01:00
#include "vo.h"
Add support for VDPAU video out, including hardware decoding. git-svn-id: svn://svn.mplayerhq.hu/mplayer/trunk@28617 b3059339-0415-0410-9bf9-f77b7e298cf2
2009-02-16 21:58:13 +01:00
#include "x11_common.h"
Rename directories, move files (step 2 of 2) Finish renaming directories and moving files. Adjust all include statements to make the previous commit compile. The two commits are separate, because git is bad at tracking renames and content changes at the same time. Also take this as an opportunity to remove the separation between "common" and "mplayer" sources in the Makefile. ("common" used to be shared between mplayer and mencoder.)
2012-11-09 01:06:43 +01:00
#include "video/csputils.h"
Rename sub.c/.h to osd.c/.h This was way too misleading. osd.c merely calls the subtitle renderers, instead of actually dealing with subtitles.
2013-11-24 12:58:06 +01:00
#include "sub/osd.h"
Move options/config related files from mpvcore/ to options/ Since m_option.h and options.h are extremely often included, a lot of files have to be changed. Moving path.c/h to options/ is a bit questionable, but since this is mainly about access to config files (which are also handled in options/), it's probably ok.
2013-12-17 02:02:25 +01:00
#include "options/m_option.h"
Rename directories, move files (step 2 of 2) Finish renaming directories and moving files. Adjust all include statements to make the previous commit compile. The two commits are separate, because git is bad at tracking renames and content changes at the same time. Also take this as an opportunity to remove the separation between "common" and "mplayer" sources in the Makefile. ("common" used to be shared between mplayer and mencoder.)
2012-11-09 01:06:43 +01:00
#include "video/vfcap.h"
#include "video/mp_image.h"
vo_vdpau: Support recovering from VDPAU display preemption Add code to reinitialize all VDPAU objects if a display preemption condition occurs. Reinitializing them in the middle of playback will cause video corruption at least until the next keyframe when using hardware decoding, but decoding does seem to recover after a keyframe.
2009-09-07 01:02:24 +02:00
#include "osdep/timer.h"
vo_vdpau: split bitmap packing code into a separate file Split the vo_vdpau code that calculates how to pack all subtitle bitmaps into a larger surface into a separate file. This will allow using it in other VOs. Conflicts: Makefile libvo/vo_vdpau.c Note: this commit does the same as an earlier commit by me (4010dd0b1a27e3996). My commit added the vo_vdpau packer code as eosd_packer.c, while this commit by uau uses bitmap_packer.c. Since bitmap_packer.c has a different interface, and because there are more commits changing OSD rendering coming, I will pick uau's version. However, vo_gl, vo_gl3 and vo_direct3d are still using eosd_packer.c, so to make the transition easier, don't delete eosd_packer.c yet.
2012-08-26 18:00:26 +02:00
#include "bitmap_packer.h"
EOSD/ASS support for vo_vdpau.c Patch by Grigori G (greg <at> chown ath cx) with minor cosmetic changes by me. git-svn-id: svn://svn.mplayerhq.hu/mplayer/trunk@28710 b3059339-0415-0410-9bf9-f77b7e298cf2
2009-02-23 10:21:57 +01:00
vo_vdpau: document what WRAP_ADD does This wasn't necessarily clear.
2014-04-08 19:13:15 +02:00
// Returns x + a, but wrapped around to the range [0, m)
// a must be within [-m, m], x within [0, m)
vo_vdpau.c cosmetics: add WRAP_ADD macro The macro is meant to simplify the handling of some code dealing with circular buffers.
2010-05-06 03:46:10 +02:00
#define WRAP_ADD(x, a, m) ((a) < 0 \
? ((x)+(a)+(m) < (m) ? (x)+(a)+(m) : (x)+(a)) \
: ((x)+(a) < (m) ? (x)+(a) : (x)+(a)-(m)))
Add support for VDPAU video out, including hardware decoding. git-svn-id: svn://svn.mplayerhq.hu/mplayer/trunk@28617 b3059339-0415-0410-9bf9-f77b7e298cf2
2009-02-16 21:58:13 +01:00
/* number of video and output surfaces */
vo_vdpau: support queuing an arbitrary number of frames ahead Make the number of output surfaces allocated by vo_vdpau configurable and allow queuing multiple future frames with the VDPAU frame timing functionality. There are two known issues that could be polished in the future for particularly long queue time cases. First, toplevel code should possibly wait for the queued changes to finish displaying in some situations like switching files. Second, the VO can block waiting for a surface to become available, and in the worst case this wait can be almost as long as the maximum queuing time (potentially causing audio underruns). However those issues are not high priority.
2010-05-14 04:18:38 +02:00
#define MAX_OUTPUT_SURFACES 15
vo: do final frame draw only near page flip Separate passing a new frame to VOs using the new API into two steps. The first, vo_draw_image(), happens after a new frame is available from the filter chain. In constrast to old behavior, now the frame is not actually rendered yet at this point (though possible slice draw calls can already reach the VO before). The second step, vo_new_frame_imminent(), happens when we're close enough to the display time of the new frame that we'll commit to flipping it as the next action and will not change the OSD over the previous frame any more. This new behavior fixes a previous problem with vo_vdpau and vo_gl in the situation where the player is paused after decoding a new frame but before flipping it; previously changing OSD in that state would switch to the new frame as a side effect. It would also allow an easy way to fix extra output files produced with something like "--vo=png --frames=1" with precise seeking, but this is not done yet. The code now relies on a new mp_image from the filter chain staying valid even after the vf_vo put_image() call providing it returns. In other words decoders/filters must not deallocate or otherwise invalidate their output frame between passing it forward and returning from the decode/filter call.
2011-12-04 17:10:17 +01:00
#define NUM_BUFFERED_VIDEO 5
Add support for VDPAU video out, including hardware decoding. git-svn-id: svn://svn.mplayerhq.hu/mplayer/trunk@28617 b3059339-0415-0410-9bf9-f77b7e298cf2
2009-02-16 21:58:13 +01:00
vo_vdpau: implement screenshots
2011-10-06 20:46:01 +02:00
/* Pixelformat used for output surfaces */
#define OUTPUT_RGBA_FORMAT VDP_RGBA_FORMAT_B8G8R8A8
Add support for VDPAU video out, including hardware decoding. git-svn-id: svn://svn.mplayerhq.hu/mplayer/trunk@28617 b3059339-0415-0410-9bf9-f77b7e298cf2
2009-02-16 21:58:13 +01:00
/*
* Global variable declaration - VDPAU specific
*/
vo_vdpau: Replace global function table with context variable
2009-05-06 20:04:37 +02:00
struct vdpctx {
vdpau: move device and video surface management from vo_vdpau.c to vdpau.c The goal is being able to use vdpau decoding independently from vo_vdpau.c.
2013-11-05 22:06:32 +01:00
struct mp_vdpau_ctx *mpvdp;
vdpau: split off decoder parts, use "new" libavcodec vdpau hwaccel API Move the decoder parts from vo_vdpau.c to a new file vdpau_old.c. This file is named so because because it's written against the "old" libavcodec vdpau pseudo-decoder (e.g. "h264_vdpau"). Add support for the "new" libavcodec vdpau support. This was recently added and replaces the "old" vdpau parts. (In fact, Libav is about to deprecate and remove the "old" API without deprecation grace period, so we have to support it now. Moreover, there will probably be no Libav release which supports both, so the transition is even less smooth than we could hope, and we have to support both the old and new API.) Whether the old or new API is used is checked by a configure test: if the new API is found, it is used, otherwise the old API is assumed. Some details might be handled differently. Especially display preemption is a bit problematic with the "new" libavcodec vdpau support: it wants to keep a pointer to a specific vdpau API function (which can be driver specific, because preemption might switch drivers). Also, surface IDs are now directly stored in AVFrames (and mp_images), so they can't be forced to VDP_INVALID_HANDLE on preemption. (This changes even with older libavcodec versions, because mp_image always uses the newer representation to make vo_vdpau.c simpler.) Decoder initialization in the new code tries to deal with codec profiles, while the old code always uses the highest profile per codec. Surface allocation changes. Since the decoder won't call config() in vo_vdpau.c on video size change anymore, we allow allocating surfaces of arbitrary size instead of locking it to what the VO was configured. The non-hwdec code also has slightly different allocation behavior now. Enabling the old vdpau special decoders via e.g. --vd=lavc:h264_vdpau doesn't work anymore (a warning suggesting the --hwdec option is printed instead).
2013-07-28 01:49:45 +02:00
struct vdp_functions *vdp;
vo_vdpau: Move things to context struct
2009-05-06 22:42:24 +02:00
VdpDevice vdp_device;
vdpau: move device and video surface management from vo_vdpau.c to vdpau.c The goal is being able to use vdpau decoding independently from vo_vdpau.c.
2013-11-05 22:06:32 +01:00
uint64_t preemption_counter;
vdpau: split off decoder parts, use "new" libavcodec vdpau hwaccel API Move the decoder parts from vo_vdpau.c to a new file vdpau_old.c. This file is named so because because it's written against the "old" libavcodec vdpau pseudo-decoder (e.g. "h264_vdpau"). Add support for the "new" libavcodec vdpau support. This was recently added and replaces the "old" vdpau parts. (In fact, Libav is about to deprecate and remove the "old" API without deprecation grace period, so we have to support it now. Moreover, there will probably be no Libav release which supports both, so the transition is even less smooth than we could hope, and we have to support both the old and new API.) Whether the old or new API is used is checked by a configure test: if the new API is found, it is used, otherwise the old API is assumed. Some details might be handled differently. Especially display preemption is a bit problematic with the "new" libavcodec vdpau support: it wants to keep a pointer to a specific vdpau API function (which can be driver specific, because preemption might switch drivers). Also, surface IDs are now directly stored in AVFrames (and mp_images), so they can't be forced to VDP_INVALID_HANDLE on preemption. (This changes even with older libavcodec versions, because mp_image always uses the newer representation to make vo_vdpau.c simpler.) Decoder initialization in the new code tries to deal with codec profiles, while the old code always uses the highest profile per codec. Surface allocation changes. Since the decoder won't call config() in vo_vdpau.c on video size change anymore, we allow allocating surfaces of arbitrary size instead of locking it to what the VO was configured. The non-hwdec code also has slightly different allocation behavior now. Enabling the old vdpau special decoders via e.g. --vd=lavc:h264_vdpau doesn't work anymore (a warning suggesting the --hwdec option is printed instead).
2013-07-28 01:49:45 +02:00
vo_vdpau: allow setting colorkey Formally, this sets the "background color" of the presentation queue. But in practice, this color is also used as colorkey. This commit doesn't change the VDPAU default yet.
2013-08-17 19:57:18 +02:00
struct m_color colorkey;
vo_vdpau: Move things to context struct
2009-05-06 22:42:24 +02:00
VdpPresentationQueueTarget flip_target;
VdpPresentationQueue flip_queue;
vo_vdpau: split bitmap packing code into a separate file Split the vo_vdpau code that calculates how to pack all subtitle bitmaps into a larger surface into a separate file. This will allow using it in other VOs. Conflicts: Makefile libvo/vo_vdpau.c Note: this commit does the same as an earlier commit by me (4010dd0b1a27e3996). My commit added the vo_vdpau packer code as eosd_packer.c, while this commit by uau uses bitmap_packer.c. Since bitmap_packer.c has a different interface, and because there are more commits changing OSD rendering coming, I will pick uau's version. However, vo_gl, vo_gl3 and vo_direct3d are still using eosd_packer.c, so to make the transition easier, don't delete eosd_packer.c yet.
2012-08-26 18:00:26 +02:00
VdpOutputSurface output_surfaces[MAX_OUTPUT_SURFACES];
vo_vdpau: fix screenshots Attempting to take screenshots printed vdpau errors on the terminal, and the resulting screenshots were filled with black. The problem was that that the screenshot code tried to use an unallocated output surface (the one at vc->output_surfaces[vc->num_output_surfaces]). This used to refer to the last allocated surface, until this was changed by a recently merged commit. That commit also added a separate screenshot surface. The merge somehow went wrong, and that part was not integrated. <uau> wm4: you used an earlier buggy version of a commit OK...
2012-10-21 00:48:01 +02:00
VdpOutputSurface screenshot_surface;
vo_vdpau: support queuing an arbitrary number of frames ahead Make the number of output surfaces allocated by vo_vdpau configurable and allow queuing multiple future frames with the VDPAU frame timing functionality. There are two known issues that could be polished in the future for particularly long queue time cases. First, toplevel code should possibly wait for the queued changes to finish displaying in some situations like switching files. Second, the VO can block waiting for a surface to become available, and in the worst case this wait can be almost as long as the maximum queuing time (potentially causing audio underruns). However those issues are not high priority.
2010-05-14 04:18:38 +02:00
int num_output_surfaces;
vo_vdpau: add RGB support Apparently this was dropped some years ago, but judging from MPlayer's handling of this, the original code wasn't so great anyway. The new code handling clearing of panscan borders correctly, and integrates better with the YUV path. (Although the VDPAU API sure makes this annoying with its separate surface types for RGB.) Note that we create 5 surfaces for some reason - I don't think this makes too much sense (because we can't use the deinterlacer with RGB surfaces), but at least it reduces the amount of differences with the YUV code path. Clearing the borders is done by drawing a single black pixel over the window. This sounds pretty dumb, but it appears to work well, and there is no other API for that. (One could try to use the video mixer for this purpose, since it has all kinds of features, including compositing multiple RGBA surfaces and clearing the window background. But it would require an invisible dummy video surface to make the video mixer happy, and that's getting too messy.)
2013-08-18 05:12:21 +02:00
VdpOutputSurface rgb_surfaces[NUM_BUFFERED_VIDEO];
vo_vdpau: always use mp_image for internal buffer queue
2014-04-29 15:18:35 +02:00
bool rgb_surfaces_used[NUM_BUFFERED_VIDEO];
vo_vdpau: add RGB support Apparently this was dropped some years ago, but judging from MPlayer's handling of this, the original code wasn't so great anyway. The new code handling clearing of panscan borders correctly, and integrates better with the YUV path. (Although the VDPAU API sure makes this annoying with its separate surface types for RGB.) Note that we create 5 surfaces for some reason - I don't think this makes too much sense (because we can't use the deinterlacer with RGB surfaces), but at least it reduces the amount of differences with the YUV code path. Clearing the borders is done by drawing a single black pixel over the window. This sounds pretty dumb, but it appears to work well, and there is no other API for that. (One could try to use the video mixer for this purpose, since it has all kinds of features, including compositing multiple RGBA surfaces and clearing the window background. But it would require an invisible dummy video surface to make the video mixer happy, and that's getting too messy.)
2013-08-18 05:12:21 +02:00
VdpOutputSurface black_pixel;
vo_vdpau: don't blank screen on VOCTRL_RESET vo_vdpau is the only VO which implements VOCTRL_RESET. Redrawing the last output frame is hard, because the output could consist of several source video frames with certain types of post-processing (deinterlacing). Implement redrawing as special case by keeping the previous video frames aside until at least one new frame is decoded. This improves the previous commit, but is separate, because it's rather complicated.
2013-10-01 23:45:30 +02:00
video: move video frame queue from vo_vdpau.c to vo.c Remove the special casing of vo_vdpau vs. other VOs. Replace the complicated interaction between vo.c and vo_vdpau.c with a simple queue in vo.c. VOs other than vdpau are handled by setting the length of the queue to 1 (this is essentially what waiting_mpi was). Note that vo_vdpau.c seems to have buffered only 1 or 2 frames into the future, while the remaining 3 or 4 frames were past frames. So the new code buffers 2 frames (vo_vdpau.c requests this queue length by setting vo->max_video_queue to 2). It should probably be investigated why vo_vdpau.c kept so many past frames. The field vo->redrawing is removed. I'm not really sure what that would be needed for; it seems pointless. Future directions include making the interface between playloop and VO simpler, as well as making rendering a frame a single operation, as opposed to the weird 3-step sequence of rendering, drawing OSD, and flipping.
2014-04-29 15:19:03 +02:00
struct mp_image *current_image;
vo_vdpau: don't blank screen on VOCTRL_RESET vo_vdpau is the only VO which implements VOCTRL_RESET. Redrawing the last output frame is hard, because the output could consist of several source video frames with certain types of post-processing (deinterlacing). Implement redrawing as special case by keeping the previous video frames aside until at least one new frame is decoded. This improves the previous commit, but is separate, because it's rather complicated.
2013-10-01 23:45:30 +02:00
vo_vdpau: Move things to context struct
2009-05-06 22:42:24 +02:00
int output_surface_width, output_surface_height;
vo_vdpau: add RGB support Apparently this was dropped some years ago, but judging from MPlayer's handling of this, the original code wasn't so great anyway. The new code handling clearing of panscan borders correctly, and integrates better with the YUV path. (Although the VDPAU API sure makes this annoying with its separate surface types for RGB.) Note that we create 5 surfaces for some reason - I don't think this makes too much sense (because we can't use the deinterlacer with RGB surfaces), but at least it reduces the amount of differences with the YUV code path. Clearing the borders is done by drawing a single black pixel over the window. This sounds pretty dumb, but it appears to work well, and there is no other API for that. (One could try to use the video mixer for this purpose, since it has all kinds of features, including compositing multiple RGBA surfaces and clearing the window background. But it would require an invisible dummy video surface to make the video mixer happy, and that's getting too messy.)
2013-08-18 05:12:21 +02:00
int force_yuv;
vo_vdpau: support vf_vdpaupp This is slightly incomplete: the mixer options, such as sharpen and especially deinterlacing, are ignored. This also breaks automatic enabling of interlacing with 'D' or --deinterlace. These issues will be fixed later in the following commits. Note that we keep all the custom vdpau queue stuff. This will also be simplified later.
2014-04-29 15:11:44 +02:00
struct mp_vdpau_mixer *video_mixer;
vo_vdpau: Move things to context struct
2009-05-06 22:42:24 +02:00
int deint;
int pullup;
float denoise;
float sharpen;
vo_vdpau: Add support for high-quality scaling feature Part of the code is currently under #ifdef to allow compilation with older VDPAU library versions; that can be removed later. Partially based on a patch by Carl Eugen Hoyos.
2009-11-15 17:39:48 +01:00
int hqscaling;
vo_vdpau: Move things to context struct
2009-05-06 22:42:24 +02:00
int chroma_deint;
vo_vdpau: make queuing future frame flips adjustable Add -vo vdpau suboptions "queuetime_windowed" and "queuetime_fs" to specify the maximum number of milliseconds how far into the future a frame flip can be queued using the VDPAU presentation queue functionality. The intended main use of these options is to allow disabling use of the queuing feature on systems where using it causes choppiness in other graphics behavior (this is an NVIDIA driver issue; the video itself isn't affected).
2010-02-05 19:13:33 +01:00
int flip_offset_window;
int flip_offset_fs;
vo_vdpau: add support for VFCAP_FLIP Patch by Carl Eugen Hoyos.
2009-11-15 14:50:28 +01:00
bool flip;
vo_vdpau: Move things to context struct
2009-05-06 22:42:24 +02:00
VdpRect src_rect_vid;
VdpRect out_rect_vid;
VO: remove code duplication for setting up mp_osd_res vo_opengl, vo_vdpau, vo_direct3d had the code for setting up mp_osd_res duplicated. Make things simpler by making calc_src_dst_rects() setup the full mp_osd_res structure, instead of just "borders". Also, rename that function to vo_get_src_dst_rects(), and make it use mp_rect. Remove vo_rect, which was annoying because it contains redundant members (width/height additional to right/bottom). Add code to print the video rect etc. in verbose mode. There should be no actual change how the video rects are calculated. The only exception are the bottom/right subtitle margins, which are now computed slightly differently, but that shouldn't matter.
2012-10-27 22:10:32 +02:00
struct mp_osd_res osd_rect;
vo_vdpau: Move things to context struct
2009-05-06 22:42:24 +02:00
video/filter: change filter API, use refcounting, remove filter DR Change the entire filter API to use reference counted images instead of vf_get_image(). Remove filter "direct rendering". This was useful for vf_expand and (in rare cases) vf_sub: DR allowed these filters to pass a cropped image to the filters before them. Then, on filtering, the image was "uncropped", so that black bars could be added around the image without copying. This means that in some cases, vf_expand will be slower (-vf gradfun,expand for example). Note that another form of DR used for in-place filters has been replaced by simpler logic. Instead of trying to do DR, filters can check if the image is writeable (with mp_image_is_writeable()), and do true in-place if that's the case. This affects filters like vf_gradfun and vf_sub. Everything has to support strides now. If something doesn't, making a copy of the image data is required.
2012-11-05 14:25:04 +01:00
int surface_num; // indexes output_surfaces
vo_vdpau: support queuing an arbitrary number of frames ahead Make the number of output surfaces allocated by vo_vdpau configurable and allow queuing multiple future frames with the VDPAU frame timing functionality. There are two known issues that could be polished in the future for particularly long queue time cases. First, toplevel code should possibly wait for the queued changes to finish displaying in some situations like switching files. Second, the VO can block waiting for a surface to become available, and in the worst case this wait can be almost as long as the maximum queuing time (potentially causing audio underruns). However those issues are not high priority.
2010-05-14 04:18:38 +02:00
int query_surface_num;
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
VdpTime recent_vsync_time;
float user_fps;
vo_vdpau: disable refresh-aware frame timing when composited Under a compositing window manager the current VDPAU implementation behaves differently than without it. Frame flip timing info becomes incorrect (I guess it only reflects when the frame was sent to the compositor, not when it was actually shown), and there is no limitation to at most one frame switch per refresh like without compositing. Detect whether a compositing window manager is active and disable refresh-aware frame timing and dropping in this case, similarly to what fps=-1 would do. This behavior can be controlled with the new suboption "composite-detect". Disabling the refresh-aware logic makes timing somewhat less accurate. Because the video switch rate limit isn't there, the lack of frame dropping on player side does not impose a hard limit on video FPS, but does reduce performance somewhat as redundant frames are drawn in memory. The existence of a compositing window manager does not guarantee that the current window is actually composited, so the current check is not foolproof. In particular, some WMs have support for a "unredirect fullscreen windows" option. Support for such things could be improved.
2012-07-27 02:40:38 +02:00
int composite_detect;
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
unsigned int vsync_interval;
uint64_t last_queue_time;
vo_vdpau: support queuing an arbitrary number of frames ahead Make the number of output surfaces allocated by vo_vdpau configurable and allow queuing multiple future frames with the VDPAU frame timing functionality. There are two known issues that could be polished in the future for particularly long queue time cases. First, toplevel code should possibly wait for the queued changes to finish displaying in some situations like switching files. Second, the VO can block waiting for a surface to become available, and in the worst case this wait can be almost as long as the maximum queuing time (potentially causing audio underruns). However those issues are not high priority.
2010-05-14 04:18:38 +02:00
uint64_t queue_time[MAX_OUTPUT_SURFACES];
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
uint64_t last_ideal_time;
bool dropped_frame;
uint64_t dropped_time;
vo_vdpau: Move things to context struct
2009-05-06 22:42:24 +02:00
uint32_t vid_width, vid_height;
uint32_t image_format;
VdpChromaType vdp_chroma_type;
VdpYCbCrFormat vdp_pixel_format;
vo_vdpau: add RGB support Apparently this was dropped some years ago, but judging from MPlayer's handling of this, the original code wasn't so great anyway. The new code handling clearing of panscan borders correctly, and integrates better with the YUV path. (Although the VDPAU API sure makes this annoying with its separate surface types for RGB.) Note that we create 5 surfaces for some reason - I don't think this makes too much sense (because we can't use the deinterlacer with RGB surfaces), but at least it reduces the amount of differences with the YUV code path. Clearing the borders is done by drawing a single black pixel over the window. This sounds pretty dumb, but it appears to work well, and there is no other API for that. (One could try to use the video mixer for this purpose, since it has all kinds of features, including compositing multiple RGBA surfaces and clearing the window background. But it would require an invisible dummy video surface to make the video mixer happy, and that's getting too messy.)
2013-08-18 05:12:21 +02:00
bool rgb_mode;
vo_vdpau: Move things to context struct
2009-05-06 22:42:24 +02:00
VO, sub: refactor Remove VFCTRL_DRAW_OSD, VFCAP_EOSD_FILTER, VFCAP_EOSD_RGBA, VFCAP_EOSD, VOCTRL_DRAW_EOSD, VOCTRL_GET_EOSD_RES, VOCTRL_QUERY_EOSD_FORMAT. Remove draw_osd_with_eosd(), which rendered the OSD by calling VOCTRL_DRAW_EOSD. Change VOs to call osd_draw() directly, which takes a callback as argument. (This basically works like the old OSD API, except multiple OSD bitmap formats are supported and caching is possible.) Remove all mentions of "eosd". It's simply "osd" now. Make OSD size per-OSD-object, as they can be different when using vf_sub. Include display_par/video_par in resolution change detection. Fix the issue with margin borders in vo_corevideo.
2012-10-19 19:25:18 +02:00
// OSD
struct osd_bitmap_surface {
subs, vo_vdpau: support RGBA color for PGS subtitles Support passing bitmap subtitles to VOs in full RGBA color, and implement this for libavcodec-decoded subtitle formats on decoding side and vo_vdpau on display side. Currently this is enabled for PGS (blu-ray) and DVB subtitles. VDPAU seems to have sampling issues similar to known GL ones when drawing a sub-rectangle from a larger texture with scaling, where adjacent pixels outside the specified source rectangle affect the result. As the bitmap subtitles may be scaled, add padding support to the bitmap packer code. In principle, this could be used for colored DVD subtitles too. However, the libavcodec DVD decoder lacks parts of the resolution and palette handling that are present in spudec.c. Conflicts: libvo/vo_gl.c sub/dec_sub.h sub/sd_lavc.c
2012-08-31 14:42:30 +02:00
VdpRGBAFormat format;
vo_vdpau: split bitmap packing code into a separate file Split the vo_vdpau code that calculates how to pack all subtitle bitmaps into a larger surface into a separate file. This will allow using it in other VOs. Conflicts: Makefile libvo/vo_vdpau.c Note: this commit does the same as an earlier commit by me (4010dd0b1a27e3996). My commit added the vo_vdpau packer code as eosd_packer.c, while this commit by uau uses bitmap_packer.c. Since bitmap_packer.c has a different interface, and because there are more commits changing OSD rendering coming, I will pick uau's version. However, vo_gl, vo_gl3 and vo_direct3d are still using eosd_packer.c, so to make the transition easier, don't delete eosd_packer.c yet.
2012-08-26 18:00:26 +02:00
VdpBitmapSurface surface;
uint32_t max_width;
uint32_t max_height;
struct bitmap_packer *packer;
vo_vdpau: use new EOSD for OSD, remove support for old OSD format This allows vo_vdpau to render OSD directly, without the indirection through the old OSD API, and without the additional conversions. Remove support for the old OSD format. Only the mplayer DVD subtitle decoder still generates this format. Although the new OSD interface does support this format, remove it from vo_vdpau. It would be relatively hard to support it in the EOSD code, as it requires two surfaces. (These two surfaces are blended on top of each other to emulate the mplayer OSD format.) The correct way to implement direct support for DVD subs would consist of adding a paletted image format of some sort. But even sd_lavc converts paletted subtitle images to RGBA, so doing something special just for DVD subs is not worth it. This means the frontend (sub.c) converts the subtitles to RGBA if it detects that vo_vdpau does not support them natively.
2012-09-28 21:49:32 +02:00
// List of surfaces to be rendered
VO, sub: refactor Remove VFCTRL_DRAW_OSD, VFCAP_EOSD_FILTER, VFCAP_EOSD_RGBA, VFCAP_EOSD, VOCTRL_DRAW_EOSD, VOCTRL_GET_EOSD_RES, VOCTRL_QUERY_EOSD_FORMAT. Remove draw_osd_with_eosd(), which rendered the OSD by calling VOCTRL_DRAW_EOSD. Change VOs to call osd_draw() directly, which takes a callback as argument. (This basically works like the old OSD API, except multiple OSD bitmap formats are supported and caching is possible.) Remove all mentions of "eosd". It's simply "osd" now. Make OSD size per-OSD-object, as they can be different when using vf_sub. Include display_par/video_par in resolution change detection. Fix the issue with margin borders in vo_corevideo.
2012-10-19 19:25:18 +02:00
struct osd_target {
vo_vdpau: use new EOSD for OSD, remove support for old OSD format This allows vo_vdpau to render OSD directly, without the indirection through the old OSD API, and without the additional conversions. Remove support for the old OSD format. Only the mplayer DVD subtitle decoder still generates this format. Although the new OSD interface does support this format, remove it from vo_vdpau. It would be relatively hard to support it in the EOSD code, as it requires two surfaces. (These two surfaces are blended on top of each other to emulate the mplayer OSD format.) The correct way to implement direct support for DVD subs would consist of adding a paletted image format of some sort. But even sd_lavc converts paletted subtitle images to RGBA, so doing something special just for DVD subs is not worth it. This means the frontend (sub.c) converts the subtitles to RGBA if it detects that vo_vdpau does not support them natively.
2012-09-28 21:49:32 +02:00
VdpRect source;
VdpRect dest;
VdpColor color;
} *targets;
vo_vdpau: allow multiple EOSD renderers Preparation for using new OSD rendering method.
2012-09-28 21:49:09 +02:00
int targets_size;
int render_count;
int bitmap_id;
int bitmap_pos_id;
VO, sub: refactor Remove VFCTRL_DRAW_OSD, VFCAP_EOSD_FILTER, VFCAP_EOSD_RGBA, VFCAP_EOSD, VOCTRL_DRAW_EOSD, VOCTRL_GET_EOSD_RES, VOCTRL_QUERY_EOSD_FORMAT. Remove draw_osd_with_eosd(), which rendered the OSD by calling VOCTRL_DRAW_EOSD. Change VOs to call osd_draw() directly, which takes a callback as argument. (This basically works like the old OSD API, except multiple OSD bitmap formats are supported and caching is possible.) Remove all mentions of "eosd". It's simply "osd" now. Make OSD size per-OSD-object, as they can be different when using vf_sub. Include display_par/video_par in resolution change detection. Fix the issue with margin borders in vo_corevideo.
2012-10-19 19:25:18 +02:00
} osd_surfaces[MAX_OSD_PARTS];
vo_vdpau: Move all remaining static/global variables to context
2009-05-06 22:49:51 +02:00
// Video equalizer
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
struct mp_csp_equalizer video_eq;
vo_vdpau: Move all remaining static/global variables to context
2009-05-06 22:49:51 +02:00
};
Add support for VDPAU video out, including hardware decoding. git-svn-id: svn://svn.mplayerhq.hu/mplayer/trunk@28617 b3059339-0415-0410-9bf9-f77b7e298cf2
2009-02-16 21:58:13 +01:00
VO, sub: refactor Remove VFCTRL_DRAW_OSD, VFCAP_EOSD_FILTER, VFCAP_EOSD_RGBA, VFCAP_EOSD, VOCTRL_DRAW_EOSD, VOCTRL_GET_EOSD_RES, VOCTRL_QUERY_EOSD_FORMAT. Remove draw_osd_with_eosd(), which rendered the OSD by calling VOCTRL_DRAW_EOSD. Change VOs to call osd_draw() directly, which takes a callback as argument. (This basically works like the old OSD API, except multiple OSD bitmap formats are supported and caching is possible.) Remove all mentions of "eosd". It's simply "osd" now. Make OSD size per-OSD-object, as they can be different when using vf_sub. Include display_par/video_par in resolution change detection. Fix the issue with margin borders in vo_corevideo.
2012-10-19 19:25:18 +02:00
static bool status_ok(struct vo *vo);
vo_vdpau: implement screenshots
2011-10-06 20:46:01 +02:00
static int render_video_to_output_surface(struct vo *vo,
VdpOutputSurface output_surface,
vo_vdpau: fix screenshots if panscan is used When panscan was used, i.e. the video is cropped to make the video fill the screen if video and screen aspects don't match, screenshots contained only the visible region of the source video, stretched to original video size.
2013-08-18 05:06:46 +02:00
VdpRect *output_rect,
VdpRect *video_rect)
Add support for VDPAU video out, including hardware decoding. git-svn-id: svn://svn.mplayerhq.hu/mplayer/trunk@28617 b3059339-0415-0410-9bf9-f77b7e298cf2
2009-02-16 21:58:13 +01:00
{
vo_vdpau: Replace global function table with context variable
2009-05-06 20:04:37 +02:00
struct vdpctx *vc = vo->priv;
struct vdp_functions *vdp = vc->vdp;
Add support for VDPAU video out, including hardware decoding. git-svn-id: svn://svn.mplayerhq.hu/mplayer/trunk@28617 b3059339-0415-0410-9bf9-f77b7e298cf2
2009-02-16 21:58:13 +01:00
VdpTime dummy;
VdpStatus vdp_st;
video: move video frame queue from vo_vdpau.c to vo.c Remove the special casing of vo_vdpau vs. other VOs. Replace the complicated interaction between vo.c and vo_vdpau.c with a simple queue in vo.c. VOs other than vdpau are handled by setting the length of the queue to 1 (this is essentially what waiting_mpi was). Note that vo_vdpau.c seems to have buffered only 1 or 2 frames into the future, while the remaining 3 or 4 frames were past frames. So the new code buffers 2 frames (vo_vdpau.c requests this queue length by setting vo->max_video_queue to 2). It should probably be investigated why vo_vdpau.c kept so many past frames. The field vo->redrawing is removed. I'm not really sure what that would be needed for; it seems pointless. Future directions include making the interface between playloop and VO simpler, as well as making rendering a frame a single operation, as opposed to the weird 3-step sequence of rendering, drawing OSD, and flipping.
2014-04-29 15:19:03 +02:00
struct mp_image *mpi = vc->current_image;
vo_vdpau: don't blank screen on VOCTRL_RESET vo_vdpau is the only VO which implements VOCTRL_RESET. Redrawing the last output frame is hard, because the output could consist of several source video frames with certain types of post-processing (deinterlacing). Implement redrawing as special case by keeping the previous video frames aside until at least one new frame is decoded. This improves the previous commit, but is separate, because it's rather complicated.
2013-10-01 23:45:30 +02:00
video: move video frame queue from vo_vdpau.c to vo.c Remove the special casing of vo_vdpau vs. other VOs. Replace the complicated interaction between vo.c and vo_vdpau.c with a simple queue in vo.c. VOs other than vdpau are handled by setting the length of the queue to 1 (this is essentially what waiting_mpi was). Note that vo_vdpau.c seems to have buffered only 1 or 2 frames into the future, while the remaining 3 or 4 frames were past frames. So the new code buffers 2 frames (vo_vdpau.c requests this queue length by setting vo->max_video_queue to 2). It should probably be investigated why vo_vdpau.c kept so many past frames. The field vo->redrawing is removed. I'm not really sure what that would be needed for; it seems pointless. Future directions include making the interface between playloop and VO simpler, as well as making rendering a frame a single operation, as opposed to the weird 3-step sequence of rendering, drawing OSD, and flipping.
2014-04-29 15:19:03 +02:00
if (!mpi) {
video/out: always support redrawing VO window at any point Before, a VO could easily refuse to respond to VOCTRL_REDRAW_FRAME, which means the VO wouldn't redraw OSD and window contents, and the player would appear frozen to the user. This was a bit stupid, and makes dealing with some corner cases much harder (think of --keep-open, which was hard to implement, because the VO gets into this state if there are no new video frames after a seek reset). Change this, and require VOs to always react to VOCTRL_REDRAW_FRAME. There are two aspects of this: First, behavior after a (successful) vo_reconfig() call, but before any video frame has been displayed. Second, behavior after a vo_seek_reset(). For the first issue, we define that sending VOCTRL_REDRAW_FRAME after vo_reconfig() should clear the window with black. This requires minor changes to some VOs. In particular vaapi makes this horribly complicated, because OSD rendering is bound to a video surface. We create a black dummy surface for this purpose. The second issue is much simpler and works already with most VOs: they simply redraw whatever has been uploaded previously. The exception is vdpau, which has a complicated mechanism to track and filter video frames. The state associated with this mechanism is completely cleared with vo_seek_reset(), so implementing this to work as expected is not trivial. For now, we just clear the window with black.
2013-10-01 23:35:51 +02:00
// At least clear the screen if there is nothing to render
int flags = VDP_OUTPUT_SURFACE_RENDER_ROTATE_0;
vdp_st = vdp->output_surface_render_output_surface(output_surface,
NULL, vc->black_pixel,
NULL, NULL, NULL,
flags);
vo_vdpau: Fix X event handling bugs check_events() first checked for a RESIZE event and called resize() if needed, and then queued a frame to be reshown if in pause state and the event was either RESIZE or EXPOSE. The most obvious problems with the code were: - resize() already called flip_page() internally, so the code in check_events could lead to _two_ frames being queued. - The call in resize() didn't depend on pause status, so the behavior was inconsistent. - The code in check_events() actually queued the wrong output surface. It showed the same surface as flip_page() would show _next_, while it should have shown the previously shown one. This typically led to the screen contents changing to a previous state, as the new surface had not been initialized and had contents from a previous use. Fix the double update. Make resize() also only immediately update the video if paused (this also affects changing to/from fullscreen) and otherwise leave the old window contents be until the next frame. Queue the right frame in check_events(). Also make resize() a bit more careful to only show contents if they were successfully updated (though a case where we're paused without content to show shouldn't normally happen).
2009-09-18 23:00:42 +02:00
return -1;
video/out: always support redrawing VO window at any point Before, a VO could easily refuse to respond to VOCTRL_REDRAW_FRAME, which means the VO wouldn't redraw OSD and window contents, and the player would appear frozen to the user. This was a bit stupid, and makes dealing with some corner cases much harder (think of --keep-open, which was hard to implement, because the VO gets into this state if there are no new video frames after a seek reset). Change this, and require VOs to always react to VOCTRL_REDRAW_FRAME. There are two aspects of this: First, behavior after a (successful) vo_reconfig() call, but before any video frame has been displayed. Second, behavior after a vo_seek_reset(). For the first issue, we define that sending VOCTRL_REDRAW_FRAME after vo_reconfig() should clear the window with black. This requires minor changes to some VOs. In particular vaapi makes this horribly complicated, because OSD rendering is bound to a video surface. We create a black dummy surface for this purpose. The second issue is much simpler and works already with most VOs: they simply redraw whatever has been uploaded previously. The exception is vdpau, which has a complicated mechanism to track and filter video frames. The state associated with this mechanism is completely cleared with vo_seek_reset(), so implementing this to work as expected is not trivial. For now, we just clear the window with black.
2013-10-01 23:35:51 +02:00
}
Add support for VDPAU video out, including hardware decoding. git-svn-id: svn://svn.mplayerhq.hu/mplayer/trunk@28617 b3059339-0415-0410-9bf9-f77b7e298cf2
2009-02-16 21:58:13 +01:00
vo_vdpau: add RGB support Apparently this was dropped some years ago, but judging from MPlayer's handling of this, the original code wasn't so great anyway. The new code handling clearing of panscan borders correctly, and integrates better with the YUV path. (Although the VDPAU API sure makes this annoying with its separate surface types for RGB.) Note that we create 5 surfaces for some reason - I don't think this makes too much sense (because we can't use the deinterlacer with RGB surfaces), but at least it reduces the amount of differences with the YUV code path. Clearing the borders is done by drawing a single black pixel over the window. This sounds pretty dumb, but it appears to work well, and there is no other API for that. (One could try to use the video mixer for this purpose, since it has all kinds of features, including compositing multiple RGBA surfaces and clearing the window background. But it would require an invisible dummy video surface to make the video mixer happy, and that's getting too messy.)
2013-08-18 05:12:21 +02:00
vdp_st = vdp->presentation_queue_block_until_surface_idle(vc->flip_queue,
output_surface,
&dummy);
vdpau: mp_msg conversions
2013-12-21 18:05:23 +01:00
CHECK_VDP_WARNING(vo, "Error when calling "
"vdp_presentation_queue_block_until_surface_idle");
vo_vdpau: add RGB support Apparently this was dropped some years ago, but judging from MPlayer's handling of this, the original code wasn't so great anyway. The new code handling clearing of panscan borders correctly, and integrates better with the YUV path. (Although the VDPAU API sure makes this annoying with its separate surface types for RGB.) Note that we create 5 surfaces for some reason - I don't think this makes too much sense (because we can't use the deinterlacer with RGB surfaces), but at least it reduces the amount of differences with the YUV code path. Clearing the borders is done by drawing a single black pixel over the window. This sounds pretty dumb, but it appears to work well, and there is no other API for that. (One could try to use the video mixer for this purpose, since it has all kinds of features, including compositing multiple RGBA surfaces and clearing the window background. But it would require an invisible dummy video surface to make the video mixer happy, and that's getting too messy.)
2013-08-18 05:12:21 +02:00
if (vc->rgb_mode) {
vo_vdpau: always use mp_image for internal buffer queue
2014-04-29 15:18:35 +02:00
VdpOutputSurface surface = (uintptr_t)mpi->planes[0];
vo_vdpau: add RGB support Apparently this was dropped some years ago, but judging from MPlayer's handling of this, the original code wasn't so great anyway. The new code handling clearing of panscan borders correctly, and integrates better with the YUV path. (Although the VDPAU API sure makes this annoying with its separate surface types for RGB.) Note that we create 5 surfaces for some reason - I don't think this makes too much sense (because we can't use the deinterlacer with RGB surfaces), but at least it reduces the amount of differences with the YUV code path. Clearing the borders is done by drawing a single black pixel over the window. This sounds pretty dumb, but it appears to work well, and there is no other API for that. (One could try to use the video mixer for this purpose, since it has all kinds of features, including compositing multiple RGBA surfaces and clearing the window background. But it would require an invisible dummy video surface to make the video mixer happy, and that's getting too messy.)
2013-08-18 05:12:21 +02:00
int flags = VDP_OUTPUT_SURFACE_RENDER_ROTATE_0;
vdp_st = vdp->output_surface_render_output_surface(output_surface,
NULL, vc->black_pixel,
NULL, NULL, NULL,
flags);
vdpau: mp_msg conversions
2013-12-21 18:05:23 +01:00
CHECK_VDP_WARNING(vo, "Error clearing screen");
vo_vdpau: add RGB support Apparently this was dropped some years ago, but judging from MPlayer's handling of this, the original code wasn't so great anyway. The new code handling clearing of panscan borders correctly, and integrates better with the YUV path. (Although the VDPAU API sure makes this annoying with its separate surface types for RGB.) Note that we create 5 surfaces for some reason - I don't think this makes too much sense (because we can't use the deinterlacer with RGB surfaces), but at least it reduces the amount of differences with the YUV code path. Clearing the borders is done by drawing a single black pixel over the window. This sounds pretty dumb, but it appears to work well, and there is no other API for that. (One could try to use the video mixer for this purpose, since it has all kinds of features, including compositing multiple RGBA surfaces and clearing the window background. But it would require an invisible dummy video surface to make the video mixer happy, and that's getting too messy.)
2013-08-18 05:12:21 +02:00
vdp_st = vdp->output_surface_render_output_surface(output_surface,
output_rect,
vo_vdpau: always use mp_image for internal buffer queue
2014-04-29 15:18:35 +02:00
surface,
vo_vdpau: add RGB support Apparently this was dropped some years ago, but judging from MPlayer's handling of this, the original code wasn't so great anyway. The new code handling clearing of panscan borders correctly, and integrates better with the YUV path. (Although the VDPAU API sure makes this annoying with its separate surface types for RGB.) Note that we create 5 surfaces for some reason - I don't think this makes too much sense (because we can't use the deinterlacer with RGB surfaces), but at least it reduces the amount of differences with the YUV code path. Clearing the borders is done by drawing a single black pixel over the window. This sounds pretty dumb, but it appears to work well, and there is no other API for that. (One could try to use the video mixer for this purpose, since it has all kinds of features, including compositing multiple RGBA surfaces and clearing the window background. But it would require an invisible dummy video surface to make the video mixer happy, and that's getting too messy.)
2013-08-18 05:12:21 +02:00
video_rect,
NULL, NULL, flags);
vdpau: mp_msg conversions
2013-12-21 18:05:23 +01:00
CHECK_VDP_WARNING(vo, "Error when calling "
"vdp_output_surface_render_output_surface");
vo_vdpau: add RGB support Apparently this was dropped some years ago, but judging from MPlayer's handling of this, the original code wasn't so great anyway. The new code handling clearing of panscan borders correctly, and integrates better with the YUV path. (Although the VDPAU API sure makes this annoying with its separate surface types for RGB.) Note that we create 5 surfaces for some reason - I don't think this makes too much sense (because we can't use the deinterlacer with RGB surfaces), but at least it reduces the amount of differences with the YUV code path. Clearing the borders is done by drawing a single black pixel over the window. This sounds pretty dumb, but it appears to work well, and there is no other API for that. (One could try to use the video mixer for this purpose, since it has all kinds of features, including compositing multiple RGBA surfaces and clearing the window background. But it would require an invisible dummy video surface to make the video mixer happy, and that's getting too messy.)
2013-08-18 05:12:21 +02:00
return 0;
}
vo_vdpau: always use mp_image for internal buffer queue
2014-04-29 15:18:35 +02:00
vo_vdpau: apply vo_vdpau postprocessing options The previous commits changed vo_vdpau so that these options are set by vf_vdpaupp, and the corresponding vo_vdpau were ignored. But for compatibility, keep the "old" options working. The value of this is questionable - maybe the vo_vdpau options should just be removed. For now, at least demonstrate that it's possible. The "deint" suboption still doesn't work, because the framerate doubling logic required for some deint modes was moved to vf_vdpaupp. This requires more elaborate workarounds.
2014-04-29 15:14:19 +02:00
struct mp_vdpau_mixer_frame *frame = mp_vdpau_mixed_frame_get(mpi);
struct mp_vdpau_mixer_opts opts = {0};
if (frame)
opts = frame->opts;
// Apply custom vo_vdpau suboptions.
opts.chroma_deint |= vc->chroma_deint;
opts.pullup |= vc->pullup;
opts.denoise = MPCLAMP(opts.denoise + vc->denoise, 0, 1);
opts.sharpen = MPCLAMP(opts.sharpen + vc->sharpen, -1, 1);
if (vc->hqscaling)
opts.hqscaling = vc->hqscaling;
mp_vdpau_mixer_render(vc->video_mixer, &opts, output_surface, output_rect,
mpi, video_rect);
vo_vdpau: Fix X event handling bugs check_events() first checked for a RESIZE event and called resize() if needed, and then queued a frame to be reshown if in pause state and the event was either RESIZE or EXPOSE. The most obvious problems with the code were: - resize() already called flip_page() internally, so the code in check_events could lead to _two_ frames being queued. - The call in resize() didn't depend on pause status, so the behavior was inconsistent. - The code in check_events() actually queued the wrong output surface. It showed the same surface as flip_page() would show _next_, while it should have shown the previously shown one. This typically led to the screen contents changing to a previous state, as the new surface had not been initialized and had contents from a previous use. Fix the double update. Make resize() also only immediately update the video if paused (this also affects changing to/from fullscreen) and otherwise leave the old window contents be until the next frame. Queue the right frame in check_events(). Also make resize() a bit more careful to only show contents if they were successfully updated (though a case where we're paused without content to show shouldn't normally happen).
2009-09-18 23:00:42 +02:00
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
}
Simplify vdpau deinterlacing code and fix timing for deint=2. git-svn-id: svn://svn.mplayerhq.hu/mplayer/trunk@29061 b3059339-0415-0410-9bf9-f77b7e298cf2
2009-03-26 00:32:27 +01:00
vo_vdpau: implement screenshots
2011-10-06 20:46:01 +02:00
static int video_to_output_surface(struct vo *vo)
{
struct vdpctx *vc = vo->priv;
return render_video_to_output_surface(vo,
vc->output_surfaces[vc->surface_num],
vo_vdpau: fix screenshots if panscan is used When panscan was used, i.e. the video is cropped to make the video fill the screen if video and screen aspects don't match, screenshots contained only the visible region of the source video, stretched to original video size.
2013-08-18 05:06:46 +02:00
&vc->out_rect_vid, &vc->src_rect_vid);
vo_vdpau: implement screenshots
2011-10-06 20:46:01 +02:00
}
vo_vdpau: don't blank screen on VOCTRL_RESET vo_vdpau is the only VO which implements VOCTRL_RESET. Redrawing the last output frame is hard, because the output could consist of several source video frames with certain types of post-processing (deinterlacing). Implement redrawing as special case by keeping the previous video frames aside until at least one new frame is decoded. This improves the previous commit, but is separate, because it's rather complicated.
2013-10-01 23:45:30 +02:00
static void forget_frames(struct vo *vo, bool seek_reset)
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 vdpctx *vc = vo->priv;
video: move video frame queue from vo_vdpau.c to vo.c Remove the special casing of vo_vdpau vs. other VOs. Replace the complicated interaction between vo.c and vo_vdpau.c with a simple queue in vo.c. VOs other than vdpau are handled by setting the length of the queue to 1 (this is essentially what waiting_mpi was). Note that vo_vdpau.c seems to have buffered only 1 or 2 frames into the future, while the remaining 3 or 4 frames were past frames. So the new code buffers 2 frames (vo_vdpau.c requests this queue length by setting vo->max_video_queue to 2). It should probably be investigated why vo_vdpau.c kept so many past frames. The field vo->redrawing is removed. I'm not really sure what that would be needed for; it seems pointless. Future directions include making the interface between playloop and VO simpler, as well as making rendering a frame a single operation, as opposed to the weird 3-step sequence of rendering, drawing OSD, and flipping.
2014-04-29 15:19:03 +02:00
if (!seek_reset)
mp_image_unrefp(&vc->current_image);
vo_vdpau: don't blank screen on VOCTRL_RESET vo_vdpau is the only VO which implements VOCTRL_RESET. Redrawing the last output frame is hard, because the output could consist of several source video frames with certain types of post-processing (deinterlacing). Implement redrawing as special case by keeping the previous video frames aside until at least one new frame is decoded. This improves the previous commit, but is separate, because it's rather complicated.
2013-10-01 23:45:30 +02:00
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
vc->dropped_frame = false;
Add support for VDPAU video out, including hardware decoding. git-svn-id: svn://svn.mplayerhq.hu/mplayer/trunk@28617 b3059339-0415-0410-9bf9-f77b7e298cf2
2009-02-16 21:58:13 +01:00
}
vo_vdpau: Make compile as new-style VO
2009-05-04 02:09:50 +02:00
static void resize(struct vo *vo)
Add support for VDPAU video out, including hardware decoding. git-svn-id: svn://svn.mplayerhq.hu/mplayer/trunk@28617 b3059339-0415-0410-9bf9-f77b7e298cf2
2009-02-16 21:58:13 +01:00
{
vo_vdpau: Replace global function table with context variable
2009-05-06 20:04:37 +02:00
struct vdpctx *vc = vo->priv;
struct vdp_functions *vdp = vc->vdp;
Add support for VDPAU video out, including hardware decoding. git-svn-id: svn://svn.mplayerhq.hu/mplayer/trunk@28617 b3059339-0415-0410-9bf9-f77b7e298cf2
2009-02-16 21:58:13 +01:00
VdpStatus vdp_st;
VO: remove code duplication for setting up mp_osd_res vo_opengl, vo_vdpau, vo_direct3d had the code for setting up mp_osd_res duplicated. Make things simpler by making calc_src_dst_rects() setup the full mp_osd_res structure, instead of just "borders". Also, rename that function to vo_get_src_dst_rects(), and make it use mp_rect. Remove vo_rect, which was annoying because it contains redundant members (width/height additional to right/bottom). Add code to print the video rect etc. in verbose mode. There should be no actual change how the video rects are calculated. The only exception are the bottom/right subtitle margins, which are now computed slightly differently, but that shouldn't matter.
2012-10-27 22:10:32 +02:00
struct mp_rect src_rect;
struct mp_rect dst_rect;
vo_get_src_dst_rects(vo, &src_rect, &dst_rect, &vc->osd_rect);
vc->out_rect_vid.x0 = dst_rect.x0;
vc->out_rect_vid.x1 = dst_rect.x1;
vc->out_rect_vid.y0 = dst_rect.y0;
vc->out_rect_vid.y1 = dst_rect.y1;
vc->src_rect_vid.x0 = src_rect.x0;
vc->src_rect_vid.x1 = src_rect.x1;
vc->src_rect_vid.y0 = vc->flip ? src_rect.y1 : src_rect.y0;
vc->src_rect_vid.y1 = vc->flip ? src_rect.y0 : src_rect.y1;
sub, VO: remove vo_osd_resized() function VOs which could render the OSD in window size (as opposed to video size, like vo_xv) and which could cache the OSD called this when the window size changed. This was needed, because VOs used another OSD function to check whether the OSD changed before passing the new window size to the OSD code. This was really just an artifact of OSD change detection, and now that the affected VOs use the new OSD rendering API, it's done automatically.
2012-10-04 17:16:28 +02:00
video: remove fullscreen flags chaos There was a MPOpts fullscreen field, a mp_vo_opts.fs field, and VOFLAG_FULLSCREEN. Remove all these and introduce a mp_vo_opts.fullscreen flag instead. When VOs receive VOCTRL_FULLSCREEN, they are supposed to set the current fullscreen mode to the state in mp_vo_opts.fullscreen. They also should do this implicitly on config(). VOs which are capable of doing so can update the mp_vo_opts.fullscreen if the actual fullscreen mode changes (e.g. if the user uses the window manager controls). If fullscreen mode switching fails, they can also set mp_vo_opts.fullscreen to the actual state. Note that the X11 backend does almost none of this, and it has a private fs flag to store the fullscreen flag, instead of getting it from the WM. (Possibly because it has to deal with broken WMs.) The fullscreen option has to be checked on config() to deal with the -fs option, especially with something like: mpv --fs file1.mkv --{ --no-fs file2.mkv --} (It should start in fullscreen mode, but go to windowed mode when playing file2.mkv.) Wayland changes by: Alexander Preisinger <alexander.preisinger@gmail.com> Cocoa changes by: Stefano Pigozzi <stefano.pigozzi@gmail.com>
2013-07-18 14:05:39 +02:00
int flip_offset_ms = vo->opts->fullscreen ?
vo: remove and cleanup globals Removes almost every global variabel in vo.h and puts them in a special struct in MPOpts for video output related options. Also we completly remove the options/globals pts and refresh rate because they were unused.
2013-03-04 17:40:21 +01:00
vc->flip_offset_fs :
vc->flip_offset_window;
vo_vdpau: make queuing future frame flips adjustable Add -vo vdpau suboptions "queuetime_windowed" and "queuetime_fs" to specify the maximum number of milliseconds how far into the future a frame flip can be queued using the VDPAU presentation queue functionality. The intended main use of these options is to allow disabling use of the queuing feature on systems where using it causes choppiness in other graphics behavior (this is an NVIDIA driver issue; the video itself isn't affected).
2010-02-05 19:13:33 +01:00
vo->flip_queue_offset = flip_offset_ms / 1000.;
Add support for VDPAU video out, including hardware decoding. git-svn-id: svn://svn.mplayerhq.hu/mplayer/trunk@28617 b3059339-0415-0410-9bf9-f77b7e298cf2
2009-02-16 21:58:13 +01:00
vo_vdpau: fix screenshots Attempting to take screenshots printed vdpau errors on the terminal, and the resulting screenshots were filled with black. The problem was that that the screenshot code tried to use an unallocated output surface (the one at vc->output_surfaces[vc->num_output_surfaces]). This used to refer to the last allocated surface, until this was changed by a recently merged commit. That commit also added a separate screenshot surface. The merge somehow went wrong, and that part was not integrated. <uau> wm4: you used an earlier buggy version of a commit OK...
2012-10-21 00:48:01 +02:00
if (vc->output_surface_width < vo->dwidth
|| vc->output_surface_height < vo->dheight) {
if (vc->output_surface_width < vo->dwidth) {
vo_vdpau: Move things to context struct
2009-05-06 22:42:24 +02:00
vc->output_surface_width += vc->output_surface_width >> 1;
vo_vdpau.c: cosmetics
2009-05-09 17:08:30 +02:00
vc->output_surface_width = FFMAX(vc->output_surface_width,
vo_vdpau: fix screenshots Attempting to take screenshots printed vdpau errors on the terminal, and the resulting screenshots were filled with black. The problem was that that the screenshot code tried to use an unallocated output surface (the one at vc->output_surfaces[vc->num_output_surfaces]). This used to refer to the last allocated surface, until this was changed by a recently merged commit. That commit also added a separate screenshot surface. The merge somehow went wrong, and that part was not integrated. <uau> wm4: you used an earlier buggy version of a commit OK...
2012-10-21 00:48:01 +02:00
vo->dwidth);
Add support for VDPAU video out, including hardware decoding. git-svn-id: svn://svn.mplayerhq.hu/mplayer/trunk@28617 b3059339-0415-0410-9bf9-f77b7e298cf2
2009-02-16 21:58:13 +01:00
}
vo_vdpau: fix screenshots Attempting to take screenshots printed vdpau errors on the terminal, and the resulting screenshots were filled with black. The problem was that that the screenshot code tried to use an unallocated output surface (the one at vc->output_surfaces[vc->num_output_surfaces]). This used to refer to the last allocated surface, until this was changed by a recently merged commit. That commit also added a separate screenshot surface. The merge somehow went wrong, and that part was not integrated. <uau> wm4: you used an earlier buggy version of a commit OK...
2012-10-21 00:48:01 +02:00
if (vc->output_surface_height < vo->dheight) {
vo_vdpau: Move things to context struct
2009-05-06 22:42:24 +02:00
vc->output_surface_height += vc->output_surface_height >> 1;
vo_vdpau.c: cosmetics
2009-05-09 17:08:30 +02:00
vc->output_surface_height = FFMAX(vc->output_surface_height,
vo_vdpau: fix screenshots Attempting to take screenshots printed vdpau errors on the terminal, and the resulting screenshots were filled with black. The problem was that that the screenshot code tried to use an unallocated output surface (the one at vc->output_surfaces[vc->num_output_surfaces]). This used to refer to the last allocated surface, until this was changed by a recently merged commit. That commit also added a separate screenshot surface. The merge somehow went wrong, and that part was not integrated. <uau> wm4: you used an earlier buggy version of a commit OK...
2012-10-21 00:48:01 +02:00
vo->dheight);
Add support for VDPAU video out, including hardware decoding. git-svn-id: svn://svn.mplayerhq.hu/mplayer/trunk@28617 b3059339-0415-0410-9bf9-f77b7e298cf2
2009-02-16 21:58:13 +01:00
}
// Creation of output_surfaces
vo_vdpau: split bitmap packing code into a separate file Split the vo_vdpau code that calculates how to pack all subtitle bitmaps into a larger surface into a separate file. This will allow using it in other VOs. Conflicts: Makefile libvo/vo_vdpau.c Note: this commit does the same as an earlier commit by me (4010dd0b1a27e3996). My commit added the vo_vdpau packer code as eosd_packer.c, while this commit by uau uses bitmap_packer.c. Since bitmap_packer.c has a different interface, and because there are more commits changing OSD rendering coming, I will pick uau's version. However, vo_gl, vo_gl3 and vo_direct3d are still using eosd_packer.c, so to make the transition easier, don't delete eosd_packer.c yet.
2012-08-26 18:00:26 +02:00
for (int i = 0; i < vc->num_output_surfaces; i++)
vo_vdpau: fix loop initializing output surfaces as invalid The loop initializing handles in the output surface table to VDP_INVALID_HANDLE ran over indices from 0 to vc->num_output_surfaces. However it is first called before that variable is initialized. As a result later code could try to destroy the handles which still had the "non-invalid" value 0. Most likely this caused no visible effects; at least on my machine no valid surface gets handle 0, and libvdpau just returns an error for the resulting invalid calls. Change the code to loop over the whole table. Also add code to print visible warnings if libvdpau rejects a surface destroy call (some other places already had checks but not all).
2010-05-26 07:54:09 +02:00
if (vc->output_surfaces[i] != VDP_INVALID_HANDLE) {
vdp_st = vdp->output_surface_destroy(vc->output_surfaces[i]);
vdpau: mp_msg conversions
2013-12-21 18:05:23 +01:00
CHECK_VDP_WARNING(vo, "Error when calling "
"vdp_output_surface_destroy");
vo_vdpau: fix loop initializing output surfaces as invalid The loop initializing handles in the output surface table to VDP_INVALID_HANDLE ran over indices from 0 to vc->num_output_surfaces. However it is first called before that variable is initialized. As a result later code could try to destroy the handles which still had the "non-invalid" value 0. Most likely this caused no visible effects; at least on my machine no valid surface gets handle 0, and libvdpau just returns an error for the resulting invalid calls. Change the code to loop over the whole table. Also add code to print visible warnings if libvdpau rejects a surface destroy call (some other places already had checks but not all).
2010-05-26 07:54:09 +02:00
}
vo_vdpau: split bitmap packing code into a separate file Split the vo_vdpau code that calculates how to pack all subtitle bitmaps into a larger surface into a separate file. This will allow using it in other VOs. Conflicts: Makefile libvo/vo_vdpau.c Note: this commit does the same as an earlier commit by me (4010dd0b1a27e3996). My commit added the vo_vdpau packer code as eosd_packer.c, while this commit by uau uses bitmap_packer.c. Since bitmap_packer.c has a different interface, and because there are more commits changing OSD rendering coming, I will pick uau's version. However, vo_gl, vo_gl3 and vo_direct3d are still using eosd_packer.c, so to make the transition easier, don't delete eosd_packer.c yet.
2012-08-26 18:00:26 +02:00
for (int i = 0; i < vc->num_output_surfaces; i++) {
vo_vdpau.c: cosmetics
2009-05-09 17:08:30 +02:00
vdp_st = vdp->output_surface_create(vc->vdp_device,
vo_vdpau: implement screenshots
2011-10-06 20:46:01 +02:00
OUTPUT_RGBA_FORMAT,
vo_vdpau.c: cosmetics
2009-05-09 17:08:30 +02:00
vc->output_surface_width,
vc->output_surface_height,
&vc->output_surfaces[i]);
vdpau: mp_msg conversions
2013-12-21 18:05:23 +01:00
CHECK_VDP_WARNING(vo, "Error when calling vdp_output_surface_create");
Some more mp_msg conversions Also add a note to mp_msg.h, since it might be not clear which of the two mechanisms is preferred.
2013-08-23 23:30:09 +02:00
MP_DBG(vo, "vdpau out create: %u\n",
vo_vdpau.c: cosmetics
2009-05-09 17:08:30 +02:00
vc->output_surfaces[i]);
Add support for VDPAU video out, including hardware decoding. git-svn-id: svn://svn.mplayerhq.hu/mplayer/trunk@28617 b3059339-0415-0410-9bf9-f77b7e298cf2
2009-02-16 21:58:13 +01:00
}
}
core, vo: new window refresh logic, add slow-video OSD redraw Remove code refreshing window contents after events such as resize from vo_vdpau, vo_gl and vo_xv. Instead have them simply set a flag indicating that a refresh is needed, and have the player core perform that refresh by doing an OSD redraw. Also add support for updating the OSD contents over existing frames during slow-but-not-paused playback. The VOs now also request a refresh if parameters affecting the picture change (equalizer settings, colormatrix, VDPAU deinterlacing setting). Even previously the picture was typically redrawn with the new settings while paused because new OSD messages associated with setting changes triggered a redraw, but this did not happen if OSD was turned off. A minor imperfection is that now window system events can trigger a single one-frame step forward when using vo_xv after pausing so that vo_xv does not yet have a copy of the current image. This could be fixed but I think it's not important enough to bother.
2011-12-05 05:36:20 +01:00
vo->want_redraw = true;
Add support for VDPAU video out, including hardware decoding. git-svn-id: svn://svn.mplayerhq.hu/mplayer/trunk@28617 b3059339-0415-0410-9bf9-f77b7e298cf2
2009-02-16 21:58:13 +01:00
}
vo_vdpau: Make compile as new-style VO
2009-05-04 02:09:50 +02:00
static int win_x11_init_vdpau_flip_queue(struct vo *vo)
Add support for VDPAU video out, including hardware decoding. git-svn-id: svn://svn.mplayerhq.hu/mplayer/trunk@28617 b3059339-0415-0410-9bf9-f77b7e298cf2
2009-02-16 21:58:13 +01:00
{
vo_vdpau: Replace global function table with context variable
2009-05-06 20:04:37 +02:00
struct vdpctx *vc = vo->priv;
struct vdp_functions *vdp = vc->vdp;
vo_vdpau: Make compile as new-style VO
2009-05-04 02:09:50 +02:00
struct vo_x11_state *x11 = vo->x11;
Add support for VDPAU video out, including hardware decoding. git-svn-id: svn://svn.mplayerhq.hu/mplayer/trunk@28617 b3059339-0415-0410-9bf9-f77b7e298cf2
2009-02-16 21:58:13 +01:00
VdpStatus vdp_st;
vo_vdpau: Support recovering from VDPAU display preemption Add code to reinitialize all VDPAU objects if a display preemption condition occurs. Reinitializing them in the middle of playback will cause video corruption at least until the next keyframe when using hardware decoding, but decoding does seem to recover after a keyframe.
2009-09-07 01:02:24 +02:00
if (vc->flip_target == VDP_INVALID_HANDLE) {
vdp_st = vdp->presentation_queue_target_create_x11(vc->vdp_device,
x11->window,
&vc->flip_target);
vdpau: mp_msg conversions
2013-12-21 18:05:23 +01:00
CHECK_VDP_ERROR(vo, "Error when calling "
"vdp_presentation_queue_target_create_x11");
vo_vdpau: Support recovering from VDPAU display preemption Add code to reinitialize all VDPAU objects if a display preemption condition occurs. Reinitializing them in the middle of playback will cause video corruption at least until the next keyframe when using hardware decoding, but decoding does seem to recover after a keyframe.
2009-09-07 01:02:24 +02:00
}
Add support for VDPAU video out, including hardware decoding. git-svn-id: svn://svn.mplayerhq.hu/mplayer/trunk@28617 b3059339-0415-0410-9bf9-f77b7e298cf2
2009-02-16 21:58:13 +01:00
vo_vdpau: Support recovering from VDPAU display preemption Add code to reinitialize all VDPAU objects if a display preemption condition occurs. Reinitializing them in the middle of playback will cause video corruption at least until the next keyframe when using hardware decoding, but decoding does seem to recover after a keyframe.
2009-09-07 01:02:24 +02:00
/* Emperically this seems to be the first call which fails when we
* try to reinit after preemption while the user is still switched
* from X to a virtual terminal (creating the vdp_device initially
* succeeds, as does creating the flip_target above). This is
* probably not guaranteed behavior, but we'll assume it as a simple
* way to reduce warnings while trying to recover from preemption.
*/
if (vc->flip_queue == VDP_INVALID_HANDLE) {
vdp_st = vdp->presentation_queue_create(vc->vdp_device, vc->flip_target,
&vc->flip_queue);
vdpau: move device and video surface management from vo_vdpau.c to vdpau.c The goal is being able to use vdpau decoding independently from vo_vdpau.c.
2013-11-05 22:06:32 +01:00
if (vc->mpvdp->is_preempted && vdp_st != VDP_STATUS_OK) {
Some more mp_msg conversions Also add a note to mp_msg.h, since it might be not clear which of the two mechanisms is preferred.
2013-08-23 23:30:09 +02:00
MP_DBG(vo, "Failed to create flip queue while preempted: %s\n",
vdp->get_error_string(vdp_st));
vo_vdpau: Support recovering from VDPAU display preemption Add code to reinitialize all VDPAU objects if a display preemption condition occurs. Reinitializing them in the middle of playback will cause video corruption at least until the next keyframe when using hardware decoding, but decoding does seem to recover after a keyframe.
2009-09-07 01:02:24 +02:00
return -1;
} else
vdpau: mp_msg conversions
2013-12-21 18:05:23 +01:00
CHECK_VDP_ERROR(vo, "Error when calling vdp_presentation_queue_create");
vo_vdpau: Support recovering from VDPAU display preemption Add code to reinitialize all VDPAU objects if a display preemption condition occurs. Reinitializing them in the middle of playback will cause video corruption at least until the next keyframe when using hardware decoding, but decoding does seem to recover after a keyframe.
2009-09-07 01:02:24 +02:00
}
Add support for VDPAU video out, including hardware decoding. git-svn-id: svn://svn.mplayerhq.hu/mplayer/trunk@28617 b3059339-0415-0410-9bf9-f77b7e298cf2
2009-02-16 21:58:13 +01:00
vo_vdpau: allow setting colorkey Formally, this sets the "background color" of the presentation queue. But in practice, this color is also used as colorkey. This commit doesn't change the VDPAU default yet.
2013-08-17 19:57:18 +02:00
if (vc->colorkey.a > 0) {
VdpColor color = {
.red = vc->colorkey.r / 255.0,
.green = vc->colorkey.g / 255.0,
.blue = vc->colorkey.b / 255.0,
.alpha = 0,
};
vdp_st = vdp->presentation_queue_set_background_color(vc->flip_queue,
&color);
vdpau: mp_msg conversions
2013-12-21 18:05:23 +01:00
CHECK_VDP_WARNING(vo, "Error setting colorkey");
vo_vdpau: allow setting colorkey Formally, this sets the "background color" of the presentation queue. But in practice, this color is also used as colorkey. This commit doesn't change the VDPAU default yet.
2013-08-17 19:57:18 +02:00
}
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
vc->vsync_interval = 1;
vo_vdpau: disable refresh-aware frame timing when composited Under a compositing window manager the current VDPAU implementation behaves differently than without it. Frame flip timing info becomes incorrect (I guess it only reflects when the frame was sent to the compositor, not when it was actually shown), and there is no limitation to at most one frame switch per refresh like without compositing. Detect whether a compositing window manager is active and disable refresh-aware frame timing and dropping in this case, similarly to what fps=-1 would do. This behavior can be controlled with the new suboption "composite-detect". Disabling the refresh-aware logic makes timing somewhat less accurate. Because the video switch rate limit isn't there, the lack of frame dropping on player side does not impose a hard limit on video FPS, but does reduce performance somewhat as redundant frames are drawn in memory. The existence of a compositing window manager does not guarantee that the current window is actually composited, so the current check is not foolproof. In particular, some WMs have support for a "unredirect fullscreen windows" option. Support for such things could be improved.
2012-07-27 02:40:38 +02:00
if (vc->composite_detect && vo_x11_screen_is_composited(vo)) {
Some more mp_msg conversions Also add a note to mp_msg.h, since it might be not clear which of the two mechanisms is preferred.
2013-08-23 23:30:09 +02:00
MP_INFO(vo, "Compositing window manager detected. Assuming timing info "
"is inaccurate.\n");
vo_vdpau: disable refresh-aware frame timing when composited Under a compositing window manager the current VDPAU implementation behaves differently than without it. Frame flip timing info becomes incorrect (I guess it only reflects when the frame was sent to the compositor, not when it was actually shown), and there is no limitation to at most one frame switch per refresh like without compositing. Detect whether a compositing window manager is active and disable refresh-aware frame timing and dropping in this case, similarly to what fps=-1 would do. This behavior can be controlled with the new suboption "composite-detect". Disabling the refresh-aware logic makes timing somewhat less accurate. Because the video switch rate limit isn't there, the lack of frame dropping on player side does not impose a hard limit on video FPS, but does reduce performance somewhat as redundant frames are drawn in memory. The existence of a compositing window manager does not guarantee that the current window is actually composited, so the current check is not foolproof. In particular, some WMs have support for a "unredirect fullscreen windows" option. Support for such things could be improved.
2012-07-27 02:40:38 +02:00
} else if (vc->user_fps > 0) {
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
vc->vsync_interval = 1e9 / vc->user_fps;
Some more mp_msg conversions Also add a note to mp_msg.h, since it might be not clear which of the two mechanisms is preferred.
2013-08-23 23:30:09 +02:00
MP_INFO(vo, "Assuming user-specified display refresh rate of %.3f Hz.\n",
vc->user_fps);
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
} else if (vc->user_fps == 0) {
configure: uniform the defines to #define HAVE_xxx (0|1) The configure followed 5 different convetions of defines because the next guy always wanted to introduce a new better way to uniform it[1]. For an hypothetic feature 'hurr' you could have had: * #define HAVE_HURR 1 / #undef HAVE_DURR * #define HAVE_HURR / #undef HAVE_DURR * #define CONFIG_HURR 1 / #undef CONFIG_DURR * #define HAVE_HURR 1 / #define HAVE_DURR 0 * #define CONFIG_HURR 1 / #define CONFIG_DURR 0 All is now uniform and uses: * #define HAVE_HURR 1 * #define HAVE_DURR 0 We like definining to 0 as opposed to `undef` bcause it can help spot typos and is very helpful when doing big reorganizations in the code. [1]: http://xkcd.com/927/ related
2013-07-16 13:28:28 +02:00
#if HAVE_XF86VM
x11: reduce VO mode switching code duplication Some parts for initiating mode switches were duplicated in every VO supporting X11 (except vo_opengl/gl_common, which didn't support mode switching). Move this to x11_common.c. Note that this might be slightly risky: is it really guaranteed that no VO needed to do "special" setup that depends on X parameters changing after a mode switch, such as bit depth, visuals etc.? From what I can see, this shouldn't be the case (X probably can't even change depth on the fly). Even if this should be a one-way road, VM switching is in general very useless, and its implementation buggy, so it can just be removed should unfixable problems arise.
2013-01-27 07:21:10 +01:00
double fps = vo_x11_vm_get_fps(vo);
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 (!fps)
Some more mp_msg conversions Also add a note to mp_msg.h, since it might be not clear which of the two mechanisms is preferred.
2013-08-23 23:30:09 +02:00
MP_WARN(vo, "Failed to get display FPS\n");
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
else {
vc->vsync_interval = 1e9 / fps;
// This is verbose, but I'm not yet sure how common wrong values are
Some more mp_msg conversions Also add a note to mp_msg.h, since it might be not clear which of the two mechanisms is preferred.
2013-08-23 23:30:09 +02:00
MP_INFO(vo, "Got display refresh rate %.3f Hz.\n", fps);
MP_INFO(vo, "If that value looks wrong give the "
"-vo vdpau:fps=X suboption manually.\n");
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
}
#else
Some more mp_msg conversions Also add a note to mp_msg.h, since it might be not clear which of the two mechanisms is preferred.
2013-08-23 23:30:09 +02:00
MP_INFO(vo, "This binary has been compiled without XF86VidMode support.\n");
MP_INFO(vo, "Can't use vsync-aware timing without manually provided "
"-vo vdpau:fps=X suboption.\n");
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
#endif
} else
Some more mp_msg conversions Also add a note to mp_msg.h, since it might be not clear which of the two mechanisms is preferred.
2013-08-23 23:30:09 +02:00
MP_VERBOSE(vo, "framedrop/timing logic disabled by user.\n");
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
Add support for VDPAU video out, including hardware decoding. git-svn-id: svn://svn.mplayerhq.hu/mplayer/trunk@28617 b3059339-0415-0410-9bf9-f77b7e298cf2
2009-02-16 21:58:13 +01:00
return 0;
}
// Free everything specific to a certain video file
vo_vdpau: Replace global function table with context variable
2009-05-06 20:04:37 +02:00
static void free_video_specific(struct vo *vo)
{
struct vdpctx *vc = vo->priv;
struct vdp_functions *vdp = vc->vdp;
Add support for VDPAU video out, including hardware decoding. git-svn-id: svn://svn.mplayerhq.hu/mplayer/trunk@28617 b3059339-0415-0410-9bf9-f77b7e298cf2
2009-02-16 21:58:13 +01:00
VdpStatus vdp_st;
vo_vdpau: don't blank screen on VOCTRL_RESET vo_vdpau is the only VO which implements VOCTRL_RESET. Redrawing the last output frame is hard, because the output could consist of several source video frames with certain types of post-processing (deinterlacing). Implement redrawing as special case by keeping the previous video frames aside until at least one new frame is decoded. This improves the previous commit, but is separate, because it's rather complicated.
2013-10-01 23:45:30 +02:00
forget_frames(vo, false);
Allow to use vdpau temporal deinterlacers with hardware accelerated decoding. git-svn-id: svn://svn.mplayerhq.hu/mplayer/trunk@28991 b3059339-0415-0410-9bf9-f77b7e298cf2
2009-03-18 18:02:29 +01:00
vo_vdpau: fix screenshots Attempting to take screenshots printed vdpau errors on the terminal, and the resulting screenshots were filled with black. The problem was that that the screenshot code tried to use an unallocated output surface (the one at vc->output_surfaces[vc->num_output_surfaces]). This used to refer to the last allocated surface, until this was changed by a recently merged commit. That commit also added a separate screenshot surface. The merge somehow went wrong, and that part was not integrated. <uau> wm4: you used an earlier buggy version of a commit OK...
2012-10-21 00:48:01 +02:00
if (vc->screenshot_surface != VDP_INVALID_HANDLE) {
vdp_st = vdp->output_surface_destroy(vc->screenshot_surface);
vdpau: mp_msg conversions
2013-12-21 18:05:23 +01:00
CHECK_VDP_WARNING(vo, "Error when calling vdp_output_surface_destroy");
vo_vdpau: fix screenshots Attempting to take screenshots printed vdpau errors on the terminal, and the resulting screenshots were filled with black. The problem was that that the screenshot code tried to use an unallocated output surface (the one at vc->output_surfaces[vc->num_output_surfaces]). This used to refer to the last allocated surface, until this was changed by a recently merged commit. That commit also added a separate screenshot surface. The merge somehow went wrong, and that part was not integrated. <uau> wm4: you used an earlier buggy version of a commit OK...
2012-10-21 00:48:01 +02:00
}
vc->screenshot_surface = VDP_INVALID_HANDLE;
vo_vdpau: add RGB support Apparently this was dropped some years ago, but judging from MPlayer's handling of this, the original code wasn't so great anyway. The new code handling clearing of panscan borders correctly, and integrates better with the YUV path. (Although the VDPAU API sure makes this annoying with its separate surface types for RGB.) Note that we create 5 surfaces for some reason - I don't think this makes too much sense (because we can't use the deinterlacer with RGB surfaces), but at least it reduces the amount of differences with the YUV code path. Clearing the borders is done by drawing a single black pixel over the window. This sounds pretty dumb, but it appears to work well, and there is no other API for that. (One could try to use the video mixer for this purpose, since it has all kinds of features, including compositing multiple RGBA surfaces and clearing the window background. But it would require an invisible dummy video surface to make the video mixer happy, and that's getting too messy.)
2013-08-18 05:12:21 +02:00
for (int n = 0; n < NUM_BUFFERED_VIDEO; n++) {
vo_vdpau: always use mp_image for internal buffer queue
2014-04-29 15:18:35 +02:00
assert(!vc->rgb_surfaces_used[n]);
vo_vdpau: add RGB support Apparently this was dropped some years ago, but judging from MPlayer's handling of this, the original code wasn't so great anyway. The new code handling clearing of panscan borders correctly, and integrates better with the YUV path. (Although the VDPAU API sure makes this annoying with its separate surface types for RGB.) Note that we create 5 surfaces for some reason - I don't think this makes too much sense (because we can't use the deinterlacer with RGB surfaces), but at least it reduces the amount of differences with the YUV code path. Clearing the borders is done by drawing a single black pixel over the window. This sounds pretty dumb, but it appears to work well, and there is no other API for that. (One could try to use the video mixer for this purpose, since it has all kinds of features, including compositing multiple RGBA surfaces and clearing the window background. But it would require an invisible dummy video surface to make the video mixer happy, and that's getting too messy.)
2013-08-18 05:12:21 +02:00
if (vc->rgb_surfaces[n] != VDP_INVALID_HANDLE) {
vdp_st = vdp->output_surface_destroy(vc->rgb_surfaces[n]);
vdpau: mp_msg conversions
2013-12-21 18:05:23 +01:00
CHECK_VDP_WARNING(vo, "Error when calling vdp_output_surface_destroy");
vo_vdpau: add RGB support Apparently this was dropped some years ago, but judging from MPlayer's handling of this, the original code wasn't so great anyway. The new code handling clearing of panscan borders correctly, and integrates better with the YUV path. (Although the VDPAU API sure makes this annoying with its separate surface types for RGB.) Note that we create 5 surfaces for some reason - I don't think this makes too much sense (because we can't use the deinterlacer with RGB surfaces), but at least it reduces the amount of differences with the YUV code path. Clearing the borders is done by drawing a single black pixel over the window. This sounds pretty dumb, but it appears to work well, and there is no other API for that. (One could try to use the video mixer for this purpose, since it has all kinds of features, including compositing multiple RGBA surfaces and clearing the window background. But it would require an invisible dummy video surface to make the video mixer happy, and that's getting too messy.)
2013-08-18 05:12:21 +02:00
}
vc->rgb_surfaces[n] = VDP_INVALID_HANDLE;
}
if (vc->black_pixel != VDP_INVALID_HANDLE) {
vdp_st = vdp->output_surface_destroy(vc->black_pixel);
vdpau: mp_msg conversions
2013-12-21 18:05:23 +01:00
CHECK_VDP_WARNING(vo, "Error when calling vdp_output_surface_destroy");
vo_vdpau: add RGB support Apparently this was dropped some years ago, but judging from MPlayer's handling of this, the original code wasn't so great anyway. The new code handling clearing of panscan borders correctly, and integrates better with the YUV path. (Although the VDPAU API sure makes this annoying with its separate surface types for RGB.) Note that we create 5 surfaces for some reason - I don't think this makes too much sense (because we can't use the deinterlacer with RGB surfaces), but at least it reduces the amount of differences with the YUV code path. Clearing the borders is done by drawing a single black pixel over the window. This sounds pretty dumb, but it appears to work well, and there is no other API for that. (One could try to use the video mixer for this purpose, since it has all kinds of features, including compositing multiple RGBA surfaces and clearing the window background. But it would require an invisible dummy video surface to make the video mixer happy, and that's getting too messy.)
2013-08-18 05:12:21 +02:00
}
vc->black_pixel = VDP_INVALID_HANDLE;
}
static int get_rgb_format(int imgfmt)
{
switch (imgfmt) {
case IMGFMT_BGR32: return VDP_RGBA_FORMAT_B8G8R8A8;
default: return -1;
}
Add support for VDPAU video out, including hardware decoding. git-svn-id: svn://svn.mplayerhq.hu/mplayer/trunk@28617 b3059339-0415-0410-9bf9-f77b7e298cf2
2009-02-16 21:58:13 +01:00
}
cosmetics: Add two missing "static" Add missing 'static' to internal functions in vo_xv.c and vo_vdpau.c.
2009-10-22 03:21:14 +02:00
static int initialize_vdpau_objects(struct vo *vo)
vo_vdpau: Support recovering from VDPAU display preemption Add code to reinitialize all VDPAU objects if a display preemption condition occurs. Reinitializing them in the middle of playback will cause video corruption at least until the next keyframe when using hardware decoding, but decoding does seem to recover after a keyframe.
2009-09-07 01:02:24 +02:00
{
struct vdpctx *vc = vo->priv;
vo_vdpau: add RGB support Apparently this was dropped some years ago, but judging from MPlayer's handling of this, the original code wasn't so great anyway. The new code handling clearing of panscan borders correctly, and integrates better with the YUV path. (Although the VDPAU API sure makes this annoying with its separate surface types for RGB.) Note that we create 5 surfaces for some reason - I don't think this makes too much sense (because we can't use the deinterlacer with RGB surfaces), but at least it reduces the amount of differences with the YUV code path. Clearing the borders is done by drawing a single black pixel over the window. This sounds pretty dumb, but it appears to work well, and there is no other API for that. (One could try to use the video mixer for this purpose, since it has all kinds of features, including compositing multiple RGBA surfaces and clearing the window background. But it would require an invisible dummy video surface to make the video mixer happy, and that's getting too messy.)
2013-08-18 05:12:21 +02:00
struct vdp_functions *vdp = vc->vdp;
VdpStatus vdp_st;
vo_vdpau: Support recovering from VDPAU display preemption Add code to reinitialize all VDPAU objects if a display preemption condition occurs. Reinitializing them in the middle of playback will cause video corruption at least until the next keyframe when using hardware decoding, but decoding does seem to recover after a keyframe.
2009-09-07 01:02:24 +02:00
vdpau: split off decoder parts, use "new" libavcodec vdpau hwaccel API Move the decoder parts from vo_vdpau.c to a new file vdpau_old.c. This file is named so because because it's written against the "old" libavcodec vdpau pseudo-decoder (e.g. "h264_vdpau"). Add support for the "new" libavcodec vdpau support. This was recently added and replaces the "old" vdpau parts. (In fact, Libav is about to deprecate and remove the "old" API without deprecation grace period, so we have to support it now. Moreover, there will probably be no Libav release which supports both, so the transition is even less smooth than we could hope, and we have to support both the old and new API.) Whether the old or new API is used is checked by a configure test: if the new API is found, it is used, otherwise the old API is assumed. Some details might be handled differently. Especially display preemption is a bit problematic with the "new" libavcodec vdpau support: it wants to keep a pointer to a specific vdpau API function (which can be driver specific, because preemption might switch drivers). Also, surface IDs are now directly stored in AVFrames (and mp_images), so they can't be forced to VDP_INVALID_HANDLE on preemption. (This changes even with older libavcodec versions, because mp_image always uses the newer representation to make vo_vdpau.c simpler.) Decoder initialization in the new code tries to deal with codec profiles, while the old code always uses the highest profile per codec. Surface allocation changes. Since the decoder won't call config() in vo_vdpau.c on video size change anymore, we allow allocating surfaces of arbitrary size instead of locking it to what the VO was configured. The non-hwdec code also has slightly different allocation behavior now. Enabling the old vdpau special decoders via e.g. --vd=lavc:h264_vdpau doesn't work anymore (a warning suggesting the --hwdec option is printed instead).
2013-07-28 01:49:45 +02:00
mp_vdpau_get_format(vc->image_format, &vc->vdp_chroma_type,
&vc->vdp_pixel_format);
vo_vdpau: support vf_vdpaupp This is slightly incomplete: the mixer options, such as sharpen and especially deinterlacing, are ignored. This also breaks automatic enabling of interlacing with 'D' or --deinterlace. These issues will be fixed later in the following commits. Note that we keep all the custom vdpau queue stuff. This will also be simplified later.
2014-04-29 15:11:44 +02:00
vc->video_mixer->chroma_type = vc->vdp_chroma_type;
vc->video_mixer->initialized = false;
vo_vdpau: Support recovering from VDPAU display preemption Add code to reinitialize all VDPAU objects if a display preemption condition occurs. Reinitializing them in the middle of playback will cause video corruption at least until the next keyframe when using hardware decoding, but decoding does seem to recover after a keyframe.
2009-09-07 01:02:24 +02:00
if (win_x11_init_vdpau_flip_queue(vo) < 0)
return -1;
vo_vdpau: add RGB support Apparently this was dropped some years ago, but judging from MPlayer's handling of this, the original code wasn't so great anyway. The new code handling clearing of panscan borders correctly, and integrates better with the YUV path. (Although the VDPAU API sure makes this annoying with its separate surface types for RGB.) Note that we create 5 surfaces for some reason - I don't think this makes too much sense (because we can't use the deinterlacer with RGB surfaces), but at least it reduces the amount of differences with the YUV code path. Clearing the borders is done by drawing a single black pixel over the window. This sounds pretty dumb, but it appears to work well, and there is no other API for that. (One could try to use the video mixer for this purpose, since it has all kinds of features, including compositing multiple RGBA surfaces and clearing the window background. But it would require an invisible dummy video surface to make the video mixer happy, and that's getting too messy.)
2013-08-18 05:12:21 +02:00
if (vc->rgb_mode) {
int format = get_rgb_format(vc->image_format);
for (int n = 0; n < NUM_BUFFERED_VIDEO; n++) {
vdp_st = vdp->output_surface_create(vc->vdp_device,
format,
vc->vid_width, vc->vid_height,
&vc->rgb_surfaces[n]);
vdpau: mp_msg conversions
2013-12-21 18:05:23 +01:00
CHECK_VDP_ERROR(vo, "Allocating RGB surface");
vo_vdpau: add RGB support Apparently this was dropped some years ago, but judging from MPlayer's handling of this, the original code wasn't so great anyway. The new code handling clearing of panscan borders correctly, and integrates better with the YUV path. (Although the VDPAU API sure makes this annoying with its separate surface types for RGB.) Note that we create 5 surfaces for some reason - I don't think this makes too much sense (because we can't use the deinterlacer with RGB surfaces), but at least it reduces the amount of differences with the YUV code path. Clearing the borders is done by drawing a single black pixel over the window. This sounds pretty dumb, but it appears to work well, and there is no other API for that. (One could try to use the video mixer for this purpose, since it has all kinds of features, including compositing multiple RGBA surfaces and clearing the window background. But it would require an invisible dummy video surface to make the video mixer happy, and that's getting too messy.)
2013-08-18 05:12:21 +02:00
}
vdp_st = vdp->output_surface_create(vc->vdp_device, OUTPUT_RGBA_FORMAT,
1, 1, &vc->black_pixel);
vdpau: mp_msg conversions
2013-12-21 18:05:23 +01:00
CHECK_VDP_ERROR(vo, "Allocating clearing surface");
vo_vdpau: add RGB support Apparently this was dropped some years ago, but judging from MPlayer's handling of this, the original code wasn't so great anyway. The new code handling clearing of panscan borders correctly, and integrates better with the YUV path. (Although the VDPAU API sure makes this annoying with its separate surface types for RGB.) Note that we create 5 surfaces for some reason - I don't think this makes too much sense (because we can't use the deinterlacer with RGB surfaces), but at least it reduces the amount of differences with the YUV code path. Clearing the borders is done by drawing a single black pixel over the window. This sounds pretty dumb, but it appears to work well, and there is no other API for that. (One could try to use the video mixer for this purpose, since it has all kinds of features, including compositing multiple RGBA surfaces and clearing the window background. But it would require an invisible dummy video surface to make the video mixer happy, and that's getting too messy.)
2013-08-18 05:12:21 +02:00
const char data[4] = {0};
vdp_st = vdp->output_surface_put_bits_native(vc->black_pixel,
(const void*[]){data},
(uint32_t[]){4}, NULL);
vdpau: mp_msg conversions
2013-12-21 18:05:23 +01:00
CHECK_VDP_ERROR(vo, "Initializing clearing surface");
vo_vdpau: add RGB support Apparently this was dropped some years ago, but judging from MPlayer's handling of this, the original code wasn't so great anyway. The new code handling clearing of panscan borders correctly, and integrates better with the YUV path. (Although the VDPAU API sure makes this annoying with its separate surface types for RGB.) Note that we create 5 surfaces for some reason - I don't think this makes too much sense (because we can't use the deinterlacer with RGB surfaces), but at least it reduces the amount of differences with the YUV code path. Clearing the borders is done by drawing a single black pixel over the window. This sounds pretty dumb, but it appears to work well, and there is no other API for that. (One could try to use the video mixer for this purpose, since it has all kinds of features, including compositing multiple RGBA surfaces and clearing the window background. But it would require an invisible dummy video surface to make the video mixer happy, and that's getting too messy.)
2013-08-18 05:12:21 +02:00
}
vo_vdpau: Support recovering from VDPAU display preemption Add code to reinitialize all VDPAU objects if a display preemption condition occurs. Reinitializing them in the middle of playback will cause video corruption at least until the next keyframe when using hardware decoding, but decoding does seem to recover after a keyframe.
2009-09-07 01:02:24 +02:00
vo_vdpau: don't blank screen on VOCTRL_RESET vo_vdpau is the only VO which implements VOCTRL_RESET. Redrawing the last output frame is hard, because the output could consist of several source video frames with certain types of post-processing (deinterlacing). Implement redrawing as special case by keeping the previous video frames aside until at least one new frame is decoded. This improves the previous commit, but is separate, because it's rather complicated.
2013-10-01 23:45:30 +02:00
forget_frames(vo, false);
vo_vdpau: Support recovering from VDPAU display preemption Add code to reinitialize all VDPAU objects if a display preemption condition occurs. Reinitializing them in the middle of playback will cause video corruption at least until the next keyframe when using hardware decoding, but decoding does seem to recover after a keyframe.
2009-09-07 01:02:24 +02:00
resize(vo);
return 0;
}
static void mark_vdpau_objects_uninitialized(struct vo *vo)
{
struct vdpctx *vc = vo->priv;
vo_vdpau: add RGB support Apparently this was dropped some years ago, but judging from MPlayer's handling of this, the original code wasn't so great anyway. The new code handling clearing of panscan borders correctly, and integrates better with the YUV path. (Although the VDPAU API sure makes this annoying with its separate surface types for RGB.) Note that we create 5 surfaces for some reason - I don't think this makes too much sense (because we can't use the deinterlacer with RGB surfaces), but at least it reduces the amount of differences with the YUV code path. Clearing the borders is done by drawing a single black pixel over the window. This sounds pretty dumb, but it appears to work well, and there is no other API for that. (One could try to use the video mixer for this purpose, since it has all kinds of features, including compositing multiple RGBA surfaces and clearing the window background. But it would require an invisible dummy video surface to make the video mixer happy, and that's getting too messy.)
2013-08-18 05:12:21 +02:00
for (int i = 0; i < NUM_BUFFERED_VIDEO; i++)
vc->rgb_surfaces[i] = VDP_INVALID_HANDLE;
vo_vdpau: don't blank screen on VOCTRL_RESET vo_vdpau is the only VO which implements VOCTRL_RESET. Redrawing the last output frame is hard, because the output could consist of several source video frames with certain types of post-processing (deinterlacing). Implement redrawing as special case by keeping the previous video frames aside until at least one new frame is decoded. This improves the previous commit, but is separate, because it's rather complicated.
2013-10-01 23:45:30 +02:00
forget_frames(vo, false);
vo_vdpau: add RGB support Apparently this was dropped some years ago, but judging from MPlayer's handling of this, the original code wasn't so great anyway. The new code handling clearing of panscan borders correctly, and integrates better with the YUV path. (Although the VDPAU API sure makes this annoying with its separate surface types for RGB.) Note that we create 5 surfaces for some reason - I don't think this makes too much sense (because we can't use the deinterlacer with RGB surfaces), but at least it reduces the amount of differences with the YUV code path. Clearing the borders is done by drawing a single black pixel over the window. This sounds pretty dumb, but it appears to work well, and there is no other API for that. (One could try to use the video mixer for this purpose, since it has all kinds of features, including compositing multiple RGBA surfaces and clearing the window background. But it would require an invisible dummy video surface to make the video mixer happy, and that's getting too messy.)
2013-08-18 05:12:21 +02:00
vc->black_pixel = VDP_INVALID_HANDLE;
vo_vdpau: support vf_vdpaupp This is slightly incomplete: the mixer options, such as sharpen and especially deinterlacing, are ignored. This also breaks automatic enabling of interlacing with 'D' or --deinterlace. These issues will be fixed later in the following commits. Note that we keep all the custom vdpau queue stuff. This will also be simplified later.
2014-04-29 15:11:44 +02:00
vc->video_mixer->video_mixer = VDP_INVALID_HANDLE;
vo_vdpau: Support recovering from VDPAU display preemption Add code to reinitialize all VDPAU objects if a display preemption condition occurs. Reinitializing them in the middle of playback will cause video corruption at least until the next keyframe when using hardware decoding, but decoding does seem to recover after a keyframe.
2009-09-07 01:02:24 +02:00
vc->flip_queue = VDP_INVALID_HANDLE;
vc->flip_target = VDP_INVALID_HANDLE;
vo_vdpau: split bitmap packing code into a separate file Split the vo_vdpau code that calculates how to pack all subtitle bitmaps into a larger surface into a separate file. This will allow using it in other VOs. Conflicts: Makefile libvo/vo_vdpau.c Note: this commit does the same as an earlier commit by me (4010dd0b1a27e3996). My commit added the vo_vdpau packer code as eosd_packer.c, while this commit by uau uses bitmap_packer.c. Since bitmap_packer.c has a different interface, and because there are more commits changing OSD rendering coming, I will pick uau's version. However, vo_gl, vo_gl3 and vo_direct3d are still using eosd_packer.c, so to make the transition easier, don't delete eosd_packer.c yet.
2012-08-26 18:00:26 +02:00
for (int i = 0; i < MAX_OUTPUT_SURFACES; i++)
vo_vdpau: Support recovering from VDPAU display preemption Add code to reinitialize all VDPAU objects if a display preemption condition occurs. Reinitializing them in the middle of playback will cause video corruption at least until the next keyframe when using hardware decoding, but decoding does seem to recover after a keyframe.
2009-09-07 01:02:24 +02:00
vc->output_surfaces[i] = VDP_INVALID_HANDLE;
vo_vdpau: fix screenshots Attempting to take screenshots printed vdpau errors on the terminal, and the resulting screenshots were filled with black. The problem was that that the screenshot code tried to use an unallocated output surface (the one at vc->output_surfaces[vc->num_output_surfaces]). This used to refer to the last allocated surface, until this was changed by a recently merged commit. That commit also added a separate screenshot surface. The merge somehow went wrong, and that part was not integrated. <uau> wm4: you used an earlier buggy version of a commit OK...
2012-10-21 00:48:01 +02:00
vc->screenshot_surface = VDP_INVALID_HANDLE;
vo_vdpau: Support recovering from VDPAU display preemption Add code to reinitialize all VDPAU objects if a display preemption condition occurs. Reinitializing them in the middle of playback will cause video corruption at least until the next keyframe when using hardware decoding, but decoding does seem to recover after a keyframe.
2009-09-07 01:02:24 +02:00
vc->vdp_device = VDP_INVALID_HANDLE;
vo_vdpau: allow multiple EOSD renderers Preparation for using new OSD rendering method.
2012-09-28 21:49:09 +02:00
for (int i = 0; i < MAX_OSD_PARTS; i++) {
VO, sub: refactor Remove VFCTRL_DRAW_OSD, VFCAP_EOSD_FILTER, VFCAP_EOSD_RGBA, VFCAP_EOSD, VOCTRL_DRAW_EOSD, VOCTRL_GET_EOSD_RES, VOCTRL_QUERY_EOSD_FORMAT. Remove draw_osd_with_eosd(), which rendered the OSD by calling VOCTRL_DRAW_EOSD. Change VOs to call osd_draw() directly, which takes a callback as argument. (This basically works like the old OSD API, except multiple OSD bitmap formats are supported and caching is possible.) Remove all mentions of "eosd". It's simply "osd" now. Make OSD size per-OSD-object, as they can be different when using vf_sub. Include display_par/video_par in resolution change detection. Fix the issue with margin borders in vo_corevideo.
2012-10-19 19:25:18 +02:00
struct osd_bitmap_surface *sfc = &vc->osd_surfaces[i];
vo_vdpau: allow multiple EOSD renderers Preparation for using new OSD rendering method.
2012-09-28 21:49:09 +02:00
talloc_free(sfc->packer);
sfc->bitmap_id = sfc->bitmap_pos_id = 0;
VO, sub: refactor Remove VFCTRL_DRAW_OSD, VFCAP_EOSD_FILTER, VFCAP_EOSD_RGBA, VFCAP_EOSD, VOCTRL_DRAW_EOSD, VOCTRL_GET_EOSD_RES, VOCTRL_QUERY_EOSD_FORMAT. Remove draw_osd_with_eosd(), which rendered the OSD by calling VOCTRL_DRAW_EOSD. Change VOs to call osd_draw() directly, which takes a callback as argument. (This basically works like the old OSD API, except multiple OSD bitmap formats are supported and caching is possible.) Remove all mentions of "eosd". It's simply "osd" now. Make OSD size per-OSD-object, as they can be different when using vf_sub. Include display_par/video_par in resolution change detection. Fix the issue with margin borders in vo_corevideo.
2012-10-19 19:25:18 +02:00
*sfc = (struct osd_bitmap_surface){
vo_vdpau: allow multiple EOSD renderers Preparation for using new OSD rendering method.
2012-09-28 21:49:09 +02:00
.surface = VDP_INVALID_HANDLE,
};
}
vo_vdpau: Support recovering from VDPAU display preemption Add code to reinitialize all VDPAU objects if a display preemption condition occurs. Reinitializing them in the middle of playback will cause video corruption at least until the next keyframe when using hardware decoding, but decoding does seem to recover after a keyframe.
2009-09-07 01:02:24 +02:00
vc->output_surface_width = vc->output_surface_height = -1;
}
static int handle_preemption(struct vo *vo)
{
struct vdpctx *vc = vo->priv;
vdpau: move device and video surface management from vo_vdpau.c to vdpau.c The goal is being able to use vdpau decoding independently from vo_vdpau.c.
2013-11-05 22:06:32 +01:00
if (!mp_vdpau_status_ok(vc->mpvdp)) {
vo_vdpau: Support recovering from VDPAU display preemption Add code to reinitialize all VDPAU objects if a display preemption condition occurs. Reinitializing them in the middle of playback will cause video corruption at least until the next keyframe when using hardware decoding, but decoding does seem to recover after a keyframe.
2009-09-07 01:02:24 +02:00
mark_vdpau_objects_uninitialized(vo);
return -1;
}
vdpau: move device and video surface management from vo_vdpau.c to vdpau.c The goal is being able to use vdpau decoding independently from vo_vdpau.c.
2013-11-05 22:06:32 +01:00
if (vc->preemption_counter == vc->mpvdp->preemption_counter)
return 0;
mark_vdpau_objects_uninitialized(vo);
vc->preemption_counter = vc->mpvdp->preemption_counter;
vc->vdp_device = vc->mpvdp->vdp_device;
if (initialize_vdpau_objects(vo) < 0)
return -1;
vo_vdpau: Support recovering from VDPAU display preemption Add code to reinitialize all VDPAU objects if a display preemption condition occurs. Reinitializing them in the middle of playback will cause video corruption at least until the next keyframe when using hardware decoding, but decoding does seem to recover after a keyframe.
2009-09-07 01:02:24 +02:00
return 1;
}
vdpau: split off decoder parts, use "new" libavcodec vdpau hwaccel API Move the decoder parts from vo_vdpau.c to a new file vdpau_old.c. This file is named so because because it's written against the "old" libavcodec vdpau pseudo-decoder (e.g. "h264_vdpau"). Add support for the "new" libavcodec vdpau support. This was recently added and replaces the "old" vdpau parts. (In fact, Libav is about to deprecate and remove the "old" API without deprecation grace period, so we have to support it now. Moreover, there will probably be no Libav release which supports both, so the transition is even less smooth than we could hope, and we have to support both the old and new API.) Whether the old or new API is used is checked by a configure test: if the new API is found, it is used, otherwise the old API is assumed. Some details might be handled differently. Especially display preemption is a bit problematic with the "new" libavcodec vdpau support: it wants to keep a pointer to a specific vdpau API function (which can be driver specific, because preemption might switch drivers). Also, surface IDs are now directly stored in AVFrames (and mp_images), so they can't be forced to VDP_INVALID_HANDLE on preemption. (This changes even with older libavcodec versions, because mp_image always uses the newer representation to make vo_vdpau.c simpler.) Decoder initialization in the new code tries to deal with codec profiles, while the old code always uses the highest profile per codec. Surface allocation changes. Since the decoder won't call config() in vo_vdpau.c on video size change anymore, we allow allocating surfaces of arbitrary size instead of locking it to what the VO was configured. The non-hwdec code also has slightly different allocation behavior now. Enabling the old vdpau special decoders via e.g. --vd=lavc:h264_vdpau doesn't work anymore (a warning suggesting the --hwdec option is printed instead).
2013-07-28 01:49:45 +02:00
static bool status_ok(struct vo *vo)
{
return vo->config_ok && handle_preemption(vo) >= 0;
}
Add support for VDPAU video out, including hardware decoding. git-svn-id: svn://svn.mplayerhq.hu/mplayer/trunk@28617 b3059339-0415-0410-9bf9-f77b7e298cf2
2009-02-16 21:58:13 +01:00
/*
* connect to X server, create and map window, initialize all
* VDPAU objects, create different surfaces etc.
*/
video/out: do remaining config to reconfig replacements The main difference between the old and new callbacks is that the old callbacks required passing the window size, which is and always was very inconvenient and confusing, since the window size is already in vo->dwidth and vo->dheight.
2014-01-24 21:22:25 +01:00
static int reconfig(struct vo *vo, struct mp_image_params *params, int flags)
Add support for VDPAU video out, including hardware decoding. git-svn-id: svn://svn.mplayerhq.hu/mplayer/trunk@28617 b3059339-0415-0410-9bf9-f77b7e298cf2
2009-02-16 21:58:13 +01:00
{
vo_vdpau: Move things to context struct
2009-05-06 22:42:24 +02:00
struct vdpctx *vc = vo->priv;
Add support for VDPAU video out, including hardware decoding. git-svn-id: svn://svn.mplayerhq.hu/mplayer/trunk@28617 b3059339-0415-0410-9bf9-f77b7e298cf2
2009-02-16 21:58:13 +01:00
vo_vdpau: Support recovering from VDPAU display preemption Add code to reinitialize all VDPAU objects if a display preemption condition occurs. Reinitializing them in the middle of playback will cause video corruption at least until the next keyframe when using hardware decoding, but decoding does seem to recover after a keyframe.
2009-09-07 01:02:24 +02:00
if (handle_preemption(vo) < 0)
return -1;
vo_vdpau: add support for VFCAP_FLIP Patch by Carl Eugen Hoyos.
2009-11-15 14:50:28 +01:00
vc->flip = flags & VOFLAG_FLIPPING;
video/out: do remaining config to reconfig replacements The main difference between the old and new callbacks is that the old callbacks required passing the window size, which is and always was very inconvenient and confusing, since the window size is already in vo->dwidth and vo->dheight.
2014-01-24 21:22:25 +01:00
vc->image_format = params->imgfmt;
vc->vid_width = params->w;
vc->vid_height = params->h;
vo_vdpau: implement screenshots
2011-10-06 20:46:01 +02:00
video/out: do remaining config to reconfig replacements The main difference between the old and new callbacks is that the old callbacks required passing the window size, which is and always was very inconvenient and confusing, since the window size is already in vo->dwidth and vo->dheight.
2014-01-24 21:22:25 +01:00
vc->rgb_mode = get_rgb_format(params->imgfmt) >= 0;
vo_vdpau: add RGB support Apparently this was dropped some years ago, but judging from MPlayer's handling of this, the original code wasn't so great anyway. The new code handling clearing of panscan borders correctly, and integrates better with the YUV path. (Although the VDPAU API sure makes this annoying with its separate surface types for RGB.) Note that we create 5 surfaces for some reason - I don't think this makes too much sense (because we can't use the deinterlacer with RGB surfaces), but at least it reduces the amount of differences with the YUV code path. Clearing the borders is done by drawing a single black pixel over the window. This sounds pretty dumb, but it appears to work well, and there is no other API for that. (One could try to use the video mixer for this purpose, since it has all kinds of features, including compositing multiple RGBA surfaces and clearing the window background. But it would require an invisible dummy video surface to make the video mixer happy, and that's getting too messy.)
2013-08-18 05:12:21 +02:00
vo_vdpau: Replace global function table with context variable
2009-05-06 20:04:37 +02:00
free_video_specific(vo);
Add support for VDPAU video out, including hardware decoding. git-svn-id: svn://svn.mplayerhq.hu/mplayer/trunk@28617 b3059339-0415-0410-9bf9-f77b7e298cf2
2009-02-16 21:58:13 +01:00
x11: don't use VOCTRL_UPDATE_SCREENINFO See previous commit.
2014-05-06 20:24:35 +02:00
vo_x11_config_vo_window(vo, NULL, flags, "vdpau");
Add support for VDPAU video out, including hardware decoding. git-svn-id: svn://svn.mplayerhq.hu/mplayer/trunk@28617 b3059339-0415-0410-9bf9-f77b7e298cf2
2009-02-16 21:58:13 +01:00
vo_vdpau: Support recovering from VDPAU display preemption Add code to reinitialize all VDPAU objects if a display preemption condition occurs. Reinitializing them in the middle of playback will cause video corruption at least until the next keyframe when using hardware decoding, but decoding does seem to recover after a keyframe.
2009-09-07 01:02:24 +02:00
if (initialize_vdpau_objects(vo) < 0)
Add support for VDPAU video out, including hardware decoding. git-svn-id: svn://svn.mplayerhq.hu/mplayer/trunk@28617 b3059339-0415-0410-9bf9-f77b7e298cf2
2009-02-16 21:58:13 +01:00
return -1;
return 0;
}
vo_vdpau: split bitmap packing code into a separate file Split the vo_vdpau code that calculates how to pack all subtitle bitmaps into a larger surface into a separate file. This will allow using it in other VOs. Conflicts: Makefile libvo/vo_vdpau.c Note: this commit does the same as an earlier commit by me (4010dd0b1a27e3996). My commit added the vo_vdpau packer code as eosd_packer.c, while this commit by uau uses bitmap_packer.c. Since bitmap_packer.c has a different interface, and because there are more commits changing OSD rendering coming, I will pick uau's version. However, vo_gl, vo_gl3 and vo_direct3d are still using eosd_packer.c, so to make the transition easier, don't delete eosd_packer.c yet.
2012-08-26 18:00:26 +02:00
static struct bitmap_packer *make_packer(struct vo *vo, VdpRGBAFormat format)
Add support for VDPAU video out, including hardware decoding. git-svn-id: svn://svn.mplayerhq.hu/mplayer/trunk@28617 b3059339-0415-0410-9bf9-f77b7e298cf2
2009-02-16 21:58:13 +01:00
{
vo_vdpau: Replace global function table with context variable
2009-05-06 20:04:37 +02:00
struct vdpctx *vc = vo->priv;
struct vdp_functions *vdp = vc->vdp;
vo_vdpau.c: cosmetics
2009-05-09 17:08:30 +02:00
vo_vdpau: split bitmap packing code into a separate file Split the vo_vdpau code that calculates how to pack all subtitle bitmaps into a larger surface into a separate file. This will allow using it in other VOs. Conflicts: Makefile libvo/vo_vdpau.c Note: this commit does the same as an earlier commit by me (4010dd0b1a27e3996). My commit added the vo_vdpau packer code as eosd_packer.c, while this commit by uau uses bitmap_packer.c. Since bitmap_packer.c has a different interface, and because there are more commits changing OSD rendering coming, I will pick uau's version. However, vo_gl, vo_gl3 and vo_direct3d are still using eosd_packer.c, so to make the transition easier, don't delete eosd_packer.c yet.
2012-08-26 18:00:26 +02:00
struct bitmap_packer *packer = talloc_zero(vo, struct bitmap_packer);
uint32_t w_max = 0, h_max = 0;
VdpStatus vdp_st = vdp->
bitmap_surface_query_capabilities(vc->vdp_device, format,
&(VdpBool){0}, &w_max, &h_max);
vdpau: mp_msg conversions
2013-12-21 18:05:23 +01:00
CHECK_VDP_WARNING(vo, "Query to get max OSD surface size failed");
vo_vdpau: split bitmap packing code into a separate file Split the vo_vdpau code that calculates how to pack all subtitle bitmaps into a larger surface into a separate file. This will allow using it in other VOs. Conflicts: Makefile libvo/vo_vdpau.c Note: this commit does the same as an earlier commit by me (4010dd0b1a27e3996). My commit added the vo_vdpau packer code as eosd_packer.c, while this commit by uau uses bitmap_packer.c. Since bitmap_packer.c has a different interface, and because there are more commits changing OSD rendering coming, I will pick uau's version. However, vo_gl, vo_gl3 and vo_direct3d are still using eosd_packer.c, so to make the transition easier, don't delete eosd_packer.c yet.
2012-08-26 18:00:26 +02:00
packer->w_max = w_max;
packer->h_max = h_max;
return packer;
Add support for VDPAU video out, including hardware decoding. git-svn-id: svn://svn.mplayerhq.hu/mplayer/trunk@28617 b3059339-0415-0410-9bf9-f77b7e298cf2
2009-02-16 21:58:13 +01:00
}
VO, sub: refactor Remove VFCTRL_DRAW_OSD, VFCAP_EOSD_FILTER, VFCAP_EOSD_RGBA, VFCAP_EOSD, VOCTRL_DRAW_EOSD, VOCTRL_GET_EOSD_RES, VOCTRL_QUERY_EOSD_FORMAT. Remove draw_osd_with_eosd(), which rendered the OSD by calling VOCTRL_DRAW_EOSD. Change VOs to call osd_draw() directly, which takes a callback as argument. (This basically works like the old OSD API, except multiple OSD bitmap formats are supported and caching is possible.) Remove all mentions of "eosd". It's simply "osd" now. Make OSD size per-OSD-object, as they can be different when using vf_sub. Include display_par/video_par in resolution change detection. Fix the issue with margin borders in vo_corevideo.
2012-10-19 19:25:18 +02:00
static void draw_osd_part(struct vo *vo, int index)
vo_vdpau: Replace global function table with context variable
2009-05-06 20:04:37 +02:00
{
struct vdpctx *vc = vo->priv;
struct vdp_functions *vdp = vc->vdp;
EOSD/ASS support for vo_vdpau.c Patch by Grigori G (greg <at> chown ath cx) with minor cosmetic changes by me. git-svn-id: svn://svn.mplayerhq.hu/mplayer/trunk@28710 b3059339-0415-0410-9bf9-f77b7e298cf2
2009-02-23 10:21:57 +01:00
VdpStatus vdp_st;
VO, sub: refactor Remove VFCTRL_DRAW_OSD, VFCAP_EOSD_FILTER, VFCAP_EOSD_RGBA, VFCAP_EOSD, VOCTRL_DRAW_EOSD, VOCTRL_GET_EOSD_RES, VOCTRL_QUERY_EOSD_FORMAT. Remove draw_osd_with_eosd(), which rendered the OSD by calling VOCTRL_DRAW_EOSD. Change VOs to call osd_draw() directly, which takes a callback as argument. (This basically works like the old OSD API, except multiple OSD bitmap formats are supported and caching is possible.) Remove all mentions of "eosd". It's simply "osd" now. Make OSD size per-OSD-object, as they can be different when using vf_sub. Include display_par/video_par in resolution change detection. Fix the issue with margin borders in vo_corevideo.
2012-10-19 19:25:18 +02:00
struct osd_bitmap_surface *sfc = &vc->osd_surfaces[index];
vo_vdpau: Move things to context struct
2009-05-06 22:42:24 +02:00
VdpOutputSurface output_surface = vc->output_surfaces[vc->surface_num];
EOSD/ASS support for vo_vdpau.c Patch by Grigori G (greg <at> chown ath cx) with minor cosmetic changes by me. git-svn-id: svn://svn.mplayerhq.hu/mplayer/trunk@28710 b3059339-0415-0410-9bf9-f77b7e298cf2
2009-02-23 10:21:57 +01:00
int i;
vo_vdpau.c: cosmetics
2009-05-09 17:08:30 +02:00
VdpOutputSurfaceRenderBlendState blend_state = {
.struct_version = VDP_OUTPUT_SURFACE_RENDER_BLEND_STATE_VERSION,
.blend_factor_source_color =
VDP_OUTPUT_SURFACE_RENDER_BLEND_FACTOR_SRC_ALPHA,
.blend_factor_source_alpha =
vo_vdpau: don't calculate destination alpha when drawing OSD Same as MPlayer svn commit r36515 "Chose cheaper alpha blend equation." No idea if this is actually faster, but can't hurt.
2013-11-18 14:02:14 +01:00
VDP_OUTPUT_SURFACE_RENDER_BLEND_FACTOR_ZERO,
vo_vdpau.c: cosmetics
2009-05-09 17:08:30 +02:00
.blend_factor_destination_color =
VDP_OUTPUT_SURFACE_RENDER_BLEND_FACTOR_ONE_MINUS_SRC_ALPHA,
.blend_factor_destination_alpha =
vo_vdpau: don't calculate destination alpha when drawing OSD Same as MPlayer svn commit r36515 "Chose cheaper alpha blend equation." No idea if this is actually faster, but can't hurt.
2013-11-18 14:02:14 +01:00
VDP_OUTPUT_SURFACE_RENDER_BLEND_FACTOR_ZERO,
vo_vdpau.c: cosmetics
2009-05-09 17:08:30 +02:00
.blend_equation_color = VDP_OUTPUT_SURFACE_RENDER_BLEND_EQUATION_ADD,
.blend_equation_alpha = VDP_OUTPUT_SURFACE_RENDER_BLEND_EQUATION_ADD,
};
sub: switch to premultiplied alpha Fixes problems with ugly borders. Note that at least in the DVD sub case, we could have just set all transparent pixels to black to solve this. vo_direct3d.c change untested, because mingw is a miserable pile of crap.
2012-10-05 20:37:16 +02:00
VdpOutputSurfaceRenderBlendState blend_state_premultiplied = blend_state;
blend_state_premultiplied.blend_factor_source_color =
VDP_OUTPUT_SURFACE_RENDER_BLEND_FACTOR_ONE;
vo_vdpau: allow multiple EOSD renderers Preparation for using new OSD rendering method.
2012-09-28 21:49:09 +02:00
for (i = 0; i < sfc->render_count; i++) {
sub: switch to premultiplied alpha Fixes problems with ugly borders. Note that at least in the DVD sub case, we could have just set all transparent pixels to black to solve this. vo_direct3d.c change untested, because mingw is a miserable pile of crap.
2012-10-05 20:37:16 +02:00
VdpOutputSurfaceRenderBlendState *blend = &blend_state;
if (sfc->format == VDP_RGBA_FORMAT_B8G8R8A8)
blend = &blend_state_premultiplied;
vo_vdpau.c: cosmetics
2009-05-09 17:08:30 +02:00
vdp_st = vdp->
output_surface_render_bitmap_surface(output_surface,
vo_vdpau: allow multiple EOSD renderers Preparation for using new OSD rendering method.
2012-09-28 21:49:09 +02:00
&sfc->targets[i].dest,
sfc->surface,
&sfc->targets[i].source,
&sfc->targets[i].color,
sub: switch to premultiplied alpha Fixes problems with ugly borders. Note that at least in the DVD sub case, we could have just set all transparent pixels to black to solve this. vo_direct3d.c change untested, because mingw is a miserable pile of crap.
2012-10-05 20:37:16 +02:00
blend,
vo_vdpau.c: cosmetics
2009-05-09 17:08:30 +02:00
VDP_OUTPUT_SURFACE_RENDER_ROTATE_0);
vdpau: mp_msg conversions
2013-12-21 18:05:23 +01:00
CHECK_VDP_WARNING(vo, "OSD: Error when rendering");
EOSD/ASS support for vo_vdpau.c Patch by Grigori G (greg <at> chown ath cx) with minor cosmetic changes by me. git-svn-id: svn://svn.mplayerhq.hu/mplayer/trunk@28710 b3059339-0415-0410-9bf9-f77b7e298cf2
2009-02-23 10:21:57 +01:00
}
}
VO, sub: refactor Remove VFCTRL_DRAW_OSD, VFCAP_EOSD_FILTER, VFCAP_EOSD_RGBA, VFCAP_EOSD, VOCTRL_DRAW_EOSD, VOCTRL_GET_EOSD_RES, VOCTRL_QUERY_EOSD_FORMAT. Remove draw_osd_with_eosd(), which rendered the OSD by calling VOCTRL_DRAW_EOSD. Change VOs to call osd_draw() directly, which takes a callback as argument. (This basically works like the old OSD API, except multiple OSD bitmap formats are supported and caching is possible.) Remove all mentions of "eosd". It's simply "osd" now. Make OSD size per-OSD-object, as they can be different when using vf_sub. Include display_par/video_par in resolution change detection. Fix the issue with margin borders in vo_corevideo.
2012-10-19 19:25:18 +02:00
static void generate_osd_part(struct vo *vo, struct sub_bitmaps *imgs)
vo_vdpau: Replace global function table with context variable
2009-05-06 20:04:37 +02:00
{
struct vdpctx *vc = vo->priv;
struct vdp_functions *vdp = vc->vdp;
EOSD/ASS support for vo_vdpau.c Patch by Grigori G (greg <at> chown ath cx) with minor cosmetic changes by me. git-svn-id: svn://svn.mplayerhq.hu/mplayer/trunk@28710 b3059339-0415-0410-9bf9-f77b7e298cf2
2009-02-23 10:21:57 +01:00
VdpStatus vdp_st;
VO, sub: refactor Remove VFCTRL_DRAW_OSD, VFCAP_EOSD_FILTER, VFCAP_EOSD_RGBA, VFCAP_EOSD, VOCTRL_DRAW_EOSD, VOCTRL_GET_EOSD_RES, VOCTRL_QUERY_EOSD_FORMAT. Remove draw_osd_with_eosd(), which rendered the OSD by calling VOCTRL_DRAW_EOSD. Change VOs to call osd_draw() directly, which takes a callback as argument. (This basically works like the old OSD API, except multiple OSD bitmap formats are supported and caching is possible.) Remove all mentions of "eosd". It's simply "osd" now. Make OSD size per-OSD-object, as they can be different when using vf_sub. Include display_par/video_par in resolution change detection. Fix the issue with margin borders in vo_corevideo.
2012-10-19 19:25:18 +02:00
struct osd_bitmap_surface *sfc = &vc->osd_surfaces[imgs->render_index];
vo_vdpau: split bitmap packing code into a separate file Split the vo_vdpau code that calculates how to pack all subtitle bitmaps into a larger surface into a separate file. This will allow using it in other VOs. Conflicts: Makefile libvo/vo_vdpau.c Note: this commit does the same as an earlier commit by me (4010dd0b1a27e3996). My commit added the vo_vdpau packer code as eosd_packer.c, while this commit by uau uses bitmap_packer.c. Since bitmap_packer.c has a different interface, and because there are more commits changing OSD rendering coming, I will pick uau's version. However, vo_gl, vo_gl3 and vo_direct3d are still using eosd_packer.c, so to make the transition easier, don't delete eosd_packer.c yet.
2012-08-26 18:00:26 +02:00
bool need_upload = false;
libvo, vo_vdpau: make the EOSD packer code from vo_vdpau generic The code in eosd_packer.c/.h is taken from vo_vdpau.c and has been made independent from vdpau API specifics. This allows other VOs, which need to pack the small EOSD images into a large surface for efficiency, to use this code.
2011-10-27 12:07:10 +02:00
vo_vdpau: allow multiple EOSD renderers Preparation for using new OSD rendering method.
2012-09-28 21:49:09 +02:00
if (imgs->bitmap_pos_id == sfc->bitmap_pos_id)
vo_vdpau: split bitmap packing code into a separate file Split the vo_vdpau code that calculates how to pack all subtitle bitmaps into a larger surface into a separate file. This will allow using it in other VOs. Conflicts: Makefile libvo/vo_vdpau.c Note: this commit does the same as an earlier commit by me (4010dd0b1a27e3996). My commit added the vo_vdpau packer code as eosd_packer.c, while this commit by uau uses bitmap_packer.c. Since bitmap_packer.c has a different interface, and because there are more commits changing OSD rendering coming, I will pick uau's version. However, vo_gl, vo_gl3 and vo_direct3d are still using eosd_packer.c, so to make the transition easier, don't delete eosd_packer.c yet.
2012-08-26 18:00:26 +02:00
return; // Nothing changed and we still have the old data
libvo, vo_vdpau: make the EOSD packer code from vo_vdpau generic The code in eosd_packer.c/.h is taken from vo_vdpau.c and has been made independent from vdpau API specifics. This allows other VOs, which need to pack the small EOSD images into a large surface for efficiency, to use this code.
2011-10-27 12:07:10 +02:00
vo_vdpau: allow multiple EOSD renderers Preparation for using new OSD rendering method.
2012-09-28 21:49:09 +02:00
sfc->render_count = 0;
vo_vdpau: split bitmap packing code into a separate file Split the vo_vdpau code that calculates how to pack all subtitle bitmaps into a larger surface into a separate file. This will allow using it in other VOs. Conflicts: Makefile libvo/vo_vdpau.c Note: this commit does the same as an earlier commit by me (4010dd0b1a27e3996). My commit added the vo_vdpau packer code as eosd_packer.c, while this commit by uau uses bitmap_packer.c. Since bitmap_packer.c has a different interface, and because there are more commits changing OSD rendering coming, I will pick uau's version. However, vo_gl, vo_gl3 and vo_direct3d are still using eosd_packer.c, so to make the transition easier, don't delete eosd_packer.c yet.
2012-08-26 18:00:26 +02:00
sub, vo_gl3, vo_vdpau: exit early if there are no sub-images to draw libass may always return a full change if no subtitle images are rendered in some cases (empty tracks). Also, a full change despite empty sub-images list may be reported on initialization. Avoid invoking odd special cases in the VO code by always exiting early if the sub-image list is empty. Note that at least for OSD, the code in sub.c doesn't even send a request VOCTRL_DRAW_EOSD if the image list is empty. But the subtitle rendering code in vf_vo.c is independent from this (at least for now).
2012-10-02 00:25:06 +02:00
if (imgs->format == SUBBITMAP_EMPTY || imgs->num_parts == 0)
subs, vo_vdpau: support RGBA color for PGS subtitles Support passing bitmap subtitles to VOs in full RGBA color, and implement this for libavcodec-decoded subtitle formats on decoding side and vo_vdpau on display side. Currently this is enabled for PGS (blu-ray) and DVB subtitles. VDPAU seems to have sampling issues similar to known GL ones when drawing a sub-rectangle from a larger texture with scaling, where adjacent pixels outside the specified source rectangle affect the result. As the bitmap subtitles may be scaled, add padding support to the bitmap packer code. In principle, this could be used for colored DVD subtitles too. However, the libavcodec DVD decoder lacks parts of the resolution and palette handling that are present in spudec.c. Conflicts: libvo/vo_gl.c sub/dec_sub.h sub/sd_lavc.c
2012-08-31 14:42:30 +02:00
return;
vo_vdpau: split bitmap packing code into a separate file Split the vo_vdpau code that calculates how to pack all subtitle bitmaps into a larger surface into a separate file. This will allow using it in other VOs. Conflicts: Makefile libvo/vo_vdpau.c Note: this commit does the same as an earlier commit by me (4010dd0b1a27e3996). My commit added the vo_vdpau packer code as eosd_packer.c, while this commit by uau uses bitmap_packer.c. Since bitmap_packer.c has a different interface, and because there are more commits changing OSD rendering coming, I will pick uau's version. However, vo_gl, vo_gl3 and vo_direct3d are still using eosd_packer.c, so to make the transition easier, don't delete eosd_packer.c yet.
2012-08-26 18:00:26 +02:00
vo_vdpau: allow multiple EOSD renderers Preparation for using new OSD rendering method.
2012-09-28 21:49:09 +02:00
if (imgs->bitmap_id == sfc->bitmap_id)
VO, sub: refactor Remove VFCTRL_DRAW_OSD, VFCAP_EOSD_FILTER, VFCAP_EOSD_RGBA, VFCAP_EOSD, VOCTRL_DRAW_EOSD, VOCTRL_GET_EOSD_RES, VOCTRL_QUERY_EOSD_FORMAT. Remove draw_osd_with_eosd(), which rendered the OSD by calling VOCTRL_DRAW_EOSD. Change VOs to call osd_draw() directly, which takes a callback as argument. (This basically works like the old OSD API, except multiple OSD bitmap formats are supported and caching is possible.) Remove all mentions of "eosd". It's simply "osd" now. Make OSD size per-OSD-object, as they can be different when using vf_sub. Include display_par/video_par in resolution change detection. Fix the issue with margin borders in vo_corevideo.
2012-10-19 19:25:18 +02:00
goto osd_skip_upload;
libvo, vo_vdpau: make the EOSD packer code from vo_vdpau generic The code in eosd_packer.c/.h is taken from vo_vdpau.c and has been made independent from vdpau API specifics. This allows other VOs, which need to pack the small EOSD images into a large surface for efficiency, to use this code.
2011-10-27 12:07:10 +02:00
vo_vdpau: split bitmap packing code into a separate file Split the vo_vdpau code that calculates how to pack all subtitle bitmaps into a larger surface into a separate file. This will allow using it in other VOs. Conflicts: Makefile libvo/vo_vdpau.c Note: this commit does the same as an earlier commit by me (4010dd0b1a27e3996). My commit added the vo_vdpau packer code as eosd_packer.c, while this commit by uau uses bitmap_packer.c. Since bitmap_packer.c has a different interface, and because there are more commits changing OSD rendering coming, I will pick uau's version. However, vo_gl, vo_gl3 and vo_direct3d are still using eosd_packer.c, so to make the transition easier, don't delete eosd_packer.c yet.
2012-08-26 18:00:26 +02:00
need_upload = true;
subs, vo_vdpau: support RGBA color for PGS subtitles Support passing bitmap subtitles to VOs in full RGBA color, and implement this for libavcodec-decoded subtitle formats on decoding side and vo_vdpau on display side. Currently this is enabled for PGS (blu-ray) and DVB subtitles. VDPAU seems to have sampling issues similar to known GL ones when drawing a sub-rectangle from a larger texture with scaling, where adjacent pixels outside the specified source rectangle affect the result. As the bitmap subtitles may be scaled, add padding support to the bitmap packer code. In principle, this could be used for colored DVD subtitles too. However, the libavcodec DVD decoder lacks parts of the resolution and palette handling that are present in spudec.c. Conflicts: libvo/vo_gl.c sub/dec_sub.h sub/sd_lavc.c
2012-08-31 14:42:30 +02:00
VdpRGBAFormat format;
int format_size;
sub: create sub_bitmap array even when using libass One sub_bitmaps struct could contain either a libass ASS_Image list, or a mplayer native list of sub-bitmaps. This caused code duplication in vo_vdpau.c and bitmap_packer.c. Avoid this by creating such a sub_bitmap array even with libass. This basically copies the list and recreates it in mplayer's native format. It gets rid of the code duplication, and will make implementing extended subtitle and OSD rendering in other VOs easier. Also do some cosmetic changes and other preparations for the following commits.
2012-09-28 21:19:36 +02:00
switch (imgs->format) {
subs, vo_vdpau: support RGBA color for PGS subtitles Support passing bitmap subtitles to VOs in full RGBA color, and implement this for libavcodec-decoded subtitle formats on decoding side and vo_vdpau on display side. Currently this is enabled for PGS (blu-ray) and DVB subtitles. VDPAU seems to have sampling issues similar to known GL ones when drawing a sub-rectangle from a larger texture with scaling, where adjacent pixels outside the specified source rectangle affect the result. As the bitmap subtitles may be scaled, add padding support to the bitmap packer code. In principle, this could be used for colored DVD subtitles too. However, the libavcodec DVD decoder lacks parts of the resolution and palette handling that are present in spudec.c. Conflicts: libvo/vo_gl.c sub/dec_sub.h sub/sd_lavc.c
2012-08-31 14:42:30 +02:00
case SUBBITMAP_LIBASS:
format = VDP_RGBA_FORMAT_A8;
format_size = 1;
break;
case SUBBITMAP_RGBA:
format = VDP_RGBA_FORMAT_B8G8R8A8;
format_size = 4;
break;
default:
abort();
};
if (sfc->format != format) {
talloc_free(sfc->packer);
sfc->packer = NULL;
};
sfc->format = format;
vo_vdpau: split bitmap packing code into a separate file Split the vo_vdpau code that calculates how to pack all subtitle bitmaps into a larger surface into a separate file. This will allow using it in other VOs. Conflicts: Makefile libvo/vo_vdpau.c Note: this commit does the same as an earlier commit by me (4010dd0b1a27e3996). My commit added the vo_vdpau packer code as eosd_packer.c, while this commit by uau uses bitmap_packer.c. Since bitmap_packer.c has a different interface, and because there are more commits changing OSD rendering coming, I will pick uau's version. However, vo_gl, vo_gl3 and vo_direct3d are still using eosd_packer.c, so to make the transition easier, don't delete eosd_packer.c yet.
2012-08-26 18:00:26 +02:00
if (!sfc->packer)
subs, vo_vdpau: support RGBA color for PGS subtitles Support passing bitmap subtitles to VOs in full RGBA color, and implement this for libavcodec-decoded subtitle formats on decoding side and vo_vdpau on display side. Currently this is enabled for PGS (blu-ray) and DVB subtitles. VDPAU seems to have sampling issues similar to known GL ones when drawing a sub-rectangle from a larger texture with scaling, where adjacent pixels outside the specified source rectangle affect the result. As the bitmap subtitles may be scaled, add padding support to the bitmap packer code. In principle, this could be used for colored DVD subtitles too. However, the libavcodec DVD decoder lacks parts of the resolution and palette handling that are present in spudec.c. Conflicts: libvo/vo_gl.c sub/dec_sub.h sub/sd_lavc.c
2012-08-31 14:42:30 +02:00
sfc->packer = make_packer(vo, format);
sub: create sub_bitmap array even when using libass One sub_bitmaps struct could contain either a libass ASS_Image list, or a mplayer native list of sub-bitmaps. This caused code duplication in vo_vdpau.c and bitmap_packer.c. Avoid this by creating such a sub_bitmap array even with libass. This basically copies the list and recreates it in mplayer's native format. It gets rid of the code duplication, and will make implementing extended subtitle and OSD rendering in other VOs easier. Also do some cosmetic changes and other preparations for the following commits.
2012-09-28 21:19:36 +02:00
sfc->packer->padding = imgs->scaled; // assume 2x2 filter on scaling
int r = packer_pack_from_subbitmaps(sfc->packer, imgs);
vo_vdpau: split bitmap packing code into a separate file Split the vo_vdpau code that calculates how to pack all subtitle bitmaps into a larger surface into a separate file. This will allow using it in other VOs. Conflicts: Makefile libvo/vo_vdpau.c Note: this commit does the same as an earlier commit by me (4010dd0b1a27e3996). My commit added the vo_vdpau packer code as eosd_packer.c, while this commit by uau uses bitmap_packer.c. Since bitmap_packer.c has a different interface, and because there are more commits changing OSD rendering coming, I will pick uau's version. However, vo_gl, vo_gl3 and vo_direct3d are still using eosd_packer.c, so to make the transition easier, don't delete eosd_packer.c yet.
2012-08-26 18:00:26 +02:00
if (r < 0) {
Some more mp_msg conversions Also add a note to mp_msg.h, since it might be not clear which of the two mechanisms is preferred.
2013-08-23 23:30:09 +02:00
MP_ERR(vo, "OSD bitmaps do not fit on a surface with the maximum "
"supported size\n");
vo_vdpau: split bitmap packing code into a separate file Split the vo_vdpau code that calculates how to pack all subtitle bitmaps into a larger surface into a separate file. This will allow using it in other VOs. Conflicts: Makefile libvo/vo_vdpau.c Note: this commit does the same as an earlier commit by me (4010dd0b1a27e3996). My commit added the vo_vdpau packer code as eosd_packer.c, while this commit by uau uses bitmap_packer.c. Since bitmap_packer.c has a different interface, and because there are more commits changing OSD rendering coming, I will pick uau's version. However, vo_gl, vo_gl3 and vo_direct3d are still using eosd_packer.c, so to make the transition easier, don't delete eosd_packer.c yet.
2012-08-26 18:00:26 +02:00
return;
} else if (r == 1) {
if (sfc->surface != VDP_INVALID_HANDLE) {
vdp_st = vdp->bitmap_surface_destroy(sfc->surface);
vdpau: mp_msg conversions
2013-12-21 18:05:23 +01:00
CHECK_VDP_WARNING(vo, "Error when calling vdp_bitmap_surface_destroy");
vo_vdpau: fix loop initializing output surfaces as invalid The loop initializing handles in the output surface table to VDP_INVALID_HANDLE ran over indices from 0 to vc->num_output_surfaces. However it is first called before that variable is initialized. As a result later code could try to destroy the handles which still had the "non-invalid" value 0. Most likely this caused no visible effects; at least on my machine no valid surface gets handle 0, and libvdpau just returns an error for the resulting invalid calls. Change the code to loop over the whole table. Also add code to print visible warnings if libvdpau rejects a surface destroy call (some other places already had checks but not all).
2010-05-26 07:54:09 +02:00
}
Some more mp_msg conversions Also add a note to mp_msg.h, since it might be not clear which of the two mechanisms is preferred.
2013-08-23 23:30:09 +02:00
MP_VERBOSE(vo, "Allocating a %dx%d surface for OSD bitmaps.\n",
sfc->packer->w, sfc->packer->h);
subs, vo_vdpau: support RGBA color for PGS subtitles Support passing bitmap subtitles to VOs in full RGBA color, and implement this for libavcodec-decoded subtitle formats on decoding side and vo_vdpau on display side. Currently this is enabled for PGS (blu-ray) and DVB subtitles. VDPAU seems to have sampling issues similar to known GL ones when drawing a sub-rectangle from a larger texture with scaling, where adjacent pixels outside the specified source rectangle affect the result. As the bitmap subtitles may be scaled, add padding support to the bitmap packer code. In principle, this could be used for colored DVD subtitles too. However, the libavcodec DVD decoder lacks parts of the resolution and palette handling that are present in spudec.c. Conflicts: libvo/vo_gl.c sub/dec_sub.h sub/sd_lavc.c
2012-08-31 14:42:30 +02:00
vdp_st = vdp->bitmap_surface_create(vc->vdp_device, format,
vo_vdpau: split bitmap packing code into a separate file Split the vo_vdpau code that calculates how to pack all subtitle bitmaps into a larger surface into a separate file. This will allow using it in other VOs. Conflicts: Makefile libvo/vo_vdpau.c Note: this commit does the same as an earlier commit by me (4010dd0b1a27e3996). My commit added the vo_vdpau packer code as eosd_packer.c, while this commit by uau uses bitmap_packer.c. Since bitmap_packer.c has a different interface, and because there are more commits changing OSD rendering coming, I will pick uau's version. However, vo_gl, vo_gl3 and vo_direct3d are still using eosd_packer.c, so to make the transition easier, don't delete eosd_packer.c yet.
2012-08-26 18:00:26 +02:00
sfc->packer->w, sfc->packer->h,
true, &sfc->surface);
vo_vdpau: Allocate one large surface for EOSD content Create a single large bitmap surface for EOSD objects and pack all the bitmap rectangles inside that. The old code created a separate bitmap surface for every bitmap and then resized the cached surfaces when drawing later frames. The number of surfaces could be large (at least about 2000 for one sample subtitle script) so this was very inefficient. The old code also used a very simple strategy for pairing existing surfaces to new bitmaps; it could resize tiny surfaces to hold large glyphs while using existing large surfaces to hold tiny glyphs and as a result allocate arbitrarily much more total surface area than was necessary. The new code only supports using a single surface, freeing it and allocating a larger one if necessary. It would be possible to support multiple surfaces in case of hitting the maximum bitmap surface size, but I'll wait to see if that is actually needed before implementing it. NVIDIA seems to support bitmap surface sizes up to 8192x8192, so it would take either a really pathological subtitle script rendered at a high resolution or an implementation with lower limits before multiple surfaces would be necessary. The packing algorithm should successfully pack the bitmaps into a surface of size w*h as long as the total area of the bitmaps does not exceed 16/17 (w-max_bitmap_width)*(h-max_bitmap_height), so there should be no totally catastrophic failure cases. The 16/17 factor comes from approximate sorting used in the algorithm. On average performance should be better than this minimum guaranteed level.
2009-09-02 19:21:24 +02:00
if (vdp_st != VDP_STATUS_OK)
vo_vdpau: split bitmap packing code into a separate file Split the vo_vdpau code that calculates how to pack all subtitle bitmaps into a larger surface into a separate file. This will allow using it in other VOs. Conflicts: Makefile libvo/vo_vdpau.c Note: this commit does the same as an earlier commit by me (4010dd0b1a27e3996). My commit added the vo_vdpau packer code as eosd_packer.c, while this commit by uau uses bitmap_packer.c. Since bitmap_packer.c has a different interface, and because there are more commits changing OSD rendering coming, I will pick uau's version. However, vo_gl, vo_gl3 and vo_direct3d are still using eosd_packer.c, so to make the transition easier, don't delete eosd_packer.c yet.
2012-08-26 18:00:26 +02:00
sfc->surface = VDP_INVALID_HANDLE;
vdpau: mp_msg conversions
2013-12-21 18:05:23 +01:00
CHECK_VDP_WARNING(vo, "OSD: error when creating surface");
EOSD/ASS support for vo_vdpau.c Patch by Grigori G (greg <at> chown ath cx) with minor cosmetic changes by me. git-svn-id: svn://svn.mplayerhq.hu/mplayer/trunk@28710 b3059339-0415-0410-9bf9-f77b7e298cf2
2009-02-23 10:21:57 +01:00
}
subs, vo_vdpau: support RGBA color for PGS subtitles Support passing bitmap subtitles to VOs in full RGBA color, and implement this for libavcodec-decoded subtitle formats on decoding side and vo_vdpau on display side. Currently this is enabled for PGS (blu-ray) and DVB subtitles. VDPAU seems to have sampling issues similar to known GL ones when drawing a sub-rectangle from a larger texture with scaling, where adjacent pixels outside the specified source rectangle affect the result. As the bitmap subtitles may be scaled, add padding support to the bitmap packer code. In principle, this could be used for colored DVD subtitles too. However, the libavcodec DVD decoder lacks parts of the resolution and palette handling that are present in spudec.c. Conflicts: libvo/vo_gl.c sub/dec_sub.h sub/sd_lavc.c
2012-08-31 14:42:30 +02:00
if (imgs->scaled) {
char zeros[sfc->packer->used_width * format_size];
memset(zeros, 0, sizeof(zeros));
vdp_st = vdp->bitmap_surface_put_bits_native(sfc->surface,
&(const void *){zeros}, &(uint32_t){0},
&(VdpRect){0, 0, sfc->packer->used_width,
sfc->packer->used_height});
}
EOSD/ASS support for vo_vdpau.c Patch by Grigori G (greg <at> chown ath cx) with minor cosmetic changes by me. git-svn-id: svn://svn.mplayerhq.hu/mplayer/trunk@28710 b3059339-0415-0410-9bf9-f77b7e298cf2
2009-02-23 10:21:57 +01:00
VO, sub: refactor Remove VFCTRL_DRAW_OSD, VFCAP_EOSD_FILTER, VFCAP_EOSD_RGBA, VFCAP_EOSD, VOCTRL_DRAW_EOSD, VOCTRL_GET_EOSD_RES, VOCTRL_QUERY_EOSD_FORMAT. Remove draw_osd_with_eosd(), which rendered the OSD by calling VOCTRL_DRAW_EOSD. Change VOs to call osd_draw() directly, which takes a callback as argument. (This basically works like the old OSD API, except multiple OSD bitmap formats are supported and caching is possible.) Remove all mentions of "eosd". It's simply "osd" now. Make OSD size per-OSD-object, as they can be different when using vf_sub. Include display_par/video_par in resolution change detection. Fix the issue with margin borders in vo_corevideo.
2012-10-19 19:25:18 +02:00
osd_skip_upload:
vo_vdpau: split bitmap packing code into a separate file Split the vo_vdpau code that calculates how to pack all subtitle bitmaps into a larger surface into a separate file. This will allow using it in other VOs. Conflicts: Makefile libvo/vo_vdpau.c Note: this commit does the same as an earlier commit by me (4010dd0b1a27e3996). My commit added the vo_vdpau packer code as eosd_packer.c, while this commit by uau uses bitmap_packer.c. Since bitmap_packer.c has a different interface, and because there are more commits changing OSD rendering coming, I will pick uau's version. However, vo_gl, vo_gl3 and vo_direct3d are still using eosd_packer.c, so to make the transition easier, don't delete eosd_packer.c yet.
2012-08-26 18:00:26 +02:00
if (sfc->surface == VDP_INVALID_HANDLE)
vo_vdpau: Allocate one large surface for EOSD content Create a single large bitmap surface for EOSD objects and pack all the bitmap rectangles inside that. The old code created a separate bitmap surface for every bitmap and then resized the cached surfaces when drawing later frames. The number of surfaces could be large (at least about 2000 for one sample subtitle script) so this was very inefficient. The old code also used a very simple strategy for pairing existing surfaces to new bitmaps; it could resize tiny surfaces to hold large glyphs while using existing large surfaces to hold tiny glyphs and as a result allocate arbitrarily much more total surface area than was necessary. The new code only supports using a single surface, freeing it and allocating a larger one if necessary. It would be possible to support multiple surfaces in case of hitting the maximum bitmap surface size, but I'll wait to see if that is actually needed before implementing it. NVIDIA seems to support bitmap surface sizes up to 8192x8192, so it would take either a really pathological subtitle script rendered at a high resolution or an implementation with lower limits before multiple surfaces would be necessary. The packing algorithm should successfully pack the bitmaps into a surface of size w*h as long as the total area of the bitmaps does not exceed 16/17 (w-max_bitmap_width)*(h-max_bitmap_height), so there should be no totally catastrophic failure cases. The 16/17 factor comes from approximate sorting used in the algorithm. On average performance should be better than this minimum guaranteed level.
2009-09-02 19:21:24 +02:00
return;
vo_vdpau: allow multiple EOSD renderers Preparation for using new OSD rendering method.
2012-09-28 21:49:09 +02:00
if (sfc->packer->count > sfc->targets_size) {
talloc_free(sfc->targets);
sfc->targets_size = sfc->packer->count;
sfc->targets = talloc_size(vc, sfc->targets_size
* sizeof(*sfc->targets));
sub: create sub_bitmap array even when using libass One sub_bitmaps struct could contain either a libass ASS_Image list, or a mplayer native list of sub-bitmaps. This caused code duplication in vo_vdpau.c and bitmap_packer.c. Avoid this by creating such a sub_bitmap array even with libass. This basically copies the list and recreates it in mplayer's native format. It gets rid of the code duplication, and will make implementing extended subtitle and OSD rendering in other VOs easier. Also do some cosmetic changes and other preparations for the following commits.
2012-09-28 21:19:36 +02:00
}
vo_vdpau: split bitmap packing code into a separate file Split the vo_vdpau code that calculates how to pack all subtitle bitmaps into a larger surface into a separate file. This will allow using it in other VOs. Conflicts: Makefile libvo/vo_vdpau.c Note: this commit does the same as an earlier commit by me (4010dd0b1a27e3996). My commit added the vo_vdpau packer code as eosd_packer.c, while this commit by uau uses bitmap_packer.c. Since bitmap_packer.c has a different interface, and because there are more commits changing OSD rendering coming, I will pick uau's version. However, vo_gl, vo_gl3 and vo_direct3d are still using eosd_packer.c, so to make the transition easier, don't delete eosd_packer.c yet.
2012-08-26 18:00:26 +02:00
sub: create sub_bitmap array even when using libass One sub_bitmaps struct could contain either a libass ASS_Image list, or a mplayer native list of sub-bitmaps. This caused code duplication in vo_vdpau.c and bitmap_packer.c. Avoid this by creating such a sub_bitmap array even with libass. This basically copies the list and recreates it in mplayer's native format. It gets rid of the code duplication, and will make implementing extended subtitle and OSD rendering in other VOs easier. Also do some cosmetic changes and other preparations for the following commits.
2012-09-28 21:19:36 +02:00
for (int i = 0 ;i < sfc->packer->count; i++) {
struct sub_bitmap *b = &imgs->parts[i];
VO, sub: refactor Remove VFCTRL_DRAW_OSD, VFCAP_EOSD_FILTER, VFCAP_EOSD_RGBA, VFCAP_EOSD, VOCTRL_DRAW_EOSD, VOCTRL_GET_EOSD_RES, VOCTRL_QUERY_EOSD_FORMAT. Remove draw_osd_with_eosd(), which rendered the OSD by calling VOCTRL_DRAW_EOSD. Change VOs to call osd_draw() directly, which takes a callback as argument. (This basically works like the old OSD API, except multiple OSD bitmap formats are supported and caching is possible.) Remove all mentions of "eosd". It's simply "osd" now. Make OSD size per-OSD-object, as they can be different when using vf_sub. Include display_par/video_par in resolution change detection. Fix the issue with margin borders in vo_corevideo.
2012-10-19 19:25:18 +02:00
struct osd_target *target = sfc->targets + sfc->render_count;
sub: create sub_bitmap array even when using libass One sub_bitmaps struct could contain either a libass ASS_Image list, or a mplayer native list of sub-bitmaps. This caused code duplication in vo_vdpau.c and bitmap_packer.c. Avoid this by creating such a sub_bitmap array even with libass. This basically copies the list and recreates it in mplayer's native format. It gets rid of the code duplication, and will make implementing extended subtitle and OSD rendering in other VOs easier. Also do some cosmetic changes and other preparations for the following commits.
2012-09-28 21:19:36 +02:00
int x = sfc->packer->result[i].x;
int y = sfc->packer->result[i].y;
target->source = (VdpRect){x, y, x + b->w, y + b->h};
target->dest = (VdpRect){b->x, b->y, b->x + b->dw, b->y + b->dh};
target->color = (VdpColor){1, 1, 1, 1};
if (imgs->format == SUBBITMAP_LIBASS) {
uint32_t color = b->libass.color;
target->color.alpha = 1.0 - ((color >> 0) & 0xff) / 255.0;
target->color.blue = ((color >> 8) & 0xff) / 255.0;
target->color.green = ((color >> 16) & 0xff) / 255.0;
target->color.red = ((color >> 24) & 0xff) / 255.0;
subs, vo_vdpau: support RGBA color for PGS subtitles Support passing bitmap subtitles to VOs in full RGBA color, and implement this for libavcodec-decoded subtitle formats on decoding side and vo_vdpau on display side. Currently this is enabled for PGS (blu-ray) and DVB subtitles. VDPAU seems to have sampling issues similar to known GL ones when drawing a sub-rectangle from a larger texture with scaling, where adjacent pixels outside the specified source rectangle affect the result. As the bitmap subtitles may be scaled, add padding support to the bitmap packer code. In principle, this could be used for colored DVD subtitles too. However, the libavcodec DVD decoder lacks parts of the resolution and palette handling that are present in spudec.c. Conflicts: libvo/vo_gl.c sub/dec_sub.h sub/sd_lavc.c
2012-08-31 14:42:30 +02:00
}
sub: create sub_bitmap array even when using libass One sub_bitmaps struct could contain either a libass ASS_Image list, or a mplayer native list of sub-bitmaps. This caused code duplication in vo_vdpau.c and bitmap_packer.c. Avoid this by creating such a sub_bitmap array even with libass. This basically copies the list and recreates it in mplayer's native format. It gets rid of the code duplication, and will make implementing extended subtitle and OSD rendering in other VOs easier. Also do some cosmetic changes and other preparations for the following commits.
2012-09-28 21:19:36 +02:00
if (need_upload) {
vdp_st = vdp->
bitmap_surface_put_bits_native(sfc->surface,
&(const void *){b->bitmap},
&(uint32_t){b->stride},
&target->source);
vdpau: mp_msg conversions
2013-12-21 18:05:23 +01:00
CHECK_VDP_WARNING(vo, "OSD: putbits failed");
vo_vdpau: split bitmap packing code into a separate file Split the vo_vdpau code that calculates how to pack all subtitle bitmaps into a larger surface into a separate file. This will allow using it in other VOs. Conflicts: Makefile libvo/vo_vdpau.c Note: this commit does the same as an earlier commit by me (4010dd0b1a27e3996). My commit added the vo_vdpau packer code as eosd_packer.c, while this commit by uau uses bitmap_packer.c. Since bitmap_packer.c has a different interface, and because there are more commits changing OSD rendering coming, I will pick uau's version. However, vo_gl, vo_gl3 and vo_direct3d are still using eosd_packer.c, so to make the transition easier, don't delete eosd_packer.c yet.
2012-08-26 18:00:26 +02:00
}
vo_vdpau: allow multiple EOSD renderers Preparation for using new OSD rendering method.
2012-09-28 21:49:09 +02:00
sfc->render_count++;
vo_vdpau: split bitmap packing code into a separate file Split the vo_vdpau code that calculates how to pack all subtitle bitmaps into a larger surface into a separate file. This will allow using it in other VOs. Conflicts: Makefile libvo/vo_vdpau.c Note: this commit does the same as an earlier commit by me (4010dd0b1a27e3996). My commit added the vo_vdpau packer code as eosd_packer.c, while this commit by uau uses bitmap_packer.c. Since bitmap_packer.c has a different interface, and because there are more commits changing OSD rendering coming, I will pick uau's version. However, vo_gl, vo_gl3 and vo_direct3d are still using eosd_packer.c, so to make the transition easier, don't delete eosd_packer.c yet.
2012-08-26 18:00:26 +02:00
}
sub: create sub_bitmap array even when using libass One sub_bitmaps struct could contain either a libass ASS_Image list, or a mplayer native list of sub-bitmaps. This caused code duplication in vo_vdpau.c and bitmap_packer.c. Avoid this by creating such a sub_bitmap array even with libass. This basically copies the list and recreates it in mplayer's native format. It gets rid of the code duplication, and will make implementing extended subtitle and OSD rendering in other VOs easier. Also do some cosmetic changes and other preparations for the following commits.
2012-09-28 21:19:36 +02:00
vo_vdpau: allow multiple EOSD renderers Preparation for using new OSD rendering method.
2012-09-28 21:49:09 +02:00
sfc->bitmap_id = imgs->bitmap_id;
sfc->bitmap_pos_id = imgs->bitmap_pos_id;
vo_vdpau: split bitmap packing code into a separate file Split the vo_vdpau code that calculates how to pack all subtitle bitmaps into a larger surface into a separate file. This will allow using it in other VOs. Conflicts: Makefile libvo/vo_vdpau.c Note: this commit does the same as an earlier commit by me (4010dd0b1a27e3996). My commit added the vo_vdpau packer code as eosd_packer.c, while this commit by uau uses bitmap_packer.c. Since bitmap_packer.c has a different interface, and because there are more commits changing OSD rendering coming, I will pick uau's version. However, vo_gl, vo_gl3 and vo_direct3d are still using eosd_packer.c, so to make the transition easier, don't delete eosd_packer.c yet.
2012-08-26 18:00:26 +02:00
}
libvo, vo_vdpau: make the EOSD packer code from vo_vdpau generic The code in eosd_packer.c/.h is taken from vo_vdpau.c and has been made independent from vdpau API specifics. This allows other VOs, which need to pack the small EOSD images into a large surface for efficiency, to use this code.
2011-10-27 12:07:10 +02:00
VO, sub: refactor Remove VFCTRL_DRAW_OSD, VFCAP_EOSD_FILTER, VFCAP_EOSD_RGBA, VFCAP_EOSD, VOCTRL_DRAW_EOSD, VOCTRL_GET_EOSD_RES, VOCTRL_QUERY_EOSD_FORMAT. Remove draw_osd_with_eosd(), which rendered the OSD by calling VOCTRL_DRAW_EOSD. Change VOs to call osd_draw() directly, which takes a callback as argument. (This basically works like the old OSD API, except multiple OSD bitmap formats are supported and caching is possible.) Remove all mentions of "eosd". It's simply "osd" now. Make OSD size per-OSD-object, as they can be different when using vf_sub. Include display_par/video_par in resolution change detection. Fix the issue with margin borders in vo_corevideo.
2012-10-19 19:25:18 +02:00
static void draw_osd_cb(void *ctx, struct sub_bitmaps *imgs)
vo_vdpau: split bitmap packing code into a separate file Split the vo_vdpau code that calculates how to pack all subtitle bitmaps into a larger surface into a separate file. This will allow using it in other VOs. Conflicts: Makefile libvo/vo_vdpau.c Note: this commit does the same as an earlier commit by me (4010dd0b1a27e3996). My commit added the vo_vdpau packer code as eosd_packer.c, while this commit by uau uses bitmap_packer.c. Since bitmap_packer.c has a different interface, and because there are more commits changing OSD rendering coming, I will pick uau's version. However, vo_gl, vo_gl3 and vo_direct3d are still using eosd_packer.c, so to make the transition easier, don't delete eosd_packer.c yet.
2012-08-26 18:00:26 +02:00
{
struct vo *vo = ctx;
VO, sub: refactor Remove VFCTRL_DRAW_OSD, VFCAP_EOSD_FILTER, VFCAP_EOSD_RGBA, VFCAP_EOSD, VOCTRL_DRAW_EOSD, VOCTRL_GET_EOSD_RES, VOCTRL_QUERY_EOSD_FORMAT. Remove draw_osd_with_eosd(), which rendered the OSD by calling VOCTRL_DRAW_EOSD. Change VOs to call osd_draw() directly, which takes a callback as argument. (This basically works like the old OSD API, except multiple OSD bitmap formats are supported and caching is possible.) Remove all mentions of "eosd". It's simply "osd" now. Make OSD size per-OSD-object, as they can be different when using vf_sub. Include display_par/video_par in resolution change detection. Fix the issue with margin borders in vo_corevideo.
2012-10-19 19:25:18 +02:00
generate_osd_part(vo, imgs);
draw_osd_part(vo, imgs->render_index);
vo_vdpau: split bitmap packing code into a separate file Split the vo_vdpau code that calculates how to pack all subtitle bitmaps into a larger surface into a separate file. This will allow using it in other VOs. Conflicts: Makefile libvo/vo_vdpau.c Note: this commit does the same as an earlier commit by me (4010dd0b1a27e3996). My commit added the vo_vdpau packer code as eosd_packer.c, while this commit by uau uses bitmap_packer.c. Since bitmap_packer.c has a different interface, and because there are more commits changing OSD rendering coming, I will pick uau's version. However, vo_gl, vo_gl3 and vo_direct3d are still using eosd_packer.c, so to make the transition easier, don't delete eosd_packer.c yet.
2012-08-26 18:00:26 +02:00
}
VO, sub: refactor Remove VFCTRL_DRAW_OSD, VFCAP_EOSD_FILTER, VFCAP_EOSD_RGBA, VFCAP_EOSD, VOCTRL_DRAW_EOSD, VOCTRL_GET_EOSD_RES, VOCTRL_QUERY_EOSD_FORMAT. Remove draw_osd_with_eosd(), which rendered the OSD by calling VOCTRL_DRAW_EOSD. Change VOs to call osd_draw() directly, which takes a callback as argument. (This basically works like the old OSD API, except multiple OSD bitmap formats are supported and caching is possible.) Remove all mentions of "eosd". It's simply "osd" now. Make OSD size per-OSD-object, as they can be different when using vf_sub. Include display_par/video_par in resolution change detection. Fix the issue with margin borders in vo_corevideo.
2012-10-19 19:25:18 +02:00
static void draw_osd(struct vo *vo, struct osd_state *osd)
vo_vdpau: split bitmap packing code into a separate file Split the vo_vdpau code that calculates how to pack all subtitle bitmaps into a larger surface into a separate file. This will allow using it in other VOs. Conflicts: Makefile libvo/vo_vdpau.c Note: this commit does the same as an earlier commit by me (4010dd0b1a27e3996). My commit added the vo_vdpau packer code as eosd_packer.c, while this commit by uau uses bitmap_packer.c. Since bitmap_packer.c has a different interface, and because there are more commits changing OSD rendering coming, I will pick uau's version. However, vo_gl, vo_gl3 and vo_direct3d are still using eosd_packer.c, so to make the transition easier, don't delete eosd_packer.c yet.
2012-08-26 18:00:26 +02:00
{
struct vdpctx *vc = vo->priv;
VO, sub: refactor Remove VFCTRL_DRAW_OSD, VFCAP_EOSD_FILTER, VFCAP_EOSD_RGBA, VFCAP_EOSD, VOCTRL_DRAW_EOSD, VOCTRL_GET_EOSD_RES, VOCTRL_QUERY_EOSD_FORMAT. Remove draw_osd_with_eosd(), which rendered the OSD by calling VOCTRL_DRAW_EOSD. Change VOs to call osd_draw() directly, which takes a callback as argument. (This basically works like the old OSD API, except multiple OSD bitmap formats are supported and caching is possible.) Remove all mentions of "eosd". It's simply "osd" now. Make OSD size per-OSD-object, as they can be different when using vf_sub. Include display_par/video_par in resolution change detection. Fix the issue with margin borders in vo_corevideo.
2012-10-19 19:25:18 +02:00
if (!status_ok(vo))
vo_vdpau: split bitmap packing code into a separate file Split the vo_vdpau code that calculates how to pack all subtitle bitmaps into a larger surface into a separate file. This will allow using it in other VOs. Conflicts: Makefile libvo/vo_vdpau.c Note: this commit does the same as an earlier commit by me (4010dd0b1a27e3996). My commit added the vo_vdpau packer code as eosd_packer.c, while this commit by uau uses bitmap_packer.c. Since bitmap_packer.c has a different interface, and because there are more commits changing OSD rendering coming, I will pick uau's version. However, vo_gl, vo_gl3 and vo_direct3d are still using eosd_packer.c, so to make the transition easier, don't delete eosd_packer.c yet.
2012-08-26 18:00:26 +02:00
return;
VO, sub: refactor Remove VFCTRL_DRAW_OSD, VFCAP_EOSD_FILTER, VFCAP_EOSD_RGBA, VFCAP_EOSD, VOCTRL_DRAW_EOSD, VOCTRL_GET_EOSD_RES, VOCTRL_QUERY_EOSD_FORMAT. Remove draw_osd_with_eosd(), which rendered the OSD by calling VOCTRL_DRAW_EOSD. Change VOs to call osd_draw() directly, which takes a callback as argument. (This basically works like the old OSD API, except multiple OSD bitmap formats are supported and caching is possible.) Remove all mentions of "eosd". It's simply "osd" now. Make OSD size per-OSD-object, as they can be different when using vf_sub. Include display_par/video_par in resolution change detection. Fix the issue with margin borders in vo_corevideo.
2012-10-19 19:25:18 +02:00
static const bool formats[SUBBITMAP_COUNT] = {
[SUBBITMAP_LIBASS] = true,
[SUBBITMAP_RGBA] = true,
vo_vdpau: split bitmap packing code into a separate file Split the vo_vdpau code that calculates how to pack all subtitle bitmaps into a larger surface into a separate file. This will allow using it in other VOs. Conflicts: Makefile libvo/vo_vdpau.c Note: this commit does the same as an earlier commit by me (4010dd0b1a27e3996). My commit added the vo_vdpau packer code as eosd_packer.c, while this commit by uau uses bitmap_packer.c. Since bitmap_packer.c has a different interface, and because there are more commits changing OSD rendering coming, I will pick uau's version. However, vo_gl, vo_gl3 and vo_direct3d are still using eosd_packer.c, so to make the transition easier, don't delete eosd_packer.c yet.
2012-08-26 18:00:26 +02:00
};
sub: uglify OSD code path with locking Do two things: 1. add locking to struct osd_state 2. make struct osd_state opaque While 1. is somewhat simple, 2. is quite horrible. Lots of code accesses lots of osd_state (and osd_object) members. To make sure everything is accessed synchronously, I prefer making osd_state opaque, even if it means adding pretty dumb accessors. All of this is meant to allow running VO in their own threads. Eventually, VOs will request OSD on their own, which means osd_state will be accessed from foreign threads.
2014-01-18 01:19:20 +01:00
osd_draw(osd, vc->osd_rect, osd_get_vo_pts(osd), 0, formats, draw_osd_cb, vo);
Add support for VDPAU video out, including hardware decoding. git-svn-id: svn://svn.mplayerhq.hu/mplayer/trunk@28617 b3059339-0415-0410-9bf9-f77b7e298cf2
2009-02-16 21:58:13 +01:00
}
vo_vdpau: support queuing an arbitrary number of frames ahead Make the number of output surfaces allocated by vo_vdpau configurable and allow queuing multiple future frames with the VDPAU frame timing functionality. There are two known issues that could be polished in the future for particularly long queue time cases. First, toplevel code should possibly wait for the queued changes to finish displaying in some situations like switching files. Second, the VO can block waiting for a surface to become available, and in the worst case this wait can be almost as long as the maximum queuing time (potentially causing audio underruns). However those issues are not high priority.
2010-05-14 04:18:38 +02:00
static int update_presentation_queue_status(struct vo *vo)
Add support for VDPAU video out, including hardware decoding. git-svn-id: svn://svn.mplayerhq.hu/mplayer/trunk@28617 b3059339-0415-0410-9bf9-f77b7e298cf2
2009-02-16 21:58:13 +01:00
{
vo_vdpau: Replace global function table with context variable
2009-05-06 20:04:37 +02:00
struct vdpctx *vc = vo->priv;
struct vdp_functions *vdp = vc->vdp;
Add support for VDPAU video out, including hardware decoding. git-svn-id: svn://svn.mplayerhq.hu/mplayer/trunk@28617 b3059339-0415-0410-9bf9-f77b7e298cf2
2009-02-16 21:58:13 +01:00
VdpStatus vdp_st;
vo_vdpau.c: cosmetics
2009-05-09 17:08:30 +02:00
vo_vdpau: support queuing an arbitrary number of frames ahead Make the number of output surfaces allocated by vo_vdpau configurable and allow queuing multiple future frames with the VDPAU frame timing functionality. There are two known issues that could be polished in the future for particularly long queue time cases. First, toplevel code should possibly wait for the queued changes to finish displaying in some situations like switching files. Second, the VO can block waiting for a surface to become available, and in the worst case this wait can be almost as long as the maximum queuing time (potentially causing audio underruns). However those issues are not high priority.
2010-05-14 04:18:38 +02:00
while (vc->query_surface_num != vc->surface_num) {
VdpTime vtime;
VdpPresentationQueueStatus status;
VdpOutputSurface surface = vc->output_surfaces[vc->query_surface_num];
vdp_st = vdp->presentation_queue_query_surface_status(vc->flip_queue,
surface,
&status, &vtime);
vdpau: mp_msg conversions
2013-12-21 18:05:23 +01:00
CHECK_VDP_WARNING(vo, "Error calling "
vo_vdpau: support queuing an arbitrary number of frames ahead Make the number of output surfaces allocated by vo_vdpau configurable and allow queuing multiple future frames with the VDPAU frame timing functionality. There are two known issues that could be polished in the future for particularly long queue time cases. First, toplevel code should possibly wait for the queued changes to finish displaying in some situations like switching files. Second, the VO can block waiting for a surface to become available, and in the worst case this wait can be almost as long as the maximum queuing time (potentially causing audio underruns). However those issues are not high priority.
2010-05-14 04:18:38 +02:00
"presentation_queue_query_surface_status");
vo_vdpau: more debugging output Might help to debug certain problems with Mesa.
2014-04-03 19:41:09 +02:00
if (mp_msg_test(vo->log, MSGL_TRACE)) {
VdpTime current;
vdp_st = vdp->presentation_queue_get_time(vc->flip_queue, &current);
CHECK_VDP_WARNING(vo, "Error when calling "
"vdp_presentation_queue_get_time");
MP_TRACE(vo, "Vdpau time: %"PRIu64"\n", (uint64_t)current);
MP_TRACE(vo, "Surface %d status: %d time: %"PRIu64"\n",
(int)surface, (int)status, (uint64_t)vtime);
}
vo_vdpau: support queuing an arbitrary number of frames ahead Make the number of output surfaces allocated by vo_vdpau configurable and allow queuing multiple future frames with the VDPAU frame timing functionality. There are two known issues that could be polished in the future for particularly long queue time cases. First, toplevel code should possibly wait for the queued changes to finish displaying in some situations like switching files. Second, the VO can block waiting for a surface to become available, and in the worst case this wait can be almost as long as the maximum queuing time (potentially causing audio underruns). However those issues are not high priority.
2010-05-14 04:18:38 +02:00
if (status == VDP_PRESENTATION_QUEUE_STATUS_QUEUED)
break;
if (vc->vsync_interval > 1) {
uint64_t qtime = vc->queue_time[vc->query_surface_num];
vo_vdpau: add some debugging messages for frame timing Note that this will print a difference even with perfect sync, because the code queues the frames _between_ vsync, probably for error margin (though I don't understand why it uses the exact values chosen).
2013-12-22 15:48:38 +01:00
int diff = ((int64_t)vtime - (int64_t)qtime) / 1e6;
MP_TRACE(vo, "Queue time difference: %d ms\n", diff);
vo_vdpau: support queuing an arbitrary number of frames ahead Make the number of output surfaces allocated by vo_vdpau configurable and allow queuing multiple future frames with the VDPAU frame timing functionality. There are two known issues that could be polished in the future for particularly long queue time cases. First, toplevel code should possibly wait for the queued changes to finish displaying in some situations like switching files. Second, the VO can block waiting for a surface to become available, and in the worst case this wait can be almost as long as the maximum queuing time (potentially causing audio underruns). However those issues are not high priority.
2010-05-14 04:18:38 +02:00
if (vtime < qtime + vc->vsync_interval / 2)
vo_vdpau: add some debugging messages for frame timing Note that this will print a difference even with perfect sync, because the code queues the frames _between_ vsync, probably for error margin (though I don't understand why it uses the exact values chosen).
2013-12-22 15:48:38 +01:00
MP_VERBOSE(vo, "Frame shown too early (%d ms)\n", diff);
vo_vdpau: support queuing an arbitrary number of frames ahead Make the number of output surfaces allocated by vo_vdpau configurable and allow queuing multiple future frames with the VDPAU frame timing functionality. There are two known issues that could be polished in the future for particularly long queue time cases. First, toplevel code should possibly wait for the queued changes to finish displaying in some situations like switching files. Second, the VO can block waiting for a surface to become available, and in the worst case this wait can be almost as long as the maximum queuing time (potentially causing audio underruns). However those issues are not high priority.
2010-05-14 04:18:38 +02:00
if (vtime > qtime + vc->vsync_interval)
vo_vdpau: add some debugging messages for frame timing Note that this will print a difference even with perfect sync, because the code queues the frames _between_ vsync, probably for error margin (though I don't understand why it uses the exact values chosen).
2013-12-22 15:48:38 +01:00
MP_VERBOSE(vo, "Frame shown late (%d ms)\n", diff);
vo_vdpau: support queuing an arbitrary number of frames ahead Make the number of output surfaces allocated by vo_vdpau configurable and allow queuing multiple future frames with the VDPAU frame timing functionality. There are two known issues that could be polished in the future for particularly long queue time cases. First, toplevel code should possibly wait for the queued changes to finish displaying in some situations like switching files. Second, the VO can block waiting for a surface to become available, and in the worst case this wait can be almost as long as the maximum queuing time (potentially causing audio underruns). However those issues are not high priority.
2010-05-14 04:18:38 +02:00
}
vc->query_surface_num = WRAP_ADD(vc->query_surface_num, 1,
vc->num_output_surfaces);
vc->recent_vsync_time = vtime;
}
int num_queued = WRAP_ADD(vc->surface_num, -vc->query_surface_num,
vc->num_output_surfaces);
Some more mp_msg conversions Also add a note to mp_msg.h, since it might be not clear which of the two mechanisms is preferred.
2013-08-23 23:30:09 +02:00
MP_DBG(vo, "Queued surface count (before add): %d\n", num_queued);
vo_vdpau: support queuing an arbitrary number of frames ahead Make the number of output surfaces allocated by vo_vdpau configurable and allow queuing multiple future frames with the VDPAU frame timing functionality. There are two known issues that could be polished in the future for particularly long queue time cases. First, toplevel code should possibly wait for the queued changes to finish displaying in some situations like switching files. Second, the VO can block waiting for a surface to become available, and in the worst case this wait can be almost as long as the maximum queuing time (potentially causing audio underruns). However those issues are not high priority.
2010-05-14 04:18:38 +02:00
return num_queued;
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
}
vo_vdpau: simplify previous vsync timestamp calculation The strange thing about this code was the shift parameter of the prev_vs2 function. The parameter is used to handle timestamps before the last vsync, since the % operator handles negative values incorrectly. Most callers set shift to 0, and _usually_ pass a timestamp after the last vsync. One caller sets it to 16, and can pass a timestamp before the last timestamp. The mystery is why prev_vs2 doesn't just compensate for the % operator semantics in the most simple way: if the result of the operator is negative, add the divisor to it. Instead, it adds a huge value to it (how huge is influenced by shift). If shift is 0, the result of the function will not be aligned to vsyncs. I have no idea why it was written in this way. Were there concerns about certain numeric overflows that could happen in the calculations? But I can't think of any (the difference between ts and vc->recent_vsync_time is usually not that huge). Or is there something more clever about it, which is important for the timing code? I can't think of anything either. So scrap it and simplify it.
2014-04-08 19:02:57 +02:00
// Return the timestamp of the vsync that must have happened before ts.
static inline uint64_t prev_vsync(struct vdpctx *vc, uint64_t ts)
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
{
vo_vdpau: simplify previous vsync timestamp calculation The strange thing about this code was the shift parameter of the prev_vs2 function. The parameter is used to handle timestamps before the last vsync, since the % operator handles negative values incorrectly. Most callers set shift to 0, and _usually_ pass a timestamp after the last vsync. One caller sets it to 16, and can pass a timestamp before the last timestamp. The mystery is why prev_vs2 doesn't just compensate for the % operator semantics in the most simple way: if the result of the operator is negative, add the divisor to it. Instead, it adds a huge value to it (how huge is influenced by shift). If shift is 0, the result of the function will not be aligned to vsyncs. I have no idea why it was written in this way. Were there concerns about certain numeric overflows that could happen in the calculations? But I can't think of any (the difference between ts and vc->recent_vsync_time is usually not that huge). Or is there something more clever about it, which is important for the timing code? I can't think of anything either. So scrap it and simplify it.
2014-04-08 19:02:57 +02:00
int64_t diff = (int64_t)(ts - vc->recent_vsync_time);
int64_t offset = diff % vc->vsync_interval;
if (offset < 0)
offset += vc->vsync_interval;
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
return ts - offset;
}
Replace all calls to GetTimer()/GetTimerMS() GetTimer() is generally replaced with mp_time_us(). Both calls return microseconds, but the latter uses int64_t, us defined to never wrap, and never returns 0 or negative values. GetTimerMS() has no direct replacement. Instead the other functions are used. For some code, switch to mp_time_sec(), which returns the time as double float value in seconds. The returned time is offset to program start time, so there is enough precision left to deliver microsecond resolution for at least 100 years. Unless it's casted to a float (or the CPU reduces precision), which is why we still use mp_time_us() out of paranoia in places where precision is clearly needed. Always switch to the correct time. The whole point of the new timer calls is that they don't wrap, and storing microseconds in unsigned int variables would negate this. In some cases, remove wrap-around handling for time values.
2013-05-25 18:31:06 +02:00
static void flip_page_timed(struct vo *vo, int64_t pts_us, int duration)
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
{
struct vdpctx *vc = vo->priv;
struct vdp_functions *vdp = vc->vdp;
VdpStatus vdp_st;
uint32_t vsync_interval = vc->vsync_interval;
vo_vdpau: Support recovering from VDPAU display preemption Add code to reinitialize all VDPAU objects if a display preemption condition occurs. Reinitializing them in the middle of playback will cause video corruption at least until the next keyframe when using hardware decoding, but decoding does seem to recover after a keyframe.
2009-09-07 01:02:24 +02:00
if (handle_preemption(vo) < 0)
return;
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 (duration > INT_MAX / 1000)
duration = -1;
else
duration *= 1000;
vo_vdpau: disable refresh-aware frame timing when composited Under a compositing window manager the current VDPAU implementation behaves differently than without it. Frame flip timing info becomes incorrect (I guess it only reflects when the frame was sent to the compositor, not when it was actually shown), and there is no limitation to at most one frame switch per refresh like without compositing. Detect whether a compositing window manager is active and disable refresh-aware frame timing and dropping in this case, similarly to what fps=-1 would do. This behavior can be controlled with the new suboption "composite-detect". Disabling the refresh-aware logic makes timing somewhat less accurate. Because the video switch rate limit isn't there, the lack of frame dropping on player side does not impose a hard limit on video FPS, but does reduce performance somewhat as redundant frames are drawn in memory. The existence of a compositing window manager does not guarantee that the current window is actually composited, so the current check is not foolproof. In particular, some WMs have support for a "unredirect fullscreen windows" option. Support for such things could be improved.
2012-07-27 02:40:38 +02:00
if (vc->vsync_interval == 1)
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
duration = -1; // Make sure drop logic is disabled
vo_vdpau: simplify time management and make it more robust vo_vdpau used a somewhat complicated and fragile mechanism to convert the vdpau time to internal mpv time. This was fragile as in it couldn't deal well with Mesa's (apparently) random timestamps, which can change the base offset in multiple situations. It can happen when moving the mpv window to a different screen, and somehow it also happens when pausing the player. It seems this mechanism to synchronize the vdpau time is not actually needed. There are only 2 places where sync_vdptime() is used (i.e. returning the current vdpau time interpolated by system time). The first call is for determining the PTS used to queue a frame. This also uses convert_to_vdptime(). It's easily replaced by querying the time directly, and adding the wait time to it (rel_pts_ns in the patch). The second call is pretty odd: it updates the vdpau time a second time in the same function. From what I can see, this can matter only if update_presentation_queue_status() is very slow. I'm not sure what to make out of this, because the call merely queries the presentation queue. Just assume it isn't slow, and that we don't have to update the time. Another potential issue with this is that we call VdpPresentationQueueGetTime() every frame now, instead of every 5 seconds and interpolating the other calls via system time. More over, this is per video frame (which can be portantially dropped, and not per actually displayed frame. Assume this doesn't matter. This simplifies the code, and should make it more robust on Mesa. But note that what Mesa does is obviously insane - this is one situation where you really need a stable time source. There are still plenty of race condition windows where things can go wrong, although this commit should drastically reduce the possibility of this. In my tests, everything worked well. But I have no access to a Mesa system with vdpau, so it needs testing by others. See github issues #520, #694, #695.
2014-04-07 18:33:25 +02:00
VdpTime vdp_time = 0;
vdp_st = vdp->presentation_queue_get_time(vc->flip_queue, &vdp_time);
CHECK_VDP_WARNING(vo, "Error when calling vdp_presentation_queue_get_time");
int64_t rel_pts_ns = (pts_us - mp_time_us()) * 1000;
if (!pts_us || rel_pts_ns < 0)
rel_pts_ns = 0;
vo_vdpau: Ensure presentation time is within bounds When a time sync happens the last sync time is the minimum time that can be used for presentation.
2014-02-02 12:07:08 +01:00
vo_vdpau: simplify time management and make it more robust vo_vdpau used a somewhat complicated and fragile mechanism to convert the vdpau time to internal mpv time. This was fragile as in it couldn't deal well with Mesa's (apparently) random timestamps, which can change the base offset in multiple situations. It can happen when moving the mpv window to a different screen, and somehow it also happens when pausing the player. It seems this mechanism to synchronize the vdpau time is not actually needed. There are only 2 places where sync_vdptime() is used (i.e. returning the current vdpau time interpolated by system time). The first call is for determining the PTS used to queue a frame. This also uses convert_to_vdptime(). It's easily replaced by querying the time directly, and adding the wait time to it (rel_pts_ns in the patch). The second call is pretty odd: it updates the vdpau time a second time in the same function. From what I can see, this can matter only if update_presentation_queue_status() is very slow. I'm not sure what to make out of this, because the call merely queries the presentation queue. Just assume it isn't slow, and that we don't have to update the time. Another potential issue with this is that we call VdpPresentationQueueGetTime() every frame now, instead of every 5 seconds and interpolating the other calls via system time. More over, this is per video frame (which can be portantially dropped, and not per actually displayed frame. Assume this doesn't matter. This simplifies the code, and should make it more robust on Mesa. But note that what Mesa does is obviously insane - this is one situation where you really need a stable time source. There are still plenty of race condition windows where things can go wrong, although this commit should drastically reduce the possibility of this. In my tests, everything worked well. But I have no access to a Mesa system with vdpau, so it needs testing by others. See github issues #520, #694, #695.
2014-04-07 18:33:25 +02:00
uint64_t now = vdp_time;
uint64_t pts = now + rel_pts_ns;
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
uint64_t ideal_pts = pts;
uint64_t npts = duration >= 0 ? pts + duration : UINT64_MAX;
vo_vdpau: add an additional check for timestamp robustness This might be a good idea in order to prevent queuing a frame too far in the future (causing apparent freezing of the video display), or dropping an infinite number of frames (also apparent as freezing). I think at this point this is most of what we can do if the vdpau time source is unreliable (like with Mesa). There are still inherent race conditions which can't be fixed.
2014-04-08 20:16:53 +02:00
/* This should normally never happen.
* - The last queued frame can't have a PTS that goes more than 50ms in the
* future. This is guaranteed by the playloop, which currently actually
* roughly queues 50ms ahead, plus the flip queue offset. Just to be sure
* give some additional room by doubling the time.
* - The last vsync can never be in the future.
*/
int64_t max_pts_ahead = (vo->flip_queue_offset + 0.050) * 2 * 1e9;
if (vc->last_queue_time > now + max_pts_ahead ||
vc->recent_vsync_time > now)
{
vc->last_queue_time = 0;
vc->recent_vsync_time = 0;
MP_WARN(vo, "Inconsistent timing detected.\n");
}
vo_vdpau: simplify previous vsync timestamp calculation The strange thing about this code was the shift parameter of the prev_vs2 function. The parameter is used to handle timestamps before the last vsync, since the % operator handles negative values incorrectly. Most callers set shift to 0, and _usually_ pass a timestamp after the last vsync. One caller sets it to 16, and can pass a timestamp before the last timestamp. The mystery is why prev_vs2 doesn't just compensate for the % operator semantics in the most simple way: if the result of the operator is negative, add the divisor to it. Instead, it adds a huge value to it (how huge is influenced by shift). If shift is 0, the result of the function will not be aligned to vsyncs. I have no idea why it was written in this way. Were there concerns about certain numeric overflows that could happen in the calculations? But I can't think of any (the difference between ts and vc->recent_vsync_time is usually not that huge). Or is there something more clever about it, which is important for the timing code? I can't think of anything either. So scrap it and simplify it.
2014-04-08 19:02:57 +02:00
#define PREV_VSYNC(ts) prev_vsync(vc, ts)
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
/* We hope to be here at least one vsync before the frame should be shown.
* If we are running late then don't drop the frame unless there is
* already one queued for the next vsync; even if we _hope_ to show the
* next frame soon enough to mean this one should be dropped we might
* not make the target time in reality. Without this check we could drop
* every frame, freezing the display completely if video lags behind.
*/
vo_vdpau.c cosmetics: add WRAP_ADD macro The macro is meant to simplify the handling of some code dealing with circular buffers.
2010-05-06 03:46:10 +02:00
if (now > PREV_VSYNC(FFMAX(pts, vc->last_queue_time + vsync_interval)))
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
npts = UINT64_MAX;
/* Allow flipping a frame at a vsync if its presentation time is a
* bit after that vsync and the change makes the flip time delta
* from previous frame better match the target timestamp delta.
* This avoids instability with frame timestamps falling near vsyncs.
* For example if the frame timestamps were (with vsyncs at
* integer values) 0.01, 1.99, 4.01, 5.99, 8.01, ... then
* straightforward timing at next vsync would flip the frames at
* 1, 2, 5, 6, 9; this changes it to 1, 2, 4, 6, 8 and so on with
* regular 2-vsync intervals.
*
* Also allow moving the frame forward if it looks like we dropped
* the previous frame incorrectly (now that we know better after
* having final exact timestamp information for this frame) and
* there would unnecessarily be a vsync without a frame change.
*/
uint64_t vsync = PREV_VSYNC(pts);
if (pts < vsync + vsync_interval / 4
vo_vdpau: simplify previous vsync timestamp calculation The strange thing about this code was the shift parameter of the prev_vs2 function. The parameter is used to handle timestamps before the last vsync, since the % operator handles negative values incorrectly. Most callers set shift to 0, and _usually_ pass a timestamp after the last vsync. One caller sets it to 16, and can pass a timestamp before the last timestamp. The mystery is why prev_vs2 doesn't just compensate for the % operator semantics in the most simple way: if the result of the operator is negative, add the divisor to it. Instead, it adds a huge value to it (how huge is influenced by shift). If shift is 0, the result of the function will not be aligned to vsyncs. I have no idea why it was written in this way. Were there concerns about certain numeric overflows that could happen in the calculations? But I can't think of any (the difference between ts and vc->recent_vsync_time is usually not that huge). Or is there something more clever about it, which is important for the timing code? I can't think of anything either. So scrap it and simplify it.
2014-04-08 19:02:57 +02:00
&& (vsync - PREV_VSYNC(vc->last_queue_time)
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
> pts - vc->last_ideal_time + vsync_interval / 2
|| vc->dropped_frame && vsync > vc->dropped_time))
pts -= vsync_interval / 2;
vc->dropped_frame = true; // changed at end if false
vc->dropped_time = ideal_pts;
pts = FFMAX(pts, vc->last_queue_time + vsync_interval);
pts = FFMAX(pts, now);
if (npts < PREV_VSYNC(pts) + vsync_interval)
return;
vo_vdpau: support queuing an arbitrary number of frames ahead Make the number of output surfaces allocated by vo_vdpau configurable and allow queuing multiple future frames with the VDPAU frame timing functionality. There are two known issues that could be polished in the future for particularly long queue time cases. First, toplevel code should possibly wait for the queued changes to finish displaying in some situations like switching files. Second, the VO can block waiting for a surface to become available, and in the worst case this wait can be almost as long as the maximum queuing time (potentially causing audio underruns). However those issues are not high priority.
2010-05-14 04:18:38 +02:00
int num_flips = update_presentation_queue_status(vo);
vsync = vc->recent_vsync_time + num_flips * vc->vsync_interval;
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
pts = FFMAX(pts, now);
vo_vdpau: support queuing an arbitrary number of frames ahead Make the number of output surfaces allocated by vo_vdpau configurable and allow queuing multiple future frames with the VDPAU frame timing functionality. There are two known issues that could be polished in the future for particularly long queue time cases. First, toplevel code should possibly wait for the queued changes to finish displaying in some situations like switching files. Second, the VO can block waiting for a surface to become available, and in the worst case this wait can be almost as long as the maximum queuing time (potentially causing audio underruns). However those issues are not high priority.
2010-05-14 04:18:38 +02:00
pts = FFMAX(pts, vsync + (vsync_interval >> 2));
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
vsync = PREV_VSYNC(pts);
if (npts < vsync + vsync_interval)
return;
pts = vsync + (vsync_interval >> 2);
vo_vdpau: more debugging output Might help to debug certain problems with Mesa.
2014-04-03 19:41:09 +02:00
VdpOutputSurface frame = vc->output_surfaces[vc->surface_num];
vdp_st = vdp->presentation_queue_display(vc->flip_queue, frame,
vo->dwidth, vo->dheight, pts);
vdpau: mp_msg conversions
2013-12-21 18:05:23 +01:00
CHECK_VDP_WARNING(vo, "Error when calling vdp_presentation_queue_display");
Add support for VDPAU video out, including hardware decoding. git-svn-id: svn://svn.mplayerhq.hu/mplayer/trunk@28617 b3059339-0415-0410-9bf9-f77b7e298cf2
2009-02-16 21:58:13 +01:00
vo_vdpau: simplify time management and make it more robust vo_vdpau used a somewhat complicated and fragile mechanism to convert the vdpau time to internal mpv time. This was fragile as in it couldn't deal well with Mesa's (apparently) random timestamps, which can change the base offset in multiple situations. It can happen when moving the mpv window to a different screen, and somehow it also happens when pausing the player. It seems this mechanism to synchronize the vdpau time is not actually needed. There are only 2 places where sync_vdptime() is used (i.e. returning the current vdpau time interpolated by system time). The first call is for determining the PTS used to queue a frame. This also uses convert_to_vdptime(). It's easily replaced by querying the time directly, and adding the wait time to it (rel_pts_ns in the patch). The second call is pretty odd: it updates the vdpau time a second time in the same function. From what I can see, this can matter only if update_presentation_queue_status() is very slow. I'm not sure what to make out of this, because the call merely queries the presentation queue. Just assume it isn't slow, and that we don't have to update the time. Another potential issue with this is that we call VdpPresentationQueueGetTime() every frame now, instead of every 5 seconds and interpolating the other calls via system time. More over, this is per video frame (which can be portantially dropped, and not per actually displayed frame. Assume this doesn't matter. This simplifies the code, and should make it more robust on Mesa. But note that what Mesa does is obviously insane - this is one situation where you really need a stable time source. There are still plenty of race condition windows where things can go wrong, although this commit should drastically reduce the possibility of this. In my tests, everything worked well. But I have no access to a Mesa system with vdpau, so it needs testing by others. See github issues #520, #694, #695.
2014-04-07 18:33:25 +02:00
MP_TRACE(vo, "Queue new surface %d: Vdpau time: %"PRIu64" "
"pts: %"PRIu64"\n", (int)frame, now, pts);
vo_vdpau: more debugging output Might help to debug certain problems with Mesa.
2014-04-03 19:41:09 +02:00
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
vc->last_queue_time = pts;
vo_vdpau: support queuing an arbitrary number of frames ahead Make the number of output surfaces allocated by vo_vdpau configurable and allow queuing multiple future frames with the VDPAU frame timing functionality. There are two known issues that could be polished in the future for particularly long queue time cases. First, toplevel code should possibly wait for the queued changes to finish displaying in some situations like switching files. Second, the VO can block waiting for a surface to become available, and in the worst case this wait can be almost as long as the maximum queuing time (potentially causing audio underruns). However those issues are not high priority.
2010-05-14 04:18:38 +02:00
vc->queue_time[vc->surface_num] = pts;
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
vc->last_ideal_time = ideal_pts;
vc->dropped_frame = false;
vo_vdpau: support queuing an arbitrary number of frames ahead Make the number of output surfaces allocated by vo_vdpau configurable and allow queuing multiple future frames with the VDPAU frame timing functionality. There are two known issues that could be polished in the future for particularly long queue time cases. First, toplevel code should possibly wait for the queued changes to finish displaying in some situations like switching files. Second, the VO can block waiting for a surface to become available, and in the worst case this wait can be almost as long as the maximum queuing time (potentially causing audio underruns). However those issues are not high priority.
2010-05-14 04:18:38 +02:00
vc->surface_num = WRAP_ADD(vc->surface_num, 1, vc->num_output_surfaces);
Add support for VDPAU video out, including hardware decoding. git-svn-id: svn://svn.mplayerhq.hu/mplayer/trunk@28617 b3059339-0415-0410-9bf9-f77b7e298cf2
2009-02-16 21:58:13 +01:00
}
vo_vdpau: always use mp_image for internal buffer queue
2014-04-29 15:18:35 +02:00
static void free_rgb_surface(void *ptr)
{
bool *entry = ptr;
*entry = false;
}
static struct mp_image *get_rgb_surface(struct vo *vo)
vo_vdpau: add RGB support Apparently this was dropped some years ago, but judging from MPlayer's handling of this, the original code wasn't so great anyway. The new code handling clearing of panscan borders correctly, and integrates better with the YUV path. (Although the VDPAU API sure makes this annoying with its separate surface types for RGB.) Note that we create 5 surfaces for some reason - I don't think this makes too much sense (because we can't use the deinterlacer with RGB surfaces), but at least it reduces the amount of differences with the YUV code path. Clearing the borders is done by drawing a single black pixel over the window. This sounds pretty dumb, but it appears to work well, and there is no other API for that. (One could try to use the video mixer for this purpose, since it has all kinds of features, including compositing multiple RGBA surfaces and clearing the window background. But it would require an invisible dummy video surface to make the video mixer happy, and that's getting too messy.)
2013-08-18 05:12:21 +02:00
{
struct vdpctx *vc = vo->priv;
assert(vc->rgb_mode);
for (int n = 0; n < NUM_BUFFERED_VIDEO; n++) {
vo_vdpau: always use mp_image for internal buffer queue
2014-04-29 15:18:35 +02:00
bool *used = &vc->rgb_surfaces_used[n];
if (!*used) {
*used = true;
struct mp_image mpi = {0};
vo_vdpau: keep colorspace flags Since vdpau_mixer.c initializes the YUV conversion using the mp_image flags, these images should have all flags set properly.
2014-04-29 15:19:30 +02:00
mp_image_setfmt(&mpi, IMGFMT_VDPAU); // not really, but keep csp flags
vo_vdpau: always use mp_image for internal buffer queue
2014-04-29 15:18:35 +02:00
mpi.planes[0] = (void *)(uintptr_t)vc->rgb_surfaces[n];
return mp_image_new_custom_ref(&mpi, used, free_rgb_surface);
vo_vdpau: add RGB support Apparently this was dropped some years ago, but judging from MPlayer's handling of this, the original code wasn't so great anyway. The new code handling clearing of panscan borders correctly, and integrates better with the YUV path. (Although the VDPAU API sure makes this annoying with its separate surface types for RGB.) Note that we create 5 surfaces for some reason - I don't think this makes too much sense (because we can't use the deinterlacer with RGB surfaces), but at least it reduces the amount of differences with the YUV code path. Clearing the borders is done by drawing a single black pixel over the window. This sounds pretty dumb, but it appears to work well, and there is no other API for that. (One could try to use the video mixer for this purpose, since it has all kinds of features, including compositing multiple RGBA surfaces and clearing the window background. But it would require an invisible dummy video surface to make the video mixer happy, and that's getting too messy.)
2013-08-18 05:12:21 +02:00
}
}
Some more mp_msg conversions Also add a note to mp_msg.h, since it might be not clear which of the two mechanisms is preferred.
2013-08-23 23:30:09 +02:00
MP_ERR(vo, "no surfaces available in get_rgb_surface\n");
vo_vdpau: always use mp_image for internal buffer queue
2014-04-29 15:18:35 +02:00
return NULL;
vo_vdpau: add RGB support Apparently this was dropped some years ago, but judging from MPlayer's handling of this, the original code wasn't so great anyway. The new code handling clearing of panscan borders correctly, and integrates better with the YUV path. (Although the VDPAU API sure makes this annoying with its separate surface types for RGB.) Note that we create 5 surfaces for some reason - I don't think this makes too much sense (because we can't use the deinterlacer with RGB surfaces), but at least it reduces the amount of differences with the YUV code path. Clearing the borders is done by drawing a single black pixel over the window. This sounds pretty dumb, but it appears to work well, and there is no other API for that. (One could try to use the video mixer for this purpose, since it has all kinds of features, including compositing multiple RGBA surfaces and clearing the window background. But it would require an invisible dummy video surface to make the video mixer happy, and that's getting too messy.)
2013-08-18 05:12:21 +02:00
}
video: move video frame queue from vo_vdpau.c to vo.c Remove the special casing of vo_vdpau vs. other VOs. Replace the complicated interaction between vo.c and vo_vdpau.c with a simple queue in vo.c. VOs other than vdpau are handled by setting the length of the queue to 1 (this is essentially what waiting_mpi was). Note that vo_vdpau.c seems to have buffered only 1 or 2 frames into the future, while the remaining 3 or 4 frames were past frames. So the new code buffers 2 frames (vo_vdpau.c requests this queue length by setting vo->max_video_queue to 2). It should probably be investigated why vo_vdpau.c kept so many past frames. The field vo->redrawing is removed. I'm not really sure what that would be needed for; it seems pointless. Future directions include making the interface between playloop and VO simpler, as well as making rendering a frame a single operation, as opposed to the weird 3-step sequence of rendering, drawing OSD, and flipping.
2014-04-29 15:19:03 +02:00
static void draw_image(struct vo *vo, struct mp_image *mpi)
{
struct vdpctx *vc = vo->priv;
mp_image_setrefp(&vc->current_image, mpi);
if (status_ok(vo))
video_to_output_surface(vo);
}
static struct mp_image *filter_image(struct vo *vo, struct mp_image *mpi)
Add support for VDPAU video out, including hardware decoding. git-svn-id: svn://svn.mplayerhq.hu/mplayer/trunk@28617 b3059339-0415-0410-9bf9-f77b7e298cf2
2009-02-16 21:58:13 +01:00
{
vo_vdpau: Replace global function table with context variable
2009-05-06 20:04:37 +02:00
struct vdpctx *vc = vo->priv;
struct vdp_functions *vdp = vc->vdp;
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 *reserved_mpi = NULL;
vo_vdpau: add RGB support Apparently this was dropped some years ago, but judging from MPlayer's handling of this, the original code wasn't so great anyway. The new code handling clearing of panscan borders correctly, and integrates better with the YUV path. (Although the VDPAU API sure makes this annoying with its separate surface types for RGB.) Note that we create 5 surfaces for some reason - I don't think this makes too much sense (because we can't use the deinterlacer with RGB surfaces), but at least it reduces the amount of differences with the YUV code path. Clearing the borders is done by drawing a single black pixel over the window. This sounds pretty dumb, but it appears to work well, and there is no other API for that. (One could try to use the video mixer for this purpose, since it has all kinds of features, including compositing multiple RGBA surfaces and clearing the window background. But it would require an invisible dummy video surface to make the video mixer happy, and that's getting too messy.)
2013-08-18 05:12:21 +02:00
VdpStatus vdp_st;
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
vdpau: deduplicate video surface upload code This was a minor code duplication between vf_vdpaupp.c and vo_vdpau.c. (In theory, we could always require using vf_vdpaupp with vo_vdpau, but I think it's better if vo_vdpau can work standalone.)
2014-05-04 10:50:32 +02:00
handle_preemption(vo);
if (vc->rgb_mode) {
vo_vdpau: always use mp_image for internal buffer queue
2014-04-29 15:18:35 +02:00
reserved_mpi = get_rgb_surface(vo);
if (!reserved_mpi)
video: move video frame queue from vo_vdpau.c to vo.c Remove the special casing of vo_vdpau vs. other VOs. Replace the complicated interaction between vo.c and vo_vdpau.c with a simple queue in vo.c. VOs other than vdpau are handled by setting the length of the queue to 1 (this is essentially what waiting_mpi was). Note that vo_vdpau.c seems to have buffered only 1 or 2 frames into the future, while the remaining 3 or 4 frames were past frames. So the new code buffers 2 frames (vo_vdpau.c requests this queue length by setting vo->max_video_queue to 2). It should probably be investigated why vo_vdpau.c kept so many past frames. The field vo->redrawing is removed. I'm not really sure what that would be needed for; it seems pointless. Future directions include making the interface between playloop and VO simpler, as well as making rendering a frame a single operation, as opposed to the weird 3-step sequence of rendering, drawing OSD, and flipping.
2014-04-29 15:19:03 +02:00
goto end;
vo_vdpau: always use mp_image for internal buffer queue
2014-04-29 15:18:35 +02:00
VdpOutputSurface rgb_surface = (uintptr_t)reserved_mpi->planes[0];
vo_vdpau: add RGB support Apparently this was dropped some years ago, but judging from MPlayer's handling of this, the original code wasn't so great anyway. The new code handling clearing of panscan borders correctly, and integrates better with the YUV path. (Although the VDPAU API sure makes this annoying with its separate surface types for RGB.) Note that we create 5 surfaces for some reason - I don't think this makes too much sense (because we can't use the deinterlacer with RGB surfaces), but at least it reduces the amount of differences with the YUV code path. Clearing the borders is done by drawing a single black pixel over the window. This sounds pretty dumb, but it appears to work well, and there is no other API for that. (One could try to use the video mixer for this purpose, since it has all kinds of features, including compositing multiple RGBA surfaces and clearing the window background. But it would require an invisible dummy video surface to make the video mixer happy, and that's getting too messy.)
2013-08-18 05:12:21 +02:00
if (rgb_surface != VDP_INVALID_HANDLE) {
vdp_st = vdp->output_surface_put_bits_native(rgb_surface,
&(const void *){mpi->planes[0]},
&(uint32_t){mpi->stride[0]},
NULL);
vdpau: mp_msg conversions
2013-12-21 18:05:23 +01:00
CHECK_VDP_WARNING(vo, "Error when calling "
"output_surface_put_bits_native");
vo_vdpau: add RGB support Apparently this was dropped some years ago, but judging from MPlayer's handling of this, the original code wasn't so great anyway. The new code handling clearing of panscan borders correctly, and integrates better with the YUV path. (Although the VDPAU API sure makes this annoying with its separate surface types for RGB.) Note that we create 5 surfaces for some reason - I don't think this makes too much sense (because we can't use the deinterlacer with RGB surfaces), but at least it reduces the amount of differences with the YUV code path. Clearing the borders is done by drawing a single black pixel over the window. This sounds pretty dumb, but it appears to work well, and there is no other API for that. (One could try to use the video mixer for this purpose, since it has all kinds of features, including compositing multiple RGBA surfaces and clearing the window background. But it would require an invisible dummy video surface to make the video mixer happy, and that's getting too messy.)
2013-08-18 05:12:21 +02:00
}
video: remove slice based filtering and video output Slices allowed filtering or drawing video in horizontal bands or blocks. This allowed working on the video in smaller units. In theory, this could bring a performance win by lowering cache pressure, as you didn't have to keep the whole video frame in cache while filtering, only the slice. In practice, the slice code path was barely used for the following reasons: - Multithreaded decoding with ffmpeg didn't use slices. The ffmpeg slice callback was disabled, because it can be called from another thread, and the mplayer video chain is not thread-safe. - There was nothing that would turn "full" images into appropriate slices, so slices were rarely used. - Most filters didn't actually support slices. On the other hand, supporting slices lead to code duplication and more complex code in general. I made some experiments and didn't find any actual measurable performance improvements when using slices. Even ffmpeg removed slices based filtering from libavfilter in favor of simpler code. The most broken thing about the slices code path is that slices can't be queued, like it is done for images in vo.c.
2012-11-04 18:16:36 +01:00
} else {
vdpau: deduplicate video surface upload code This was a minor code duplication between vf_vdpaupp.c and vo_vdpau.c. (In theory, we could always require using vf_vdpaupp with vo_vdpau, but I think it's better if vo_vdpau can work standalone.)
2014-05-04 10:50:32 +02:00
reserved_mpi = mp_vdpau_upload_video_surface(vc->mpvdp, mpi);
video: remove slice based filtering and video output Slices allowed filtering or drawing video in horizontal bands or blocks. This allowed working on the video in smaller units. In theory, this could bring a performance win by lowering cache pressure, as you didn't have to keep the whole video frame in cache while filtering, only the slice. In practice, the slice code path was barely used for the following reasons: - Multithreaded decoding with ffmpeg didn't use slices. The ffmpeg slice callback was disabled, because it can be called from another thread, and the mplayer video chain is not thread-safe. - There was nothing that would turn "full" images into appropriate slices, so slices were rarely used. - Most filters didn't actually support slices. On the other hand, supporting slices lead to code duplication and more complex code in general. I made some experiments and didn't find any actual measurable performance improvements when using slices. Even ffmpeg removed slices based filtering from libavfilter in favor of simpler code. The most broken thing about the slices code path is that slices can't be queued, like it is done for images in vo.c.
2012-11-04 18:16:36 +01:00
}
Add support for VDPAU video out, including hardware decoding. git-svn-id: svn://svn.mplayerhq.hu/mplayer/trunk@28617 b3059339-0415-0410-9bf9-f77b7e298cf2
2009-02-16 21:58:13 +01:00
vdpau: deduplicate video surface upload code This was a minor code duplication between vf_vdpaupp.c and vo_vdpau.c. (In theory, we could always require using vf_vdpaupp with vo_vdpau, but I think it's better if vo_vdpau can work standalone.)
2014-05-04 10:50:32 +02:00
if (!reserved_mpi)
goto end;
vo_vdpau: keep colorspace flags Since vdpau_mixer.c initializes the YUV conversion using the mp_image flags, these images should have all flags set properly.
2014-04-29 15:19:30 +02:00
mp_image_copy_attributes(reserved_mpi, 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
video: move video frame queue from vo_vdpau.c to vo.c Remove the special casing of vo_vdpau vs. other VOs. Replace the complicated interaction between vo.c and vo_vdpau.c with a simple queue in vo.c. VOs other than vdpau are handled by setting the length of the queue to 1 (this is essentially what waiting_mpi was). Note that vo_vdpau.c seems to have buffered only 1 or 2 frames into the future, while the remaining 3 or 4 frames were past frames. So the new code buffers 2 frames (vo_vdpau.c requests this queue length by setting vo->max_video_queue to 2). It should probably be investigated why vo_vdpau.c kept so many past frames. The field vo->redrawing is removed. I'm not really sure what that would be needed for; it seems pointless. Future directions include making the interface between playloop and VO simpler, as well as making rendering a frame a single operation, as opposed to the weird 3-step sequence of rendering, drawing OSD, and flipping.
2014-04-29 15:19:03 +02:00
end:
talloc_free(mpi);
return reserved_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
}
vo_vdpau: implement screenshots
2011-10-06 20:46:01 +02:00
// warning: the size and pixel format of surface must match that of the
// surfaces in vc->output_surfaces
vdpau: mp_msg conversions
2013-12-21 18:05:23 +01:00
static struct mp_image *read_output_surface(struct vo *vo,
vo_vdpau: fix screenshots Attempting to take screenshots printed vdpau errors on the terminal, and the resulting screenshots were filled with black. The problem was that that the screenshot code tried to use an unallocated output surface (the one at vc->output_surfaces[vc->num_output_surfaces]). This used to refer to the last allocated surface, until this was changed by a recently merged commit. That commit also added a separate screenshot surface. The merge somehow went wrong, and that part was not integrated. <uau> wm4: you used an earlier buggy version of a commit OK...
2012-10-21 00:48:01 +02:00
VdpOutputSurface surface,
int width, int height)
vo_vdpau: implement screenshots
2011-10-06 20:46:01 +02:00
{
vdpau: mp_msg conversions
2013-12-21 18:05:23 +01:00
struct vdpctx *vc = vo->priv;
vo_vdpau: implement screenshots
2011-10-06 20:46:01 +02:00
VdpStatus vdp_st;
struct vdp_functions *vdp = vc->vdp;
video/out: remove legacy colorspace stuff Reduce most dependencies on struct mp_csp_details, which was a bad first attempt at dealing with colorspace stuff. Instead, consistently use mp_image_params. Code which retrieves colorspace matrices from csputils.c still uses this type, though.
2014-03-29 00:25:08 +01:00
if (!vo->params)
return NULL;
video: cleanup: replace old mp_image function names mp_image_alloc() also changes argument order compared to alloc_mpi(). The format now comes first, then width/height.
2012-12-22 21:46:22 +01:00
struct mp_image *image = mp_image_alloc(IMGFMT_BGR32, width, height);
video: make mp_image use mp_image_params directly Minor cleanup, so that we can stuff more information into mp_image_params later.
2014-04-20 21:27:45 +02:00
image->params.colorspace = MP_CSP_RGB;
// hardcoded with conv. matrix
image->params.colorlevels = vo->params->outputlevels;
vo_vdpau: implement screenshots
2011-10-06 20:46:01 +02:00
void *dst_planes[] = { image->planes[0] };
uint32_t dst_pitches[] = { image->stride[0] };
vdp_st = vdp->output_surface_get_bits_native(surface, NULL, dst_planes,
dst_pitches);
vdpau: mp_msg conversions
2013-12-21 18:05:23 +01:00
CHECK_VDP_WARNING(vo, "Error when calling vdp_output_surface_get_bits_native");
vo_vdpau: implement screenshots
2011-10-06 20:46:01 +02:00
return image;
}
static struct mp_image *get_screenshot(struct vo *vo)
{
struct vdpctx *vc = vo->priv;
vo_vdpau: fix screenshots Attempting to take screenshots printed vdpau errors on the terminal, and the resulting screenshots were filled with black. The problem was that that the screenshot code tried to use an unallocated output surface (the one at vc->output_surfaces[vc->num_output_surfaces]). This used to refer to the last allocated surface, until this was changed by a recently merged commit. That commit also added a separate screenshot surface. The merge somehow went wrong, and that part was not integrated. <uau> wm4: you used an earlier buggy version of a commit OK...
2012-10-21 00:48:01 +02:00
VdpStatus vdp_st;
struct vdp_functions *vdp = vc->vdp;
vo_vdpau: implement screenshots
2011-10-06 20:46:01 +02:00
video/out: don't access aspdat in VOs vo->aspdat is basically an outdated version of vo->params, plus some weirdness. Get rid of it, which will allow further cleanups and which will make multithreading easier (less state to care about). Also, simplify some VO code by using mp_image_set_attributes() instead of caring about display size, colorspace, etc. manually. Add the function osd_res_from_image_params(), which is often needed in the case OSD renders into an image.
2014-01-21 23:43:54 +01:00
if (!vo->params)
return NULL;
vo_vdpau: fix screenshots Attempting to take screenshots printed vdpau errors on the terminal, and the resulting screenshots were filled with black. The problem was that that the screenshot code tried to use an unallocated output surface (the one at vc->output_surfaces[vc->num_output_surfaces]). This used to refer to the last allocated surface, until this was changed by a recently merged commit. That commit also added a separate screenshot surface. The merge somehow went wrong, and that part was not integrated. <uau> wm4: you used an earlier buggy version of a commit OK...
2012-10-21 00:48:01 +02:00
if (vc->screenshot_surface == VDP_INVALID_HANDLE) {
vdp_st = vdp->output_surface_create(vc->vdp_device,
OUTPUT_RGBA_FORMAT,
vc->vid_width, vc->vid_height,
&vc->screenshot_surface);
vdpau: mp_msg conversions
2013-12-21 18:05:23 +01:00
CHECK_VDP_WARNING(vo, "Error when calling vdp_output_surface_create");
vo_vdpau: fix screenshots Attempting to take screenshots printed vdpau errors on the terminal, and the resulting screenshots were filled with black. The problem was that that the screenshot code tried to use an unallocated output surface (the one at vc->output_surfaces[vc->num_output_surfaces]). This used to refer to the last allocated surface, until this was changed by a recently merged commit. That commit also added a separate screenshot surface. The merge somehow went wrong, and that part was not integrated. <uau> wm4: you used an earlier buggy version of a commit OK...
2012-10-21 00:48:01 +02:00
}
vo_vdpau: implement screenshots
2011-10-06 20:46:01 +02:00
vo_vdpau: let vdpau scale anamorphic screenshots In theory, returning the screenshot with original pixel aspect would allow avoiding scaling them with image formats that support non-square pixels, but in practice this isn't used anyway (nothing seems to understand e.g. jpeg aspect ratio tags).
2014-04-29 13:27:07 +02:00
VdpRect in = { .x1 = vo->params->w, .y1 = vo->params->h };
VdpRect out = { .x1 = vo->params->d_w, .y1 = vo->params->d_h };
render_video_to_output_surface(vo, vc->screenshot_surface, &out, &in);
vo_vdpau: implement screenshots
2011-10-06 20:46:01 +02:00
vo_vdpau: let vdpau scale anamorphic screenshots In theory, returning the screenshot with original pixel aspect would allow avoiding scaling them with image formats that support non-square pixels, but in practice this isn't used anyway (nothing seems to understand e.g. jpeg aspect ratio tags).
2014-04-29 13:27:07 +02:00
return read_output_surface(vo, vc->screenshot_surface, out.x1, out.y1);
vo_vdpau: implement screenshots
2011-10-06 20:46:01 +02:00
}
static struct mp_image *get_window_screenshot(struct vo *vo)
{
struct vdpctx *vc = vo->priv;
int last_surface = WRAP_ADD(vc->surface_num, -1, vc->num_output_surfaces);
VdpOutputSurface screen = vc->output_surfaces[last_surface];
vdpau: mp_msg conversions
2013-12-21 18:05:23 +01:00
struct mp_image *image = read_output_surface(vo, screen,
vo_vdpau: fix screenshots Attempting to take screenshots printed vdpau errors on the terminal, and the resulting screenshots were filled with black. The problem was that that the screenshot code tried to use an unallocated output surface (the one at vc->output_surfaces[vc->num_output_surfaces]). This used to refer to the last allocated surface, until this was changed by a recently merged commit. That commit also added a separate screenshot surface. The merge somehow went wrong, and that part was not integrated. <uau> wm4: you used an earlier buggy version of a commit OK...
2012-10-21 00:48:01 +02:00
vc->output_surface_width,
vc->output_surface_height);
mp_image: require using mp_image_set_size() for setting w/h Setting the size of a mp_image must be done with mp_image_set_size() now. Do this to guarantee that the redundant fields (like chroma_width) are updated consistently. Replacing the redundant fields by function calls would probably be better, but there are too many uses of them, and is a bit less convenient. Most code actually called mp_image_setfmt(), which did this as well. This commit just makes things a bit more explicit. Warning: the video filter chain still sets up mp_images manually, and vf_get_image() is not updated.
2012-11-10 02:02:24 +01:00
mp_image_set_size(image, vo->dwidth, vo->dheight);
vo_vdpau: implement screenshots
2011-10-06 20:46:01 +02:00
return image;
}
video/out: replace VOCTRL_QUERY_FORMAT with vo_driver.query_format
2012-11-04 16:24:18 +01:00
static int query_format(struct vo *vo, uint32_t format)
Add support for VDPAU video out, including hardware decoding. git-svn-id: svn://svn.mplayerhq.hu/mplayer/trunk@28617 b3059339-0415-0410-9bf9-f77b7e298cf2
2009-02-16 21:58:13 +01:00
{
vo_vdpau: add RGB support Apparently this was dropped some years ago, but judging from MPlayer's handling of this, the original code wasn't so great anyway. The new code handling clearing of panscan borders correctly, and integrates better with the YUV path. (Although the VDPAU API sure makes this annoying with its separate surface types for RGB.) Note that we create 5 surfaces for some reason - I don't think this makes too much sense (because we can't use the deinterlacer with RGB surfaces), but at least it reduces the amount of differences with the YUV code path. Clearing the borders is done by drawing a single black pixel over the window. This sounds pretty dumb, but it appears to work well, and there is no other API for that. (One could try to use the video mixer for this purpose, since it has all kinds of features, including compositing multiple RGBA surfaces and clearing the window background. But it would require an invisible dummy video surface to make the video mixer happy, and that's getting too messy.)
2013-08-18 05:12:21 +02:00
struct vdpctx *vc = vo->priv;
video: remove --flip The --flip option flipped the image upside-down, by trying to use VO support, or if not available, by inserting a video filter. I'm not sure why it existed. Maybe it was important in ancient times when VfW based decoders output an image this way (but even then, flipping an image is a free operation by negating the stride). One nice thing about this is that it provided a possible path for implementing video orientation, which is a feature we should probably support eventually. The important part is that it would be for free for VOs that support it, and would work even with hardware decoding. But for now get rid of it. It's useless, trivial, stands in the way, and supporting video orientation would require solving other problems first.
2013-12-05 22:55:35 +01:00
int flags = VFCAP_CSP_SUPPORTED | VFCAP_CSP_SUPPORTED_BY_HW;
vo_vdpau: add RGB support Apparently this was dropped some years ago, but judging from MPlayer's handling of this, the original code wasn't so great anyway. The new code handling clearing of panscan borders correctly, and integrates better with the YUV path. (Although the VDPAU API sure makes this annoying with its separate surface types for RGB.) Note that we create 5 surfaces for some reason - I don't think this makes too much sense (because we can't use the deinterlacer with RGB surfaces), but at least it reduces the amount of differences with the YUV code path. Clearing the borders is done by drawing a single black pixel over the window. This sounds pretty dumb, but it appears to work well, and there is no other API for that. (One could try to use the video mixer for this purpose, since it has all kinds of features, including compositing multiple RGBA surfaces and clearing the window background. But it would require an invisible dummy video surface to make the video mixer happy, and that's getting too messy.)
2013-08-18 05:12:21 +02:00
if (mp_vdpau_get_format(format, NULL, NULL))
return flags;
int rgb_format = get_rgb_format(format);
if (!vc->force_yuv && rgb_format >= 0)
return flags;
return 0;
Add support for VDPAU video out, including hardware decoding. git-svn-id: svn://svn.mplayerhq.hu/mplayer/trunk@28617 b3059339-0415-0410-9bf9-f77b7e298cf2
2009-02-16 21:58:13 +01:00
}
vo_vdpau: Replace global function table with context variable
2009-05-06 20:04:37 +02:00
static void destroy_vdpau_objects(struct vo *vo)
Add support for VDPAU video out, including hardware decoding. git-svn-id: svn://svn.mplayerhq.hu/mplayer/trunk@28617 b3059339-0415-0410-9bf9-f77b7e298cf2
2009-02-16 21:58:13 +01:00
{
vo_vdpau: Replace global function table with context variable
2009-05-06 20:04:37 +02:00
struct vdpctx *vc = vo->priv;
struct vdp_functions *vdp = vc->vdp;
Add support for VDPAU video out, including hardware decoding. git-svn-id: svn://svn.mplayerhq.hu/mplayer/trunk@28617 b3059339-0415-0410-9bf9-f77b7e298cf2
2009-02-16 21:58:13 +01:00
VdpStatus vdp_st;
vo_vdpau: Replace global function table with context variable
2009-05-06 20:04:37 +02:00
free_video_specific(vo);
Add support for VDPAU video out, including hardware decoding. git-svn-id: svn://svn.mplayerhq.hu/mplayer/trunk@28617 b3059339-0415-0410-9bf9-f77b7e298cf2
2009-02-16 21:58:13 +01:00
vo_vdpau: Make CHECK_ST macro safer Also contains a couple of changes in destroy_vdpau_objects.
2009-05-08 19:57:22 +02:00
if (vc->flip_queue != VDP_INVALID_HANDLE) {
vdp_st = vdp->presentation_queue_destroy(vc->flip_queue);
vdpau: mp_msg conversions
2013-12-21 18:05:23 +01:00
CHECK_VDP_WARNING(vo, "Error when calling vdp_presentation_queue_destroy");
vo_vdpau: Make CHECK_ST macro safer Also contains a couple of changes in destroy_vdpau_objects.
2009-05-08 19:57:22 +02:00
}
Add support for VDPAU video out, including hardware decoding. git-svn-id: svn://svn.mplayerhq.hu/mplayer/trunk@28617 b3059339-0415-0410-9bf9-f77b7e298cf2
2009-02-16 21:58:13 +01:00
vo_vdpau: Make CHECK_ST macro safer Also contains a couple of changes in destroy_vdpau_objects.
2009-05-08 19:57:22 +02:00
if (vc->flip_target != VDP_INVALID_HANDLE) {
vdp_st = vdp->presentation_queue_target_destroy(vc->flip_target);
vdpau: mp_msg conversions
2013-12-21 18:05:23 +01:00
CHECK_VDP_WARNING(vo, "Error when calling "
vo_vdpau.c: cosmetics
2009-05-09 17:08:30 +02:00
"vdp_presentation_queue_target_destroy");
vo_vdpau: Make CHECK_ST macro safer Also contains a couple of changes in destroy_vdpau_objects.
2009-05-08 19:57:22 +02:00
}
Add support for VDPAU video out, including hardware decoding. git-svn-id: svn://svn.mplayerhq.hu/mplayer/trunk@28617 b3059339-0415-0410-9bf9-f77b7e298cf2
2009-02-16 21:58:13 +01:00
Fix some -Wshadow warnings In general, this warning can hint to actual bugs. We don't enable it yet, because it would conflict with some unmerged code, and we should check with clang too (this commit was done by testing with gcc).
2013-07-23 00:45:23 +02:00
for (int i = 0; i < vc->num_output_surfaces; i++) {
vo_vdpau: Make CHECK_ST macro safer Also contains a couple of changes in destroy_vdpau_objects.
2009-05-08 19:57:22 +02:00
if (vc->output_surfaces[i] == VDP_INVALID_HANDLE)
continue;
vo_vdpau: Move things to context struct
2009-05-06 22:42:24 +02:00
vdp_st = vdp->output_surface_destroy(vc->output_surfaces[i]);
vdpau: mp_msg conversions
2013-12-21 18:05:23 +01:00
CHECK_VDP_WARNING(vo, "Error when calling vdp_output_surface_destroy");
Add support for VDPAU video out, including hardware decoding. git-svn-id: svn://svn.mplayerhq.hu/mplayer/trunk@28617 b3059339-0415-0410-9bf9-f77b7e298cf2
2009-02-16 21:58:13 +01:00
}
vo_vdpau: allow multiple EOSD renderers Preparation for using new OSD rendering method.
2012-09-28 21:49:09 +02:00
for (int i = 0; i < MAX_OSD_PARTS; i++) {
VO, sub: refactor Remove VFCTRL_DRAW_OSD, VFCAP_EOSD_FILTER, VFCAP_EOSD_RGBA, VFCAP_EOSD, VOCTRL_DRAW_EOSD, VOCTRL_GET_EOSD_RES, VOCTRL_QUERY_EOSD_FORMAT. Remove draw_osd_with_eosd(), which rendered the OSD by calling VOCTRL_DRAW_EOSD. Change VOs to call osd_draw() directly, which takes a callback as argument. (This basically works like the old OSD API, except multiple OSD bitmap formats are supported and caching is possible.) Remove all mentions of "eosd". It's simply "osd" now. Make OSD size per-OSD-object, as they can be different when using vf_sub. Include display_par/video_par in resolution change detection. Fix the issue with margin borders in vo_corevideo.
2012-10-19 19:25:18 +02:00
struct osd_bitmap_surface *sfc = &vc->osd_surfaces[i];
vo_vdpau: allow multiple EOSD renderers Preparation for using new OSD rendering method.
2012-09-28 21:49:09 +02:00
if (sfc->surface != VDP_INVALID_HANDLE) {
vdp_st = vdp->bitmap_surface_destroy(sfc->surface);
vdpau: mp_msg conversions
2013-12-21 18:05:23 +01:00
CHECK_VDP_WARNING(vo, "Error when calling vdp_bitmap_surface_destroy");
vo_vdpau: allow multiple EOSD renderers Preparation for using new OSD rendering method.
2012-09-28 21:49:09 +02:00
}
EOSD/ASS support for vo_vdpau.c Patch by Grigori G (greg <at> chown ath cx) with minor cosmetic changes by me. git-svn-id: svn://svn.mplayerhq.hu/mplayer/trunk@28710 b3059339-0415-0410-9bf9-f77b7e298cf2
2009-02-23 10:21:57 +01:00
}
vdpau: move device and video surface management from vo_vdpau.c to vdpau.c The goal is being able to use vdpau decoding independently from vo_vdpau.c.
2013-11-05 22:06:32 +01:00
mp_vdpau_destroy(vc->mpvdp);
vc->mpvdp = NULL;
Add support for VDPAU video out, including hardware decoding. git-svn-id: svn://svn.mplayerhq.hu/mplayer/trunk@28617 b3059339-0415-0410-9bf9-f77b7e298cf2
2009-02-16 21:58:13 +01:00
}
vo_vdpau: Make compile as new-style VO
2009-05-04 02:09:50 +02:00
static void uninit(struct vo *vo)
Add support for VDPAU video out, including hardware decoding. git-svn-id: svn://svn.mplayerhq.hu/mplayer/trunk@28617 b3059339-0415-0410-9bf9-f77b7e298cf2
2009-02-16 21:58:13 +01:00
{
vo_vdpau: support vf_vdpaupp This is slightly incomplete: the mixer options, such as sharpen and especially deinterlacing, are ignored. This also breaks automatic enabling of interlacing with 'D' or --deinterlace. These issues will be fixed later in the following commits. Note that we keep all the custom vdpau queue stuff. This will also be simplified later.
2014-04-29 15:11:44 +02:00
struct vdpctx *vc = vo->priv;
Add support for VDPAU video out, including hardware decoding. git-svn-id: svn://svn.mplayerhq.hu/mplayer/trunk@28617 b3059339-0415-0410-9bf9-f77b7e298cf2
2009-02-16 21:58:13 +01:00
/* Destroy all vdpau objects */
vo_vdpau: support vf_vdpaupp This is slightly incomplete: the mixer options, such as sharpen and especially deinterlacing, are ignored. This also breaks automatic enabling of interlacing with 'D' or --deinterlace. These issues will be fixed later in the following commits. Note that we keep all the custom vdpau queue stuff. This will also be simplified later.
2014-04-29 15:11:44 +02:00
mp_vdpau_mixer_destroy(vc->video_mixer);
vo_vdpau: Replace global function table with context variable
2009-05-06 20:04:37 +02:00
destroy_vdpau_objects(vo);
EOSD/ASS support for vo_vdpau.c Patch by Grigori G (greg <at> chown ath cx) with minor cosmetic changes by me. git-svn-id: svn://svn.mplayerhq.hu/mplayer/trunk@28710 b3059339-0415-0410-9bf9-f77b7e298cf2
2009-02-23 10:21:57 +01:00
vo_vdpau: Make compile as new-style VO
2009-05-04 02:09:50 +02:00
vo_x11_uninit(vo);
Add support for VDPAU video out, including hardware decoding. git-svn-id: svn://svn.mplayerhq.hu/mplayer/trunk@28617 b3059339-0415-0410-9bf9-f77b7e298cf2
2009-02-16 21:58:13 +01:00
}
video/out: remove options argument from preinit() All VOs use proper option parsing now, and compatibility hacks are not needed.
2013-07-22 22:52:42 +02:00
static int preinit(struct vo *vo)
Add support for VDPAU video out, including hardware decoding. git-svn-id: svn://svn.mplayerhq.hu/mplayer/trunk@28617 b3059339-0415-0410-9bf9-f77b7e298cf2
2009-02-16 21:58:13 +01:00
{
VO: implement shared option handling, use for vdpau Add infrastructure that allows VOs to specify the suboptions they take, and get the values directly parsed into their private struct. The option functionality available with the new system is the same as for top-level player options. Convert vo_vdpau to use the new system instead of the old subopt_helper.
2012-06-25 22:12:03 +02:00
struct vdpctx *vc = vo->priv;
Add support for VDPAU video out, including hardware decoding. git-svn-id: svn://svn.mplayerhq.hu/mplayer/trunk@28617 b3059339-0415-0410-9bf9-f77b7e298cf2
2009-02-16 21:58:13 +01:00
vdpau: move device and video surface management from vo_vdpau.c to vdpau.c The goal is being able to use vdpau decoding independently from vo_vdpau.c.
2013-11-05 22:06:32 +01:00
if (!vo_x11_init(vo))
return -1;
vc->mpvdp = mp_vdpau_create_device_x11(vo->log, vo->x11);
if (!vc->mpvdp) {
vo_x11_uninit(vo);
return -1;
}
vdpau: split off decoder parts, use "new" libavcodec vdpau hwaccel API Move the decoder parts from vo_vdpau.c to a new file vdpau_old.c. This file is named so because because it's written against the "old" libavcodec vdpau pseudo-decoder (e.g. "h264_vdpau"). Add support for the "new" libavcodec vdpau support. This was recently added and replaces the "old" vdpau parts. (In fact, Libav is about to deprecate and remove the "old" API without deprecation grace period, so we have to support it now. Moreover, there will probably be no Libav release which supports both, so the transition is even less smooth than we could hope, and we have to support both the old and new API.) Whether the old or new API is used is checked by a configure test: if the new API is found, it is used, otherwise the old API is assumed. Some details might be handled differently. Especially display preemption is a bit problematic with the "new" libavcodec vdpau support: it wants to keep a pointer to a specific vdpau API function (which can be driver specific, because preemption might switch drivers). Also, surface IDs are now directly stored in AVFrames (and mp_images), so they can't be forced to VDP_INVALID_HANDLE on preemption. (This changes even with older libavcodec versions, because mp_image always uses the newer representation to make vo_vdpau.c simpler.) Decoder initialization in the new code tries to deal with codec profiles, while the old code always uses the highest profile per codec. Surface allocation changes. Since the decoder won't call config() in vo_vdpau.c on video size change anymore, we allow allocating surfaces of arbitrary size instead of locking it to what the VO was configured. The non-hwdec code also has slightly different allocation behavior now. Enabling the old vdpau special decoders via e.g. --vd=lavc:h264_vdpau doesn't work anymore (a warning suggesting the --hwdec option is printed instead).
2013-07-28 01:49:45 +02:00
vo_vdpau: support vf_vdpaupp This is slightly incomplete: the mixer options, such as sharpen and especially deinterlacing, are ignored. This also breaks automatic enabling of interlacing with 'D' or --deinterlace. These issues will be fixed later in the following commits. Note that we keep all the custom vdpau queue stuff. This will also be simplified later.
2014-04-29 15:11:44 +02:00
vc->video_mixer = mp_vdpau_mixer_create(vc->mpvdp, vo->log);
vo_vpdau: Clean up uninit logic
2009-05-08 20:48:01 +02:00
// Mark everything as invalid first so uninit() can tell what has been
// allocated
vo_vdpau: Support recovering from VDPAU display preemption Add code to reinitialize all VDPAU objects if a display preemption condition occurs. Reinitializing them in the middle of playback will cause video corruption at least until the next keyframe when using hardware decoding, but decoding does seem to recover after a keyframe.
2009-09-07 01:02:24 +02:00
mark_vdpau_objects_uninitialized(vo);
vo_vpdau: Clean up uninit logic
2009-05-08 20:48:01 +02:00
vdpau: move device and video surface management from vo_vdpau.c to vdpau.c The goal is being able to use vdpau decoding independently from vo_vdpau.c.
2013-11-05 22:06:32 +01:00
vc->preemption_counter = vc->mpvdp->preemption_counter;
vc->vdp_device = vc->mpvdp->vdp_device;
vdpau: remove pointer indirection for a field There's no reason to. This is basically a cosmetic change.
2014-03-19 19:57:08 +01:00
vc->vdp = &vc->mpvdp->vdp;
vdpau: move device and video surface management from vo_vdpau.c to vdpau.c The goal is being able to use vdpau decoding independently from vo_vdpau.c.
2013-11-05 22:06:32 +01:00
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
vc->video_eq.capabilities = MP_CSP_EQ_CAPS_COLORMATRIX;
VO: implement shared option handling, use for vdpau Add infrastructure that allows VOs to specify the suboptions they take, and get the values directly parsed into their private struct. The option functionality available with the new system is the same as for top-level player options. Convert vo_vdpau to use the new system instead of the old subopt_helper.
2012-06-25 22:12:03 +02:00
video: move video frame queue from vo_vdpau.c to vo.c Remove the special casing of vo_vdpau vs. other VOs. Replace the complicated interaction between vo.c and vo_vdpau.c with a simple queue in vo.c. VOs other than vdpau are handled by setting the length of the queue to 1 (this is essentially what waiting_mpi was). Note that vo_vdpau.c seems to have buffered only 1 or 2 frames into the future, while the remaining 3 or 4 frames were past frames. So the new code buffers 2 frames (vo_vdpau.c requests this queue length by setting vo->max_video_queue to 2). It should probably be investigated why vo_vdpau.c kept so many past frames. The field vo->redrawing is removed. I'm not really sure what that would be needed for; it seems pointless. Future directions include making the interface between playloop and VO simpler, as well as making rendering a frame a single operation, as opposed to the weird 3-step sequence of rendering, drawing OSD, and flipping.
2014-04-29 15:19:03 +02:00
vo->max_video_queue = 2;
Add support for VDPAU video out, including hardware decoding. git-svn-id: svn://svn.mplayerhq.hu/mplayer/trunk@28617 b3059339-0415-0410-9bf9-f77b7e298cf2
2009-02-16 21:58:13 +01:00
return 0;
}
vo_vdpau: Replace global function table with context variable
2009-05-06 20:04:37 +02:00
static int get_equalizer(struct vo *vo, const char *name, int *value)
{
struct vdpctx *vc = vo->priv;
vo_vdpau: add RGB support Apparently this was dropped some years ago, but judging from MPlayer's handling of this, the original code wasn't so great anyway. The new code handling clearing of panscan borders correctly, and integrates better with the YUV path. (Although the VDPAU API sure makes this annoying with its separate surface types for RGB.) Note that we create 5 surfaces for some reason - I don't think this makes too much sense (because we can't use the deinterlacer with RGB surfaces), but at least it reduces the amount of differences with the YUV code path. Clearing the borders is done by drawing a single black pixel over the window. This sounds pretty dumb, but it appears to work well, and there is no other API for that. (One could try to use the video mixer for this purpose, since it has all kinds of features, including compositing multiple RGBA surfaces and clearing the window background. But it would require an invisible dummy video surface to make the video mixer happy, and that's getting too messy.)
2013-08-18 05:12:21 +02:00
if (vc->rgb_mode)
return false;
vo_vdpau: support vf_vdpaupp This is slightly incomplete: the mixer options, such as sharpen and especially deinterlacing, are ignored. This also breaks automatic enabling of interlacing with 'D' or --deinterlace. These issues will be fixed later in the following commits. Note that we keep all the custom vdpau queue stuff. This will also be simplified later.
2014-04-29 15:11:44 +02:00
return mp_csp_equalizer_get(&vc->video_mixer->video_eq, name, value) >= 0 ?
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
VO_TRUE : VO_NOTIMPL;
Support brightness, contrast, hue and saturation adjustments via custom color space conversion matrices in VDPAU. Patch by Grigori Goronzy, greg A chown D ath D cx git-svn-id: svn://svn.mplayerhq.hu/mplayer/trunk@28760 b3059339-0415-0410-9bf9-f77b7e298cf2
2009-02-28 14:20:01 +01:00
}
vo_vdpau: Replace global function table with context variable
2009-05-06 20:04:37 +02:00
static int set_equalizer(struct vo *vo, const char *name, int value)
{
struct vdpctx *vc = vo->priv;
Support brightness, contrast, hue and saturation adjustments via custom color space conversion matrices in VDPAU. Patch by Grigori Goronzy, greg A chown D ath D cx git-svn-id: svn://svn.mplayerhq.hu/mplayer/trunk@28760 b3059339-0415-0410-9bf9-f77b7e298cf2
2009-02-28 14:20:01 +01:00
vo_vdpau: add RGB support Apparently this was dropped some years ago, but judging from MPlayer's handling of this, the original code wasn't so great anyway. The new code handling clearing of panscan borders correctly, and integrates better with the YUV path. (Although the VDPAU API sure makes this annoying with its separate surface types for RGB.) Note that we create 5 surfaces for some reason - I don't think this makes too much sense (because we can't use the deinterlacer with RGB surfaces), but at least it reduces the amount of differences with the YUV code path. Clearing the borders is done by drawing a single black pixel over the window. This sounds pretty dumb, but it appears to work well, and there is no other API for that. (One could try to use the video mixer for this purpose, since it has all kinds of features, including compositing multiple RGBA surfaces and clearing the window background. But it would require an invisible dummy video surface to make the video mixer happy, and that's getting too messy.)
2013-08-18 05:12:21 +02:00
if (vc->rgb_mode)
return false;
vo_vdpau: support vf_vdpaupp This is slightly incomplete: the mixer options, such as sharpen and especially deinterlacing, are ignored. This also breaks automatic enabling of interlacing with 'D' or --deinterlace. These issues will be fixed later in the following commits. Note that we keep all the custom vdpau queue stuff. This will also be simplified later.
2014-04-29 15:11:44 +02:00
if (mp_csp_equalizer_set(&vc->video_mixer->video_eq, name, value) < 0)
Support brightness, contrast, hue and saturation adjustments via custom color space conversion matrices in VDPAU. Patch by Grigori Goronzy, greg A chown D ath D cx git-svn-id: svn://svn.mplayerhq.hu/mplayer/trunk@28760 b3059339-0415-0410-9bf9-f77b7e298cf2
2009-02-28 14:20:01 +01:00
return VO_NOTIMPL;
vo_vdpau: support vf_vdpaupp This is slightly incomplete: the mixer options, such as sharpen and especially deinterlacing, are ignored. This also breaks automatic enabling of interlacing with 'D' or --deinterlace. These issues will be fixed later in the following commits. Note that we keep all the custom vdpau queue stuff. This will also be simplified later.
2014-04-29 15:11:44 +02:00
vc->video_mixer->initialized = false;
Add yuv_colorspace property, implemented in vo_vdpau and vo_xv Add a property to select YUV colorspace. Currently implemented only in vo_vdpau and vo_xv. Allows switching between BT.601, BT.709 and SMPTE-240M (vdpau only). The xv support uses the "XV_ITURBT_709" attribute. At least my NVIDIA card supports that; I don't know whether other xv implementations do. Bind the colorspace switch to the 'c' key by default. 'c' is currently used by vo_sdl for some fullscreen mode change thing, but at the moment that does not conflict and if it will in the future then vo_sdl can change. VDPAU part based on a patch from Lauri Mylläri <lauri.myllari@gmail.com>
2009-11-15 14:21:40 +01:00
return true;
Support brightness, contrast, hue and saturation adjustments via custom color space conversion matrices in VDPAU. Patch by Grigori Goronzy, greg A chown D ath D cx git-svn-id: svn://svn.mplayerhq.hu/mplayer/trunk@28760 b3059339-0415-0410-9bf9-f77b7e298cf2
2009-02-28 14:20:01 +01:00
}
vo_vpdau: fix preemption recovery broken in decec7f2a37e559d Commit decec7f2a3 ("vo_vdpau: skip resize code if not fully initialized") broke preemption recovery because the resize code stayed incorrectly disabled when it would have been used to reinitialize things during recovery. Revert that commit and add different checks to avoid running various code when not in a fully functional state.
2011-08-11 20:13:34 +02:00
static void checked_resize(struct vo *vo)
{
if (!status_ok(vo))
return;
resize(vo);
}
vo_vdpau: Make compile as new-style VO
2009-05-04 02:09:50 +02:00
static int control(struct vo *vo, uint32_t request, void *data)
Add support for VDPAU video out, including hardware decoding. git-svn-id: svn://svn.mplayerhq.hu/mplayer/trunk@28617 b3059339-0415-0410-9bf9-f77b7e298cf2
2009-02-16 21:58:13 +01:00
{
vo_vdpau: Replace global function table with context variable
2009-05-06 20:04:37 +02:00
struct vdpctx *vc = vo->priv;
vo_vdpau: Support recovering from VDPAU display preemption Add code to reinitialize all VDPAU objects if a display preemption condition occurs. Reinitializing them in the middle of playback will cause video corruption at least until the next keyframe when using hardware decoding, but decoding does seem to recover after a keyframe.
2009-09-07 01:02:24 +02:00
handle_preemption(vo);
Add support for VDPAU video out, including hardware decoding. git-svn-id: svn://svn.mplayerhq.hu/mplayer/trunk@28617 b3059339-0415-0410-9bf9-f77b7e298cf2
2009-02-16 21:58:13 +01:00
switch (request) {
vo_vdpau.c: Reindent control() switch statement
2009-09-05 05:20:03 +02:00
case VOCTRL_PAUSE:
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 (vc->dropped_frame)
vo_vdpau: use new want_redraw mechanism in one more case
2011-12-09 02:08:37 +01:00
vo->want_redraw = true;
core, vo: new window refresh logic, add slow-video OSD redraw Remove code refreshing window contents after events such as resize from vo_vdpau, vo_gl and vo_xv. Instead have them simply set a flag indicating that a refresh is needed, and have the player core perform that refresh by doing an OSD redraw. Also add support for updating the OSD contents over existing frames during slow-but-not-paused playback. The VOs now also request a refresh if parameters affecting the picture change (equalizer settings, colormatrix, VDPAU deinterlacing setting). Even previously the picture was typically redrawn with the new settings while paused because new OSD messages associated with setting changes triggered a redraw, but this did not happen if OSD was turned off. A minor imperfection is that now window system events can trigger a single one-frame step forward when using vo_xv after pausing so that vo_xv does not yet have a copy of the current image. This could be fixed but I think it's not important enough to bother.
2011-12-05 05:36:20 +01:00
return true;
vdpau: split off decoder parts, use "new" libavcodec vdpau hwaccel API Move the decoder parts from vo_vdpau.c to a new file vdpau_old.c. This file is named so because because it's written against the "old" libavcodec vdpau pseudo-decoder (e.g. "h264_vdpau"). Add support for the "new" libavcodec vdpau support. This was recently added and replaces the "old" vdpau parts. (In fact, Libav is about to deprecate and remove the "old" API without deprecation grace period, so we have to support it now. Moreover, there will probably be no Libav release which supports both, so the transition is even less smooth than we could hope, and we have to support both the old and new API.) Whether the old or new API is used is checked by a configure test: if the new API is found, it is used, otherwise the old API is assumed. Some details might be handled differently. Especially display preemption is a bit problematic with the "new" libavcodec vdpau support: it wants to keep a pointer to a specific vdpau API function (which can be driver specific, because preemption might switch drivers). Also, surface IDs are now directly stored in AVFrames (and mp_images), so they can't be forced to VDP_INVALID_HANDLE on preemption. (This changes even with older libavcodec versions, because mp_image always uses the newer representation to make vo_vdpau.c simpler.) Decoder initialization in the new code tries to deal with codec profiles, while the old code always uses the highest profile per codec. Surface allocation changes. Since the decoder won't call config() in vo_vdpau.c on video size change anymore, we allow allocating surfaces of arbitrary size instead of locking it to what the VO was configured. The non-hwdec code also has slightly different allocation behavior now. Enabling the old vdpau special decoders via e.g. --vd=lavc:h264_vdpau doesn't work anymore (a warning suggesting the --hwdec option is printed instead).
2013-07-28 01:49:45 +02:00
case VOCTRL_GET_HWDEC_INFO: {
struct mp_hwdec_info *arg = data;
vdpau: move device and video surface management from vo_vdpau.c to vdpau.c The goal is being able to use vdpau decoding independently from vo_vdpau.c.
2013-11-05 22:06:32 +01:00
arg->vdpau_ctx = vc->mpvdp;
video/filter: change filter API, use refcounting, remove filter DR Change the entire filter API to use reference counted images instead of vf_get_image(). Remove filter "direct rendering". This was useful for vf_expand and (in rare cases) vf_sub: DR allowed these filters to pass a cropped image to the filters before them. Then, on filtering, the image was "uncropped", so that black bars could be added around the image without copying. This means that in some cases, vf_expand will be slower (-vf gradfun,expand for example). Note that another form of DR used for in-place filters has been replaced by simpler logic. Instead of trying to do DR, filters can check if the image is writeable (with mp_image_is_writeable()), and do true in-place if that's the case. This affects filters like vf_gradfun and vf_sub. Everything has to support strides now. If something doesn't, making a copy of the image data is required.
2012-11-05 14:25:04 +01:00
return true;
vdpau: split off decoder parts, use "new" libavcodec vdpau hwaccel API Move the decoder parts from vo_vdpau.c to a new file vdpau_old.c. This file is named so because because it's written against the "old" libavcodec vdpau pseudo-decoder (e.g. "h264_vdpau"). Add support for the "new" libavcodec vdpau support. This was recently added and replaces the "old" vdpau parts. (In fact, Libav is about to deprecate and remove the "old" API without deprecation grace period, so we have to support it now. Moreover, there will probably be no Libav release which supports both, so the transition is even less smooth than we could hope, and we have to support both the old and new API.) Whether the old or new API is used is checked by a configure test: if the new API is found, it is used, otherwise the old API is assumed. Some details might be handled differently. Especially display preemption is a bit problematic with the "new" libavcodec vdpau support: it wants to keep a pointer to a specific vdpau API function (which can be driver specific, because preemption might switch drivers). Also, surface IDs are now directly stored in AVFrames (and mp_images), so they can't be forced to VDP_INVALID_HANDLE on preemption. (This changes even with older libavcodec versions, because mp_image always uses the newer representation to make vo_vdpau.c simpler.) Decoder initialization in the new code tries to deal with codec profiles, while the old code always uses the highest profile per codec. Surface allocation changes. Since the decoder won't call config() in vo_vdpau.c on video size change anymore, we allow allocating surfaces of arbitrary size instead of locking it to what the VO was configured. The non-hwdec code also has slightly different allocation behavior now. Enabling the old vdpau special decoders via e.g. --vd=lavc:h264_vdpau doesn't work anymore (a warning suggesting the --hwdec option is printed instead).
2013-07-28 01:49:45 +02:00
}
vo_vdpau.c: Reindent control() switch statement
2009-09-05 05:20:03 +02:00
case VOCTRL_GET_PANSCAN:
return VO_TRUE;
case VOCTRL_SET_PANSCAN:
vo_vpdau: fix preemption recovery broken in decec7f2a37e559d Commit decec7f2a3 ("vo_vdpau: skip resize code if not fully initialized") broke preemption recovery because the resize code stayed incorrectly disabled when it would have been used to reinitialize things during recovery. Revert that commit and add different checks to avoid running various code when not in a fully functional state.
2011-08-11 20:13:34 +02:00
checked_resize(vo);
vo_vdpau.c: Reindent control() switch statement
2009-09-05 05:20:03 +02:00
return VO_TRUE;
case VOCTRL_SET_EQUALIZER: {
core, vo: new window refresh logic, add slow-video OSD redraw Remove code refreshing window contents after events such as resize from vo_vdpau, vo_gl and vo_xv. Instead have them simply set a flag indicating that a refresh is needed, and have the player core perform that refresh by doing an OSD redraw. Also add support for updating the OSD contents over existing frames during slow-but-not-paused playback. The VOs now also request a refresh if parameters affecting the picture change (equalizer settings, colormatrix, VDPAU deinterlacing setting). Even previously the picture was typically redrawn with the new settings while paused because new OSD messages associated with setting changes triggered a redraw, but this did not happen if OSD was turned off. A minor imperfection is that now window system events can trigger a single one-frame step forward when using vo_xv after pausing so that vo_xv does not yet have a copy of the current image. This could be fixed but I think it's not important enough to bother.
2011-12-05 05:36:20 +01:00
vo->want_redraw = true;
vo_vdpau.c: Reindent control() switch statement
2009-09-05 05:20:03 +02:00
struct voctrl_set_equalizer_args *args = data;
return set_equalizer(vo, args->name, args->value);
}
case VOCTRL_GET_EQUALIZER: {
struct voctrl_get_equalizer_args *args = data;
return get_equalizer(vo, args->name, args->valueptr);
}
video/out: remove legacy colorspace stuff Reduce most dependencies on struct mp_csp_details, which was a bad first attempt at dealing with colorspace stuff. Instead, consistently use mp_image_params. Code which retrieves colorspace matrices from csputils.c still uses this type, though.
2014-03-29 00:25:08 +01:00
case VOCTRL_GET_COLORSPACE: {
struct mp_image_params *params = data;
if (vo->params && !vc->rgb_mode) {
params->colorspace = vo->params->colorspace;
params->colorlevels = vo->params->colorlevels;
params->outputlevels = vo->params->outputlevels;
}
Add yuv_colorspace property, implemented in vo_vdpau and vo_xv Add a property to select YUV colorspace. Currently implemented only in vo_vdpau and vo_xv. Allows switching between BT.601, BT.709 and SMPTE-240M (vdpau only). The xv support uses the "XV_ITURBT_709" attribute. At least my NVIDIA card supports that; I don't know whether other xv implementations do. Bind the colorspace switch to the 'c' key by default. 'c' is currently used by vo_sdl for some fullscreen mode change thing, but at the moment that does not conflict and if it will in the future then vo_sdl can change. VDPAU part based on a patch from Lauri Mylläri <lauri.myllari@gmail.com>
2009-11-15 14:21:40 +01:00
return true;
video/out: remove legacy colorspace stuff Reduce most dependencies on struct mp_csp_details, which was a bad first attempt at dealing with colorspace stuff. Instead, consistently use mp_image_params. Code which retrieves colorspace matrices from csputils.c still uses this type, though.
2014-03-29 00:25:08 +01:00
}
core, vo: modify OSD redraw architecture, support EOSD Previously the core sent VFCTRL_REDRAW_OSD to change OSD contents over the current frame. Change this to VFCTRL_REDRAW_FRAME followed by normal EOSD and OSD drawing calls, then vo_flip_page(). The new version supports changing EOSD contents for libass-rendered subtitles and simplifies the redraw support code needed per VO. vo_xv doesn't support EOSD changes because it relies on vf_ass to render EOSD contents earlier in the filter chain. vo_xv logic is additionally simplified because the previous commit removed the need to track the status of current and next images separately (now each frame is guaranteed to become "visible" soon after we receive it as "next", with no VO code running in the interval between).
2011-12-05 04:24:18 +01:00
case VOCTRL_REDRAW_FRAME:
vo_vdpau: fix preemption recovery after recent commits Recent commits for screenshot support and video redraw changes didn't handle vdpau driver preemption state correctly, which could make the player crash if preemption occurred. Fix this and improve preemption handling a bit otherwise.
2011-12-20 02:47:16 +01:00
if (status_ok(vo))
video_to_output_surface(vo);
vo_vdpau: Support updating OSD while paused
2009-09-05 05:33:33 +02:00
return true;
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
case VOCTRL_RESET:
vo_vdpau: don't blank screen on VOCTRL_RESET vo_vdpau is the only VO which implements VOCTRL_RESET. Redrawing the last output frame is hard, because the output could consist of several source video frames with certain types of post-processing (deinterlacing). Implement redrawing as special case by keeping the previous video frames aside until at least one new frame is decoded. This improves the previous commit, but is separate, because it's rather complicated.
2013-10-01 23:45:30 +02:00
forget_frames(vo, true);
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 true;
vo_vdpau: implement screenshots
2011-10-06 20:46:01 +02:00
case VOCTRL_SCREENSHOT: {
vo_vdpau: fix preemption recovery after recent commits Recent commits for screenshot support and video redraw changes didn't handle vdpau driver preemption state correctly, which could make the player crash if preemption occurred. Fix this and improve preemption handling a bit otherwise.
2011-12-20 02:47:16 +01:00
if (!status_ok(vo))
return false;
vo_vdpau: implement screenshots
2011-10-06 20:46:01 +02:00
struct voctrl_screenshot_args *args = data;
if (args->full_window)
args->out_image = get_window_screenshot(vo);
else
args->out_image = get_screenshot(vo);
return true;
}
command, vo_vdpau: respect vdpau deint sub-option This is a horrible hack to keep compatibility with the vo_vdpau deint sub-option.
2014-04-29 15:18:19 +02:00
case VOCTRL_GET_PREF_DEINT:
*(int *)data = vc->deint;
return true;
Add support for VDPAU video out, including hardware decoding. git-svn-id: svn://svn.mplayerhq.hu/mplayer/trunk@28617 b3059339-0415-0410-9bf9-f77b7e298cf2
2009-02-16 21:58:13 +01:00
}
x11: use vo_x11_control() for all VOs
2013-05-16 14:02:28 +02:00
int events = 0;
int r = vo_x11_control(vo, &events, request, data);
if (events & VO_EVENT_RESIZE) {
checked_resize(vo);
} else if (events & VO_EVENT_EXPOSE) {
vo->want_redraw = true;
}
return r;
Add support for VDPAU video out, including hardware decoding. git-svn-id: svn://svn.mplayerhq.hu/mplayer/trunk@28617 b3059339-0415-0410-9bf9-f77b7e298cf2
2009-02-16 21:58:13 +01:00
}
VO: implement shared option handling, use for vdpau Add infrastructure that allows VOs to specify the suboptions they take, and get the values directly parsed into their private struct. The option functionality available with the new system is the same as for top-level player options. Convert vo_vdpau to use the new system instead of the old subopt_helper.
2012-06-25 22:12:03 +02:00
#define OPT_BASE_STRUCT struct vdpctx
vo_vdpau: Make compile as new-style VO
2009-05-04 02:09:50 +02:00
const struct vo_driver video_out_vdpau = {
video/out: remove useless info struct and redundant fields The author and comment fields were printed only in -v mode.
2013-10-23 19:06:14 +02:00
.description = "VDPAU with X11",
.name = "vdpau",
vo_vdpau: Make compile as new-style VO
2009-05-04 02:09:50 +02:00
.preinit = preinit,
video/out: replace VOCTRL_QUERY_FORMAT with vo_driver.query_format
2012-11-04 16:24:18 +01:00
.query_format = query_format,
video/out: do remaining config to reconfig replacements The main difference between the old and new callbacks is that the old callbacks required passing the window size, which is and always was very inconvenient and confusing, since the window size is already in vo->dwidth and vo->dheight.
2014-01-24 21:22:25 +01:00
.reconfig = reconfig,
vo_vdpau: Make compile as new-style VO
2009-05-04 02:09:50 +02:00
.control = control,
video/filter: change filter API, use refcounting, remove filter DR Change the entire filter API to use reference counted images instead of vf_get_image(). Remove filter "direct rendering". This was useful for vf_expand and (in rare cases) vf_sub: DR allowed these filters to pass a cropped image to the filters before them. Then, on filtering, the image was "uncropped", so that black bars could be added around the image without copying. This means that in some cases, vf_expand will be slower (-vf gradfun,expand for example). Note that another form of DR used for in-place filters has been replaced by simpler logic. Instead of trying to do DR, filters can check if the image is writeable (with mp_image_is_writeable()), and do true in-place if that's the case. This affects filters like vf_gradfun and vf_sub. Everything has to support strides now. If something doesn't, making a copy of the image data is required.
2012-11-05 14:25:04 +01:00
.draw_image = draw_image,
video: move video frame queue from vo_vdpau.c to vo.c Remove the special casing of vo_vdpau vs. other VOs. Replace the complicated interaction between vo.c and vo_vdpau.c with a simple queue in vo.c. VOs other than vdpau are handled by setting the length of the queue to 1 (this is essentially what waiting_mpi was). Note that vo_vdpau.c seems to have buffered only 1 or 2 frames into the future, while the remaining 3 or 4 frames were past frames. So the new code buffers 2 frames (vo_vdpau.c requests this queue length by setting vo->max_video_queue to 2). It should probably be investigated why vo_vdpau.c kept so many past frames. The field vo->redrawing is removed. I'm not really sure what that would be needed for; it seems pointless. Future directions include making the interface between playloop and VO simpler, as well as making rendering a frame a single operation, as opposed to the weird 3-step sequence of rendering, drawing OSD, and flipping.
2014-04-29 15:19:03 +02:00
.filter_image = filter_image,
vo_vdpau: Make compile as new-style VO
2009-05-04 02:09:50 +02:00
.draw_osd = draw_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
.flip_page_timed = flip_page_timed,
vo_vdpau: Make compile as new-style VO
2009-05-04 02:09:50 +02:00
.uninit = uninit,
video_out: rename privsize member to priv_size
2012-08-06 17:51:53 +02:00
.priv_size = sizeof(struct vdpctx),
VO: implement shared option handling, use for vdpau Add infrastructure that allows VOs to specify the suboptions they take, and get the values directly parsed into their private struct. The option functionality available with the new system is the same as for top-level player options. Convert vo_vdpau to use the new system instead of the old subopt_helper.
2012-06-25 22:12:03 +02:00
.options = (const struct m_option []){
OPT_INTRANGE("deint", deint, 0, -4, 4),
cleanup: replace OPT_FLAG_ON and OPT_MAKE_FLAGS with OPT_FLAG OPT_MAKE_FLAGS() used to emit two options (one with "no" prefixed), but that has been long removed by special casing flag options in the option parser. OPT_FLAG_ON() used to imply that there's no "no-" prefixed option, but this hasn't been the case for a while either. (Conceptually, it has been replaced by OPT_FLAG_STORE().) Remove OPT_FLAG_OFF, which was unused.
2013-02-08 21:09:18 +01:00
OPT_FLAG("chroma-deint", chroma_deint, 0, OPTDEF_INT(1)),
OPT_FLAG("pullup", pullup, 0),
VO: implement shared option handling, use for vdpau Add infrastructure that allows VOs to specify the suboptions they take, and get the values directly parsed into their private struct. The option functionality available with the new system is the same as for top-level player options. Convert vo_vdpau to use the new system instead of the old subopt_helper.
2012-06-25 22:12:03 +02:00
OPT_FLOATRANGE("denoise", denoise, 0, 0, 1),
OPT_FLOATRANGE("sharpen", sharpen, 0, -1, 1),
OPT_INTRANGE("hqscaling", hqscaling, 0, 0, 9),
OPT_FLOAT("fps", user_fps, 0),
cleanup: replace OPT_FLAG_ON and OPT_MAKE_FLAGS with OPT_FLAG OPT_MAKE_FLAGS() used to emit two options (one with "no" prefixed), but that has been long removed by special casing flag options in the option parser. OPT_FLAG_ON() used to imply that there's no "no-" prefixed option, but this hasn't been the case for a while either. (Conceptually, it has been replaced by OPT_FLAG_STORE().) Remove OPT_FLAG_OFF, which was unused.
2013-02-08 21:09:18 +01:00
OPT_FLAG("composite-detect", composite_detect, 0, OPTDEF_INT(1)),
VO: implement shared option handling, use for vdpau Add infrastructure that allows VOs to specify the suboptions they take, and get the values directly parsed into their private struct. The option functionality available with the new system is the same as for top-level player options. Convert vo_vdpau to use the new system instead of the old subopt_helper.
2012-06-25 22:12:03 +02:00
OPT_INT("queuetime_windowed", flip_offset_window, 0, OPTDEF_INT(50)),
OPT_INT("queuetime_fs", flip_offset_fs, 0, OPTDEF_INT(50)),
OPT_INTRANGE("output_surfaces", num_output_surfaces, 0,
2, MAX_OUTPUT_SURFACES, OPTDEF_INT(3)),
vo_vdpau: use color close to black as default colorkey (instead of green) The VDPAU default colorkey, although it seems to be driver specific, is usually green. This is a pretty annoying color, and you usually see it briefly (as flashes) if the VDPAU window resizes. Change it to some shade of black. The new default color is close to what MPlayer picks as colorkey (and apparently it worked well for them): VdpColor vdp_bg = {0.01, 0.02, 0.03, 0}; Since our OPT_COLOR can set 8 bit colors only, we use '#020507' instead, which should be the same assuming 8 bit colors. Obviously, you can't use black, because black is a way too common color, and would make it too easy to observe the colorkey effect when e.g. moving a terminal with black background over the video window.
2013-08-17 20:05:28 +02:00
OPT_COLOR("colorkey", colorkey, 0,
.defval = &(const struct m_color) {
.r = 2, .g = 5, .b = 7, .a = 255,
}),
vo_vdpau: add RGB support Apparently this was dropped some years ago, but judging from MPlayer's handling of this, the original code wasn't so great anyway. The new code handling clearing of panscan borders correctly, and integrates better with the YUV path. (Although the VDPAU API sure makes this annoying with its separate surface types for RGB.) Note that we create 5 surfaces for some reason - I don't think this makes too much sense (because we can't use the deinterlacer with RGB surfaces), but at least it reduces the amount of differences with the YUV code path. Clearing the borders is done by drawing a single black pixel over the window. This sounds pretty dumb, but it appears to work well, and there is no other API for that. (One could try to use the video mixer for this purpose, since it has all kinds of features, including compositing multiple RGBA surfaces and clearing the window background. But it would require an invisible dummy video surface to make the video mixer happy, and that's getting too messy.)
2013-08-18 05:12:21 +02:00
OPT_FLAG("force-yuv", force_yuv, 0),
VO: implement shared option handling, use for vdpau Add infrastructure that allows VOs to specify the suboptions they take, and get the values directly parsed into their private struct. The option functionality available with the new system is the same as for top-level player options. Convert vo_vdpau to use the new system instead of the old subopt_helper.
2012-06-25 22:12:03 +02:00
{NULL},
}
vo_vdpau: Make compile as new-style VO
2009-05-04 02:09:50 +02:00
};
Copy Permalink