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.
If the main image buffer was not altered for OSD then allow updating
OSD even if no separate OSD-less copy was made. The code now makes a
copy at that time (another possibility would be to not make a copy and
disallow further updates).
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.
It is useless because with the new API enabled by VOCTRL_UPDATE_SCREENINFO it
is not necessary because it is already done in video_out.c:config_video_out.
Secondly, the removal of the aspect_save_prescale triggered a regression because of
it, with -wid the window would not be filled completely initially.
git-svn-id: svn://svn.mplayerhq.hu/mplayer/trunk@27978 b3059339-0415-0410-9bf9-f77b7e298cf2
This fixes the -vm bug that the created window is too small.
git-svn-id: svn://svn.mplayerhq.hu/mplayer/trunk@27925 b3059339-0415-0410-9bf9-f77b7e298cf2
This commit creates the struct and passes it to some functions that
needs to access OSD state but does not yet move much data from globals
to it.
vf_expand accesses the OSD state for rendering purposes outside of the
normal OSD draw time. The way this currently works is suboptimal, but
I did not attempt to clean it up now. To keep things working the same
way vf_expand needs to know the address of the state object to be able
to access the data even in the functions that should normally not need
it. For that purpose this commit adds a VFCTRL to tell vf_expand the
address of the object.
Port selection was broken in conversion to new VO API (the user
setting was parsed to a variable that then wasn't used for anything).
Fix by parsing it to the x11 struct xv_port variable.
of XVideo adaptor to be used (instead of default one, which is #0).
This is useful for example if you'd rather like to use the original
Overlay renderer of your GPU instead of the texture blitting engine
(which is usually default), which is number one cause of nasty
video tearing effects.
git-svn-id: svn://svn.mplayerhq.hu/mplayer/trunk@26762 b3059339-0415-0410-9bf9-f77b7e298cf2
Use the same mp_input_add_key_fd for all uses and add a context
argument to its callback that was before only in the event fd
callbacks. Instead of checking in input.c whether keys were inserted
to the keypress FIFO during the callback do the check in the callback
before returning and set return value accordingly.
Remove the global and Add a corresponding field to the vo struct, plus
another which tells whether the LAST config call was successful.The
latter value which tells whether the VO should be properly configured
at the moment seems a better match for the semantics actually needed
in most places where the old value was used. The 'count' field with
the old semantics is not currently used by anything, but I'm leaving
it there for vo drivers which would need those semantics if converted
to use the struct.
Existing uses of the global outside old vo drivers are either converted
to use the struct field or moved inside the vo_xyz() calls (instead of
"if (vo_config_count) vo_flip_page(..." just call vo_flip_page which
will now do nothing if not configured). The removal of the check in
mpcommon.c/update_subtitles() is less trivial than the others, but I
think it shouldn't cause problems.
