| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| |
|
|
|
| |
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.
|
| |
|
|
|
|
|
| |
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_inpu |
