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).
Change 'struct vf_instance' pointer arguments to more standard style
as in the subject. Also some other minor formatting fixes.
Patch by Diego Biurrun.
Note that r30455 is wrong, that commit does not in fact change the
default behavior as claimed in the commit message. It only breaks
"-af-adv force=0", which was already pretty much useless though.
This avoids clashes with fcntl.h under certain circumstances.
git-svn-id: svn://svn.mplayerhq.hu/mplayer/trunk@30680 b3059339-0415-0410-9bf9-f77b7e298cf2
will be recalculated correctly e.g. after aspect change and -vf expand=aspect=4/3
command line.
git-svn-id: svn://svn.mplayerhq.hu/mplayer/trunk@29666 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.
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.
Patch by Tomas Janousek (tomi nomi cz) with small modifications by me.
git-svn-id: svn://svn.mplayerhq.hu/mplayer/trunk@24263 b3059339-0415-0410-9bf9-f77b7e298cf2
This occurs when the destination buffer is packed but the source buffer uses aligned h&w.
patch by John Koleszar < jkoleszar AH on2 POIS com >
original thread:
Date: Apr 11, 2006 4:27 PM
Subject: [MPlayer-dev-eng] [PATCH] Chroma plane copy in vf_expand
git-svn-id: svn://svn.mplayerhq.hu/mplayer/trunk@18322 b3059339-0415-0410-9bf9-f77b7e298cf2
- make sure that the black buffer is actually allocated to avoid sig11
git-svn-id: svn://svn.mplayerhq.hu/mplayer/trunk@15253 b3059339-0415-0410-9bf9-f77b7e298cf2
Uoti Urpala
Uoti Urpala
cehoyos
diego
reimar
ben
Amar Takhar
Uoti Urpala
gpoirier
reynaldo
michael
ods15
rfelker
henry