Normally, F10 enters the window menu (it's invisible at first, and the
blocking/recursive message handling by Windows makes it look like
mplayer was paused, without much visual indication). Stop this almost
completely useless behavior by signalling Windows that the F10 key was
handled. This makes the F10 key usable as normal mplayer shortcut.
This is probably still somewhat questionable.
Windows sends the same character code on CTRL+Enter and CTRL+J. I'm not
sure what's the proper way to deal with this, but the hack added with
this commit seems to work fine.
Just to be sure, don't forward the modified wParam to DefWindowProc.
Add the missing "break;" in the switch statement, which sometimes
produced bogus mouse button events.
Fix the F12 key, which wasn't mapped correctly due to a typo.
Use the *W variants instead of the implicit *A functions. (One could
define the UNICODE macro to switch the functions without suffix from
A to W, but I'm too lazy to figure out how portable that is, etc.)
Also make sure io.h defines a unicode aware printf().
Support for this is rather simple, and some combinations of modifiers
and keys don't work. For example, Ctrl+Alt+character is not supported,
because Windows doesn't emit a WM_CHAR in this case.
Also add support for the pause and print screen keys. Remove the
pointless KEY_CTRL translation. Remove KEY_CTRL altogether, because it
was not clear what it was actually supposed to mean.
Remove all platform/GUI specific includes from gl_common.h. Get rid of
the ugly union in MPGLContext. Use function pointers instead of an
ifdef ridden switch statement in uninit_mpglcontext(). Always include
glext.h, not only on Windows.
None of this should actually change any functionality.
This new vo is heavily based on vo_gl.c. It provides better scale
filters, dithering, and optional color management with LittleCMS2.
It requires OpenGL 3.
Many features are enabled by default, so it will be slower than vo_gl.
However, it can be tuned to behave almost as vo_gl.
The code used OpenGL 3 specific functions for querying the extension
string when the actual GL 3 context wasn't created yet. This appears to
work fine on nVidia, but could break otherwise. Remove the offending
getFunctions call and retrieve the needed function pointer manually.
(This way the wglCreateContextAttribsARB function pointer can be removed
from struct GL too.)
(Amusingly exposes a wine bug; they made the same mistake.)
Explicitly check the extension string whether the function is available,
although this probably doesn't matter in practice.
Also retrieve bit depth information on win32.
Also include GL/glext.h on windows:
Mingw's (and cygwin's) GL/gl.h has GL/glext.h's inclusion commented
out for some reason. Their glext.h is also ancient, so do yourself
a favor and replace your GL/glext.h with the one from
http://www.opengl.org/registry/api/glext.h .
A workaround is needed for NVidia's broken wglCreateContextAtrribsARB:
It'll return an error if the requested OpenGL version is previous to
3.2 *and* you request a profile... which is exactly *not* what the
wgl_create_context spec says should happen.
Handle it by removing the profile request from attribs[] and retrying
the context creation once more if the first try fails.
And after my first foray into OpenGL I already find a driver quirk.
Oh well.
Also add a bunch of GL functions to the function loader, which will be
needed by vo_gl3. Remove some unused legacy GL functions from the
loader.
Use the proper name for glGetProgramivARB. glGetProgramiv is a different
and incompatible function. The ARB variant is used for ARB shaders,
while the proper one is for GLSL.
The function mp_get_yuv2rgb_coeffs() expects valid values for
input_bits.
When using RGB formats, input_bits is outside the range of what
mp_get_yuv2rgb_coeffs() expects. This doesn't matter since we don't
use the result of that function in the RGB case, but it triggered an
assertion.
This is a regression from commit a816810266,
"vo_gl: improve 10-bit YUV->RGB conversion accuracy slightly".
If the user moved the window to another screen, fullscreen mode would
still use the original screen. Fix to use the screen the window is
currently on (unless overridden by --xineramascreen).
The gl video output is faster and has more features than corevideo, so
it should be preferred on mac osx.
This doesn't affect GUI compatibility because they specify the
corevideo video output along with the suboptions for the shared buffer
name to mmap in.
This video output is not useful anymore. It is based on Carbon to draw
the mplayer window and this has been deprecated by Apple in 10.5.
The upcoming 10.8 OSX release should deprecate most of Carbon, so it
doesn't make sense to keep vo_quartz in the codebase when there are
modern and better alternatives (vo_gl and vo_corevideo).
The Cocoa framework generates only a NS*MouseDown event when handling
the second click of a double click (no NS*MouseUp). If that's the case
put mouse up key in mplayer2's fifo when dealing with the MouseDown
Cocoa event.
Change the window to accept mouse drag events not only on the title
bar, but also on the rest of the window surface; this includes the
video area.
It looks like the changing of the window mask resets the behaviour
specified in the delegate method, probably due to some strange
interaction with NSBorderlessWindow. For this reason call
-setPresentationOptions in the -fullscreen method to remind cocoa the
behaviour we want.
Add option --cursor-autohide-delay to control the number of milliseconds
with no user interaction before the mouse cursor is hidden.
There are two negative values with useful special meanings:
* A value of -1 prevents the cursor from hiding (useful for users
with multiple displays).
* A value of -2 prevents the cursor from showing upon activity.
The default is 1 second to keep the behaviour consistent with the
past X11 backend implementation.
Remove the vo_mouse_autohide field as it was always true.
At least on some keyboards, the key between '0' and 'Enter' on the
key pad is mapped to KP_Separator. Since X11 VOs accept unicode
input, the mplayer keycode this key generates depended on the numlock
state, and with numlock enabled this mapped to an ASCII character.
This is probably not what the user wanted, since two physical keys
will always map to the same key code.
Map it to KP_DEC.
This change allows using non-ASCII keys with X11. These keys were ingored
before.
Technically, this creates an invisible, non-interactive input method
context. If creation fails, the code falls back to the old method, which
allows a subset of ASCII only.
Setting the WM_NAME/WM_ICON_NAME window properties didn't always work:
apparently there are some characters that can't be represented in the X
STRING or COMPOUND_TEXT encodings, such as U+2013 EN DASH. The function
Xutf8TextListToTextProperty partially converts the string, and returns
a value different from 'Success'. This means vo_x11_set_property_string
didn't set these window properties.
On most modern window managers, this is not a problem, since these use
the _NET_WM_NAME/_NET_ICON_NAME and the UTF8_STRING encoding. Some older
WMs like IceWM don't read these, and the window title remains blank.
It's not clear what exactly we should do in this situation, but fix it
by setting set the WM_NAME/WM_ICON_NAME properties as UTF8_TEXT. This
violates the ICCCM, but at least IceWM seems to handle this well.
See also:
http://lists.freedesktop.org/archives/xorg/2004-September/003391.htmlhttp://lists.freedesktop.org/archives/xorg/2004-September/003395.html
Direct rendering support in vo_xv (used with --dr) had at least two
problems. First, OSD drawing modified the buffers; this meant that
if the buffers were used for reference frames there would be video
corruption. I don't think "performance optimization" with this level
of drawbacks is appropriate with today's machines any more. Direct
rendering could still be used for non-reference frames, but there's a
second problem: with direct rendering enabled the same buffer is used
for every frame, and with the XShm extension that is used by default
there's no checking that the previous frame has been completely
uploaded to the graphics card before it's overwritten by the next one.
This could be fixed, but as Xv is becoming obsolete I don't see it as
a priority to improve it. Thus I'm simply removing the parts of
functionality that were more likely to break things than improve
playback.
Restructure parts of the code in the main play loop. The main
functionality difference is that if a video track ends first, now
audio will continue to be played until it ends too.
Now the process also wakes up less often if there's no need to update
video or audio. This will reduce unnecessary wakeups especially when
paused, but may make handling of input events laggier when fd-based
notifications are not supported (like most input on Windows).
Add the flag D3DCREATE_FPU_PRESERVE, which tells Direct3D not to switch
the FPU to single precision mode. Single precision mode would mean that
all floating point calculations are done in float precision, even if
using double variables.
The MSDN documentation seems to discourage use of this flag with scary
warnings about bad performance and stability, but I suspect in practice
switching off this completely unreasonable behavior is fine.
The case when the EOSD sub-images changed position, but didn't need
re-upload, wasn't handled correctly. If a subtitle script made text move
over the screen (without any other changes), the subtitle display wasn't
updated. vo_vdpau was not affected, because vdpau directly reads the
sub-image positions on every frame.
The fix could be simpler. It could recreate the vertex array every frame.
This commit keeps the optimization that nothing is done when the libass
native change detection doesn't report any change. Maybe this optimization
isn't worth doing, since recreating the vertex array is relatively cheap
compared to amount of work required to render complicated subtitles.
The eosd_packer_generate function returning 3 boolean flags is ugly.
Set the window title on win32 based VOs using the same logic as on X11
and Cocoa.
Until now, the window title when using vo_direct3d and vo_gl was hardcoded
to "MPlayer - The Movie Player", and vo_directx showed "MPlayer". Now it
will show "mplayer2", unless the --title or --use-filename-title options
are used.
Change the internal window class name to the string "mplayer2" too.
There are 4 code paths when taking a screenshot:
- textured rendering mode
- StretchRect rendering mode with planar formats
- StretchRect with packed formats
- full-window screenshot mode
The implementation of the full-window mode (capturing the window contents,
instead of the video) is very inefficient: it will create a surface of
desktop size, copy the desktop contents, allocate a new memory image, and
copy in the window contents. The code in screenshot.c will (as of now)
allocate and convert the image from BGR to RGB, and allocate a destination
buffer for the libavcodec PNG writer.
If parts of the mplayer window are obscured, the full-window mode wil
contain these parts as seen on the screen. Parts of the window that are
outside the bounds of the desktop are clipped away. It is not known
whether full-window mode works on multi-monitor setups.
Switching to fullscreen mode on Windows 7 didn't work: the window position
and size weren't set to fullscreen. It turns out that merely calling
SetWindowLong caused windows to send move/resize messages, which changed
the global variables that were supposed to contain the new window size.
Move the SetWindowLong call out of the way to guarantee that always the
correct values are used.
If the Direct3D device is "lost" (e,g, when minimizing mplayer, or when
another application uses Direct3D exclusive mode), we free it and try to
recrate the device. This can fail, and may fail for an extended period of
time, until D3D is available again and the device can be created. So we
basically have to provide all VO functionality while d3d_device is NULL.
Don't terminate if device creation fails, and re-add the NULL checks that
were removed in the commit "vo_direct3d: refactor D3D initialization and
reconfigure code".
If mplayer calls the VO's config() while the D3D device can not be
created, the VO will return an error and mplayer will terminate.
config() is typically called when new files are played, when ordered
chapter boundaries are crossed, or on other events.
This actually applies to YUV formats with 9-16 bit depths. This hack is
disabled by default, and the VO will use 16 bit textures normally.
It can be enabled by passing the no16bit-textures option is passed to
vo_direct3d. Then the VO will use D3DFMT_A8L8 as texture formats for the
YUV plane (instead of D3DFMT_L16), and compute the sampled two color
values back into one.
In some cases it might be undesireable to use 16 bit texture formats. At
least some OpenGL drivers on Linux (Mesa + Intel) round values sampled
from 16 bit textures back into 8 bit, which loses 8 from 10 bit color
information when playing 10 bit formats. It is unknown whether there are
D3D9 drivers which do this, so this commit might be removed later.
This simplifies the code and removes code duplication.
There should be no actual semantic differences to the previous code. The
only exception is that the new code doesn't query the display adapter's
desktop pixel format on backbuffer resizing anymore. In my opinion the
format can never change anyway, and if it does, it will cause the D3D
device to become "uncooperative" and we will recreate it in flip_page.
Remove attempts to handle d3d_device when it's NULL (outside of the
initialization paths). d3d_device can only be NULL if recreating a D3D
device, that was in "incooperative" state, fails. The current (and
previous) code seems to assume that this never happens. It is unlikely
that these NULL checks improved correct operation in any way, or at least
they won't anymore after the recent changes done to the code.
If it should be possible that a device can't be reset/recreated for a
while (during display resolution changes? when another D3D application is
in fullscreen mode?), another solution has to be found.
It is unknown why the code recreates the IDirect3D9 interface when the
device was uncooperative. At least on Windows XP + reference rasterizer,
resuming works without recreating it. Leave this code just in case.
Now using the "direct3d" VO will never make use of shaders. Instead, users
are supposed to use the direct3d_shaders VO entry, which is exactly the
same as direct3d, except with shaders enabled by default.
"direct3d" always uses the Direct3D StretcRect API call to render videos.
Playing formats not supported by this function will force mplayer to
insert a scale filter to convert video frames in software.
"direct3d_shaders" prefers shader color conversion, but can fall back to
StretchRect if the format can be handled. (This happens only with some
insignificant packed YUV formats.)
The minor reformats are mainly about adding more line breaks to fit a 80
column limit.
Using the new VO API implies removing all non-const global variables
(because that is one important goal of the new API), so do that as well.
The code already had all variables in a context struct, and changing all
the functions to pass this context struct along was all what had to be
done.
Also handle redrawing properly: if something changes that requires an
immediate redrawing operation (e.g. setting video equalizers when paused
or when playback is slow), vo->want_redraw should be set, instead of
redrawing on your own.
Use the 3D rendering functions and shaders to render the video frame. This
is very similar to vo_gl. Most planar formats with varying chroma shifts
and bit depths are supported (including 10 bit), as well as some RGB
formats. The old code that used D3D's StretchRect function is still
available, but will by default be used with the least priority.
Also implement video equalizers and colorspace selection. These use the
same code as vo_gl and vo_vdpau, and are available only if shader YUV
conversion is active.
The rendering is extremely simple and naive, there are no filters etc.
Since compiling shaders seems to require the 500 MB DirectX SDK, all
shaders come in pre-compiled form, and there is no make rule to compile
them. mplayer should be compilable without 500 MB of garbage.
The main problem is that compiling shaders within an application seems to
require d3dx9_*.dll, which isn't installed by default.
Add an option ("disable-texture-align") that allows making the video
textures exactly the same size as the source video. The code used to align
the OSD texture size on 16 for unknown reasons, but since this was perhaps
a good reason, this behavior is kept for video textures as well. (There is
a chance that the alignment improves performance and stability with some
drivers.) Passing this option disables this behavior. It is useful for
reducing texture filtering artifacts at the bottom/right borders.
The code locked the texture once for each OSD object that was rendered.
But there doesn't seem to be any good reason to do that, so lock it only
once during OSD rendering.
The OSD code used a shadow texture on systems that don't report
D3DDEVCAPS_TEXTURESYSTEMMEMORY. Do that for EOSD as well. Refactor the
OSD texture management code to reduce code duplication.
I have not the slightest clue about Direct3D9 texture management, so it
seems like a good idea not to do something different for EOSD textures,
even though the OSD code does exactly the same as far as texture handling
goes.
It's also worth noting that D3DDEVCAPS_TEXTURESYSTEMMEMORY doesn't seem to
be supported by most real systems [1], and maintaining a shadow copy in
system memory in order to update textures is required. The previous EOSD
texture code may or may not have worked on some or all real systems, I
can't really tell by reading the MSDN documentation only.
[1] http://www.kludx.com/capability.php?capability=17
The D3D state (the IDirect3DDevice9 and all textures and buffers) were
released and recreated in the config() function. This is completely
unnecessary. Instead explicitly handle changes. The video surface is only
reallocated if the video format or the video size changes. The OSD texture
is only reallocated if the window size is increased. The EOSD texture is
not released. Since the resize code is reused to deal with reconfig
changes, some of these improvements (and possible bugs) apply to normal
window resizing as well.
