Remove useless XSetBackground() call right before freeing the graphic
context.
git-svn-id: svn://svn.mplayerhq.hu/mplayer/trunk@33524 b3059339-0415-0410-9bf9-f77b7e298cf2
Create empty vo_gc graphic context instead of one with
undefined foreground color.
The code that uses vo_gc already employs XSetForeground()/XSetBackground()
to change the context accordingly.
git-svn-id: svn://svn.mplayerhq.hu/mplayer/trunk@33525 b3059339-0415-0410-9bf9-f77b7e298cf2
Set background color only when using ck-method=background. In the
other cases clearing of the non-video image area should be done
manually. Not drawing on the video image area prevents flickering
(visible when resizing).
git-svn-id: svn://svn.mplayerhq.hu/mplayer/trunk@33522 b3059339-0415-0410-9bf9-f77b7e298cf2
git-svn-id: svn://svn.mplayerhq.hu/mplayer/trunk@33502 b3059339-0415-0410-9bf9-f77b7e298cf2
Fix clear/border color of chroma texture for 9- and 10-bit formats.
Avoids pink borders for those formats.
git-svn-id: svn://svn.mplayerhq.hu/mplayer/trunk@33504 b3059339-0415-0410-9bf9-f77b7e298cf2
This fixes the warning:
libvo/vo_direct3d.c:984:6: warning: no previous prototype for 'vo_draw_alpha_l8a8'
git-svn-id: svn://svn.mplayerhq.hu/mplayer/trunk@33499 b3059339-0415-0410-9bf9-f77b7e298cf2
The warning "[ASPECT] Warning: No suitable new res found!" was printed
from aspect() if the video ended up being downscaled from the original
size AND the horizontal direction was the more limiting one for
aspect-aware scaling. Also, because aspect() can run multiple times
when starting playback this warning could be output multiple times.
Change the code so that downscaling alone no longer triggers this
message.
Clean up aspect.c code and simplify it somewhat (without changing the
overall logic). Replace debug output printf calls under #ifdef with
mp_msg() debug output (somewhat modified).
Remove the file aspecttest.c which created a binary to test aspect.c
functionality. It did not compile and would not be particularly useful
anyway. Remove some support lines from aspect.c and Makefile.
Request GL_LUMINANCE16 as internal format for > 8 bit YUV formats.
Have yet to find a system that actually provides that though.
git-svn-id: svn://svn.mplayerhq.hu/mplayer/trunk@33453 b3059339-0415-0410-9bf9-f77b7e298cf2
Make mp_get_chroma_shift() simpler/more generic and add an argument
to get the per-component bit depth.
Use this to check more properly for supported formats in
gl and gl2 vos (only 8 and 16 bit are supported, 9 and 10 are not).
git-svn-id: svn://svn.mplayerhq.hu/mplayer/trunk@33452 b3059339-0415-0410-9bf9-f77b7e298cf2
WM_XBUTTONDOWN is used for extra mouse buttons (mapped to button 5 and
button 6 in mplayer2). Previously only vo_directx handled this
message. Add support to w32_common.c event handling too (used by
vo_direct3d and vo_gl/vo_gl2 on Windows).
Due to libavcodec changes vo_xvmc would have needed some modifications
to keep working. However, I think there's little real demand for XvMC,
so I'll just drop XvMC support. XvMC only supported MPEG-2, making it
of very limited usefulness nowadays, plus the vo_xvmc implementation
was not high quality and never worked particularly well or reliably
anyway.
vo_svga.c used its static query_format() function before defining it,
but had no prototype before the use. Thus is depended on the otherwise
useless static declaration in a shared header, and broke after that
was removed. Fix by adding an advance declaration inside the file.
Move the definitions of all special key codes (those not passed by
ASCII value) to input/keycodes.h. Before they were spread between
osdep/keycodes.h, input/joystick.h, input/mouse.h and input/ar.h, plus
some special values in input.h. This was especially inconvenient as
the codes had to be coordinated to not conflict between the files.
The change requires a bit of ugliness as appleir.c includes
<linux/input.h> which contains various conflicting KEY_* definitions.
Work around this by adding a special preprocessor variable which can
be used to avoid defining these in keycodes.h.
Simplify by using FFMAX3.
git-svn-id: svn://svn.mplayerhq.hu/mplayer/trunk@33300 b3059339-0415-0410-9bf9-f77b7e298cf2
Simplify colormap generation code, avoid some mallocs and add frees
for one error case.
git-svn-id: svn://svn.mplayerhq.hu/mplayer/trunk@33302 b3059339-0415-0410-9bf9-f77b7e298cf2
Use memcpy_pic instead of reimplementing it.
git-svn-id: svn://svn.mplayerhq.hu/mplayer/trunk@33303 b3059339-0415-0410-9bf9-f77b7e298cf2
The "gamma" setting only changed red gamma. Fix it to change all of
red, green and blue gamma.
git-svn-id: svn://svn.mplayerhq.hu/mplayer/trunk@32895 b3059339-0415-0410-9bf9-f77b7e298cf2
After creating a video window the common X code waited for a MapNotify
event before proceeding. This meant that if the window was opened on
another workspace the player would be stuck until the user switched to
that workspace and the window could become actually visible. Remove
this waiting code. I don't know why it was there or if it was actually
beneficial/needed for some setup (at least common uses seem to work
fine without it); it comes from the earliest MPlayer versions visible
in VCS history.
Libavcore was merged back to libavutil. Change the mga_template.c
include of libavcore/imgutils.h to match. This means that split
libavcore/libavutil versions won't work any more; but since this only
affects people who enable vo_mga and there was no released version
using the split libs I won't bother with any conditionals for the
include.
When doing a precise seek video_out->frame_loaded was left to true
while frames were being skipped. However vo_get_buffered_frame()
always returns success if a frame is already loaded; due to this the
EOF detection in update_video() never triggered, and a hr-seek past
EOF could cause a soft hang (commands were still processed and it was
possible to seek again to exit the loop). This could also happen with
Matroska files using ordered chapters if an underlying file was
actually shorter than the chapter that was supposed to come from it.
Then seeking to a timestamp after the end of the file but before the
end of the chapter would trigger the bug.
Fix the problem by setting frame_loaded to false when we decide to
skip the frame in question.
vo_x11_create_vo_window() only called vo_x11_update_geometry() if no
window position had been specified by -geometry or -xineramascreen, to
avoid overwriting the specified position with values from the existing
window. However window size should be initialized to the existing
window here, and setting new window title for -use-filename-title is
also done in vo_x11_update_geometry() (for whatever reason, it doesn't
match what else that function does). Change the code in
vo_x11_create_vo_window() to always call vo_x11_update_geometry() for
size variable and window title updates, but add a flag that tells it
not to update position variables.
There were multiple files specific to Zoran support, and they also
depended on internal FFmpeg headers (so it would probably have been
hard to get them to compile now even if you tried). It's obsolete now,
so just drop the whole mess.
dxr2 support had been broken quite a while and nobody noticed. There
were finally commits to fix it in the svn repo, but rather than apply
those I'll just drop dxr2 support.
By now VIDIX is too obscure to justify the amount of code and
complexity it requires in the sources. Although there is no pressing
need to drop it just now from a code point of view, I'll rather remove
it before release than release with VIDIX support and then drop it
later.
Some of the manpage mentions of VIDIX were in "this option supported
for these VOs" lists that looked outdated and failed to mention vdpau
for example. Replace such incorrect lists with a generic "not
supported for all VOs" mention.
llvmpipe, while only slow instead of insanely slow, is a software
renderer. Recognize it as such and disable -vo gl_nosw on it.
git-svn-id: svn://svn.mplayerhq.hu/mplayer/trunk@32719 b3059339-0415-0410-9bf9-f77b7e298cf2
Rendering of ASS subtitles tries to be bug compatible with VSFilter
and stretches fonts when the video is anamorphic (some scripts try to
compensate for this VSFilter behavior, so trying to render them
"correctly" would give the wrong result). However this behavior is not
appropriate for subtitles we converted to ASS format ourselves for
libass rendering, as they certainly don't have VSFilter bug
workarounds. Change the code to use different behavior for "native"
ASS tracks and converted ones. It's questionable whether the
VSFilter-compatible behavior is appropriate for external .ass files
either, as there could be anamorphic and non-anamorphic versions of
the same video and the bug-compatible behavior can only be correct for
one alternative at most. However it's probably better to keep it as a
default at least, so that extracting a muxed subtitle track and using
that does not give behavior different from the original muxed one.
The aspect ratio setting is per ASS_Renderer, and changing it resets
libass caches. For that reason this commit adds separate renderer
instances to use for the "correct" and "VSFilter bug compatible"
cases.
Allow negative values of the "deint" parameter and make them select
the same deinterlacing mode as the corresponding positive value, but
without enabling deinterlace on startup. This is useful for
configuration files. Also tweak the overall manpage description of
vo_vdpau a bit to make it sound less as if the VO would be for
hardware acceleration only.
* hr-seek:
input: add default keybindings Shift+[arrow] for small exact seeks
input: support bindings with modifier keys for X input
core: audio: make ogg missing audio timing workaround more complex
core: add support for precise non-keyframe-limited seeks
core: add struct for queued seek info
commands: add generic option -> property wrapper
options: add "choice" option type, use for -pts-association-mode
core: remove looping in update_video(), modify command handling a bit
core: seek: use accurate seek mode with audio-only files
core: avoid using sh_video->pts as "current pts"
libvo: register X11 connection fd in input event system
core: timing: add special handling of long frame intervals
core: move central play loop to a separate function
Conflicts:
DOCS/tech/slave.txt
Add support for binding commands to modifier+key combinations like
"Shift+Left" or "Ctrl+Alt+x", and support reading such combinations
from the output window of X VOs.
The recognized modifier names are Shift, Ctrl, Alt and Meta. Any
combination of those and then a non-modifier key name, separated by
'+', is accepted as a key name in input.conf. For non-special keys
that produce characters shift is ignored as a modifier. For example
"A" is handled as a key without modifiers even if you use shift to
write the capital letter; 'a' vs 'A' already distinguishes the
combinations with a normal keymap, and having separate 'a', 'Shift+A'
and 'A' (written with caps lock for example) would bring more
confusion than benefit.
Currently reading the modifier+key combinations is only supported in
the output window of those VOs that use x11_common.c event
handling. It's not possible to input the key combinations in other VOs
or in a terminal window.
Set the option value to disabled, not enabled, if the functionality is
not available at all. Without this, -font and -subfont do not work
when using -ass.
git-svn-id: svn://svn.mplayerhq.hu/mplayer/trunk@32636 b3059339-0415-0410-9bf9-f77b7e298cf2
Register the X11 connection fd in the input system so that
mp_input_get_cmd() can immediately wake up and handle keyboard or
other X events. The callback calls vo_check_events() and tells the
input system to handle any input possibly recorded during that. Before
this was done for vo_xv only; this commit generalizes it to all VOs
that call vo_x11_create_vo_window() - those are hopefully ones that
will handle all X events in check_events().
The callback is only kept registered while the vo is properly
configured. At other times calling check_events() would not clear
pending input and so could lead to a busy loop.
The wrong variable was used as a function argument, and as a result
the code modified the usage_count field of non-refcounted mp_image
types. This error did not have any effect on visible behavior as no
code cares about the field value in the affected case.
