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
73a5417950
mpv/video/out/vo_vdpau.c

1540 lines
55 KiB
C
Raw Normal View History

Add support for VDPAU video out, including hardware decoding. git-svn-id: svn://svn.mplayerhq.hu/mplayer/trunk@28617 b3059339-0415-0410-9bf9-f77b7e298cf2
2009-02-16 21:58:13 +01:00
/*
* VDPAU video output driver
*
video/out: remove useless info struct and redundant fields The author and comment fields were printed only in -v mode.
2013-10-23 19:06:14 +02:00
* Copyright (C) 2008 NVIDIA (Rajib Mahapatra <rmahapatra@nvidia.com>)
Implement vsync-aware frame timing for VDPAU Main things added are custom frame dropping for VDPAU to work around the display FPS limit, frame timing adjustment to avoid jitter when video frame times keep falling near vsyncs, and use of VDPAU's timing feature to keep one future frame queued in advance. NVIDIA's VDPAU implementation refuses to change the displayed frame more than once per vsync. This set a limit on how much video could be sped up, and caused problems for nearly all videos on low-FPS video projectors (playing 24 FPS video on a 24 FPS projector would not work reliably as MPlayer may need to slightly speed up the video for AV sync). This commit adds a framedrop mechanism that drops some frames so that no more than one is sent for display per vsync. The code tries to select the dropped frames smartly, selecting the best one to show for each vsync. Because of the timing features needed the drop functionality currently does not work if the correct-pts option is disabled. The code also adjusts frame timing slightly to avoid jitter. If you for example play 24 FPS video content on a 72 FPS display then normally a frame would be shown for 3 vsyncs, but if the frame times happen to fall near vsyncs and change between just before and just after then there could be frames alternating between 2 and 4 vsyncs. The code changes frame timing by up to one quarter vsync interval to avoid this. The above functionality depends on having reliable vsync timing information available. The display refresh rate is not directly provided by the VDPAU API. The current code uses information from the XF86VidMode extension if available; I'm not sure how common cases where that is inaccurate are. The refresh rate can be specified manually if necessary. After the changes in this commit MPlayer now always tries to keep one frame queued for future display using VDPAU's internal timing mechanism (however no more than 50 ms to the future). This should make video playback somewhat more robust against timing inaccuracies caused by system load.
2009-11-15 03:39:22 +01:00
* Copyright (C) 2009 Uoti Urpala
Add support for VDPAU video out, including hardware decoding. git-svn-id: svn://svn.mplayerhq.hu/mplayer/trunk@28617 b3059339-0415-0410-9bf9-f77b7e298cf2
2009-02-16 21:58:13 +01:00
*
* This file is part of MPlayer.
*
* MPlayer is free software; you can redistribute it and/or modify
* it under the terms of the GNU General Public License as published by
* the Free Software Foundation; either version 2 of the License, or
* (at your option) any later version.
*
* MPlayer is distributed in the hope that it will be useful,
* but WITHOUT ANY WARRANTY; without even the implied warranty of
* MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
* GNU General Public License for more details.
*
* You should have received a copy of the GNU General Public License along
* with MPlayer; if not, write to the Free Software Foundation, Inc.,
* 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301 USA.
*/
vo_vdpau.c: cosmetics
2009-05-09 17:08:30 +02:00
/*
vdpau: split off decoder parts, use "new" libavcodec vdpau hwaccel API Move the decoder parts from vo_vdpau.c to a new file vdpau_old.c. This file is named so because because it's written against the "old" libavcodec vdpau pseudo-decoder (e.g. "h264_vdpau"). Add support for the "new" libavcodec vdpau support. This was recently added and replaces the "old" vdpau parts. (In fact, Libav is about to deprecate and remove the "old" API without deprecation grace period, so we have to support it now. Moreover, there will probably be no Libav release which supports both, so the transition is even less smooth than we could hope, and we have to support both the old and new API.) Whether the old or new API is used is checked by a configure test: if the new API is found, it is used, otherwise the old API is assumed. Some details might be handled differently. Especially display preemption is a bit problematic with the "new" libavcodec vdpau support: it wants to keep a pointer to a specific vdpau API function (which can be driver specific, because preemption might switch drivers). Also, surface IDs are now directly stored in AVFrames (and mp_images), so they can't be forced to VDP_INVALID_HANDLE on preemption. (This changes even with older libavcodec versions, because mp_image always uses the newer representation to make vo_vdpau.c simpler.) Decoder initialization in the new code tries to deal with codec profiles, while the old code always uses the highest profile per codec. Surface allocation changes. Since the decoder won't call config() in vo_vdpau.c on video size change anymore, we allow allocating surfaces of arbitrary size instead of locking it to what the VO was configured. The non-hwdec code also has slightly different allocation behavior now. Enabling the old vdpau special decoders via e.g. --vd=lavc:h264_vdpau doesn't work anymore (a warning suggesting the --hwdec option is printed instead).
2013-07-28 01:49:45 +02:00
* Actual decoding is done in video/decode/vdpau.c
Add support for VDPAU video out, including hardware decoding. git-svn-id: svn://svn.mplayerhq.hu/mplayer/trunk@28617 b3059339-0415-0410-9bf9-f77b7e298cf2
2009-02-16 21:58:13 +01:00
*/
#include <stdio.h>
core/VO: Allow VO drivers to add/modify frames Add interfaces to allow VO drivers to add or remove frames from the video stream and to alter timestamps. Currently this functionality only works with in correct-pts mode. Use the new functionality in vo_vdpau to properly support frame-adding deinterlace modes. Frames added by the VDPAU deinterlacing code are now properly timed. Before every second frame was always shown immediately (probably next monitor refresh) after the previous one, even if you were watching things in slow motion, and framestepping didn't stop at them at all. When seeking the deinterlace algorithm is no longer fed a mix of frames from old and new positions. As a side effect of the changes a problem with resize events was also fixed. Resizing calls video_to_output_surface() to render the frame at the new resolution, but before this function also changed the list of history frames, so resizing could give an image different from the original one, and also corrupt next frames due to them seeing the wrong history. Now the function has no such side effects. There are more resize-related problems though that will be fixed in a later commit. The deint_mpi[] list of reserved frames is increased from 2 to 3 entries for reasons related to the above. Having 2 entries is enough when you initially get a new frame in draw_image() because then you'll have those two entries plus the new one for a total of 3 (the code relied on the oldest mpi implicitly staying reserved for the duration of the call even after usage count was decreased). However if you want to be able to reproduce the rendering outside draw_image(), relying on the explicitly reserved list only, then it needs to store 3 entries.
2009-09-18 15:27:55 +02:00
#include <stdlib.h>
vo_vdpau: Move all remaining static/global variables to context
2009-05-06 22:49:51 +02:00
#include <stdint.h>
#include <stdbool.h>
Implement vsync-aware frame timing for VDPAU Main things added are custom frame dropping for VDPAU to work around the display FPS limit, frame timing adjustment to avoid jitter when video frame times keep falling near vsyncs, and use of VDPAU's timing feature to keep one future frame queued in advance. NVIDIA's VDPAU implementation refuses to change the displayed frame more than once per vsync. This set a limit on how much video could be sped up, and caused problems for nearly all videos on low-FPS video projectors (playing 24 FPS video on a 24 FPS projector would not work reliably as MPlayer may need to slightly speed up the video for AV sync). This commit adds a framedrop mechanism that drops some frames so that no more than one is sent for display per vsync. The code tries to select the dropped frames smartly, selecting the best one to show for each vsync. Because of the timing features needed the drop functionality currently does not work if the correct-pts option is disabled. The code also adjusts frame timing slightly to avoid jitter. If you for example play 24 FPS video content on a 72 FPS display then normally a frame would be shown for 3 vsyncs, but if the frame times happen to fall near vsyncs and change between just before and just after then there could be frames alternating between 2 and 4 vsyncs. The code changes frame timing by up to one quarter vsync interval to avoid this. The above functionality depends on having reliable vsync timing information available. The display refresh rate is not directly provided by the VDPAU API. The current code uses information from the XF86VidMode extension if available; I'm not sure how common cases where that is inaccurate are. The refresh rate can be specified manually if necessary. After the changes in this commit MPlayer now always tries to keep one frame queued for future display using VDPAU's internal timing mechanism (however no more than 50 ms to the future). This should make video playback somewhat more robust against timing inaccuracies caused by system load.
2009-11-15 03:39:22 +01:00
#include <limits.h>
vo_vdpau: split bitmap packing code into a separate file Split the vo_vdpau code that calculates how to pack all subtitle bitmaps into a larger surface into a separate file. This will allow using it in other VOs. Conflicts: Makefile libvo/vo_vdpau.c Note: this commit does the same as an earlier commit by me (4010dd0b1a27e3996). My commit added the vo_vdpau packer code as eosd_packer.c, while this commit by uau uses bitmap_packer.c. Since bitmap_packer.c has a different interface, and because there are more commits changing OSD rendering coming, I will pick uau's version. However, vo_gl, vo_gl3 and vo_direct3d are still using eosd_packer.c, so to make the transition easier, don't delete eosd_packer.c yet.
2012-08-26 18:00:26 +02:00
#include <assert.h>
#include <libavutil/common.h>
Add support for VDPAU video out, including hardware decoding. git-svn-id: svn://svn.mplayerhq.hu/mplayer/trunk@28617 b3059339-0415-0410-9bf9-f77b7e298cf2
2009-02-16 21:58:13 +01:00
#include "config.h"
vdpau: split off decoder parts, use "new" libavcodec vdpau hwaccel API Move the decoder parts from vo_vdpau.c to a new file vdpau_old.c. This file is named so because because it's written against the "old" libavcodec vdpau pseudo-decoder (e.g. "h264_vdpau"). Add support for the "new" libavcodec vdpau support. This was recently added and replaces the "old" vdpau parts. (In fact, Libav is about to deprecate and remove the "old" API without deprecation grace period, so we have to support it now. Moreover, there will probably be no Libav release which supports both, so the transition is even less smooth than we could hope, and we have to support both the old and new API.) Whether the old or new API is used is checked by a configure test: if the new API is found, it is used, otherwise the old API is assumed. Some details might be handled differently. Especially display preemption is a bit problematic with the "new" libavcodec vdpau support: it wants to keep a pointer to a specific vdpau API function (which can be driver specific, because preemption might switch drivers). Also, surface IDs are now directly stored in AVFrames (and mp_images), so they can't be forced to VDP_INVALID_HANDLE on preemption. (This changes even with older libavcodec versions, because mp_image always uses the newer representation to make vo_vdpau.c simpler.) Decoder initialization in the new code tries to deal with codec profiles, while the old code always uses the highest profile per codec. Surface allocation changes. Since the decoder won't call config() in vo_vdpau.c on video size change anymore, we allow allocating surfaces of arbitrary size instead of locking it to what the VO was configured. The non-hwdec code also has slightly different allocation behavior now. Enabling the old vdpau special decoders via e.g. --vd=lavc:h264_vdpau doesn't work anymore (a warning suggesting the --hwdec option is printed instead).
2013-07-28 01:49:45 +02:00
#include "video/vdpau.h"
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"
core: move contents to mpvcore (2/2) Followup commit. Fixes all the files references.
2013-08-06 22:41:30 +02:00
#include "mpvcore/mp_msg.h"
Move options/config related files from mpvcore/ to options/ Since m_option.h and options.h are extremely often included, a lot of files have to be changed. Moving path.c/h to options/ is a bit questionable, but since this is mainly about access to config files (which are also handled in options/), it's probably ok.
2013-12-17 02:02:25 +01:00
#include "options/options.h"
vo_vdpau: Replace global function table with context variable
2009-05-06 20:04:37 +02:00
#include "talloc.h"
Rename directories, move files (step 2 of 2) Finish renaming directories and moving files. Adjust all include statements to make the previous commit compile. The two commits are separate, because git is bad at tracking renames and content changes at the same time. Also take this as an opportunity to remove the separation between "common" and "mplayer" sources in the Makefile. ("common" used to be shared between mplayer and mencoder.)
2012-11-09 01:06:43 +01:00
#include "vo.h"
Add support for VDPAU video out, including hardware decoding. git-svn-id: svn://svn.mplayerhq.hu/mplayer/trunk@28617 b3059339-0415-0410-9bf9-f77b7e298cf2
2009-02-16 21:58:13 +01:00
#include "x11_common.h"
Rename directories, move files (step 2 of 2) Finish renaming directories and moving files. Adjust all include statements to make the previous commit compile. The two commits are separate, because git is bad at tracking renames and content changes at the same time. Also take this as an opportunity to remove the separation between "common" and "mplayer" sources in the Makefile. ("common" used to be shared between mplayer and mencoder.)
2012-11-09 01:06:43 +01:00
#include "video/csputils.h"
Rename sub.c/.h to osd.c/.h This was way too misleading. osd.c merely calls the subtitle renderers, instead of actually dealing with subtitles.
2013-11-24 12:58:06 +01:00
#include "sub/osd.h"
Move options/config related files from mpvcore/ to options/ Since m_option.h and options.h are extremely often included, a lot of files have to be changed. Moving path.c/h to options/ is a bit questionable, but since this is mainly about access to config files (which are also handled in options/), it's probably ok.
2013-12-17 02:02:25 +01:00
#include "options/m_option.h"
Rename directories, move files (step 2 of 2) Finish renaming directories and moving files. Adjust all include statements to make the previous commit compile. The two commits are separate, because git is bad at tracking renames and content changes at the same time. Also take this as an opportunity to remove the separation between "common" and "mplayer" sources in the Makefile. ("common" used to be shared between mplayer and mencoder.)
2012-11-09 01:06:43 +01:00
#include "video/vfcap.h"
#include "video/mp_image.h"
vo_vdpau: Support recovering from VDPAU display preemption Add code to reinitialize all VDPAU objects if a display preemption condition occurs. Reinitializing them in the middle of playback will cause video corruption at least until the next keyframe when using hardware decoding, but decoding does seem to recover after a keyframe.
2009-09-07 01:02:24 +02:00
#include "osdep/timer.h"
vo_vdpau: split bitmap packing code into a separate file Split the vo_vdpau code that calculates how to pack all subtitle bitmaps into a larger surface into a separate file. This will allow using it in other VOs. Conflicts: Makefile libvo/vo_vdpau.c Note: this commit does the same as an earlier commit by me (4010dd0b1a27e3996). My commit added the vo_vdpau packer code as eosd_packer.c, while this commit by uau uses bitmap_packer.c. Since bitmap_packer.c has a different interface, and because there are more commits changing OSD rendering coming, I will pick uau's version. However, vo_gl, vo_gl3 and vo_direct3d are still using eosd_packer.c, so to make the transition easier, don't delete eosd_packer.c yet.
2012-08-26 18:00:26 +02:00
#include "bitmap_packer.h"
EOSD/ASS support for vo_vdpau.c Patch by Grigori G (greg <at> chown ath cx) with minor cosmetic changes by me. git-svn-id: svn://svn.mplayerhq.hu/mplayer/trunk@28710 b3059339-0415-0410-9bf9-f77b7e298cf2
2009-02-23 10:21:57 +01:00
vo_vdpau.c cosmetics: add WRAP_ADD macro The macro is meant to simplify the handling of some code dealing with circular buffers.
2010-05-06 03:46:10 +02:00
#define WRAP_ADD(x, a, m) ((a) < 0 \
? ((x)+(a)+(m) < (m) ? (x)+(a)+(m) : (x)+(a)) \
: ((x)+(a) < (m) ? (x)+(a) : (x)+(a)-(m)))
Add support for VDPAU video out, including hardware decoding. git-svn-id: svn://svn.mplayerhq.hu/mplayer/trunk@28617 b3059339-0415-0410-9bf9-f77b7e298cf2
2009-02-16 21:58:13 +01:00
/* number of video and output surfaces */
vo_vdpau: support queuing an arbitrary number of frames ahead Make the number of output surfaces allocated by vo_vdpau configurable and allow queuing multiple future frames with the VDPAU frame timing functionality. There are two known issues that could be polished in the future for particularly long queue time cases. First, toplevel code should possibly wait for the queued changes to finish displaying in some situations like switching files. Second, the VO can block waiting for a surface to become available, and in the worst case this wait can be almost as long as the maximum queuing time (potentially causing audio underruns). However those issues are not high priority.
2010-05-14 04:18:38 +02:00
#define MAX_OUTPUT_SURFACES 15
vo: do final frame draw only near page flip Separate passing a new frame to VOs using the new API into two steps. The first, vo_draw_image(), happens after a new frame is available from the filter chain. In constrast to old behavior, now the frame is not actually rendered yet at this point (though possible slice draw calls can already reach the VO before). The second step, vo_new_frame_imminent(), happens when we're close enough to the display time of the new frame that we'll commit to flipping it as the next action and will not change the OSD over the previous frame any more. This new behavior fixes a previous problem with vo_vdpau and vo_gl in the situation where the player is paused after decoding a new frame but before flipping it; previously changing OSD in that state would switch to the new frame as a side effect. It would also allow an easy way to fix extra output files produced with something like "--vo=png --frames=1" with precise seeking, but this is not done yet. The code now relies on a new mp_image from the filter chain staying valid even after the vf_vo put_image() call providing it returns. In other words decoders/filters must not deallocate or otherwise invalidate their output frame between passing it forward and returning from the decode/filter call.
2011-12-04 17:10:17 +01:00
#define NUM_BUFFERED_VIDEO 5
Add support for VDPAU video out, including hardware decoding. git-svn-id: svn://svn.mplayerhq.hu/mplayer/trunk@28617 b3059339-0415-0410-9bf9-f77b7e298cf2
2009-02-16 21:58:13 +01:00
vo_vdpau: implement screenshots
2011-10-06 20:46:01 +02:00
/* Pixelformat used for output surfaces */
#define OUTPUT_RGBA_FORMAT VDP_RGBA_FORMAT_B8G8R8A8
Add support for VDPAU video out, including hardware decoding. git-svn-id: svn://svn.mplayerhq.hu/mplayer/trunk@28617 b3059339-0415-0410-9bf9-f77b7e298cf2
2009-02-16 21:58:13 +01:00
/*
* Global variable declaration - VDPAU specific
*/
vo_vdpau: Replace global function table with context variable
2009-05-06 20:04:37 +02:00
struct vdpctx {
vdpau: move device and video surface management from vo_vdpau.c to vdpau.c The goal is being able to use vdpau decoding independently from vo_vdpau.c.
2013-11-05 22:06:32 +01:00
struct mp_vdpau_ctx *mpvdp;
vdpau: split off decoder parts, use "new" libavcodec vdpau hwaccel API Move the decoder parts from vo_vdpau.c to a new file vdpau_old.c. This file is named so because because it's written against the "old" libavcodec vdpau pseudo-decoder (e.g. "h264_vdpau"). Add support for the "new" libavcodec vdpau support. This was recently added and replaces the "old" vdpau parts. (In fact, Libav is about to deprecate and remove the "old" API without deprecation grace period, so we have to support it now. Moreover, there will probably be no Libav release which supports both, so the transition is even less smooth than we could hope, and we have to support both the old and new API.) Whether the old or new API is used is checked by a configure test: if the new API is found, it is used, otherwise the old API is assumed. Some details might be handled differently. Especially display preemption is a bit problematic with the "new" libavcodec vdpau support: it wants to keep a pointer to a specific vdpau API function (which can be driver specific, because preemption might switch drivers). Also, surface IDs are now directly stored in AVFrames (and mp_images), so they can't be forced to VDP_INVALID_HANDLE on preemption. (This changes even with older libavcodec versions, because mp_image always uses the newer representation to make vo_vdpau.c simpler.) Decoder initialization in the new code tries to deal with codec profiles, while the old code always uses the highest profile per codec. Surface allocation changes. Since the decoder won't call config() in vo_vdpau.c on video size change anymore, we allow allocating surfaces of arbitrary size instead of locking it to what the VO was configured. The non-hwdec code also has slightly different allocation behavior now. Enabling the old vdpau special decoders via e.g. --vd=lavc:h264_vdpau doesn't work anymore (a warning suggesting the --hwdec option is printed instead).
2013-07-28 01:49:45 +02:00
struct vdp_functions *vdp;
vo_vdpau: Move things to context struct
2009-05-06 22:42:24 +02:00
VdpDevice vdp_device;
vdpau: move device and video surface management from vo_vdpau.c to vdpau.c The goal is being able to use vdpau decoding independently from vo_vdpau.c.
2013-11-05 22:06:32 +01:00
uint64_t preemption_counter;
vdpau: split off decoder parts, use "new" libavcodec vdpau hwaccel API Move the decoder parts from vo_vdpau.c to a new file vdpau_old.c. This file is named so because because it's written against the "old" libavcodec vdpau pseudo-decoder (e.g. "h264_vdpau"). Add support for the "new" libavcodec vdpau support. This was recently added and replaces the "old" vdpau parts. (In fact, Libav is about to deprecate and remove the "old" API without deprecation grace period, so we have to support it now. Moreover, there will probably be no Libav release which supports both, so the transition is even less smooth than we could hope, and we have to support both the old and new API.) Whether the old or new API is used is checked by a configure test: if the new API is found, it is used, otherwise the old API is assumed. Some details might be handled differently. Especially display preemption is a bit problematic with the "new" libavcodec vdpau support: it wants to keep a pointer to a specific vdpau API function (which can be driver specific, because preemption might switch drivers). Also, surface IDs are now directly stored in AVFrames (and mp_images), so they can't be forced to VDP_INVALID_HANDLE on preemption. (This changes even with older libavcodec versions, because mp_image always uses the newer representation to make vo_vdpau.c simpler.) Decoder initialization in the new code tries to deal with codec profiles, while the old code always uses the highest profile per codec. Surface allocation changes. Since the decoder won't call config() in vo_vdpau.c on video size change anymore, we allow allocating surfaces of arbitrary size instead of locking it to what the VO was configured. The non-hwdec code also has slightly different allocation behavior now. Enabling the old vdpau special decoders via e.g. --vd=lavc:h264_vdpau doesn't work anymore (a warning suggesting the --hwdec option is printed instead).
2013-07-28 01:49:45 +02:00
vo_vdpau: allow setting colorkey Formally, this sets the "background color" of the presentation queue. But in practice, this color is also used as colorkey. This commit doesn't change the VDPAU default yet.
2013-08-17 19:57:18 +02:00
struct m_color colorkey;
vo_vdpau: Move things to context struct
2009-05-06 22:42:24 +02:00
VdpPresentationQueueTarget flip_target;
VdpPresentationQueue flip_queue;
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_vdp_time;
Replace all calls to GetTimer()/GetTimerMS() GetTimer() is generally replaced with mp_time_us(). Both calls return microseconds, but the latter uses int64_t, us defined to never wrap, and never returns 0 or negative values. GetTimerMS() has no direct replacement. Instead the other functions are used. For some code, switch to mp_time_sec(), which returns the time as double float value in seconds. The returned time is offset to program start time, so there is enough precision left to deliver microsecond resolution for at least 100 years. Unless it's casted to a float (or the CPU reduces precision), which is why we still use mp_time_us() out of paranoia in places where precision is clearly needed. Always switch to the correct time. The whole point of the new timer calls is that they don't wrap, and storing microseconds in unsigned int variables would negate this. In some cases, remove wrap-around handling for time values.
2013-05-25 18:31:06 +02:00
uint64_t last_sync_update;
vo_vdpau: Move things to context struct
2009-05-06 22:42:24 +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
VdpOutputSurface output_surfaces[MAX_OUTPUT_SURFACES];
vo_vdpau: fix screenshots Attempting to take screenshots printed vdpau errors on the terminal, and the resulting screenshots were filled with black. The problem was that that the screenshot code tried to use an unallocated output surface (the one at vc->output_surfaces[vc->num_output_surfaces]). This used to refer to the last allocated surface, until this was changed by a recently merged commit. That commit also added a separate screenshot surface. The merge somehow went wrong, and that part was not integrated. <uau> wm4: you used an earlier buggy version of a commit OK...
2012-10-21 00:48:01 +02:00
VdpOutputSurface screenshot_surface;
vo_vdpau: support queuing an arbitrary number of frames ahead Make the number of output surfaces allocated by vo_vdpau configurable and allow queuing multiple future frames with the VDPAU frame timing functionality. There are two known issues that could be polished in the future for particularly long queue time cases. First, toplevel code should possibly wait for the queued changes to finish displaying in some situations like switching files. Second, the VO can block waiting for a surface to become available, and in the worst case this wait can be almost as long as the maximum queuing time (potentially causing audio underruns). However those issues are not high priority.
2010-05-14 04:18:38 +02:00
int num_output_surfaces;
vo_vdpau: add RGB support Apparently this was dropped some years ago, but judging from MPlayer's handling of this, the original code wasn't so great anyway. The new code handling clearing of panscan borders correctly, and integrates better with the YUV path. (Although the VDPAU API sure makes this annoying with its separate surface types for RGB.) Note that we create 5 surfaces for some reason - I don't think this makes too much sense (because we can't use the deinterlacer with RGB surfaces), but at least it reduces the amount of differences with the YUV code path. Clearing the borders is done by drawing a single black pixel over the window. This sounds pretty dumb, but it appears to work well, and there is no other API for that. (One could try to use the video mixer for this purpose, since it has all kinds of features, including compositing multiple RGBA surfaces and clearing the window background. But it would require an invisible dummy video surface to make the video mixer happy, and that's getting too messy.)
2013-08-18 05:12:21 +02:00
VdpOutputSurface rgb_surfaces[NUM_BUFFERED_VIDEO];
VdpOutputSurface black_pixel;
vo_vdpau: Modify frame buffering code Clean up code related to frame buffering and generate pts information also for the next frame in the output queue. The timing information will be used in a following framedrop patch. This commit adds one frame of buffering delay in vo_vdpau and increases the number of buffered vdpau video surfaces from 3 to 4. The delay increase makes it more important to fix remaining code in MPlayer that doesn't deal well with filter/VO delay; OTOH it should help any decoding/filtering parallelism in the underlying VDPAU implementation as now filtering a frame for display can happen while the next one is being decoded.
2009-10-14 03:12:10 +02:00
struct buffered_video_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
// Either surface or rgb_surface is used (never both)
vo_vdpau: Modify frame buffering code Clean up code related to frame buffering and generate pts information also for the next frame in the output queue. The timing information will be used in a following framedrop patch. This commit adds one frame of buffering delay in vo_vdpau and increases the number of buffered vdpau video surfaces from 3 to 4. The delay increase makes it more important to fix remaining code in MPlayer that doesn't deal well with filter/VO delay; OTOH it should help any decoding/filtering parallelism in the underlying VDPAU implementation as now filtering a frame for display can happen while the next one is being decoded.
2009-10-14 03:12:10 +02:00
VdpVideoSurface 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
VdpOutputSurface rgb_surface;
vo_vdpau: Modify frame buffering code Clean up code related to frame buffering and generate pts information also for the next frame in the output queue. The timing information will be used in a following framedrop patch. This commit adds one frame of buffering delay in vo_vdpau and increases the number of buffered vdpau video surfaces from 3 to 4. The delay increase makes it more important to fix remaining code in MPlayer that doesn't deal well with filter/VO delay; OTOH it should help any decoding/filtering parallelism in the underlying VDPAU implementation as now filtering a frame for display can happen while the next one is being decoded.
2009-10-14 03:12:10 +02:00
double pts;
mp_image_t *mpi;
} buffered_video[NUM_BUFFERED_VIDEO];
core/VO: Allow VO drivers to add/modify frames Add interfaces to allow VO drivers to add or remove frames from the video stream and to alter timestamps. Currently this functionality only works with in correct-pts mode. Use the new functionality in vo_vdpau to properly support frame-adding deinterlace modes. Frames added by the VDPAU deinterlacing code are now properly timed. Before every second frame was always shown immediately (probably next monitor refresh) after the previous one, even if you were watching things in slow motion, and framestepping didn't stop at them at all. When seeking the deinterlace algorithm is no longer fed a mix of frames from old and new positions. As a side effect of the changes a problem with resize events was also fixed. Resizing calls video_to_output_surface() to render the frame at the new resolution, but before this function also changed the list of history frames, so resizing could give an image different from the original one, and also corrupt next frames due to them seeing the wrong history. Now the function has no such side effects. There are more resize-related problems though that will be fixed in a later commit. The deint_mpi[] list of reserved frames is increased from 2 to 3 entries for reasons related to the above. Having 2 entries is enough when you initially get a new frame in draw_image() because then you'll have those two entries plus the new one for a total of 3 (the code relied on the oldest mpi implicitly staying reserved for the duration of the call even after usage count was decreased). However if you want to be able to reproduce the rendering outside draw_image(), relying on the explicitly reserved list only, then it needs to store 3 entries.
2009-09-18 15:27:55 +02:00
int deint_queue_pos;
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
// State for redrawing the screen after seek-reset
int prev_deint_queue_pos;
vo_vdpau: Move things to context struct
2009-05-06 22:42:24 +02:00
int output_surface_width, output_surface_height;
vo_vdpau: add RGB support Apparently this was dropped some years ago, but judging from MPlayer's handling of this, the original code wasn't so great anyway. The new code handling clearing of panscan borders correctly, and integrates better with the YUV path. (Although the VDPAU API sure makes this annoying with its separate surface types for RGB.) Note that we create 5 surfaces for some reason - I don't think this makes too much sense (because we can't use the deinterlacer with RGB surfaces), but at least it reduces the amount of differences with the YUV code path. Clearing the borders is done by drawing a single black pixel over the window. This sounds pretty dumb, but it appears to work well, and there is no other API for that. (One could try to use the video mixer for this purpose, since it has all kinds of features, including compositing multiple RGBA surfaces and clearing the window background. But it would require an invisible dummy video surface to make the video mixer happy, and that's getting too messy.)
2013-08-18 05:12:21 +02:00
int force_yuv;
vo_vdpau: Move things to context struct
2009-05-06 22:42:24 +02:00
VdpVideoMixer video_mixer;
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_details colorspace;
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 user_deint;
vo_vdpau: Move things to context struct
2009-05-06 22:42:24 +02:00
int deint;
int deint_type;
int pullup;
float denoise;
float sharpen;
vo_vdpau: Add support for high-quality scaling feature Part of the code is currently under #ifdef to allow compilation with older VDPAU library versions; that can be removed later. Partially based on a patch by Carl Eugen Hoyos.
2009-11-15 17:39:48 +01:00
int hqscaling;
vo_vdpau: Move things to context struct
2009-05-06 22:42:24 +02:00
int chroma_deint;
vo_vdpau: make queuing future frame flips adjustable Add -vo vdpau suboptions "queuetime_windowed" and "queuetime_fs" to specify the maximum number of milliseconds how far into the future a frame flip can be queued using the VDPAU presentation queue functionality. The intended main use of these options is to allow disabling use of the queuing feature on systems where using it causes choppiness in other graphics behavior (this is an NVIDIA driver issue; the video itself isn't affected).
2010-02-05 19:13:33 +01:00
int flip_offset_window;
int flip_offset_fs;
vo_vdpau: Move things to context struct
2009-05-06 22:42:24 +02:00
int top_field_first;
vo_vdpau: add support for VFCAP_FLIP Patch by Carl Eugen Hoyos.
2009-11-15 14:50:28 +01:00
bool flip;
vo_vdpau: Move things to context struct
2009-05-06 22:42:24 +02:00
VdpRect src_rect_vid;
VdpRect out_rect_vid;
VO: remove code duplication for setting up mp_osd_res vo_opengl, vo_vdpau, vo_direct3d had the code for setting up mp_osd_res duplicated. Make things simpler by making calc_src_dst_rects() setup the full mp_osd_res structure, instead of just "borders". Also, rename that function to vo_get_src_dst_rects(), and make it use mp_rect. Remove vo_rect, which was annoying because it contains redundant members (width/height additional to right/bottom). Add code to print the video rect etc. in verbose mode. There should be no actual change how the video rects are calculated. The only exception are the bottom/right subtitle margins, which are now computed slightly differently, but that shouldn't matter.
2012-10-27 22:10:32 +02:00
struct mp_osd_res osd_rect;
vo_vdpau: Move things to context struct
2009-05-06 22:42:24 +02:00
video/filter: change filter API, use refcounting, remove filter DR Change the entire filter API to use reference counted images instead of vf_get_image(). Remove filter "direct rendering". This was useful for vf_expand and (in rare cases) vf_sub: DR allowed these filters to pass a cropped image to the filters before them. Then, on filtering, the image was "uncropped", so that black bars could be added around the image without copying. This means that in some cases, vf_expand will be slower (-vf gradfun,expand for example). Note that another form of DR used for in-place filters has been replaced by simpler logic. Instead of trying to do DR, filters can check if the image is writeable (with mp_image_is_writeable()), and do true in-place if that's the case. This affects filters like vf_gradfun and vf_sub. Everything has to support strides now. If something doesn't, making a copy of the image data is required.
2012-11-05 14:25:04 +01:00
int surface_num; // indexes output_surfaces
vo_vdpau: support queuing an arbitrary number of frames ahead Make the number of output surfaces allocated by vo_vdpau configurable and allow queuing multiple future frames with the VDPAU frame timing functionality. There are two known issues that could be polished in the future for particularly long queue time cases. First, toplevel code should possibly wait for the queued changes to finish displaying in some situations like switching files. Second, the VO can block waiting for a surface to become available, and in the worst case this wait can be almost as long as the maximum queuing time (potentially causing audio underruns). However those issues are not high priority.
2010-05-14 04:18:38 +02:00
int query_surface_num;
Implement vsync-aware frame timing for VDPAU Main things added are custom frame dropping for VDPAU to work around the display FPS limit, frame timing adjustment to avoid jitter when video frame times keep falling near vsyncs, and use of VDPAU's timing feature to keep one future frame queued in advance. NVIDIA's VDPAU implementation refuses to change the displayed frame more than once per vsync. This set a limit on how much video could be sped up, and caused problems for nearly all videos on low-FPS video projectors (playing 24 FPS video on a 24 FPS projector would not work reliably as MPlayer may need to slightly speed up the video for AV sync). This commit adds a framedrop mechanism that drops some frames so that no more than one is sent for display per vsync. The code tries to select the dropped frames smartly, selecting the best one to show for each vsync. Because of the timing features needed the drop functionality currently does not work if the correct-pts option is disabled. The code also adjusts frame timing slightly to avoid jitter. If you for example play 24 FPS video content on a 72 FPS display then normally a frame would be shown for 3 vsyncs, but if the frame times happen to fall near vsyncs and change between just before and just after then there could be frames alternating between 2 and 4 vsyncs. The code changes frame timing by up to one quarter vsync interval to avoid this. The above functionality depends on having reliable vsync timing information available. The display refresh rate is not directly provided by the VDPAU API. The current code uses information from the XF86VidMode extension if available; I'm not sure how common cases where that is inaccurate are. The refresh rate can be specified manually if necessary. After the changes in this commit MPlayer now always tries to keep one frame queued for future display using VDPAU's internal timing mechanism (however no more than 50 ms to the future). This should make video playback somewhat more robust against timing inaccuracies caused by system load.
2009-11-15 03:39:22 +01:00
VdpTime recent_vsync_time;
float user_fps;
vo_vdpau: disable refresh-aware frame timing when composited Under a compositing window manager the current VDPAU implementation behaves differently than without it. Frame flip timing info becomes incorrect (I guess it only reflects when the frame was sent to the compositor, not when it was actually shown), and there is no limitation to at most one frame switch per refresh like without compositing. Detect whether a compositing window manager is active and disable refresh-aware frame timing and dropping in this case, similarly to what fps=-1 would do. This behavior can be controlled with the new suboption "composite-detect". Disabling the refresh-aware logic makes timing somewhat less accurate. Because the video switch rate limit isn't there, the lack of frame dropping on player side does not impose a hard limit on video FPS, but does reduce performance somewhat as redundant frames are drawn in memory. The existence of a compositing window manager does not guarantee that the current window is actually composited, so the current check is not foolproof. In particular, some WMs have support for a "unredirect fullscreen windows" option. Support for such things could be improved.
2012-07-27 02:40:38 +02:00
int composite_detect;
Implement vsync-aware frame timing for VDPAU Main things added are custom frame dropping for VDPAU to work around the display FPS limit, frame timing adjustment to avoid jitter when video frame times keep falling near vsyncs, and use of VDPAU's timing feature to keep one future frame queued in advance. NVIDIA's VDPAU implementation refuses to change the displayed frame more than once per vsync. This set a limit on how much video could be sped up, and caused problems for nearly all videos on low-FPS video projectors (playing 24 FPS video on a 24 FPS projector would not work reliably as MPlayer may need to slightly speed up the video for AV sync). This commit adds a framedrop mechanism that drops some frames so that no more than one is sent for display per vsync. The code tries to select the dropped frames smartly, selecting the best one to show for each vsync. Because of the timing features needed the drop functionality currently does not work if the correct-pts option is disabled. The code also adjusts frame timing slightly to avoid jitter. If you for example play 24 FPS video content on a 72 FPS display then normally a frame would be shown for 3 vsyncs, but if the frame times happen to fall near vsyncs and change between just before and just after then there could be frames alternating between 2 and 4 vsyncs. The code changes frame timing by up to one quarter vsync interval to avoid this. The above functionality depends on having reliable vsync timing information available. The display refresh rate is not directly provided by the VDPAU API. The current code uses information from the XF86VidMode extension if available; I'm not sure how common cases where that is inaccurate are. The refresh rate can be specified manually if necessary. After the changes in this commit MPlayer now always tries to keep one frame queued for future display using VDPAU's internal timing mechanism (however no more than 50 ms to the future). This should make video playback somewhat more robust against timing inaccuracies caused by system load.
2009-11-15 03:39:22 +01:00
unsigned int vsync_interval;
uint64_t last_queue_time;
vo_vdpau: support queuing an arbitrary number of frames ahead Make the number of output surfaces allocated by vo_vdpau configurable and allow queuing multiple future frames with the VDPAU frame timing functionality. There are two known issues that could be polished in the future for particularly long queue time cases. First, toplevel code should possibly wait for the queued changes to finish displaying in some situations like switching files. Second, the VO can block waiting for a surface to become available, and in the worst case this wait can be almost as long as the maximum queuing time (potentially causing audio underruns). However those issues are not high priority.
2010-05-14 04:18:38 +02:00
uint64_t queue_time[MAX_OUTPUT_SURFACES];
Implement vsync-aware frame timing for VDPAU Main things added are custom frame dropping for VDPAU to work around the display FPS limit, frame timing adjustment to avoid jitter when video frame times keep falling near vsyncs, and use of VDPAU's timing feature to keep one future frame queued in advance. NVIDIA's VDPAU implementation refuses to change the displayed frame more than once per vsync. This set a limit on how much video could be sped up, and caused problems for nearly all videos on low-FPS video projectors (playing 24 FPS video on a 24 FPS projector would not work reliably as MPlayer may need to slightly speed up the video for AV sync). This commit adds a framedrop mechanism that drops some frames so that no more than one is sent for display per vsync. The code tries to select the dropped frames smartly, selecting the best one to show for each vsync. Because of the timing features needed the drop functionality currently does not work if the correct-pts option is disabled. The code also adjusts frame timing slightly to avoid jitter. If you for example play 24 FPS video content on a 72 FPS display then normally a frame would be shown for 3 vsyncs, but if the frame times happen to fall near vsyncs and change between just before and just after then there could be frames alternating between 2 and 4 vsyncs. The code changes frame timing by up to one quarter vsync interval to avoid this. The above functionality depends on having reliable vsync timing information available. The display refresh rate is not directly provided by the VDPAU API. The current code uses information from the XF86VidMode extension if available; I'm not sure how common cases where that is inaccurate are. The refresh rate can be specified manually if necessary. After the changes in this commit MPlayer now always tries to keep one frame queued for future display using VDPAU's internal timing mechanism (however no more than 50 ms to the future). This should make video playback somewhat more robust against timing inaccuracies caused by system load.
2009-11-15 03:39:22 +01:00
uint64_t last_ideal_time;
bool dropped_frame;
uint64_t dropped_time;
vo_vdpau: Move things to context struct
2009-05-06 22:42:24 +02:00
uint32_t vid_width, vid_height;
uint32_t image_format;
VdpChromaType vdp_chroma_type;
VdpYCbCrFormat vdp_pixel_format;
vo_vdpau: add RGB support Apparently this was dropped some years ago, but judging from MPlayer's handling of this, the original code wasn't so great anyway. The new code handling clearing of panscan borders correctly, and integrates better with the YUV path. (Although the VDPAU API sure makes this annoying with its separate surface types for RGB.) Note that we create 5 surfaces for some reason - I don't think this makes too much sense (because we can't use the deinterlacer with RGB surfaces), but at least it reduces the amount of differences with the YUV code path. Clearing the borders is done by drawing a single black pixel over the window. This sounds pretty dumb, but it appears to work well, and there is no other API for that. (One could try to use the video mixer for this purpose, since it has all kinds of features, including compositing multiple RGBA surfaces and clearing the window background. But it would require an invisible dummy video surface to make the video mixer happy, and that's getting too messy.)
2013-08-18 05:12:21 +02:00
bool rgb_mode;
vo_vdpau: Move things to context struct
2009-05-06 22:42:24 +02:00
VO, sub: refactor Remove VFCTRL_DRAW_OSD, VFCAP_EOSD_FILTER, VFCAP_EOSD_RGBA, VFCAP_EOSD, VOCTRL_DRAW_EOSD, VOCTRL_GET_EOSD_RES, VOCTRL_QUERY_EOSD_FORMAT. Remove draw_osd_with_eosd(), which rendered the OSD by calling VOCTRL_DRAW_EOSD. Change VOs to call osd_draw() directly, which takes a callback as argument. (This basically works like the old OSD API, except multiple OSD bitmap formats are supported and caching is possible.) Remove all mentions of "eosd". It's simply "osd" now. Make OSD size per-OSD-object, as they can be different when using vf_sub. Include display_par/video_par in resolution change detection. Fix the issue with margin borders in vo_corevideo.
2012-10-19 19:25:18 +02:00
// OSD
struct osd_bitmap_surface {
subs, vo_vdpau: support RGBA color for PGS subtitles Support passing bitmap subtitles to VOs in full RGBA color, and implement this for libavcodec-decoded subtitle formats on decoding side and vo_vdpau on display side. Currently this is enabled for PGS (blu-ray) and DVB subtitles. VDPAU seems to have sampling issues similar to known GL ones when drawing a sub-rectangle from a larger texture with scaling, where adjacent pixels outside the specified source rectangle affect the result. As the bitmap subtitles may be scaled, add padding support to the bitmap packer code. In principle, this could be used for colored DVD subtitles too. However, the libavcodec DVD decoder lacks parts of the resolution and palette handling that are present in spudec.c. Conflicts: libvo/vo_gl.c sub/dec_sub.h sub/sd_lavc.c
2012-08-31 14:42:30 +02:00
VdpRGBAFormat format;
vo_vdpau: split bitmap packing code into a separate file Split the vo_vdpau code that calculates how to pack all subtitle bitmaps into a larger surface into a separate file. This will allow using it in other VOs. Conflicts: Makefile libvo/vo_vdpau.c Note: this commit does the same as an earlier commit by me (4010dd0b1a27e3996). My commit added the vo_vdpau packer code as eosd_packer.c, while this commit by uau uses bitmap_packer.c. Since bitmap_packer.c has a different interface, and because there are more commits changing OSD rendering coming, I will pick uau's version. However, vo_gl, vo_gl3 and vo_direct3d are still using eosd_packer.c, so to make the transition easier, don't delete eosd_packer.c yet.
2012-08-26 18:00:26 +02:00
VdpBitmapSurface surface;
uint32_t max_width;
uint32_t max_height;
struct bitmap_packer *packer;
vo_vdpau: use new EOSD for OSD, remove support for old OSD format This allows vo_vdpau to render OSD directly, without the indirection through the old OSD API, and without the additional conversions. Remove support for the old OSD format. Only the mplayer DVD subtitle decoder still generates this format. Although the new OSD interface does support this format, remove it from vo_vdpau. It would be relatively hard to support it in the EOSD code, as it requires two surfaces. (These two surfaces are blended on top of each other to emulate the mplayer OSD format.) The correct way to implement direct support for DVD subs would consist of adding a paletted image format of some sort. But even sd_lavc converts paletted subtitle images to RGBA, so doing something special just for DVD subs is not worth it. This means the frontend (sub.c) converts the subtitles to RGBA if it detects that vo_vdpau does not support them natively.
2012-09-28 21:49:32 +02:00
// List of surfaces to be rendered
VO, sub: refactor Remove VFCTRL_DRAW_OSD, VFCAP_EOSD_FILTER, VFCAP_EOSD_RGBA, VFCAP_EOSD, VOCTRL_DRAW_EOSD, VOCTRL_GET_EOSD_RES, VOCTRL_QUERY_EOSD_FORMAT. Remove draw_osd_with_eosd(), which rendered the OSD by calling VOCTRL_DRAW_EOSD. Change VOs to call osd_draw() directly, which takes a callback as argument. (This basically works like the old OSD API, except multiple OSD bitmap formats are supported and caching is possible.) Remove all mentions of "eosd". It's simply "osd" now. Make OSD size per-OSD-object, as they can be different when using vf_sub. Include display_par/video_par in resolution change detection. Fix the issue with margin borders in vo_corevideo.
2012-10-19 19:25:18 +02:00
struct osd_target {
vo_vdpau: use new EOSD for OSD, remove support for old OSD format This allows vo_vdpau to render OSD directly, without the indirection through the old OSD API, and without the additional conversions. Remove support for the old OSD format. Only the mplayer DVD subtitle decoder still generates this format. Although the new OSD interface does support this format, remove it from vo_vdpau. It would be relatively hard to support it in the EOSD code, as it requires two surfaces. (These two surfaces are blended on top of each other to emulate the mplayer OSD format.) The correct way to implement direct support for DVD subs would consist of adding a paletted image format of some sort. But even sd_lavc converts paletted subtitle images to RGBA, so doing something special just for DVD subs is not worth it. This means the frontend (sub.c) converts the subtitles to RGBA if it detects that vo_vdpau does not support them natively.
2012-09-28 21:49:32 +02:00
VdpRect source;
VdpRect dest;
VdpColor color;
} *targets;
vo_vdpau: allow multiple EOSD renderers Preparation for using new OSD rendering method.
2012-09-28 21:49:09 +02:00
int targets_size;
int render_count;
int bitmap_id;
int bitmap_pos_id;
VO, sub: refactor Remove VFCTRL_DRAW_OSD, VFCAP_EOSD_FILTER, VFCAP_EOSD_RGBA, VFCAP_EOSD, VOCTRL_DRAW_EOSD, VOCTRL_GET_EOSD_RES, VOCTRL_QUERY_EOSD_FORMAT. Remove draw_osd_with_eosd(), which rendered the OSD by calling VOCTRL_DRAW_EOSD. Change VOs to call osd_draw() directly, which takes a callback as argument. (This basically works like the old OSD API, except multiple OSD bitmap formats are supported and caching is possible.) Remove all mentions of "eosd". It's simply "osd" now. Make OSD size per-OSD-object, as they can be different when using vf_sub. Include display_par/video_par in resolution change detection. Fix the issue with margin borders in vo_corevideo.
2012-10-19 19:25:18 +02:00
} osd_surfaces[MAX_OSD_PARTS];
vo_vdpau: Move all remaining static/global variables to context
2009-05-06 22:49:51 +02:00
// Video equalizer
video, options: implement better YUV->RGB conversion control Rewrite control of the colorspace and input/output level parameters used in YUV-RGB conversions, replacing VO-specific suboptions with new common options and adding configuration support to more cases. Add new option --colormatrix which selects the colorspace the original video is assumed to have in YUV->RGB conversions. The default behavior changes from assuming BT.601 to colorspace autoselection between BT.601 and BT.709 using a simple heuristic based on video size. Add new options --colormatrix-input-range and --colormatrix-output-range which select input YUV and output RGB range. Disable the previously existing VO-specific colorspace and level conversion suboptions in vo_gl and vo_vdpau. Remove the "yuv_colorspace" property and replace it with one named "colormatrix" and semantics matching the new option. Add new properties matching the options for level conversion. Colorspace selection is currently supported by vo_gl, vo_vdpau, vo_xv and vf_scale, and all can change it at runtime (previously only vo_vdpau and vo_xv could). vo_vdpau now uses the same conversion matrix generation as vo_gl instead of libvdpau functionality; the main functional difference is that the "contrast" equalizer control behaves somewhat differently (it scales the Y component around 1/2 instead of around 0, so that contrast 0 makes the image gray rather than black). vo_xv does not support level conversion. vf_scale supports range setting for input, but always outputs full-range RGB. The value of the slave properties is the policy setting used for conversions. This means they can be set to any value regardless of whether the current VO supports that value or whether there currently even is any video. Possibly separate properties could be added to query the conversion actually used at the moment, if any. Because the colorspace and level settings are now set with a single VF/VO control call, the return value of that is no longer used to signal whether all the settings are actually supported. Instead code should set all the details it can support, and ignore the rest. The core will use GET_YUV_COLORSPACE to check which colorspace details have been set and which not. In other words, the return value for SET_YUV_COLORSPACE only signals whether any kind of YUV colorspace conversion handling exists at all, and VOs have to take care to return the actual state with GET_YUV_COLORSPACE instead. To be changed in later commits: add missing option documentation.
2011-10-15 23:50:21 +02:00
struct mp_csp_equalizer video_eq;
vo_vdpau: Move all remaining static/global variables to context
2009-05-06 22:49:51 +02:00
};
Add support for VDPAU video out, including hardware decoding. git-svn-id: svn://svn.mplayerhq.hu/mplayer/trunk@28617 b3059339-0415-0410-9bf9-f77b7e298cf2
2009-02-16 21:58:13 +01:00
VO, sub: refactor Remove VFCTRL_DRAW_OSD, VFCAP_EOSD_FILTER, VFCAP_EOSD_RGBA, VFCAP_EOSD, VOCTRL_DRAW_EOSD, VOCTRL_GET_EOSD_RES, VOCTRL_QUERY_EOSD_FORMAT. Remove draw_osd_with_eosd(), which rendered the OSD by calling VOCTRL_DRAW_EOSD. Change VOs to call osd_draw() directly, which takes a callback as argument. (This basically works like the old OSD API, except multiple OSD bitmap formats are supported and caching is possible.) Remove all mentions of "eosd". It's simply "osd" now. Make OSD size per-OSD-object, as they can be different when using vf_sub. Include display_par/video_par in resolution change detection. Fix the issue with margin borders in vo_corevideo.
2012-10-19 19:25:18 +02:00
static bool status_ok(struct vo *vo);
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
static int change_vdptime_sync(struct vo *vo, int64_t *t)
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
{
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
struct vdpctx *vc = vo->priv;
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 vdp_functions *vdp = vc->vdp;
VdpStatus vdp_st;
VdpTime vdp_time;
vdp_st = vdp->presentation_queue_get_time(vc->flip_queue, &vdp_time);
CHECK_ST_ERROR("Error when calling vdp_presentation_queue_get_time");
Replace all calls to GetTimer()/GetTimerMS() GetTimer() is generally replaced with mp_time_us(). Both calls return microseconds, but the latter uses int64_t, us defined to never wrap, and never returns 0 or negative values. GetTimerMS() has no direct replacement. Instead the other functions are used. For some code, switch to mp_time_sec(), which returns the time as double float value in seconds. The returned time is offset to program start time, so there is enough precision left to deliver microsecond resolution for at least 100 years. Unless it's casted to a float (or the CPU reduces precision), which is why we still use mp_time_us() out of paranoia in places where precision is clearly needed. Always switch to the correct time. The whole point of the new timer calls is that they don't wrap, and storing microseconds in unsigned int variables would negate this. In some cases, remove wrap-around handling for time values.
2013-05-25 18:31:06 +02:00
uint64_t t1 = *t;
uint64_t t2 = mp_time_us();
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 old = vc->last_vdp_time + (t1 - vc->last_sync_update) * 1000ULL;
vdpau: silence a clang warning It's just some braces...
2012-12-28 10:46:02 +01:00
if (vdp_time > old) {
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 (vdp_time > old + (t2 - t1) * 1000ULL)
vdp_time -= (t2 - t1) * 1000ULL;
else
vdp_time = old;
vdpau: silence a clang warning It's just some braces...
2012-12-28 10:46:02 +01: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_DBG(vo, "adjusting VdpTime offset by %f µs\n",
Implement vsync-aware frame timing for VDPAU Main things added are custom frame dropping for VDPAU to work around the display FPS limit, frame timing adjustment to avoid jitter when video frame times keep falling near vsyncs, and use of VDPAU's timing feature to keep one future frame queued in advance. NVIDIA's VDPAU implementation refuses to change the displayed frame more than once per vsync. This set a limit on how much video could be sped up, and caused problems for nearly all videos on low-FPS video projectors (playing 24 FPS video on a 24 FPS projector would not work reliably as MPlayer may need to slightly speed up the video for AV sync). This commit adds a framedrop mechanism that drops some frames so that no more than one is sent for display per vsync. The code tries to select the dropped frames smartly, selecting the best one to show for each vsync. Because of the timing features needed the drop functionality currently does not work if the correct-pts option is disabled. The code also adjusts frame timing slightly to avoid jitter. If you for example play 24 FPS video content on a 72 FPS display then normally a frame would be shown for 3 vsyncs, but if the frame times happen to fall near vsyncs and change between just before and just after then there could be frames alternating between 2 and 4 vsyncs. The code changes frame timing by up to one quarter vsync interval to avoid this. The above functionality depends on having reliable vsync timing information available. The display refresh rate is not directly provided by the VDPAU API. The current code uses information from the XF86VidMode extension if available; I'm not sure how common cases where that is inaccurate are. The refresh rate can be specified manually if necessary. After the changes in this commit MPlayer now always tries to keep one frame queued for future display using VDPAU's internal timing mechanism (however no more than 50 ms to the future). This should make video playback somewhat more robust against timing inaccuracies caused by system load.
2009-11-15 03:39:22 +01:00
(int64_t)(vdp_time - old) / 1000.);
vc->last_vdp_time = vdp_time;
vc->last_sync_update = t1;
*t = t2;
return 0;
}
static uint64_t sync_vdptime(struct vo *vo)
{
struct vdpctx *vc = vo->priv;
Replace all calls to GetTimer()/GetTimerMS() GetTimer() is generally replaced with mp_time_us(). Both calls return microseconds, but the latter uses int64_t, us defined to never wrap, and never returns 0 or negative values. GetTimerMS() has no direct replacement. Instead the other functions are used. For some code, switch to mp_time_sec(), which returns the time as double float value in seconds. The returned time is offset to program start time, so there is enough precision left to deliver microsecond resolution for at least 100 years. Unless it's casted to a float (or the CPU reduces precision), which is why we still use mp_time_us() out of paranoia in places where precision is clearly needed. Always switch to the correct time. The whole point of the new timer calls is that they don't wrap, and storing microseconds in unsigned int variables would negate this. In some cases, remove wrap-around handling for time values.
2013-05-25 18:31:06 +02:00
uint64_t t = mp_time_us();
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 (t - vc->last_sync_update > 5000000)
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
change_vdptime_sync(vo, &t);
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 now = (t - vc->last_sync_update) * 1000ULL + vc->last_vdp_time;
// Make sure nanosecond inaccuracies don't make things inconsistent
now = FFMAX(now, vc->recent_vsync_time);
return now;
}
Replace all calls to GetTimer()/GetTimerMS() GetTimer() is generally replaced with mp_time_us(). Both calls return microseconds, but the latter uses int64_t, us defined to never wrap, and never returns 0 or negative values. GetTimerMS() has no direct replacement. Instead the other functions are used. For some code, switch to mp_time_sec(), which returns the time as double float value in seconds. The returned time is offset to program start time, so there is enough precision left to deliver microsecond resolution for at least 100 years. Unless it's casted to a float (or the CPU reduces precision), which is why we still use mp_time_us() out of paranoia in places where precision is clearly needed. Always switch to the correct time. The whole point of the new timer calls is that they don't wrap, and storing microseconds in unsigned int variables would negate this. In some cases, remove wrap-around handling for time values.
2013-05-25 18:31:06 +02:00
static uint64_t convert_to_vdptime(struct vo *vo, uint64_t t)
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;
Replace all calls to GetTimer()/GetTimerMS() GetTimer() is generally replaced with mp_time_us(). Both calls return microseconds, but the latter uses int64_t, us defined to never wrap, and never returns 0 or negative values. GetTimerMS() has no direct replacement. Instead the other functions are used. For some code, switch to mp_time_sec(), which returns the time as double float value in seconds. The returned time is offset to program start time, so there is enough precision left to deliver microsecond resolution for at least 100 years. Unless it's casted to a float (or the CPU reduces precision), which is why we still use mp_time_us() out of paranoia in places where precision is clearly needed. Always switch to the correct time. The whole point of the new timer calls is that they don't wrap, and storing microseconds in unsigned int variables would negate this. In some cases, remove wrap-around handling for time values.
2013-05-25 18:31:06 +02:00
return (t - vc->last_sync_update) * 1000LL + vc->last_vdp_time;
Implement vsync-aware frame timing for VDPAU Main things added are custom frame dropping for VDPAU to work around the display FPS limit, frame timing adjustment to avoid jitter when video frame times keep falling near vsyncs, and use of VDPAU's timing feature to keep one future frame queued in advance. NVIDIA's VDPAU implementation refuses to change the displayed frame more than once per vsync. This set a limit on how much video could be sped up, and caused problems for nearly all videos on low-FPS video projectors (playing 24 FPS video on a 24 FPS projector would not work reliably as MPlayer may need to slightly speed up the video for AV sync). This commit adds a framedrop mechanism that drops some frames so that no more than one is sent for display per vsync. The code tries to select the dropped frames smartly, selecting the best one to show for each vsync. Because of the timing features needed the drop functionality currently does not work if the correct-pts option is disabled. The code also adjusts frame timing slightly to avoid jitter. If you for example play 24 FPS video content on a 72 FPS display then normally a frame would be shown for 3 vsyncs, but if the frame times happen to fall near vsyncs and change between just before and just after then there could be frames alternating between 2 and 4 vsyncs. The code changes frame timing by up to one quarter vsync interval to avoid this. The above functionality depends on having reliable vsync timing information available. The display refresh rate is not directly provided by the VDPAU API. The current code uses information from the XF86VidMode extension if available; I'm not sure how common cases where that is inaccurate are. The refresh rate can be specified manually if necessary. After the changes in this commit MPlayer now always tries to keep one frame queued for future display using VDPAU's internal timing mechanism (however no more than 50 ms to the future). This should make video playback somewhat more robust against timing inaccuracies caused by system load.
2009-11-15 03:39:22 +01:00
}
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;
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
struct buffered_video_surface *bv = vc->buffered_video;
int dp = vc->deint_queue_pos;
// Redraw frame from before seek reset?
if (dp < 0)
dp = vc->prev_deint_queue_pos;
if (dp < 0) {
video/out: always support redrawing VO window at any point Before, a VO could easily refuse to respond to VOCTRL_REDRAW_FRAME, which means the VO wouldn't redraw OSD and window contents, and the player would appear frozen to the user. This was a bit stupid, and makes dealing with some corner cases much harder (think of --keep-open, which was hard to implement, because the VO gets into this state if there are no new video frames after a seek reset). Change this, and require VOs to always react to VOCTRL_REDRAW_FRAME. There are two aspects of this: First, behavior after a (successful) vo_reconfig() call, but before any video frame has been displayed. Second, behavior after a vo_seek_reset(). For the first issue, we define that sending VOCTRL_REDRAW_FRAME after vo_reconfig() should clear the window with black. This requires minor changes to some VOs. In particular vaapi makes this horribly complicated, because OSD rendering is bound to a video surface. We create a black dummy surface for this purpose. The second issue is much simpler and works already with most VOs: they simply redraw whatever has been uploaded previously. The exception is vdpau, which has a complicated mechanism to track and filter video frames. The state associated with this mechanism is completely cleared with vo_seek_reset(), so implementing this to work as expected is not trivial. For now, we just clear the window with black.
2013-10-01 23:35:51 +02:00
// At least clear the screen if there is nothing to render
int flags = VDP_OUTPUT_SURFACE_RENDER_ROTATE_0;
vdp_st = vdp->output_surface_render_output_surface(output_surface,
NULL, vc->black_pixel,
NULL, NULL, NULL,
flags);
vo_vdpau: Fix X event handling bugs check_events() first checked for a RESIZE event and called resize() if needed, and then queued a frame to be reshown if in pause state and the event was either RESIZE or EXPOSE. The most obvious problems with the code were: - resize() already called flip_page() internally, so the code in check_events could lead to _two_ frames being queued. - The call in resize() didn't depend on pause status, so the behavior was inconsistent. - The code in check_events() actually queued the wrong output surface. It showed the same surface as flip_page() would show _next_, while it should have shown the previously shown one. This typically led to the screen contents changing to a previous state, as the new surface had not been initialized and had contents from a previous use. Fix the double update. Make resize() also only immediately update the video if paused (this also affects changing to/from fullscreen) and otherwise leave the old window contents be until the next frame. Queue the right frame in check_events(). Also make resize() a bit more careful to only show contents if they were successfully updated (though a case where we're paused without content to show shouldn't normally happen).
2009-09-18 23:00:42 +02:00
return -1;
video/out: always support redrawing VO window at any point Before, a VO could easily refuse to respond to VOCTRL_REDRAW_FRAME, which means the VO wouldn't redraw OSD and window contents, and the player would appear frozen to the user. This was a bit stupid, and makes dealing with some corner cases much harder (think of --keep-open, which was hard to implement, because the VO gets into this state if there are no new video frames after a seek reset). Change this, and require VOs to always react to VOCTRL_REDRAW_FRAME. There are two aspects of this: First, behavior after a (successful) vo_reconfig() call, but before any video frame has been displayed. Second, behavior after a vo_seek_reset(). For the first issue, we define that sending VOCTRL_REDRAW_FRAME after vo_reconfig() should clear the window with black. This requires minor changes to some VOs. In particular vaapi makes this horribly complicated, because OSD rendering is bound to a video surface. We create a black dummy surface for this purpose. The second issue is much simpler and works already with most VOs: they simply redraw whatever has been uploaded previously. The exception is vdpau, which has a complicated mechanism to track and filter video frames. The state associated with this mechanism is completely cleared with vo_seek_reset(), so implementing this to work as expected is not trivial. For now, we just clear the window with black.
2013-10-01 23:35:51 +02:00
}
Add support for VDPAU video out, including hardware decoding. git-svn-id: svn://svn.mplayerhq.hu/mplayer/trunk@28617 b3059339-0415-0410-9bf9-f77b7e298cf2
2009-02-16 21:58:13 +01:00
vo_vdpau: add RGB support Apparently this was dropped some years ago, but judging from MPlayer's handling of this, the original code wasn't so great anyway. The new code handling clearing of panscan borders correctly, and integrates better with the YUV path. (Although the VDPAU API sure makes this annoying with its separate surface types for RGB.) Note that we create 5 surfaces for some reason - I don't think this makes too much sense (because we can't use the deinterlacer with RGB surfaces), but at least it reduces the amount of differences with the YUV code path. Clearing the borders is done by drawing a single black pixel over the window. This sounds pretty dumb, but it appears to work well, and there is no other API for that. (One could try to use the video mixer for this purpose, since it has all kinds of features, including compositing multiple RGBA surfaces and clearing the window background. But it would require an invisible dummy video surface to make the video mixer happy, and that's getting too messy.)
2013-08-18 05:12:21 +02:00
vdp_st = vdp->presentation_queue_block_until_surface_idle(vc->flip_queue,
output_surface,
&dummy);
CHECK_ST_WARNING("Error when calling "
"vdp_presentation_queue_block_until_surface_idle");
if (vc->rgb_mode) {
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);
CHECK_ST_WARNING("Error clearing screen");
vdp_st = vdp->output_surface_render_output_surface(output_surface,
output_rect,
bv[dp/2].rgb_surface,
video_rect,
NULL, NULL, flags);
CHECK_ST_WARNING("Error when calling "
"vdp_output_surface_render_output_surface");
return 0;
}
int field = VDP_VIDEO_MIXER_PICTURE_STRUCTURE_FRAME;
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
// dp==0 means last field of latest frame, 1 earlier field of latest frame,
// 2 last field of previous frame and so on
if (vc->deint) {
field = vc->top_field_first ^ (dp & 1) ?
VDP_VIDEO_MIXER_PICTURE_STRUCTURE_BOTTOM_FIELD:
VDP_VIDEO_MIXER_PICTURE_STRUCTURE_TOP_FIELD;
}
const VdpVideoSurface *past_fields = (const VdpVideoSurface []){
vo_vdpau: Modify frame buffering code Clean up code related to frame buffering and generate pts information also for the next frame in the output queue. The timing information will be used in a following framedrop patch. This commit adds one frame of buffering delay in vo_vdpau and increases the number of buffered vdpau video surfaces from 3 to 4. The delay increase makes it more important to fix remaining code in MPlayer that doesn't deal well with filter/VO delay; OTOH it should help any decoding/filtering parallelism in the underlying VDPAU implementation as now filtering a frame for display can happen while the next one is being decoded.
2009-10-14 03:12:10 +02:00
bv[(dp+1)/2].surface, bv[(dp+2)/2].surface};
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
const VdpVideoSurface *future_fields = (const VdpVideoSurface []){
vo_vdpau: Modify frame buffering code Clean up code related to frame buffering and generate pts information also for the next frame in the output queue. The timing information will be used in a following framedrop patch. This commit adds one frame of buffering delay in vo_vdpau and increases the number of buffered vdpau video surfaces from 3 to 4. The delay increase makes it more important to fix remaining code in MPlayer that doesn't deal well with filter/VO delay; OTOH it should help any decoding/filtering parallelism in the underlying VDPAU implementation as now filtering a frame for display can happen while the next one is being decoded.
2009-10-14 03:12:10 +02:00
dp >= 1 ? bv[(dp-1)/2].surface : VDP_INVALID_HANDLE};
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
vdp_st = vdp->video_mixer_render(vc->video_mixer, VDP_INVALID_HANDLE,
0, field, 2, past_fields,
vo_vdpau: Modify frame buffering code Clean up code related to frame buffering and generate pts information also for the next frame in the output queue. The timing information will be used in a following framedrop patch. This commit adds one frame of buffering delay in vo_vdpau and increases the number of buffered vdpau video surfaces from 3 to 4. The delay increase makes it more important to fix remaining code in MPlayer that doesn't deal well with filter/VO delay; OTOH it should help any decoding/filtering parallelism in the underlying VDPAU implementation as now filtering a frame for display can happen while the next one is being decoded.
2009-10-14 03:12:10 +02:00
bv[dp/2].surface, 1, future_fields,
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
video_rect, output_surface,
vo_vdpau: implement screenshots
2011-10-06 20:46:01 +02:00
NULL, output_rect, 0, NULL);
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
CHECK_ST_WARNING("Error when calling vdp_video_mixer_render");
vo_vdpau: Fix X event handling bugs check_events() first checked for a RESIZE event and called resize() if needed, and then queued a frame to be reshown if in pause state and the event was either RESIZE or EXPOSE. The most obvious problems with the code were: - resize() already called flip_page() internally, so the code in check_events could lead to _two_ frames being queued. - The call in resize() didn't depend on pause status, so the behavior was inconsistent. - The code in check_events() actually queued the wrong output surface. It showed the same surface as flip_page() would show _next_, while it should have shown the previously shown one. This typically led to the screen contents changing to a previous state, as the new surface had not been initialized and had contents from a previous use. Fix the double update. Make resize() also only immediately update the video if paused (this also affects changing to/from fullscreen) and otherwise leave the old window contents be until the next frame. Queue the right frame in check_events(). Also make resize() a bit more careful to only show contents if they were successfully updated (though a case where we're paused without content to show shouldn't normally happen).
2009-09-18 23:00:42 +02:00
return 0;
core/VO: Allow VO drivers to add/modify frames Add interfaces to allow VO drivers to add or remove frames from the video stream and to alter timestamps. Currently this functionality only works with in correct-pts mode. Use the new functionality in vo_vdpau to properly support frame-adding deinterlace modes. Frames added by the VDPAU deinterlacing code are now properly timed. Before every second frame was always shown immediately (probably next monitor refresh) after the previous one, even if you were watching things in slow motion, and framestepping didn't stop at them at all. When seeking the deinterlace algorithm is no longer fed a mix of frames from old and new positions. As a side effect of the changes a problem with resize events was also fixed. Resizing calls video_to_output_surface() to render the frame at the new resolution, but before this function also changed the list of history frames, so resizing could give an image different from the original one, and also corrupt next frames due to them seeing the wrong history. Now the function has no such side effects. There are more resize-related problems though that will be fixed in a later commit. The deint_mpi[] list of reserved frames is increased from 2 to 3 entries for reasons related to the above. Having 2 entries is enough when you initially get a new frame in draw_image() because then you'll have those two entries plus the new one for a total of 3 (the code relied on the oldest mpi implicitly staying reserved for the duration of the call even after usage count was decreased). However if you want to be able to reproduce the rendering outside draw_image(), relying on the explicitly reserved list only, then it needs to store 3 entries.
2009-09-18 15:27:55 +02:00
}
Simplify vdpau deinterlacing code and fix timing for deint=2. git-svn-id: svn://svn.mplayerhq.hu/mplayer/trunk@29061 b3059339-0415-0410-9bf9-f77b7e298cf2
2009-03-26 00:32:27 +01:00
vo_vdpau: implement screenshots
2011-10-06 20:46:01 +02:00
static int video_to_output_surface(struct vo *vo)
{
struct vdpctx *vc = vo->priv;
return render_video_to_output_surface(vo,
vc->output_surfaces[vc->surface_num],
vo_vdpau: fix screenshots if panscan is used When panscan was used, i.e. the video is cropped to make the video fill the screen if video and screen aspects don't match, screenshots contained only the visible region of the source video, stretched to original video size.
2013-08-18 05:06:46 +02:00
&vc->out_rect_vid, &vc->src_rect_vid);
vo_vdpau: implement screenshots
2011-10-06 20:46:01 +02:00
}
vo: do final frame draw only near page flip Separate passing a new frame to VOs using the new API into two steps. The first, vo_draw_image(), happens after a new frame is available from the filter chain. In constrast to old behavior, now the frame is not actually rendered yet at this point (though possible slice draw calls can already reach the VO before). The second step, vo_new_frame_imminent(), happens when we're close enough to the display time of the new frame that we'll commit to flipping it as the next action and will not change the OSD over the previous frame any more. This new behavior fixes a previous problem with vo_vdpau and vo_gl in the situation where the player is paused after decoding a new frame but before flipping it; previously changing OSD in that state would switch to the new frame as a side effect. It would also allow an easy way to fix extra output files produced with something like "--vo=png --frames=1" with precise seeking, but this is not done yet. The code now relies on a new mp_image from the filter chain staying valid even after the vf_vo put_image() call providing it returns. In other words decoders/filters must not deallocate or otherwise invalidate their output frame between passing it forward and returning from the decode/filter call.
2011-12-04 17:10:17 +01:00
static int next_deint_queue_pos(struct vo *vo, bool eof)
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;
vo_vdpau: Modify frame buffering code Clean up code related to frame buffering and generate pts information also for the next frame in the output queue. The timing information will be used in a following framedrop patch. This commit adds one frame of buffering delay in vo_vdpau and increases the number of buffered vdpau video surfaces from 3 to 4. The delay increase makes it more important to fix remaining code in MPlayer that doesn't deal well with filter/VO delay; OTOH it should help any decoding/filtering parallelism in the underlying VDPAU implementation as now filtering a frame for display can happen while the next one is being decoded.
2009-10-14 03:12:10 +02:00
int dqp = vc->deint_queue_pos;
if (dqp < 0)
dqp += 1000;
else
dqp = vc->deint >= 2 ? dqp - 1 : dqp - 2 | 1;
if (dqp < (eof ? 0 : 3))
vo: do final frame draw only near page flip Separate passing a new frame to VOs using the new API into two steps. The first, vo_draw_image(), happens after a new frame is available from the filter chain. In constrast to old behavior, now the frame is not actually rendered yet at this point (though possible slice draw calls can already reach the VO before). The second step, vo_new_frame_imminent(), happens when we're close enough to the display time of the new frame that we'll commit to flipping it as the next action and will not change the OSD over the previous frame any more. This new behavior fixes a previous problem with vo_vdpau and vo_gl in the situation where the player is paused after decoding a new frame but before flipping it; previously changing OSD in that state would switch to the new frame as a side effect. It would also allow an easy way to fix extra output files produced with something like "--vo=png --frames=1" with precise seeking, but this is not done yet. The code now relies on a new mp_image from the filter chain staying valid even after the vf_vo put_image() call providing it returns. In other words decoders/filters must not deallocate or otherwise invalidate their output frame between passing it forward and returning from the decode/filter call.
2011-12-04 17:10:17 +01:00
return -1;
return dqp;
}
static void set_next_frame_info(struct vo *vo, bool eof)
{
struct vdpctx *vc = vo->priv;
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: do final frame draw only near page flip Separate passing a new frame to VOs using the new API into two steps. The first, vo_draw_image(), happens after a new frame is available from the filter chain. In constrast to old behavior, now the frame is not actually rendered yet at this point (though possible slice draw calls can already reach the VO before). The second step, vo_new_frame_imminent(), happens when we're close enough to the display time of the new frame that we'll commit to flipping it as the next action and will not change the OSD over the previous frame any more. This new behavior fixes a previous problem with vo_vdpau and vo_gl in the situation where the player is paused after decoding a new frame but before flipping it; previously changing OSD in that state would switch to the new frame as a side effect. It would also allow an easy way to fix extra output files produced with something like "--vo=png --frames=1" with precise seeking, but this is not done yet. The code now relies on a new mp_image from the filter chain staying valid even after the vf_vo put_image() call providing it returns. In other words decoders/filters must not deallocate or otherwise invalidate their output frame between passing it forward and returning from the decode/filter call.
2011-12-04 17:10:17 +01:00
vo->frame_loaded = false;
int dqp = next_deint_queue_pos(vo, eof);
if (dqp < 0)
return;
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->frame_loaded = true;
vo_vdpau: Modify frame buffering code Clean up code related to frame buffering and generate pts information also for the next frame in the output queue. The timing information will be used in a following framedrop patch. This commit adds one frame of buffering delay in vo_vdpau and increases the number of buffered vdpau video surfaces from 3 to 4. The delay increase makes it more important to fix remaining code in MPlayer that doesn't deal well with filter/VO delay; OTOH it should help any decoding/filtering parallelism in the underlying VDPAU implementation as now filtering a frame for display can happen while the next one is being decoded.
2009-10-14 03:12:10 +02:00
// Set pts values
struct buffered_video_surface *bv = vc->buffered_video;
vo: do final frame draw only near page flip Separate passing a new frame to VOs using the new API into two steps. The first, vo_draw_image(), happens after a new frame is available from the filter chain. In constrast to old behavior, now the frame is not actually rendered yet at this point (though possible slice draw calls can already reach the VO before). The second step, vo_new_frame_imminent(), happens when we're close enough to the display time of the new frame that we'll commit to flipping it as the next action and will not change the OSD over the previous frame any more. This new behavior fixes a previous problem with vo_vdpau and vo_gl in the situation where the player is paused after decoding a new frame but before flipping it; previously changing OSD in that state would switch to the new frame as a side effect. It would also allow an easy way to fix extra output files produced with something like "--vo=png --frames=1" with precise seeking, but this is not done yet. The code now relies on a new mp_image from the filter chain staying valid even after the vf_vo put_image() call providing it returns. In other words decoders/filters must not deallocate or otherwise invalidate their output frame between passing it forward and returning from the decode/filter call.
2011-12-04 17:10:17 +01:00
int idx = dqp >> 1;
vo_vdpau: Modify frame buffering code Clean up code related to frame buffering and generate pts information also for the next frame in the output queue. The timing information will be used in a following framedrop patch. This commit adds one frame of buffering delay in vo_vdpau and increases the number of buffered vdpau video surfaces from 3 to 4. The delay increase makes it more important to fix remaining code in MPlayer that doesn't deal well with filter/VO delay; OTOH it should help any decoding/filtering parallelism in the underlying VDPAU implementation as now filtering a frame for display can happen while the next one is being decoded.
2009-10-14 03:12:10 +02:00
if (idx == 0) { // no future frame/pts available
vo->next_pts = bv[0].pts;
vo->next_pts2 = MP_NOPTS_VALUE;
} else if (!(vc->deint >= 2)) { // no field-splitting deinterlace
vo->next_pts = bv[idx].pts;
vo->next_pts2 = bv[idx - 1].pts;
} else { // deinterlace with separate fields
double intermediate_pts;
double diff = bv[idx - 1].pts - bv[idx].pts;
core/VO: Allow VO drivers to add/modify frames Add interfaces to allow VO drivers to add or remove frames from the video stream and to alter timestamps. Currently this functionality only works with in correct-pts mode. Use the new functionality in vo_vdpau to properly support frame-adding deinterlace modes. Frames added by the VDPAU deinterlacing code are now properly timed. Before every second frame was always shown immediately (probably next monitor refresh) after the previous one, even if you were watching things in slow motion, and framestepping didn't stop at them at all. When seeking the deinterlace algorithm is no longer fed a mix of frames from old and new positions. As a side effect of the changes a problem with resize events was also fixed. Resizing calls video_to_output_surface() to render the frame at the new resolution, but before this function also changed the list of history frames, so resizing could give an image different from the original one, and also corrupt next frames due to them seeing the wrong history. Now the function has no such side effects. There are more resize-related problems though that will be fixed in a later commit. The deint_mpi[] list of reserved frames is increased from 2 to 3 entries for reasons related to the above. Having 2 entries is enough when you initially get a new frame in draw_image() because then you'll have those two entries plus the new one for a total of 3 (the code relied on the oldest mpi implicitly staying reserved for the duration of the call even after usage count was decreased). However if you want to be able to reproduce the rendering outside draw_image(), relying on the explicitly reserved list only, then it needs to store 3 entries.
2009-09-18 15:27:55 +02:00
if (diff > 0 && diff < 0.5)
vo_vdpau: Modify frame buffering code Clean up code related to frame buffering and generate pts information also for the next frame in the output queue. The timing information will be used in a following framedrop patch. This commit adds one frame of buffering delay in vo_vdpau and increases the number of buffered vdpau video surfaces from 3 to 4. The delay increase makes it more important to fix remaining code in MPlayer that doesn't deal well with filter/VO delay; OTOH it should help any decoding/filtering parallelism in the underlying VDPAU implementation as now filtering a frame for display can happen while the next one is being decoded.
2009-10-14 03:12:10 +02:00
intermediate_pts = (bv[idx].pts + bv[idx - 1].pts) / 2;
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
else
vo_vdpau: Modify frame buffering code Clean up code related to frame buffering and generate pts information also for the next frame in the output queue. The timing information will be used in a following framedrop patch. This commit adds one frame of buffering delay in vo_vdpau and increases the number of buffered vdpau video surfaces from 3 to 4. The delay increase makes it more important to fix remaining code in MPlayer that doesn't deal well with filter/VO delay; OTOH it should help any decoding/filtering parallelism in the underlying VDPAU implementation as now filtering a frame for display can happen while the next one is being decoded.
2009-10-14 03:12:10 +02:00
intermediate_pts = bv[idx].pts;
vo: do final frame draw only near page flip Separate passing a new frame to VOs using the new API into two steps. The first, vo_draw_image(), happens after a new frame is available from the filter chain. In constrast to old behavior, now the frame is not actually rendered yet at this point (though possible slice draw calls can already reach the VO before). The second step, vo_new_frame_imminent(), happens when we're close enough to the display time of the new frame that we'll commit to flipping it as the next action and will not change the OSD over the previous frame any more. This new behavior fixes a previous problem with vo_vdpau and vo_gl in the situation where the player is paused after decoding a new frame but before flipping it; previously changing OSD in that state would switch to the new frame as a side effect. It would also allow an easy way to fix extra output files produced with something like "--vo=png --frames=1" with precise seeking, but this is not done yet. The code now relies on a new mp_image from the filter chain staying valid even after the vf_vo put_image() call providing it returns. In other words decoders/filters must not deallocate or otherwise invalidate their output frame between passing it forward and returning from the decode/filter call.
2011-12-04 17:10:17 +01:00
if (dqp & 1) { // first field
vo_vdpau: Modify frame buffering code Clean up code related to frame buffering and generate pts information also for the next frame in the output queue. The timing information will be used in a following framedrop patch. This commit adds one frame of buffering delay in vo_vdpau and increases the number of buffered vdpau video surfaces from 3 to 4. The delay increase makes it more important to fix remaining code in MPlayer that doesn't deal well with filter/VO delay; OTOH it should help any decoding/filtering parallelism in the underlying VDPAU implementation as now filtering a frame for display can happen while the next one is being decoded.
2009-10-14 03:12:10 +02:00
vo->next_pts = bv[idx].pts;
vo->next_pts2 = intermediate_pts;
} else {
vo->next_pts = intermediate_pts;
vo->next_pts2 = bv[idx - 1].pts;
}
}
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: Modify frame buffering code Clean up code related to frame buffering and generate pts information also for the next frame in the output queue. The timing information will be used in a following framedrop patch. This commit adds one frame of buffering delay in vo_vdpau and increases the number of buffered vdpau video surfaces from 3 to 4. The delay increase makes it more important to fix remaining code in MPlayer that doesn't deal well with filter/VO delay; OTOH it should help any decoding/filtering parallelism in the underlying VDPAU implementation as now filtering a frame for display can happen while the next one is being decoded.
2009-10-14 03:12:10 +02:00
static void add_new_video_surface(struct vo *vo, VdpVideoSurface 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
VdpOutputSurface rgb_surface,
vo_vdpau: Modify frame buffering code Clean up code related to frame buffering and generate pts information also for the next frame in the output queue. The timing information will be used in a following framedrop patch. This commit adds one frame of buffering delay in vo_vdpau and increases the number of buffered vdpau video surfaces from 3 to 4. The delay increase makes it more important to fix remaining code in MPlayer that doesn't deal well with filter/VO delay; OTOH it should help any decoding/filtering parallelism in the underlying VDPAU implementation as now filtering a frame for display can happen while the next one is being decoded.
2009-10-14 03:12:10 +02:00
struct mp_image *reserved_mpi, double pts)
{
struct vdpctx *vc = vo->priv;
struct buffered_video_surface *bv = vc->buffered_video;
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
mp_image_unrefp(&bv[NUM_BUFFERED_VIDEO - 1].mpi);
vo_vdpau: Modify frame buffering code Clean up code related to frame buffering and generate pts information also for the next frame in the output queue. The timing information will be used in a following framedrop patch. This commit adds one frame of buffering delay in vo_vdpau and increases the number of buffered vdpau video surfaces from 3 to 4. The delay increase makes it more important to fix remaining code in MPlayer that doesn't deal well with filter/VO delay; OTOH it should help any decoding/filtering parallelism in the underlying VDPAU implementation as now filtering a frame for display can happen while the next one is being decoded.
2009-10-14 03:12:10 +02:00
for (int i = NUM_BUFFERED_VIDEO - 1; i > 0; i--)
bv[i] = bv[i - 1];
bv[0] = (struct buffered_video_surface){
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
.mpi = reserved_mpi,
vo_vdpau: Modify frame buffering code Clean up code related to frame buffering and generate pts information also for the next frame in the output queue. The timing information will be used in a following framedrop patch. This commit adds one frame of buffering delay in vo_vdpau and increases the number of buffered vdpau video surfaces from 3 to 4. The delay increase makes it more important to fix remaining code in MPlayer that doesn't deal well with filter/VO delay; OTOH it should help any decoding/filtering parallelism in the underlying VDPAU implementation as now filtering a frame for display can happen while the next one is being decoded.
2009-10-14 03:12:10 +02:00
.surface = 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
.rgb_surface = rgb_surface,
vo_vdpau: Modify frame buffering code Clean up code related to frame buffering and generate pts information also for the next frame in the output queue. The timing information will be used in a following framedrop patch. This commit adds one frame of buffering delay in vo_vdpau and increases the number of buffered vdpau video surfaces from 3 to 4. The delay increase makes it more important to fix remaining code in MPlayer that doesn't deal well with filter/VO delay; OTOH it should help any decoding/filtering parallelism in the underlying VDPAU implementation as now filtering a frame for display can happen while the next one is being decoded.
2009-10-14 03:12:10 +02:00
.pts = pts,
};
vo: do final frame draw only near page flip Separate passing a new frame to VOs using the new API into two steps. The first, vo_draw_image(), happens after a new frame is available from the filter chain. In constrast to old behavior, now the frame is not actually rendered yet at this point (though possible slice draw calls can already reach the VO before). The second step, vo_new_frame_imminent(), happens when we're close enough to the display time of the new frame that we'll commit to flipping it as the next action and will not change the OSD over the previous frame any more. This new behavior fixes a previous problem with vo_vdpau and vo_gl in the situation where the player is paused after decoding a new frame but before flipping it; previously changing OSD in that state would switch to the new frame as a side effect. It would also allow an easy way to fix extra output files produced with something like "--vo=png --frames=1" with precise seeking, but this is not done yet. The code now relies on a new mp_image from the filter chain staying valid even after the vf_vo put_image() call providing it returns. In other words decoders/filters must not deallocate or otherwise invalidate their output frame between passing it forward and returning from the decode/filter call.
2011-12-04 17:10:17 +01:00
vc->deint_queue_pos = FFMIN(vc->deint_queue_pos + 2,
NUM_BUFFERED_VIDEO * 2 - 3);
set_next_frame_info(vo, false);
vo_vdpau: Modify frame buffering code Clean up code related to frame buffering and generate pts information also for the next frame in the output queue. The timing information will be used in a following framedrop patch. This commit adds one frame of buffering delay in vo_vdpau and increases the number of buffered vdpau video surfaces from 3 to 4. The delay increase makes it more important to fix remaining code in MPlayer that doesn't deal well with filter/VO delay; OTOH it should help any decoding/filtering parallelism in the underlying VDPAU implementation as now filtering a frame for display can happen while the next one is being decoded.
2009-10-14 03:12:10 +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;
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
if (seek_reset) {
if (vc->deint_queue_pos >= 0)
vc->prev_deint_queue_pos = vc->deint_queue_pos;
} else {
vc->prev_deint_queue_pos = -1001;
}
vo_vdpau: Modify frame buffering code Clean up code related to frame buffering and generate pts information also for the next frame in the output queue. The timing information will be used in a following framedrop patch. This commit adds one frame of buffering delay in vo_vdpau and increases the number of buffered vdpau video surfaces from 3 to 4. The delay increase makes it more important to fix remaining code in MPlayer that doesn't deal well with filter/VO delay; OTOH it should help any decoding/filtering parallelism in the underlying VDPAU implementation as now filtering a frame for display can happen while the next one is being decoded.
2009-10-14 03:12:10 +02:00
vc->deint_queue_pos = -1001;
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;
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
if (vc->prev_deint_queue_pos < 0) {
for (int i = 0; i < NUM_BUFFERED_VIDEO; i++) {
struct buffered_video_surface *p = vc->buffered_video + i;
mp_image_unrefp(&p->mpi);
*p = (struct buffered_video_surface){
.surface = VDP_INVALID_HANDLE,
.rgb_surface = VDP_INVALID_HANDLE,
};
}
Enable Bob de-interlacing for VDPAU. git-svn-id: svn://svn.mplayerhq.hu/mplayer/trunk@28719 b3059339-0415-0410-9bf9-f77b7e298cf2
2009-02-24 22:46:25 +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
}
vo_vdpau: Make compile as new-style VO
2009-05-04 02:09:50 +02:00
static void resize(struct vo *vo)
Add support for VDPAU video out, including hardware decoding. git-svn-id: svn://svn.mplayerhq.hu/mplayer/trunk@28617 b3059339-0415-0410-9bf9-f77b7e298cf2
2009-02-16 21:58:13 +01:00
{
vo_vdpau: Replace global function table with context variable
2009-05-06 20:04:37 +02:00
struct vdpctx *vc = vo->priv;
struct vdp_functions *vdp = vc->vdp;
Add support for VDPAU video out, including hardware decoding. git-svn-id: svn://svn.mplayerhq.hu/mplayer/trunk@28617 b3059339-0415-0410-9bf9-f77b7e298cf2
2009-02-16 21:58:13 +01:00
VdpStatus vdp_st;
VO: remove code duplication for setting up mp_osd_res vo_opengl, vo_vdpau, vo_direct3d had the code for setting up mp_osd_res duplicated. Make things simpler by making calc_src_dst_rects() setup the full mp_osd_res structure, instead of just "borders". Also, rename that function to vo_get_src_dst_rects(), and make it use mp_rect. Remove vo_rect, which was annoying because it contains redundant members (width/height additional to right/bottom). Add code to print the video rect etc. in verbose mode. There should be no actual change how the video rects are calculated. The only exception are the bottom/right subtitle margins, which are now computed slightly differently, but that shouldn't matter.
2012-10-27 22:10:32 +02:00
struct mp_rect src_rect;
struct mp_rect dst_rect;
vo_get_src_dst_rects(vo, &src_rect, &dst_rect, &vc->osd_rect);
vc->out_rect_vid.x0 = dst_rect.x0;
vc->out_rect_vid.x1 = dst_rect.x1;
vc->out_rect_vid.y0 = dst_rect.y0;
vc->out_rect_vid.y1 = dst_rect.y1;
vc->src_rect_vid.x0 = src_rect.x0;
vc->src_rect_vid.x1 = src_rect.x1;
vc->src_rect_vid.y0 = vc->flip ? src_rect.y1 : src_rect.y0;
vc->src_rect_vid.y1 = vc->flip ? src_rect.y0 : src_rect.y1;
sub, VO: remove vo_osd_resized() function VOs which could render the OSD in window size (as opposed to video size, like vo_xv) and which could cache the OSD called this when the window size changed. This was needed, because VOs used another OSD function to check whether the OSD changed before passing the new window size to the OSD code. This was really just an artifact of OSD change detection, and now that the affected VOs use the new OSD rendering API, it's done automatically.
2012-10-04 17:16:28 +02:00
video: remove fullscreen flags chaos There was a MPOpts fullscreen field, a mp_vo_opts.fs field, and VOFLAG_FULLSCREEN. Remove all these and introduce a mp_vo_opts.fullscreen flag instead. When VOs receive VOCTRL_FULLSCREEN, they are supposed to set the current fullscreen mode to the state in mp_vo_opts.fullscreen. They also should do this implicitly on config(). VOs which are capable of doing so can update the mp_vo_opts.fullscreen if the actual fullscreen mode changes (e.g. if the user uses the window manager controls). If fullscreen mode switching fails, they can also set mp_vo_opts.fullscreen to the actual state. Note that the X11 backend does almost none of this, and it has a private fs flag to store the fullscreen flag, instead of getting it from the WM. (Possibly because it has to deal with broken WMs.) The fullscreen option has to be checked on config() to deal with the -fs option, especially with something like: mpv --fs file1.mkv --{ --no-fs file2.mkv --} (It should start in fullscreen mode, but go to windowed mode when playing file2.mkv.) Wayland changes by: Alexander Preisinger <alexander.preisinger@gmail.com> Cocoa changes by: Stefano Pigozzi <stefano.pigozzi@gmail.com>
2013-07-18 14:05:39 +02:00
int flip_offset_ms = vo->opts->fullscreen ?
vo: remove and cleanup globals Removes almost every global variabel in vo.h and puts them in a special struct in MPOpts for video output related options. Also we completly remove the options/globals pts and refresh rate because they were unused.
2013-03-04 17:40:21 +01:00
vc->flip_offset_fs :
vc->flip_offset_window;
vo_vdpau: make queuing future frame flips adjustable Add -vo vdpau suboptions "queuetime_windowed" and "queuetime_fs" to specify the maximum number of milliseconds how far into the future a frame flip can be queued using the VDPAU presentation queue functionality. The intended main use of these options is to allow disabling use of the queuing feature on systems where using it causes choppiness in other graphics behavior (this is an NVIDIA driver issue; the video itself isn't affected).
2010-02-05 19:13:33 +01:00
vo->flip_queue_offset = flip_offset_ms / 1000.;
Add support for VDPAU video out, including hardware decoding. git-svn-id: svn://svn.mplayerhq.hu/mplayer/trunk@28617 b3059339-0415-0410-9bf9-f77b7e298cf2
2009-02-16 21:58:13 +01:00
vo_vdpau: fix screenshots Attempting to take screenshots printed vdpau errors on the terminal, and the resulting screenshots were filled with black. The problem was that that the screenshot code tried to use an unallocated output surface (the one at vc->output_surfaces[vc->num_output_surfaces]). This used to refer to the last allocated surface, until this was changed by a recently merged commit. That commit also added a separate screenshot surface. The merge somehow went wrong, and that part was not integrated. <uau> wm4: you used an earlier buggy version of a commit OK...
2012-10-21 00:48:01 +02:00
if (vc->output_surface_width < vo->dwidth
|| vc->output_surface_height < vo->dheight) {
if (vc->output_surface_width < vo->dwidth) {
vo_vdpau: Move things to context struct
2009-05-06 22:42:24 +02:00
vc->output_surface_width += vc->output_surface_width >> 1;
vo_vdpau.c: cosmetics
2009-05-09 17:08:30 +02:00
vc->output_surface_width = FFMAX(vc->output_surface_width,
vo_vdpau: fix screenshots Attempting to take screenshots printed vdpau errors on the terminal, and the resulting screenshots were filled with black. The problem was that that the screenshot code tried to use an unallocated output surface (the one at vc->output_surfaces[vc->num_output_surfaces]). This used to refer to the last allocated surface, until this was changed by a recently merged commit. That commit also added a separate screenshot surface. The merge somehow went wrong, and that part was not integrated. <uau> wm4: you used an earlier buggy version of a commit OK...
2012-10-21 00:48:01 +02:00
vo->dwidth);
Add support for VDPAU video out, including hardware decoding. git-svn-id: svn://svn.mplayerhq.hu/mplayer/trunk@28617 b3059339-0415-0410-9bf9-f77b7e298cf2
2009-02-16 21:58:13 +01:00
}
vo_vdpau: fix screenshots Attempting to take screenshots printed vdpau errors on the terminal, and the resulting screenshots were filled with black. The problem was that that the screenshot code tried to use an unallocated output surface (the one at vc->output_surfaces[vc->num_output_surfaces]). This used to refer to the last allocated surface, until this was changed by a recently merged commit. That commit also added a separate screenshot surface. The merge somehow went wrong, and that part was not integrated. <uau> wm4: you used an earlier buggy version of a commit OK...
2012-10-21 00:48:01 +02:00
if (vc->output_surface_height < vo->dheight) {
vo_vdpau: Move things to context struct
2009-05-06 22:42:24 +02:00
vc->output_surface_height += vc->output_surface_height >> 1;
vo_vdpau.c: cosmetics
2009-05-09 17:08:30 +02:00
vc->output_surface_height = FFMAX(vc->output_surface_height,
vo_vdpau: fix screenshots Attempting to take screenshots printed vdpau errors on the terminal, and the resulting screenshots were filled with black. The problem was that that the screenshot code tried to use an unallocated output surface (the one at vc->output_surfaces[vc->num_output_surfaces]). This used to refer to the last allocated surface, until this was changed by a recently merged commit. That commit also added a separate screenshot surface. The merge somehow went wrong, and that part was not integrated. <uau> wm4: you used an earlier buggy version of a commit OK...
2012-10-21 00:48:01 +02:00
vo->dheight);
Add support for VDPAU video out, including hardware decoding. git-svn-id: svn://svn.mplayerhq.hu/mplayer/trunk@28617 b3059339-0415-0410-9bf9-f77b7e298cf2
2009-02-16 21:58:13 +01:00
}
// Creation of output_surfaces
vo_vdpau: split bitmap packing code into a separate file Split the vo_vdpau code that calculates how to pack all subtitle bitmaps into a larger surface into a separate file. This will allow using it in other VOs. Conflicts: Makefile libvo/vo_vdpau.c Note: this commit does the same as an earlier commit by me (4010dd0b1a27e3996). My commit added the vo_vdpau packer code as eosd_packer.c, while this commit by uau uses bitmap_packer.c. Since bitmap_packer.c has a different interface, and because there are more commits changing OSD rendering coming, I will pick uau's version. However, vo_gl, vo_gl3 and vo_direct3d are still using eosd_packer.c, so to make the transition easier, don't delete eosd_packer.c yet.
2012-08-26 18:00:26 +02:00
for (int i = 0; i < vc->num_output_surfaces; i++)
vo_vdpau: fix loop initializing output surfaces as invalid The loop initializing handles in the output surface table to VDP_INVALID_HANDLE ran over indices from 0 to vc->num_output_surfaces. However it is first called before that variable is initialized. As a result later code could try to destroy the handles which still had the "non-invalid" value 0. Most likely this caused no visible effects; at least on my machine no valid surface gets handle 0, and libvdpau just returns an error for the resulting invalid calls. Change the code to loop over the whole table. Also add code to print visible warnings if libvdpau rejects a surface destroy call (some other places already had checks but not all).
2010-05-26 07:54:09 +02:00
if (vc->output_surfaces[i] != VDP_INVALID_HANDLE) {
vdp_st = vdp->output_surface_destroy(vc->output_surfaces[i]);
CHECK_ST_WARNING("Error when calling "
"vdp_output_surface_destroy");
}
vo_vdpau: split bitmap packing code into a separate file Split the vo_vdpau code that calculates how to pack all subtitle bitmaps into a larger surface into a separate file. This will allow using it in other VOs. Conflicts: Makefile libvo/vo_vdpau.c Note: this commit does the same as an earlier commit by me (4010dd0b1a27e3996). My commit added the vo_vdpau packer code as eosd_packer.c, while this commit by uau uses bitmap_packer.c. Since bitmap_packer.c has a different interface, and because there are more commits changing OSD rendering coming, I will pick uau's version. However, vo_gl, vo_gl3 and vo_direct3d are still using eosd_packer.c, so to make the transition easier, don't delete eosd_packer.c yet.
2012-08-26 18:00:26 +02:00
for (int i = 0; i < vc->num_output_surfaces; i++) {
vo_vdpau.c: cosmetics
2009-05-09 17:08:30 +02:00
vdp_st = vdp->output_surface_create(vc->vdp_device,
vo_vdpau: implement screenshots
2011-10-06 20:46:01 +02:00
OUTPUT_RGBA_FORMAT,
vo_vdpau.c: cosmetics
2009-05-09 17:08:30 +02:00
vc->output_surface_width,
vc->output_surface_height,
&vc->output_surfaces[i]);
CHECK_ST_WARNING("Error when calling vdp_output_surface_create");
Some more mp_msg conversions Also add a note to mp_msg.h, since it might be not clear which of the two mechanisms is preferred.
2013-08-23 23:30:09 +02:00
MP_DBG(vo, "vdpau out create: %u\n",
vo_vdpau.c: cosmetics
2009-05-09 17:08:30 +02:00
vc->output_surfaces[i]);
Add support for VDPAU video out, including hardware decoding. git-svn-id: svn://svn.mplayerhq.hu/mplayer/trunk@28617 b3059339-0415-0410-9bf9-f77b7e298cf2
2009-02-16 21:58:13 +01:00
}
}
core, vo: new window refresh logic, add slow-video OSD redraw Remove code refreshing window contents after events such as resize from vo_vdpau, vo_gl and vo_xv. Instead have them simply set a flag indicating that a refresh is needed, and have the player core perform that refresh by doing an OSD redraw. Also add support for updating the OSD contents over existing frames during slow-but-not-paused playback. The VOs now also request a refresh if parameters affecting the picture change (equalizer settings, colormatrix, VDPAU deinterlacing setting). Even previously the picture was typically redrawn with the new settings while paused because new OSD messages associated with setting changes triggered a redraw, but this did not happen if OSD was turned off. A minor imperfection is that now window system events can trigger a single one-frame step forward when using vo_xv after pausing so that vo_xv does not yet have a copy of the current image. This could be fixed but I think it's not important enough to bother.
2011-12-05 05:36:20 +01:00
vo->want_redraw = true;
Add support for VDPAU video out, including hardware decoding. git-svn-id: svn://svn.mplayerhq.hu/mplayer/trunk@28617 b3059339-0415-0410-9bf9-f77b7e298cf2
2009-02-16 21:58:13 +01:00
}
vo_vdpau: Make compile as new-style VO
2009-05-04 02:09:50 +02:00
static int win_x11_init_vdpau_flip_queue(struct vo *vo)
Add support for VDPAU video out, including hardware decoding. git-svn-id: svn://svn.mplayerhq.hu/mplayer/trunk@28617 b3059339-0415-0410-9bf9-f77b7e298cf2
2009-02-16 21:58:13 +01:00
{
vo_vdpau: Replace global function table with context variable
2009-05-06 20:04:37 +02:00
struct vdpctx *vc = vo->priv;
struct vdp_functions *vdp = vc->vdp;
vo_vdpau: Make compile as new-style VO
2009-05-04 02:09:50 +02:00
struct vo_x11_state *x11 = vo->x11;
Add support for VDPAU video out, including hardware decoding. git-svn-id: svn://svn.mplayerhq.hu/mplayer/trunk@28617 b3059339-0415-0410-9bf9-f77b7e298cf2
2009-02-16 21:58:13 +01:00
VdpStatus vdp_st;
vo_vdpau: Support recovering from VDPAU display preemption Add code to reinitialize all VDPAU objects if a display preemption condition occurs. Reinitializing them in the middle of playback will cause video corruption at least until the next keyframe when using hardware decoding, but decoding does seem to recover after a keyframe.
2009-09-07 01:02:24 +02:00
if (vc->flip_target == VDP_INVALID_HANDLE) {
vdp_st = vdp->presentation_queue_target_create_x11(vc->vdp_device,
x11->window,
&vc->flip_target);
CHECK_ST_ERROR("Error when calling "
"vdp_presentation_queue_target_create_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
vo_vdpau: Support recovering from VDPAU display preemption Add code to reinitialize all VDPAU objects if a display preemption condition occurs. Reinitializing them in the middle of playback will cause video corruption at least until the next keyframe when using hardware decoding, but decoding does seem to recover after a keyframe.
2009-09-07 01:02:24 +02:00
/* Emperically this seems to be the first call which fails when we
* try to reinit after preemption while the user is still switched
* from X to a virtual terminal (creating the vdp_device initially
* succeeds, as does creating the flip_target above). This is
* probably not guaranteed behavior, but we'll assume it as a simple
* way to reduce warnings while trying to recover from preemption.
*/
if (vc->flip_queue == VDP_INVALID_HANDLE) {
vdp_st = vdp->presentation_queue_create(vc->vdp_device, vc->flip_target,
&vc->flip_queue);
vdpau: move device and video surface management from vo_vdpau.c to vdpau.c The goal is being able to use vdpau decoding independently from vo_vdpau.c.
2013-11-05 22:06:32 +01:00
if (vc->mpvdp->is_preempted && vdp_st != VDP_STATUS_OK) {
Some more mp_msg conversions Also add a note to mp_msg.h, since it might be not clear which of the two mechanisms is preferred.
2013-08-23 23:30:09 +02:00
MP_DBG(vo, "Failed to create flip queue while preempted: %s\n",
vdp->get_error_string(vdp_st));
vo_vdpau: Support recovering from VDPAU display preemption Add code to reinitialize all VDPAU objects if a display preemption condition occurs. Reinitializing them in the middle of playback will cause video corruption at least until the next keyframe when using hardware decoding, but decoding does seem to recover after a keyframe.
2009-09-07 01:02:24 +02:00
return -1;
} else
CHECK_ST_ERROR("Error when calling vdp_presentation_queue_create");
}
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);
CHECK_ST_WARNING("Error setting colorkey");
}
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 vdp_time;
vdp_st = vdp->presentation_queue_get_time(vc->flip_queue, &vdp_time);
CHECK_ST_ERROR("Error when calling vdp_presentation_queue_get_time");
vc->last_vdp_time = vdp_time;
Replace all calls to GetTimer()/GetTimerMS() GetTimer() is generally replaced with mp_time_us(). Both calls return microseconds, but the latter uses int64_t, us defined to never wrap, and never returns 0 or negative values. GetTimerMS() has no direct replacement. Instead the other functions are used. For some code, switch to mp_time_sec(), which returns the time as double float value in seconds. The returned time is offset to program start time, so there is enough precision left to deliver microsecond resolution for at least 100 years. Unless it's casted to a float (or the CPU reduces precision), which is why we still use mp_time_us() out of paranoia in places where precision is clearly needed. Always switch to the correct time. The whole point of the new timer calls is that they don't wrap, and storing microseconds in unsigned int variables would negate this. In some cases, remove wrap-around handling for time values.
2013-05-25 18:31:06 +02:00
vc->last_sync_update = mp_time_us();
Implement vsync-aware frame timing for VDPAU Main things added are custom frame dropping for VDPAU to work around the display FPS limit, frame timing adjustment to avoid jitter when video frame times keep falling near vsyncs, and use of VDPAU's timing feature to keep one future frame queued in advance. NVIDIA's VDPAU implementation refuses to change the displayed frame more than once per vsync. This set a limit on how much video could be sped up, and caused problems for nearly all videos on low-FPS video projectors (playing 24 FPS video on a 24 FPS projector would not work reliably as MPlayer may need to slightly speed up the video for AV sync). This commit adds a framedrop mechanism that drops some frames so that no more than one is sent for display per vsync. The code tries to select the dropped frames smartly, selecting the best one to show for each vsync. Because of the timing features needed the drop functionality currently does not work if the correct-pts option is disabled. The code also adjusts frame timing slightly to avoid jitter. If you for example play 24 FPS video content on a 72 FPS display then normally a frame would be shown for 3 vsyncs, but if the frame times happen to fall near vsyncs and change between just before and just after then there could be frames alternating between 2 and 4 vsyncs. The code changes frame timing by up to one quarter vsync interval to avoid this. The above functionality depends on having reliable vsync timing information available. The display refresh rate is not directly provided by the VDPAU API. The current code uses information from the XF86VidMode extension if available; I'm not sure how common cases where that is inaccurate are. The refresh rate can be specified manually if necessary. After the changes in this commit MPlayer now always tries to keep one frame queued for future display using VDPAU's internal timing mechanism (however no more than 50 ms to the future). This should make video playback somewhat more robust against timing inaccuracies caused by system load.
2009-11-15 03:39:22 +01:00
vc->vsync_interval = 1;
vo_vdpau: disable refresh-aware frame timing when composited Under a compositing window manager the current VDPAU implementation behaves differently than without it. Frame flip timing info becomes incorrect (I guess it only reflects when the frame was sent to the compositor, not when it was actually shown), and there is no limitation to at most one frame switch per refresh like without compositing. Detect whether a compositing window manager is active and disable refresh-aware frame timing and dropping in this case, similarly to what fps=-1 would do. This behavior can be controlled with the new suboption "composite-detect". Disabling the refresh-aware logic makes timing somewhat less accurate. Because the video switch rate limit isn't there, the lack of frame dropping on player side does not impose a hard limit on video FPS, but does reduce performance somewhat as redundant frames are drawn in memory. The existence of a compositing window manager does not guarantee that the current window is actually composited, so the current check is not foolproof. In particular, some WMs have support for a "unredirect fullscreen windows" option. Support for such things could be improved.
2012-07-27 02:40:38 +02:00
if (vc->composite_detect && vo_x11_screen_is_composited(vo)) {
Some more mp_msg conversions Also add a note to mp_msg.h, since it might be not clear which of the two mechanisms is preferred.
2013-08-23 23:30:09 +02:00
MP_INFO(vo, "Compositing window manager detected. Assuming timing info "
"is inaccurate.\n");
vo_vdpau: disable refresh-aware frame timing when composited Under a compositing window manager the current VDPAU implementation behaves differently than without it. Frame flip timing info becomes incorrect (I guess it only reflects when the frame was sent to the compositor, not when it was actually shown), and there is no limitation to at most one frame switch per refresh like without compositing. Detect whether a compositing window manager is active and disable refresh-aware frame timing and dropping in this case, similarly to what fps=-1 would do. This behavior can be controlled with the new suboption "composite-detect". Disabling the refresh-aware logic makes timing somewhat less accurate. Because the video switch rate limit isn't there, the lack of frame dropping on player side does not impose a hard limit on video FPS, but does reduce performance somewhat as redundant frames are drawn in memory. The existence of a compositing window manager does not guarantee that the current window is actually composited, so the current check is not foolproof. In particular, some WMs have support for a "unredirect fullscreen windows" option. Support for such things could be improved.
2012-07-27 02:40:38 +02:00
} else if (vc->user_fps > 0) {
Implement vsync-aware frame timing for VDPAU Main things added are custom frame dropping for VDPAU to work around the display FPS limit, frame timing adjustment to avoid jitter when video frame times keep falling near vsyncs, and use of VDPAU's timing feature to keep one future frame queued in advance. NVIDIA's VDPAU implementation refuses to change the displayed frame more than once per vsync. This set a limit on how much video could be sped up, and caused problems for nearly all videos on low-FPS video projectors (playing 24 FPS video on a 24 FPS projector would not work reliably as MPlayer may need to slightly speed up the video for AV sync). This commit adds a framedrop mechanism that drops some frames so that no more than one is sent for display per vsync. The code tries to select the dropped frames smartly, selecting the best one to show for each vsync. Because of the timing features needed the drop functionality currently does not work if the correct-pts option is disabled. The code also adjusts frame timing slightly to avoid jitter. If you for example play 24 FPS video content on a 72 FPS display then normally a frame would be shown for 3 vsyncs, but if the frame times happen to fall near vsyncs and change between just before and just after then there could be frames alternating between 2 and 4 vsyncs. The code changes frame timing by up to one quarter vsync interval to avoid this. The above functionality depends on having reliable vsync timing information available. The display refresh rate is not directly provided by the VDPAU API. The current code uses information from the XF86VidMode extension if available; I'm not sure how common cases where that is inaccurate are. The refresh rate can be specified manually if necessary. After the changes in this commit MPlayer now always tries to keep one frame queued for future display using VDPAU's internal timing mechanism (however no more than 50 ms to the future). This should make video playback somewhat more robust against timing inaccuracies caused by system load.
2009-11-15 03:39:22 +01:00
vc->vsync_interval = 1e9 / vc->user_fps;
Some more mp_msg conversions Also add a note to mp_msg.h, since it might be not clear which of the two mechanisms is preferred.
2013-08-23 23:30:09 +02:00
MP_INFO(vo, "Assuming user-specified display refresh rate of %.3f Hz.\n",
vc->user_fps);
Implement vsync-aware frame timing for VDPAU Main things added are custom frame dropping for VDPAU to work around the display FPS limit, frame timing adjustment to avoid jitter when video frame times keep falling near vsyncs, and use of VDPAU's timing feature to keep one future frame queued in advance. NVIDIA's VDPAU implementation refuses to change the displayed frame more than once per vsync. This set a limit on how much video could be sped up, and caused problems for nearly all videos on low-FPS video projectors (playing 24 FPS video on a 24 FPS projector would not work reliably as MPlayer may need to slightly speed up the video for AV sync). This commit adds a framedrop mechanism that drops some frames so that no more than one is sent for display per vsync. The code tries to select the dropped frames smartly, selecting the best one to show for each vsync. Because of the timing features needed the drop functionality currently does not work if the correct-pts option is disabled. The code also adjusts frame timing slightly to avoid jitter. If you for example play 24 FPS video content on a 72 FPS display then normally a frame would be shown for 3 vsyncs, but if the frame times happen to fall near vsyncs and change between just before and just after then there could be frames alternating between 2 and 4 vsyncs. The code changes frame timing by up to one quarter vsync interval to avoid this. The above functionality depends on having reliable vsync timing information available. The display refresh rate is not directly provided by the VDPAU API. The current code uses information from the XF86VidMode extension if available; I'm not sure how common cases where that is inaccurate are. The refresh rate can be specified manually if necessary. After the changes in this commit MPlayer now always tries to keep one frame queued for future display using VDPAU's internal timing mechanism (however no more than 50 ms to the future). This should make video playback somewhat more robust against timing inaccuracies caused by system load.
2009-11-15 03:39:22 +01:00
} else if (vc->user_fps == 0) {
configure: uniform the defines to #define HAVE_xxx (0|1) The configure followed 5 different convetions of defines because the next guy always wanted to introduce a new better way to uniform it[1]. For an hypothetic feature 'hurr' you could have had: * #define HAVE_HURR 1 / #undef HAVE_DURR * #define HAVE_HURR / #undef HAVE_DURR * #define CONFIG_HURR 1 / #undef CONFIG_DURR * #define HAVE_HURR 1 / #define HAVE_DURR 0 * #define CONFIG_HURR 1 / #define CONFIG_DURR 0 All is now uniform and uses: * #define HAVE_HURR 1 * #define HAVE_DURR 0 We like definining to 0 as opposed to `undef` bcause it can help spot typos and is very helpful when doing big reorganizations in the code. [1]: http://xkcd.com/927/ related
2013-07-16 13:28:28 +02:00
#if HAVE_XF86VM
x11: reduce VO mode switching code duplication Some parts for initiating mode switches were duplicated in every VO supporting X11 (except vo_opengl/gl_common, which didn't support mode switching). Move this to x11_common.c. Note that this might be slightly risky: is it really guaranteed that no VO needed to do "special" setup that depends on X parameters changing after a mode switch, such as bit depth, visuals etc.? From what I can see, this shouldn't be the case (X probably can't even change depth on the fly). Even if this should be a one-way road, VM switching is in general very useless, and its implementation buggy, so it can just be removed should unfixable problems arise.
2013-01-27 07:21:10 +01:00
double fps = vo_x11_vm_get_fps(vo);
Implement vsync-aware frame timing for VDPAU Main things added are custom frame dropping for VDPAU to work around the display FPS limit, frame timing adjustment to avoid jitter when video frame times keep falling near vsyncs, and use of VDPAU's timing feature to keep one future frame queued in advance. NVIDIA's VDPAU implementation refuses to change the displayed frame more than once per vsync. This set a limit on how much video could be sped up, and caused problems for nearly all videos on low-FPS video projectors (playing 24 FPS video on a 24 FPS projector would not work reliably as MPlayer may need to slightly speed up the video for AV sync). This commit adds a framedrop mechanism that drops some frames so that no more than one is sent for display per vsync. The code tries to select the dropped frames smartly, selecting the best one to show for each vsync. Because of the timing features needed the drop functionality currently does not work if the correct-pts option is disabled. The code also adjusts frame timing slightly to avoid jitter. If you for example play 24 FPS video content on a 72 FPS display then normally a frame would be shown for 3 vsyncs, but if the frame times happen to fall near vsyncs and change between just before and just after then there could be frames alternating between 2 and 4 vsyncs. The code changes frame timing by up to one quarter vsync interval to avoid this. The above functionality depends on having reliable vsync timing information available. The display refresh rate is not directly provided by the VDPAU API. The current code uses information from the XF86VidMode extension if available; I'm not sure how common cases where that is inaccurate are. The refresh rate can be specified manually if necessary. After the changes in this commit MPlayer now always tries to keep one frame queued for future display using VDPAU's internal timing mechanism (however no more than 50 ms to the future). This should make video playback somewhat more robust against timing inaccuracies caused by system load.
2009-11-15 03:39:22 +01:00
if (!fps)
Some more mp_msg conversions Also add a note to mp_msg.h, since it might be not clear which of the two mechanisms is preferred.
2013-08-23 23:30:09 +02:00
MP_WARN(vo, "Failed to get display FPS\n");
Implement vsync-aware frame timing for VDPAU Main things added are custom frame dropping for VDPAU to work around the display FPS limit, frame timing adjustment to avoid jitter when video frame times keep falling near vsyncs, and use of VDPAU's timing feature to keep one future frame queued in advance. NVIDIA's VDPAU implementation refuses to change the displayed frame more than once per vsync. This set a limit on how much video could be sped up, and caused problems for nearly all videos on low-FPS video projectors (playing 24 FPS video on a 24 FPS projector would not work reliably as MPlayer may need to slightly speed up the video for AV sync). This commit adds a framedrop mechanism that drops some frames so that no more than one is sent for display per vsync. The code tries to select the dropped frames smartly, selecting the best one to show for each vsync. Because of the timing features needed the drop functionality currently does not work if the correct-pts option is disabled. The code also adjusts frame timing slightly to avoid jitter. If you for example play 24 FPS video content on a 72 FPS display then normally a frame would be shown for 3 vsyncs, but if the frame times happen to fall near vsyncs and change between just before and just after then there could be frames alternating between 2 and 4 vsyncs. The code changes frame timing by up to one quarter vsync interval to avoid this. The above functionality depends on having reliable vsync timing information available. The display refresh rate is not directly provided by the VDPAU API. The current code uses information from the XF86VidMode extension if available; I'm not sure how common cases where that is inaccurate are. The refresh rate can be specified manually if necessary. After the changes in this commit MPlayer now always tries to keep one frame queued for future display using VDPAU's internal timing mechanism (however no more than 50 ms to the future). This should make video playback somewhat more robust against timing inaccuracies caused by system load.
2009-11-15 03:39:22 +01:00
else {
vc->vsync_interval = 1e9 / fps;
// This is verbose, but I'm not yet sure how common wrong values are
Some more mp_msg conversions Also add a note to mp_msg.h, since it might be not clear which of the two mechanisms is preferred.
2013-08-23 23:30:09 +02:00
MP_INFO(vo, "Got display refresh rate %.3f Hz.\n", fps);
MP_INFO(vo, "If that value looks wrong give the "
"-vo vdpau:fps=X suboption manually.\n");
Implement vsync-aware frame timing for VDPAU Main things added are custom frame dropping for VDPAU to work around the display FPS limit, frame timing adjustment to avoid jitter when video frame times keep falling near vsyncs, and use of VDPAU's timing feature to keep one future frame queued in advance. NVIDIA's VDPAU implementation refuses to change the displayed frame more than once per vsync. This set a limit on how much video could be sped up, and caused problems for nearly all videos on low-FPS video projectors (playing 24 FPS video on a 24 FPS projector would not work reliably as MPlayer may need to slightly speed up the video for AV sync). This commit adds a framedrop mechanism that drops some frames so that no more than one is sent for display per vsync. The code tries to select the dropped frames smartly, selecting the best one to show for each vsync. Because of the timing features needed the drop functionality currently does not work if the correct-pts option is disabled. The code also adjusts frame timing slightly to avoid jitter. If you for example play 24 FPS video content on a 72 FPS display then normally a frame would be shown for 3 vsyncs, but if the frame times happen to fall near vsyncs and change between just before and just after then there could be frames alternating between 2 and 4 vsyncs. The code changes frame timing by up to one quarter vsync interval to avoid this. The above functionality depends on having reliable vsync timing information available. The display refresh rate is not directly provided by the VDPAU API. The current code uses information from the XF86VidMode extension if available; I'm not sure how common cases where that is inaccurate are. The refresh rate can be specified manually if necessary. After the changes in this commit MPlayer now always tries to keep one frame queued for future display using VDPAU's internal timing mechanism (however no more than 50 ms to the future). This should make video playback somewhat more robust against timing inaccuracies caused by system load.
2009-11-15 03:39:22 +01:00
}
#else
Some more mp_msg conversions Also add a note to mp_msg.h, since it might be not clear which of the two mechanisms is preferred.
2013-08-23 23:30:09 +02:00
MP_INFO(vo, "This binary has been compiled without XF86VidMode support.\n");
MP_INFO(vo, "Can't use vsync-aware timing without manually provided "
"-vo vdpau:fps=X suboption.\n");
Implement vsync-aware frame timing for VDPAU Main things added are custom frame dropping for VDPAU to work around the display FPS limit, frame timing adjustment to avoid jitter when video frame times keep falling near vsyncs, and use of VDPAU's timing feature to keep one future frame queued in advance. NVIDIA's VDPAU implementation refuses to change the displayed frame more than once per vsync. This set a limit on how much video could be sped up, and caused problems for nearly all videos on low-FPS video projectors (playing 24 FPS video on a 24 FPS projector would not work reliably as MPlayer may need to slightly speed up the video for AV sync). This commit adds a framedrop mechanism that drops some frames so that no more than one is sent for display per vsync. The code tries to select the dropped frames smartly, selecting the best one to show for each vsync. Because of the timing features needed the drop functionality currently does not work if the correct-pts option is disabled. The code also adjusts frame timing slightly to avoid jitter. If you for example play 24 FPS video content on a 72 FPS display then normally a frame would be shown for 3 vsyncs, but if the frame times happen to fall near vsyncs and change between just before and just after then there could be frames alternating between 2 and 4 vsyncs. The code changes frame timing by up to one quarter vsync interval to avoid this. The above functionality depends on having reliable vsync timing information available. The display refresh rate is not directly provided by the VDPAU API. The current code uses information from the XF86VidMode extension if available; I'm not sure how common cases where that is inaccurate are. The refresh rate can be specified manually if necessary. After the changes in this commit MPlayer now always tries to keep one frame queued for future display using VDPAU's internal timing mechanism (however no more than 50 ms to the future). This should make video playback somewhat more robust against timing inaccuracies caused by system load.
2009-11-15 03:39:22 +01:00
#endif
} else
Some more mp_msg conversions Also add a note to mp_msg.h, since it might be not clear which of the two mechanisms is preferred.
2013-08-23 23:30:09 +02:00
MP_VERBOSE(vo, "framedrop/timing logic disabled by user.\n");
Implement vsync-aware frame timing for VDPAU Main things added are custom frame dropping for VDPAU to work around the display FPS limit, frame timing adjustment to avoid jitter when video frame times keep falling near vsyncs, and use of VDPAU's timing feature to keep one future frame queued in advance. NVIDIA's VDPAU implementation refuses to change the displayed frame more than once per vsync. This set a limit on how much video could be sped up, and caused problems for nearly all videos on low-FPS video projectors (playing 24 FPS video on a 24 FPS projector would not work reliably as MPlayer may need to slightly speed up the video for AV sync). This commit adds a framedrop mechanism that drops some frames so that no more than one is sent for display per vsync. The code tries to select the dropped frames smartly, selecting the best one to show for each vsync. Because of the timing features needed the drop functionality currently does not work if the correct-pts option is disabled. The code also adjusts frame timing slightly to avoid jitter. If you for example play 24 FPS video content on a 72 FPS display then normally a frame would be shown for 3 vsyncs, but if the frame times happen to fall near vsyncs and change between just before and just after then there could be frames alternating between 2 and 4 vsyncs. The code changes frame timing by up to one quarter vsync interval to avoid this. The above functionality depends on having reliable vsync timing information available. The display refresh rate is not directly provided by the VDPAU API. The current code uses information from the XF86VidMode extension if available; I'm not sure how common cases where that is inaccurate are. The refresh rate can be specified manually if necessary. After the changes in this commit MPlayer now always tries to keep one frame queued for future display using VDPAU's internal timing mechanism (however no more than 50 ms to the future). This should make video playback somewhat more robust against timing inaccuracies caused by system load.
2009-11-15 03:39:22 +01:00
Add support for VDPAU video out, including hardware decoding. git-svn-id: svn://svn.mplayerhq.hu/mplayer/trunk@28617 b3059339-0415-0410-9bf9-f77b7e298cf2
2009-02-16 21:58:13 +01:00
return 0;
}
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
static int set_video_attribute(struct vo *vo, VdpVideoMixerAttribute attr,
vo_vdpau: Check return value when setting video attributes Check the return value when setting any video mixer attribute and print an error message if the operation failed. Also simplify code by changing update_csc_matrix() to use the utility function added for this.
2009-11-17 05:18:14 +01:00
const void *value, char *attr_name)
{
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
struct vdpctx *vc = vo->priv;
vo_vdpau: Check return value when setting video attributes Check the return value when setting any video mixer attribute and print an error message if the operation failed. Also simplify code by changing update_csc_matrix() to use the utility function added for this.
2009-11-17 05:18:14 +01:00
struct vdp_functions *vdp = vc->vdp;
VdpStatus vdp_st;
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 -1;
vo_vdpau: Check return value when setting video attributes Check the return value when setting any video mixer attribute and print an error message if the operation failed. Also simplify code by changing update_csc_matrix() to use the utility function added for this.
2009-11-17 05:18:14 +01:00
vdp_st = vdp->video_mixer_set_attribute_values(vc->video_mixer, 1, &attr,
&value);
if (vdp_st != VDP_STATUS_OK) {
Some more mp_msg conversions Also add a note to mp_msg.h, since it might be not clear which of the two mechanisms is preferred.
2013-08-23 23:30:09 +02:00
MP_ERR(vo, "Error setting video mixer attribute %s: %s\n", attr_name,
vdp->get_error_string(vdp_st));
vo_vdpau: Check return value when setting video attributes Check the return value when setting any video mixer attribute and print an error message if the operation failed. Also simplify code by changing update_csc_matrix() to use the utility function added for this.
2009-11-17 05:18:14 +01:00
return -1;
}
return 0;
}
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
static void update_csc_matrix(struct vo *vo)
{
struct vdpctx *vc = vo->priv;
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, "Updating CSC matrix\n");
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
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
// VdpCSCMatrix happens to be compatible with mplayer's CSC matrix type
// both are float[3][4]
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
VdpCSCMatrix matrix;
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_gl: improve 10-bit YUV->RGB conversion accuracy slightly Modify the YUV->RGB conversion matrix to take into account the difference between the same color value being x/255 in a 8-bit texture and x*256/65535 in a 16-bit texture (actually things are stored as x*4/65535 for 10-bit color, but that can be ignored here). This 0.4 % difference in the shader float value could make shades of gray in 10-bit (or generally more than 8 bit) YUV produce RGB values with green slightly higher than red/blue.
2012-03-08 04:25:33 +01:00
struct mp_csp_params cparams = {
.colorspace = vc->colorspace, .input_bits = 8, .texture_bits = 8 };
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
mp_csp_copy_equalizer_values(&cparams, &vc->video_eq);
mp_get_yuv2rgb_coeffs(&cparams, matrix);
vo_vdpau: add option for studio level output Add -vo vdpau suboption "studio" to produce output in RGB range 16-235. Man page description mostly taken from a patch by Lauri Mylläri (but not code). Also slightly tweak the description of two other suboptions on the man page.
2010-05-12 02:52:43 +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
set_video_attribute(vo, VDP_VIDEO_MIXER_ATTRIBUTE_CSC_MATRIX,
vo_vdpau: Check return value when setting video attributes Check the return value when setting any video mixer attribute and print an error message if the operation failed. Also simplify code by changing update_csc_matrix() to use the utility function added for this.
2009-11-17 05:18:14 +01:00
&matrix, "CSC matrix");
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
}
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
#define SET_VIDEO_ATTR(attr_name, attr_type, value) set_video_attribute(vo, \
vo_vdpau: Check return value when setting video attributes Check the return value when setting any video mixer attribute and print an error message if the operation failed. Also simplify code by changing update_csc_matrix() to use the utility function added for this.
2009-11-17 05:18:14 +01:00
VDP_VIDEO_MIXER_ATTRIBUTE_ ## attr_name, &(attr_type){value},\
# attr_name)
vo_vdpau: Replace global function table with context variable
2009-05-06 20:04:37 +02:00
static int create_vdp_mixer(struct vo *vo, VdpChromaType vdp_chroma_type)
{
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
#define VDP_NUM_MIXER_PARAMETER 3
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
#define MAX_NUM_FEATURES 6
Add support for VDPAU deinterlacing, pullup, denoise and sharpening. Deinterlacing can not yet be toggled at runtime, and actually it does not seem to work at all... git-svn-id: svn://svn.mplayerhq.hu/mplayer/trunk@28673 b3059339-0415-0410-9bf9-f77b7e298cf2
2009-02-20 10:45:48 +01:00
int 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
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->video_mixer != VDP_INVALID_HANDLE)
return 0;
Add support for VDPAU deinterlacing, pullup, denoise and sharpening. Deinterlacing can not yet be toggled at runtime, and actually it does not seem to work at all... git-svn-id: svn://svn.mplayerhq.hu/mplayer/trunk@28673 b3059339-0415-0410-9bf9-f77b7e298cf2
2009-02-20 10:45:48 +01:00
int feature_count = 0;
VdpVideoMixerFeature features[MAX_NUM_FEATURES];
VdpBool feature_enables[MAX_NUM_FEATURES];
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
static const VdpVideoMixerParameter parameters[VDP_NUM_MIXER_PARAMETER] = {
VDP_VIDEO_MIXER_PARAMETER_VIDEO_SURFACE_WIDTH,
VDP_VIDEO_MIXER_PARAMETER_VIDEO_SURFACE_HEIGHT,
vo_vdpau.c: cosmetics
2009-05-09 17:08:30 +02:00
VDP_VIDEO_MIXER_PARAMETER_CHROMA_TYPE,
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
};
const void *const parameter_values[VDP_NUM_MIXER_PARAMETER] = {
vo_vdpau: Move things to context struct
2009-05-06 22:42:24 +02:00
&vc->vid_width,
&vc->vid_height,
vo_vdpau.c: cosmetics
2009-05-09 17:08:30 +02:00
&vdp_chroma_type,
Add support for VDPAU video out, including hardware decoding. git-svn-id: svn://svn.mplayerhq.hu/mplayer/trunk@28617 b3059339-0415-0410-9bf9-f77b7e298cf2
2009-02-16 21:58:13 +01:00
};
Cosmetics: Fix whitespace. git-svn-id: svn://svn.mplayerhq.hu/mplayer/trunk@28969 b3059339-0415-0410-9bf9-f77b7e298cf2
2009-03-15 22:26:10 +01:00
features[feature_count++] = VDP_VIDEO_MIXER_FEATURE_DEINTERLACE_TEMPORAL;
vo_vdpau: allow "deint=-N" to specify mode without enabling deint Allow negative values of the "deint" parameter and make them select the same deinterlacing mode as the corresponding positive value, but without enabling deinterlace on startup. This is useful for configuration files. Also tweak the overall manpage description of vo_vdpau a bit to make it sound less as if the VO would be for hardware acceleration only.
2011-01-04 22:51:31 +01:00
if (vc->deint_type == 4)
vo_vdpau.c: cosmetics
2009-05-09 17:08:30 +02:00
features[feature_count++] =
VDP_VIDEO_MIXER_FEATURE_DEINTERLACE_TEMPORAL_SPATIAL;
vo_vdpau: Move things to context struct
2009-05-06 22:42:24 +02:00
if (vc->pullup)
Add support for VDPAU deinterlacing, pullup, denoise and sharpening. Deinterlacing can not yet be toggled at runtime, and actually it does not seem to work at all... git-svn-id: svn://svn.mplayerhq.hu/mplayer/trunk@28673 b3059339-0415-0410-9bf9-f77b7e298cf2
2009-02-20 10:45:48 +01:00
features[feature_count++] = VDP_VIDEO_MIXER_FEATURE_INVERSE_TELECINE;
vo_vdpau: Move things to context struct
2009-05-06 22:42:24 +02:00
if (vc->denoise)
Add support for VDPAU deinterlacing, pullup, denoise and sharpening. Deinterlacing can not yet be toggled at runtime, and actually it does not seem to work at all... git-svn-id: svn://svn.mplayerhq.hu/mplayer/trunk@28673 b3059339-0415-0410-9bf9-f77b7e298cf2
2009-02-20 10:45:48 +01:00
features[feature_count++] = VDP_VIDEO_MIXER_FEATURE_NOISE_REDUCTION;
vo_vdpau: Move things to context struct
2009-05-06 22:42:24 +02:00
if (vc->sharpen)
Add support for VDPAU deinterlacing, pullup, denoise and sharpening. Deinterlacing can not yet be toggled at runtime, and actually it does not seem to work at all... git-svn-id: svn://svn.mplayerhq.hu/mplayer/trunk@28673 b3059339-0415-0410-9bf9-f77b7e298cf2
2009-02-20 10:45:48 +01:00
features[feature_count++] = VDP_VIDEO_MIXER_FEATURE_SHARPNESS;
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
if (vc->hqscaling) {
VdpVideoMixerFeature hqscaling_feature =
VDP_VIDEO_MIXER_FEATURE_HIGH_QUALITY_SCALING_L1 + vc->hqscaling-1;
VdpBool hqscaling_available;
vdp_st = vdp->video_mixer_query_feature_support(vc->vdp_device,
hqscaling_feature,
&hqscaling_available);
CHECK_ST_ERROR("Error when calling video_mixer_query_feature_support");
if (hqscaling_available)
features[feature_count++] = hqscaling_feature;
else
Some more mp_msg conversions Also add a note to mp_msg.h, since it might be not clear which of the two mechanisms is preferred.
2013-08-23 23:30:09 +02:00
MP_ERR(vo, "Your hardware or VDPAU library does not support "
"requested hqscaling.\n");
vo_vdpau.c: Fix compilation with old libvdpau versions Misplaced #endif broke compilation with old libvdpau versions that lack VDP_VIDEO_MIXER_FEATURE_HIGH_QUALITY_SCALING_L1 #define. Also add missing space to the text in related mp_msg() call.
2009-11-29 00:32:30 +01:00
}
Add support for VDPAU deinterlacing, pullup, denoise and sharpening. Deinterlacing can not yet be toggled at runtime, and actually it does not seem to work at all... git-svn-id: svn://svn.mplayerhq.hu/mplayer/trunk@28673 b3059339-0415-0410-9bf9-f77b7e298cf2
2009-02-20 10:45:48 +01:00
vo_vdpau: Move things to context struct
2009-05-06 22:42:24 +02:00
vdp_st = vdp->video_mixer_create(vc->vdp_device, feature_count, features,
vo_vdpau.c: cosmetics
2009-05-09 17:08:30 +02:00
VDP_NUM_MIXER_PARAMETER,
parameters, parameter_values,
&vc->video_mixer);
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
CHECK_ST_ERROR("Error when calling vdp_video_mixer_create");
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
for (i = 0; i < feature_count; i++)
feature_enables[i] = VDP_TRUE;
vo_vdpau: Move things to context struct
2009-05-06 22:42:24 +02:00
if (vc->deint < 3)
Initial support for advanced VDPAU deinterlacers (software-decoded video only). With a lot of help from Reimar git-svn-id: svn://svn.mplayerhq.hu/mplayer/trunk@28968 b3059339-0415-0410-9bf9-f77b7e298cf2
2009-03-15 22:20:06 +01:00
feature_enables[0] = VDP_FALSE;
vo_vdpau: allow "deint=-N" to specify mode without enabling deint Allow negative values of the "deint" parameter and make them select the same deinterlacing mode as the corresponding positive value, but without enabling deinterlace on startup. This is useful for configuration files. Also tweak the overall manpage description of vo_vdpau a bit to make it sound less as if the VO would be for hardware acceleration only.
2011-01-04 22:51:31 +01:00
if (vc->deint_type == 4 && vc->deint < 4)
feature_enables[1] = VDP_FALSE;
vo_vdpau: Check return value when setting video mixer features
2009-11-17 22:22:10 +01:00
if (feature_count) {
vdp_st = vdp->video_mixer_set_feature_enables(vc->video_mixer,
feature_count, features,
feature_enables);
CHECK_ST_WARNING("Error calling vdp_video_mixer_set_feature_enables");
}
vo_vdpau: Move things to context struct
2009-05-06 22:42:24 +02:00
if (vc->denoise)
vo_vdpau: Check return value when setting video attributes Check the return value when setting any video mixer attribute and print an error message if the operation failed. Also simplify code by changing update_csc_matrix() to use the utility function added for this.
2009-11-17 05:18:14 +01:00
SET_VIDEO_ATTR(NOISE_REDUCTION_LEVEL, float, vc->denoise);
vo_vdpau: Move things to context struct
2009-05-06 22:42:24 +02:00
if (vc->sharpen)
vo_vdpau: Check return value when setting video attributes Check the return value when setting any video mixer attribute and print an error message if the operation failed. Also simplify code by changing update_csc_matrix() to use the utility function added for this.
2009-11-17 05:18:14 +01:00
SET_VIDEO_ATTR(SHARPNESS_LEVEL, float, vc->sharpen);
vo_vdpau: Move things to context struct
2009-05-06 22:42:24 +02:00
if (!vc->chroma_deint)
vo_vdpau: Check return value when setting video attributes Check the return value when setting any video mixer attribute and print an error message if the operation failed. Also simplify code by changing update_csc_matrix() to use the utility function added for this.
2009-11-17 05:18:14 +01:00
SET_VIDEO_ATTR(SKIP_CHROMA_DEINTERLACE, uint8_t, 1);
Add support for VDPAU deinterlacing, pullup, denoise and sharpening. Deinterlacing can not yet be toggled at runtime, and actually it does not seem to work at all... git-svn-id: svn://svn.mplayerhq.hu/mplayer/trunk@28673 b3059339-0415-0410-9bf9-f77b7e298cf2
2009-02-20 10:45:48 +01:00
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
update_csc_matrix(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
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: Move things to context struct
2009-05-06 22:42:24 +02:00
if (vc->video_mixer != VDP_INVALID_HANDLE) {
vdp_st = vdp->video_mixer_destroy(vc->video_mixer);
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
CHECK_ST_WARNING("Error when calling vdp_video_mixer_destroy");
Only check for vdp_video_mixer_destroy failure when we actually executed that function. git-svn-id: svn://svn.mplayerhq.hu/mplayer/trunk@28711 b3059339-0415-0410-9bf9-f77b7e298cf2
2009-02-23 10:22:57 +01:00
}
vo_vdpau: Move things to context struct
2009-05-06 22:42:24 +02:00
vc->video_mixer = VDP_INVALID_HANDLE;
vo_vdpau: fix screenshots Attempting to take screenshots printed vdpau errors on the terminal, and the resulting screenshots were filled with black. The problem was that that the screenshot code tried to use an unallocated output surface (the one at vc->output_surfaces[vc->num_output_surfaces]). This used to refer to the last allocated surface, until this was changed by a recently merged commit. That commit also added a separate screenshot surface. The merge somehow went wrong, and that part was not integrated. <uau> wm4: you used an earlier buggy version of a commit OK...
2012-10-21 00:48:01 +02:00
if (vc->screenshot_surface != VDP_INVALID_HANDLE) {
vdp_st = vdp->output_surface_destroy(vc->screenshot_surface);
CHECK_ST_WARNING("Error when calling vdp_output_surface_destroy");
}
vc->screenshot_surface = VDP_INVALID_HANDLE;
vo_vdpau: add RGB support Apparently this was dropped some years ago, but judging from MPlayer's handling of this, the original code wasn't so great anyway. The new code handling clearing of panscan borders correctly, and integrates better with the YUV path. (Although the VDPAU API sure makes this annoying with its separate surface types for RGB.) Note that we create 5 surfaces for some reason - I don't think this makes too much sense (because we can't use the deinterlacer with RGB surfaces), but at least it reduces the amount of differences with the YUV code path. Clearing the borders is done by drawing a single black pixel over the window. This sounds pretty dumb, but it appears to work well, and there is no other API for that. (One could try to use the video mixer for this purpose, since it has all kinds of features, including compositing multiple RGBA surfaces and clearing the window background. But it would require an invisible dummy video surface to make the video mixer happy, and that's getting too messy.)
2013-08-18 05:12:21 +02:00
for (int n = 0; n < NUM_BUFFERED_VIDEO; n++) {
if (vc->rgb_surfaces[n] != VDP_INVALID_HANDLE) {
vdp_st = vdp->output_surface_destroy(vc->rgb_surfaces[n]);
CHECK_ST_WARNING("Error when calling vdp_output_surface_destroy");
}
vc->rgb_surfaces[n] = VDP_INVALID_HANDLE;
}
if (vc->black_pixel != VDP_INVALID_HANDLE) {
vdp_st = vdp->output_surface_destroy(vc->black_pixel);
CHECK_ST_WARNING("Error when calling vdp_output_surface_destroy");
}
vc->black_pixel = VDP_INVALID_HANDLE;
}
static int get_rgb_format(int imgfmt)
{
switch (imgfmt) {
case IMGFMT_BGR32: return VDP_RGBA_FORMAT_B8G8R8A8;
default: return -1;
}
Add support for VDPAU video out, including hardware decoding. git-svn-id: svn://svn.mplayerhq.hu/mplayer/trunk@28617 b3059339-0415-0410-9bf9-f77b7e298cf2
2009-02-16 21:58:13 +01:00
}
cosmetics: Add two missing "static" Add missing 'static' to internal functions in vo_xv.c and vo_vdpau.c.
2009-10-22 03:21:14 +02:00
static int initialize_vdpau_objects(struct vo *vo)
vo_vdpau: Support recovering from VDPAU display preemption Add code to reinitialize all VDPAU objects if a display preemption condition occurs. Reinitializing them in the middle of playback will cause video corruption at least until the next keyframe when using hardware decoding, but decoding does seem to recover after a keyframe.
2009-09-07 01:02:24 +02:00
{
struct vdpctx *vc = vo->priv;
vo_vdpau: add RGB support Apparently this was dropped some years ago, but judging from MPlayer's handling of this, the original code wasn't so great anyway. The new code handling clearing of panscan borders correctly, and integrates better with the YUV path. (Although the VDPAU API sure makes this annoying with its separate surface types for RGB.) Note that we create 5 surfaces for some reason - I don't think this makes too much sense (because we can't use the deinterlacer with RGB surfaces), but at least it reduces the amount of differences with the YUV code path. Clearing the borders is done by drawing a single black pixel over the window. This sounds pretty dumb, but it appears to work well, and there is no other API for that. (One could try to use the video mixer for this purpose, since it has all kinds of features, including compositing multiple RGBA surfaces and clearing the window background. But it would require an invisible dummy video surface to make the video mixer happy, and that's getting too messy.)
2013-08-18 05:12:21 +02:00
struct vdp_functions *vdp = vc->vdp;
VdpStatus vdp_st;
vo_vdpau: Support recovering from VDPAU display preemption Add code to reinitialize all VDPAU objects if a display preemption condition occurs. Reinitializing them in the middle of playback will cause video corruption at least until the next keyframe when using hardware decoding, but decoding does seem to recover after a keyframe.
2009-09-07 01:02:24 +02:00
vdpau: split off decoder parts, use "new" libavcodec vdpau hwaccel API Move the decoder parts from vo_vdpau.c to a new file vdpau_old.c. This file is named so because because it's written against the "old" libavcodec vdpau pseudo-decoder (e.g. "h264_vdpau"). Add support for the "new" libavcodec vdpau support. This was recently added and replaces the "old" vdpau parts. (In fact, Libav is about to deprecate and remove the "old" API without deprecation grace period, so we have to support it now. Moreover, there will probably be no Libav release which supports both, so the transition is even less smooth than we could hope, and we have to support both the old and new API.) Whether the old or new API is used is checked by a configure test: if the new API is found, it is used, otherwise the old API is assumed. Some details might be handled differently. Especially display preemption is a bit problematic with the "new" libavcodec vdpau support: it wants to keep a pointer to a specific vdpau API function (which can be driver specific, because preemption might switch drivers). Also, surface IDs are now directly stored in AVFrames (and mp_images), so they can't be forced to VDP_INVALID_HANDLE on preemption. (This changes even with older libavcodec versions, because mp_image always uses the newer representation to make vo_vdpau.c simpler.) Decoder initialization in the new code tries to deal with codec profiles, while the old code always uses the highest profile per codec. Surface allocation changes. Since the decoder won't call config() in vo_vdpau.c on video size change anymore, we allow allocating surfaces of arbitrary size instead of locking it to what the VO was configured. The non-hwdec code also has slightly different allocation behavior now. Enabling the old vdpau special decoders via e.g. --vd=lavc:h264_vdpau doesn't work anymore (a warning suggesting the --hwdec option is printed instead).
2013-07-28 01:49:45 +02:00
mp_vdpau_get_format(vc->image_format, &vc->vdp_chroma_type,
&vc->vdp_pixel_format);
vo_vdpau: Support recovering from VDPAU display preemption Add code to reinitialize all VDPAU objects if a display preemption condition occurs. Reinitializing them in the middle of playback will cause video corruption at least until the next keyframe when using hardware decoding, but decoding does seem to recover after a keyframe.
2009-09-07 01:02:24 +02:00
if (win_x11_init_vdpau_flip_queue(vo) < 0)
return -1;
vo_vdpau: add RGB support Apparently this was dropped some years ago, but judging from MPlayer's handling of this, the original code wasn't so great anyway. The new code handling clearing of panscan borders correctly, and integrates better with the YUV path. (Although the VDPAU API sure makes this annoying with its separate surface types for RGB.) Note that we create 5 surfaces for some reason - I don't think this makes too much sense (because we can't use the deinterlacer with RGB surfaces), but at least it reduces the amount of differences with the YUV code path. Clearing the borders is done by drawing a single black pixel over the window. This sounds pretty dumb, but it appears to work well, and there is no other API for that. (One could try to use the video mixer for this purpose, since it has all kinds of features, including compositing multiple RGBA surfaces and clearing the window background. But it would require an invisible dummy video surface to make the video mixer happy, and that's getting too messy.)
2013-08-18 05:12:21 +02:00
if (vc->rgb_mode) {
int format = get_rgb_format(vc->image_format);
for (int n = 0; n < NUM_BUFFERED_VIDEO; n++) {
vdp_st = vdp->output_surface_create(vc->vdp_device,
format,
vc->vid_width, vc->vid_height,
&vc->rgb_surfaces[n]);
CHECK_ST_ERROR("Allocating RGB surface");
}
vdp_st = vdp->output_surface_create(vc->vdp_device, OUTPUT_RGBA_FORMAT,
1, 1, &vc->black_pixel);
CHECK_ST_ERROR("Allocating clearing surface");
const char data[4] = {0};
vdp_st = vdp->output_surface_put_bits_native(vc->black_pixel,
(const void*[]){data},
(uint32_t[]){4}, NULL);
CHECK_ST_ERROR("Initializing clearing surface");
} else {
if (create_vdp_mixer(vo, vc->vdp_chroma_type) < 0)
return -1;
}
vo_vdpau: Support recovering from VDPAU display preemption Add code to reinitialize all VDPAU objects if a display preemption condition occurs. Reinitializing them in the middle of playback will cause video corruption at least until the next keyframe when using hardware decoding, but decoding does seem to recover after a keyframe.
2009-09-07 01:02:24 +02:00
vo_vdpau: don't blank screen on VOCTRL_RESET vo_vdpau is the only VO which implements VOCTRL_RESET. Redrawing the last output frame is hard, because the output could consist of several source video frames with certain types of post-processing (deinterlacing). Implement redrawing as special case by keeping the previous video frames aside until at least one new frame is decoded. This improves the previous commit, but is separate, because it's rather complicated.
2013-10-01 23:45:30 +02:00
forget_frames(vo, false);
vo_vdpau: Support recovering from VDPAU display preemption Add code to reinitialize all VDPAU objects if a display preemption condition occurs. Reinitializing them in the middle of playback will cause video corruption at least until the next keyframe when using hardware decoding, but decoding does seem to recover after a keyframe.
2009-09-07 01:02:24 +02:00
resize(vo);
return 0;
}
static void mark_vdpau_objects_uninitialized(struct vo *vo)
{
struct vdpctx *vc = vo->priv;
vo_vdpau: add RGB support Apparently this was dropped some years ago, but judging from MPlayer's handling of this, the original code wasn't so great anyway. The new code handling clearing of panscan borders correctly, and integrates better with the YUV path. (Although the VDPAU API sure makes this annoying with its separate surface types for RGB.) Note that we create 5 surfaces for some reason - I don't think this makes too much sense (because we can't use the deinterlacer with RGB surfaces), but at least it reduces the amount of differences with the YUV code path. Clearing the borders is done by drawing a single black pixel over the window. This sounds pretty dumb, but it appears to work well, and there is no other API for that. (One could try to use the video mixer for this purpose, since it has all kinds of features, including compositing multiple RGBA surfaces and clearing the window background. But it would require an invisible dummy video surface to make the video mixer happy, and that's getting too messy.)
2013-08-18 05:12:21 +02:00
for (int i = 0; i < NUM_BUFFERED_VIDEO; i++)
vc->rgb_surfaces[i] = VDP_INVALID_HANDLE;
vo_vdpau: don't blank screen on VOCTRL_RESET vo_vdpau is the only VO which implements VOCTRL_RESET. Redrawing the last output frame is hard, because the output could consist of several source video frames with certain types of post-processing (deinterlacing). Implement redrawing as special case by keeping the previous video frames aside until at least one new frame is decoded. This improves the previous commit, but is separate, because it's rather complicated.
2013-10-01 23:45:30 +02:00
forget_frames(vo, false);
vo_vdpau: add RGB support Apparently this was dropped some years ago, but judging from MPlayer's handling of this, the original code wasn't so great anyway. The new code handling clearing of panscan borders correctly, and integrates better with the YUV path. (Although the VDPAU API sure makes this annoying with its separate surface types for RGB.) Note that we create 5 surfaces for some reason - I don't think this makes too much sense (because we can't use the deinterlacer with RGB surfaces), but at least it reduces the amount of differences with the YUV code path. Clearing the borders is done by drawing a single black pixel over the window. This sounds pretty dumb, but it appears to work well, and there is no other API for that. (One could try to use the video mixer for this purpose, since it has all kinds of features, including compositing multiple RGBA surfaces and clearing the window background. But it would require an invisible dummy video surface to make the video mixer happy, and that's getting too messy.)
2013-08-18 05:12:21 +02:00
vc->black_pixel = VDP_INVALID_HANDLE;
vo_vdpau: Support 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->video_mixer = VDP_INVALID_HANDLE;
vc->flip_queue = VDP_INVALID_HANDLE;
vc->flip_target = VDP_INVALID_HANDLE;
vo_vdpau: split bitmap packing code into a separate file Split the vo_vdpau code that calculates how to pack all subtitle bitmaps into a larger surface into a separate file. This will allow using it in other VOs. Conflicts: Makefile libvo/vo_vdpau.c Note: this commit does the same as an earlier commit by me (4010dd0b1a27e3996). My commit added the vo_vdpau packer code as eosd_packer.c, while this commit by uau uses bitmap_packer.c. Since bitmap_packer.c has a different interface, and because there are more commits changing OSD rendering coming, I will pick uau's version. However, vo_gl, vo_gl3 and vo_direct3d are still using eosd_packer.c, so to make the transition easier, don't delete eosd_packer.c yet.
2012-08-26 18:00:26 +02:00
for (int i = 0; i < MAX_OUTPUT_SURFACES; i++)
vo_vdpau: Support recovering from VDPAU display preemption Add code to reinitialize all VDPAU objects if a display preemption condition occurs. Reinitializing them in the middle of playback will cause video corruption at least until the next keyframe when using hardware decoding, but decoding does seem to recover after a keyframe.
2009-09-07 01:02:24 +02:00
vc->output_surfaces[i] = VDP_INVALID_HANDLE;
vo_vdpau: fix screenshots Attempting to take screenshots printed vdpau errors on the terminal, and the resulting screenshots were filled with black. The problem was that that the screenshot code tried to use an unallocated output surface (the one at vc->output_surfaces[vc->num_output_surfaces]). This used to refer to the last allocated surface, until this was changed by a recently merged commit. That commit also added a separate screenshot surface. The merge somehow went wrong, and that part was not integrated. <uau> wm4: you used an earlier buggy version of a commit OK...
2012-10-21 00:48:01 +02:00
vc->screenshot_surface = VDP_INVALID_HANDLE;
vo_vdpau: Support recovering from VDPAU display preemption Add code to reinitialize all VDPAU objects if a display preemption condition occurs. Reinitializing them in the middle of playback will cause video corruption at least until the next keyframe when using hardware decoding, but decoding does seem to recover after a keyframe.
2009-09-07 01:02:24 +02:00
vc->vdp_device = VDP_INVALID_HANDLE;
vo_vdpau: allow multiple EOSD renderers Preparation for using new OSD rendering method.
2012-09-28 21:49:09 +02:00
for (int i = 0; i < MAX_OSD_PARTS; i++) {
VO, sub: refactor Remove VFCTRL_DRAW_OSD, VFCAP_EOSD_FILTER, VFCAP_EOSD_RGBA, VFCAP_EOSD, VOCTRL_DRAW_EOSD, VOCTRL_GET_EOSD_RES, VOCTRL_QUERY_EOSD_FORMAT. Remove draw_osd_with_eosd(), which rendered the OSD by calling VOCTRL_DRAW_EOSD. Change VOs to call osd_draw() directly, which takes a callback as argument. (This basically works like the old OSD API, except multiple OSD bitmap formats are supported and caching is possible.) Remove all mentions of "eosd". It's simply "osd" now. Make OSD size per-OSD-object, as they can be different when using vf_sub. Include display_par/video_par in resolution change detection. Fix the issue with margin borders in vo_corevideo.
2012-10-19 19:25:18 +02:00
struct osd_bitmap_surface *sfc = &vc->osd_surfaces[i];
vo_vdpau: allow multiple EOSD renderers Preparation for using new OSD rendering method.
2012-09-28 21:49:09 +02:00
talloc_free(sfc->packer);
sfc->bitmap_id = sfc->bitmap_pos_id = 0;
VO, sub: refactor Remove VFCTRL_DRAW_OSD, VFCAP_EOSD_FILTER, VFCAP_EOSD_RGBA, VFCAP_EOSD, VOCTRL_DRAW_EOSD, VOCTRL_GET_EOSD_RES, VOCTRL_QUERY_EOSD_FORMAT. Remove draw_osd_with_eosd(), which rendered the OSD by calling VOCTRL_DRAW_EOSD. Change VOs to call osd_draw() directly, which takes a callback as argument. (This basically works like the old OSD API, except multiple OSD bitmap formats are supported and caching is possible.) Remove all mentions of "eosd". It's simply "osd" now. Make OSD size per-OSD-object, as they can be different when using vf_sub. Include display_par/video_par in resolution change detection. Fix the issue with margin borders in vo_corevideo.
2012-10-19 19:25:18 +02:00
*sfc = (struct osd_bitmap_surface){
vo_vdpau: allow multiple EOSD renderers Preparation for using new OSD rendering method.
2012-09-28 21:49:09 +02:00
.surface = VDP_INVALID_HANDLE,
};
}
vo_vdpau: Support recovering from VDPAU display preemption Add code to reinitialize all VDPAU objects if a display preemption condition occurs. Reinitializing them in the middle of playback will cause video corruption at least until the next keyframe when using hardware decoding, but decoding does seem to recover after a keyframe.
2009-09-07 01:02:24 +02:00
vc->output_surface_width = vc->output_surface_height = -1;
}
static int handle_preemption(struct vo *vo)
{
struct vdpctx *vc = vo->priv;
vdpau: move device and video surface management from vo_vdpau.c to vdpau.c The goal is being able to use vdpau decoding independently from vo_vdpau.c.
2013-11-05 22:06:32 +01:00
if (!mp_vdpau_status_ok(vc->mpvdp)) {
vo_vdpau: Support recovering from VDPAU display preemption Add code to reinitialize all VDPAU objects if a display preemption condition occurs. Reinitializing them in the middle of playback will cause video corruption at least until the next keyframe when using hardware decoding, but decoding does seem to recover after a keyframe.
2009-09-07 01:02:24 +02:00
mark_vdpau_objects_uninitialized(vo);
return -1;
}
vdpau: move device and video surface management from vo_vdpau.c to vdpau.c The goal is being able to use vdpau decoding independently from vo_vdpau.c.
2013-11-05 22:06:32 +01:00
if (vc->preemption_counter == vc->mpvdp->preemption_counter)
return 0;
mark_vdpau_objects_uninitialized(vo);
vc->preemption_counter = vc->mpvdp->preemption_counter;
vc->vdp_device = vc->mpvdp->vdp_device;
if (initialize_vdpau_objects(vo) < 0)
return -1;
vo_vdpau: Support recovering from VDPAU display preemption Add code to reinitialize all VDPAU objects if a display preemption condition occurs. Reinitializing them in the middle of playback will cause video corruption at least until the next keyframe when using hardware decoding, but decoding does seem to recover after a keyframe.
2009-09-07 01:02:24 +02:00
return 1;
}
vdpau: split off decoder parts, use "new" libavcodec vdpau hwaccel API Move the decoder parts from vo_vdpau.c to a new file vdpau_old.c. This file is named so because because it's written against the "old" libavcodec vdpau pseudo-decoder (e.g. "h264_vdpau"). Add support for the "new" libavcodec vdpau support. This was recently added and replaces the "old" vdpau parts. (In fact, Libav is about to deprecate and remove the "old" API without deprecation grace period, so we have to support it now. Moreover, there will probably be no Libav release which supports both, so the transition is even less smooth than we could hope, and we have to support both the old and new API.) Whether the old or new API is used is checked by a configure test: if the new API is found, it is used, otherwise the old API is assumed. Some details might be handled differently. Especially display preemption is a bit problematic with the "new" libavcodec vdpau support: it wants to keep a pointer to a specific vdpau API function (which can be driver specific, because preemption might switch drivers). Also, surface IDs are now directly stored in AVFrames (and mp_images), so they can't be forced to VDP_INVALID_HANDLE on preemption. (This changes even with older libavcodec versions, because mp_image always uses the newer representation to make vo_vdpau.c simpler.) Decoder initialization in the new code tries to deal with codec profiles, while the old code always uses the highest profile per codec. Surface allocation changes. Since the decoder won't call config() in vo_vdpau.c on video size change anymore, we allow allocating surfaces of arbitrary size instead of locking it to what the VO was configured. The non-hwdec code also has slightly different allocation behavior now. Enabling the old vdpau special decoders via e.g. --vd=lavc:h264_vdpau doesn't work anymore (a warning suggesting the --hwdec option is printed instead).
2013-07-28 01:49:45 +02:00
static bool status_ok(struct vo *vo)
{
return vo->config_ok && handle_preemption(vo) >= 0;
}
Add support for VDPAU video out, including hardware decoding. git-svn-id: svn://svn.mplayerhq.hu/mplayer/trunk@28617 b3059339-0415-0410-9bf9-f77b7e298cf2
2009-02-16 21:58:13 +01:00
/*
* connect to X server, create and map window, initialize all
* VDPAU objects, create different surfaces etc.
*/
vo_vdpau: Make compile as new-style VO
2009-05-04 02:09:50 +02:00
static int config(struct vo *vo, uint32_t width, uint32_t height,
uint32_t d_width, uint32_t d_height, uint32_t flags,
libvo: remove title argument from struct vo_driver.config This affects only the "new" VO API. The config() title argument was barely used, and it's hardcoded to "MPlayer" in vf_vo.c. The X11 and the Cocoa GUI backends, which are the only ones properly supporting window titles, ignored this argument. Remove the title argument. Add the vo_get_window_title function. All GUI VOs are supposed to use it for the window title.
2011-12-06 20:23:54 +01:00
uint32_t format)
Add support for VDPAU video out, including hardware decoding. git-svn-id: svn://svn.mplayerhq.hu/mplayer/trunk@28617 b3059339-0415-0410-9bf9-f77b7e298cf2
2009-02-16 21:58:13 +01:00
{
vo_vdpau: Move things to context struct
2009-05-06 22:42:24 +02:00
struct vdpctx *vc = vo->priv;
Add support for VDPAU video out, including hardware decoding. git-svn-id: svn://svn.mplayerhq.hu/mplayer/trunk@28617 b3059339-0415-0410-9bf9-f77b7e298cf2
2009-02-16 21:58:13 +01:00
vo_vdpau: Support recovering from VDPAU display preemption Add code to reinitialize all VDPAU objects if a display preemption condition occurs. Reinitializing them in the middle of playback will cause video corruption at least until the next keyframe when using hardware decoding, but decoding does seem to recover after a keyframe.
2009-09-07 01:02:24 +02:00
if (handle_preemption(vo) < 0)
return -1;
vo_vdpau: add support for VFCAP_FLIP Patch by Carl Eugen Hoyos.
2009-11-15 14:50:28 +01:00
vc->flip = flags & VOFLAG_FLIPPING;
vo_vdpau: Move things to context struct
2009-05-06 22:42:24 +02:00
vc->image_format = format;
vc->vid_width = width;
vc->vid_height = height;
vo_vdpau: implement screenshots
2011-10-06 20:46:01 +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
vc->rgb_mode = get_rgb_format(format) >= 0;
vc->deint = vc->rgb_mode ? 0 : vc->user_deint;
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
video/out: rename create_window to config_window create_window is really bad naming, because this function can be called multiple times, while the name implies that it always creates a new window. At least the name config_window is not actively misleading.
2013-02-24 23:32:51 +01:00
vo_x11_config_vo_window(vo, NULL, vo->dx, vo->dy, d_width, d_height,
x11: simplify handling of X Visuals and Colormaps in VOs Don't force VOs to pick an arbitrary default Visual and Colormap. They still can override them if needed. This simplifies the X11 VO interface. Always create a Colormap for simplicity. Using CopyFromParent fails if the selected visual is not the same of that of the parent window, which happens for me with vo_opengl. vo_vdpau and vo_xv explicitly set CWBorderPixel, do that in x11_common instead (it was already done for native windows, but not for slave mode windows). What gl_common did was incorrect in theory: freeing a colormap while a window uses it will change the colormap of the window to "None", and the color mapping for such windows is "undefined".
2013-01-27 12:01:08 +01:00
flags, "vdpau");
Add support for VDPAU video out, including hardware decoding. git-svn-id: svn://svn.mplayerhq.hu/mplayer/trunk@28617 b3059339-0415-0410-9bf9-f77b7e298cf2
2009-02-16 21:58:13 +01:00
vo_vdpau: Support recovering from VDPAU display preemption Add code to reinitialize all VDPAU objects if a display preemption condition occurs. Reinitializing them in the middle of playback will cause video corruption at least until the next keyframe when using hardware decoding, but decoding does seem to recover after a keyframe.
2009-09-07 01:02:24 +02:00
if (initialize_vdpau_objects(vo) < 0)
Add support for VDPAU video out, including hardware decoding. git-svn-id: svn://svn.mplayerhq.hu/mplayer/trunk@28617 b3059339-0415-0410-9bf9-f77b7e298cf2
2009-02-16 21:58:13 +01:00
return -1;
return 0;
}
vo_vdpau: split bitmap packing code into a separate file Split the vo_vdpau code that calculates how to pack all subtitle bitmaps into a larger surface into a separate file. This will allow using it in other VOs. Conflicts: Makefile libvo/vo_vdpau.c Note: this commit does the same as an earlier commit by me (4010dd0b1a27e3996). My commit added the vo_vdpau packer code as eosd_packer.c, while this commit by uau uses bitmap_packer.c. Since bitmap_packer.c has a different interface, and because there are more commits changing OSD rendering coming, I will pick uau's version. However, vo_gl, vo_gl3 and vo_direct3d are still using eosd_packer.c, so to make the transition easier, don't delete eosd_packer.c yet.
2012-08-26 18:00:26 +02:00
static struct bitmap_packer *make_packer(struct vo *vo, VdpRGBAFormat format)
Add support for VDPAU video out, including hardware decoding. git-svn-id: svn://svn.mplayerhq.hu/mplayer/trunk@28617 b3059339-0415-0410-9bf9-f77b7e298cf2
2009-02-16 21:58:13 +01:00
{
vo_vdpau: Replace global function table with context variable
2009-05-06 20:04:37 +02:00
struct vdpctx *vc = vo->priv;
struct vdp_functions *vdp = vc->vdp;
vo_vdpau.c: cosmetics
2009-05-09 17:08:30 +02:00
vo_vdpau: split bitmap packing code into a separate file Split the vo_vdpau code that calculates how to pack all subtitle bitmaps into a larger surface into a separate file. This will allow using it in other VOs. Conflicts: Makefile libvo/vo_vdpau.c Note: this commit does the same as an earlier commit by me (4010dd0b1a27e3996). My commit added the vo_vdpau packer code as eosd_packer.c, while this commit by uau uses bitmap_packer.c. Since bitmap_packer.c has a different interface, and because there are more commits changing OSD rendering coming, I will pick uau's version. However, vo_gl, vo_gl3 and vo_direct3d are still using eosd_packer.c, so to make the transition easier, don't delete eosd_packer.c yet.
2012-08-26 18:00:26 +02:00
struct bitmap_packer *packer = talloc_zero(vo, struct bitmap_packer);
uint32_t w_max = 0, h_max = 0;
VdpStatus vdp_st = vdp->
bitmap_surface_query_capabilities(vc->vdp_device, format,
&(VdpBool){0}, &w_max, &h_max);
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
CHECK_ST_WARNING("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);
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
CHECK_ST_WARNING("OSD: Error when rendering");
EOSD/ASS support for vo_vdpau.c Patch by Grigori G (greg <at> chown ath cx) with minor cosmetic changes by me. git-svn-id: svn://svn.mplayerhq.hu/mplayer/trunk@28710 b3059339-0415-0410-9bf9-f77b7e298cf2
2009-02-23 10:21:57 +01:00
}
}
VO, sub: refactor Remove VFCTRL_DRAW_OSD, VFCAP_EOSD_FILTER, VFCAP_EOSD_RGBA, VFCAP_EOSD, VOCTRL_DRAW_EOSD, VOCTRL_GET_EOSD_RES, VOCTRL_QUERY_EOSD_FORMAT. Remove draw_osd_with_eosd(), which rendered the OSD by calling VOCTRL_DRAW_EOSD. Change VOs to call osd_draw() directly, which takes a callback as argument. (This basically works like the old OSD API, except multiple OSD bitmap formats are supported and caching is possible.) Remove all mentions of "eosd". It's simply "osd" now. Make OSD size per-OSD-object, as they can be different when using vf_sub. Include display_par/video_par in resolution change detection. Fix the issue with margin borders in vo_corevideo.
2012-10-19 19:25:18 +02:00
static void generate_osd_part(struct vo *vo, struct sub_bitmaps *imgs)
vo_vdpau: Replace global function table with context variable
2009-05-06 20:04:37 +02:00
{
struct vdpctx *vc = vo->priv;
struct vdp_functions *vdp = vc->vdp;
EOSD/ASS support for vo_vdpau.c Patch by Grigori G (greg <at> chown ath cx) with minor cosmetic changes by me. git-svn-id: svn://svn.mplayerhq.hu/mplayer/trunk@28710 b3059339-0415-0410-9bf9-f77b7e298cf2
2009-02-23 10:21:57 +01:00
VdpStatus vdp_st;
VO, sub: refactor Remove VFCTRL_DRAW_OSD, VFCAP_EOSD_FILTER, VFCAP_EOSD_RGBA, VFCAP_EOSD, VOCTRL_DRAW_EOSD, VOCTRL_GET_EOSD_RES, VOCTRL_QUERY_EOSD_FORMAT. Remove draw_osd_with_eosd(), which rendered the OSD by calling VOCTRL_DRAW_EOSD. Change VOs to call osd_draw() directly, which takes a callback as argument. (This basically works like the old OSD API, except multiple OSD bitmap formats are supported and caching is possible.) Remove all mentions of "eosd". It's simply "osd" now. Make OSD size per-OSD-object, as they can be different when using vf_sub. Include display_par/video_par in resolution change detection. Fix the issue with margin borders in vo_corevideo.
2012-10-19 19:25:18 +02:00
struct osd_bitmap_surface *sfc = &vc->osd_surfaces[imgs->render_index];
vo_vdpau: split bitmap packing code into a separate file Split the vo_vdpau code that calculates how to pack all subtitle bitmaps into a larger surface into a separate file. This will allow using it in other VOs. Conflicts: Makefile libvo/vo_vdpau.c Note: this commit does the same as an earlier commit by me (4010dd0b1a27e3996). My commit added the vo_vdpau packer code as eosd_packer.c, while this commit by uau uses bitmap_packer.c. Since bitmap_packer.c has a different interface, and because there are more commits changing OSD rendering coming, I will pick uau's version. However, vo_gl, vo_gl3 and vo_direct3d are still using eosd_packer.c, so to make the transition easier, don't delete eosd_packer.c yet.
2012-08-26 18:00:26 +02:00
bool need_upload = false;
libvo, vo_vdpau: make the EOSD packer code from vo_vdpau generic The code in eosd_packer.c/.h is taken from vo_vdpau.c and has been made independent from vdpau API specifics. This allows other VOs, which need to pack the small EOSD images into a large surface for efficiency, to use this code.
2011-10-27 12:07:10 +02:00
vo_vdpau: allow multiple EOSD renderers Preparation for using new OSD rendering method.
2012-09-28 21:49:09 +02:00
if (imgs->bitmap_pos_id == sfc->bitmap_pos_id)
vo_vdpau: split bitmap packing code into a separate file Split the vo_vdpau code that calculates how to pack all subtitle bitmaps into a larger surface into a separate file. This will allow using it in other VOs. Conflicts: Makefile libvo/vo_vdpau.c Note: this commit does the same as an earlier commit by me (4010dd0b1a27e3996). My commit added the vo_vdpau packer code as eosd_packer.c, while this commit by uau uses bitmap_packer.c. Since bitmap_packer.c has a different interface, and because there are more commits changing OSD rendering coming, I will pick uau's version. However, vo_gl, vo_gl3 and vo_direct3d are still using eosd_packer.c, so to make the transition easier, don't delete eosd_packer.c yet.
2012-08-26 18:00:26 +02:00
return; // Nothing changed and we still have the old data
libvo, vo_vdpau: make the EOSD packer code from vo_vdpau generic The code in eosd_packer.c/.h is taken from vo_vdpau.c and has been made independent from vdpau API specifics. This allows other VOs, which need to pack the small EOSD images into a large surface for efficiency, to use this code.
2011-10-27 12:07:10 +02:00
vo_vdpau: allow multiple EOSD renderers Preparation for using new OSD rendering method.
2012-09-28 21:49:09 +02:00
sfc->render_count = 0;
vo_vdpau: split bitmap packing code into a separate file Split the vo_vdpau code that calculates how to pack all subtitle bitmaps into a larger surface into a separate file. This will allow using it in other VOs. Conflicts: Makefile libvo/vo_vdpau.c Note: this commit does the same as an earlier commit by me (4010dd0b1a27e3996). My commit added the vo_vdpau packer code as eosd_packer.c, while this commit by uau uses bitmap_packer.c. Since bitmap_packer.c has a different interface, and because there are more commits changing OSD rendering coming, I will pick uau's version. However, vo_gl, vo_gl3 and vo_direct3d are still using eosd_packer.c, so to make the transition easier, don't delete eosd_packer.c yet.
2012-08-26 18:00:26 +02:00
sub, vo_gl3, vo_vdpau: exit early if there are no sub-images to draw libass may always return a full change if no subtitle images are rendered in some cases (empty tracks). Also, a full change despite empty sub-images list may be reported on initialization. Avoid invoking odd special cases in the VO code by always exiting early if the sub-image list is empty. Note that at least for OSD, the code in sub.c doesn't even send a request VOCTRL_DRAW_EOSD if the image list is empty. But the subtitle rendering code in vf_vo.c is independent from this (at least for now).
2012-10-02 00:25:06 +02:00
if (imgs->format == SUBBITMAP_EMPTY || imgs->num_parts == 0)
subs, vo_vdpau: support RGBA color for PGS subtitles Support passing bitmap subtitles to VOs in full RGBA color, and implement this for libavcodec-decoded subtitle formats on decoding side and vo_vdpau on display side. Currently this is enabled for PGS (blu-ray) and DVB subtitles. VDPAU seems to have sampling issues similar to known GL ones when drawing a sub-rectangle from a larger texture with scaling, where adjacent pixels outside the specified source rectangle affect the result. As the bitmap subtitles may be scaled, add padding support to the bitmap packer code. In principle, this could be used for colored DVD subtitles too. However, the libavcodec DVD decoder lacks parts of the resolution and palette handling that are present in spudec.c. Conflicts: libvo/vo_gl.c sub/dec_sub.h sub/sd_lavc.c
2012-08-31 14:42:30 +02:00
return;
vo_vdpau: split bitmap packing code into a separate file Split the vo_vdpau code that calculates how to pack all subtitle bitmaps into a larger surface into a separate file. This will allow using it in other VOs. Conflicts: Makefile libvo/vo_vdpau.c Note: this commit does the same as an earlier commit by me (4010dd0b1a27e3996). My commit added the vo_vdpau packer code as eosd_packer.c, while this commit by uau uses bitmap_packer.c. Since bitmap_packer.c has a different interface, and because there are more commits changing OSD rendering coming, I will pick uau's version. However, vo_gl, vo_gl3 and vo_direct3d are still using eosd_packer.c, so to make the transition easier, don't delete eosd_packer.c yet.
2012-08-26 18:00:26 +02:00
vo_vdpau: allow multiple EOSD renderers Preparation for using new OSD rendering method.
2012-09-28 21:49:09 +02:00
if (imgs->bitmap_id == sfc->bitmap_id)
VO, sub: refactor Remove VFCTRL_DRAW_OSD, VFCAP_EOSD_FILTER, VFCAP_EOSD_RGBA, VFCAP_EOSD, VOCTRL_DRAW_EOSD, VOCTRL_GET_EOSD_RES, VOCTRL_QUERY_EOSD_FORMAT. Remove draw_osd_with_eosd(), which rendered the OSD by calling VOCTRL_DRAW_EOSD. Change VOs to call osd_draw() directly, which takes a callback as argument. (This basically works like the old OSD API, except multiple OSD bitmap formats are supported and caching is possible.) Remove all mentions of "eosd". It's simply "osd" now. Make OSD size per-OSD-object, as they can be different when using vf_sub. Include display_par/video_par in resolution change detection. Fix the issue with margin borders in vo_corevideo.
2012-10-19 19:25:18 +02:00
goto osd_skip_upload;
libvo, vo_vdpau: make the EOSD packer code from vo_vdpau generic The code in eosd_packer.c/.h is taken from vo_vdpau.c and has been made independent from vdpau API specifics. This allows other VOs, which need to pack the small EOSD images into a large surface for efficiency, to use this code.
2011-10-27 12:07:10 +02:00
vo_vdpau: split bitmap packing code into a separate file Split the vo_vdpau code that calculates how to pack all subtitle bitmaps into a larger surface into a separate file. This will allow using it in other VOs. Conflicts: Makefile libvo/vo_vdpau.c Note: this commit does the same as an earlier commit by me (4010dd0b1a27e3996). My commit added the vo_vdpau packer code as eosd_packer.c, while this commit by uau uses bitmap_packer.c. Since bitmap_packer.c has a different interface, and because there are more commits changing OSD rendering coming, I will pick uau's version. However, vo_gl, vo_gl3 and vo_direct3d are still using eosd_packer.c, so to make the transition easier, don't delete eosd_packer.c yet.
2012-08-26 18:00:26 +02:00
need_upload = true;
subs, vo_vdpau: support RGBA color for PGS subtitles Support passing bitmap subtitles to VOs in full RGBA color, and implement this for libavcodec-decoded subtitle formats on decoding side and vo_vdpau on display side. Currently this is enabled for PGS (blu-ray) and DVB subtitles. VDPAU seems to have sampling issues similar to known GL ones when drawing a sub-rectangle from a larger texture with scaling, where adjacent pixels outside the specified source rectangle affect the result. As the bitmap subtitles may be scaled, add padding support to the bitmap packer code. In principle, this could be used for colored DVD subtitles too. However, the libavcodec DVD decoder lacks parts of the resolution and palette handling that are present in spudec.c. Conflicts: libvo/vo_gl.c sub/dec_sub.h sub/sd_lavc.c
2012-08-31 14:42:30 +02:00
VdpRGBAFormat format;
int format_size;
sub: create sub_bitmap array even when using libass One sub_bitmaps struct could contain either a libass ASS_Image list, or a mplayer native list of sub-bitmaps. This caused code duplication in vo_vdpau.c and bitmap_packer.c. Avoid this by creating such a sub_bitmap array even with libass. This basically copies the list and recreates it in mplayer's native format. It gets rid of the code duplication, and will make implementing extended subtitle and OSD rendering in other VOs easier. Also do some cosmetic changes and other preparations for the following commits.
2012-09-28 21:19:36 +02:00
switch (imgs->format) {
subs, vo_vdpau: support RGBA color for PGS subtitles Support passing bitmap subtitles to VOs in full RGBA color, and implement this for libavcodec-decoded subtitle formats on decoding side and vo_vdpau on display side. Currently this is enabled for PGS (blu-ray) and DVB subtitles. VDPAU seems to have sampling issues similar to known GL ones when drawing a sub-rectangle from a larger texture with scaling, where adjacent pixels outside the specified source rectangle affect the result. As the bitmap subtitles may be scaled, add padding support to the bitmap packer code. In principle, this could be used for colored DVD subtitles too. However, the libavcodec DVD decoder lacks parts of the resolution and palette handling that are present in spudec.c. Conflicts: libvo/vo_gl.c sub/dec_sub.h sub/sd_lavc.c
2012-08-31 14:42:30 +02:00
case SUBBITMAP_LIBASS:
format = VDP_RGBA_FORMAT_A8;
format_size = 1;
break;
case SUBBITMAP_RGBA:
format = VDP_RGBA_FORMAT_B8G8R8A8;
format_size = 4;
break;
default:
abort();
};
if (sfc->format != format) {
talloc_free(sfc->packer);
sfc->packer = NULL;
};
sfc->format = format;
vo_vdpau: split bitmap packing code into a separate file Split the vo_vdpau code that calculates how to pack all subtitle bitmaps into a larger surface into a separate file. This will allow using it in other VOs. Conflicts: Makefile libvo/vo_vdpau.c Note: this commit does the same as an earlier commit by me (4010dd0b1a27e3996). My commit added the vo_vdpau packer code as eosd_packer.c, while this commit by uau uses bitmap_packer.c. Since bitmap_packer.c has a different interface, and because there are more commits changing OSD rendering coming, I will pick uau's version. However, vo_gl, vo_gl3 and vo_direct3d are still using eosd_packer.c, so to make the transition easier, don't delete eosd_packer.c yet.
2012-08-26 18:00:26 +02:00
if (!sfc->packer)
subs, vo_vdpau: support RGBA color for PGS subtitles Support passing bitmap subtitles to VOs in full RGBA color, and implement this for libavcodec-decoded subtitle formats on decoding side and vo_vdpau on display side. Currently this is enabled for PGS (blu-ray) and DVB subtitles. VDPAU seems to have sampling issues similar to known GL ones when drawing a sub-rectangle from a larger texture with scaling, where adjacent pixels outside the specified source rectangle affect the result. As the bitmap subtitles may be scaled, add padding support to the bitmap packer code. In principle, this could be used for colored DVD subtitles too. However, the libavcodec DVD decoder lacks parts of the resolution and palette handling that are present in spudec.c. Conflicts: libvo/vo_gl.c sub/dec_sub.h sub/sd_lavc.c
2012-08-31 14:42:30 +02:00
sfc->packer = make_packer(vo, format);
sub: create sub_bitmap array even when using libass One sub_bitmaps struct could contain either a libass ASS_Image list, or a mplayer native list of sub-bitmaps. This caused code duplication in vo_vdpau.c and bitmap_packer.c. Avoid this by creating such a sub_bitmap array even with libass. This basically copies the list and recreates it in mplayer's native format. It gets rid of the code duplication, and will make implementing extended subtitle and OSD rendering in other VOs easier. Also do some cosmetic changes and other preparations for the following commits.
2012-09-28 21:19:36 +02:00
sfc->packer->padding = imgs->scaled; // assume 2x2 filter on scaling
int r = packer_pack_from_subbitmaps(sfc->packer, imgs);
vo_vdpau: split bitmap packing code into a separate file Split the vo_vdpau code that calculates how to pack all subtitle bitmaps into a larger surface into a separate file. This will allow using it in other VOs. Conflicts: Makefile libvo/vo_vdpau.c Note: this commit does the same as an earlier commit by me (4010dd0b1a27e3996). My commit added the vo_vdpau packer code as eosd_packer.c, while this commit by uau uses bitmap_packer.c. Since bitmap_packer.c has a different interface, and because there are more commits changing OSD rendering coming, I will pick uau's version. However, vo_gl, vo_gl3 and vo_direct3d are still using eosd_packer.c, so to make the transition easier, don't delete eosd_packer.c yet.
2012-08-26 18:00:26 +02:00
if (r < 0) {
Some more mp_msg conversions Also add a note to mp_msg.h, since it might be not clear which of the two mechanisms is preferred.
2013-08-23 23:30:09 +02:00
MP_ERR(vo, "OSD bitmaps do not fit on a surface with the maximum "
"supported size\n");
vo_vdpau: split bitmap packing code into a separate file Split the vo_vdpau code that calculates how to pack all subtitle bitmaps into a larger surface into a separate file. This will allow using it in other VOs. Conflicts: Makefile libvo/vo_vdpau.c Note: this commit does the same as an earlier commit by me (4010dd0b1a27e3996). My commit added the vo_vdpau packer code as eosd_packer.c, while this commit by uau uses bitmap_packer.c. Since bitmap_packer.c has a different interface, and because there are more commits changing OSD rendering coming, I will pick uau's version. However, vo_gl, vo_gl3 and vo_direct3d are still using eosd_packer.c, so to make the transition easier, don't delete eosd_packer.c yet.
2012-08-26 18:00:26 +02:00
return;
} else if (r == 1) {
if (sfc->surface != VDP_INVALID_HANDLE) {
vdp_st = vdp->bitmap_surface_destroy(sfc->surface);
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
CHECK_ST_WARNING("Error when calling vdp_bitmap_surface_destroy");
}
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;
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
CHECK_ST_WARNING("OSD: error when creating surface");
EOSD/ASS support for vo_vdpau.c Patch by Grigori G (greg <at> chown ath cx) with minor cosmetic changes by me. git-svn-id: svn://svn.mplayerhq.hu/mplayer/trunk@28710 b3059339-0415-0410-9bf9-f77b7e298cf2
2009-02-23 10:21:57 +01:00
}
subs, vo_vdpau: support RGBA color for PGS subtitles Support passing bitmap subtitles to VOs in full RGBA color, and implement this for libavcodec-decoded subtitle formats on decoding side and vo_vdpau on display side. Currently this is enabled for PGS (blu-ray) and DVB subtitles. VDPAU seems to have sampling issues similar to known GL ones when drawing a sub-rectangle from a larger texture with scaling, where adjacent pixels outside the specified source rectangle affect the result. As the bitmap subtitles may be scaled, add padding support to the bitmap packer code. In principle, this could be used for colored DVD subtitles too. However, the libavcodec DVD decoder lacks parts of the resolution and palette handling that are present in spudec.c. Conflicts: libvo/vo_gl.c sub/dec_sub.h sub/sd_lavc.c
2012-08-31 14:42:30 +02:00
if (imgs->scaled) {
char zeros[sfc->packer->used_width * format_size];
memset(zeros, 0, sizeof(zeros));
vdp_st = vdp->bitmap_surface_put_bits_native(sfc->surface,
&(const void *){zeros}, &(uint32_t){0},
&(VdpRect){0, 0, sfc->packer->used_width,
sfc->packer->used_height});
}
EOSD/ASS support for vo_vdpau.c Patch by Grigori G (greg <at> chown ath cx) with minor cosmetic changes by me. git-svn-id: svn://svn.mplayerhq.hu/mplayer/trunk@28710 b3059339-0415-0410-9bf9-f77b7e298cf2
2009-02-23 10:21:57 +01:00
VO, sub: refactor Remove VFCTRL_DRAW_OSD, VFCAP_EOSD_FILTER, VFCAP_EOSD_RGBA, VFCAP_EOSD, VOCTRL_DRAW_EOSD, VOCTRL_GET_EOSD_RES, VOCTRL_QUERY_EOSD_FORMAT. Remove draw_osd_with_eosd(), which rendered the OSD by calling VOCTRL_DRAW_EOSD. Change VOs to call osd_draw() directly, which takes a callback as argument. (This basically works like the old OSD API, except multiple OSD bitmap formats are supported and caching is possible.) Remove all mentions of "eosd". It's simply "osd" now. Make OSD size per-OSD-object, as they can be different when using vf_sub. Include display_par/video_par in resolution change detection. Fix the issue with margin borders in vo_corevideo.
2012-10-19 19:25:18 +02:00
osd_skip_upload:
vo_vdpau: split bitmap packing code into a separate file Split the vo_vdpau code that calculates how to pack all subtitle bitmaps into a larger surface into a separate file. This will allow using it in other VOs. Conflicts: Makefile libvo/vo_vdpau.c Note: this commit does the same as an earlier commit by me (4010dd0b1a27e3996). My commit added the vo_vdpau packer code as eosd_packer.c, while this commit by uau uses bitmap_packer.c. Since bitmap_packer.c has a different interface, and because there are more commits changing OSD rendering coming, I will pick uau's version. However, vo_gl, vo_gl3 and vo_direct3d are still using eosd_packer.c, so to make the transition easier, don't delete eosd_packer.c yet.
2012-08-26 18:00:26 +02:00
if (sfc->surface == VDP_INVALID_HANDLE)
vo_vdpau: Allocate one large surface for EOSD content Create a single large bitmap surface for EOSD objects and pack all the bitmap rectangles inside that. The old code created a separate bitmap surface for every bitmap and then resized the cached surfaces when drawing later frames. The number of surfaces could be large (at least about 2000 for one sample subtitle script) so this was very inefficient. The old code also used a very simple strategy for pairing existing surfaces to new bitmaps; it could resize tiny surfaces to hold large glyphs while using existing large surfaces to hold tiny glyphs and as a result allocate arbitrarily much more total surface area than was necessary. The new code only supports using a single surface, freeing it and allocating a larger one if necessary. It would be possible to support multiple surfaces in case of hitting the maximum bitmap surface size, but I'll wait to see if that is actually needed before implementing it. NVIDIA seems to support bitmap surface sizes up to 8192x8192, so it would take either a really pathological subtitle script rendered at a high resolution or an implementation with lower limits before multiple surfaces would be necessary. The packing algorithm should successfully pack the bitmaps into a surface of size w*h as long as the total area of the bitmaps does not exceed 16/17 (w-max_bitmap_width)*(h-max_bitmap_height), so there should be no totally catastrophic failure cases. The 16/17 factor comes from approximate sorting used in the algorithm. On average performance should be better than this minimum guaranteed level.
2009-09-02 19:21:24 +02:00
return;
vo_vdpau: allow multiple EOSD renderers Preparation for using new OSD rendering method.
2012-09-28 21:49:09 +02:00
if (sfc->packer->count > sfc->targets_size) {
talloc_free(sfc->targets);
sfc->targets_size = sfc->packer->count;
sfc->targets = talloc_size(vc, sfc->targets_size
* sizeof(*sfc->targets));
sub: create sub_bitmap array even when using libass One sub_bitmaps struct could contain either a libass ASS_Image list, or a mplayer native list of sub-bitmaps. This caused code duplication in vo_vdpau.c and bitmap_packer.c. Avoid this by creating such a sub_bitmap array even with libass. This basically copies the list and recreates it in mplayer's native format. It gets rid of the code duplication, and will make implementing extended subtitle and OSD rendering in other VOs easier. Also do some cosmetic changes and other preparations for the following commits.
2012-09-28 21:19:36 +02:00
}
vo_vdpau: split bitmap packing code into a separate file Split the vo_vdpau code that calculates how to pack all subtitle bitmaps into a larger surface into a separate file. This will allow using it in other VOs. Conflicts: Makefile libvo/vo_vdpau.c Note: this commit does the same as an earlier commit by me (4010dd0b1a27e3996). My commit added the vo_vdpau packer code as eosd_packer.c, while this commit by uau uses bitmap_packer.c. Since bitmap_packer.c has a different interface, and because there are more commits changing OSD rendering coming, I will pick uau's version. However, vo_gl, vo_gl3 and vo_direct3d are still using eosd_packer.c, so to make the transition easier, don't delete eosd_packer.c yet.
2012-08-26 18:00:26 +02:00
sub: create sub_bitmap array even when using libass One sub_bitmaps struct could contain either a libass ASS_Image list, or a mplayer native list of sub-bitmaps. This caused code duplication in vo_vdpau.c and bitmap_packer.c. Avoid this by creating such a sub_bitmap array even with libass. This basically copies the list and recreates it in mplayer's native format. It gets rid of the code duplication, and will make implementing extended subtitle and OSD rendering in other VOs easier. Also do some cosmetic changes and other preparations for the following commits.
2012-09-28 21:19:36 +02:00
for (int i = 0 ;i < sfc->packer->count; i++) {
struct sub_bitmap *b = &imgs->parts[i];
VO, sub: refactor Remove VFCTRL_DRAW_OSD, VFCAP_EOSD_FILTER, VFCAP_EOSD_RGBA, VFCAP_EOSD, VOCTRL_DRAW_EOSD, VOCTRL_GET_EOSD_RES, VOCTRL_QUERY_EOSD_FORMAT. Remove draw_osd_with_eosd(), which rendered the OSD by calling VOCTRL_DRAW_EOSD. Change VOs to call osd_draw() directly, which takes a callback as argument. (This basically works like the old OSD API, except multiple OSD bitmap formats are supported and caching is possible.) Remove all mentions of "eosd". It's simply "osd" now. Make OSD size per-OSD-object, as they can be different when using vf_sub. Include display_par/video_par in resolution change detection. Fix the issue with margin borders in vo_corevideo.
2012-10-19 19:25:18 +02:00
struct osd_target *target = sfc->targets + sfc->render_count;
sub: create sub_bitmap array even when using libass One sub_bitmaps struct could contain either a libass ASS_Image list, or a mplayer native list of sub-bitmaps. This caused code duplication in vo_vdpau.c and bitmap_packer.c. Avoid this by creating such a sub_bitmap array even with libass. This basically copies the list and recreates it in mplayer's native format. It gets rid of the code duplication, and will make implementing extended subtitle and OSD rendering in other VOs easier. Also do some cosmetic changes and other preparations for the following commits.
2012-09-28 21:19:36 +02:00
int x = sfc->packer->result[i].x;
int y = sfc->packer->result[i].y;
target->source = (VdpRect){x, y, x + b->w, y + b->h};
target->dest = (VdpRect){b->x, b->y, b->x + b->dw, b->y + b->dh};
target->color = (VdpColor){1, 1, 1, 1};
if (imgs->format == SUBBITMAP_LIBASS) {
uint32_t color = b->libass.color;
target->color.alpha = 1.0 - ((color >> 0) & 0xff) / 255.0;
target->color.blue = ((color >> 8) & 0xff) / 255.0;
target->color.green = ((color >> 16) & 0xff) / 255.0;
target->color.red = ((color >> 24) & 0xff) / 255.0;
subs, vo_vdpau: support RGBA color for PGS subtitles Support passing bitmap subtitles to VOs in full RGBA color, and implement this for libavcodec-decoded subtitle formats on decoding side and vo_vdpau on display side. Currently this is enabled for PGS (blu-ray) and DVB subtitles. VDPAU seems to have sampling issues similar to known GL ones when drawing a sub-rectangle from a larger texture with scaling, where adjacent pixels outside the specified source rectangle affect the result. As the bitmap subtitles may be scaled, add padding support to the bitmap packer code. In principle, this could be used for colored DVD subtitles too. However, the libavcodec DVD decoder lacks parts of the resolution and palette handling that are present in spudec.c. Conflicts: libvo/vo_gl.c sub/dec_sub.h sub/sd_lavc.c
2012-08-31 14:42:30 +02:00
}
sub: create sub_bitmap array even when using libass One sub_bitmaps struct could contain either a libass ASS_Image list, or a mplayer native list of sub-bitmaps. This caused code duplication in vo_vdpau.c and bitmap_packer.c. Avoid this by creating such a sub_bitmap array even with libass. This basically copies the list and recreates it in mplayer's native format. It gets rid of the code duplication, and will make implementing extended subtitle and OSD rendering in other VOs easier. Also do some cosmetic changes and other preparations for the following commits.
2012-09-28 21:19:36 +02:00
if (need_upload) {
vdp_st = vdp->
bitmap_surface_put_bits_native(sfc->surface,
&(const void *){b->bitmap},
&(uint32_t){b->stride},
&target->source);
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
CHECK_ST_WARNING("OSD: putbits failed");
vo_vdpau: split bitmap packing code into a separate file Split the vo_vdpau code that calculates how to pack all subtitle bitmaps into a larger surface into a separate file. This will allow using it in other VOs. Conflicts: Makefile libvo/vo_vdpau.c Note: this commit does the same as an earlier commit by me (4010dd0b1a27e3996). My commit added the vo_vdpau packer code as eosd_packer.c, while this commit by uau uses bitmap_packer.c. Since bitmap_packer.c has a different interface, and because there are more commits changing OSD rendering coming, I will pick uau's version. However, vo_gl, vo_gl3 and vo_direct3d are still using eosd_packer.c, so to make the transition easier, don't delete eosd_packer.c yet.
2012-08-26 18:00:26 +02:00
}
vo_vdpau: allow multiple EOSD renderers Preparation for using new OSD rendering method.
2012-09-28 21:49:09 +02:00
sfc->render_count++;
vo_vdpau: split bitmap packing code into a separate file Split the vo_vdpau code that calculates how to pack all subtitle bitmaps into a larger surface into a separate file. This will allow using it in other VOs. Conflicts: Makefile libvo/vo_vdpau.c Note: this commit does the same as an earlier commit by me (4010dd0b1a27e3996). My commit added the vo_vdpau packer code as eosd_packer.c, while this commit by uau uses bitmap_packer.c. Since bitmap_packer.c has a different interface, and because there are more commits changing OSD rendering coming, I will pick uau's version. However, vo_gl, vo_gl3 and vo_direct3d are still using eosd_packer.c, so to make the transition easier, don't delete eosd_packer.c yet.
2012-08-26 18:00:26 +02:00
}
sub: create sub_bitmap array even when using libass One sub_bitmaps struct could contain either a libass ASS_Image list, or a mplayer native list of sub-bitmaps. This caused code duplication in vo_vdpau.c and bitmap_packer.c. Avoid this by creating such a sub_bitmap array even with libass. This basically copies the list and recreates it in mplayer's native format. It gets rid of the code duplication, and will make implementing extended subtitle and OSD rendering in other VOs easier. Also do some cosmetic changes and other preparations for the following commits.
2012-09-28 21:19:36 +02:00
vo_vdpau: allow multiple EOSD renderers Preparation for using new OSD rendering method.
2012-09-28 21:49:09 +02:00
sfc->bitmap_id = imgs->bitmap_id;
sfc->bitmap_pos_id = imgs->bitmap_pos_id;
vo_vdpau: split bitmap packing code into a separate file Split the vo_vdpau code that calculates how to pack all subtitle bitmaps into a larger surface into a separate file. This will allow using it in other VOs. Conflicts: Makefile libvo/vo_vdpau.c Note: this commit does the same as an earlier commit by me (4010dd0b1a27e3996). My commit added the vo_vdpau packer code as eosd_packer.c, while this commit by uau uses bitmap_packer.c. Since bitmap_packer.c has a different interface, and because there are more commits changing OSD rendering coming, I will pick uau's version. However, vo_gl, vo_gl3 and vo_direct3d are still using eosd_packer.c, so to make the transition easier, don't delete eosd_packer.c yet.
2012-08-26 18:00:26 +02:00
}
libvo, vo_vdpau: make the EOSD packer code from vo_vdpau generic The code in eosd_packer.c/.h is taken from vo_vdpau.c and has been made independent from vdpau API specifics. This allows other VOs, which need to pack the small EOSD images into a large surface for efficiency, to use this code.
2011-10-27 12:07:10 +02:00
VO, sub: refactor Remove VFCTRL_DRAW_OSD, VFCAP_EOSD_FILTER, VFCAP_EOSD_RGBA, VFCAP_EOSD, VOCTRL_DRAW_EOSD, VOCTRL_GET_EOSD_RES, VOCTRL_QUERY_EOSD_FORMAT. Remove draw_osd_with_eosd(), which rendered the OSD by calling VOCTRL_DRAW_EOSD. Change VOs to call osd_draw() directly, which takes a callback as argument. (This basically works like the old OSD API, except multiple OSD bitmap formats are supported and caching is possible.) Remove all mentions of "eosd". It's simply "osd" now. Make OSD size per-OSD-object, as they can be different when using vf_sub. Include display_par/video_par in resolution change detection. Fix the issue with margin borders in vo_corevideo.
2012-10-19 19:25:18 +02:00
static void draw_osd_cb(void *ctx, struct sub_bitmaps *imgs)
vo_vdpau: split bitmap packing code into a separate file Split the vo_vdpau code that calculates how to pack all subtitle bitmaps into a larger surface into a separate file. This will allow using it in other VOs. Conflicts: Makefile libvo/vo_vdpau.c Note: this commit does the same as an earlier commit by me (4010dd0b1a27e3996). My commit added the vo_vdpau packer code as eosd_packer.c, while this commit by uau uses bitmap_packer.c. Since bitmap_packer.c has a different interface, and because there are more commits changing OSD rendering coming, I will pick uau's version. However, vo_gl, vo_gl3 and vo_direct3d are still using eosd_packer.c, so to make the transition easier, don't delete eosd_packer.c yet.
2012-08-26 18:00:26 +02:00
{
struct vo *vo = ctx;
VO, sub: refactor Remove VFCTRL_DRAW_OSD, VFCAP_EOSD_FILTER, VFCAP_EOSD_RGBA, VFCAP_EOSD, VOCTRL_DRAW_EOSD, VOCTRL_GET_EOSD_RES, VOCTRL_QUERY_EOSD_FORMAT. Remove draw_osd_with_eosd(), which rendered the OSD by calling VOCTRL_DRAW_EOSD. Change VOs to call osd_draw() directly, which takes a callback as argument. (This basically works like the old OSD API, except multiple OSD bitmap formats are supported and caching is possible.) Remove all mentions of "eosd". It's simply "osd" now. Make OSD size per-OSD-object, as they can be different when using vf_sub. Include display_par/video_par in resolution change detection. Fix the issue with margin borders in vo_corevideo.
2012-10-19 19:25:18 +02:00
generate_osd_part(vo, imgs);
draw_osd_part(vo, imgs->render_index);
vo_vdpau: split bitmap packing code into a separate file Split the vo_vdpau code that calculates how to pack all subtitle bitmaps into a larger surface into a separate file. This will allow using it in other VOs. Conflicts: Makefile libvo/vo_vdpau.c Note: this commit does the same as an earlier commit by me (4010dd0b1a27e3996). My commit added the vo_vdpau packer code as eosd_packer.c, while this commit by uau uses bitmap_packer.c. Since bitmap_packer.c has a different interface, and because there are more commits changing OSD rendering coming, I will pick uau's version. However, vo_gl, vo_gl3 and vo_direct3d are still using eosd_packer.c, so to make the transition easier, don't delete eosd_packer.c yet.
2012-08-26 18:00:26 +02:00
}
VO, sub: refactor Remove VFCTRL_DRAW_OSD, VFCAP_EOSD_FILTER, VFCAP_EOSD_RGBA, VFCAP_EOSD, VOCTRL_DRAW_EOSD, VOCTRL_GET_EOSD_RES, VOCTRL_QUERY_EOSD_FORMAT. Remove draw_osd_with_eosd(), which rendered the OSD by calling VOCTRL_DRAW_EOSD. Change VOs to call osd_draw() directly, which takes a callback as argument. (This basically works like the old OSD API, except multiple OSD bitmap formats are supported and caching is possible.) Remove all mentions of "eosd". It's simply "osd" now. Make OSD size per-OSD-object, as they can be different when using vf_sub. Include display_par/video_par in resolution change detection. Fix the issue with margin borders in vo_corevideo.
2012-10-19 19:25:18 +02:00
static void draw_osd(struct vo *vo, struct osd_state *osd)
vo_vdpau: split bitmap packing code into a separate file Split the vo_vdpau code that calculates how to pack all subtitle bitmaps into a larger surface into a separate file. This will allow using it in other VOs. Conflicts: Makefile libvo/vo_vdpau.c Note: this commit does the same as an earlier commit by me (4010dd0b1a27e3996). My commit added the vo_vdpau packer code as eosd_packer.c, while this commit by uau uses bitmap_packer.c. Since bitmap_packer.c has a different interface, and because there are more commits changing OSD rendering coming, I will pick uau's version. However, vo_gl, vo_gl3 and vo_direct3d are still using eosd_packer.c, so to make the transition easier, don't delete eosd_packer.c yet.
2012-08-26 18:00:26 +02:00
{
struct vdpctx *vc = vo->priv;
VO, sub: refactor Remove VFCTRL_DRAW_OSD, VFCAP_EOSD_FILTER, VFCAP_EOSD_RGBA, VFCAP_EOSD, VOCTRL_DRAW_EOSD, VOCTRL_GET_EOSD_RES, VOCTRL_QUERY_EOSD_FORMAT. Remove draw_osd_with_eosd(), which rendered the OSD by calling VOCTRL_DRAW_EOSD. Change VOs to call osd_draw() directly, which takes a callback as argument. (This basically works like the old OSD API, except multiple OSD bitmap formats are supported and caching is possible.) Remove all mentions of "eosd". It's simply "osd" now. Make OSD size per-OSD-object, as they can be different when using vf_sub. Include display_par/video_par in resolution change detection. Fix the issue with margin borders in vo_corevideo.
2012-10-19 19:25:18 +02:00
if (!status_ok(vo))
vo_vdpau: split bitmap packing code into a separate file Split the vo_vdpau code that calculates how to pack all subtitle bitmaps into a larger surface into a separate file. This will allow using it in other VOs. Conflicts: Makefile libvo/vo_vdpau.c Note: this commit does the same as an earlier commit by me (4010dd0b1a27e3996). My commit added the vo_vdpau packer code as eosd_packer.c, while this commit by uau uses bitmap_packer.c. Since bitmap_packer.c has a different interface, and because there are more commits changing OSD rendering coming, I will pick uau's version. However, vo_gl, vo_gl3 and vo_direct3d are still using eosd_packer.c, so to make the transition easier, don't delete eosd_packer.c yet.
2012-08-26 18:00:26 +02:00
return;
VO, sub: refactor Remove VFCTRL_DRAW_OSD, VFCAP_EOSD_FILTER, VFCAP_EOSD_RGBA, VFCAP_EOSD, VOCTRL_DRAW_EOSD, VOCTRL_GET_EOSD_RES, VOCTRL_QUERY_EOSD_FORMAT. Remove draw_osd_with_eosd(), which rendered the OSD by calling VOCTRL_DRAW_EOSD. Change VOs to call osd_draw() directly, which takes a callback as argument. (This basically works like the old OSD API, except multiple OSD bitmap formats are supported and caching is possible.) Remove all mentions of "eosd". It's simply "osd" now. Make OSD size per-OSD-object, as they can be different when using vf_sub. Include display_par/video_par in resolution change detection. Fix the issue with margin borders in vo_corevideo.
2012-10-19 19:25:18 +02:00
static const bool formats[SUBBITMAP_COUNT] = {
[SUBBITMAP_LIBASS] = true,
[SUBBITMAP_RGBA] = true,
vo_vdpau: split bitmap packing code into a separate file Split the vo_vdpau code that calculates how to pack all subtitle bitmaps into a larger surface into a separate file. This will allow using it in other VOs. Conflicts: Makefile libvo/vo_vdpau.c Note: this commit does the same as an earlier commit by me (4010dd0b1a27e3996). My commit added the vo_vdpau packer code as eosd_packer.c, while this commit by uau uses bitmap_packer.c. Since bitmap_packer.c has a different interface, and because there are more commits changing OSD rendering coming, I will pick uau's version. However, vo_gl, vo_gl3 and vo_direct3d are still using eosd_packer.c, so to make the transition easier, don't delete eosd_packer.c yet.
2012-08-26 18:00:26 +02:00
};
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
osd_draw(osd, vc->osd_rect, osd->vo_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);
CHECK_ST_WARNING("Error calling "
"presentation_queue_query_surface_status");
if (status == VDP_PRESENTATION_QUEUE_STATUS_QUEUED)
break;
if (vc->vsync_interval > 1) {
uint64_t qtime = vc->queue_time[vc->query_surface_num];
if (vtime < qtime + vc->vsync_interval / 2)
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, "Frame shown too early\n");
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)
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, "Frame shown late\n");
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
}
static inline uint64_t prev_vs2(struct vdpctx *vc, uint64_t ts, int shift)
{
uint64_t offset = ts - vc->recent_vsync_time;
// Fix negative values for 1<<shift vsyncs before vc->recent_vsync_time
offset += (uint64_t)vc->vsync_interval << shift;
offset %= vc->vsync_interval;
return ts - offset;
}
Replace all calls to GetTimer()/GetTimerMS() GetTimer() is generally replaced with mp_time_us(). Both calls return microseconds, but the latter uses int64_t, us defined to never wrap, and never returns 0 or negative values. GetTimerMS() has no direct replacement. Instead the other functions are used. For some code, switch to mp_time_sec(), which returns the time as double float value in seconds. The returned time is offset to program start time, so there is enough precision left to deliver microsecond resolution for at least 100 years. Unless it's casted to a float (or the CPU reduces precision), which is why we still use mp_time_us() out of paranoia in places where precision is clearly needed. Always switch to the correct time. The whole point of the new timer calls is that they don't wrap, and storing microseconds in unsigned int variables would negate this. In some cases, remove wrap-around handling for time values.
2013-05-25 18:31:06 +02:00
static void flip_page_timed(struct vo *vo, int64_t pts_us, int duration)
Implement vsync-aware frame timing for VDPAU Main things added are custom frame dropping for VDPAU to work around the display FPS limit, frame timing adjustment to avoid jitter when video frame times keep falling near vsyncs, and use of VDPAU's timing feature to keep one future frame queued in advance. NVIDIA's VDPAU implementation refuses to change the displayed frame more than once per vsync. This set a limit on how much video could be sped up, and caused problems for nearly all videos on low-FPS video projectors (playing 24 FPS video on a 24 FPS projector would not work reliably as MPlayer may need to slightly speed up the video for AV sync). This commit adds a framedrop mechanism that drops some frames so that no more than one is sent for display per vsync. The code tries to select the dropped frames smartly, selecting the best one to show for each vsync. Because of the timing features needed the drop functionality currently does not work if the correct-pts option is disabled. The code also adjusts frame timing slightly to avoid jitter. If you for example play 24 FPS video content on a 72 FPS display then normally a frame would be shown for 3 vsyncs, but if the frame times happen to fall near vsyncs and change between just before and just after then there could be frames alternating between 2 and 4 vsyncs. The code changes frame timing by up to one quarter vsync interval to avoid this. The above functionality depends on having reliable vsync timing information available. The display refresh rate is not directly provided by the VDPAU API. The current code uses information from the XF86VidMode extension if available; I'm not sure how common cases where that is inaccurate are. The refresh rate can be specified manually if necessary. After the changes in this commit MPlayer now always tries to keep one frame queued for future display using VDPAU's internal timing mechanism (however no more than 50 ms to the future). This should make video playback somewhat more robust against timing inaccuracies caused by system load.
2009-11-15 03:39:22 +01:00
{
struct vdpctx *vc = vo->priv;
struct vdp_functions *vdp = vc->vdp;
VdpStatus vdp_st;
uint32_t vsync_interval = vc->vsync_interval;
vo_vdpau: Support recovering from VDPAU display preemption Add code to reinitialize all VDPAU objects if a display preemption condition occurs. Reinitializing them in the middle of playback will cause video corruption at least until the next keyframe when using hardware decoding, but decoding does seem to recover after a keyframe.
2009-09-07 01:02:24 +02:00
if (handle_preemption(vo) < 0)
return;
Implement vsync-aware frame timing for VDPAU Main things added are custom frame dropping for VDPAU to work around the display FPS limit, frame timing adjustment to avoid jitter when video frame times keep falling near vsyncs, and use of VDPAU's timing feature to keep one future frame queued in advance. NVIDIA's VDPAU implementation refuses to change the displayed frame more than once per vsync. This set a limit on how much video could be sped up, and caused problems for nearly all videos on low-FPS video projectors (playing 24 FPS video on a 24 FPS projector would not work reliably as MPlayer may need to slightly speed up the video for AV sync). This commit adds a framedrop mechanism that drops some frames so that no more than one is sent for display per vsync. The code tries to select the dropped frames smartly, selecting the best one to show for each vsync. Because of the timing features needed the drop functionality currently does not work if the correct-pts option is disabled. The code also adjusts frame timing slightly to avoid jitter. If you for example play 24 FPS video content on a 72 FPS display then normally a frame would be shown for 3 vsyncs, but if the frame times happen to fall near vsyncs and change between just before and just after then there could be frames alternating between 2 and 4 vsyncs. The code changes frame timing by up to one quarter vsync interval to avoid this. The above functionality depends on having reliable vsync timing information available. The display refresh rate is not directly provided by the VDPAU API. The current code uses information from the XF86VidMode extension if available; I'm not sure how common cases where that is inaccurate are. The refresh rate can be specified manually if necessary. After the changes in this commit MPlayer now always tries to keep one frame queued for future display using VDPAU's internal timing mechanism (however no more than 50 ms to the future). This should make video playback somewhat more robust against timing inaccuracies caused by system load.
2009-11-15 03:39:22 +01:00
if (duration > INT_MAX / 1000)
duration = -1;
else
duration *= 1000;
vo_vdpau: disable refresh-aware frame timing when composited Under a compositing window manager the current VDPAU implementation behaves differently than without it. Frame flip timing info becomes incorrect (I guess it only reflects when the frame was sent to the compositor, not when it was actually shown), and there is no limitation to at most one frame switch per refresh like without compositing. Detect whether a compositing window manager is active and disable refresh-aware frame timing and dropping in this case, similarly to what fps=-1 would do. This behavior can be controlled with the new suboption "composite-detect". Disabling the refresh-aware logic makes timing somewhat less accurate. Because the video switch rate limit isn't there, the lack of frame dropping on player side does not impose a hard limit on video FPS, but does reduce performance somewhat as redundant frames are drawn in memory. The existence of a compositing window manager does not guarantee that the current window is actually composited, so the current check is not foolproof. In particular, some WMs have support for a "unredirect fullscreen windows" option. Support for such things could be improved.
2012-07-27 02:40:38 +02:00
if (vc->vsync_interval == 1)
Implement vsync-aware frame timing for VDPAU Main things added are custom frame dropping for VDPAU to work around the display FPS limit, frame timing adjustment to avoid jitter when video frame times keep falling near vsyncs, and use of VDPAU's timing feature to keep one future frame queued in advance. NVIDIA's VDPAU implementation refuses to change the displayed frame more than once per vsync. This set a limit on how much video could be sped up, and caused problems for nearly all videos on low-FPS video projectors (playing 24 FPS video on a 24 FPS projector would not work reliably as MPlayer may need to slightly speed up the video for AV sync). This commit adds a framedrop mechanism that drops some frames so that no more than one is sent for display per vsync. The code tries to select the dropped frames smartly, selecting the best one to show for each vsync. Because of the timing features needed the drop functionality currently does not work if the correct-pts option is disabled. The code also adjusts frame timing slightly to avoid jitter. If you for example play 24 FPS video content on a 72 FPS display then normally a frame would be shown for 3 vsyncs, but if the frame times happen to fall near vsyncs and change between just before and just after then there could be frames alternating between 2 and 4 vsyncs. The code changes frame timing by up to one quarter vsync interval to avoid this. The above functionality depends on having reliable vsync timing information available. The display refresh rate is not directly provided by the VDPAU API. The current code uses information from the XF86VidMode extension if available; I'm not sure how common cases where that is inaccurate are. The refresh rate can be specified manually if necessary. After the changes in this commit MPlayer now always tries to keep one frame queued for future display using VDPAU's internal timing mechanism (however no more than 50 ms to the future). This should make video playback somewhat more robust against timing inaccuracies caused by system load.
2009-11-15 03:39:22 +01:00
duration = -1; // Make sure drop logic is disabled
uint64_t now = sync_vdptime(vo);
uint64_t pts = pts_us ? convert_to_vdptime(vo, pts_us) : now;
uint64_t ideal_pts = pts;
uint64_t npts = duration >= 0 ? pts + duration : UINT64_MAX;
#define PREV_VS2(ts, shift) prev_vs2(vc, ts, shift)
// Only gives accurate results for ts >= vc->recent_vsync_time
#define PREV_VSYNC(ts) PREV_VS2(ts, 0)
/* We hope to be here at least one vsync before the frame should be shown.
* If we are running late then don't drop the frame unless there is
* already one queued for the next vsync; even if we _hope_ to show the
* next frame soon enough to mean this one should be dropped we might
* not make the target time in reality. Without this check we could drop
* every frame, freezing the display completely if video lags behind.
*/
vo_vdpau.c cosmetics: add WRAP_ADD macro The macro is meant to simplify the handling of some code dealing with circular buffers.
2010-05-06 03:46:10 +02:00
if (now > PREV_VSYNC(FFMAX(pts, vc->last_queue_time + vsync_interval)))
Implement vsync-aware frame timing for VDPAU Main things added are custom frame dropping for VDPAU to work around the display FPS limit, frame timing adjustment to avoid jitter when video frame times keep falling near vsyncs, and use of VDPAU's timing feature to keep one future frame queued in advance. NVIDIA's VDPAU implementation refuses to change the displayed frame more than once per vsync. This set a limit on how much video could be sped up, and caused problems for nearly all videos on low-FPS video projectors (playing 24 FPS video on a 24 FPS projector would not work reliably as MPlayer may need to slightly speed up the video for AV sync). This commit adds a framedrop mechanism that drops some frames so that no more than one is sent for display per vsync. The code tries to select the dropped frames smartly, selecting the best one to show for each vsync. Because of the timing features needed the drop functionality currently does not work if the correct-pts option is disabled. The code also adjusts frame timing slightly to avoid jitter. If you for example play 24 FPS video content on a 72 FPS display then normally a frame would be shown for 3 vsyncs, but if the frame times happen to fall near vsyncs and change between just before and just after then there could be frames alternating between 2 and 4 vsyncs. The code changes frame timing by up to one quarter vsync interval to avoid this. The above functionality depends on having reliable vsync timing information available. The display refresh rate is not directly provided by the VDPAU API. The current code uses information from the XF86VidMode extension if available; I'm not sure how common cases where that is inaccurate are. The refresh rate can be specified manually if necessary. After the changes in this commit MPlayer now always tries to keep one frame queued for future display using VDPAU's internal timing mechanism (however no more than 50 ms to the future). This should make video playback somewhat more robust against timing inaccuracies caused by system load.
2009-11-15 03:39:22 +01:00
npts = UINT64_MAX;
/* Allow flipping a frame at a vsync if its presentation time is a
* bit after that vsync and the change makes the flip time delta
* from previous frame better match the target timestamp delta.
* This avoids instability with frame timestamps falling near vsyncs.
* For example if the frame timestamps were (with vsyncs at
* integer values) 0.01, 1.99, 4.01, 5.99, 8.01, ... then
* straightforward timing at next vsync would flip the frames at
* 1, 2, 5, 6, 9; this changes it to 1, 2, 4, 6, 8 and so on with
* regular 2-vsync intervals.
*
* Also allow moving the frame forward if it looks like we dropped
* the previous frame incorrectly (now that we know better after
* having final exact timestamp information for this frame) and
* there would unnecessarily be a vsync without a frame change.
*/
uint64_t vsync = PREV_VSYNC(pts);
if (pts < vsync + vsync_interval / 4
&& (vsync - PREV_VS2(vc->last_queue_time, 16)
> pts - vc->last_ideal_time + vsync_interval / 2
|| vc->dropped_frame && vsync > vc->dropped_time))
pts -= vsync_interval / 2;
vc->dropped_frame = true; // changed at end if false
vc->dropped_time = ideal_pts;
pts = FFMAX(pts, vc->last_queue_time + vsync_interval);
pts = FFMAX(pts, now);
if (npts < PREV_VSYNC(pts) + vsync_interval)
return;
vo_vdpau: support queuing an arbitrary number of frames ahead Make the number of output surfaces allocated by vo_vdpau configurable and allow queuing multiple future frames with the VDPAU frame timing functionality. There are two known issues that could be polished in the future for particularly long queue time cases. First, toplevel code should possibly wait for the queued changes to finish displaying in some situations like switching files. Second, the VO can block waiting for a surface to become available, and in the worst case this wait can be almost as long as the maximum queuing time (potentially causing audio underruns). However those issues are not high priority.
2010-05-14 04:18:38 +02:00
int num_flips = update_presentation_queue_status(vo);
vsync = vc->recent_vsync_time + num_flips * vc->vsync_interval;
Implement vsync-aware frame timing for VDPAU Main things added are custom frame dropping for VDPAU to work around the display FPS limit, frame timing adjustment to avoid jitter when video frame times keep falling near vsyncs, and use of VDPAU's timing feature to keep one future frame queued in advance. NVIDIA's VDPAU implementation refuses to change the displayed frame more than once per vsync. This set a limit on how much video could be sped up, and caused problems for nearly all videos on low-FPS video projectors (playing 24 FPS video on a 24 FPS projector would not work reliably as MPlayer may need to slightly speed up the video for AV sync). This commit adds a framedrop mechanism that drops some frames so that no more than one is sent for display per vsync. The code tries to select the dropped frames smartly, selecting the best one to show for each vsync. Because of the timing features needed the drop functionality currently does not work if the correct-pts option is disabled. The code also adjusts frame timing slightly to avoid jitter. If you for example play 24 FPS video content on a 72 FPS display then normally a frame would be shown for 3 vsyncs, but if the frame times happen to fall near vsyncs and change between just before and just after then there could be frames alternating between 2 and 4 vsyncs. The code changes frame timing by up to one quarter vsync interval to avoid this. The above functionality depends on having reliable vsync timing information available. The display refresh rate is not directly provided by the VDPAU API. The current code uses information from the XF86VidMode extension if available; I'm not sure how common cases where that is inaccurate are. The refresh rate can be specified manually if necessary. After the changes in this commit MPlayer now always tries to keep one frame queued for future display using VDPAU's internal timing mechanism (however no more than 50 ms to the future). This should make video playback somewhat more robust against timing inaccuracies caused by system load.
2009-11-15 03:39:22 +01:00
now = sync_vdptime(vo);
pts = FFMAX(pts, now);
vo_vdpau: support queuing an arbitrary number of frames ahead Make the number of output surfaces allocated by vo_vdpau configurable and allow queuing multiple future frames with the VDPAU frame timing functionality. There are two known issues that could be polished in the future for particularly long queue time cases. First, toplevel code should possibly wait for the queued changes to finish displaying in some situations like switching files. Second, the VO can block waiting for a surface to become available, and in the worst case this wait can be almost as long as the maximum queuing time (potentially causing audio underruns). However those issues are not high priority.
2010-05-14 04:18:38 +02:00
pts = FFMAX(pts, vsync + (vsync_interval >> 2));
Implement vsync-aware frame timing for VDPAU Main things added are custom frame dropping for VDPAU to work around the display FPS limit, frame timing adjustment to avoid jitter when video frame times keep falling near vsyncs, and use of VDPAU's timing feature to keep one future frame queued in advance. NVIDIA's VDPAU implementation refuses to change the displayed frame more than once per vsync. This set a limit on how much video could be sped up, and caused problems for nearly all videos on low-FPS video projectors (playing 24 FPS video on a 24 FPS projector would not work reliably as MPlayer may need to slightly speed up the video for AV sync). This commit adds a framedrop mechanism that drops some frames so that no more than one is sent for display per vsync. The code tries to select the dropped frames smartly, selecting the best one to show for each vsync. Because of the timing features needed the drop functionality currently does not work if the correct-pts option is disabled. The code also adjusts frame timing slightly to avoid jitter. If you for example play 24 FPS video content on a 72 FPS display then normally a frame would be shown for 3 vsyncs, but if the frame times happen to fall near vsyncs and change between just before and just after then there could be frames alternating between 2 and 4 vsyncs. The code changes frame timing by up to one quarter vsync interval to avoid this. The above functionality depends on having reliable vsync timing information available. The display refresh rate is not directly provided by the VDPAU API. The current code uses information from the XF86VidMode extension if available; I'm not sure how common cases where that is inaccurate are. The refresh rate can be specified manually if necessary. After the changes in this commit MPlayer now always tries to keep one frame queued for future display using VDPAU's internal timing mechanism (however no more than 50 ms to the future). This should make video playback somewhat more robust against timing inaccuracies caused by system load.
2009-11-15 03:39:22 +01:00
vsync = PREV_VSYNC(pts);
if (npts < vsync + vsync_interval)
return;
pts = vsync + (vsync_interval >> 2);
vo_vdpau.c: cosmetics
2009-05-09 17:08:30 +02:00
vdp_st =
vdp->presentation_queue_display(vc->flip_queue,
vc->output_surfaces[vc->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
vo->dwidth, vo->dheight, pts);
vo_vdpau.c: cosmetics
2009-05-09 17:08:30 +02:00
CHECK_ST_WARNING("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
Implement vsync-aware frame timing for VDPAU Main things added are custom frame dropping for VDPAU to work around the display FPS limit, frame timing adjustment to avoid jitter when video frame times keep falling near vsyncs, and use of VDPAU's timing feature to keep one future frame queued in advance. NVIDIA's VDPAU implementation refuses to change the displayed frame more than once per vsync. This set a limit on how much video could be sped up, and caused problems for nearly all videos on low-FPS video projectors (playing 24 FPS video on a 24 FPS projector would not work reliably as MPlayer may need to slightly speed up the video for AV sync). This commit adds a framedrop mechanism that drops some frames so that no more than one is sent for display per vsync. The code tries to select the dropped frames smartly, selecting the best one to show for each vsync. Because of the timing features needed the drop functionality currently does not work if the correct-pts option is disabled. The code also adjusts frame timing slightly to avoid jitter. If you for example play 24 FPS video content on a 72 FPS display then normally a frame would be shown for 3 vsyncs, but if the frame times happen to fall near vsyncs and change between just before and just after then there could be frames alternating between 2 and 4 vsyncs. The code changes frame timing by up to one quarter vsync interval to avoid this. The above functionality depends on having reliable vsync timing information available. The display refresh rate is not directly provided by the VDPAU API. The current code uses information from the XF86VidMode extension if available; I'm not sure how common cases where that is inaccurate are. The refresh rate can be specified manually if necessary. After the changes in this commit MPlayer now always tries to keep one frame queued for future display using VDPAU's internal timing mechanism (however no more than 50 ms to the future). This should make video playback somewhat more robust against timing inaccuracies caused by system load.
2009-11-15 03:39:22 +01:00
vc->last_queue_time = pts;
vo_vdpau: support queuing an arbitrary number of frames ahead Make the number of output surfaces allocated by vo_vdpau configurable and allow queuing multiple future frames with the VDPAU frame timing functionality. There are two known issues that could be polished in the future for particularly long queue time cases. First, toplevel code should possibly wait for the queued changes to finish displaying in some situations like switching files. Second, the VO can block waiting for a surface to become available, and in the worst case this wait can be almost as long as the maximum queuing time (potentially causing audio underruns). However those issues are not high priority.
2010-05-14 04:18:38 +02:00
vc->queue_time[vc->surface_num] = pts;
Implement vsync-aware frame timing for VDPAU Main things added are custom frame dropping for VDPAU to work around the display FPS limit, frame timing adjustment to avoid jitter when video frame times keep falling near vsyncs, and use of VDPAU's timing feature to keep one future frame queued in advance. NVIDIA's VDPAU implementation refuses to change the displayed frame more than once per vsync. This set a limit on how much video could be sped up, and caused problems for nearly all videos on low-FPS video projectors (playing 24 FPS video on a 24 FPS projector would not work reliably as MPlayer may need to slightly speed up the video for AV sync). This commit adds a framedrop mechanism that drops some frames so that no more than one is sent for display per vsync. The code tries to select the dropped frames smartly, selecting the best one to show for each vsync. Because of the timing features needed the drop functionality currently does not work if the correct-pts option is disabled. The code also adjusts frame timing slightly to avoid jitter. If you for example play 24 FPS video content on a 72 FPS display then normally a frame would be shown for 3 vsyncs, but if the frame times happen to fall near vsyncs and change between just before and just after then there could be frames alternating between 2 and 4 vsyncs. The code changes frame timing by up to one quarter vsync interval to avoid this. The above functionality depends on having reliable vsync timing information available. The display refresh rate is not directly provided by the VDPAU API. The current code uses information from the XF86VidMode extension if available; I'm not sure how common cases where that is inaccurate are. The refresh rate can be specified manually if necessary. After the changes in this commit MPlayer now always tries to keep one frame queued for future display using VDPAU's internal timing mechanism (however no more than 50 ms to the future). This should make video playback somewhat more robust against timing inaccuracies caused by system load.
2009-11-15 03:39:22 +01:00
vc->last_ideal_time = ideal_pts;
vc->dropped_frame = false;
vo_vdpau: support queuing an arbitrary number of frames ahead Make the number of output surfaces allocated by vo_vdpau configurable and allow queuing multiple future frames with the VDPAU frame timing functionality. There are two known issues that could be polished in the future for particularly long queue time cases. First, toplevel code should possibly wait for the queued changes to finish displaying in some situations like switching files. Second, the VO can block waiting for a surface to become available, and in the worst case this wait can be almost as long as the maximum queuing time (potentially causing audio underruns). However those issues are not high priority.
2010-05-14 04:18:38 +02:00
vc->surface_num = WRAP_ADD(vc->surface_num, 1, vc->num_output_surfaces);
Add support for VDPAU video out, including hardware decoding. git-svn-id: svn://svn.mplayerhq.hu/mplayer/trunk@28617 b3059339-0415-0410-9bf9-f77b7e298cf2
2009-02-16 21:58:13 +01:00
}
vo_vdpau: 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
static VdpOutputSurface get_rgb_surface(struct vo *vo)
{
struct vdpctx *vc = vo->priv;
assert(vc->rgb_mode);
for (int n = 0; n < NUM_BUFFERED_VIDEO; n++) {
VdpOutputSurface surface = vc->rgb_surfaces[n];
// Note: we expect to be called before add_new_video_surface(), which
// will lead to vc->buffered_video[NUM_BUFFERED_VIDEO - 1] to be
// marked unused. So this entries rgb_surface can be reused
// freely.
for (int i = 0; i < NUM_BUFFERED_VIDEO - 1; i++) {
if (vc->buffered_video[i].rgb_surface == surface)
goto in_use;
}
return surface;
in_use:;
}
Some more mp_msg conversions Also add a note to mp_msg.h, since it might be not clear which of the two mechanisms is preferred.
2013-08-23 23:30:09 +02:00
MP_ERR(vo, "no surfaces available in get_rgb_surface\n");
vo_vdpau: 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 VDP_INVALID_HANDLE;
}
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
static void draw_image(struct vo *vo, mp_image_t *mpi)
Add support for VDPAU video out, including hardware decoding. git-svn-id: svn://svn.mplayerhq.hu/mplayer/trunk@28617 b3059339-0415-0410-9bf9-f77b7e298cf2
2009-02-16 21:58:13 +01:00
{
vo_vdpau: Replace global function table with context variable
2009-05-06 20:04:37 +02:00
struct vdpctx *vc = vo->priv;
struct vdp_functions *vdp = vc->vdp;
core/VO: Allow VO drivers to add/modify frames Add interfaces to allow VO drivers to add or remove frames from the video stream and to alter timestamps. Currently this functionality only works with in correct-pts mode. Use the new functionality in vo_vdpau to properly support frame-adding deinterlace modes. Frames added by the VDPAU deinterlacing code are now properly timed. Before every second frame was always shown immediately (probably next monitor refresh) after the previous one, even if you were watching things in slow motion, and framestepping didn't stop at them at all. When seeking the deinterlace algorithm is no longer fed a mix of frames from old and new positions. As a side effect of the changes a problem with resize events was also fixed. Resizing calls video_to_output_surface() to render the frame at the new resolution, but before this function also changed the list of history frames, so resizing could give an image different from the original one, and also corrupt next frames due to them seeing the wrong history. Now the function has no such side effects. There are more resize-related problems though that will be fixed in a later commit. The deint_mpi[] list of reserved frames is increased from 2 to 3 entries for reasons related to the above. Having 2 entries is enough when you initially get a new frame in draw_image() because then you'll have those two entries plus the new one for a total of 3 (the code relied on the oldest mpi implicitly staying reserved for the duration of the call even after usage count was decreased). However if you want to be able to reproduce the rendering outside draw_image(), relying on the explicitly reserved list only, then it needs to store 3 entries.
2009-09-18 15:27:55 +02:00
struct mp_image *reserved_mpi = NULL;
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
VdpVideoSurface surface = VDP_INVALID_HANDLE;
vo_vdpau: add RGB support Apparently this was dropped some years ago, but judging from MPlayer's handling of this, the original code wasn't so great anyway. The new code handling clearing of panscan borders correctly, and integrates better with the YUV path. (Although the VDPAU API sure makes this annoying with its separate surface types for RGB.) Note that we create 5 surfaces for some reason - I don't think this makes too much sense (because we can't use the deinterlacer with RGB surfaces), but at least it reduces the amount of differences with the YUV code path. Clearing the borders is done by drawing a single black pixel over the window. This sounds pretty dumb, but it appears to work well, and there is no other API for that. (One could try to use the video mixer for this purpose, since it has all kinds of features, including compositing multiple RGBA surfaces and clearing the window background. But it would require an invisible dummy video surface to make the video mixer happy, and that's getting too messy.)
2013-08-18 05:12:21 +02:00
VdpOutputSurface rgb_surface = VDP_INVALID_HANDLE;
VdpStatus vdp_st;
core/VO: Allow VO drivers to add/modify frames Add interfaces to allow VO drivers to add or remove frames from the video stream and to alter timestamps. Currently this functionality only works with in correct-pts mode. Use the new functionality in vo_vdpau to properly support frame-adding deinterlace modes. Frames added by the VDPAU deinterlacing code are now properly timed. Before every second frame was always shown immediately (probably next monitor refresh) after the previous one, even if you were watching things in slow motion, and framestepping didn't stop at them at all. When seeking the deinterlace algorithm is no longer fed a mix of frames from old and new positions. As a side effect of the changes a problem with resize events was also fixed. Resizing calls video_to_output_surface() to render the frame at the new resolution, but before this function also changed the list of history frames, so resizing could give an image different from the original one, and also corrupt next frames due to them seeing the wrong history. Now the function has no such side effects. There are more resize-related problems though that will be fixed in a later commit. The deint_mpi[] list of reserved frames is increased from 2 to 3 entries for reasons related to the above. Having 2 entries is enough when you initially get a new frame in draw_image() because then you'll have those two entries plus the new one for a total of 3 (the code relied on the oldest mpi implicitly staying reserved for the duration of the call even after usage count was decreased). However if you want to be able to reproduce the rendering outside draw_image(), relying on the explicitly reserved list only, then it needs to store 3 entries.
2009-09-18 15:27:55 +02:00
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 previous frames, as we can display a new one now.
vc->prev_deint_queue_pos = -1001;
vdpau: always let decoder output IMGFMT_VDPAU The old ffmpeg vdpau support code uses separate vdpau pixel formats for each decoder (pretty much because mplayer's architecture sucked), which just gets into the way. Force the old decoder's output to IMGFMT_VDPAU, and remove IMGFMT_IS_VDPAU() where we can remove it. This should completely remove the differences betwene the old and new vdpau decoder outside of the decoder.
2013-11-29 14:19:44 +01:00
if (vc->image_format == IMGFMT_VDPAU) {
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
surface = (VdpVideoSurface)(intptr_t)mpi->planes[3];
reserved_mpi = mp_image_new_ref(mpi);
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
} else if (vc->rgb_mode) {
rgb_surface = get_rgb_surface(vo);
if (rgb_surface != VDP_INVALID_HANDLE) {
vdp_st = vdp->output_surface_put_bits_native(rgb_surface,
&(const void *){mpi->planes[0]},
&(uint32_t){mpi->stride[0]},
NULL);
CHECK_ST_WARNING("Error when calling "
"output_surface_put_bits_native");
}
video: remove slice based filtering and video output Slices allowed filtering or drawing video in horizontal bands or blocks. This allowed working on the video in smaller units. In theory, this could bring a performance win by lowering cache pressure, as you didn't have to keep the whole video frame in cache while filtering, only the slice. In practice, the slice code path was barely used for the following reasons: - Multithreaded decoding with ffmpeg didn't use slices. The ffmpeg slice callback was disabled, because it can be called from another thread, and the mplayer video chain is not thread-safe. - There was nothing that would turn "full" images into appropriate slices, so slices were rarely used. - Most filters didn't actually support slices. On the other hand, supporting slices lead to code duplication and more complex code in general. I made some experiments and didn't find any actual measurable performance improvements when using slices. Even ffmpeg removed slices based filtering from libavfilter in favor of simpler code. The most broken thing about the slices code path is that slices can't be queued, like it is done for images in vo.c.
2012-11-04 18:16:36 +01:00
} else {
vdpau: 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
reserved_mpi = mp_vdpau_get_video_surface(vc->mpvdp, IMGFMT_VDPAU,
vc->vdp_chroma_type,
mpi->w, mpi->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
if (!reserved_mpi)
return;
surface = (VdpVideoSurface)(intptr_t)reserved_mpi->planes[3];
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 (handle_preemption(vo) >= 0) {
const void *destdata[3] = {mpi->planes[0], mpi->planes[2],
mpi->planes[1]};
if (vc->image_format == IMGFMT_NV12)
destdata[1] = destdata[2];
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
vdp_st = vdp->video_surface_put_bits_y_cb_cr(surface,
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
vc->vdp_pixel_format, destdata, mpi->stride);
CHECK_ST_WARNING("Error when calling "
"vdp_video_surface_put_bits_y_cb_cr");
}
video: remove slice based filtering and video output Slices allowed filtering or drawing video in horizontal bands or blocks. This allowed working on the video in smaller units. In theory, this could bring a performance win by lowering cache pressure, as you didn't have to keep the whole video frame in cache while filtering, only the slice. In practice, the slice code path was barely used for the following reasons: - Multithreaded decoding with ffmpeg didn't use slices. The ffmpeg slice callback was disabled, because it can be called from another thread, and the mplayer video chain is not thread-safe. - There was nothing that would turn "full" images into appropriate slices, so slices were rarely used. - Most filters didn't actually support slices. On the other hand, supporting slices lead to code duplication and more complex code in general. I made some experiments and didn't find any actual measurable performance improvements when using slices. Even ffmpeg removed slices based filtering from libavfilter in favor of simpler code. The most broken thing about the slices code path is that slices can't be queued, like it is done for images in vo.c.
2012-11-04 18:16:36 +01:00
}
10l: Don't use MP_IMGFIELD_TOP_FIRST if MP_IMGFIELD_ORDERED is not set. git-svn-id: svn://svn.mplayerhq.hu/mplayer/trunk@29093 b3059339-0415-0410-9bf9-f77b7e298cf2
2009-03-29 13:15:22 +02:00
if (mpi->fields & MP_IMGFIELD_ORDERED)
vo_vdpau: Move things to context struct
2009-05-06 22:42:24 +02:00
vc->top_field_first = !!(mpi->fields & MP_IMGFIELD_TOP_FIRST);
10l: Don't use MP_IMGFIELD_TOP_FIRST if MP_IMGFIELD_ORDERED is not set. git-svn-id: svn://svn.mplayerhq.hu/mplayer/trunk@29093 b3059339-0415-0410-9bf9-f77b7e298cf2
2009-03-29 13:15:22 +02:00
else
vo_vdpau: Move things to context struct
2009-05-06 22:42:24 +02:00
vc->top_field_first = 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: 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
add_new_video_surface(vo, surface, rgb_surface, reserved_mpi, mpi->pts);
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;
}
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
static struct mp_image *read_output_surface(struct vdpctx *vc,
vo_vdpau: fix screenshots Attempting to take screenshots printed vdpau errors on the terminal, and the resulting screenshots were filled with black. The problem was that that the screenshot code tried to use an unallocated output surface (the one at vc->output_surfaces[vc->num_output_surfaces]). This used to refer to the last allocated surface, until this was changed by a recently merged commit. That commit also added a separate screenshot surface. The merge somehow went wrong, and that part was not integrated. <uau> wm4: you used an earlier buggy version of a commit OK...
2012-10-21 00:48:01 +02:00
VdpOutputSurface surface,
int width, int height)
vo_vdpau: implement screenshots
2011-10-06 20:46:01 +02:00
{
VdpStatus vdp_st;
struct vdp_functions *vdp = vc->vdp;
video: cleanup: replace old mp_image function names mp_image_alloc() also changes argument order compared to alloc_mpi(). The format now comes first, then width/height.
2012-12-22 21:46:22 +01:00
struct mp_image *image = mp_image_alloc(IMGFMT_BGR32, width, height);
screenshot: let VOs pass colorspace information via mp_image This removes the hack that screenshot_save() got the colorspace information from the decoder. Instead, require the VOs to set the colorspace information on the mp_images used to pass around the screenshot data. This is more correct, as the image may have been converted/modified in the video filter chain, although there's nothing yet in the video filter chain which does this correctly.
2012-10-26 19:29:47 +02:00
image->colorspace = MP_CSP_RGB;
image->levels = vc->colorspace.levels_out; // hardcoded with conv. matrix
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);
CHECK_ST_WARNING("Error when calling vdp_output_surface_get_bits_native");
return image;
}
static struct mp_image *get_screenshot(struct vo *vo)
{
struct vdpctx *vc = vo->priv;
vo_vdpau: fix screenshots Attempting to take screenshots printed vdpau errors on the terminal, and the resulting screenshots were filled with black. The problem was that that the screenshot code tried to use an unallocated output surface (the one at vc->output_surfaces[vc->num_output_surfaces]). This used to refer to the last allocated surface, until this was changed by a recently merged commit. That commit also added a separate screenshot surface. The merge somehow went wrong, and that part was not integrated. <uau> wm4: you used an earlier buggy version of a commit OK...
2012-10-21 00:48:01 +02:00
VdpStatus vdp_st;
struct vdp_functions *vdp = vc->vdp;
vo_vdpau: implement screenshots
2011-10-06 20:46:01 +02:00
vo_vdpau: fix screenshots Attempting to take screenshots printed vdpau errors on the terminal, and the resulting screenshots were filled with black. The problem was that that the screenshot code tried to use an unallocated output surface (the one at vc->output_surfaces[vc->num_output_surfaces]). This used to refer to the last allocated surface, until this was changed by a recently merged commit. That commit also added a separate screenshot surface. The merge somehow went wrong, and that part was not integrated. <uau> wm4: you used an earlier buggy version of a commit OK...
2012-10-21 00:48:01 +02:00
if (vc->screenshot_surface == VDP_INVALID_HANDLE) {
vdp_st = vdp->output_surface_create(vc->vdp_device,
OUTPUT_RGBA_FORMAT,
vc->vid_width, vc->vid_height,
&vc->screenshot_surface);
CHECK_ST_WARNING("Error when calling vdp_output_surface_create");
}
vo_vdpau: implement screenshots
2011-10-06 20:46:01 +02:00
VdpRect rc = { .x1 = vc->vid_width, .y1 = vc->vid_height };
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
render_video_to_output_surface(vo, vc->screenshot_surface, &rc, &rc);
vo_vdpau: implement screenshots
2011-10-06 20:46:01 +02:00
vo_vdpau: fix screenshots Attempting to take screenshots printed vdpau errors on the terminal, and the resulting screenshots were filled with black. The problem was that that the screenshot code tried to use an unallocated output surface (the one at vc->output_surfaces[vc->num_output_surfaces]). This used to refer to the last allocated surface, until this was changed by a recently merged commit. That commit also added a separate screenshot surface. The merge somehow went wrong, and that part was not integrated. <uau> wm4: you used an earlier buggy version of a commit OK...
2012-10-21 00:48:01 +02:00
struct mp_image *image = read_output_surface(vc, vc->screenshot_surface,
vc->vid_width, vc->vid_height);
vo_vdpau: implement screenshots
2011-10-06 20:46:01 +02:00
mp_image: require using mp_image_set_size() for setting w/h Setting the size of a mp_image must be done with mp_image_set_size() now. Do this to guarantee that the redundant fields (like chroma_width) are updated consistently. Replacing the redundant fields by function calls would probably be better, but there are too many uses of them, and is a bit less convenient. Most code actually called mp_image_setfmt(), which did this as well. This commit just makes things a bit more explicit. Warning: the video filter chain still sets up mp_images manually, and vf_get_image() is not updated.
2012-11-10 02:02:24 +01:00
mp_image_set_display_size(image, vo->aspdat.prew, vo->aspdat.preh);
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: fix screenshots Attempting to take screenshots printed vdpau errors on the terminal, and the resulting screenshots were filled with black. The problem was that that the screenshot code tried to use an unallocated output surface (the one at vc->output_surfaces[vc->num_output_surfaces]). This used to refer to the last allocated surface, until this was changed by a recently merged commit. That commit also added a separate screenshot surface. The merge somehow went wrong, and that part was not integrated. <uau> wm4: you used an earlier buggy version of a commit OK...
2012-10-21 00:48:01 +02:00
struct mp_image *image = read_output_surface(vo->priv, screen,
vc->output_surface_width,
vc->output_surface_height);
mp_image: require using mp_image_set_size() for setting w/h Setting the size of a mp_image must be done with mp_image_set_size() now. Do this to guarantee that the redundant fields (like chroma_width) are updated consistently. Replacing the redundant fields by function calls would probably be better, but there are too many uses of them, and is a bit less convenient. Most code actually called mp_image_setfmt(), which did this as well. This commit just makes things a bit more explicit. Warning: the video filter chain still sets up mp_images manually, and vf_get_image() is not updated.
2012-11-10 02:02:24 +01:00
mp_image_set_size(image, vo->dwidth, vo->dheight);
vo_vdpau: implement screenshots
2011-10-06 20:46:01 +02:00
return image;
}
video/out: replace VOCTRL_QUERY_FORMAT with vo_driver.query_format
2012-11-04 16:24:18 +01:00
static int query_format(struct vo *vo, uint32_t format)
Add support for VDPAU video out, including hardware decoding. git-svn-id: svn://svn.mplayerhq.hu/mplayer/trunk@28617 b3059339-0415-0410-9bf9-f77b7e298cf2
2009-02-16 21:58:13 +01:00
{
vo_vdpau: add RGB support Apparently this was dropped some years ago, but judging from MPlayer's handling of this, the original code wasn't so great anyway. The new code handling clearing of panscan borders correctly, and integrates better with the YUV path. (Although the VDPAU API sure makes this annoying with its separate surface types for RGB.) Note that we create 5 surfaces for some reason - I don't think this makes too much sense (because we can't use the deinterlacer with RGB surfaces), but at least it reduces the amount of differences with the YUV code path. Clearing the borders is done by drawing a single black pixel over the window. This sounds pretty dumb, but it appears to work well, and there is no other API for that. (One could try to use the video mixer for this purpose, since it has all kinds of features, including compositing multiple RGBA surfaces and clearing the window background. But it would require an invisible dummy video surface to make the video mixer happy, and that's getting too messy.)
2013-08-18 05:12:21 +02:00
struct vdpctx *vc = vo->priv;
video: remove --flip The --flip option flipped the image upside-down, by trying to use VO support, or if not available, by inserting a video filter. I'm not sure why it existed. Maybe it was important in ancient times when VfW based decoders output an image this way (but even then, flipping an image is a free operation by negating the stride). One nice thing about this is that it provided a possible path for implementing video orientation, which is a feature we should probably support eventually. The important part is that it would be for free for VOs that support it, and would work even with hardware decoding. But for now get rid of it. It's useless, trivial, stands in the way, and supporting video orientation would require solving other problems first.
2013-12-05 22:55:35 +01:00
int flags = VFCAP_CSP_SUPPORTED | VFCAP_CSP_SUPPORTED_BY_HW;
vo_vdpau: add RGB support Apparently this was dropped some years ago, but judging from MPlayer's handling of this, the original code wasn't so great anyway. The new code handling clearing of panscan borders correctly, and integrates better with the YUV path. (Although the VDPAU API sure makes this annoying with its separate surface types for RGB.) Note that we create 5 surfaces for some reason - I don't think this makes too much sense (because we can't use the deinterlacer with RGB surfaces), but at least it reduces the amount of differences with the YUV code path. Clearing the borders is done by drawing a single black pixel over the window. This sounds pretty dumb, but it appears to work well, and there is no other API for that. (One could try to use the video mixer for this purpose, since it has all kinds of features, including compositing multiple RGBA surfaces and clearing the window background. But it would require an invisible dummy video surface to make the video mixer happy, and that's getting too messy.)
2013-08-18 05:12:21 +02:00
if (mp_vdpau_get_format(format, NULL, NULL))
return flags;
int rgb_format = get_rgb_format(format);
if (!vc->force_yuv && rgb_format >= 0)
return flags;
return 0;
Add support for VDPAU video out, including hardware decoding. git-svn-id: svn://svn.mplayerhq.hu/mplayer/trunk@28617 b3059339-0415-0410-9bf9-f77b7e298cf2
2009-02-16 21:58:13 +01:00
}
vo_vdpau: Replace global function table with context variable
2009-05-06 20:04:37 +02:00
static void destroy_vdpau_objects(struct vo *vo)
Add support for VDPAU video out, including hardware decoding. git-svn-id: svn://svn.mplayerhq.hu/mplayer/trunk@28617 b3059339-0415-0410-9bf9-f77b7e298cf2
2009-02-16 21:58:13 +01:00
{
vo_vdpau: Replace global function table with context variable
2009-05-06 20:04:37 +02:00
struct vdpctx *vc = vo->priv;
struct vdp_functions *vdp = vc->vdp;
Add support for VDPAU video out, including hardware decoding. git-svn-id: svn://svn.mplayerhq.hu/mplayer/trunk@28617 b3059339-0415-0410-9bf9-f77b7e298cf2
2009-02-16 21:58:13 +01:00
VdpStatus vdp_st;
vo_vdpau: Replace global function table with context variable
2009-05-06 20:04:37 +02:00
free_video_specific(vo);
Add support for VDPAU video out, including hardware decoding. git-svn-id: svn://svn.mplayerhq.hu/mplayer/trunk@28617 b3059339-0415-0410-9bf9-f77b7e298cf2
2009-02-16 21:58:13 +01:00
vo_vdpau: Make CHECK_ST macro safer Also contains a couple of changes in destroy_vdpau_objects.
2009-05-08 19:57:22 +02:00
if (vc->flip_queue != VDP_INVALID_HANDLE) {
vdp_st = vdp->presentation_queue_destroy(vc->flip_queue);
vo_vdpau.c: cosmetics
2009-05-09 17:08:30 +02:00
CHECK_ST_WARNING("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);
vo_vdpau.c: cosmetics
2009-05-09 17:08:30 +02:00
CHECK_ST_WARNING("Error when calling "
"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]);
vo_vdpau.c: cosmetics
2009-05-09 17:08:30 +02:00
CHECK_ST_WARNING("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);
CHECK_ST_WARNING("Error when calling vdp_bitmap_surface_destroy");
}
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
{
/* Destroy all vdpau objects */
vo_vdpau: Replace global function table with context variable
2009-05-06 20:04:37 +02:00
destroy_vdpau_objects(vo);
EOSD/ASS support for vo_vdpau.c Patch by Grigori G (greg <at> chown ath cx) with minor cosmetic changes by me. git-svn-id: svn://svn.mplayerhq.hu/mplayer/trunk@28710 b3059339-0415-0410-9bf9-f77b7e298cf2
2009-02-23 10:21:57 +01:00
vo_vdpau: Make compile as new-style VO
2009-05-04 02:09:50 +02:00
vo_x11_uninit(vo);
Add support for VDPAU video out, including hardware decoding. git-svn-id: svn://svn.mplayerhq.hu/mplayer/trunk@28617 b3059339-0415-0410-9bf9-f77b7e298cf2
2009-02-16 21:58:13 +01:00
}
video/out: remove options argument from preinit() All VOs use proper option parsing now, and compatibility hacks are not needed.
2013-07-22 22:52:42 +02:00
static int preinit(struct vo *vo)
Add support for VDPAU video out, including hardware decoding. git-svn-id: svn://svn.mplayerhq.hu/mplayer/trunk@28617 b3059339-0415-0410-9bf9-f77b7e298cf2
2009-02-16 21:58:13 +01:00
{
VO: implement shared option handling, use for vdpau Add infrastructure that allows VOs to specify the suboptions they take, and get the values directly parsed into their private struct. The option functionality available with the new system is the same as for top-level player options. Convert vo_vdpau to use the new system instead of the old subopt_helper.
2012-06-25 22:12:03 +02:00
struct vdpctx *vc = vo->priv;
Add support for VDPAU video out, including hardware decoding. git-svn-id: svn://svn.mplayerhq.hu/mplayer/trunk@28617 b3059339-0415-0410-9bf9-f77b7e298cf2
2009-02-16 21:58:13 +01:00
vdpau: move device and video surface management from vo_vdpau.c to vdpau.c The goal is being able to use vdpau decoding independently from vo_vdpau.c.
2013-11-05 22:06:32 +01:00
if (!vo_x11_init(vo))
return -1;
vc->mpvdp = mp_vdpau_create_device_x11(vo->log, vo->x11);
if (!vc->mpvdp) {
vo_x11_uninit(vo);
return -1;
}
vdpau: split off decoder parts, use "new" libavcodec vdpau hwaccel API Move the decoder parts from vo_vdpau.c to a new file vdpau_old.c. This file is named so because because it's written against the "old" libavcodec vdpau pseudo-decoder (e.g. "h264_vdpau"). Add support for the "new" libavcodec vdpau support. This was recently added and replaces the "old" vdpau parts. (In fact, Libav is about to deprecate and remove the "old" API without deprecation grace period, so we have to support it now. Moreover, there will probably be no Libav release which supports both, so the transition is even less smooth than we could hope, and we have to support both the old and new API.) Whether the old or new API is used is checked by a configure test: if the new API is found, it is used, otherwise the old API is assumed. Some details might be handled differently. Especially display preemption is a bit problematic with the "new" libavcodec vdpau support: it wants to keep a pointer to a specific vdpau API function (which can be driver specific, because preemption might switch drivers). Also, surface IDs are now directly stored in AVFrames (and mp_images), so they can't be forced to VDP_INVALID_HANDLE on preemption. (This changes even with older libavcodec versions, because mp_image always uses the newer representation to make vo_vdpau.c simpler.) Decoder initialization in the new code tries to deal with codec profiles, while the old code always uses the highest profile per codec. Surface allocation changes. Since the decoder won't call config() in vo_vdpau.c on video size change anymore, we allow allocating surfaces of arbitrary size instead of locking it to what the VO was configured. The non-hwdec code also has slightly different allocation behavior now. Enabling the old vdpau special decoders via e.g. --vd=lavc:h264_vdpau doesn't work anymore (a warning suggesting the --hwdec option is printed instead).
2013-07-28 01:49:45 +02:00
vo_vpdau: Clean up uninit logic
2009-05-08 20:48:01 +02:00
// Mark everything as invalid first so uninit() can tell what has been
// allocated
vo_vdpau: Support recovering from VDPAU display preemption Add code to reinitialize all VDPAU objects if a display preemption condition occurs. Reinitializing them in the middle of playback will cause video corruption at least until the next keyframe when using hardware decoding, but decoding does seem to recover after a keyframe.
2009-09-07 01:02:24 +02:00
mark_vdpau_objects_uninitialized(vo);
vo_vpdau: Clean up uninit logic
2009-05-08 20:48:01 +02:00
vdpau: move device and video surface management from vo_vdpau.c to vdpau.c The goal is being able to use vdpau decoding independently from vo_vdpau.c.
2013-11-05 22:06:32 +01:00
vc->preemption_counter = vc->mpvdp->preemption_counter;
vc->vdp_device = vc->mpvdp->vdp_device;
vc->vdp = vc->mpvdp->vdp;
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->colorspace = (struct mp_csp_details) MP_CSP_DETAILS_DEFAULTS;
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
vc->deint_type = vc->deint ? FFABS(vc->deint) : 3;
vo_vdpau: allow "deint=-N" to specify mode without enabling deint Allow negative values of the "deint" parameter and make them select the same deinterlacing mode as the corresponding positive value, but without enabling deinterlace on startup. This is useful for configuration files. Also tweak the overall manpage description of vo_vdpau a bit to make it sound less as if the VO would be for hardware acceleration only.
2011-01-04 22:51:31 +01:00
if (vc->deint < 0)
vc->deint = 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 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;
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
return mp_csp_equalizer_get(&vc->video_eq, name, value) >= 0 ?
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;
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
if (mp_csp_equalizer_set(&vc->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_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
if (status_ok(vo))
update_csc_matrix(vo);
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;
struct vdp_functions *vdp = vc->vdp;
vo_vdpau: Support recovering from VDPAU display preemption Add code to reinitialize all VDPAU objects if a display preemption condition occurs. Reinitializing them in the middle of playback will cause video corruption at least until the next keyframe when using hardware decoding, but decoding does seem to recover after a keyframe.
2009-09-07 01:02:24 +02:00
handle_preemption(vo);
Add support for VDPAU video out, including hardware decoding. git-svn-id: svn://svn.mplayerhq.hu/mplayer/trunk@28617 b3059339-0415-0410-9bf9-f77b7e298cf2
2009-02-16 21:58:13 +01:00
switch (request) {
vo_vdpau.c: Reindent control() switch statement
2009-09-05 05:20:03 +02:00
case VOCTRL_GET_DEINTERLACE:
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)
break;
cosmetics: remove unused code, small formatting tweaks
2010-12-20 05:42:04 +01:00
*(int *)data = vc->deint;
vo_vdpau.c: Reindent control() switch statement
2009-09-05 05:20:03 +02:00
return VO_TRUE;
case VOCTRL_SET_DEINTERLACE:
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)
break;
vc->deint = vc->user_deint = *(int *)data;
vo_vdpau.c: Reindent control() switch statement
2009-09-05 05:20:03 +02:00
if (vc->deint)
vc->deint = vc->deint_type;
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
if (vc->deint_type > 2 && status_ok(vo)) {
vo_vdpau.c: Reindent control() switch statement
2009-09-05 05:20:03 +02:00
VdpStatus vdp_st;
VdpVideoMixerFeature features[1] =
{vc->deint_type == 3 ?
VDP_VIDEO_MIXER_FEATURE_DEINTERLACE_TEMPORAL :
VDP_VIDEO_MIXER_FEATURE_DEINTERLACE_TEMPORAL_SPATIAL};
VdpBool feature_enables[1] = {vc->deint ? VDP_TRUE : VDP_FALSE};
vdp_st = vdp->video_mixer_set_feature_enables(vc->video_mixer,
1, features,
feature_enables);
CHECK_ST_WARNING("Error changing deinterlacing settings");
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;
vo_vdpau.c: Reindent control() switch statement
2009-09-05 05:20:03 +02:00
return VO_TRUE;
case VOCTRL_PAUSE:
Implement vsync-aware frame timing for VDPAU Main things added are custom frame dropping for VDPAU to work around the display FPS limit, frame timing adjustment to avoid jitter when video frame times keep falling near vsyncs, and use of VDPAU's timing feature to keep one future frame queued in advance. NVIDIA's VDPAU implementation refuses to change the displayed frame more than once per vsync. This set a limit on how much video could be sped up, and caused problems for nearly all videos on low-FPS video projectors (playing 24 FPS video on a 24 FPS projector would not work reliably as MPlayer may need to slightly speed up the video for AV sync). This commit adds a framedrop mechanism that drops some frames so that no more than one is sent for display per vsync. The code tries to select the dropped frames smartly, selecting the best one to show for each vsync. Because of the timing features needed the drop functionality currently does not work if the correct-pts option is disabled. The code also adjusts frame timing slightly to avoid jitter. If you for example play 24 FPS video content on a 72 FPS display then normally a frame would be shown for 3 vsyncs, but if the frame times happen to fall near vsyncs and change between just before and just after then there could be frames alternating between 2 and 4 vsyncs. The code changes frame timing by up to one quarter vsync interval to avoid this. The above functionality depends on having reliable vsync timing information available. The display refresh rate is not directly provided by the VDPAU API. The current code uses information from the XF86VidMode extension if available; I'm not sure how common cases where that is inaccurate are. The refresh rate can be specified manually if necessary. After the changes in this commit MPlayer now always tries to keep one frame queued for future display using VDPAU's internal timing mechanism (however no more than 50 ms to the future). This should make video playback somewhat more robust against timing inaccuracies caused by system load.
2009-11-15 03:39:22 +01:00
if (vc->dropped_frame)
vo_vdpau: use new want_redraw mechanism in one more case
2011-12-09 02:08:37 +01:00
vo->want_redraw = true;
core, vo: new window refresh logic, add slow-video OSD redraw Remove code refreshing window contents after events such as resize from vo_vdpau, vo_gl and vo_xv. Instead have them simply set a flag indicating that a refresh is needed, and have the player core perform that refresh by doing an OSD redraw. Also add support for updating the OSD contents over existing frames during slow-but-not-paused playback. The VOs now also request a refresh if parameters affecting the picture change (equalizer settings, colormatrix, VDPAU deinterlacing setting). Even previously the picture was typically redrawn with the new settings while paused because new OSD messages associated with setting changes triggered a redraw, but this did not happen if OSD was turned off. A minor imperfection is that now window system events can trigger a single one-frame step forward when using vo_xv after pausing so that vo_xv does not yet have a copy of the current image. This could be fixed but I think it's not important enough to bother.
2011-12-05 05:36:20 +01:00
return true;
vdpau: split off decoder parts, use "new" libavcodec vdpau hwaccel API Move the decoder parts from vo_vdpau.c to a new file vdpau_old.c. This file is named so because because it's written against the "old" libavcodec vdpau pseudo-decoder (e.g. "h264_vdpau"). Add support for the "new" libavcodec vdpau support. This was recently added and replaces the "old" vdpau parts. (In fact, Libav is about to deprecate and remove the "old" API without deprecation grace period, so we have to support it now. Moreover, there will probably be no Libav release which supports both, so the transition is even less smooth than we could hope, and we have to support both the old and new API.) Whether the old or new API is used is checked by a configure test: if the new API is found, it is used, otherwise the old API is assumed. Some details might be handled differently. Especially display preemption is a bit problematic with the "new" libavcodec vdpau support: it wants to keep a pointer to a specific vdpau API function (which can be driver specific, because preemption might switch drivers). Also, surface IDs are now directly stored in AVFrames (and mp_images), so they can't be forced to VDP_INVALID_HANDLE on preemption. (This changes even with older libavcodec versions, because mp_image always uses the newer representation to make vo_vdpau.c simpler.) Decoder initialization in the new code tries to deal with codec profiles, while the old code always uses the highest profile per codec. Surface allocation changes. Since the decoder won't call config() in vo_vdpau.c on video size change anymore, we allow allocating surfaces of arbitrary size instead of locking it to what the VO was configured. The non-hwdec code also has slightly different allocation behavior now. Enabling the old vdpau special decoders via e.g. --vd=lavc:h264_vdpau doesn't work anymore (a warning suggesting the --hwdec option is printed instead).
2013-07-28 01:49:45 +02:00
case VOCTRL_GET_HWDEC_INFO: {
struct mp_hwdec_info *arg = data;
vdpau: move device and video surface management from vo_vdpau.c to vdpau.c The goal is being able to use vdpau decoding independently from vo_vdpau.c.
2013-11-05 22:06:32 +01:00
arg->vdpau_ctx = vc->mpvdp;
video/filter: change filter API, use refcounting, remove filter DR Change the entire filter API to use reference counted images instead of vf_get_image(). Remove filter "direct rendering". This was useful for vf_expand and (in rare cases) vf_sub: DR allowed these filters to pass a cropped image to the filters before them. Then, on filtering, the image was "uncropped", so that black bars could be added around the image without copying. This means that in some cases, vf_expand will be slower (-vf gradfun,expand for example). Note that another form of DR used for in-place filters has been replaced by simpler logic. Instead of trying to do DR, filters can check if the image is writeable (with mp_image_is_writeable()), and do true in-place if that's the case. This affects filters like vf_gradfun and vf_sub. Everything has to support strides now. If something doesn't, making a copy of the image data is required.
2012-11-05 14:25:04 +01:00
return true;
vdpau: split off decoder parts, use "new" libavcodec vdpau hwaccel API Move the decoder parts from vo_vdpau.c to a new file vdpau_old.c. This file is named so because because it's written against the "old" libavcodec vdpau pseudo-decoder (e.g. "h264_vdpau"). Add support for the "new" libavcodec vdpau support. This was recently added and replaces the "old" vdpau parts. (In fact, Libav is about to deprecate and remove the "old" API without deprecation grace period, so we have to support it now. Moreover, there will probably be no Libav release which supports both, so the transition is even less smooth than we could hope, and we have to support both the old and new API.) Whether the old or new API is used is checked by a configure test: if the new API is found, it is used, otherwise the old API is assumed. Some details might be handled differently. Especially display preemption is a bit problematic with the "new" libavcodec vdpau support: it wants to keep a pointer to a specific vdpau API function (which can be driver specific, because preemption might switch drivers). Also, surface IDs are now directly stored in AVFrames (and mp_images), so they can't be forced to VDP_INVALID_HANDLE on preemption. (This changes even with older libavcodec versions, because mp_image always uses the newer representation to make vo_vdpau.c simpler.) Decoder initialization in the new code tries to deal with codec profiles, while the old code always uses the highest profile per codec. Surface allocation changes. Since the decoder won't call config() in vo_vdpau.c on video size change anymore, we allow allocating surfaces of arbitrary size instead of locking it to what the VO was configured. The non-hwdec code also has slightly different allocation behavior now. Enabling the old vdpau special decoders via e.g. --vd=lavc:h264_vdpau doesn't work anymore (a warning suggesting the --hwdec option is printed instead).
2013-07-28 01:49:45 +02:00
}
vo_vdpau.c: Reindent control() switch statement
2009-09-05 05:20:03 +02:00
case VOCTRL_GET_PANSCAN:
return VO_TRUE;
case VOCTRL_SET_PANSCAN:
vo_vpdau: fix preemption recovery broken in decec7f2a37e559d Commit decec7f2a3 ("vo_vdpau: skip resize code if not fully initialized") broke preemption recovery because the resize code stayed incorrectly disabled when it would have been used to reinitialize things during recovery. Revert that commit and add different checks to avoid running various code when not in a fully functional state.
2011-08-11 20:13:34 +02:00
checked_resize(vo);
vo_vdpau.c: Reindent control() switch statement
2009-09-05 05:20:03 +02:00
return VO_TRUE;
case VOCTRL_SET_EQUALIZER: {
core, vo: new window refresh logic, add slow-video OSD redraw Remove code refreshing window contents after events such as resize from vo_vdpau, vo_gl and vo_xv. Instead have them simply set a flag indicating that a refresh is needed, and have the player core perform that refresh by doing an OSD redraw. Also add support for updating the OSD contents over existing frames during slow-but-not-paused playback. The VOs now also request a refresh if parameters affecting the picture change (equalizer settings, colormatrix, VDPAU deinterlacing setting). Even previously the picture was typically redrawn with the new settings while paused because new OSD messages associated with setting changes triggered a redraw, but this did not happen if OSD was turned off. A minor imperfection is that now window system events can trigger a single one-frame step forward when using vo_xv after pausing so that vo_xv does not yet have a copy of the current image. This could be fixed but I think it's not important enough to bother.
2011-12-05 05:36:20 +01:00
vo->want_redraw = true;
vo_vdpau.c: Reindent control() switch statement
2009-09-05 05:20:03 +02:00
struct voctrl_set_equalizer_args *args = data;
return set_equalizer(vo, args->name, args->value);
}
case VOCTRL_GET_EQUALIZER: {
struct voctrl_get_equalizer_args *args = data;
return get_equalizer(vo, args->name, args->valueptr);
}
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
case VOCTRL_SET_YUV_COLORSPACE:
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)
break;
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->colorspace = *(struct mp_csp_details *)data;
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
if (status_ok(vo))
update_csc_matrix(vo);
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 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;
case VOCTRL_GET_YUV_COLORSPACE:
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)
break;
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_details *)data = vc->colorspace;
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;
vo: do final frame draw only near page flip Separate passing a new frame to VOs using the new API into two steps. The first, vo_draw_image(), happens after a new frame is available from the filter chain. In constrast to old behavior, now the frame is not actually rendered yet at this point (though possible slice draw calls can already reach the VO before). The second step, vo_new_frame_imminent(), happens when we're close enough to the display time of the new frame that we'll commit to flipping it as the next action and will not change the OSD over the previous frame any more. This new behavior fixes a previous problem with vo_vdpau and vo_gl in the situation where the player is paused after decoding a new frame but before flipping it; previously changing OSD in that state would switch to the new frame as a side effect. It would also allow an easy way to fix extra output files produced with something like "--vo=png --frames=1" with precise seeking, but this is not done yet. The code now relies on a new mp_image from the filter chain staying valid even after the vf_vo put_image() call providing it returns. In other words decoders/filters must not deallocate or otherwise invalidate their output frame between passing it forward and returning from the decode/filter call.
2011-12-04 17:10:17 +01:00
case VOCTRL_NEWFRAME:
vc->deint_queue_pos = next_deint_queue_pos(vo, true);
vo_vdpau: fix preemption recovery after recent commits Recent commits for screenshot support and video redraw changes didn't handle vdpau driver preemption state correctly, which could make the player crash if preemption occurred. Fix this and improve preemption handling a bit otherwise.
2011-12-20 02:47:16 +01:00
if (status_ok(vo))
video_to_output_surface(vo);
vo: do final frame draw only near page flip Separate passing a new frame to VOs using the new API into two steps. The first, vo_draw_image(), happens after a new frame is available from the filter chain. In constrast to old behavior, now the frame is not actually rendered yet at this point (though possible slice draw calls can already reach the VO before). The second step, vo_new_frame_imminent(), happens when we're close enough to the display time of the new frame that we'll commit to flipping it as the next action and will not change the OSD over the previous frame any more. This new behavior fixes a previous problem with vo_vdpau and vo_gl in the situation where the player is paused after decoding a new frame but before flipping it; previously changing OSD in that state would switch to the new frame as a side effect. It would also allow an easy way to fix extra output files produced with something like "--vo=png --frames=1" with precise seeking, but this is not done yet. The code now relies on a new mp_image from the filter chain staying valid even after the vf_vo put_image() call providing it returns. In other words decoders/filters must not deallocate or otherwise invalidate their output frame between passing it forward and returning from the decode/filter call.
2011-12-04 17:10:17 +01:00
return true;
case VOCTRL_SKIPFRAME:
vc->deint_queue_pos = next_deint_queue_pos(vo, true);
return true;
core, vo: modify OSD redraw architecture, support EOSD Previously the core sent VFCTRL_REDRAW_OSD to change OSD contents over the current frame. Change this to VFCTRL_REDRAW_FRAME followed by normal EOSD and OSD drawing calls, then vo_flip_page(). The new version supports changing EOSD contents for libass-rendered subtitles and simplifies the redraw support code needed per VO. vo_xv doesn't support EOSD changes because it relies on vf_ass to render EOSD contents earlier in the filter chain. vo_xv logic is additionally simplified because the previous commit removed the need to track the status of current and next images separately (now each frame is guaranteed to become "visible" soon after we receive it as "next", with no VO code running in the interval between).
2011-12-05 04:24:18 +01:00
case VOCTRL_REDRAW_FRAME:
vo_vdpau: fix preemption recovery after recent commits Recent commits for screenshot support and video redraw changes didn't handle vdpau driver preemption state correctly, which could make the player crash if preemption occurred. Fix this and improve preemption handling a bit otherwise.
2011-12-20 02:47:16 +01:00
if (status_ok(vo))
video_to_output_surface(vo);
vo_vdpau: Support updating OSD while paused
2009-09-05 05:33:33 +02:00
return true;
core/VO: Allow VO drivers to add/modify frames Add interfaces to allow VO drivers to add or remove frames from the video stream and to alter timestamps. Currently this functionality only works with in correct-pts mode. Use the new functionality in vo_vdpau to properly support frame-adding deinterlace modes. Frames added by the VDPAU deinterlacing code are now properly timed. Before every second frame was always shown immediately (probably next monitor refresh) after the previous one, even if you were watching things in slow motion, and framestepping didn't stop at them at all. When seeking the deinterlace algorithm is no longer fed a mix of frames from old and new positions. As a side effect of the changes a problem with resize events was also fixed. Resizing calls video_to_output_surface() to render the frame at the new resolution, but before this function also changed the list of history frames, so resizing could give an image different from the original one, and also corrupt next frames due to them seeing the wrong history. Now the function has no such side effects. There are more resize-related problems though that will be fixed in a later commit. The deint_mpi[] list of reserved frames is increased from 2 to 3 entries for reasons related to the above. Having 2 entries is enough when you initially get a new frame in draw_image() because then you'll have those two entries plus the new one for a total of 3 (the code relied on the oldest mpi implicitly staying reserved for the duration of the call even after usage count was decreased). However if you want to be able to reproduce the rendering outside draw_image(), relying on the explicitly reserved list only, then it needs to store 3 entries.
2009-09-18 15:27:55 +02:00
case VOCTRL_RESET:
vo_vdpau: don't blank screen on VOCTRL_RESET vo_vdpau is the only VO which implements VOCTRL_RESET. Redrawing the last output frame is hard, because the output could consist of several source video frames with certain types of post-processing (deinterlacing). Implement redrawing as special case by keeping the previous video frames aside until at least one new frame is decoded. This improves the previous commit, but is separate, because it's rather complicated.
2013-10-01 23:45:30 +02:00
forget_frames(vo, true);
core/VO: Allow VO drivers to add/modify frames Add interfaces to allow VO drivers to add or remove frames from the video stream and to alter timestamps. Currently this functionality only works with in correct-pts mode. Use the new functionality in vo_vdpau to properly support frame-adding deinterlace modes. Frames added by the VDPAU deinterlacing code are now properly timed. Before every second frame was always shown immediately (probably next monitor refresh) after the previous one, even if you were watching things in slow motion, and framestepping didn't stop at them at all. When seeking the deinterlace algorithm is no longer fed a mix of frames from old and new positions. As a side effect of the changes a problem with resize events was also fixed. Resizing calls video_to_output_surface() to render the frame at the new resolution, but before this function also changed the list of history frames, so resizing could give an image different from the original one, and also corrupt next frames due to them seeing the wrong history. Now the function has no such side effects. There are more resize-related problems though that will be fixed in a later commit. The deint_mpi[] list of reserved frames is increased from 2 to 3 entries for reasons related to the above. Having 2 entries is enough when you initially get a new frame in draw_image() because then you'll have those two entries plus the new one for a total of 3 (the code relied on the oldest mpi implicitly staying reserved for the duration of the call even after usage count was decreased). However if you want to be able to reproduce the rendering outside draw_image(), relying on the explicitly reserved list only, then it needs to store 3 entries.
2009-09-18 15:27:55 +02:00
return true;
vo_vdpau: implement screenshots
2011-10-06 20:46:01 +02:00
case VOCTRL_SCREENSHOT: {
vo_vdpau: fix preemption recovery after recent commits Recent commits for screenshot support and video redraw changes didn't handle vdpau driver preemption state correctly, which could make the player crash if preemption occurred. Fix this and improve preemption handling a bit otherwise.
2011-12-20 02:47:16 +01:00
if (!status_ok(vo))
return false;
vo_vdpau: implement screenshots
2011-10-06 20:46:01 +02:00
struct voctrl_screenshot_args *args = data;
if (args->full_window)
args->out_image = get_window_screenshot(vo);
else
args->out_image = get_screenshot(vo);
return true;
}
Add support for VDPAU video out, including hardware decoding. git-svn-id: svn://svn.mplayerhq.hu/mplayer/trunk@28617 b3059339-0415-0410-9bf9-f77b7e298cf2
2009-02-16 21:58:13 +01:00
}
x11: use vo_x11_control() for all VOs
2013-05-16 14:02:28 +02:00
int events = 0;
int r = vo_x11_control(vo, &events, request, data);
if (events & VO_EVENT_RESIZE) {
checked_resize(vo);
} else if (events & VO_EVENT_EXPOSE) {
vo->want_redraw = true;
}
return r;
Add support for VDPAU video out, including hardware decoding. git-svn-id: svn://svn.mplayerhq.hu/mplayer/trunk@28617 b3059339-0415-0410-9bf9-f77b7e298cf2
2009-02-16 21:58:13 +01:00
}
VO: implement shared option handling, use for vdpau Add infrastructure that allows VOs to specify the suboptions they take, and get the values directly parsed into their private struct. The option functionality available with the new system is the same as for top-level player options. Convert vo_vdpau to use the new system instead of the old subopt_helper.
2012-06-25 22:12:03 +02:00
#define OPT_BASE_STRUCT struct vdpctx
vo_vdpau: Make compile as new-style VO
2009-05-04 02:09:50 +02:00
const struct vo_driver video_out_vdpau = {
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
.buffer_frames = true,
video/out: remove useless info struct and redundant fields The author and comment fields were printed only in -v mode.
2013-10-23 19:06:14 +02:00
.description = "VDPAU with X11",
.name = "vdpau",
vo_vdpau: Make compile as new-style VO
2009-05-04 02:09:50 +02:00
.preinit = preinit,
video/out: replace VOCTRL_QUERY_FORMAT with vo_driver.query_format
2012-11-04 16:24:18 +01:00
.query_format = query_format,
vo_vdpau: Make compile as new-style VO
2009-05-04 02:09:50 +02:00
.config = config,
.control = control,
video/filter: change filter API, use refcounting, remove filter DR Change the entire filter API to use reference counted images instead of vf_get_image(). Remove filter "direct rendering". This was useful for vf_expand and (in rare cases) vf_sub: DR allowed these filters to pass a cropped image to the filters before them. Then, on filtering, the image was "uncropped", so that black bars could be added around the image without copying. This means that in some cases, vf_expand will be slower (-vf gradfun,expand for example). Note that another form of DR used for in-place filters has been replaced by simpler logic. Instead of trying to do DR, filters can check if the image is writeable (with mp_image_is_writeable()), and do true in-place if that's the case. This affects filters like vf_gradfun and vf_sub. Everything has to support strides now. If something doesn't, making a copy of the image data is required.
2012-11-05 14:25:04 +01:00
.draw_image = draw_image,
vo: do final frame draw only near page flip Separate passing a new frame to VOs using the new API into two steps. The first, vo_draw_image(), happens after a new frame is available from the filter chain. In constrast to old behavior, now the frame is not actually rendered yet at this point (though possible slice draw calls can already reach the VO before). The second step, vo_new_frame_imminent(), happens when we're close enough to the display time of the new frame that we'll commit to flipping it as the next action and will not change the OSD over the previous frame any more. This new behavior fixes a previous problem with vo_vdpau and vo_gl in the situation where the player is paused after decoding a new frame but before flipping it; previously changing OSD in that state would switch to the new frame as a side effect. It would also allow an easy way to fix extra output files produced with something like "--vo=png --frames=1" with precise seeking, but this is not done yet. The code now relies on a new mp_image from the filter chain staying valid even after the vf_vo put_image() call providing it returns. In other words decoders/filters must not deallocate or otherwise invalidate their output frame between passing it forward and returning from the decode/filter call.
2011-12-04 17:10:17 +01:00
.get_buffered_frame = set_next_frame_info,
vo_vdpau: Make compile as new-style VO
2009-05-04 02:09:50 +02:00
.draw_osd = draw_osd,
Implement vsync-aware frame timing for VDPAU Main things added are custom frame dropping for VDPAU to work around the display FPS limit, frame timing adjustment to avoid jitter when video frame times keep falling near vsyncs, and use of VDPAU's timing feature to keep one future frame queued in advance. NVIDIA's VDPAU implementation refuses to change the displayed frame more than once per vsync. This set a limit on how much video could be sped up, and caused problems for nearly all videos on low-FPS video projectors (playing 24 FPS video on a 24 FPS projector would not work reliably as MPlayer may need to slightly speed up the video for AV sync). This commit adds a framedrop mechanism that drops some frames so that no more than one is sent for display per vsync. The code tries to select the dropped frames smartly, selecting the best one to show for each vsync. Because of the timing features needed the drop functionality currently does not work if the correct-pts option is disabled. The code also adjusts frame timing slightly to avoid jitter. If you for example play 24 FPS video content on a 72 FPS display then normally a frame would be shown for 3 vsyncs, but if the frame times happen to fall near vsyncs and change between just before and just after then there could be frames alternating between 2 and 4 vsyncs. The code changes frame timing by up to one quarter vsync interval to avoid this. The above functionality depends on having reliable vsync timing information available. The display refresh rate is not directly provided by the VDPAU API. The current code uses information from the XF86VidMode extension if available; I'm not sure how common cases where that is inaccurate are. The refresh rate can be specified manually if necessary. After the changes in this commit MPlayer now always tries to keep one frame queued for future display using VDPAU's internal timing mechanism (however no more than 50 ms to the future). This should make video playback somewhat more robust against timing inaccuracies caused by system load.
2009-11-15 03:39:22 +01:00
.flip_page_timed = flip_page_timed,
vo_vdpau: Make compile as new-style VO
2009-05-04 02:09:50 +02:00
.uninit = uninit,
video_out: rename privsize member to priv_size
2012-08-06 17:51:53 +02:00
.priv_size = sizeof(struct vdpctx),
VO: implement shared option handling, use for vdpau Add infrastructure that allows VOs to specify the suboptions they take, and get the values directly parsed into their private struct. The option functionality available with the new system is the same as for top-level player options. Convert vo_vdpau to use the new system instead of the old subopt_helper.
2012-06-25 22:12:03 +02:00
.options = (const struct m_option []){
OPT_INTRANGE("deint", deint, 0, -4, 4),
cleanup: replace OPT_FLAG_ON and OPT_MAKE_FLAGS with OPT_FLAG OPT_MAKE_FLAGS() used to emit two options (one with "no" prefixed), but that has been long removed by special casing flag options in the option parser. OPT_FLAG_ON() used to imply that there's no "no-" prefixed option, but this hasn't been the case for a while either. (Conceptually, it has been replaced by OPT_FLAG_STORE().) Remove OPT_FLAG_OFF, which was unused.
2013-02-08 21:09:18 +01:00
OPT_FLAG("chroma-deint", chroma_deint, 0, OPTDEF_INT(1)),
OPT_FLAG("pullup", pullup, 0),
VO: implement shared option handling, use for vdpau Add infrastructure that allows VOs to specify the suboptions they take, and get the values directly parsed into their private struct. The option functionality available with the new system is the same as for top-level player options. Convert vo_vdpau to use the new system instead of the old subopt_helper.
2012-06-25 22:12:03 +02:00
OPT_FLOATRANGE("denoise", denoise, 0, 0, 1),
OPT_FLOATRANGE("sharpen", sharpen, 0, -1, 1),
OPT_INTRANGE("hqscaling", hqscaling, 0, 0, 9),
OPT_FLOAT("fps", user_fps, 0),
cleanup: replace OPT_FLAG_ON and OPT_MAKE_FLAGS with OPT_FLAG OPT_MAKE_FLAGS() used to emit two options (one with "no" prefixed), but that has been long removed by special casing flag options in the option parser. OPT_FLAG_ON() used to imply that there's no "no-" prefixed option, but this hasn't been the case for a while either. (Conceptually, it has been replaced by OPT_FLAG_STORE().) Remove OPT_FLAG_OFF, which was unused.
2013-02-08 21:09:18 +01:00
OPT_FLAG("composite-detect", composite_detect, 0, OPTDEF_INT(1)),
VO: implement shared option handling, use for vdpau Add infrastructure that allows VOs to specify the suboptions they take, and get the values directly parsed into their private struct. The option functionality available with the new system is the same as for top-level player options. Convert vo_vdpau to use the new system instead of the old subopt_helper.
2012-06-25 22:12:03 +02:00
OPT_INT("queuetime_windowed", flip_offset_window, 0, OPTDEF_INT(50)),
OPT_INT("queuetime_fs", flip_offset_fs, 0, OPTDEF_INT(50)),
OPT_INTRANGE("output_surfaces", num_output_surfaces, 0,
2, MAX_OUTPUT_SURFACES, OPTDEF_INT(3)),
vo_vdpau: use color close to black as default colorkey (instead of green) The VDPAU default colorkey, although it seems to be driver specific, is usually green. This is a pretty annoying color, and you usually see it briefly (as flashes) if the VDPAU window resizes. Change it to some shade of black. The new default color is close to what MPlayer picks as colorkey (and apparently it worked well for them): VdpColor vdp_bg = {0.01, 0.02, 0.03, 0}; Since our OPT_COLOR can set 8 bit colors only, we use '#020507' instead, which should be the same assuming 8 bit colors. Obviously, you can't use black, because black is a way too common color, and would make it too easy to observe the colorkey effect when e.g. moving a terminal with black background over the video window.
2013-08-17 20:05:28 +02:00
OPT_COLOR("colorkey", colorkey, 0,
.defval = &(const struct m_color) {
.r = 2, .g = 5, .b = 7, .a = 255,
}),
vo_vdpau: add RGB support Apparently this was dropped some years ago, but judging from MPlayer's handling of this, the original code wasn't so great anyway. The new code handling clearing of panscan borders correctly, and integrates better with the YUV path. (Although the VDPAU API sure makes this annoying with its separate surface types for RGB.) Note that we create 5 surfaces for some reason - I don't think this makes too much sense (because we can't use the deinterlacer with RGB surfaces), but at least it reduces the amount of differences with the YUV code path. Clearing the borders is done by drawing a single black pixel over the window. This sounds pretty dumb, but it appears to work well, and there is no other API for that. (One could try to use the video mixer for this purpose, since it has all kinds of features, including compositing multiple RGBA surfaces and clearing the window background. But it would require an invisible dummy video surface to make the video mixer happy, and that's getting too messy.)
2013-08-18 05:12:21 +02:00
OPT_FLAG("force-yuv", force_yuv, 0),
VO: implement shared option handling, use for vdpau Add infrastructure that allows VOs to specify the suboptions they take, and get the values directly parsed into their private struct. The option functionality available with the new system is the same as for top-level player options. Convert vo_vdpau to use the new system instead of the old subopt_helper.
2012-06-25 22:12:03 +02:00
{NULL},
}
vo_vdpau: Make compile as new-style VO
2009-05-04 02:09:50 +02:00
};
Copy Permalink