| Commit message (Collapse) | Author | Age | Files | Lines |
|
|
|
|
|
|
|
|
|
|
|
| |
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
|
|
|
|
|
|
|
|
|
|
| |
Add disabled feature: noise filter for vo_gl.
git-svn-id: svn://svn.mplayerhq.hu/mplayer/trunk@34014 b3059339-0415-0410-9bf9-f77b7e298cf2
Hook up -vo gl noise support.
git-svn-id: svn://svn.mplayerhq.hu/mplayer/trunk@34015 b3059339-0415-0410-9bf9-f77b7e298cf2
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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.html
http://lists.freedesktop.org/archives/xorg/2004-September/003395.html
Also fix a minor memory leak when conversion to COMPOUND_TEXT fails.
|
|\ |
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
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.
|
|\ \ |
|
| | |
| | |
| | |
| | |
| | | |
Use the <X11/keysymdef.h> xlib header instead. I'm not sure why mplayer
defined these constants itself.
|
| | | |
|
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
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.
|
|\ \ |
|
| |/
| |
| |
| |
| |
| |
| | |
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.
|
|/ |
|
|
|
|
|
| |
Remove support for building the player without libavcodec and
libavformat. These libraries are now always required.
|
| |
|
|\ |
|
| |
| |
| |
| |
| |
| |
| |
| | |
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.
|
|\| |
|
| |
| |
| |
| |
| | |
Also change the WM_CLASS "application class" string from "MPlayer" to
"mplayer2". This string is visible as application name in Gnome 3.
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
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 20256a8a64c96 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.
|
|
|
|
|
|
|
| |
This option enabled using Mesa specific functions, which have never been
widely supported, and were removed from Mesa in 2010.
http://cgit.freedesktop.org/mesa/mesa/commit/?id=cb2a66fd0c095fe03be5aaf88c8d48f5867425d3
|
|
|
|
|
|
|
|
|
| |
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.
|
|
|
|
|
| |
Before the SDL code would change screen resolution when switching to
fullscreen. Try to keep existing desktop resolution instead.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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.
|
<