Clean up the code and make the behavior more consistent. Before
bits of the OSD information were triggered in different places, and
various property commands that affect playback position only showed
the seek bar while the main seek command also triggered showing the
percentage in OSD text. Now only the seek and chapter commands trigger
all information and others nothing (which is consistent with most
property behavior).
Disable by default the code that forcefully moved the video output
window to the middle of the screen whenever it was reconfigured or
created. That behavior was really annoying when switching video
streams within a file, and overriding the window manager like that is
not good default behavior for the initial creation of a window either.
Add a new option "-force-window-position" that can be used to restore
the old behavior.
If the fullscreen state was changed via keyboard commands or the slave
interface the option value was not changed. However that value is used
if the VO is reconfigured. Set the option too to avoid switching
back to the previous state in that case.
When the new mode is active relative seeks are converted to absolute
ones (current video pts + relative seek amount) and forward/backward
flag before being sent to the demuxer. This mode is used if the
demuxer has set the accurate_seek field in the demuxer struct and
there is a video stream. At the moment the mkv and lavf demuxers
enable the flag.
This change is useful for later Matroska ordered chapter support (and
for more general timelime editing), but also fixes problems in
existing functionality. The main problem with the old mode, where
relative seeks are passed directly to the demuxer, is that the user
wants to seek relative to the currently displayed position but the
demuxer does not know what that position is. There can be an arbitrary
amount of buffering between the demuxer read position and what is
displayed on the screen. In some situations this makes small seeks
fail to move backward at all (especially visible at high playback
speed, when audio needs to be demuxed and decoded further ahead to
fill the output buffers after resampling).
Some container formats that can be used with the lavf demuxer do not
always have reliable timestamps that could be used for unambiguous
absolute seeking. However I made the demuxer always enable the new
mode because it already converted all seeks to absolute ones before
sending them to libavformat, so cases without reliable absolute seeks
were failing already and this should only improve the working cases.
Clean up demux_mkv_read_info() and demux_mkv_read_chapters() somewhat.
(Why do the names of static functions have a stupid prefix like that?
Didn't remove it now however).
Demux_mkv_read_info() now delays printing duration information until
the end of the function where we hopefully have the correct timescale
for converting it to seconds. The code to calculate the duration had
been fixed for that earlier but the message had not.
Restore accidentally dropped '!' to fixed-vo test in
reinit_video_chain(). It could have caused some issues when switching
video streams. Probably nobody noticed because files with multiple
video streams are rare.
Makes things a bit simpler for everyone who insists on compiling MPlayer as PIE-code.
git-svn-id: svn://svn.mplayerhq.hu/mplayer/trunk@28942 b3059339-0415-0410-9bf9-f77b7e298cf2
available memcpy variants and prints benchmark results about them.
git-svn-id: svn://svn.mplayerhq.hu/mplayer/trunk@28929 b3059339-0415-0410-9bf9-f77b7e298cf2
That fixes the case when converting 15-bit RGB/BGR to YUV and high bit is set
for input value(s).
git-svn-id: svn://svn.mplayerhq.hu/mplayer/trunk@28916 b3059339-0415-0410-9bf9-f77b7e298cf2
