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.
The required feature for this, VOCTRL_REDRAW_OSD, was unimplemented for
unknown reasons. It is trivial to add.
There is still a weird issue when switching the fullscreen state while
paused. I have no idea why this happens. The contents of the video should
survive the window reconfiguration (at least we don't free it), and we
explicitly redraw the screen after fullscreen.
The code assumed the last format passed to query_format will be the one
that is used on playback. This is probably true and thus didn't cause any
bugs, but make query_format side effect free just like the other VOs.
Clipping it makes the video output look extremely crappy. There seems no
good reason to do this, and VirtualBox is fine with overlays larger than
the screen.
The code used WM_WINDOWPOSCHANGING to force an spect ratio. This didn't
behave well if the left/top window borders were used for resizing.
Resizing with these borders changed the screen position of the right/bottom
as well, which is unintuitive and annoying.
Use WM_SIZING instead. Unlike WM_WINDOWPOSCHANGING, WM_SIZING knows about
which border is being used for resizing and can act accordingly.
Note that the calculated window size doesn't necessarily match with the
size mplayer calculates, but this problem exists on x11 as well.
This commit fixes various issues with the way the window position and
size is setup. Most importantly, it fixes some bugs with restoring from
fullscreen state.
Rename create_rendering_context() to reinit_window_state(). This function
doesn't create anything, it just sets the window bounds and styles.
Do not use vo_dx/dy for the window position, as video_out.c overwrites it
with each vo_config() call. Use private variables window_x/y instead.
A big cause for issues was that reinit_window_state() accidentally cleared
the WS_VISIBLE style. I suspect that the API call to temporarily hide the
window was a hack to deal with this. Another bug was that the window style
was changed without calling SetWindowPos with SWP_FRAMECHANGED (as the
MSDN documentation says).
Properly initialize window position and size on vo_config following the
same rules as the x11 backend:
- Never change the window position. The window position should be kept, as
the user might move the window, and resetting the window position e.g.
during ordered chapter playback is not desired.
- Never change the window size, unless the size of the video changes.
These rules don't apply to fullscreen. When switching from fullscreen to
windowed mode, the backend should restore the previous windowed size and
position. When the VO was reconfigured during playback (vo_config() etc.),
the saved window position and size should be changed according to the
rules above, even if the window was in fullscreen mode during
reconfiguring.
Note that these rules might be perceived as awkward by some users: if you
play multiple files with different resolutions, the window won't be
centered when playing the files after the first. This is not a bug.
Restore hunk disabling overlay when the Window is minimized.
This was accidentally removed in r33657.
Fixes bug 1950.
git-svn-id: svn://svn.mplayerhq.hu/mplayer/trunk@33894 b3059339-0415-0410-9bf9-f77b7e298cf2
Simplify code handling minimized state.
git-svn-id: svn://svn.mplayerhq.hu/mplayer/trunk@33895 b3059339-0415-0410-9bf9-f77b7e298cf2
Apply uncrustify to vo_directx.c.
The vast majority of changes are whitespace changes, but in some cases
{} was merged with other lines or a ; was removed after a } from a
switch and similar minor and obviously correct changes.
git-svn-id: svn://svn.mplayerhq.hu/mplayer/trunk@33896 b3059339-0415-0410-9bf9-f77b7e298cf2
Fix array layout uncrustify messed up.
git-svn-id: svn://svn.mplayerhq.hu/mplayer/trunk@33897 b3059339-0415-0410-9bf9-f77b7e298cf2
Remove pointless () and {}.
git-svn-id: svn://svn.mplayerhq.hu/mplayer/trunk@33898 b3059339-0415-0410-9bf9-f77b7e298cf2
Make NULL checks simpler/more consistent.
git-svn-id: svn://svn.mplayerhq.hu/mplayer/trunk@33899 b3059339-0415-0410-9bf9-f77b7e298cf2
Use FFMIN/FFMAX.
git-svn-id: svn://svn.mplayerhq.hu/mplayer/trunk@33901 b3059339-0415-0410-9bf9-f77b7e298cf2
Simplify struct initialization.
git-svn-id: svn://svn.mplayerhq.hu/mplayer/trunk@33902 b3059339-0415-0410-9bf9-f77b7e298cf2
Split out read/write part from data struct and make read-only
struct const.
git-svn-id: svn://svn.mplayerhq.hu/mplayer/trunk@33903 b3059339-0415-0410-9bf9-f77b7e298cf2
Store fixed-length string directly in struct, avoid pointer indirection.
git-svn-id: svn://svn.mplayerhq.hu/mplayer/trunk@33904 b3059339-0415-0410-9bf9-f77b7e298cf2
Replace some inappropriate while() loops with for()
git-svn-id: svn://svn.mplayerhq.hu/mplayer/trunk@33905 b3059339-0415-0410-9bf9-f77b7e298cf2
Simplify some more struct initializations.
git-svn-id: svn://svn.mplayerhq.hu/mplayer/trunk@33906 b3059339-0415-0410-9bf9-f77b7e298cf2
Avoid typedef.
git-svn-id: svn://svn.mplayerhq.hu/mplayer/trunk@33907 b3059339-0415-0410-9bf9-f77b7e298cf2
Use struct initializer in one more case.
git-svn-id: svn://svn.mplayerhq.hu/mplayer/trunk@33908 b3059339-0415-0410-9bf9-f77b7e298cf2
Simplify printing of error strings.
git-svn-id: svn://svn.mplayerhq.hu/mplayer/trunk@33909 b3059339-0415-0410-9bf9-f77b7e298cf2
Conflicts:
libvo/vo_directx.c
Modify the YUV->RGB conversion matrix to take into account the
difference between the same color value being x/255 in a 8-bit texture
and x*256/65535 in a 16-bit texture (actually things are stored as
x*4/65535 for 10-bit color, but that can be ignored here). This 0.4 %
difference in the shader float value could make shades of gray in
10-bit (or generally more than 8 bit) YUV produce RGB values with
green slightly higher than red/blue.
Windows uses a legacy codepage for char* / runtime functions accepting
char *. Using UTF-8 as the codepage with setlocale() is explicitly
forbidden.
Work this around by overriding the MSVCRT functions with wrapper
macros, that assume UTF-8 and use "proper" API calls like _wopen etc.
to deal with unicode filenames. All code that uses standard functions
that take or return filenames must now include osdep/io.h. stat()
can't be overridden, because MinGW-w64 itself defines "stat" as a
macro. Change code to use use mp_stat() instead.
This is not perfectly clean, but still somewhat sane, and much better
than littering the rest of the mplayer code with MinGW specific hacks.
It's also a bit fragile, but that's actually little different from the
previous situation. Also, MinGW is unlikely to ever include a nice way
of dealing with this.
Some of the code, especially the dshow and windows codec loader parts,
are extremely hacky and likely full of bugs. The goal is merely getting
rid of warnings that could obscure more important warnings and actual
bugs, instead of fixing actual problems. This reduces the number of
warnings from over 500 to almost the same as when compiling on Linux.
Note that many problems stem from using the ancient wine-derived
windows headers. There are some differences to the "proper" windows
header. Changing the code to compile with the proper headers would be
too much trouble, and it still has to work on Unix.
Some of the changes might actually break compilation on legacy MinGW,
but we don't support that anymore. Always use MinGW-w64, even when
compiling to 32 bit.
Fixes some warnings in the win32 loader code on Linux too.
Instead of opening avctx in preinit() and setting paramters later,
(re)open it in config() where parameters can be set first. This fixes
a failure to open the codec with new libavcodec versions that check
pix_fmt during avcodec_open2().
vo_xv crashed if existing frames had been lost due to a config() call
in the middle of a file and vo_redraw_frame() was called. Add checks
to reject vo_redraw_frame() unless at least one frame has been flipped
after the the last configuration change, so individual VOs do not have
to deal with this case.
The "backend" suboption allows selecting the GUI backend used by vo_gl.
Normally, it's auto-selected, but sometimes it's desireable to explicitly
select it.
Remove the gl_sdl VO. This can now be done by using: --vo=gl:backend=sdl
This is based on svn commit 34438, and tries to be compatible with it. The
undocumented numeric backend names serve this purpose. (They are
undocumented because names are preferred.)
Fix spelling.
git-svn-id: svn://svn.mplayerhq.hu/mplayer/trunk@34006 b3059339-0415-0410-9bf9-f77b7e298cf2
Fix disabled code.
git-svn-id: svn://svn.mplayerhq.hu/mplayer/trunk@34007 b3059339-0415-0410-9bf9-f77b7e298cf2
Remove pointless pointer indirection for shader program strings.
git-svn-id: svn://svn.mplayerhq.hu/mplayer/trunk@34016 b3059339-0415-0410-9bf9-f77b7e298cf2
Remove usage of glColor3f, there is not really a point in it.
git-svn-id: svn://svn.mplayerhq.hu/mplayer/trunk@34149 b3059339-0415-0410-9bf9-f77b7e298cf2
Remove the private bswap and intreadwrite.h implementations and use
libavutil headers instead.
Originally these headers weren't publicly installed by libavutil at
all. That already changed in 2010, but the pure C bswap version in
installed headers was very inefficient. That was recently (2011-12)
improved and now using the public bswap version probably shouldn't
cause noticeable performance problems, at least if using a new enough
compiler.
Change various code to use the latest Libav API. The libavcodec
error_recognition setting has been removed and replaced with different
semantics. I removed the "--lavdopts=er=<value>" option accordingly,
as I don't think it's widely enough used to be worth attempting to
emulate the old option semantics using the new API. A new option with
the new semantics can be added later if needed.
Libav dropped APIs that were necessary with all Libav versions
until quite recently (like setting avctx->age), and it would thus not
be possible to keep compatibility with previous Libav versions without
adding workarounds. The new APIs also had some bugs/limitations in the
recent Libav release 0.8, and it would not work fully (at least some
avcodec options would not be set correctly). Because of those issues,
this commit makes no attempt to maintain compatibility with anything
but the latest Libav git head. Hopefully the required fixes and
improvements will be included in a following Libav point release.
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
Also fix a minor memory leak when conversion to COMPOUND_TEXT fails.
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.
This is an experiment.
The change probably doesn't matter much.
One issue with the old code was that "large" images caused each sub-image
to be created and rendered as a new texture. "Large" in this case means
larger than 32x32 pixels, which actually isn't very large with screen
sizes beyond 1500x1000 pixels. This means rendering a simple subtitle for
a fullscreened video may allocate many small textures, one for each glyph.
On the other hand, the old code could be fixed by tuning the texture sizes
for "modern" work loads.
Also, the new code uses less deprecated OpenGL features and draws all
sub-images in one batch.
There are two possible issues the new code could cause:
- Drivers could have performance issues with the larger texture sizes and
the number of glTexSubImage2D calls on it
- There is only one EOSD texture, which could become full (it's enlarged
on demand, but restricted by driver texture size limitations)
It has been reported that this is faster on OSX with ATI GPUs than the old
code.
The code in eosd_packer.c/.h is taken from vo_vdpau.c and has been made
independent from vdpau API specifics. This allows other VOs, which need
to pack the small EOSD images into a large surface for efficiency, to use
this code.
Recent commits for screenshot support and video redraw changes didn't
handle vdpau driver preemption state correctly, which could make the
player crash if preemption occurred. Fix this and improve preemption
handling a bit otherwise.
Currently there is no way to set the swap interval with a function
that has a signature compatible with other platforms' gl extensions.
Make a wrapper function around the gui toolkit method of setting the
swap interval property, and point gl->SwapInterval to it.
Remove the useless dependency on MPGLContext from cocoa_common, since
it was used just to access the vo struct. Change gl_common to pass the
vo struct directly to all the cocoa_common functions.
Always set the X11 window title properties as UTF-8. This is a bit tricky
for X11 window properties which are not specified to use UTF-8, such as
WM_NAME.
We also properly set WM_ICON_NAME, which means the window caption and the
text used in the task bar (of the WM has one) will be the same on most
window managers. Before this commit, WM_ICON_NAME was always hardcoded to
"MPlayer", even if --title or --use-filename-title was used.
Also update the window title only on reconfigure, like it is done in
mplayer-svn commit 34380.
This affects only the "new" VO API. The config() title argument was barely
used, and it's hardcoded to "MPlayer" in vf_vo.c. The X11 and the Cocoa
GUI backends, which are the only ones properly supporting window titles,
ignored this argument. Remove the title argument.
Add the vo_get_window_title function. All GUI VOs are supposed to use it
for the window title.
Remove code refreshing window contents after events such as resize
from vo_vdpau, vo_gl and vo_xv. Instead have them simply set a flag
indicating that a refresh is needed, and have the player core perform
that refresh by doing an OSD redraw. Also add support for updating the
OSD contents over existing frames during slow-but-not-paused playback.
The VOs now also request a refresh if parameters affecting the picture
change (equalizer settings, colormatrix, VDPAU deinterlacing setting).
Even previously the picture was typically redrawn with the new
settings while paused because new OSD messages associated with setting
changes triggered a redraw, but this did not happen if OSD was turned
off.
A minor imperfection is that now window system events can trigger a
single one-frame step forward when using vo_xv after pausing so that
vo_xv does not yet have a copy of the current image. This could be
fixed but I think it's not important enough to bother.
Previously the core sent VFCTRL_REDRAW_OSD to change OSD contents over
the current frame. Change this to VFCTRL_REDRAW_FRAME followed by
normal EOSD and OSD drawing calls, then vo_flip_page(). The new
version supports changing EOSD contents for libass-rendered subtitles
and simplifies the redraw support code needed per VO. vo_xv doesn't
support EOSD changes because it relies on vf_ass to render EOSD
contents earlier in the filter chain.
vo_xv logic is additionally simplified because the previous commit
removed the need to track the status of current and next images
separately (now each frame is guaranteed to become "visible" soon
after we receive it as "next", with no VO code running in the interval
between).
Separate passing a new frame to VOs using the new API into two steps.
The first, vo_draw_image(), happens after a new frame is available
from the filter chain. In constrast to old behavior, now the frame is
not actually rendered yet at this point (though possible slice draw
calls can already reach the VO before). The second step,
vo_new_frame_imminent(), happens when we're close enough to the
display time of the new frame that we'll commit to flipping it as the
next action and will not change the OSD over the previous frame any
more.
This new behavior fixes a previous problem with vo_vdpau and vo_gl in
the situation where the player is paused after decoding a new frame
but before flipping it; previously changing OSD in that state would
switch to the new frame as a side effect. It would also allow an easy
way to fix extra output files produced with something like "--vo=png
--frames=1" with precise seeking, but this is not done yet.
The code now relies on a new mp_image from the filter chain staying
valid even after the vf_vo put_image() call providing it returns. In
other words decoders/filters must not deallocate or otherwise
invalidate their output frame between passing it forward and returning
from the decode/filter call.
Add native Cocoa code to display an OpenGL window. Some of the code is
based on the OpenGL parts of vo_corevideo but I took the time to remove
old code based on Carbon.
There is autodetection in the configure script but you can use
--enable[disable]-cocoa to enable[disable] this.
When interpreting a key event, use the "charactersIgnoringModifiers"
method of the event in order to extract Alt+key combinations while
keeping the normal meaning of "key". When the right alt modifier is
pressed use the "characters" method to allow AltGr behavior to be used
to generate different characters.
The ARB shader code generated at the end of the shaders for scaling mode 4
and 5 was something like:
MAD yuv.g, b.r, {0.5}, a.r;
This appears to be semantically equivalent with:
MAD yuv.g, b.rrrr, {0.5, 0, 0, 0}, a.rrrr;
This has the consequence that the result register, yuv.g, will not contain
the value computed by the scale filter, but a.r. a.r is the unchanged
value sampled from the normal texture coordinates, so the filter did
effectively nothing and behaved as if cscale=0 was specified. The basic
mistake here is that yuv.g does not specify a single register, but it
specifies the full vector register yuv, with writing enabled on the g
channel. This means yuv.g will assigned the g channel of the the result
vector computed by the MAD instruction.
The GL_LUMINANCE16 texture format had only 8 bit precision on Mesa
based drivers. This caused heavy degradation of the image when playing
formats with more than 8 bits per pixel, such as 10 bit h264. Use
GL_R16 instead, which at least Mesa and Nvidia drivers actually
implement as 16 bit textures. Since sampling from this texture format
doesn't return anything meaningful in the other color components
(unlike luminance textures), the shader code has to be slightly
changed.
GL_R16 requires the GL_ARB_texture_rg extension. Check for it, and fall
back to the old texture format if it's not available.
The low precision of the GL_LUMINANCE16 format has just been fixed in
upstream Mesa, but it'll take a while before that fix is available in
distros.
The shader code was generated from very long strings with lots of
format specifiers with snprintf calls. It was almost impossible to
quickly tell what variables were inserted where in the shader. Make
this more readable by implementing a kind of simple variable
substitution, which allows replacing the format specifiers in the code
templates with with variable names.
Caveat: the OSD will be included in the screenshots when the screenshot is
taken during normal playback. This doesn't happen when a screenshot is
taken while playback is paused.
Fixing this would introduce a small performance reduction during normal
playback, which is unacceptable for a possibly rarely used optional
feature.
Due to the nature of the Xv API, taking a screenshot of the scaled video
isn't possible either.
The screenshot command normally converts the currently displayed video
frame to an image. Add support for an alternative screenshot mode
that is supposed to capture the real window contents. Such a
screenshot contains a possibly scaled version of the frame, the OSD,
and subtitles.
Add a default key binding Alt+s for taking screenshots in this mode.
This needs special VO support, and might not work with all VOs (this
commit does not yet contain an implementation for any VO, only the
infrastructure).
Add a VO command (VOCTRL_SCREENSHOT) which requests a screenshot
directly from the VO. If VO support is available, screenshots will be
taken instantly (no more 1 or 2 frames delay). Taking screenshots when
hardware decoding is in use will also work (vdpau). Additionally, the
screenshots will now use the same colorspace as the video display.
Change the central MPContext to be allocated with talloc so that it
can be used as a talloc parent context.
This commit does not yet implement the functionality for any VO (added
in subsequent commits).
The old screenshot video filter is not needed anymore if VO support is
present, and in that case will not be used even if it is present in
the filter chain. If VO support is not available then the filter is
used like before. Note that the filter still has some of the old
problems, such as delaying the screenshot by at least 1 frame.
Some functionality provided by the windowing backend (such as x11,
win32) is optional. The function pointers in MPGLContext are NULL if
the functionality is not implemented. Check them before calling them,
instead of crashing. This happened at least on Windows with the
"vo_ontop" command.
The register combiner color conversion is broken and seems to use a
slightly incorrect color matrix (the image looks gray-ish). Completely
remove all code related to nVidia register combiners.
Unless you have an ancient nVidia GPU, there's no reason to prefer register
combiners over fragment shaders. Users with ancient GPUs without fragment
shader support can just use -vo xv.
Passing yuv=1 (register combiners) as sub option will print a warning and
use yuv=2 (fragment shaders) instead.
Using the ati-hack and force-pbo suboptions (both can be enabled
automatically when particular ATI drivers are detected) could lead to
segfaults due to incorrect length calculation.
The problem is that width*((bpp+7)/8) == width*(bpp+7)/8 doesn't hold
true in general. The old code used bpp/8, because bpp was always
guaranteed to be divisible by 8. When commit 20256a8a64 fixed bugs
around 10 bit pixel formats, this assumption was broken, and resulted
in out of bounds memory accesses.
Additionally, the color values that were used to clear image borders
were incorrect and showed up as pink borders on the right/bottom sides
of the video when playing 10 bit content. Make the clear value
approximately correct; the borders are still filled with a single byte
value even though formats with 9-16 bits should be cleared with 2-byte
values with the low byte 0.
This commit also contains some other minor cleanups with no functional
changes.
Now modifiers such as shift, control, and alt are handled.
Unfortunately this requires a hack to deal with a SDL quirks when combining
CTRL and a letter key.
Also add some missing key syms.
Now all windowing specific code is in gl_common.c.
init_mpglcontext() used to set dummy callbacks for non-optional windowing
callbacks. Remove these, as they only lead to confusion.
The actual work is done by the existing SDL code. This commit merely
makes it possible to explicitly select the SDL backend ("gl" alone
uses SDL only if the X11 and win32 backends are not available, while
the new "gl_sdl" always forces use of SDL).
Also disable YUV conversion method autodetection when SDL is used.
This gets rid of a temporary window that appears for a moment and is
immediately closed again. SDL can't deal with the VOFLAG_HIDDEN flag,
which is needed to create an invisible GL context (when the
autodetection is run, the video size isn't yet known to the VO, and
creating a window then resizing would cause problems with window
placement). Instead always pick the fragment program method by default
(yuv=2). This change affects the normal "gl" VO too if it chooses the
SDL backend.
Apparently this is fully redundant given the global "noaspect" option.
Refuse this suboption, and output an error message suggesting the
correct option.
Reformat vo_gl.c, gl_common.c, gl_common.h.
Remove all global variables and move them into a context struct (the
Windows and SDL backends still refer to global_vo though).
Change vo_gl.c to use the "new" VO API.
Delete the vo_gl2 and vo_matrixview implementations.
vo_gl2 was barely useful anymore. It was a hack based on an old
vo_gl.c version, and all it did differently was rendering the video in
tiles instead of using a single texture. That made it work with some
crappy OpenGL implementations. These days all GPUs support textures of
at least 2048x2048 pixels, which is enough for HD playback. On the
other hand, gl2 suffered from various bugs and deficiencies, all of
which are fixed in gl. Its existence also confused users; many thought
that gl2 is the next version of gl and attempted to use it, even
though it's much worse than gl and they should have used that instead.
Should it turn out that tiling is actually useful, it should be
implemented in vo_gl, instead of keeping vo_gl2 alive.
vo_matrixview was a toy that couldn't even properly display a video.
All it did was display a screensaver-like animation that showed "a
Matrix-like running-text effect". (mplayer is not a screensaver.)
Rewrite control of the colorspace and input/output level parameters
used in YUV-RGB conversions, replacing VO-specific suboptions with new
common options and adding configuration support to more cases.
Add new option --colormatrix which selects the colorspace the original
video is assumed to have in YUV->RGB conversions. The default
behavior changes from assuming BT.601 to colorspace autoselection
between BT.601 and BT.709 using a simple heuristic based on video
size. Add new options --colormatrix-input-range and
--colormatrix-output-range which select input YUV and output RGB range.
Disable the previously existing VO-specific colorspace and level
conversion suboptions in vo_gl and vo_vdpau. Remove the
"yuv_colorspace" property and replace it with one named "colormatrix"
and semantics matching the new option. Add new properties matching the
options for level conversion.
Colorspace selection is currently supported by vo_gl, vo_vdpau, vo_xv
and vf_scale, and all can change it at runtime (previously only
vo_vdpau and vo_xv could). vo_vdpau now uses the same conversion
matrix generation as vo_gl instead of libvdpau functionality; the main
functional difference is that the "contrast" equalizer control behaves
somewhat differently (it scales the Y component around 1/2 instead of
around 0, so that contrast 0 makes the image gray rather than black).
vo_xv does not support level conversion. vf_scale supports range
setting for input, but always outputs full-range RGB.
The value of the slave properties is the policy setting used for
conversions. This means they can be set to any value regardless of
whether the current VO supports that value or whether there currently
even is any video. Possibly separate properties could be added to
query the conversion actually used at the moment, if any.
Because the colorspace and level settings are now set with a single
VF/VO control call, the return value of that is no longer used to
signal whether all the settings are actually supported. Instead code
should set all the details it can support, and ignore the rest. The
core will use GET_YUV_COLORSPACE to check which colorspace details
have been set and which not. In other words, the return value for
SET_YUV_COLORSPACE only signals whether any kind of YUV colorspace
conversion handling exists at all, and VOs have to take care to return
the actual state with GET_YUV_COLORSPACE instead.
To be changed in later commits: add missing option documentation.
vo_gl.c hardcoded the assumption that YUV formats always use 1 byte per
component. This corrupted the output when playing 10 bit h264 video.
Only the PBO code path was affected. PBOs are normally unused, unless ATI
is detected, or the force-pbo option is used.
Rewrite the csputils.c code generating a conversion matrix for
YUV->RGB conversions (currently used by vo_gl only). Functional
differences:
- The separate "mplayer default" colorspace is removed, and BT.601 is
used instead (the default colorspace was in fact BT.601; see below).
- The old code was missing chroma scaling. As a result the "mplayer
default" colorspace actually mapped to BT.601, and everything else
was buggy (I guess the other colorspaces were added with particular
coefficient semantics, without understanding that the original
"default colorspace" was actually BT.601 and why its coefficients
differed from the added version).
- The old code had a bug in the equalizer hue equations.
- The old code assumed that for specifying whether input and output
were limited-range or full-range YUV or RGB it would make sense to
specify "no conversion" meaning full-range YUV to full-range RGB or
limited-range YUV to limited-range RGB. This isn't true; limited-
range YUV has different ranges for luma and chroma (16-235
vs 16-240) which means you have to scale chroma for limited->limited
conversions. The new code assumes limited->limited conversions for
the levelconv parameter 2. It'd probably make sense to change the
API later to specify the ranges of input and output separately.
- The undocumented EBU and XYZ colorspaces are removed. I doubt any
videos use these. Also the EBU colorspace looks like it'd expect
a different input range - at least no input would map to full RGB
red as it was.
Convert the list of VOCTLR_* defines to an enum, dropping some unused
values. This resolves a collision between VOCTRL_XOVERLAY_SET_COLORKEY
and VOCTRL_REDRAW_OSD, which had the same value (the XOVERLAY one was
only used by vo_xvr100 and vo_tdfx, so this didn't matter much in
practice).
Commit decec7f2a3 ("vo_vdpau: skip resize code if not fully
initialized") broke preemption recovery because the resize code stayed
incorrectly disabled when it would have been used to reinitialize
things during recovery. Revert that commit and add different checks
to avoid running various code when not in a fully functional state.
Code mapping X keyboard events to internal player key names remapped
the incoming KeySym values in a way that only kept information about
the lowest byte of the value and whether or not the value was below
256. This caused collisions between values. Remove this obviously
broken mapping and use the raw KeySym values instead. I'm not familiar
enough with X key handling to tell whether there was any valid
motivation whatsoever for the mapping, but the implementation was
certainly broken; if something else breaks it'll have to be fixed
later.
Do the global initialization of libavcodec and libavformat
(avcodec_register_all(), av_register_all()) immediately on program
startup and remove the initialization calls from various individual
modules that use libavcodec/libavformat functionality.
Window events or user commands could trigger a call to resize() before
config() had been called. This caused at least error messages. Add a
check to make resize() exit without doing anything in this case. It
will be called again later when the output is configured.
Rework much of the logic related to reading from event sources and
queuing commands. The two biggest architecture changes are:
- The code buffering keycodes in mp_fifo.c is gone. Instead key input
is now immediately fed to input.c and interpreted as commands, and
then the commands are buffered instead.
- mp_input_get_cmd() now always tries to read every available event
from every event source and convert them to (buffered) commands.
Before it would only process new events until one new command became
available.
Some relevant behavior changes:
- Before commands could be lost when stream code called
mp_input_check_interrupt() which read commands (to see if they were
of types that triggered aborts during slow IO tasks) and then threw
them away. This was especially an issue if cache was enabled and slow
to read. Fixed - now it's possible to check whether there are queued
commands which will abort playback of the current file without
throwing other commands away.
- mp_input_check_interrupt() now prints a message if it returns
true. This is especially useful because the failures caused by
aborted stream reads can trigger error messages from other code that
was doing the read; the new message makes it more obvious what the
cause of the subsequent error messages is.
- It's now possible to again avoid making stdin non-blocking (which
caused some issues) without reintroducing extra latency. The change
will be done in a subsequent commit.
- Event sources that do not support select() should now have somewhat
lower latency in certain situations as they will be checked both
before and after select()/sleep in input reading; before the sleep
always happened first even if such sources already had queued
input. Before the key fifo was also handled in this manner (first
key triggered select, but if multiple were read then rest could be
delayed; however in most cases this didn't add latency in practice
as after central code started doing command handling it queried for
further commands with a max sleep time of 0).
- Key fifo limiting is more accurate now: it now counts actual
commands intead of keycodes, and all queued keys are read
immediately from input devices so they can be counted correctly.
- Since keypresses are now interpreted immediately, commands which
change keybindings will no longer affect following keypresses that
have already been read before the command is executed. This should
not be an issue in practice with current keybinding behavior.
Cosmetics: vo_mpegpes.c: Fix strange space placement
Avoids clang warning that =- might have been intended as -=.
git-svn-id: svn://svn.mplayerhq.hu/mplayer/trunk@33797 b3059339-0415-0410-9bf9-f77b7e298cf2
vo_jpeg: Use "const char *" type for paths.
Fixes a clang warning due to sign mismatch when calling open().
git-svn-id: svn://svn.mplayerhq.hu/mplayer/trunk@33799 b3059339-0415-0410-9bf9-f77b7e298cf2
mga_template.c: Remove pointless and in addition incorrect cast.
git-svn-id: svn://svn.mplayerhq.hu/mplayer/trunk@33800 b3059339-0415-0410-9bf9-f77b7e298cf2
Simplify code for printing display adapter list.
git-svn-id: svn://svn.mplayerhq.hu/mplayer/trunk@33672 b3059339-0415-0410-9bf9-f77b7e298cf2
Remove left-over code from icon/cursor handling that is
now done by w32_common.c
git-svn-id: svn://svn.mplayerhq.hu/mplayer/trunk@33673 b3059339-0415-0410-9bf9-f77b7e298cf2
Remove more code and variables that have no purpose anymore.
git-svn-id: svn://svn.mplayerhq.hu/mplayer/trunk@33674 b3059339-0415-0410-9bf9-f77b7e298cf2
Remove some #includes that are no longer needed.
git-svn-id: svn://svn.mplayerhq.hu/mplayer/trunk@33675 b3059339-0415-0410-9bf9-f77b7e298cf2
Remove more unnecessary code/defines.
git-svn-id: svn://svn.mplayerhq.hu/mplayer/trunk@33677 b3059339-0415-0410-9bf9-f77b7e298cf2
Move check_events function to avoid forward declaration.
git-svn-id: svn://svn.mplayerhq.hu/mplayer/trunk@33678 b3059339-0415-0410-9bf9-f77b7e298cf2
Remove more unused variables.
git-svn-id: svn://svn.mplayerhq.hu/mplayer/trunk@33679 b3059339-0415-0410-9bf9-f77b7e298cf2
Add const to avoid compiler warning.
git-svn-id: svn://svn.mplayerhq.hu/mplayer/trunk@33680 b3059339-0415-0410-9bf9-f77b7e298cf2
Use the proper type for the palette, fixes compiler warning.
git-svn-id: svn://svn.mplayerhq.hu/mplayer/trunk@33681 b3059339-0415-0410-9bf9-f77b7e298cf2
While I tested it quite thoroughly, with and without
-wid, -vm, -fs, ... it is _very_ likely to break
something, please report any regressions!
In the worst case it can still be reverted, however
since it has very little relevance nowadays it will
rot all the faster if not at least some code is shared.
git-svn-id: svn://svn.mplayerhq.hu/mplayer/trunk@33657 b3059339-0415-0410-9bf9-f77b7e298cf2
Allow Pause/Break key to be bound as MPlayer input key under X11.
patch by Steaphan Greene, sgreene cs.binghamton edu
git-svn-id: svn://svn.mplayerhq.hu/mplayer/trunk@33609 b3059339-0415-0410-9bf9-f77b7e298cf2
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
The x11_common.c window creation code could lose the initial expose
event due to input mask changes. This meant that the window might
not be cleared at start (there's a vo_x11_clearwindow() call but it
may do nothing if it runs before the window is mapped). Modify the
code to avoid losing the expose event. Handling that event should
ensure the window is cleared and otherwise set up properly.
wm4
reimar
Uoti Urpala
Stefano Pigozzi
harklu
diego
iive