Change 'struct vf_instance' pointer arguments to more standard style
as in the subject. Also some other minor formatting fixes.
Patch by Diego Biurrun.
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.
Create new video driver API that has a per-instance context structure
and does not rely on keeping status in global or static variables.
Existing drivers are not yet converted to this API; instead there is a
wrapper which translates calls to them.
In the new API, an old API call vo_functions->xyz(args) is generally
replaced by vo_xyz(vo_instance, args).
The changes to keep the vesa, dxr2 and xover drivers compiling have
not been tested.
pause by checking mpctx directly. If there's any video update before the pause
then capture the frame or fallback to use last captured frame as pausing frame.
git-svn-id: svn://svn.mplayerhq.hu/mplayer/trunk@25054 b3059339-0415-0410-9bf9-f77b7e298cf2
* menus are enabled
* menus are enabled but not displayed
* direct rendering is in use
Patch by Adam Sulmicki % adam A cfar P umd P edu %
Original thread:
date: Jan 7, 2007 11:07 PM
subject: [MPlayer-dev-eng] [PATCH] slow menus : try two
Other threads:
date: Jan 7, 2007 12:39 PM
subject: [MPlayer-advusers] [patch] slow menus
Also:
date: Jan 6, 2007 11:13 PM
subject: [MPlayer-advusers] [patch] slow menus
And:
date: Jan 2, 2007 11:46 PM
subject: [MPlayer-advusers] slow down with menu off
Finaly:
date: Dec 24, 2006 11:25 AM
subject: [MPlayer-users] slow down with menu off
git-svn-id: svn://svn.mplayerhq.hu/mplayer/trunk@21942 b3059339-0415-0410-9bf9-f77b7e298cf2
