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
1b71cfccba
mpv/video/out/vo_vdpau.c

1198 lines
42 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
*
Update license headers Signed-off-by: wm4 <wm4@nowhere>
2015-04-13 09:36:54 +02:00
* This file is part of mpv.
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
*
Update license headers Signed-off-by: wm4 <wm4@nowhere>
2015-04-13 09:36:54 +02:00
* mpv is free software; you can redistribute it and/or modify
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
* 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.
*
Update license headers Signed-off-by: wm4 <wm4@nowhere>
2015-04-13 09:36:54 +02:00
* mpv is distributed in the hope that it will be useful,
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
* 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
Update license headers Signed-off-by: wm4 <wm4@nowhere>
2015-04-13 09:36:54 +02:00
* with mpv. If not, see <http://www.gnu.org/licenses/>.
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.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"
mpv_talloc.h: rename from talloc.h This change helps avoiding conflict with talloc.h from libtalloc.
2016-01-11 19:03:40 +01:00
#include "mpv_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/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
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: 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 black_pixel;
vo_vdpau: Implement rotation support VDPAU has explicit support for rotating surfaces, and it is far less expensive than using the normal rotation filter (which would require reading video frames back into system memory), it is desirable to implement the VO rotation capability. To do this, we need to render the video frames to an output surface, without rotation, and then render from that surface to the final output surface to apply the rotation. It is important that the intermediate surface is the same size as the final one (only not rotated) so that hqscaling can be applied if requested by the user. (hqscaling is a mixer capability and so takes effect when the video surface is rendered to an output surface) Finally, we must remember to explicitly clear the final output surface as VDPAU only auto-clears output surfaces when rendering video surfaces.
2015-07-11 05:42:22 +02:00
VdpOutputSurface rotation_surface;
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: change internal API for drawing frames draw_image_timed is renamed to draw_frame. struct frame_timing is renamed to vo_frame. flip_page_timed is merged into draw_frame (the additional parameters are part of struct vo_frame). draw_frame also deprecates VOCTRL_REDRAW_FRAME, and replaces it with a method that works for both VOs which can cache the current frame, and VOs which need to redraw it anyway. This is preparation to making the interpolation and (work in progress) display sync code saner. Lots of other refactoring, and also some simplifications.
2015-07-01 19:24:28 +02:00
int64_t current_pts;
int current_duration;
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: shorten 2 variable names Why should I be required to type so much?
2015-06-05 19:18:12 +02:00
int output_surface_w, output_surface_h;
vo_vdpau: Move things to context struct
2009-05-06 22:42:24 +02: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
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: include normal render-ahead time in flip_queue_offset A small refactor; shouldn't change any behavior. Do this so immediate display can be achieved.
2014-12-09 17:46:35 +01:00
int64_t flip_offset_us;
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: check VDP_RGBA_FORMAT_A8 support Apparently not all vdpau drivers in the wild support this format (VDPAU SUNXI can't). Revert to RGB in these cases.
2015-11-04 21:47:20 +01:00
VdpBool supports_a8;
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;
vo_vdpau: fix frame scheduling if display FPS is unknown Pretty stupid: vo_get_vsync_interval() returns a negative value if the display FPS is unknown (e.g. xrandr not compiled), and the comparison whether the value is below 0 fails later because it's assigned to an unsigned int. Regression since commit e3d85ad4. Also, fix some comments in vo.c.
2015-08-04 19:23:07 +02:00
int 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
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;
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;
osd: simplify an aspect of change detection handling There was a somewhat obscure optimization in the OSD and subtitle rendering path: if only the position of the sub-images changed, and not the actual image data, uploading of the image data could be skipped. In theory, this could speed up things like scrolling subtitles. But it turns out that even in the rare cases subtitles have such scrolls or axis-aligned movement, modern libass rarely signals this kind of change. Possibly this is because of sub-pixel handling and such, which break this. As such, it's a worthless optimization and just introduces additional complexity and subtle bugs (especially in cases libass does the opposite: incorrectly signaling a position change only, which happened before). Remove this optimization, and rename bitmap_pos_id to change_id.
2015-03-18 12:33:14 +01:00
int change_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);
video/out: change aspects of OSD handling Let the VOs draw the OSD on their own, instead of making OSD drawing a separate VO driver call. Further, let it be the VOs responsibility to request subtitles with the correct PTS. We also basically allow the VO to request OSD/subtitles at any time. OSX changes untested.
2014-06-15 20:46:57 +02:00
static void draw_osd(struct vo *vo);
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
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
vo_vdpau: don't render to an output surface if it could be busy There was a case when we could have rendered to an output surface while it's still used for display. Not sure why the API doesn't do this automatically.
2015-01-22 17:57:59 +01:00
vdp_st = vdp->presentation_queue_block_until_surface_idle(vc->flip_queue,
output_surface,
&dummy);
CHECK_VDP_WARNING(vo, "Error when calling "
"vdp_presentation_queue_block_until_surface_idle");
vo_vdpau: remove some minor code duplication The way-too-big API call for clearing the screen can be easily shared between two completely different codepaths.
2015-03-23 18:15:40 +01:00
// Clear the borders between video and window (if there are any).
// For some reason, video_mixer_render doesn't need it for YUV.
// Also, if there is nothing to render, at least clear the screen.
vo_vdpau: Implement rotation support VDPAU has explicit support for rotating surfaces, and it is far less expensive than using the normal rotation filter (which would require reading video frames back into system memory), it is desirable to implement the VO rotation capability. To do this, we need to render the video frames to an output surface, without rotation, and then render from that surface to the final output surface to apply the rotation. It is important that the intermediate surface is the same size as the final one (only not rotated) so that hqscaling can be applied if requested by the user. (hqscaling is a mixer capability and so takes effect when the video surface is rendered to an output surface) Finally, we must remember to explicitly clear the final output surface as VDPAU only auto-clears output surfaces when rendering video surfaces.
2015-07-11 05:42:22 +02:00
if (vc->rgb_mode || !mpi || mpi->params.rotate != 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
}
vo_vdpau: remove some minor code duplication The way-too-big API call for clearing the screen can be easily shared between two completely different codepaths.
2015-03-23 18:15:40 +01:00
if (!mpi)
return -1;
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;
vo_vdpau: Implement rotation support VDPAU has explicit support for rotating surfaces, and it is far less expensive than using the normal rotation filter (which would require reading video frames back into system memory), it is desirable to implement the VO rotation capability. To do this, we need to render the video frames to an output surface, without rotation, and then render from that surface to the final output surface to apply the rotation. It is important that the intermediate surface is the same size as the final one (only not rotated) so that hqscaling can be applied if requested by the user. (hqscaling is a mixer capability and so takes effect when the video surface is rendered to an output surface) Finally, we must remember to explicitly clear the final output surface as VDPAU only auto-clears output surfaces when rendering video surfaces.
2015-07-11 05:42:22 +02:00
if (mpi->params.rotate != 0) {
int flags;
VdpRect r_rect;
switch (mpi->params.rotate) {
case 90:
r_rect.y0 = output_rect->x0;
r_rect.y1 = output_rect->x1;
r_rect.x0 = output_rect->y0;
r_rect.x1 = output_rect->y1;
flags = VDP_OUTPUT_SURFACE_RENDER_ROTATE_90;
break;
case 180:
r_rect.x0 = output_rect->x0;
r_rect.x1 = output_rect->x1;
r_rect.y0 = output_rect->y0;
r_rect.y1 = output_rect->y1;
flags = VDP_OUTPUT_SURFACE_RENDER_ROTATE_180;
break;
case 270:
r_rect.y0 = output_rect->x0;
r_rect.y1 = output_rect->x1;
r_rect.x0 = output_rect->y0;
r_rect.x1 = output_rect->y1;
flags = VDP_OUTPUT_SURFACE_RENDER_ROTATE_270;
break;
default:
MP_ERR(vo, "Unsupported rotation angle: %u\n", mpi->params.rotate);
return -1;
}
mp_vdpau_mixer_render(vc->video_mixer, &opts, vc->rotation_surface,
&r_rect, mpi, video_rect);
vdp_st = vdp->output_surface_render_output_surface(output_surface,
output_rect,
vc->rotation_surface,
&r_rect,
NULL,
NULL,
flags);
CHECK_VDP_WARNING(vo, "Error rendering rotated frame");
} else {
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;
video/out: change aspects of OSD handling Let the VOs draw the OSD on their own, instead of making OSD drawing a separate VO driver call. Further, let it be the VOs responsibility to request subtitles with the correct PTS. We also basically allow the VO to request OSD/subtitles at any time. OSX changes untested.
2014-06-15 20:46:57 +02:00
int r = render_video_to_output_surface(vo,
vc->output_surfaces[vc->surface_num],
&vc->out_rect_vid, &vc->src_rect_vid);
draw_osd(vo);
return r;
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: limit output surfaces to allowed maximum dimensions We can't do much in this case, but at least we can not call the vdpau API functions with too large sizes. Apparently the API considers this undefined behavior, and random stuff might happen.
2015-06-05 19:33:09 +02:00
static int s_size(int max, int s, int disp)
vo_vdpau: don't try to create surfaces of size 0 At least on kwin, we decide to proceed without waiting for the window being mapped (due to the frame exts hack, see commit 8c002b79). But that leaves us with a window size of 0x0, which causes VdpOutputSurfaceCreate to fail. This prints some warnings, although vo_vdpau recovers later and this has no other bad consequences. Do the following things to deal with this: - set the "known" window size to the suggested window size before the window is even created - allow calling XGetGeometry on the window even if the window is not mapped yet (this should work just fine) - make the output surface minimum size 1x1 Strictly speaking, only one of these would be required to make the warning disappear, but they're all valid changes and increase robustness and correctness. At no point we use a window size of 0x0 as magic value for "unset" or unknown size, so keeping it unset has no purpose anyway. CC: @mpv-player/stable
2014-10-01 17:12:46 +02:00
{
disp = MPMAX(1, disp);
s += s / 2;
vo_vdpau: limit output surfaces to allowed maximum dimensions We can't do much in this case, but at least we can not call the vdpau API functions with too large sizes. Apparently the API considers this undefined behavior, and random stuff might happen.
2015-06-05 19:33:09 +02:00
return MPMIN(max, s >= disp ? s : disp);
vo_vdpau: don't try to create surfaces of size 0 At least on kwin, we decide to proceed without waiting for the window being mapped (due to the frame exts hack, see commit 8c002b79). But that leaves us with a window size of 0x0, which causes VdpOutputSurfaceCreate to fail. This prints some warnings, although vo_vdpau recovers later and this has no other bad consequences. Do the following things to deal with this: - set the "known" window size to the suggested window size before the window is even created - allow calling XGetGeometry on the window even if the window is not mapped yet (this should work just fine) - make the output surface minimum size 1x1 Strictly speaking, only one of these would be required to make the warning disappear, but they're all valid changes and increase robustness and correctness. At no point we use a window size of 0x0 as magic value for "unset" or unknown size, so keeping it unset has no purpose anyway. CC: @mpv-player/stable
2014-10-01 17:12:46 +02: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;
vo_vdpau: Implement rotation support VDPAU has explicit support for rotating surfaces, and it is far less expensive than using the normal rotation filter (which would require reading video frames back into system memory), it is desirable to implement the VO rotation capability. To do this, we need to render the video frames to an output surface, without rotation, and then render from that surface to the final output surface to apply the rotation. It is important that the intermediate surface is the same size as the final one (only not rotated) so that hqscaling can be applied if requested by the user. (hqscaling is a mixer capability and so takes effect when the video surface is rendered to an output surface) Finally, we must remember to explicitly clear the final output surface as VDPAU only auto-clears output surfaces when rendering video surfaces.
2015-07-11 05:42:22 +02:00
if (vo->params->rotate == 90 || vo->params->rotate == 270) {
vc->src_rect_vid.y0 = src_rect.x0;
vc->src_rect_vid.y1 = src_rect.x1;
vc->src_rect_vid.x0 = src_rect.y0;
vc->src_rect_vid.x1 = src_rect.y1;
} else {
vc->src_rect_vid.x0 = src_rect.x0;
vc->src_rect_vid.x1 = src_rect.x1;
vc->src_rect_vid.y0 = src_rect.y0;
vc->src_rect_vid.y1 = 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
vo_vdpau: limit output surfaces to allowed maximum dimensions We can't do much in this case, but at least we can not call the vdpau API functions with too large sizes. Apparently the API considers this undefined behavior, and random stuff might happen.
2015-06-05 19:33:09 +02:00
VdpBool ok;
uint32_t max_w, max_h;
vdp_st = vdp->output_surface_query_capabilities(vc->vdp_device,
OUTPUT_RGBA_FORMAT,
&ok, &max_w, &max_h);
if (vdp_st != VDP_STATUS_OK || !ok)
return;
vo: include normal render-ahead time in flip_queue_offset A small refactor; shouldn't change any behavior. Do this so immediate display can be achieved.
2014-12-09 17:46:35 +01:00
vc->flip_offset_us = vo->opts->fullscreen ?
1000LL * vc->flip_offset_fs :
1000LL * vc->flip_offset_window;
vo_opengl: disable interpolation without display-sync Without display-sync mode, our guesses wrt. vsync phase etc. are much worse, and I see no reason to keep the complicated "vsync_timed" code.
2015-11-25 22:10:55 +01:00
vo_set_queue_params(vo, vc->flip_offset_us, 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
vo_vdpau: shorten 2 variable names Why should I be required to type so much?
2015-06-05 19:18:12 +02:00
if (vc->output_surface_w < vo->dwidth || vc->output_surface_h < vo->dheight) {
vo_vdpau: limit output surfaces to allowed maximum dimensions We can't do much in this case, but at least we can not call the vdpau API functions with too large sizes. Apparently the API considers this undefined behavior, and random stuff might happen.
2015-06-05 19:33:09 +02:00
vc->output_surface_w = s_size(max_w, vc->output_surface_w, vo->dwidth);
vc->output_surface_h = s_size(max_h, vc->output_surface_h, 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: shorten 2 variable names Why should I be required to type so much?
2015-06-05 19:18:12 +02:00
vc->output_surface_w,
vc->output_surface_h,
vo_vdpau.c: cosmetics
2009-05-09 17:08:30 +02:00
&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
}
vo_vdpau: Implement rotation support VDPAU has explicit support for rotating surfaces, and it is far less expensive than using the normal rotation filter (which would require reading video frames back into system memory), it is desirable to implement the VO rotation capability. To do this, we need to render the video frames to an output surface, without rotation, and then render from that surface to the final output surface to apply the rotation. It is important that the intermediate surface is the same size as the final one (only not rotated) so that hqscaling can be applied if requested by the user. (hqscaling is a mixer capability and so takes effect when the video surface is rendered to an output surface) Finally, we must remember to explicitly clear the final output surface as VDPAU only auto-clears output surfaces when rendering video surfaces.
2015-07-11 05:42:22 +02:00
if (vc->rotation_surface != VDP_INVALID_HANDLE) {
vdp_st = vdp->output_surface_destroy(vc->rotation_surface);
CHECK_VDP_WARNING(vo, "Error when calling "
"vdp_output_surface_destroy");
}
if (vo->params->rotate == 90 || vo->params->rotate == 270) {
vdp_st = vdp->output_surface_create(vc->vdp_device,
OUTPUT_RGBA_FORMAT,
vc->output_surface_h,
vc->output_surface_w,
&vc->rotation_surface);
} else if (vo->params->rotate == 180) {
vdp_st = vdp->output_surface_create(vc->vdp_device,
OUTPUT_RGBA_FORMAT,
vc->output_surface_w,
vc->output_surface_h,
&vc->rotation_surface);
}
CHECK_VDP_WARNING(vo, "Error when calling vdp_output_surface_create");
MP_DBG(vo, "vdpau rotation surface create: %u\n",
vc->rotation_surface);
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
vo_vdpau, vo_opengl: handle vdpau preemption differently Use the newly provided mp_vdpau_handle_preemption() function, instead of accessing mp_vdpau_ctx fields directly. Will probably make multithreaded access to the vdpau context easier. Mostly unrelated to the actual changes, I've noticed that using hw decoding with vo_opengl sometimes leads to segfaults inside of nvidia's libGL when doing the following: 1. use hw decoding + vo_opengl 2. switch to console (will preempt on nvidia systems) 3. switch back to X (mpv will recover, switches to sw decoding) 4. enable hw decoding again 5. exit mpv Then it segfaults when mpv finally calls exit(). I'll just blame nvidia, although it seems likely that something in the gl_hwdec_vdpau.c preemption handling triggers corner cases in nvidia's code.
2014-05-09 21:49:32 +02:00
* probably not guaranteed behavior.
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_queue == VDP_INVALID_HANDLE) {
vdp_st = vdp->presentation_queue_create(vc->vdp_device, vc->flip_target,
&vc->flip_queue);
vo_vdpau, vo_opengl: handle vdpau preemption differently Use the newly provided mp_vdpau_handle_preemption() function, instead of accessing mp_vdpau_ctx fields directly. Will probably make multithreaded access to the vdpau context easier. Mostly unrelated to the actual changes, I've noticed that using hw decoding with vo_opengl sometimes leads to segfaults inside of nvidia's libGL when doing the following: 1. use hw decoding + vo_opengl 2. switch to console (will preempt on nvidia systems) 3. switch back to X (mpv will recover, switches to sw decoding) 4. enable hw decoding again 5. exit mpv Then it segfaults when mpv finally calls exit(). I'll just blame nvidia, although it seems likely that something in the gl_hwdec_vdpau.c preemption handling triggers corner cases in nvidia's code.
2014-05-09 21:49:32 +02: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
}
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");
video: take refresh rate changes into account This works only on X11, and only if the refresh rate changes due to the window being moved to another screen (detected by us). It doesn't include system screen reconfiguration yet. This calls VOCTRL_GET_DISPLAY_FPS on every frame, which makes me uneasy. It means extra thread communication with the win32 and Cocoa backends. On the other hand, a frame doesn't happen _that_ often, and the communication should still be pretty cheap and fast, so it's probably ok. Also needs some extra fuzz for vo_vdpau.c, because that does everything differently.
2014-08-17 02:50:59 +02:00
vc->user_fps = -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
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: 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->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;
}
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: retrieve mixer parameters directly from the hw surface Always configure the vdpau mixer based on the current surface sent to it. Before this, we just hardcoded the chroma type, and the surface size was essentially a guess. Calling VdpVideoSurfaceGetParameters() on every surface is a bit suspicious, but it appears it's a cheap function (just requiring some locks and a table lookup). This way we avoid creating another complicated mechanism to carry around the actual surface parameters with a mp_image/AVFrame.
2015-05-28 21:54:02 +02:00
mp_vdpau_get_format(vc->image_format, NULL, &vc->vdp_pixel_format);
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->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: always allocate the black pixel black_pixel is an (apparently necessary) 1x1 black surface used for clearing the screen. It was allocated in RGB mode only, but is sometimes used in YUV mode too.
2014-05-22 20:55:05 +02:00
if (vc->black_pixel == 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
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: 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 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: Implement rotation support VDPAU has explicit support for rotating surfaces, and it is far less expensive than using the normal rotation filter (which would require reading video frames back into system memory), it is desirable to implement the VO rotation capability. To do this, we need to render the video frames to an output surface, without rotation, and then render from that surface to the final output surface to apply the rotation. It is important that the intermediate surface is the same size as the final one (only not rotated) so that hqscaling can be applied if requested by the user. (hqscaling is a mixer capability and so takes effect when the video surface is rendered to an output surface) Finally, we must remember to explicitly clear the final output surface as VDPAU only auto-clears output surfaces when rendering video surfaces.
2015-07-11 05:42:22 +02:00
vc->rotation_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);
osd: simplify an aspect of change detection handling There was a somewhat obscure optimization in the OSD and subtitle rendering path: if only the position of the sub-images changed, and not the actual image data, uploading of the image data could be skipped. In theory, this could speed up things like scrolling subtitles. But it turns out that even in the rare cases subtitles have such scrolls or axis-aligned movement, modern libass rarely signals this kind of change. Possibly this is because of sub-pixel handling and such, which break this. As such, it's a worthless optimization and just introduces additional complexity and subtle bugs (especially in cases libass does the opposite: incorrectly signaling a position change only, which happened before). Remove this optimization, and rename bitmap_pos_id to change_id.
2015-03-18 12:33:14 +01:00
sfc->change_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: shorten 2 variable names Why should I be required to type so much?
2015-06-05 19:18:12 +02:00
vc->output_surface_w = vc->output_surface_h = -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
}
vo_vdpau, vo_opengl: handle vdpau preemption differently Use the newly provided mp_vdpau_handle_preemption() function, instead of accessing mp_vdpau_ctx fields directly. Will probably make multithreaded access to the vdpau context easier. Mostly unrelated to the actual changes, I've noticed that using hw decoding with vo_opengl sometimes leads to segfaults inside of nvidia's libGL when doing the following: 1. use hw decoding + vo_opengl 2. switch to console (will preempt on nvidia systems) 3. switch back to X (mpv will recover, switches to sw decoding) 4. enable hw decoding again 5. exit mpv Then it segfaults when mpv finally calls exit(). I'll just blame nvidia, although it seems likely that something in the gl_hwdec_vdpau.c preemption handling triggers corner cases in nvidia's code.
2014-05-09 21:49:32 +02:00
static bool check_preemption(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, vo_opengl: handle vdpau preemption differently Use the newly provided mp_vdpau_handle_preemption() function, instead of accessing mp_vdpau_ctx fields directly. Will probably make multithreaded access to the vdpau context easier. Mostly unrelated to the actual changes, I've noticed that using hw decoding with vo_opengl sometimes leads to segfaults inside of nvidia's libGL when doing the following: 1. use hw decoding + vo_opengl 2. switch to console (will preempt on nvidia systems) 3. switch back to X (mpv will recover, switches to sw decoding) 4. enable hw decoding again 5. exit mpv Then it segfaults when mpv finally calls exit(). I'll just blame nvidia, although it seems likely that something in the gl_hwdec_vdpau.c preemption handling triggers corner cases in nvidia's code.
2014-05-09 21:49:32 +02:00
int r = mp_vdpau_handle_preemption(vc->mpvdp, &vc->preemption_counter);
if (r < 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
mark_vdpau_objects_uninitialized(vo);
vo_vdpau, vo_opengl: handle vdpau preemption differently Use the newly provided mp_vdpau_handle_preemption() function, instead of accessing mp_vdpau_ctx fields directly. Will probably make multithreaded access to the vdpau context easier. Mostly unrelated to the actual changes, I've noticed that using hw decoding with vo_opengl sometimes leads to segfaults inside of nvidia's libGL when doing the following: 1. use hw decoding + vo_opengl 2. switch to console (will preempt on nvidia systems) 3. switch back to X (mpv will recover, switches to sw decoding) 4. enable hw decoding again 5. exit mpv Then it segfaults when mpv finally calls exit(). I'll just blame nvidia, although it seems likely that something in the gl_hwdec_vdpau.c preemption handling triggers corner cases in nvidia's code.
2014-05-09 21:49:32 +02:00
if (r < 0)
return false;
vc->vdp_device = vc->mpvdp->vdp_device;
if (initialize_vdpau_objects(vo) < 0)
return 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
}
vo_vdpau, vo_opengl: handle vdpau preemption differently Use the newly provided mp_vdpau_handle_preemption() function, instead of accessing mp_vdpau_ctx fields directly. Will probably make multithreaded access to the vdpau context easier. Mostly unrelated to the actual changes, I've noticed that using hw decoding with vo_opengl sometimes leads to segfaults inside of nvidia's libGL when doing the following: 1. use hw decoding + vo_opengl 2. switch to console (will preempt on nvidia systems) 3. switch back to X (mpv will recover, switches to sw decoding) 4. enable hw decoding again 5. exit mpv Then it segfaults when mpv finally calls exit(). I'll just blame nvidia, although it seems likely that something in the gl_hwdec_vdpau.c preemption handling triggers corner cases in nvidia's code.
2014-05-09 21:49:32 +02:00
return true;
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
static bool status_ok(struct vo *vo)
{
vo_vdpau, vo_opengl: handle vdpau preemption differently Use the newly provided mp_vdpau_handle_preemption() function, instead of accessing mp_vdpau_ctx fields directly. Will probably make multithreaded access to the vdpau context easier. Mostly unrelated to the actual changes, I've noticed that using hw decoding with vo_opengl sometimes leads to segfaults inside of nvidia's libGL when doing the following: 1. use hw decoding + vo_opengl 2. switch to console (will preempt on nvidia systems) 3. switch back to X (mpv will recover, switches to sw decoding) 4. enable hw decoding again 5. exit mpv Then it segfaults when mpv finally calls exit(). I'll just blame nvidia, although it seems likely that something in the gl_hwdec_vdpau.c preemption handling triggers corner cases in nvidia's code.
2014-05-09 21:49:32 +02:00
return vo->config_ok && check_preemption(vo);
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
}
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: remove an unused parameter This parameter has been unused for years (the last flag was removed in commit d658b115). Get rid of it. This affects the general VO API, as well as the vo_opengl backend API, so it touches a lot of files. The VOFLAGs are still used to control OpenGL context creation, so move them to the OpenGL backend code.
2015-10-03 18:20:16 +02:00
static int reconfig(struct vo *vo, struct mp_image_params *params)
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;
vo_vdpau: check maximum video size Check the maximum size of video surfaces, and refuse initialization if the video is too large for them. Maybe we could do something more sophisticated, like inserting a software scaler. On the other hand, this would have a very questionable benefit, as it would be guaranteed to be too slow.
2015-06-04 22:29:21 +02:00
struct vdp_functions *vdp = vc->vdp;
VdpStatus vdp_st;
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, vo_opengl: handle vdpau preemption differently Use the newly provided mp_vdpau_handle_preemption() function, instead of accessing mp_vdpau_ctx fields directly. Will probably make multithreaded access to the vdpau context easier. Mostly unrelated to the actual changes, I've noticed that using hw decoding with vo_opengl sometimes leads to segfaults inside of nvidia's libGL when doing the following: 1. use hw decoding + vo_opengl 2. switch to console (will preempt on nvidia systems) 3. switch back to X (mpv will recover, switches to sw decoding) 4. enable hw decoding again 5. exit mpv Then it segfaults when mpv finally calls exit(). I'll just blame nvidia, although it seems likely that something in the gl_hwdec_vdpau.c preemption handling triggers corner cases in nvidia's code.
2014-05-09 21:49:32 +02:00
if (!check_preemption(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
return -1;
vo_vdpau: add support for VFCAP_FLIP Patch by Carl Eugen Hoyos.
2009-11-15 14:50:28 +01:00
vo_vdpau: check maximum video size Check the maximum size of video surfaces, and refuse initialization if the video is too large for them. Maybe we could do something more sophisticated, like inserting a software scaler. On the other hand, this would have a very questionable benefit, as it would be guaranteed to be too slow.
2015-06-04 22:29:21 +02:00
VdpChromaType chroma_type = VDP_CHROMA_TYPE_420;
mp_vdpau_get_format(params->imgfmt, &chroma_type, NULL);
VdpBool ok;
uint32_t max_w, max_h;
vdp_st = vdp->video_surface_query_capabilities(vc->vdp_device, chroma_type,
&ok, &max_w, &max_h);
CHECK_VDP_ERROR(vo, "Error when calling vdp_video_surface_query_capabilities");
if (!ok)
return -1;
if (params->w > max_w || params->h > max_h) {
if (ok)
MP_ERR(vo, "Video too large for vdpau.\n");
return -1;
}
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
vdpau: move RGB surface management out of the VO Integrate it with the existing surface allocator in vdpau.c. The changes are a bit violent, because the vdpau API is so non-orthogonal: compared to video surfaces, output surfaces use a different ID type, different format types, and different API functions. Also, introduce IMGFMT_VDPAU_OUTPUT for VdpOutputSurfaces wrapped in mp_image, rather than hacking it. This is a bit cleaner.
2014-05-22 20:55:17 +02:00
vc->rgb_mode = mp_vdpau_get_rgb_format(params->imgfmt, 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
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: separate window creation and configuration This gets rid of an old hack, VOFLAG_HIDDEN. Although handling of it has been sane for a while, it used to cause much pain, and is still unintuitive and weird even today. The main reason for this hack is that OpenGL selects a X11 Visual for you, and you're supposed to use this Visual when creating the X window for the OpenGL context. Which means the X window can't be created early in the common X11 init code, but the OpenGL code needs to do something before that. API-wise you need separate functions for X11 init and X11 window creation. The VOFLAG_HIDDEN hack conflated window creation and the entrypoint for resizing on video resolution change into one function, vo_x11_config_vo_window(). This required all platform backends to handle this flag, even if they didn't need this mechanism. Wayland still uses this for minor reasons (alpha support?), so the wayland backend must be changed before the flag can be entirely removed.
2015-09-30 23:31:34 +02:00
vo_x11_config_vo_window(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 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
osd: simplify an aspect of change detection handling There was a somewhat obscure optimization in the OSD and subtitle rendering path: if only the position of the sub-images changed, and not the actual image data, uploading of the image data could be skipped. In theory, this could speed up things like scrolling subtitles. But it turns out that even in the rare cases subtitles have such scrolls or axis-aligned movement, modern libass rarely signals this kind of change. Possibly this is because of sub-pixel handling and such, which break this. As such, it's a worthless optimization and just introduces additional complexity and subtle bugs (especially in cases libass does the opposite: incorrectly signaling a position change only, which happened before). Remove this optimization, and rename bitmap_pos_id to change_id.
2015-03-18 12:33:14 +01:00
if (imgs->change_id == sfc->change_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
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) {
Remove some VLAs They are evil and should be eradicated. Some of these were pretty dumb anyway. There are probably some more around in platform specific code or other code not enabled by default on Linux.
2015-11-06 21:12:20 +01:00
char *zeros = calloc(sfc->packer->used_width, format_size);
if (!zeros)
return;
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_put_bits_native(sfc->surface,
&(const void *){zeros}, &(uint32_t){0},
&(VdpRect){0, 0, sfc->packer->used_width,
sfc->packer->used_height});
vo_vdpau: check vdpau API return value
2015-03-23 18:12:05 +01:00
CHECK_VDP_WARNING(vo, "OSD: error uploading OSD bitmap");
Remove some VLAs They are evil and should be eradicated. Some of these were pretty dumb anyway. There are probably some more around in platform specific code or other code not enabled by default on Linux.
2015-11-06 21:12:20 +01:00
free(zeros);
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
}
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: 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
osd: simplify an aspect of change detection handling There was a somewhat obscure optimization in the OSD and subtitle rendering path: if only the position of the sub-images changed, and not the actual image data, uploading of the image data could be skipped. In theory, this could speed up things like scrolling subtitles. But it turns out that even in the rare cases subtitles have such scrolls or axis-aligned movement, modern libass rarely signals this kind of change. Possibly this is because of sub-pixel handling and such, which break this. As such, it's a worthless optimization and just introduces additional complexity and subtle bugs (especially in cases libass does the opposite: incorrectly signaling a position change only, which happened before). Remove this optimization, and rename bitmap_pos_id to change_id.
2015-03-18 12:33:14 +01:00
sfc->change_id = imgs->change_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
}
video/out: change aspects of OSD handling Let the VOs draw the OSD on their own, instead of making OSD drawing a separate VO driver call. Further, let it be the VOs responsibility to request subtitles with the correct PTS. We also basically allow the VO to request OSD/subtitles at any time. OSX changes untested.
2014-06-15 20:46:57 +02:00
static void draw_osd(struct vo *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
{
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_vdpau: check VDP_RGBA_FORMAT_A8 support Apparently not all vdpau drivers in the wild support this format (VDPAU SUNXI can't). Revert to RGB in these cases.
2015-11-04 21:47:20 +01:00
bool formats[SUBBITMAP_COUNT] = {
[SUBBITMAP_LIBASS] = vc->supports_a8,
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
[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
};
video/out: change aspects of OSD handling Let the VOs draw the OSD on their own, instead of making OSD drawing a separate VO driver call. Further, let it be the VOs responsibility to request subtitles with the correct PTS. We also basically allow the VO to request OSD/subtitles at any time. OSX changes untested.
2014-06-15 20:46:57 +02:00
double pts = vc->current_image ? vc->current_image->pts : 0;
osd_draw(vo->osd, vc->osd_rect, pts, 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;
}
vo: change internal API for drawing frames draw_image_timed is renamed to draw_frame. struct frame_timing is renamed to vo_frame. flip_page_timed is merged into draw_frame (the additional parameters are part of struct vo_frame). draw_frame also deprecates VOCTRL_REDRAW_FRAME, and replaces it with a method that works for both VOs which can cache the current frame, and VOs which need to redraw it anyway. This is preparation to making the interpolation and (work in progress) display sync code saner. Lots of other refactoring, and also some simplifications.
2015-07-01 19:24:28 +02:00
static void flip_page(struct vo *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
{
struct vdpctx *vc = vo->priv;
struct vdp_functions *vdp = vc->vdp;
VdpStatus vdp_st;
vo: change internal API for drawing frames draw_image_timed is renamed to draw_frame. struct frame_timing is renamed to vo_frame. flip_page_timed is merged into draw_frame (the additional parameters are part of struct vo_frame). draw_frame also deprecates VOCTRL_REDRAW_FRAME, and replaces it with a method that works for both VOs which can cache the current frame, and VOs which need to redraw it anyway. This is preparation to making the interpolation and (work in progress) display sync code saner. Lots of other refactoring, and also some simplifications.
2015-07-01 19:24:28 +02:00
int64_t pts_us = vc->current_pts;
int duration = vc->current_duration;
vo_vdpau: better integration with the generic framedrop code vo_vdpau uses its own framedrop code, mostly for historic reasons. It has some tricky heuristics, of which I'm not sure how they work, or if they have any effect at all, but in any case, I want to keep this code for now. One day it might get fully ported to the vo.c framedrop code, or just removed. But improve its interaction with the user-visible framedrop controls. Make --framedrop actually enable and disable the vo_vdpau framedrop code, and increment the number of dropped frames correctly. The code path for other VOs should be equivalent. The vo_vdpau behavior should, except for the improvements mentioned above, be mostly equivalent as well. One minor change is that frames "shown" during preemption are always count as dropped. Remove the statement from the manpage that vo_vdpau is the default; this hasn't been the case for a while.
2014-09-20 15:14:43 +02:00
vc->dropped_frame = true; // changed at end if false
vo_vdpau, vo_opengl: handle vdpau preemption differently Use the newly provided mp_vdpau_handle_preemption() function, instead of accessing mp_vdpau_ctx fields directly. Will probably make multithreaded access to the vdpau context easier. Mostly unrelated to the actual changes, I've noticed that using hw decoding with vo_opengl sometimes leads to segfaults inside of nvidia's libGL when doing the following: 1. use hw decoding + vo_opengl 2. switch to console (will preempt on nvidia systems) 3. switch back to X (mpv will recover, switches to sw decoding) 4. enable hw decoding again 5. exit mpv Then it segfaults when mpv finally calls exit(). I'll just blame nvidia, although it seems likely that something in the gl_hwdec_vdpau.c preemption handling triggers corner cases in nvidia's code.
2014-05-09 21:49:32 +02:00
if (!check_preemption(vo))
vo: change internal API for drawing frames draw_image_timed is renamed to draw_frame. struct frame_timing is renamed to vo_frame. flip_page_timed is merged into draw_frame (the additional parameters are part of struct vo_frame). draw_frame also deprecates VOCTRL_REDRAW_FRAME, and replaces it with a method that works for both VOs which can cache the current frame, and VOs which need to redraw it anyway. This is preparation to making the interpolation and (work in progress) display sync code saner. Lots of other refactoring, and also some simplifications.
2015-07-01 19:24:28 +02:00
goto drop;
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
video: take refresh rate changes into account This works only on X11, and only if the refresh rate changes due to the window being moved to another screen (detected by us). It doesn't include system screen reconfiguration yet. This calls VOCTRL_GET_DISPLAY_FPS on every frame, which makes me uneasy. It means extra thread communication with the win32 and Cocoa backends. On the other hand, a frame doesn't happen _that_ often, and the communication should still be pretty cheap and fast, so it's probably ok. Also needs some extra fuzz for vo_vdpau.c, because that does everything differently.
2014-08-17 02:50:59 +02:00
vc->vsync_interval = 1;
if (vc->user_fps > 0) {
vc->vsync_interval = 1e9 / vc->user_fps;
} else if (vc->user_fps == 0) {
vc->vsync_interval = vo_get_vsync_interval(vo) * 1000;
}
vo: better magic value for unknown vsync interval The value 1 is useful in some contexts, but not such a good choice otherwise.
2015-07-01 19:25:13 +02:00
vc->vsync_interval = MPMAX(vc->vsync_interval, 1);
video: take refresh rate changes into account This works only on X11, and only if the refresh rate changes due to the window being moved to another screen (detected by us). It doesn't include system screen reconfiguration yet. This calls VOCTRL_GET_DISPLAY_FPS on every frame, which makes me uneasy. It means extra thread communication with the win32 and Cocoa backends. On the other hand, a frame doesn't happen _that_ often, and the communication should still be pretty cheap and fast, so it's probably ok. Also needs some extra fuzz for vo_vdpau.c, because that does everything differently.
2014-08-17 02:50:59 +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
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
video: move display and timing to a separate thread The VO is run inside its own thread. It also does most of video timing. The playloop hands the image data and a realtime timestamp to the VO, and the VO does the rest. In particular, this allows the playloop to do other things, instead of blocking for video redraw. But if anything accesses the VO during video timing, it will block. This also fixes vo_sdl.c event handling; but that is only a side-effect, since reimplementing the broken way would require more effort. Also drop --softsleep. In theory, this option helps if the kernel's sleeping mechanism is too inaccurate for video timing. In practice, I haven't ever encountered a situation where it helps, and it just burns CPU cycles. On the other hand it's probably actively harmful, because it prevents the libavcodec decoder threads from doing real work. Side note: Originally, I intended that multiple frames can be queued to the VO. But this is not done, due to problems with OSD and other certain features. OSD in particular is simply designed in a way that it can be neither timed nor copied, so you do have to render it into the video frame before you can draw the next frame. (Subtitles have no such restriction. sd_lavc was even updated to fix this.) It seems the right solution to queuing multiple VO frames is rendering on VO-backed framebuffers, like vo_vdpau.c does. This requires VO driver support, and is out of scope of this commit. As consequence, the VO has a queue size of 1. The existing video queue is just needed to compute frame duration, and will be moved out in the next commit.
2014-08-12 23:02:08 +02:00
* future. This is guaranteed by vo.c, which currently actually queues
vo: include normal render-ahead time in flip_queue_offset A small refactor; shouldn't change any behavior. Do this so immediate display can be achieved.
2014-12-09 17:46:35 +01:00
* ahead by roughly the flip queue offset. Just to be sure
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
* give some additional room by doubling the time.
* - The last vsync can never be in the future.
*/
vo: include normal render-ahead time in flip_queue_offset A small refactor; shouldn't change any behavior. Do this so immediate display can be achieved.
2014-12-09 17:46:35 +01:00
int64_t max_pts_ahead = vc->flip_offset_us * 1000 * 2;
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
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: fix confusion around vsync_interval vc->vsync_interval and vsync_interval should be the same value, but actually vc->vsync_interval was updated after vsync_interval was initialized. This was probably not intended. Fix this by removing the duplicate local variable. There were probably no bad effects.
2014-09-20 14:54:19 +02:00
if (now > PREV_VSYNC(FFMAX(pts, vc->last_queue_time + 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
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);
vo_vdpau: fix confusion around vsync_interval vc->vsync_interval and vsync_interval should be the same value, but actually vc->vsync_interval was updated after vsync_interval was initialized. This was probably not intended. Fix this by removing the duplicate local variable. There were probably no bad effects.
2014-09-20 14:54:19 +02:00
if (pts < vsync + vc->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)
vo_vdpau: fix confusion around vsync_interval vc->vsync_interval and vsync_interval should be the same value, but actually vc->vsync_interval was updated after vsync_interval was initialized. This was probably not intended. Fix this by removing the duplicate local variable. There were probably no bad effects.
2014-09-20 14:54:19 +02:00
> pts - vc->last_ideal_time + vc->vsync_interval / 2
buid: readd -Wparentheses This warning wasn't overly helpful in the past, and warned against perfectly fine code. But at least with recent gcc versions, this is the warning that complains about assignments in if expressions (why???), so we want to enable it. Also change all the code this warning complains about for no reason.
2015-03-02 19:09:25 +01:00
|| (vc->dropped_frame && vsync > vc->dropped_time)))
vo_vdpau: fix confusion around vsync_interval vc->vsync_interval and vsync_interval should be the same value, but actually vc->vsync_interval was updated after vsync_interval was initialized. This was probably not intended. Fix this by removing the duplicate local variable. There were probably no bad effects.
2014-09-20 14:54:19 +02:00
pts -= vc->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
vc->dropped_time = ideal_pts;
vo_vdpau: fix confusion around vsync_interval vc->vsync_interval and vsync_interval should be the same value, but actually vc->vsync_interval was updated after vsync_interval was initialized. This was probably not intended. Fix this by removing the duplicate local variable. There were probably no bad effects.
2014-09-20 14:54:19 +02:00
pts = FFMAX(pts, vc->last_queue_time + 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: fix confusion around vsync_interval vc->vsync_interval and vsync_interval should be the same value, but actually vc->vsync_interval was updated after vsync_interval was initialized. This was probably not intended. Fix this by removing the duplicate local variable. There were probably no bad effects.
2014-09-20 14:54:19 +02:00
if (npts < PREV_VSYNC(pts) + vc->vsync_interval)
vo: change internal API for drawing frames draw_image_timed is renamed to draw_frame. struct frame_timing is renamed to vo_frame. flip_page_timed is merged into draw_frame (the additional parameters are part of struct vo_frame). draw_frame also deprecates VOCTRL_REDRAW_FRAME, and replaces it with a method that works for both VOs which can cache the current frame, and VOs which need to redraw it anyway. This is preparation to making the interpolation and (work in progress) display sync code saner. Lots of other refactoring, and also some simplifications.
2015-07-01 19:24:28 +02:00
goto drop;
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: 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: fix confusion around vsync_interval vc->vsync_interval and vsync_interval should be the same value, but actually vc->vsync_interval was updated after vsync_interval was initialized. This was probably not intended. Fix this by removing the duplicate local variable. There were probably no bad effects.
2014-09-20 14:54:19 +02:00
pts = FFMAX(pts, vsync + (vc->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);
vo_vdpau: fix confusion around vsync_interval vc->vsync_interval and vsync_interval should be the same value, but actually vc->vsync_interval was updated after vsync_interval was initialized. This was probably not intended. Fix this by removing the duplicate local variable. There were probably no bad effects.
2014-09-20 14:54:19 +02:00
if (npts < vsync + vc->vsync_interval)
vo: change internal API for drawing frames draw_image_timed is renamed to draw_frame. struct frame_timing is renamed to vo_frame. flip_page_timed is merged into draw_frame (the additional parameters are part of struct vo_frame). draw_frame also deprecates VOCTRL_REDRAW_FRAME, and replaces it with a method that works for both VOs which can cache the current frame, and VOs which need to redraw it anyway. This is preparation to making the interpolation and (work in progress) display sync code saner. Lots of other refactoring, and also some simplifications.
2015-07-01 19:24:28 +02:00
goto drop;
vo_vdpau: fix confusion around vsync_interval vc->vsync_interval and vsync_interval should be the same value, but actually vc->vsync_interval was updated after vsync_interval was initialized. This was probably not intended. Fix this by removing the duplicate local variable. There were probably no bad effects.
2014-09-20 14:54:19 +02:00
pts = vsync + (vc->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);
vo: change internal API for drawing frames draw_image_timed is renamed to draw_frame. struct frame_timing is renamed to vo_frame. flip_page_timed is merged into draw_frame (the additional parameters are part of struct vo_frame). draw_frame also deprecates VOCTRL_REDRAW_FRAME, and replaces it with a method that works for both VOs which can cache the current frame, and VOs which need to redraw it anyway. This is preparation to making the interpolation and (work in progress) display sync code saner. Lots of other refactoring, and also some simplifications.
2015-07-01 19:24:28 +02:00
return;
drop:
vo_increment_drop_count(vo, 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
}
vo: change internal API for drawing frames draw_image_timed is renamed to draw_frame. struct frame_timing is renamed to vo_frame. flip_page_timed is merged into draw_frame (the additional parameters are part of struct vo_frame). draw_frame also deprecates VOCTRL_REDRAW_FRAME, and replaces it with a method that works for both VOs which can cache the current frame, and VOs which need to redraw it anyway. This is preparation to making the interpolation and (work in progress) display sync code saner. Lots of other refactoring, and also some simplifications.
2015-07-01 19:24:28 +02:00
static void draw_frame(struct vo *vo, struct vo_frame *frame)
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 vdpctx *vc = vo->priv;
vo_vdpau, vo_opengl: handle vdpau preemption differently Use the newly provided mp_vdpau_handle_preemption() function, instead of accessing mp_vdpau_ctx fields directly. Will probably make multithreaded access to the vdpau context easier. Mostly unrelated to the actual changes, I've noticed that using hw decoding with vo_opengl sometimes leads to segfaults inside of nvidia's libGL when doing the following: 1. use hw decoding + vo_opengl 2. switch to console (will preempt on nvidia systems) 3. switch back to X (mpv will recover, switches to sw decoding) 4. enable hw decoding again 5. exit mpv Then it segfaults when mpv finally calls exit(). I'll just blame nvidia, although it seems likely that something in the gl_hwdec_vdpau.c preemption handling triggers corner cases in nvidia's code.
2014-05-09 21:49:32 +02:00
check_preemption(vo);
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
vo: change internal API for drawing frames draw_image_timed is renamed to draw_frame. struct frame_timing is renamed to vo_frame. flip_page_timed is merged into draw_frame (the additional parameters are part of struct vo_frame). draw_frame also deprecates VOCTRL_REDRAW_FRAME, and replaces it with a method that works for both VOs which can cache the current frame, and VOs which need to redraw it anyway. This is preparation to making the interpolation and (work in progress) display sync code saner. Lots of other refactoring, and also some simplifications.
2015-07-01 19:24:28 +02:00
if (frame->current && !frame->redraw) {
struct mp_image *vdp_mpi =
mp_vdpau_upload_video_surface(vc->mpvdp, frame->current);
if (!vdp_mpi)
MP_ERR(vo, "Could not upload image.\n");
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
vo: change internal API for drawing frames draw_image_timed is renamed to draw_frame. struct frame_timing is renamed to vo_frame. flip_page_timed is merged into draw_frame (the additional parameters are part of struct vo_frame). draw_frame also deprecates VOCTRL_REDRAW_FRAME, and replaces it with a method that works for both VOs which can cache the current frame, and VOs which need to redraw it anyway. This is preparation to making the interpolation and (work in progress) display sync code saner. Lots of other refactoring, and also some simplifications.
2015-07-01 19:24:28 +02:00
talloc_free(vc->current_image);
vc->current_image = vdp_mpi;
}
vc->current_pts = frame->pts;
vc->current_duration = frame->duration;
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: don't upload video images in advance With software decoding, images were uploaded to vdpau surfaces as they were queued to the VO. This makes it slightly more complicated (especially later on), and has no advantages - so stop doing it. The only reason why this was done explicitly was due to attempts to keep the code equivalent (instead of risking performance regressions). The original code did this naturally for certain reasons, but now that we can measure that it has no advantages and just requires extra code, we can just drop it.
2014-07-29 00:21:02 +02:00
if (status_ok(vo))
video_to_output_surface(vo);
core/VO: Allow VO drivers to add/modify frames Add interfaces to allow VO drivers to add or remove frames from the video stream and to alter timestamps. Currently this functionality only works with in correct-pts mode. Use the new functionality in vo_vdpau to properly support frame-adding deinterlace modes. Frames added by the VDPAU deinterlacing code are now properly timed. Before every second frame was always shown immediately (probably next monitor refresh) after the previous one, even if you were watching things in slow motion, and framestepping didn't stop at them at all. When seeking the deinterlace algorithm is no longer fed a mix of frames from old and new positions. As a side effect of the changes a problem with resize events was also fixed. Resizing calls video_to_output_surface() to render the frame at the new resolution, but before this function also changed the list of history frames, so resizing could give an image different from the original one, and also corrupt next frames due to them seeing the wrong history. Now the function has no such side effects. There are more resize-related problems though that will be fixed in a later commit. The deint_mpi[] list of reserved frames is increased from 2 to 3 entries for reasons related to the above. Having 2 entries is enough when you initially get a new frame in draw_image() because then you'll have those two entries plus the new one for a total of 3 (the code relied on the oldest mpi implicitly staying reserved for the duration of the call even after usage count was decreased). However if you want to be able to reproduce the rendering outside draw_image(), relying on the explicitly reserved list only, then it needs to store 3 entries.
2009-09-18 15:27:55 +02:00
}
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: directly get surface size from surface for screenshots The previous code was not wrong, but I'd claim this makes the code more robust. If a situation could happen in which the passed surface size is incorrect, we could have passed a too small image, and VdpOutputSurfaceGetBitsNative could have randomly overwritten memory.
2015-06-05 19:25:25 +02:00
VdpOutputSurface surface)
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;
vo_vdpau: directly get surface size from surface for screenshots The previous code was not wrong, but I'd claim this makes the code more robust. If a situation could happen in which the passed surface size is incorrect, we could have passed a too small image, and VdpOutputSurfaceGetBitsNative could have randomly overwritten memory.
2015-06-05 19:25:25 +02:00
VdpRGBAFormat fmt;
uint32_t w, h;
vdp_st = vdp->output_surface_get_parameters(surface, &fmt, &w, &h);
if (vdp_st != VDP_STATUS_OK)
return NULL;
assert(fmt == OUTPUT_RGBA_FORMAT);
struct mp_image *image = mp_image_alloc(IMGFMT_BGR0, w, h);
video: introduce failure path for image allocations Until now, failure to allocate image data resulted in a crash (i.e. abort() was called). This was intentional, because it's pretty silly to degrade playback, and in almost all situations, the OOM will probably kill you anyway. (And then there's the standard Linux overcommit behavior, which also will kill you at some point.) But I changed my opinion, so here we go. This change does not affect _all_ memory allocations, just image data. Now in most failure cases, the output will just be skipped. For video filters, this coincidentally means that failure is treated as EOF (because the playback core assumes EOF if nothing comes out of the video filter chain). In other situations, output might be in some way degraded, like skipping frames, not scaling OSD, and such. Functions whose return values changed semantics: mp_image_alloc mp_image_new_copy mp_image_new_ref mp_image_make_writeable mp_image_setrefp mp_image_to_av_frame_and_unref mp_image_from_av_frame mp_image_new_external_ref mp_image_new_custom_ref mp_image_pool_make_writeable mp_image_pool_get mp_image_pool_new_copy mp_vdpau_mixed_frame_create vf_alloc_out_image vf_make_out_image_writeable glGetWindowScreenshot
2014-06-17 22:43:43 +02:00
if (!image)
return NULL;
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_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];
vo_vdpau: directly get surface size from surface for screenshots The previous code was not wrong, but I'd claim this makes the code more robust. If a situation could happen in which the passed surface size is incorrect, we could have passed a too small image, and VdpOutputSurfaceGetBitsNative could have randomly overwritten memory.
2015-06-05 19:25:25 +02:00
struct mp_image *image = read_output_surface(vo, screen);
vo_vdpau: add a NULL check, verify image dimensions read_output_surface() could fail and return NULL. Also, make sure we don't set the image to a size larger than the allocated size. Normally this shouldn't happen, but in theory it could in corner cases; this is for robustness.
2015-06-06 21:06:54 +02:00
if (image && image->w >= vo->dwidth && image->h >= vo->dheight)
mp_image_set_size(image, vo->dwidth, vo->dheight);
vo_vdpau: implement screenshots
2011-10-06 20:46:01 +02:00
return image;
}
video: remove vfcap.h And remove all uses of the VFCAP_CSP_SUPPORTED* constants. This is supposed to reduce conversions if many filters are used (with many incompatible pixel formats), and also for preferring the VO's natively supported pixel formats (as opposed to conversion). This is worthless by now. Not only do the main VOs not use software conversion, but also the way vf_lavfi and libavfilter work mostly break the way the old MPlayer mechanism worked. Other important filters like vf_vapoursynth do not support "proper" format negotation either. Part of this was already removed with the vf_scale cleanup from today. While I'm touching every single VO, also fix the query_format argument (it's not a FourCC anymore).
2015-01-21 22:08:24 +01:00
static int query_format(struct vo *vo, int 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;
if (mp_vdpau_get_format(format, NULL, NULL))
video: remove vfcap.h And remove all uses of the VFCAP_CSP_SUPPORTED* constants. This is supposed to reduce conversions if many filters are used (with many incompatible pixel formats), and also for preferring the VO's natively supported pixel formats (as opposed to conversion). This is worthless by now. Not only do the main VOs not use software conversion, but also the way vf_lavfi and libavfilter work mostly break the way the old MPlayer mechanism worked. Other important filters like vf_vapoursynth do not support "proper" format negotation either. Part of this was already removed with the vf_scale cleanup from today. While I'm touching every single VO, also fix the query_format argument (it's not a FourCC anymore).
2015-01-21 22:08:24 +01:00
return 1;
vdpau: move RGB surface management out of the VO Integrate it with the existing surface allocator in vdpau.c. The changes are a bit violent, because the vdpau API is so non-orthogonal: compared to video surfaces, output surfaces use a different ID type, different format types, and different API functions. Also, introduce IMGFMT_VDPAU_OUTPUT for VdpOutputSurfaces wrapped in mp_image, rather than hacking it. This is a bit cleaner.
2014-05-22 20:55:17 +02:00
if (!vc->force_yuv && mp_vdpau_get_rgb_format(format, NULL))
video: remove vfcap.h And remove all uses of the VFCAP_CSP_SUPPORTED* constants. This is supposed to reduce conversions if many filters are used (with many incompatible pixel formats), and also for preferring the VO's natively supported pixel formats (as opposed to conversion). This is worthless by now. Not only do the main VOs not use software conversion, but also the way vf_lavfi and libavfilter work mostly break the way the old MPlayer mechanism worked. Other important filters like vf_vapoursynth do not support "proper" format negotation either. Part of this was already removed with the vf_scale cleanup from today. While I'm touching every single VO, also fix the query_format argument (it's not a FourCC anymore).
2015-01-21 22:08:24 +01:00
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
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: Implement rotation support VDPAU has explicit support for rotating surfaces, and it is far less expensive than using the normal rotation filter (which would require reading video frames back into system memory), it is desirable to implement the VO rotation capability. To do this, we need to render the video frames to an output surface, without rotation, and then render from that surface to the final output surface to apply the rotation. It is important that the intermediate surface is the same size as the final one (only not rotated) so that hqscaling can be applied if requested by the user. (hqscaling is a mixer capability and so takes effect when the video surface is rendered to an output surface) Finally, we must remember to explicitly clear the final output surface as VDPAU only auto-clears output surfaces when rendering video surfaces.
2015-07-11 05:42:22 +02:00
if (vc->rotation_surface != VDP_INVALID_HANDLE) {
vdp_st = vdp->output_surface_destroy(vc->rotation_surface);
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;
video: refactor how VO exports hwdec device handles The main change is with video/hwdec.h. mp_hwdec_info is made opaque (and renamed to mp_hwdec_devices). Its accessors are mainly thread-safe (or documented where not), which makes the whole thing saner and cleaner. In particular, thread-safety rules become less subtle and more obvious. The new internal API makes it easier to support multiple OpenGL interop backends. (Although this is not done yet, and it's not clear whether it ever will.) This also removes all the API-specific fields from mp_hwdec_ctx and replaces them with a "ctx" field. For d3d in particular, we drop the mp_d3d_ctx struct completely, and pass the interfaces directly. Remove the emulation checks from vaapi.c and vdpau.c; they are pointless, and the checks that matter are done on the VO layer. The d3d hardware decoders might slightly change behavior: dxva2-copy will not use the VO device anymore if the VO supports proper interop. This pretty much assumes that any in such cases the VO will not use any form of exclusive mode, which makes using the VO device in copy mode unnecessary. This is a big refactor. Some things may be untested and could be broken.
2016-05-09 19:42:03 +02:00
hwdec_devices_remove(vo->hwdec_devs, &vc->mpvdp->hwctx);
hwdec_devices_destroy(vo->hwdec_devs);
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;
x11: separate window creation and configuration This gets rid of an old hack, VOFLAG_HIDDEN. Although handling of it has been sane for a while, it used to cause much pain, and is still unintuitive and weird even today. The main reason for this hack is that OpenGL selects a X11 Visual for you, and you're supposed to use this Visual when creating the X window for the OpenGL context. Which means the X window can't be created early in the common X11 init code, but the OpenGL code needs to do something before that. API-wise you need separate functions for X11 init and X11 window creation. The VOFLAG_HIDDEN hack conflated window creation and the entrypoint for resizing on video resolution change into one function, vo_x11_config_vo_window(). This required all platform backends to handle this flag, even if they didn't need this mechanism. Wayland still uses this for minor reasons (alpha support?), so the wayland backend must be changed before the flag can be entirely removed.
2015-09-30 23:31:34 +02:00
if (!vo_x11_create_vo_window(vo, NULL, "vdpau")) {
vo_x11_uninit(vo);
return -1;
}
video: reduce error message when loading hwdec backend fails When using --hwdec=auto, about half of all systems will print: "[vdpau] Error when calling vdp_device_create_x11: 1" this happens because usually mpv will be linked against both vdpau and vaapi libs, but the drivers are not necessarily available. Then trying to load a driver will fail. This is a normal part of probing, but the error messages were printed anyway. Silence them by explicitly distinguishing probing. This pretty much goes through all the layers. We actually consider loading hw backends for vo_opengl always "auto probed", even if a hw backend is explicitly requested. In this case vd_lavc will print a warning message anyway (adjust this message a bit).
2015-06-20 22:26:57 +02:00
vc->mpvdp = mp_vdpau_create_device_x11(vo->log, vo->x11->display, false);
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) {
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
video: refactor how VO exports hwdec device handles The main change is with video/hwdec.h. mp_hwdec_info is made opaque (and renamed to mp_hwdec_devices). Its accessors are mainly thread-safe (or documented where not), which makes the whole thing saner and cleaner. In particular, thread-safety rules become less subtle and more obvious. The new internal API makes it easier to support multiple OpenGL interop backends. (Although this is not done yet, and it's not clear whether it ever will.) This also removes all the API-specific fields from mp_hwdec_ctx and replaces them with a "ctx" field. For d3d in particular, we drop the mp_d3d_ctx struct completely, and pass the interfaces directly. Remove the emulation checks from vaapi.c and vdpau.c; they are pointless, and the checks that matter are done on the VO layer. The d3d hardware decoders might slightly change behavior: dxva2-copy will not use the VO device anymore if the VO supports proper interop. This pretty much assumes that any in such cases the VO will not use any form of exclusive mode, which makes using the VO device in copy mode unnecessary. This is a big refactor. Some things may be untested and could be broken.
2016-05-09 19:42:03 +02:00
vo->hwdec_devs = hwdec_devices_create();
hwdec_devices_add(vo->hwdec_devs, &vc->mpvdp->hwctx);
video: don't keep multiple pointers to hwdec info struct This makes a certain corner case simpler at a later point.
2014-08-11 23:08:35 +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);
video: warn if an emulated hwdec API is used mpv supports two hardware decoding APIs on Linux: vdpau and vaapi. Each of these has emulation wrappers. The wrappers are usually slower and have fewer features than their native opposites. In particular the libva vdpau driver is practically unmaintained. Check the vendor string and print a warning if emulation is detected. Checking vendor strings is a very stupid thing to do, but I find the thought of people using an emulated API for no reason worse. Also, make --hwdec=auto never use an API that is detected as emulated. This doesn't work quite right yet, because once one API is loaded, vo_opengl doesn't unload it, so no hardware decoding will be used if the first probed API (usually vdpau) is rejected. But good enough.
2014-05-28 01:37:53 +02:00
if (mp_vdpau_guess_if_emulated(vc->mpvdp)) {
MP_WARN(vo, "VDPAU is most likely emulated via VA-API.\n"
"This is inefficient. Use --vo=opengl instead.\n");
}
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
vo_vdpau, vo_opengl: handle vdpau preemption differently Use the newly provided mp_vdpau_handle_preemption() function, instead of accessing mp_vdpau_ctx fields directly. Will probably make multithreaded access to the vdpau context easier. Mostly unrelated to the actual changes, I've noticed that using hw decoding with vo_opengl sometimes leads to segfaults inside of nvidia's libGL when doing the following: 1. use hw decoding + vo_opengl 2. switch to console (will preempt on nvidia systems) 3. switch back to X (mpv will recover, switches to sw decoding) 4. enable hw decoding again 5. exit mpv Then it segfaults when mpv finally calls exit(). I'll just blame nvidia, although it seems likely that something in the gl_hwdec_vdpau.c preemption handling triggers corner cases in nvidia's code.
2014-05-09 21:49:32 +02:00
mp_vdpau_handle_preemption(vc->mpvdp, &vc->preemption_counter);
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->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
vo_vdpau: check VDP_RGBA_FORMAT_A8 support Apparently not all vdpau drivers in the wild support this format (VDPAU SUNXI can't). Revert to RGB in these cases.
2015-11-04 21:47:20 +01:00
vc->vdp->bitmap_surface_query_capabilities(vc->vdp_device, VDP_RGBA_FORMAT_A8,
&vc->supports_a8, &(uint32_t){0}, &(uint32_t){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
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
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, vo_opengl: handle vdpau preemption differently Use the newly provided mp_vdpau_handle_preemption() function, instead of accessing mp_vdpau_ctx fields directly. Will probably make multithreaded access to the vdpau context easier. Mostly unrelated to the actual changes, I've noticed that using hw decoding with vo_opengl sometimes leads to segfaults inside of nvidia's libGL when doing the following: 1. use hw decoding + vo_opengl 2. switch to console (will preempt on nvidia systems) 3. switch back to X (mpv will recover, switches to sw decoding) 4. enable hw decoding again 5. exit mpv Then it segfaults when mpv finally calls exit(). I'll just blame nvidia, although it seems likely that something in the gl_hwdec_vdpau.c preemption handling triggers corner cases in nvidia's code.
2014-05-09 21:49:32 +02:00
check_preemption(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
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_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);
}
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;
video: separate screenshot modes Use different VOCTRLs for "window" and normal screenshot modes. The normal one will probably be removed, and replaced by generic code in vo.c, and this commit is preparation for this. (Doing it the other way around would be slightly simpler, but I haven't decided yet about the second one, and touching every VO is needed anyway in order to remove the unneeded crap. E.g. has_osd has been unused for a long time.)
2015-01-23 22:06:12 +01:00
case VOCTRL_SCREENSHOT_WIN:
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: simplify VOs by adding generic screenshot support At the time screenshot support was added, images weren't refcounted yet, so screenshots required specialized implementations in the VOs. But now we can handle these things much simpler. Also see commit 5bb24980. If there are VOs in the future which can't do this (e.g. they need to write to the image passed to vo_driver->draw_image), this still could be disabled on a per-VO basis etc., so we lose no potential performance advantages.
2015-01-24 22:56:02 +01:00
*(struct mp_image **)data = get_window_screenshot(vo);
vo_vdpau: implement screenshots
2011-10-06 20:46:01 +02:00
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;
}
command: make window-scale property observable Add a generic mechanism to the VO to relay "extra" events from VO to player. Use it to notify the core of window resizes, which in turn will be used to mark all affected properties ("window-scale" in this case) as changed. (I refrained from hacking this as internal command into input_ctx, or to poll the state change, etc. - but in the end, maybe it would be best to actually pass the client API context directly to the places where events can happen.)
2014-11-02 20:26:51 +01:00
vo_event(vo, events);
x11: use vo_x11_control() for all VOs
2013-05-16 14:02:28 +02:00
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: Implement rotation support VDPAU has explicit support for rotating surfaces, and it is far less expensive than using the normal rotation filter (which would require reading video frames back into system memory), it is desirable to implement the VO rotation capability. To do this, we need to render the video frames to an output surface, without rotation, and then render from that surface to the final output surface to apply the rotation. It is important that the intermediate surface is the same size as the final one (only not rotated) so that hqscaling can be applied if requested by the user. (hqscaling is a mixer capability and so takes effect when the video surface is rendered to an output surface) Finally, we must remember to explicitly clear the final output surface as VDPAU only auto-clears output surfaces when rendering video surfaces.
2015-07-11 05:42:22 +02:00
.caps = VO_CAP_FRAMEDROP | VO_CAP_ROTATE90,
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,
vo: change internal API for drawing frames draw_image_timed is renamed to draw_frame. struct frame_timing is renamed to vo_frame. flip_page_timed is merged into draw_frame (the additional parameters are part of struct vo_frame). draw_frame also deprecates VOCTRL_REDRAW_FRAME, and replaces it with a method that works for both VOs which can cache the current frame, and VOs which need to redraw it anyway. This is preparation to making the interpolation and (work in progress) display sync code saner. Lots of other refactoring, and also some simplifications.
2015-07-01 19:24:28 +02:00
.draw_frame = draw_frame,
.flip_page = flip_page,
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