Remove some commented-out code that has no purpose and is only confusing.
git-svn-id: svn://svn.mplayerhq.hu/mplayer/trunk@31620 b3059339-0415-0410-9bf9-f77b7e298cf2
Remove useless ()
git-svn-id: svn://svn.mplayerhq.hu/mplayer/trunk@31621 b3059339-0415-0410-9bf9-f77b7e298cf2
It will most likely break their input processing.
If someone needs the previous behaviour, an option could be added (and
also used in the w32_common.c code).
git-svn-id: svn://svn.mplayerhq.hu/mplayer/trunk@31601 b3059339-0415-0410-9bf9-f77b7e298cf2
Fix resizing with -wid after previous commit.
git-svn-id: svn://svn.mplayerhq.hu/mplayer/trunk@31604 b3059339-0415-0410-9bf9-f77b7e298cf2
Always request expose events, we have to handle them, the application
that created the -wid window can't.
git-svn-id: svn://svn.mplayerhq.hu/mplayer/trunk@31605 b3059339-0415-0410-9bf9-f77b7e298cf2
Now the window is only resized when video size (or size specified by
-geometry) changes; reconfiguring the window with the same size no
longer changes back to default size from possibly user-modified one.
Also fix a bug in fullscreen handling that could cause incorrect
window size when turning fullscreen off.
This in particular avoids MPlayer continuing to play when
a frontend using -wid crashed.
git-svn-id: svn://svn.mplayerhq.hu/mplayer/trunk@31179 b3059339-0415-0410-9bf9-f77b7e298cf2
This avoids the compilation failure on kFreeBSD (at least amd64):
In file included from libvo/vo_directfb2.c:44:
libvo/video_out.h:267: error: redefinition of 'struct keymap'
This is because libvo/vo_directfb2.c #includes sys/kd.h, which in turn
includes sys/kbio.h, which defines another 'struct keymap'.
git-svn-id: svn://svn.mplayerhq.hu/mplayer/trunk@31059 b3059339-0415-0410-9bf9-f77b7e298cf2
Fixes hangs if OpenGL initialization fails in vo gl preinit and we
call uninit while the window is still hidden.
git-svn-id: svn://svn.mplayerhq.hu/mplayer/trunk@30760 b3059339-0415-0410-9bf9-f77b7e298cf2
exit_player() was declared with differing parameter types in mplayer.c and
mplayer.h. Make the declaration in the .h file match the one in the .c file
and adjust all usages of exit_player() throughout the codebase. Also move
the exit_player() declaration into mp_core.h next to exit_player_with_rc().
git-svn-id: svn://svn.mplayerhq.hu/mplayer/trunk@30558 b3059339-0415-0410-9bf9-f77b7e298cf2
because vo_x11_clearwindow works as intended also when the background is
set to None.
git-svn-id: svn://svn.mplayerhq.hu/mplayer/trunk@30497 b3059339-0415-0410-9bf9-f77b7e298cf2
Add a property to select YUV colorspace. Currently implemented only in
vo_vdpau and vo_xv. Allows switching between BT.601, BT.709 and
SMPTE-240M (vdpau only).
The xv support uses the "XV_ITURBT_709" attribute. At least my NVIDIA
card supports that; I don't know whether other xv implementations do.
Bind the colorspace switch to the 'c' key by default. 'c' is currently
used by vo_sdl for some fullscreen mode change thing, but at the moment
that does not conflict and if it will in the future then vo_sdl can
change.
VDPAU part based on a patch from Lauri Mylläri <lauri.myllari@gmail.com>
Main things added are custom frame dropping for VDPAU to work around
the display FPS limit, frame timing adjustment to avoid jitter when
video frame times keep falling near vsyncs, and use of VDPAU's timing
feature to keep one future frame queued in advance.
NVIDIA's VDPAU implementation refuses to change the displayed frame
more than once per vsync. This set a limit on how much video could be
sped up, and caused problems for nearly all videos on low-FPS video
projectors (playing 24 FPS video on a 24 FPS projector would not work
reliably as MPlayer may need to slightly speed up the video for AV
sync). This commit adds a framedrop mechanism that drops some frames
so that no more than one is sent for display per vsync. The code
tries to select the dropped frames smartly, selecting the best one to
show for each vsync. Because of the timing features needed the drop
functionality currently does not work if the correct-pts option is
disabled.
The code also adjusts frame timing slightly to avoid jitter. If you
for example play 24 FPS video content on a 72 FPS display then
normally a frame would be shown for 3 vsyncs, but if the frame times
happen to fall near vsyncs and change between just before and just
after then there could be frames alternating between 2 and 4
vsyncs. The code changes frame timing by up to one quarter vsync
interval to avoid this.
The above functionality depends on having reliable vsync timing
information available. The display refresh rate is not directly
provided by the VDPAU API. The current code uses information from the
XF86VidMode extension if available; I'm not sure how common cases
where that is inaccurate are. The refresh rate can be specified
manually if necessary.
After the changes in this commit MPlayer now always tries to keep one
frame queued for future display using VDPAU's internal timing
mechanism (however no more than 50 ms to the future). This should make
video playback somewhat more robust against timing inaccuracies caused
by system load.
In a list of enabled fstypes, "none" now clears the list rather than
disabling all fstypes and interrupting the parser. To enable only one
(or more) fstypes, list the types to enable after "none".
For example:
"-fstype none" is the same as before: all disabled
"-fstype none,fullscreen" enables only the fullscreen type
git-svn-id: svn://svn.mplayerhq.hu/mplayer/trunk@29805 b3059339-0415-0410-9bf9-f77b7e298cf2
Fixes the warnings:
libvo/x11_common.c:1344: warning: 'h' may be used uninitialized in this function
libvo/x11_common.c:1344: warning: 'w' may be used uninitialized in this function
libvo/x11_common.c:1344: warning: 'y' may be used uninitialized in this function
libvo/x11_common.c:1344: warning: 'x' may be used uninitialized in this function
git-svn-id: svn://svn.mplayerhq.hu/mplayer/trunk@29795 b3059339-0415-0410-9bf9-f77b7e298cf2
managers this has the ugly side-effect of moving the window.
Instead call XInstallColormap to ensure the Colormap is installed.
git-svn-id: svn://svn.mplayerhq.hu/mplayer/trunk@29614 b3059339-0415-0410-9bf9-f77b7e298cf2
The GUI is badly designed and too closely coupled to the internal
details of other code. The GUI code is in bad shape and unmaintained
for years. There is no indication that anyone would maintain it in the
future either. Even if someone did volunteer to implement a better
integrated GUI having the current code in the tree probably wouldn't
help much. So get rid of it.
reimar
Uoti Urpala
diego
siretart
ptt
reynaldo
corey
Anton Khirnov
Amar Takhar
attila