vo_xv set the "use_fs" parameter to vo_x11_clearwindow_part(). This
meant it always used the whole screen size to calculate the area to
clear. I can't see why overriding the vo->dwidth/dheight values would
ever be the right thing to do (if in fullscreen they should be set to
match that), so remove the use_fs parameter and always use the
dwidth/dheight values in the function. Also delete code drawing back
borders in vo_xv_draw colorkey. That should already happen in
vo_x11_clearwindow_part(); if it doesn't then things need to be fixed
anyway because colorkey code only ran in fullscreen mode (but borders
must work in window mode too).
vo_x11_create_vo_window() only called vo_x11_update_geometry() if no
window position had been specified by -geometry or -xineramascreen, to
avoid overwriting the specified position with values from the existing
window. However window size should be initialized to the existing
window here, and setting new window title for -use-filename-title is
also done in vo_x11_update_geometry() (for whatever reason, it doesn't
match what else that function does). Change the code in
vo_x11_create_vo_window() to always call vo_x11_update_geometry() for
size variable and window title updates, but add a flag that tells it
not to update position variables.
Add support for binding commands to modifier+key combinations like
"Shift+Left" or "Ctrl+Alt+x", and support reading such combinations
from the output window of X VOs.
The recognized modifier names are Shift, Ctrl, Alt and Meta. Any
combination of those and then a non-modifier key name, separated by
'+', is accepted as a key name in input.conf. For non-special keys
that produce characters shift is ignored as a modifier. For example
"A" is handled as a key without modifiers even if you use shift to
write the capital letter; 'a' vs 'A' already distinguishes the
combinations with a normal keymap, and having separate 'a', 'Shift+A'
and 'A' (written with caps lock for example) would bring more
confusion than benefit.
Currently reading the modifier+key combinations is only supported in
the output window of those VOs that use x11_common.c event
handling. It's not possible to input the key combinations in other VOs
or in a terminal window.
Now the window is only resized when video size (or size specified by
-geometry) changes; reconfiguring the window with the same size no
longer changes back to default size from possibly user-modified one.
Also fix a bug in fullscreen handling that could cause incorrect
window size when turning fullscreen off.
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.
Convert vo_x11_border (used in vo_gl/gl2 though the vo_gl_border
macro) to use a wrapper macro in old-style VOs which do not provide a
VO object argument. Before this function had an explicit global_vo
argument in vo_gl/gl2. New vo_vdpau uses it too so use the same
mechanism as most other functions.
The libdvdread4 and libdvdnav directories, which are externals in the
svn repository, are at least for now not included in any form. I added
configure checks to automatically disable internal libdvdread and
libdvdnav if the corresponding directories are not present; if they're
added manually then things work the same as in svn.
Conflicts:
libvo/x11_common.c
libvo/x11_common.h
Rename the vo_gl macro "vo_border()" to "vo_gl_border" as it conflicts
with the global variable "vo_border"; done in the merge commit because
uses of the macro needed changes anyway to resolve conflicts.
Will be used for common data between X11 VOs. The main reasons for
making it a separate struct rather than extra fields in the main VO
struct are that some field definitions need X headers and that the code
keeps basic X state such as the display connection over opening and
closing of individual VOs.
