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.
The screenshot command normally converts the currently displayed video
frame to an image. Add support for an alternative screenshot mode
that is supposed to capture the real window contents. Such a
screenshot contains a possibly scaled version of the frame, the OSD,
and subtitles.
Add a default key binding Alt+s for taking screenshots in this mode.
This needs special VO support, and might not work with all VOs (this
commit does not yet contain an implementation for any VO, only the
infrastructure).
Add a VO command (VOCTRL_SCREENSHOT) which requests a screenshot
directly from the VO. If VO support is available, screenshots will be
taken instantly (no more 1 or 2 frames delay). Taking screenshots when
hardware decoding is in use will also work (vdpau). Additionally, the
screenshots will now use the same colorspace as the video display.
Change the central MPContext to be allocated with talloc so that it
can be used as a talloc parent context.
This commit does not yet implement the functionality for any VO (added
in subsequent commits).
The old screenshot video filter is not needed anymore if VO support is
present, and in that case will not be used even if it is present in
the filter chain. If VO support is not available then the filter is
used like before. Note that the filter still has some of the old
problems, such as delaying the screenshot by at least 1 frame.
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.
Convert the list of VOCTLR_* defines to an enum, dropping some unused
values. This resolves a collision between VOCTRL_XOVERLAY_SET_COLORKEY
and VOCTRL_REDRAW_OSD, which had the same value (the XOVERLAY one was
only used by vo_xvr100 and vo_tdfx, so this didn't matter much in
practice).
When doing a precise seek video_out->frame_loaded was left to true
while frames were being skipped. However vo_get_buffered_frame()
always returns success if a frame is already loaded; due to this the
EOF detection in update_video() never triggered, and a hr-seek past
EOF could cause a soft hang (commands were still processed and it was
possible to seek again to exit the loop). This could also happen with
Matroska files using ordered chapters if an underlying file was
actually shorter than the chapter that was supposed to come from it.
Then seeking to a timestamp after the end of the file but before the
end of the chapter would trigger the bug.
Fix the problem by setting frame_loaded to false when we decide to
skip the frame in question.
Register the X11 connection fd in the input system so that
mp_input_get_cmd() can immediately wake up and handle keyboard or
other X events. The callback calls vo_check_events() and tells the
input system to handle any input possibly recorded during that. Before
this was done for vo_xv only; this commit generalizes it to all VOs
that call vo_x11_create_vo_window() - those are hopefully ones that
will handle all X events in check_events().
The callback is only kept registered while the vo is properly
configured. At other times calling check_events() would not clear
pending input and so could lead to a busy loop.
Select a stereo pixel format for window when Quadbuffer OpenGL was
selected as 3D mode.
git-svn-id: svn://svn.mplayerhq.hu/mplayer/trunk@32620 b3059339-0415-0410-9bf9-f77b7e298cf2
Add VO_EVENT_MOVE which is required for VOs that interact directly
with hardware like MGA and VIDIX.
Patch by Dirk Porezag [porezag yahoo com]
git-svn-id: svn://svn.mplayerhq.hu/mplayer/trunk@32454 b3059339-0415-0410-9bf9-f77b7e298cf2
This avoids the compilation failure on kFreeBSD (at least amd64):
In file included from libvo/vo_directfb2.c:44:
libvo/video_out.h:267: error: redefinition of 'struct keymap'
This is because libvo/vo_directfb2.c #includes sys/kd.h, which in turn
includes sys/kbio.h, which defines another 'struct keymap'.
git-svn-id: svn://svn.mplayerhq.hu/mplayer/trunk@31059 b3059339-0415-0410-9bf9-f77b7e298cf2
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).
By default (without -nokeepaspect) MPlayer tries to maintain video
aspect ratio by using window manager hints to keep output window
aspect when resizing. Before this commit it would however scale the
video to completely fill the window even if the window manager did not
respect those hints. Change the behavior to add black bars like in
fullscreen mode instead in this case.
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>
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.
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.
* vdpau: (22 commits)
VO: Prefer vo_vdpau over vo_xv again
vo_vdpau: Fix X event handling bugs
vo_vdpau: Fix memory corruption bug with MP_IMGTYPE_NUMBERED
core/VO: Allow VO drivers to add/modify frames
video_out.h: Cosmetics
VO interface: Remove obsolete draw_frame() from new interface
vo_vdpau: Support recovering from VDPAU display preemption
vo_vdpau: Support updating OSD while paused
vo_vdpau.c: Reindent control() switch statement
vo_vdpau: Allocate one large surface for EOSD content
vo_vdpau.c: cosmetics
vo_vdpau: reindent after GUI code removal
vo_vpdau: Clean up uninit logic
vo_vdpau: Make CHECK_ST macro safer
vo_vdpau: Move all remaining static/global variables to context
vo_vdpau: Move things to context struct
vo_vdpau: Make info struct const
vo_vdpau: Replace global function table with context variable
vo_vdpau: Move VDPAU interface pointers into one struct
vo_vdpau: Add template file for VDPAU functions
...
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.
The GUI is badly designed and too closely coupled to the internal
details of other code. The GUI code is in bad shape and unmaintained
for years. There is no indication that anyone would maintain it in the
future either. Even if someone did volunteer to implement a better
integrated GUI having the current code in the tree probably wouldn't
help much. So get rid of it.
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.
which part of the video source must be scaled onto which part of the window.
Direct3D and (future) VDPAU need this, for XvMC it makes it easier to add
cropping support and Xv is changed to keep the diff to XvMC small.
git-svn-id: svn://svn.mplayerhq.hu/mplayer/trunk@28546 b3059339-0415-0410-9bf9-f77b7e298cf2
When OSD contents change while paused, try to change the OSD drawn in
the currently visible frame. If such OSD updates are not supported
then advance by one frame and draw the OSD normally. Add some support
for OSD redrawing to vo xv.
The new xv code makes a copy of the original frame contents before
drawing the OSD if MPlayer is already paused when the frame is drawn.
If such a copy of the current frame exists then the frame contents can
be restored and a different OSD drawn on top of the same frame.
Uoti Urpala
wm4
harklu
Uoti Urpala
reimar
Clément Bœsch
siretart
ptt
Anton Khirnov
cehoyos
diego