Update the version.sh script for git so it'll generate version numbers
more useful than "UNKNOWN". At the moment it only generates the short
SHA1 name, but adding a tag as a starting point should allow more
useful output. Rather than update the Makefile logic that tried to
guess whether the svn revision had changed since the last version.h
update, just run the version.sh script from configure so the version
is updated at least at that time.
Check that frames added by filters reach the screen and are not just
buffered by the VO, and give filters a chance to output added frames
if previous frame at EOF was buffered by VO. It's unlikely that anyone
ever noticed practical problems caused by these issues.
At least show the extra frames even if correct-pts mode is disabled.
They cannot be timed properly though; the most practical way to fix
that is to just move to correct-pts mode instead.
stream_ffmpeg used libavformat's url_read_complete() to read data.
However that function returns failure if it did not manage to read the
_full_ amount of data asked for, while the behavior we want is to
return any positive amount of data there was before end of file. This
caused attempts to read the last bytes in a file to fail. Fix by using
url_read() instead of url_read_complete(); even if some reads before
EOF return less than the full amount that should not be a problem.
name clashes, in particular with Windows headers (which define STREAM_SEEK as an enum type).
git-svn-id: svn://svn.mplayerhq.hu/mplayer/trunk@29962 b3059339-0415-0410-9bf9-f77b7e298cf2
OSD contents such as video position and non-libass subtitles were
updated just before feeding a video frame through filters. The updates
were done at that point mainly for the benefit of vf_expand OSD
rendering functionality, which draws the OSD contents when the frame
passes through that filter. However this gave the wrong results for
VO-drawn OSD if the filter chain or VO had any delay or timestamp
manipulation: the OSD contents should reflect the most recent contents
that were _output_ after any filtering, not the last frame that was
fed _into_ the filtering machinery. This issue became more important
after vo_vdpau started buffering frames by default.
Move the OSD updates to be done just before the OSD is drawn, using
the most accurate available information. This fixes the common case
but worsens vf_expand OSD behavior (adding extra latency). A special
case could be added to fall back to the previous behavior when
vf_expand OSD is being used; however I don't consider that a high
priority at the moment especially when other problems with vf_expand
OSD would still remain.
This has little effect on libass-rendered subtitles either way,
because both vf_ass and VO libass rendering use timestamps from the
filter chain and do not rely on separate position updates.
The scaletempo filter has a special-case check to return the samples
unchanged if the current scaling factor is 1. In this case code
setting af->delay wasn't run. If the scale had had a different value
and then been changed to 1 as a result of a playback speed change then
the delay field could have a nonzero value left, resulting in A/V sync
errors. Fix by setting the delay field to 0 in the scale == 1 special
case code.
Has little use except for experimenting - on Windows 9x it could be used to
render on monitors that were not managed by Windows, but that feature was
removed in newer Windows versions.
git-svn-id: svn://svn.mplayerhq.hu/mplayer/trunk@29946 b3059339-0415-0410-9bf9-f77b7e298cf2
the args argument to open will always be NULL and vf->priv will always be
!= NULL.
git-svn-id: svn://svn.mplayerhq.hu/mplayer/trunk@29945 b3059339-0415-0410-9bf9-f77b7e298cf2
to actually use GLX/WGL visuals with more than 8 bits per component if available).
git-svn-id: svn://svn.mplayerhq.hu/mplayer/trunk@29944 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.
putting it on the stack, performance should not matter much here.
git-svn-id: svn://svn.mplayerhq.hu/mplayer/trunk@29938 b3059339-0415-0410-9bf9-f77b7e298cf2
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.
This is necessary to sync up with some recent FFmpeg changes.
git-svn-id: svn://svn.mplayerhq.hu/mplayer/trunk@29933 b3059339-0415-0410-9bf9-f77b7e298cf2
Cache can not be used for it, since it does not provide any
data stream, the data is provided to the demuxer "behind
MPlayer's back".
git-svn-id: svn://svn.mplayerhq.hu/mplayer/trunk@29930 b3059339-0415-0410-9bf9-f77b7e298cf2
enabled.
Enabling network support should not have side-effects on code not really
related to networking.
git-svn-id: svn://svn.mplayerhq.hu/mplayer/trunk@29926 b3059339-0415-0410-9bf9-f77b7e298cf2
Uoti Urpala
reimar
jrash
cehoyos
diego