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.
scattered all over the place with half of it forgotten in some places.
git-svn-id: svn://svn.mplayerhq.hu/mplayer/trunk@30420 b3059339-0415-0410-9bf9-f77b7e298cf2
Add a mode where libavcodec's reordered_opaque feature is used to
associate container packet timestamps with decoded frames. This should
improve behavior at least for MPEG files with interlaced h264; the
previous code does not cope well with the libavformat demuxer
producing two field packets with separate timestamps but the
libavcodec h264 decoder only producing a single output frame for those
two packets (so half the timestamps have no associated output frame).
The current libavformat mpeg demuxer seems to finally work with
interlaced h264 files and produce valid timestamps which are useful
with a mode like this.
By default MPlayer now selects between this new mode and the old one
automatically based on the number of timestamp problems they cause; by
default the new mode is used if both seem to work. The new option
-pts-association-mode can be used to force a particular mode. If
correct-pts mode is disabled this has no effect on timing.
Also remove the "EXPERIMENTAL" marker from the manpage description of
-correct-pts.
below the OSD and document possible issues when this is changed.
Patch by Uoti (though originally intended for a different issue) with extra comment by me.
git-svn-id: svn://svn.mplayerhq.hu/mplayer/trunk@28841 b3059339-0415-0410-9bf9-f77b7e298cf2
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.
and #ifdef HAVE_MMX etc -> #if HAVE_MMX.
There might be still more that need to be fixed.
git-svn-id: svn://svn.mplayerhq.hu/mplayer/trunk@28325 b3059339-0415-0410-9bf9-f77b7e298cf2
Move the OSD drawing calls from filter_video() to higher-level code to
ensure that VOs will draw the OSD also in filter-added frames, which
are displayed without a separate call to filter_video().
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.
vo gl generates bitmaps for EOSD content (libass subtitles) when
DRAW_EOSD is called but actual drawing of both EOSD and OSD is done in
draw_osd(). Since draw_osd() was called first it drew the EOSD content
from the previous frame, so the subtitles were always one frame late.
As a simple workaround update EOSD content first, then normal OSD.
This makes vo gl work correctly and should have no effect on anything
else.
We were using an inconsistent mix of the three variants and 'volatile' should
be the most correct and portable variant.
git-svn-id: svn://svn.mplayerhq.hu/mplayer/trunk@27791 b3059339-0415-0410-9bf9-f77b7e298cf2
Neither variant is valid C99 syntax, but __asm__ is the most portable variant.
git-svn-id: svn://svn.mplayerhq.hu/mplayer/trunk@27788 b3059339-0415-0410-9bf9-f77b7e298cf2
Replace all USE_ prefixes by CONFIG_ prefixes to indicate
options which are configurable.
git-svn-id: svn://svn.mplayerhq.hu/mplayer/trunk@27373 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.
Remove the global variable mpvdec and move the video decoder pointer
to struct sh_video field vd_driver. Audio already had a similar
ad_driver field from before.
"indent -kr -l79 -nut dec_video.c --ignore-newlines dec_video.c", fix
some "unknown_typedef * arg" in parameter lists by hand to
"unrecognized_typedef *arg".
an almost-trivial implementation.
This allows making the builtin codec structs const, and it also makes
clearer that this "selected" status is not used outside the init functions.
git-svn-id: svn://svn.mplayerhq.hu/mplayer/trunk@25689 b3059339-0415-0410-9bf9-f77b7e298cf2
against instead of directly #including the C file and replace the many extern
declarations by a proper header file.
git-svn-id: svn://svn.mplayerhq.hu/mplayer/trunk@24262 b3059339-0415-0410-9bf9-f77b7e298cf2
as long as there are enough pts values for frames that the decoder
returns.
This should allow passing NAL units individually.
git-svn-id: svn://svn.mplayerhq.hu/mplayer/trunk@22516 b3059339-0415-0410-9bf9-f77b7e298cf2
Avoids an incorrect "FATAL: Could not initialize video filters (-vf) or video output (-vo)."
message in some rare cases.
git-svn-id: svn://svn.mplayerhq.hu/mplayer/trunk@22423 b3059339-0415-0410-9bf9-f77b7e298cf2
The most visible inaccuracy caused by the previous update location was
that the OSD always showed position 0 after seeking with demux_mkv.
Split frame decoding and filtering because with -correct-pts the pts
value that should be displayed for the frame is only known after
decoding but is needed before filtering (during which the OSD is drawn).
git-svn-id: svn://svn.mplayerhq.hu/mplayer/trunk@20918 b3059339-0415-0410-9bf9-f77b7e298cf2
